EP1516234A2 - Systeme de production d'informations pour creation de produits - Google Patents

Systeme de production d'informations pour creation de produits

Info

Publication number
EP1516234A2
EP1516234A2 EP03738033A EP03738033A EP1516234A2 EP 1516234 A2 EP1516234 A2 EP 1516234A2 EP 03738033 A EP03738033 A EP 03738033A EP 03738033 A EP03738033 A EP 03738033A EP 1516234 A2 EP1516234 A2 EP 1516234A2
Authority
EP
European Patent Office
Prior art keywords
types
type
data
relation
data object
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
EP03738033A
Other languages
German (de)
English (en)
Inventor
Johann Ulrich Zimmermann
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.)
Daimler AG
Original Assignee
DaimlerChrysler 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
Priority claimed from DE10236384A external-priority patent/DE10236384A1/de
Application filed by DaimlerChrysler AG filed Critical DaimlerChrysler AG
Publication of EP1516234A2 publication Critical patent/EP1516234A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/41865—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by job scheduling, process planning, material flow
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/31—From computer integrated manufacturing till monitoring
    • G05B2219/31395—Process management, specification, process and production data, middle level
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

Definitions

  • the invention relates to a system and an information model for generating information about data objects, each of which represents a component of a technical product or a step of a development process for the product.
  • product creation process is understood to be a sequence of phases and activities that are necessary for the manufacture of a technical product. These phases include e.g. B. construction and production planning. The activities of a phase require intermediate or final results from previous phases. It is sometimes possible to run several phases in parallel.
  • a model is a simplified and inevitably incomplete image of a section of reality, here the product or the product development process, on a data processing system.
  • the model contains the properties and dependencies of reality that are required to solve a specific task in a phase.
  • information on is the abstract meaning (the” semantics ) of a statement, description, instruction, message or message.
  • An information model is a simplification of reality, through which information and facts are structured for the processing of at least one task.
  • a data model describes how the data structured according to an information model is stored physically, e.g. B. in a file or a database.
  • Modern tools for computer-aided design offer the possibility of defining construction design elements (design features) or general design elements (features), also called functional elements, as components of product models.
  • a construction design element represents a component of a component and contains geometric specifications, e.g. B. surfaces, edges, geometric bodies, roundings. Bores, pockets, grooves and ribs on the cylinder heads of automobile engines are examples of design and design elements.
  • Design elements are supported by the proposal for the German standard DIN 32869-3 "Technical product documentation - Three-dimensional CAD models - Part 3: Functional elements "from February 2002 known.
  • CAD tools e.g. B. CATIA or UniGraphics or ProEngineer
  • design elements are often tailored to the specific requirements and the conceptual world of a phase. They are the smallest building blocks with functional meaning, with which a user builds a product model for a phase and thus realizes a specific view of the product.
  • Design elements represent e.g. B. Boring and milling, attributes can be assigned to them with a semantics for construction or manufacturing.
  • Basic geometric elements e.g. B. lines, circles and cuboids are also building blocks that are used in many product models, but have no functional meaning.
  • taxonomies (kinship hierarchies) are under Known types of design elements: A taxonomy in Wong and Leung refers to design elements of a phase. The concept of types and examples of design elements corresponds to that of classes and objects of object-oriented programming. In a taxonomy it is stipulated that a type A is a supertype of a type B. All properties of type A also apply to type B and thus to all design elements.
  • the documents disclose a formal language called "Part Design Graph Language” (PDGL) to represent the regulations.
  • PDGL Part Design Graph Language
  • the regulations formulated in PDGL are processed, for example, by an interpreter of the formal language.
  • JJ Shah, D. Hsiao, J Leonard: “A Systematic Approach for Design-Manufacturing Feature Mapping", in PR Wilson, MJ Wozny, MJ Pratt (eds.): “Geometry Modeling for Product Realization", North-Holland Publ., 1992, pp. 205 - 221 automatically executable regulations are implemented directly using a programming language, as part of the processing algorithms of a product design tool.
  • the regulations determine how types of user-defined design features to predefined ones that are stored in a library of manufacturing features, which is done using a reconstruction algorithm us, who realizes the transformation outlined above, performed.
  • the algorithm delivers a "Constructive Feature Tree".
  • MJ Wozny Interactive Feature Extraction for a Form Feature Mapping System ", Rensselaer Polytechnic Institute Troy, New York, 1998, and in TN Wong and CB Leung, loc. Cit., Approaches to transforming design elements are presented that are based on an intermediate model for the product geometry. This intermediate model contains application-neutral types and copies of intermediate design elements. The transformation is carried out indirectly via the intermediate model.
  • a fundamental disadvantage of intermediate models is that only those facts that can also be expressed in the intermediate model can be described in a phase-specific model. Therefore, the intermediate model has to store any information that is needed in any phase. Therefore, the intermediate model often includes difficult-to-use types of "general-purpose design elements" that result in storage undesirable redundant data storage and requires a large amount of storage space.
  • a method and a device are known from EP 785491 A2 in order to link and manage information about the construction and information about the production. Relationships between various pieces of information are established and used to move from one group of information to another group.
  • the information e.g. B. about products, components and manufacturing steps (processes) are saved by data records, the relations by references between data records.
  • a database schema is created, through which data records are structured and stored in meaningful relationships with each other. Regulations that can be evaluated automatically are not mentioned in EP 785491 A2.
  • the database to be built comprises two basic tables.
  • elements of a basic class e.g. B. data objects of a data object type, stored. Relationships between the elements of the two basic tables can be saved in a relationship table.
  • the database can contain several relationship tables for the two basic tables.
  • a relationship category can be assigned to each relationship in a relationship table.
  • the relationship categories are stored in a category table.
  • a word can be the last name of a person.
  • a person can be the inventor of a thing designated by a word.
  • relationship table are the two relationships "word - person” and "person - word” are stored.
  • category table relationship categories "last name” and “inventor” are stored and assigned to the relationships "word - person” and "person - word”.
  • relationship table all possible relationships between the two basic tables are saved saved saved and connected to the entries in the category table. For example, the relationships "person - word”, “thing - word”, “project - word” and "object - word” are assigned to the relationship category "name” in the category table by means of corresponding entries in the relationship table.
  • DE 19816658 AI discloses a relational storage and data processing system.
  • the system comprises a memory in the manner of a semantic network with data objects and relations between these data objects.
  • Such a relation can be linked to a data object using a relation relation.
  • Two relations can be linked with each other by means of a relation relation.
  • two data objects C1, C2 for two computer systems of a rocket are each connected by means of a “used” relation to a data object L for a position control system.
  • the “used” relation between Cl and L is via a relation “while” with one Data object linked for the "Normal” operating state.
  • the relation “used” between C2 and L is linked via a relation "while” to a data object for the operating state "emergency”.
  • the invention has for its object to provide a system according to the preamble of claim 1 and an information model according to the preamble of claim 13, which do not require an intermediate model and by which the automatically evaluable rules for dependencies between data objects are set up efficiently and without redundancy , change, save and delete.
  • Such objects link data objects for different phases or from different applications.
  • these relations connect data objects that represent the same component of the product or process for different phases. Thanks to the relations, it can be automatically and efficiently determined which data objects relate to the same component and which further data objects have to be changed after changing a first data object so that all data objects for one component remain consistent with one another.
  • the invention thus reduces the number and the severity of errors in the product creation process, in particular those errors which are based on contradictions between the different product or process models. Changes to individual models are simplified because the automatically executable regulations, which determine the consequences of the changes and / or execute them automatically, can be set up, expanded, changed, saved and deleted efficiently and without redundancy.
  • the relations can be classified into types. As a result, information that is valid for n similar relations Rel__l, ..., Rel_n between data objects need not be formulated and stored several times. Examples of such information are automatically evaluable rules, attributes, permissible value ranges, preferred values or default values as well as dependencies (constraints) and calculation rules between attributes of data object types connected by a relation. Rather, a type of relation is created and it is determined that Rel_l, ..., Rel_n are all of this type. The information is assigned to the type and only needs to be generated and once to be saved. They are therefore valid for Rel_l, ..., Rel_n.
  • relation types allows simple and uniform access to all relations of a relation type. For example, an application of the product creation process can assign a new attribute to all relations, or make evaluations of those attribute values that assume the relations of a type. The application does not need to know the respective name of the relations or an identifier or an access path to the relations of the type in order to carry out the access. Furthermore, the introduction of relation types makes filtering certain relations considerably easier, because e.g. B. only certain relation types need to be specified and all relations of these specified relation types are filtered out. This filtering facilitates the retrieval of information, which leads to shorter computing times and the work of experts.
  • the automatically evaluable regulations are assigned to these relationship types and not e.g. B. individual relations or even types of design features.
  • data object types remain free of references to other data object types, which would be inevitable if the automatically evaluable regulations were assigned to data object types.
  • This feature is particularly advantageous if another data object type, to which a first data object type refers, is deleted. If the first data object type had a reference to the other data object type, you would have to ensure that this reference is deleted when the other data object type is deleted.
  • the invention creates and stores data objects separately from their mutual relationships.
  • the system according to the invention does not require an intermediate model that is valid for several phases of the product creation process. The system thus avoids the disadvantages described above.
  • the automatically evaluable regulations are preferably formulated in such a way that they do not depend on a specific application of the product creation process, but are application-neutral. This means that an additional application can be supplemented or an old one replaced by a new one without having to change the data storage of other applications.
  • the regulations represent information about which calculations, evaluations and generations are to be carried out. Information on how the regulations are to be executed in detail is assigned to the respective executing application.
  • Another advantage of the invention is that it can deliver productive results even if not all data object types are linked to one another by relation types. Rather, the system according to the invention can also work with incomplete information, e.g. B. with relations Types for only some of the dependencies between data object types. Subsequent additions do not make it necessary to revise earlier specifications.
  • This aspect is particularly important when the product creation process is already established in a company, specific applications for individual phases in productive use and therefore the system according to the invention is gradually coupled with the existing productive applications when it is introduced, because it is impossible to use it to combine suddenly with all these applications during operation or even to interrupt the operation for the introduction. Different degrees of coupling different applications can be realized by means of the system according to the invention.
  • the system according to the invention can initially be used prototypically for individual phases and applications and can be gradually coupled with other applications. Above all, this scalability makes it possible to introduce the system according to the invention evolutionarily into an existing product creation process.
  • the above-mentioned aspect also makes it possible to adapt the invention in the course of a product creation process, instead of having to make do with a rigid data storage scheme during the entire product creation process.
  • relation type categories under relation types is a further feature by means of which duplicate and undesirably redundant data storage is avoided.
  • Information that is valid for m relation types T_l, ..., T_m is assigned to a relation type category K. The information is formulated and saved once.
  • T_l, ..., T_m it is specified that these m types are of the relationship type category K. This means that the specifications for K apply to the m relations types. It is also possible to subsequently assign a relation type T_i to a relation type category.
  • relation type category which attributes and methods the relation types of Category.
  • Further examples of information that are assigned to a relationship type category are the stipulations that each relationship type of the category must have a name and an automatically evaluable rule.
  • Processing algorithms can also be assigned to a category.
  • a rule can be specified for a relation type category, which limits or checks the assignment of data object types to relation types of the category. This regulation takes z.
  • B Reference to data object types. It is also possible to introduce categories of data objects and to refer to data object categories in a rule that is assigned to a relationship type category.
  • relation type categories Another advantage of using relation type categories occurs when information that is valid for several relation types of the same relation type category has to be changed subsequently, eg. B. due to a new design, new requirements for the product to be designed and manufactured or because errors in the old design or work plan became apparent. Because the information is only stored once, namely as part of the information about a relationship type category, it only needs to be changed once. If, on the other hand, they were saved multiple times and redundantly, several change processes would have to be carried out. There is a great risk that a required change process will not be carried out at all, or will only be carried out incompletely or incorrectly, and errors will result in the product part.
  • Certain relation types can be automatically selected by specifying at least one specific relation type category, as a result of which all relation types of the predefined category are selected. This enables intelligent filtering of and a focus on certain relationship types.
  • the taxonomy under relation type categories arranges the u. U. extensive set of relationship types.
  • An application can automatically determine syntactic rules and semantics for a relationship type by determining the assigned relationship type category and its position in the taxonomy and evaluating the information about this relationship type category. The risk is reduced that different types of relations are introduced for the same situation. This avoids unwanted redundancy and overlaps.
  • a uniform taxonomy is preferably established among all types of data objects. This taxonomy comprises several phases of the product creation process as well as data object types for different levels of abstraction of the product.
  • the taxonomy under relation type categories and the taxonomy under data object types are preferably not generated again for each product creation process.
  • the system according to the invention comprises two cross-application and predefined and expandable standard libraries, namely one with data object types and another with categories of relation types between these data object types.
  • These two standard libraries are e.g. B. for each series of an automobile manufacturer, which is designed and manufactured according to a defined product development process. They can be used and expanded as a starting point for a specific product development process, for example a specific new series from an automobile manufacturer, e.g. B. for the product development process of a certain series or a certain application.
  • the libraries are preferably in the form of integrable software libraries (libraries) or data records in a database. It is also possible to use only the standard Provide library for data object types or only that for relation types.
  • Specific data object types and relation type categories are created as subtypes of data object types or relation type categories of the standard libraries. Attributes and other information that are assigned to a data object type or a relation type category of the respective standard library are also valid for all subtypes due to inheritance along the taxonomy of the data object types or the relation type categories - unless specified for the data object type or the relationship type category. Specifications for a more specific data object type override inherited specifications for a more abstract data object type (overloading). Specific types and categories, because they were created as subtypes or subcategories of types or categories of a cross-application standard library, already have a rough semantics through the generation and can be evaluated by applications.
  • a rule that refers to a type or relation of a standard library can also be applied to the specific subtype or subcategory. Because the subtype or subcategory inherits at least all those regulations, methods, attributes etc. that are assigned to the type or category from the standard library.
  • a relation type can e.g. B. two abstract data object types are assigned, these are two data object types that are roots of branches of the tree-like taxonomy, that is, have several sub-types. This assignment specifies that a relation of the relation type may connect two data objects from two data object types of these two branches, but not data objects of other data object types.
  • the exam is e.g. B. performed automatically after the creation of a relation.
  • the taxonomy among data object types can be multiple inheritance provide, ie a data object type can have several other data object types than parent types and inherit different regulations, methods or attributes from them. The taxonomy then no longer forms a tree, but a directed acyclic graph.
  • an automatic recognition of design elements is preferably carried out.
  • certain parts of a product or process model that have not yet been typed are typed by assigning them to previously defined data object types. It is preferably made possible that a component can be assigned not only to a sheet of taxonomy under data object types, but also to an abstract data object type. These data objects are then linked to other data objects for other phases of the product creation process by means of relations.
  • Data object types and thus data objects are preferably assigned to specific phases of the product creation process.
  • a data object type can be assigned to several phases.
  • the phases are e.g. B. also modeled as data object types that are linked by relationship types with other data object types.
  • the system according to the invention preferably comprises (claim 8) a device for assigning a data object type to at least one of at least two different phases of the creation process and a device for generating a single taxonomy for data object types, ...) which are assigned to a first phase and for data object types (500.1, 500.2, ...) that are assigned to a second phase.
  • the taxonomy can include data object types for any number of phases.
  • This embodiment is preferably combined with a system with the features of claim 1.
  • it is also possible to provide a system for generating information about data objects the system a device for generating types of data objects, a device for assigning a data object type to a phase and a device for generating a single taxonomy for data object types.
  • FIG. 3 shows a section of a taxonomy under data object types.
  • the system 10 comprises the central service program 98 as well as the central database 100 with relation type categories, data object and relation types as well as relations 400.1, 400.2, 400.3, 400.4. Relation type categories on the one hand, relation types 600 and data object types 500 on the other hand and relations 400 as a third logically form three different levels of abstraction, but are preferably stored physically in the same central database 100.
  • Information forwarding interfaces 250 connect the central service program 98 to four applications 200.1, 200.2, 200.3 and 200.4.
  • the two The applications 200.2 and 200.4 each manage local data storage 110.1 and 110.2, which is filled with data from the central database 100.
  • the system 10 according to the invention is implemented with the aid of a central data processing system, which is preferably connected to a number of other data processing devices.
  • the system 10 comprises a central service program (application server) 98 and a central database 100.
  • the system 10 according to the invention preferably functions as a central data storage system for the applications 200 and thus for several phases of the product creation process. This provides an application 200 for one phase with data and information from other phases, and the individual applications are better integrated with one another. This supply of data and information avoids errors that e.g. B. due to media breaks, saves time and facilitates changes because the effects of a change in one phase on other phases or on other applications 200 are determined.
  • the applications 200 typically solve specific tasks for certain phases of the product creation process. These phases include e.g. B. Design (concept design), construction (detailed design), calculations, construction of the tools required for product manufacture, prototype construction and testing, work planning for series production, resource Planning, work planning for series production including resource planning, series production, quality control, evaluation of experience in series use. Examples of the applications 200 on the data processing devices are software systems for construction (computer-aided design, CAD), for product data management (product data management, product engineering management), for product simulation by means of calculation models, for example. B. for the behavior of the product under mechanical loads, for manufacturing planning, for resource planning (enterprise resource management), for programming machine tools, for carrying out and evaluating measurements for quality assurance and for processing a workflow (workflow management).
  • CAD computer-aided design
  • product data management product data management
  • product engineering management for product simulation by means of calculation models, for example.
  • B. for the behavior of the product under mechanical loads, for manufacturing planning, for resource planning (enterprise resource management), for programming
  • Each of these applications 200 uses a specific view of the product and requires certain data objects 300.
  • the reasons for the different views are that each application 200 has specific tasks to perform and therefore requires specific data, information and knowledge and requires specific work states when solving problems.
  • a data object 300 belongs to at least one specific model 150, which in turn belongs to a specific view of the product or the process and is generated and processed by at least one application 200 for a phase of the product creation process. It is possible for the same model to be processed by different applications 200.
  • These applications and the central database 100 are connected to the central service program via information forwarding interfaces 250.
  • This reduces the development and maintenance effort: With n applications 200.1, ..., 200. n only n interfaces between the applications and the central service program 98 are required. In extreme cases, if direct interfaces between the n applications 200.1, ..., 200.n would be required to develop and maintain a total of n * (nl) / 2 interfaces. For n 10, only 10 instead of 45 interfaces can be developed thanks to the invention. Due to the central data storage, a conversion between application-specific product or process models 150 and the information and / or data models used in each case is also not necessary.
  • FIG. 2 shows an exemplary architecture with the system 10 according to the invention and four applications 200.1, 200.2,
  • the four applications are via four information forwarding interfaces 250.1, 250.2, 250.3 and
  • System 10 further includes a user interface 50.
  • the central data storage is preferably described and read exclusively by the central service program 98. Only the central service program 98, but not the applications 200.1, 200.2, 200.3 and 200.4, have write and read access to the central database 100.
  • the following information is permanently managed in the central database 100 and via the central service program 98 and the information forwarding Interfaces 250 made available to the applications: the relationship type categories and the taxonomy among them, the data object types 500 and the taxonomy among them the relationship types including the taxonomy among them and the automatically evaluable regulations
  • An application 200.1 thus “knows” relations after a read access, for example a relation 400.1 between a data object.
  • no information about the other models is preferably stored in the models 150 or local data memories 110, so that a model of one application does not have direct references to a model of another application.
  • Data objects 300 and applications 200 for generating, editing and evaluating data objects, in particular construction and manufacturing design elements, are often tailored to the specific requirements of the phase. They represent the relevant components of the product or process for the respective phase.
  • the data objects 300 and relations 400 form the building blocks in order to generate models 150 for the respective phase.
  • a data object 300 is preferably not generated, changed, deleted and managed by the central service program 98, but rather by the respective application 200.
  • the application 150 provides, in particular, the permanent storage of the data object 300 z. B. in a local database 110.
  • the data object 300 is part of a product or process model 150 and is generally only available to the generating application 200, but not to any other application.
  • the central service program 98 can address a data object 300 via an access method, e.g. B. with the aid of an access path to the product or process model 150 and a unique identifier within this model or via a programming interface (application programming interface, API) to an application 200.
  • a relation 400.1 stored in the central database 100 has references to the data objects 300.1 and 300.3, which are connected by the relation 400.1. These references include all information that the central service program 98 requires for read access to the data objects 300.1 and 300.3.
  • An application 200 can trigger the generation and permanent (persistent) storage of a data object type 500 in the central database 100 via an information forwarding interface 250 and the central service program 98. Conversely, the application 200 can obtain information about data object types 500 from the central database 100, e.g.
  • a data object 300 of a certain data object type 500 by instantiation.
  • an information forwarding interface 250 is sent to a CAD tool as an application 200 to instantiate a data object 300 of a predetermined data object type 500.
  • the system 10 specifies the type 500 and the name and certain attributes and / or methods of the data object 300 to be generated to an application 200.
  • the central service program 98 determines which other data objects 300.3 of the same or other applications are affected by this deletion. The following sequence is carried out automatically for this, cf. Fig. 1:
  • the application 200.1 transmits to the central service program 98 an identifier and the type 500.1 of the data object 300.1 to be deleted.
  • the central service program 98 uses read access to the central database 100 to determine which relationship types connect the data object type 500.1 to other data object types. Be 600.1, ..., 600. n these types.
  • the central service program 98 determines the m relations 400.1, ..., 400. m, which are of one of the types 600.1, ..., 600. n or a subtype of these n types and which each carry a reference to the data object 300.1.
  • the central service program 98 determines which other data objects 300.3, 300.5 at least one of these m rela- are assigned. The planned deletion affects these data objects.
  • the central service program 98 determines which automatically evaluable regulations are assigned to the n relationship types 600.1, ..., 600. n. By evaluating these regulations, the central service program 98 determines further consequences of the planned deletion, e.g. B. Changing parameters or deleting other data objects.
  • the central service program 98 determines which applications 200.1, 200.3 manage at least one of these influenced further data objects 300.3, 300.5, and transmits a description of the effects to the respective application 200.1, 200.3.
  • the central service program 98 deletes all references to the deleted data object 300.1 from the relations 400.1, ..., 400.m. Relations are deleted if necessary.
  • An alternative embodiment provides that the application 200.1 deletes the data object 300.1 and only subsequently transmits the information about the deletion to the central service program 98.
  • a corresponding sequence is z. B. executed to generate information about which other data objects a previously selected typed first data object 300 is associated with. This information is generated either by direct evaluation of information or, for example, by the following sequence:
  • a typed data object is selected.
  • the system 10 comprises components for carrying out this determination.
  • the central service program 98 regulates the control and information flow between the applications 200 and between an application 200 and the central database 100. It answers queries that come in from an application 200 via an information forwarding interface 250, triggers events such as the generation of a Data object 300 and manages the central database 100 including transaction management for the permanent storage of data objects 300 and relation types 600, relations 400 and relation type categories.
  • the central service program 98 intervenes e.g. B. with the aid of standard protocols such as "Open Database Connectivity" (ODBC) to a relational database that functions as the central database 100.
  • ODBC Open Database Connectivity
  • SQL Standard Query Language
  • An alternative embodiment provides for functional or object-oriented interfaces to be provided between central service program 98 and central database 100 in connection with defined programming interfaces for applications (application programming interfaces, APIs).
  • the central service program 98 uses functionalities of programming interfaces to obtain read and / or write access to the central database 100.
  • One advantage of XML files is that they are easy to use. ODBC and SQL are widely used standards.
  • DCOM distributed Component Object Model
  • HTTP Hypertext Transfer Protocol
  • CORBA Common Object Request Broker Architecture
  • IDL Interface Definition Language
  • EJB Enterprise Java Beans
  • the central service program 98 and further components of the system 10 according to the invention and at least some applications 200 all run on the same data processing system.
  • the system 10 according to the invention preferably comprises its own data processing system, which functions as a network central computer (server) in a client-server architecture.
  • the data processing devices for the applications 200 act as network subscriber computers (clients).
  • the invention supports the integration of various applications 200 in two directions along the product creation process: downstream and backward. Integration upstream is achieved in particular by determining the effects of a change in one phase on subsequent phases, e.g. B. from the construction phase to the manufacturing phase or to the tool making phase, in which, depending on product models 150, the tools required for manufacturing the product are designed.
  • the downstream integration results in applications 200 being informed about models 150 in earlier phases in later phases. Individual data objects 300 from these earlier phases, e.g. B. the product design phase, z. B. Design reasons (design rationale) can be assigned, which lead to better decisions in later phases.
  • the invention supports, for example, cost prediction, product design with a predefined optimization criterion and / or predefined Boundary conditions (design-to-X), automation of the workflow (workflow management) as well as the handling of experiences, justifications and reasons.
  • a cost prediction application 200 e.g. B. includes a database 110 with data records for tools, machining times and hourly rates. Thanks to the invention, the application 200 that manipulates the product model 150 with the design features has read access to the cost information and can cause the cost of the wellbore to be predicted.
  • FIG. 3 shows a section from the taxonomy for data object types spanning applications and phases.
  • a rectangle represents a data object type.
  • An edge connects a subtype with the supertype shown above the subtype.
  • the rectangles represent the following data object types:
  • Data objects in particular design features and manufacturing features, are preferably treated according to the object-oriented paradigm that is derived from J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenson : "Object-Oriented Modeling and Design", Prentice-Hall, Englewood Cliffs, 1991, is known.
  • Data objects 300 are typed, and types 500 (types / classes) of data objects can have attributes or parameters that reflect the static properties of the data objects describe, and have methods for the dynamic properties of the data objects.
  • a data object 300 of a predetermined data object type 500 can be created by “instantiating” the data object type.
  • the data object generated in this way has the attributes and Methods of the data object type.
  • several abstraction steps are preferably carried out. Similarities between n data object types 500.1, ..., 500.n are identified and summarized in a new, more abstract data object type.
  • This new data object type 500. o becomes parent type of 500.1, ..., 500. n. 500. o is connected to 500.1, ..., 500. n by a specialization relation.
  • the result of the abstraction steps is a taxonomy among data object types 500. Sheets of this taxonomy, that is to say data object types without subtypes, can be instantiated, the more abstract data object types preferably not.
  • Relation types 600 Corresponding typings are carried out for the relations 400 according to the invention between data objects 300. This creates relation types 600, from which relations 400 can be generated by instantiation. Corresponding abstractions of the relationship types 600 generate relationship type categories and a taxonomy under these relationship type categories.
  • a relation 400 connects at least two data objects 300. a and 300.b.
  • a relation 400 functions as a building block for the administration and evaluation of the dependencies between data objects 300. a, 300. b.
  • a relation 400.a can also connect another relation 00.b with one or more data objects 300. a, 300.b or connect several other relations with one another.
  • a relationship type 600 connects at least two data object types 500. a and 500.b with one another.
  • a relation type 600. a can also connect another relation type 600.b to one or more data object types 500 or else connect several other relation types to one another.
  • An example of a relation that connects other relations with one another are data objects and relations for a hole pattern, that is, several holes with specific positions relative to one another, which are punched out of a metal sheet.
  • a data object type "boreholes" with the two sub-types “Reference holes” and “dependent holes” are introduced.
  • the n holes of a hole pattern are represented by a data object of the type “reference boreholes” and n-1 data objects of the type “dependent boreholes”.
  • the absolute target position of the reference borehole and the relative positions of the n-1 dependent boreholes are specified and represented by corresponding attributes.
  • a data object of the "position tolerance” type and n-1 data objects of the "measurement tolerances” type are generated and assigned to the reference borehole or the n-1 dependent boreholes by means of relations.
  • a relation type "relative position” and n-1 relations of this type are created, each relation of this type connects the reference borehole, a dependent borehole and a measurement tolerance.
  • the relation type "relative position” is with the data object types “Reference holes”, “dependent holes” and “measurement tolerances”. It includes a checking rule for the relative position of the dependent hole relative to the reference hole of the hole pattern. The rule refers to those by the third Every relation of the "relative position” type "knows” this regulation.
  • the system 10 determines the required attributes of the three data objects and inserts them into the regulation. whether the relative position complies with the specified measurement tolerance.
  • Another relation type called "hole patterns” is inserted leads.
  • a relation of this type is generated for each hole pattern, which connects the n-1 relations of the “relative position” type that have just been described. Via this relation, the central service program 98 can access all data objects and relations that represent the hole pattern.
  • a different embodiment of this example provides for N subtypes of the data object type "dependent boreholes" to be generated, where N is the maximum possible number of holes Hole pattern is.
  • the n-1 data objects for the n-1 dependent boreholes of the hole pattern belong to n-1 different ones of the N data object types. Thanks to this embodiment, a specific dependent borehole can be addressed by knowing only the respective data object type.
  • An experience object comprises texts, images and / or sequences of images, the experiences with another data object or a relation or reasons z. B. for a design decision (design rationale).
  • a data object of the type "explanations” is identified by a relation with at least one other data object, e.g. B. a design element or a component, a data object type or a relation or a relation type or a relation type category.
  • the same explanation can be assigned to different data objects. It is possible to first assign an explanation to a data object and later to the corresponding data object type after an approval process.
  • the relations between explanations on the one hand and other data objects, relations, types or relation type categories on the other hand are also typed, e.g. For example, they all belong to a relation type "explanation assignment".
  • checking and generic relations Two types of relations are distinguished, namely checking and generic relations. A distinction is made between checking and generic relationship types.
  • a checking relation type describes at least one logical dependency between data objects through the assigned checking regulations. It is checked whether the existing data objects are compatible with the regulations. New data objects are not created.
  • a special form of a checking rule is an attribute of the relation type. For example, this attribute identifies a relation and thus a dependency between data objects of different applications 200.1, 200.2 closer.
  • a cylinder head has n cooling fins. These are modeled in the construction phase by n construction design elements. A basic body for the cylinder head is supplemented by these n design elements.
  • the cooling fins are created by milling recesses from a block. These recesses to be milled are modeled in the work planning phase using manufacturing design elements.
  • a type of relationship between n construction design elements for the construction phase and m manufacturing design elements for the work planning phase is introduced. Such a relationship connects n cooling fins and m cutouts on a cylinder head.
  • a membership interval has e.g. B. the form a: b, where a is a natural number and b is a natural number or *.
  • the definition * stands for any number of data objects.
  • two foreign roles are also assigned to the relationship type, namely the roles “as construction design elements” and “as production design elements”. This determines which roles the connected data objects play in a relation of the type “from the role perspective”.
  • n membership intervals and n roles are preferably defined for a relation type, the n data object types and / or relations -Types types with each other. This configuration makes it possible to efficiently model now relationships.
  • a relation type is assigned an identifier of its own role, that is the role that a relation of the type plays from the perspective of the connected data objects. The following example explains the difference between foreign roles and your own role:
  • the data object type “construction design elements” has, inter alia, the subtype "two-stage boreholes"
  • the data object type “production design elements” has the subtype "holes”.
  • "Two-stage boreholes” and “holes” are assigned to a relation type "is manufactured as” in such a way that a relation of the type connects a two-stage borehole with two holes.
  • the relations type is assigned its own roles “manufacturing View “(from the point of view of the design elements) and” precast element view “(from the point of view of the design elements).
  • the foreign roles upper hole “and” lower hole “(from the point of view of the two - stepped borehole) and "stepped borehole” (from the perspective of the boreholes).
  • the rule assigned to the relation type called "is manufactured by” specifies, for example, which and how many manufacturing design elements are required for given construction design elements.
  • the missing manufacturing design elements are not created automatically. It is the responsibility of the particular application 200 to which the objection is being reported, or its users, to resolve it.
  • Checking relations can also have so-called ontological knowledge about semantic relationships between data object types. They allow a consistent flow of information along the product creation process and link applications on the information level and not only on the data level.
  • a generating relation comprises at least one generation rule that can be evaluated automatically and that defines how data objects are generated automatically.
  • This rule is assigned to a type of generating relationship and specifies the desired result of a generation step.
  • the central service program 98 preferably transmits this desired result to the respective applications 200. It is the responsibility of these applications 200 and, if necessary, of their users to generate the desired result.
  • These regulations may depend on conditions in product models 150 or may be triggered by these or by other defined events. For example, after each change of an application-specific model for a phase, it is determined which data objects are affected by the change and which generating relations relate to these data objects. A change in the product model triggers an automatic evaluation of the generating relations determined on the basis of the change. Generating relations thus automate tasks in the product creation process.
  • a generating relation links the data objects that trigger a generation step with those data objects that are generated during this generation step, e.g. B. by "instantiation".
  • the generation rule which is assigned to the respective type of generating relations, includes all information that is required to instantiate data objects in a specific product or process model.
  • a rule encompassed by a generating relation generates z. B. a group of design elements interconnected by relations (feature constellation). Not only are the data object types instantiated to create the connected design elements, but also the relation types to create the connecting relations.
  • a generation step is always triggered, for example, whenever a previously specified data object is changed or instantiated. According to the invention, the definition of what triggers a generation step is assigned to a relation type.
  • a rule that is assigned to a relationship type is interpreted, for example, by a component of the system 10 according to the invention. Or the central service program 98 forwards the rule to an inference machine 60, which carries out the automatic evaluation and reports its result, ie the desired result of a generation, back to the central service program 98. Because the inference machine 60 carries out complex evaluations, it is often advantageous to implement it as a separate application from the central service program 98.
  • relation type categories, relation types and relations are explained using an example.
  • a data object type "holes” is introduced in the cross-application standard library and assigned to the phase product construction.
  • the data objects of this type are construction design elements
  • a type of quality design elements called "function tolerances” with the sub-types “shape tolerances”, “position tolerances” and “measurement tolerances” is introduced and assigned to the phase "construction”.
  • the type "holes” receives a subtype “drill holes” and this subtype “drill holes for bodywork”.
  • This configuration takes into account that the designers already in the "construction” phase have functional tolerances such as: B. for construction design elements lay.
  • further tolerances are defined, for example those for monitoring the manufacturing process and in particular the processing machines and tools used to manufacture the product.
  • the quality assurance phase is assigned a type of measuring design elements (measuring features) called "measuring points".
  • Each measuring design element represents a sampling point, the actual position and / or orientation of which is determined during quality assurance and with a target position and / or target Orientation is compared.
  • a relation type category called "measurement strategies" is introduced. It is determined that a relation type of this category connects three data object types, namely a type of construction design elements, a type of quality design elements and a type of measurement design elements, and which parameters a relation type of the category must have at least, preferably at least one name and a measurement strategy, formulated, for example, with the help of the document description language "eXtended Markup Language” (XML) or as free text.
  • XML extended Markup Language
  • Each relationship type in the "measurement strategies" category thus combines a type of construction design elements, a type of quality design elements and a type of measurement design elements.
  • a checking relation type of the category "measurement strategies” is created, given the name “is checked by” and assigned to the category "measurement strategies".
  • the relation type "is checked by” connects three data object types with one another, namely the types " Boreholes ",” Hole Tolerance " and "measuring points”. For example, the following checking rule is assigned to this relationship type:
  • the diameter of k is less than 0.5 mm and the tolerance of qu is greater than 0.1 mm, then the number of m is 5.
  • the number of m is 8.
  • the diameter of k is between 0.5 mm and 5 mm, then the number of m is 10. If the diameter of k is greater than 5 mm, then the number of m is 20.
  • the “number of m” denotes the number of measuring points which are assigned to the borehole and with which the compliance with the required tolerance is checked.
  • the invention enables “bidirectional associativity” between data object types. This is explained in the following example.
  • Two data object types A and B have the three parameters x and y (parameters of A) and z (parameters of B).
  • Tools for automatic equation and inequality solving can rather do such an equation automatically of the unknown to solve. Such tools are e.g. B. from WO 00/31640 A2 and US 5,477,450.
  • the system 10 automates the cooperation between different applications 200 and thus the automation of tasks in the product creation process across different phases and applications 200.
  • an application 200.1 transmits to the central service program 98 that the application 200.1 will create a data object 300.1 of a predetermined type by instantiation.
  • This data object 300.1 belongs to a product model 150.1, which is generated and processed by the application 200.1.
  • the central service program 98 determines the type 500.1 of the data object 300.1 to be generated and determines which relationship types connect this data object type 500.1 to other data object types. If there are no such relationship types, or if only checking regulations are assigned to this relationship type, the system 10 reports to the application 200.1 that the creation of the data object 300.1 can be continued.
  • the inference machine 60 evaluates it. The result depends on the data object 300.1 of type 500.1 to be generated, for example it consists of n data objects of a type 500.2 and r data objects of another type 500.3 as well as relations between the new data object of type 500.1, the n new data objects of type 500.2 and the r new type 500.3 are to be created.
  • the inference engine 60 transmits this result to the central service program 98.
  • the central service program 98 determines which applications 200 are influenced by this result, e.g. B. the triggering application 200.1 and / or other applications.
  • Each affected application 200.b receives the message which data objects it has to create, e.g. B. which the n of type 500.2, which the r of type 500.3. The generation of these data objects is the responsibility of the respective applications. After the applications 200 have completely created the data objects 300 for their respective product models 150, they report back to the central service program 98 that the creation proposals have been carried out.
  • a similar process is triggered when an application 200 changes or deletes an existing data object 300 (change management). If a relationship type 600 is determined with a checking rule, this is used to check whether there is still a consistent state after the change or whether, for example, the change violates a rule that can be executed automatically and assigned to a relationship type.
  • the system 10 also supports the simultaneous collaboration of different applications 200 (current engineering). Changes that a first application 200.1 makes to a first model 150.1 of the product or process often have an effect on a second model that is processed by a second application 200.2. However, the first application 200.1 has no write access to the second model 150.2, because the processing of the second model is the responsibility of the users of the second application 200.2. In this case, the system 10 determines which data objects of the first model 150.1 are affected by the change. It determines which relations link this data object with other data objects and which regulations are assigned to the types of these relations.
  • a procedure and a data model are preferably selected that are independent of a specific application.
  • One embodiment provides that the syntax "extended markup language” (XML) with "XML Schema Definition” (XSD) is used and information is saved as ASCII text or text in Unicode format.
  • XML extended markup language
  • XSD XML Schema Definition
  • information about data object types 500 and relationship types 600 are stored in different files and / or tables in a relational database. Each type is saved as a separate XML entity in a separate data record in a table.
  • Applications 200 have read and write access to the central database 100 of the system 10 according to the invention as central data storage via defined information forwarding interfaces 250.
  • ODBC Open Database Connectivity
  • SQL Standard Query Language
  • Data objects 300 are preferably stored together with the respective product model 150, but relations are separated from the applications 200 in the central database 100 together with the types.
  • the user interface 50 of the system 10 according to the invention is preferably implemented separately from the central service program 98.
  • the user interface 50 can thus be tailored and “personalized” to different users without having to adapt the data storage to different user groups. For example, an experienced user is offered more options for action than a newcomer, while a newcomer receives more assistance.
  • Central utility 98 also preferably creates and manages models for read and write permissions, behavior, skills, and preferences of users who use at least one of applications 200 (user modeling).
  • These "user profiles" are managed in the central database 100.
  • the users are categorized into different classes.
  • the applications 200 have read access to these profiles and generate local user interfaces of the applications which are based on the respective Because these profiles and authorizations are stored and managed centrally for the users, they only need to be created and maintained once. It is not necessary for each application to manage 200 such profiles separately. This is inevitably with double data storage and is considerable more effort.
  • a user profile preferably also includes information that determines how the data object types are presented to the respective user.
  • information that determines how the data object types are presented to the respective user.
  • it is specified in which order which data object types appear in a navigation tree that is presented to the user.
  • This navigation tree can match the taxonomy, but can also be structured differently and not show all abstract data object types (types with subtypes), e.g. B. only the instantiable data object types.
  • the navigation tree for a particular user is constructed in such a way that the user can achieve certain types of data objects with few operations (eg "expand" and select). Data object types that a user frequently uses can be reached more quickly than others Data object types.
  • the system 10 has a user interface 50, which is preferably hidden from the users of the applications 200 and is used by an administrator and administrator of the central database 100 and the central service program 98.
  • the two syntaxes for two exemplary data models are outlined below.
  • the first data model referred to below as the class model, specifies how resource categories, resource types and data object types are stored in the central database 100.
  • the second data model hereinafter called the instance model, determines how resources (instances) are stored in the central database 100.
  • the instance model syntax can also be used to store data objects.
  • the specifications for both data models can e.g. B. using XML and XSD.
  • the class model syntax specifies the following:
  • the class model includes at least one class, and, if necessary, a specification of which version of the class model is used.
  • the class model can include any number of classes.
  • the class is a resource category, a resource type or a data object type, an internal identifier and at least one externally visible name of the class - a name is preferably stored for each natural language used, which simple parameters the class has, with a class having no, one or more simple parameters.
  • the measuring unit e.g. mm
  • an elementary data type e.g. integer
  • a preset value access value
  • a range of values and Explanations saved, which complex parameters the class has, whereby a class has no, one or more complex parameters.
  • a complex parameter refers to a type of complex parameter, which is a user-defined data type, and includes internal ID, names and default values, which methods the class has, whereby a class has none, one or more methods.
  • Each method is identified by its internal identifier, name, list of arguments (with argument name and data type), type of return value (return type) and method body (body), which dependencies the class has, whereby the dependencies are formulated as automatically evaluable rules .
  • Administrative information e.g. B. Determinations of who has read and who has write access to the class, who created the class when, who last changed it and when, which applications have 200 read access to the class.
  • An automatically evaluable rule can be implemented as a parameter or as a method of a relation type or a relation type category.
  • the syntax for the instance model specifies the following:
  • the instance model comprises at least one instance, that is, a relation or a data object, and, if necessary, a specification of which version of the instance model is used.
  • the instance model can include any number of instances.
  • the instance is a relation or a data object, a reference to the relation type or data object type to which the instance belongs, preferably by specifying the internal identifier of the type, an internal identifier and at least one externally visible name of the instance - preferably one name per natural language used saved which simple parameters the instance has,
  • one data record per data object type 500 is created according to the class model.
  • n + 1 data records are created, namely one for the relationship type 600.1 itself and one for a reference to a partner, i. H. a data object type 500. a or on another relation type 600. a, which is assigned to the relation type 600.1 and is connected to other types by 600.1.
  • the relational database is preferably structured in normal form, each table implements 1: 1 and 1: n links, but no m: n links with m> 1 and n> 1.
  • the internal identifiers of the types function as keys of the data records.
  • the XML statements to represent the parameters and methods of a type are entered as text in a single cell of the data record.
  • An XML statement for a reference to another type is also entered in a single cell.
  • This embodiment has the advantage, among other things, that information can be read quickly from the central database 100 and that the database schema even when a data model is changed, e.g. B. the co- The "XML Schema Definition" (XSD) implemented class model does not need to be changed.
  • XSD XML Schema Definition
  • relation type categories, relation types and data object types are read in from the central database 100
  • the links between categories and types are kept available in the form of duplicate lists in the random access memory of the data processing system.
  • the central service program 98 generates these lists in the working memory. If an application 200 needs information about a category or type, e.g. If, for example, the taxonomy under relation type categories, read access to the central database 100 is not necessary. Rather, the required information is obtained with the help of pointers to specific memory cells in the main memory. This embodiment saves computing time because accessing permanent storage media takes more time than accessing a temporary storage medium such as a working memory.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Manufacturing & Machinery (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

La présente invention concerne un système (10) pour produire et enregistrer des objets de données (300.1, 300.2,..) qui représentent respectivement un élément constitutif d'un produit technique ou une étape du processus de création du produit. Selon l'invention, le système (10) est capable de produire des types de relations (600.1, 600.2, ...) entre plusieurs types d'objets de données (500.1, 500.2, ...) et d'associer à ces types des types d'objets de données (500.1, 500.2, ...) et des dispositions automatiquement exploitables de différences entre objets de données (300.1, 300.2, ...). De préférence, une taxonomie est prévue pour des types d'objets de données (500.1, 500.2, ...) de différentes phases du processus de création. L'invention permet le couplage de différentes applications (200.1, 200.2, ...) pour des phases déterminées respectives, sans nécessiter la production et l'entretien d'un modèle intermédiaire ou d'interfaces directes entre les applications.
EP03738033A 2002-06-27 2003-06-13 Systeme de production d'informations pour creation de produits Withdrawn EP1516234A2 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
DE10228906 2002-06-27
DE10228906 2002-06-27
DE10236384 2002-08-08
DE10236384A DE10236384A1 (de) 2002-06-27 2002-08-08 Informationserzeugungssystem für die Produktentstehung
PCT/EP2003/006270 WO2004003798A2 (fr) 2002-06-27 2003-06-13 Systeme de production d'informations pour creation de produits

Publications (1)

Publication Number Publication Date
EP1516234A2 true EP1516234A2 (fr) 2005-03-23

Family

ID=30001483

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03738033A Withdrawn EP1516234A2 (fr) 2002-06-27 2003-06-13 Systeme de production d'informations pour creation de produits

Country Status (3)

Country Link
US (1) US20050246160A1 (fr)
EP (1) EP1516234A2 (fr)
WO (1) WO2004003798A2 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100498810C (zh) * 2002-08-21 2009-06-10 斯戴勒斯机械公司 解释设计数据并使该数据和制造信息相关联的方法以及实现该方法的软件和***
US7398129B2 (en) * 2004-10-07 2008-07-08 Amada Company, Limited Representation of sheet metal part models
US7584200B2 (en) * 2005-01-31 2009-09-01 International Business Machines Corporation Graphical database navigator with relation level control
US8554520B2 (en) * 2007-05-01 2013-10-08 Auto Prep, Llc Systems and methods for differentiating and associating multiple drawings in a CAD environment
US8600706B2 (en) 2007-05-01 2013-12-03 Auto Prep, Llc Systems and methods for identifying crash sources in a CAD environment
FI20125700A (fi) * 2012-06-21 2013-12-22 Tekla Corp Yhteisdata suhdetiedolla
CN103049532A (zh) * 2012-12-21 2013-04-17 东莞中国科学院云计算产业技术创新与育成中心 基于突发事件应急管理的知识库引擎构建及其查询方法

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2004003798A3 (fr) 2004-03-04
US20050246160A1 (en) 2005-11-03
WO2004003798A2 (fr) 2004-01-08

Similar Documents

Publication Publication Date Title
DE60008264T2 (de) Datenaustausch zwischen cad-systemen
DE69031758T2 (de) Verfahren zur Organisation von und zum Zugriff auf Produkt beschreibenden Daten in Zusammenhang mit einem technischen Prozess
DE69704624T2 (de) System und verfahren für dynamische datenreferenz in einer generischen datenaustauschumgebung
DE19705955A1 (de) Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung
DE102011001460A1 (de) Verfahren und Gerät für eine datengesteuerte Schnittstelle basierend auf Relationen zwischen Prozesssteuerungsetiketten
DE60209631T2 (de) Verfahren zur Programmierung einer Automatisierungsapplikation
EP1699005A1 (fr) Integration de MES et ingenierie de contrôle
EP1674954A1 (fr) Sytème et procédé de réutilisation des données de conception
EP1397730B1 (fr) Procede permettant de determiner les effets de decisions de conception
EP3364257A1 (fr) Procédé de fonctionnement d'un système d'ingénierie pour un système d'automatisation de processus industriel et programme de commande
DE10149692A1 (de) Objekt-orientierte Datenverarbeitung
EP1516234A2 (fr) Systeme de production d'informations pour creation de produits
DE4417393A1 (de) Eine Methode zur Herstellung spezifischer Programm-Systeme und Sammlungen von Unterstützungsprogrammen (Tools) zur Erleichterung von Programmsystem-Herstellungsarbeiten
DE10324594A1 (de) Verfahren zum Bereitstellen einer verbesserten Simulationsfähigkeit eines dynamischen Systems außerhalb der ursprünglichen Modellierungsumgebung
WO2003001310A2 (fr) Procede de determination des effets de modification de conception
EP1347376B1 (fr) Logiciel visualisant des structures hierarchisées de données
DE102020119853B3 (de) Verfahren zum Steuern eines Automatisierungssystems mit Visualisierung von Programmobjekten eines Steuerprogramms des Automatisierungssystems und Automatisierungssystem
DE102011082838A1 (de) Identifikation wiederverwendbarer mechatronischer Komponenten in der Fabrikautomation
EP1285315B1 (fr) Systeme de traitement d'informations et son procede d'exploitation
DE69329007T2 (de) Kompilierungsmechanismus für Simulationsmodelle
DE10236384A1 (de) Informationserzeugungssystem für die Produktentstehung
WO1995014281A1 (fr) Procede de modelisation automatique d'une partie d'un processus global a l'aide d'un ordinateur
DE102004023634B4 (de) Verfahren zur Vollständigkeits- und Konsistenzprüfung einer Informationsbibliothek
EP2093663A1 (fr) Système d'ingénierie pour le développement d'un projet et procédé
EP1332446A2 (fr) Systeme, procede et programme informatique destines a la configuration d'objets

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

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

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

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20060621