Simulation Process Organization

Using visual specifications of described multi-pole models of hydraulic components one can graphically compose models of various fluid power systems for simulating dynamic responses.

When simulating dynamic behavior, transient responses in certain points of the fluid power system caused by applied disturbances are calculated. Disturbances are considered as changes of input variables of the fluid power system (pressures, volumetric flows, load forces or moments, control signals, etc.). Time step length and number of steps are to be specified. For integrations in dynamic calculations fourth-order classical Runge-Kutta method is used in component models.

Dynamic computing process is organized by corresponding process class (dynamic Process 3D). To follow the system behavior, concept of state is invoked. State variables are introduced for each component to characterize behavior of the element at the current simulation step.

Simulation tasks require computing states in a loop until some satisfying final state is reached. To specify such task in CoCoViLa, subtasks are used. The following statement specifies that a finalstate can be computed from a given initstate if a function exists that calculates the nextstate from known states (usually from prevstate and state):

[prevstate, state -> nextstate], initstate -> finalstate {process}.

To solve a topmost computational problem initstate -> finalstate, the subtask prevstate, state -> nextstate must be solved. If the subtask is solvable, higher-order dataflow is constructed by the CoCoViLa planner. The constructed function prevstate, state -> nextstate is passed as an argument to the method process and this method can iteratively call the function to increment the state as long as it is needed.

When solving subtask prevstate, state -> nextstate loop dependences between outer variables (poles) of components models may occur. The described below technique is used for calculating variables in loop dependences. One variable in each loop is split and iteration statement for calculating variables in loops is specified:

[primset -> secondset], initset -> finalset {iterator},

where: initset – set of approximate initial values of variables in loop, primset, secondset – sets of split variables, finalset – set of variables in loop, computed using iterations.

To solve computational problem initset -> finalset, the subtask primset -> secondset for recomputing split variables must be solved. The synthesized function primset -> secondset is passed as an argument to the method iterator and this method can iteratively call the synthesized function to calculate finalset.

The method is illustrated in the following example.

PieceOfScheme.png In this fragment two loop dependencies VP.Q1 -> ResG.Q2 -> ResG.p2e -> VP.p1 -> VP.Q1 and VP.Q2 -> ResH.Q1 -> ResH.p1e -> VP.p2 -> VP.Q2 take place. The loop dependencies can be solved if variables ResG.p2e and ResH.p1e are split and calculated using built-in iteration method. State variables and split variables must be described in component models. When building a particular simulation task model and performing simulations state variables and split variables are used automatically.

When composing a simulation task all the parameters of components must be provided with necessary parameter values through properties windows. Approximate initial values are to be specified in properties windows as well.

All the input variables in the dynamic simulation tasks are to be specified by dynamic Source and dyn_stat_Source classes. All the constant inputs are to be specified by constant Source classes. Time is specified by Clock class.

In a simulation example hydraulic fluid specified in dynamic Process 3D properties is used. Physical properties of fluid (density ρ, kinematic viscosity ν and compressibility factor β) are calculated for each component at each simulation step depending on medial pressure in the component.