You are on page 1of 6

Analysis and synthesis: The search for solutions to

the given problem takes place against the background


of situation analysis and objective. This process takes
the form in practice of a permanent alternation between
synthesis steps and analysis steps which the
product developers carry out partly consciously,
partly also subconsciously. The aim of this substep is
to work out alternative solution variants. In the search
for a solution, it is of course possible to identify additional
aspects of the problem which necessitate a return
to situation analysis and objective or have to be
included in the subsequent assessment step as supplementary
criteria.
Analysis and assessment: The solution variants concretized
in the course of the search for a solution are
subsequently subjected to a detailed evaluation. For
this purpose, the properties of the individual variants of
a part solution or overall solution are analyzed on the
basis of the requirements imposed on them. This can
take place for example by calculation, simulation, experimentation,
etc. If individual approaches to a solution
differ too much in their degree of concretization to
allow comparative assessment, a return should also be
made here to the search for a solution. The assessment
of the solution variants in this case takes place on the
basis of the assessment criteria defined during the formulation
of a goal and search for a solution. As a result
of the assessment, a proposal or recommendation for
one or more alternatives for a solution should prepare
the way for a decision to be taken.
Decision: With the decision, it must be established
whether the previous procedure for problem-solving
has led to a satisfactory result. If this is not the case, a
return must be made to the situation analysis and formulation
of a goal. Otherwise, a decision is made on an
alternative for a solution, perhaps even more than one
alternative, which is or are to be made the basis of further
planning.
Planning the further procedure or learning: The
planning of the further procedure will in many cases
run more or less smoothly into further problem-solving
cycles and in this way lead to an efficient process
procedure that is adapted to the situation. Apart from
the purely operative assessment of the handling result,
there should however also be a brief pause at the
end of each micro-cycle, in order to subject both the
result and the process sequence to a general critical
appraisal. By examining what was or is good about
the respective process sequence and the result and
what was or is less good, available knowledge can be
generated for forthcoming development tasks. In this
way, future process sequences can be systematically
improved.
3.1.2 V model as a macro-cycle
The V model describes the generic procedure for designing9)
mechatronic systems, which is to be given a
more distinct form from case to case (Figure 3-2).
Requirements: The starting point is formed by an
actual development order. The defined object was
specified more precisely and described in the form of
requirements. These requirements at the same time
form the measure against which the later product is to
be assessed.
System design: The aim is to establish a cross-domain
solution concept which describes the main physical
and logical operating characteristics of the future prod-
uct. For this purpose, the overall function of a system is
broken down into main subfunctions. These subfunctions
are assigned suitable operating principles or solution
elements and the performance of the function is
tested in the context of the system.
Domain-specific design: On the basis of this jointly
developed solution concept, further concretization
usually takes place separately in the domains involved.
More detailed interpretations and calculations are necessary
to ensure the performance of the function, in
particular in the case of critical functions.
System integration: The results from the individual
domains are integrated to form an overall system, to allow
the interaction to be investigated.
Assurance of properties: The progress made with the
design must be continually checked on the basis of the
specified solution concept and the requirements. It
must be ensured that the actual system properties coincide
with the desired system properties.
Modeling and model analysis: the phases described
are flanked by the forming and investigating of the system
properties with the aid of models and computeraided
tools for simulation.
Product: The result of a continuous macro-cycle is the
product. In this case, a product is understood as meaning
not exclusively the finished, actually existing product
but the increasing concretization of the future product
(product maturity). Degrees of maturity are, for
example, the laboratory specimen, the functional specimen,
the pilot-run product, etc.
A complex mechatronic product is generally not produced
within one macro-cycle. Rather, a number of cycles
are required (Figure 3-3).
In a first cycle, for example, the product is functionally
specified, first operating principles10) and/or solution
elements11) are selected and roughly dimensioned,
checked for consistency in the system context
and realized in an exemplary form. The result is gener-
ally a laboratory specimen. This is further concretized
in a second cycle (fine dimensioning of the solution elements,
simulation of behavior and form), in order to
create a first functional specimen. Depending on the
progress made with the design and the type and complexity
of the development task, further macro-cycles
may be required to arrive at the product that is ready
for mass production. The number of macro-cycles and
the substeps to be run through in the V model depend
on the specific development task.
3.1.3 Process modules for recurrent working
steps
Some substeps which keep recurring when designing
mechatronic systems can be described in a more concrete
way in the form of partly predefined process
modules. The process modules of system design,
modeling and model analysis, domain-specific design,
system integration and assurance of properties
are explained below.
System design
The system design begins with the abstraction of the
ideas described in the requirements list. This is intended
to avoid prefixed elements which possibly restrict
the solution space. The aim is to work out what
is essential and generally applicable in respect of the
setting of the problem. This is achieved for example
by reduction of the requirements list to essential
statements and solution-neutral formulation of the
problem [PB97].
Setting up the function structure: the overall function
is derived from the problem specification (cf.
Figure 3-4). It represents the target function for the
behavior of the system under its operating conditions.
The operating conditions form the input variables, the
output variables describe the desired behavior. With
the aid of the general flow variables of material, energy
and information (cf. Section 2.2.1), and block

representation, the interrelationship between input


variables and output variables can be specified. The
task to be solved is generally too complex to allow the
technical realization to be derived directly from the
overall function. Therefore, the overall function has
to be divided up into subfunctions. Subfunctions of
mechatronic systems are, for example, driving, openclosed-
loop control, measurement, transmission, etc.
The subfunctions are in turn linked via material, energy
and information flows to form the function
structure, to describe the behavior and detect inconsistencies
at an early time. The aim is to detail the
function structure to the extent required to find operating
principles and solution elements for performing
the subfunctions. If this does not appear to be possible
for a subfunction, the subfunction has to be divided
up further. This takes place as an alternation of
analysis steps and synthesis steps (cf. Section 3.1.1).
So-called canonical functions represent a new solution
approach, to support the described transition
from the abstract general flow and function variables
to suitable mechatronic solution principles. Canonical
functions comprise a set of domain-independent
function verbs and function variables. For concretizing
a canonical function variable, only one physical
variable from each domain is respectively available
for selection. This makes further specification easier.
For more on the canonical functions, you are referred
to [Hua02].

Search for operating principles and solution elements


for performing subfunctions: For individual
subfunctions, suitable operating principles and solution
elements are sought. The performance of a subfunction
cannot always be realized as a 1 : 1 relationship
with an operating principle/solution element;
rather, there are polyhierarchical performance relationships
[Rot00]. This is the case for example with
supporting solution elements such as the housing,
which performs several subfunctions (fastening, supporting,
sealing, etc.). The search and assignment
takes place in an iterative process, taking the beneficial
and disturbing functions and the compatibility
conditions into consideration. The process is continued
until all the subfunctions are satisfied by suitable
operating principles and/or solution elements
[KBS97]. Catalogs (catalogs for physical effects and
operating principles, for example [Rot00], product
catalogs) and electronic market places (for example
CompoNET12) make the search easier. To perform
the overall function, the operating principles/solution
elements are linked (via material, energy and information
flows) to form the operating structure13).
The aim is to identify the physical compatibilities between
the operating principles/solution elements and
ensure a trouble-free material, energy and information
flow. Often, however, the operating structure
alone is still insufficiently concrete to allow the solution
principle to be assessed. The operating structure
must be quantified for example by approximate calculation
or rough dimensioning of the geometry. The
further concretization of the operating structure leads
to the building structure14). With its aid, the compatibilities
between the operating principles/solution
elements are checked with respect to the form (in particular
in the case of spatial integration). The solution
elements are also to be embedded in a supporting
and enveloping system, which ensures the functionally
appropriate arrangement of the elements and
their interaction. For optimizing the building structure
with regard to degree of integration, avoidance of
disturbing functions etc., creation principles, such as
for example the integral and differential methods
of construction15) are to be applied.
Concretizing to form solution variants in principle:
The ideas worked out for a solution are generally
not concrete enough to stipulate the final cross-domain
concept and allow the design to be continued in
the technical disciplines involved. Further aspects
such as fault susceptibility, weight, service life, etc.
must be taken into consideration. Among the means
of obtaining information are orienting calculations
(Finite Element Method (FEM), analysis of multibody
systems (MBS); cf. Section 3.3), outlined creation
studies, building of viewing models. The operating
principles and solution elements are concretized
on the basis of the newly obtained information until
solution variants in principle of the defined object can
be identified. These are subjected to a final assessment
on the basis of technical and commercial criteria.

The result of the system design is a cross-domain solution


concept, which describes the main physical
and logical operating characteristics of the future
product and the type and arrangement of its components.
Modeling and model analysis
On account of their complex structure and cross-domain
character, mechatronic systems should be depicted
in a computer. Without modeling the entire behavior,
it is not possible to deal with the complexity
of mechatronic products. The modeling and analysis
of the system takes place from the aspects of dynamics,
heating, stray fields, vibration-noise simulation,
etc. In modeling and model analysis, it is necessary to
take into account some special aspects, which are described
in more detail in Section 3.2.
Domain-specific design
When assigning operating principles and solution elements
to subfunctions, a partitioning is generally
performed, i.e. dividing of the performance of the
function among the domains involved. The term partitioning
has been introduced in hardware/software
codesign [Buc01]. The development in the relevant
domains takes place on the basis of established, domain-
specific development methodologies, which are
characterized by their own ways of thinking, conceptual
ranges and experiences. For more, you are referred
to the respective literature: including mechanical
engineering (VDI 2221); software technology:
phase models [Pre94; Bei95], waterfall model
[PB96], V model [Br95; Ver94], spiral model
[Boe88], Unified Modeling Language (UML)
[Oes98]; digital electronics: abstraction levels
[BGH96; Arm89], phase model [Esc93]. A comprehensive
overview is also provided by [GEK01].
System integration
System integration is understood as meaning the
bringing together of parts (functions, components,
subsystems) to form a superordinate whole (future
product represented according to degree of maturity
as, for example, laboratory specimen, functional
specimen, pilot-run product). The suitable type of integration
is to be chosen in accordance with the defined
object. Types of integration are, for example
[KZB01]:
Integration of distributed components: Components
such as actors, sensors and power actuators
are connected to one another via signal and energy
flows. The processing of the signals takes place
with the aid of communication systems (for example
sensor-actor bus, field bus, etc.), that of the
Feinenergy
flows via cabling and plug-in connectors.
It is advantageous that series components can be
used; cable and plug-in connections entail the
risk, however, of contact problems, cable breakages
and short-circuits, in particular under rough
ambient conditions.
Modular integration: The overall system is
made up of modules of defined functionality and
standardized dimensions in various size classes.
The coupling takes place via unified interfaces,
such as for example a DIN plug and socket connection,
standardized integral, nonpositive or positive
connections. These modules that are included
in a modular system can be flexibly combined
and make it possible to obtain great functional variety.
Modularly integrated systems generally also
have a larger component volume and higher material
expenditure and component complexity in
comparison with spatially integrated systems.
Spatial integration: All components are spatially
integrated and form a complex functional unit, for
example integration of all elements of a drive system
(controller, power actuator, motor, transfer
element, operating element) into a housing (see
for example the Integrated multicoordinate
drive in Section 4.4). Advantages include a smaller
installation space, greater reliability brought
about by reduction of the interfaces, faster data
transmission/higher power and lower assembly effort.
However, the spatial proximity of the components
also allows undesired interactions to arise,
such as for example heating, stray magnetic fields,
vibrations, noises and voltage peaks, which are to
be taken into consideration at an early time. Under
some circumstances, electronic components are to
be adapted to the operating environment (temperature,
humidity, vibrations, etc.); additional
measures such as encapsulation or cooling may be
required to ensure component reliability. Spatial
integration therefore requires a systematic procedure
for design, early observance of the creation
principle of an integral method of construction
(see Section 3.1.3 System design) and support
by modeling and IT tools.
To achieve a high degree of integration, the operating
principles and solution elements are to be checked for
compatibility, taking the beneficial and disturbing
functions into consideration, and the interfaces for the
later integration (rough dimensioning) are to be
formed already in the system design. During the fine

You might also like