WO2000022552A1

WO2000022552A1 - Method and device for modeling a technical system

Info

Publication number: WO2000022552A1
Application number: PCT/DE1999/003175
Authority: WO
Inventors: Bernhard Thome; Matthias Rosenberger
Original assignee: Siemens Aktiengesellschaft
Priority date: 1998-10-14
Filing date: 1999-10-01
Publication date: 2000-04-20

Abstract

Various requirements are predefined in order to model a technical system. Said requirements can be met by certain architectural modules. At least one concept for the realization thereof is provided. Configurations for meeting said requirements are determined by establishing a realization concept for each architectural module. Optimum configurations with respect to a given target function are used for modeling.

Description

description

Method and arrangement for modeling a technical system

The invention relates to a method and an arrangement for modeling a technical system.

When modeling a technical system, it is difficult to determine the suitable parameters from a large number of parameters that parameterize the system. In particular, 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. This is a complex project, since a variety of different factors affect the costs and each selection of a component determining the technical system has a number of implications that cannot be considered manually or only possible with great effort and a high probability of errors is.

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.

This object is achieved in accordance with the features of the independent claims. Further developments of the invention also result from the dependent claims.

To solve the problem, 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. For each

Architectural building block is given at least one implementation concept. For the at least one requirement Configurations determined by determining an implementation concept for each of the at least one architectural component of the requirement. In addition, that configuration is determined that fulfills a predetermined condition. The determined configuration is used to model the technical system.

In particular, for a request,. which comprises a plurality of architectural components, a multiplicity of configurations are determined, if in turn several for each architectural component

Realization options are available. From the several configurations, a configuration that is best in terms of the condition can now be determined automatically, depending on a predetermined condition. This configuration is suitable for modeling the technical system.

A further development is that all possible configurations are determined. For this purpose, all possible implementation concepts for each architectural component are preferably taken into account.

Another further development is that the modeling of the technical system is used for the design and / or control. In particular, the draft or a

Planning the technical system includes a new design or an adaptation of an existing system. In the first case, the technical system is redesigned as part of the modeling and preferably implemented according to this design. In the second case (adaptation), 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.

One embodiment consists in the fact that the predetermined condition comprises an optimization of a target function. there In particular, 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.

Furthermore, the requirement or the configurations themselves can also be provided with attributes. In particular, a benefit can be determined by multiplying the importance of a requirement by a predetermined degree of fulfillment of a configuration. By default, the degree of fulfillment can be preset to 100%.

In another configuration, 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

Implementation of the requirement is described with the objective function, d) There may be an environmental impact when the

Requirement to be captured by the target function. e) The period of time until the completion of the

Realization be described with the target function. f) 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. g) Furthermore, 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.

If a configuration differs from another by no more than a predetermined tolerance limit with regard to its value determined by a first objective function, 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).

Another further development relates to an automated specification of different implementation concepts for one architecture module or for several architecture modules. These implementation concepts can take the form of a

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.

In particular, several of the above-mentioned attributes can be provided per implementation concept, which are taken into account in a suitable manner in the target function. Certain attributes for certain (different) target functions can also be present. Furthermore, it is a further development that the configuration is determined which, after taking into account the attribute values, in particular a number of requirements fulfilled by it or architectural modules connected to it, delivers the best value for the target function. By an already selected one

Implementation concept, the architecture module is determined and further requirements can fall back on this selected architecture module. As a result, synergetic effects are advantageously exploited and, for example, a cheapest implementation of the implementation concepts to meet the multiple requirements is determined.

Another development is that the method is terminated as soon as • a predefined variable has reached a predefined threshold value or • a predefined number of iterations has been carried out.

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.

It is also a further development that, through the selection of an implementation concept, a given influence on at least one other implementation concept is taken into account.

Furthermore, to achieve the above-mentioned object, an arrangement for modeling a technical system is provided, which has a processor unit that is set up in such a way that a) at least one requirement can be specified, the

Realization based on at least one given

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.

This arrangement is particularly suitable for carrying out the method according to the invention or one of its developments explained above.

Embodiments of the invention are illustrated and explained below with reference to the drawing.

Show it

Fig.l is a sketch showing the dependencies between the requirement, architectural component and implementation concept;

2 shows a block diagram with steps of a method for modeling a technical system;

3 shows a sketch depicting dependencies between the requirement, the architectural component and the implementation concept for computer peripherals;

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;

7 shows a block diagram with steps of a modified method for modeling a technical system.

In Fig.l a sketch is shown, which shows dependencies between the requirement, architectural component and implementation concept of a technical system. For this purpose, 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

Importance of 0.15. In addition, the 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. In order to implement requirement 102, the architectural modules 103 "supply module" and 104 "motor" are required.

There are different implementation concepts for the implementation of the respective architectural components. So he can

Architecture module 103 "feed module" using the

Realization concept 105 "unregulated feed module,

10/25 KW ", costs 50DM, or based on the

Realization concept 106 "E / R module, 0 pulse resistance, 16 / 21KW", cost 70DM, to be implemented. To realize the

So there are two building blocks 103

Realization concepts 105 and 106.

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 and implementation concept 109 "engine type 3" also costs 90 DM.

Configurations are now determined from the data given so far. 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.

For example, of all configurations 110 to 114, 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%. The implementation of the requirement 101 created by the implementation of the architectural module 103 therefore has a benefit contribution of 0.15 * 0 = 0. If configuration 111 is selected to implement request 101, the corresponding benefit contribution is 0.15 * 1 = 0.15.

2 shows a block diagram with steps of a method for modeling a technical system. In step 201, requirements are specified. In a step 202, relationships to architectural components are specified for all requirements. In particular, the requirements are defined here: Each requirement comprises at least one architectural component that is necessary to implement the requirement. In a 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. In a next step 205, possible configurations are determined. If there are several requirements, possible configurations are determined for each requirement. In 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

Condition best met. 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. In the example of FIG. 1, such 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.

Alternatively, several configurations can be determined, all of which meet the specified condition with one

Meet minimum level of goodness. This quality can be defined by a threshold value which is not to be exceeded or undershot for the value of the target function. Depending on the application, the target function can be minimized or maximized; in the example of the costs, the aim is often to minimize, and vice versa to maximize the benefits. In 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

Requirement, architectural components and implementation concepts for units of the computer periphery. 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

Priority of "16". The architecture blocks 303 and 304 "SCSI CD-ROM drive" are required for this. There are two different implementation concepts 305 and 306 for the architecture module 303. 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

Table with "Rl", the request 302 abbreviated to "R2". 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. Finally, requirement 302 can be met by the

Realization concepts 306 and 308 for a total price of DM 1,100, a benefit of "20" and a cost-benefit ratio of 55.

Finally, if you consider the six configurations listed (see lines) in the table in Fig. 4, the third configuration (at the total price of 250 DM) results in "the best" cost-benefit ratio (12.5). Requirement 301 and requirement 302 are met equally and at a comparatively low price. The mentioned analysis of the cost-benefit ratio does not take quality requirements into account in the present case, these could be separated by the degree of fulfillment of the

Configurations, but the benefits related to the total cost. Based on this premise, the configuration in line 3 is the best without compromise.

In FIG. 5, cumulative costs, i.e. cost contributions of the implementation concepts, are dependent on

Customer requirements. A request R2 includes the implementation concepts K1 and K2, a request R5 includes the implementation concepts K2, K9 and K11 and a request R11 includes the implementation concepts K1, K12 and K8. Has a product planner or developer

Realization of the requirement Rl decided and this implemented on the basis of the implementation concepts K1 and K2, so that when the requirement R5 is implemented on the basis of the implementation concepts K2, K9 and Kll, there are only expenses (costs) for the implementation concepts K9 and K1. The

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. Furthermore, 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. In block 701, a plurality of predefined variables are entered into the method. These variables are, in particular, the domain model for the automatic determination of the implementation concepts, a customer information file for the automatic selection of the domain model and the relationships between the requirement and the architectural components. A preconceived list of requirements can also be stored in the customer information file. In addition, a strategy for determining the objective function, risks of the implementation concept and an effort limit for the system to be defined can be stored in block 701. Levels of fulfillment of configurations and selected competitors are also possible as inputs. In a block 702, configurations are determined by taking into account the specified criteria (= requirements), architecture modules, implementation concepts. In block 703, it is automatically checked for each criterion with regard to a predetermined strategy, by which configuration it is best fulfilled. In one

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. In 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.

Claims

claims

1. Method for modeling a technical system, a) in which at least one requirement is specified, the realization of which is carried out using at least one predetermined architectural module; b) in which at least one implementation concept is specified for each architectural component; c) in which configurations are determined for the request, for the at least one

Architectural component of the requirement, one implementation concept is determined; d) in which the configuration is determined which fulfills a predetermined condition; e) in which the determined configuration is used to model the technical system.

2. The method of claim 1, wherein all configurations for the request are determined by all possible

Implementation concepts for each architecture component on which the requirement is based are taken into account.

3. The method according to claim 1 or 2, wherein the modeling of the technical system for design, planning or control is used.

4. The method of claim 3, wherein the design of the technical system

New design or adaptation of an existing technical system includes.

5. The method according to any one of the preceding claims, wherein the predetermined condition comprises an optimization of a target function.

Method according to Claim 5, in which the objective function is given by one of the following options: a) costs when the request is implemented; b) benefits in realizing the requirement; c) cost / benefit ratio when implementing the requirement; d) environmental impact when the requirement is implemented; e) Duration of the realization of the requirement.

7. The method according to any one of claims 5 or 6, wherein the implementation concept, the requirement, the architectural component and / or the configuration contain at least one attribute that can be assessed with respect to the target function.

8. The method of claim 7, wherein the attribute is a bonus value or a penalty value.

9. The method according to any one of the preceding claims, in which different implementation concepts for the architectural module are automatically determined by a domain model.

10. The method according to any one of the preceding claims, in which that configuration or configurations for multiple requirements is / are determined that meet the specified condition.

11. The method according to any one of the preceding claims, in which an additional objective function is used to assess the configurations if one configuration differs from another by no more than a predetermined tolerance limit with regard to its value determined by a first objective function.

12. The method as claimed in one of the preceding claims, in which, by selecting an implementation concept, a predetermined implication for at least one other architectural component than the selected implementation concept is taken into account.

13. The method according to any one of the preceding claims, in which a predetermined implication for at least one other implementation concept is taken into account by selecting an implementation concept.

14. Arrangement for modeling a technical system with a processor unit, which is set up in such a way that a) at least one requirement can be specified, the implementation of which takes place on the basis of at least one predetermined architectural module; 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.