WO2000022552A1 - Procede et dispositif de modelisation d'un systeme technique - Google Patents

Procede et dispositif de modelisation d'un systeme technique Download PDF

Info

Publication number
WO2000022552A1
WO2000022552A1 PCT/DE1999/003175 DE9903175W WO0022552A1 WO 2000022552 A1 WO2000022552 A1 WO 2000022552A1 DE 9903175 W DE9903175 W DE 9903175W WO 0022552 A1 WO0022552 A1 WO 0022552A1
Authority
WO
WIPO (PCT)
Prior art keywords
requirement
determined
implementation
configuration
technical system
Prior art date
Application number
PCT/DE1999/003175
Other languages
German (de)
English (en)
Inventor
Bernhard Thome
Matthias Rosenberger
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2000022552A1 publication Critical patent/WO2000022552A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation

Definitions

  • the invention relates to a method and an arrangement for modeling a technical system.
  • a target function serves this purpose, e.g. a cost function for the implementation of the technical system, which is optimized as part of a suitable modeling with regard to the lowest possible total costs.
  • the object of the invention is to enable safe and / or reliable modeling of a technical system, automatically taking complex interrelationships and multifaceted dependencies into account.
  • a method for modeling a technical system is specified, in which at least one requirement is specified, the implementation of which is carried out using at least one architectural module.
  • Architectural building block is given at least one implementation concept.
  • Configurations determined by determining an implementation concept for each of the at least one architectural component of the requirement.
  • that configuration is determined that fulfills a predetermined condition.
  • the determined configuration is used to model the technical system.
  • a multiplicity of configurations are determined, if in turn several for each architectural component
  • Planning the technical system includes a new design or an adaptation of an existing system.
  • the technical system is redesigned as part of the modeling and preferably implemented according to this design.
  • an existing system in particular is "designed” in such a way that the control or implementation of this system is carried out in accordance with the requirements of the present method.
  • the predetermined condition comprises an optimization of a target function.
  • each implementation concept is given an attribute that is taken into account in the target function.
  • Optimizing the target function is done, for example, by maximizing or minimizing a function of the attributes.
  • a benefit can be determined by multiplying the importance of a requirement by a predetermined degree of fulfillment of a configuration.
  • the degree of fulfillment can be preset to 100%.
  • the objective function is given, for example, by one of the following options (no exhaustive list): a) The costs are taken into account when realizing the request. An optimization of the objective function "costs" concerns the minimization of the same. b) The benefit in realizing the requirement is recorded in the form of the objective function. Optimizing the "benefit” is associated with maximizing it. c) A cost-benefit ratio for implementation and / or
  • An overall risk for example a risk associated with the choice of a particular technology, can also be determined and taken into account in the objective function.
  • a differentiation from competitors can be made by the requirements with an importance and a degree of fulfillment per competitor. A point of sale is determined by multiplying your own planned degree of fulfillment (100% by default) minus the competitor's degree of fulfillment by the importance of the requirement. The sum of all sales points for all requirements (here the target function) is then maximized.
  • an additional objective function can be used to assess the configurations.
  • the attribute taken into account by the target function can be both a bonus value and a penalty value for the requirement, the architecture module, the implementation concept or the configuration (positive or negative attribute).
  • Domain model are provided.
  • the selection of an architecture module then automatically leads to the implementation concepts available in the domain model with the attributes describing the respective implementation concept.
  • the architecture module is determined and further requirements can fall back on this selected architecture module.
  • synergetic effects are advantageously exploited and, for example, a cheapest implementation of the implementation concepts to meet the multiple requirements is determined.
  • Another further development consists in the fact that, by selecting an implementation concept, a predetermined influence (implication) on at least one other architectural component than the one on which the selected implementation concept is based is taken into account.
  • an arrangement for modeling a technical system which has a processor unit that is set up in such a way that a) at least one requirement can be specified, the
  • Architectural building block b) at least one implementation concept can be specified for each architectural component; c) configurations can be determined for the requirement in that one implementation concept can be determined for each of the at least one architectural component; d) that configuration can be determined which fulfills a predetermined condition; e) the determined configuration can be used to model the technical system.
  • Fig.l is a sketch showing the dependencies between the requirement, architectural component and implementation concept
  • FIG. 2 shows a block diagram with steps of a method for modeling a technical system
  • FIG. 4 shows a table with possible configurations for FIG. 3
  • 5 shows a diagram which shows a target cost achievement depending on certain configurations
  • 6 shows a processor unit
  • FIG. 7 shows a block diagram with steps of a modified method for modeling a technical system.
  • Fig.l a sketch is shown, which shows dependencies between the requirement, architectural component and implementation concept of a technical system.
  • Fig.l includes the requirements 101 and 102, the architectural components 103 and 104, the implementation concepts 105 to 109 and the configurations 110 to 114.
  • the requirement 101 contains the statement that an infeed module must enable feedback.
  • the request 101 is with a
  • Request 101 requires the architecture module 103 "feed module”.
  • Request 102 includes the statement that an engine must deliver up to 25 KW.
  • the request 102 has an importance of 0.2.
  • the architectural modules 103 "supply module” and 104 "motor” are required.
  • the architecture module 104 "motor” can be implemented using three implementation concepts 107, 108 and 109.
  • the realization concept 107 "engine type 1” costs 100 DM
  • Realization concept 108 "engine type 2” costs 90 DM
  • implementation concept 109 "engine type 3” also costs 90 DM.
  • Configuration 110 contains this
  • Realization concept 105 This fulfills requirement 101, which contains the architectural component 103.
  • the configuration 111 contains the module 106 as an implementation concept and thus fulfills the requirement 101.
  • the configuration 112 contains the implementation concepts 105 and 107 and fulfills the requirement 102.
  • the configuration 113 contains the implementation concepts 105 and 108 and fulfills the requirement 102.
  • the configuration 114 contains the implementation concepts 106 and 107 and fulfills the requirement 102.
  • configuration 114 fulfills both requirements 101 and 102 equally.
  • the requirement 101 has a importance of 0.15 and the configuration 110 has a degree of fulfillment of 0%.
  • step 201 requirements are specified.
  • step 202 relationships to architectural components are specified for all requirements.
  • the requirements are defined here:
  • Each requirement comprises at least one architectural component that is necessary to implement the requirement.
  • step 203 the architecture building blocks are specified in more detail by possible Realization concepts for the architectural building blocks can be specified.
  • the possible implementation concepts can alternatively be specified using a domain model 204, for example in the form of a database. In the example above (FIG. 1), it is possible, using a domain model for motors, to automatically predetermine the architectural component 104 using a large number of possible implementation concepts 107 to 109.
  • step 206 an appropriate configuration of the multiple configurations is determined. This is done by examining the multiple configurations for a given condition. In particular, the configuration is determined that the specified one
  • the specified condition can be formulated as an optimization requirement for a target function.
  • the target function is preferably composed of attributes that have the implementation concepts, requirements and / or configurations.
  • attributes are the costs for the implementation concepts, the importance for the requirements and the degree of fulfillment for the configurations
  • the objective function includes the total costs for the implementation of a requirement
  • the optimization of the objective function consists in minimal costs for an implementation to apply both requirements 101 and 102.
  • step 207 the result, that is to say the configuration determined, is used to model the technical system.
  • Fig.3 shows a sketch showing the dependencies between
  • the requirements 301 and 302 are implemented using architectural components 303 and 304, alternative implementation concepts 305 to 308 being specified.
  • Request 301 requires a SCSI scanner port with a priority of "4". This requirement 301 requires the architecture module 303, a SCSI interface.
  • Request 302 requires a SCSI CD-ROM drive for an operating system installation with a
  • the architecture blocks 303 and 304 "SCSI CD-ROM drive" are required for this.
  • the implementation concept 305 is an ISA SCSI card at a price of 100 DM.
  • the other implementation concept 306 is a PCI-SCSI card for the price of 300 DM.
  • the architecture module 304 can be implemented on the basis of two implementation concepts.
  • Realization concept 307 is a 4xCD-ROM drive for internal installation at a price of 150DM.
  • Realization concept 308 is a 20xCD-ROM drive for external use at a price of 800DM.
  • Fig. 4 shows possible configurations in the form of a table for the example of Fig. 3.
  • the request 301 is in the
  • the architecture module 303 is abbreviated “ABI” and the architecture module 304 is abbreviated “AB2”.
  • the first line in the table of Figure 4 shows that the request 301 "Rl” by the architecture block 303 "ABI" with the
  • Realization concept 305 for the price of 100 DM and a benefit of "4" is implemented.
  • the benefit "4" corresponds to the Priority of requirement 301.
  • the cost-benefit ratio for the first possible configuration is therefore 25.
  • the second option (second line of the table) uses the implementation concept 306 for the price of 300 DM, also with priority 4. It results here a cost-benefit ratio of 75.
  • the third configuration (third line in the table in FIG. 4) relates to the requirement 302 “R2”, which is implemented using the architecture components 303 and 304.
  • the architectural components are implemented using the implementation concepts 305 and 307 at a total price of 250 DM.
  • the benefits result from adding priorities "4" and "16” to "20”.
  • the cost-benefit ratio is thus 12.5.
  • the fourth configuration also relates to request 302, implemented by the implementation concepts 305 and 308 at a price of 900 DM.
  • the benefit is again "20", the cost-benefit ratio 45.
  • a further configuration for implementing the requirement 302 takes into account the implementation concepts 306 and 307 for a total price of 450 DM and a benefit of "20". This results in a cost-benefit ratio of 22.5.
  • requirement 302 can be met by the
  • a request R2 includes the implementation concepts K1 and K2
  • a request R5 includes the implementation concepts K2
  • a request R11 includes the implementation concepts K1, K12 and K8.
  • Implementation concept K2 has already been implemented as part of requirement R2 and can flow synergistically into requirement R5. The same applies to the implementation of the requirement R11, which, based on the requirement R5, only requires expenditure for the additional implementation concepts K12 and K8.
  • a processor unit PRZE is shown in FIG.
  • the processor unit PRZE comprises a processor CPU, a memory SPE and an input / output interface IOS, which is used in different ways via an interface IFC: an output is visible on a monitor MON and / or on a printer via a graphic interface PRT issued. An entry is made using a mouse MAS or a keyboard TAST.
  • the processor unit PRZE also has a data bus BUS, which ensures the connection of a memory MEM, the processor CPU and the input / output interface IOS.
  • additional components can be connected to the data bus BUS, for example additional memory, data storage (hard disk) or scanner. 7 shows a modified method for modeling a technical system using a block diagram.
  • Step 704 determines a configuration which is best with regard to an objective function and preferably the best criterion, and the criterion with its configuration is deleted from a list of criteria which have not yet been selected.
  • a step 705 it is queried whether a configuration has already been selected for all criteria, if this is not the case, then in a step 706 it is queried whether the effort limit, for example target costs for a system, has been reached and if this is not the case The case branches back to step 703. If the effort limit has been reached, i.e. if a time period or budget for creating the product / system has run out or is overused, the amount of configuration is output in step 707, which was previously the best configuration for the selected requirements were determined. In step 705 the question was asked whether all criteria have been selected, the method branches directly to step 707.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Pour la modélisation d'un système technique sont prédéfinies des exigences qui peuvent être satisfaites à l'aide de certains éléments d'architecture. Au moins un concept de réalisation est prédéterminé pour chaque élément d'architecture. Des configurations destinées à la satisfaction des exigences sont établies par la détermination d'un concept de réalisation pour chaque élément d'architecture. Les configurations qui sont utilisées pour la modélisation sont celles qui sont optimales dans la perspective d'une fonction cible donnée.
PCT/DE1999/003175 1998-10-14 1999-10-01 Procede et dispositif de modelisation d'un systeme technique WO2000022552A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE19847373.7 1998-10-14
DE19847373 1998-10-14

Publications (1)

Publication Number Publication Date
WO2000022552A1 true WO2000022552A1 (fr) 2000-04-20

Family

ID=7884453

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE1999/003175 WO2000022552A1 (fr) 1998-10-14 1999-10-01 Procede et dispositif de modelisation d'un systeme technique

Country Status (1)

Country Link
WO (1) WO2000022552A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000034057A1 (fr) 1998-12-08 2000-06-15 Dt Swiss Ag Moyeu de roue libre
DE10125688A1 (de) * 2001-05-25 2002-12-05 Advanced Photonics Tech Ag Computergestütztes Entwurfsverfahren und Expertensystem zur Erstellung thermischer Bearbeitungsanordnungen

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4604718A (en) * 1983-04-25 1986-08-05 Simulated Designs, Ltd. Computer simulation system
DE29601198U1 (de) * 1996-01-26 1996-03-28 Specht, Hubert, 91074 Herzogenaurach Simulationseinrichtung
US5687094A (en) * 1994-07-06 1997-11-11 Matsushita Electric Industrial Co., Ltd. Design verification apparatus
US5754738A (en) * 1996-06-07 1998-05-19 Camc Corporation Computerized prototyping system employing virtual system design enviroment
US5872957A (en) * 1997-05-01 1999-02-16 International Business Machines Corporation Method for flexible simulation modeling of multi-component systems

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4604718A (en) * 1983-04-25 1986-08-05 Simulated Designs, Ltd. Computer simulation system
US5687094A (en) * 1994-07-06 1997-11-11 Matsushita Electric Industrial Co., Ltd. Design verification apparatus
DE29601198U1 (de) * 1996-01-26 1996-03-28 Specht, Hubert, 91074 Herzogenaurach Simulationseinrichtung
US5754738A (en) * 1996-06-07 1998-05-19 Camc Corporation Computerized prototyping system employing virtual system design enviroment
US5872957A (en) * 1997-05-01 1999-02-16 International Business Machines Corporation Method for flexible simulation modeling of multi-component systems

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000034057A1 (fr) 1998-12-08 2000-06-15 Dt Swiss Ag Moyeu de roue libre
DE10125688A1 (de) * 2001-05-25 2002-12-05 Advanced Photonics Tech Ag Computergestütztes Entwurfsverfahren und Expertensystem zur Erstellung thermischer Bearbeitungsanordnungen

Similar Documents

Publication Publication Date Title
DE3855706T2 (de) Automatisierte Rechnung von Materialien
DE4410775C2 (de) Steuergerät und Arbeitsverfahren eines Betriebssystems für dieses Steuergerät
WO2000011581A1 (fr) Procede ameliore d'affectation des couts basee sur la quantite a partir de differentes sources d'informations
WO2011131509A1 (fr) Programme nc et procédé permettant de simplifier la post-production sur une machine-outil
DE69532307T2 (de) Ausdrucks-Propagierung für hierarchisches Netzlisten
DE19814422A1 (de) System zur Lösung eines Randbedingungsproblems und Aufbau eines derartigen Systems
EP2439691A1 (fr) Dispositif et procédé d'établissement mécanique d'un schéma de processus
EP0770945A1 (fr) Procédé pour la génération automatique des schémas de procédés industriels
DE19960048A1 (de) Zeitgesteuerte Startbedingungen für Aktivitäten in Workflow-Management-Systemen
DE10034694B4 (de) Verfahren zum Vergleichen von Suchprofilen sowie dessen Verwendung
EP2088486B1 (fr) Procédé de mesure d'un système réel dynamique non linéaire selon un plan d'expériences
DE10256990A1 (de) Programmcodegenerator und Programm
DE68923126T2 (de) Automatisches Programmiersystem.
DE69020280T2 (de) Verfahren zur Bestimmung einer gewünschten Systemkonfiguration.
DE102020111204A1 (de) Verfahren zum Betreiben eines Steuergeräts für ein Kraftfahrzeug sowie entsprechendes Steuergerät
DE3689502T2 (de) System und Verfahren zur Programmstrukturierung durch Datentabellenübersetzung.
WO2000022552A1 (fr) Procede et dispositif de modelisation d'un systeme technique
EP2601594A1 (fr) Procédé et dispositif de traitement automatique de données en un format de cellule
EP2574996B1 (fr) Procédé de détermination de l'état de la charge partielle d'un système
EP1159655B1 (fr) Systeme d'automatisation comportant des objets d'automatisation composes d'elements modulaires
EP1516234A2 (fr) Systeme de production d'informations pour creation de produits
DE2418360A1 (de) Numerische werkzeugkorrektur bei einer werkzeugmaschinensteuerung
DE102022101000B4 (de) Verfahren und Vorrichtung zum Erzeugen einer CAM-orientierten Zeit-Spline-Kurve und -Oberfläche
WO2000072096A1 (fr) Procede, dispositif et programme informatique pour la conception d'un systeme technique
EP0814402A2 (fr) Méthode pour la conception ou pour l'adaptation d'un régulateur à logique floue, ou d'un système de régulateurs à logique floue interconnectés

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A1

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

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase