Matlab/Simulink R

storage? It will be hard to estimate the answer to such questions without extensive simulations or experiments. Even less predictable is the consumer’s reaction on having a potentially heavier vehicle with less effective space and payload.

With additional systems also the question of their optimal arrangement arises:

∗ Connection Structure

When thinking of the basic electric elements (resistor, capacitance and induc-tance) it is common sense, that the system structure has a huge impact on the overall behaviour. The two basic patterns, plugging every part in series or in par-allel, will result in two very different resonant circuits - in parpar-allel, the resistance of the result is maximal, in series minimal.

More complex design problems like production systems or computer networks of-fer a variety of difof-ferent topologies to arrange the subsystems - rings and stars to name two that are in use for both.

– System Properties

Besides those high-level decisions also the values of, be they discrete or continuous, the system’s properties will have impacts on the properties describing the system’s behavior. Some examples:

∗ On a quadcopter, the capacity of the battery - und thus its weight - will determine how long the drone can fly, the payload it is able to carry and, if it is capable of taking off at all.

∗ In a resonant electric circuit, the components’ properties will determine the res-onating frequency.

∗ For a discrete controller, sampling time has a big impact on control performance.

As already mentioned, in design problems these questions can and will occur combined. Is a small combustion engine more efficient than a large electric drive? How many production machines of which types in which topology will optimise the prodction line’s throughput?

The structure of the design problem also has an influence on the detailed descriptions in Mat-lab/Simulink.

6.3. Matlab/Simulink

The Matlab environment is a scientific computing and simulation tool that was used extensively for teaching purposes throughout my mechatronics curriculum, as well as it is employed broadly in companies and research facilities. Also its support for graphical generation of mathematical and physical models via the Simulink/SimScape package. These models are stored in plain text, which made Matlab/Simulink the number one choice to demonstrate the framework’s functionality.

Given the time to read into the specification and to implement the necessary adapters would for sure enable the workflow in figure 6.1 also to use another modeling language like e.g. Modelica.

6.3.1. Creating the Skeleton Model

The skeleton model contains the elements every concept has in common, as well as the experi-mental setup to evaluate a concept. In figure 6.2 a simple skeleton model is given for an electric drive powering a linear transmission with transmission ratioi1which then moves a body carrying

inertia.

The controller is tasked to perform a step, which means moving the mass instantly. Of course this is infeasible as motor and mass are modeled with inertia, but the simulation result - the step response tells a lot on the system that responded it. In the example, the consumed electric power (P =U ·I) is integrated and serves as a characteristic property to describe the fitness of a concept. But back to the important elements in the skeleton.

Insertion of Working Principles

Any subsystem block named after the scheme “subsys ” + name + “ ” is interpreted as a dummy working principle, which can be seen like a formal parameter. When evaluating solutions, this dummy working principle is replaced by an actual working principle - the actual parameter for the corresponding dummy working principle. In figure 6.2 such subsystems are shaded, but only for better visibility - the block colour has no influence on the framework’s functionality.

Insertion of Variable Parameters

Any parameter named after the scheme “param ” + name + “ ” is interpreted as a variable and will be replaced by its actual value, be it e.g. numeric, boolean, or string. The possible values are defined in the SysML design space. In figure 6.2 such parameters are coloured too, again for better visibility. In the simulation shown in figure 6.2, the replacement mechanism was only applied to gains. It could be used for basically any textual input of Simulink blocks - be it sources, transfer functions or switching conditions.

Enriching Matlab Script

Similar to variable parameters in Simulink, the “param ” + name + “ ” combination is also replacable in a Matlab script used to initialise the Simulink simulation.

6.3.2. Modeling Components

An example of a model of an electric drive used in the skeleton in figure 6.2 is given in figure 6.3.

The only real limitation to the component modeler is the interface of the subsystem. This, and especially the sequence of input and output ports, can be ensured easily by copying the block used in the skeleton into a new Simulink model, then clearing all elements except the ports to come to a valid starting point for the component.

The components allow the same naming scheme for variable parameters with “param ” + name + “ ”, which allows to use the same model for e.g. various build sizes of a component.

Limits in Modeling of Variable Subsystems

For now, the framework is not implemented to support multiple levels of subsystems. It is possible for sure, but will increase the algorithms’ complexity, as recursions are needed to proceed through the different levels of subsytems.

A second limitation arises in the use of multiplicities. As already stated, every possible subsystem needs to be modeled in the skeleton. If multiplicities vary, a dummy system, e.g., a system without impact on the overall system’s interfaces, needs to be modeled and included in the design space.

As insertion points for working principles are foreseen for the maximum number of subsystems, unused spots have to be filled with dummy systems that behave like a non-existent system.

6.3. Matlab/SimulinkR

Figure 6.2.: A Simulink Skeleton

(a) Block Interface (b) Block Contents Figure 6.3.: Inner structure of a variable subsystem