WO2007080437A2 - Process simulation software and hardware architecture and method - Google Patents

Process simulation software and hardware architecture and method Download PDF

Info

Publication number
WO2007080437A2
WO2007080437A2 PCT/HU2007/000002 HU2007000002W WO2007080437A2 WO 2007080437 A2 WO2007080437 A2 WO 2007080437A2 HU 2007000002 W HU2007000002 W HU 2007000002W WO 2007080437 A2 WO2007080437 A2 WO 2007080437A2
Authority
WO
WIPO (PCT)
Prior art keywords
software
state parameter
modules
output
processor
Prior art date
Application number
PCT/HU2007/000002
Other languages
French (fr)
Other versions
WO2007080437A9 (en
WO2007080437A3 (en
Inventor
Béla CSUKÁS
Gyöngyi BÁNKUTI
Sándor BALOGH
Original Assignee
Kaposvári Egyetern
Folyamatinformatika Kutató-Fejlesztö Betéti Társaság
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 Kaposvári Egyetern, Folyamatinformatika Kutató-Fejlesztö Betéti Társaság filed Critical Kaposvári Egyetern
Publication of WO2007080437A2 publication Critical patent/WO2007080437A2/en
Publication of WO2007080437A9 publication Critical patent/WO2007080437A9/en
Publication of WO2007080437A3 publication Critical patent/WO2007080437A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/30Circuit design
    • G06F30/32Circuit design at the digital level
    • G06F30/33Design verification, e.g. functional simulation or model checking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/30Circuit design
    • G06F30/36Circuit design at the analogue level
    • G06F30/367Design verification, e.g. using simulation, simulation program with integrated circuit emphasis [SPICE], direct methods or relaxation methods
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2117/00Details relating to the type or aim of the circuit design
    • G06F2117/08HW-SW co-design, e.g. HW-SW partitioning

Definitions

  • the invention relates to a software and hardware architecture for the simulation of a process, and the underlying method.
  • the invention primarily concerns a method which employs certain principles of parallel processing for the solving of otherwise complex computational problems.
  • the suggested software and hardware architecture facilitates the easy implementation of the suggested method.
  • US Patent No. 5,692,193 discloses a computer software architecture for controlling a parallel computer system.
  • the disclosed computer software architecture comprises multiple layers.
  • One of the layers contains so-called threads, which are defined as "lightweight" processes.
  • Such lightweight processes are than run on virtual processors.
  • US Patent Application No. 2002/0133325A1 discloses a system and method for the simulation of discrete events. Such events are either defined or mapped from a source.
  • the event models are run in parallel simulator engines.
  • a central scheduler minimizes computation time, and for this purpose the central scheduler is interfaced with the simulator engines on separate dedicated communication channels.
  • the scheduler also serves events to the simulation engines.
  • the disclosed simulation system and method is capable of simulating real-world events, such as the internal logic functions of a semiconductor device or a power consumption and associated heat characteristics of a digital circuit.
  • the applied simulator engines still require complex programming, and the disclosed system and method is difficult to implement for an arbitrary simulation problem.
  • US Patent Application No. 2002/0169785A1 discloses a computer system and method for the simulation of transport phenomena in a complex system.
  • the computer system comprises an object-oriented software product, the latter comprising two different sets of generic classes with variables for object types. An arbitrary number of variables may be added to the classes.
  • the suggested system and method is proposed for the numerical simulation of certain physical processes, such as the behaviour of a hydrocarbon reservoir.
  • the physical model proposed uses the notion of cells, and various state variables are assigned to cells.
  • the physical processes within cells are expressed with the help of a set of equations, where the equations represent rules between state variables of a cell, such as mass, energy, pressure, etc.
  • a changing phenomenon is modelled by calculating physical quantities at discrete time intervals.
  • US Patent Application No. 2002/0221086Al discloses another computer system and method for executing vector instructions, i.e. such instructions which may be executed in a parallel fashion.
  • the vector instructions are executed with configurable stream processors (CSP), where the CSP contains RISC (Reduced Instruction Set) computers and associated registers.
  • CSP configurable stream processors
  • RISC Reduced Instruction Set
  • the proposed system is suitable for use in multiprocessor configurations.
  • it is not disclosed or suggested how such a computer system may be programmed to facilitate the simulation of complex processes which otherwise require complicated mathematical tools.
  • a software architecture which comprises multiple substantially equal first software modules and multiple substantially equal second software modules.
  • Each first software module has an input variable representing a change of a state parameter, a memory for storing a state parameter and an output for outputting a value of a state parameter.
  • the first software modules are programmed to represent a passive element and to establish on the basis of a set of predetermined rules a value of a state parameter.
  • the term "passive element" means that a software module represents an entity which is under the influence of external rules, and possible states of that entity are determined by these external rules, hence, the represented entity is subjected to the external rules and passively yields to the rules.
  • the set of predetermined rules establishing the values of the state parameters are defined so that a resulting output value of the rules may be calculated substantially without repeated cycles.
  • Each second software module has an input variable representing a state parameter and an output for outputting a change of a state parameter.
  • the second software modules are programmed to represent an active element and to establish on the basis of a set of predetermined rules a change of a value of a state parameter.
  • active element means that a software module represents those rules which describe interactions between (typically different) entities, and in this manner actively form the state parameters (i. e. the actual state) of the affected entities.
  • the set of predetermined rules are defined so that a resulting output value of the rules may be calculated substantially without repeated cycles.
  • the suggested software architecture further comprises first connection means for communicating an output value of a state parameter from a first software module to the input of one or more second software modules, and second connection means for communicating an output value of a change of a state parameter from a second software module to the input of one or more first software modules.
  • the suggested software architecture further comprises cycle control means.
  • the cycle control means are adapted for causing
  • substantially all first software modules to establish the output values of the state parameters of their associated characteristic entities substantially simultaneously, and subsequently b, substantially all first connection means to communicate the output values from the first software module to the second software modules, and subsequently c, substantially all second software modules to establish the output values from their respective input state parameters substantially simultaneously, and subsequently d, substantially all second connection means to communicate the output values from the second software module to the first software modules, and to repeat steps a, to d, cyclically.
  • a hardware architecture comprising a set of processor modules arranged for the parallel processing of a task.
  • the hardware architecture comprises a first subset of processor modules comprising multiple substantially equal first processor modules.
  • the first processor modules being adapted for the execution of a first software module, where the first software module represents a passive element and establishes on the basis of a set of predetermined rules a state parameter.
  • the first processor modules have an input for receiving a change of a state parameter, a memory for storing a state parameter and an output for outputting a value of a state parameter.
  • the hardware architecture further comprises a second subset of processor modules comprising multiple substantially equal second processor modules.
  • the second processor modules are adapted for the execution of a second software module, where the second software module represents an active element and establishes on the basis of a set of predetermined rules a change of a state parameter.
  • the second processor modules have an input for receiving a state parameter and an output for outputting a change of a state parameter.
  • the hardware architecture further comprises first connection means for communicating an output value generated by a first software module in a first processor module to the input of one or more second software modules in a second processor module, and second connection means for communicating an output value from a second software module in a second processor module to the input of one or more first software modules in a first software module.
  • the hardware architecture further comprises cycle control means for causing a, substantially all first processor modules to establish output values of the first software modules substantially simultaneously, b, substantially all first connection means to communicate output values from the first software modules in a first processor module to the input of one or more second software modules in a second processor module, c, substantially all second processor modules to establish output values of the second software modules from their respective inputs substantially simultaneously, and d, substantially all second connection means to communicate output values from the second software modules in a second processor module to inputs of first software modules in a first processor module, and to repeat steps a, to d, cyclically.
  • the physical or conceptual process is regarded as a primary process, and the functioning and state of the primary process are simulated with the help of a computational secondary process.
  • the secondary process involves the essential structure and the elementary relationships determining the functioning and state of the primary process.
  • the following steps are performed: i, identifying characteristic entities of the primary process, and relevant structures and properties describing a state and a change of state of the characteristic entities; ii, defining a finite number of passive elements of the secondary process, and associating to each passive element a characteristic entity of the primary process, a set of state parameters describing the characteristic entity associated to the respective passive element, and a set of rules expressing a relationship between the state parameters of the characteristic entity associated to the respective passive element and/or expressing constraints imposed upon the state parameters of the characteristic entity associated to the respective passive element.
  • the set of rules are defined so that an application of the rules and thereby the determination of an output result resulting from the application of the rules may be performed readily and substantially without repeated cycles; iii, defining a finite number of active elements of the secondary process, and associating to each active element a set of rules, where the rules define a change of the state parameters of the entities associated to one or more passive elements.
  • the set of rules are defined so that an application of the rules and thereby the determination of an output result resulting from the application of the rules may be performed readily and substantially without repeated cycles; iv, defining a modifying channel between an active element and one or more passive elements, during which modifying channel a value of a change of a state parameter associated to the respective active element may be output towards the respective passive element(s); v, defining a reading feedback channel between a passive elements and one or more active elements, during which reading feedback channel a value of a state parameter may be fed to an input of an active element, where the rule associated to the respective active element involves a state parameter of the passive element at the input end of the respective reading channel.
  • the method further includes the steps of cyclically repeating the following steps: a, substantially simultaneously establishing on the basis of the set of rules associated to the respective passive element an output value of the set of state parameters of substantially each passive element, b, forwarding along the reading feedback channel(s) to one or more active elements the value(s) of the state parameters of the characteristic entity associated to the respective passive element, c, substantially simultaneously establishing on the basis of the rule associated to the respective active element output value(s) of the change of the state parameters, d, updating through the modifying channel(s) the state parameters of the physical entity associated to the respective passive element with the output value established in step c.
  • the disclosed software and hardware architecture and the underlying method allow the effective and realistic simulation of all types of processes. It is particularly suitable for the simulation of various physical, chemical and biological processes, which typically involve a large number of different physical entities, such as various materials in a chemical, physical or biological reaction, and different physical parameters describing the actual states of the materials. Such physical parameters may be the mass, temperature, pressure, dimension, etc. of the materials in question.
  • the state parameters may be also abstract parameters, and the entities simulated by the invented method and software architecture may be abstract entities, such as logical variables and their actual values.
  • the entities may represent physical devices, such as vessels or tanks, where their state is "empty” or “full” or the like. Further entities may be real or abstract signals and their state may describe their information content.
  • the suggested hardware architecture offers a possibility for the fast execution of the software modules in the software architecture of the invention, but otherwise the proposed software architecture may be readily run on traditional computers, as well.
  • the proposed method offers the advantage that even very complex processes may be handled in a simple and straightforward fashion, without having to bother about the existence or non-existence of an analytical solution to the equations describing the physical process. It is a particular advantage of the method that with the complexity of a mathematical problem, only the number of the software modules - and typically the number of connections between the software modules - increase, but otherwise the inherent programs of the software modules remain very simple.
  • a physical simulation may at all times remain between the limits of physical feasibility.
  • the actual calculated states of the entities very closely follow the parameters of a real physical process, and the various states of the process may be retrieved any time during the process.
  • the proposed software architecture is suitable for the simulation of all types of processes, e.g. physical or theoretical, continuous or discrete, quantitative or qualitative, analogous or digital process.
  • the system can handle mixed or hybrid type of processes in a straightforward manner, and in this way greatly facilitates the modelling of practically any process, without the need for extensive programming skills for an average user (who would typically have a technical educational degree, but not necessarily be a computer programming specialist).
  • FIG. 1 illustrates the general overview of the software architecture
  • Fig. 2 illustrates the generation and distribution process of program partitions among the first and second software modules
  • Fig. 3 illustrates the generation and distribution process of the dynamic data partitions, determining the prescribed state, as well as the prescribed changes of the states;
  • Fig. 4 shows an exemplary execution step 1 of the software architecture with the first software modules establishing output values of the state parameters of associated characteristic entities;
  • Fig. 5 shows an exemplary execution step 2 of the software architecture with the first connection means communicating the output values from the first software modules to the second software modules and the output interface;
  • Fig. 6 shows an exemplary execution step 3 of the software architecture with the second software modules establishing the output values of the respective input state parameters
  • Fig. 7. shows an exemplary execution step 4 of the software architecture with the second connection means communicating the output values from the second software module to the first software module and the output interface;
  • Fig. 8. illustrates the time- and event-dependency of the active states of the software modules in the software architecture
  • Fig. 9. illustrates the general view of the hardware architecture for process simulation according to the invention.
  • Fig. 10 illustrates an exemplary generation and distribution process of program and data partitions among of the first and second processor modules
  • Fig. 11. illustrates the hardware architecture, configured and programmed according to the actual task to be solved
  • Fig. 12. shows an exemplary execution step 1 of the hardware architecture with the first connection means communicating output values from the first processor modules to the second processor modules;
  • Fig. 13. shows an exemplary execution step 2 of the hardware architecture with the second processor modules establishing output values
  • Fig. 14. shows an exemplary execution step 3 of the hardware architecture with the second connection means communicating the output values from the second processor modules to the first processor modules;
  • Fig. 15. shows an exemplary execution step 4 of the hardware architecture with the first processor modules establishing output values
  • Fig. 16. illustrates the time- and event-dependency of the active states of the hardware modules of the hardware architecture.
  • Fig. 1 The essential features of the software architecture are shown in Fig. 1, illustrating how the resident part of a general kernel program 101 is extended by expert interfaces 102, 103 and user interfaces 104, 105 to generate a software architecture for process simulation.
  • First and second expert interfaces 102, 103 enable an expert to configure first and second program partitions 107, 112 respectively, thereby determining the system functionality.
  • First and second user interfaces 104, 105 are used by a user to configure a plurality of first and second data partitions 117, 125 respectively thereby determining the case specific structure and the initial state of the system.
  • the dynamically extendable core of the software architecture is supplemented by two sets of software modules: the so-called first software modules and the so-called second software modules.
  • the modules may have a number of inputs and outputs, and the modules perform calculations with the inputs, the results of the calculation being output as the outputs.
  • the calculations may be considered also as applying a set of rules on the inputs, and thereby generating the outputs of a software module.
  • the main common feature of both types of software modules is that the set of predetermined rules which are implemented during the execution of a software module are defined so that a resulting output value of the rules may be calculated substantially without repeated cycles during one step.
  • the fact that a software module practically does not contain calculations which would require extensive iterative programming, is a key feature of the proposed software architecture.
  • this feature makes it possible to simulate almost any arbitrary processes without the need for sophisticated mathematical tools (for example, for the solution of a higher-order equation), or without the need for special programming skills on the part of the user.
  • This feature also contributes to a simple implementation of the whole software architecture, as the software modules are more easily handled by the controlling kernel. Since the software modules do not contain a high number of cycles, they will require more or less the same execution time, which again facilitates parallel processing, and the parallel execution on multiple processors.
  • the software modules within the sets are considered as substantially equal, that is in a typical example, practically all software modules have the same simple structure: reading in the input values, executing the commands which specify certain rules, and outputting the outputs resulting from the application of the rules, where the rules are defined so that their application does not require any iterative (recursive) steps.
  • Such rules are typically expressed by equations which have a solution in a closed algebraic form, or by a finite number of constraints, which require a finite number of comparisons with predetermined values.
  • Experience shows that even very complex processes may be described so that the number of comparisons within a software module is very low, typically much less than hundred, i.e. a single software module is executed very fast.
  • first and second software modules have input variables which represent a change of a state parameter, while their output is a value of a state parameter.
  • State parameters are typically numerical and/or logical and/or symbolic values expressing a state of a simulated entity, such as a physical object, a physical signal or event.
  • the first software modules and the second software modules are configured, controlled or supervised by a dynamically extendable kernel program 101 serving only the most general functions common in all implementations and applications.
  • the kernel program and its extensions may be programmed in different programming languages or may be implemented under different platforms and operating systems.
  • the substantially equal first software modules are set up of dynamically added application specific first program partitions 107 configured according to generalized rules of the given application field, as well as according to the dynamically added case specific first structure and data partitions 117.
  • the program partitions are determined by an expert via expert interface 102, while the structure and data partition are generated for the specific modelling task through the user interface 104.
  • the substantially equal second software modules are set up of dynamically added application specific second program partitions 112 configured according to generalized rules of the given application field, as well as according to the dynamically added case specific second structure and data partitions 125.
  • the program partitions are determined by the expert via expert interface 103, while the structure and data partition are generated for the specific modelling task through the user interface 105.
  • the possible sets of dynamically added application specific first and second program partitions 107, 112 of the first and second software modules are determined during the different implementations and/or they can be dynamically modified through an expert interface 102 and 103 prepared for an expert user.
  • the first and second structure and data partitions 117 and 225 forming first and second databases may be generated in one or more steps automatically on the basis of user inputs provided through a user interface 104, 105 prepared for a class of problems to be solved.
  • the executable simulating program, denoted by 106 comprises the permanent core of the kernel program, extended by the dynamically added, domain specific program partitions 107, 112 defined by an expert user through the expert interface 102, 103, as well as case specific structure and data partitions 117, 125 carrying structural and parametrical information defined by a user through the user interface 104, 105.
  • the first and second software modules are similar in architecture, but differ in their content and the functionality defined by their content, which difference is realized during kernel operation.
  • a program partition 107 is shown. It is configured for a specific task of an application field, and comprises a small, program element 108.
  • a first program element 108 is capable of determining a specific functionality for producing output variables 110 in response to input variables 109 that models the change of state parameters. This process is controlled by a first program 111 and the calculation is carried out in a single step without any iteration.
  • the first program 111 represents the objective rules, describing the function of the first software modules so that the output of the changed state can be calculated with the knowledge of the input states without repetitions (iteration).
  • the first program element 108 can have possible input and output connections to many data elements 118 in many data partitions 117 containing the case specific data, as it is shown by directed graphs.
  • a program partition 112 is shown. It is configured for a specific task of an application field, and consists of a small, second program element 113.
  • a second program element 113 is capable of determining a specific functionality for producing output variables 115 in response to input variables 114, that models the calculation of elementary changes. This process is controlled by a program 116 and the calculation is carried out in a single step without any iteration.
  • the second program 116 represents the objective rules describing the function of the second software modules so that the output changes can be calculated with the knowledge of the input states without repetitions (iteration).
  • the second program element 113 can have possible input and output connections to many second data elements 126 in many second data partitions 125 of the case specific data, as it is shown by directed graphs.
  • the dynamically generated structure and data partitions 117 of the substantially equal first software modules form optional connected systems with the corresponding program elements 108 in the program partitions 107 during execution.
  • the first structure and data partition 117 is set up of a plurality of first data elements 118 comprising in this case two elements denoted by first output and input memory 119 and 120, respectively.
  • First output memory 119 shown in the drawing as a circle, stores an output variable for outputting a value of a state parameter from the actual first dynamic data set to the connected second software module while first input memory 120, shown in the drawing as a square, stores an input variable representing the actual state of a state parameter affected by the changes coining from the connected second software modules for the actual first dynamic data set.
  • the first data element 118 representing a first structure and data element, is provided with an input 121 for receiving input data through second connection means 133 as a communication channel from the connected second software modules.
  • the optionally modified value will be transmitted from an output 122 of the first input memory 120 to a first program input 109.
  • the response of the program 111 will be available at first program output 110 and will be transmitted to an input 123 of the first output memory 119 representing a state parameter, which in return will be transmitted from a first data output 124 of the first output memory 119 through first connection means 135 as a communication channel to the second software modules.
  • the dynamically generated structure and data partitions 125 of the substantially equal second software modules form optional connected systems with the corresponding program elements 113 in the program partitions 112 during execution.
  • the second structure and data partition 125 is set up of a plurality of second data elements 126 comprising a plurality of elements denoted by second output and input memory 127 and 128, respectively. They are connected with second program elements 113 within the set of second program partitions 112.
  • the data element 126 comprises in the shown embodiment three second output memory parts 127 depicted as a triangle for storing an output variable for outputting values of state parameter changes received from the connected program element 113 to the connected first software module.
  • the data element 126 also comprises in this case two second input memory parts 128 depicted as a circle for storing input variables representing the state parameters received from the connected first software modules.
  • the data element 126 representing a second structure and data element is provided with second data inputs 129 for receiving input data through first connection means 135 as communication channel from the connected first software modules.
  • the optionally modified value will be transmitted from an output 130 of the memory 128 to a second program input 114.
  • the response of the program 116 will be available at second program outputs 115 and will be transmitted to inputs 131 of second output memory 127 representing a state parameter change, which in return will be transmitted from second data outputs 132 of the memory 127 through second connection means 133 as a communication channel to the first software modules.
  • the output values of a change of a state parameter provided by the second software modules are transferred through second connection means 133 as a communication channel to the selected first software modules and, through second connection means 134 or communication channel to an output interface 137.
  • the output values of state parameters provided by the first software modules are transferred through first connection means 135 as a communication channel to the selected second software modules and through first connection means 136 or communication channel to the output interface 137.
  • Fig. 1 The software architecture of Fig. 1 will be described in more detail with respect to Figs. 2 to 7 in the order of the consecutive steps of generating configuring and operating the system.
  • the extension of the kernel program with functionalities for a class of problems can be determined by defining the dynamically added program partitions.
  • the dynamic extension means of the general kernel program in a configuration step denoted by 201 is shown in Fig. 2.
  • the expert user has the possibility through an expert interface 102, 103 and a generating means of first and second program partitions 202, 203 to select or define and allocate the first and second program partitions 107, 112 necessary for a specific field of application.
  • the general software in the kernel provides support for the user to input the case specific parameters, to define, select and/or generate the necessary case specific, dynamically downloadable first and second program partitions 107 and 112 and to allocate the selected and/or generated program partitions to the first and second software modules respectively.
  • the expert user has defined, selected and/or generated and allocated using the expert interface 102 and the generating means 202 a first program element 108 to the set of program partitions 107 of the first software modules.
  • This program element 108 comprises a input 109 for receiving input variables, an output 110 for providing output variables and a program 111 representing the objective rules (definitions, instructions) for establishing output variables from the input variables and determining the function of a class of the first software modules.
  • the objective rules definitions, instructions
  • the expert user has defined, selected and/or generated and allocated using the expert interface 103 and a generating means 203 a program element 113 to the set of program partitions 112 of the second software modules.
  • This program element 113 comprises two inputs 114 for receiving input variables, three outputs 115 for providing output variables and a program 1 16 representing the objective rules (definitions, instructions) for establishing output variables from the input variables and determining the function of a class of the second software modules.
  • the generation of a case specific, actual model structure and data via extension means for user interface 301 is shown in Fig. 3.
  • the extension of the kernel program 101 with the actual structure and data of the problems or task to be simulated can be determined for modelling a specific case or problem or task by defining the actual structure and data contained by the dynamically added structure and data partitions 117, 125.
  • the generation of the structure and data partitions 117 for the substantially equal first software modules can be accomplished by a user with the help of a user interface 104 and generation means of first data partitions 302 as shown on the left side of Fig. 3.
  • the user has generated data partitions 117 of a first dynamic database.
  • the first data partition 117 comprises first data elementsl l ⁇ having first data elements or output and input memory parts 119 and 120 for storing input and output variables representing state parameters or changes of the state parameters.
  • the input memory 120 has a first data input 121 for receiving state parameter changes from the second software module and an output 122 for transmitting this value to one or more of the associated program element 108 of the first software module.
  • the output memory 119 has an input 123 for receiving state parameter values from the associated program element 108 and a first data output 124 for transmitting this value to the second software modules.
  • AU the memory parts of the data partitions forming the first dynamic database and all of their connections are defined in this database generation step.
  • the generation of the structure and data partitions 125 for the substantially equal second software modules can be accomplished by a user with the help of a user interface 103 and generation means of second data partitions 303 as shown on the right side of Fig. 3. hi the shown embodiment the user has generated second data partitions 125 of a second dynamic database.
  • the data partition 125 comprises second data elements 126 having data elements or second output and input memory parts 127 and 128 for storing input and output variables representing state parameters or changes of the state parameters.
  • input memory 128 has a second data input 129 for receiving state parameter values from the first software module and an output 130 for transmitting this value to one or more of the associated program elements 113 of the second software modules.
  • the second output memory 127 has an input 131 for receiving state parameter changes from the associated program element 113 and a second data output 132 for transmitting this value to the first software modules. All the memory parts of the data partitions forming the second dynamic database and all of their connections are defined in this database generation step.
  • the actual model simulation can be performed which will be described in more detail with reference to Figs. 4 to 7.
  • the model simulation takes place in four execution steps each of which being controlled by the kernel program. The four execution steps are usually be repeated according to the optionally changing time steps of the dynamic simulation.
  • the first execution step of the model simulation will be explained in more detail.
  • the data set 118 of the passive dynamic database recognises the program partition 108 which will determine its functionality.
  • a data/program transfer 401 occurs and during a functor communication the appropriate part of the content of the first input memory 120 will be transferred from the output 122 to the first program input 109.
  • a similar program/data transfer 402 occurs and during a functor communication the first program output 110 will be transferred to the input 123 of the first output memory 119 determining the appropriate part of its content.
  • the same data transfers and processing functions will be performed for all passive data sets involved and therefore activated by the kernel program.
  • the second execution step of the model simulation will be explained in more detail. After execution of all program parts of the program partitions selected to be active in the first execution step a connection will be established between the first software modules and the second software modules and all state parameters determined by the first software modules will be transferred from the first software modules to the second software modules and to the output interface. The transferred state parameters will be received by the dynamic database partitions of the second software modules. As it is shown in Fig. 5, the output variable of the first output memory 119 will be transferred through a first connection means 501a as a communication channel to the second data input 129 of the second input memory 128 of the second data element 126 during a first data/data transfer.
  • First connection means 501b as communication channels connect one output with two inputs at the same time, hi the shown exemplary embodiment the connection means 501a and 501b transmit output state parameter values to different inputs in parallel at the same time.
  • the first software modules also provide output values to the output interface 137 through communication channel realized by connection means 502 during a first data output transfer.
  • First connection means 501a, 501b and 502 can also be accomplished as third software modules.
  • connection means define the structure of the system while the content carried by them changes dynamically in response to the function of the first software modules.
  • the third execution step of the model simulation will be explained in more detail.
  • the second software modules take part in the execution in which all data elements 126 of the data partitions 125 will be processed consecutively by the associated program elements 113.
  • the data element 126 of the active dynamic database recognises the program element 113 which will determine its functionality.
  • a second data/program transfer 601a, 601b occurs and during a functor communication the appropriate part of the content of two second input memory 128 will be transferred from the output 130 to the second program input 114.
  • a connection will be established between the second software modules and the first software modules and all state parameter changes determined by the second software modules will be transferred from the second software modules to the first software modules and to the output interface.
  • the transferred state parameter changes will be received by the dynamic database partitions of the first software modules.
  • the output variable of the second output memory 127 will be transferred through a communication channel or second connection means 701a to the first data input 121 of the first input memory 120 of the first data element 118.
  • connection means 702. Second connection means 701a, 701b, 701c and 702 can also be accomplished as fourth software modules.
  • connection means 701a, 701b, 701c, and 702 are clearly distinguished from the content of the communication channels.
  • the connection means define the structure of the system while the content carried by them changes dynamically in response to the function of the second software modules.
  • Fig. 8 illustrates a more complex system view of a model structure with time dependency for modelling processes with a structure changing in time.
  • the dynamically generated passive and active databases of the first and second software modules have also a time dependency.
  • On the arrow representing the time axis three points are marked which define different time slices 801a, 801b and 801c with different structure of the system.
  • the existing data partitions of the dynamic database of the first software modules are connected with lines 802a, 802b and 802c.
  • the existing data partitions of the dynamic database of the second software modules are connected with lines 803a, 803b, 803c and 803d.
  • Fig. 8 illustrates a more complex system view of a model structure with time dependency for modelling processes with a structure changing in time.
  • the dynamically generated passive and active databases of the first and second software modules have also a time dependency.
  • On the arrow representing the time axis three points are marked which define different time slices 801a, 801b and 801c with different structure
  • the data partitions connected with lines 802a, 803a and 803b exist in a time interval between the first and second time slices 801a and 801b
  • the data partition connected with line 802b exists in a time interval between the first and third time slices 801a to 801c
  • the data partitions connected with lines 803c and 803d exist in a time interval between the second and third time slices 801b and 801c.
  • the lines 802 and 803 in the right side view of the three dimensional drawing represent a GANTT diagram of the system with time dependent structure.
  • the front view of the three dimensional drawing represents the whole of the structure of the first and second connection means.
  • a first, functionally distinguished subset of processor modules 902 comprises a plurality of substantially equal first processor modules 903.
  • the first processor modules are adapted for the execution of a first software module, where a first software module represents a passive element and establishes on the basis of a set of predetermined rules a ⁇
  • the first processor module elements 903 comprise an input/output unit 905 that is provided with an input 907 for receiving a change of a state parameter from the second processor modules 911, a. memory for storing a state parameter and an output 913 for outputting a value of a state parameter.
  • a second, functionally distinguished subset of processor modules 916 comprise a plurality of substantially equal second processor module elements 917.
  • the second processor modules are adapted for the execution of a second software module, where a second software module represents an active element and establishes on the basis of a set of predetermined rules a change of a state parameter.
  • the second processor module elements 917 comprise an input/output unit 919 that is provided with an input 921 for receiving a state parameter from the first processor modules 903 and an output 927 for outputting a change of a state parameter.
  • a group of the processor module elements 903 are comprised in the subset of first processor modules 902, the processor modules 903 being adapted for the parallel execution of the programs of the first software modules.
  • the first processor module element 903 is configured to comprise a dynamic structure and data set on the one hand and a memory part, with data and program on the other hand which determine the functionality of the processor module.
  • the first processor module element 903 is adapted for the execution of a first software module, where the first software module represents a passive element and establishes on the basis of a set of predetermined rules a state parameter.
  • the first processor module 903 comprises the following elements: a freely programmable first processing unit 904 with local memory for the program and the data, being adapted for the execution of the program of a first software module; a freely programmable first input/output unit 905 for selectively receiving input data and sending output data; wired or wireless first input communication channels 906; a freely programmable selectively receiving first input port 907; a first input decoding and interpretation means 908 ; a first input memory 909 for the constant and dynamic input data and for the communication program of the first processor module; a first program memory 910; a first output memory 911 for the executable program and for the constant and dynamic output data of the first processor module; a first output coding means 912 ; a module specific programmable first output port 913; and wired or wireless first output communication channel 914.
  • a group of the processor module elements 917 are comprised in the second subset of processor modules 916, the processor modules being adapted for the parallel execution of the programs of a second software module.
  • Each processor module 917 is configured to comprise a dynamic structure and data set on the one hand and a memory part with data and program on the other hand which determine the functionality of the processor modules.
  • the second processor module 917 is adapted for the execution of a second software module, where the second software module represents an active element and establishes on the basis of a set of predetermined rules a change of a state parameter.
  • the second processor module 917 comprises the following elements: a freely programmable second processing unit 918 with local memory for the program and the data, being adapted for the execution of the program of a second software module; a freely programmable input/output unit 919 for selectively receiving input data and sending output data; wired or wireless second input communication channels 920; a freely programmable selectively receiving second input port 921; a second input decoding and interpretation means 922; a second input memory 923 for the constant and dynamic input data and for the communication program of the second processor module; a second program memory 924; a second output memory 925 for the executable program and for the constant and dynamic output data of the second processor module; a second output coding means 926; a module specific programmable first output-port 927; and wired or wireless second communication channel 928.
  • the exchange of data between the first and second subset of processor modules and an output interface 937 may be effected through first and second communication channels 914, 929, 928 and 930.
  • the communication channels may be wired such as twisted pair, coaxial cable, switching field, or wireless, such as infra bluetooth or radio channels or any combination thereof.
  • the general system of the hardware implementation has to be configured according to the field of application and to the specific case or task or problem.
  • Fig. 10 shows a configuration architecture, in which a supervisory or control processor module 1001 arranges for the selection of the first and second processor modules forming the first and second subset of processor modules, the assignment of the memory parts within the processor modules and of the connection means between the first and second processor modules and the output interface, and the generation and/or selection and distribution of the first and second program modules for the individual first and second processor modules.
  • a supervisory or control processor module 1001 arranges for the selection of the first and second processor modules forming the first and second subset of processor modules, the assignment of the memory parts within the processor modules and of the connection means between the first and second processor modules and the output interface, and the generation and/or selection and distribution of the first and second program modules for the individual first and second processor modules.
  • the supervisory control processor 1001 that has connections means to all of the individual processor modules.
  • the programs, the data and the communication abilities are distributed for the processor modules.
  • the supervisory control processor starts and coordinates the cyclic parallel run of executable programs in the processor modules, while the output is forwarded to the output processor module(s).
  • the programming starts in the supervisory processor module.
  • As a first step domain specific set of dynamic programs and case specific program associated data partitions are prepared for the first and second processor modules.
  • the edition, generation and/or selection of these software elements is carried out for example with the help of a first and second expert interface 1002 and 1003.
  • the structure of the model, as well as the structure associated data are prepared also within the extended control processor module 1001.
  • the edition, generation and/or selection of these software elements is carried out for example with the help of the user interface connection means 1004.
  • connection means between the supervisory control processor module 1001 and the first processor modules.
  • One part of these connection means 1004, controlled by the supervisory control processor realizes the configuration of the selective receiving and individual sending capabilities of the first processor modules.
  • Another part of these connection means 1005, controlled also by the supervisory control processor performs the distribution of the domain specific programs and case specific data among the first processor modules.
  • Programming of the first processor modules means the distribution of the input variables, iteration free executable first processing unit programs 1007 and output variables for the individual processor modules according to the model-driven structure on the one hand through a connection means 1009. Furthermore programming of the first processor modules has to be completed with the distribution of the communication capabilities on the other hand. For example all of the first processor modules are given a communication code (e.g. a frequency) for sending of its data, as well as a list of codes (e.g. frequencies) for receiving the incoming data from the second processor modules in the sense of the architecture shown in Fig. 1.
  • the first processor module provided with these particulars is fully functional.
  • connection means between the supervisory control processor module and the second processor modules.
  • One part of these connection means 1010, controlled by the supervisory control processor realizes the configuration of the selective receiving and individual sending capabilities of the second processor modules.
  • Another part of these connection means 1010, controlled also by the supervisory control processor realizes the distribution of the domain specific programs and case specific data for the second processor modules.
  • Programming of the second processor modules means the distribution of the input variables, iteration free executable second processing unit programs 1013 and output variables for the individual processor modules according to the model-driven structure on the one hand through a connection means 1015.
  • Furthermore programming of the second processor modules has to be completed with the distribution of the communication capabilities on the other hand. For example all of the second processor modules are given a communication code (e.g. a frequency) for sending of its data, as well as a list of codes (e.g. frequencies) for receiving the incoming data from the first processor modules in the sense of the architecture shown in Fig. 1.
  • the second processor module provided with these particulars is fully functional.
  • the hardware architecture configured for modelling and simulating a specific case, task or problem is shown schematically in Fig. 11. It is noted, that the processor modules are equipped with an autonomous input/output communication unit 905, 919, as well as with a processing unit with an executable program stored in a program memory 910, 924.
  • the communication is advantageously arranged so that all processor modules are capable of specific output encoding of their messages thereby defining for all other processor modules the messages in a form of digital data or signals that can be decoded and received by one or more predetermined individual processor modules.
  • the actual model simulation can be performed which will be described in more detail with reference to Figs. 12 to 15.
  • the model simulation takes place in four execution steps each of which being controlled by the supervising processor module.
  • the four execution steps are usually be repeated according to the optionally changing time steps of the dynamic simulation.
  • the first execution step of the model simulation will be explained in more detail.
  • the first processor modules take part in the execution in which all first hardware modules communicate the state values through first communication channels 1202 to the second processor modules.
  • the first processor modules transfer their output values through first output communication channels 1203 to processor modules handling the output interface 937.
  • the second execution step is shown, in which the second processor modules 1301 perform data processing 1302a, 1302b, 1303a, 1303b, 1304a.
  • the resulting changes of the state parameters will be communicated through second communication channels 1401 to the first processor modules.
  • the second processor modules transfer their output values through second output communication channels 1402 to processor modules handling the output interface 937 as shown in Fig. 14.
  • the first processor modules 1201 perform in parallel data processing 1501abc, 1502abc, 1503abc.
  • Fig. 16 illustrates a more complex system of a model structure with time dependency of the hardware architecture with a structure changing in time.
  • the existence of the active processor modules and/or the connection means between the processor modules change according to some time- or event driven rules involved in the supervisory control processor module or in the distributed programs themselves.
  • On the arrow representing the time axis three points are marked which represent different events 1601a, 1601b and 1601c or states of the system.
  • the existing active software modules of the first processor modules are connected with lines 1602a, 1602b and 1602c.
  • the existing active software modules of the second processor modules are connected with lines 1603a, 1603b, 1603c, 1603d and 1603e.
  • the active software modules connected with lines 1602a, 1602b and 1602c exist in a time interval between the first and third events 1601a and 1601c
  • the active software modules connected with lines 1603a, 1603c and 1603e exist in a time interval between the first and second events 1601a to 1601b
  • the active software modules connected with lines 1603b and 1603d exist in a time interval between the second and third events 1601b and 1601c.
  • the lines 1602 and 1603 in the right side view of the three dimensional drawing represent a GANTT diagram of the system with time dependent structure.
  • dimensional drawing represents the whole structure of the hardware architecture with first and second connection means.
  • a "user” is the user of the software system, who prepares the input data and selects the actual software modules with the help of a user interface, and finally also evaluates the results.
  • the user interface may be of a general type, which is capable of handling practically all types of data, or it may be a more specific type which is adapted to a particular type of tasks, for example the modelling of genetic processes.
  • User interface is a set of tools devised for a specific field of application, assisting the user in the preparation of the starting data, and also displays the obtained results. In a simple realisation, it is sufficient to use Microsoft EXCEL® worksheet, and the output may be presented in a similar manner, for example on other sheets of the same file. In a more sophisticated version the user interface may assist the user with defining various types of variables, and the definition of the relationships between them.
  • the "expert" or expert user is capable of changing the abilities of the simulator software.
  • the expert user is capable of adding new types of active or passive elements, and may add appropriate smaller programs to the kernel code which may process the new types of active and passive elements, for example, an expert may be capable of modifying a software architecture originally conceived for the simulation of chromatographic analysis or polymerisation reactor tanks so that that the software architecture will be suitable for simulating a metabolic network model or the calculation of a logistics task.
  • the "expert interface” means the totality of the available subroutines which support the preparation of the different model adaptations.
  • the dynamic data, program and connection partitions can be supplemented, modified and deleted in runtime. It is to be noted that in the described software architecture the qualitative change in the complexity of the usual mathematical constructs can be transformed into the quantitative increase of the same, similar elements and connections. As an example, the models of concentrated and distributed parameters and even of population balance differ only in the number of the elements and connections. As another example, the various discrete or continuous, quantitative or qualitative, deterministic or stochastic, crisp or fuzzy models can be interpreted on the same structural skeleton of the elements and of connections, described by the first and second software modules.
  • the software architecture can be implemented on various platforms and languages, hi order to provide an even better understanding of the invention, in the following the general, upper level features of the software architecture will be summarized by means of an example with Prolog definitions.
  • first and second software modules, as well as the first and second connection means correspond to automatically generated dynamic program partitions.
  • These dynamic program partitions describe the detailed states, the changes of the states of the modelled process, as well as, the input/output communication between the state and the changes of the states.
  • the respective predicates are the following:
  • first_module data ( FM Identifier, Identifying_name, Coordinates, Scheduling,
  • FC_Identifier FC_Identifier, FM_Identif ⁇ er, State values, SM_Identifier
  • FM Identif ⁇ er the identifier of the first software module data set
  • SM_Identifier the identifier of the second software module data set
  • FC Identifier the identifier of the first connection means
  • SC_Identifier the identifier of the second connection means
  • Identifying_name ⁇ stringlist ⁇ the identifying name of the respective software module data set
  • Coordinates ⁇ integerlist ⁇ the spatial and property coordinates in the case of the processes with distributed parameter
  • State_values ⁇ sign ⁇ a user configured data set about the state (e.g. integers, reals, strings, tables, fuzzy variables, optional records, etc.) of the first software module data set;
  • Change values ⁇ sign ⁇ a user configured data set describing an individual change (increase, decrease, overwriting, modification, etc.) in the second software module data set;
  • State ⁇ state_data ⁇ a user configured static and/or dynamic data set characterizing the state of a given class of the first software module data sets;
  • Process ⁇ process data ⁇ a user configured static and/or dynamic data set, associated with a given class of second software module data sets;
  • First_module_program identifier of the dynamic, case specific clause partition, that executes the functionality associated with the given first software module data set;
  • Second_module_program identifier of the dynamic, case specific clause partition that executes the functionality associated with the given active element.
  • the main kernel program is organized by the basic clauses of
  • Simulated Moving Bed Design and control of the co-current or countercurrent ion exchange processes, realized in the so-called Simulated Moving Bed system.
  • the key idea of the Simulated Moving Bed is to "simulate" the solid phase motion by using standard fixed bed columns and periodically switching the inlet and outlet ports of the unit.
  • First software module data sets Individual competitive components in the given phase at a given compartment along the length of the respective column.
  • the number of elements is usually in the order of magnitude 10 4 .
  • Second software module data sets The terminal elements of the hierarchy designate the architecture of the elementary transformations (ion exchange, weak sorption, etc.), transportations (convective and mixing flows, pore diffusion) and rules (control actions).
  • Second software module programs These brief dynamic program partitions declare the calculation of the component transfer, of the liquid flow, etc. for the conservational processes, as well as the execution of the diagnostic, control and evaluating rules.
  • the user has to define the configuration of the system, the data of the columns, the initial state, the equilibrium and the process parameters (flow rates, column switch time, etc.).
  • the kinetic and mixing parameters have to be identified from simple tests, using the simulator itself.
  • First software module data sets All of the possible, more or less freely moving compounds and complexes, as well as the structured, located sites that may have any functionality in the various compartments.
  • Second software module data sets AU of the possible elementary transformations inside the compartments and transportations between the compartments.
  • Second software module programs These brief dynamic program partitions declare the calculation of the transformations and transportations for the conservational processes, as well as the execution of the control functions of the signalling processes.
  • First software module data sets Storage volumes associated with the respective cost and measure of demand.
  • Second software module data sets The possibility space of the model is determined by the alternative productions, consumptions, purchases, and sales, as well as by the concurrent processing recipes realizable in the given equipment.
  • Second software module programs Simulation of the purchases, consumptions, productions, transportations and transformations.
  • First software module data sets There are various groups of realistic and fictitious storage volumes at vendors, inside the farm, as well as at the consumers, containing raw materials, machinery, manpower, crops, fodders, animal populations, products, etc.
  • Second software module data sets Describe the structure of the possible purchases, sales, as well as of the agricultural processes (e.g. ploughing, harrowing, sowing, harvest, etc.).
  • First software module programs Describe the calculation, associated with the storages and evaluation of the signs for the controlling systems.
  • Second software module programs Determine the simulation of the agricultural processes (consumption of land, seed grain, fertilizers, chemicals, machines, manpower, and the products, as well as determine the economic characteristics.
  • the user has to define the initial state of the agricultural system, the estimated (optionally changing) economical parameters, as well as the possible, alternative agricultural activities, described by the sequence of the respective operations.
  • the simulated output describes the detailed change of the characteristic materials, energy, manpower and machine consumption, as well as the cash-flow of the alternative plans.
  • the Gantt-chart of the allocated resources can also be generated.

Abstract

There is disclosed a software architecture with multiple substantially equal first software modules and multiple substantially equal second software modules. The first software modules are programmed to represent a passive element and to establish on the basis of a set of predetermined rules a value of a state parameter. The set of predetermined rules establishing the values of the state parameters are defined so that a resulting output value of the rules may be calculated substantially without repeated cycles. The second software modules are programmed to represent an active element and to establish on the basis of a set of predetermined rules a change of a value of a state parameter. The set of predetermined rules are defined so that a resulting output value of the rules may be calculated substantially without repeated cycles. The suggested software architecture further comprises first connection means for communicating an output value of a state parameter from a first software module to the input of one or more second software modules, and second connection means for communicating an output value of a change of a state parameter from a second software module to the input of one or more first software modules. The suggested software architecture further comprises cycle control means cyclically causing the first software modules to establish the output values of state parameters substantially simultaneously, the first connection means to communicate output values from the first software module to the second software modules, the second software modules to establish the output values from their respective input state parameters substantially simultaneously, and the second connection means to communicate the output values from the second software module to the first software modules. There is further disclosed a hardware architecture for executing the software, and a method underlying the software.

Description

PROCESS SIMULATION SOFTWARE AND HARDWARE ARCHITECTURE AND
METHOD
BACKGROUND OF THE INVENTION
The invention relates to a software and hardware architecture for the simulation of a process, and the underlying method. The invention primarily concerns a method which employs certain principles of parallel processing for the solving of otherwise complex computational problems. The suggested software and hardware architecture facilitates the easy implementation of the suggested method.
Methods for parallel processing and related apparatus are well known in the art. For example, US Patent No. 5,692,193 discloses a computer software architecture for controlling a parallel computer system. The disclosed computer software architecture comprises multiple layers. One of the layers contains so-called threads, which are defined as "lightweight" processes. Such lightweight processes are than run on virtual processors.
However, this patent does not teach how such a computer architecture may contribute to the solving of complex computational problems, particularly such mathematical problems which do not have a solution in closed form, or which do not have any analytical solution.
US Patent Application No. 2002/0133325A1 discloses a system and method for the simulation of discrete events. Such events are either defined or mapped from a source. The event models are run in parallel simulator engines. A central scheduler minimizes computation time, and for this purpose the central scheduler is interfaced with the simulator engines on separate dedicated communication channels. The scheduler also serves events to the simulation engines. The disclosed simulation system and method is capable of simulating real-world events, such as the internal logic functions of a semiconductor device or a power consumption and associated heat characteristics of a digital circuit. However, the applied simulator engines still require complex programming, and the disclosed system and method is difficult to implement for an arbitrary simulation problem.
US Patent Application No. 2002/0169785A1 discloses a computer system and method for the simulation of transport phenomena in a complex system. The computer system comprises an object-oriented software product, the latter comprising two different sets of generic classes with variables for object types. An arbitrary number of variables may be added to the classes. The suggested system and method is proposed for the numerical simulation of certain physical processes, such as the behaviour of a hydrocarbon reservoir. The physical model proposed uses the notion of cells, and various state variables are assigned to cells. The physical processes within cells are expressed with the help of a set of equations, where the equations represent rules between state variables of a cell, such as mass, energy, pressure, etc. A changing phenomenon is modelled by calculating physical quantities at discrete time intervals. In the proposed method and computer system, physical equipment, such as wells and pumps are represented by class objects. The system is useful for parallel computing the properties of the cells. This computer system and method does not lend itself to the solving of problems more general nature, particularly for solving problems with hybrid variables, i.e. which contain both continuous and discrete inputs.
US Patent Application No. 2002/0221086Al discloses another computer system and method for executing vector instructions, i.e. such instructions which may be executed in a parallel fashion. The vector instructions are executed with configurable stream processors (CSP), where the CSP contains RISC (Reduced Instruction Set) computers and associated registers. The proposed system is suitable for use in multiprocessor configurations. On the other hand, it is not disclosed or suggested how such a computer system may be programmed to facilitate the simulation of complex processes which otherwise require complicated mathematical tools.
Accordingly, there is a need for a method which provides a relatively simple and readily applicable tool for solving relatively complex computational problems, and which may be used without any deeper mathematical analysis of the problem to be solved. There is also need for a software and hardware architecture which supports the straightforward implementation of the proposed method. Further, it is sought to provide a software architecture which may be run also on more traditional non-parallel, single-processor computer systems, such as a personal computer.
SUMMARY OF THE INVENTION
In an embodiment of the present invention, there is provided a software architecture which comprises multiple substantially equal first software modules and multiple substantially equal second software modules.
Each first software module has an input variable representing a change of a state parameter, a memory for storing a state parameter and an output for outputting a value of a state parameter. The first software modules are programmed to represent a passive element and to establish on the basis of a set of predetermined rules a value of a state parameter. Here, the term "passive element" means that a software module represents an entity which is under the influence of external rules, and possible states of that entity are determined by these external rules, hence, the represented entity is subjected to the external rules and passively yields to the rules. The set of predetermined rules establishing the values of the state parameters are defined so that a resulting output value of the rules may be calculated substantially without repeated cycles.
Each second software module has an input variable representing a state parameter and an output for outputting a change of a state parameter. The second software modules are programmed to represent an active element and to establish on the basis of a set of predetermined rules a change of a value of a state parameter. Here, the term "active element" means that a software module represents those rules which describe interactions between (typically different) entities, and in this manner actively form the state parameters (i. e. the actual state) of the affected entities. The set of predetermined rules are defined so that a resulting output value of the rules may be calculated substantially without repeated cycles. The suggested software architecture further comprises first connection means for communicating an output value of a state parameter from a first software module to the input of one or more second software modules, and second connection means for communicating an output value of a change of a state parameter from a second software module to the input of one or more first software modules.
The suggested software architecture further comprises cycle control means. The cycle control means are adapted for causing
a, substantially all first software modules to establish the output values of the state parameters of their associated characteristic entities substantially simultaneously, and subsequently b, substantially all first connection means to communicate the output values from the first software module to the second software modules, and subsequently c, substantially all second software modules to establish the output values from their respective input state parameters substantially simultaneously, and subsequently d, substantially all second connection means to communicate the output values from the second software module to the first software modules, and to repeat steps a, to d, cyclically.
According to another aspect of the invention, there is provided a hardware architecture comprising a set of processor modules arranged for the parallel processing of a task. The hardware architecture according to the invention comprises a first subset of processor modules comprising multiple substantially equal first processor modules. The first processor modules being adapted for the execution of a first software module, where the first software module represents a passive element and establishes on the basis of a set of predetermined rules a state parameter. The first processor modules have an input for receiving a change of a state parameter, a memory for storing a state parameter and an output for outputting a value of a state parameter. The hardware architecture further comprises a second subset of processor modules comprising multiple substantially equal second processor modules. The second processor modules are adapted for the execution of a second software module, where the second software module represents an active element and establishes on the basis of a set of predetermined rules a change of a state parameter. The second processor modules have an input for receiving a state parameter and an output for outputting a change of a state parameter.
The hardware architecture further comprises first connection means for communicating an output value generated by a first software module in a first processor module to the input of one or more second software modules in a second processor module, and second connection means for communicating an output value from a second software module in a second processor module to the input of one or more first software modules in a first software module.
The hardware architecture further comprises cycle control means for causing a, substantially all first processor modules to establish output values of the first software modules substantially simultaneously, b, substantially all first connection means to communicate output values from the first software modules in a first processor module to the input of one or more second software modules in a second processor module, c, substantially all second processor modules to establish output values of the second software modules from their respective inputs substantially simultaneously, and d, substantially all second connection means to communicate output values from the second software modules in a second processor module to inputs of first software modules in a first processor module, and to repeat steps a, to d, cyclically.
According to yet another aspect of the invention, there is provided a method for the simulation of a physical or conceptual process. In the method, the physical or conceptual process is regarded as a primary process, and the functioning and state of the primary process are simulated with the help of a computational secondary process. The secondary process involves the essential structure and the elementary relationships determining the functioning and state of the primary process.
According to the invention, in the method the following steps are performed: i, identifying characteristic entities of the primary process, and relevant structures and properties describing a state and a change of state of the characteristic entities; ii, defining a finite number of passive elements of the secondary process, and associating to each passive element a characteristic entity of the primary process, a set of state parameters describing the characteristic entity associated to the respective passive element, and a set of rules expressing a relationship between the state parameters of the characteristic entity associated to the respective passive element and/or expressing constraints imposed upon the state parameters of the characteristic entity associated to the respective passive element. The set of rules are defined so that an application of the rules and thereby the determination of an output result resulting from the application of the rules may be performed readily and substantially without repeated cycles; iii, defining a finite number of active elements of the secondary process, and associating to each active element a set of rules, where the rules define a change of the state parameters of the entities associated to one or more passive elements. The set of rules are defined so that an application of the rules and thereby the determination of an output result resulting from the application of the rules may be performed readily and substantially without repeated cycles; iv, defining a modifying channel between an active element and one or more passive elements, during which modifying channel a value of a change of a state parameter associated to the respective active element may be output towards the respective passive element(s); v, defining a reading feedback channel between a passive elements and one or more active elements, during which reading feedback channel a value of a state parameter may be fed to an input of an active element, where the rule associated to the respective active element involves a state parameter of the passive element at the input end of the respective reading channel. The method further includes the steps of cyclically repeating the following steps: a, substantially simultaneously establishing on the basis of the set of rules associated to the respective passive element an output value of the set of state parameters of substantially each passive element, b, forwarding along the reading feedback channel(s) to one or more active elements the value(s) of the state parameters of the characteristic entity associated to the respective passive element, c, substantially simultaneously establishing on the basis of the rule associated to the respective active element output value(s) of the change of the state parameters, d, updating through the modifying channel(s) the state parameters of the physical entity associated to the respective passive element with the output value established in step c.
The disclosed software and hardware architecture and the underlying method allow the effective and realistic simulation of all types of processes. It is particularly suitable for the simulation of various physical, chemical and biological processes, which typically involve a large number of different physical entities, such as various materials in a chemical, physical or biological reaction, and different physical parameters describing the actual states of the materials. Such physical parameters may be the mass, temperature, pressure, dimension, etc. of the materials in question.
However, the state parameters may be also abstract parameters, and the entities simulated by the invented method and software architecture may be abstract entities, such as logical variables and their actual values. The entities may represent physical devices, such as vessels or tanks, where their state is "empty" or "full" or the like. Further entities may be real or abstract signals and their state may describe their information content.
The suggested hardware architecture offers a possibility for the fast execution of the software modules in the software architecture of the invention, but otherwise the proposed software architecture may be readily run on traditional computers, as well. The proposed method offers the advantage that even very complex processes may be handled in a simple and straightforward fashion, without having to bother about the existence or non-existence of an analytical solution to the equations describing the physical process. It is a particular advantage of the method that with the complexity of a mathematical problem, only the number of the software modules - and typically the number of connections between the software modules - increase, but otherwise the inherent programs of the software modules remain very simple. With other words, the mathematical complexity of a process is transformed into a "structural" complexity of the software architecture, but this structural complexity is much easier to handle by an average skilled user, because the individual connections between the software modules are based on easily comprehensible principles. This inherent simplicity of the software modules also makes it possible to use a standard set of simple subroutines, which only need to be filled up with appropriate input data to represent a particular event in an otherwise complex process. The inherent simplicity of the software modules also permits the creation of a user-friendly user interface for managing the software architecture.
With proper selection of the constraints and rules, a physical simulation may at all times remain between the limits of physical feasibility. The actual calculated states of the entities very closely follow the parameters of a real physical process, and the various states of the process may be retrieved any time during the process.
The proposed software architecture is suitable for the simulation of all types of processes, e.g. physical or theoretical, continuous or discrete, quantitative or qualitative, analogous or digital process. The system can handle mixed or hybrid type of processes in a straightforward manner, and in this way greatly facilitates the modelling of practically any process, without the need for extensive programming skills for an average user (who would typically have a technical educational degree, but not necessarily be a computer programming specialist).
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will be now described with reference to the enclosed drawings, where Fig. 1 illustrates the general overview of the software architecture;
Fig. 2 illustrates the generation and distribution process of program partitions among the first and second software modules;
Fig. 3 illustrates the generation and distribution process of the dynamic data partitions, determining the prescribed state, as well as the prescribed changes of the states;
Fig. 4 shows an exemplary execution step 1 of the software architecture with the first software modules establishing output values of the state parameters of associated characteristic entities;
Fig. 5 shows an exemplary execution step 2 of the software architecture with the first connection means communicating the output values from the first software modules to the second software modules and the output interface;
Fig. 6 shows an exemplary execution step 3 of the software architecture with the second software modules establishing the output values of the respective input state parameters;
Fig. 7. shows an exemplary execution step 4 of the software architecture with the second connection means communicating the output values from the second software module to the first software module and the output interface;
Fig. 8. illustrates the time- and event-dependency of the active states of the software modules in the software architecture;
Fig. 9. illustrates the general view of the hardware architecture for process simulation according to the invention;
Fig. 10. illustrates an exemplary generation and distribution process of program and data partitions among of the first and second processor modules;
Fig. 11. illustrates the hardware architecture, configured and programmed according to the actual task to be solved; Fig. 12. shows an exemplary execution step 1 of the hardware architecture with the first connection means communicating output values from the first processor modules to the second processor modules;
Fig. 13. shows an exemplary execution step 2 of the hardware architecture with the second processor modules establishing output values; Fig. 14. shows an exemplary execution step 3 of the hardware architecture with the second connection means communicating the output values from the second processor modules to the first processor modules;
Fig. 15. shows an exemplary execution step 4 of the hardware architecture with the first processor modules establishing output values; and
Fig. 16. illustrates the time- and event-dependency of the active states of the hardware modules of the hardware architecture.
DETAILED DESCRIPTION OF THE INVENTION
Referring now to the figures in general, in the following we present a possible implementation of the described software architecture in Figs 1 to 8, together with the suitable hardware implementation in Figs 9 to 16. The use of the software architecture will also be explained with the help of typical simulated process examples.
The essential features of the software architecture are shown in Fig. 1, illustrating how the resident part of a general kernel program 101 is extended by expert interfaces 102, 103 and user interfaces 104, 105 to generate a software architecture for process simulation. First and second expert interfaces 102, 103 enable an expert to configure first and second program partitions 107, 112 respectively, thereby determining the system functionality. First and second user interfaces 104, 105 are used by a user to configure a plurality of first and second data partitions 117, 125 respectively thereby determining the case specific structure and the initial state of the system. The dynamically extendable core of the software architecture is supplemented by two sets of software modules: the so-called first software modules and the so-called second software modules. As shown, the modules may have a number of inputs and outputs, and the modules perform calculations with the inputs, the results of the calculation being output as the outputs. The calculations may be considered also as applying a set of rules on the inputs, and thereby generating the outputs of a software module. From a programming point of view, the main common feature of both types of software modules is that the set of predetermined rules which are implemented during the execution of a software module are defined so that a resulting output value of the rules may be calculated substantially without repeated cycles during one step. The fact that a software module practically does not contain calculations which would require extensive iterative programming, is a key feature of the proposed software architecture. As it will be shown later, exactly this feature makes it possible to simulate almost any arbitrary processes without the need for sophisticated mathematical tools (for example, for the solution of a higher-order equation), or without the need for special programming skills on the part of the user. This feature also contributes to a simple implementation of the whole software architecture, as the software modules are more easily handled by the controlling kernel. Since the software modules do not contain a high number of cycles, they will require more or less the same execution time, which again facilitates parallel processing, and the parallel execution on multiple processors.
The software modules within the sets are considered as substantially equal, that is in a typical example, practically all software modules have the same simple structure: reading in the input values, executing the commands which specify certain rules, and outputting the outputs resulting from the application of the rules, where the rules are defined so that their application does not require any iterative (recursive) steps. Such rules are typically expressed by equations which have a solution in a closed algebraic form, or by a finite number of constraints, which require a finite number of comparisons with predetermined values. Experience shows that even very complex processes may be described so that the number of comparisons within a software module is very low, typically much less than hundred, i.e. a single software module is executed very fast.
The main difference between the first and second software modules is actually their data content and functioning. As it will be clearer from the selection of the variable names in the implemented software architecture explained below, and even more clear from the presented examples, the first software modules have input variables which represent a change of a state parameter, while their output is a value of a state parameter. State parameters are typically numerical and/or logical and/or symbolic values expressing a state of a simulated entity, such as a physical object, a physical signal or event. For a better understanding of the software architecture according to the invention we will give a detailed explanation on the basis of Figs. 1 to 8.
The first software modules and the second software modules are configured, controlled or supervised by a dynamically extendable kernel program 101 serving only the most general functions common in all implementations and applications. The kernel program and its extensions may be programmed in different programming languages or may be implemented under different platforms and operating systems.
The substantially equal first software modules are set up of dynamically added application specific first program partitions 107 configured according to generalized rules of the given application field, as well as according to the dynamically added case specific first structure and data partitions 117. The program partitions are determined by an expert via expert interface 102, while the structure and data partition are generated for the specific modelling task through the user interface 104.
The substantially equal second software modules are set up of dynamically added application specific second program partitions 112 configured according to generalized rules of the given application field, as well as according to the dynamically added case specific second structure and data partitions 125. The program partitions are determined by the expert via expert interface 103, while the structure and data partition are generated for the specific modelling task through the user interface 105.
The possible sets of dynamically added application specific first and second program partitions 107, 112 of the first and second software modules are determined during the different implementations and/or they can be dynamically modified through an expert interface 102 and 103 prepared for an expert user.
The first and second structure and data partitions 117 and 225 forming first and second databases may be generated in one or more steps automatically on the basis of user inputs provided through a user interface 104, 105 prepared for a class of problems to be solved. The executable simulating program, denoted by 106, comprises the permanent core of the kernel program, extended by the dynamically added, domain specific program partitions 107, 112 defined by an expert user through the expert interface 102, 103, as well as case specific structure and data partitions 117, 125 carrying structural and parametrical information defined by a user through the user interface 104, 105.
The first and second software modules are similar in architecture, but differ in their content and the functionality defined by their content, which difference is realized during kernel operation.
Within the possible set of program partitions, an example for a program partition 107 is shown. It is configured for a specific task of an application field, and comprises a small, program element 108. A first program element 108 is capable of determining a specific functionality for producing output variables 110 in response to input variables 109 that models the change of state parameters. This process is controlled by a first program 111 and the calculation is carried out in a single step without any iteration.
The first program 111 represents the objective rules, describing the function of the first software modules so that the output of the changed state can be calculated with the knowledge of the input states without repetitions (iteration). As it is clear from Fig. 1 , the first program element 108 can have possible input and output connections to many data elements 118 in many data partitions 117 containing the case specific data, as it is shown by directed graphs.
Within the possible set of program partitions an example for a program partition 112 is shown. It is configured for a specific task of an application field, and consists of a small, second program element 113. A second program element 113 is capable of determining a specific functionality for producing output variables 115 in response to input variables 114, that models the calculation of elementary changes. This process is controlled by a program 116 and the calculation is carried out in a single step without any iteration. The second program 116 represents the objective rules describing the function of the second software modules so that the output changes can be calculated with the knowledge of the input states without repetitions (iteration). As it is clear from Fig. 1, the second program element 113 can have possible input and output connections to many second data elements 126 in many second data partitions 125 of the case specific data, as it is shown by directed graphs.
The dynamically generated structure and data partitions 117 of the substantially equal first software modules form optional connected systems with the corresponding program elements 108 in the program partitions 107 during execution.
The first structure and data partition 117 is set up of a plurality of first data elements 118 comprising in this case two elements denoted by first output and input memory 119 and 120, respectively. First output memory 119, shown in the drawing as a circle, stores an output variable for outputting a value of a state parameter from the actual first dynamic data set to the connected second software module while first input memory 120, shown in the drawing as a square, stores an input variable representing the actual state of a state parameter affected by the changes coining from the connected second software modules for the actual first dynamic data set.
The first data element 118, representing a first structure and data element, is provided with an input 121 for receiving input data through second connection means 133 as a communication channel from the connected second software modules. The optionally modified value will be transmitted from an output 122 of the first input memory 120 to a first program input 109. The response of the program 111 will be available at first program output 110 and will be transmitted to an input 123 of the first output memory 119 representing a state parameter, which in return will be transmitted from a first data output 124 of the first output memory 119 through first connection means 135 as a communication channel to the second software modules. The dynamically generated structure and data partitions 125 of the substantially equal second software modules form optional connected systems with the corresponding program elements 113 in the program partitions 112 during execution.
The second structure and data partition 125 is set up of a plurality of second data elements 126 comprising a plurality of elements denoted by second output and input memory 127 and 128, respectively. They are connected with second program elements 113 within the set of second program partitions 112. The data element 126 comprises in the shown embodiment three second output memory parts 127 depicted as a triangle for storing an output variable for outputting values of state parameter changes received from the connected program element 113 to the connected first software module. The data element 126 also comprises in this case two second input memory parts 128 depicted as a circle for storing input variables representing the state parameters received from the connected first software modules.
The data element 126 representing a second structure and data element is provided with second data inputs 129 for receiving input data through first connection means 135 as communication channel from the connected first software modules. The optionally modified value will be transmitted from an output 130 of the memory 128 to a second program input 114. The response of the program 116 will be available at second program outputs 115 and will be transmitted to inputs 131 of second output memory 127 representing a state parameter change, which in return will be transmitted from second data outputs 132 of the memory 127 through second connection means 133 as a communication channel to the first software modules.
The output values of a change of a state parameter provided by the second software modules are transferred through second connection means 133 as a communication channel to the selected first software modules and, through second connection means 134 or communication channel to an output interface 137.
The output values of state parameters provided by the first software modules are transferred through first connection means 135 as a communication channel to the selected second software modules and through first connection means 136 or communication channel to the output interface 137.
The software architecture of Fig. 1 will be described in more detail with respect to Figs. 2 to 7 in the order of the consecutive steps of generating configuring and operating the system.
The extension of the kernel program with functionalities for a class of problems can be determined by defining the dynamically added program partitions. The dynamic extension means of the general kernel program in a configuration step denoted by 201 is shown in Fig. 2. In this step the expert user has the possibility through an expert interface 102, 103 and a generating means of first and second program partitions 202, 203 to select or define and allocate the first and second program partitions 107, 112 necessary for a specific field of application. The general software in the kernel provides support for the user to input the case specific parameters, to define, select and/or generate the necessary case specific, dynamically downloadable first and second program partitions 107 and 112 and to allocate the selected and/or generated program partitions to the first and second software modules respectively. As shown in an exemplary embodiment of the invention on the left side of Fig. 2, the expert user has defined, selected and/or generated and allocated using the expert interface 102 and the generating means 202 a first program element 108 to the set of program partitions 107 of the first software modules. This program element 108 comprises a input 109 for receiving input variables, an output 110 for providing output variables and a program 111 representing the objective rules (definitions, instructions) for establishing output variables from the input variables and determining the function of a class of the first software modules. As shown in an exemplary embodiment of the invention on the right side of Fig. 2, the expert user has defined, selected and/or generated and allocated using the expert interface 103 and a generating means 203 a program element 113 to the set of program partitions 112 of the second software modules. This program element 113 comprises two inputs 114 for receiving input variables, three outputs 115 for providing output variables and a program 1 16 representing the objective rules (definitions, instructions) for establishing output variables from the input variables and determining the function of a class of the second software modules.
The generation of a case specific, actual model structure and data via extension means for user interface 301 is shown in Fig. 3. The extension of the kernel program 101 with the actual structure and data of the problems or task to be simulated can be determined for modelling a specific case or problem or task by defining the actual structure and data contained by the dynamically added structure and data partitions 117, 125.
The generation of the structure and data partitions 117 for the substantially equal first software modules can be accomplished by a user with the help of a user interface 104 and generation means of first data partitions 302 as shown on the left side of Fig. 3. In the shown embodiment the user has generated data partitions 117 of a first dynamic database. The first data partition 117 comprises first data elementsl lδ having first data elements or output and input memory parts 119 and 120 for storing input and output variables representing state parameters or changes of the state parameters. The input memory 120 has a first data input 121 for receiving state parameter changes from the second software module and an output 122 for transmitting this value to one or more of the associated program element 108 of the first software module. The output memory 119 has an input 123 for receiving state parameter values from the associated program element 108 and a first data output 124 for transmitting this value to the second software modules. AU the memory parts of the data partitions forming the first dynamic database and all of their connections are defined in this database generation step.
The generation of the structure and data partitions 125 for the substantially equal second software modules can be accomplished by a user with the help of a user interface 103 and generation means of second data partitions 303 as shown on the right side of Fig. 3. hi the shown embodiment the user has generated second data partitions 125 of a second dynamic database. The data partition 125 comprises second data elements 126 having data elements or second output and input memory parts 127 and 128 for storing input and output variables representing state parameters or changes of the state parameters. The second o
input memory 128 has a second data input 129 for receiving state parameter values from the first software module and an output 130 for transmitting this value to one or more of the associated program elements 113 of the second software modules. The second output memory 127 has an input 131 for receiving state parameter changes from the associated program element 113 and a second data output 132 for transmitting this value to the first software modules. All the memory parts of the data partitions forming the second dynamic database and all of their connections are defined in this database generation step.
After completing the configuration and generation steps for a class of problems and for case specific task, the software and data architecture, the actual model simulation can be performed which will be described in more detail with reference to Figs. 4 to 7. The model simulation takes place in four execution steps each of which being controlled by the kernel program. The four execution steps are usually be repeated according to the optionally changing time steps of the dynamic simulation.
Referring to Fig. 4, the first execution step of the model simulation will be explained in more detail. During the first execution step only the first software modules take part in the execution in which all data elements 118 of the data partitions 117 will be processed consecutively by the associated program partitions 108. The data set 118 of the passive dynamic database recognises the program partition 108 which will determine its functionality. After this a data/program transfer 401 occurs and during a functor communication the appropriate part of the content of the first input memory 120 will be transferred from the output 122 to the first program input 109. After execution of the program 111 a similar program/data transfer 402 occurs and during a functor communication the first program output 110 will be transferred to the input 123 of the first output memory 119 determining the appropriate part of its content. In this first execution step the same data transfers and processing functions will be performed for all passive data sets involved and therefore activated by the kernel program.
Referring to Fig. 5, the second execution step of the model simulation will be explained in more detail. After execution of all program parts of the program partitions selected to be active in the first execution step a connection will be established between the first software modules and the second software modules and all state parameters determined by the first software modules will be transferred from the first software modules to the second software modules and to the output interface. The transferred state parameters will be received by the dynamic database partitions of the second software modules. As it is shown in Fig. 5, the output variable of the first output memory 119 will be transferred through a first connection means 501a as a communication channel to the second data input 129 of the second input memory 128 of the second data element 126 during a first data/data transfer. First connection means 501b as communication channels connect one output with two inputs at the same time, hi the shown exemplary embodiment the connection means 501a and 501b transmit output state parameter values to different inputs in parallel at the same time. The first software modules also provide output values to the output interface 137 through communication channel realized by connection means 502 during a first data output transfer. First connection means 501a, 501b and 502 can also be accomplished as third software modules.
It is important to note that the first communication channels of the first connection means are clearly distinguished from the content of the communication channels. The connection means define the structure of the system while the content carried by them changes dynamically in response to the function of the first software modules.
Referring now to Fig. 6, the third execution step of the model simulation will be explained in more detail. During the third execution step only the second software modules take part in the execution in which all data elements 126 of the data partitions 125 will be processed consecutively by the associated program elements 113. The data element 126 of the active dynamic database recognises the program element 113 which will determine its functionality. After this a second data/program transfer 601a, 601b occurs and during a functor communication the appropriate part of the content of two second input memory 128 will be transferred from the output 130 to the second program input 114. After execution of the program 116 a similar second program/data transfer 602a, 602b, 602c occurs and during a functor communication the second program outputs 115 will be transferred to the inputs 131 of the second output memory 127 determining the appropriate part of its content. In this third execution step the same data transfers and processing functions will be performed for all second data elements involved and therefore activated by the kernel program.
Referring to Fig. 7, the fourth execution step of the model simulation will be explained in more detail. After execution of all program parts of the program partitions selected to be active in the third execution step a connection will be established between the second software modules and the first software modules and all state parameter changes determined by the second software modules will be transferred from the second software modules to the first software modules and to the output interface. The transferred state parameter changes will be received by the dynamic database partitions of the first software modules. As it is shown in Fig. 7, the output variable of the second output memory 127 will be transferred through a communication channel or second connection means 701a to the first data input 121 of the first input memory 120 of the first data element 118. In the shown exemplary embodiment three outputs of one data element 126 of the second software modules are connected to an input of three data elements 118 of the first software modules in parallel at the same time. The second software modules also provide output values to the output interface 137 through a communication channel realized by connection means 702. Second connection means 701a, 701b, 701c and 702 can also be accomplished as fourth software modules.
It is an essential advantage of the invention that not only the change of the state parameters in time can be followed but also the change of the elementary state parameters in detail which is not taught or disclosed by prior art documents. In the majority of the known numeric algorithms this feature can not be accomplished and the user often has to make presumptions on the basis of the totality of state changes and figure out the information on the individual partial changes.
It is important to note that the second communication channels of the second connection means 701a, 701b, 701c, and 702 are clearly distinguished from the content of the communication channels. The connection means define the structure of the system while the content carried by them changes dynamically in response to the function of the second software modules.
Fig. 8 illustrates a more complex system view of a model structure with time dependency for modelling processes with a structure changing in time. In such a case the dynamically generated passive and active databases of the first and second software modules have also a time dependency. On the arrow representing the time axis three points are marked which define different time slices 801a, 801b and 801c with different structure of the system. The existing data partitions of the dynamic database of the first software modules are connected with lines 802a, 802b and 802c. Similarly the existing data partitions of the dynamic database of the second software modules are connected with lines 803a, 803b, 803c and 803d. As shown in Fig. 8, the data partitions connected with lines 802a, 803a and 803b exist in a time interval between the first and second time slices 801a and 801b, the data partition connected with line 802b exists in a time interval between the first and third time slices 801a to 801c and the data partitions connected with lines 803c and 803d exist in a time interval between the second and third time slices 801b and 801c.
The lines 802 and 803 in the right side view of the three dimensional drawing represent a GANTT diagram of the system with time dependent structure. The front view of the three dimensional drawing represents the whole of the structure of the first and second connection means.
For a better understanding of the hardware architecture according to the invention we will give a detailed explanation on the basis of Figs. 9 to 16.
In the hardware implementation of the invention as shown in the exemplary embodiment in Fig. 9, a first, functionally distinguished subset of processor modules 902 comprises a plurality of substantially equal first processor modules 903. The first processor modules are adapted for the execution of a first software module, where a first software module represents a passive element and establishes on the basis of a set of predetermined rules a ^
state parameter. The first processor module elements 903 comprise an input/output unit 905 that is provided with an input 907 for receiving a change of a state parameter from the second processor modules 911, a. memory for storing a state parameter and an output 913 for outputting a value of a state parameter. A second, functionally distinguished subset of processor modules 916 comprise a plurality of substantially equal second processor module elements 917. The second processor modules are adapted for the execution of a second software module, where a second software module represents an active element and establishes on the basis of a set of predetermined rules a change of a state parameter. The second processor module elements 917 comprise an input/output unit 919 that is provided with an input 921 for receiving a state parameter from the first processor modules 903 and an output 927 for outputting a change of a state parameter.
In the shown embodiment a group of the processor module elements 903 are comprised in the subset of first processor modules 902, the processor modules 903 being adapted for the parallel execution of the programs of the first software modules. Each processor module
903 is configured to comprise a dynamic structure and data set on the one hand and a memory part, with data and program on the other hand which determine the functionality of the processor module. The first processor module element 903 is adapted for the execution of a first software module, where the first software module represents a passive element and establishes on the basis of a set of predetermined rules a state parameter. Accordingly the first processor module 903 comprises the following elements: a freely programmable first processing unit 904 with local memory for the program and the data, being adapted for the execution of the program of a first software module; a freely programmable first input/output unit 905 for selectively receiving input data and sending output data; wired or wireless first input communication channels 906; a freely programmable selectively receiving first input port 907; a first input decoding and interpretation means 908 ; a first input memory 909 for the constant and dynamic input data and for the communication program of the first processor module; a first program memory 910; a first output memory 911 for the executable program and for the constant and dynamic output data of the first processor module; a first output coding means 912 ; a module specific programmable first output port 913; and wired or wireless first output communication channel 914.
In the shown embodiment a group of the processor module elements 917 are comprised in the second subset of processor modules 916, the processor modules being adapted for the parallel execution of the programs of a second software module. Each processor module 917 is configured to comprise a dynamic structure and data set on the one hand and a memory part with data and program on the other hand which determine the functionality of the processor modules. The second processor module 917 is adapted for the execution of a second software module, where the second software module represents an active element and establishes on the basis of a set of predetermined rules a change of a state parameter. Accordingly the second processor module 917 comprises the following elements: a freely programmable second processing unit 918 with local memory for the program and the data, being adapted for the execution of the program of a second software module; a freely programmable input/output unit 919 for selectively receiving input data and sending output data; wired or wireless second input communication channels 920; a freely programmable selectively receiving second input port 921; a second input decoding and interpretation means 922; a second input memory 923 for the constant and dynamic input data and for the communication program of the second processor module; a second program memory 924; a second output memory 925 for the executable program and for the constant and dynamic output data of the second processor module; a second output coding means 926; a module specific programmable first output-port 927; and wired or wireless second communication channel 928. The exchange of data between the first and second subset of processor modules and an output interface 937 may be effected through first and second communication channels 914, 929, 928 and 930. The communication channels may be wired such as twisted pair, coaxial cable, switching field, or wireless, such as infra bluetooth or radio channels or any combination thereof.
Similar to the software implementation before the actual simulation steps can be performed, the general system of the hardware implementation has to be configured according to the field of application and to the specific case or task or problem.
Fig. 10 shows a configuration architecture, in which a supervisory or control processor module 1001 arranges for the selection of the first and second processor modules forming the first and second subset of processor modules, the assignment of the memory parts within the processor modules and of the connection means between the first and second processor modules and the output interface, and the generation and/or selection and distribution of the first and second program modules for the individual first and second processor modules.
First the model specific architecture has to be defined in the supervisory control processor 1001 that has connections means to all of the individual processor modules. Next the programs, the data and the communication abilities are distributed for the processor modules. Finally the supervisory control processor starts and coordinates the cyclic parallel run of executable programs in the processor modules, while the output is forwarded to the output processor module(s).
Accordingly the programming starts in the supervisory processor module. As a first step domain specific set of dynamic programs and case specific program associated data partitions are prepared for the first and second processor modules. The edition, generation and/or selection of these software elements is carried out for example with the help of a first and second expert interface 1002 and 1003. Similarly the structure of the model, as well as the structure associated data are prepared also within the extended control processor module 1001. The edition, generation and/or selection of these software elements is carried out for example with the help of the user interface connection means 1004.
There are connection means between the supervisory control processor module 1001 and the first processor modules. One part of these connection means 1004, controlled by the supervisory control processor realizes the configuration of the selective receiving and individual sending capabilities of the first processor modules. Another part of these connection means 1005, controlled also by the supervisory control processor performs the distribution of the domain specific programs and case specific data among the first processor modules. Programming of the first processor modules means the distribution of the input variables, iteration free executable first processing unit programs 1007 and output variables for the individual processor modules according to the model-driven structure on the one hand through a connection means 1009. Furthermore programming of the first processor modules has to be completed with the distribution of the communication capabilities on the other hand. For example all of the first processor modules are given a communication code (e.g. a frequency) for sending of its data, as well as a list of codes (e.g. frequencies) for receiving the incoming data from the second processor modules in the sense of the architecture shown in Fig. 1. The first processor module provided with these particulars is fully functional.
There are connection means between the supervisory control processor module and the second processor modules. One part of these connection means 1010, controlled by the supervisory control processor realizes the configuration of the selective receiving and individual sending capabilities of the second processor modules. Another part of these connection means 1010, controlled also by the supervisory control processor realizes the distribution of the domain specific programs and case specific data for the second processor modules. Programming of the second processor modules means the distribution of the input variables, iteration free executable second processing unit programs 1013 and output variables for the individual processor modules according to the model-driven structure on the one hand through a connection means 1015. Furthermore programming of the second processor modules has to be completed with the distribution of the communication capabilities on the other hand. For example all of the second processor modules are given a communication code (e.g. a frequency) for sending of its data, as well as a list of codes (e.g. frequencies) for receiving the incoming data from the first processor modules in the sense of the architecture shown in Fig. 1. The second processor module provided with these particulars is fully functional.
The hardware architecture configured for modelling and simulating a specific case, task or problem is shown schematically in Fig. 11. It is noted, that the processor modules are equipped with an autonomous input/output communication unit 905, 919, as well as with a processing unit with an executable program stored in a program memory 910, 924. The communication is advantageously arranged so that all processor modules are capable of specific output encoding of their messages thereby defining for all other processor modules the messages in a form of digital data or signals that can be decoded and received by one or more predetermined individual processor modules.
After completing the configuration and generation steps of a domain and case specific hardware and date architecture, as preparation steps, the actual model simulation can be performed which will be described in more detail with reference to Figs. 12 to 15. The model simulation takes place in four execution steps each of which being controlled by the supervising processor module. The four execution steps are usually be repeated according to the optionally changing time steps of the dynamic simulation.
Referring to Fig. 12, the first execution step of the model simulation will be explained in more detail. During the first execution step only the first processor modules take part in the execution in which all first hardware modules communicate the state values through first communication channels 1202 to the second processor modules. At the same time the first processor modules transfer their output values through first output communication channels 1203 to processor modules handling the output interface 937. In Fig. 13 the second execution step is shown, in which the second processor modules 1301 perform data processing 1302a, 1302b, 1303a, 1303b, 1304a.
hi the third step the resulting changes of the state parameters will be communicated through second communication channels 1401 to the first processor modules. At the same time the second processor modules transfer their output values through second output communication channels 1402 to processor modules handling the output interface 937 as shown in Fig. 14.
In the fourth executions step, as can be seen in Fig. 15, the first processor modules 1201 perform in parallel data processing 1501abc, 1502abc, 1503abc.
Fig. 16 illustrates a more complex system of a model structure with time dependency of the hardware architecture with a structure changing in time. In such a case the existence of the active processor modules and/or the connection means between the processor modules change according to some time- or event driven rules involved in the supervisory control processor module or in the distributed programs themselves. On the arrow representing the time axis three points are marked which represent different events 1601a, 1601b and 1601c or states of the system. The existing active software modules of the first processor modules are connected with lines 1602a, 1602b and 1602c. Similarly the existing active software modules of the second processor modules are connected with lines 1603a, 1603b, 1603c, 1603d and 1603e. As shown in Fig. 16, the active software modules connected with lines 1602a, 1602b and 1602c exist in a time interval between the first and third events 1601a and 1601c, the active software modules connected with lines 1603a, 1603c and 1603e exist in a time interval between the first and second events 1601a to 1601b and the active software modules connected with lines 1603b and 1603d exist in a time interval between the second and third events 1601b and 1601c.
The lines 1602 and 1603 in the right side view of the three dimensional drawing represent a GANTT diagram of the system with time dependent structure. The front view of the three Zo
dimensional drawing represents the whole structure of the hardware architecture with first and second connection means.
The following terms are used throughout the specification with a meaning defined below:
A "user" is the user of the software system, who prepares the input data and selects the actual software modules with the help of a user interface, and finally also evaluates the results. The user interface may be of a general type, which is capable of handling practically all types of data, or it may be a more specific type which is adapted to a particular type of tasks, for example the modelling of genetic processes.
"User interface" is a set of tools devised for a specific field of application, assisting the user in the preparation of the starting data, and also displays the obtained results. In a simple realisation, it is sufficient to use Microsoft EXCEL® worksheet, and the output may be presented in a similar manner, for example on other sheets of the same file. In a more sophisticated version the user interface may assist the user with defining various types of variables, and the definition of the relationships between them.
The "expert" or expert user is capable of changing the abilities of the simulator software. The expert user is capable of adding new types of active or passive elements, and may add appropriate smaller programs to the kernel code which may process the new types of active and passive elements, for example, an expert may be capable of modifying a software architecture originally conceived for the simulation of chromatographic analysis or polymerisation reactor tanks so that that the software architecture will be suitable for simulating a metabolic network model or the calculation of a logistics task.
The "expert interface" means the totality of the available subroutines which support the preparation of the different model adaptations.
The dynamic data, program and connection partitions can be supplemented, modified and deleted in runtime. It is to be noted that in the described software architecture the qualitative change in the complexity of the usual mathematical constructs can be transformed into the quantitative increase of the same, similar elements and connections. As an example, the models of concentrated and distributed parameters and even of population balance differ only in the number of the elements and connections. As another example, the various discrete or continuous, quantitative or qualitative, deterministic or stochastic, crisp or fuzzy models can be interpreted on the same structural skeleton of the elements and of connections, described by the first and second software modules.
The software architecture can be implemented on various platforms and languages, hi order to provide an even better understanding of the invention, in the following the general, upper level features of the software architecture will be summarized by means of an example with Prolog definitions.
In the Prolog implementation the first and second software modules, as well as the first and second connection means correspond to automatically generated dynamic program partitions. These dynamic program partitions describe the detailed states, the changes of the states of the modelled process, as well as, the input/output communication between the state and the changes of the states. The respective predicates are the following:
first_module data( FM Identifier, Identifying_name, Coordinates, Scheduling,
List_of_second_connections, First_module_program, State,
List_of_first_connections )
fϊrst_connection ( FC_Identifier, FM_Identifϊer, State values, SM_Identifier )
second_module_data ( SM Identifier, Identifyingjtiame, Coordinates, Scheduling,
List_of_first_connections, Second_modulejprogram, Process, List_of_second_connections) second_connection ( SC_Identifier, SM_Identifier, Change_values, FM_Identifier )
where:
FM Identifϊer = the identifier of the first software module data set;
SM_Identifier = the identifier of the second software module data set;
FC Identifier = the identifier of the first connection means,
SC_Identifier = the identifier of the second connection means;
Identifying_name {stringlist} = the identifying name of the respective software module data set;
Coordinates {integerlist}= the spatial and property coordinates in the case of the processes with distributed parameter);
Scheduling {timelist} = the temporal existence of the module data sets, declared by the Scheduling = [t(F,L,[Tl , ...,TN]5DT),...] data structure, where F and L are the first and last points of the time intervals, as well as T 1,...,TN are the discrete points of time, when the given module data set is to be taken into consideration, while DT is the optional initial time step of the simulation;
List_of first_connections {lflist} = the list of first connections, determining the input data for the functioning of the second software modules, i.e. lflist=first_connection* ;
List_of_second_connections {lslist} = the list of second connections, corresponding to the output data of the second software modules, i.e. lslist=second connection*; State_values {sign} = a user configured data set about the state (e.g. integers, reals, strings, tables, fuzzy variables, optional records, etc.) of the first software module data set;
Change values {sign}= a user configured data set describing an individual change (increase, decrease, overwriting, modification, etc.) in the second software module data set;
State {state_data} = a user configured static and/or dynamic data set characterizing the state of a given class of the first software module data sets;
Process {process data} = a user configured static and/or dynamic data set, associated with a given class of second software module data sets;
First_module_program = identifier of the dynamic, case specific clause partition, that executes the functionality associated with the given first software module data set;
Second_module_program = identifier of the dynamic, case specific clause partition that executes the functionality associated with the given active element.
The functionalities are described by the dynamic, case specific partitions of clauses
first_module( First_module_program, List_of_second_connections, State,
List_of_first_connections ) if
and
second_module( Second_module_program, List_of_first_connections, Process,
List_of_second_connections ) if respectively.
The main kernel program is organized by the basic clauses of
run if expert_input(...), user_input(...), generate_model(...), simulate(...), evaluate_output(...).
simulate(...) if stop_condition(...),!. simulate(...) if time_step(...), new_time(...),!, simulate(...).
time_step(...) if
execute_first_modules(...), excute_first_cormections(...), execute_second_modules(...), execute_second_connections(...),
In the following section examples for the application of the method and of the respective software architecture will be illustrated. It is to be noted, that all of the listed adaptations run with the same kernel program, supplied with the respective domain specific dynamic partitions. This makes possible to develop a platform independent code for any, arbitrary application, where the domain specific structures and functionalities can be edited by the field expert, using the so-called expert's interface.
Example 1. Model Based Design and Control of Cyclic, Pseudo-steady State Ion Exchange Process
Practical problem to be solved: Design and control of the co-current or countercurrent ion exchange processes, realized in the so-called Simulated Moving Bed system. The key idea of the Simulated Moving Bed is to "simulate" the solid phase motion by using standard fixed bed columns and periodically switching the inlet and outlet ports of the unit.
Special difficulties of the simulation: There are 8-32 systems of partial differential equations of second order with coupled, nonlinear inhomogeneous terms is to be solved under stepwise cyclically changing initial and boundary conditions. Sometimes the radial pore diffusion swelling and shrinkage have also to be taken into consideration.
First software module data sets: Individual competitive components in the given phase at a given compartment along the length of the respective column. The number of elements is usually in the order of magnitude 104.
Second software module data sets: The terminal elements of the hierarchy designate the architecture of the elementary transformations (ion exchange, weak sorption, etc.), transportations (convective and mixing flows, pore diffusion) and rules (control actions).
First software module programs: These brief dynamic program partitions define the calculation of the intensive properties from the extensive quantities, as well as the evaluation of the signs for the controlling systems.
Second software module programs: These brief dynamic program partitions declare the calculation of the component transfer, of the liquid flow, etc. for the conservational processes, as well as the execution of the diagnostic, control and evaluating rules.
User input: The user has to define the configuration of the system, the data of the columns, the initial state, the equilibrium and the process parameters (flow rates, column switch time, etc.). The kinetic and mixing parameters have to be identified from simple tests, using the simulator itself.
User output: There are detailed time functions for the instantaneous and column step averaged concentrations of the ions, as well as the concentration profiles along the length of the column series.
Evaluation of the results: There is a good agreement between the measure and calculated results. The simulator helped in the successful design and control of ion exchange process.
Example 2. Identification of Biological Processes
Practical problem to be solved: There is a gap between the genomic information discovered by bioinformatics and the organization & functioning of the cellular processes.
The efforts to synthesize the major cellular functions from the in vitro measured individual functionalities failed. Biosystem engineers need huge, complex models, built from the simplest elementary steps. The models must be able to be supplemented with any new interaction (e.g. in drug discovery or in toxicology). These models have to connect the metabolism with the polypeptide formation and degradation, too.
Special difficulties of the simulation: Regardless to the equilibrium reaction kinetic approach of biochemistry, the significant part of the cellular function takes place rather in a well-defined and "crowded" structure of the proteins, than in a more or less diluted liquid.
That's why the chemical engineer's way of thinking has to be combined the discrete cellular machineries, working according to some principles of mechanical engineering. The biosystems are highly underdetermined and, the useable models need special identifying abilities to treat the missing or uncertain knowledge. First software module data sets: All of the possible, more or less freely moving compounds and complexes, as well as the structured, located sites that may have any functionality in the various compartments.
Second software module data sets: AU of the possible elementary transformations inside the compartments and transportations between the compartments.
First software module programs: These brief dynamic program partitions define the calculation of the intensive properties from the extensive quantities, as well as the evaluation of the signs for the controlling systems.
Second software module programs: These brief dynamic program partitions declare the calculation of the transformations and transportations for the conservational processes, as well as the execution of the control functions of the signalling processes.
User input: The available quantities and concentrations, as well as the estimations of the process parameters. The detailed equilibrium, kinetic, transporting and signalling parameters have to be identified from possible measurements, using the simulator combined with a genetic algorithm.
User output: The calculated change of the amount and concentration of the various metabolites and macromolecular complexes, as well as the state of the keynote cellular elements.
Evaluation of the results: There is a good agreement between the measured and calculated results of the investigated published example.
Example 3. Planning and Scheduling of Supply / Demand Chains
Practical problem to be solved: The logistical (e.g. supply / demand) chains are built from storage volumes, as well as from discrete and continuous transportations and transformations (purchase, production, processing, consumption, sale). Thinking about the perspective cooperative systems, the goal is to evolve and to control an adaptable multiobjective suboptimal (compromise) solution for the collaborating participants.
Special difficulties of the simulation: In the (for the time being simplified and plausible) case studies we investigated the possibility of the cooperative local decisions about the alternative and/or concurrent elementary processes. Decisions are based on the economical potential, calculated from the changes in the costs and in the measures of demand, associated with the respective storage volumes.
First software module data sets: Storage volumes associated with the respective cost and measure of demand.
Second software module data sets: The possibility space of the model is determined by the alternative productions, consumptions, purchases, and sales, as well as by the concurrent processing recipes realizable in the given equipment.
First software module programs: Calculation of the specific parameters.
Second software module programs: Simulation of the purchases, consumptions, productions, transportations and transformations.
User input: a: Initial state, constraints, recipes, add-on control rules.
User output: Automatic schedules of the technically and economically feasible production.
Evaluation of the results: According to our experiences the method tends to select the locally advantages suboptimal solutions for each subsystems. A natural cooperativity appears in the system because of the same storage volumes are associated with the various connected elementary processes that results in the overlapping of the individual subgoals. The essence of this kind of cooperative architecture is that the functionally connected parts of the process are forced to develop such suboptimal states that allow developing the suboptimal configuration also for their neighbours.
Example 4. Simulation Based Cash Flow Analysis of an Agricultural Farm
Practical problem to be solved: Planning and scheduling of an agricultural farm, including the liquidity (cash flow) analysis.
Special difficulties of the simulation: There are a lot of elaborated data in form of statistical correlation, but the consistent system of the first principle expressions for the appropriate balance equations has not evolved yet. In addition the qualitative knowledge of the field expert has not collected in a systematic way.
First software module data sets: There are various groups of realistic and fictitious storage volumes at vendors, inside the farm, as well as at the consumers, containing raw materials, machinery, manpower, crops, fodders, animal populations, products, etc.
Second software module data sets: Describe the structure of the possible purchases, sales, as well as of the agricultural processes (e.g. ploughing, harrowing, sowing, harvest, etc.).
First software module programs: Describe the calculation, associated with the storages and evaluation of the signs for the controlling systems.
Second software module programs: Determine the simulation of the agricultural processes (consumption of land, seed grain, fertilizers, chemicals, machines, manpower, and the products, as well as determine the economic characteristics.
User input: The user has to define the initial state of the agricultural system, the estimated (optionally changing) economical parameters, as well as the possible, alternative agricultural activities, described by the sequence of the respective operations.
User output: The simulated output describes the detailed change of the characteristic materials, energy, manpower and machine consumption, as well as the cash-flow of the alternative plans. In addition the Gantt-chart of the allocated resources can also be generated.
Evaluation of the results: There calculated results are in good agreement with the practical experiences and, having connected the simulator with a genetic algorithm, feasible propositions for more favourable rotations of crops have been suggested.
The invention is not limited to the shown and disclosed embodiments, but other elements, improvements and variations are also within the scope of the invention. For example, it is clear for those skilled in the art that a number of other field definitions may be introduced in a specific implementation of the proposed software architecture. For example, the constraint conditions may even extend to semantic comparisons of strings.

Claims

1. A software architecture for the simulation of a process, comprising
i, multiple substantially equal first software modules (108, 118), each first software module having an input variable (121, 109) representing a change of a state parameter, a memory (119, 120) for storing a state parameter and an output (110, 124) for outputting a value of a state parameter, the first software module (108, 118) being programmed to represent a passive element and to establish on the basis of a set of predetermined rules a value of a state parameter, the set of predetermined rules being defined so that a resulting output value of the rules may be calculated substantially without repeated cycles,
ii, multiple substantially equal second software modules (113,126), each second software module having an input variable (129, 114) representing a state parameter and an output (115, 132) for outputting a change of a state parameter, the second software module
(113,126) being programmed to represent an active element and to establish on the basis of a set of predetermined rules a change of a value of a state parameter, the set of predetermined rules being defined so that a resulting output value of the rules may be calculated substantially without repeated cycles,
iii, first connection means (135) for communicating an output value (124) of a state parameter from the first software module (108, 118) to an input (129) of one or more second software modules (113,126),
iv, second connection means (133) for communicating an output value (132) of a change of a state parameter from a second software module (113,126) to the input (121) of one or more first software modules (108, 118),
v, cycle control means for causing • a, substantially all first software modules (108, 118) to establish the output values (124) of the state parameters of their associated characteristic entities substantially simultaneously, and subsequently
b, substantially all first connection means (135) to communicate the output values (124) from the first software module (108, 118) to the second software modules (113,126), and subsequently
c, substantially all second software modules (113, 126) to establish the output values (132) from their respective input state parameters substantially simultaneously, and subsequently
d, substantially all second connection means (133) to communicate the output values (132) from the second software module (113,126) to the first software modules (108, 118),
and to repeat steps a, to d, cyclically.
2. The software architecture of claim 1, including in the first and/or the second software module an optional third software module for performing the functions of the first connection means (135) and for communicating an output value (124) of a state parameter from a first software module (108, 118) to the input (129) of one or more second software modules (113,126).
3. The software architecture of claim 1 or 2, including in the first and/or the second software module an optional fourth software module for performing the functions of the second connection means (133) for communicating an output value (132) of a change of a state parameter from a second software module (113,126) to the input (121) of one or more first software modules (108, 118).
4. The software architecture of any one of claims 1 to 3, in which a rule within the set of rules defined for an active element describes a change of a state parameter as a function of time.
5. The software architecture of claim 4, further comprising constraint control means for checking during the execution of step c, the fulfilment of a constraint condition imposed on a value of a state parameter.
6. The software architecture of claim 5, in which the constraint control means is programmed for causing the cycle control means and the second software modules (113,126) to repeat step c, in a cycle if it is established in the subsequent step a, that a constraint condition is not fulfilled.
7. The software architecture of claim 6, in which the cycle control means and/or the second software modules (113,126) are programmed for changing step c, with a modified time increment.
8. The software architecture of any one of claims 1 to 7, in which the first software module (108, 118) is programmed for establishing an output value (124) of a state parameter by modifying the value of the state parameter determined during step a, of the previous cycle according to the change of the state parameter determined during step c, of the previous cycle.
9. The software architecture of claim 8, in which the value of the state parameter determined during steps a, of the cycle is stored in the memory (119) associated to the first software module (108, 118).
10. A hardware architecture comprising a set of processor modules arranged for the parallel processing of a task, comprising
i, a first subset of processor modules (901) comprising multiple substantially equal first processor modules (903), the first processor modules being adapted for the execution of a first software module, where a first software module represents a passive element and establishes on the basis of a set of predetermined rules a state parameter, the first processor modules (903) having an input (907, 908) for receiving a change of a state parameter, a memory (909, 911) for storing a state parameter and an output (912, 913) for outputting a value of a state parameter,
ii, a second subset of processor modules (915) comprising multiple substantially equal second processor modules (917), the second processor modules being adapted for the execution of a second software module, where the second software module represents an active element and establishes on the basis of a set of predetermined rules a change of a state parameter, the second processor modules (917) having an input (921, 922) for receiving a state parameter, a memory (923, 925) for storing the changes of the state parameter and an output (926, 927) for outputting the value of the change of a state parameter,
iii, first connection means (914) for communicating an output value (911, 912, 913) generated by a first software module in a first processor module (903) to the input (921, 922) of one or more second software modules in a second processor module (917),
iv, second connection means (928) for communicating an output value (925, 926, 927) from a second software module in a second processor module (917) to the input (907, 908) of one or more first software modules in a first processor module (903),
v, cycle control means for causing
a, substantially all first processor modules (903) to establish output values of the first software modules substantially simultaneously,
b, substantially all first connection means (914) to communicate output values (911, 912, 913) from the first software modules in a first processor module (903) to inputs (921, 922, 923) of second software modules in a second processor module (917),
c, substantially all second processor modules (917) to establish output values of the second software modules from their respective inputs substantially simultaneously, and d, substantially all second connection means (928) to communicate output values (925, 926, 927) from the second software modules in a second processor module (917) to inputs (907, 908, 909) of first software modules in a first processor module (903),
and to repeat steps a, to d, cyclically.
11. The hardware architecture of claim 10, further comprising - a control processor module (1001) - connection means ( 1004, 1009, 1010, 1015) for connecting control processor module (1001) to substantially all first and second processor modules (903, 917), where the control processor module is adapted for the distribution (1009, 1015) of the programs, data and for the configuration and the initialisation (1004, 1010) of the connection means (914, 928) for connecting the processor modules (903, 917) of the first and second subsets (902, 916) of processor modules.
12. The hardware architecture of claim 10 or 11, further comprising analogous processing units and/or analogous connections with associated A/D converter means in first (908, 912) and/or second (922, 926) processor modules.
13. The hardware architecture of any one of claims 10 to 12, further comprising constraint control means (1007, 1013) for checking during the execution of step b, the fulfilment of a constraint condition imposed on a value of a state parameter.
14. The hardware architecture of claim 13, in which the constraint control means is programmed for causing the cycle control means and the second subset of processor modules to repeat step c, in a cycle if it is established in the subsequent step a, that a constraint condition is not fulfilled.
15. The hardware architecture of claim 14, in which the first subset of processor modules further comprise an output for indicating the fulfilment or non-fulfilment of a constraint ^
condition.
16. The hardware architecture of any one of claims 10 to 15, in which the first connection means and/or second connection means are wired or wireless connections.
17. The hardware architecture of any one of claims 10 to 16, in which the cycle control means comprises a supervisory controlling processor (1001) module separate from the first and second subsets of processor modules.
18. The hardware architecture of any one of claims 10 to 16, in which the functions of the cycle control means are distributed between multiple processor modules.
19. The hardware architecture of claim 18, comprising a set of substantially equal processor modules, which are adapted for the execution of both first and second software modules.
20. A method for the simulation of a physical or conceptual process, in which the physical or conceptual process is regarded as a primary process, and the functioning and state of the primary process are simulated with the help of a computational secondary process, the secondary process involving the essential structure and the elementary relationships determining the functioning and state of the primary process,
comprising the steps of
i, identifying characteristic entities of the primary process, and relevant structures and properties describing a state and a change of state of the characteristic entities,
ii, defining a finite number of passive elements of the secondary process, and associating to each passive element a characteristic entity of the primary process, a set of state parameters describing the characteristic entity associated to the respective passive element, a set of rules expressing a relationship between the state parameters of the characteristic entity associated to the respective passive element and/or expressing constraints imposed upon the state parameters of the characteristic entity associated to the respective passive element, the set of rules being defined so that an application of the rules and thereby the determination of an output result resulting from the application of the rules may be performed readily and substantially without repeated cycles,
iii, defining a finite number of active elements of the secondary process, and associating to each active element a set of rules, where the rules define a change of the state parameters of the entities associated to one or more passive elements, the set of rules being defined so that an application of the rules and thereby the determination of an output result resulting from the application of the rules may be performed readily and substantially without repeated cycles,
iv, defining a modifying channel between an active element and one or more passive elements, during which modifying channel a value of a change of a state parameter associated to the respective active element may be output towards the respective passive element(s),
v, defining a reading feedback channel between a passive elements and one or more active elements, during which reading feedback channel a value of a state parameter may be fed to an input of an active element, where the rule associated to the respective active element involves a state parameter of the passive element at the input end of the respective reading channel,
vi, and cyclically repeating the following steps:
a, substantially simultaneously establishing on the basis of the set of rules associated to the respective passive element an output value of the set of state parameters of substantially each passive element, b, forwarding along the reading feedback channel(s) to one or more active elements the value(s) of the state parameters of the characteristic entity associated to the respective passive element,
c, substantially simultaneously establishing on the basis of the rule associated to the respective active element output value(s) of the change of the state parameters,
d, updating through the modifying channel(s) the state parameters of the physical entity associated to the respective passive element with the output value established in step c.
21, The method of claim 20, in which a state parameter is described by a numeric or symbolic value.
22. The method of claim 20 or 21, in which a rule within the set of rules defined for an active element describes a change of a state parameter as a function of time.
23. The method of claim 22, further comprising the step of checking of the fulfilment of a constraint imposed on a value of a state parameter.
24. The method of claim 23, further comprising the step of repeating step c, in a cycle if it is established in the subsequent step a, that a constraint is not fulfilled.
25. The method of claim 24, in which step c, is repeated with a modified time increment.
26. The method of any one of claims 20 to 25, further comprising the step of storing a value of a state parameter associated to a point in time.
27. The method of claim 26, further comprising the step of establishing an output value of a state parameter by modifying a value of a state parameter determined during step a, of the previous cycle according to a change of a state parameter determined during step c, of the previous cycle.
28. The method of any one of claims 20 to 27, wherein a state parameter is an additive physical measure, a signal or an abstract symbol.
29. The method of any one of claims 20 to 28, wherein a rule defined for the active element is deterministic, non-deterministic (stochastic), quantitative, qualitative, crisp or fuzzy.
PCT/HU2007/000002 2006-01-16 2007-01-15 Process simulation software and hardware architecture and method WO2007080437A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
HU0600034A HU0600034D0 (en) 2006-01-16 2006-01-16 Process simulation software and hardware architecture and method
HUP0600034 2006-01-16

Publications (3)

Publication Number Publication Date
WO2007080437A2 true WO2007080437A2 (en) 2007-07-19
WO2007080437A9 WO2007080437A9 (en) 2008-01-10
WO2007080437A3 WO2007080437A3 (en) 2008-02-14

Family

ID=89986521

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/HU2007/000002 WO2007080437A2 (en) 2006-01-16 2007-01-15 Process simulation software and hardware architecture and method

Country Status (2)

Country Link
HU (1) HU0600034D0 (en)
WO (1) WO2007080437A2 (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5692193A (en) * 1994-03-31 1997-11-25 Nec Research Institute, Inc. Software architecture for control of highly parallel computer systems
WO2001098871A2 (en) * 2000-06-19 2001-12-27 P.C. Krause And Associates, Inc. Distributed simulation
US20020133325A1 (en) * 2001-02-09 2002-09-19 Hoare Raymond R. Discrete event simulator
US20020169785A1 (en) * 2000-12-29 2002-11-14 Netemeyer Stephen C. Computer system and method having a facility network architecture
US20030221086A1 (en) * 2002-02-13 2003-11-27 Simovich Slobodan A. Configurable stream processor apparatus and methods

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5692193A (en) * 1994-03-31 1997-11-25 Nec Research Institute, Inc. Software architecture for control of highly parallel computer systems
WO2001098871A2 (en) * 2000-06-19 2001-12-27 P.C. Krause And Associates, Inc. Distributed simulation
US20020169785A1 (en) * 2000-12-29 2002-11-14 Netemeyer Stephen C. Computer system and method having a facility network architecture
US20020133325A1 (en) * 2001-02-09 2002-09-19 Hoare Raymond R. Discrete event simulator
US20030221086A1 (en) * 2002-02-13 2003-11-27 Simovich Slobodan A. Configurable stream processor apparatus and methods

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"Using Simulink Version 6" USING SIMULINK, XX, XX, June 2004 (2004-06), pages I-XVI,1, XP002383210 *
BELA CSUKAS ET AL: "Generic Bi-Layered Net Programming" IFIP CONFERENCE ON ARTIFICIAL INTELLIGENCE APPLICATIONS AND INNOVATIONS (AIAI), X, XX, vol. 187, 7 September 2005 (2005-09-07), pages 701-710, XP009091653 *
CSUKÁS B ET AL: "GENERIC BI-LAYERED NET, AS THE NATURAL COMPUTATIONAL MODEL OF CONSERVATION AND INFORMATION PROCESSES" INTERNATIONAL JOURNAL OF SIMULATION. SYSTEMS, SCIENCE AND TECHNOLOGY, UK SIMULATION SOCIETY, NOTTINGHAM, GB, vol. 6, no. 6, 2004, pages 10-22, XP007903366 ISSN: 1473-8031 *
GYOENGYI BANKUTI AND BELA CSUKAS: "Generic Bi-Layered Net Model. General Methodology for Process Simulation" IFIP CONFERENCE ON ARTIFICIAL INTELLIGENCE APPLICATIONS AND INNOVATIONS (AIAI), X, XX, vol. 187, 7 September 2005 (2005-09-07), pages 691-700, XP009091652 *

Also Published As

Publication number Publication date
WO2007080437A9 (en) 2008-01-10
HU0600034D0 (en) 2006-03-28
WO2007080437A3 (en) 2008-02-14

Similar Documents

Publication Publication Date Title
Kleijnen et al. State-of-the-art review: a user’s guide to the brave new world of designing simulation experiments
Pal et al. A review of platforms for the development of agent systems
Cabarle et al. Improving GPU simulations of spiking neural P systems
Jalving et al. Graph-based modeling and simulation of complex systems
Dudley et al. A quick guide for developing effective bioinformatics programming skills
Pan et al. Numerical P systems with production thresholds
Csukás et al. Combining genetic programming with generic simulation models in evolutionary synthesis
Wang et al. BrainPy: a flexible, integrative, efficient, and extensible framework towards general-purpose brain dynamics programming
Bolte Object-oriented programming for decision systems
Lopez-Ortega et al. A multi-agent system to construct production orders by employing an expert system and a neural network
Goles et al. On the effects of firing memory in the dynamics of conjunctive networks
Shahid et al. A systematic parameter analysis of cloud simulation tools in cloud computing environments
Cheng et al. A two-machine flowshop scheduling problem with precedence constraint on two jobs
Dib et al. Formal Specification of Multi-Agent System Architecture.
WO2007080437A2 (en) Process simulation software and hardware architecture and method
De Vos et al. Virtual plant tissue: building blocks for next-generation plant growth simulation
Duro et al. Liger: A cross-platform open-source integrated optimization and decision-making environment
Lambert et al. Deep learning from phylogenies for diversification analyses
Räihä Applying genetic algorithms in software architecture design
Cedeno-Mieles et al. Data analysis and modeling pipelines for controlled networked social science experiments
Chabrier et al. Toward a simulation modeling platform for studying cropping systems management: the Record project
García-Quismondo et al. Membrane computing as a modelling tool: looking back and forward from Sevilla
Akl et al. Introduction to parallel computation
Cabarle et al. Spiking neural P system without delay simulator implementation using GPGPUs
Csukás et al. Generic Bi-Layered Net Programming: General Software for the Simulation of Hybrid Processes

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07705402

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07705402

Country of ref document: EP

Kind code of ref document: A2