DE69522500T2

DE69522500T2 - Computerprogramm zur Qualitätskontrolle

Info

Publication number: DE69522500T2
Application number: DE69522500T
Authority: DE
Inventors: Lars William Johnson; John Mark Lepper; Wallace Anthony Martin; Leonard Ross Reinhart; Ravi Sankar Sanka; Craig William Walker; Daniel Tsu-Fang Wang
Original assignee: Johnson and Johnson Vision Products Inc
Current assignee: Johnson and Johnson Vision Care Inc
Priority date: 1994-06-10
Filing date: 1995-06-09
Publication date: 2002-05-16
Anticipated expiration: 2015-06-10
Also published as: EP0686900B1; DE69522500D1; AU704451B2; US5461570A; JP2007011402A; ZA954790B; EP0686900A3; CZ146795A3; AU2057495A; JPH08202410A; EP0686900A2; BR9502755A; ATE205313T1; IL113948A0; CA2151357C; CA2151357A1

Description

1. Fachgebiet der Erfindung

Diese Erfindung betrifft allgemein eine Anlage zur Herstellung ophthalmischer Kontaktlinsen und insbesondere ein Überwachungssystem zur Kontrolle der Produktionslinien- Prozesse, die in einer solchen Anlage zur Herstellung von Kontaktlinsen angewandt werden, mit dem Ziel der Untersuchung und Optimierung des Herstellungsprozesses.

2. Beschreibung des Standes der Technik

Die Direktformung von Hydrogel-Kontaktlinsen ist beschrieben in den US-Patenten Nr. 4.495.313, welches an Larsen erteilt wurde, Nr. 4.680.336, welches an Larsen und Miterfinder erteilt wurde, Nr. 4.565.348, welches an Larsen erteilt wurde und Nr. 4.640.489, welches an Larsen und Miterfinder erteilt wurde. Diese zitierten Veröffentlichungen beschreiben einen automatisierten Kontaktlinsen-Produktionprozeß, bei welchem jede Linse dadurch geformt wird, daß ein Monomer sandwichartig zwischen einer Hinterkrümmungs- Formhälfte (obere Formhälfte) und einer Vorderkrümmungs-Formhälfte (untere Formhälfte) eingeschlossen wird. Das Monomer polymerisiert und bildet somit die Linse, welche dann aus den Formhälften entnommen, weiterbehandelt und für den Endverbraucher verpackt wird.
Die Herstellung von Kontaktlinsen erfordert strenge Prüfbedingungen und -prozesse, von denen viele durch Computer oder andere Steuervorrichtungen überwacht werden. Viele Informationen beispielsweise in Form von Prozeßbedingungen und Steuerungsdaten, die bei der Herstellung von Kontaktlinsen auftreten, können für Qualitätssteuerungszwecke zusammengeführt werden. Dies führt jedoch zur Erfassung immenser Datenmengen für jede Kontaktlinse, welche hergestellt wird. Weiterhin ist eine Einrichtung zur Verarbeitung der erfaßten Daten in einer Weise erforderlich, die durch Operatoren, Ingenieure, Überwachungspersonal usw. genutzt werden kann, so daß diese ihre Aufgaben exakt erfüllen können. Weiterhin können einige der erzeugten Informationen auf menschlicher Beobachtung, wie beispielsweise bei der Linsenprüfung, beruhen, was nicht so genau ist wie die Verwendung automatischer Sensoren.
Es besteht daher ein Bedürfnis nach der Schaffung eines Qualitätssteuerungssystems, welches Prozeßsteuerungsdaten von einer Vielzahl von Herstellungsprozeß-Steuereinheiten, die verschiedene Aspekte der Kontaktlinsenherstellung in einer Anlage zur Herstellung derselben automatisch erfassen und diese automatisch in Echtzeit verarbeiten, anzuzeigen und zu archivieren vermag.
Es wäre weiterhin höchst erwünscht, ein Qualitätssteuerungssystem zu schaffen, welches die Prozeßsteuerungsdaten für jede spezielle Kontaktlinse von jeder aus der Vielzahl der Bearbeitungsstationen automatisch zusammenzuführen vermag.
Zusätzlich wäre es höchst erwünscht, ein Qualitätssteuerungssystem zu schaffen, welches die Prozeßsteuerungsdaten für jede spezielle Kontaktlinse zusammenführt und ein Einrichtung zur automatischen Korrelation der erfaßten Daten mit jeder speziellen hergestellten Kontaktlinse für Speicherungs- und Optimierungszwecke aufweist.
Es wäre ferner höchst erwünscht ein Qualitätssteuerungssystem für eine Kontaktlinsen- Herstellungsanlage zu schaffen, welche es dem Operator ermöglicht, den speziellen Grund für die Zurückweisung einer Kontaktlinse bei der automatischen Prüfung nach der Herstellung einer fehlerhaften Linse festzustellen.
Das US-Patent Nr. 4.901.242 beschreibt ein System zum Führen der Produktion von Halbleiterschaltungen mit einem Qualitätssteuerungssystem zur Optimierung der Prozeßparameter in einer automatisierten Produktionslinie mit einer Vielzahl von Prozeßstationen. Das System umfaßt einen Prozeß-Führungsblock zum Empfang von Daten bereits ausgeführter Prozeßschritte sowie der Bereitstellung der Bedingungen für noch durchzuführende Prozeßschritte. Das System weist auch einen Sammel-Block zur statistischen Auswertung von Daten bereits durchgeführter Prozesse sowie einen Simulations-Block zur Bestimmung optimaler Bedingungen noch durchzuführender Prozesse auf der Basis der Daten der bereits durchgeführten Prozesse auf. Sollte ein fehlerhaftes Erzeugnis auftreten, so wird durch eine Variation der Bedingungen für nachfolgende Prozesse eine Kompensation angestrebt.
Die Patentschrift GB 2.239.723 beschreibt ein Produktions-Leitsystem mit einer Produktionslinie mit einer Vielzahl von Bearbeitungs- und Montagestationen, einem ersten Informationsnetz zur Übertragung von Steuerungsinformationen an die Stationen sowie einem zweiten Informationsnetz zur Übertragung von Informationen, welche die Ergebnisse von Arbeitsgängen an stromabwärts gelegenen Stationen enthalten. Wenn ein Erzeugnis fehlerhaft ist, wird es nicht den Gesamterzeugnissen zugeführt sondern repariert.
Die US-Patentschrift Nr. 5.134.574 beschreibt eine Vorrichtung zur Leistungssteuerung einer Bearbeitungsanlage sowie ein entsprechendes Verfahren unter Verwendung einer relationalen Datenbank. Die Steuervorrichtung liefert Echtzeit-Angaben zur Leistung von Arbeitsgängen der Anlage in bezug auf den momentanen Zustand der Bearbeitungseinrichtungen. Dadurch wird eine rechtzeitige Änderung an den Bearbeitungseinrichtungen zur Erhöhung der Leistung ermöglicht. Eine Computereinrichtung liefert quantitative Informationen der momentanen Leistung, welche graphisch dargestellt und auch in einer Datenbank gespeichert werden. Die Informationen werden durch Korrelation der Leistungsdaten mit bekannten Fehlerparametern erhalten.

Zusammenfassung der Erfindung

Im Hinblick auf das zuvor Gesagte ist ein Qualitätssteuerungssystem vorgesehen, wie es nachfolgend in Anspruch 1 beansprucht wird.

Kurze Beschreibung der Zeichnungen

Die vorgenannten Aufgaben und Vorteile der vorliegenden Erfindung für ein Kontaktlinsen- Produktionslinien-Palettensystem werden für den Fachmann unter Bezugnahme auf die nachfolgende detaillierte Beschreibung verschiedener bevorzugter Ausführungsformen der Erfindung in Verbindung mit den beigefügten Zeichnungen besser verständlich werden, wobei gleiche Elemente durchweg mit gleichen Bezugszahlen versehen wurden und die einzelnen Figuren darstellen:
Fig. 1 ist ein Organisationsschema der Überwachungs-Steuerungssystem-Anordnung nach der vorliegenden Erfindung.
Die Fig. 2a und 2b zeigen das Speicherschema für Ereignis- bzw. Datenblöcke, die von lokalen PLC erzeugt und vom Datenerfassungsknoten nach der vorliegenden Erfindung erfaßt werden.
Die Fig. 3a zeigt den Datenerfassungsvorgang bei der Erfassung von Ereignis-Datenblöcken von den lokalen PLC.
Fig. 3b zeigt den Datenerfassungsvorgang bei der Erfassung von Prozeßsteuerungs- Datenblöcken von den lokalen PLC.
Fig. 4a zeigt den Datenerfassungsvorgang bei der Erfassung von Linsenprüfdaten von der Sichtprüfungs-Maschine.
Fig. 4b zeigt spezielle Punkte von Linsenprüfdaten, die von der Sichtprüfungs-Maschine zu erfassen sind.
Fig. 5a zeigt die Datenerfassungsfolge zur Erfassung von Linsen-Formungsmaschinen- Prozeßdaten von der Vorderkrümmungs-Formungsmaschine, von der Hinterkrümmungs- Formungsmaschine oder von der Primärverpackungs-Formungsmaschine.
Fig. 5b zeigt spezielle Formungs-Verfahrensdaten, die von der Vorderkrümmungs-Formungsmaschine, von der Hinterkrümmungs-Formungsmaschine oder von der Primärverpackungs-Formungsmaschine zu erfassen sind.
Fig. 6 ist ein Diagramm, welches die funktionellen Beziehungen zwischen dem Steuerungs-Server und anderen Modulen der Überwachungs-Steuereinheit zeigt.
Fig. 7 zeigt einen Ereignisblock und einen Datenblock, die im PLC-Speicher gespeichert sind, welcher der PLC 11 in Fig. 20 zugeordnet ist.
Fig. 8 ist ein vereinfachtes Schema, welches die Wechselwirkungen zwischen den Ursprungsdatenfeldern, den Proben und den Gruppen zeigt.
Fig. 9 ist ein Logik-Flußdiagramm, welches die Wirkungsweise des Steuerungs-Servers bei der Erzeugung von Datenbankaufzeichnungen zeigt.
Fig. 10a zeigt eine Serie von Speicher-Ursprungsdatenwert-Warteschlangen im Steuerungs-Server-Speicher zur Speicherung einer Historie von Datenfeldern bei bestimmten Prozessen.
Fig. 10b zeigt eine typische Probe von Datenfeldern, die in vorgegebener Weise versetzt aus der Speicher-Ursprungsdatenwert-Warteschlange entnommen wurden.
Fig. 10c zeigt eine Anordnung von Proben, die zu einer Gruppe mit einem zugeordneten Index zusammengefaßt wurden.
Fig. 11 zeigt das Format von Prozeßaufzeichnungen, die einer speziellen Palette zugeordnet sind und die zwecks Langzeitspeicherung zur relationalen Datenbank gesandt werden.
Die Fig. 12a und 12b zeigen die geometrische Anordnung der Trägerpaletten, wie sie die Behandlung von der Spritzformung bis zur Hydration durchlaufen.
Die Fig. 12c und 12d zeigen die geometrische Anordnung der Trägerpaletten, wie sie die Behandlung von der Hydration bis zur automatischen Linsenprüfung durchlaufen.
Die Fig. 13a und 13b zeigen Ursprungsdatenwert-Speicher-Warteschlangen für Strichcode-Scanner, welche Paletten ID-(Index-)Informationen von Paletten mit Linsen am Eingang der Hydrationsstation enthalten.
Fig. 14 zeigt ein Diagramm von Prüfergebnissen (y-Achse) als Funktion der Prozeßparameter (x-Achse).
Fig. 15 zeigt ein Balkendiagramm der Anzahl der Linsenfehler an einer bestimmten Position einer Vertiefung einer bestimmten Palette bei mehrfachem Durchlauf dieser Palette durch die Produktionslinie.
Die Fig. 16a bis 16c zeigen den Prozeßablauf zur Erzeugung eines Punktdiagrammes der in der relationalen Datenbank verfügbaren Datenaufzeichnungen.
Fig. 17 zeigt den Prozeßablauf zur Erzeugung eines Balkendiagrammes der in der relationalen Datenbank verfügbaren Datenaufzeichnungen.
Fig. 18 zeigt ein Prozeß-Balkendiagramm, welches einen Eindruck davon liefert, wie sich ein spezieller Prozeßparameter (beispielsweise das Monomer-Einfhul-Niveau) verhält.
Fig. 19 zeigt den Prozeßablauf zur Erzeugung eines Balkendiagrammes der in der relationalen Datenbank verfügbaren Gruppen-Datenaufzeichungen.
Fig. 20 zeigt das Konzept einer schematischen Darstellung eines Palettenträger- und Verfolgungssystems für eine Kontaktlinsen-Produktionslinie.
Die Fig. 21a und 21b zeigen den Ablauf zur Erzeugung einer Prozeßparameter- Aufzeichnung in bezug auf eine feste Zeitskala, um Trends der Prozeßparameter im System darzustellen.
Fig. 22a zeigt eine Pareto-Tabelle der gezählten Alarme für die Produktionslinie.
Fig. 22b zeigt eine Pareto-Tabelle der gezählten Alarme geordnet nach ihrer Dauer.
Fig. 23 zeigt den Prozeßablauf zur Erzeugung einer Pareto-Tabelle, wie sie in den Fig. 22a, 22b oder 22c dargestellt ist.

Beschreibung der bevorzugten Ausführungsform

Wie in der gleichzeitig eingereichten Patentanmeldung mit dem Aktenzeichen VTN-96 diskutiert, wird hier eine Anlage zur Herstellung von Kontaktlinsen beschrieben, welche mit einer Vielzahl programmierbarer und nicht programmierbarer Steuereinheiten zur Steuerung und Überwachung verschiedener Herstellungsprozesse ausgestattet ist, wobei die Anlage zur Herstellung der Kontaktlinsen dieselben mit einer Geschwindigkeit von 8 Stück in jeweils 6 Sekunden produziert.
Im einzelnen gibt es zwei programmierbare Logik-Steuereinheiten (PLC), die in den Fig. 1 und 20 mit 11 und 12 bezeichnet sind, zur Steuerung der Überführung von jeweils acht Vorderkrümmungs-Einspritz-Formhälften (FC) und acht Hinterkrümmungs-Einspritz-Formhälften (BC) aus den Spritzform-Maschinen (Fig. 20) zu den jeweiligen Trägerpaletten, die in der Nähe eines ersten bzw. eines zweiten Palettenförderers 27 bzw. 29 angeordnet sind. Die beiden Palettenförderer sind teilweise von einer Kammer mit niedrigem Sauerstoffgehalt umschlossen. Die Funktionsweise ist detailliert in der gleichzeitig eingereichten Patentanmeldung mit dem Aktenzeichen VTN-78 beschrieben.
Wie in den Fig. 1 und 20 dargestellt, steuert eine dritte PLC 13 die Monomer-Füllung sowie die Arbeitsgänge der Kontaktlinsen-Formbaugruppe, wie es detailliert in der gleichzeitig eingereichten Patentanmeldung mit dem Aktenzeichen VTN-80 beschrieben ist.
Diese PLC steuert die Prozeßbedingungen für die Monomer-Füllung, welche darin besteht, in einer Vakuum-Umgebung eine polymerisierbare Verbindung (ein Monomergemisch) zur Formung einer Kontaktlinse in den konkaven Teil jeder Vorderkrümmungs-Formhälfte in jeder Trägerpalette 71a einzubringen und auch das Zusammenfügen der einzelnen Kontaktlinsen-Formbaugruppen zu steuern, welches das Aufnehmen einer jeden Hinterkrümmungs- Formhälfte von der Palette und deren Plazierung in geordneter Anordnung auf den zugehörigen Vorderkrümmungs-Formhälften, die auf der angrenzenden Trägerpalette 71a aufliegen, umfaßt.
Wie in den Fig. 1 und 20 dargestellt, steuert eine vierte PLC 14 das Vor-Aushärten, das UV-Aushärten sowie die Entformungs-Arbeitsgänge der Kontaktlinsen-Produktionslinie. Diese PLC wird wirksam, um den Vor-Aushärtungsprozeß zu steuern, wobei die in jeder Formbaugruppe enthaltene Monomer-Lösung zu einem viskosen, gelartigen Zustand teilweise ausgehärtet wird und wobei die Vorderkrümmungs-Formhälfte und die Hinterkrümmungs-Formhälfte einem vorgegebenen Druck unterworfen werden, um weiterhin eine Anlage an die Kontaktlinsenkanten zu bewirken und eine Dezentrierung zu verhindern. Einzelheiten zur Funktion des Vor-Aushärtens sind detailliert in der gleichzeitig eingereichten Patentanmeldung mit dem Aktenzeichen VTN-83 beschrieben.
Einzelheiten zur Funktion der UV-Aushärtung von Kontaktlinsen sind detailliert in der gleichzeitig eingereichten Patentanmeldung mit dem Aktenzeichen VTN-87 beschrieben.
Ganz allgemein steuert die vierte PLC auch den Polymerisationsprozeß in UV-Öfen, wo die in einzelnen Formbaugruppen befindlichen vor-ausgehärteten Linsen zu Kontaktlinsenrohlingen geformt werden. Einzelheiten zur Funktion der Entformungs-Arbeitsgänge von Kontaktlinsen sind detailliert in der gleichzeitig eingereichten Patentanmeldung mit dem Aktenzeichen VTN-82 beschrieben.
Im allgemeinen werden die Hinterkrümmungs-Formhälften der Formbaugruppen automatisch von den Vorderkrümmungs-Formhälften getrennt, um die polymerisierten Kontaktlinsen zur Förderung zur stromabwärts gelegenen Hydrationsstation freizulegen.
Wie in den Fig. 1 und 20 dargestellt, steuert eine fünfte PLC 15 die Überführung der Vorderkrümmungs-Formhälften mit den geformten Kontaktlinsen zu einer Hydrationskammer, wo die Kontaktlinsen hydratisiert werden. Dies ist in der gleichzeitig eingereichten Patentanmeldung mit dem Aktenzeichen VTN-74 beschrieben.
Wie in der Fig. 1 dargestellt, steuert eine sechste PLC 16 die Arbeitsgänge nach der Hydration, was in der gleichzeitig eingereichten Patentanmeldung mit dem Aktenzeichen VTN- 81 mit weiteren Einzelheiten beschrieben ist.
Die Arbeitsgänge nach der Hydration umfassen die Erzeugung von Kontaktlinsen- Prüfdaten, wozu die Gut-Ausschuß-Ergebnisse gehören, die von einem automatischen Sichtsystem einer automatischen Linsenprüfstation (nicht dargestellt) ermittelt werden.
Eine siebente PLC 17 steuert die Arbeitsgänge des Linsen-Verpackungssystems hinsichtlich der Primär-Verpackung sowie der Verdichtung bei der Verpackung der Linsen, was in der gleichzeitig eingereichten Patentanmeldung mit dem Aktenzeichen VTN-150 mit weiteren Einzelheiten beschrieben ist. Sie steuert auch solche Prozesse, wie den Lösungsaustausch, das Einfüllen einer Salzlösung, das dichte Verschließen der Packung mittels Wärme usw., die auf einem Drehtisch (Verpackungs-Drehtisch) erfolgen, wie es in der gleichzeitig eingereichten Patentanmeldung mit dem Aktenzeichen VTN-93 mit weiteren Einzelheiten beschrieben ist.
Zusätzlich kann eine achte PLC (nicht dargestellt) vorgesehen werden, um die verschiedenen Arbeitsgänge einer Sekundär-Verpackung zu steuern, welche die Überführung der Packungen vom Drehtisch in den Sekundär-Verpackungsbereich sowie die anschließende Sterilisation der Packungen an einer Sterilisationsstation umfassen, deren Einzelheiten in der gleichzeitig eingereichten Patentanmeldung mit dem Aktenzeichen VTN-152 beschrieben sind.
Bei der bevorzugten Ausführungsform besteht jede PLC aus einem System TI 545 (Texas Instruments) und kann ein TI 386/ATM-Koprozessor-Modul zur Verbindung zur jeweiligen PLC über eine Rückseiten-Verdrahtung oder über eine serielle Verbindung (nicht dargestellt) enthalten. Es versteht sich, daß jede PLC ihren eigenen Speicher sowie Adressierungseinrichtungen zur Speicherung und Aktualisierung von Datenblöcken enthält, was später mit weiteren Einzelheiten erläutert werden wird.
Weitere programmierbare Steuereinheiten sind in der Kontaktlinsen-Produktionslinie zur Steuerung der Vorderkrümmungs-Formungs-Maschine 18a, welche die Vorderkrümmungs- Formhälften mit einer Geschwindigkeit von acht Stück alle sechs Sekunden produziert bzw. der Hinterkrümmungs-Formungs-Maschine 18b, welche die Hinterkrümmungs-Formhälften produziert sowie weiterhin für die Primär-Verpackungs-Maschine 19 vorgesehen, welche die Kontaktlinsen-Verpackungen produziert, in welchen die hergestellten Kontaktlinsen aufgenommen werden. Diese programmierbaren Vorrichtungen werden von der Yushin Corp. hergestellt.
Eine andere Vorrichtungs-Steuereinheit 20 steuert ein Sichtsystem, welches die Kontaktlinsen vor ihrer Verpackung automatisch prüft. Einzelheiten zur Funktion sind detailliert in den gleichzeitig eingereichten Patentanmeldungen mit den Aktenzeichen VTN-101 und VTN- 102 beschrieben. Die Vorrichtungs-Steuereinheit 20 wird von der Fa. Perceptics in Knoxville, Tennessee, hergestellt.
Wie in der oben erwähnten Patentanmeldung mit dem Aktenzeichen VTN-96 beschrieben, bewirkt ein Produktionslinien-Palettensystem den Hochgeschwindigkeits-Transport der Hinterkrümmungs-Formhälften und der Vorderkrümmungs-Formhälften durch die verschiedenen Bearbeitungsstationen einer Kontaktlinsen-Herstellungsanlage zur Herstellung derselben. Die Produktionslinie selbst ist mit einer Vielzahl von Strichcode-Lesevorrichtungen versehen, die in der Fig. 20 als Elemente 80 bis 89 bezeichnet und an strategischen Stellen der Fabrikationsanlage montiert sind. Jede der Strichcode-Lesevorrichtungen 80 bis 89 ist vorzugsweise ein Strichcode-Laserscanner, Modell Scanstar 110, hergestellt von der Firma Computer Identics Corporation in Canton, Massachusetts. Diese Lesevorrichtungen sind dafür vorgesehen, jede einzelne Palette, bzw. die von der Palette getragenen Kontaktlinsen- Formhälften oder Formbaugruppen zu identifizieren. Im einzelnen identifiziert jeder Strichcode-Scanner an den in Fig. 20 dargestellten Stellen jede unter ihm durchlaufende Trägerpalette durch Abtastung des unverwechselbaren Identifizierungs-Strichcodes (nicht dargestellt) auf der Palette. Jeder Strichcode-Scanner ist mit einer Decodierungseinheit, wie beispielsweise vom Typ Scanstar Modell-Nr. 240 (nicht dargestellt) versehen, so daß die Information in Gestalt einer Paletten-Identifikationsnummer in jeden zur Position der Trägerpalette im Palettensystem zugeordneten PLC-Speicherplatz eingegeben wird. Weiterhin werden Zeitmarkendaten durch die PLC aufgezeichnet, d. h. es erfolgt eine Zeitabtastung der Palette.
Die Beschreibung der oben erwähnten Trägerpalette, welche jeweils acht Kontaktlinsen- Formbaugruppen trägt, ist in der gleichzeitig hinterlegten Patentanmeldung mit dem Aktenzeichen VTN-77 zu finden.
Die Fig. 12a zeigt den konzeptionellen Entwurf für eine Trägerpalette 71a, welche Vorderkrümmungs-Formhälften (nicht dargestellt) oder Formbaugruppen (nicht dargestellt) trägt sowie einer Trägerpalette 71b, welche Hinterkrümmungs-Formhälften (nicht dargestellt) trägt. Jede Palette ist austauschbar, so daß sie jede der beiden Arten von Formhälften tragen kann. Weiterhin sind in Fig. 12a die Vertiefungspositionen 73 zur Aufnahme der einzelnen Vorderkrümmungs-Formhälften, Hinterkrümmungs-Formhälften oder Formbaugruppen auf der Trägerpalette zu erkennen. Wie weiter unten mit weiteren Einzelheiten erläutert werden wird, sind die Vertiefungspositionen zur Verfolgung und zeitlichen Koordinierung numeriert. Dies betrifft historische Prozeßsteuerungsdaten, welchen durch den gesamten Produktionsprozeß hindurch zusammen mit den Kontaktlinsen-Sichtprüfungs-Gut- und -Ausschußdaten für jede produzierte Linse und jede Vertiefung in der Trägerpalette erzeugt und gespeichert werden. Wie weiterhin beschrieben werden wird, wurde eine relationale Datenbank entwickelt, welche zur Speicherung von Produktionsaufzeichnungen und Langzeit-Daten-Vorgeschichten verwendet wird. Das Überwachungs-Steuerungssystem 10 bewirkt einen Off-Line-Zugriff auf diese Datenbank und weist einen Mechanismus zur Erzeugung informativer graphischer Darstellungen auf. Dazu gehören ohne Einschränkung darauf Punktdiagramme von Prozeßparametern in Abhängigkeit von den Kontaktlinsen- Prüfergebnissen, Balkendiagramme von Fehlern in Abhängigkeit von der Position auf der Palette, Pareto-Tabellen von Alarmereignissen in Abhängigkeit von der Maschinenlaufzeit, zeitliche Aufzeichnungen kumulierter Prüfergebnisse, gemessene und berechnete Parameter die als Einzeltrend als Funktion der Zeit aufgezeichnet werden, wobei die Trends über festgelegte Zeitskalen über Minuten, Stunden, Tage und Wochen verfügbar sind.
Wie in Fig. 1 dargestellt, wird die Leistung einer Kontaktlinsen-Produktionslinie durch die Überwachungs-Steuereinheit 10 nach der vorliegenden Erfindung überwacht und analysiert. Bezug nehmend auf Fig. 1 sind die Hardware-Elemente der Überwachungs-Steuereinheit 10 sowie die hauptsächlichen Software-Bestandteile in jedem der Hardware-Elemente dargestellt. Im wesentlichen umfaßt das Überwachungs-Steuerungssystem (Steuerungssystem) fünf Typen von Verarbeitungsknoten: einen Datenerfassungsknoten 100 zur Verbindung mit jeder der sieben oben besprochenen programmierbaren Logik-Steuereinheiten (PLC) über die Verbindungsleitungen 21a sowie die TIWAY-Adapterkarte 21b und auch zur Verbindung zu den Steuereinheiten der drei Form-Maschinen sowie zur Sichtprüfungs-Maschine über eine serielle 8-Kanal-Karte 22, wobei die Verbindung zu den Maschinen durch leistungsfähige asynchrone serielle Leitungen 23a, 23b, 23c und 23d erfolgt, wie in Fig. 1 dargestellt. Die Verbindung erfolgt weiter über einen relationalen Datenbank-Knoten 220, welcher mit einer relationalen Datenbank-Software 202 arbeitet und mindestens drei 200 MB-Festplatten zur Off-Line-Datenspeicherung von Produktionsaufzeichnungen und Langzeit-Daten-Vorgeschichten enthält; über einen Analyse- und Weg-Leit-Knoten 300, welcher den Großteil der Software enthält, die benutzt wird, um die Daten der sieben PLG zusammenzuführen und deren Ursprungsdatenwerte zu bearbeiten und welcher "Echtzeit- Datenbanken" enthält, die statistische Prüfpläne und andere Anzeigen unterstützen; vier identisch aufgebaute Bedienungsstationen 400, welche die Anzeige graphischer Darstellungen und Displays für das Bedienungspersonal der Anlage bearbeiten sowie einen Off-Line- Analyse-Knoten 500, welcher für die Analyse der im relationalen Datenbank-Knoten gesammelten Daten sorgt, nachdem die Daten nicht mehr "On-Line" sind, d. h. nach einem bestimmten Zyklus der Produktionslinie. Wie in Fig. 1 dargestellt, sind ARCNET- Schnittstellenkarten 101, 201, 301, 401 und 501 für die entsprechenden Knoten 100, 200, 300, 400 und 500 vorgesehen, um die Datenübertragung zwischen den verschiedenen Knoten zu unterstützen. Ein ARCNET-Netz 99 unterstützt die Datenübertragung zwischen den sieben zuvor genannten Prozessoren.
Zusätzlich ist, wie in Fig. 1 dargestellt, ein Standard-Steuereinheiten-Software-Modul vorgesehen, um dem Überwachungs-Steuerungssystem 10 zusätzliche Funktionen zu erteilen. Der Alarm-Server 402 in der Operatorstation 400 bearbeitet Bearbeitungszellen- Alarme, -Warnungen sowie Ausnahmen, die entsprechend der definierten Bedingungen aktiviert werden. Ein Konsolen-Server 403 liefert an den Operator eine Nur-Text-Darstellung mit einer Eingabevorrichtung, um eine Datenübertragung zu allen anderen Administratoren zu ermöglichen. Der Anzeige-Server 404 bewirkt eine Datenausgabe unter Verwendung graphischer Darstellungen der Bearbeitungszellen. Der Graphik-Server 405 bewirkt eine Datenausgabe in Form verschiedener graphischer Darstellungen und Diagramme auf einem Computer-Graphik-Bilschirm. Dieser Server unterstützt die Anzeige und die Echtzeit- Aktualisierung von Kurven, Punktdiagrammen, Balkendiagrammen, Pareto-Tabellen, x- Balkendiagrammen und anderer graphischer Darstellungen sowie auch typischer Koordinatenlinien und Normal-(Gauß-)verteilungen, um die berechneten statistischen Informationen in den angezeigten graphischen Darstellungen oder Diagrammen zu verdeutlichen. Der Statistik-Server 406 ist eine Echtzeit-Datenbank für die Produktionslinie und speichert Daten in logischen benutzerdefinierten Gruppen oder Datensätzen. Er ist in der Lage, Statistiken oder (wahlweise) Alarme zu Datensätzen zu erzeugen. Jeder der o. g. Server enthält eine handelsübliche Standard-CELLworks-Software, wie sie von der Firma FASTech Integration mit Sitz in Lincoln, Mass., hergestellt wird.
Weitere Software-Module, die sich in jeder Hardware-Einheit befinden, wie sie in Fig. 1 dargestellt ist, umfassen: Einen Nutzer-Schnittstellen-Manager 502, wobei es sich um einen Modul handelt, welcher diejenigen Aktivitäten koordiniert, die zur Änderung der Bildschirmansichten an der Operatorstation 400 erforderlich sind. Einen Abfrager 505, welcher die Erfassung aller Daten von den PLC, Form-Maschine und von der Sichtprüfungs- Maschine koordiniert. Einen in C programmierten Daten-Server 510, welcher Blöcke von Informationen von den PLC übernimmt, feststellt, welche Daten-Positionen sich in den Blöcken geändert haben und die geänderten Werte an einen Steuerungs-Server 600 sendet. Ein Ereignis-Server 503 ist ein in C programmierter Server, welcher Blöcke von Ereignis- Codes von den PLC übernimmt, die genaue Alarmfolge für den Ereignis-Code lokalisiert und die Folge an den Alarm-Server weiterleitet. Der in C programmierte Steuerungs-Server 600 ist ein Partnermodul zum Statistik-Server und steuert den Statistik-Server zur Ausführung statistischer Funktionen, wie sie zum Betrieb aktiver Anzeige-Einheiten benötigt werden. Wenn die beobachteten Anzeigen geändert werden, gibt der Steuerungs-Server 600 neue Befehlssätze an den Statistik-Server. Der in C programmierte Statistik-Zähl-Server 506 hält einen fortlaufenden Zählwert der Frequenz der verschiedenen Zustands-Codes, so daß schnell eine Pareto-Tabelle der Zustands-Codes für eine bestimmte Stelle (beispielsweise für den Ausgang der Entformungsstation) angezeigt werden kann, und ein Typen- Server 508 wandelt die numerischen Codes in Textfolgen um und nutzt Bool'sche Werte zum Ein- und Ausschalten farbiger Graphiken. Zur Kommunikation mit den Texas Instruments PLC's ist ein ti_adm-Server 512 vorgesehen, um das Verbindungsprotokoll zu handhaben, welches mit der PLC-Kommunikation verknüpft ist.
Die in C programmierten Form-Server 514a, 514b und 514c empfangen jeweils Nachrichtendaten von einer jeweiligen Form-Maschine 18a, 18b und 19, entnehmen den Nachrichten Daten und leiten alle geänderten Daten an den Steuerungs-Server 600 weiter. Der in C programmierte Sicht-Server 525 empfängt Nachrichtendaten von der Sichtprüfungs-Maschine 20, entnimmt aus diesen Nachrichten Informationen und leitet alle geänderten Daten an den Steuerungs-Server 600 weiter. Der in C programmierte Alarm-Steuerungs-Server 528 hält die Synchronisation des Alarm-Servers, hält die Frequenz der Alarmzustände und deren Dauer, um Pareto-Tabellen der Alarme zu unterstützen und löscht automatisch PLC- Alarme, so daß die PLC als gelöscht gemeldet wird.
Die funktionellen Beschreibungen der Hardware- und der Software-Module des Überwachungs-Steuerungssystems 10 nach der vorliegenden Erfindung soll nachfolgend mit weiteren Einzelheiten besprochen werden.

Datenterfassung

Wie oben erwähnt, gibt es zwei Typen von Eingabe-Ursprüngen für die Überwachungs- Steuereinheit 10: die acht PLC und die Steuereinheiten der Spritzform-Maschinen sowie der Maschine zu Sichtprüfung. Nun soll die Anordnung der Ereignisblöcke sowie der Datenblöcke beschrieben werden, welche die Überwachungs-Steuereinheit aus den acht PLC ausliest. Es versteht sich, daß jede PLC zur Datenerfassung mindestens einmal in sechs Sekunden automatisch abgefragt wird. Jedoch werden die Daten von jeder PLC asynchron an die jeweiligen Ereignis- und Datenblöcke bereitgestellt. Das Überwachungs-Steuerungssystem 10 weist einen Prozessor-Taktgeber (nicht dargestellt) auf, der mit 33 MHz läuft und für einen Systemtakt für die Abfragefunktion des Datererfassungsknoten 100 und für andere Steuerungs-Server-Funktionen sorgt.
Die Fig. 2a und 2b zeigen die Struktur eines Ereignis-Datenblockes 30 und eines Prozeß-Datenblockes 40, der von der PLC aus den erfaßten Daten erzeugt wird. Jeder Ereignisblock besteht aus einer Gruppe aufeinanderfolgender Register (Speicherplätze) in jeder der Texas-Instruments-PLC. Die Überwachungs-Steuereinheit fragt die PLC vorzugsweise alle sechs Sekunden nach Ereignis- und Datenblock-Inhalten ab.
Der erste Eintrag im Ereignisblock 30 ist die Daten-Gültigkeits-Markierung 32, welche den Wert 1 hat, wenn der Block schlüssige Daten enthält. Ein Wert 0 in der Daten-Gültigkeits- Markierung zeigt an, daß der Block aus der PLC ausgelesen wurde, während die spezielle PLC gerade die Aktualisierung des Blockinhaltes durchführte. In diesem Falle wird der Block erneut gelesen.
Der zweite Eintrag im Ereignisblock 30 ist ein sequentieller Zähler 35, d. h. eine fortlaufende Zahl, welche jedes mal dann um eins erhöht wird, wenn ein neues Lesen erfolgt. Eine Änderung des Zählerwertes wird benutzt, um die Überwachungs-Steuereinheit zu informieren, daß der Block zusätzlich zur Anzahl neuer Ereigniscodes im Block einen anderen Blockinhalt hat. Die Anzahl neuer Ereigniscodes wird zum letzten Wert des Zählers addiert.
Schließlich wird im Block eine Anordnung von Ereigniscodes 38 gespeichert. Der letzte Ereigniscode erscheint zuerst, gefolgt vom vorletzten Ereigniscode bis zur letzten berücksichtigten Eintragung, welche der fernste Ereigniscode ist.
Im Datenblock 40 ist die erste Eintragung die Daten-Gültigkeits-Markierung 40, die in der gleichen Weise funktioniert, wie es oben für die Ereignisblöcke beschrieben wurde.
Der Zähler 45 im Datenblock 40 wird benutzt, um anzuzeigen, daß die Datenwerte im Block potentiell neue Informationen enthalten. Es ist eine Zahl, die mit jedem neuen Lesevorgang um eins erhöht wird. Auf den Zähler folgt eine blockspezifische Folge von Datenwerten 48. Jeder Wert wird einer anderen Variablen in der Überwachungs-Steuereinheit zugeordnet, wie es nachfolgend im Detail beschrieben werden wird. Der Zähler kann auch verwendet werden, um festzustellen, ob Daten für den Prozeßzyklus nicht im Takt gelesen wurden.
Fig. 3a zeigt den Fluß der von der PLC erzeugten Ereignisblock-Daten durch die Überwachungs-Steuereinheit 10.
Im Abfrager 505 wird eine Liste der in der PLC vorhandenen Ereignisblöcke durch eine Abtastung pro Takt bearbeitet, d. h. es wird eine Anforderung für jede PLC 11 bis 17 des Netzes ausgesandt. Jede Blockanforderung wird einmal pro Takt vom Ereignis-Server 503 bearbeitet. Der Ereignis-Server gibt eine Leseanforderung für den Block aus dem ti_adm 512 aus, welcher mit der TIWAY-Schnittstellenkarte 216 in Verbindung steht, und die PLC sind an die TIWAY angeschlossen. Der ti_adm 512 sendet eine "Leseblock"-Anforderung an die richtige PLC, so daß die PLC den Block aus ihrem Speicher auslesen kann. Die PLC reagiert durch Senden des Blockes über das TIWAY-Netz an den ti_adm 512. Wenn die Daten-Gültigkeits-Markierung 32 in der Antwort eine 1 ist, dann werden die Daten als gültig angesehen und zum Ereignis-Server 503 gesandt. Wenn die Daten-Gültigkeits-Markierung eine 0 ist, dann wird der ti_adm 512 der PLC die Anforderung senden, den Ereignisblock erneut zu lesen. Der ti_adm 512 sendet den auf Gültigkeit geprüften Datenblock dann zum Ereignis-Server, welcher dann eine "Block-vollständig"-Nachricht zum Abfrager sendet, die darüber informiert, daß der Block erfolgreich empfangen wurde. Der Ereignis- Server 503 prüft dann den Zähler 35 im Block 30, um festzustellen, ob sich der Zählwert gegenüber dem vorhergehenden Ereignisblock 30 (für diese spezielle PLC) geändert hat. Wenn er sich geändert hat, ist die Differenz zwischen dem vorhergehenden und dem neuen Zählwert gleich der Anzahl der Ereigniscodes im neuen Ereignisblock. Für jeden der neuen Ereigniscodes sendet der Ereignis-Server 503 die entsprechende Alarmfolge an den Alarm- Server. Wenn Ereignisse vom Ereignis-Server bearbeitet werden, wird ein Vier-Bit-Code gebildet indem der von der PLC gesandte Drei-Bit-Code durch Anhängen eines einzelnen Bits ergänzt wird, welches die PLC identifiziert, von welcher der Code kam. Wenn beim Lesen eines Ereignisblockes 30 ein Fehler auftritt, wird durch den Abfrager ein Alarm in geeigneter Weise ausgelöst. Sowohl die Ereigniscodes vom Ereignis-Server als auch die Fehlercodes vom Abfrager werden an den Alarm-Steuerungs-Server 528 gesandt.
Der Durchlauf der von den PLC erzeugten Prozeßdaten durch die Überwachungs-Steuereinheit 10 ist in Fig. 3b dargestellt und entspricht dem Durchlauf, der für die Ereignisblock-Daten beschrieben wurde. Im Abfrager 505 wird eine Liste der in der PLC vorhandenen Datenblöcke 40 durch eine Abtastung pro Takt bearbeitet, d. h. es wird eine Anforderung für jede PLC 11 bis 17 des Netzes ausgesandt. Ein Beispiel für zwei Blöcke von Informationen ist in Fig. 7 dargestellt, welche einen Ereignisblock 78 und einen Datenblock 79 zeigt, die im PLC-Speicher für die PLC 11 gespeichert werden, welche die Überführung der Vorderkrümmungs-Formhälfte zur Trägerpalette steuert (Fig. 20). Jede Blockanforderung wird einmal pro Takt vom Daten-Server 510 bearbeitet. Der Daten-Server 510 gibt eine Block-Lese-Anforderung zum ti_adm 512, welcher mit der TIWAY-Schnittstellenkarte 216 und mit den PLC in Verbindung steht. Der ti_adm 512 sendet eine "Block-Lese"- Anforderung an die richtige PLC und empfängt die Anwort der PLC.
Wenn der Daten-Server 510 einen Block vom ti_adm 512 empfängt, wird die Daten- Gültigkeits-Markierung gelesen, und wenn diese gleich Null ist, fordert der ti_adm 512 von der PLC, den Datenblock erneut aus dem Speicher zu lesen. Zusätzlich wird der Zähler 45 im Block überprüft, um festzustellen, ob er sich gegenüber dem Zählwert geändert hat, welcher zuvor für diesen Blocktyp empfangen worden ist. Wenn die Zählwerte die gleichen sind, erfolgt keine weitere Bearbeitung. Wenn sich die Zählwerte gegenüber der letzten Auslesung unterscheiden, dann wird das jeweilige einzelne Datenfeld im Block wie folgt bearbeitet:
Der Daten-Server 510 sucht ausschließlich nach Änderungen der Werte der Datenfelder 48 und bearbeitet nur diese. Jedes Datenfeld wird im Vergleich zum vorhergehenden Wert dieses Datenfeldes geprüft. Wenn es keine Änderung im Wert des Datenfeldes gibt, geht der Daten-Server zur Bearbeitung des nächsten Datenfeldes im Block über. Wenn sich das Datenfeld gegenüber seinem vorhergehenden Wert geändert hat, dann wird das Datenfeld unter Verwendung einer gesonderten VALUE-Nachricht für jeden Datenpunkt zum Steuerungs- Server (CTRL_SRV) 600 weitergeleitet. Anzumerken ist, daß beim Lesen eines Fehlers im Datenblock ein Alarm erzeugt und zum Alarm-Steuerungs-Server 528 gesandt wird.
Die Syntax für die VALUE-Nachricht wird wie folgt dargestellt:
VALUE < Ursprungsname> < Wert>
wobei der Ursprungsname der Name des einzelnen Datenpunktes und der Wert die Ablesung der Prozeßparameter-Messung ist. Ein Beispiel einer Wert-Nachricht, welche eine O&sub2;- Konzentration an einem Sauerstoffsensor von 0,0843% anzeigt, lautet wie folgt:
VALUE CD/O2_LEV_2 84,3.
Nachdem alle VALUE-Nachrichten für einen Block gesendet worden sind, sendet der Daten-Server eine COUNTER-Nachricht an den Steuerungs-Server. Die COUNTER-Nachricht wird verwendet, um die Bearbeitung des Blockes im Steuerungs-Server auszulösen.
Die Syntax für eine COUNTER-Nachricht wird wie folgt dargestellt:
COUNTER < Zählername> < Zählwert>
wobei "Zählername" der Name des Zählers und "Zählwert" dessen Wert ist.
Die von jeder der Form- und Sichtprüfungs-Maschinen gesandten Werte haben nicht das Blockformat der von den PLC kommenden Daten, und die Spritzformungs- und Sichtprüfungs-Steuereinheiten werden auch nicht abgefragt. Statt dessen senden die Formungs- und Sichtprüfungs-Steuereinheiten Nachrichten an die Überwachungs-Steuereinheit, bei denen es sich um Textfolgen handelt, die abgesandt werden, wenn die Information an der betreffenden Maschine anfällt. In den Fig. 4a und 5a ist der Prozeß der Datengewinnung an diesen Maschinen dargestellt.
Für die Sicht- und Form-Maschinen nutzen der Sicht-Server 525 (und jeder der Form- Server 514a, 514b und 514c) Betriebssystem-Kommunikations-Dienstprogramme, um eine Leseanforderung auszugeben. Dies erfolgt nur ein Mal beim Systemstart. Die Betriebssystem-Kommunikations-Dienstprogramme senden dann eine Leseanforderung zur seriellen Schnittstellenkarte 22, die mit den jeweiligen Form- und Sicht-Maschinen verbunden ist. Im Falle der Sichtprüfungs-Maschine 20 sendet diese nach jedem Sichtprüfungszyklus Prüfdaten über die serielle Schnittstelle an die Überwachungs-Steuereinheit. Die Daten werden als Serien von ASCII-Nachrichten, eine Nachricht je Linse, abgesandt. Die Nachrichten werden durch die Betriebssystem-Kommunikations-Dienstprogramm-Software aneinander gekettet. Der Sicht-Server 525 analysiert jede der Nachrichten, zerlegt sie durch Entnahme von neun Datenfeldern aus der Nachricht und leitet die neun Datenfelder unter Verwendung von VALUE- und COUNTER-Nachrichten an den Steuerungs-Server 600 weiter. Für jede Gruppe von acht Linsen wird auch ein Zählwert an den Steuerungs-Server berichtet, so daß der Steuerungs-Server eine Blockverarbeitung durchführen kann.
Wie es mit weiteren Einzelheiten in den oben erwähnten Anmeldungen mit den Aktenzeichen VTN-101 und VTN-102 erläutert ist, umfassen die Sichtprüfungs-Ergebnisse für jede geprüfte Linse einen Datenstrom 50, wie er in Fig. 4b dargestellt ist. Der Datenstrom umfaßt einen Eintrag 51 für eine spezielle Linsennummer (1 bis 16) auf der Linsen-Prüfpalette, den Gut-/Auschuß-Eintrag 52 für diese Linse, die Ergebnisse bezüglich innerer Fehler bzw. der inneren Punktbewertung 53 und bezüglich der äußeren Fehler bzw. der äußeren Punktbewertung 54, bezüglich der kombinierten Fehler und der kombinierten Punktbewertung 55, die Gesamt-Punktbewertung der Linse 56 sowie den Linsenmitten-Prüfcode 57. Diese Daten werden in einer Gruppe von Datenproben gespeichert, was weiter unten diskutiert werden wird, und jeder speziellen Palette für eine Langzeitspeicherung in der relationalen Datenbank zugeordnet.
In entsprechender Weise sendet jede Form-Maschine nach jedem Formspritz-Zyklus Prozeßdaten über die serielle Schnittstelle an die Überwachungs-Steuereinheit. Die Daten werden als Serien von ASCII-Nachrichten, eine Nachricht je Palette mit Linsenformen, abgesandt. Die Nachrichten werden durch die Betriebssystem-Kommunikations-Dienstprogramm-Software aneinander gekettet. Jeder einzelne Form-Server analysiert jede der Nachrichten, zerlegt sie durch Entnahme von vierzehn Datenfeldern aus der Nachricht und leitet die vierzehn Datenfelder unter Verwendung von VALUE- und COUNTER-Nachrichten an den Steuerungs-Server 600 weiter.
Die typischen Datenfelder für die Form-Steuereinheiten sind in Fig. 5b dargestellt und umfassen einen Datenstrom 60 mit etwa vierzehn Einträgen, nämlich: einen Eintrag 61 mit einer Zeitmarken-Information, welche nicht an den Steuerungs-Server 600 gesandt wird, einen Eintrag 62, welcher lokal erzeugt wird und die Anzahl der produzierten Linsenformen angibt sowie weitere andere Form-Steuereinheiten-Bearbeitungsbedingungen wie: Zykluszeit (Eintrag 63), Plastifzierungszeit (Eintrag 64), Einspritz-Spitzendruck (Eintrag 66), Temperaturen der Einspritzformen (Einträge 67 und 68) usw. Auch hier identifiziert jeder Form-Server S 14 jedes Datenfeld mit einem unterscheidbaren Namen, wenn es zum Steuerungs-Server gesandt wird.
Wie später noch im Detail erläutert werden wird, werden die VALUE-Nachrichten, nachdem sie vom Steuerungs-Server empfangen wurden, weiter bearbeitet und mit einem speziellen Index korreliert, d. h. Paletten-Nummer und Zeitmarke, so daß historische Aufzeichnungen der Prozeßsteuerungsdaten zusammen mit Prüfergebnissen sowie Aufzeichnungen von Ereignissen in einer relationalen Datenbank archiviert werden können. Die bei jeder Palette beim Durchlauf durch die Produktionslinie angewandten Prozeßparameter werden, wie oben erwähnt, auch in einer permanenten Datenbank archiviert, und jede geprüfte Linse kann zu ihrer Herstellungs-Palette zurückverfolgt werden.

Steuerungs-Server

Die funktionellen Aufgaben des Steuerungs-Servers betreffen: Weiterleiten der Daten- Nachrichten zum STATISTIC-Server 406, Aufbereiten dynamischer Einstelldaten für den STATISTIC-Server, so daß er die Datenanforderungen für Benutzer-Schnittstellen- Bildschirme (nicht dargestellt), wenn sie sich ändern, unterstützen kann sowie das Sammeln von Daten aus Bearbeitungsdurchlauf-Aufzeichnungen und Weiterleiten der Aufzeichnungen zur Archivierung an die relationale Datenbank 202.
Fig. 6 ist eine schematische Darstellung der funktionellen Beziehungen zwischen dem Steuerungs-Server 600 und den anderen Module der Überwachungs-Steuereinheit 10.
Beim Systemstart liest der Steuerungs-Server 600 die Start-Konfigurations-Dateien 610 ("Dateien-Einbau"), welche die Organisation der Datenverarbeitung im Steuerungs-Server und wie er mit ihnen arbeitet, beschreiben. In den Konfigurations-Dateien sind Daten- Ursprünge 611, Zähler 612, Indizes 613, Blöcke 614 und Gruppen 615 definiert. Jeder dieser Datensatz-Inhalte wird nachfolgend detailliert besprochen. In den Start-Konfigurations- Dateien sind auch Prototypen von Befehlsfolgen (Schablonen) 616 enthalten, die an den STATISTIC-Server 406 zu senden sind. Die Prototypen 616 werden während der Laufzeit benutzt, um die Arbeitsgänge zu beschreiben, die der STATISTIC-Server 406 ausführen muß, um die aktiven Anzeigen zu unterstützen. Die Arbeitsgänge könnten beispielsweise Richtlinien zur Berechnung eines Mittelwertes und einer Standardabweichung eines bestimmten Datensatzes umfassen. Die Prototypen 616 könnten auch eine "Datensenken"- Information für den STATISTIC-Server enthalten, d. h. wohin er die von ihm erzeugte Information senden soll. Weiterhin empfängt der Steuerungs-Server von den Konfigurations- Dateien Befehle, welche die Prozeß-Grenzwerte definieren sowie Nachrichten, daß der STATISTIC-Server den Alarm-Steuerungs-Server informieren soll, wenn Grenzen überschritten werden.
Der Steuerungs-Server 600 steuert auch den Start der STATISTIC-Server-Module, wenn der Steuerungs-Server arbeitsbereit ist. Es wird ein START-Befehl 601 an den STATISTIC-Server ausgegeben, und der Steuerungs-Server wartet bis dieser arbeitsbereit ist, bevor die Echtzeit-Arbeitsweise beginnt.

Datenpunkte

Wie oben erwähnt, empfängt der Steuerungs-Server Prozeßdaten von drei Form-Servern 514a, 514b und 514c, vom Sicht-Server 525 sowie vom Daten-Server 510. Die Punkte werden nicht als Punkthaufen empfangen, sondern es wird zu einem bestimmten Zeitpunkt immer nur ein Punkt in Gestalt der oben beschriebenen VALUE-Nachrichten empfangen. Nur Datenpunkte, die sich geändert haben, werden an den Steuerungs-Server weitergegeben, um sicherzustellen, daß die Reserven des Systems erweitert werden müssen, indem statische Punktwerte wiederholt werden. Der Steuerungs-Server 600 nimmt jeden neuen Datenpunktwert und sichert ihn in einem lokalen Speicherplatz oder in einer Warteschlange für den letzten Wert für diesen Punkt. In dem Kontaktlinsen-Fertigungssystem gibt es etwa vierhundert Datenpunkte zur Eingabe in die Steuereinheit. Die Datenpunkte sind für den Steuerungs-Server als Ursprünge definiert, und beim Systemstart werden SOURCE-Befehle 611 empfangen, deren Syntax folgende ist:
SOURCE < Ursprung> [Typ = < Datentyp> ] [ID = < id> ]
[Zyklus = < ms> ] [Einheiten = < Kennung> ] [+/- Datensatz]
Das folgende Beispiel beschreibt die Kennung und andere Kennzeichen für den Datenerfassungs-Sensor, Kontakt- bzw. Maschinenfehler:

Beispiel: Ursprung SEQ_CNT

Das wahlfreie "Typen"-Argument des SOURCE-Befehls ist eine Folge von zwei Zeichen, welche den Typ des zu erwartenden Datenwertes definiert:
AI synchrone Analog-Eingaben, realer Zahlenwert;
DI synchrone Digital-Eingabe, 1 oder 0;
CI asynchrone Kontakt-Eingabe, SET oder CLEAR mit wahlfreiem Wert
EV asynchrones Ereignis, wahlfreier Wert.
Das wahlfreie Argument "ID" ist eine Vier-Zeichen-Kette, die zur Verweisung auf andere Kennungssysteme verwendet wird. Das wahlfreie "Zyklus"-Argument ist die Zykluszeit in Millisekunden, wobei die Zykluszeit die Arbeitszeit und die Rückkehrzeit umfaßt. Das wahlfreie Argument "Einheiten" ist eine Zehn-Zeichen-Kette zur Speicherung der technischen Einheiten. Mit den ID-Punkten werden die Einheiten versehen, wenn die Daten- Attribute zum STATISTIC-Server weitergeleitet werden, wenn der Punktwert gleich 1 ist.
Wenn die "-Datensatz"-Markierung vorgegeben ist, werden keine Aktualisierungen zum STATISTIC-Server gesandt. Die "+Datensatz"-Markierung wiederholt die Übermittlung, wenn bei irgendeinem neuen Ursprung ein Fehler aufgetreten ist.

Blöcke

Blöcke sind Ansammlungen von Datenpunkten (Daten-Ursprüngen). Steuerungs-Server- Blöcke werden mit den Blockdefinitionen in Übereinstimmung gebracht, damit sie von den PLC und der Datenerfassung verstanden werden. Durch Definition eines Blockes teilt der Benutzer dem Steuerungs-Server mit, daß ein Satz von Punkten in der PLC als Einheit aktualisiert worden ist und dieser Satz als Einheit von der PLC zum Überwachungs-Server 10 übertragen wird. Jeder dem Steuerungs-Server bekannte Block hat einen definierten Datenpunkt, der als Block-Auslöser dient und für den Steuerungs-Server als COUNTER definiert ist. Der Auslöser ist ein Ursprung, der dem Steuerungs-Server nach allen anderen Punkten des Blockes mitgeteilt wird. Wenn ein neuer Wert als Auslöser empfangen wird, führt der Steuerungs-Server zwei Aktionen durch:
1) Alle Datenpunkte die zum STATISTIC-Server gesandt werden können (diejenigen Punkte, die mit -Datensatz markiert worden sind), sind Bestandteil des (zum gleichen Zeitpunkt) an den STATISTIC-Server gesandten Blockes. Da der Auslöser der letzte Punkt in dem Block ist, der von der Datenerfassung zum Steuerungs-Server zu senden ist, sind alle Datenpunkte gegenwärtig, wenn der Inhalt des Blockes zum STATISTIC-Server befördert wird. Anzumerken ist, daß der Steuerungs-Server alle Punkte des Blockes zum STATISTIC-Server schickt, unabhängig davon, ob sie sich gegenüber ihren früheren Ablesungen verändert haben oder nicht.
2) Die Vorgeschichte eines jeden Datenpunktes (Ursprung) wird erforderlichenfalls in der einem bestimmten Prozeß zugeordneten Speicher-Warteschlange aktualisiert. Aufeinanderfolgende Werte für jeden Datenpunkt können in Speicher-Warteschlangen gespeichert werden, so daß eine Vorgeschichte der "N" letzten Proben für einen bestimmten Punkt verfügbar ist. Der Nutzen einer solchen Maßnahme wird deutlich werden, wenn nachfolgend die Proben besprochen werden.
Zusammengefaßt sind Block-Auslöser Mechanismen, welche 1) veranlassen, Prozeßwerte vom Steuerungs-Server 600 zum STATISTIC-Server 402 zu senden und 2) die Datenpunkt-Vorgeschichte aktualisieren.
Blöcke werden für den Steuerungs-Server mittels des BLOCK-Befehles definiert, desser. Syntax wie folgt lautet:
BLOCK < Block> Zähler = < Ursprung> [< Ursprung> ]
die folgenden Beispiele erläutern im Detail einen Satz von Ursprüngen, deren Werte sich synchrön mit dem Maschinenzyklus-Zähler ändern.

Beispiele:

Block LFBC c = BC_L_CNT 02TIMEBC ID_02_BC
Block LFBC 02TIMEFC ID_02_FC
Jeder Ursprungsdatenwert, welcher dem STATISTIC-Server-Datensatz zugeführt wird, muß Bestandteil eines Blockes sein. Das "Zähler"-Argument ist ein Ursprungsdatenwert, der gemeldet werden sollte, nachdem alle Ursprungsdatenwerte des Blockes für den momentanen Zyklus aktualisiert worden sind. Wenn ein Ursprungsdatenwert nicht aktualisiert wurde, wird angenommen, daß er seinem vorhergehenden Wert entspricht. Zähler werden als Auslöser für Proben und Gruppen verwendet, um eine Aufzeichnung für den Speicher der relationalen Datenbank zu erzeugen, was später im Detail erläutert werden wird. Eine Block-Defintion kann verändert werden, indem sie weitere Ursprungsdatenwerte durch Wiederholung des Blockes ahne einen Zähler aufnimmt.

Proben

Für die Überwachungs-Steuereinheit besteht die Notwendigkeit, Prozeßinformationen zu sammeln und zu sichern, welche zu bestimmten Paletten mit Linsen gehören, wenn diese den Prozeß durchlaufen. Der Steuerungs-Server 600 ermöglicht die zu sammelnden und zu sichernden Daten zeitlich zu ordnen.
Eine Probe ist eine Sammlung von Ursprungsdatenwerten (Datenpunkten), die entweder mit einer Paletten-Identifikation oder mit einem Zähler verknüpft sind. Die typische Anwendung in der Überwachungs-Steuereinheit besteht darin, daß die Sammlung mit einer Paletten- Identifikation verknüpft ist. Da nicht an jedem Punkt des Prozesses, wo Messungen erfolgen, Strichcode-Leser installiert sind, sorgt der Steuerungs-Server 600 dafür, daß die Daten zur Palette vom Strichcode-Leser zeitlich ausgerichtet werden.
Die Zeit-Ausrichtung der Ursprungsdatenwerte zur Paletten-Identifikation kann gegenwärtig auf zweierlei Weise erfolgen. Beide Verfahren können in dem System gleichzeitig für unterschiedliche Proben-Definitionen angewandt werden.
1) Wenn der Strichcode-Leser in bezug auf die Sensoren für die Ursprungsdatenwerte stromabwärts angeordnet ist, muß die Datenpunkt-Information in bezug auf eine bestimmte Palette für eine gewisse Zeit gesichert werden, bis die Palette den Strichcode-Leser passiert. Die Probe wird durch den Empfang eines Block-Auslösers ausgelöst. Wenn der Steuerungs- Server den Strichcode (die Paletten-Identifikation) empfängt, können die zeitweilig gespeicherten Prozeßdaten abgerufen und der Paletten-Identifikation zugeordnet werden. Wie beispielsweise in Fig. 20 dargestellt, ist der Strichcode-Leser 82 stromabwärts von den Paletten angeordnet, die gerade einem Entgasungsvorgang in der Stickstoff-Kammer 46 unterzogen werden. Wenn daher die Paletten 71a und 71b den Tunnel 46 verlassen und vom Strichcode-Scanner 82 identifiziert werden, wird die durch einen Block-Auslöser erzeugte Probe der speziellen Palette zugeordnet (Index).
2) Falls der Strichcode-Leser in bezug auf die Sensoren für die Ursprungsdatenwerte stromaufwärts gelegen ist, werden die Strichcode-Ablesungen gesichert und später den Datenpunkten zugeordnet. In diesem Falle kann der Empfang eines Block-Auslösers dazu verwendet werden, die für eine Probe bestimmten Ursprungsdatenwerte zusammenzuführen.
Ein bedeutsames Beispiel besteht darin, wie die Ergebnisse der Linsenprüfung der Strichcode-Paletten-Identifikation zugeordnet werden. Wie in Fig. 12b dargestellt, werden die Paletten-Identifikationen der Paletten 71a und 71c, welche die jeweiligen Strichcode-Leser 88 und 89 passieren in den Ursprungsdatenspeicher-Warteschlangen 660 bzw. 660' gespeichert, wie es in den Fig. 13a und 13b dargestellt ist, und die anschließend von den Sichtprüfungs-Maschinen erzeugten Daten werden mit dem speziellen Paletten-Identifikations-Index verknüpft, der aus diesen Ursprungsdatenspeicher-Warteschlangen wieder entnommen wird. Dies geschieht deshalb, weil zwischen dem Zeitpunkt, zu dem der Paletten- Identifikations-Strichcode abgetastet wird und dem Zeitpunkt, zu dem die Linsen der Palette an der ALI-Station geprüft werden, eine bestimmte Anzahl von Maschinenzyklen liegt. Daher wird, was später detailliert erläutert werden wird, der Proben-Befehl derart definiert, daß, wenn er von einem Zähler an der Sichtprüfungs-Maschine ausgelöst wird, die Sichtprüfungs-Ergebnisse einer bestimmen Palette eine Probe mit derjenigen korrekten Paletten- Identifikation bilden, die sich mit einer vorgegebene Speicher-Verschiebung in der Ursprungsdatenspeicher-Warteschlange für die Strichcode-Leser 88 oder 89 befinden.
Wenn eine Probe (unter Anwendung des SAMPLE-Befehls) definiert wird, dann werden die Ursprungsdatenwerte, welche in die Probe eingehen, mit einer Zeitversetzung für jedes Ursprungsdatenfeld definiert. Die Zeitversetzung teilt dem Steuerungs-Server mit, um wie viele Zyklen er in der Ursprungs-Vorgeschichte zurückgehen muß, um denjenigen Wert zu erhalten, der zu dieser Probe gehört. Eine Zeitversetzung von Null teilt dem Steuerungs- Server beispielsweise mit, den momentanen Urprungsdatenwert zu verwenden, und eine Zeitversetzung von eins bedeutet, daß der Ursprungsdatenwert eines Zyklus zuvor zu erfassen ist.
Jede Probe hat einen ihr zugewiesenen Index, der sie von anderen, nach der gleichen Proben-Definition entnommen Proben unterscheidet. Der Strichcodewert wird typischerweise für den Index verwendet. Die Syntax für den SAMPLE-Befehl ist folgende:
SAMPLE < Probe> Auslöser = < Zähler>
[Index = < Ursprung> Zeitverschiebung = < Verzögerung> ]
[Ursprung = < Ursprung> Zeitverschiebung = < Verzögerung> ]
Die folgenden Beispiele beschreiben einen geordneten Satz von Ursprungsdatenwerten, die in einer Datenbankaufzeichnung zu erfassen und zu formatieren sind.

Beispiele:

Probe NUTIME tri = F_A_CNT i = DEPB_ID o = 0
s = NUTIMEAB o = 0
Probe NUTIME s = NUTIMEAB o = 0
Dadurch wird ein geordneter Satz von Ursprungsdatenwerten beschrieben. Das "Auslöser"- Argument ist ein Block, dessen Zähler die Erfassung für eine eventuelle Speicherung in der Datenbank auslöst. Das wahlfreie "Index"-Argument ist der Ursprung, welcher den Strichcode für die Aufzeichnung enthält, wo die Probe plaziert ist. Das wahlfreie "Zeitverschiebungs"-Argument wird benutzt, um Zugriff zu einem Strichcode zu erlangen, der in einem vorhergehenden Zyklus gelesen wurde. Wenn der Index-Ursprung nicht festgelegt ist, dann wird der momentane Wert des Auslöser-Block-Zählers verwendet. Der Zugriff zu jedem Ursprungsdatenwert erfolgt mit seiner eigenen Zeitverschiebung. Zeitverschiebungen werden nicht zur Bezugnahme auf Werte in künftigen Zyklen verwendet. Eine Proben- Definition kann in der Weise modifiziert werden, daß sie zusätzliche Ursprünge enthält, indem die Probe ohne einen Auslöser und einen Index wiederholt wird.

Gruppen

Wenn ein Satz von Proben aus Proben mit gleichem Index (gleicher Paletten-Identifikation) zusammengestellt wird, dann wird eine Gruppe gebildet, welche eine Aufzeichnung der Prozeßbedingungen während des Bearbeitungsdurchlaufes darstellt, die auf eine Palette bei ihrer Bewegung durch die Produktionslinie einwirkten. Fig. 8 zeigt, wie die Ursprungsdatenwerte, die Proben und die Gruppen mit gleichem Index einander zugeordnet werden. Die Proben mit den Markierungen 618a, 618b und 618c entsprechen den Blöcken 2, 3 bzw. 4 der Ursprungsdatenwert-Punkte. Daher ist in Fig. 8 die Probe 618b aus drei Ursprungsdatenwert-Punkten zusammengesetzt, welche bei jedem Prozeßzyklus gesammelt werden, was später im Detail erläutert werden wird.
Wenn eine Palette ihren Durchlauf durch den Prozeß beendet hat, werden alle Proben für eine Gruppe gesammelt, und die Gruppe ist somit vollständig. Bezüglich der Darstellung in Fig. 8 ist die Gruppe für einen Index vollständig, wenn alle Proben der Gruppen-Reihe erfaßt wurden. Eine Gruppe für einen speziellen Index (Strichcode) muß an jedem Trennpunkt, an welchem eine spezielle Palette abgetrennt werden kann (im System zurückgewiesen wird), beendet und in die Datenbank eingegeben werden, und die wird nicht wieder von einem Strichcode-Scanner gesehen. Daher gibt es verschiedene Gruppen mit abweichenden Proben-Definitionen (abweichenden Namen), die verschiedenen Abschnitten der Linie entsprechen, aber die gleichen Index-Zahl (Paletten-Identifikation) haben.
Wenn eine Gruppe vollständig ist, wird die Information der Gruppe zur relationalen Datenbank für eine Langzeitspeicherung gesandt. Die Gruppen werden dem Steuerungs-Server durch den GROUP-Befehl zugewiesen, der die folgende Syntax hat:
GROUP < Gruppe> < maxrec> Auslöser = < Block>
[Index = < Ursprung> Zeitversetzung = < Verzögerung> [REFINDEX = < Index> ]
(Test = < Ursprung> Zeitversetzung = > Verzögerung> [Löschen = < Gruppe> ]
[Kennung = < Kennung> ] [< Probe> ]
Die folgenden Beispiele beschreiben einen geordneten Satz von Proben für eine Datenbank- Aufzeichung näher:

Beispiele:

Gruppe AB 256 tri = SERVO_CNT i = BCR3_IDB o = 0
1 = Palette NUTIME NUBUFB FAENCB MONOB
Gruppe AB CHM1B CHM2B CHM3B CIIM4B DEPSB.
Das "Auslöser"-Argument ist ein Block, dessen Zähler das Absenden der Aufzeichnung zur relationalen Datenbank auslöst und kann das gleiche Argument sein, das die Probe bildet. Das wahlfreie "Index"-Argument ist der Ursprung, welcher den Strichcode für die zu sendende Aufzeichnung enthält. Das wahlfreie "Zeitversetzungs"-Argument wird für den Zugriff auf einen Strichcode verwendet, der in einem vorhergehenden Zyklus gelesen wurde. Wenn keine Zeitversetzung gegeben ist, wird der Momentanwert des Auslöser-Block- Zählers verwendet. Eine Gruppendefinition kann durch Einschluß zusätzlicher Gruppen, durch Wiederholung der Gruppe ohne einen Auslöser, Index bzw. einen Test-Ursprung abgewandelt werden. Das wahlfreie "Test"-Argument wird dazu benutzt, zu steuern, ob die mit dem Index versehene Aufzeichnung übertragen wird. Die Aufzeichnung wird gesendet, wenn der Test-Ursprung bei einer gegebenen Zeitversetzung beim Auslösen der Gruppe einen von Null verschiedenen Wert hat. Wie weiter unten im Detail erläutert werden wird, wird die zur relationalen Datenbank zu sendende formatierte Nachricht durch eine Markierung gestartet, die durch das wahlfreie "Kennungs"-Argument festgelegt wird.
Wie im logischen Flußdiagramm der Fig. 9 dargestellt, welche die Schritte zur Erzeugung einer Datenbank-Aufzeichnung, die zur relationalen Datenbank zu senden ist, beschreibt, liest der Steuerungs-Server 600 zuerst, wie oben beschrieben, bei Schritt 700 die Start- Konfigurations-Dateien. Dann wartet der Steuerungs-Server bei Schritt 705 auf eine Nachricht, die in seiner Daten-Mailbox-Position (nicht dargestellt) erscheint. Die Mailbox ist Teil eines Nachrichten-Dienstes (MBX), der vom Arcnet-Netz aus berichtet und Prozesse (Aufträge) beim System-Informationsaustausch sogar dann zuläßt, wenn die Prozesse auf verschiedenen Computern ablaufen. Daher wird jeder Prozeß auf eine in seine Mailbox eingeschriebene Nachricht warten, so daß diese Nachricht für die spezielle Aufgabe in der gleichen Reihenfolge aufgesucht und weitergegeben wird, in welche sie in die Mailbox geschrieben wurde (Warteschlange vom FIFO-Typ, d. h. "Zuerst geschrieben, zuerst gelesen"). In diesem Falle wird die VALUE-Nachricht von der Datenerfassung bzw. von der Eingabe zur Daten-Mailbox gesandt, wo sie durch den Steuerungs-Server wieder aufgefunden werden kann. Bei Schritt 707 stellt der Steuerungs-Server fest, ob die Nachricht eine Wert- Nachricht ist. Ist dies der Fall, so wird der Momentanwert des Ursprungsdatenwertes bei Schritt 710 aktualisiert.
Fig. 10a zeigt eine Serie von Speicher-Ursprungs-Warteschlangen 620, 630, 640 und 650 zur Speicherung der Vorgeschichte von Datenpunkten. Wenn, wie bei Schritt 707 festgestellt, eine Wert-Nachricht empfangen wird, dann werden die darin enthaltenen Daten in einem Momentan-Speicherplatz, welcher der jeweiligen Ursprungsdatenwert-Warteschlange zugeordnet ist, aktualisiert gespeichert. Beispielsweise werden in den mit den Bezugszahlen 621, 631, 641 und 651 bezeichneten Speicherplätzen die Momentanwerte von Datenpunkten bezüglich Temperatur-Prozeßparametern, Druck, Durchlauf bzw. Fördergeschwindigkeits-Prozeßparametern gespeichert, wenn sie als erste empfangen werden.
Wenn die empfangene Nachricht, nach der Feststellung bei Schritt 707, keine Wert- Nachricht ist, dann ist es, wie oben besprochen, eine Zähler-Nachricht. Der Steuerungs- Server bewirkt dann, daß die momentanen Datenwerte für jeden in dem Block definierten Ursprung, die vom Zähler ausgelöst wurden in der Speicher-Warteschlange für diesen Ursprung, wie bei Schritt 714 angegeben, an die Spitze der Speicher-Warteschlange gesetzt werden. Indem dies geschieht, werden alle Werte verschoben, wie es in Fig. 10a durch Pfeile angedeutet ist, so daß die zeitliche Ausrichtung der Datenwerte aufrechterhalten bleiben kann. Beispielsweise wird nach Empfang des Zähler-Auslösers der Momentanwert für die Temperatur 1 im Speicherplatz 621 der Ursprungs-Warteschlange 620 in den Speicherplatz 622 eingegeben, welches der Warteschlangen-Speicherplatz zur Speicherung des Temperaturwertes 1 des vorhergehenden Maschinenzyklus (einen Maschinenzyklus zurück) ist. Der Temperaturwert 1, der sich im Speicherplatz 622 befand, wird nun zum Temperaturwert 1 zwei Maschinenzyklen zurück, was im Speicherplatz 623 in Fig. 10a angedeutet ist. Dies wiederholt sich für jeden Speicherplatz der Speicher-Warteschlange. Der Temperatur-Datenwert 1, der um K Zyklen zurück liegt, wie er im Warteschlangen-Speicherplatz 624 dargestellt ist, wird gelöscht. Wie es aus Fig. 10A erkennbar ist, ist die Länge einer jeden Speicher-Warteschlange 620, 630 usw. zur Speicherung der Vorgeschichte spezieller Prozeßparameter prozeßabhängig. Demzufolge werden bis zu "K" Temperatur-Prozeßwerte 1 in der Warteschlange 620 gehalten, welche den Werten aller Maschinenzyklen bis zu K Zyklen zurück entsprechen, und es werden bis zu "L" Druck-Prozeßwerte 3 in der Warteschlange 630 gespeichert, welche den Werten aller Maschinenzyklen bis zu L Zyklen zurück entsprechen. Es muß unterstrichen werden, daß jeder Strichcode-Scanner in Fig. 20 mit einer Ursprungs-Speicher-Warteschlange, wie sie oben beschrieben wurde, verknüpft ist. Die in der Speicher-Warteschlange für einen speziellen Strichcode enthaltenen Daten stellen die Identifikations-Strichcodes für jede Palette dar, die unter dem Strichcode-Scanner durchläuft.
Bei Schritt 717 in Fig. 9 wird festgestellt, ob der von einem bestimmten Block empfangene Zähler-Auslöser auch als Auslöser für eine Probe definiert ist. Wenn, wie oben beschrieben, der Auslöser zur Bildung einer Probe empfangen wird, wie es in Fig. 9 bei Schritt 720 angegeben ist, dann werden alle durch den Proben-Befehl bezeichneten Ursprungsdatenwerte aus ihren jeweiligen Ursprungs-Warteschlangen gesammelt, und es wird eine Probe aus den Datenwerten in einer Gruppe gesammelt und gespeichert, die dann zusammen mit dem zugehörigen Strichcode weitergeschaltet wird, wie nachfolgend mit weiteren Einzelheiten erläutert werden wird. Wie oben im Zusammenhang mit dem Proben-Anordnungs-Befehl beschrieben, können die Daten aus den Ursprungs-Warteschlangen mit einer beliebigen vorgegebenen Zeitversetzung ("Tiefe") gesammelt werden. Wie in Fig. 10b dargestellt, kann demzufolge ein Proben-Sammel-Befehl die Ursprungs-Warteschlangen 620, 630, 640 oder 650 sowie Zeitversetzungen 626, 636, 646 oder 656 benennen, um eine Probe 670 zu bilden, die zeitlich ausgerichtete, einem Index zugeordnete Prozeßdaten enthält.
Wie in Fig. 9 dargestellt, wird bei Schritt 723 auch festgestellt, ob ein von einem speziellen Block empfangener Zähler-Auslöser auch als Auslöser für eine Gruppe wirkt. Wie es oben besprochen wurde, werden beim Empfang des betreffenden Auslösers die empfangenen Proben mit der gemeinsamen Paletten-Identifikation zur Bildung einer Gruppe zusammengeführt. Der Gruppen-Befehl definiert die in der Gruppe enthaltenen Proben und er definiert auch den Auslöser, welcher dazu führt, daß die Gruppe zur Datenbank gesandt wird.
Fig. 10c zeigt das Schema der Proben, welche eine Gruppe bilden. Die Spalte 637 enthält die eindeutigen Strichcode-Zahlen (Indizes) für jede im System befindliche Palette. Es versteht sich, daß die Spalte der Strichcode-Identifikations-Zahlen nicht zwingend zahlenmäßig geordnet sein muß, sondern auch zufällig angeordnet sein kann. Jede Zeile 647 in Fig. 10c stellt die Gruppe dar, welche die Proben für die spezielle, durch die erste Spalte identifizierten speziellen Paletten-Identifikationen umfaßt. Wie in Fig. 10c dargestellt, enthält die Gruppe 645 die zuvor beschriebene Probe 670.
Bei Schritt 724 in Fig. 9 wird die Anordnung der Datenbank-Aufzeichnung, bestehend aus den Gruppendaten und dem Strichcode-Index, an die relationale Datenbank gesandt. Zu dem Zeitpunkt, an welchem die Aufzeichnung zur Datenbank gesandt wird, wird sie vom Steuerungs-Server mit einer Zeitmarke versehen, welche als zusätzlicher Index für bestimmte Gruppen von Daten dienen kann. Wenn bei Schritt 724 der Gruppen-Auslöser nicht empfangen wurde, dann wird der Vorgang wiederholt, und der Steuerungs-Server wartet bei Schritt 705 auf die nächste Nachricht.
Die Zeitmarken-Information (Index) kann benutzt werden, um Bearbeitungsprozesse der Erzeugnisse zu identifizieren, die während bestimmter Perioden ablaufen, in denen äußere Bedingungen (wie beispielsweise Klimaanlage, Luftfeuchte, "Reinraum"-Bedingungen) die Erzeugnisqualität der automatischen Kontaktlinsen-Produktion beeinflußt haben könnten.
Fig. 11 zeigt das Format von Gruppen von Aufzeichnungen, die markiert mit 1, 2, ..., n zur relationalen Datenbank 202 (Fig. 1) gesandt und dort gespeichert werden. Wie in Fig. 11 dargestellt, enthält die Spalte 657a die Datums- und Zeitmarken-Information der jeweiligen übermittelten Aufzeichnung, wie sie vom Steuerungs-Server erzeugt wird. Die Spalte 657b enthält den Strichcode-Index (Paletten-Identifikation). Die Spalte 657c enthält die Kennungs-Information, welche bei der bevorzugten Ausführungsform eine Kombination des Gruppennamens und einer codierten Datums-Zeit-Information ist, welche der Steuerungs- Server für eine bestimmte Aufzeichnung an die Datenbank schickt. Der Rest der Spalten von 657d bis zum Ursprungsdatenwert "J" enthält die Vorgeschichte einer bestimmten Bearbeitungsstufe an einem bestimmten Erzeugnis in der Kontaktlinsen-Produktionsanlage. Es versteht sich, daß eine andere Aufzeichnung mit der in Fig. 11 dargestellten Struktur der Aufzeichnungen 1, 2, ..., n die gleiche Paletten-Identifikationszahl haben und auch den gleichen Abschnitt des Kontaktlinsen-Fabrikationssystems betreffen kann, aber ein anderes Datum und eine andere Uhrzeit aufweist oder daß die Bearbeitung auf der gleichen Palette in einem anderen Teil des Systems erfolgte, beispielsweise nach der Zurückweisung einer Palette am Ausgang der Formhälften-Zusammenfügungs-Station oder nach der ALI- Sichtprüfung. Es versteht sich, daß für den Fall, in welchem für den gleichen Paletten-Index mehr als eine Aufzeichnung erfolgt, welches in jeder Aufzeichung mehr oder weniger Ursprungsdatenwerte sein können in Abhängigkeit davon, an welcher Stelle der Produktionslinie die Bearbeitung erfolgte.

Sichtprüfungs-Ergebnisse

Wie in Fig. 20 dargestellt und mit weiteren Details in der oben erwähnten Patentanmeldung mit dem Aktenzeichen VTN-77 besprochen, folgt jetzt die Spritzformung und die Ablage der Hinterkrümmungs- und Vorderkrümmungs-Formhälften auf den entsprechenden Hinterkrümmungs- und Vorderkrümmungs-Trägerpaletten, wobei nach dem Eintritt in einen Stickstoff-Puffer-Tunnel 46 ein Doppel-Querstoß-Mechanismus 44 Paare aus je einer Palette mit Vorderkrümmungs-Formhälften und solcher mit Hinterkrümmungs-Formhälften zur Beförderung in eine Form-Füll- und Zusammenfügungsstation 59 bildet. In der Form-Füll- und -Zusammenfügungsstation werden die Vorderkrümmungs-Formhälften dosiert mit einem Monomer gefüllt, und die Hinterkrümmungs-Trägerpalette wird auf der Oberseite der Vorderkrümmungs-Formhälften, welche das Monomer enthalten, plaziert. Die Hinterkrümmungs-Trägerpaletten werden anschließend zur Wiederverwendung zur Spritzformungsstation zurückgebracht. Wenn ein Alarmzustand auftritt und festgestellt wird, daß die von einer bestimmten Palette getragenen Linsen fehlerhaft sind und zurückgewiesen werden müssen, dann erhält, wie in der oben erwähnten Patentanmeldung mit dem Aktenzeichen VTN-140 beschrieben, eine Stößel-Vorrichtung 58, die allgemein in Fig. 20 dargestellt ist, den Befehl, die spezielle Palette mit den fehlerhaften Linsen zurückzuweisen und auch die leeren Hinterkrümmungs-Trägerpaletten, welche die Füll- und Form-Zusammenfügungsstation 59 verlassen, vom Förderer 26 zum Förderer 29 zurückzuführen
Fig. 12a zeigt die Ausrichtung und Bewegungsrichtung der Vorderkrümmungs- und der Hinterkrümmungs-Paletten 71a bzw. 71b kurz vor dem Eintritt in die Füll- und Form- Zusammenfügungsstation. Wie in der Fig. 12a zu erkennen ist, sind die Vertiefungen einer jeden Palette in einer bestimmten Richtung numeriert: 1, 2, ..., 8.
Nach dem Verlassen der Formtrenn-Vorrichtung und vor dem Eintritt in die Hydrationskammer 335 werden die Paletten mit fertigen Kontaktlinsen, wie in Fig. 20 dargestellt, paarweise angeordnet, so daß zwei Paletten Seite an Seite bewegt werden. An der Hydrationsstation ist eine Stößel-Vorrichtung 332 derart getaktet, daß vier Paletten 74 auf einem Träger 337 abgelegt werden, so daß zweiunddreißig Kontaktlinsen für die Hydrationsbehandlung gruppiert werden. Die Fig. 12b und 20 zeigen die Ausrichtung der vier Paletten 71a, 71b, 71c und 71d, wenn sie auf dem Träger 337 zur Förderung zur Hydrationsstation angeordnet sind. Wie in Fig. 20 dargestellt, identifizieren die Strichcode-Scanner 88 und 89 jede Palette, bevor sie zur Hydration überführt wird. Im einzelnen liest der Strichcode-Scanner 88 die Strichcodes der in Fig. 12b mit 71a und 71b gekennzeichneten Paletten, und der Strichcode-Scanner 89 liest die Strichcodes der mit 71c und 71d gekennzeichneten Paletten. Dies ist die letzte Strichcode-Ablesung im Kontaktlinsen-Produktionsprozeß. Da die Linsen selbst von den Paletten entnommen werden, und da es von diesem Punkt an keine weiteren Strichcode-Scanner gibt, werden die Linsen-Position und - Identifikation während und nach der Hydration aus der Zählung der Maschinenzyklen abgeleitet. Wie oben kurz angemerkt, wird für jeden Strichcode-Scanner eine Ursprungsspeicher-Warteschlange erzeugt, und die in jeder Strichcode-Scanner-Ursprungsspeicher- Warteschlange enthaltenen Daten umfassen die Paletten-Identifikations-Zahlen, der unter ihm durchlaufenden Paletten. Die Fig. 13a und 13b zeigen die Strichcode-Speicher- Warteschlangen 660 bzw. 660', welche den Strichcode-Scannern 88 und 89 (Fig. 20) entsprechen und Paletten-Identifikations-Datenwerte (Indizes) enthalten. Wenn eine Palette beispielsweise unter dem Strichcode-Scanner 88 durchläuft, werden die Paletten- Identifikations-Daten im Speicherplatz 661 untergebracht, d. h. in dem Platz, wo die laufenden Daten gespeichert werden. Wenn die nachfolgenden Paletten darunter hindurchlaufen, werden die ursprünglichen Paletten-Identifikations-Daten und alle danach gesammelten Paletten-Identifikations-Daten in der Speicher-Warteschlange auf einmal um einen Speicherplatz verschoben, wie es in Fig. 13a durch unterbrochene Pfeile angegeben ist. Wenn dann eine Probe zur Zusammenführung der Sichtprüfungs-Ursprungsdatenwerte (Ergebnisse) ausgelöst wird, wird dann eine bestimmte Zeitversetzung für den Ursprungsdatenwert des Strichcode-Scanners 88, beispielsweise der im Speicherplatz 662 der Speicher- Warteschlange abgelegte Paletten-Identifikations-Index mit den Ergebnisdaten der Linsenprüfung zusammengefaßt. Diese Probe wird nach Empfang des Zählwertes vom Sicht- Server ausgelöst, und der Betrag der Zeitversetzung ist durch die Programmierung in den Konfigurationsdatei-Proben-Definitionen vorgegeben, welche vom Steuerungs-Server beim Systemstart gelesen werden.
Am Ausgang der Hydrationsstation werden die Linsen um 90º entgegen dem Uhrzeigersinn gedreht, wenn sie aufgenommen und in spritzgeformten Blistern (nicht dargestellt), welche den Boden der Linsenverpackung bilden, plaziert werden. Diese werden dann in Prüf- Trägerpaletten 76 und 76', welche, wie in Fig. 12c dargestellt, jeweils sechzehn spritzgeformte Blisterverpackungen tragen, weiter befördert. Die Fig. 12c zeigt die Ausrichtung der jeweils sechzehn Packungen in den Prüf-Paletten 76 und 76', wie sie durch den Bereich nach der Hydration gefördert werden. Jede Linsenposition in den Prüf-Paletten 76 und 76' ist im Vergleich mit den Positionen der Vertiefungen in den ursprünglichen Paletten 71a, 71b, 71c und 71d dargestellt.
Vor dem Eintritt in die ALI-Sichtprüfungsstation werden die Packungen in einer vorgegebenen Weise erfaßt. Die Fig. 12d zeigt die Ausrichtung der Linsen-Prüf-Paletten 76, um Gruppen von sechzehn Linsen durch die Sichtprüfungs-Maschine zu führen. Eine oder mehrere Sichtprüfungs-Kameras (nicht dargestellt) sind mit einem Prüfkanal 77a bzw. 77b verbunden, der in Fig. 12 dargestellt ist. Die Sichtprüfungs-Kameras prüfen die mit 1 bis 16 numerierten Kontaktlinsen-Positionen, wie es verkleinert in Fig. 12d dargestellt ist, wobei die ersten Datenwerte 51 erhalten und von der Sichtprüfungs-Maschine weiter gesandt werden, wie es oben im Zusammenhang mit der Fig. 4b besprochen wurde. Im einzelnen prüfen die Sichtprüfungs-Kameras für den Prüfkanal 77a die Linsen-Positionen 1 bis 8 und die Sichtprüfungs-Kameras für den Prüfkanal 77b die Linsen-Positionen 9 bis 16. Im Hinblick auf die vorherbestimmbare Anordnung, in welcher die Paletten in der Sichtprüfungsstation ausgerichtet sind und im Hinblick auf die vorherbestimmbare Anzahl von Maschinenzyklen, die zur Durchführung der Sichtprüfung erforderlich sind, werden die Sichtprüfungs- Ergebnisse mit der Original-Strichcode-Paletten-Identifikation (Paletten 71a, 71b, 71c und 71d) automatisch weitergeschaltet, wenn der Steuerungs-Server den Zählwert der Sichtprüfung nach dem Empfang des Prüfergebnis-Blockes 50 empfängt. Um dies durchzuführen, werden die Ursprungsdatenwert-Speicher-Warteschlangen 660 und 660', die Strichcode- Paletten-Identifikations-Ablesungen der Strichcode-Scanner 88 bzw. 89 enthalten (Fig. 13a und 13b). Weil jede gerade geprüfte Linsen-Position auf der Prüf-Palette um eine vorgegebene Anzahl von Maschinenzyklen vom Zeitpunkt der Strichcode-Paletten- Identifikation an den Scannern entfernt ist, ergibt sich, daß jede Vertiefung mit demjenigen Paletten-Identifikations-Index verknüpft wird, der um eine vorgegebene Anzahl von Speicherplätzen in der jeweiligen Strichcode-Paletten-Identifikations-Ursprungsdatenwert- Warteschlange 660 bzw. 660' versetzt ist. Wie in Fig. 12d dargestellt, werden beispielsweise die Linsen-Prüfergebnisse für die Linsen-Positionen 5 bis 8 und 13 bis 16 mit der gespeicherten, mit 622 gekennzeichneten, versetzten Position des Strichcode-Scanners 88 in der Ursprungsdatenwert-Speicher-Warteschlange 660 in Fig. 13a verknüpft. In entsprechender Weise werden die Linsen-Prüfergebnisse für die Linsen-Positionen 1 bis 4 und 9 bis 12 mit der gespeicherten, mit 622' gekennzeichneten, versetzten Position des Strichcode- Scanners 89 in der Ursprungsdatenwert-Speicher-Warteschlange 660' in Fig. 13b verknüpft. Wenn die Sichtprüfungs-Ergebnisse zusammen mit einer Strichcode-Paletten- Identifikation weitergeschaltet werden, werden sie nach dem Empfang des Sicht-Zählwertes (vom Sicht-Server) gruppiert, um eine Datenbankaufzeichnung zu bilden, wie sie oben im Zusammenhang mit der Fig. 11 dargestellt und diskutiert wurde.

Punktdiagramme

Wenn alle Bearbeitungsdaten der Vorgeschichte einer bestimmten Paletten-Identifikation als Aufzeichnungen in der Datenbank zusammengeführt werden, sind sie für eine weitere Verarbeitung und Analyse verfügbar. Wie oben erwähnt, ist es beispielsweise erwünscht, Punktdiagramme, d. h. graphische Darstellungen, bei denen eine Variable auf der x-Achse und eine Variable auf der y-Achse in Beziehung zueinander gesetzt werden, zu erstellen. So werden beispielsweise Qualitätsmessungen als Funktion von Prozeßvariablen aufgezeichnet, um festzustellen, ob und in welchem Ausmaß die spezielle Prozeßvariable die Qualität beeinflußt. Die aufgezeichnete Punktdiagramm-Information gestattet ferner die Auswahl geeigneter Einstellpunkte für eine Variable, weil leicht festgestellt werden kann, wie sich die Qualitätsmeßwerte ändern, wenn sich der Wert des Prozeßparameters ändert.
Fig. 14 zeigt ein Punktdiagramm 880 von Prüfergebnissen (y-Achse) als Funktion von Prozeßparametern (x-Achse). Im einzelnen wurde eine graphische Darstellung erzeugt, welche die Anzahl der Linsenfehler für eine bestimmte Vertiefung in einer Palette zeigt, wie sie aus den ALI-Prüfergebnissen als Funktion des Monomer-Einfüll-Niveaus in der Vorderkrümmungs-Formhälfte bestimmt wurde. Als Alternative kann die graphische Darstellung des Monomer-Einfiill-Niveaus auch in bezug auf eine bestimmte Vertiefung in allen gespeicherten Paletten erstellt werden. Wie in Fig. 14 dargestellt, zeigen die Ergebnisse dieser Prüfungen, daß der Linsen-Herstellungsprozeß über das Monomer-Einfüll-Niveau in die Vorderkrümmungs-Formhälfte steuerbar sein muß, so daß, wie festgestellt wurde, innerhalb akzeptabler, durch den Pfeil A gekennzeichneter Grenzen durchweg fehlerfreie Linsen hergestellt werden konnten. Da die meisten Abweichungen als Normalverteilung auftreten, ist der Einstellpunkt in erster Linie in der Mitte des akzeptablen Bereiches anzusetzen, was in Fig. 14 durch den Pfeil B angezeigt wird. Aus Gründen der Übersichtlichkeit wurde in Fig. 14 nur eine Vertiefung mit der Bezugszahl 879 gekennzeichnet. Andere Typen von Kennzeichnungen zur Hervorhebung anderer Vertiefungen können in der gleichen graphischen Darstellung angebracht werden. Wenn es keine Unterschiede zwischen den Vertiefungen einer bestimmten Palette gibt, werden sich die Kennzeichnungen einander überlagern. Wenn sich eine oder mehrere Vertiefung(en) nicht gleich verhalten, werden sich die Kennzeichnungen nicht überlagern, sondern sichtbar bleiben und anzeigen, daß zwischen den Vertiefungen Unterschiede existieren, die behoben werden sollten, damit in allen Vertiefungen Gut-Linsen hergestellt werden können.
Die Fig. 16a bis 16c zeigen den Prozeß-Ablauf zur Erzeugung einer graphischen Punktdiagramm-Darstellung aus den in der relationalen Datenbank verfügbaren Datenaufzeichnungen. Der erste, als Schritt 750 bezeichnete Schritt besteht darin, eine Nachricht an die Datenbank zu senden, Parameterdaten für einen Paletten-Index (Strichcode) herauszusuchen und bei Schritt 752 eine Nachricht an den Graphik-Server zur Einstellung der Anzeige auf ein Punktdiagramm zusenden. Es versteht sich, daß die Anordnung der Verfahrensschritte, um die Datenbank ordnungsgemäß abzufragen und zur Darstellung der gewünschten Aussagen zusammenzuführen, jedem Programmier-Fachmann für die Datenbank-Programmierung bekannt sind. Der nächste Schritt 754 besteht darin, jeder einzelnen Vertiefung ein Zeichensymbol (Kennzeichnung) sowie andere graphische Attribute zuzuweisen, damit eine Punktdiagramm-Anzeige entsteht. Es kann eine Ausdehnung (Bereich) von Werten für jede Achse eingestellt werden, beispielsweise für die maximale Anzahl von Linsenfehlerdaten, um sicherzustellen, daß alle Datenpunkte innerhalb der Skala dargestellt werden. Bei Schritt 756 wartet das Programm auf von der Datenbank ankommende Daten, und bei Schritt 758 wird festgestellt, ob noch weitere Daten ankommen. Wenn bei Schritt 758 weitere Daten empfangen werden, wird bei Schritt 765 festgestellt, ob gefordert wird, die Linsenprüfdaten für die Palettenvertiefung in Position 1 graphisch darzustellen. Wenn dies der Fall ist, dann werden bei Schritt 767 die Daten "ax" und "bx" mit den Palettenvertiefungen 1 bzw. 2 verknüpft und zum Graphik-Programm zur graphischen Darstellung gesandt und, falls der momentan empfangene Datenwert der erste Datenwert ist, dann erfolgt bei Schritt 781 ein Durchlauf, um den Minimal-Maximal-Bereich zu erstellen (Fig. 16b und 16c). Wenn dies nicht der Fall ist, dann wird bei Schritt 769 festgestellt, ob die Linsenprüfergebnisdaten für die Palettenvertiefung in der Position Nr. 3 zur graphischen Darstellung angefordert werden. Wenn dies der Fall ist, dann werden bei Schritt 771 die Daten "ax" und "bx" mit den Palettenvertiefungen 3 bzw. 4 verknüpft und zum Graphik- Programm zur graphischen Darstellung gesandt. Als nächstes wird bei Schritt 773 festgestellt, ob die Linsenprüfergebnisdaten für die Palettenvertiefung in der Position Nr. 5 zur graphischen Darstellung angefordert werden. Wenn dies der Fall ist, dann werden bei Schritt 775 die Daten "ax" und "bx" mit den Palettenvertiefungen 5 bzw. 6 verknüpft und zum Graphik-Programm zur graphischen Darstellung gesandt. Wenn dies nicht der Fall ist, dann wird bei Schritt 777 festgestellt, ob die Linsenprüfergebnisdaten für die Palettenvertiefung in der Position Nr. 7 zur graphischen Darstellung angefordert werden. Wenn dies der Fall ist, so werden bei Schritt 779 die y-Achsen-Daten ax und bx mit den Palettenvertiefungen 7 bzw. 8 verknüpft und zum Graphik-Programmm zur graphischen Darstellung gesandt. Nachdem die richtige Nachricht zur graphischen Darstellung der Ergebnisse einer in den Schritten 767, 771, 775 und 779 bestimmten Vertiefung an den Graphik-Server zur graphischen Darstellung der Ergebnisse gesandt worden ist, wird bei Schritt 780 festgestellt, ob die momentan empfangenen Daten die Daten des ersten Teiles sind. Ist dies der Fall, so werden bei Schritt 781 die Variablen min, max, imin und imax initialisiert. Die Variable "indep" stellt die unabhängige x-Achsen-Variable für die graphische Darstellung dar, und die Variablen "imin" und "imax" sind die Minimal- und Maximalwerte der Variablen "indep". Bei Schritt 783 wird festgestellt, ob der momentan abgerufene ax-Datenwert eine untere Grenze für den Bereich der graphisch darzustellenden y-Achsen-Daten ist. Wenn ax Meiner ist als der min-Wert, dann wird der min-Wert bei Schritt 785 gleich dem Datenpunkt ax gesetzt. Bei Schritt 787 erfolgt eine entsprechende Feststellung, ob der momentane bx- Datenwert eine untere Grenze für den Bereich der graphisch darzustellenden y-Achsen- Datenwerte ist. Wenn der bx-Wert der empfangenen Daten kleiner ist als der min-Wert, dann wird der min-Wert bei Schritt 789 gleich dem Datenpunkt bx gesetzt. Als nächstes erfolgt bei Schritt 791 eine Feststellung, ob der momentane ax-Wert eine obere Grenze für den Bereich der graphisch darzustellenden y-Achsen-Datenwerte ist. Wenn der ax-Wert der empfangenen Daten größer ist als der momentane max-Wert, dann wird der max-Wert bei Schritt 793 gleich diesem Datenpunkt ax gesetzt. Bei Schritt 795 erfolgt eine entsprechende Feststellung, ob der momentane bx-Datenwert eine obere Grenze für den Bereich der graphisch darzustellenden y-Achsen-Datenwerte ist. Wenn bx größer ist als der max-Wert, dann wird der max-Wert bei Schritt 797 gleich diesem Datenpunkt bx eingestellt. Bei Schritt 776 wird festgestellt, ob der momentane indep-Datenwert eine obere Grenze für den Bereich der x-Achsen-Daten (beispielsweise für das Monomer-Einfüll-Niveau) ist. Wenn indep größer ist als der momentane imax-Wert, dann wird imax auf den Wert indep eingestellt. Eine entsprechende Feststellung, ob der momentane indep-Datenwert eine untere Grenze für den Bereich der x-Achsen-Daten ist, erfolgt bei Schritt 782. Wenn indep kleiner ist als der momentane imin-Wert, dann wird imin auf indep eingestellt. Wenn bei Schritt 758 festgestellt wurde, daß mehr Daten abrufbar sind als angefordert, dann wird der Zyklus wiederholt, und der Graphik-Server wird bei Schritt 756 einen neuen Datensatz erwarten.
Wenn bei Schritt 758 keine Daten mehr abrufbar sind, wird festgestellt, ob eine normale Datei-Ende-Nachricht eingegangen ist, wie es bei Schritt 759 angegeben ist. Wenn eine normale Datei-Ende-Nachricht eingegangen ist, werden bei Schritt 799 der y-Achsen- Bereich, d. h. die max- und min-Werte sowie der x-Achsen-Bereich, d. h. die imax- und imin- Werte eingestellt, und es wird eine entsprechende Nachricht an den Graphik-Server gesandt, so daß das Punktdiagramm exakt graphisch dargestellt bzw. angezeigt werden kann. Der Prozeß endet dann bei Schritt 761. Wenn keine Datei-Ende-Nachricht empfangen wurde, dann wird bei Schritt 762 eine Fehlerverfolgungs-Nachricht erzeugt.

Balkendiagramm

Das Balkendiagramm ist eine graphische Darstellung der Zählwerte der Fehler eines speziellen Typs (einige Gut-Ausschuß-Qualitätsmessungen). Die Zählwerte werden der Paletten- Vertiefung zugeordnet dargestellt, so daß eine Vertiefung, die sich anders darstellt als die anderen, isoliert (und festgehalten) werden kann.
Fig. 15 zeigt ein Balkendiagramm 890 der Anzahl der Linsenfehler für eine bestimmte Vertiefungs-Position in einer bestimmten Palette. Im einzelnen stellt jeder Balken 889 die Anzahl der Fehler für jede Vertiefung einer bestimmten Palette dar, die sich in einem vom Benutzer festgelegten Zeitraum ergeben hat. Aus einer solchen graphischen Darstellung kann leicht festgestellt werden, welche Vertiefungs-Position mehr Fehler als andere auf der gleichen Palette aufweist. Eine Situation, wie sie durch die graphische Darstellung von Fig. 15 gezeigt wird, kann anzeigen, daß sich in der Vertiefung 7, wie durch den Pfeil angedeutet, Verunreinigungen befinden.
Fig. 17 zeigt den Prozeßablauf 800 zur Erstellung einer graphischen Balkendiagramm- Darstellung aus einer Gruppe von Datenaufzeichnungen, die in der relationalen Datenbank verfügbar sind. Bei Schritt 801 wird von der Datenbank gefordert, die Gut-/Ausschuß- Zustände (Prüfergebnisse) für eine bestimmte Qualitätsmessung, eine bestimmte Palette und über einen bestimmten Zeitraum zu sammeln und die Daten an den Graphik-Server zu senden. Nachdem bei Schritt 803 eine Weile gewartet wurde, wird bei Schritt 805 festgestellt, ob die Datenbank die Datei mit angeforderten Daten-Informationen geliefert hat. Wenn die Datei geliefert wurde, wird der Graphik-Server die Datei lesen und, wie bei Schritt 807 angegeben, einen Gesamtdurchlauf der Fehler pro Vertiefung durchführen. Ein Bereich wird automatisch eingestellt, so daß die Daten exakt graphisch dargestellt werden. Nach dem Lesen der von der Datenbank gesandten Datei wird bei Schritt 809 festgestellt, ob es irgendwelche Probleme gibt, wie beispielsweise Empfang von mehr Daten als angefordert oder Empfang eines unerwarteten Gut-/Ausschuß-Codes. Wenn ein Problem festgestellt wird, dann wird bei Schritt 811 über das Problem berichtet und bei Schritt 812 eine Beendigungs- Nachricht an den Graphik-Prozessor gesandt. Wenn es keine Daten-Probleme zu berichten gibt, dann wird die Nachricht zur graphischen Darstellung der Daten an die Graphik- Anzeige gesandt, wie es bei Schritt 810 angegeben ist.
Wenn die Datenbank bei Schritt 805 keine Datei geliefert hat, dann wird das System fünfmal warten, wie es bei Schritt 806 angegeben ist. Wenn nach diesen fünfmal Warten, die Datenbank die Datei noch immer nicht geliefert hat, dann wird bei Schritt 812 eine Nachricht an den Graphik-Server gesandt, daß er zur Annahme anderer Anforderungen zur graphischen Anzeige frei ist.

Prozeß-Streubreiten-Balkendiagramm

Das Prozeß-Streubreiten-Balkendiagramm ist eine graphische Darstellung, welche zeigt, wie die Werte eine Reihe von Prozeß-Messungen verteilt sind. Ein normalverteilter Prozeß wird beispielsweise ein glockenförmiges Balkendiagramm aufweisen. Diese Art des Balkendiagrammes ist von Nutzen, um Abweichungen im Fertigungsprozeß oder Fehler in Meßeinrichtungen hervorzuheben.
Fig. 18 zeigt ein Prozeß-Streubreiten-Balkendiagramm 870, welches angibt, wie sich ein bestimmter Prozeßparameter (beispielsweise das Monomer-Einfüll-Niveau) verhält. Wie in Fig. 18 dargestellt, werden die Daten in sechzehn Zonen gleicher Breite aufgeteilt. Jede Zone wird durch einen Balken 869 dargestellt, dessen Höhe die Anzahl der Proben zeigt, welche in dieser Zone auftreten. Wenn die Streubreite der Summe aller Balken gleich oder kleiner ist als die vorgeschriebene Streubreite, dann kann der Prozeß innerhalb der vorgeschriebenen Toleranz gesteuert werden. Wenn das Balkendiagramm die Gestalt einer Glockenkurve hat, dann kann von einer Normalverteilung der Parameterstreuung gesprochen werden.
Fig. 19 zeigt den Prozeßablauf 814 zur Erzeugung einer graphische Darstellung eines Prozeß-Streubreiten-Säulendiagrammes aus der Gruppe der in der relationalen Datenbank verfügbaren Datenaufzeichnungen. Schritt 815 ist der Schritt, welcher von der Datenbank fordert, Werte für einen bestimmten Prozeßparameter über einen bestimmten Zeitraum zu sammeln und diese Daten an den Graphik-Server zu senden. Nachdem bei Schritt 817 eine Weile gewartet wurde, wird bei Schritt 819 festgestellt, ob die Datenbank die Datei mit den angeforderten Daten-Informationen geliefert hat. Wenn die Datei geliefert worden ist, wird der Graphik-Server die Datei lesen und bei Schritt 821 eine Liste der Maximal- und Minimal-Parameter für die Prozeßparameter anlegen. Aus den Maximal- und Minimalwerten wird automatisch ein Bereich gebildet derart, daß die x-Achsen-Koordinaten in sechzehn gleiche Datengruppen unterteilt werden. Bei Schritt 825 wird jeder Datenwert aus der Datei gelesen, und es wird festgestellt, in welche Datengruppe der Wert fällt. Zugleich wird die Proben-Zählung (nicht dargestellt) für die spezielle Datengruppe um einen Schritt erhöht. Dann erfolgt bei Schritt 827 die Feststellung, ob ein normales Ende der Datei angetroffen wurde. Ein normales Ende der Datei zeigt an, daß es keine Probleme beim Lesen der Daten aus der Datenbank gab. Wenn ein Problem festgestellt wird, dann wird bei Schritt 831 über das Problem berichtet und bei Schritt 833 eine Beendigungs-Nachricht an den Graphik- Prozessor gesandt. Wenn es nichts über Datenprobleme zu berichten gibt, dann wird, wie bei Schritt 829 dargestellt, die Nachricht zur graphischen Darstellung der Daten an die Graphik-Anzeige gesandt.
Wenn die Datenbank bei Schritt 819 die Datei nicht geliefert hat, dann wartet das System fünfmal, wie es bei Schritt 820 dargestellt ist. Wenn die Datenbank die gewünschte Datei nach fünf Durchläufen nicht geliefert hat, dann wird bei Schritt 833 eine Nachricht an den Graphik-Server gesandt, daß er zur Annahme anderer Anforderungen zur graphischen Darstellung frei ist.

Statistik-Server

Der in Fig. 1 dargestellte Statistik-Server 406 ist ein Verwahrungsort für Echtzeit-Datenwerte. Die Daten werden in logischen benutzerdefinierten Gruppen oder Datensätzen gespeichert. Die Stärke des Statistik-Servers besteht in seiner Fähigkeit, an den Daten Transformationen bzw. "PERFORMS" vorzunehmen. Wenn die Datenwerte vom Steuerungs- Server empfangen werden, werden sie automatisch nach Alarmzuständen abgesucht und summiert, wobei der Server statistische Prozeßkontrollen durchführt sowie damit verbundene Alarme einstellt und auch wieder löscht. Es werden Werte aus den Datensätzen weitergegeben, um momentane Trends anzuzeigen sowie bewegte Anzeigen auf dem Bildschirm zu erzeugen.
Wie in Fig. 6 dargestellt, werden STATE-Befehle 604 vom Konsolen-Server 403 und vom Graphik-Server 405 an der Steuerungs-Server 600 gesandt. Diese Befehle beziehen sich auf einen Datensatz und wahlweise auf einen Verfahrensnamen. Die Befehle werden dazu genutzt, den Steuerungs-Server 600 zu veranlassen, Befehle an den Statistik-Server 406 auszugeben. Diese Befehle weisen den Statistik-Server 406 an, entsprechende Berechnungen vorzunehmen, um eine Bildschirmwiedergabe zu unterstützen und die Ergebnisse an den Aktiv-Anzeigemodul an der Operatorstation 400 zu senden.
Wenn ein Verfahrensname angegeben ist, teilt der STATE-Befehl 604 dem Steuerungs-Server mit, dem Statistik-Server 406 einen vordefinierten Satz von Befehlen (ein Verfahren) zu senden, wobei im Anschluß an einen bestimmten Datensatz Ersetzungen erfolgen. Das Verfahren ist als eine Schablone für einen Satz an den Statistik-Server zu sendender Befehle vorstellbar.
Der Steuerungs-Server 600 liefert drei Arten von Ausgaben an den Statistik-Server 406:
1) Die START-Nachricht 601, um den Statistik-Server während des Systemstartes zu initialisieren.
2) Ursprungsdatenwert-Nachrichten 602, um den Statistik-Server 406 über neue Datenwerte zu informieren. Die Daten werden zu einer reservierten Statistik-Server-Mailbox (nicht dargestellt) gesandt. Die allgemeine Form der Nachricht ist: "Datensatzname = Wert".
3) Nachrichten, welche die Art und Weise ändern, wie der Statistik-Server Daten verarbeitet und welche Empfänger für die vom Statistik-Server erzeugten Daten hinzufügen oder entfernen. Die wichtigsten Nachrichtentypen, welche dem Statistik-Prozessor zugeleitet werden, sind: DATASET, welcher einem Datensatz mit bestimmtem Namen die Speicherung im Statistik-Server zuweist; SINK welcher den Empfänger vom Statistik-Server ausgehender Daten bestimmt; PERFORM welcher eine Funktion festlegt, die der Statistik- Server auf einen Datensatz anwenden soll; REMOVE welcher ein Objekt (Datensatz, Empfänger, Funktion usw.) aus dem Statistik-Server entfernt sowie CONTROL, welcher Alarmbereichsgrenzen für einen Datensatz im Statistik-Server einstellt, damit ein Datensatz einer statistischen Prozeßkontrolle unterworfen wird.

Zeitreihen

Jeder gemessene oder berechnete Parameter kann als ein einzelner Trend als Funktion der Zeit graphisch dargestellt werden. Mehrere graphisch dargestellte Zeitreihen können mit einem allgemeinen Trend verglichen werden. Es sind feste Zeitskalen verfügbar, um die Daten über Minuten, Stunden, Tage und Wochen anzuzeigen.
Der Statistik-Server 406 enthält ein Programm-Paket, welches es ermöglicht, Datensätze (eine Anzahl Proben des gleichen Datenursprunges) zusammenzustellen. Wenn ein solcher Datensatz erstellt ist, können auf den gleichen Kriterien beruhende Bearbeitungsvorgänge als automatisch durchzuführend eingestellt werden. Empfänger (für erstellte Ergebnisse) können dynamisch erstellt werden, beispielsweise zur graphische Darstellung an der Operatorstation oder ein anderer Datensatz zur Erstellung einer Vorgeschichte.
Für alle gewünschten Ursprungsdatenwerte können Trends über Zyklen von Minuten (10 Sechs-Sekunden-Zyklen), Stunden (60 Minuten), Tage (24 Stunden) und Wochen (7 Tage) als Serien oder Kaskaden von Datensätzen zwangsläufig erstellt werden, wobei "s" die Größe ist. Um dies zu ermöglichen, müssen die letzten 60 Werte für diesen Datensatz gespeichert werden, so daß sie verfügbar sind, wenn beispielsweise der Befehl erteilt wird, sie zur graphische Darstellung oder zur Durchführung anderer Arbeitsgänge an die Operatorstation zu senden, wie zum Beispiel:
Der Prozeßparameter Monomer-Einfüll-Niveau DEPO2LEV wird in jedem Zyklus einmal gemessen und dem Datensatz DEPO2LEV s = 60 zugeführt, welcher 60 Werte halten kann. Jede zehnte Ablesung löst einen oben beschriebenen PERFORM-Befehl aus, um mit den letzten 10 Werten eine Durchschnittsberechnung durchzuführen und führt das Ergebnis dem Datensatz DEPO2LEV/M s = 60 zu, welcher bis zu 60 Werte halten kann. Umgekehrt löst jedes sechzigste Lesen von DEPO2LEV/M ein PERFORM aus, um dessen Durchschnittswert in den Datensatz DEPO2LEV/H s = 60 zu überführen. In entsprechender Weise löst jedes vierundzwanzigste Lesen von DEPO2LEVIH ein PERFORM aus, um dessen Durchschnittswert in den Datensatz DEPO2LEV/D s = 60 zu überführen, und jedes siebente Lesen von DEPO2LEV/D löst ein PERFORM aus, um dessen Durchschnittswert in den Datensatz DEPO2LEV/W s = 60 zu überführen. Die Kaskade hat dann folgendes Aussehen:
Zykluslesung → Datensatz DEPO2LEV
Ein-Minuten-Durchschnitt → Datensatz DEPO2LEV/M
Sechzig-Minuten-Durchschnitt → Datensatz DEPO2LEV/H
Ein-Stunden-Durchschnitt → Datensatz DEPO2LEV/D
Ein-Tages-Durchschnitt → Datensatz DEPO2LEV/W usw.
wobei M, H, D und W Zoom-Faktoren sind, die später im Detail diskutiert werden. Um einen Datensatz-Empfänger zu definieren, wird DEPO2LEV/M mit dem gleichen Datensatznamen einer dynamischen Behandlung unterworfen, was die Umwandlung für die Software einfacher macht. Die Empfänger werden für die Operatorstationen automatisch erstellt, um die Trend-Daten graphisch darzustellen. Der folgende Satz von Empfängern wird bei der System-Initialisierung erstellt und vermag die Minuten-, Stunden-, Tages- und Wochendaten auf Anforderung graphisch darzustellen:
Empfänger DEPO2LEV/M d = DEPO2LEV/M
Empfänger DEPO2LEV/H d = DEPO2LEV/H
Empfänger DEPO2LEV/D d = DEPO2LEV/D
Empfänger DEPO2LEV/W d = DEPO2LEVIW
Um schließlich die Vorgeschichten zu erzeugen, werden die einzelnen Ursprungsdatenwert- Ablesungen vom Steuerungs-Server an den Statistik-Server gesandt, wobei folgende Serien definiert sind:
Ausführung DEPO2LEV f = Mittelwert s = DEMP2LEV/M t = 10
Ausführung DEPO2LEV/M f = Mittelwert s = DEPO2LEV/H t = 60
Ausführung DEPO2LEV/H f = Mittelwert s = DEPO2LEV/D t = 24
Ausführung DEPO2LEV/D f = Mittelwert s = DEPO2LEV/W t = 7
wobei die erste Ausführung der Befehl ist, den Mittelwert von zehn Proben zu bilden, welche im Datensatz DEPO2LEV ankommen (Die Ursprungsdatenwerte für den Datenpunkt DEPO2LEV werden in jedem Zyklus erfaßt), und das Ergebnis an den Empfänger von DEPO2LEV/M zu senden, welcher seinerseits (oben) als Datensatz DEPO2LEV/M definiert ist und nun die Vorgeschichte für die Minuten-Durchschnitte des Datenursprunges DEPO2LEV speichert. In entsprechender Weise besteht die zweite Ausführung in dem Befehl, den Mittelwert von 60 Proben zu bilden, welche im Datensatz DEPO2LEV/M ankommen (Die Durchschnittswerte für jede Minute werden aus dem Datensatz DEPO2LEV/M entnommen), und das Ergebnis an den Empfänger von DEPO2LEV/H zu senden, welcher seinerseits als Datensatz DEPO2LEV/H definiert ist und nun die Vorgeschichte für die Stunden-Durchschnitte des Datenursprunges DEPO2LEV speichert. Die dritte Ausführung wiederum besteht in dem Befehl, den Mittelwert von 24 Proben zu bilden, welche im Datensatz DEPO2LEV/H ankommen (Die Durchschnittswerte für jede Stunde werden aus dem Datensatz DEPO2LEVIH entnommen), und das Ergebnis an den Empfänger von DEPO2LEV/D zu senden, welcher seinerseits als Datensatz DEPO2LEV/D definiert ist und nun die Vorgeschichte für die Tages-Durchschnitte des Datenursprunges DEPO2LEV speichert. Schließlich besteht die letzte Ausführung in dem Befehl, den Mittelwert von 7 Proben zu bilden, welche im Datensatz DEPO2LEV/D ankommen (Die Durchschnittswerte für jede Tag werden aus dem Datensatz DEPO2LEV/D entnommen), und das Ergebnis an den Empfänger von DEPO2LEV/W zu senden, welcher seinerseits als Datensatz DEPO2LEV/W definiert ist und nun die Vorgeschichte für die Wochen-Durchschnitte des Datenursprunges DEPO2LEV speichert. Wenn die Datensätze, Empfänger und Ausführungen definiert sind, wird die Ausführung der Berechnungen fortgesetzt, wann immer das definierte Kriterium für diese Ausführung erfüllt ist (beispielsweise, wenn im Datensatz DEPO2LEV 10 Proben angekommen sind).
Die Fig. 21a zeigt den Ablauf 560 zur Erzeugung einer graphischen Darstellung von Prozeßparametern als Funktion einer festen Zeitskala, um den Prozeßparameter-Trend in dem System darzustellen. An einer Operator- oder Benutzer-Schnittstelle kann ein Operator fordern, daß er bestimmte Prozeßparameter mit ihren Änderungen in Echtzeit (einmal in einem Prozeßzyklus von sechs Sekunden) oder solche Prozeßparameter in ihrer Entwicklung über einen Zeitraum (Tage, Wochen) sehen möchte. Die Eingabe für eine Anforderung zur Wiedergabe eines Trends ist eine Tastaturbetätigung, die auch einen "Zoom-Faktor" umfassen kann, wobei es sich um eine Anhang mit dem Wert M, H, D oder W und einen Binärwert größer als Null handelt. Der erste mit 561 bezeichnete Schritt ist die Bewertung des Zoom- Faktors. Wenn der Wert des Zoom-Faktors gleich Null ist, d. h. wenn kein Zoom-Faktor vorgeschrieben ist, dann wird der Datensatz der Ursprungs- oder System-Zeitskala (einmal pro Zyklus) zugewiesen, wie es in Fig. 21a als Schritt 564 beschrieben ist. Wenn beispielsweise 60 Werte in dem oben beschriebenen Datensatz DEPO2LEV sind, soll dieser Datensatz zur graphische Darstellung zum Graphik-Server gesandt werden. Als nächstes werden bei Schritt 584, gesteuert vom Steuerungs-Server, geeignete Verbindungen zum Statistik-Programmpaket eingestellt und eine Nachricht abgesandt, daß die Daten dorthin geliefert wurden. Bei Schritt 586 werden die Variablen min und max initialisiert, welche zum Einstellen des Bereiches der graphischen Darstellung benutzt werden. Bei Schritt 588 wird jeder Wert des Datensatzes gelesen und bei Schritt 590 festgestellt, ob es weitere Wertes dieses speziellen Datensatzes gibt.
Wenn es keine weiteren Werte gibt, dann wird der Momentanwert des Datensatzes bei Schritt 591 mit dem momentanen Miminalwert (min) des Datensatzes verglichen. Wenn der Momentanwert kleiner ist als der Minimalwert, dann wird der Minimalwert bei Schritt 592 dem Momentanwert des Datensatzes zugeordnet. Wenn der Momentanwert nicht kleiner ist als der Minimalwert des Datensatzes, dann wird der Momentanwert bei Schritt 593 mit dem Maximalwert (max) des Datensatzes verglichen. Wenn der Momentanwert größer ist als der Maximalwert, dann wird bei Schritt 594 der Maximalwert dem Momentanwert des Datensatzes zugewiesen, und das Programm kehrt zu Schritt 588 zurück, wo der nächste Wert aus dem Datensatz gelesen wird und die Schritte 590 bis 594 wiederholt werden. Wenn bei Schritt 590 keine Werte mehr aus dem momentanen Datensatz gelesen werden, dann werden bei Schritt 595 die benutzerdefinierten Grenzen vom Steuerungs-Server angefordert. Als nächstes werden vor der graphischen Darstellung der Datensatz-Trendwerte bei Schritt 599 zunächst bei Schritt 597 die Text-Kennungen, der Minimal-Maximal-Bereich, die Grenzlinien und die Markierungen eingestellt, so daß die Daten in verständlicher Weise graphisch dargestellt werden.
Wenn der Wert des Zoom-Faktors nicht gleich Null ist, d. h. es gibt einen vorgeschriebenen Zoom-Faktor, dann wird bei Schritt 565 festgestellt, ob der Befehl ein Auf-Zoom-Befehl ist, d. h. ob der fixierte x-Achsen-Trend auf größere Teilintervalle vergrößert werden soll (beispielsweise von Stunden auf Tage) oder ein Ab-Zoom-Befehl ist, wo gefordert wird, daß die fixierte Trend-Skala beispielsweise von Tagen auf Stunden verkleinert werden soll. Wenn die Anforderung ein Auf-Zoom-Befehl ist, dann wird bei Schritt 566 festgestellt, ob der momentane Zoom-Faktor auf Tage; bei Schritt 567, ob er auf Stunden; bei Schritt 568 ob er auf Minuten lautet oder bei Schritt 569, ob er auf Ursprungsdatenwerte (Echtzeit) eingestellt ist. Wenn der momentane Zustand des Zoom-Faktors auf Tage lautet, dann wird er bei Schritt 571 auf Wochen (W) erhöht; wenn er auf Stunden lautet, wird er bei Schritt 573 auf Tage (D) erhöht; wenn er auf Minuten lautet, wird er bei Schritt 574 auf Stunden (H) erhöht oder wenn er gleich Null ist (Systemzyklus), dann wird er bei Schritt 576 auf Minuten (M) erhöht.
Wenn die Anforderung ein Ab-Zoom-Befehl ist, was bei Schritt 565 in Fig. 21a festgestellt wird, dann wird bei Schritt 577 festgestellt, ob der momentane Zoom-Faktor auf Minuten; bei Schritt 578, ob er auf Stunden; bei Schritt 579 ob er auf Tage lautet oder bei Schritt 580, ob er auf Wochen lautet. Wenn der momentane Zustand des Zoom-Faktors auf Minuten lautet, dann wird er bei Schritt 581 auf Ursprungsdatenwerte (System-Zykluszeit) vermindert; wenn er auf Stunden lautet, wird er bei Schritt 572 auf Minuten (M) vermindert; wenn er auf Tage lautet, wird er bei Schritt 582 auf Stunden (H) vermindert oder wenn er auf Wochen lautet, dann wird er bei Schritt 583 auf Tage (D) vermindert. Wenn der Zoom-Faktor durch den in Fig. 21a dargestellten logischen Ablauf für den angeforderten Prozeßparameter-Trend bestimmt worden ist, dann wird der an den Statistik-Server zu sendende Datensatz den Ursprung (Prozeßdaten) und den Zoom-Faktor enthalten. Dies ist in Fig. 21a bei Schritt 575 dargestellt. Bei dem oben beschriebenen Monomer-Einfüll- Beispiel werden die Datensätze beispielsweise lauten: d = DEPO2LEV, d = DEPO2LEV/M, d = DEPO2LEV/H, d = DEPO2LEV/D oder d = DEPO2LEV/W.
Wegen der großen Anzahl in den relationalen Datenbanken 202 online oder off-line auffindbarer Daten können zahlreiche andere Vergleiche oder Beziehungen graphisch angezeigt und zum Zwecke der Produktionsoptimierung aufgezeichnet werden. Es kann beispielsweise entsprechend den FDA-Vorschriften auf Produktionsaufzeichnungen zurückgegriffen werden, welche die Prüfergebnisse für jede hergestellte Linse als Funktion ihrer Prozeßparameter enthalten, und diese können auch aufbewahrt werden. Als ein anderes Beispiel erlaubt das System auch den Zugriff auf Daten von Aufzeichnungen des Sterilisationszyklus, welche die Angabe über Erfolg oder Fehler der Sterilisation, die Chargennummer sowie die Sterilisations-Durchlaufzahl aus der Sterilisations-Steuereinheit (nicht dargestellt) umfaßt. Diese Dateien können im off-line-Datenbank-Speicherberich gespeichert und wieder abgerufen werden, um die Leistungsfähigkeit des Sterilisationsgerätes über einen langen Zeitraum zu analysieren. Zusätzlich kann auf diese Daten zurückgegriffen werden, um Ausrüstungs- und Verfahrens-Überprüfungs-Informationen zu liefern, wie sie durch Vorschriften von Bundesbehörden gefordert werden. Es können auch andere auf Daten beruhende Funktionen einschließlich der statistischen Prozeßsteuerung durchgeführt werden, wobei mittels einer X-R-Aufzeichnung mit dynamischen Kontrollgrenzen und Alarmgabe laufende Ablesungen und Alarmzeichen auf der Anzeige erzeugt werden können. Weiterhin können zur Überwachung der Produktionslinien-Maschinenleistung erzeugt werden: eine Alarmliste mit Beschreibungen aktiver Warnungen, Alarme sowie Empfehlungen, wie produziert werden soll; graphische Anzeigen in Form einer Pareto-Tabelle der Anzahl und Dauer von der Maschine ausgelöster Alarme oder eine Pareto-Tabelle von Linsenverlusten durch Maschinenteile. Beispiele für Alarmzustände umfassen: fehlende Auslösung eines Schrittmotors, an der Hydrationsstation wird in der oberen Kammer kein Vakuum erzeugt, fehlender Luftdruck in der Hydrationsstation usw. Weitere graphische Anzeigen, die erzeugt werden können, umfassen: Ereignisse von Änderungen der Arbeitsweise in zeitmarkierten Protokollen und graphische Darstellung kumulativer Prüfergebnisse (Ausstoß).
Diese Merkmale werden mindestens zwei komplementären Nutzer-Schnittstellen 400 zugeordnet, die an jeder Station verfügbar sind. Ein Ingenieur-Konsolen-Server (nicht dargestellt) wird zur Prozeßanalyse und -optimierung verwendet. Durch eine Produktions- Konsolen-Schnittstelle (nicht dargestellt) werden die Produktionslinien-Funktions- und Maschinendiagnose unterstützt. Eine Haupt-Operatorstation ermöglicht Änderungen in der Spurverfolgung sowie eine Alarm-Bestätigung, welche durch eine Operator-Sperre (Paßwort erforderlich) gesichert ist.

Pareto-Tabellen

Es können graphische Anzeigen in Form von Pareto-Tabellen von Anzahl und Dauer durch die Maschine ausgelöster Alarme oder auch Pareto-Tabellen von Paletten-Zuständen erzeugt werden. Fig. 22a zeigt eine Pareto-Tabelle gezählter Alarmzustände. Die Alarmzustände sind vom Alarm-Steuerungs-Server 528 erhaltene Datenwerte, wobei dieser die Zahl der Alarmzustände speichert, die sich erfahrungsgemäß in der Kontaktlinsen-Produktionslinie ereignen können. Wie in Fig. 22a dargestellt, ist jeder Balken farbcodiert und gibt die Häufigkeit eines Alarmzustandes an. Beispielsweise zeigt der Balken 902a einen Zustand, in welchem an der Hydrationsstation die oberen Kammern fehlen und der Balken 902b zeigt einen nicht ausgelösten Motor an. Diese beiden Alarmzustände zeigen die beiden für diesen speziellen Produktionsdurchlauf häufigsten Alarmzustände an.
Fig. 22b zeigt eine Pareto-Tabelle eines Zeit-(Dauer-)Alarmzustandes. Die Zeit-Alarm- Zustände sind vom Alarm-Steuerungs-Server empfangene Datenwerte, welche die Dauer speichern, in welcher ein Alarmzustand in der Kontaktlinsen-Produktion existiert oder existiert hat. Wie in Fig. 22b dargestellt, ist jeder Balken farbcodiert und gibt die Dauer eines Alarmzustandes an. Beispielsweise zeigt der Balken 903 einen Zustand, in welchem an der Hydrationsstation über eine Periode von 1 Stunde und 26 Minuten keine obere Kammer vorhanden war.
Fig. 22c zeigt eine Pareto-Tabelle von Paletten-Zuständen (Zustands-Codierungen). Die Tabelle zeigt die Ursachen für Paletten-Fehler, wenn diese einen bestimmten Strichcode- Scanner passieren, beispielsweise den Strichcode-Scanner 86 am Ausgang der Entformungs-Baugruppe. Beispielsweise zeigt der Balken 905a der Tabelle an, daß 249 Paletten wegen eines übermäßigen Monomer-Ringes (HEMA-Ring) zurückgewiesen wurden, was nach dem Entformen auftritt oder daß die Hinterkrümmungs-Formhälfte nach der Entformung noch vorhanden war (Zustands-Code -18). In entsprechender Weise zeigt der Balken 905b an, daß 50 Paletten wegen eines Fehlers im UV-Polymerisations-Tunnel zurückgewisen wurden, d. h. eine UV-Lampe oder ein Heizkörper hatten Funktionsfehler (Zustands- Code -4). Es ist anzumerken, daß die in der Y-Achse gezeigten Häufigkeiten in jeder der oben beschriebenen Pareto-Tabellen nach fallender Häufigkeit geordnet wurden. Es muß erwähnt werden, daß eine Pareto-Tabelle der Paletten-Zustände von allen Strichcode-Scannern in der Produktionslinie erzeugt werden kann.
Fig. 23 zeigt den Prozeßablauf 901 zur Erstellung einer Pareto-Tabelle aus Echtzeit- Daten, die vom Alarm-Steuerungs-Server oder vom Statistik-Zähl-Server verfügbar sind. Der erste, mit 904 bezeichnete Schritt dient der Bestimmung des Typs der Pareto-Tabelle, deren Erstellung und Anzeige angefordert wird. Wenn die Anforderung darin besteht, eine Pareto-Tabelle der Alarmzustände (Fig. 22a und 22b) zu erstellen, dann wird bei Schritt 907 festgestellt, ob eine Pareto-Tabelle nach der Zeit (Dauer) angefordert wird. Wenn dies der Fall ist, dann wird bei Schritt 909 vom Alarm-Steuerungs-Server gefordert, Daten für die acht häufigsten Alarme in der Reihenfolge ihrer Dauer zur Verfügung zu stellen. Wenn bei Schritt 907 eine Pareto-Tabelle der Alarm-Anzahl angefordert wird, dann wird bei Schritt 911 vom Alarm-Steuerungs-Server gefordert, Daten für die acht häufigsten Alarme nach der Häufigkeit ihres Auftretens zur Verfügung zu stellen. Wenn der bei Schritt 904 angeforderte Typ der Pareto-Tabelle nicht Alarme betrifft, dann handelt es sich um die Paletten-Zustands-Codes an einem bestimmten Strichcode-Scanner oder an allen Strichcode- Scannern, d. h. um die häufigsten Gründe, daß Paletten zurückgewiesen werden (Fig. 22c). Wenn eine solche Anforderung erfolgt, dann wird bei Schritt 906 von Fig. 23 vom Statistik-Zähl-Server verlangt, die acht häufigsten Paletten-Zustände für einen bestimmten geforderten Strichcode-Scanner oder für alle Strichcode-Scanner zur Verfügung zu stellen. Die graphische Darstellung von Fig. 22c zeigt die für den Strichcode-Scanner 86 (Fig. 20) am häufigsten angeforderten Codes.
Nachdem alle Daten zusammengeführt sind, was, wie bei Schritt 913 angedeutet, einige Zeit erfordern kann, werden die Pareto-Tabellen-Einstell-Befehle an den Graphik-Server gesandt, um die Pareto-Anzeige, wie bei Schritt 916 angegeben, zu konfigurieren. Dann werden die Pareto-Daten bei Schritt 919 an den Graphik-Server gesandt, wo die Tabelle erstellt und an die Operatorstation zur Anzeige gesandt wird. Die graphische Darstellung bleibt online, bis der Operator eine Funktion auslöst, beispielsweise, um die momentane Pareto- Anzeige in Echtzeit zu aktualisieren oder die Darstellung eines anderen Typs der Pareto- Tabellen anzufordern. Daher wartet das System bei Schritt 922 auf einen Tastendruck- Befehl des Operators, und bei Schritt 924 erfolgt eine Feststellung, ob der Operator die Anzeige eines anderen Typs von Tabelle angefordert hat. Wenn gefordert wird, einen anderen Typ von Pareto-Tabellen zu erstellen, dann kehrt das System zu Schritt 904 in Fig. 23 zurück, um festzustellen, welcher Typ von Pareto-Tabelle angefordert wird. Wenn ein anderer Typ von graphischer Darstellung oder Anzeige angefordert wird, dann wird die momentane Pareto-Tabelle bei Schritt 927 geschlossen, und die graphische Anzeige wird gelöscht.

Claims

1. Mehrfach-Niveau-Qualitätssteuerungssystem (10) für eine automatisierte Produktionslinie zur Herstellung von Kontaktlinsen in Paletten-Chargen, wobei jeder Palette (71) für die Linsen auf dieser Palette (71) Kontaktlinsendaten zugeordnet sind und die Produktionslinie eine Vielzahl von Prozeßstationen aufweist, wobei das System umfaßt:

(a) eine Vielzahl von Prozeßsteuereinheiten (11, 12, 13, 14, 15, 16, 17) zur Steuerung einer oder mehrerer Prozeßstationen auf einem ersten Steuerungsniveau, wobei jede der Steuereinheiten (11 bis 17) eine Vielzahl von Prozeßsteuervorrichtungen regelt, diese Vorrichtungen zur Steuerung von Produktionsparametern bei der automatisierten Herstellung von Kontaktlinsen an der (den) Prozeßstation(en) verwendet werden und jede der Steuereinheiten (11 bis 17) ein Zurückweisungssignal erzeugt, wenn eine Palette (71) mit Linsen mit einem Produktionsparameter angetroffen wird, der einen vorgegebenen Bereich überschreitet,

(b) eine Vielzahl von Einrichtungen (58), die auf das Zurückweisungssignal reagieren, indem sie nach der Erzeugung dieses Signales die Palette (71) und beliebige Kontaktlinsen darauf aus der Produktionslinie entfernen,

(c) eine automatische Linsenprüfeinrichtung (20) zur optischen und automatischen Bewertung einer jeden hergestellten Kontaktlinse und zur Erzeugung von Ausnahmedaten (52) für jede fehlerhafte Kontaktlinse, die mit Produktionsparametern hergestellt wurde, welche nicht die vorgegebenen Bereiche überschreiten,

(d) eine Abfrage-Einrichtung (505) zum Abfragen jeder der Prozeßsteuereinheiten sowie der Linsenprüfeinrichtung auf einer Frequenzbasis, um Prozeßsteuerungsdaten für jede Periode zu erfassen,

(e) eine Einrichtung zur Korrelation der Prozeßsteuerungsdaten mit den Kontaktlinsendaten für die Palette (71) mit den Kontaktlinsen, die sich während dieser Periode in der Prozeßstation befindet sowie weiterhin zur Korrelation von Ausnahmedaten mit den Prozeßsteuerungsdaten und mit den Kontaktlinsendaten, um die bei der Herstellung der Kontaktlinsen angewandten Prozeßparameter zu optimieren;

(f) eine relationale Datenbank (202) zur Speicherung der von der Abfrage-Einrichtung (SOS) empfangenen Prozeßsteuerungsdaten, der Kontaktlinsendaten sowie der Ausnahmedaten.

2. Qualitätssteuerungssystem (10) zur Optimierung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 1, bei welchem die Korrelationseinrichtung vorgegebene und berechnete Eingabeparameter zwecks Optimierung mit in Echtzeit gemessenen Parametern der Prozeßsteuerungsdaten vergleicht.

3. Qualitätssteuerungssystem (10) zur Optimierung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 2, bei welchem die berechneten und gemessenen Daten nach einer gewissen Zeit mit den Prüfdaten verglichen werden.

4. Qualitätssteuerungssystem (10) zur Optimierung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 1, bei welchem jede Prozeßsteuereinheit (11 bis 17) eine. Liste vorgegebener Prozeßparameter auf dem neuesten Stand hält und einen Alarmzustand (52) meldet, wenn einer der vorgegebenen Prozeßparameteraußerhalb eines vorgegebenen Bereiches liegt.

5. Qualitätssteuerungssystem (10) zur Optimierung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 4, bei welchem die Korrelationseinrichtung eine Pareto-Tabelle der Alarmzustände der Prozeßsteuereinheit erstellt.

6. Qualitätssteuerungssystem (10) zur Optimierung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 1, bei welchem die Korrelationseinrichtung unkontrollierte Trendwerte aus den Prozeßsteuerungsdaten ausschaltet.

7. Qualitätssteuerungssystem (10) zur Optimierung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 1, bei welchem die Korrelationseinrichtung aus mehrfachen, aus den Prozeßsteuerungsdaten abgeleiteten Zeitreihen historische Trends korreliert.

8. Qualitätssteuerungssystem (10) zur Optimierung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 1, bei welchem die Prozeßsteuerungsdaten durch die Korrelationseinrichtung in Gruppen zur relationalen Datenbank (202) übertragen werden und wobei die Daten zum Zeitpunkt des Absendens zur relationalen Datenbank (202) zeitlich markiert werden.

9. Mehrfach-Niveau-Qualitätssteuerungssystem (10) für eine automatisierte Produktionslinie zur Herstellung von Kontaktlinsen in Paletten-Chargen nach Anspruch 1, bei welchem die Abfrage-Einrichtung die Prozeßsteuerungsdaten mit den Kontaktlinsendaten für die Palette (71) mit den Kontaktlinsen, die sich während dieser Periode in der Prozeßstation befindet, korreliert,

wobei das System weiterhin eine Zweit-Niveau-Datenverarbeitungseinrichtung aufweist, um die Ausnahmedaten mit den Prozeßsteuerungsdaten und den Kontaktlinsendaten zu korrelieren und dadurch Komponenten der Produktionlinie auszuschalten, welche für die Herstellung einer fehlerhaften oder mehrerer fehlerhafter Kontaktlinse(n) in jedem Funktionszyklus verantwortlich sind.

10. Mehrfach-Niveau-Qualitätssteuerungssystem nach Anspruch 1 oder 9, bei welchem die Kontaktlinsen in Formen hergestellt werden, die in Vertiefungen (1 bis 8) gehalten werden, welche in den Paletten (71) ausgebildet sind, und die Zweit-Niveau-Datenverarbeitungseinrichtung bestimmte Paletten (71) aussschaltet, welche mit einer oder mehreren Vertiefung(en) (1 bis 8) zur Herstellung fehlerhafter Kontaktlinsen beigetragen haben.

11. Mehrfach-Niveau-Qualitätssteuerungssystem nach Anspruch 1 oder 9, bei welchem die Linsenprüfeinrichtung (50) für jede geprüfte Linse Daten erzeugt und die Korrelation eine kumulierte Aufzeichnung von Linsenprufungen sowie von einem oder mehreren Prozeßsteuerungsparameter(n) umfaßt.

12. Mehrfach-Niveau-Qualitätssteuerungssystem (10) für eine automatisierte Produktionslinie zur Herstellung von geformten Kontaktlinsen in Paletten-Chargen nach Anspruch 1 oder 9, welches weiterhin mindestens eine Einspritzstation für Formhälften zur Formung von Kontaktlinsen umfaßt.

13. Mehrfach-Niveau-Qualitätssteuerungssystem (10) nach Anspruch 12, bei welchem die Prozeßsteuerungsdaten von der Einspritzstation mit den Daten der Anordnung der Palette (71) korreliert werden, um die Korrelation der Ausnahmedaten mit bestimmten Formhohlräumen an der bzw. den Einspritzstation(en) festzustellen.

14. Mehrfach-Niveau-Qualitätssteuerungssystem (10) nach Anspruch 12, bei welchem eine der Prozeßsteuerstationen die Menge des Monomers steuert, welches in die Form zur Herstellung einer Kontaktlinse dosiert wird, und die Prozeßsteuerungsdaten von dieser Einspritzstation von der Prozeßsteuereinrichtung an der Dosierungsstation zum Dosieren des Monomers in die Form und damit zur Formung der Linse verwendet werden.

15. Mehrfach-Niveau-Qualitätssteuerungssystem (10) nach Anspruch 12, bei welchem die Kontaktlinsen in Formen geformt werden, welche in Vertiefungen (1 bis 8) gehalten werden, die in einer vorgegebenen Anordnung in den Paletten (71) ausgebildet sind, wobei die Formen an der Einspritzstation eine Anordnung von Hohlräumen bilden und die Zweit- Niveau-Datenverarbeitungseinrichtung bestimmte Einspritz-Formhohlräume ausschaltet, welche zur Herstellung fehlerhafter Kontaktlinsen beitragen.

16. Qualitätssteuerungssystem (10) zur Optimierung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 12, bei welchem die Prozeßsteuerungsparameter für jede Palette (71) von Linsen in der relationalen Datenbank (202) archiviert werden.

17. Qualitätssteuerungssystem (10) zur Optimierung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 1, 9 oder 12, bei welchem die automatische Linsenprüfeinrichtung (50) für jede Linse ein Prüfergebnis erzeugt und das Prüfergebnis in der relationalen Datenbank (202) mit den Kontaktlinsendaten und den Prozeßsteuerungsdaten korreliert wird.

18. Verfahren zur optimalen Steuerung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen, wobei diese Produktionslinie eine Vielzahl untereinander in Beziehung stehender Produktionsstationen sowie eine optische Prüfstation (20) aufweist, mit folgenden Verfahrensschritten:

(a) automatische Steuerung einer oder mehrerer Produktionsstation(en) durch eine oder mehrere Erst-Niveau-Steuereinheit(en) (11 bis 17), welche eine Vielzahl Prozeßsteuereinrichtungen regeln und dadurch eine Vielzahl von bei der automatisierten Herstellung von Kontaktlinsen angewandten Produktionsparametern steuern;

(b) Zuordnung von Kontaktlinsendaten zu hergestellten Kontaktlinsen;

(c) automatisches Aussondern aller hergestellten Kontaktlinsen, wenn ein Produktionsparameter an einer Produktionsstation jenseits einer bestimmten Grenze liegt;

(d) automatische Bewertung einer jeden hergestellten Kontaktlinse und Erzeugung visueller Prüfdaten für jede hergestellte Kontaktlinse;

(e) Abfragen (505) einer jeden Erst-Niveau-Steuereinheit (11 bis 17) auf einer Frequenzbasis, um für jede Periode Prozeßsteuerungsdaten zu erhalten und diese Prozeßsteuerungsdaten dann mit den zugehörigen Kontaktlinsendaten zu korrelieren und dadurch die während dieser Periode in der betreffenden Produktionsstation befindlichen Kontaktlinsen darzustellen,

(f) Speicherung der von der Abfrage-Einrichtung erhaltenen Prozeßsteuerungsdaten, der Kontaktlinsendaten und der Daten aus der visuellen Prüfung in einer relationalen Datenbank (202),

(g) Korrelieren der Daten aus der visuellen Prüfung mit den Prozeßsteuerungsdaten und den Kontaktlinsendaten, um die bei der Herstellung von Kontaktlinsen angewandten Prozeßparameter zu optimieren.

19. Verfahren zur optimalen Steuerung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 18, wobei das Verfahren als weiteren Schritt die Erzeugung von Ausnahmedaten (52) für jede Kontaktlinse umfaßt, welche die visuelle Prüfung (50) nicht besteht und die Ausnahmedaten dann mit den Prozeßsteuerungsdaten und den Kontaktlinsendaten korelliert werden, um eine Verfolgung und Ausschaltung von Prozeßparametern zu ermöglichen, welche zur Herstellung fehlerhafter Kontaktlinsen führen.

20. Verfahren zur optimalen Steuerung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 18, wobei das Verfahren als weiteren Schritt die Speicherung vorgegebener und berechneter Eingabeparameter sowie den Vergleich der berechneten Eingabeparameter mit gemessenen Echtzeit-Daten umfaßt, die aus den Prozeßsteuerungsdaten abgeleitet wurden.

21. Verfahren zur optimalen Steuerung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 18, wobei das Verfahren als weiteren Schritt den Vergleich der berechneten und der gemessenen Daten nach einer gewissen Zeit mit den Ausnahmedaten umfaßt.

22. Verfahren zur optimalen Steuerung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 18, wobei das Verfahren als weiteren Schritt umfaßt, daß eine Liste vorgegebener Prozeßparameter in jeder der Erst- Niveau-Steuereinheiten (11 bis 17) auf dem neuesten Stand gehalten und ein Alarmzustand gemeldet wird, wenn einer der vorgegebenen Prozeßparameter vorgegebene Parameter überschreitet.

23. Verfahren zur optimalen Steuerung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 18, wobei das Verfahren als weiteren Schritt die Erstellung einer Pareto-Tabelle der Alarmzustände durch die Prozeßsteuereinrichtungen umfaßt.

24. Verfahren zur optimalen Steuerung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 18, wobei das Verfahren als weiteren Schritt die Ausschaltung unkontrollierter Trendwerte aus den Prozeßsteuerungsdaten umfaßt.

25. Verfahren zur optimalen Steuerung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 18, wobei das Verfahren als weiteren Schritt das Korrelieren historischer Trends aus mehrfachen, aus den Prozeßsteuerungsdaten abgeleiteten Zeitreihen umfaßt.

26. Verfahren zur optimalen Steuerung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 18, wobei das Verfahren als weiteren Schritt das Übertragen der Prozeßsteuerungsdaten zur relationalen Datenbank (202) in Datengruppen umfaßt, bei welchem diese Datengruppen zum Zeitpunkt ihrer Speicherung in der relationalen Datenbank (202) zeitlich markiert werden.

27. Verfahren zur optimalen Steuerung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 20, bei welchem die Kontaktlinsen in Formen hergestellt werden, die in Vertiefungen (1 bis 8) gehalten werden, welche in den Paletten (71) für jede Form ausgebildet sind und der Korrelationsschritt den Schritt der Ausschaltung bestimmter Paletten (71) umfaßt, welche mit einer oder mehreren Vertiefung(en) zur Herstellung fehlerhafter Kontaktlinsen beigetragen haben.

28. Verfahren zur optimalen Steuerung der Prozeßparameter in einer automatisierten Produktionslinie zur Herstellung von Kontaktlinsen nach Anspruch 27, bei welchem die Formteile in einer Anordnung von Formhohlräumen in einer Spritzformvorrichtung, welche in die Produktionslinie einbezogen ist, geformt werden und durch den Korrelationsschritt Kontaktlinsendaten mit Daten bezüglich dieser Anordnung verknüpft werden, um eine Korrelation der Prüfdaten zu bestimmten Formhohlräumen herzustellen.