EP0859987A2 - Computergestütztes arbeits- und informationssystem und zugehöriger baustein - Google Patents

Computergestütztes arbeits- und informationssystem und zugehöriger baustein

Info

Publication number
EP0859987A2
EP0859987A2 EP96945833A EP96945833A EP0859987A2 EP 0859987 A2 EP0859987 A2 EP 0859987A2 EP 96945833 A EP96945833 A EP 96945833A EP 96945833 A EP96945833 A EP 96945833A EP 0859987 A2 EP0859987 A2 EP 0859987A2
Authority
EP
European Patent Office
Prior art keywords
engineering
objects
abstract physical
model
window
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP96945833A
Other languages
English (en)
French (fr)
Inventor
Herbert Jung
Helmut Leng
Hermann Reiter
Thomas Zink
Fritz Reuter
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Publication of EP0859987A2 publication Critical patent/EP0859987A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/13—Architectural design, e.g. computer-aided architectural design [CAAD] related to design of buildings, bridges, landscapes, production plants or roads

Definitions

  • the invention relates to a computer-aided work and information system, in particular CAE and / or CAD system, and the module used in the process.
  • the object of the invention is therefore to create a work and information system with which especially in plant engineering niche and electrotechnical engineering, consistent documents are always generated during the plant creation process.
  • the term 'create' should also take into account the changing of documents (editing).
  • a specific application module is to be created.
  • the object is achieved according to the invention in that in the object-oriented work and information system, in which data models are used for structuring, each of which represents an abstract physical model of the objects occurring in reality, and in each of the abstract physical models Applications without their own data model are assigned, which form a window on the abstract physical model, the window visualizes the abstract physical model in an application-specific manner specifically for a technical and / or electrical engineering.
  • parts of an object are preferably brought from the abstract physical model into the application-specific window for the technical and / or electrical engineering engineering via an algorithmic processing unit. It is advantageous that an engineering chain is implemented in which the objects - mathematically speaking - are unique.
  • the system according to the invention has an abstract physical product component as an essential architectural feature.
  • the abstract physical product model describes the real objects occurring in the technical or electrical engineering in a compact and complete notation. This means that the compact notation of the objects represents a 1: 1 correspondence between the abstract physical product model and the objects occurring in reality.
  • applications are built around the abstract physical product model which are characterized by the fact that they do not have their own physical data model. Rather, an application merely represents a window on the abstract physical product model, in which the product model is visualized in a specific application of a specific type.
  • the abstract physical product model can be successively built up or modified via the window.
  • the system advantageously always enforces consistent system documentation in the entire engineering chain due to its architecture.
  • this architecture modifies and updates all documents in the individual windows, which are also referred to as so-called views, with sufficient performance for interactive operation.
  • a method can be created within the work and information system by means of which applications are always consistent objects for any additional visualizations that can be expanded in engineering during the plant creation process and the subsequent life phases of the "plant" product -specifically, for example on the connections of a product, can be generated and managed consistently.
  • the latter is realized according to the invention with an additional component, in which a single classification for the real connection classes of these objects is used for structuring defined objects, for example products and networks. For reasons of consistency, the same classification can also be used for the representations of such objects with the aid of graphic symbols.
  • the classification is thus an abstract model of all of the connection classes that occur in reality. Each object within a system is only functionally connected to its via its connections Environment in connection. Each connection of an object is integrated into a network of identical class by the class of the connection.
  • the classification can be expanded hierarchically at any level.
  • This method allows OnLine to perform a plausibility check with regard to consistency between the different connection classes of an object. Provided connections of a connection of a defined class to a network of another class or a direct connection of an object of a class to the connection of an object of another class are automatically rejected.
  • This method also allows OnLine to perform a plausibility check with regard to consistency, even between the data of the technical features assigned to a connection and the corresponding data of the features of the connection of the network of the identical connection class to be connected.
  • connection classes of a real product in plant engineering not only one class of connections is managed as before, but all required or required classes of the identical object within a plant or system.
  • connection classes of an object can be carried out with the functions of the CAE or CAD system created according to the invention.
  • identical functionalities can be achieved for the routing of any networks in the 2D and 3D environment, or for the generation of MSR, current flow and P&ID schemes.
  • FIG. 1 shows a representation of the applications for setting up an electrotechnical system documentation that are possible in accordance with the prior art
  • FIG. 2 shows the basic architectural structure of the system according to the invention
  • FIG. 3 shows a concrete implementation of FIG. 2 using the example of a motor
  • FIG. 4 shows a basic structure of an engineering chain on different platforms
  • FIG. 5 shows an architectural structure of the system that complements FIG. 2, which can form its own component
  • FIG. 6 shows a concrete implementation of FIG. 1 using the example of the representation of an electromagnetically actuated pneumatic valve with auxiliary contact for an optical fiber connection using graphic symbols.
  • FIG. 11 shows examples of possible applications for setting up an electrical system documentation as a block diagram.
  • 11 mean a unit for project management and project structuring
  • 12 a unit for a circuit diagram
  • 13 to 16 units for a terminal diagram, resource plan, parts list or the like
  • 17 a unit for the control cabinet layout. It is important here that the data go from unit 11 to unit 12 and from there to units 13 to 16.
  • the control cabinet layout can be generated from unit 16 for the parts list.
  • Each of the units 11 to 17 has its own data structure, for example the unit 11 the data structure A, the unit 12 the data structure B, etc.
  • the unit 17 for the control cabinet layout accordingly has the data structure G.
  • terminal designation on the terminal strip is changed in the application according to unit 13 (terminal diagram) for technical reasons, the logical description of the circuit in the circuit diagram is initially unaffected.
  • the consistency of the documents, that is to say the circuit diagram and the terminal diagram, can only be ensured by manually making changes in the application in accordance with unit 12 (circuit diagram).
  • FIG. 2 shows the basic architectural structure of a new CAE system for electrical engineering (ET) or for electrical, measuring and control technology (EMSR).
  • 20 means a physical and consistent product model in an object-oriented database (OODB), which is surrounded by individual sectors 21 to 28 and has a bi-directional data connection with these sectors.
  • 21 means the application "equipment diagram”
  • 22 the application “circuit diagram”
  • 23 the application “terminal diagram”
  • 24 the application "wiring lists”
  • 25 the application "PLC total representation”
  • 26 the application "parts lists”
  • 27 the application "cables etc.”
  • the abstract physical product model is successively built up or modified via these so-called views.
  • Modifications in a view - corresponding to one of the applications 21 to 28 - mean the automatic updating of the other application-specific views, because the other application-specific views only represent the graph, i.e. represent the visualization of the abstract physical product model. Only parts of an object that are of interest in this engineering discipline are also visualized in the view. For example, a "component" object is visualized in the circuit diagram with its logical function, in the terminal diagram, among other things, with its connection designations, in the parts list with its order data.
  • a physical product model for an engine is designated by 30 in FIG.
  • the elements of this physical and consistent product model stored in the object-oriented database (OODB) include, for example, a group 31, which describe the logical function of the engine, and for example another group 32, which contains a pure enumeration.
  • the physical product model 30 of the motor can, for example, generate a first window 34 which visualizes the circuit diagram.
  • a unit 35 with a specific visualization algorithm which, however, does not contain its own data structure. It is thus achieved that the view "circuit diagram" with its own algorithm accordingly the unit 35 interprets and visualizes the information of the physical product model 30 relevant to the application for the motor.
  • the relevant information summarized in the unit 31 is used for this.
  • the parts list can be displayed in another window 36, here again a unit 37 having its own visualization algorithm, which likewise does not have its own data structure, is connected upstream.
  • the parts list is interpreted and visualized with its own algorithm, in which case the relevant information from the physical product model 30 is used for the engine by the sub-group 32.
  • the circuit diagram automatically receives the changed designation through the software architecture described.
  • the physical product model 30 only one object always represents the representative for specific ones The latter is the intersection of groups 31 and 32, ie specifically the area covered by the rectangle and the ellipse in Figure 3.
  • the decisive factor here is that the two windows 34 and 36 with the respective views do not have their own possess physical data structure, but rather interpret and visualize parts of the physical product model 30 for the motor with the view-specific algorithm.
  • OODB object-oriented database
  • HW hardware
  • FIG. 4 shows in detail that multi-users, concurrent engineering and interoperability are possible via different platforms.
  • 40 represents an OODB server, which runs, for example, on a Unix and / or Windows platform and to which the data according to OODB is assigned in a unit 41, the unit 41 likewise being on a UNIX and / or Windows platform is running.
  • Two users 46 and 47 are exemplarily shown, of whom one 46 has a PC with Windows and the other 47 has a workstation with UNIX. For example, the views “project structure / project management” and “circuit diagram” are displayed for the user 46 and the views “terminal plan, parts list” for the user 47.
  • FIGS. 2 to 4 A computer-aided work and information system was described with the aid of FIGS. 2 to 4, with which a continuously object-oriented engineering of a system is possible.
  • Project structuring, circuit diagrams, parts lists, terminal diagrams etc. always fit together in the system documents created in this way. If, for example, the terminal names are changed in the terminal editor, all documents on which the terminal names also appear are automatically updated accordingly.
  • An open circuit diagram document shows the current changed terminals.
  • the engineering of the terminals can be carried out in a terminal editor on a hardware platform A by a project engineer AI, whereby the engineer Bl on the hardware platform B immediately sees the current circuit diagram document.
  • FIGS. 2 to 4 show the basic architectural structure of the new CAE system with an additional module.
  • 100 means an object with connections in the object-oriented database (OODB) as a subgroup of the object 20 from FIG. 2, which is surrounded by individual sectors 101 to n and is in bidirectional data connection with these sectors.
  • OODB object-oriented database
  • sector 101 means the view of the overall object, documented e.g. in various function, product and location-oriented applications of a resource plan.
  • Sector 102 means the view of the electrical connections, in turn documented in various function, product and location-oriented applications.
  • Sector 103 means the view of the material-carrying connections, possibly subclassified, also documented in various function, product and location-oriented applications.
  • the individual applications are designated in FIG. 5 with 111, 112, with 113, 121, 122, 123, ... etc for parts lists, connection diagram lists and schematic diagrams, ... etc.
  • the abstract physical product model can be successively built up or modified via these views.
  • FIG. 6 The implementation of the object in individual views for specific applications is explained with reference to FIG. 6 for the example of an electromagnetically operated pneumatic valve:
  • the reference symbols 130 symbolize an electrical conductor, 140 a material-carrying conductor (valve) and 150 an optical conductor (LWL), which Units are coupled by a mechanical knitting network 160.
  • window 180 different views are on the one hand an overall view of the object and through the windows 181 to 184, on the other hand, partial views of the mechanical active networks. Possible on the electrical conductors, on the material-carrying conductors and on the optical conductors.
  • FIG. 6 shows that for the first time all the connections of an object can be considered in their entirety by the proposed method and can be visualized in the various applications by means of specific software-based processing units that contain a predetermined algorithm. It can also be seen that the processing units used in one sector can also be applied to any other of the sectors.
  • CAE Computer Aided Engineering
  • CAD Computer Aided Design
  • ESR electrical engineering

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Geometry (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Mathematical Optimization (AREA)
  • Computational Mathematics (AREA)
  • Architecture (AREA)
  • Mathematical Analysis (AREA)
  • Structural Engineering (AREA)
  • Pure & Applied Mathematics (AREA)
  • Evolutionary Computation (AREA)
  • General Engineering & Computer Science (AREA)
  • Civil Engineering (AREA)
  • Stored Programmes (AREA)
  • Digital Computer Display Output (AREA)

Abstract

Vom Stand der Technik sind CAE- und/oder CAD-Systeme bekannt. Gemäss der Erfindung ist das System derart ausgebildet, dass ein objektorientiertes Engineering einer Anlage mit hinreichender Performance für die interaktive Bedienung möglich ist. Dazu ist insbesondere ein Datenmodell vorhanden, das die in der Realität vorkommenden Objekte des Anlagenbaus in einem physischen Produktmodell abbildet. Um das abstrakte physische Produktmodell sind Applikationen gebaut, die kein eigenes Datenmodell haben. Die Applikationen bilden ein Fenster auf das abstrakte physische Modell, wobei das Fenster das abstrakte physische Modell applikationsspezifisch speziell für ein anlagentechnisches und/oder elektrotechnisches Engineering visualisiert. Ein Baustein zur Anwendung bei diesem System verwendet eine einzige Klassifikation bei der Strukturierung definierter Objekte.

Description

Beschreibung
Computergestütztes Arbeits- und Informationssystem und zuge¬ höriger Baustein
Die Erfindung bezieht sich auf ein computergestütztes Ar¬ beits- und Informationssystem, insbesondere CAE und/oder CAD- System, und dabei verwendeter Baustein.
Die Projektierung bzw. das Engineering einer großtechnischen Anlage erfolgt heutzutage in der Praxis bereits weitgehend computergestützt. Insbesondere beim anlagentechnischen und elektrotechnischen Engineering tritt das Problem auf, daß im Anlagen-Entstehungsprozeß konsistente Dokumente erzeugt wer- den müssen bzw. daß auf konsistenten Dokumenten aufsetzend das Engineering modifiziert werden muß.
Beispielsweise bei der Anlagendokumentation wird bisher durch manuelle Nacharbeit versucht, die Dokumentation durchgehend konsistent zu gestalten. Weitergehende Ansätze versuchen, durch zeitintensive post-processing-Läufe die verschiedenen Datenmodelle der am Anlagenentstehungsprozeß beteiligten Dis¬ ziplinen/Applikationen abzugleichen. Der Abgleich kann nur eine Partiallösung darstellen, weil im allgemeinen Fall die verschiedenen Datenmodelle nicht bijektiv abbildbar sind.
Mit der Veröffentlichung "Die Zukunft ist objektorientiert" (CAD-CAM REPORT Nr. 4, S.90 - 100 (1995)) wird auf die Mög¬ lichkeit der Realisierung reaktiver Systeme hingewiesen. Die bestehende Hardwareleistung wird dort aber als noch ungenü¬ gend bezeichnet und es werden für die Zukunft entsprechende Software-Algorithmen gefordert, da zur praktischen Ausführung beim Anlagenengineering umfangreiche Datenmengen bewegt wer¬ den müssen.
Aufgabe der Erfindung ist es daher, ein Arbeits- und Informa¬ tionssystem zu schaffen, mit dem speziell im anlagentech- nischen und elektrotechnischen Engineering während des An¬ lagenentstehungsprozesses immer konsistente Dokumente erzeugt werden. Mit dem Begriff 'Erzeugen' soll auch das Verändern von Dokumenten (Editieren) berücksichtigt werden. Weiterhin soll ein spezifischer Applikationsbaustein geschaffen werden.
Die Aufgabe ist erfindungsgemäß dadurch gelöst, daß beim ob¬ jektorientiert ausgebildeten Arbeits- und Informations¬ system, bei dem zur Strukturierung Datenmodelle verwendet werden, die jeweils ein abstraktes physisches Modell der in der Realität vorkommenden Objekte darstellen, und bei dem den abstrakten physischen Modellen jeweils Applikationen ohne ei¬ genes Datenmodell zugeordnet sind, die ein Fenster auf das abstrakte physische Modell bilden, das Fenster das abstrakte physische Modell applikationsspezifisch speziell für ein an¬ lagentechnisches und/oder elektrotechnisches Engineering vi¬ sualisiert. Vorzugsweise werden zur Visualisierung Teile je¬ weils eines Objektes über eine algorithmische Verarbeitugs- einheit vom abstrakten physischen Modell in das für das anla- gentechnische und/oder elektrotechnische Engineering applika¬ tionsspezifische Fenster gebracht. Dabei ist vorteilhaft, daß eine Engineeringkette realisiert ist, in der die Objekte - mathematisch gesehen - eindeutig sind.
Mit der Erfindung ist erstmalig ein durchgehend objektorien¬ tiertes Engineering in der gesamten anlagentechnischen und/oder elektrotechnischen Engineeringkette möglich. Dabei besitzt das System gemäß der Erfindung als wesentliches ar¬ chitektonisches Merkmal ein abstraktes physisches Produkt- modeil. Das abstrakte physische Produktmodell beschreibt die im anlagentechnischen bzw. elektrotechnischen Engineering vorkommenden realen Objekte in einer kompakten und vollstän¬ digen Notation. Dies bedeutet, daß die kompakte Notation der Objekte eine l:l-Korrespondenz zwischen abstraktem physischem Produktmodell und der in der Realität vorkommenden Objekte darstellt. Als weiteres architektonisches Merkmal werden um das ab¬ strakte physische Produktmodell Applikationen gebaut, die sich dadurch auszeichnen, kein eigenes physisches Datenmodell zu besitzen. Vielmehr stellt eine Applikation lediglich je- weils ein Fenster auf das abstrakte physische Produktmodell dar, in der das Produktmodell in einer bestimmten Applikation spezifischer Art visualisiert wird. Ober das Fenster kann das abstrakte physische Produktmodell sukzessive aufgebaut bzw. modifiziert werden.
Bei der Erfindung erzwingt in vorteilhafter Weise das System durch seine Architektur immer eine konsistente Anlagendoku¬ mentation in der gesamten Engineeringkette. Insbesondere die¬ se Architektur modifiziert und aktualisiert dann mit einer für eine interaktive Bedienung hinreichenden Performance alle Dokumente in den einzelnen Fenstern, die auch als sogenannte Views bezeichnet werden.
Als ergänzender Bestandteil der Erfindung kann eine Methode innerhalb des Arbeits- und Informationssystem geschaffen wer¬ den, mit der im Engineering während des Anlagen- Entstehungsprozesses und den folgenden Lebensphasen des Pro¬ duktes "Anlage" immer konsistente Objekte für beliebig erwei¬ terbare zusätzliche Visualisierungen applikations-spezifisch, beispielsweise auf die Anschlüsse eines Produktes, konsistent erzeugt und verwaltet werden.
Letzteres wird erfindungsgemäß mit einem zusätzlichen Bau¬ stein realisiert, bei dem zur Strukturierung definierter Ob- jekte, z.B. von Produkten und Netzwerken, eine einzige Klas¬ sifikation für die realen Anschlußklassen dieser Objekte ver¬ wendet wird. Dieselbe Klassifikation ist aus Konsistenz¬ gründen auch für die Repräsentationen solcher Objekte mit Hilfe graphischer Symbole zu verwenden. Die Klassifikation ist somit ein abstraktes Modell aller der in der Realität vorkommenden Anschlußklassen. Jedes Objekt innerhalb einer Anlage steht funktional nur über seine Anschlüsse mit seiner Umwelt in Verbindung. Jeder Anschluß eines Objektes ist durch die Klasse des Anschlusses in ein Netzwerk identischer Klas¬ se eingebunden. Die Klassifizierung läßt sich auf jeder Ebene beliebig hierarchisch erweitern.
Die Einführung dieser Methode erlaubt OnLine eine Plausi- bilitätsprüfung hinsichtlich Konsistenz zwischen den unter¬ schiedlichen Anschlußklassen eines Objektes. Vorgesehene Ver¬ bindungen eines Anschlusses einer definierten Klasse an ein Netzwerk einer anderen Klasse oder einen direkten Anschluß eines Objektes einer Klasse an den Anschluß eines Objektes einer anderen Klasse werden automatisch zwangsweise abgewie¬ sen.
Die Einführung dieser Methode erlaubt weiterhin OnLine eine Plausibilitätsprüfung hinsichtlich Konsistenz auch zwischen den Daten der einem Anschluß zugewiesenen technischen Merkma¬ le und den entsprechenden Daten der Merkmale des anzuschlie¬ ßenden Anschlusses des Netzwerkes der identischen Anschluß- klasse.
Durch die Spezifikation aller Anschlußklassen eines realen Produktes im Anlagenbau wird nicht wie bisher nur eine Klasse von Anschlüssen verwaltet, sondern alle erforderlichen bzw. benötigten Klassen des identischen Objektes innerhalb einer Anlage bzw. eines Systems.
Besonders vorteilhaft ist, daß die Bearbeitung der verschie¬ denen Views auf die Anschlußklassen eines Objektes mit den Funktionen des erfindungsgemäß geschaffenen CAE- bzw. CAD- Systems abgewickelt werden kann. Beispielsweise können iden¬ tische Funktionalitäten für das Routing aller beliebigen Net¬ ze im 2D- und 3D-Umfeld, oder das Erzeugen von MSR-, Strom¬ lauf- sowie P&ID Schemata erreicht werden.
Weitere Einzelheiten und Vorteile der Erfindung ergeben sich aus der nachfolgenden Figurenbeschreibung eines Ausführungs- beispiels anhand der Zeichnung in Verbindung mit weiteren Un¬ teransprüchen. Es zeigen
Figur 1 eine Darstellung der gemäß dem Stand der Technik ex- emplarisch möglichen Applikationen zum Aufbau einer elektrotechnischen Anlagendokumentation, Figur 2 den prinzipiellen architektonischen Aufbau des Sy¬ stems gemäß der Erfindung, Figur 3 eine konkrete Realisierung der Figur 2 am Beispiel eines Motors,
Figur 4 einen prinzipiellen Aufbau einer Engineeringkette auf unterschiedlichen Plattformen, Figur 5 ein zu Fig. 2 ergänzenden architektonischen Aufbau des Systems, der einen eigenen Baustein bilden kann, und
Figur 6 eine konkrete Realisierung der Figur 1 am Beispiel der Repräsentation eines elektromagnetisch betätigten pneumatischen Ventils mit Hilfskontakt für einen LWL- Anschluß mittels grafischer Symbole.
Beim Engineering von Anlagen ist die Anlagendokumentation von wesentlicher Bedeutung. In Figur 1 sind exemplarisch mögliche Applikationen zum Aufbau einer elektrotechnischen Anlagen¬ dokumentation als Blockschaltbild dargestellt. Dabei bedeuten 11 eine Einheit für die ProjektVerwaltung und zur Projekt- strukturierung, 12 eine Einheit für einen Stromlaufplan, 13 bis 16 Einheiten für Klemmenplan, Betriebsmittelplan, Stück¬ liste od. dgl. und 17 eine Einheit für das Schaltschrank- Layout. Wesentlich ist dabei, daß aus der Einheit 11 die Da- ten zur Einheit 12 gehen und von dort zu den Einheiten 13 bis 16. Aus der Einheit 16 für die Stückliste läßt sich das Schaltschrank-Layout generieren. Jede der Einheiten 11 bis 17 hat dabei eine eigene Datenstruktur, beispielsweise die Ein¬ heit 11 die Datenstruktur A, die Einheit 12 die Datenstruktur B, usw.. Die Einheit 17 für das Schaltschrank-Layout hat dem¬ zufolge die Datenstruktur G. Wenn aus technischen Notwendigkeiten heraus in der Applika¬ tion gemäß Einheit 13 (Klemmenplan) die Klemmenbezeichnung auf der Klemmenleiste verändert wird, ist zunächst die logi¬ sche Beschreibung der Schaltung im Stromlaufplan davon unbe- rührt. Nur durch manuelles Nachziehen der Änderung in der Ap¬ plikation gemäß Einheit 12 (Stromlaufplan) kann die Kon¬ sistenz der Dokumente, d.h. Stromlaufplan und Klemmenplan, sichergestellt werden.
Letztere Problematik verschärft sich, wenn die Verkettung der Applikationen für das Anlagen-Engineering länger wird. Aus Figur 1 ist ersichtlich, daß bei Modifikationen der Be¬ stückung in der Einheit 17 für das Schaltschrank-Layout erst ein manuelles Nachziehen des Stromlaufplanes und der Stück- liste die Wiederherstellung der konsistenten Engineering- Dokumente zur Folge hat. Damit sind aber insbesondere bei längeren Engeneeringketten entsprechende Fehlerquellen ver¬ bunden.
In Figur 2 ist der prinzipielle architektonische Aufbau eines neuen CAE-Systems für die Elektrotechnik(ET) bzw. für die Elektro-, Meß- und Regeltechnik(EMSR) wiedergegeben. Dabei bedeutet 20 ein physisches und konsistentes Produktmodell in einer objektorientierten Datenbank(OODB) , das von einzelnen Sektoren 21 bis 28 umgeben ist und mit diesen Sektoren in bi- direktioneller Datenverbindung steht. Beispielsweise bedeutet 21 die Applikation "Betriebsmittelplan", 22 die Applikation "Stromlaufplan", 23 die Applikation "Klemmenplan", 24 die Ap¬ plikation "Verdrahtungslisten", 25 die Applikation "SPS Ge- samtdarstellung", 26 die Applikation "Stücklisten", 27 die Applikation "Kabel etc.". Wesentlich ist dabei, daß das ab¬ strakte physische Produktmodell 20 ein physisches Datenmodell beinhaltet, während die darum gebauten Applikationen kein ei¬ genes physisches Datenmodell besitzen. Vielmehr stellen die Applikationen lediglich jeweils ein Fenster ("View") auf das abstrakte physische Produktmodell 20 dar, in der das Produkt¬ modell in einer applikationspezifischen Art visualisiert wird. Über diese sogenannten Views wird das abstrakte physi¬ sche Produktmodell sukzessive aufgebaut bzw. modifiziert.
Modifikationen in einer View - entsprechend einer der Appli- kationen 21 bis 28 - bedeuten die automatische Aktualisierung der anderen applikationsspezifischen Views, weil die anderen applikationsspezifischen Views lediglich die graphische Re¬ präsentation, d.h. die Visualisierung des abstrakten physi¬ schen Produktmodells, darstellen. Es werden auch nur die Tei- le eines Objektes in der View visualisiert, die in dieser En¬ gineering-Disziplin von Interesse sind. Beispielsweise visua¬ lisiert sich ein Objekt "Bauteil" im Stromlaufplan mit seiner logischen Funktion, im Klemmenplan dagegen unter anderem mit seinen Anschlußbezeichnungen, in der Stückliste mit seinen Bestelldaten.
Die Umsetzung des Objektes in einzelne Views für bestimmte Applikationen wird anhand Figur 3 für das Beispiel eines Mo¬ tors beschrieben. Es wird deutlich, daß dafür jeweils nur Teile des Objektes verwendet werden und mittels spezifischer Verarbeitungseinheiten, die einen vorgegebenen Algorithmus beinhaltet, visualisiert werden. Die Visualisierungsmethoden sind dabei software-gestützt.
In Figur 3 ist ein physisches Produktmodell für einen Motor mit 30 bezeichnet. Die Elemente dieses in der objektorien¬ tierten Datenbank (OODB) abgespeicherten physischen und kon¬ sistenten Produktmodells beinhalten beispielsweise eine Grup¬ pe 31, welche die logische Funktion des Motors beschreiben, und beispielsweise eine andere Gruppe 32, welche eine reine Aufzählung beinhaltet. Entsprechend Figur 2 läßt sich vom physischen Produktmodell 30 des Motors beispielsweise ein er¬ stes Fenster 34 generieren, welches den Stromlaufplan visua¬ lisiert. Dazu ist eine Einheit 35 mit einer spezifischen Vi- sualisierungsalgorythmik vorhanden, die jedoch keine eigene Datenstruktur beinhaltet. Es wird somit erreicht, daß die View „Stromlaufplan" mit der eigenen Algorithmik entsprechend der Einheit 35 die aus der Anwendungssieht relevanten Infor¬ mationen des physischen Produktmodells 30 für den Motor in¬ terpretiert und visualisiert. Dafür werden die in der Einheit 31 zusammengefaßten relevanten Informationen verwendet.
Ganz entsprechend kann in einem anderen Fenster 36 die Stück¬ liste dargestellt werden, wobei hier wiederum eine Einheit 37 mit einer eigenen Visualisierungsalgorythmik vorgeschaltet ist, die ebenfalls keine eigene Datenstruktur hat. Es wird so in der View "Stückliste" die Stückliste mit einer eigenen Al- gorithmik interpretiert und visualisiert, wobei in diesem Fall die relevanten Informationen aus dem physischen Produkt¬ modell 30 für den Motor durch die Untergruppe 32 verwendet wird.
Wird nun beispielsweise in der View „Stückliste" die Bezeich¬ nung Ml geändert, erhält der Stromlaufplan automatisch durch die beschriebene Software-Architektur die geänderte Bezeich¬ nung. Dabei wird deutlich, daß im physischen Produktmodell 30 immer nur ein Objekt den Repräsentanten für spezifische an¬ lagentechnische Merkmale darstellt. Letzterer ist die Schnittmenge der Gruppen 31 und 32, d.h. konkret, die gemein¬ sam vom Rechteck und der Ellipse in Figur 3 überstrichene Fläche. Entscheidend ist dabei, daß die beiden Fenster 34 und 36 mit den jeweiligen Views keine eigene physische Daten¬ struktur besitzen, sondern vielmehr mit der viewspezifischen Algorithmik Teile des physischen Produktmodells 30 für den Motor interpretieren und visualisieren.
Der Aufbau und die Modifikation des in der objektorientierten Datenbank (OODB) befindlichen physischen Produktmodells wird für das objektorientierte Engineering durch eine Client-Ser¬ ver-Architektur unterstützt, wobei die Clients mit den oben beschriebenen Views und die Server auf verschiedenen Hard- wäre(HW) -Plattformen laufen können. Dadurch wird eine trans¬ parente und gleichzeitige Projektbearbeitung unterstützt, selbst wenn der eine Client auf MS/Windows und der andere Client auf UNIX operiert.
Die Figur 4 zeigt im einzelnen, daß Multi-User, Concurrent- Engineering und Interoperabilität über verschiedene Platt¬ formen möglich sind. Im einzelnen stellt 40 einen OODB-Server dar, der beispielsweise auf einer Unix- und/oder Windows- Plattform läuft und dem in einer Einheit 41 die Daten gemäß OODB zugeordnet sind, wobei die Einheit 41 ebenfalls auf ei- ner UNIX- und/oder Windows-Plattform läuft. Es sind exem¬ plarisch zwei Nutzer 46 und 47 dargestellt, von denen der ei¬ ne Nutzer 46 einen PC mit Windows und der andere Nutzer 47 eine Workstation mit UNIX hat. Beispielsweise werden beim Nutzer 46 die Views „Projektstruktur/Projektverwaltung" und "Stromlaufplan" angezeigt und beim Nutzer 47 der Views "Klemmenplan, Stückliste" .
Bei der gemäß Figur 4 beschriebenen Client-Server-Architektur ist eine vollständige Interoperabilität zwischen den unter- schiedlichen Systemen gegeben.
Anhand der Figuren 2 bis 4 wurde ein computergestütztes Ar¬ beits- und Informationssystem beschrieben, mit dem ein durch¬ gehend objektorientiertes Engineering einer Anlage möglich ist. In den damit geschaffenen Anlagendokumenten passen Pro- jektstrukturierung, Stromlaufplan, Stücklisten, Klemmenplan etc. immer zusammen. Ändert man beispielsweise im Klemmen- Editor Klemmenbezeichnungen, so werden entsprechend alle Do¬ kumente geändert, auf denen die Klemmenbezeichnungen auch auftreten, automatisch aktuell gehalten. Ein aufgeblendetes Stromlaufplandokument zeigt die aktuellen geänderten Klemmen an. Dabei kann das Engineering der Klemmen in einem Klemmen- Editor auf einer HW-Plattform A von einem Projekteur AI durchgeführt werden, wobei der Projekteur Bl auf der HW- Plattform B sofort das aktuelle Stromlaufplandokument sieht. Entsprechendes gilt für die anderen anlagentechnischen Diszi¬ plinen analog, beispielsweise Stücklisten für Bestellung, Projektverwaltung/Projektstrukturierung, Betriebsmittelplan, EMR-Stellenplan oder Schaltschrank-Layout.
Beim Engineering gemäß den Figuren 2 bis 4 ist also eine in der Engineeringkette durchgehend konsistente Anlagendokumen¬ tation gewährleistet. In Figur 5 ist der prinzipielle archi¬ tektonische Aufbau des neuen CAE-Systems mit zusätzlichem Baustein wiedergegeben. Dabei bedeutet 100 ein Objekt mit An¬ schlüssen in der objektorientierten Datenbank(OODB) als Un- tergruppe des Objektes 20 aus Fig. 2, das von einzelnen Sek¬ toren 101 bis n umgeben ist und mit diesen Sektoren in bidi¬ rektionaler Datenverbindung steht.
Beispielsweise bedeutet der Sektor 101 die Sicht auf das Ge- samtobjekt, dokumentiert z.B. in verschiedenen funktions-, produkt- und ortsorientierten Applikationen eines Betriebs¬ mittelplans. Sektor 102 bedeutet die Sicht auf die elektri¬ schen Anschlüsse, dokumentiert wiederum in verschiedenen funktions-, produkt- und ortsorientierten Applikationen. Sek- tor 103 bedeutet die Sicht auf die materialführenden An¬ schlüsse, ggf. subklassifiziert, dokumentiert ebenfalls in verschiedenen funktions-, produkt- und ortsorientierten Ap¬ plikationen. Die einzelnen Applikationen sind in Fig. 5 je¬ weils mit 111,112, mit 113,121, 122,123,...etc für Stückli- sten, Anschlußplanlisten und Schemapläne,... etc bezeichnet. Entsprechendes gilt analog für die weiteren Sektoren 104 bis n. Ober diese Views kann das abstrakte physische Produktmo¬ dell sukzessive aufgebaut bzw. modifiziert werden.
Die Umsetzung des Objektes in einzelne Views für bestimmten Applikationen wird anhand Figur 6 für das Beispiel eines elektromagnetisch betätigten pneumatischen Ventils erläutert: Dabei symbolisieren die Bezugszeichen 130 einen elektrischen Leiter, 140 einen materialführenden Leiter (Ventil) und 150 einen optischen Leiter(LWL), welche Einheiten durch ein me¬ chanisches Wirknetz 160 gekoppelt sind. Als unterschiedliche Views sind gemäß Fenster 180 einerseits eine Gesamtansicht des Objektes sowie durch die Fenster 181 bis 184 andererseits jeweils Teilansichten auf die mechanischen Wirknetze. Auf die elektrischen Leiter, auf die materialführenden Leiter und auf die optischen Leiter möglich.
Durch Fig.6 wird verdeutlicht, daß durch die vorgeschlagene Methode erstmals gesamtheitlich alle Anschlüsse eines Objek¬ tes betrachtet werden können und mittels spezifischer soft- ware-gestützter Verarbeitungseinheiten, die einen vorgegebe- nen Algorithmus beinhalten, in den verschiedenen Applikatio¬ nen visualisiert werden. Weiterhin ist ersichtlich, daß die in einem Sektor angewendeten Verarbeitungseinheiten auf jeden anderen der Sektoren gleichfalls angewendet werden kann.
Das beschriebene System wurde als CAE(Computer Aided Engi¬ neering) -System oder als CAD(Computer Aided Design) -System speziell für die Elektrotechnik (ET) beschrieben. Die glei¬ chen Prinzipien können auch speziell für das Fachgebiet Elek¬ trotechnik, Messen, Stellen und Regeln (EMSR) angewandt wer- den.

Claims

Patentansprüche
1. Computergestütztes Arbeits- und Informationssystem, insbe¬ sondere CAE- und/oder CAD-System, das objektorientiert ausge- bildet ist und bei dem zur Strukturierung Datenmodelle ver¬ wendet werden, die jeweils ein abstraktes physisches Modell der in der Realität vorkommenden Objekte darstellen, und bei dem der abstrakten physischen Modellen jeweils Applikationen ohne eigenes Datenmodell zugeordnet sind, die ein Fenster auf das abstrakte physische Modell bilden, wobei das Fenster das abstrakte physische Modell applikationsspezifisch speziell für ein anlagentechnisches und/oder elektrotechnische Engi¬ neering visualisiert.
2. System nach Anspruch 1, d a d u r c h g e k e n n ¬ z e i c h n e t , daß zur Visualisierung Teile jeweils eines Objektes über eine algorithmische Verarbeitungseinheit vom abstrakten physischen Modell in das für das anlagentech¬ nische und/oder elektrotechnische Engineering applikations- spezifische Fenster gebracht werden.
3. System nach Anspruch 2, d a d u r c h g e k e n n ¬ z e i c h n e t , daß von der algorithmischen Verarbei¬ tungseinheit eine Engineeringkette realisiert wird, in der die Objekte eieineindeutig sind sowie ggf. fortlaufend mit Informationenen angereichert werden.
4. System nach Anspruch 2, d a d u r c h g e k e n n ¬ z e i c h ne t , daß das anlagentechnische und/oder elektro- technische Engineering Objekte zum Messen, Stellen, Regeln (MSR) umfaßt.
5. System nach einem der vorhergehenden Ansprüche, g e ¬ k e n n z e i c h n e t durch eine Ablauffähigkeit auf un- terschiedlichen HW-Plattformen.
6. System nach einem der vorhergehenden Ansprüche, g e ¬ k e n n z e i c h n e t durch einen Client-Server-Betrieb.
7. System nach Anspruch 1 oder einem der Ansprüche 2 bis 6, d a d u r c h g e k e n n z e i c h n e t , daß in der gesamten Engineeringkette eine konsistente Anlagendokumenta¬ tion gewährleitet ist.
8. Baustein zur Anwendung bei einem Computergestützten Infor- mationssystem nach Anspruch 1 oder einen der Ansprüche 2 bis
7, d a d u r c h g e k e n n z e i c h n e t , daß zur Strukturierung definierter Objekte, beispielsweise von Pro¬ dukten und Netzwerken, eine einzige Klassifikation für die realen Anschlußklassen der Objekte verwendet wird.
9. Baustein nach Anspruch 7, d a d u r c h g e k e n n ¬ z e i c h n e t , daß für graphische Symbole der Objekte die gleiche Klassifikation verwendet wird.
10. Baustein nach Anspruch 8 oder Anspruch 9, d a ¬ d u r c h g e k e n n z e i c h n e t , daß die Objekte innerhalb einer Anlage nur über Anschlüsse mit der Umwelt in Verbindung stehen.
11. Baustein nach Anspruch 10, d a d u r c h g e ¬ k e n n z e i c h n e t , daß die Anschlüsse eines Objektes durch eine Klassifikation des Anschlusses in ein Netzwerk identischer Klasse eingebunden ist, so daß eine einzige Klas¬ sifikation realisiert ist.
EP96945833A 1995-10-27 1996-10-25 Computergestütztes arbeits- und informationssystem und zugehöriger baustein Withdrawn EP0859987A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE19540181 1995-10-27
DE19540181 1995-10-27
PCT/DE1996/002040 WO1997015877A2 (de) 1995-10-27 1996-10-25 Computergestütztes arbeits- und informationssystem und zugehöriger baustein

Publications (1)

Publication Number Publication Date
EP0859987A2 true EP0859987A2 (de) 1998-08-26

Family

ID=7776024

Family Applications (1)

Application Number Title Priority Date Filing Date
EP96945833A Withdrawn EP0859987A2 (de) 1995-10-27 1996-10-25 Computergestütztes arbeits- und informationssystem und zugehöriger baustein

Country Status (3)

Country Link
EP (1) EP0859987A2 (de)
DE (1) DE19644481A1 (de)
WO (1) WO1997015877A2 (de)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19914216A1 (de) * 1999-03-29 2000-10-12 Siemens Ag Verfahren zum automatischen Zuweisen von Adressen in Sende- und Empfangspuffern
IT1314049B1 (it) * 1999-10-15 2002-12-03 Abb Ricerca Spa Sistema computerizzato integrato per implementare metodi diprogettazione e preventivazione di sistemi elettrici e/o
DE10013037A1 (de) 2000-03-17 2001-10-18 Siemens Ag Verfahren zur Projektierung einer elektrischen Anlage und Projektierungsvorrichtung
WO2001097095A2 (en) * 2000-06-13 2001-12-20 Industria Solutions, Incorporated Systems and methods for the collaborative design, construction, and maintenance of fluid processing plants
DE10046742A1 (de) * 2000-09-21 2002-04-11 Daimler Chrysler Ag Vorrichtung und Verfahren für ein Fahrzeugentwurfssytem
WO2002037341A1 (fr) * 2000-10-27 2002-05-10 Mitsubishi Denki Kabushiki Kaisha Procede de support de plan d'installation, ordinateur serveur de systeme de support de plan d'installation, et ordinateur client de systeme de plan d'installation
DE10111537A1 (de) * 2001-03-10 2002-09-19 Daimler Chrysler Ag Datenverarbeitungs- und Informationssystem
WO2003005249A2 (en) * 2001-07-04 2003-01-16 Kinematik Research Limited An information management and control system
DE10204310A1 (de) * 2002-02-01 2003-08-14 Correct Software Gmbh Verfahren zur Steuerung eines Computers
JP4058289B2 (ja) * 2002-04-09 2008-03-05 株式会社東芝 プラント機器の寿命診断・保守管理方法および装置
DE10254536A1 (de) 2002-11-21 2004-06-03 Siemens Ag Layout-orientierte Erfassung von Automatisierungsinformationen
DE10257612A1 (de) * 2002-12-09 2004-06-24 Siemens Ag System zur Generierung von Code
DE10352376A1 (de) * 2003-11-10 2005-06-16 Siemens Ag Datenplattform für die Erstellung von Produktionsanlagen
DE102004007229A1 (de) * 2004-02-13 2005-09-08 Siemens Ag Projektierungsverfahren für ein Automatisierungssystem
DE102004023634B4 (de) * 2004-05-10 2007-09-27 Siemens Ag Verfahren zur Vollständigkeits- und Konsistenzprüfung einer Informationsbibliothek

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5526517A (en) * 1992-05-15 1996-06-11 Lsi Logic Corporation Concurrently operating design tools in an electronic computer aided design system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9715877A2 *

Also Published As

Publication number Publication date
WO1997015877A3 (de) 1997-06-19
WO1997015877A2 (de) 1997-05-01
DE19644481A1 (de) 1997-04-30

Similar Documents

Publication Publication Date Title
WO1997015877A2 (de) Computergestütztes arbeits- und informationssystem und zugehöriger baustein
DE102006027202A1 (de) Kraneinsatzplaner
EP2081415A1 (de) Mikrokontroller-gesteuerte Notlichtbeleuchtungsanlage und geeignetes Kommunikationsverfahren hierfür
DE69710653T2 (de) Systemanalysewerkzeug für sequentielle Prozessereignisse
EP3605758B1 (de) Einrichtung und verfahren zum prüfen eines schaltschrankinhalts nach planungsbasierter montage
WO2013075909A1 (de) Verfahren zur automatischen generierung von simulationsmodellen anhand von stromlaufplänen
WO2006003198A2 (de) Verfahren zur simulation einer technischen anlage
DE102020211679A1 (de) Computer-implementiertes system und verfahren mit einem digitalen zwilling und einer graphen-basierten struktur
EP3956750A1 (de) System und verfahren zur simulation von industrieprozessen
WO2008025719A1 (de) Verfahren zur erzeugung eines grössenoptimierten delta-files
EP1137972A2 (de) Automatisierungssystem zur lösung einer prozesstechnischen aufgabenstellung und verfahren hierzu
EP1092210B1 (de) Vorrichtung und verfahren zur erstellung eines virtuellen anlagenmodells
EP1450279A2 (de) Verfahren zur Projektierung eines elektrischen Systems
EP2048587A1 (de) Vorrichtung und Verfahren zur Planung einer Produktionsanlage
EP4224353A1 (de) Verfahren zum erzeugen eines virtuellen modells eines bauteils, computersystem, computerprogrammprodukt
DE102011082838A1 (de) Identifikation wiederverwendbarer mechatronischer Komponenten in der Fabrikautomation
EP2515229A1 (de) Softwarewerkzeug für die Automatisierungstechnik
EP4010765A1 (de) System und verfahren zum bereitstellen einer digitalen nachbildung einer anlage und entsprechendes computerprogrammprodukt
DE102015209715A1 (de) Verfahren und System zur rechnergestützten Überführung eines Architektur-Konzepts eines technischen Systems in eine Architekturspezifikation
WO2002007449A2 (de) Verfahren und anordnung zur ermittlung von aktuellen projektionsdaten für eine projektion einer räumlich veränderlichen fläche
EP1242852B1 (de) Vorrichtung und verfahren zur einbindung von automatisierungskomponenten
DE102004039884A1 (de) Verfahren und System zur Beschreibung und Ausführung automatischer Tests
EP1178438A1 (de) Verfahren und System zum automatischen Überprüfen der Baubarkeit eines aus mehreren rechnergestützt konstruierten Bauteilen bestehenden Gesamtprodukts
DE102018205007A1 (de) Verfahren, Vorrichtung und computerlesbares Speichermedium mit Instruktionen zum Erstellen einer Virtual-Reality-Anwendung
EP1332446A2 (de) System, verfahren und computerprogramm zur konfiguration von objekten

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19980420

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): DE GB

17Q First examination report despatched

Effective date: 20020226

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20070503