DE102004057872A1

DE102004057872A1 - Etikettenverwaltung innerhalb einer Entscheidungs-, Unterstützungs- und Berichtsumgebung

Info

Publication number: DE102004057872A1
Application number: DE102004057872A
Authority: DE
Inventors: Jesse G. Lake Forest Demesa; Andrei V. Rancho Santa Margarita Ougarov
Original assignee: Indx Software Corp
Current assignee: Siemens Energy and Automation Inc
Priority date: 2003-12-03
Filing date: 2004-11-30
Publication date: 2005-08-18
Also published as: US7689579B2; US20050144154A1; US20050143969A1; US7698292B2

Abstract

Ein System und Verfahren zum Abrufen und Präsentieren von Daten in einer auf Etiketten basierenden Komponentenumgebung. Das offengelegte System liefert einen effizienten Mechanismus zum Assoziieren von Punkt- und Nicht-Punktdaten unter Verwendung hochgradig konfigurierbarer Datenerfassungsstrategien. Die Datenerfassungsstrategien umfassen angepaßte Abrufroutinen zum Durchführen der Datenerfassung in gewünschten Intervallen, um so unnötigen Bandbreitenverbrauch und unnötiges rechnerisches Overhead zu verringern.

Description

Querverweis auf verwandte Anmeldungen
Die vorliegende Anmeldung beansprucht den Nutzen der Priorität aus der provisorischen U.S.-Anmeldung Nr. 60/526,891, registriert am 3.12.2003 mit dem Titel „System and Methods for Retrieval, Presentation, and Synchronization of Real-Time Points/Tags with a Class-Based Component and View Model".
Technisches Gebiet
Die Anmeldung betrifft allgemein Informationsverwaltungsstrategien und insbesondere ein System und Verfahren zur Bereitstellung von Lösungen von skalierbarer Datensammlung, Modulierung und Zugriff.

Allgemeiner Stand der Technik

Beim Abrufen und Verwalten von Informationen innerhalb eines Geschäfts oder organisatorischen Unternehmens zeigen sich in der Regel zahlreiche technische Probleme in Verbindung mit Datenintegration und -interpretation, insbesondere wenn die Daten aus mehreren Quellen stammen. Zum Beispiel entstehen häufig Schwierigkeiten beim Versuch, große Datenmengen zur Benutzervisualisierung zu vereinigen und/oder zu formatieren, im Hinblick auf die entstehende administrative Last und komplexe programmatische Logik. Zusätzlich zeigen sich bei der Integration von Informationen von einer oder mehreren Quellen, die so konfiguriert sind, daß sie Echtzeitdaten mit anderen gewünschten Informationen bereitstellen, Probleme mit Zugänglichkeit, Bandbreite und Latenz, wodurch die Flexibilität und Skalierbarkeit dieser Systeme als Ganzes beschränkt wird.

Von einem herkömmlichen computerisierten System, das mit der Überwachung und Steuerung verschiedener Betriebsparameter für Komponenten und Subkomponenten einer Herstellungsanlage assoziiert ist, kann gefordert werden, große Mengen an Echtzeit- und/oder Nahezu-Echtzeit-Daten zu verarbeiten. Diese als Punktdaten bezeichneten Daten können aus unabhängigen Quellen entstehen, wobei jede Quelle so konfiguriert ist, daß sie in vordefinierten Intervallen im wesentlichen „rohe" oder „native" Informationen bereitstellt, wie zum Beispiel numerische Werte, die verschiedenen Meß-/Überwachungsvorrichtungsmeßwerten zugeordnet sind. Alleine genommen liefern diese Daten möglicherweise nur wenig oder keinen Kontext für ihre Interpretation und es müssen ihnen zusätzliche Informationen zugeordnet werden, um nachfolgend eine sinnvolle Verarbeitung und Analyse zu gestatten. Außerdem kann es wünschenswert sein, die Punktdaten zu erfassen, zu speichern und zu anderen Verarbeitungskomponenten zu verteilen, so daß den Punktdaten ein gewisses Maß an Kontext zugeschrieben werden muß.

Moderne industrielle Automatisierungssysteme, Überwachungssteuer- und Datenerfassungssysteme (SCADA), allgemeine Datenerfassungssysteme und Anlagedaten-Geschichtsschreiber repräsentieren nur einige wenige der Klassen oder Kategorien von Systemen, die Echtzeit- und/oder Nahezu-Echtzeit-Informationen in Form von Punktdaten speichern und verteilen können. In solchen Systemen repräsentiert ein Etikett ein Strukturdatenelement, das mit Punktdaten assoziiert ist, die aus verschiedenen Komponenten des Systems entstehen, die anderen Komponenten, Systemen, Anwendungen und/oder Benutzern zugänglich gemacht werden. Im allgemeinen unterliegen Punktdaten dynamischen Änderungen und werden überwacht und durch verschiedene Operationen und Funktionen, die der Verarbeitung der von gewählten Quellen erhaltenen Punktdaten zugeordnet sind, gemeldet. In industriellen Automatisierungs- und Steuersystemen können Entscheidungssupport- und Meldefähigkeiten auf der Basis von Etikett-assoziierten Punktdaten bereitgestellt werden, die über sehr kurze Zeitrahmen im Bereich von weniger als einer Sekunde bis zu weniger als einer Minute liegen können, überwacht werden.

Eine bei vielen herkömmlichen Systemen gefundene Beschränkung besteht darin, daß sie nur beschränkte Fähigkeiten für den Zugriff, die Interpretation und/oder Manipulation von auf Etiketten basierenden Punktdaten kollektiv oder in Verbindung mit anderen Nicht-Punktdaten bereitstellen. Nicht-Punktdaten betreffen eine allgemeine Kategorie von mit Punktdaten assoziierten Kontextbereitstellungsinformationen, die in einer Hinsicht die Funktionalität und Bedeutung der Punktdaten erweitern. Zu Nicht-Punktdaten können zum Beispiel deskriptive und/oder Attributinformationen gehören, die die Punktdaten charakterisieren, sowie andere Informationen, wie zum Beispiel Grenzwerte, Bereiche usw. Bei herkömmlichen Systemen ist die integrale und flexible Manipulation von auf Etiketten basierenden Punktdaten und Nicht-Punktdaten aufgrund ihrer naturgemäßen Unterschiede und Eigenschaften eingeschränkt.

Eine weitere bei herkömmlichen Systemen anzutreffende Schwierigkeit ist die begrenzte Fähigkeit, auf Etiketten basierende Daten und nicht auf Etiketten basierende Daten zu integrieren und miteinander in Beziehung zu setzen. Nicht auf Etiketten basierende Daten können aus zahlreichen Quellen stammen und betreffen getrennte Aspekte einer Unternehmensumgebung. Zum Beispiel können nicht auf Etiketten basierende Daten Daten umfassen, die herkömmlichen Datenbankanwendungen bzw. -Umgebungen zugeordnet sind, und können Transaktionsinformationen, Produktionsdaten, Geschäftsdaten usw. enthalten. Versuche, nicht auf Etiketten basierende Daten mit auf Etiketten basierenden Informationen zu integrieren, können herkömmlicherweise als Folge der zugrunde liegenden strukturellen und inhaltlichen Unterschiede zwischen diesen Datentypen behindern oder völlig verhindert werden. Das Erzeugen und Implementieren logischer Konstruktionen oder Schemata, bei denen sowohl auf Etiketten basierende Daten als auch nicht auf Etiketten basierende Daten integral benutzt werden, ist folglich bei herkömmlichen Systemen problematisch. Solche Beschränkungen begrenzen die Gesamtflexibilität des Systems und vergrößern die Schwierigkeit des Skalierens solcher Systeme auf komplexe Umgebungen auf Unternehmensebene.

Ein weiterer wichtiger Gesichtspunkt für die integrale Verwaltung von Punktdaten und Nicht-Punktdaten betrifft die Erkennung von Unterschieden bei den erwünschten Aktualisierungs- oder Erfassungshäufigkeiten. Die dynamischen Eigenschaften der Punktdaten führen zu zeitkritischen Abrufbeschränkungen für Systeme, die für das Erfassen und Auswerten von Punktdaten ausgelegt sind. Sich schnell ändernde Punktdaten werden im allgemeinen mit einer höheren Frequenz (z.B. einem kurzen Abrufzeitintervall) erfaßt oder aufgefrischt, um sicherzustellen, daß die Informationen aktuell sind. Andere Punktdaten und Nicht-Punktdaten können von statischerer Beschaffenheit sein und erfordern möglicherweise kein ähnlich kurzes Erfassungsintervall. Das Entwickeln effizienter und anpassbarer Datenerfassungsstrategien für das Abrufen von Informationen, die Dateneigenschaften und optimale Erfassungsraten berücksichtigen, ist wichtig, um Genauigkeit und Pünktlichkeit in den Daten sicherzustellen, ohne eine übermäßige rechnerische oder Übertragungslast zu erzeugen.

Herkömmliche Systeme eignen sich nicht gut für die Bereitstellung von Integration anpassbarer datenabhängiger Erfassungsstrategien oder zugeordneter Erfassungsraten. Folglich kommt es bei diesen Systemen zu verringerter Leistungsfähigkeit, insbesondere in komplexen Umgebungen, in denen abzurufende Daten oder Werte verschiedene optimale oder gewünschte Auffrischraten besitzen. Außerdem können diese herkömmlichen Systeme nicht die Möglichkeit liefern, differentielle Erfassungsstrategien für Punktdaten und Nicht-Punktdaten leicht so anzupassen oder zu konfigurieren, daß die Gesamtsystemleistungsfähigkeit verbessert wird. Folglich besteht eine Notwendigkeit, diese Beschränkungen bei der Integration und Verwaltung von auf Etiketten basierenden Informationen zu überwinden, um verbesserte Mechanismen zum Assoziieren und Arbeiten mit Punktdaten und Nicht-Punktdaten in derselben programmatischen oder logischen Umgebung bereitzustellen.

Kurze Darstellung

Verschiedene Ausführungsformen der Erfindung beschreiben ein System zum Entwickeln von Computermodellen für das Sammeln und Anzeigen von Daten. Eine Komponenten-Builder-Funktionalität des Systems erzeugt wiederverwendbare Komponenten zum Sammeln von Punktdaten und Nicht-Punktdaten, die mindestens einer Backend-Datenquelle zugeordnet sind. In einer Hinsicht umfassen die Punktdaten Daten, die aus mindestens einer adressierbaren Informationsquelle gesammelt werden, und die Nicht-Punktdaten umfassen Kontext definierende Daten, die den Punktdaten zugeordnet sind. Die Nicht-Punktdaten können außerdem nicht auf Etiketten basierende Nicht-Punktdaten umfassen, die wünschenswerterweise mit den auf Etiketten basierenden Punktdaten integriert werden sollen. Eine View-Builder-Funktionalität des Systems erzeugt wiederverwendbare Ansichten, die spezifischen, von dem Komponenten-Builder erzeugten Komponenten entsprechen, wodurch ein Benutzer eine oder mehrere Ansichten erzeugen kann, die spezifizieren, wie die Punktdaten und Nicht-Punktdaten, die von einer entsprechenden Komponente gesammelt werden, angezeigt werden sollen.

Verschiedene Ausführungsformen der Erfindung liefern weiterhin ein Verfahren zum Erzeugen eines Computermodells für das Sammeln und Anzeigen angesammelter Punktdaten und Nicht-Punktdaten. Bei mindestens einer Ausführungsform umfaßt das Verfahren weiterhin die folgenden Schritte: Sammeln von Punktdaten, die Daten umfassen, die aus mindestens" einer adressierbaren Informationsquelle gesammelt werden, auf der Basis einer spezifizierten Punktdatenerfassungsstrategie; Sammeln von Nicht-Punktdaten, die Kontext definierende Daten umfassen, die den Punktdaten zugeordnet sind, auf der Basis einer spezifizierten Nicht-Punktdatenerfassungsstrategie; Identifizieren einer oder mehrerer Beziehungen, die die Punktdaten und Nicht-Punktdaten assoziieren; und Anzeigen der Punktdaten und Nicht-Punktdaten in einer ersten Ansammlungsansicht.

Verschiedene Ausführungsformen der Erfindung liefern weiterhin ein Verfahren zum Erzeugen einer Computerrepräsentation, die beim Sammeln angesammelter Punktdaten und Nicht-Punktdaten verwendet wird. Bei mindestens einer Ausführungsform umfaßt das Verfahren die folgenden Schritte: Sammeln von Punktdaten, die Daten umfassen, die aus mindestens einer adressierbaren Informationsquelle gesammelt werden; Sammeln von Nicht-Punktdaten, die Kontext definierende Daten umfassen, die den Punktdaten zugeordnet sind; Identifizieren einer oder mehrerer Beziehungen, die die Punktdaten und Nicht-Punktdaten assoziieren, um so eine Basiskomponente zu definieren; und Definieren einer ersten erweiterten Komponente, die eine Instanziierung der Basiskomponente umfaßt, wobei mindestens ein Teil der Punktdaten und Nicht-Punktdaten der Basiskomponente in der ersten erweiterten Komponente verwendet wird.

Verschiedene Ausführungsformen der Erfindung beschreiben weiterhin ein System zum Erzeugen einer Computerrepräsentation, die beim Sammeln angesammelter Punktdaten und Nicht-Punktdaten verwendet wird. Bei mindestens einer Ausführungsform umfaßt dieses System weiterhin eine erste Datenerfassungskomponente zum Bereitstellen von Funktionalität zum Sammeln von Punktdaten, die Daten umfassen, die von mindestens einer adressierbaren Informationsquelle gesammelt werden; und eine zweite Datenerfassungskomponente, die Funktionalität zum Sammeln von Nicht-Punktdaten liefert, die Kontext definierende Daten umfassen, die den Punktdaten zugeordnet sind; und einen Komponenten-Builder, der Funktionalität zum Identifizieren einer oder mehrerer Beziehungen liefert, die die Punktdaten und Nicht-Punktdaten assoziieren, um so eine Basiskomponente zu definieren; wobei der Komponenten-Builder weiterhin Funktionalität zum Definieren einer ersten erweiterten Komponente liefert, die eine Instanziierung der Basiskomponente umfaßt, wobei mindestens ein Teil der Punktdaten und Nicht-Punktdaten der Basiskomponente in der ersten erweiterten Komponente verwendet wird.

Verschiedene Ausführungsformen der Erfindung liefern weiterhin ein Computermodell für das Sammeln von Daten aus mehreren Quellen, das innerhalb von Computerspeicherung folgendes umfaßt: mindestens eine Instanz mindestens einer Basiskomponente, wobei jede Instanz der mindestens einen Basiskomponente Punktdaten enthält, die Daten umfassen, die von mindestens einer adressierbaren Informationsquelle gesammelt werden, sowie Nicht-Punktdaten, die Kontext definierende Daten umfassen, die den Punktdaten zugeordnet sind; wenigstens eine Instanz der mindestens einen erweiterten Komponente, wobei jede Instanz der mindestens einen erweiterten Komponente eine Instanziierung der mindestens einen Basiskomponente umfaßt, wobei mindestens ein Teil der Punktdaten und Nicht-Punktdaten der mindestens einen Basiskomponente in jeder Instanz der mindestens einen erweiterten Komponente verwendet wird; und eine erste wiederverwendbare Ansicht, die spezifiziert, wie durch Instanzen der mindestens einen Basiskomponente und der mindestens einen erweiterten Komponente gesammelte Daten angezeigt werden sollen.

Verschiedene Ausführungsformen der Erfindung liefern weiterhin ein Computermodell für das Sammeln von Daten aus mehreren Quellen. Bei mindestens einer Ausführungsform umfaßt dieses Modell weiterhin innerhalb von Computerspeicherung: (a) mindestens eine Instanz mindestens einer ersten Komponente, wobei jede Instanz der mindestens einen ersten Komponente Punktdaten und erste Nicht-Punktdaten enthält, die aus mindestens einer auf Etiketten basierenden Informationsquelle gesammelt werden, sowie zweite Nicht-Punktdaten, die aus mindestens einer nicht auf Etiketten basierenden Informationsquelle gesammelt werden, wobei die ersten Nicht-Punktdaten Kontext definierende Informationen umfassen, die den Punktdaten zugeordnet sind, und die zweiten Nicht-Punktdaten Informationen umfassen, die einer Datenverwaltungsanwendung zugeordnet sind; und (b) mindestens eine Instanz mindestens einer zweiten Komponente, wobei jede Instanz der mindestens einen zweiten Komponente eine Instanziierung mindestens einer ersten Komponente umfaßt, wobei mindestens ein Teil der Punktdaten und Nicht-Punktdaten der mindestens einen ersten Komponente in jeder Instanz der mindestens einen zweiten Komponente verwendet wird.

Verschiedene Ausführungsformen der Erfindung liefern weiterhin ein System zum Entwickeln von Computermodellen für das Sammeln und Anzeigen von Daten. Bei mindestens einer Ausführungsform umfaßt ein solches System weiterhin einen Komponenten-Builder, der Funktionalität zum Erzeugen wiederverwendbarer Komponenten zum Sammeln von auf Etiketten basierenden Punktdaten und ersten Nicht-Punktdaten liefert, die mindestens einer Backend-Datenquelle zugeordnet sind, wobei die Punktdaten Daten umfassen, die aus mindestens einer adressierbaren Informationsquelle gesammelt werden, und die ersten Nicht-Punktdaten Kontext definierende Daten umfassen, die den Punktdaten zugeordnet sind; wobei der Komponenten-Builder weiterhin Funktionalität zum Sammeln zweiter Nicht-Punktdaten liefert, die einer nicht auf Etiketten basierenden Informationsquelle zugeordnet sind; und einen View-Builder, der Funktionalität zum Erzeugen wiederverwendbarer Ansichten liefert, die von dem Komponenten-Builder erzeugten spezifischen Komponenten entsprechen, wodurch ein Benutzer eine oder mehrere Ansichten erzeugen kann, die spezifizieren, wie die Punktdaten und Nicht-Punktdaten, die von einer entsprechenden Komponente gesammelt werden, angezeigt werden sollen.

Verschiedene Ausführungsformen der Erfindung liefern weiterhin ein Verfahren zum Erzeugen einer Computerrepräsentation, die beim Sammeln angesammelter Punktdaten und Nicht-Punktdaten verwendet wird. Bei mindestens einer Ausführungsform umfaßt dieses Verfahren die folgenden Schritte: Sammeln von Punktdaten, die Daten umfassen, die von mindestens einer adressierbaren Informationsquelle gesammelt werden; Sammeln erster Nicht-Punktdaten, die Kontext definierende Daten umfassen, die den Punktdaten zugeordnet sind; Sammeln zweiter Nicht-Punktdaten, die Daten umfassen, die einer nicht auf Etiketten basierenden Informationsquelle zugeordnet sind; Identifizieren einer oder mehrerer Beziehungen, die die Punktdaten und ersten Nicht-Punktdaten assoziieren, um so eine Basiskomponente zu definieren; und Definieren einer ersten erweiterten Komponente, die eine Instanziierung der Basiskomponente umfaßt, wobei mindestens ein Teil der Punktdaten und ersten Nicht-Punktdaten der Basiskomponente in der ersten erweiterten Komponente in Kombination mit den zweiten Nicht-Punktdaten verwendet wird.

Verschiedene Ausführungsformen der Erfindung beschreiben weiterhin System und Verfahren zum Integrieren von Punktdaten und Nicht-Punktdaten, die einer auf Etiketten basierenden Umgebung zugeordnet sind, dergestalt, daß Daten in Verbindung mit nicht auf Etiketten basierenden Nicht-Punktdaten verwendet werden können. In einer Hinsicht wird die Kombination und Benutzung von auf Etiketten basierenden Daten und nicht auf Etiketten basierenden Daten durch die Bildung einer Verbundtabelle erzielt, die auf Etiketten basierende Punktdaten und nicht auf Etiketten basierende Punktdaten umfaßt, die in einer Struktur dargelegt ist, die einer Verwendung mit nicht auf Etiketten basierenden Datenstrukturen zugänglich ist.

Verschiedene Ausführungsformen der Erfindung beschreiben weiterhin Verfahren zum Verwalten von Informationen, die mindestens einem auf Etiketten basierenden System zugeordnet sind. Diese Verfahren umfassen weiterhin folgendes: Identifizieren mindestens einer Punktdatenquelle, die dem mindestens einen auf Etiketten basierenden System zugeordnet sind, die so konfiguriert ist, daß sie Punktdaten liefert; Identifizieren mindestens eines Nicht-Punktdatenattributs, das den Punktdaten der mindestens einen Punktdatenquelle zugeordnet ist, wobei das mindestens eine Nicht-Punktdatenattribut bei der Entwicklung einer Datenerfassungsregel für das Erfassen von Punktdaten aus der mindestens einen Punktdatenquelle verwendet wird, und Auffüllen einer auf Etiketten basierenden Datenstruktur mit dem mindestens einen Nicht-Punktdatenattribut und erfaßten Punktdaten aus der mindestens einen Punktdatenquelle, wodurch die Punktdaten und Nicht-Punktdaten auf eine Weise, die kombinierte Zugänglichkeit liefert, integriert werden.

Kurze Beschreibung der Zeichnungen
Diese und andere Aspekte, Vorteile und neuartigen Merkmale der verschiedenen Ausführungsformen der Erfindung werden in der folgenden ausführlichen Beschreibung und unter Bezugnahme auf die beigefügten Zeichnungen dargelegt. In den Zeichnungen tragen gleiche Elemente dieselben Bezugszahlen, und es zeigen:
1 ein Punktdaten- und Nicht-Punktdatenerfassungssystem gemäß verschiedenen Ausführungsformen der Erfindung.
2 ein beispielhaftes System mit mehreren Instrumenten oder Einrichtungen jeweils mit einer oder mehreren Punktdatenquellen.
3 eine Übersicht über die Beziehung zwischen Punktdaten und Nicht-Punktdaten, die von einer Anwendungsumgebung verwendeten Backend-Quellen zugeordnet sind.
4A–D Beispiele für die Organisation von Punktdaten und Nicht-Punktdaten innerhalb des Systems der vorliegenden Lehren.
4E Beispiele für die Integration von auf Etiketten basierenden Punktdaten bzw. Nicht-Punktdaten und nicht auf Etiketten basierenden Nicht-Punktdaten innerhalb des Systems der vorliegenden Lehren.
5A–B beispielhafte Komponentendefinitionen, die Punktdaten- und Nicht-Punktdatengruppierungen zugeordnet sind, die logische Konstrukte innerhalb des Systems repräsentieren.
5C beispielhafte Komponentendefinitionen, die auf Etiketten basierenden Punktdaten- bzw. Nicht-Punktdaten- und nicht auf Etiketten basierenden Nicht-Punktdatengruppierungen zugeordnet sind, die logische Konstrukte innerhalb des Systems repräsentieren.
6A ein Diagramm auf hoher Ebene, das modellierte und nicht-modellierte Ansätze für die Etiketten- bzw. Komponentendefinition unterscheidet.
6B beispielhafte modellierte und nicht-modellierte Ansätze für die Etiketten- bzw. Komponentendefinition.
7A–C weiter den beispielhaften modellierten Ansatz für die Etiketten- bzw. Komponentendefinition.
8 einen beispielhaften nicht-modellierten Ansatz für die Etiketten- bzw. Komponentenansichtsdefinition.
9 eine beispielhafte Etiketten- bzw. Komponentenansichtsdefinition für auf Etiketten basierende und nicht auf Etiketten basierende Informationen.
Ausführliche Beschreibung
Bei verschiedenen Ausführungsformen liefert die Erfindung verbesserte Mechanismen zum Abrufen, Manipulieren, Organisieren und Analysieren von Informationen in Systemen, in denen Punktdaten und Nicht-Punktdaten Ko-existieren. Insbesondere werden neuartige Mechanismen zum Organisieren dieser Informationen in einem auf Klassen basierenden Repräsentationsmodell, das Etiketten unterstützt, offengelegt. Wie später ausführlicher beschrieben werden wird, liefern bestimmte Aspekte der Verfahren zur Datenverwaltung Formulierungen für Datenstrukturen, mit denen sowohl Punktdaten als auch Nicht-Punktdaten auf kohäsive Weise gespeichert und manipuliert werden. Zahlreiche Vorteile können aus den offengelegten Verfahren der integrierten Datenverwaltung realisiert werden, darunter eine verbesserte Systemleistungsfähigkeit und ein verringter Bandbreitenverbrauch.
Im vorliegenden Kontext können Punktdaten als aktuelle, Echtzeit- oder Wertedaten charakterisiert werden, die häufig einem oder mehreren Instrumenten, Komponenten oder Teilen eines Herstellungs-, industriellen, kommerziellen oder anderweitigen Systems zugeordnet sind. Beliebige dieser Vorrichtungen können so konfiguriert werden, daß sie Daten bezüglich einer oder mehrerer interessierender Punktdatenquellen erzeugen, messen und/oder abtasten. Zum Beispiel kann ein Datenerfassungssystem für ein bestimmtes Instrument oder eine bestimmte Maschine kontinuierlich oder periodisch Daten erfassen, die die Betriebsdrehzahl und/oder Betriebstemperatur eines Motors als Punktdaten aus einer dem Motor zugeordneten Punktdatenquelle erfaßt. In bestimmten Fällen kann es sich bei den Punktdaten um einen einfachen numerischen oder String-Wert handeln. Punktdaten können ferner dem Überwachen, Steuern und Melden von Funktionen verschiedener Instrumente, Komponenten und Anwendungen zugeordnet sein, um Informationen bezüglich des Betriebes eines Gerätesystems zu liefern. Diese Informationen können auch für ein Sammeln und Betrachten durch verschiedene Datenerfassungs- und Steuersysteme zur Verfügung gestellt werden.
Punktdaten werden häufig in roher oder unstrukturierter Form erfaßt, wobei die Punktdaten einen numerischen oder String-Wert ohne unterstützende Einzelheiten, Beschreibung und/oder Attribute widerspiegeln. Wie bereits beschrieben, können bestimmte Arten von Punktdaten Echtzeit- oder Nahezu-Echtzeit-Informationen zugeordnet sein (z.B. aktuelle Temperatur, aktueller Druck, aktuelle Geschwindigkeit, aktuelle Spannung, aktueller Strom usw.), die wünschenswerterweise relativ häufig abgetastet, aktualisiert oder aufgefrischt werden können.
Die genaue Häufigkeit dieser Operationen hängt in der Regel von den Eigenschaften der Punktdaten selbst ab und kann über die mehreren, in ein bestimmtes System integrierten Punktdatenquellen hinweg verschieden sein. Die Bereitstellung eines Mechanismus zur Ermöglichung einer Anpassung der Erfassungsstrategie für verschiedene Klassen von Punktdaten wird mit wachsender Größe oder Komplexität des Systems zunehmend signifikant, um unnötige Abfragen, Datenaufrufe und rechnerische Last zu verringern.
Wie für Fachleute erkennbar, kann der Kontext, in dem Punktdaten interpretiert werden sollen, ohne weiteres verlorengehen oder durcheinander gebracht werden. Um Punktdaten Kontext zu geben, kann es deshalb wünschenswert sein, den Punktdaten bestimmte Nicht-Punktdaten zuzuordnen. Nicht-Punktdaten können viele Formen annehmen, darunter u.a. Attributinformationen, Parameter, Grenzwerte und andere beschreibende Informationen. Im vorliegenden Kontext umfassen die Begriffe Punktdaten und Nicht-Punktdaten verschiedene Informationskategorien, die nicht unbedingt auf die hier beschriebenen Beispiele beschränkt sind. Folglich können die verschiedenen Ausführungsformen der Erfindung auf vielfältige verschiedene Kontexte angewandt werden, die in der Kombination und Benutzung von Punktdaten und Nicht-Punktdaten realisiert sind.
Andere nützliche Nicht-Punktdaten sind zum Beispiel Informationen wie etwa Wartungs-Arbeitsaufträge (relationale Daten oder Strukturdaten einer API (Anwendungsprogrammierschnittstelle) aus Wartungssystemen), Gerätedokumentation (unstrukturierte Daten, die gewöhnlich in Betriebssystemdateien und -dokumenten enthalten sind) und Informationen wie zum Beispiel URL-Links (Uniform Resource Locator) zu Lieferanten-Websites. Diese Arten von Nicht-Punktdaten können nicht auf Etiketten basierenden Informationen zugeordnet sein, die zum Beispiel in Datenbanken bzw. Umgebungen von Oracle^® oder SAP^® enthalten sind. Nicht-Punktdaten repräsentieren deshalb eine große Klasse von Informationen, die Punktdaten zugeordnet werden können und eine kontextuelle und informationelle Basis liefern.
Verschiedene Ausführungsformen der Erfindung liefern Mechanismen zum Integrieren von auf Etiketten basierenden Daten (einschließlich Punktdaten und Nicht-Punktdaten) mit nicht auf Etiketten basierenden Daten. Herkömmlicherweise können diese beiden Arten von Daten strukturell oder programmatisch aufgrund der Umgebung oder Anwendungen, in denen sie verwendet werden, miteinander inkompatibel sein. Bestimmte Merkmale der Erfindung überwinden diese herkömmlichen Beschränkungen, um eine bessere Integration, Verwaltung und Benutzung von auf Etiketten basierenden Daten und nicht auf Etiketten basierenden Daten in derselben Umgebung zu ermöglichen. Wie später ausführlicher beschrieben werden wird, liefert eine solche Integration wünschenswerterweise verbesserte Fähigkeiten zur Durchführung zahlreicher Aufgaben, wie zum Beispiel des Präsentierens zusammengesetzter, auf Etiketten basierender und nicht auf Etiketten basierender Ansichten.
Eine beispielhafte Architektur, in der auf Etiketten basierende Daten und nicht auf Etiketten basierende Daten (sowie Punktdaten und Nicht-Punktdaten) kollektiv verwendet werden können, ist die Softwareplattform XHQ (entwickelt und vertrieben von der IndX Software Corporation, Aliso Viejo, CA.). Diese XHQ-Anwendung kann so konfiguriert werden, daß sie einen Datenansammlungs- und Modellierungsrahmen und Werkzeuge zum Abrufen, Manipulieren, Analysieren und Assoziieren von auf Etiketten basierenden und nicht auf Etiketten basierenden Daten (sowie von Punktdaten und Nicht-Punktdaten) aus einer oder mehreren Quellen bereitstellt. Eine durch die vorliegenden Lehren bereitgestellte signifikante Verbesserung der XHQ-Softwarearchitektur ist die Möglichkeit, auf Etiketten basierende und nicht auf Etiketten basierende Daten (sowie Punktdaten und Nicht-Punktdaten) auf eine Weise zusammenzubringen, die klassenorientiert und hochgradig konfigurierbar ist. Ferner ermöglichen die vorliegenden Lehren das Erzeugen anpaßbarer „Ansichten", die eine großen Kreis von Benutzern und spezifische Anwendungsanforderungen unterstützen können. Zusätzliche Einzelheiten der Konfiguration und Benutzung dieses Systems sind in den XHQ-Benutzerhandbüchern zu finden.
Die Benutzung der verschiedenen Ausführungsformen der Erfindung liefert einen Mechanismus, durch den Informationen, die aus einem oder mehreren Backend-Datensystemen erhalten werden, verwaltet werden können. Backend-Datensysteme sind zum Beispiel verschiedene herkömmliche Systeme zum Empfangen und Verarbeiten von Punktdaten und Nicht-Punktdaten. In bestimmten Fällen besitzt ein Backend-Datensystem nur beschränkte Fähigkeiten zum Bereitstellen, Empfangen oder Verarbeiten von Punktdaten, während das Backend-Datensystem in anderen Fällen sowohl Punkt- als auch Nicht-Punktdaten verarbeiten kann. Im Kontext einer auf Etiketten basierenden Architektur können verschiedene Backend-Datensysteme zum Sammeln von Punktdaten und zum Durchführen von Operationen, bei denen Nicht-Punktdaten mit Punktdaten assoziiert werden, verwendet werden. Jedes sogenannte „Etikett" kann deshalb eine Datenstruktur repräsentieren, die ein gewähltes Informationsquantum umfaßt, das einer bestimmten Punktdaten-Informationsquelle zugeordnet ist und kann außerdem bestimmte Nicht-Punktdaten umfassen. Die verschiedenen Ausführungsformen der Erfindung liefern einen Mechanismus zum Erweitern von auf Etiketten basierenden Datenverwaltungsfähigkeiten, so daß eine verbesserte Integration von Punktdaten und Nicht-Punktdaten möglich wird. Solche Merkmale sind besonders über Umgebungen auf Unternehmensebene hinweg nützlich, bei denen große Mengen an Punktdaten und Nicht- Punktdaten kollektiv verwaltet werden sollen.
Im Kontext der informationalen Ansammlung, Etikettenpräsentation und des Daten-Warehousing können die verschiedenen Ausführungsformen der Erfindung angepaßt werden, um Punktdaten und Nicht-Punktdaten zu synchronisieren und zusätzlich diese Daten in einem objektorientieren System oder auf klassenartige Weise zu „verknüpfen" oder zusammenzuführen, um verbesserte Flexibilität bei der Abwicklung, Verarbeitung und Anzeige bereitzustellen. Wie später ausführlicher beschrieben werden wird, ermöglicht die Bereitstellung einer kohärenten und aktuellen Repräsentation für jedes Etikett eine Implementierung eines flexiblen, auf klassen basierenden Komponenten- und Ansichtsmodells.
In herkömmlichen Systemen erfordert die Konfiguration einer Datenerfassung, um den aktuellen Wert jedes Etiketts (z.B. Punktdaten-assoziierte Informationen) zu erfassen, im allgemeinen eine einzigartige Konfiguration für jedes Etikett und möglicherweise die Attribute jedes Etiketts (z.B. Nicht-Punktdaten). Wenn man berücksichtigt, daß es nicht selten ist, daß komplexe industrielle Automatisierungsanwendungen bis über 100.000 Etiketten enthalten, ist erkennbar, daß die individualisierte Konfiguration und Verwaltung von Etiketten auf die oben erwähnte Weise sehr zeitaufwendig, ineffizient und fehleranfällig sein kann. Ferner werden herkömmliche Mechanismen zur Steuerung, Überwachung oder Archivierung von auf Etiketten basierenden Informationen tendenziell sogar noch weniger nützlich, wenn versucht wird, solche Informationen über mehrere Systeme hinweg anzusammeln, wie zum Beispiel andere Anlagenproduktionssysteme und – Anwendungen.
Die verschiedenen Ausführungsformen der Erfindung liefern einen Mechanismus, wodurch die oben erwähnten Beschränkungen effektiv behandelt werden, wobei ein neuartiger Ansatz verwendet wird, der das Erfassen der Nicht-Punktdaten (z.B. Attribute und andere Informationen, die sich nicht häufig ändern) unter Verwendung eines periodischen, auf Abfragen basierenden Mechanismus, der sich nicht häufig ändert, mit einem auf Regel basierenden oder Vorlagen-Ansatz kombiniert, der die Erfassung sich schneller oder häufiger ändernder Punktdaten (z.B. Echtzeit- oder aktueller Wert eines Etiketts) lenkt. Außerdem erfordert der auf Regel basierende oder Vorlagen-Erfassungsansatz im allgemeinen keine individuelle Etikettenkonfiguration, so daß eine schnellere Entwicklung von Datenorganisations- und -visualisierungswerkzeugen gewährleistet wird.
1 zeigt Komponenten eines beispielhaften Datenerfassungs- und -verwaltungssystems gemäß mindestens einer Ausführungsform der Erfindung. Eine Backend-Datenumgebung 100 umfaßt verschiedene, auf Etiketten basierende Systeme und nicht auf Etiketten basierende Systeme. Diese Datenquellen sind zum Beispiel Anlagenhallenproduktionssysteme 102, Überwachungs-/Steuer-/Meldesysteme 103, Unternehmensressourcenplanungsdatensysteme 104, Personalverwaltungssysteme 105, Kundenbeziehungsverwaltungssysteme 106 und andere Datensysteme 107. Daten, die aus der Backend-Datenumgebung 100 entstehen, können Punktdaten 110, wie zum Beispiel die oben erwähnten aktuellen oder Echtzeit-Betriebswerte, und Nicht-Punktdaten 112 umfassen, die aus auf Etiketten basierenden Systemen, wie zum Beispiel den oben erwähnten Anlagenhallenproduktionssystemen 102 und den Überwachungs-/Steuer-/Meldesystemen 103 entstehen oder diesen zugeordnet sind. Diesen auf Etiketten basierenden Systemen zugeordnete Nicht-Punktdaten können weiterhin auch Attributinformationen umfassen, mit denen die Punktdaten und/oder Punktdatenquelle charakterisiert, kontextualisiert oder identifiziert werden.
Zusätzlich zu auf Etiketten basierenden Nicht-Punktdaten können nicht auf Etiketten basierende Nicht-Punktdaten verschiedenen Backend-Systemressourcen zugeordnet sein, wie zum Beispiel den Unternehmensressourcenplanungsdatensystemen 104, den Personalverwaltungssystemen 105 und den Kundenbeziehungsverwaltungssystemen 106. Überlicherweise können nicht auf Etiketten basierende Nicht-Punktdaten verschiedenen Datenbank- und Datenverwaltungsanwendungen zugeordnet sein, die solche Daten in einer Form bereitstellen, die aus den oben erwähnten Gründen (z.B. Format, Struktur, Anwendungsabhängigkeit usw.) nicht ohne weiteres mit bestimmten Komponenten der auf Etiketten basierenden Systemdaten kompatibel bzw. integrierbar ist. Wie später ausführlicher beschrieben werden wird, überwinden die verschiedenen Ausführungsformen der Erfindung diese Beschränkungen, um effiziente Mechanismen bereitzustellen, durch die es möglich wird, auf Etiketten basierende Punkt- und Nicht-Punkdaten innerhalb derselben Umgebung zum Zwecke u.a. der Verwaltung bzw. des Abrufens bzw. des Entwickelns bzw. der Betrachtung zu integrieren und miteinander in Beziehung zu setzen.
Die verschiedenen Komponenten der Backend-Datenumgebung 100 sind mit einer Anwendungsumgebung 120 dergestalt verbunden, daß die Punktdaten 110 und die Nicht-Punktdaten 112 (sowohl auf Etiketten basierend als auch nicht auf Etiketten basierend) der Anwendungsumgebung 120 zugänglich sind und darin gespeichert und verarbeitet werden können. In diesem Kontext bedeutet der Ausdruck verbunden direkt oder indirekt zur Kommunikation über eine direkte verdrahtete Netzwerk- oder drahtlose Verbindung zur Kommunikation fähig. Die Anwendungsumgebung 120 kann einen Unternehmensserver 122, einen Webserver 124 und/oder einen oder mehrere Lösungsserver 126 umfassen. Die Anwendungsumgebung 120 kann weiterhin mit einer Entwicklungsumgebung 128 verbunden sein. Die Entwicklungsumgebung 128 umfaßt einen oder mehrere Entwicklungs-Clients 130. Bei verschiedenen Ausführungsformen können der Unternehmensserver 122, die Lösungsserver 126 und die Entwicklungs-Clients 130 aus Anwendungsprogrammen bestehen, die zum Beispiel in einer Sprache wie etwa Java und/oder C++ entwickelt werden und unter einem Betriebssystem wie zum Beispiel der Windows^TM-Familie von Betriebssystemen (ein Produkt der Microsoft Corp.) ablaufen.
Die Anwendungsumgebung 120 kann ferner mit einer Browsing-Umgebung 132 verbunden sein. Die Browsing-Umgebung 132 umfaßt ein oder mehrere Browsing-Terminals 134. Jedes Browsing-Terminal 134 umfaßt ein Kommunikationsprogramm, wie zum Beispiel einen Web-Browser. Bei verschiedenen Ausführungsformen sind die Browsing-Terminals 134 durch Verwendung eines Web-Browsers wie zum Beispiel Netscape Communicator oder Internet Explorer, der von den Browsing-Terminals 134 aus gestartet wird, durch das Internet mit der Anwendungsumgebung 120 verbunden. Bei anderen Ausführungsformen sind die Browsing-Terminals 134 durch ein Intranet mit der Anwendungsumgebung 120 verbunden.
Bei verschiedenen Ausführungsformen liefert die Erfindung einen Mechanismus zur Integration von erfaßten Punktdaten 110 und Nicht-Punktdaten 112 auf vereinigte Weise unter Verwendung eines objektorientierten repräsentationalen Modells für die Datenerfassung und -verwaltung. Ferner wird ein Mechanismus zum Anpassen des Datenerfassungsprozesses bereitgestellt, in dem konfigurierbare Erfassungshäufigkeiten oder Abrufintervalle für die Informationen assoziiert werden, um die Gesamtsystemeffizienz zu verbessern. Die konfigurierbaren Erfassungsfrequenzen können eingestellt werden, um sowohl Punktdaten 110 als auch Nicht-Punktdaten 112 sowie die Rate, mit der diese Daten sich ändern oder aufgefrischt werden, zu berücksichtigen, um der Anwendungsumgebung 120 aktuelle Informationen zuzuführen.
Die oben erwähnten informationalen Erfassungs- und Verwaltungsmerkmale verbessern wünschenswerterweise die Systemleistungsfähigkeit und vermindern den Bandbreitenverbrauch durch Vermeidung unnötiger oder redundanter Datenanforderungen von der Backend-Datenumgebung 100. Genauer gesagt liefert das System Optionen und Funktionalität zum zweckmäßigen Spezifizieren und Gruppieren verschiedener Informationen, die aus der Backend-Datenumgebung 100 abgerufen werden sollen und von der Anwendungsumgebung 120 verarbeitet werden. Bei verschiedenen Ausführungsformen verwendet die Datengruppierungsfunktionalität Etikettensammlungen zur Modellierung von Punktdatenerfassungen aus einer oder mehreren Punktdatenquellen. Die Etikettensammlungen ermöglichen ferner ein Definieren und Modellieren von Komponenten innerhalb der Backend-Datenumgebung 100 und liefern ein wiederverwendbares Betriebsmittel, mit dem der Entwicklungsprozeß insbesondere in großen oder komplexen Systemen verbessert werden kann.
Bei herkömmlichen Systemen, in denen die oben erwähnten Merkmale leicht kombinierbarer Punktdaten- und Nicht-Punktdatenzugänglichkeit fehlen, kann man signifikante Kosten im Hinblick auf vergrößerte Entwicklungszeit, komplexe Systemmodellierung und ineffiziente Datenmeldung beobachten. Ein häufig in herkömmlichen Systemen beobachtetes Problem besteht darin, daß das Datenabrufen für Daten, die kein Auffrischen oder Aktualisieren mit der Rate, mit der sie aufgefrischt werden, erfordern, zu häufig erfolgt. Folglich kann es bei diesen Systemen zu potentiell verschwendeten Systembetriebsmitteln und nachteiligen Effekten bezüglich der Gesamtdatenzugänglichkeit kommen. Herkömmliche Systeme, die Daten nicht häufig genug abrufen, stellen zusätzlich ein Problem dar, da die Daten unakzeptabel veraltet (z.B. „stale") werden können und. den aktuellen Status oder Zustand der Punktquelle, aus der die Informationen erfaßt wurden, nicht genau widerspiegeln. Die verschiedenen Ausführungsformen der Erfindung überwinden diese und andere Beschränkungen durch Bereitstellung eines hochkonfigurierbaren Mittels zum Abstimmen von Datenerfassungsraten oder Abruffrequenzen, um dabei zu helfen, eine genaue und pünktliche Repräsentation der Punktdaten 110 sicherzustellen.
Im Gegensatz zu den rudimentär konfigurierbaren Datenabruffähigkeiten bestimmter herkömmlicher Systeme können die verschiedenen Ausführungsformen der Erfindung für Leichtigkeit der Benutzung in einer auf Klassen basierenden Umgebung ausgelegt werden. Die verschiedenen Ausführungsformen der Erfindung können ferner auf klassen basierende Anordnungen bereitstellen, wodurch Konfiguration, Steuerung und Überwachung von Punktdaten 110 und Nicht-Punktdaten 112 mit anpaßbaren Abruffrequenzen möglich werden.
2 zeigt ein Blockschaltbild eines beispielhaften Mechanismus zur Assoziation von Punktdaten 110 mit Nicht-Punktdaten 112. In einer Hinsicht können die Informationen aus mehreren Informationsquellen 204 entstehen, die beispielsweise als Instrumente oder Einrichtungen 205 gezeigt sind, wie zum Beispiel eine beispielhafte Pumpe 206 und ein beispielhafter Motor 207. Die Informationsquellen 204 können Punktdatenquellen 208 umfassen, die einem bestimmten Instrument oder einer bestimmten Einrichtung 205 zugeordnet sind, wie zum Beispiel: Register, Meßgeräte, Überwachungsvorrichtungen oder Sonden, aus denen die Punktdaten 110 erzeugt und nachfolgend abgerufen oder erfaßt werden können. Außerdem können mit jeder Informations-quelle 204 Nicht-Punktdaten 112 assoziiert werden, darunter zum Beispiel: Namen, Bereiche, Attribute, Orte, Grenzwerte, Quellen und andere Informationen. Bestimmte Nicht-Punktdaten 112 können durch eine gewählte Informationsquelle 204 in Verbindung mit den Punktdaten 110 bereitgestellt werden, oder die Nicht-Punktdaten 112 können als Alternative nachfolgend den Punktdaten 110 zugeordnet werden, wie später ausführlicher beschrieben werden wird.
In einer Hinsicht entsprechen die Punktdatenquellen 208 adressierbaren Punkten der Informationsquellen 204 und können als ein Etikett bezeichnet werden. Ein Etikett umfaßt eine Sammlung gewünschter Punktdaten 110 und Nicht-Punktdaten 112, die von der Anwendungsumgebung 120 verwendet oder verarbeitet werden. Jedes Etikett kann ferner eine Datenstruktur widerspiegeln, die zum Speichern von Punktdaten 110 und/oder Nicht-Punktdaten 112 verwendet werden, an denen die Anwendungsumgebung 120 wirkt. Es versteht sich, daß „Punktdaten" und „Etikette" Ausdrücke widerspiegeln, die in verschiedenen Verarbeitungs- und Herstellungsindustrien verwendet werden, um Quellen eindeutig identifizierbarer Werte für verschiedene Instrument- und Vorrichtungsfunktionalitäten und -merkmale zu definieren, können aber auch in anderen Kontexten und Systemen angewandt werden.
Jede Punktdatenquelle 208 kann einem meßbaren oder überwachbaren Merkmal zugeordnet werden, aus dem Punktdaten 110 angefordert und gesammelt werden. Für ein gegebenes Instrument oder eine gegebenene Einrichtung 205 können mehrere solche Punktdatenquellen existieren, wobei die Punktdaten 110, die von jeder Punktdatenquelle 208 erzeugt werden oder dieser zugeordnet sind, relativ häufigen Änderungen unterworfen sind und allgemein einen aktuellen Zustand oder eine Betriebsbedingung dieser Punktdatenquelle 208 repräsentieren. Punktdaten 110 können außerdem direkt oder indirekt durch Komponenten der Anwendungsumgebung 120 erfaßt und mit Nicht-Punktdaten 112 assoziiert werden, die von den Komponenten der Anwendungsumgebung 120 erkannt werden. Bei verschiedenen Ausführungsformen kann die Assoziation bestimmter Nicht-Punktdaten 112 mit den Punktdaten 110 durch das Instrument 205 erzielt werden, oder alternativ dazu können Assoziationen der Nicht-Punktdaten 112 durch andere Komponenten des Systems durchgeführt werden. In verschiedenen Fällen kann die Assoziation von Punktdaten 110 mit Nicht-Punktdaten 112 im wesentlichen für die Punktdatenquellen 208 und/oder andere verschiedene assoziierte Backend-Datensysteme transparent erfolgen.
Im allgemeinen sind die Nicht-Punktdaten 112 mit Punktdaten 110 assoziiert und werden in der Etikettendatenstruktur widergespiegelt. Zusammen können diese Informationen von der Anwendungsumgebung 120 zum Zwecke des Überwachens, Steuerns und Analysierens und zum Bewerten des Zustands gewählter Instrumente oder Systeme in der Backend-Umgebung 100 verwendet werden.
Punktdaten 110 und Nicht-Punktdaten 112 können von einem Datenerfassungssystem 215 empfangen werden, das so konfiguriert ist, daß es Informationen von verschiedenen Punktdatenquellen 208 oder anderen Backend-Datensystemen 217, die entsprechenden Punktdatenquellen 208 zugeordnet sind, sammelt. Bei verschiedenen Ausführungsformen liefern das Datenerfassungssystem 215 und die Backend-Datensysteme 217 in der Regel nur begrenzte Funktionalität im Hinblick auf Datenerfassung- und verwaltung, können aber als Quelle von Punktdaten 110 und Nicht-Punktdaten 112 für die Anwendungsumgebung 120 dienen. Als Alternative kann die Anwendungsumgebung 120 so konfiguriert werden, daß sie Punktdaten 110 und Nicht-Punktdaten 112 direkt von den verschiedenen Backend-Datensystemen 217 und Punktdatenquellen 208 erfaßt. In solchen Fällen ist die Anwendungsumgebung 120 fähig, mit den verschiedenen Komponenten der Backend-Datenumgebung 100, den Systemen 215, 217 und/oder Punktdatenquellen 208 in Wechselwirkung zu treten, um Informationen über jede gewünschte Punktdatenquelle 208 und assoziierte Nicht-Punktdaten 112 zu sammeln.
Wie bereits beschrieben, können die Punktdaten 110 aus vielen Punktdatenquellen stammen, die jeweils unterschiedliche Flüchtigkeits- oder Langlebigkeitseigenschaften aufweisen. In einer Hinsicht beschreiben diese Eigenschaften, wie dynamisch die Punktdaten 110 erwartungsgemäß sind, wobei bestimmte Punktdaten als relativ statisch oder sich selten ändernd und andere Punktdaten als relativ dynamisch oder sich häufiger ändernd charakterisiert werden können. Die aus den Systemen 215, 217 oder Punktdatenquellen 208 erfaßten Punktdaten 110 können also vielfältige zeitliche Eigenschaften besitzen, die von sich im wesentlichen niemals ändernd bis zu sich im wesentlichen jeden Moment ändernd reichen können. Ein Merkmal des Datenerfassungs- und Verwaltungssystems der verschiedenen Ausführungsformen der Erfindung besteht darin, daß es einen Mechanismus zum zweckmäßigen Assoziieren einer konfigurierbaren Datenabruf- oder -erfassungsfrequenz mit jeder Punktdatenquelle 208 liefert, so daß die Anwendungsumgebung 120 so konfiguriert werden kann, daß sie die Punktdaten 110 je nach Notwendigkeit oder Wunsch erhält, auffrischt oder aktualisiert.
Bei verschiedenen Ausführungsformen können die Punktdaten 110 vielfältige verschiedene Datenkonstruktionen umfassen. Zum Beispiel können die Punktdaten 110 Echtzeit-Betriebsdaten für eine Informationsquelle 204 oder ein Backend-Datensystem 215, 217 betreffen, darunter Temperatur, Druck, Geschwindigkeit usw. Bei bestimmten Fällen kann es sich bei den Punktdaten 110 um einen primitiven Wert handeln, der keine Beschreibung der Punktdatenquelle 208, aus der er erhalten wurde, mit sich führt. In anderen Fällen können die Punktdaten 110 mit Nicht-Punktdaten 112 assoziiert sein, darunter Attributinformationen, die die Punktdatenquelle 208 (z.B. Instrumentenname) oder Punktdaten 110 selbst (z.B. Dateneinheiten) charakterisieren. Ferner können bestimmte Nicht-Punktdaten oder Attribute 112 für die Punktdatenquellen 208 definiert werden. Dazu können zum Beispiel Betriebsbereiche, Punktdatenquellennamen oder -assoziationen und andere Informationen gehören. Die Nicht-Punktdaten oder Attributinformationen 112 können von den Datenerfassungssystemen 215, 217 zugewiesen werden, mit denen die Punktdaten 110 erfaßt werden, oder können direkt durch Komponenten der Anwendungsumgebung 120 zugewiesen werden. Bei verschiedenen Ausführungsformen spiegeln Nicht-Punktdaten oder Attributinformationen 112 statischere Informationen als Punktdaten 110 wider und ändern sich in der Regel nicht mit derselben Frequenz wie die Punktdaten 110 selbst. Als Folge des statischeren Charakters dieser Informationen können die Erfassungsrate oder Abruffrequenz wünschenswerterweise entsprechend niedriger eingestellt werden.
In einer Hinsicht können ein Komponenten-Builder 226 und Lösungs-Builder 227 mit der Anwendungsumgebung 120 assoziiert werden. Der Komponenten-Builder 226 liefert Funktionalität zum Definieren, Erzeugen, Verwalten und Visualisieren verschiedener Komponentendatenstrukturen, die für Punkt- und Nicht-Punktdatenerfassung bzw. Integration gemäß verschiedenen Ausführungsformen der Erfindung benutzt werden. Der Lösungs-Builder 227 liefert Funktionalität zum Erzeugen von Ansichten oder Visualisierungen von mit dem Komponenten-Builder 226 erzeugten Komponenten.
In einer Hinsicht ermöglichen der Komponenten-Builder 226 und der Lösungs-Builder 227 eine flexible Organisation und Präsentation von Punkt- und Nicht-Daten 110, 112 unter Verwendung eines graphisch gesteuerten Ansatzes. Bei einem solchen Ansatz kann ein Benutzer eine oder mehrere Komponenten und Ansichten auf symbolische und menügesteuerte Weise erzeugen. Weiterhin können diese Builder 226, 227 intuitive und halbautomatisierte Mechanismen für Punktdaten- und Nicht-Punktdatenintegration verwenden, die den Entwurf und die Manipulation der Daten 110, 112 in kleinem und auch in großem Maßstab ermöglichen.
Die oben erwähnte XHQ-Softwareplattform repräsentiert eine beispielhafte Architektur, die konfiguriert werden kann, um aus der Implementierung der Komponenten-Builder- und Lösungs-Builder-Funktionalität 226, 227 Nutzen zu ziehen. Obwohl sie als mit der Anwendungsumgebung 120 assoziiert abgebildet sind, versteht sich, daß der Komponenten-Builder 226 und der Lösungs-Builder 227 mit verschiedenen Komponenten des Systems 100, wie zum Beispiel der Entwicklungsumgebung 128 integriert werden können.
3 zeigt weiter eine Übersicht über die Beziehung zwischen Punktdaten 110 und Nicht-Punktdaten 112, die mit der Backend-Umgebung 100 assoziiert sind, und der Etikettenrepräsentation und -sammlungen, die von der Anwendungsumgebung 120 verwendet werden. In einer Hinsicht können Punktdaten 110 und Nicht-Punktdaten 112, die von ausgewählten Punktdatenquellen 208, Backend-Datensystemen 217, Datenerfassungssystemen 215 und/oder der Anwendungsumgebung 120 erhalten werden, in einem oder mehreren Etiketten 305 gespeichert werden, die als eine Etikettensammlung 310 organisiert sind. Jede Etikettensammlung 310 repräsentiert eine Gruppierung von Etiketten 305, die logisch assoziiert und für eine Datenlösung repräsentativ sind, die einem Teil oder im wesentlichen allen gewünschten Punktdaten 110 und Nicht-Punktdaten 112 für ein bestimmtes Instrument, eine bestimmte Vorrichtung, ein bestimmtes System, eine bestimmte Ansicht usw. entspricht. Dies ist in Figur als ein Motor-assoziiertes Temperaturetikett, ein Pumpen-assoziiertes Drucketikett und zusätzliche unspezifizierte Etiketten exemplifiziert. Bei verschiedenen Ausführungsformen kann jede Datenlösung als eine hierarchische Ordnung oder Datenstruktur visualisiert werden, die auf visuell intuitive Weise angezeigt und navigiert werden kann. Wie später ausführlicher beschrieben werden wird, gewährleistet diese Art von Datenorganisation wesentliche Flexibilität beim Sammeln und Präsentieren von Daten, wodurch die Entwicklung anpaßbarer Ansichten und Lösungen auf relativ unkomplizierte Weise möglich wird.
In einer Hinsicht repräsentiert jedes Etikett 305 eine wiederverwendbare Komponente, die ein oder mehrere Etikettenkomponentenglieder 322 umfassen kann, die Punktdaten 110 und/oder Nicht-Punktdaten 112 zugeordnet sind. Jedes Etikett 305 kann ferner mit einer oder mehreren „Ansichten" assoziiert sein, die jeweils eine wiederverwendbare Visualisierung der in dem Etikett 305 enthaltenden Informationen repräsentieren. Bei bestimmten Ausführungsformen referenziert jede Ansicht bestimmte Etikettengliederinformationen, einschließlich Teile der Punktdaten 110 und Nicht-Punktdaten 112, die auf spezifizierte Weise angezeigt oder visualisiert werden können. Aspekte der Etikettenvisualisierung können auf diese Weise die Verwendung von Animationstechniken umfassen, um die Bedingungen und Informationen des Etiketts graphisch abzubilden.
Bei verschiedenen Ausführungsformen enthält jede Etikettensammlung 310 mehrere ähnlich definierte Etiketten 305, die jeweils mit verschiedenen gewählten Informationsquellen 204, Punktdatenquellen 208 oder anderen Systemkomponenten oder Subkomponenten assoziiert sein können, für die auf die Punktdaten 110 und Nicht-Punktdaten 112 wünschenswerterweise zugegriffen werden kann und für die die Punktdaten 110 und die Nicht-Punktdaten 112 wünschenswerterweise visualisiert werden können. Ein Vorteil, der durch die Verwendung der Etikettensammlung 310 und der konstituierenden Etiketten 305 entsteht, besteht darin, daß jedes Etikett 305 die Hauptinformationen und Felder zur Aufnahme einer Punktdatenquelle 208 in die Etikettensammlung 310 darlegt. Jedes Etikett 305 kann eine ähnliche Struktur umfassen und kann weiterhin vordefinierte oder Vorgabe-Datenzugriffsregeln und -operationen für den Zugriff auf die Punktdaten 110 und Nicht-Punktdaten 112 bereitstellen. Das Hinzufügen neuer Etiketten 305 (z.B. neu überwachter Punktdatenquellen 208) kann folglich umfassen, je nach Bedarf oder Wunsch zusätzliche Etiketten 305 an die Etikettensammlung 310 anzuhängen.
Aufgrund der logischen Organisation der Etiketten 305 und der darin enthaltenden Informationen kann die Datenintegrität auch in sehr großen Überwachungsumgebungen relativ leicht erhalten werden, und das System ist hochgradig skalierbar. Ein weiterer Vorteil, der durch die Benutzung der Etiketten 305 auf die oben erwähnte Weise entsteht, besteht darin, daß über eine Vielzahl von Etiketten 305 hinweg relativ leicht Regeln und Operationen angewandt werden können, ohne daß es notwendig wird, jedes Etikett 305 unabhängig zu editieren oder zu modifizieren. Ein solches Merkmal ist zum Beispiel dann nützlich, wenn die Auffrisch- bzw. Aktualisierungsfrequenz und/oder Anweisungen für Informationszugriff spezifiziert werden. Die Konstruktion jedes Etiketts 305 liefert einen Mechanismus zum „globalen" Definieren von Operationen, die später aufgelöst werden, um die entsprechende Punktdatenquelle 208 oder andere Komponente, aus der die Punktdaten 110 und Nicht-Punktdaten 112 erhalten werden können, zu identifizieren.
Die Leistungsfähigkeit in dem System wird verbessert, indem die Möglichkeit bereitgestellt wird, Datenzugriffskonstrukte für Punktdaten 110 und Nicht-Punktdaten 112 zu definieren, die sich für die Aufgabe des Erfassens der Informationen mit der entsprechenden Frequenz eignen. Zum Beispiel können Nicht-Punktdaten 112 durch Datenbank-Abfragesprachenabfragen 315 wie zum Beispiel SQL (Structured Query Language) oder SQL-artige Abfragen erhalten werden, um gewählte Informationen, die in der Etikettensammlung 310 enthalten sind, aufzufrischen. Solche Abfragen 315 eignen sich zum Zugreifen und Abrufen im allgemeinen statischer Informationen, wie zum Beispiel Nicht-Punktdaten 112, die einem gewählten Etikett 305 zugeordnet sind. Bei bestimmten Implementierungen ist jeweils Konstrukt 315 so konfiguriert, daß es auf die Ergebnisse verschiedener Abfragespalten, die gewählten Etikettenkomponentenglieder 322 zugeordnet sind, zugreift und diese bereitstellt. Abfragen 315 können sowohl Punktdaten 110 als auch Nicht-Punktdaten 112 assoziiert werden, obwohl im allgemeinen die Abfragen 315 in der Regel auf Informationen gerichtet sind, die sich selten ändern (z.B. die Nicht-Punktdaten 112).
Ferner können eine oder mehrere „Etiketten"-Wertverbindungen 320 für gewählte Punktdaten-assoziierte Etikettenkomponentenglieder 322 definiert werden, von denen bestimmt wird, daß sie sich relativ häufig ändern (z.B. akuteller Wert oder Sollwert). Bei verschiedenen Ausführungsformen muß eine „Etiketten"-Wertverbindung 320 nur einmal pro interessierendem Etikettenkomponentenglied 322 spezifiziert werden. Die Etikettenwertverbindung 320 kann ferner auf einer Vorlage oder Regel basieren, die generisch über einen Teil oder im wesentlichen alle der Etiketten 305 hinweg angewandt werden kann, ohne eine explizite Spezifikation für jedes Etikett 305 zu erfordern.
Um die Flexibilität des Systems zu verbessern, können jedes Etikett 305 und zugeordnete Etikettenkomponentenglieder 322 mit einer Namenskennung 325 assoziiert werden. Die Namenskennung 325 liefert einen zweckmäßigen Mechanismus zum Zugreifen auf ein spezifisches oder gewünschtes Etikett 305 und darin enthaltene Komponentenglieder 322.
Ferner kann man mit der Namenskennung 325 in Verbindung mit Formeln, Ausdrücken oder Regeln eine verbesserte Zugänglichkeit zu den in dem Etikett 305 enthaltenen Informationen bereitstellen. Die Namenskennung 325 kann ferner so konfiguriert werden, daß diese Informationen als Referenz benutzt werden können, um ein entsprechendes Etikettenkomponentenglied 322 anzugeben, dessen Wert mit Informationen (z.B. Punktdaten 110 oder Nicht-Punktdaten 112) aus der Backend-Umgebung 100 assoziiert werden soll.
Etikettenregeln geben Anweisungen für den Zugriff auf den entsprechenden Wert oder die entsprechenden Informationen aus dem gewünschten Betriebsmittel bzw. den gewünschten Betriebsmitteln der Backend-Datenumgebung 100. Zum Beispiel kann eine Regel dergestalt definiert werden, daß die Namenskennung 325 eines gewählten Etiketts 305 als eine Referenz verwendet wird, um ein gewähltes Etikettenkomponentenglied Current Value 330 (aktueller Wert) mit aus einem gekennzeichneten Betriebsmittel der Backend-Umgebung 100 erhaltenen Punktdaten 110 aufzufüllen.
Als ein weiteres Beispiel kann ein gewähltes Backend-Umgebungsbetriebsmittel eine adressierbare Punktdatenquelle 208 umfassen, deren Wert in dem Feld Current Value 330 eines gewählten Etiketts 305 gespeichert wird. Das Feld Current Value 330 (sowie weitere Etikettenkomponentenglieder 322) kann vielfältige Punktdateninformationen speichern, darunter aktuelle Temperaturen, Geschwindigkeiten, Drücke und andere Echtzeit- bzw. Nahezu-Echtzeitinformationen, die wünschenswerterweise mit relativ hoher Frequenz überwacht und aufgefrischt werden. Ähnlich können Nicht-Punktdaten 112 mit den Punktdaten 110 assoziierte Attribute enthalten, wie zum Beispiel Maschinen- oder Instrumentennamen, Bereich, Region, Organisation, Einheit, Hochbereiche, Niedrigbereiche, mit den Punktdaten 110 assoziierte Einheiten, Beschreibungen des Etiketts 305 und andere Informationen. Diese Informationen können innerhalb eines gewählten Etiketts 305 unter Verwendung der oben erwähnten Datenabfrage 315 aufgefüllt werden, um Kontext für die Punktdaten 112 bereitzustellen.
Bei verschiedenen Ausführungsformen kann die Anwendungsumgebung 120 so konfiguriert werden, daß eine Kombination von Datenabfragen 315 und Etikettenwertverbindungen 320 verwendet wird, um entsprechende Daten und Informationen, auf die aus der Backenddatenumgebung 100 zugegriffen werden soll, zu erfassen und diese Informationen in einem entsprechenden Etikettenkomponentenglied 322 zu speichern (z.B. in einem temperaturassoziierten TAG (Etikett) und einem druckassoziierten TAG (Etikett)). Wie bereits erwähnt, kann, um Bandbreite zu erhalten und die Systemleistungsfähigkeit zu verbessern, jede Anforderung von Punktdaten 110 und Nicht-Punktdaten 112 mit verschiedenen gewählten Auffrischfrequenzen assoziiert werden, um ein Gleichgewicht zwischen dem aktuell halten von Informationen innerhalb des Etiketts 305 und der Vermeidung unnötiger Datenanforderungen aufrechtzuerhalten.
Obwohl die in 3 gezeigte Etikettensammlung aus mehreren Etiketten homogener Zusammensetzung zusammengesetzt ist, versteht sich, daß gemäß den verschiedenen Ausführungsformern der Erfindung andere Etikettensammlungen ohne weiteres konzipiert werden können, deren Zusammensetzung zusätzliche bzw. andere Etikettenkomponentenglieder 322 umfassen kann. In einer Hinsicht kann es wünschenswert sein, eine Etikettensammlung zu führen, die eine singuläre Etikettenzusammensetzung aufweist, die durch im wesentlichen identische Etikettenkomponentenglieder 322 (z.B. ähnlich wie die gezeigte) definiert wird. Solch eine Konfiguration vermittelt wünschenswerterweise Gleichförmigkeit zwischen allen Erfassungen von Punktdaten 110 bzw. Nicht-Punktdaten 112. Es wird jedoch in Betracht gezogen, das es Fälle gibt, in denen eine Etikettensammlung wünschenswerterweise als mehrere Etiketten heterogener Zusammensetzung gebildet wird. Die Bereitstellung mehrerer Zusammensetzungen von Etiketten kann dabei nützlich sein, vielfältige verschiedene Erfassungen von Punktdaten 110 bzw. Nicht-Punktdaten 112 zu berücksichtigen, die logisch oder funktional kompatibel miteinander sein können oder nicht.
4A–D zeigen Beispiele für die Organisation von Punktdaten 110 und Nicht-Punktdaten 112 innerhalb des Systems, und wie auf diese Informationen zugegriffen werden kann und wie sie manipuliert werden können. In einer Hinsicht können Punktdaten 110 und Nicht-Punktdaten 112 in einer oder mehreren Datenbanken, Tabellen oder Zwischenspeicherstrukturen, wie in Tabellen 405, 406, gespeichert werden. Ein beispielhafter Nicht-Punktdatenmechanismus wird durch Tabelle 405 widergespiegelt, die mehrere Felder 410 umfassen kann, die mit mehreren verschiedenen Punktdatenquellen 208, Instrumenten, Vorrichtungen, Einrichtungen oder anderen Betriebsmitteln der Backend-Datenumgebung 100 assoziiert sein können. In einer Hinsicht repräsentieren die Felder 410 der Tabelle 405 Nicht-Punktdaten 112, von denen erwartet wird, daß sie sich relativ selten ändern, und die für die Anwendungsumgebung 120 durch Benutzung der oben erwähnten Datenabfragen 315 zugänglich sein können. Die Tabelle 405 und darin enthaltene Informationen können auf einem gewählten Betriebsmittel der Backend-Umgebung 100, einem Datenerfassungssystem 215, einem anderen Backenddatensystem 217 oder innerhalb eines Teils der Erfassungsumgebung 120 selbst verankert sein.
In dem dargestellten Beispiel entsprechen die Felder 410 der Tabelle 405 einem NAME-Feld (Kennungs-String) 415, einem ID-Feld (Kennungsnumer) 420, einem HLIMIT-Feld (obere Grenze) 425, einem LLIMIT-Feld (untere Grenze 430, einem EUNIT-Feld (mit Punktdaten assoziierte Einheit) 435 und einem DESC-Feld (informational) 440. Jedes Feld kann je nach Wunsch konfiguriert werden und kann zum Beispiel String-Daten oder numerische Werten (real, integer, usw.) repräsentieren. Jedes der Felder 410 dient zum Charakterisieren oder geben den Kontext für eine gewählte Komponente oder Punktdatenquelle 208 innerhalb des Systems, die überwacht werden soll, und zum Assoziieren bestimmter Attribute mit der Komponente oder Punktdatenquelle 208 in Form von Nicht-Punktdaten 112. Die mit der gewählten Komponente oder Punktdatenquelle 208 assoziierten Attribute können zum Beispiel deskriptive Informationen, Betriebsparameter sowie andere gewünschte Informationen sein.
Zum Beispiel spiegeln die als P100-P102 identifizierten Komponenteneinträge Nicht-Punktdaten- bzw. Attributinformationen wieder, mit denen verschiedene Betriebsparameter für Punktdaten 110 bzw. Punktdatenquellen 208 charakterisiert werden, die mit einer beispielhaften Pumpe assoziiert sind (z.B. Pumpentemperatur, Pumpendruck und Pumpendrehzahl). Zu diesen Informationen können ein gekennzeichneter Name (in dem NAME-Feld gespeichert), eine numerische Kennung (in dem ID-Feld gespeichert), eine obere Betriebsgrenze (in dem HLIMIT-Feld gespeichert), eine untere Betriebsgrenze (in dem LLIMIT-Feld gespeichert), mit aus der Punktdatenquelle 208 erhaltenen Punktdaten 110 assoziierte Einheiten (in den EUNIT-Feld gespeichert) und eine entsprechende kurze Beschreibung der gewählten Komponente (in dem DESC-Feld gespeichert) gehören. Auf die in den Feldern 410 gespeicherten Informationen kann selektiv durch die oben erwähnten Datenabfragen 315 oder durch andere Abrufmechanismen zugegriffen werden, um Etikettattributinformationen bereitzustellen, die nachfolgend mit Punktdaten 110 bezüglich einer spezifischen Komponente oder Punktdatenquelle 208 in der Backend-Datenumgebung 100 assoziiert werden können.
Ähnlich können diese Felder 410 auch in Verbindung mit Punktdaten 110 bzw. Punktdatenquellen 208 verwendet werden, die mit einem beispielhaften Förderband assoziiert sind (z.B. Förderbandgeschwindigkeit und Förderband-Betriebsstatus). Auf das Förderband angewandt, können die Felder 410 verschiedene Werte und Kontext annehmen. Zum Beispiel können Name 415, ID 420, Grenzen 425, 430, Einheiten 435 und Beschreibung 440 so aufgefüllt werden, daß Werte widergespiegelt werden, die für mit dem Förderband assoziierte Punktdatenquelle 208 angemessen sind. Ferner können bestimmte Felder unaufgefüllt gelassen werden, mit einem Vorgabewert assoziiert werden, mit einem Leer- oder Nullwert assoziiert werden oder abhängig von der Beschaffenheit der Punktdaten 110 bzw. Punktdatenquelle 208, womit sie assoziiert sind, auf andere Weise aufgefüllt werden (z.B. Unterschiede der Förderbandgeschwindigkeitsfelder und Förderband-Betriebsstatusfelder). Auf der Basis des obigen versteht sich, daß die Felder 410 der Nicht-Punktdaten- bzw. Attributtabelle 405 so konstruiert werden können, daß im wesentlichen alle Informationen berücksichtigt werden, die mit Punktdatenquellen 208 in dem System assoziiert werden sollen.
Ähnlich können Punktdaten 110 in bezug auf die oben beschriebenen Komponenten auf analoge Weise wie die oben erwähnten Nicht-Punktdaten wie in der Tabelle 406 exemplifiziert separat gespeichert werden. Die Informationen in dieser Tabelle 406 können ein oder mehrere Felder 455 umfassen, darunter ein NAME-Feld (Kennungs-String) 460, ein ID-Feld (Kennungsnummer) 465, und VALUE-Feld (aktueller bzw. Echtzeit-Wert) 470. In einer Hinsicht kann die Punktdaten 110 enthaltende Tabelle 406 nur begrenzte Informationen in bezug auf jede Komponente oder Punktdatenquelle 208 repräsentieren, und es können die entsprechenden deskriptiven Eigenschaften und Attributinformationen, die mit der Nicht-Punktdatentabelle 405 assoziiert sind, fehlen. Die in dieser Tabelle 406 gespeicherten Punktdaten 110 können die aktuellen oder Echtzeit-Werte für jede gewählte Komponente oder Punktdatenquelle 208 repräsentieren, auf die wünschenswerterweise mit relativ hoher Frequenz zugegriffen werden soll, um sicherzustellen, daß sie in der Anwendungsumgebung 120 enthaltenen Informationen aktuell sind. Wie bereits erwähnt, können die in dieser Tabelle 406 enthaltenen Informationen durch Verwendung von Etikettenwertverbindungen 320 erfaßt werden, die so ausgelegt sind, daß gewählte Informationen aus der Tabelle 406 mit einer gewünschten Rate oder Frequenz extrahiert werden.
In einer Hinsicht kann jeder Punktdatenwert für eine gewählte Punktdatenquelle 208 (in dem VALUE-Feld gespeichert) mit entsprechenden Identifikationsinformationen (in dem NAME- und ID-Feld gespeichert) assoziiert werden, mit denen die Punktdaten 110 der Tabelle 406 mit den Nicht-Punktdaten 112 der Tabelle 405 in Beziehung gesetzt werden können. Bei anderen Ausführungsformen können bei den Punktdatenwerten entsprechende Identifikationsinformationen fehlen und sie können nur Rohdatenwerte präsentieren. Falls bei den Punktdaten 110 minimale entsprechende Identifikationsinformationen fehlen oder sie diese besitzen, kann die Anwendungsumgebung 120 die richtigen Abbildungsfunktionalitäten bereitstellen, um die Punktdaten 110 mit den Nicht-Punktdaten 112, die in der Tabelle 405 enthalten sind, zu assoziieren. Zusammengenommen kann mit den beiden Quellen von Punktdaten 110 (aus der Tabelle 406 erfaßt) und Nicht-Punktdaten 112 (aus der Tabelle 405 erfaßt) eine gewählte, in der Anwendungsumgebung 120 definierte Etikettensammlung 310 auffüllen.
Die beispielhafte Etikettensammlung 310, die Etiketten 305 und die Etikettenkomponentenglieder 322, die in 4A gezeigt sind, zeigen die Abbildung von Informationen aus der Punktdaten-Datenbank 406 und Nicht-Punktdaten-Datenbank 405. Wie bereits erwähnt, umfaßt die Etikettensammlung 310 eine Gruppierung von Etiketten oder Etiketteninstanzen 305, die Datenstrukturen repräsentieren, die für die Erfassung und Assoziation von Punktdaten 110 und Nicht-Punktdaten 112 verwendet werden. Bei verschiedenen Ausführungsformen umfaßt die Etikettensammlung 310 Instanzierungen zuvor definierter Etikettenkomponenten, die durch die eine oder mehreren Etiketteninstanzen 305 repräsentiert werden. Jede Etiketteninstanz 305 umfaßt Etikettenkomponentenglieder 322, die weiterhin einen Gliednamen 482 und einen assoziierten Gliedtyp 484 umfassen können. Der Gliedtyp 484 definiert die erwarteten Datentypen der verschiedenen Etikettenkomponentenglieder 322 für jede Etiketteninstanz 305, zum Beispiel als Real- oder String-Werte.
Die Etikettensammlung 310 kann als mehrere Instanzierungen einer singulären Etikettenkomponentendefinition konstruiert werden oder kann mehr als eine Etikettenkomponentendefinition benutzen. Im allgemeinen liefert die Etikettenkomponentendefinition einen logischen Rahmen für das Assoziieren von Punktdaten 110 und Nicht-Punktdaten 112 auf benutzerwählbare bzw. -konfigurierbare Weise. In einer Hinsicht wird die Etikettenkomponentendefinition so konstruiert, daß ihre Verwendung in vielfältigen verschiedenen Kontexten möglich wird, ohne Einschränkung auf eine bestimmte Assoziation von Punktdaten/Nicht-Punktdaten. Bei bestimmten Implementierungen kann eine singuläre Etikettenkomponentendefinition ausreichen, um eine Anzahl verschiedener Assoziationen von Punktdaten und Nicht-Punktdaten durch eine oder mehrere in der Etikettensammlung 310 enthaltene Instanzierungen berücksichtigen.
In einer Hinsicht können Etikettenkomponentenglieder 322 der Etikettensammlung 310 unter Verwendung des oben erwähnten Ansatzes mit Datenabfrage 315 bzw. Etikettenwertverbindung 320 auf gewählte Informationen abgebildet werden, die in der Punktdaten- und der Nicht-Punktdaten-Datenbank 405, 406 enthalten sind. Dies ist auf hoher Ebene in 4A gezeigt, wobei gewählte Informationen, die bestimmte Punktdatenquellen 208 widerspiegeln, die in Feldern 410 der Punktdaten- und Nicht-Punktdaten-Datenbank 405, 406 enthalten sind, auf entsprechende Komponentenglieder 322 abgebildet werden und diese mit den entsprechenden Werten oder Informationen auffüllen.
In einer Hinsicht wird das Auffüllen der Komponentenglieder 322 unter Verwendung des Datenabfrageansatzes durch eine vereinfachte Abfragesprache erleichtert. Die vereinfachte Abfragesprache kann die Form einer Abfrage annehmen, wie zum Beispiel „SELECT NAME, HLIMIT, LLIMIT, EUNIT, DESC FROM TAG TABLE". Die oben erwähnte vereinfachte Abfrage kann durch die Anwendungsumgebung 120 in eine oder mehrere geeignete Datenbankabfragen (z.B. in SQL) übersetzt werden, mit denen man Informationen aus der Nicht-Punktdatentabelle 405 extrahieren kann. Die Form der vereinfachten Abfrage ergibt ein intuitiveres Verständnis der bei der Abbildung der Informationen durchzuführenden Operationen ohne ausführliche Kenntnis der zugrundeliegenden Operationen selbst zu besitzen.
4B zeigt weiter eine beispielhafte Abbildung zwischen der Nicht-Punktdaten-Datenbank 405 und der beispielhaften Etikettensammlung 310, die in 4A gezeigt ist. Die oben erwähnte Abfrage kann teilweise aufgelöst werden, indem die Sprache der Abfrageauflösungs-Feldnamen 410 aus der Nicht-Punktdaten-Datenbank 405 interpretiert und ein mit einem bestimmten Komponentenglied 322 assoziierter Gliedname 482 identifiziert wird. In der Sprache der Abfrage spiegeln: NAME, HLIIMIT, LLIMIT, EUNIT und DESC zum Beispiel Felder der Nicht-Punktdaten-Datenbank 405 wider, die auf entsprechende Gliednamen 482 abgebildet werden können, die mit bestimmten Komponentengliedern 322 für Etiketten 305 innerhalb der Etikettensammlung 310 assoziiert sind. Informationen können somit aus der Nicht-Punktdaten-Datenbank 405 extrahiert und zum Auffüllen der Komponentenglieder 322 TagName, hiLimit, Units and Description des entsprechenden Etiketts 305 verwendet werden.
Das Auffüllen von Punktdaten 110, die häufiger akutalisiert werden können, kann auf ähnliche Weise vor sich gehen, wobei eine Abbildungsfunktionalität verwendet wird, um in der Punktdaten-Datenbank 406 enthaltene Felder 455 mit gewählten Komponentengliedern 322 für entsprechende Etiketten 305 in der Etikettensammlung 310 zu assoziieren. 4C zeigt ein Beispiel für Punktdatenzugriff bzw. -assoziation 485 für ein gewähltes Komponentenglied 322, das mit einem bestimmten Etikett 305 der Etikettensammlung 310 assoziiert ist, das dem „Current Value" 486 entspricht, wofür wünschenswerterweise eine Punktdatenverbindung hergestellt werden kann. Das Etikettenglied „Current Value" 486 kann wünschenswerterweise mit Punktdaten 110 aufgefüllt werden, die aus einem gewählten Backend-Etikettensystem oder einer Punktdatenquelle 208 extrahiert werden, das bzw. die als eine Verbindungsgruppe 488 spezifiziert wird (PHD in diesem Beispiel). Wie bereits erwähnt, können die Punktdateninformationen 110 unter Verwendung einer Etikettenwertverbindung 320 aus Punkttabelle oder 406 erfaßt oder direkt aus der entsprechenden Punktdatenquelle 208 extrahiert bzw. abgetastet werden. In jedem Fall wird auf die entsprechenden Punktdaten 110 wünschenswerterweise aus der spezifizierten Stelle mit einer gewünschten Auffrischrate zugegriffen und sie werden in dem entsprechenden Komponentenglied 322 (Current Value in diesem Beispiel) gespeichert.
Wie oben beschrieben, kann man mit Etikettenwertverbindungen 320 und Datenabfragen 315 gewählte Etikettenkomponentenglieder 322 mit gewünschten Informationen aus Punktdaten- und Nicht-Punktdatenquellen „auffüllen". Bei verschiedenen Ausführungsformen werden Abfrageergebnisse aus Datenabfragen 315 in einer gewählten Etiketteninstanz 305 benutzt, um die Parameter und Informationen, die mit der für das Etikett 305 definierten Etikettenwertverbindung bzw. den für das Etikett 305 definierten Etikettenwertverbindungen assoziiert sind, einzutragen. Ein effizienter Mechanismus zum Implementieren des Abrufens von Datenabfrageinformationen besteht darin, daß eine einzige Abfrage 315 die notwendigen Operationen zum Zurückgeben von mit Nicht-Punktdaten assoziierten Informationen für mehrere Etiketteninstanzen 305 durchführt. Eine solche Konfiguration verbessert die Betriebsmittelausnutzung und verringert das mit dem Ausführen mehrfacher Datenabfragen zur Erzielung ähnlicher Ergebnisse assoziierte Overhead.
Die Etikettenwertverbindungen 320 können auf singuläre Weise mit den Punktdatengliedern 322 dergestalt assoziiert werden, daß eine spezifische Etikettenwertverbindung 320 mit einem gewählten Punktdatenglied 322 einer gewählten Etiketteninstanz 305 assoziiert wird. Hierbei kann die Etikettenwertverbindung 320 zum Definieren einer „Formel" oder eines Mechanismus verwendet werden, wodurch die Nicht-Punktdaten 112 für eine gewählte Etiketteninstanz 305 zusätzlich zu anderen mit der Etikettenwertverbindung 320 assoziierten Konfigurationsinformationen zum Abrufen und Auffüllen der Punktdaten 110 für jedes Etikett 305 verwendet werden.
In einer Hinsicht umfaßt, wie in 4C gezeigt, das Bilden einer Etikettenwertverbindung 320, das Spezifizieren des NAME bzw. der ID 490 des mit der Punktdatentabelle 406 oder Punktdatenquelle 208 assoziierten Etiketts 305, um die zu erfassenden Informationen und das gewünschte Feld bzw. die gewünschten Informationen 492, das extrahiert werden soll bzw. die extrahiert werden sollen (z.B. VALUE) zu identifizieren. Ein vereinfachter Referenzierungsmechanismus zum Assoziieren eines Komponentengliedes 322 zum Speichern extrahierter Punktdaten 110 mit den relevanten, aus der Tabelle 406 oder der Punktdatenquelle 208 zu extrahierenden Punktdaten 110 kann folgendes umfassen: Spezifizieren der Etikettnamen-Kennung (z.B. „%TagName") 490 zusammen mit der Anforderung, eine Verbindung 486 mit einer entsprechenden Verbindungsgruppe (z.B. „PHD") 488 herzustellen, um ein gewähltes Komponentenglied mit Punktdaten 110 aufzufüllen, die dem gewählten Feld (z.B. „VALUE") 492 entsprechen. Hierbei gibt die Etikettennamen-Kennung „%TagName" an, daß die Anforderung zum Auffüllen des Komponentengliedes 322 des Etiketts 305 das Namenfeld (z.B. „TagName") dieses Etiketts in der Laufzeit verwenden und diese Informationen zu der entsprechenden Backend-Datenquelle oder Verbindungsgruppe (z.B. „PHD") 488 weiterleiten wird, wobei die zugeordneten, in dem gewählten Feld (z.B. „VALUE") 492 enthaltenen Informationen ausreichen werden, um den gewünschten Wert, auf den zugegriffen werden soll, eindeutig zu identifizieren.
4D zeigt eine beispielhafte Verbundtabelle oder -sammlung 494 von Punktdaten 110 und Nicht-Punktdaten 112, die gebildet werden kann, indem die oben erwähnten Datenzugriffsprinzipien angewandt werden, um Daten aus der Punktdatentabelle 406 und der Nicht-Punktdatentabelle 405 zu erfassen. Ein wünschenswertes Merkmal der Bildung einer solchen Verbundtabelle oder -sammlung 494 besteht darin, daß jedes Etikett 305 und seine konstituierenden Komponenten 322 als ein unabhängiges Objekt mit dem Nutzen und Anzeigefähigkeiten eines Objekts repräsentiert und verfügbar sein kann. Jedes mit der Verbundtabelle 494 assoziierte Etikett 305 kann somit als ein Objekt repräsentiert werden, das eine beliebige Anzahl von verfügbaren auf klassen basierenden Ansichten zur Anzeige des Inhalts (z.B. Komponentenglieder 322) des Etiketts 305 aufweist. Die Konstruktion und Präsentation von Daten auf diese Weise verbessert deshalb die funktionalen Fähigkeiten eines Datenerfassungssystem, indem das Zusammenführen von Punktdaten 110 und Nicht-Punktdaten 112 in einer einzigen kohärenten Tabelle oder Ansicht ermöglicht wird. Zusätzlich werden die Verbunddaten zugänglicher, indem Mittel zum zweckmäßigen Inbeziehungsetzen von Datentypen bereitgestellt werden, die normalerweise unter Verwendung herkömmlicher Systeme nicht ohne weiteres kombinierbar sind.
Wie aus der oben erwähnten Beschreibung erkennbar wird, können verschiedene Datenerfassungsstrategien (z.B. strukturierte Abfragen bzw. Etikettenwertverbindungen) sowie verschiedene Datenerfassungszeiten bzw. Abrufintervalle implementiert werden, um die verschiedenen Felder (z.B. die Komponentenglieder 322) aufzufüllen, die eines oder mehrere Etiketten 305, die durch die Verbundtabelle 494 beschrieben werden, betreffen. Ein wünschenswerter Vorteil, der durch die Anordnung der Informationen auf eine solche Weise bereitgestellt wird, besteht darin, daß ein Teil oder im wesentlichen die Gesamtheit der Nicht-Punktdaten 112 mit sogar nur einer einzigen strukturierten Abfrage 315 identifiziert und erfaßt werden kann, so daß die rechnerische Last, programmatische Komplexität und Kommunikationsbandbreite signifikant verringert wird.
Bei verschiedenen Ausführungsformen liefert die Verbundtabelle 494, die auf Etiketten basierende Punktdaten 110 und Nicht-Punktdaten 112 umfaßt, wünschenswerterweise einen Mechanismus, durch den auf Etiketten basierende Informationen mit nicht auf Etiketten basierenden Informationen vereinigt werden können. Wie bereits erwähnt, fehlt bei herkömmlichen Systemen die Möglichkeit zur integralen Verwaltung von auf Etiketten basierenden Daten und nicht auf Etiketten basierenden Daten; oder sie sind in dieser Fähigkeit signifikant beschränkt. In einer Hinsicht überwindet das Verbinden von auf Etiketten basierenden Punkt- und Nicht-Punkdaten 110, 112 in der Verbundtabelle 494 diese Beschränkung durch Bereitstellung der auf Etiketten basierenden Daten in der Form bzw. in einem Format, die bzw. das zweckmäßig mit nicht auf Etiketten basierenden Informationen, wie in 4E gezeigt, assoziiert werden kann.
Auf Etiketten basierende Punktdaten und Nicht-Punktdaten in der Verbundtabelle 494 können in einer Form präsentiert bzw. gespeichert werden, die mit anderen herkömmlichen nicht auf Etiketten basierenden Nicht-Punktdatenquellen kompatibel ist. Zum Beispiel können Arbeitsauftragspläne 495 und Wartungsvorgeschichtetabellen bzw. -datensätze 496, die mit nicht auf Etiketten basierenden Backend-Datenquellen bzw. Systemen assoziiert sein können, als Datensätze in herkömmlichen Datenbanken bzw. Anwendungen gespeichert werden. Für Fachleute ist erkennbar, daß in diesen Quellen entstehende Informationen nach Integration in der Verbundtabelle 494 teilweise aufgrund der ähnlichen Struktur oder Organisation der Daten ohne weiteres mit den auf Etiketten basierenden Informationen assoziiert werden können.
Umfangreiche und getrennte Klassen anderer nicht auf Etiketten basierender Datenquellen können mit in der Verbundtabelle 494 enthaltenen auf Etiketten basierenden Informationen integriert werden. Zu solchen Informationen können die gehören, die in Personalressourcendatenbanken 497, Kundenbeziehungsdatenbanken 498 und anderen Quellen von nicht auf Etiketten basierenden Informationen 499 gefunden werden. Es versteht sich, daß vielfältige verschiedene Quellen von nicht auf Etiketten basierenden Nicht-Punktdaten existieren und solche Informationen wünschenswerterweise durch Anwendung der vorliegenden Lehren mit auf Etiketten basierenden Punkt- und Nicht-Punktdaten in Beziehung gesetzt werden können.
Bei verschiedenen Ausführungsformen kontextualisieren die vorliegenden Lehren auf Etiketten basierende Informationen auf eine Weise, die deren Integration mit nicht auf Etiketten basierenden Informationen ermöglicht, ohne daß eine signifikante Modifikation oder Umkonfiguration der nicht auf Etiketten basierenden Informationen erforderlich ist. Folglich kann an auf Etiketten basierenden Informationen und nicht auf Etiketten basierenden Informationen in der Anwendungsumgebung auf verbundene Weise operiert werden, und sie können wünschenswerterweise für eine integrierte Benutzung konfiguriert werden. Ein Aspekt einer solchen Integration ist die Möglichkeit, kombinierte „Ansichten" bereitzustellen, die auf Etiketten basierende und nicht auf Etiketten basierende Informationen innerhalb desselben visuellen Kontexts repräsentieren. Wie später ausführlicher beschrieben wird, wird die Erzeugung solcher Ansichten signifikant durch die Möglichkeit verbessert, auf Etiketten basierende Daten und nicht auf Etiketten basierende Daten auf ähnliche Weise in bezug auf „Ansichts"-Entwurf zu „behandeln". Ferner ermöglichen die vorliegenden Lehren eine Verwendung von auf Etiketten basierenden Daten und nicht auf Etiketten basierenden Daten innerhalb derselben Datenstrukturen, wodurch eine verbesserte, auf klassen basierende Komponentenentwicklung gewährleistet wird.
5A–B zeigen, wie die Etiketten 305 auf hierarchische und/oder objektorientierte (d.h. modellierte) Weise verwendet und als Grundlage für eine Organisation zunehmend komplexer Systeme mit mehreren Gruppierungen von Punktdaten 110 und Nicht-Punktdaten 112, die logische Konstrukte in dem System repräsentieren, dienen können. In einer Hinsicht hat die Verwendung von Etiketten 305 auf die oben erwähnte Weise einen zweckmäßigen Mechanismus bereitgestellt, um eine auf klassen basierende oder objektorientierte Struktur auf ein System zu vermitteln, das viele potentielle Datenquellen aufweist, die überwacht, visualisiert und gruppiert werden sollen. In dem beispielhaften System wird ein Basiskomponenten-Etikett 305 definiert, um das fundamentale Element zu repräsentieren, das gewählte Punktdaten 110 und Nicht-Punktdaten 120 verbindet. Wie zuvor beschrieben, umfaßt das Etikett 305 verschiedene Komponentenglieder 322, mit denen Punktdaten 110 (z.B. Current Value) und Nicht-Punktdaten 112 (z.B. hiLimit, lowLimit, TagName, Units und Description) gespeichert und auf diese zugegriffen werden.
Jedes Komponentenglied 322 kann ferner einen assoziierten Gliednamen 472 und Gliedtyp 484 aufweisen, der Zugänglichkeit und Einschränkungen bezüglich der in dem Komponentenglied 322 enthaltenen Daten umreißt. In einer Hinsicht gibt der Gliedtyp 484 eine Erbeigenschaft, Zusammensetzung, Gruppierung oder Einschränkung an, die mit einer gewählten Komponente 322 assoziiert ist. Zum Beispiel umfassen die Gliedtypen für das Etikett 305 erwartete Formen der Daten mit dem Typ Real 525 (assoziiert mit hiLimit, lowLimit, und Current Value) und mit Typ String 530 (assoziiert mit TagName, Units und Description). Mit dem Gliedtyp können ferner weitere logische Konstruktionen spezifiziert werden, wie zum Beispiel Typ Etikett und Komponenten auf höherer Ebene bzw. Sammlungen, um einen Mechanismus für die auf klassen basierende Modellierung bereitzustellen, wie später ausführlicher beschrieben werden wird.
Eine Pumpenkomponente 535 auf höherer Ebene zeigt, wie man Etiketten 305 bei der Definition anderer logischer Komponenten oder informationaler Gruppierungen verwenden und wiederverwenden kann. Zum Beispiel enthält die beispielhafte Pumpenkomponente 535 Etiketten 305 und instanziiert deshalb diese Etiketten 305, die ein Temperaturassoziiertes Etikett 545 und ein Druckassoziiertes Etikett 550 umfassen. Jedes dieser Etiketten 545, 550 wird durch den Gliedtyp „Tag" 505 angegeben, der seperate Etiketten-Instanzen der beispielhaften Pumpenkomponente umreißt. Diese Art der Komponentendefinition ist sehr effizient, da sie das Basiskomponentenetikett 305 wiederverwendet und eine Bildung von Assoziationen mit diversen und komplexen logischen Gruppen ermöglicht, ohne daß explizit jedes der Komponentenglieder in einer gewählten Gruppe auf höherer Ebene definiert werden muß. Die Assoziation des Temperatur assoziierten Etiketts 545 und des Druckassoziierten Etiketts 550 mit dem Gliedtyp „Tag" 505 ermöglicht somit ein automatisches erben bzw. instanziieren der Eigenschaften und Definitionen für die Etikettenkomponente 505 durch die Temperatur- und Druckkomponentenglieder der Pumpenkomponente 535 unter Verwendung einer einzigen Assoziation.
Bei verschiedenen Ausführungsformen können Komponenten und logische Gruppierungen auf mehrere Weisen definiert werden. In einer Hinsicht kann eine gewählte Komponente dadurch konstruiert werden, daß jede in die Komponentendefinition aufzunehmende Komponentengliedassoziation von Punktdaten 110 und Nicht-Punktdaten 112 angegeben wird. Dieser Ansatz ist nützlich beim Definieren von Etikettenkomponenten auf niedriger Ebene, wobei jedes Komponentenglied 322 in der Etikettenkomponente 305 explizit mit einer Quelle von Punktdaten 110 und Nicht-Punktdaten 112 assoziiert wird. Umgekehrt, kann auch eine Komponentendefinition erzielt werden, wobei existierende Komponenten zum „Aufbauen" neuer Komponenten verwendet werden können, die eine oder mehrere zuvor definierte Komponenten bzw. ein oder mehrere zuvor definierte Etiketten umfassen oder instanziieren, wodurch durch Enthaltung die Eigenschaften dieser zuvor definierten Komponenten ererbt werden. Bei verschiedenen Ausführungsformen liefert die Komponentendefinition gemäß der oben erwähnten Weise einen Mechanismus, durch den existierende Komponenten und Etikettendefinitionen wiederverwendet werden können, um dadurch die Entwicklung von Etikettensammlungen zu ermöglichen, mit denen sehr viele Quellen 112 von Punktdaten 110 und Nicht-Punktdaten modelliert werden können.
In einer Hinsicht ist die Wiederverwendbarkeit von Komponenten besonders nützlich, wenn mehrere Instanzen von Objekten, Einrichtungen, Vorrichtungen usw. definiert werden. Wenn zum Beispiel mehrere Pumpenkomponenteninstanzen definiert werden, ist es nicht notwendig, explizit jedes Komponentenglied aufzuzählen. Statt dessen kann eine gewählte Komponente definiert werden, indem von einer zuvor definierten Komponente oder einem zuvor definiertem Etikett mit den in der Komponentendefinition eingebetteten erforderlichen Komponentengliedern assoziiert oder ererbt wird.
Bei bestimmten Ausführungsformen können Komponentendefinitionen unter Verwendung kombinierter Ansätze konstruiert werden, wobei die Assoziationen von Komponenten, enthaltenden Komponenten und Subkomponenten explizit wie in 5A–B dargestellt definiert werden und alternativ dazu, wobei die Benutzung enthaltener und verwandter Komponenten keine explizite Definition aller dazwischentretenden Komponentenbeziehungen erfordert (z.B. kann auf die mit der Area-Komponente 570 verwandten oder zu dieser gehörenden Etikette zugegriffen werden, indem entweder die explizite Beziehung zwischen jeder Komponente Area 570, Pump 535, Conveyor 555 und Tags 305 definiert wird, oder alternativ dazu, indem eine allgemeine Beziehung vieler zu der Area-Komponente 570 gehörende Etikette 305 definiert und ein Mittel zur entsprechenden Referenzierung eines einzelnen Etiketts 305 je nach Bedarf bereitgestellt wird). Diese Flexibilität- beim Komponentenentwurf erweitert weiter die Möglichkeiten des Entwicklers, zunehmend komplexe Komponenten in dem System mit weniger Mühe zu erzeugen.
Es kann Funktionalität für ein „Maskieren" von Teilen gewählter Komponentendefinitionen bereitgestellt werden, so daß nur die unmaskierten Teile aktiv benutzt oder angezeigt werden. Eine Maske der unnötigen Komponentenglieder einer ersten Komponente, die ein oder mehrere Komponentenglieder aufweist, die nicht für die Konstruktion einer zweiten Komponente erforderlich sind, kann also durchgeführt werden, um nur unmaskierte Komponentenglieder zurückzulassen, die bei der Konstruktion der zweiten Komponente verwendet werden können. Dieser Ansatz vereinfacht die Komponentenkonstruktion und vermeidet Verwirrung, wenn unerwünschte bzw. unnötige Komponentenglieder in aus anderen Komponenten abgeleiteten Komponenten integriert werden.
Wieder mit Bezug auf 5A kann eine Förderbandkomponente 555 definiert werden, die dieselbe oder eine ähnliche strukturelle Definition für ein Etikett 305 wie die Pumpenkomponente 535 wiederverwendet. Die Förderbandkomponente 555 kann diese Etiketten 305 mit verschiedenen Quellen von Punktdaten 110 und Nicht-Punktdaten 112 wie zuvor beschrieben in Beziehung setzen, obwohl jedoch die zugrundeliegenden Komponentenglieder 322 für jedes Etikett 305 ähnliche logische Konstruktionen besitzen. Somit kann ein Definieren eines Geschwindigkeits-Etiketts 560 und eines Betriebsstatus-Etiketts 565 in Assoziation mit der Förderbandkomponente 555 unter Verwendung im wesentlichen derselben Komponenten definition des Etiketts 305 erzielt werden, die bei der Definition der Pumpenkomponentenetikette von Temp 545 und Pressure 550 verwendet wurde.
Unter Verwendung der Komponentendefinitionen für die Pumpenkomponente 535 und die Förderbandkomponente 555 als Grundlage, kann eine Area-Komponente 570 durch eine Einlaßpumpe 572 und eine Auslaßpumpe 574 mit einem Gliedtyp Pumpe 535 definiert werden. Ähnlich kann man eine Förderbandkomponente 576 und eine zweite Förderbandkomponente 578 unter Verwendung des Gliedtyps Förderband 555 definieren. Es versteht sich, daß die Area-Komponente 570 mit einer mäßigen bis großen Anzahl von Komponenten auf hoher Ebene (z.B. Pumpen und Förderbändern und ähnlichen Komponenten mit einer Anzahl von 10 bis 20) und möglicherweise sogar noch größeren Tiefegraden an Komplexität insgesamt (d.h. alle durch die Area-Komponente enthaltenen Etikette und beliebige ihrer Subkomponenten mitgezählt) eine relativ große Anzahl von Etiketten 305 und/oder Komponentengliedern 322 enthalten könnte, die individuell für die Area-Komponente 570 definiert werden müßten. Durch Anwenden eines hierarchischen, auf klassen basierenden Komponentendefinitionsansatzes können die vielen Etiketteninstanzen, die mit einer Area-Komponente 570 assoziiert sind, jedoch ohne weiteres definiert und verwaltet werden, indem Komponentendefinitionen auf höherer Ebene (z.B. Pumpe und Förderband), die ihre eigenen Subkomponenten- und Etikettenassoziationen definieren (im Vergleich zu der expliziten Definition jedes Etikettenkomponentengliedes als unmittelbare Glieder der Area-Komponente 570) integriert werden.
In einer Hinsicht ist die Komponentendefinition auf diese Weise für den Benutzer bzw. Entwickler, der komplexere Komponenten unter Verwendung zuvor definierter Komponenten als „Baublöcke" entwerfen kann, intuitiver. Anstatt jedes Etikett auf niedriger Ebene, das mit einem komplexen System assoziiert ist, identifizieren zu müssen, kann auf der Basis eines Komponentenentwurfs auf hoher Ebene somit eine Repräsentation des modellierten Systems und assoziierter Ansichten konstruiert werden, wobei die entsprechenden Etiketten 305 mittels der zugrundeliegenden Komponentendefinitionen automatisch ererbt bzw. instanziiert werden.
Als Beispiel dafür, wie die Komponentendefinition auf hoher Ebene und Wiederverwendbarkeit arbeitet, kann eine Anlagenkomponente 580 als eine einzige Komponente Area1 585 definiert werden, deren Gliedtyp 520 Area 570 ist. Durch diese relativ simple Komponentendefinition werden automatisch alle zugrundeliegenden Komponenten 570, 555, 535 und Etiketten 305, die mit den verschiedenen Komponenten niedriger Ebene assoziiert sind, automatisch instanziiert, wenn die Anlagenkomponente 580 istanziiert wird, wodurch eine Repräsentation einer komplexen „Anlage" durch die relativ geringen Bemühungen erzeugt wird, die erforderlich sind, um die entsprechenden, mit der Anlagenkomponente 580 assoziierten Komponentenglieder zu definieren.
5B zeigt eine resultierende Komponentenlösung 590 für die Anlagenkomponente 580 auf der Basis der oben beschriebenen Komponenten 580, 570, 555, 535 und Etiketten 305, die mit 5A assoziiert sind. In einer Hinsicht wird die Anlagenlösung 590 in einem Baum bzw. einem hierarchischen Format angezeigt, wodurch die Visualisierung und das Verständnis der Beziehungen und Muster der Ererbung bzw. Instanziierungen für die verschiedenen Komponenten der Lösung 590 erleichtert wird. Wie gezeigt, umfaßt die Anlagenkomponente 580 die Area1-Komponente 585, die weiterhin die Komponenten intakePump 572, outlet Pump 574, conveyor1 576 und conveyor2 578 umfaßt. Die Pumpenkomponenten 572, 574 umfassen weiter die Komponenten temp 545 und pressure 550 und die Förderbandkomponenten 576, 578 umfassen weiterhin die Komponenten speed 560 und operatingStatus 565. Bei jeder der Komponenten temp 545, pressure 550, speed 560, operatingStatus 565 handelt es sich um Etiketten 305 ähnlicher Form, die die zugrundeliegenden Etikettenglieder 322 ererben bzw. instanziieren; hiLimit, lowLimit, CurrentValue, TagName, Units und Description.
5C erweitert die die Verwendung der Etiketten- bzw. Komponentendefinitionen, so daß sie auf Etiketten basierende Informationen sowie nicht auf Etiketten basierende Informationen enthalten. In einer Hinsicht können auf Etiketten basierende Punktdaten und Nicht-Punktdaten auf ähnliche hierarchische und/oder objektorientierte (d.h. modellierte) Weisen, wie oben in 5A–B beschrieben, mit nicht auf Etiketten basierenden Punktdaten kombiniert werden. Zum Beispiel kann die Area-Komponente auf hoher Ebene 570 so konfiguriert werden, daß sie sowohl auf Etiketten basierende Informationen in bezug auf Pumpen- und Förderbandkomponenten 535, 555 sowie nicht auf Etiketten basierende Informationen, wie zum Beispiel die Arbeitsauftragsinformationen 591 und Personalinformationen 593 enthält.
Die Integration von nicht auf Etiketten basierenden Informationen in eine Komponente kann auf ähnliche Weise wie oben beschrieben erreicht werden, wobei der Gliedtyp 520 der Area-Komponente 570 die Komponenten 592, 594 auf niedrigerer Ebene spezifiziert, die nicht auf Etiketten basierende Nicht-Punktdatenrelationen definieren. Zum Beispiel kann die Sammlung WorkOrder 592 verschiedene nicht auf Etiketten basierende Nicht-Punktdatenreferenzen 595 umfassen (z.B. Beschreibung, Dienstnummer, Abteilung, Einreichungsdatum, erwartetes Abschlußdatum usw.), die assoziierte Gliedtypen 596 aufweisen (z.B. string, real, date, usw.). Diese nicht auf Etiketten basierenden Komponenten 592, 594 können auf ähnliche Weise wie auf Etiketten basierende Komponenten verwendet und durch entsprechende Referenzierung und Erfassung von Daten, die mit nicht auf Etiketten basierenden Datenquellen assoziiert sind, wie z.B. die oben erwähnten Arbeitsauftrags-Datenquellen 495, die Wartungsvorgeschichte-Datenquellen 496, die Personalressourcen-Datenbank 497, die Kundenbeziehungs-Datenbank 498 und die anderen nicht auf Etiketten basierenden Datenquellen 499 konfiguriert werden.
Wie die Mechanismen für die auf Etiketten basierende Komponentendefinition liefern die Mechanismen für nicht auf Etiketten basierende Komponentendefinition einen zweckmäßigen Mechanismus zum Übermitteln einer auf klassen basierenden oder objektorientierten Struktur auf ein System mit vielen potentiellen Datenquellen, die überwacht, visualisiert und gruppiert werden sollen. Es wird in Betracht gezogen, daß eine weitere Erweiterung solcher Implementierungen die Entwicklung und Verwendung hybrider Komponenten wäre, die sowohl auf Etiketten basierende Informationen als auch nicht auf Etiketten basierende Informationen enthalten. Zusammengenommen liefern diese verschiedenen Arten der Komponentendefinition hochflexible Verfahren zum Assoziieren von Daten verschiedener Typen bzw. Klassen.
6A–B zeigen Diagramme auf hoher Ebene, die zwei Ansätze unterscheiden, die bei der Erfassung und Assoziation von Punktdaten 110 und Nicht-Punktdaten 112 benutzt werden können. Es versteht sich, daß sich diese Ansätze nicht unbedingt gegenseitig ausschließen und nach Wunsch kombiniert werden können, um verschiedene Funktionalitäten zu erzielen, wie später ausführlicher beschrieben werden wird. Wie bereits beschrieben, kann die Assoziation von Punktdaten 110 und Nicht-Punktdaten 112 aus verschiedenen Quellen bei der Repräsentation logischer und physikalischer Komponenten eines zu überwachenden Systems verwendet werden. Diese Repräsentationen können weiterhin mittels Etiketten- oder Komponentendefinitionen und -zuordnungen ausgedrückt werden.
Wie in 6A gezeigt, kann eine Komponentendefinition 610 zur Repräsentation einer Datenstruktur dienen, die gewählte Punktdaten 110 und Nicht-Punktdaten 112 für eine oder mehrere logische und/oder physikalische Komponenten eines Systems darlegt und gruppiert. Zum Beispiel können Komponentendefinitionen 610 für relativ simple Entitäten auf niedriger Ebene innerhalb eines Systems konzipiert werden, wie zum Beispiel Skalen, Meßgeräte, Meßanzeigen, Zähler usw. Ähnlich können Komponentendefinitionen 610 für Komponenten auf höherer Ebene konzipiert werden, wie z.B. Pumpen, Förderbänder, Gebiete und Anlagen. Komponenten auf höherer Ebene können ferner durch verschiedene Kombinationen und/oder Gruppierungen von Komponenten auf niedrigerer Ebene repräsentiert werden, die durch explizite Referenzen auf die zugrundeliegenden Punktdaten- und Nicht-Punktdatenverbindungen definiert werden (oder Kombinationen davon).
Bei verschiedenen Ausführungsformen kann die Komponentendefinition 610 einer Etikettenrepräsentation 612 entweder mit einem modellierten 614 oder einem Nicht-modellierten Ansatz 616 (oder einer Kombination davon) benutzt werden. Die Wahl, welcher Ansatz verwendet wird, kann von verschiedenen Faktoren abhängen, wie zum Beispiel u.a.: Benutzerpräferenzen, Systemkomplexität, existierende Quellen bzw. Verfügbarkeit von Informationen usw. Zusätzlich kann die Verwendung modellierter oder Nicht-modellierter Ansätze 614, 616 teilweise von dem Typ oder den Eigenschaften der definierten Komponente abhängen. Für bestimmte Komponenten und Konfigurationen kann ein Ansatz vorteilhafte Fähigkeiten und Funktionalität gegenüber dem anderen ergeben und als Folge vorzugsweise benutzt werden. Eine Rechtfertigung für die Bereitstellung eines dualen Ansatzes besteht darin, die Flexibilität und Anpassbarkeit in dem Datensammelsystem zu verbessern, wodurch die Effizienz verbessert wird, mit der gewählte Datenansammlungs-, Datenabruf- und Datenpräsentationsaufgaben durchgeführt werden können.
Bei dem modellierten Ansatz 614 werden Etiketten und Komponenten (die zuvor durch die instanziierten Elemente 305, 535, 555, 570 und 580 exemplifiziert wurden) explizit definiert und mit der gewählten Komponentendefinition 610 assoziiert. Wie in 6B gezeigt, kann also der modellierte Ansatz 614 für die Etikettenrepräsentation 612 für die beispielhaften Komponenten 622, 623 (Komponente A, B) umfassen, eine oder mehrere Etiketteninstanzen (Tag1, Tag2, Tag3 usw.) 305 aufzurufen, die jeweils mit gewählten Punktdaten 110 oder Nicht-Punktdaten 112 in dem System, das die beispielhaften Komponenten 622, 623 betrifft, assoziiert sind.
Bei dem modellierten Ansatz 614 können mehrere Komponenten 622, 623 derselben Kategorie oder Klasse auf der Basis diskreter Instanziierungen der Etiketteninstanzen 305 in der Komponentendefinition 610 definiert werden. In einer Hinsicht können die Etiketteninstanzen 305 mit vordefinierten Nicht-Punktdatenassoziationen (z.B. Vorgabeassoziationen) konfiguriert werden, die jeder Etiketteninstanz 305 gemeinsam sein können. Attribute wie z.B. Einheiten, Bereiche, Grenzwerte usw. können zum Beispiel als Vorgabe bei der Instanziierung des Etiketts 305 erfaßt werden, ohne daß jedes Etikettenkomponentenglied 322 einzeln konfiguriert werden muß. Es versteht sich, daß eine solche Konfiguration dabei hilft, die Notwendigkeit, redundante Nicht-Punktdatenassoziationen, die ansonsten individuell konfiguriert werden müßten, zu beseitigen. Ein solcher Vorteil kann zunehmend signifikant werden, wenn die Größe des zu überwachenden Systems zunimmt.
Zusätzlich zu der Verwendung von Vorgabe-Nicht-Punktdatenassoziationen können die Etikettenkomponentenglieder 322 jeder Etiketteninstanz 305 außerdem je nach Notwendigkeit oder Wunsch individuell konfiguriert werden. Zum Beispiel können für jede Etiketteninstanz 305 Punktdatenassoziationen dergestalt definiert werden, daß eine gewählte Etiketteninstanz 305 mit einer oder mehreren Punktdatenquellen assoziiert werden kann, wodurch die gewählte Etiketteninstanz 305 mit partikularisierten oder relevanten Punktdaten 110 in Beziehung gesetzt wird. Während des Etiketteninstanziierungsprozesses kann also praktisch jeder adressierbare Punkt bzw. jedes adressierbare Attribut in dem System für eine Assoziation mit den gewählten Etikettenkomponentengliedern 322 konfiguriert werden.
Wie bereits beschrieben, besteht ein weiterer Vorteil des modellierten Ansatzes 614 darin, zur Repräsentation von Komponentendefinitionen einen strukturierten oder auf klassen basierenden Entwicklungsmechanismus bereitzustellen. Der auf klassen basierende Ansatz ermöglicht ein „Aufbauen" zunehmend komplexer Komponenten aus anderen, zuvor definierten Komponenten. Ein solcher Ansatz erleichtert die Organisation und Gruppierung von Etiketten 305 und kann zur Bildung logischer Assoziationen zwischen Etiketten 305 und Quellen von Punktdaten bzw. Nicht-Punktdaten verwendet werden. Weiterhin ermöglicht die Modellierung von Komponentendefinitionen 610 die Erzeugung anpaßbarer „Ansichten", die teilweise auf der hierarchischen Ordnung von Etiketten und Komponenten basieren können.
Zusätzliche Informationen, die mit der Implementierung von „Ansichten" in dem Kontext eines Datenerfassungssystems zusammenhängen, sind in der XHQ-Anwendungsdokumentation bzw. -handbüchern zu finden, darunter der XHQ User Guide, der XHQ Administrator Guide und der XHQ Connection Guide. Weitere Einzelheiten finden sich außerdem in den eigenen Patenten und Patentanmeldungen, darunter US-Patentanmeldung, laufende Nummer 10/726,430 mit dem Titel „Modeling system for retrieving and displaying data from multiple sources"; US-Patentanmeldung, laufende Nummer 60/526,891 mit dem Titel „System and Methods for Retrieval, Presentation, and Synchronization of Real-Time Points/Tags within a Class-Based Component and View Model"; US-Patentanmeldung, laufende Nummer 09/704,471 mit dem Titel „System and method for retrieving and presenting data using class-based component and view model"; und US-Patentanmeldung 60/162,975 mit dem Titel „System to Provide Real Time Information Portal Using Class-Based Component and View Model".
Wie bereits erwähnt, können Komponentendefinitionen 610 auch mit dem Nicht-modellierten Ansatz 616 repräsentiert werden. Der Nicht-modellierte Ansatz 616 unterscheidet sich insofern von dem modellierten Ansatz 614, als keine explizite Definition bzw. kein expliziter Aufruf von Instanziierungen von Etiketten für jede Instanz eines Komponentengliedes verwendet werden. Bei dem Nicht-modellierten Ansatz 616 kann statt dessen eine Etikettensammlung 650 definiert werden, die ein oder mehrere Etiketten 305 umfaßt, wobei jedes Etikett Glieder 660 umfaßt, d.h. die Komponentendefinition des Etiketts – äquivalent der Etikettendefinition 305 in 5A, die bei dem modellierten Ansatz verwendet wird. Die Etikettensammlung 650 erhält ihre Etiketten 305 durch die beschriebenen Verfahren, die die Etikettensammlung 310 in 4A erzeugen. Die Etiketten innerhalb der Etikettensammlung 310, 650 werden deshalb nicht komponentenweise (oder etikettenweise) instanziiert, wie bei dem modellierten Ansatz 614. Auf die Etiketten 305 innerhalb der Etikettensammlung 310, 650 kann durch verschiedene Mechanismen zugegriffen bzw. sie können dadurch referenziert werden, wie später ausführlicher beschrieben werden wird. In einer Hinsicht kann der Nicht-modellierte Ansatz 616 zur Entwicklung einer Etikettensammlung 650 verwendet werden, wobei wie bei den Komponentendefinitionen 622, 623 beliebige ihrer Etiketten 305 mit einem Etikettenglied einer modellierten Komponente assoziiert werden können.
Bei bestimmten Implementierungen kann es wünschenswert sein, während der Komponentendefinition 610 den Nicht-modellierten Ansatz 616 zu benutzen, wenn die auf klassen basierende Organisation des modellierten Ansatzes 614 nicht ohne weiteres benötigt oder gewünscht wird. Zum Beispiel kann die Benutzung des Nicht-modellierten Ansatzes 616 für sehr große auf Etiketten basierende Systeme vorzuziehen sein, wenn die wiederverwendbaren Subkomponenten, die die einzelnen Etiketten enthalten würden, an und für sich nicht nützlich sind oder wenn die Anzeige von Etiketten in vielen Ansichten auf einer höheren Ebene, wie zum Beispiel einem Gebiet oder einer Anlage, wichtiger als die Assoziation jedes Etiketts mit einer Komponente niedrigerer Ebene, die jedes Etikett enthält, ist. Bei solchen Systemen kann die Auferlegung eines auf klassen basierenden Organisationsschemas für das Assoziieren von Punktdaten 110 und Nicht-Punktdaten 112 weniger wichtig sein, und eine ausreichende organisatorische Einfachheit und Zugänglichkeit kann durch Verwendung einer Etikettensammlung bewahrt werden. Zusätzlich wird in Betracht gezogen, daß Datenerfassungssysteme entwickelt werden, die einen hybriden Charakter aufweisen, bei dem modellierte und nicht-modellierte Ansätze 614, 616 zusammenverwendet werden, um so die Merkmale und Vorteile beider auszunutzen. Zum Beispiel können verschiedene Komponenten eines Systems sowohl modellierte Etiketteninstanzen als auch nicht-modellierte Etiketten enthalten, die innerhalb von Etikettensammlungen organisiert sind.
In einer Hinsicht umfaßt die Etikettensammlung eine Menge von Etiketten, die mit verschiedenen Punktdaten 210 und Nicht-Punktdaten 212 innerhalb des Systems oder Backend-Datensystems 217, Datenerfassungssystems 215 oder der Punktdatenquelle 208 in der Backend-Umgebung 100 identifiziert und assoziiert werden können. Der nicht-modellierte Ansatz 616 unterscheidet sich dadurch von dem modellierten Ansatz 614, daß eine Repräsentation einer Vielzahl von Etiketten als eine Etikettensammlung ermöglicht wird, die durch die bei der Erzeugung der „verbundenen" Tabelle 494 in 4D beschriebenen Techniken mit Etiketten 305 „aufgefüllt" wird. Diese Etiketten 305 würden andernfalls wie bei dem modellierten Ansatz 715 eine explizite Definition erfordern.
Unter Verwendung der oben erwähnten Ansätze für Etiketten- und Komponentenentwicklung 614, 616 kann ein System entwickelt werden, um Punktdaten 110 und Nicht-Punktdaten auf effiziente, flexible und relativ unkomplizierte Weise zu erfassen. Beispiele für Systeme, die von der Art und Weise der Datenorganisation der vorliegenden Lehren Nutzen ziehen können, sind u.a. Steuersysteme, SCADA-Systeme, Anlagendatengeschichtsschreiber oder andere generische Datenerfassungssysteme, bei denen hauptsächlich ein Überwachen, Sammeln, Steuern und Melden von Etikettendatenquellen erfolgt (d.h. Systeme, die sowohl Punkt- als auch Nicht-Punktaspekte für Etikettendaten enthalten), Punktdatenquellen und Kombinationen von Etikettendatenquellen, Punktdatenquellen und Nicht-Etiketten-Datenquellen, wie z.B. Geschäftsanwendungen, Vielzweckdatenbanken und andere Datenquellen in bezug auf die Führung eines Geschäfts, dessen Beschaffenheit nicht auf Etiketten basiert. Im allgemeinen ermöglichen durch die verschiedenen Ausführungsformen der Erfindung bereitgestellte Lösungen eine Assoziation von genug Attributen und Information mit gewählten Punktdatenquellen und Etikettendatenquellen und liefern Mechanismen für die Speicherung und Verwaltung von Informationen zur Verwendung in Steuer-, Überwachung-, Melde- und anderen Automatisierungssystemen und Geschäftssystemverwendungen.
7A–C und ihre zugeordneten Beschreibungen charakterisieren die oben beschriebenen modellierten und nicht-modellierten Ansätze 614, 616 weiter. In einer Hinsicht kann entweder der modellierte oder der nicht-modellierte Ansatz 614, 616 zum Erstellen einer Datenorganisation, zum Zugreifen auf Lösungen und zum Präsentieren dieser verwendet werden, um ähnliche Ergebnisse zu erzielen. Bei der Entwicklung von Datenvisualisierungen für Etikette bzw. Komponenten für sich oder mit anderen Nicht-Etiketten-Daten, repräsentiert die Bereitstellung der Möglichkeit, den nicht-modellierten und den modellierten Ansatz 614, 616 zu mischen und zu vergleichen, einen signifikanten Vorteil gegenüber herkömmlichen Systemen. Bei verschiedenen Ausführungsformen der vorliegenden Lehren können also die Nutzen und Stärken eines der Ansätze 614, 616 oder beider je nach Wunsch ausgenutzt werden.
Wie bereits besprochen, kann man auf Situationen treffen, bei denen der nicht-modellierte Ansatz 616 gegenüber dem modellierten Ansatz 614 vorteilhafterweise oder wünschenswerterweise implementiert werden kann. Zum Beispiel kann es bei kleineren Systemen oder Systemen mit vielen einzigartigen (nicht redundanten bzw. nicht ähnlich definierten) Komponenten Überlegungen bezüglich verminderter Komplexität und vermindertem administrativem Overhead geben, wenn Erfassungsschemata für Punktdaten 110 und Nicht-Punktdaten 112 entworfen werden. Während komplexe Systeme mit mehreren Komponenten von redundantem oder ähnlichem Charakter von der Implementierung des modellierten Ansatzes 614 durch Aspekte der Komponentenwiederverwendung Nutzen ziehen können, kann die Benutzung des nicht-modellierten Ansatzes 616 in kleineren Systemen, in Systemen mit keinem oder beschränktem Nutzen einer expliziten Modellierung der Nicht-Etiketten-Komponenten des Systems oder in Systemen mit vielen einzigartigen Komponenten im Hinblick auf verringerte organisatorische Komplexität und Leichtigkeit der Entwicklung vergleichbare oder verbesserte Ergebnisse liefern.
Unter Verwendung der zuvor in Verbindung mit 5A–B beschriebenen Etikettenkomponentendefinition 305 zeigt 7A eine beispielhafte Ansicht (z.B. Value-Ansicht) 705, die konstruiert werden kann, um Informationen anzuzeigen, die Punktdaten 110, die aktuelle Werte für ein mit einer beliebigen gegebenen Pumpe assoziiertes einzelnes Etikett repräsentieren, und Nicht-Punktdaten 112, die Einheiten für die Punktdaten 110 in bezug auf die Pumpen (z.B. Einlaßpumpe Auslaßpumpe) in Area1 585 entsprechen, entsprechen.
In einer Hinsicht beschreibt der Ausdruck „Ansicht" eine Visualisierung für gewählte Punktdaten 110 und/oder Nicht-Punktdaten 112, die eine logische oder physikalische Komponente in dem System repräsentiert. Ansichten können konstruiert werden, um Daten und Informationen auf eine Weise zusammenzubringen, die einfacher bzw. leichter interpretiert werden kann. Ansichten können außerdem die Möglichkeit geben, die auf klassen basierende Beschaffenheit oder Organisation von Komponenten innerhalb des Systems zu übermitteln. Bei verschiedenen Implementierungen können Ansichten als wiederverwendbare Elemente konfiguriert werden, um die Anzeige von Informationen für verschiedene Etiketten und Komponenten innerhalb des Systems zu ermöglichen. Der wiederverwendbare Aspekt dieser Ansichten verleiht dem Datenerfassungs- und Überwachungssystem vorteilhafterweise einen Grad an Flexibilität und verringert die Entwicklungszeit bei der Konstruktion mehrerer bzw. komplexer Systemansichten. Es versteht sich, daß die beispielhaften Ansichten und Verfahren zum Konstruieren dieser für eine Verwendung bei der Erzeugung zahlreicher verschiedener Ansichtsrepräsentationen angepaßt werden können und daß folglich die hier beschriebenen beispielhaften Ansichten nicht als den Schutzumfang der Erfindung einschränkend interpretiert werden sollten.
In einer Hinsicht ist die beispielhafte Value-Ansicht 705 so konfiguriert, daß sie die Etikettenkomponentenglieder anzeigt, die CurrentValue 710 und Unit 712 für ein gewähltes Etikett bzw. eine gewählte Etiketteninstanz 305 entsprechen. Es versteht sich, daß eine solche Ansicht 705 in Verbindung mit einer Anwendung verwendet werden könnte, die so konfiguriert ist, daß sie einem Benutzer solche Posten anzeigt. In der nachfolgenden Beschreibung wird die beispielhafte Ansicht 705 im Kontext sowohl des modellierten als auch des nicht-modellierten Ansatzes 614, 616 implementiert.
Die Value-Ansicht 705 umfaßt weiterhin zwei Ansichtselemente 720, 722. Das erste Ansichtselement 720 kann ein Punktdaten-Ansichtselement repräsentieren, an dem der tatsächliche Wert für die Punktdaten 110 (z.B. CurrentValue), der durch die Ansicht 705 referenziert bzw. erfaßt wird, präsentiert wird. Der gezeigte angegebene Wert „1.234" repräsentiert ferner einen Platzhalter für den Punktdatenwert, der mit dem Etikettenkomponentenglied CurrentValue 710 assoziiert ist (z . B. ein Wert des Typs „real") . Es versteht sich, daß sich die in diesem Ansichtselement 720 enthaltenen Informationen in der Laufzeit gemäß den CurrentValue 710 zugeordneten Punktdaten 110 ändern können.
Auf ähnliche Weise kann das zweite Ansichtselement 722 ein Nicht-Punktdatenansichtselement repräsentieren, an dem der tatsächliche Wert für die Nicht-Punktdaten 112 (z.B. Units), der in der Ansicht 705 referenziert bzw. erfaßt wird, repräsentiert wird. Der gezeigte angegebene Wert „ABCD" repräsentiert weiterhin einen Platzhalter für den Nicht-Punktdatenwert, mit dem Etikettenkomponentenglied Units 712 assoziiert ist (z.B. einen Wert des Typs „string"). Wie oben versteht sich, daß sich die in diesem Ansichtselement 722 enthaltenen Informationen in der Laufzeit gemäß den Nicht-Punktdaten 112, die mit dem Etikettenkomponentenglied Units 712 assoziiert sind, ändern können.
Gemäß einer Implementierung des modellierten Ansatzes 614 kann eine Ansicht für eine Komponente auf hoher Ebene (z.B. die Area-Komponente) auf der Basis von Ansichten entwickelt werden, die für Komponenten auf niedriger Ebene oder mittlerer Ebene erzeugt werden, aus denen die Komponente höherer Ebene besteht (z.B. Förderbänder, Pumpen, Etiketten usw.). Die hierarchische oder ererbte Komponentenentwicklung liefert auf diese Weise einen Mechanismus zur Anzeige der Details der Komponenten bzw. Etiketten auf niedriger Ebene und mittlerer Ebene innerhalb der Komponente auf hoher Ebene. In dem dargestellten Beispiel wurde Area1 585 wie in 5B gezeigt instanziiert. Area1 585 repräsentiert deshalb eine Instanz der Komponente Area 570 auf hoher Ebene und umfaßt bzw. enthält modellierte instanziierte Instanzierungen der in der Area-Komponente 570 enthaltenen Komponenten auf niedriger Ebene bzw. mittlerer Ebene und die in jeder dieser Komponenten enthaltenen zugrundeliegenden Komponenten bzw. Etiketten, wie in 5B dargestellt.
Gemäß dem modellierten Ansatz 614 können für jede der Komponenten Ansichten entwickelt werden, um die Informationen anzuzeigen, die mit den Etiketten 305 für die Komponenten niedrigerer Ebene (z.B. Pumpen) assoziiert sind, aus denen die Komponenten höherer Ebene (z.B. Area) bestehen. Die hier angegebenen Beispiele zeigen eine beispielhafte Ansicht für die Pumpenkomponente auf niedrigerer Ebene und die resultierende gewählte Ansicht für die Area-Komponenten hoher Ebene, die so konfiguriert ist, daß die zugeordneten Etikettenwerte angezeigt werden.
Wie in 7B gezeigt, kann eine Pumpenkomponentenwerteansicht 730 für eine Pumpenkomponente entwickelt werden. In der dargestellten Ansicht 730 werden mit gewählten Etiketten assoziierte Punktdaten 110 und Nicht-Punktdaten 112 aus der Pumpenkomponente für eine Anzeige konfiguriert. Also kann eine erste Werteansicht 705 in der Pumpenkomponentenwerteansicht 730 „eingebettet" werden, die das temp-Etikett 545 repräsentiert, und eine zweite Werteansicht 705 kann in die Pumpenkomponentenwerteansicht 730 „eingebettet" werden, die das Druck-Etikett 550 repräsentiert. Das Einbetten der mit jedem der Pumpenkomponentenglieder assoziierten Werteansichten liefert deshalb einen Mechanismus zum Anzeigen von Punktdaten 110 und Nicht-Punktdaten 112, die mit einer beliebigen gegebenen oder gewählten Instanz der Pumpenkomponente 535 assoziiert sind.
Es versteht sich, daß diese Ansicht 730 konfiguriert werden kann, um die Etikettenwerte (Punktdaten 110 bzw. Nicht-Punktdaten 112) für eine oder mehrere gewählte Pumpenkomponenteninstanzen anzuzeigen, für die es gemäß 5B zwei solche Pumpeninstanzen gibt. Obwohl das oben erwähnte Beispiel die Anzeige beider Etiketten der Pumpenkomponente zeigt, versteht sich, daß die Informationen in dieser und anderen Ansichten je nach Wunsch modifiziert bzw. konfiguriert werden können. In einem System mit vielen ähnlichen Komponenten können zum Beispiel gewählte Komponenten für eine Anzeige als Ansammlung oder Gruppe konfiguriert werden. Ähnlich kann die Anzeige der Punktdaten 110 bzw. Nicht-Punktdaten 112 in Verbindung mit jeder Komponente gemäß Benutzerpräferenzen einzeln konfiguriert bzw. angepaßt werden. Zusätzlich können je nach Wunsch verschiedene Konfigurationen von Ansichten (z.B. Werteansichten) ähnlichen Komponententypen zugewiesen werden.
Wie in 7C gezeigt, kann eine Komponente auf hoher Ebene, die einer Area-Komponentenpumpenansicht 740 entspricht, als eine repräsentative Ansicht für die Area-Komponente 570 konzipiert werden. Gemäß dem modellierten Ansatz 614 konstruiert, kann diese Ansicht 740 durch Einschluß einer ersten und einer zweiten Pumpenkomponentenwerteansicht 730, entsprechend der Einlaßpumpe und der Auslaßpumpe der Area-Komponente 570 entwickelt werden. Diese Ansicht 740 zeigt also jede der Pumpen (z.B. die Einlaßpumpe bzw. Auslaßpumpe) innerhalb der Area1-Komponente. In einer Hinsicht können zusätzlich zu dem Einschluß der Pumpenkomponentenwerteansichten 730 zusätzliche Informationen in die Area-Komponentenpumpenansicht 740 aufgenommen werden, wie zum Beispiel Textattribute bzw. Labels 750, mit denen die eingebetteten Pumpenkomponenten voneinander unterschieden werden.
Das Modellieren von Komponenten und Ansichten auf die oben beschriebene Weise liefert einen nützlichen und flexiblen Mechanismus, durch den Beziehungen für die Integration von Punktdaten 110 und Nicht-Punktdaten 112 definiert werden können. Ferner können zunehmend komplexe Komponenten bzw. Ansichten auf der Grundlage von vorheriger Arbeit aufgebaut werden, wodurch redundante Operationen und Aufgaben vermindert werden. Zusätzlich kann gefunden werden, daß sich Komponenten bzw. Ansichten, die im Hinblick auf ihren Inhalt oder ihre Gestalt (Pumpe im Gegensatz zu Förderband) physisch voneinander verschieden sind, einen signifikanten Grad an Gemeinsamkeit teilen (z.B. ähnliche Datensammlungs- bzw. -präsentationsanforderungen), was bei der Komponenten- bzw. Ansichtswiederbenutzung auf die oben beschriebene Weise ausgenutzt werden kann. Wie bereits beschrieben, können ferner Komponenten bzw. Ansichten konfiguriert werden, um Daten selektiv je nach Wunsch auf distinktive Weisen zu erfassen bzw. zu präsentieren bzw. zu kombinieren.
Bei bestimmten Ausführungsformen kann der oben beschriebene modellierte Ansatz 614 implementiert werden, indem eine Verbindung zwischen jedem der Etiketten bzw. der Komponenten (oder genauer gesagt, gewählten Etikettenkomponentengliedern) zu einer entsprechenden Informationsquelle (z.B. Punktdaten aus einer Punktdatenquelle oder Tabelle 406 bzw. Nicht-Punktdaten aus einer Nicht-Punktdatenquelle oder Tabelle 405), die mit der Etikettensammlung assoziiert ist, hergestellt wird. Zum Beispiel kann jedes der Etikettenkomponentenglieder 322, das mit jedem der instanziierten Etiketten assoziiert ist, mit den entsprechenden Backend-Datenquellen zum Beispiel durch entsprechende Kennungen oder Schlüssel 415, 460 verbunden werden. In dem oben beschriebenen Fall für die Area-Komponentenpumpenansicht 740 kann das Konfigurieren der Verbindungen für eine Instanz der Area-Komponente zu einem in der Punktdatentabelle 406 bzw. der Nicht-Punktdatentabelle 405 in der Etikettensammlung gefundenen „Datensatz" durch Verwendung von „Konfigurations"-Sequenzen 760 für jede Etiketteninstanz 305 erreicht werden, die als eine Etikettenwerteansicht 705 repräsentiert wird, die in der Area-Komponentenpumpenansicht 740 enthalten ist (wovon es in dem dargestellten Beispiel vier geben würde). Im Fall des Konfigurierens von Verbindungen für jede als eine Etikettenwert-Ansichtsinstanz 705 repräsentierte Etiketteninstanz 305 können einzelne Etikettenkomponentenglieder 322, mit denen Punktdaten (z.B. CurrentValue) 110 und Nicht-Punktdaten (z.B. Units) 112 erfaßt werden, unter Verwendung von „Konfigurations"-Sequenzen 770 auf ähnliche Weise erzielt werden (von denen es in dem dargestellten Beispiel acht geben würde). Die oben erwähnten Konfigurationssequenzen können Befehlsstrukturen umfassen, die von dem Datenerfassungssystem zum Abrufen der Punktdaten 110 und Nicht-Punktdaten auf ähnliche Weise wie zuvor in Verbindung mit 4A–D beschrieben erkannt werden.
In einer Hinsicht kann eine beispielhafte Konfigurationssequenz für die gewählten Etiketteninstanzen das Verbinden des CurrentValue-Gliedes und des Units-Gliedes für jedes Etikett umfassen. Da die oben erwähnten Glieder die einzigen in diesem Beispiel verwendeten Glieder sind, würden nur diese Glieder konfiguriert. Aus diesem Beispiel versteht sich jedoch, daß man in der Regel jedes der Glieder 322 eines Etiketts 305 konfigurieren könnte.
Eine beispielhafte Sequenz für jedes Glied könnte folgendes umfassen: Spezifizieren eines Backend-Systems oder einer Verbindungsgruppe, die das Backend-System identifiziert, und Spezifizieren des Etiketts in dem Backend-System, zum Beispiel durch Spezifizieren des Etikettennamens oder der Etiketten-ID, der bzw. die das Etikett in diesem System mit dem Etikett in dem Backend-System assoziiert. Danach kann ein interessierendes „Attribut" spezifiziert werden (z.B. Value, Units, HiLimit, usw.). Die Konnektivität zu verschiedenen Backend-Systemen liefert in der Regel einen bestimmten Mechanismus zum Identifizieren, welche Punkt- oder Nicht-Punktdaten für das Etikett gewünscht sind.
In einem Aspekt kann für zunehmend komplexe Komponenten bzw. Ansichten, die unter dem modellierten Ansatz 614 implementiert werden, die Entwicklung der entsprechenden Verbindungen zu Punktdaten 110 und Nicht-Punktdaten 112 durch den Einschluß mehrerer zuvor definierter Komponenten bzw. Ansichten erreicht werden. Der modellierte Ansatz 614 leitet also bestimmte Vorteile aus der auf klassen basierenden Struktur und Organisation ab, wenn Komponenten bzw. Ansichten auf hoher Ebene durch Verwendung von Komponenten bzw. Ansichten auf niedrigerer Ebene, je nach Bedarf mit oder ohne Einschluß zusätzlicher Informationen, repräsentiert werden können.
8 zeigt eine beispielhafte Anwendung des nicht-modellierten Ansatzes 616 bei der Entwicklung einer analogen Area-Pumpenkomponentenansicht 770, die ähnliche Informationen und Struktur wie in Verbindung mit dem obigen modellierten Ansatz 614 beschrieben enthält. Bei dem nicht-modellierten Ansatz 616 ist es nicht notwendig, sich an ein auf klassen basierendes Organisationsschema zu halten und Komponenten und Ansichten auf niedriger und mittlerer Ebene zu definieren. Es ist also nicht unbedingt erforderlich, diskret einzelne Komponenten niedrigerer Ebene, wie zum Beispiel Pumpenglieder der Area-Komponente zu definieren. Statt dessen können mit einer Etikettensanmmlung 650 Relationen für Punktdaten 110 und Nicht-Punktdaten 112 für die Area-Komponente 570 definiert werden. In einer Hinsicht ermöglicht die Verwendung der Etikettensammlung 650 eine zur Verfügungstellung aller Etiketten 305 und der Komponentenglieder 322 der Etiketten für die Area-Komponente 570. In der Etikettensammlung 650 verwendete Etikettenkomponentenglieder 322 können im wesentlichen für die Area-Komponente 570 selbst einzigartig sein oder können über die gesamte Anlage 580 hinweg verwendet werden. Bei Verwendung im Kontext der Area-Komponente 570 alleine versteht sich für Fachleute auf dem Gebiet der Datenbankfiltertechniken, daß ein entsprechendes Filter für die Area-Komponenteninstanzen konzipiert werden kann, das die Verfügbarkeit von Etiketten für die Verwendung in der Area-Komponente 570 entsprechend begrenzt. Zusätzlich versteht sich, daß verschiedene Datenbankauswahltechniken für eine entsprechende Auswahl gewünschter Datensätze bzw.
Posten in der Etikettensammlung oder Datensatzmenge implementiert werden können.
Bei dem nicht-modellierten Ansatz 616 kann die „Assoziation" eingebetteter Ansichten für gewählte Etiketten bzw. Komponenten mit einem „Datensatz" in der Etikettensammlung konstituieren, eine der oben beschriebenen ähnliche entsprechende „Verbindung" zu bilden, um die gewünschten Daten zu der entsprechenden Etiketten- bzw. Komponentenanzeige zu routen. Das Einbetten der Werteansicht der Etikettenkomponente für das Temperaturetikett der Pumpe kann zum Beispiel umfassen, das korrekte Etikett bzw. die korrekte Komponente auszuwählen, indem die Etikettensammlung 650 spezifiziert und das einzelne Etikett 305 „ausgewählt" wird, indem ein Schlüssel bzw. eine eindeutige Kennung 788 innerhalb der Punktdatentabelle 406 oder der Nicht-Punktdatentabelle 405 (siehe 4A–D) spezifiziert wird. Zum Beispiel kann die Erfassung entsprechender Temperaturpunktdaten 110 und Nicht-Punktdaten 112, die mit einer eingebetteten Wertesansicht 790 der Einlaßpumpe 791 assoziiert ist, durch die Etikettenreferenz 790 erhalten werden, die „P100" in der in 4D gezeigten Verbunddatentabelle 494 entspricht. Ähnlich können mit der Etikettenreferenz 788, die „P101" in der Verbunddatentabelle 494 entspricht, Verbindungen konfiguriert werden, um entsprechende Druckpunktdaten 110 und Nicht-Punktdaten 112 für die eingebettete Werteansicht 792 zu erfassen. Die Auslaßpumpe 793 kann ähnlich mit analogen eingebetteten Werteansichten 794, 796, entsprechend Temperatur- und Druckpunktdaten 110 und Nicht-Punktdaten 112, konfiguriert werden (Etiketten und Schlüsselreferenzen für die beispielhafte Auslaßpumpe sind in A-D nicht gezeigt).
Im Fall des nicht-modellierten Ansatzes 616 für die Entwicklung der Area-Komponentenpumpenübersicht 770 kann deshalb die Anzahl von „Konfigurationen", die zur Erzielung eines ähnlichen Ergebnisses wie bei dem modellierten Beispiel verwendet werden, geringer sein (z.B. vier in dem dargestellten Beispiel). Aus dem obigen wird erkennbar, daß der nicht-modellierte Ansatz 616 deshalb wünschenswerterweise in verschiedenen Situationen implementiert werden kann und im Vergleich zu dem modellierten Ansatz 614 weniger Verbindungen bzw. weniger Arbeit erfordert. In solchen Fällen können bestimmte Aspekte der auf klassen basierenden Organisation von Komponenten bzw. Ansichten bewahrt werden, während auf andere im Vergleich zu dem modellierten Ansatz 614 verzichtet wird.
9 zeigt eine beispielhafte Area-Komponentenpumpenansicht 802, die auf Etiketten basierende Daten 805 und nicht auf Etiketten basierende Daten 810 integriert. In einer Hinsicht kann diese beispielhafte Ansicht 802 so konfiguriert werden, daß sie ähnliche Informationen und Struktur wie die oben in Verbindung mit 8 beschrieben enthält, aber weiter erweitert um gewählte nicht auf Etiketten basierende Nicht-Punktdaten, wie zum Beispiel Arbeitsauftragsinformationen 815 und/oder Personalinformationen 820. Verschiedene gewählte Teile der nicht auf Etiketten basierenden Nicht-Punktdaten können in der Ansicht 802 zusammen mit den auf Etiketten basierenden Punktdaten und Nicht-Punktdaten präsentiert werden, wodurch eine Vielzahl verschiedener Anordnungen und Konfigurationen der Datenpräsentation bereitgestellt wird. Es versteht sich, daß das Zugreifen auf die nicht auf Etiketten basierenden Daten 810 und deren Integration auf ähnliche Weise wie für die auf Etiketten basierende Datenerfassung bzw. -präsentation erreicht werden kann, wobei zum Beispiel die in Verbindung mit 5C beschriebenen Komponentendefinitionen verwendet werden. Sowohl der modellierte als auch der nicht-modellierte Ansatz 614, 616 kann in der „Ansichts"-Entwicklung mit den entsprechenden Vorteilen jedes Verfahrens verwendet werden. Wie bei anderen beispielhaften Ansichten versteht sich, daß die dargestellte Ansicht nicht als den Schutzumfang der vorliegenden Lehren einschränkend gedacht ist, sondern statt dessen gewählte Vorteile und Möglichkeiten der integrierten Informationsverwaltungsansätze abbildet.
Kollektiv werden die Funktionalität und Fähigkeiten herkömmlicher auf Etiketten basierender und nicht auf Etiketten basierender Datenerfassungs- bzw. -verwaltungs – bzw. -entwicklungssysteme durch die vorliegenden Lehren signifikant verbessert bzw. erweitert, wodurch Merkmale bereitgestellt werden, die ansonsten bisher aufgrund der Beschränkungen bei der Manipulation von auf Etiketten basierenden und nicht auf Etiketten basierenden Daten sowie von Punkt- und Nicht-Punktdaten nicht verfügbar waren. Obwohl die obige Beschreibung neuartige Merkmale der Erfindung gezeigt, beschrieben und herausgestellt hat, versteht sich, daß Fachleute verschiedene Weglassungen, Substitutionen und Änderungen der Form und Einzelheiten der dargestellten Vorrichtungen sowie ihrer Verwendungen vornehmen können, ohne vom Gedanken der Erfindung abzuweichen.

Claims

Verfahren zum Erzeugen eines Computermodells für das Sammeln und Anzeigen angesammelter Punktdaten und Nicht-Punktdaten, mit den folgenden Schritten: Sammeln von Punktdaten, die Daten umfassen, die von mindestens einer adressierbaren Informationsquelle gesammelt werden, auf der Basis einer spezifizierten Punktdatenerfassungsstrategie; Sammeln von Nicht-Punktdaten, die kontext-definierende Daten umfassen, die mit den Punktdaten assoziiert sind, auf der Basis einer spezifizierten Nicht-Punktdatenerfassungsstrategie; Identifizieren mindestens einer Beziehung, die die Punktdaten und Nicht-Punktdaten assoziiert; und Anzeigen der Punktdaten und Nicht-Punktdaten in einer ersten Ansammlungsansicht.
Verfahren nach Anspruch 1, wobei das Sammeln von Punktdaten und Nicht-Punktdaten unter Verwendung einer ersten wiederverwendbaren Softwarekomponente durchgeführt wird.
Verfahren nach Anspruch 2, wobei eine zweite wiederverwendbare Softwarekomponente weiterhin zusätzlich Punktdaten und Nicht-Punktdaten sammelt, wobei die zweite wiederverwendbare Softwarekomponente die erste Softwarekomponente als ein Glied enthält.
Verfahren nach Anspruch 1, wobei die Identifikation von Punktdaten und Nicht-Punktdatenbeziehungen und deren Anzeige unter Verwendung einer ersten wiederverwendbaren Ansichtskomponente durchgeführt wird.
Verfahren nach Anspruch 4, wobei eine zweite wiederverwendbare Ansichtskomponente weiterhin Beziehungen identifiziert, die die gesammelten Punktdaten und Nicht-Punktdaten assoziieren, und die Punktdaten und Nicht-Punktdaten in einer zweiten Ansammlungsansicht anzeigt, in dem die erste Ansichtskomponente dergestalt eingeschlossen wird, daß wenn ein Benutzer auf die zweite Ansicht zugreift, um durch die zweite Ansichtskomponente gesammelte Daten zu betrachten, die erste Ansammlungsansicht innerhalb der zweiten Ansammlungsansicht angezeigt wird.
Verfahren zum Erzeugen einer Computerrepräsentation, die beim Sammeln angesammelter Punktdaten und Nicht-Punktdaten verwendet wird, mit den folgenden Schritten: Sammeln von Punktdaten, die Daten umfassen, die aus mindestens einer adressierbaren Informationsquelle gesammelt werden; Sammeln von Nicht-Punktdaten, die kontext-definierende Daten umfassen, die mit den Punktdaten assoziiert sind; Identifizieren mindestens einer Beziehung, die die Punktdaten und die Nicht-Punktdaten assoziiert, um so eine Basiskomponente zu definieren; und Definieren einer ersten erweiterten Komponente, die eine Instanzierung der Basiskomponente umfaßt, wobei mindestens ein Teil der Punktdaten und Nicht-Punktdaten der Basiskomponente in der ersten erweiterten Komponente verwendet wird.
Verfahren nach Anspruch 6, wobei die erste erweiterte Komponente zusätzlich zu den durch die Instanzierung der Basiskomponente bereitgestellten weitere Punktdaten und Nicht-Punktdaten umfaßt.
Verfahren nach Anspruch 6, wobei durch Beziehungen, die die Punktdaten und Nicht-Punktdaten assoziieren, mehrere Basiskomponenten definiert werden und wobei die erste erweiterte Komponente Instanzierungen der mehreren Basiskomponenten umfaßt.
Verfahren nach Anspruch 8, wobei die mehreren Basiskomponenten, die in der erweiterten Komponente enthalten sind, wiederverwendbar sind und Subeinheiten der erweiterten Komponente repräsentieren.
Verfahren nach Anspruch 9, weiterhin mit dem folgenden Schritt: Definieren einer zweiten erweiterten Komponente, die eine Instanzierung der ersten erweiterten Komponente umfaßt, wobei mindestens ein Teil der ersten erweiterten Komponente in der Definition der zweiten erweiterten Komponente verwendet wird.
Verfahren nach Anspruch 6, wobei die Basiskomponente ein Etikett mit Komponentengliedern repräsentiert, die durch die mindestens eine die Punktdaten und Nicht-Punktdaten assoziierende Beziehung definiert werden.
Vorrichtung, die ein computerlesbares Medium umfaßt, auf dem Anweisungen gespeichert sind, um eine Sammlung von Daten aus mehreren Quellen zu repräsentieren, und die folgendes bereitstellt: mindestens eine Instanz mindestens einer ersten Komponente, wobei jede Instanz der mindestens einen ersten Komponente Punktdaten und erste Nicht-Punktdaten, die aus mindestens einer auf Etiketten basierenden Informationsquelle gesammelt werden, und zweite Nicht-Punktdaten, die aus mindestens einer nicht auf Etiketten basierenden Informationsquelle gesammelt werden, enthält, wobei die ersten Nicht-Punktdaten kontext-definierende Informationen umfassen, die mit den Punktdaten assoziiert sind, und die zweiten Nicht-Punktdaten Information umfassen, die mit einer Datenverwaltungsanwendung assoziiert sind; und mindestens eine Instanz mindestens einer zweiten Komponente, wobei jede Instanz der mindestens einen zweiten Komponente eine Instanzierung mindestens einer ersten Komponente umfaßt, wobei mindestens ein Teil der Punktdaten und Nicht-Punktdaten der mindestens einen ersten Komponente in jeder Instanz der mindestens einen zweiten Komponente verwendet wird.
Vorrichtung nach Anspruch 12, weiterhin mit einer ersten wiederverwendbaren Ansicht, die spezifiziert, wie durch Instanzen der mindestens einen ersten Komponente und der mindestens einen zweiten Komponente gesammelte Daten angezeigt werden sollen.
Vorrichtung nach Anspruch 13, weiterhin mit einer zweiten wiederverwendbaren Ansicht, die als eine Komponente mindestens einen Teil der ersten Ansicht enthält, wobei die zweite Ansicht durch Instanzen der mindestens einen ersten Komponente und der mindestens einen zweiten Komponente gesammelte Daten in einem der ersten Ansicht entsprechenden Anzeigegebiet anzeigt.
Vorrichtung nach Anspruch 12, wobei die erste Komponente ein Etikett mit Komponentengliedern repräsentiert, die durch die mindestens eine die Punktdaten und die ersten Nicht-Punktdaten assozierende Beziehung definiert werden.
Vorrichtung nach Anspruch 12, wobei die Punktdaten und ersten Nicht-Punktdaten der ersten Komponente in einer Verbundtabelle zusammengeführt werden.
Vorrichtung nach Anspruch 16, wobei die Verbundtabelle eine Form aufweist, die mit den zweiten Nicht-Punktdateninformationen, die mit einer Datenverwaltungsanwendung assoziiert sind, kompatibel ist, so daß die Punktdaten, ersten Nicht-Punktdaten und zweiten Nicht-Punktdaten kollektiv verwendet werden können.
Verfahren zum Verwalten von Informationen, die mit mindestens einem auf Etiketten basierenden System assoziiert sind, mit den folgenden Schritten: Identifizieren mindestens einer mit dem mindestens einen auf Etiketten basierenden System assoziierten Punktdatenquelle, die so konfiguriert ist, daß sie Punktdaten liefert, Identifizieren mindestens eines mit den Punktdaten der mindestens einen Punktdatenquelle assoziierten Nicht-Punktdatenattributs, wobei das mindestens eine Nicht-Punktdatenattribut bei der Entwicklung einer Datenerfassungsregel zum Erfassen von Punktdaten aus der mindestens einen Punktdatenquelle verwendet wird, und Auffüllen einer auf Etiketten basierenden Datenstruktur mit dem mindestens einen Nicht-Punktdatenattribut und erfaßten Punktdaten aus der mindestens einen Punktdatenquelle, wodurch die Punktdaten und Nicht-Punktdaten auf eine Weise integriert werden, die kombinierte Zugänglichkeit bereitstellt.
Verfahren nach Anspruch 18, weiterhin mit dem Schritt des Erzeugens mindestens einer Ansicht, die eine visuelle Repräsentation mindestens eines Teils der Nicht-Punktdaten und Punktdaten in der auf Etiketten basierenden Datenstruktur bereitstellt.
Verfahren nach Anspruch 19, wobei die Datenerfassungsregel einen Mechanismus bereitstellt, durch den auf die Punktdaten aus der mindestens einen Punktdatenquelle zugegriffen werden kann und der weiterhin einen Mechanismus spezifiziert, durch den die auf Etiketten basierende Datenstruktur mit den erfaßten Punktdaten aufgefüllt werden kann.
Verfahren nach Anspruch 19, wobei die auf Etiketten basierende Datenstruktur so konfiguriert ist, daß es möglich wird, die Punktdaten und Nicht-Punktdaten mit anderen Informationen in Beziehung zu setzen, die in den nicht auf Etiketten basierenden Nicht-Punktdatenstrukturen enthalten sind.