DE10206903A1

DE10206903A1 - Softwareapplikation, Softwarearchitektur und Verfahren zur Erstellung von Softwareapplikationen, insbesondere für MES-Systeme

Info

Publication number: DE10206903A1
Application number: DE10206903A
Authority: DE
Inventors: Elmar Thurner
Original assignee: Siemens Corp
Current assignee: Siemens Corp
Priority date: 2002-02-19
Filing date: 2002-02-19
Publication date: 2003-09-04
Also published as: CN1717655A; WO2003071417A2; CN100397342C; EP1516250A2; WO2003071417A3; US7581226B2; US20050160412A1

Abstract

Objekte (mit Daten, Attributen, Verhalten, Funktionen) für Softwareapplikationen, insbesondere MES-Applikationen, werden mit Metainformationen verknüpft, als hierarchische Bäume (OB1, OB2) strukturiert (wobei unterschiedliche Darstellungsformen wählbar sind) und miteinander verzeigert bzw. vernetzt (lateral und/oder horizontal). Zur Laufzeit werden die Objektte (K1-K4, K1'-K4') zu Softwareapplikationen zusammengesetzt, wobei sich die Gesamtfunktion der Softwareapplikationen aus der Struktur der hierarchischen Bäume (OB1, OB2) ableitet. Es können Softwareapplikationen für MES-Systeme, für Automatisierungssysteme, für industrielle Steuerungen (auch Bewegungssteuerungen) und für Büroanwendungen (Officebereich) erstellt werden.

Description

Beschreibung

Die Erfindung betrifft Softwareapplikationen, insbesondere MES-Applikation, mit Objekten, die Daten und/oder Attribute und/oder Verhalten beinhalten und/oder referenzieren, wobei die Objekte auf mindestens einer Rechnereinheit ablaufen und/oder gespeichert sind.
Des Weiteren betrifft die Erfindung eine Softwarearchitektur, insbesondere für MES-Applikationen, und ein Verfahren zur Erstellung von Softwareapplikationen, insbesondere für MES- Systeme.
Ferner betrifft die Erfindung eine Softwareentwicklungsumgebung, ein Computerprogramm, einen Datenträger und eine Datenverarbeitungseinrichtung.
Aus "Software für die Automatisierung-Transparenz über die Abläufe schaffen", Artikel von Dirk Kozian in Elektronik für die Automatisierung 11, 17.11.1999 ist bekannt, für die Automatisierung von Produktions- bzw. Fertigungsabläufen so genannte Manufacturing Execution Systems (MES) einzusetzen. Diese Systeme integrieren die Automatisierungsebene (Controls) mit den ERP-Systemen (ERP: Enterprise Resource Planning) der Unternehmensleitebene. Manufacturing Execution Systems sind Systeme, die z. B. Informationen zur Optimierung von Produktionsabläufen bereitstellen bzw. die Koordination oder Optimierung der Produktionsabläufe durchführen. Zum einen müssen die Manufacturing Execution Systems die groben Planungsdaten der ERP-Systeme um anlagenspezifische und aktuelle Feinplanungsdaten ergänzen und diese entsprechend an die unterlagerte Automatisierungsebene weiterleiten, zum anderen haben sie die Aufgabe, aus der Automatisierungsebene produktionsrelevante Informationen zu übernehmen, diese aufzubereiten und an die Unternehmensleitebene weiterzumelden. MES- Systeme erfüllen somit u. a. die Aufgabe einer vertikalen Integration zwischen der Unternehmensleitebene und der Automatisierungsebene. Typische Einzelaufgaben von MES-Systemen sind Enterprise Asset Management, Maintenance Management, Information Management, Scheduling, Dispatching und Trace & Tracking. Diese Aufgaben werden jeweils von MES-Komponenten bzw. MES-Applikationen ausgeführt.
In den klassischen Programmiersprachen (z. B. Pascal oder Fortran), die in den 80er Jahren für die Softwareerstellung verwendet wurden, waren Daten und Funktionen getrennt. Erst im Zuge des Paradigmas der Objektorientierung wurden Daten und Funktionen zu Objekten zusammengeführt. Innerhalb der 90er Jahre wurden vereinzelt und ansatzweise Metadaten den Objekten zugeordnet. Metadaten sind Informationen über andere Informationen, z. B. Informationen über vorhandene Objekte selbst. Diese Metadaten sind zwar im Gesamtsystem bzw. im Gesamtkontext vorhanden, sie sind aber weder physikalisch in einem Objekt hinterlegt, noch enthalten sie Wissen über die zu realisierende Applikation oder über den zu realisierenden Geschäftsprozess.
Von D. E. Perry und A. A. Wolf wurde in "Foundations for the study of Software Architecture", ACM SIGSOFT, Software Engineering Notes, Vol. 17, No. 4. Pp. 40-52, October 1992, der Begriff "architectural style" eingeführt. Darin wird u. a. auf die Konsequenzen und Einflüsse einer Architektur auf eine auf die Architektur basierenden Applikation hingewiesen. Es ist aber nicht beschrieben, wie durch den gezielten Einsatz von Metainformationen in einer Softwarearchitektur Vorteile hinsichtlich der Erstellung, der Konfigurierung, der Reorganisation oder der Änderbarkeit von Softwareapplikationen erreicht werden.
Aufgabe der Erfindung ist es Softwareapplikationen, eine Softwarearchitektur und ein Verfahren zur Erstellung von Softwareapplikationen zur Verfügung zu stellen, das die Änderbarkeit und Erweiterbarkeit von Systemen verbessert.
Gemäß der Erfindung wird die oben genannte Aufgabe für eine Softwareapplikation durch die Merkmale des Anspruchs 1 gelöst. Die einem Objekt zugeordneten Metainformationen beschreiben z. B. welche Daten und Funktionen ein Objekt enthält, Metainformationen können aber auch Beschreibungen zur Implementierung- und Bedienung beinhalten oder eine Benutzerdokumentation umfassen. In Auszeichnungssprachen wie HTML oder XML können Metainformationen über sogenannte Tags oder über Attribute beschrieben und den Objekten zugeordnet werden. Metainformationen können auch mit einer hierarchischen Struktur versehen werden. Ein Vorteil der Erfindung liegt darin, dass keine explizite Code-Erzeugung nötig ist, um eine Softwareapplikation ablaufen zu lassen. Die Objekte sind Black Boxes mit entsprechenden Zugriffsmechanismen zum Lesen der Metadaten. Aus der Struktur des Baumes und seiner Vernetzung wird die Ablauflogik und die Ablaufreihenfolge der durch den Baum repräsentierten Softwareapplikation festgelegt. Die zur Laufzeit manuell oder automatisch änderbare Struktur des Baumes und die Vernetzung der Baumelemente bestimmt, mit welchen Operanden Funktionen versorgt werden und ob Funktionen sequentiell oder parallel ausgeführt werden. Bei industriellen Anlagen wird durch die Struktur des Baumes und die Vernetzung der Baumelemente z. B. bestimmt, mit welchen Eingabegrößen Geräte versorgt werden und wie die vom Gerät erzeugten Ausgabewerte weiterverarbeitet werden. An einer Softwareentwicklungsumgebung wird von einem Benutzer der Baum und die Vernetzung grafisch editiert. Die Darstellungsform der Bäume kann unterschiedlich sein und vom Benutzer frei bzw. anwendungsspezifisch gewählt werden. Die Vernetzung oder Verzeigerung der Baumelemente kann durch die hierarchische Anordnung im Baum erfolgen. Vernetzungen oder Verzeigerungen der Baumelemente können aber auch durch vom Anwender editierte Referenzierungen oder laterale Vernetzungen zu Elementen anderer Teilbäume erfolgen. Die Eingaben zur Erstellung des Baumes und zur Etablierung von Vernetzungen kann über Eingabemasken, Drag&Drop-Mechanismen oder über Spracheingabe erfolgen.
Den einzelnen Objekten ist ihre Implementierung, d. h. ihr Code und Metainformation zugeordnet. Dadurch, dass die Softwareapplikation zur Laufzeit aus vorgefertigten Objekten zusammengesetzt wird (z. B. automatisch anhand der Metadaten über den Anwendungsprozess) kann auf eine explizite Kompilierphase zur Erzeugung des Codes der zu erstellenden Softwareapplikation verzichtet werden. Kompilierläufe können sehr lange dauern. Dadurch, dass explizite Kompilierläufe nicht benötigt werden, wird die Zeit zur Erstellung der Softwareapplikation, des Testens und der Inbetriebnahme minimiert.
Ein weiterer wesentlicher Vorteil liegt darin, daß Programme und Daten einheitlich behandelt werden. Daten sind Objektbäume ohne Funktionen, Programme sind Objektbäume mit Funktionen. Alle in einem Runtimesystem vorhandenen Mechanismen zum Zusammensetzen, Vernetzen, Versionieren, Speichern, Transportieren etc. von Daten und Programmen müssen nur einmal implementiert werden und nicht je einmal für Daten und für Programme. Dies erleichtert auch die Handhabung für Softwareentwickler, Inbetriebsetzer und Administratoren da sie sich nur einmal in diese Mechanismen einarbeiten müssen.
Ein weiterer Vorteil liegt darin, dass Änderungen sehr leicht durchführbar sind. Teilbäume können jederzeit hinzugefügt, geändert oder entfernt werden, ohne dass die gesamte Baumstruktur geändert werden muss. Die Agilität eines Unternehmens wird dadurch erhöht, da auf veränderte Marktbedürfnisse schneller reagiert werden kann. Dies ist insbesondere dann wichtig, wenn die Softwareapplikationen für die Steuerung von Automatisierungssystemen, Produktionsanlagen oder MES- Systemen eingesetzt wird. Die erfindungsgemäßen Softwareapplikationen können aber auch im Bürobereich (Officebereich) vorteilhaft eingesetzt werden.
Die Vernetzung, Verzeigerung oder Referenzierung zwischen den Objekten kann in einer unterschiedlichen Granularität stattfinden. So kann eine Vernetzung z. B. durch den Verweis auf physikalische Adressen (durch Zeiger bzw. Pointer) erfolgen, wodurch eine hohe Effizienz (z. B. innerhalb des Ablaufs eines Prozesses) erreicht wird. Andere Vernetzungsmechanismen sind z. B. elektronische Nachrichten (z. B. E-Mail), Telefon oder Fax. Je nach Anforderung der zugrundeliegenden Applikation kann vom Anwender ein entsprechender Vernetzungsmechanismus gewählt werden.
Objekte im Sinne der Erfindung sind solche Objekte, die bei der Erstellung der Softwareapplikation verwendet werden, aber auch Laufzeit-Objekte. Laufzeit-Objekte sind Objekte, die zur Laufzeit eines Systems (z. B. einer Applikation) die Logik des Systems ausführen.
Die erfindungsgemäßen Softwareapplikationen eignen sich weiterhin für Lösungen für Prozessleitsysteme und Fertigungsautomatisierungssysteme.
Eine erste vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass zur Laufzeit die Objekte und/oder Referenzierungsmechanismen und/oder Vernetzungsmechanismen und/oder Implementierungen der Objekte austauschbar sind. Dadurch, dass zur Laufzeit Objekte durch andere Objekte, z. B. durch Objekte mit erweiterter Funktionalität oder die Implementierungen von Objekten (z. B. die neuen Implementierungen sind fehlerbereinigt oder haben eine bessere Performance) oder Referenzierungs- und Vernetzungsmechanismen ausgetauscht werden können, wird die Turnaround-Zeit bei Änderungen deutlich reduziert. Dadurch wird die Flexibilität für den Anwender und den Betreiber einer Anlage erhöht und die Agilität eines Unternehmens erhöht. Für die Auswertung der Metadaten wird kein üblicher Compiler verwendet, sondern ein so genannter inkrementeller Compiler oder ein Interpreter, der nur zum Zeitpunkt des Austauschens objektlokal aktiv ist. Für das neu eingesetzte Objekt, wird, wenn nötig inkrementell Code erzeugt und der inkrementelle Compiler oder Interpreter fügt das neu eingesetzte Objekt (bzw. den Referenzierungsmechanismus und/oder Vernetzungsmechanismus und/oder eine neue Implementierung von Objekten) zur Laufzeit in den Baum wieder ein, ohne andere (nicht betroffene) Teile des Baumes berücksichtigen zu müssen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass den Objekten zur Laufzeit Dienste hinzufügbar sind. Die Dienste verwenden die objektlokalen Metadaten um (MES-, bzw. Control- Infrastrukturfunktionen generisch zur Verfügung zu stellen. Solche Dienste können z. B. sein: Serialisierung, Replikation, Verschlüsselung oder Zugriffsschutz. Die Objekte können dadurch mit sogenannten "Quality of Services" ausgestattet werden. Ein Benutzer eines Objektes kann sich auf die Ausführung dieser Dienste verlassen und von ihrer Realisierung abstrahieren.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass Implementierungen der Referenzierungsmechanismen oder der Vernetzungsmechanismen oder der Dienste für Daten und für Programme anwendbar sind. Die Mechanismen und die Dienste müssen somit nicht jeweils für Daten und für Programme separat implementiert werden. Weiterhin können Metainformationen allen Objekten (egal, ob es sich um Daten oder Programme handelt) in gleicher Weise zugefügt werden und es kann in gleicher Weise bei allen Objekten auf die Metainformationen zugegriffen werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass die Objekte statisch und/oder dynamisch vernetzt sind. Vernetzungen (bzw. Verzeigerungen oder Referenzierungen) können statisch bei einer manuellen Erstellung des Baumes erfolgen, aber auch automatisch aufgrund von aktuellen Informationen oder Metainformationen erstellt werden (z. B. bei Bedarf). Dadurch wird die Flexibilität für einen Anwender erhöht. Vernetzungen können über unterschiedliche Mechanismen und Implementierungen eingerichtet werden: z. B. Zeiger auf Objekte, E-Mail an Objekte oder Vernetzung über OPC-Protokolle (OPC steht für OLE for Process Control). Insbesondere im industriellen Umfeld werden OPC-Protokolle häufig verwendet. Weitere Techniken bzw. Implementierungen die für Vernetzungen oder für Verknüpfungen einsetzbar sind, sind z. B. MSMQ (Microsoft Message Queue), HTTP (Hypertext Transfer Protocol) oder SOAP (Simple Object Transfer Protocol).
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass die Objekte die Metainformation physikalisch enthalten. Dadurch wird bei der Erstellung der Softwareapplikation das Prinzip der Lokalität unterstützt, d. h. alle Informationen (auch die Metainformationen), die für ein Objekt wichtig sind, sind auch physikalisch am Objekt vorhanden. Der Zugriff auf diese Informationen wird dadurch erleichtert. Dadurch, dass die Objekte die Metainformationen physikalisch enthalten, kann auch ein Objekt für sich alleine zur Organisation, Reorganisation oder Rekonfigurierung der Softwareapplikation verwendet werden, in Abhängigkeit davon, welche Metainformationen (Typus und Umfang) im Objekt vorhanden sind. Dies ist insbesondere für mobile Objekte von Vorteil, z. B. für Softwareagenten die sich im Internet (oder anderen vernetzten Systemen wie z. B. Intranet) von Rechner zu Rechner bewegen um z. B. jeweils rechnerlokal hochperformant Anlageninformation z. B. für ein Maintenancesystem zu sammeln.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass die Metainformation statische und/oder dynamische Objektmodelle beinhaltet. Solche Objektmodelle sind z. B. Klassen und deren Beziehungen, State/Event-Modelle, Activity-Modelle, Deployment-Modelle oder Domain-Modelle (z. B. MES Prozessmodell in spezifischen Branchen wie z. B. Automobilherstellung, Düngemittelproduktion). Dies ist insbesondere für die generische Softwareentwicklung bzw. für Softwaregeneratoren von Vorteil.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass die Metainformation eine Applikation oder einen Geschäftsprozess beschreibt. Wenn die Metainformation nicht nur Informationen über das Objekt selbst, sondern auch Informationen über die gesamte Softwareapplikation, über die Einsatzumgebung oder über den zu realisierenden Geschäftsprozess (bzw. Business Logik) beinhaltet, dann wird dadurch die Konfigurierung der Softwareapplikation vereinfacht, bis dahin, dass eine Konfigurierung automatisch erfolgen kann. Auch Rekonfigurierungen (z. B. nach Systemabstürzen oder Ausfall von Teilen des Systems) können ohne menschlichen Eingriff automatisch erfolgen. Dadurch wird die Agilität eines Unternehmens und die Verfügbarkeit der Produktionsanlage erhöht.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass jedes einzelne Objekt die gesamte Metainformation über die Applikation oder den Geschäftsprozess beinhaltet. Das bedeutet, dass in einer Softwareapplikation bzw. in einem Softwaresystem in jedem einzelnen Objekt (z. B. im allerkleinsten Tag, in jeder Variable oder in jedem Operator, d. h. auch in den ganz fein granularen Objekten) die gesamte Beschreibung der Applikation oder auch eines Geschäftsprozesses enthalten ist. Durch diese Informationen kann jedes einzelne Objekt zu einer Reorganisation, aber auch Selbstorganisation der Applikation, des Systems oder des Geschäftsprozesses verwendet werden. Dies ist z. B. bei Systemfehlern sehr vorteilhaft wenn große Teile des Systems ausfallen. Das System kann sich aus dem kleinsten noch funktionsfähigen Teil selbst vollständig regenerieren. Ein Wartungsingenieur muss sich somit nicht aufwendig mit dem Beschaffen und Lesen von Dokumentationen beschäftigen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass auf einer Anzeigevorrichtung die Bäume in unterschiedlichen Ansichten darstellbar sind. Die Darstellung der Bäume kann unterschiedlich sein, z. B. durch eine statische Explorer ähnliche Notation oder in Form von Workflow- bzw. Ablaufdiagrammen (Flowcharts, Activitydiagramme) oder z. B. in Form von Blockschaltbildern (z. B. Stromlaufpläne) oder Anlagenplänen (z. B. physikalisches Anlagenlayout, Materialflusspläne). Dadurch wird die Flexibilität für einen Anwender sehr erhöht, denn er kann eine seinem Wissensstand adäquate Notation bzw. Visualisierung auswählen, um die im Laufzeitsystem vorhandene Metainformation einzusehen. Es kann auch zwischen den Darstellungsformen gewechselt werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwareapplikation liegt darin, dass im Fehlerfall die Softwareapplikation sich selbst rekonfiguriert. Wenn in einer Softwareapplikation bzw. in einem Softwaresystem in jedem einzelnen Objekt (z. B. im allerkleinsten Tag, in jeder Variable oder in jedem Operator, d. h. auch in den ganz fein granularen Objekten) die gesamte Beschreibung der Applikation oder auch eines Geschäftsprozesses enthalten ist, können diese Informationen zu einer automatischen Reorganisation, d. h. Selbstheilung der Applikation, des Systems oder des Geschäftsprozesses verwendet werden. Benutzereingriffe sind nicht mehr erforderlich und die Stillstandzeiten werden minimiert. Ein Wartungsingenieur muss sich somit nicht aufwendig mit dem Beschaffen und Lesen von Dokumentationen beschäftigen.
Gemäß der Erfindung wird die oben genannte Aufgabe für eine Softwarearchitektur durch die Merkmale des Anspruchs 12 gelöst. Eine Softwarearchitektur ist eine Beschreibung von Subsystemen, Komponenten (Subsysteme und Komponenten werden durch Objekte unterschiedlicher Granularität repräsentiert) und der Beziehungen zwischen ihnen. Subsysteme und Komponenten werden typischerweise in unterschiedlichen Betrachtungsweisen (Views) spezifiziert und stellen funktionelle und nicht-funktionelle Eigenschaften für eine auf einer Softwarearchitektur basierenden Softwareapplikation dar. Eine Softwarearchitektur soll als vorteilhaft erkannte Softwareentwurfsprinzipien (Lokalitätsprinzip, enge Bindung, lose Kopplung etc.) manifestieren. Eine Softwarearchitektur muss unterschiedliche Aspekte, die für ein Softwaresystem bzw. eine Softwarearchitektur von Bedeutung sind berücksichtigen: Struktur, Funktion, Daten, Verhalten, Dynamik, nicht funktionale Eigenschaften. Diese Aspekte können durch teilweise unterschiedliche Beschreibungsmittel oder Darstellungsformen modelliert werden. Geeignetes Beschreibungsmittel ist z. B. UML (Unified Modeling Language) mit einer Menge von unterschiedlichen Diagrammtypen und Beschreibungstechniken. Die Komponenten, die in einer Softwarearchitektur verwendet werden, können z. B. unterschieden werden in: Datenelemente (Data Elements, die Informationen beinhalten), Verarbeitungselemente (Processing Elements, die die Datenelemente verarbeiten bzw. transformieren) und Verbindungselemente (Connecting Elements, die die beiden anderen Komponenttypen miteinander bzw. untereinander verbinden).
All die Beschreibungsmittel und Darstellungsformen repräsentieren Metainformationen die gemäß der dargestellten Erfindung zur Laufzeit in den Objekten des Laufzeitsystems vorhanden sind, bzw. und zur Laufzeit objektlokal verwendet werden können.
Durch die explizite und gezielte Verwendung von Metainformationen in der einer Softwareapplikation zugrundeliegenden Softwarearchitektur werden durch die vorliegende Erfindung insbesondere die nicht funktionalen Eigenschaften (nonfunctional properties) von Softwareapplikation positiv beeinflusst, wie Änderbarkeit, Effizienz, Zuverlässigkeit, Testbarkeit, Wiederverwendbarkeit, Wartbarkeit, Rekonfigurierbarkeit und Selbstreorganisation z. B. im Fehlerfall.
Die einem Objekt zugeordneten Metainformationen beschreiben z. B. welche Daten und Funktionen ein Objekt enthält, Metainformationen können aber auch Implementierungs- und Bedieninformationen beinhalten oder eine Benutzerdokumentation umfassen. In Auszeichnungssprachen wie HTML oder XML können Metainformationen über sogenannte Tags oder über Attribute beschrieben und den Objekten zugeordnet werden. Metainformationen können auch mit einer hierarchischen Struktur versehen werden. Ein Vorteil der Erfindung liegt darin, dass keine explizite Code-Erzeugung nötig ist, um eine Softwareapplikation ablaufen zu lassen. Die Objekte sind Black Boxes mit entsprechenden Zugriffsmechanismen zum Lesen der Metadaten. Aus der Struktur des Baumes und seiner Vernetzung wird die Ablauflogik und die Ablaufreihenfolge der durch den Baum repräsentierten Softwareapplikation festgelegt. Die Struktur des Baumes und die Vernetzung der Baumelemente bestimmt, mit welchen Operanden Funktionen versorgt werden und ob Funktionen sequentiell oder parallel ausgeführt werden. Bei industriellen Anlagen wird durch die Struktur des Baumes und die Vernetzung der Baumelemente z. B. bestimmt, mit welchen Eingabegrößen Geräte versorgt werden und wie die vom Gerät erzeugten Ausgabewerte weiterverarbeitet werden. An einer Softwareentwicklungsumgebung wird von einem Benutzer der Baum und die Vernetzung grafisch editiert. Die Darstellungsform der Bäume kann unterschiedlich sein und vom Benutzer frei bzw. anwendungsspezifisch gewählt werden. Die Vernetzung oder Verzeigerung der Baumelemente kann durch die hierarchische Anordnung im Baum erfolgen. Vernetzungen oder Verzeigerungen der Baumelemente können aber auch durch vom Anwender editierte Referenzierungen oder laterale Vernetzungen zu Elementen anderer Teilbäume erfolgen. Die Eingaben zur Erstellung des Baumes und zur Etablierung von Vernetzungen kann über Eingabemasken, Drag&Drop-Mechanismen oder über Spracheingabe erfolgen.
Den einzelnen Objekten ist ihre Implementierung, d. h. ihr Code sowie Metainformation zugeordnet. Dadurch, dass die Softwareapplikation zur Laufzeit aus den Objekten zusammengesetzt wird (z. B. automatisch anhand der Metadaten über den Anwendungsprozess), kann auf eine explizite Kompilierphase zur Erzeugung des Codes der zu erstellenden Softwareapplikation verzichtet werden. Kompilierläufe können sehr lange dauern. Dadurch, dass explizite Kompilierläufe nicht benötigt werden, wird die Zeit zur Erstellung der Softwareapplikation, des Testens und der Inbetriebnahme minimiert.
Ein weiterer wesentlicher Vorteil liegt darin, daß Programme und Daten einheitlich behandelt werden. Daten sind Objektbäume ohne Funktionen, Programme sind Objektbäume mit Funktionen. Alle in einem Runtimesystem vorhandenen Mechanismen zum Zusammensetzen, Vernetzen Versionieren, Speichern, Transportieren etc. von Daten und Programmen müssen nur einmal implementiert werden und nicht je einmal für Daten und für Programme. Dies erleichtert auch die Handhabung für Softwareentwickler, Inbetriebsetzer und Administratoren da sie sich nur einmal in diese Mechanismen einarbeiten müssen.
Ein weiterer Vorteil liegt darin, dass Änderungen sehr leicht durchführbar sind. Teilbäume können hinzugefügt, geändert oder entfernt werden, ohne dass die restliche Baumstruktur geändert werden muss. Die Agilität eines Unternehmens wird dadurch erhöht, da auf veränderte Marktbedürfnisse schneller reagiert werden kann. Dies ist insbesondere dann wichtig, wenn die Softwareapplikationen für die Steuerung von Automatisierungssystemen, Produktionsanlagen oder MES-Systemen eingesetzt wird. Die erfindungsgemäßen Softwareapplikationen können aber auch im Bürobereich (Officebereich) vorteilhaft eingesetzt werden.
Die Vernetzung, Verzeigerung oder Referenzierung zwischen den Objekten kann in einer unterschiedlichen Granularität stattfinden. So kann eine Vernetzung z. B. durch den Verweis auf physikalische Adressen (durch Zeiger bzw. Pointer) erfolgen, wodurch eine hohe Effizienz (z. B. innerhalb des Ablaufs eines Prozesses) erreicht wird. Andere Vernetzungsmechanismen sind z. B. elektronische Nachrichten (z. B. E-Mail), Telefon oder Fax. Je nach Anforderung der zugrundeliegenden Applikation kann vom Anwender ein entsprechender Vernetzungsmechanismus gewählt werden.
Objekte im Sinne der Erfindung sind diejenigen Objekte, die bei der Erstellung der Softwareapplikation verwendet werden, aber auch Laufzeit-Objekte. Laufzeit-Objekte sind Objekte, die zur Laufzeit eines Systems (z. B. einer Applikation) die Logik des Systems ausführen.
Die erfindungsgemäße Architektur eignet sich weiterhin für Prozessleitsysteme und Fertigungsautomatisierungssysteme.
Eine erste vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass zur Laufzeit die Objekte und/oder Referenzierungsmechanismen und/oder Vernetzungsmechanismen und/oder Implementierungen der Objekte und/oder Kommunikationsmechanismen austauschbar sind. Dadurch, dass zur Laufzeit Objekte durch andere Objekte, z. B. durch Objekte mit erweiterter Funktionalität oder die Implementierungen von Objekten (z. B. die neuen Implementierungen sind fehlerbereinigt oder haben eine bessere Performance) oder Referenzierungs- und Vernetzungsmechanismen ausgetauscht werden können, wird die Turnaround-Zeit bei Änderungen deutlich reduziert. Dadurch wird die Flexibilität für den Anwender und den Betreiber einer Anlage erhöht und die Agilität eines Unternehmens erhöht. Für die Auswertung der Metadaten wird kein üblicher Compiler verwendet, sondern ein so genannter inkrementeller Compiler oder ein Interpreter, der nur zum Zeitpunkt des Austauschens objektlokal aktiv ist. Für das neu eingesetzte Objekt, wird, wenn nötig inkrementell Code erzeugt und der inkrementelle Compiler oder Interpreter fügt das neu eingesetzte Objekt (bzw. den Referenzierungsmechanismus und/oder Vernetzungsmechanismus und/oder eine neue Implementierung von Objekten) zur Laufzeit in den Baum wieder ein, ohne andere (nicht betroffene) Teile des Baumes berücksichtigen zu müssen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass den Objekten zur Laufzeit Dienste hinzufügbar sind. Die Dienste verwenden die objeklokalen Metadaten um (MES-, bzw. Control-) Infrastrukturfunktionen generisch zur Verfügung zu stellen. Solche Dienste können z. B. sein: Serialisierung, Replikation, Verschlüsselung oder Zugriffsschutz. Die Objekte können dadurch mit sogenannten "Quality of Services" ausgestattet werden. Ein Benutzer eines Objektes kann sich auf die Ausführung dieser Dienste verlassen und von ihrer Realisierung abstrahieren.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass Implementierungen der Referenzierungsmechanismen oder der Vernetzungsmechanismen oder der Kommunikationsmechanismen oder der Dienste für Daten und für Programme anwendbar sind. Die Mechanismen und die Dienste müssen somit nicht jeweils für Daten und für Programme separat implementiert werden. Weiterhin können Metainformationen allen Objekten (egal, ob es sich um Daten oder Programme handelt) in gleicher Weise zugefügt werden und es kann in gleicher Weise bei allen Objekten auf die Metainformationen zugegriffen werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass die Objekte statisch und/oder dynamisch vernetzt sind. Vernetzungen (bzw. Verzeigerungen oder Referenzierungen) können statisch bei einer manuellen Erstellung des Baumes erfolgen, aber auch automatisch aufgrund von aktuellen Informationen oder Metainformationen erstellt werden (z. B. bei Bedarf). Dadurch wird die Flexibilität für einen Anwender erhöht. Vernetzungen können über unterschiedliche Mechanismen und Implementierungen eingerichtet werden: z. B. Zeiger auf Objekte, E-Mail an Objekte oder Vernetzung über OPC-Protokolle (OPC steht für OLE for Process Control). Insbesondere im industriellen Umfeld werden OPC-Protokolle häufig verwendet. Weitere Techniken bzw. Implementierungen die für Vernetzungen oder für Verknüpfungen einsetzbar sind, sind z. B. MSMQ (Microsoft Message Queue), HTTP (Hypertext Transfer Protocol) oder SOAP (Simple Object Transfer Protocol).
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass die Objekte die Metainformation physikalisch enthalten. Dadurch wird bei der Erstellung der Softwareapplikation das Prinzip der Lokalität unterstützt, d. h. alle Informationen (auch die Metainformationen), die für ein Objekt wichtig sind, sind auch physikalisch am Objekt vorhanden. Der Zugriff auf diese Informationen wird dadurch erleichtert. Dadurch, dass die Objekte die Metainformationen physikalisch enthalten, kann auch ein Objekt für sich alleine zur Organisation, Reorganisation oder Rekonfigurierung der Softwareapplikation verwendet werden, in Abhängigkeit davon, welche Metainformationen (Typus und Umfang) im Objekt vorhanden sind. Dies ist insbesondere für mobile Objekte von Vorteil, z. B. für Softwareagenten die sich im Intranet (oder anderen vernetzten Systemen wie z. B. Intranet) von Rechner zu Rechner bewegen um z. B. jeweils rechnerlokal hochperformant Anlageninformation z. B. für ein Maintenancesystem zu sammeln.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass die Metainformation statische und/oder dynamische Objektmodelle beinhaltet. Solche Objektmodelle sind z. B. Klassen und deren Beziehungen, State/Event-Modelle, Activity-Modelle, Deployment-Modelle oder Domain-Modelle (z. B. MES Prozessmodell in spezifischen Branchen wie z. B. Automobilherstellung, Düngemittelproduktion). Dies ist insbesondere für die generische Softwareentwicklung bzw. für Softwaregeneratoren von Vorteil.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass die Metainformation eine Applikation oder einen Geschäftsprozess beschreibt. Wenn die Metainformation nicht nur Informationen über das Objekt selbst, sondern auch Informationen über die gesamte Softwareapplikation, über die Einsatzumgebung oder über den zu realisierenden Geschäftsprozess (bzw. Business Logik) beinhaltet, dann wird dadurch die Konfigurierung der Softwareapplikation vereinfacht, bis dahin, dass eine Konfigurierung automatisch erfolgen kann. Auch Rekonfigurierungen (z. B. nach Systemabstürzen oder Ausfall von Teilen des Systems) können ohne menschlichen Eingriff automatisch erfolgen. Dadurch wird die Agilität eines Unternehmens und die Verfügbarkeit der Produktionsanlage erhöht.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass jedes einzelne Objekt die gesamte Metainformation über die Applikation oder den Geschäftsprozess beinhaltet. Das bedeutet, dass in einer Softwareapplikation bzw. in einem Softwaresystem in jedem einzelnen Objekt (z. B. im allerkleinsten Tag, in jeder Variable oder in jedem Operator, d. h. auch in den ganz fein granularen Objekten) die gesamte Beschreibung der Applikation oder auch eines Geschäftsprozesses (bzw. Business Logik) enthalten ist. Durch diese Informationen kann jedes einzelne Objekt zu einer Reorganisation, aber auch Selbstorganisation der Applikation, des Systems oder des Geschäftsprozesses verwendet werden. Dies ist z. B. bei Systemfehlern sehr vorteilhaft wenn große Teile des Systems ausfallen. Das System kann sich aus dem kleinsten noch funktionsfähigen Teil selbst vollständig regenerieren. Ein Wartungsingenieur muss sich somit nicht aufwendig mit Wiederinbetriebssetzen beschäftigen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass auf einer Anzeigevorrichtung die Bäume in unterschiedlichen Ansichten darstellbar sind. Die Darstellung der Bäume kann unterschiedlich sein, z. B. durch eine statische Explorer ähnliche Notation oder in Form von Workflow- bzw. Ablaufdiagrammen (Flowcharts, Activitydiagramme) oder z. B. in Form von Blockschaltbildern (z. B. Stromlaufpläne) oder Anlagenplänen (z. B. physikalisches Anlagenlayout, Materialflusspläne). Dadurch wird die Flexibilität für einen Anwender sehr erhöht, denn er kann eine seinem Wissensstand adäquate Notation bzw. Visualisierung auswählen, um die im Laufzeitsystem vorhandene Metainformation einzusehen. Es kann auch zwischen den Darstellungsformen gewechselt werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für eine Softwarearchitektur liegt darin, dass im Fehlerfall die auf der Softwarearchitektur basierende Softwareapplikation sich selbst rekonfiguriert. Wenn in einer Softwareapplikation bzw. in einem Softwaresystem in jedem einzelnen Objekt (z. B. im allerkleinsten Tag, in jeder Variable oder in jedem Operator, d. h. auch in den ganz fein granularen Objekten) die gesamte Beschreibung der Applikation oder auch eines Geschäftsprozesses enthalten ist, können diese Informationen zu einer automatischen Reorganisation, d. h. Selbstheilung der Applikation, des Systems oder des Geschäftsprozesses verwendet werden. Benutzereingriffe sind nicht mehr erforderlich und die Stillstandzeiten werden minimiert. Ein Wartungsingenieur muss sich somit nicht aufwendig mit Wiederinbetriebsetzen beschäftigen.
Gemäß der Erfindung wird die oben genannte Aufgabe für ein Verfahren zur Erstellung von Softwareapplikationen durch die Merkmale des Anspruchs 23 gelöst. Die einem Objekt zugeordneten Metainformationen beschreiben z. B. welche Daten und Funktionen ein Objekt enthält, Metainformationen können aber auch Beschreibungen zur Implementierung- und Bedienung beinhalten oder eine Benutzerdokumentation umfassen. In Auszeichnungssprachen wie HTML oder XML können Metainformationen über sogenannte Tags oder über Attribute beschrieben und den Objekten zugeordnet werden. Metainformationen können auch mit einer hierarchischen Struktur versehen werden. Ein Vorteil der Erfindung liegt darin, dass keine explizite Code-Erzeugung nötig ist, um eine Softwareapplikation ablaufen zu lassen. Die Objekte sind Black Boxes mit entsprechenden Zugriffsmechanismen zum Lesen der Metadaten. Aus der Struktur des Baumes und seiner Vernetzung wird die Ablauflogik und die Ablaufreihenfolge der durch den Baum repräsentierten Softwareapplikation festgelegt. Die zur Laufzeit manuell oder automatisch änderbare Struktur des Baumes und die Vernetzung der Baumelemente bestimmt, mit welchen Operanden Funktionen versorgt werden und ob Funktionen sequentiell oder parallel ausgeführt werden. Bei industriellen Anlagen wird durch die Struktur des Baumes und die Vernetzung der Baumelemente z. B. bestimmt, mit welchen Eingabegrößen Geräte versorgt werden und wie die vom Gerät erzeugten Ausgabewerte weiterverarbeitet werden. An einer Softwareentwicklungsumgebung wird von einem Benutzer der Baum und die Vernetzung grafisch editiert. Die Darstellungsform der Bäume kann unterschiedlich sein und vom Benutzer frei bzw. anwendungsspezifisch gewählt werden. Die Vernetzung oder Verzeigerung der Baumelemente kann durch die hierarchische Anordnung im Baum erfolgen. Vernetzungen oder Verzeigerungen der Baumelemente können aber auch durch vom Anwender editierte Referenzierungen oder laterale Vernetzungen zu Elementen anderer Teilbäume erfolgen. Die Eingaben zur Erstellung des Baumes und zur Etablierung von Vernetzungen kann über Eingabemasken, Drag&Drop-Mechanismen oder über Spracheingabe erfolgen.
Den einzelnen Objekten ist ihre Implementierung, d. h. ihr Code und Metainformation zugeordnet. Dadurch, dass die Softwareapplikation zur Laufzeit aus vorgefertigten Objekten zusammengesetzt wird (z. B. automatisch anhand der Metadaten über den Anwendungsprozeß), kann auf eine explizite Kompilierphase zur Erzeugung des Codes der zu erstellenden Softwareapplikation verzichtet werden. Kompilierläufe können sehr lange dauern. Dadurch, dass explizite Kompilierläufe nicht benötigt werden, wird die Zeit zur Erstellung der Softwareapplikation, des Testens und der Inbetriebnahme minimiert.
Ein weiterer Vorteil liegt darin, dass Änderungen sehr leicht durchführbar sind. Teilbäume können jederzeit hinzugefügt, geändert oder entfernt werden, ohne dass die gesamte Baumstruktur geändert werden muss. Die Agilität eines Unternehmens wird dadurch erhöht, da auf veränderte Marktbedürfnisse schneller reagiert werden kann. Dies ist insbesondere dann wichtig, wenn die Softwareapplikationen für die Steuerung von Automatisierungssystemen, Produktionsanlagen oder MES- Systemen eingesetzt wird. Die erfindungsgemäßen Softwareapplikationen können aber auch im Bürobereich (Officebereich) vorteilhaft eingesetzt werden.
Die Vernetzung, Verzeigerung oder Referenzierung zwischen den Objekten kann in einer unterschiedlichen Granularität stattfinden. So kann eine Vernetzung z. B. durch den Verweis auf physikalische Adressen (durch Zeiger bzw. Pointer) erfolgen, wodurch eine hohe Effizienz (z. B. innerhalb des Ablaufs eines Prozesses) erreicht wird. Andere Vernetzungsmechanismen sind z. B. elektronische Nachrichten (z. B. E-Mail), Telefon oder Fax. Je nach Anforderung der zugrundeliegenden Applikation kann vom Anwender ein entsprechender Vernetzungsmechanismus gewählt werden.
Durch geeignete Softwareentwicklungsumgebungen wird das Verfahren unterstützt. So können in einem Repository bereits erstellte Objekte vorhanden sein, die über Drag&Drop oder andere Eingabehilfsmittel (z. B. Tastatur, Lichtgriffel) in den Baum eingefügt werden können. Weiterhin ist es von Vorteil, wenn die Anzeigevorrichtung, die zum Darstellen und zum Erstellen der Bäume verwendet wird, in unterschiedliche Bildschirmbereiche aufteilbar ist (Fenstertechnik) Objekte im Sinne der Erfindung sind diejenigen Objekte, die bei der Erstellung der Softwareapplikation verwendet werden, aber auch Laufzeit-Objekte. Laufzeit-Objekte sind Objekte, die zur Laufzeit eines Systems (z. B. einer Applikation) die Logik des Systems ausführen.
Das erfindungsgemäße Verfahren eignet sich weiterhin für die Erstellung von Softwareapplikationen für Prozessleitsysteme und Fertigungsautomatisierungssysteme.
Eine erste vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass zur Laufzeit die Objekte und/oder Referenzierungsmechanismen und/oder Vernetzungsmechanismen und/oder Implementierungen der Objekte austauschbar sind. Dadurch, dass zur Laufzeit Objekte durch andere Objekte, z. B. durch Objekte mit erweiterter Funktionalität oder die Implementierungen von Objekten (z. B. die neuen Implementierungen sind fehlerbereinigt oder haben eine bessere Performance) oder Referenzierungs- und Vernetzungsmechanismen ausgetauscht werden können, wird die Turnaround-Zeit bei Änderungen deutlich reduziert. Dadurch wird die Flexibilität für den Anwender und den Betreiber einer Anlage erhöht und die Agilität eines Unternehmens erhöht. Für die Auswertung der Metadaten wird kein üblicher Compiler verwendet, sondern ein so genannter inkrementeller Compiler oder ein Interpreter, der nur zum Zeitpunkt des Austauschens objektlokal aktiv ist. Für das neu eingesetzte Objekt, wird, wenn nötig inkrementell Code erzeugt und der inkrementelle Compiler oder Interpreter fügt das neu eingesetzte Objekt (bzw. den Referenzierungsmechanismus und/oder Vernetzungsmechanismus und/oder eine neue Implementierung von Objekten) zur Laufzeit in den Baum wieder ein, ohne andere (nicht betroffene) Teile des Baumes berücksichtigen zu müssen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass den Objekten zur Laufzeit Dienste hinzugefügt werden. Die Dienste verwenden die objektlokalen Metadaten um (MES-, bzw. Control-)Infrastrukturfunktionen generisch zur Verfügung zu stellen. Solche Dienste können z. B. sein: Serialisierung, Replikation, Verschlüsselung oder Zugriffsschutz. Die Objekte können dadurch mit sogenannten "Quality of Services" ausgestattet werden. Ein Benutzer eines Objektes kann sich auf die Ausführung dieser Dienste verlassen und von ihrer Realisierung abstrahieren.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass Implementierungen der Referenzierungsmechanismen oder der Vernetzungsmechanismen oder der Dienste für Daten und für Programme verwendet werden. Die Mechanismen und die Dienste müssen somit nicht jeweils für Daten und für Programme separat implementiert werden. Weiterhin können Metainformationen allen Objekten (egal, ob es sich um Daten oder Programme handelt) in gleicher Weise zugefügt werden und es kann in gleicher Weise bei allen Objekten auf die Metainformationen zugegriffen werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass die Objekte statisch und/oder dynamisch vernetzt werden. Vernetzungen (bzw. Verzeigerungen oder Referenzierungen) können statisch bei einer manuellen Erstellung des Baumes erfolgen, aber auch automatisch aufgrund von aktuellen Informationen oder Metainformationen erstellt werden (z. B. bei Bedarf). Dadurch wird die Flexibilität für einen Anwender erhöht. Vernetzungen können über unterschiedliche Mechanismen und Implementierungen eingerichtet werden: z. B. Zeiger auf Objekte, E-Mail an Objekte oder Vernetzung über OPC-Protokolle (OPC steht für OLE for Process Control). Insbesondere im industriellen Umfeld werden OPC-Protokolle häufig verwendet. Weitere Techniken bzw. Implementierungen die für Vernetzungen oder für Verknüpfungen einsetzbar sind, sind z. B. MSMQ (Microsoft Message Queue), HTTP (Hypertext Transfer Protocol) oder SOAP (Simple Object Transfer Protocol).
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass die Objekte die Metainformation physikalisch enthalten. Dadurch wird bei der Erstellung der Softwareapplikation das Prinzip der Lokalität unterstützt, d. h. alle Informationen (auch die Metainformationen), die für ein Objekt wichtig sind, sind auch physikalisch am Objekt vorhanden. Der Zugriff auf diese Informationen wird dadurch erleichtert. Dadurch, dass die Objekte die Metainformationen physikalisch enthalten, kann auch ein Objekt für sich alleine zur Organisation, Reorganisation oder Rekonfigurierung der Softwareapplikation verwendet werden, in Abhängigkeit davon, welche Metainformationen (Typus und Umfang) im Objekt vorhanden sind. Dies ist insbesondere für mobile Objekte von Vorteil, z. B. für Softwareagenten die sich im Internet (oder anderen vernetzten Systemen wie z. B. Intranet) von Rechner zu Rechner bewegen, um z. B. jeweils rechnerlokal hochperformant Anlageninformation z. B. für ein Maintenancesystem zu sammeln.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass die Metainformation statische und/oder dynamische Objektmodelle beinhaltet. Solche Objektmodelle sind z. B. Klassen und deren Beziehungen, State/Event-Modelle, Activity-Modelle, Deployment-Modelle oder Domain-Modelle (z. B. MES Prozessmodell in spezifischen Branchen wie z. B. Automobilherstellung, Düngemittelproduktion). Dies ist insbesondere für die generische Softwareentwicklung bzw. für Softwaregeneratoren von Vorteil.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass die Metainformation eine Applikation oder einen Geschäftsprozess beschreibt. Wenn die Metainformation nicht nur Informationen über das Objekt selbst, sondern auch Informationen über die gesamte Softwareapplikation, über die Einsatzumgebung oder über den zu realisierenden Geschäftsprozess (bzw. Business Logik) beinhaltet, dann wird dadurch die Konfigurierung der Softwareapplikation vereinfacht, bis dahin, dass eine Konfigurierung automatisch erfolgen kann. Auch Rekonfigurierungen (z. B. nach Systemabstürzen oder Ausfall von Teilen des Systems) können ohne menschlichen Eingriff automatisch erfolgen. Dadurch wird die Agilität eines Unternehmens erhöht.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass jedes einzelne Objekt die gesamte Metainformation über die Applikation oder den Geschäftsprozess beinhaltet. Das bedeutet, dass in einer Softwareapplikation bzw. in einem Softwaresystem in jedem einzelnen Objekt (z. B. im allerkleinsten Tag, in jeder Variable oder in jedem Operator, d. h. auch in den ganz fein granularen Objekten) die gesamte Beschreibung der Applikation oder auch eines Geschäftsprozesses enthalten ist. Durch diese Informationen kann jedes einzelne Objekt zu einer Reorganisation, aber auch Selbstorganisation der Applikation, des Systems oder des Geschäftsprozesses verwendet werden. Dies ist z. B. bei Systemfehlern sehr vorteilhaft wenn große Teile des Systems ausfallen. Das System kann sich aus dem kleinsten noch funktionsfähigen Teil selbst vollständig regenerieren. Ein Wartungsingenieur muss sich somit nicht aufwendig mit dem Wiederinbetriebsetzen beschäftigen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass auf einer Anzeigevorrichtung die Bäume in unterschiedlichen Ansichten dargestellt werden. Die Darstellung der Bäume kann unterschiedlich sein, z. B. durch eine statische Explorer ähnliche Notation oder in Form von Workflow- bzw. Ablaufdiagrammen (Flowcharts, Activitydiagramme) oder z. B. in Form von Blockschaltbildern (z. B. Stromlaufpläne) oder Anlagenplänen (z. B. physikalisches Anlagenlayout, Materialflusspläne). Dadurch wird die Flexibilität für einen Anwender sehr erhöht, denn er kann eine seinem Wissensstand adäquate Notation bzw. Visualisierung auswählen, um die im Laufzeitsystem vorhandene Metainformation einzusehen. Es kann auch zwischen den Darstellungsformen gewechselt werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung für ein Verfahren liegt darin, dass im Fehlerfall die Softwareapplikation sich selbst rekonfiguriert. Wenn in einer Softwareapplikation bzw. in einem Softwaresystem in jedem einzelnen Objekt (z. B. im allerkleinsten Tag, in jeder Variable oder in jedem Operator, d. h. auch in den ganz fein granularen Objekten) die gesamte Beschreibung der Applikation oder auch eines Geschäftsprozesses enthalten ist, können diese Informationen zu einer automatischen Reorganisation, d. h. Selbstheilung der Applikation, des Systems oder des Geschäftsprozesses verwendet werden. Benutzereingriffe sind nicht mehr erforderlich und die Stillstandzeiten werden minimiert. Ein Wartungsingenieur muss sich somit nicht aufwendig mit dem Beschaffen und Lesen von Dokumentationen beschäftigen.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung liegt in einer Softwareentwicklungsumgebung, die ins Laufzeitsystem integriert ist, wobei über Sichten auf auswählbare Funktionalitäten zugegriffen wird. Die traditionelle Softwarentwicklungsumgebung wird somit reduziert auf Darstellungen und Editoren mit denen direkt das Laufzeitsystem betrachtet und verändert werden kann. Vorteile dieses Konstruktionsprinzips bzw. dieser Architektur sind neben der einfacheren Änderbarkeit des Laufzeitsystems auch die System- und Datenkonsistenz. So kann über die Sichten, die z. B. durch Editoren realisiert werden, auf Anwendungsfunktionen des Laufzeitsystems zugegriffen werden (Bedienungssicht) oder aber auch Änderungen bzw. Erweiterungen vorgenommen werden (Engineering- oder Wartungssicht).
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung liegt darin, dass die erfindungsgemäße Softwareapplikation oder das erfindungsgemäße Verfahren und die Softwareentwicklungsumgebung durch ein Computerprogramm implementiert sind. Dadurch können eventuelle Modifizierungen bzw. Anpassungen leicht durchgeführt werden.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung liegt darin, dass das Computerprogramm für das erfindungsgemäße Verfahren bzw. für die Softwareentwicklungsumgebung auf einem Datenträger gespeichert ist. Dadurch ist das Verfahren bezüglich der Logistik und Verteilung leicht handhabbar. Datenträger sind z. B. übliche Computerprogrammprodukte wie z. B. Disketten oder CDs.
Eine weitere vorteilhafte Ausgestaltung der vorliegenden Erfindung liegt darin, dass das Computerprogramm für das erfindungsgemäße Verfahren bzw. für die Softwareentwicklungsumgebung auf einer Datenverarbeitungseinrichtung installiert ist. Dadurch wird die Performance erhöht.
Weitere Vorteile und Details der Erfindung ergeben sich anhand der nun folgenden Beschreibung vorteilhafter Ausführungsbeispiele und in Verbindung mit den Figuren. Soweit in unterschiedlichen Figuren Elemente mit gleichen Funktionalitäten beschrieben sind, sind diese mit gleichen Bezugszeichen gekennzeichnet.
Es zeigen:
Fig. 1 in einer prinzipiellen Übersichtsdarstellung die "Unternehmenspyramide" mit drei Steuerungsebenen,
Fig. 2 eine Schemadarstellung mit einer herkömmlichen Softwareentwicklungsumgebung, einem Laufzeitsystem und einem zu steuerndem technischen Prozess,
Fig. 3 die Schemadarstellung eines Objektes,
Fig. 4 die Baumstruktur einer Softwareapplikation,
Fig. 5 eine Darstellungsform eines Baumes,
Fig. 6 eine weitere Darstellungsform eines Baumes,
Fig. 7 eine Schemadarstellung mit einem Laufzeitsystem und einem zu steuernden technischen Prozeß, wobei Funktionen der Softwareentwicklungsumgebung ins Laufzeitsystem integriert sind und
Fig. 8 in einem Schaubild Aspekte, die eine Softwarearchitektur bestimmen.
Die Darstellung gemäß Fig. 1 zeigt in einer prinzipiellen Übersichtsdarstellung die drei Steuerungsebenen, wie sie üblicherweise in einem produzierenden bzw. fertigenden Unternehmen zu finden sind. Durch die Pyramidenform wird ausgedrückt, dass nach oben hin eine Verdichtung der Informationen stattfindet. Die oberste Ebene ist die ERP-Ebene (Enterprise Ressource Planning. Auf dieser Unternehmensleitebene werden üblicherweise die betriebswirtschaftlichen und vertrieblichen Aufgaben in einem Unternehmen durchgeführt (z. B. Finanzwesen, Vertriebswesen, Personalwesen, Berichterstattung). Aber auch produktionsanlagenübergreifende logistische Aufgaben (z. B. Auftrags- und Materialverwaltung) werden auf dieser Ebene durchgeführt. Das System SAP R/3 ist ein ERP-System, das auf der Unternehmensleitebene sehr häufig verwendet wird.
Die unterste Ebene der Pyramide ist die Automatisierungs- Ebene (Controls). Auf dieser Ebene kommen üblicherweise speicherprogrammierbare Steuerungen (SPS) in Verbindung mit Visualisierungs- und Prozessleitsystemen (PLS) zum Einsatz. Die Antriebe, Aktoren und Sensoren der Produktions- und/oder Fertigungseinrichtungen stehen direkt mit den Systemen dieser Ebene in Verbindung.
Das Verbindungsglied zwischen der ERP-Ebene und der Automatisierungs-Ebene wird durch die MES-Ebene gebildet. Die Applikationen der MES-Ebene sorgen somit für eine vertikale Integration zwischen der ERP-Ebene und der Automatisierungs-Ebene. Die MES-Applikationen müssen einerseits die Grobplanungen der ERP-Systeme um produktionsanlagenspezifische Feinplanungen ergänzen und an die Systeme der Automatisierungs-Ebene weiterleiten, andererseits ist es Aufgabe der MES-Applikationen produktionsrelevante Daten der Automatisierungs-Ebene aufzunehmen, aufzubereiten und an die ERP-Ebene (Unternehmensleitebene) weiterzuleiten sowie die Abläufe in der Produktion zu optimieren.
Typische MES-Applikationen sind u. a. Quality Management (QM), Maintenance Management (mm), Performance Analysis (PA), Process Management, Labor Management, Asset Management. Durch jeweils drei Punkte wird in Fig. 1 ausgedrückt, dass sich auf einer Ebene weitere Elemente (Applikationen, Systeme etc.) befinden können.
MES-Systeme bzw. ERP-Systeme enthalten in der Regel ein so genanntes Laufzeitsystem zur zeitlichen Ablaufsteuerung der beteiligten Komponenten (Teilkomponenten, Module, Tasks, Prozesse des Betriebssystems etc.), sowie ein so genanntes Engineeringsystem zum Erstellen und Editieren von Programmen, welche zur Ausführung im Laufzeitsystem vorgesehen sind.
Die Darstellung gemäß Fig. 2 zeigt eine Schemadarstellung mit einer herkömmlichen Softwareentwicklungsumgebung SU, einem Laufzeitsystem RTS und einem zu steuernden technischen Prozess TP1. Softwareapplikationen werden heutzutage methodisch und ingenieurmäßig erstellt. Dazu werden üblicherweise Werkzeuge (so genannte CASE-Werkzeuge, CASE steht für Computer Aided Software Engineering) verwendet. Durch diese CASE- Werkzeuge wird die Einhaltung von Methoden und Standards unterstützt, um die Produktivität der Softwareentwickler, aber auch um die Qualität der erstellten Software zu erhöhen. Die CASE-Werkzeuge werden den Softwareentwicklern über eine Softwareentwicklungsumgebung SU zur Verfügung gestellt. Diese Softwareentwicklungsumgebung SU ist Teil des Arbeitsplatzes für einen Softwareersteller. Eine Softwareentwicklungsumgebung SU unterstützt einen Softwareersteller in allen Phasen der Softwareentwicklung, d. h. von den frühen Phasen in der Analyse bis zu den späten Phasen des Testens. Für alle Phasen der Softwareentwicklung stehen einem Entwickler geeignete Dienstprogramme, wie z. B. Editor, Compiler, Debugger, aber auch Werkzeuge für die Analyse und für den Entwurf zur Verfügung.
Der Arbeitsplatz eines Softwareentwicklers besteht üblicherweise aus einer Recheneinheit mit Prozessor und Speicher sowie Ausgabeeinheiten wie Bildschirm, Display und Eingabehilfsmittel wie Keyboard und Maus sowie den Hilfsprogramme, die zur Softwareentwicklung benötigt werden (Editor, Compiler, etc.). Über eine geeignete Softwareentwicklungsumgebung SU können diese Hilfsprogramme von einem Softwareentwickler sehr leicht aufgerufen werden und bedient werden. Moderne Softwareentwicklungsumgebungen SU ermöglichen weiterhin einen Zugriff auf Konfigurationsmanagement-Werkzeuge und auf Änderungsmanagement-Werkzeuge.
Heutzutage unterstützen moderne Softwareentwicklungsumgebungen SU insbesondere die Paradigmen der Objektorientierung wie die Erstellung von Objekten, die Erstellung von Klassen, die Erstellung von Oberklassen sowie die Darstellung von Vererbungsbeziehungen. Über geeignete Editoren, Maskeneingabe oder über Drag&Drop-Mechanismen werden die Objekte mit Metainformationen verknüpft, werden die Objekte als hierarchische Bäume strukturiert und auch miteinander vernetzt. Die mit Hilfe der Softwareentwicklungsumgebung SU erstellten Softwareapplikationen müssen auf einem Zielsystem bzw. auf einem Zielrechner letztendlich ausgeführt werden, um z. B. einen technischen Prozess TP1 zu steuern. Das Zielsystem besteht üblicherweise aus einer bis mehreren Recheneinheiten mit Prozessoren und Speichereinrichtungen sowie einem Laufzeitsystem RTS. Die mit Hilfe der Softwareentwicklungsumgebung SU erstellten Programme werden über den Informationspfad I auf das Runtimesystem RTS geladen. Über Ein-/Ausgabeverbindungen EA1 wird der zugrunde liegende technische Prozess z. B. für eine Automatisierungslösung oder eine MES-Lösung gesteuert. Vom Laufzeitsystem RTS zum technischen Prozess TP1 werden über die EA- Verbindung EA1 z. B. Aktoren beeinflusst, vom technischen Prozess TP1 zurück zum Laufzeitsystem RTS werden über die EA- Verbindung EA1 z. B. Sensordaten geliefert, die dann in der Softwareapplikation weiterverarbeitet werden. Ein Laufzeitsystem RTS kann auch auf mehrere Rechnereinheiten verteilt sein.
Die Darstellung gemäß Fig. 3 zeigt die Schemadarstellung eines Objektes mit einem Objektinterface OI. Ein Objekt ist allgemein ein Gegenstand oder ein Element einer Domäne bzw. einer Diskurswelt. In der objektorientierten Softwareentwicklung ist ein Objekt ein individuelles Exemplar von Dingen oder Sachen (z. B. Roboter, Auto, Maschine), Personen (z. B. Kunde, Mitarbeiter, Patentanwalt) oder Begriffen der realen Welt (z. B. Bestellauftrag) oder der Vorstellungswelt (z. B. juristische und natürliche Personen oder Organisationen). Ein Objekt besitzt einen bestimmten definierten Zustand und reagiert mit einem definierten Verhalten auf seine Umgebung. Außerdem besitzt jedes Objekt eine Objektidentität, die es von allen anderen Objekten unterscheidet und die es erlaubt, auf ein bestimmtes Objekt zuzugreifen. Ein Objekt kann ein oder mehrere andere Objekte kennen. Zwischen Objekten, die sich kennen, bestehen Verbindungen oder Verzeigerungen bzw. Vernetzungen. Der Zustand eines Objekts wird durch seine Daten bzw. Attributwerte und die jeweiligen Verbindungen zu anderen Objekten bestimmt. Das Verhalten eines Objekts wird durch seine Menge von Methoden bzw. Operationen definiert. In der Objektorientierung wird durch eine Klasse der Typ eines Objektes beschrieben. Aus dieser Typbeschreibung können konkrete Inkarnationen bzw. Instanzen, die dann ein konkretes programmiersprachliches Objekt darstellen, erzeugt werden. Mit Hilfe von Objektdiagrammen lassen sich Objekte und ihre Verbindungen graphisch darstellen. Die Editoren für Objektdiagramme sind Teil der Softwareentwicklungsumgebung (SU; Fig. 2). UML (Unified Modeling Language) bietet eine Reihe von Notationen zur graphischen Darstellung objektorientierter Konzepte (Geschäftsprozessdiagramm, Zustandsdiagramm, Aktivitätsdiagramm, Kollaborationsdiagramm, Sequence Diagramm, Klassendiagramme, etc.). Diese Diagramme können von einem Anwender mit der Softwareentwicklungsumgebung (SU; Fig. 2) editiert und bearbeitet werden.
Der linke Teil von Fig. 3 zeigt die Informationen bzw. Elemente, die ein Objekt üblicherweise enthält. Daten sind so einfache Dinge wie ein Zahlenwert oder aber auch komplexe Strukturen wie Rezepte, Bestellungen oder Archive. Methoden (oft auch als Operationen bezeichnet) repräsentieren ausführbare Tätigkeiten im Sinne eines Algorithmus. Die Menge der Methoden bestimmt das Verhalten eines von dieser Klasse instantiierten Objektes. Die Methoden eines Objektes können von anderen Objekten vergleichbar einer Client-Server-Architektur verwendet bzw. aufgerufen werden. Weiterhin können Objekte so genannte Subobjekte beinhalten, die sie für die Realisierung ihrer Methoden benötigen. Durch die Subobjekte wird ein struktureller Aufbau eines Objektes bestimmt.
In der Darstellung von Fig. 3 ist auf der rechten Seite schraffiert ein so genannter Container dargestellt. Durch diesen Container werden die der Erfindung entsprechenden Mechanismen für die Metainformationshältung und die Mechanismen des Zugriffs auf diese Metainformationen realisiert. Die Container stellen eine Kapselschicht um das Objekt dar, und alle Zugriffe auf ein Objekt können nur über die Schnittstelle OI erfolgen. Über die Schnittstelle OI wird auf die Methoden und Daten und auf die Metainformation des Objektes zugegriffen. Bei einem Zugriff auf die Daten, die Methoden oder auf die Metainformationen kann somit ein Benutzer von der Realisierung von Datenmethoden und Metainformationen abstrahieren. Alle Zugriffe auf ein Objekt erfolgen über die Schnittstelle OI. Dadurch ist die Wiederverwendbarkeit und die Austauschbarkeit von Objekten sehr leicht möglich. In einem auch komplexen System, z. B. Softwaresystem, kann somit immer auf dieselbe Art und Weise auf Objekte zugegriffen werden. Insbesondere stellen die so genannten Container Infrastrukturfunktionen wie Datenvernetzung, Datenspeicherung, Datenvisualisierung in einheitlicher Weise für alle Arten von Objekten (z. B. Businessobjekten) zur Verfügung. In dem Container ist schematisch eine Doppelhelix vergleichbar einer DNA-Struktur einer menschlichen Zelle dargestellt. Dadurch soll verdeutlicht werden, dass ein Objekt Teile oder die gesamte Metainformation, d. h. auch die Aufbauinformation und die Logik, die z. B. in einem Geschäftsprozess steckt, enthält. Dadurch kann aus einem Objekt das gesamte System oder die gesamte Applikation organisiert werden bzw. reorganisiert werden. Dadurch können Ausfallzeiten eines Systems minimiert werden und Wartungsarbeiten sehr effizient durchgeführt werden.
Zu den Infrastrukturfunktionen, die ein Container zur Verfügung stellt, gehören z. B. Trace-Funktionen, d. h. wer und wie lange hat ein Objekt verwendet. Wie schon erwähnt, enthält der Container Metainformationen, Selbstbeschreibungsinformationen für das Objekt. Dadurch können auch Messungen, aber auch Security-Mechanismen eingefügt werden.
Die Darstellung gemäß Fig. 4 zeigt die Baumstruktur einer Softwareapplikation. Die Objekte sind dabei als Doppelkreise dargestellt. Der innere Kreis stellt schematisch den Aufbau eines Objektes dar, wie es aus Fig. 3 bekannt ist. Der linke Teil eines Objektes stellt dabei wieder die Datenmethoden und Subobjekte dar, der rechte schraffierte Teil repräsentiert den so genannten Container, der die Metainformationen enthält und die Infrastrukturinformationen für ein Objekt zur Verfügung stellt. Der Container stellt eine Kapselschicht für das Objekt dar. Ein Zugriff auf das Objekt ist nur über die Objektschnittstelle OI möglich, die vom Container zur Verfügung gestellt wird. Infrastrukturfunktionen sind z. B. Datenvernetzung, Datenspeicherung und Datenvisualisierung. Durch den Container werden diese Funktionen in einer einheitlichen Wiese für alle anderen Objekte zur Verfügung gestellt.
Die Außenkreise um die Objekte stellen dar, dass die Objekte in die Infrastruktur eines Systems letztendlich eingebettet sind. Ein Aspekt der Infrastruktur ist die Vernetzung. Eine Vernetzung oder Verzeigerung kann sehr feingranular, z. B. über Speicherpointer erfolgen. Sie kann aber auch übers Internet, über E-Mail oder über Telefonverbindungen erfolgen. In der Darstellung gemäß Fig. 4 wird durch die fett eingezeichneten Verbindungslinien zwischen den Objekten dargestellt, dass diese Objekte lateral miteinander verbunden sind. So eine laterale Verbindung kann im industriellen Umfeld z. B. eine Verbindung über OPC sein (OLE for Procress Control). So eine Verbindung bzw. ein Infrastrukturdienst kann auch über Message Queue-Mechanismen realisiert werden. Der Zugriff auf Infrastrukturdienste oder -funktionalitäten wird über den Container dargeboten und ist für alle Objekte in einem Baum gleich, egal, ob es sich um ein B&B-Gerät (Bedienen und Beobachten) oder über eine speicherprogrammierbare Steuerung (SPS) handelt. Deshalb ist es auch sehr einfach, die Implementierung eines Infrastrukturdienstes zu ändern, da die Spezifikation unverändert bleibt. Der äußere Kreis eines Objektes stellt also eine Sammlung von Infrastrukturdiensten oder Infrastrukturfunktionen dar, die über einen Container verwendet werden können. Ein einmal realisierter Infrastrukturdienst kann von allen Objekten in der gleichen Weise verwendet werden.
Die Darstellung gemäß Fig. 4 zeigt eine Softwareapplikation, bei der die Objekte als hierarchischer Baum strukturiert sind. Das zu realisierende System bzw. die Softwareapplikation enthält ein B&B-Gerät mit einer Datenbank DB, wobei das B&B-Gerät von einer speicherprogrammierbaren Steuerung (SPS) versorgt wird. Die SPS greift über Ein-/Ausgabefunktionen auf Aktoren und Sensoren zu. Die Ergebnisse des Bedien- und Beobacht-Gerätes werden von einem Objekt "Execution" weiterverarbeitet. Der Algorithmus, für diese Weiterverarbeitung im Objekt "Execution" erfolgt, wird durch den Teilbaum dargestellt, der unter dem Objekt "Execution" hängt. Dabei wird ein Wert X1 mit einer Funktion F bearbeitet, wobei die Funktion F als Eingabewert den Wert X2 erhält. Nach dem Ausführen dieser Execution-Komponente werden weitere Nachbearbeitungen durchgeführt, dargestellt durch die Objekte "Postprocessing 1" und "Postprocessing 2". Dabei kann es sich z. B. um Verdichtungs- oder Anzeigefunktionen handeln. In Fig. 4 ist dargestellt, dass die Ergebnisse der Nachbearbeitung von "Postprocessing 1" durch das Objekt "Weiterverarbeitung" einem weiteren Verarbeitungsschritt unterzogen werden. Ein auf diese Weise beschriebenes Softwaresystem bzw. eine Softwareapplikation kann natürlich mit weiteren auf diese Art und Weise beschriebenen Softwareapplikationen Teil einer übergeordneten Welt sein, hier in Fig. 4 dargestellt durch das Objekt "World".
Neben der hierarchischen Strukturierung, wie sie durch die Struktur des Baumes vorgegeben wird, können die Objekte auch lateral bzw. horizontal miteinander vernetzt, reflexiert oder verzeigert werden. Dies ist in Fig. 4 dargestellt durch die fetten Linien. Solche Verzeigerungen können über Eingabemasken modelliert werden oder auch über Drag&Drop-Mechanismen hergestellt werden.
Die Funktion, die von einem Softwaresystem bzw. von einer Softwareapplikation realisiert wird, ergibt sich aus der Struktur, aus der Hierarchie und aus der Vernetzung der Baumobjekte. In Abhängigkeit von einem zugrunde zu legenden Traversierungsalgorithmus werden die Baumelemente, d. h. die Objekte, abgearbeitet und ausgeführt. Die Ausführung einer Softwareapplikation ist der Funktionsweise des Nervensystems eines Menschen vergleichbar, wo die einzelnen Neuronen über Dentriten und Synapsen miteinander verbunden sind und ihre Aktivitäten untereinander austauschen, wobei ein Reiz eine Impulskette durch den Körper auslöst und je nach Vernetzung der Neuronen eine solche Impulskette ausgeführt wird. Im erfindungsgemäßen System bzw. Softwareapplikation oder auch Softwarearchitektur wird auch durch die Struktur und die Vernetzung der Objekte, die den Neuronen im menschlichen Körper vergleichbar sind, einem Anreiz in Fig. 4, z. B. wenn ein Sensor eine SPS ein Ereignis weiterliefert und dieses Ereignis über das B&B-Gerät erfasst wird und dann eine Execution gestartet wird, die wiederum "Postprocessing 1" und "Postprocessing 2" zu einer Weiterverarbeitung anstößt, wobei "Postprocessing 1" nach der Weiterverarbeitung noch eine Weiterverarbeitung initiiert. Auf diese Art und Weise erstellte Softwareapplikationen haben sehr vorteilhafte Eigenschaften. So können die Objekte, die für eine Applikation benötigt werden, erst zur Laufzeit zusammengesetzt werden, wodurch die Änderbarkeit und die Flexibilität diese Applikationen sehr groß ist. Bei Änderungen muss ein Objekt nicht erst kompiliert werden. Ein neu in das System eingebrachtes Objekt, das ein anderes ersetzt, ist sehr einfach integrierbar, wenn es die gleiche Schnittstelle, die gleiche Spezifikation wie das zu ersetzende Objekt besitzt und sich nur in der Implementierung ändert, z. B. durch eine bessere Performance.
Die Darstellung gemäß Fig. 5 zeigt eine Darstellungsform für einen Baum. In Fig. 5 ist eine Anzeigevorrichtung AZ1 als mit den beiden Bildschirmbereichen BB1 und BB2 dargestellt. Eine Anzeigevorrichtung AZ1, kann z. B. ein Monitor oder ein Display sein. Die Anzeigevorrichtung AZ1 ist üblicherweise ein Element einer Element einer Softwareentwicklungsumgebung (SU; Fig. 2). Mit Hilfe von Anzeigevorrichtungen und Eingabehilfsmitteln wie z. B. Tastatur oder Maus werden Objekte auf dem Bildschirm erzeugt, hierarchisch als Baum strukturiert, miteinander vernetzt oder verzeigert, aber mit Metainformationen oder anderen Informationen versehen. Es ist vorstellbar, dass eine Anzeigevorrichtung AZ1 weitere Bildschirmbereiche enthält zu der Darstellung von Bäumen, aber auch, um Eingaben zu realisieren (z. B. Menüleisten). Eine Softwareapplikation wird zur Laufzeit aus den Objekten eines Baumes zusammengesetzt. Für die Abarbeitung der Objekte ist die Struktur wichtig, aber auch die Vernetzung der Objekte. Wenn ein Benutzer (z. B. ein Systemintegrator oder Wartungsingenieur) Änderungen einbringen will, dann benötigt er eine Darstellung des Baumes, die seinen entsprechenden Anforderungen und Bedürfnissen entgegenkommt. In der Darstellung, wie sie im Bildschirmbereich BB1 auf der linken Seite von Fig. 5 dargestellt ist, wird ein Baum OB1 mit den Baumelementen K1, K2, K3, K4 gezeigt, und zwar in einer explorerähnlichen Notation. Die Darstellung eines Baumes, wie sie im Bildschirmbereich BB2 gezeigt wird, entspricht einer Notation, wie sie z. B. für Stromlaufpläne verwendet wird. Die im Bildschirmbereich BB2 dargestellten Elemente K1' und K2' sind über Ein- (x1, x2) und Ausgabevariablen (r1, r2), die jeweils mit Linien miteinander verbunden sind, zu einer Baumstruktur dargestellt. Eine Darstellung in dieser Form von Stromablaufplänen ist besonders für Elektriker interessant, denn Elektriker denken in Stromlaufplänen. Über Eingabehilfsmittel ist es möglich, die Repräsentierung eines Baumes zu ändern und jeweils für die Usergruppe die praktischste Darstellung zu wählen. Usergruppen sind z. B. Wartungsingenieure, Systemintegratoren, Entwickler, aber auch Marketing- und Vertriebsleute.
Die Darstellung gemäß Fig. 6 zeigt eine weitere Möglichkeit, wie ein Baum an einer Anzeigevorrichtung AZ2 dargestellt werden kann. Der linke Abschnitt von Fig. 6 zeigt einen Bildschirmbereich BB1' mit einem Objektbaum OB2 in einer explorerähnlichen Struktur. Der rechte Teil von Fig. 6 zeigt einen Bildschirmbereich BB2', in welchem für die Darstellung eines Baumes eine Notation verwendet wird, die insbesondere für die Darstellung von Geschäftsabläufen sehr vorteilhaft ist. Menschen in der Buchhaltung oder im Management des Unternehmens denken in solchen Geschäftsprozessabläufen (Businessabläufen). Die Benutzerfreundlichkeit und auch die Effizienz bei der Erstellung von Bäumen oder beim Ändern von Bäumen wird durch die Möglichkeit, dass zwischen unterschiedlichen Darstellungsformen gewechselt werden kann, sehr erhöht. Ein Benutzer kann dadurch von der internen Repräsentierung oder Implementierung eines Baumes abstrahieren. Bei der Erstellung eines Baumes oder bei der Änderung eines Baumes muss nichts neu programmiert werden, sondern alles kann projektiert werden. Dies ist vorteilhaft für die Effizienz bei der Erstellung von Softwareapplikationen, aber auch für die Erstellung von Softwarearchitekturen.
Die Darstellung gemäß Fig. 7 zeigt eine Schemadarstellung mit einem erweiterten Laufzeitsystem RTS/SU und einem zu steuernden technischen Prozeß TP2, wobei Funktionen der Softwareentwicklungsumgebung im erweiterten Laufzeitsystem RTS/SU integriert sind. Über Sichten (sog. Views) wird auf die jeweils benötigten Funktionen zugegriffen. In Fig. 7 sind Sichten für die Entwicklung (SU-view) für die Bedienung (Operator view) und für die Wartung (Wartungs view) dargestellt. Durch drei Punkte ist angedeutet, dass weitere views vorhanden sein können. Das erweiterte Laufzeitsystem RTS/SU beinhaltet die Infrastruktur für die Entwicklung und Veränderung des Laufzeitsystems. Die Verbindung zum zu steuernden technischen Prozeß TP2 erfolgt über Ein-/Ausgabeverbindungen EA2.
Es ist ein wesentliche Auswirkung der Erfindung, dass die Funktionalität einer herkömmlichen Softwareentwicklungsumgebung (SU; Fig. 2) zu großen Teilen durch das Laufzeitsystem RTS/SU abgedeckt wird. Metadaten sind großteils Daten die bei der Entwicklung sowieso anfallen. Somit können Laufzeitsystem und Softwareentwicklungsumgebung sozusagen miteinander verschmelzen und müssen nicht mehr als separate Komponenten ausgebildet werden. Ein System, das änderbar ist, beinhaltet zur Laufzeit viele Aspekte die heute nur in Entwicklungsumgebungen vorhanden sind (Modellierung, Versionierung, Compilierung etc). Die traditionelle Softwarentwicklungsumgebung wird reduziert auf Darstellungen und Editoren mit denen direkt das Laufzeitsystem betrachtet und verändert werden kann.
Vorteile dieses Konstruktionsprinzips bzw. dieser Architektur sind neben der einfacheren Änderbarkeit des Laufzeitsystems auch die Systemkonsistenz. Alle Komponenten, die die Metadaten beinhalten bzw. referenzieren, beschreiben sich selbst. Die Zusammensetzung der Komponenten ergeben eine gesamte Systembeschreibung. D. h. wie auch immer das System geändert wird (z. Baugruppen stecken oder ziehen) die Sichten (Engineeringviews) sind in der Lage immer das aktuell vorhandene System zu zeigen. UML Diagramme, Business Prozess-Abbildungen, Stromlaufpläne, Anlagenbilder sind immer aktuell.
Die Darstellung gemäß Fig. 8 zeigt in einem Schaubild die Aspekte, die eine Softwarearchitektur SA bestimmen. Die Erstellung von Softwarearchitekturen SA erfordert abstraktes und konzeptionelles Denken. Die erfindungsgemäß vorgeschlagene Architektur stellt sicher, dass zwischen der Analysephase und der Designphase kein Strukturbruch auftritt. In einer Analysephase werden die für eine Softwarearchitektur benötigten Objekte identifiziert, mit Metainformationen verknüpft und als hierarchische Bäume strukturiert. Weiterhin können die Objekte lateral und horizontal miteinander vernetzt werden und über Kommunikationsmechanismen untereinander oder mit der Umgebung kommunizieren. Die Funktion einer Softwareapplikation, die auf einer Softwarearchitektur beruht, wird durch die Anordnung der Objekte zueinander bestimmt. Zur Laufzeit werden dann die Objekte zu einer Softwareapplikation zusammengesetzt, wobei die Softwareapplikation Prinzipien, die durch die Softwarearchitektur vorgegeben werden, inherent beinhaltet. Dadurch ist sichergestellt, dass kein Designbruch stattfindet.
Eine Softwarearchitektur muss unterschiedliche Aspekte, Gesichtspunkte bzw. so genannte Views berücksichtigen. Dazu gehört die Funktion, die letztendlich durch eine Softwareapplikation erreicht werden soll, die auf der Architektur basiert. Die Funktionalität findet sich üblicherweise und insbesondere in den Methoden bzw. Operationen der Objekte. Das Verhalten und die Dynamik werden insbesondere durch das Zusammenspiel der Objekte bzw. durch das Zusammenspiel der in den Objekten vorhandenen Operationen bestimmt. Der Datenaspekt wird üblicherweise über die Attribute bestimmt. Weiterhin bestimmen die Attribute die Zustände eines Objektes, wobei die Zustände auch durch die jeweiligen Verbindungen zu anderen Objekten bestimmt werden. Der Strukturaspekt beinhaltet den hierarchischen Aufbau eines Baumes mit seinen Objekten bezüglich einer "besteht aus"-Relation. In einer Softwarearchitektur wird der Strukturaspekt aber auch durch die "is a"-Relation mit eingebracht. Innerhalb einer Softwarearchitektur ist der Kommunikationsaspekt sehr wichtig, denn durch die verwendeten Kommunikationsmechanismen wird sichergestellt, dass die Objekte, die verwendet werden für eine Applikation, überhaupt miteinander Daten austauschen können, d. h. kommunizieren können. Kommunikationsmechanismen sind z. B. MQ (Message Queues), so genannte Middleware-Plattformen wie COM, DCOM oder CORBA oder auch darauf aufsetzenden Schichten wie das OPC-Protokoll (OLE for Process Control). Die Auswahl von Kommunikationsmechanismen hat einen ganz entscheidenden Einfluss auf eine Softwarearchitektur. Auch Synchronisationsmechanismen und die Fähigkeit zur Nebenläufigkeit wird dadurch beeinflusst.
Für aktuelle Softwarearchitekturen und für Softwareapplikationen, die auf ihnen beruhen, wird der Aspekt der nicht funktionalen Eigenschaften immer wichtiger. Nicht funktionale Eigenschaften sind z. B. Änderbarkeit, Effizienz, Zulässigkeit, Testbarkeit oder Wiederverwendbarkeit. Die gezielte und explizite Verwendung von Metainformationen in einer Softwarearchitektur fördert die Erfüllung von nicht funktionalen Eigenschaften enorm. Dadurch, dass die einzelnen Objekte Metainformationen nicht nur über sich selbst beinhalten, sondern auch über die Applikationen, in denen sie verwendet werden, oder in den Geschäftsprozessen, in denen sie verwendet werden, können sehr leicht selbst Organisationen einer Softwareapplikation durchgeführt werden, d. h. ein automatisches Recovery kann erfolgen, ohne dass ein Mensch eingreifen muss. Die genannten Aspekte, die für eine Softwarearchitektur wichtig sind, werden üblicherweise durch CASE-Werkzeuge (Computer- Aided Software-Engineering) mit entsprechenden Programmeditoren von einem Benutzer modelliert bzw. editiert. Diese CASE- Werkzeuge sind Bestandteil einer Softwareentwicklungsumgebung (SU; Fig. 2). Für die Beschreibung einer Softwarearchitektur, wie sie in der Erfindung vorgeschlagen wird, eignen sich u. a. die Diagramme, die die Methode UML (Unified Modeling Language) zur Verfügung stellt.
Metainformationen lassen sich durch die Verwendung von Auszeichnungssprachen (Markup Language) sehr geschickt und einfach an Objekte und auch Systeme koppeln bzw. einbringen. Insbesondere XML (Extended Markup Language) bietet Möglichkeiten, um Metainformationen leicht zu formulieren. Metainformationen können in XML z. B. als Elemente (durch ein Start- Tag und ein End-Tag eingeschlossen) oder als Attribute (direkt in eine Start-Tag integriert) hinterlegt werden.
Zusammenfassend betrifft die Erfindung Softwareapplikationen, Softwarearchitekturen und Verfahren zur Erstellung von Softwareapplikationen, insbesondere für MES-Systeme, wobei Objekte (mit Daten, Attributen, Verhalten, Funktionen) für Softwareapplikationen, insbesondere MES-Applikationen, mit Metainformationen verknüpft werden, die Objekte als hierarchische Bäume strukturiert werden (wobei unterschiedliche Darstellungsformen wählbar sind) und die Objekte miteinander verzeigert bzw. vernetzt (lateral bzw. horizontal) werden. Zur Laufzeit werden die Objekte zu Softwareapplikationen zusammengesetzt, wobei sich die Gesamtfunktion der Softwareapplikationen aus der Struktur der hierarchischen Bäume ableitet. Es können Softwareapplikationen oder Softwarearchitekturen für MES-Systeme, für Automatisierungssysteme, für industrielle Steuerungen (auch Bewegungsteuerungen) und für Büroanwendungen (Officebereich) erstellt werden.
Die oben beschriebene erfindungsgemäße Softwareapplikation bzw. Softwareentwicklungsumgebung lässt sich als Computerprogramm in dafür bekannten Sprachen implementieren. Ein derartig implementiertes Computerprogramm kann in ebenfalls bekannter Weise über elektronische Datenwege abgespeichert und transportiert werden.

Claims

1. Softwareapplikation, insbesondere MES-Applikation, mit Objekten, die Daten und/oder Attribute und/oder Verhalten beinhalten und/oder referenzieren, wobei die Objekte auf mindestens einer Rechnereinheit ablaufen und/oder gespeichert sind, dadurch gekennzeichnet, dass
die Objekte (K1-K4, K1'-K4') zur Laufzeit mit Metainformation verknüpft sind,
die Objekte (K1-K4, K1'-K4') zur Laufzeit als hierarchische Bäume (OB1, OB2) strukturiert sind,
die Objekte (K1-K4, K1'-K4') zur Laufzeit lateral und/oder horizontal vernetzt und/oder referenziert sind und
die Softwareapplikation zur Laufzeit aus den Objekten (K1 -K4, K1'-K4') zusammengesetzt wird, wobei sich die Gesamtfunktion der Softwareapplikation aus der Struktur der hierarchischen Bäume (OB1, OB2) sowie der Vernetzung der Objekte in den Bäumen ableitet.

2. Softwareapplikation nach Anspruch 1, dadurch gekennzeichnet, dass zur Laufzeit die Objekte (K1-K4, K1'-K4') und/oder Referenzierungsmechanismen und/oder Vernetzungsmechanismen und/oder Implementierungen der Objekte austauschbar sind.

3. Softwareapplikation nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass den Objekten (K1-K4, K1'-K4') zur Laufzeit Dienste hinzufügbar sind.

4. Softwareapplikation nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass Implementierungen der Referenzierungsmechanismen oder der Vernetzungsmechanismen oder der Dienste für Daten und für Programme anwendbar sind.

5. Softwareapplikation nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Objekte (K1-K4, K1'-K4') statisch und/oder dynamisch vernetzt sind.

6. Softwareapplikation nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Objekte (K1-K4, K1'-K4') die Metainformation physikalisch enthalten.

7. Softwareapplikation nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Metainformation statische und/oder dynamische Objektmodelle beinhaltet.

8. Softwareapplikation nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Metainformation eine Applikation oder einen Geschäftsprozess beschreibt.

9. Softwareapplikation nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass jedes einzelne Objekt (K1-K4, K1'-K4') die gesamte Metainformation über die Applikation oder den Geschäftsprozess beinhaltet.

10. Softwareapplikation nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass auf einer Anzeigevorrichtung (AZ1, AZ2) die Bäume (OB1, OB2) in unterschiedlichen Ansichten darstellbar sind.

11. Softwareapplikation nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass im Fehlerfall die Softwareapplikation sich selbst rekonfiguriert.

12. Softwarearchitektur, insbesondere für MES-Applikationen, mit Objekten, die Daten und/oder Attribute und/oder Verhalten beinhalten und/oder referenzieren, wobei die Objekte auf mindestens einer Rechnereinheit ablaufen und/oder gespeichert sind, dadurch gekennzeichnet, dass
die Objekte (K1-K4, K1'-K4') zur Laufzeit mit Metainformation verknüpft sind,
die Objekte (K1-K4, K1'-K4') zur Laufzeit als hierarchische Bäume (OB1, OB2) strukturiert sind,
die Objekte (K1-K4, K1'-K4') zur Laufzeit lateral und/oder horizontal vernetzt und/oder referenziert sind,
die Objekte (K1-K4, K1'-K4') zur Laufzeit untereinander und/oder mit der Umgebung durch Kommunikationsmechanismen kommunizieren und
die Softwareapplikation zur Laufzeit aus den Objekten (K1 -K4, K1'-K4') zusammengesetzt wird, wobei sich die Gesamtfunktion der Softwareapplikationen, die auf der Softwarearchitektur beruhen, aus der Struktur der hierarchischen Bäume sowie der Vernetzung der Objekte in den Bäumen bestimmt.

13. Softwarearchitektur nach Anspruch 12, dadurch gekennzeichnet, dass zur Laufzeit die Objekte (K1-K4, K1'-K4') und/oder Referenzierungsmechanismen und/oder Vernetzungsmechanismen und/oder Implementierungen der Objekte und/oder Kommunikationsmechanismen austauschbar sind.

14. Softwarearchitektur nach Anspruch 12 oder 13, dadurch gekennzeichnet, dass den Objekten (K1-K4, K1'-K4') zur Laufzeit Dienste hinzufügbar sind.

15. Softwarearchitektur nach einem der Ansprüche 12 bis 14, dadurch gekennzeichnet, dass Implementierungen der Referenzierungsmechanismen oder der Vernetzungsmechanismen oder der Kommunikationsmechanismen oder der Dienste für Daten und für Programme anwendbar sind.

16. Softwarearchitektur nach einem der Ansprüche 12 bis 15, dadurch gekennzeichnet, dass die Objekte (K1-K4, K1'-K4') statisch und/oder dynamisch vernetzt sind.

17. Softwarearchitektur nach einem der Ansprüche 12 bis 16, dadurch gekennzeichnet, dass die Objekte (K1-K4, K1'-K4') die Metainformation physikalisch enthalten.

18. Softwarearchitektur nach einem der Ansprüche 12 bis 17, dadurch gekennzeichnet, dass die Metainformation statische und/oder dynamische Objektmodelle beinhaltet.

19. Softwarearchitektur nach einem der Ansprüche 12 bis 18, dadurch gekennzeichnet, dass die Metainformation eine Applikation oder einen Geschäftsprozess beschreibt.

20. Softwarearchitektur nach einem der Ansprüche 12 bis 19, dadurch gekennzeichnet, dass jedes einzelne Objekt (K1-K4, K1'-K4') die gesamte Metainformation über die Applikation oder den Geschäftsprozess beinhaltet.

21. Softwarearchitektur nach einem der Ansprüche 12 bis 20, dadurch gekennzeichnet, dass auf einer Anzeigevorrichtung (AZ1, AZ2) die Bäume (OB1, OB2) in unterschiedlichen Ansichten darstellbar sind.

22. Softwarearchitektur nach einem der Ansprüche 12 bis 21, dadurch gekennzeichnet, dass im Fehlerfall die auf der Softwarearchitektur basierende Softwareapplikation sich selbst rekonfiguriert.

23. Verfahren zur Erstellung von Softwareapplikationen, insbesondere für MES-Systeme, basierend auf mindestens einer Rechnereinheit mit Eingabehilfsmittel, Ausgabehilfsmittel, sowie mindestens einer Anzeigevorrichtung, gekennzeichnet durch folgende Schritte:

- Erstellen von Objekten (K1-K4, K1'-K4'), die Einheiten der Softwareapplikation repräsentieren, mit den Eingabehilfsmitteln und der Anzeigevorrichtung,

- Zuordnen von Metainformationen zu den Objekten (K1-K4, K1'-K4'), mit den Eingabehilfsmitteln und der Anzeigevorrichtung,

- Strukturieren der Objekte (K1-K4, K1'-K4') als hierarchische Bäume (OB1, OB2) mit den Eingabehilfsmitteln und der Anzeigevorrichtung (AZ1, AZ2),

- Vernetzen der Objekte (K1-K4, K1'-K4') mit den Eingabehilfsmitteln und der Anzeigevorrichtung (AZ1, AZ2),

- automatisches Zusammensetzen der Objekte (K1-K4, K1'- K4') zur Laufzeit zu einer Softwareapplikation,

- automatisches Ableiten der Funktion der Softwareapplikation aus der Struktur der hierarchischen Bäume, der Vernetzung der Objekte in den Bäumen, sowie der zugeordneten Metainformationen.

24. Verfahren nach Anspruch 23, dadurch gekennzeichnet, dass zur Laufzeit die Objekte (K1-K4, K1'-K4') und/oder Referenzierungsmechanismen und/oder Vernetzungsmechanismen und/oder Implementierungen der Objekte austauschbar sind.

25. Verfahren nach Anspruch 23 oder 24, dadurch gekennzeichnet, dass den Objekten (K1-K4, K1'-K4') zur Laufzeit Dienste hinzugefügt werden.

26. Verfahren nach einem der Ansprüche 23 bis 25, dadurch gekennzeichnet, dass Implementierungen der Referenzierungsmechanismen oder der Vernetzungsmechanismen oder der Dienste für Daten und für Programme verwendet werden.

27. Verfahren nach einem der Ansprüche 23 bis 26, dadurch gekennzeichnet, dass die Objekte (K1-K4, K1'-K4') statisch und/oder dynamisch vernetzt werden.

28. Verfahren nach einem der Ansprüche 23 bis 27, dadurch gekennzeichnet, dass die Objekte (K1-K4, K1'-K4') die Metainformation physikalisch enthalten.

29. Verfahren nach einem der Ansprüche 23 bis 28, dadurch gekennzeichnet, dass die Metainformation statische und/oder dynamische Objektmodelle beinhaltet.

30. Verfahren nach einem der Ansprüche 23 bis 29, dadurch gekennzeichnet, dass die Metainformation eine Applikation oder einen Geschäftsprozess beschreibt.

31. Verfahren nach einem der Ansprüche 23 bis 30, dadurch gekennzeichnet, dass jedes einzelne Objekt (K1-K4, K1'-K4') die gesamte Metainformation über die Applikation oder den Geschäftsprozess beinhaltet.

32. Verfahren nach einem der Ansprüche 23 bis 31, dadurch gekennzeichnet, dass auf einer Anzeigevorrichtung (AZ1, AZ2) die Bäume (OB1, OB2) in unterschiedlichen Ansichten dargestellt werden.

33. Verfahren nach einem der Ansprüche 23 bis 32, dadurch gekennzeichnet, dass im Fehlerfall die Softwareapplikation sich selbst rekonfiguriert.

34. Softwarentwicklungsumgebung (SU) zur Ausführung eines Verfahrens nach einem der Ansprüche 23 bis 33, dadurch gekennzeichnet, dass die Softwareentwicklungsumgebung (SU) ins Laufzeitsystem (RTS, RTS/SU) integriert ist, wobei über Sichten auf auswählbare Funktionalitäten zugegriffen wird.

35. Computerprogramm, das eine Softwareapplikation nach einem der Ansprüche 1 bis 11 oder ein Verfahren nach einem der Ansprüche 23 bis 33 oder eine Softwareentwicklungsumgebung nach Anspruch 34 implementiert.

36. Datenträger, auf dem ein Computerprogramm nach Anspruch 35 gespeichert ist.

37. Datenverarbeitungseinrichtung, auf der ein Computerprogramm nach Anspruch 35 installiert ist.