EP1332446A2 - System, verfahren und computerprogramm zur konfiguration von objekten - Google Patents

System, verfahren und computerprogramm zur konfiguration von objekten

Info

Publication number
EP1332446A2
EP1332446A2 EP01975945A EP01975945A EP1332446A2 EP 1332446 A2 EP1332446 A2 EP 1332446A2 EP 01975945 A EP01975945 A EP 01975945A EP 01975945 A EP01975945 A EP 01975945A EP 1332446 A2 EP1332446 A2 EP 1332446A2
Authority
EP
European Patent Office
Prior art keywords
components
archetypes
component
meta
configuration
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
EP01975945A
Other languages
English (en)
French (fr)
Inventor
Stephan Lutzke
Dominik Eichelberg
Daniel Von Lucius
Philipp Ackermann
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.)
Perspectix AG
Original Assignee
Perspectix 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 Perspectix AG filed Critical Perspectix AG
Publication of EP1332446A2 publication Critical patent/EP1332446A2/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/17—Mechanical parametric or variational design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]

Definitions

  • the invention relates to the field of computer-aided configuration of objects. It relates in particular to a system, a method and a computer program according to the preambles of the independent claims.
  • Standard configuration systems are based on known systems for the construction of objects.
  • Computer Aided Design is a prime example of a construction system, for example for machines or buildings, using computer software.
  • Modern CAD systems combine any design options with clear presentation in an excellent way. They offer means for the direct generation of technical drawings or even codes that can be used directly in the manufacture of the objects (CIM).
  • CCM manufacture of the objects
  • the unlimited number of design options also set limits for applications.
  • CAD systems can only be operated by specialists. In addition, they can hardly be converted into configuration systems with additional modules.
  • Such are systems with which an object is configured with the help of individual components in a user-friendly and - possibly just as important - user-leading manner.
  • a "finished" object can be assumed here, which can be individually configured through changes. However, the object can also be created on the basis of individual components.
  • user guidance consists in that the design options of the user depend on physically and possibly also functionally meaningful variants are limited or that the user is made aware of them.
  • configuration systems which are only based on the individual adaptation of a list of components, for example those listed in the table.
  • Such configuration systems are used, for example, in ERP (Enterprise Resource Planning) systems. They are used for the direct implementation of component assemblies adapted to customer needs by employees in resource data.
  • ERP Enterprise Resource Planning
  • These configuration systems have the serious disadvantage that the specific design of the object in question is left to the client's imagination. They are therefore not suitable for certain customer-related applications.
  • An example of the graphic configuration systems that exist on the other hand comes from the furniture industry. This is based on approaches, graphically represented and depending on the components represented by CAD files. It can additionally be provided that, for example, price information is calculated on the basis of the components currently used in the configuration and is continuously updated.
  • Such configuration systems are rather limited in their performance and can only be expanded with great effort.
  • Essential features of the invention are the following: Rule sets for representing components - including geometric, optical physical and / or further properties of the components - are present as meta components in a set of meta components. There is also a set of component connection rules (metadocks), with at least some meta components having calls of such connection rules (docks).
  • a component pool also called ArcoTope; the term Arcotope is made up of the elements "Arco” for "Arrange and Configure” and “Tope” as a short form of "Biotope”
  • ArcoTope is made up of the elements "Arco” for "Arrange and Configure” and “Tope” as a short form of "Biotope”
  • the components from the component pool can or will be connected, whereby connection rules must be satisfied.
  • connection rules are called by the meta-components corresponding to the components.
  • the components in the component pool together with their connections form the configured or to be configured object.
  • the configuration of the possibly connected components in the component pool is checked for correspondence with archetypes.
  • object in this not only designates objects but any arrangements to be configured.
  • the object can be any modular consumer and investment goods, that is to say both a piece of furniture or a vehicle and a house interior, a group of buildings and / or civil engineering, any combination of articles etc. others used Terms are: "component” for the building blocks (quasi atoms) that are not further subdivided by the configuration system and "object part” for a subset of the object.
  • assemblies of components and connections between them that form a functional unit are “assemblies”.
  • metal denotes representations that can be converted into effective elements and “instantiate” this implementation into effective elements.
  • the connection of components to one another is limited to a finite number of docks creates a discretization of the configuration options (comparable to "Lego" kits).
  • the set of archetypes contains, for example, both configurations of Completely assembled and, for example, functional objects as well as configurations of parts of such objects, the latter can, for example, be partial assemblies which form functional units and are available to a user analogously to the components and just like configurations of fully assembled objects for introduction into the component pool Due to the fact that an assembly can have a sub-assembly that forms a unit and is recognized as such, a first hierarchy is naturally defined, and this first hierarchy can already be created in the archetypes.
  • the archetype set preferably also has a second hierarchy.
  • This hierarchy is a property hierarchy. For components or archetypes that have properties in common, there is an archetype in a higher hierarchy level. This inherits its properties to the hierarchically subordinate components and / or archetypes. For example, it may be that there are different archetypes that relate to a common function and can therefore be interchanged, for example when configuring an object. These have many properties in common.
  • One with a properties Hierarchy-provided archetype sets may therefore also have archetypes that are not intended to be instantiated and that only serve to summarize common properties of archetypes / components.
  • a first advantage of this hierarchy is that the properties of several components can be changed together by one user.
  • Manipulation performed by a user often means that the configuration of the manipulated object no longer corresponds to an archetype. This can be the case, for example, when a component of the object is replaced by another component.
  • Such a manipulation can now be supplemented by the system in such a way that the object again corresponds to an archetype, which, however, has the property newly introduced by the manipulation (for example, has the newly used component).
  • the archetype is used, for example, which is one level above the original archetype in the second hierarchy. From the group of archetypes subordinate to this archetype, the one who has the new property and at the same time is selected. other properties are closest to the original archetype.
  • the system manipulates the object so that its properties are those of the archetype. This last manipulation can of course be made dependent on confirmation to be made by the user.
  • Computer program is its flexibility and expandability. It is naturally suitable for implementation through object-oriented programming. The components are then classes with properties that other classes do not own, namely with meta docks. Because according to the invention only one rule sets for archetypes, metadocks etc. have to be available, a flexible and expandable implementation with a core in an object-oriented programming language, e.g. C ++, and with rule sets in an easy-to-use, machine-readable standard, e.g. XML done.
  • object-oriented programming language e.g. C ++
  • rule sets in an easy-to-use, machine-readable standard e.g. XML done.
  • the system also has means for generating a resource list from the data available in the component pool.
  • a resource list can be designed, for example, as an order list.
  • it can also have data which are prepared for the resource management of an ERP computer program.
  • An order list is determined continuously using a rule set and in parallel with the review of the assembly structures. This dynamic determination based on rules is a very important property of this embodiment. It represents a significant difference to systems that only provide an evaluation after the configured object has been completed. The dynamic determination ensures that a user, for example, is not ultimately confronted with an abundance of error messages.
  • the system, method and computer program according to the invention are necessarily distinguished by a certain redundancy, since each manipulation also involves a comparison of the components present in the component pool with their connections to all archetypes. This guarantees any flexibility and great security.
  • freezing of parts of the object can be made possible according to a special embodiment of the invention. Such freezing can, for example, redefine an assembly - which may or may not be an archetype - into a component.
  • FIG. 1 shows a diagram of the component pool with components connected to one another via docks
  • FIG. 2 shows a diagram analogous to FIG. 1, with the recognition based on archetypes and a corresponding grouping now taking place,
  • FIG. 3 shows a diagram which shows the separation of abstract model and possible concrete visualizations "model-view-separation"
  • FIG. 4 shows a sketch of the interaction of various elements of the system and computer program according to the invention.
  • FIG. 5 shows the diagram of FIG. 2, the set of archetypes with a representation of its second hierarchization and thus the relationship between instanced assemblies and archetypes being additionally shown.
  • FIG. 1 shows, by way of example and in a simplified manner, a first stage of the system according to the invention:
  • a pool 1 of components 3, 5, 7, 9, also called “ArcoTope” - wherein several identical components 3, 5 can occur - is schematically delimited by a frame in the figure
  • Components are instanced metacomponents, which are quasi present as "blueprints" in a metacomponent set. Because of these meta-components, the components of the figure have docks 21, 23, 25, 27, 29, 31. These docks are calls to components - connection rules (metadocks). They also contain geometric information, for example the position and orientation of a connection relative to the component. Metadocks specify the type of connection and possible partner docks with which the dock can be connected.
  • Component pool 1 is not a priori hierarchical. It offers the user a kind of reservoir of building blocks to put together a unit. However, the docks discretize the configuration options. With a certain number of selected components, there is only a finite number of possibilities for configuring the object.
  • FIG. 2 shows schematically how the archetype reservoir can be structured using archetypes from the set of archetypes. Only the differences from FIG. 1 are discussed here.
  • the system recognizes certain configurations of object parts 31, 33, i.e. Components connected to each other in a predefined way, as an archetype. A corresponding hierarchical grouping takes place in the component pool. It is preferably additionally provided that the recognition and assignment of object parts to archetypes is also visible on the user interface.
  • the assignment of components connected to each other in a predefined way to assemblies is central to the input elements described below. What manipulations a user can carry out on the object depends directly on which archetypes the object and its parts can be assigned to.
  • manipulation options on an assembly is a key point where visual, interactive operation is based directly on the abstract concept described here using examples.
  • a certain manipulation of the object can affect a partial assembly of the object as a whole and can accordingly be carried out as a unit on the partial assembly.
  • the set of archetypes is, for example, also designed as a computer-readable rule set written in a programmer-friendly language.
  • a computer-readable rule set written in a programmer-friendly language.
  • two examples are given here for the definition of archetypes and for the definition of rules concerning them in the XML standard: Definition of archetypes:
  • the grouping (“assembly”) of object parts 31, 33 is preferably carried out dynamically, ie subsets of the component pool are continuously checked for correspondence with the archetypes.
  • the assemblies as instanced archetypes do not themselves store any data but are always in accordance with the current 10 rules generated.
  • the hierarchy of grouping components in the component pool is referred to here as the first hierarchy. It is described in more detail below with reference to FIG. 5.
  • FIG. 3 shows an example for the implementation of a system according to the invention.
  • the so-called "package” 41 in which the software elements that have not been changed during use are summarized.
  • a "cartridge” 43 contains a set of metadocks ("dock system”), a set of meta components (“component system”) , a set of archetypes ("assemblerrules”) and possibly other fixed rule sets - for example for resource lists, see below - together.
  • modules 45, 41, 49 with rules for displaying the object configured in component pool 1.
  • Such representations are preferably 3-dimensional (first module: "3D models” 45) and contain, in a manner known per se, geometric properties, material surface properties (textures, ...), colors, etc.
  • a module 47 with rule sets for A two-dimensional representation (“2D models”) may be present.
  • symbols, names Such are, for example, representations in lists, hierarchy trees, etc.
  • the system according to the invention thus allows the parallel representation of different visualizations of the object on the basis of a single concept, namely on the basis of the component pool with the structuring by means of archetypes.
  • a user interface is provided through which, for example, representations of the object are output on an output unit (for example, a computer screen).
  • User input 51 is of course also used to record user inputs, for example using conventional input means (computer keyboard, computer mouse, etc.) with the aid of a graphical user interface including a representation of the object.
  • FIG. 4 shows the flow of interactions in the system for the specific example of a configuration system for the assembly of furniture.
  • the user can control the system via various input elements: by direct manipulation 51 on the object, in a known manner also via graphic symbols menus etc. 53, by manipulation using virtual aids 55, by adding or removing graphically present components or sub-objects 57, by external ones Commands 59 etc.
  • the user interface translates the input into commands from operators 61. These operators then change the components in the component pool, including their properties and their docks.
  • the operators 61 are drawn linearly, ie with equal rights, but they can equally well be structured hierarchically. For example, an operator can include a call to another, more fundamental operator. The operators can be addressed in the same way using different input elements, so that it is possible to trigger the same operation using different input principles.
  • the operators 61 are preferably generic, i.e. regardless of the elements available for configuration as meta components, metadocks, archetypes etc. However, it may still be possible to provide special operators for very complex and specific functionality. However, these special operators fit seamlessly into the user interface, since they are also controlled by the same input elements.
  • a resource list 71 is created, for example.
  • a resource rule set 81 is available for this.
  • a resource list is created, for example, as follows:
  • Each component and each dock has quantitative resource attributes defined by the meta component or the metadock.
  • a component "table leg" in a furniture configuration system has, for example, the resource attributes "1 time Table leg body "," 1 time table foot “and” 4 times screw xy ".
  • a dock can have additional resource attributes that do not belong to the component.
  • the resource attributes of all components and docks instantiated in the component pool are added to a resource set-up Starting with the meta-resource entities provided in the rule set (in the example, a pack of 20 screws xy could represent a resource entity).
  • the resource list is then a list of resource entities, possibly supplemented with further attributes such as price, availability, etc.
  • the difference to existing configuration systems and, for example, also to accounting programs lies in the systematics, which in the invention is given on the one hand in the hierarchical assembly system defined by archetypes, which sensibly combines components according to their function n of course, a tool which fits into the invention and which summarizes resources as according to their availability.
  • the relationship between the resource list on the one hand and the component pool and the available operators on the other hand is bidirectional.
  • the resource list can be continuously compared with a resource database or the like.
  • Such bidirectionality is made possible by the implementation of the configuration system according to the invention with a continuous and / or constantly repeated check of the components present in the component pool.
  • the feasibility of an operation 61 by a user can be linked to an availability attribute. If, for example, a user wants to re-instantiate a metacomponent and add it to the existing object, the resource attributes of the metacomponent are examined for their availability, only if this is given, the operation is possible at all or can be done without a corresponding warning for the Users are done.
  • FIG. 5 again shows a diagram of the configuration system described above.
  • the component pool of FIG. 2 is shown.
  • the components are connected to one another by docks.
  • object parts 31, 33 are recognized as corresponding to an archetype.
  • Certain compositions of object parts and / or components can of course in turn correspond to an archetype and thus in turn form an object part - at a higher hierarchical level.
  • the object consists of parts A, B, C, part A, for its part, consists of parts AI, A2 and the components X, Y, part AI of ... etc.
  • the object hierarchy can already be created in the archetypes. It enables the user to manipulate the object in a context that makes sense.
  • Every object part and every component is of a so-called type.
  • Each of these types is part of a hierarchical type tree, which represents a property hierarchy of the archetypes and forms the second hierarchy.
  • Properties which are defined for an archetype (“assembly type") are inherited downwards. These inherited properties also include interaction options on the graphical user interface (GUI), for example input elements to be displayed such as pop-up menus or virtual aids, etc. This enables a user there, depending on how it makes sense to define or manipulate properties for entire assemblies or for individual components.
  • GUI graphical user interface
  • the second hierarchy also contains archetypes that are never instantiated, but whose definition makes sense.
  • archetypes that are never instantiated, but whose definition makes sense.
  • an archetype "underpass” with archetypes "pedestrian underpass” and "cycle path underpass” located below it in the second hierarchy is present. Then either is instantiated a pedestrian underpass or a cycle path underpass.
  • many properties can already be defined at the higher hierarchy level.

Abstract

Regelsätze zur Repräsentation von Komponenten - beeinhaltend geometrische, optische physikalische und/oder weitere Eigenschaften der Komponenten - sind als Metakomponenten in einem Satz von Metakomponenten vorhanden. Weiter besteht ein Satz von Komponenten-Verbindungsregeln (Metadocks), wobei mindestens einige Metakomponenten Aufrufe solcher Verbindungsregeln (Docks) aufweisen. Zusätzlich wird ein Komponenten-Pool von instanzierten Komponenten aufrecht erhalten, in diesem können auch mehrere von ein und derselben Metakomponente beschriebene Komponenten vorhanden sein. Die Komponenten aus dem Komponenten-Pool können verbunden sein oder werden, wobei Verbindungsregeln genüge getan werden muss. Diese Verbindungsregeln werden durch die den Komponenten entsprechenden Metakomponenten aufgerufen. Die im Komponenten-Pool vorhandenen Komponenten bilden zusammen mit ihren Verbindungen das konfigurierte oder zu konfigurierende Objekt. Es existiert ferner ein Satz von Archetypen (oder Meta-Assemblies), welche vorgegebenen Konfigurationen von Komponenten entsprechen. Die Konfiguration der unter Umständen verbundenen im Komponenten-Pool vorhandenen Komponenten wird laufend auf Übereinstimmung mit Archetypen untersucht.

Description

SYSTEM, VERFAHREN UND COMPUTERPROGRAMM ZUR KONFIGURATION VON OBJEKTEN
Die Erfindung betrifft das Gebiet der computergestützten Konfiguration von Objekten. Sie bezieht sich im Speziellen auf ein System, ein Verfahren und ein Computerprogramm gemäss den Oberbegriffen der unabhängigen Ansprüche.
Standard-Konfigurationssysteme gemäss dem Stand der Technik beruhen auf bekannten Systemen zur Konstruktion von Objekten. Ein Paradebeispiel für ein Konstruktionssystem, bspw. für Maschinen oder Bauten, mit Hilfe von Computersoftware ist das Computer Aided Design (CAD). Moderne CAD-Systeme vereinen in hervorragender Weise beliebige Gestaltungsmöglichkeiten mit anschaulicher Darstellung. Sie bieten dabei Mittel zur direkten Erzeugung von technischen Zeichnungen oder sogar von Codes, die direkt bei der Herstellung der Gegenstände benutzt werden können (CIM). Die beliebig vielen Gestaltungsmöglichkeiten setzen aber auch Grenzen bei Anwendungen. So können CAD-Systeme nur von Fachleuten bedient werden. Sie lassen sich ausserdem auch mit Zusatzmodulen kaum in Konfigurationssysteme umwandeln. Solche sind Systeme, mit denen auf eine benutzerfreundliche und - u.U. gerade so wichtig - Benutzer führende Art ein Gegenstand mit Hilfe von Einzelkomponenten konfiguriert wird. Dabei kann von einem „fertigen" Objekt ausgegangen werden, das durch Abänderungen individuell konfiguriert wird. Das Objekt kann aber auch ausgehend von Einzelkomponenten geschaffen werden. Eine Benutzerführung besteht im Idealfall darin, dass die Gestaltungsmöglichkeiten des Benutzer auf physikalisch und eventuell auch funktionell sinnvolle Varianten beschränkt werden oder dass der Benutzer auf diese aufmerksam gemacht wird.
Gemäss dem Stand der Technik gibt es zwei Arten von Konfigurationssystemen. Einerseits existieren Konfigurationssysteme, welche lediglich auf der individuellen Anpassung einer Liste von beispielsweise tabellarisch aufgeführten Komponenten beruhen. Solche Konfigurationssysteme werden bspw. in ERP (Enterprise Resource Planning) -Systemen verwendet. Sie dienen der direkten Umsetzung von durch Mitarbeiter an Kundenbedürfnisse angepassten Komponentenzusammenstellungen in Ressourcendaten. Diese Konfigurationssysteme haben den gravierenden Nachteil, dass die konkrete Ausgestaltung des betroffenen Gegenstandes dem Vorstellungsvermögen des Klienten überlassen wird. Sie sind deshalb für gewisse kundennahe Anwendungen nicht geeignet. Ein Beispiel für die andererseits existierenden grafischen Konfigurationssysteme kommt aus der Möbelbranche. Dieses beruht auf Ansätzen, grafisch dargestellte und je nach dem durch CAD-Files repräsentierte Komponenten aneinanderzufügen. Es kann zusätzlich noch vorgesehen sein, dass bspw. eine Preisinformation auf der Basis der aktuell bei der Konfiguration verwendeten Komponenten berechnet und laufend aktualisiert wird. Solche Konfigurationssysteme sind aber in ihrer Leistungsfähigkeit eher beschränkt und können nur mit grossem Aufwand ausgebaut werden.
Es ist daher Aufgabe der Erfindung, ein Konfigurationssystem zur Verfügung zu stellen, welches Nachteile von Systemen gemäss dem Stand der Technik nicht aufweist und welches insbesondere eine einfache Bedienbarkeit aufweist, eine grosse Flexibilität in Bezug auf verwendete Komponenten aufweist und mit nur wenig Programmieraufwand ausbau- und anpassbar ist. Diese Aufgabe wird durch die Erfindung gelöst, wie sie in den Ansprüchen definiert ist.
Wesentliche Merkmale der Erfindung sind die folgenden: Regelsätze zur Repräsentation von Komponenten - beeinhaltend geometrische, optische physikalische und/oder weitere Eigenschaften der Komponenten - sind als Metakomponenten in einem Satz von Metakomponenten vorhanden. Weiter besteht ein Satz von Komponenten-Verbindungsregeln (Metadocks), wobei mindestens einige Metakomponenten Aufrufe solcher Verbindungsregeln (Docks) aufweisen. Zusätzlich wird ein Komponenten-Pool (auch ArcoTope genannt; der Begriff Arcotope setzt sich zusammen den Elementen „Arco" für „Arrange and Configure" und „Tope" als Kurzform von „Biotope") von instanzierten Komponenten aufrecht erhalten, in diesem können auch mehrere von ein und derselben Metakomponente beschriebene Komponenten vorhanden sein. Die Komponenten aus dem Komponenten-Pool können verbunden sein oder werden, wobei Verbindungsregeln genüge getan werden muss. Diese Verbindungsregeln werden durch die den Komponenten entsprechenden Metakomponenten aufgerufen. Die im Komponenten- Pool vorhandenen Komponenten bilden zusammen mit ihren Verbindungen das konfigurierte oder zu konfigurierende Objekt. Es existiert ferner ein Satz von Archetypen (oder Meta- Assemblies), welche vorgegebenen Konfigurationen von Komponenten entsprechen. Die Konfiguration der unter Umständen verbundenen im Komponenten-Pool vorhandenen Komponenten wird auf Übereinstimmung mit Archetypen untersucht.
Der Ausdruck „Objekt" bezeichnet in diesem nicht nur Gegenstände sondern jegliche zu konfigurierende Anordnungen. Beim Objekt kann es sich um beliebige modulare Konsum- und Investitionsgüter handeln, also sowohl um bspw. ein Möbel oder ein Fahrzeug, als auch um eine Haus-Inneneinrichtung, eine Gruppe von Hoch- und/oder Tiefbauten, beliebige Zusammenstellungen von Artikeln etc. Weitere verwendete Begriffe sind: „Komponente" für die vom Konfigurationssystem nicht weiter unterteilten Bausteine (quasi Atome) und „Objektteil" für eine Untermenge des Objektes. Generell sind eine funktioneile Einheit bildende Zusammenstellungen von Komponenten und Verbindungen zwischen ihnen „Assemblies". Die Vorsilbe „Meta-,, bezeichnet in effektive Elemente umsetzbare Repräsentationen und „instanzieren" dieses Umsetzen in effektive Elemente.
Dadurch, dass die Verbindung von Komponenten untereinander auf eine endliche Anzahl Docks beschränkt ist, entsteht eine Diskretisierung der Konfigurationsmöglichkeiten (vergleichbar mit „Lego"-Bausätzen). Damit wird ein Vergleich mit Archetypen erst möglich. Der Satz von Archetypen enthält bspw. sowohl Konfigurationen von fertig zusammengestellten und bspw. funktionstüchtigen Objekten als auch Konfigurationen von Teilen solcher Objekte. Letztere können bspw. funktioneile Einheiten bildende Teil-Assemblies sein und einem Benutzer analog zu den Komponenten und genau so wie Konfigurationen von fertig zusammengestellten Objekten zum Einbringen in den Komponentenpool zur Verfügung stehen. Dadurch, dass ein Assembly eine Einheit bildende und als solche erkannte Teil-Assemblies aufweisen kann wird in natürlicher weise eine erste Hierarchie definiert. Diese erste Hierarchie kann bereits in den Archetypen angelegt sein.
Vorzugsweise weist der Archetypensatz noch eine zweite Hierarchie auf. Diese Hierarchie ist eine Eigenschaften-Hierarchie. Zu Komponenten oder Archetypen, welche Eigenschaften gemeinsam haben, existiert in einer höheren Hierarchiestufe ein Archetyp. Dieser vererbt seine Eigenschaften an die hierarchisch untergeordneten Komponenten und/oder Archetypen. Es kann bspw. sein, dass verschiedene Archetypen vorhanden sind, die eine gemeinsame Funktion betreffen und daher bspw. beim Konfigurieren eines Gegenstandes gegeneinander ausgetauscht werden können. Diese haben viele Eigenschaften gemeinsam. Ein mit einer Eigenschaften- Hierarchie versehener Archetypensatz weist deshalb u.U. auch Archetypen auf, die gar nicht dazu gedacht sind, instanziert zu werden und die lediglich dazu dienen, gemeinsame Eigenschaften von Archetypen/Komponenten zusammenzufassen.
Ein erster Vorteil dieser Hierarchisierung ist, dass durch einen Benutzer Eigenschaften von mehreren Komponenten sinnvoll gemeinsam abändern kann.
Es ergeben sich noch weitere Möglichkeiten aus dieser Hierarchisierung . Eine von einem Benutzer vorgenommene Manipulation führt häufig dazu, dass die Konfiguration des manipulierten Gegenstandes nicht mehr einem Archetyp entspricht. Dies kann bspw. der Fall sein, wenn eine Komponente des Gegenstandes durch eine andere Komponente ersetzt wird. Durch das System kann eine solche Manipulation nun so ergänzt werden, dass der Gegenstand wieder einem Archetyp entspricht, welcher aber die vom Benutzer durch die Manipulation neu eingeführte Eigenschaft aufweist (also bspw. die neu verwendete Komponente besitzt). Dazu wird bspw. der Archetyp verwendet, welcher in der zweiten Hierarchie eine Stufe über dem ursprünglichen Archetyp liegt. Aus der diesem Archetyp untergeordneten Gruppe von Archetypen wird derjenige ausgewählt, welcher die neue Eigenschaft besitzt und gleichzeitig bezügl. der anderen Eigenschaften dem ursprünglichen Archetyp am nächsten ist. Der Gegenstand wird nun durch das System dahingehend manipuliert, dass seine Eigenschaften diejenigen des Archetypen sind. Diese letzte Manipulation kann natürlich von einer vorzunehmenden Bestätigung durch den Benutzer abhängig gemacht werden.
Ein grosser Vorteil des erfindungsgemässen Verfahren, des Systems und des
Computerprogramms ist seine Flexibilität und Ausbaubarkeit. Es eignet sich in natürlicher Weise zur Implementierung durch objektorientierte Programmierung. Die Komponenten sind dann Klassen mit Eigenschaften, welche andere Klassen nicht besitzen, nämlich mit Meta-Docks. Dadurch, dass erfindungsgemäss lediglich eine Regelsätze für Archetypen, Metadocks etc. vorhanden sein müssen, kann auch sehr gut eine flexible und ausbaufähige Implementierung mit einem Kern in einer objektorientierten Programmiersprache, bspw. C++, und mit Regelsätzen in einem einfach handhabbaren, maschinenlesbaren Standard, bspw. XML erfolgen.
Gemäss einer bevorzugten Ausführungsform besitzt das System zusätzlich zu den vorstehend kurz erläuterten Attributen noch Mittel zur Erzeugung einer Ressourcenliste aus den im Komponentenpool vorhandenen Daten. Eine solche Ressourcenliste kann bspw. als Bestellliste ausgebildet sein. Sie kann alternativ oder ergänzend dazu auch Daten aufweisen, die für die Ressourcenverwaltung eines ERP- Computerprogramms aufbereitet sind. Die Ermittlung einer Bestellliste erfolgt anhand eines Regelsatzes dauernd und parallel zur Überprüfung der Assemblystrukturen. Diese dynamische Ermittlung anhand von Regeln ist sehr eine wesentliche Eigenschaft dieser Ausführungsform. Sie stellt einen wesentlichen Unterschied zu Systemen dar, die eine Auswertung erst nach Fertigstellung des konfigurierten Objektes vorsehen. Die dynamische Ermittlung gewährleistet, dass sich ein Benutzer bspw. nicht am Schluss mit einer Fülle von Fehlermeldungen konfrontiert sieht.
Das erfindungsgemässe System, Verfahren und Computerprogramm zeichnen sich notwendigerweise durch eine gewisse Redundanz auf, indem mit jeder Manipulation auch ein Vergleich der im Komponenten-Pool vorhandenen Komponenten mit ihren Verbindungen mit sämtlichen Archetypen stattfindet. Dadurch ist eine beliebige Flexibilität und eine grosse Sicherheit gewährleistet. Damit auch für sehr grosse zu konfigurierende Gegenstände der Rechenaufwand nicht zu gross wird, kann gemäss einer speziellen Ausführungsform der Erfindung das Einfrieren von Teilen des Objektes ermöglicht werden. Ein solches Einfrieren kann bspw. ein Umdefinieren eines Assemblys - das einem Archetypen entspricht oder auch nicht - in eine Komponente sein.
Im Folgenden sollen noch Ausführungsbeispiele der Erfindung anhand von Figuren beschrieben werden. Dabei zeigen
die Figur 1 ein Schema des Komponenten-Pools mit via Docks miteinander verbundenen Komponenten,
die Figur 2 ein zu Figur 1 analoges Schema, wobei nun die Erkennung anhand von Archetypen und eine entsprechende Gruppierung erfolgt ist,
- die Figur 3 zeigt ein Schema, welches die Trennung von abstrakten Modell und möglichen konkreten Visualisierungen darstellt „model-view-separation"
die Figur 4 eine Skizze des Zusammenspiels verschiedener Elemente der erfindungsgemässen Systems und Computerprogramms und
die Figur 5 das Schema der Figur 2, wobei zusätzlich noch der Satz von Archetypen mit einer Darstellung seiner zweiten Hierarchisierung und damit der Zusammenhang zwischen instanzierten Assemblies und Archetypen aufgezeigt ist.
Die nun folgenden Beschreibung bedient sich zur Veranschaulichung der Erfindung wiederholt des Beispiels eines Programms („Konfigurator") zum Zusammenstellen von Möbeln aus Einzelteilen. Es sei hier aber ausdrücklich darauf hingewiesen, dass die Erfindung sich nicht auf dieses Beispiel beschränkt. Sie lässt sich ebenso gut auf andere Konstruktionssysteme anwenden, beispielsweise in der Architektur oder
Innenarchitektur, im Maschinenbau, in der Elektronik, etc.
Figur 1 zeigt exemplarisch und vereinfacht eine erste Stufe des erfindungsgemässen Systems: Ein auch „ArcoTope" genannter Pool 1 von Komponenten 3, 5, 7, 9 - wobei mehrere identische Komponenten 3, 5 vorkommen können - ist in der Figur schematisch durch einen Rahmen eingegrenzt. Komponenten sind instanzierte Metakomponenten, welche quasi als „Baupläne" in einem Metakomponenten-Satz vorhanden sind. Aufgrund dieser Metakomponenten weisen die Komponenten der Figur Docks 21, 23, 25, 27, 29, 31 auf. Diese Docks sind Aufrufe von Komponenten - Verbindungsregeln (Metadocks). Sie beinhalten auch geometrische Informationen, bspw. die Lage und Orientierung einer Verbindung relativ zur Komponente. Metadocks spezifizieren die Art der Verbindung und mögliche Partnerdocks, mit denen das Dock verbunden werden kann.
Zur Illustration wird nachfolgend je ein Beispiel für eine möglichen Realisierung eines Satzes von Metakomponenten und eines Satzes von Metadocks in einer computerlesbaren Form, nämlich im XML-Standard angegeben. Die genauen Definitionen der Tags werden als VCML - „Visual Configuration Markup Language" - bezeichnet:
Ausschnitt aus einem Satz von Metakomponenten:
— >
</cotnponent>
</componentsysteπι>
Ausschnitt aus einem Satz von Metadocks:
<?xral version="1.0" encoding-,*öTF-8"?>
< ! — edited with XMIi Spy v3.0 NT (http : //www. xmlspy. com) (Perspectix Inc. ) — > < ! -- VCML ( 1.0) Dock System Definition by Perspectix AG (http: //www.perspectix.com) < ! — (C) 1999/2000 Perspectix AG -all rights reserved — > <docksyste > <dock type"narmlehne2basis ">
<partrιerdock type-"basis2armlehne"/> </dock> <dock typeα"ba3is2armlehne">
<ρartnerdock type-"armlehne2basis " /> </dock> <dock type="fusskreuz2rolle">
<partnerdock type«"rolle2russkreuz"/> </dock> <dock type«"rolle2fusskreuz">
<partnerdock type="fusskreuz2rolle"/> <do£ type=Hrota" axis=""z">
<domain type»"continous'' from»" -180.0" to="180.0"/> </dof> </dock>
</docksystem> Der Komponenten-Pool 1 ist nicht a priori hierarchisch. Er bietet dem Nutzer quasi ein Reservoir an Bausteinen zur Zusammenstellung einer Einheit. Durch die Docks wird aber eine Diskretisierung der Konfigurationsmöglichkeiten erreicht. Bei einer bestimmten Anzahl ausgewählter Komponenten besteht nur eine endliche Anzahl von Möglichkeiten, den Gegenstand zu konfigurieren.
In der Figur 2 ist schematisch dargestellt, wie das Archetypen-Reservoir mit Hilfe von Archetypen aus dem Satz von Archetypen strukturiert werden kann. Es wird hier lediglich auf die Unterschiede zur Figur 1 eingegangen. Das System erkennt gewisse Konfigurationen von Objektteilen 31, 33, d.h. auf vordefinierte Art miteinander verbundenen Komponenten, als einem Archetyp entsprechend. Im Komponentenpool erfolgt eine entsprechende hierarchische Gruppierung. Vorzugsweise ist zusätzlich vorgesehen, dass die Erkennung und Zuordnung von Objektteilen zu Archetypen auch auf der Benutzeroberfläche sichtbar wird. Die Zuordnung von auf vordefinierte Art miteinander verbundenen Komponenten zu Assemblies ist zentral für die nachstehend beschriebenen Eingabeelemente. Was für Manipulationen ein Benutzer am Objekt vornehmen kann, hängt direkt davon ab, welchen Archetypen das Objekt und seine Teile zugeordnet werden können. Die zur Verfügung Stellung und Darstellung von Manipulationsmöglichkeiten an einer Assembly (betreffend die Eingabeelemente) ist ein Kernpunkt, wo visuelle, interaktive Bedienung direkt auf dem abstrakten, hier anhand von Beispielen beschriebenen Konzept beruht. So kann bspw. eine bestimmte Manipulation am Objekt eine Teilassembly des Objektes als Ganze betreffen und entsprechend an der Teilassembly als Einheit ausführbar sein.
Der Satz von Archetypen ist bspw. ebenfalls als in einer programmiererfreundlichen Sprache abgefasster, computerlesbarer Regelsatz angelegt. Zur Illustration werden hier zwei Beispiele für die Definition von Archetypen und für die Definition von sie betreffenden Regeln im XML-Standard angegeben: Definition von Archetypen:
— >
</aggregationsystem
Archetypenregeln:
>
Ond connected«="truen>
<part id=>"50" type="traverse" class="component" markable>=ntrue"> s3θciation <and>
<partner>
<part id»"100" type="eckverbinder" class»"component"/> </partner> <partner>
<part id=»"200M type="eckverbinder" class="cαmponent"/> </partner> </and> </associatioπ> </part>
<part id='*100" type»"eckverbinder" class="component" markable-"true"/ part id="200" type-"eckverbinder" class-"component" markable-"true"/> </and> </condition> </geomerry> </prioritydock> </as3emblyrule> </as3emblyrule3ystem> </rulβ3ystem
Die Gruppierung („Assemblierung") von Objektteilen 31, 33 erfolgt vorzugsweise dynamisch, d.h. Teilmengen des Komponenten-Pools werden laufend auf Übereinstimmung mit den Archetypen untersucht. Die Assemblies als instanzierte Archetypen speichern selber keine Daten sondern werden immer nach dem jeweils 10 aktuellen Regelwerk wieder generiert.
Die Hierarchie der Gruppierung von Komponenten im Komponentenpool wird hier als erste Hierarchie bezeichnet. Sie wird weiter unten anhand von Figur 5 noch näher beschrieben.
Die Gruppierung in Archetypen entsprechende Objekt-Teile bietet beliebige 15 Gestaltungsmöglichkeiten. Anstatt entweder von Einzelkomponenten auszugehen und das Objekt Schritt für Schritt zusammenzustellen oder von einem fertigen Objekt auszugehen und daran gewisse Modifikationen vorzunehmen kann der Benutzer auch Objekt-Teile aneinanderfügen, diese modifizieren, ergänzen, etc.. Figur 3 zeigt ein Beispiel für die Implementierung eines erfindungsgemässen Systems. Im Zentrum dargestellt ist das sog. „Package" 41, in welchem die während eines Gebrauchs unveränderten Software-Elemente zusammengefasst sind. Eine „Cartridge" 43 fasst einen Satz von Metadocks („Docksystem"), einen Satz vom Metakomponenten („ComponentSystem"), einen Satz von Archetypen („Assemblerrules") sowie möglicherweise weitere feste Regelsätze - bspw. für Ressourcenlisten, siehe weiter unten - zusammen. Ebenfalls im Package 41 vorhanden sind Module 45, 41, 49 mit Regeln zur Darstellung des im Komponentenpool 1 konfigurierten Objektes. Solche Darstellungen sind vorzugsweise 3-Dimensional (erstes Modul: „3D-Models" 45) und enthalten in an sich bekannter Art geometrische Eigenschaften, Material-Oberflächeneigenschaften (Texturen, ...), Farben, etc. Auch ein Modul 47 mit Regelsätzen für eine 2- dimensionale Darstellung („2D-Models") kann vorhanden sein. Weiter sind bspw. diverse andere Darstellungs arten möglich („Symbols, Names" 49). Solche sind bspw. Darstellungen in Listen, Hierarchiebäumen, etc. Das erfindungsgemässe System erlaubt also die parallele Darstellung von verschiedenen Visualisierungen des Objektes aufgrund eines einzigen Konzeptes, nämlich aufgrund des Komponentenpools mit der Strukturierung mittels Archetypen. Zusätzlich zum Komponentenpool 1 und zum Package 41 ist ein Benutzerinterface vorgesehen, durch welches bspw. die Ausgabe von Darstellungen des Objektes auf einer Ausgabeeinheit (bspw. einem Computerbildschirm) erfolgt. Ebenfalls über das Benutzerinterface 51 erfolgt natürlich auch die Erfassung von Benutzereingaben, die bspw. mit üblichen Eingabemitteln (Computertastatur, Computermaus etc.) mit Hilfe einer grafischen Oberfläche inkl. einer Darstellung des Objekts erfolgt.
Die Regeln aus den Regelsätzen werden, wie schon vorgängig beschrieben, auf die Komponenten und Verbindungen im Komponentenpool angewandt. Eine Darstellung des im Komponentenpool vorhandenen Objektes erfolgt durch die Darstellungsmodule. Figur 4 zeigt den Fluss der Interaktionen im System für das spezielle Beispiel eines Konfigurationssystems für die Zusammenstellung von Möbeln. Der Benutzer kann das System über verschiedene Eingabeelemente kontrollieren: Durch unmittelbare Manipulation 51 am Objekt, in bekannter Art auch über Grafiksymbole Menüs etc. 53, durch Manipulation mittels virtuellen Hilfsmitteln 55, durch das Hinzufügen oder Entfernen von grafisch vorhandenen Komponenten oder Teilobjekten 57, durch externe Kommandos 59 etc. Das Benutzerinterface übersetzt die Eingaben in Kommandos von Operatoren 61. Diese Operatoren verändern dann die Komponenten im Komponentenpool, inklusive ihre Eigenschaften und ihre Docks. In der Figur sind die Operatoren 61 linear, d.h. gleichberechtigt, gezeichnet, sie können aber ebenso gut hierarchisch aufgebaut sein. Es kann bspw. ein Operator einen Aufruf eines anderen, fundamentaleren Operators beinhalten. Die Operatoren können gleichermassen durch verschiedene Eingabeelemente angesprochen werden, so dass es möglich ist, ein und die selbe Operation durch verschiedene Eingabeprinzipien auszulösen.
Die Operatoren 61 sind vorzugsweise generisch, d.h. unabhängig von den als Metakomponenten, Metadocks, Archetypen etc. grundsätzlich zur Konfiguration verfügbaren Elementen. Es kann aber trotzdem möglich sein, für sehr komplexe und spezifische Funktionalität SpezialOperatoren zur Verfügung zu stellen. Diese SpezialOperatoren fügen sich aber nahtlos in das Benutzerinterface ein, da auch sie durch die gleichen Eingabeelemente kontrolliert werden.
In einem weiteren Schritt erfolgt beispielsweise eine Erstellung einer Ressourcenliste 71. Für diese steht ein Ressourcen-Regelsatz 81 zur Verfügung. Die Erstellung einer Ressourcenliste erfolgt bspw. folgendermassen: Jede Komponente und jedes Dock besitzt durch die Metakomponente bzw. das Metadock festgelegte quantitative Ressourcenattribute. Als einfaches Beispiel: Eine Komponente „Tischbein" in einem Möbel-Konfigurationssystem besitzt bspw. die Ressourcenattribute „1 mal Tischbeinkörper", „1 mal Tischfuss" und „4 mal Schraube xy". Ein Dock kann zusätzliche, nicht zur Komponente gehörende Ressourcenattribute aufweisen. In einem ersten Schritt werden die Ressourcenattribute aller im Komponentenpool instanzierten Komponenten und Docks zu einer Ressourcenzusammenstellung addiert. Anschliessend erfolgt ein Ab gleich mit im Regelsatz zur Verfügung gestellten Meta-Ressourcenentitäten. (Im Beispiel könnte z.B. ein 20-er Pack von Schrauben xy eine Ressourcenentität darstellen). Die Ressourcenliste ist dann eine Liste der Ressourcenentitäten, ggf. ergänzt mit weiteren Attributen wie Preis, Verfügbarkeit, etc. Der Unterschied zu bestehenden Konfigurationssystemen und bspw. auch zu Buchhaltungsprogrammen liegt in der Systematik. Diese ist in der Erfindung einerseits im durch Archetypen festgelegten hierarchischen Assemblysystems gegeben, welches Komponenten gemäss ihrer Funktion sinnvoll zusammenfasst. Andererseits existiert die Ressourcenliste als ein sich natürlich in die Erfindung einfügendes Tool, welches Ressourcen als gemäss ihrer Verfügbarkeit zusammenfasst.
Gemäss einer speziellen Ausführungsform der Erfindung ist der Zusammenhang zwischen Ressourcenliste einerseits und dem Komponentenpool und den verfügbaren Operatoren andererseits bidirektional. In einem solchen Fall kann ein laufender Abgleich der Ressourcenliste mit einer Ressourcendatenbank o.a. stattfinden. Eine solche Bidirektionalität wird möglich gemacht durch die erfindungsgemässe Implementation des Konfigurationssystemes mit einer laufenden und/oder ständig wiederholten Überprüfung der im Komponentenpool vorhandenen Komponenten. Es kann bspw. die Durchführbarkeit einer Operation 61 durch einen Benutzer an ein Verfügbarkeitsattribut geknüpft werden. Wenn z.B. ein Benutzer eine Metakomponente neu instanzieren und zum bestehenden Objekt hinzufügen will, so werden in diesem Fall die Ressourcenattribute der Metakomponente auf ihre Verfügbarkeit hin untersucht, nur wenn diese gegeben ist, ist die Operation überhaupt möglich, bzw. kann ohne entsprechende Warnung für den Benutzer durchgeführt werden. Die Figur 5 stellt noch einmal ein Schema des vorstehend beschriebenen Konfigurationssystems dar. Es wird insbesondere der Unterschied zwischen der ersten Hierarchie und der zweiten Hierarchie verdeutlicht. Dargestellt ist der Komponentenpool der Fig. 2. Die Komponenten sind durch Docks miteinander verbunden. Ausserdem sind Objektteile 31, 33, als einem Archetyp entsprechend erkannt. Natürlich können bestimmte Zusammensetzungen von Objektteilen und/oder Komponenten ihrerseits wieder einem Archetyp entsprechen und also ihrerseits ein Objektteil - auf einer höheren Hierarchieebene - bilden. Die entspricht der Objekthierarchie, die hier auch erste Hierarchie genannt wird: Das Objekt besteht bspw. aus den Teilen A, B, C, Teil A seinerseits besteht aus den Teilen AI, A2 und den Komponenten X, Y, Teil AI aus ... etc. Die Objekthierarchie kann natürlich schon in den Archetypen angelegt sein. Sie ermöglicht dem Benutzer ein im Kontext sinnvolles Manipulieren des Objektes.
Jedes Objektteil und jede Komponente ist von einem sog. Typ. Jeder dieser Typen ist Teil eines hierarchischen Typenbaums, welcher eine Eigenschaftshierarchie der Archetypen darstellt und die zweite Hierarchie bildet. Eigenschaften, welche für einen Archetypen („Assembly type") definiert sind, werden nach unten vererbt. Zu diesen vererbten Eigenschaften gehören auch Interaktionsmöglichkeiten am Graphical User Interface (GUI), bspw. anzuzeigende Eingabeelemente wie PopUp- Menüs oder virtuelle Hilfsmittel etc. Das ermöglicht einem Benutzer dort, je nach dem, wie es sinnvoll ist, Eigenschaften für ganze Assemblies oder aber für einzelne Komponenten zu definieren resp. zu manipulieren.
Die zweite Hierarchie enthält auch Archetypen, die gar nie instanziert werden, deren Definition aber sinnvoll ist. So kann in einem Konfigurationssystem für das Tiefbauwesen vorgesehen sein, dass ein Archetyp „Unterführung" mit in der zweiten Hierarchie darunter liegenden Archetypen „Fussgänger-Unterführung" und „Fahrradweg-Unterführung" vorhanden sein. Instanziert wird dann immer entweder eine Fussgänger-Unterführung oder eine Fahrradweg-Unterführung. Viele Eigenschaften können aber schon auf der höheren Hierarchiestufe festgelegt sein.

Claims

PATENTANSPRÜCHE
1. System zur Konfiguration eines Objektes, aufweisend ein Datenverarbeitungsmittel mit einer Eingabeeinheit, einer Ausgabeeinheit, einen Prozessor und Speichermittel, gekennzeichnet durch folgende in den Speichermitteln zur Benutzung durch den Prozessor angelegte Elemente:
- einen Satz von Metakomponenten als Regelsatz mit geometrischen, optischen physikalischen und/oder weiteren Eigenschaften von Komponenten
- einen Satz von Metadocks als Komponenten-Verbindungsregeln, wobei mindestens eine Metakomponente einen Aufruf einer solchen Verbindungsregel aufweist,
- einen Komponenten-Pool zur Verwaltung von instanzierten Komponenten, welche miteinander gemäss aufgerufenen Verbindungsregeln verbindbar sind, so dass im Komponenten-Pool vorhandene und miteinander verbundene Komponenten zusammen eine Konfiguration des Objektes bilden,
- einen Satz von Archetypen, welche Archetypen vorgegebenen
Konfigurationen darstellen und
- Mitteln zum Suchen von Übereinstimmungen zwischen der Konfiguration des Objektes und/oder von Teilen des Objektes einerseits und von Archetypen aus dem Satz von Archetypen andererseits.
2. System nach Anspruch 1, dadurch gekennzeichnet, dass der Satz von Archetypen gemäss einer zweiten Hierarchie hierarchisch strukturiert sind, wobei von einer höheren auf eine niedrigere Hierarchiestufe Eigenschaften und Interaktionsmöglichkeiten vererbt werden.
3. System nach Anspruch 1 oder 3, dadurch gekennzeichnet, dass Eingabeelemente vorhanden sind, durch welche ein Benutzer Manipulationen am Objekt vornehmen kann, wobei die vom Benutzer vornehmbaren Manipulationen von den Archetypen abhängen, zwischen denen mit dem Objekt oder mit Teilen des
Objektes Übereinstimmung gefunden wurde.
4. System nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass Mittel zur Darstellung des Objektes in mehr als eine Visualisierung vorhanden sind.
5. System nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass zusätzlich zum Satz von Archetypen mindestens ein weiterer Regelsatz mit Mitteln zur Strukturierung des Komponenten-Pools vorhanden ist, wobei die Strukturierung mittels des weiteren Regelsatzes parallel zum Suchen von Übereinstimmungen zwischen der Konfiguration und dem Satz von Archetypen erfolgt.
6. System nach Anspruch 5, dadurch gekennzeichnet, dass ein weiterer Regelsatz ein Satz von Ressourcen-Regeln zur Erstellung einer Ressourcenliste ist.
7. Verfahren zur Konfiguration eines Objektes mittels eines Computerprogramms auf einem Datenverarbeitungsmittel mit einer Eingabeeinheit, einer
Ausgabeeinheit, einem Prozessor und Speichermitteln, gekennzeichnet durch die folgenden Schritte: - Zur Verfügung stellen eines Satzes von Metakomponenten
- Zur Verfügung stellen eines Satzes von Komponenten-Verbindungsregeln, wobei mindestens eine Metakomponente einen Aufruf einer Verbindungsregel aufweist,
- Zur Verfügung stellen eines Satzes von Archetypen als vorgegebene Konfigurationen
- Aufrecht erhalten eines Pools von Komponenten als instanzierte Metakomponenten, welche miteinander gemäss aufgerufenen Verbindungsregeln verbindbar sind, so dass im Komponenten-Pool vorhandene und miteinander verbundene Komponenten zusammen eine Konfiguration des Objektes bilden,
- Ermöglichen von Manipulationen des Objektes durch einen Benutzer
Laufendes oder wiederholtes von Übereinstimmungen zwischen der Konfiguration des Objektes und/oder von Teilen des Objektes einerseits und von Archetypen aus dem Satz von Archetypen andererseits
8. Computerprogramm zur Konfiguration eines Objektes, aufweisend computerlesbaren Programmcode um ein Datenverarbeitungsmittel mit einer Eingabeeinheit, einer Ausgabeeinheit, einen Prozessor und Speichermittel, folgende Elemente zu implementieren:
- einen Satz von Metakomponenten als Regelsatz mit geometrischen, optischen physikalischen und/oder weiteren Eigenschaften von Komponenten - einen Satz von Metadocks als Komponenten-Verbindungsregeln, wobei mindestens eine Metakomponente einen Aufruf einer solchen Verbindungsregel aufweist,
- einen Komponenten-Pool zur Verwaltung von instanzierten Komponenten, welche miteinander gemäss aufgerufenen Verbindungsregeln verbindbar sind, so dass im Komponenten-Pool vorhandene und miteinander verbundene Komponenten zusammen eine Konfiguration des Objektes bilden,
- einen Satz von Archetypen, die vorgegebenen Konfigurationen darstellen und
- Mitteln zum Suchen von Übereinstimmungen zwischen der Konfiguration des Objektes und/oder von Teilen des Objektes einerseits und von Archetypen aus dem Satz von Archetypen andererseits.
EP01975945A 2000-10-30 2001-10-24 System, verfahren und computerprogramm zur konfiguration von objekten Withdrawn EP1332446A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CH21222000 2000-10-30
CH212200 2000-10-30
PCT/CH2001/000633 WO2002037339A2 (de) 2000-10-30 2001-10-24 System, verfahren und computerprogramm zur konfiguration von objekten

Publications (1)

Publication Number Publication Date
EP1332446A2 true EP1332446A2 (de) 2003-08-06

Family

ID=4567597

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01975945A Withdrawn EP1332446A2 (de) 2000-10-30 2001-10-24 System, verfahren und computerprogramm zur konfiguration von objekten

Country Status (3)

Country Link
EP (1) EP1332446A2 (de)
AU (1) AU2001295356A1 (de)
WO (1) WO2002037339A2 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GR1004555B (el) * 2003-02-26 2004-05-11 Βασιλειος Ιωαννου Τσακιρης Αρθρωτο συστημα ηχειων για πολυκαναλη αναπαραγωγη ηχου, που συνθετει επιπλο, αναλογα με τον χωρο ακροασης
DE10347156A1 (de) * 2003-10-10 2005-05-04 Volkswagen Ag Verfahren und Vorrichtung zum rechnergestützten Entwerfen
US8200457B2 (en) 2005-08-17 2012-06-12 Tacton Systems Ab Customizing of computer aided design models

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6002854A (en) * 1993-03-29 1999-12-14 Trilogy Developmetn Group, Inc. Method and apparatus for configuring systems
US6052669A (en) * 1997-06-06 2000-04-18 Haworth, Inc. Graphical user interface supporting method and system for remote order generation of furniture products
AU758640C (en) * 1998-03-16 2005-08-11 Array Technology Aps A database useful for configuring and/or optimizing a system and a method for generating the database

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2002037339A3 (de) 2003-03-13
WO2002037339A2 (de) 2002-05-10
AU2001295356A1 (en) 2002-05-15

Similar Documents

Publication Publication Date Title
DE10051645B4 (de) Prozesssteuersystem und Verfahren zum Kontrollieren eines Prozesses
DE69817158T2 (de) Benutzerschnittstellen-Mechanismus zur Manipulierung von Kontexten in Computerverwaltungsapplikationen
DE19712946A1 (de) Methode zum Generieren einer Implementierung wiederverwendbarer Teile von Containern eines Workflow-Prozessmodells
EP1061422A1 (de) Informationstechnisches System zur Definition, Optimierung und Steuerung von Prozessen
DE10150387A1 (de) CAD-Datenmodell mit Entwurfsnotizen
DE102006046310A1 (de) System zur Erzeugung und zum Betrieb einer Softwareapplikation für medizinische Bildgebung
EP2637114B1 (de) Verfahren zur Kopplung eines CAD-Systems mit einem Datenbank- und Planungssystem zum Austausch von Daten zwischen beiden Systemen
EP3425571A1 (de) Digitales gebäudeinformationssystem
DE69907714T2 (de) Komponentbasiertes quellcodegeneratorverfahren
EP3364257B1 (de) Verfahren zum betrieb eines engineering-systems für ein industrielles prozessautomatisierungssystem und steuerungsprogramm
WO1997015877A2 (de) Computergestütztes arbeits- und informationssystem und zugehöriger baustein
WO2002037339A2 (de) System, verfahren und computerprogramm zur konfiguration von objekten
DE10215653A1 (de) Verfahren und Anordung zur automatischen Erzeugung von Programmcodeabschnitten sowie ein entsprechendes Computerprogrammprodukt und ein entsprechendes computerlesbares Speichermedium
WO2004003798A2 (de) Informationserzeugungssystem für die produktentstehung
EP1490762B1 (de) Verfahren, software-produkt und system zur universellen computergestuetzten informationsverarbeitung
DE102004023634B4 (de) Verfahren zur Vollständigkeits- und Konsistenzprüfung einer Informationsbibliothek
EP1285315B1 (de) Informationsverarbeitungssystem und verfahren zu dessen betrieb
EP1343078B1 (de) System zur Modellierung und Generierung von Softwaregenerierungssystemen
EP1234231B1 (de) Verfahren zur erzeugung grafischer benutzerschnittstellen für computerprogramme
DE102005023145B4 (de) Verfahren zum Simulieren und Untersuchen einer elektrischen Schaltung und Speichermedium
EP2026202A1 (de) Verfahren zur Visualisierung von Selektionskontexten in einem Automatisierungsumfeld
DE19955002C2 (de) Modellierungsverfahren für Informationsmodelle zur konsistenten Repräsentation und/oder Speicherung von Systemelementen hierarchischer Systemstrukturen
DE10139761B4 (de) Computeranordnung in Form eines Client-/Server-Systems mit einer Datei einer Auszeichnungssprache für die Parametrisierung einer automatischen Abfrage sowie entsprechendes Verfahren
DE10109876B4 (de) Verfahren und Einrichtung zum Datenmanagement
DE10236384A1 (de) Informationserzeugungssystem für die Produktentstehung

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: 20030519

AK Designated contracting states

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

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: 20060518