Estrategia para emprender un proyecto

All rights reserved © Verein Deutscher Ingenieure, Düsseldorf 2004– 26 – VDI 2206

3 EntwicklungsmethodikMechatronik

3.1 VorgehenSowohl die Erfahrungen der industriellen Praxis alsauch die Ergebnisse der empirischen Konstruktions-forschung der letzten Jahre haben deutlich gemacht,dass es keine „kanonisierbare Optimalform des Kon-struktionsprozesses gibt, der der Konstrukteur ineinem festen Ablaufplan folgen kann“ [Dör94]. Umdieser Erkenntnis auch bei der Entwicklung mecha-tronischer Systeme Rechnung zu tragen, wird imRahmen dieser Richtlinie ein flexibleres Vorgehens-modell vorgeschlagen, das sich im Wesentlichen aufdrei Elemente stützt:

• allgemeiner Problemlösungszyklus auf der Mi-kroebene

• V-Modell auf der Makroebene• vordefinierte Prozessbausteine zur Bearbeitung

wiederkehrender Arbeitsschritte bei der Entwick-lung mechatronischer Systeme

Problemlösungszyklus als Mikrozyklus: DieStrukturierung des Vorgehens im Entwicklungs-prozess erfolgt dabei auf der Grundlage eines allge-meinen Problemlösungszyklus, wie er z.B. aus dem„Systems Engineering“ [DH94] bekannt ist. DurchAneinanderreihen und Verschachteln von Vorgehens-zyklen lässt sich die Prozessplanung flexibel an dieEigenheiten jeder Entwicklungsaufgabe anpassen.Der vorgestellte Mikrozyklus soll vor allem den imProzess stehenden Produktentwickler bei der Bear-beitung vorhersehbarer und damit planbarer Teilauf-gaben, aber auch bei der Lösung plötzlich auftreten-der, unvorhersehbarer Probleme unterstützen.

Das V-Modell als Makrozyklus: Eine Richtschnurfür das grundsätzliche Vorgehen bietet das aus derSoftwareentwicklung übernommene und an die An-forderungen der Mechatronik angepasste V-Modell,das die logische Abfolge wesentlicher Teilschritte beider Entwicklung mechatronischer Systeme be-schreibt [Brö95; FKM00]. Bei der Anwendung die-ses Modells in der Praxis ist zu beachten, dass diezeitliche Abfolge der Teilschritte von der logischenReihenfolge abweichen kann: So kann es z.B. sinn-voll sein, kritische Teilsysteme zur Minimierung desEntwicklungsrisikos fast bis zur Serienreife zu brin-gen, bevor mit der Entwicklung des davon abhängi-gen komplexen Gesamtsystems begonnen wird.

Prozessbausteine für wiederkehrende Arbeits-schritte: Die Bearbeitung einzelner Teilschritte derauf der Grundlage des V-Modells erarbeiteten Pro-zessplanung orientiert sich am bereits erwähnten Pro-blemlösungszyklus. Für einige bei der Entwicklungmechatronischer Systeme immer wieder auftretende

3 Development methodology of mechatronics

3.1 ProcedureBoth the experiences of industrial practice and the re-sults of empirical design research from recent yearshave made it clear that there is no ”canonizable opti-mal form of the design process which the designercan follow in a fixed schedule“ [Dör94]. In order toallow for this realization also in the development ofmechatronic systems, within this guideline there isproposed a more flexible procedural model, which issupported essentially on three elements:

• general problem-solving cycle on the micro-level

• V model on the micro-level• predefined process modules for handling recurrent

working steps in the development of mechatronicsystems

Problem-solving cycle as a micro-cycle: The struc-turing of the procedure in the development processtakes place in this case on the basis of a general prob-lem-solving cycle, such as that known for examplefrom systems engineering [DH94]. By arranging pro-cedural cycles in series and one within the other,process planning can be flexibly adapted to the pecu-liarities of any development task. The presented mi-cro-cycle is intended in particular to support the prod-uct developer engaged in the process to work onpredictable, and consequently plannable, subtasks,but also to solve suddenly occurring, unforeseeableproblems.

The V model as a macro-cycle: A guide for the ba-sic procedure is offered by the V model adopted fromsoftware development and adapted to the require-ments of mechatronics; it describes the logical se-quence of important substeps in the development ofmechatronic systems [Brö95; FKM00]. When usingthis model in practice, it must be taken into accountthat the time sequence of the substeps may deviatefrom the logical sequence: for example, to minimizethe development risk, it may be advisable to bringcritical subsystems almost up to readiness for massproduction before commencing development of thecomplex overall system dependent on it.

Process modules for recurrent working steps: Thehandling of individual substeps of the process plan-ning worked out on the basis of the V model is gov-erned by the already mentioned problem-solving cy-cle. However, for some mechatronic systems that arein development for recurring defined tasks, handling

Lizenzierte Kopie von elektronischem Datenträger

BA178AF3EC677050DBAC9B8DA5349567ADC990EEFF93F3A44AE34EFEE3FD05986DFD490D91F8479383AF68BF4E578DD1A00B89B15CDC6A1BE27A76EB69973498797498B84A6336A2542F000E0DBC256BF9A67937B5B3BF96E36572C95F945324F309BC9AAE8BC7AFA055B036AA99A702

A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49

Alle Rechte vorbehalten © Verein Deutscher Ingenieure, Düsseldorf 2004 VDI 2206 – 27 –

Aufgabenstellungen kann die Bearbeitung jedochkonkreter in Form von teilweise vordefinierten Pro-zessbausteinen beschrieben werden. In dieser Richt-linie werden Prozessbausteine für Systementwurf,Modellbildung und -analyse, domänenspezifischerEntwurf, Systemintegration und Eigenschaftsab-sicherung beschrieben.

Die funktionale und räumliche Integration von me-chanischen und elektrischen/elektronischen Kompo-nenten in mechatronischen Produkten erfordert diemöglichst frühzeitige Betrachtung der in Frage kom-menden Fertigungstechnologien und die entspre-chende Planung des Herstellprozesses. Produkt- undProduktionsentwicklung sind daher im engen Wech-selspiel vorzunehmen. Darauf wird in Ab-schnitt 3.1.4 eingegangen.

3.1.1 Problemlösungszyklus als MikrozyklusDer hier vorgestellte Mikrozyklus der Handlungsor-ganisation (vgl. Bild 3-1) stammt aus dem SystemsEngineering und hat in Abwandlungen auch Eingangin andere Disziplinen wie z.B. Betriebswirtschaftoder Software Engineering gefunden.

Seine prinzipielle Gültigkeit zur Planung und Durch-führung effektiven Problemlösungsverhaltens wurdedabei auch von psychologischer Seite immer wiederbestätigt [KOV86; Dör89]. Er umfasst folgendeSchritte:

Situationsanalyse bzw. Zielübernahme: Am Be-ginn eines elementaren Handlungszyklus steht entwe-der die Situationsanalyse oder die Zielübernahme.Die handelnde Gruppe bzw. das Individuum könnenein extern vorgegebenes Ziel übernehmen, woran sicheine Situationsanalyse anschließt (Soll-Zustand-orientiertes Vorgehen) oder nach der Analyse einerzunächst unklaren Situation selbstständig das Zielformulieren (Ist-Zustand-orientiertes Vorgehen).

Analyse und Synthese: Vor dem Hintergrund vonSituationsanalyse und Zielformulierung findet dieSuche nach Lösungen für das gegebene Problemstatt. Dieser Prozess stellt sich in der Praxis als einpermanentes Wechselspiel von Synthese- und Analy-seschritten dar, die die Produktentwickler zum Teilbewusst, zum Teil aber auch unbewusst durchführen.Ziel dieses Teilschritts ist es, alternative Lösungsva-rianten zu erarbeiten. Bei der Lösungssuche könnenselbstverständlich zusätzliche Aspekte des Problemserkannt werden, die einen Rücksprung zu Situations-analyse und Zielformulierung notwendig machenoder als ergänzende Kriterien in den nachfolgendenBewertungsschritt mit einfließen müssen.

can be described in more concrete terms in the formof partly predefined process modules. In this guide-line, process modules for system design, modelingand model analysis, domain-specific design, systemintegration and assurance of properties are described.

The functional and spatial integration of mechanicaland electrical/electronic components in mechatronicproducts requires the earliest possible considerationof the production technologies coming into consider-ation and the corresponding planning of the manufac-turing process. Product and production developmentare therefore to be performed in close cooperation.This is dealt with a Section 3.1.4.

3.1.1 Problem-solving cycle as a micro-cycleThe micro-cycle of the handling organization pre-sented here (cf. Figure 3-1) originates from systemsengineering and has also been adopted in modifiedforms in other disciplines, such as for example busi-ness management or software engineering.

Its validity in principle for the planning and imple-mentation of effective problem-solving behavior hasin this way been confirmed over and again, includingfrom a psychological aspect [KOV86; Dör89]. Itcomprises the following steps:

Situation analysis or adoption of a goal: at the be-ginning of an elementary handling cycle there is ei-ther the situation analysis or the adoption of a goal.The acting group or individual can adopt an exter-nally prescribed goal, which is followed by a situa-tion analysis (procedure governed by the desiredstate), or, following the analysis of an initially unclearsituation, itself formulate the goal (procedure gov-erned by the actual situation).

Analysis and synthesis: The search for solutions tothe given problem takes place against the backgroundof situation analysis and objective. This process takesthe form in practice of a permanent alternation be-tween synthesis steps and analysis steps which theproduct developers carry out partly consciously,partly also subconsciously. The aim of this substep isto work out alternative solution variants. In the searchfor a solution, it is of course possible to identify addi-tional aspects of the problem which necessitate a re-turn to situation analysis and objective or have to beincluded in the subsequent assessment step as supple-mentary criteria.



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Analyse und Bewertung: Die im Verlauf derLösungssuche konkretisierten Lösungsvarianten wer-den im Anschluss einer detaillierten Evaluation unter-zogen. Hierzu werden die Eigenschaften der einzelnenTeil- bzw. Gesamtlösungsvarianten anhand der an siegestellten Anforderungen analysiert. Dies kann z.B.durch Berechnung, Simulation, Versuch etc. erfolgen.Unterscheiden sich dabei einzelne Lösungsansätze inihrem Konkretisierungsgrad zu stark, um vergleichendbewertet werden zu können, sollte auch hier ein Rück-schritt zur Lösungssuche erfolgen. Die Bewertung derLösungsvarianten erfolgt dabei auf Grundlage der imRahmen von Zielformulierung und Lösungssuche de-finierten Bewertungskriterien. Als Ergebnis der Be-wertung sollte ein Vorschlag oder eine Empfehlung füreine oder mehrere Lösungsalternativen das Fällen ei-ner Entscheidung vorbereiten.Entscheidung: Mit der Entscheidung muss festge-stellt werden, ob der bisherige Verlauf der Problemlö-sung zu einem befriedigenden Ergebnis geführt hat. Istdas nicht der Fall, muss zur Situationsanalyse undZielformulierung zurückgekehrt werden. Andernfallserfolgt eine Entscheidung für eine, vielleicht auchmehrere Lösungsalternativen, die zur Grundlage derweiteren Planung gemacht werden sollen.Planen des weiteren Vorgehens bzw. Lernen: DiePlanung des weiteren Vorgehens wird in vielen Fällen

Analysis and assessment: The solution variants con-cretized in the course of the search for a solution aresubsequently subjected to a detailed evaluation. Forthis purpose, the properties of the individual variants ofa part solution or overall solution are analyzed on thebasis of the requirements imposed on them. This cantake place for example by calculation, simulation, ex-perimentation, etc. If individual approaches to a solu-tion differ too much in their degree of concretization toallow comparative assessment, a return should also bemade here to the search for a solution. The assessmentof the solution variants in this case takes place on thebasis of the assessment criteria defined during the for-mulation of a goal and search for a solution. As a resultof the assessment, a proposal or recommendation forone or more alternatives for a solution should preparethe way for a decision to be taken.Decision: With the decision, it must be establishedwhether the previous procedure for problem-solvinghas led to a satisfactory result. If this is not the case, areturn must be made to the situation analysis and for-mulation of a goal. Otherwise, a decision is made on analternative for a solution, perhaps even more than onealternative, which is or are to be made the basis of fur-ther planning.Planning the further procedure or learning: Theplanning of the further procedure will in many cases

Bild 3-1. Problemlösungszyklus als Mikrozyklus, nach [DH94] Fig. 3-1. Problem-solving cycle as a micro-cycle, according to[DH94]



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


mehr oder weniger fließend in weitere Problem-lösungszyklen einmünden und auf diese Weise zueinem effizienten, situationsangepassten Prozessver-lauf führen. Neben der rein operativen Bewertung desHandlungsergebnisses sollte am Ende jedes Mikro-zyklus jedoch auch kurz innegehalten werden, um so-wohl das Ergebnis als auch den Prozessablauf einerallgemeinen kritischen Betrachtung zu unterziehen.Indem nachvollzogen wird, was am jeweiligen Pro-zessablauf und dem Ergebnis gut und was wenigergut war bzw. ist, lässt sich verfügbares Wissen fürkommende Entwicklungsaufgaben generieren. Aufdiese Weise können zukünftige Prozessabläufe syste-matisch verbessert werden.

3.1.2 V-Modell als MakrozyklusDas V-Modell beschreibt das generische Vorgehenbeim Entwurf9) mechatronischer Systeme, das fall-weise auszuprägen ist (Bild 3-2).

Anforderungen: Ausgangspunkt bildet ein konkre-ter Entwicklungsauftrag. Die Aufgabenstellungwurde präzisiert und in Form von Anforderungen be-schrieben. Diese Anforderungen bilden zugleich denMaßstab, anhand dessen das spätere Produkt zu be-werten ist.

Systementwurf: Ziel ist die Festlegung eines domä-nenübergreifenden Lösungskonzepts, das die wesent-lichen physikalischen und logischen Wirkungsweisen

9) Unter Entwurf wird „die Erahnung eines Ganzen, eines Lösungskon-zepts, das Erkennen bzw. Finden der dazu erforderlichen Lösungsele-mente und das gedankliche, modellhafte Zusammenfügen undVerbinden dieser Elemente zu einem tauglichen Ganzen“ verstanden[DH94, S. 158]. Diese Vorstellung umfasst auch das so genannte Kon-zipieren und weicht damit von der im Maschinenbau eingeführten Ter-minologie ab. Das Entwerfen ist demnach ein Vorgang, der ausgehendvon den Anforderungen zu einer Konkretisierung eines technischenSystems führt. Diese Konkretisierung drückt sich in Komponenten derMechatronik sowie dem Zusammenwirken dieser Komponenten aus.

run more or less smoothly into further problem-solv-ing cycles and in this way lead to an efficient processprocedure that is adapted to the situation. Apart fromthe purely operative assessment of the handling re-sult, there should however also be a brief pause at theend of each micro-cycle, in order to subject both theresult and the process sequence to a general criticalappraisal. By examining what was or is good aboutthe respective process sequence and the result andwhat was or is less good, available knowledge can begenerated for forthcoming development tasks. In thisway, future process sequences can be systematicallyimproved.

3.1.2 V model as a macro-cycleThe V model describes the generic procedure for de-signing9) mechatronic systems, which is to be given amore distinct form from case to case (Figure 3-2).

Requirements: The starting point is formed by anactual development order. The defined object wasspecified more precisely and described in the form ofrequirements. These requirements at the same timeform the measure against which the later product is tobe assessed.System design: The aim is to establish a cross-domainsolution concept which describes the main physicaland logical operating characteristics of the future prod-

9) A design is understood as meaning ”the conceiving of a whole, asolution concept, the identifying or finding of the solution elementsrequired for this and the intellectual, model-based joining together andconnecting of these elements to form a workable whole“ [DH94,p. 158). This idea also includes the so-called conceptual design andconsequently deviates from the terminology introduced in mechanicalengineering. Designing is accordingly a process which, starting fromthe requirements, leads to a concretization of a technical system. Thisconcretization is expressed in components of mechatronics and theinteraction of these components.

Bild 3-2. V-Modell als Makrozyklus Fig. 3-2. V model as a macro-cycle



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


des zukünftigen Produktes beschreibt. Hierzu wird dieGesamtfunktion eines Systems in wesentliche Teil-funktionen zerlegt. Diesen Teilfunktionen werden ge-eignete Wirkprinzipien bzw. Lösungselemente zuge-ordnet und die Funktionserfüllung wird im Systemzu-sammenhang geprüft. Domänenspezifischer Entwurf: Auf der Basis diesesgemeinsam entwickelten Lösungskonzepts erfolgt dieweitere Konkretisierung meist getrennt in den beteilig-ten Domänen. Detailliertere Auslegungen und Berech-nungen sind nötig, um insbesondere bei kritischenFunktionen die Funktionserfüllung sicherzustellen.Systemintegration: Die Ergebnisse aus den einzelnenDomänen werden zu einem Gesamtsystem integriert,um das Zusammenwirken untersuchen zu können.Eigenschaftsabsicherung: Der Entwurfsfortschrittmuss fortlaufend anhand des spezifizierten Lösungs-konzepts und der Anforderungen überprüft werden. Esist sicherzustellen, dass die tatsächlichen mit den ge-wünschten Systemeigenschaften übereinstimmen. Modellbildung und -analyse: Die beschriebenenPhasen werden flankiert durch die Abbildung und Un-tersuchung der Systemeigenschaften mit Hilfe vonModellen und rechnerunterstützten Werkzeugen zurSimulation. Produkt: Ergebnis eines durchlaufenen Makrozyklusist das Produkt. Dabei wird unter Produkt nicht aus-schließlich das fertige, real existierende Erzeugnis ver-standen, sondern die zunehmende Konkretisierung deszukünftigen Produktes (Produktreife). Reifegrade sindz.B. das Labormuster, das Funktionsmuster, das Vor-serienprodukt etc. Ein komplexes mechatronisches Erzeugnis entsteht inder Regel nicht innerhalb eines Makrozyklus.Vielmehr sind mehrere Durchläufe erforderlich(Bild 3-3). In einem ersten Zyklus werden beispielsweise dasProdukt funktional spezifiziert, erste Wirkprinzi-pien10) und/oder Lösungselemente11) ausgewählt undgrobdimensioniert, im Systemkontext auf Konsistenzgeprüft und exemplarisch realisiert. Ergebnis ist in der

10) „Das Wirkprinzip bezeichnet den Zusammenhang von physika-lischem Effekt sowie geometrischen und stofflichen Merkmalen (Wirk-geometrie, Wirkbewegung und Werkstoff). Es lässt das Prinzip derLösung zur Erfüllung einer Teilfunktion erkennen“. [PB97]11) „Ein Lösungselement ist eine realisierte und bewährte Lösung zurErfüllung einer Funktion. Dabei handelt es sich im Allgemeinen umein Modul/eine Baugruppe, das/die auf einem Wirkprinzip beruht. Dierechnerinterne Repräsentation eines Lösungselementes besteht ausunterschiedlichen Aspekten wie Verhalten und Gestalt. Jeder dieserAspekte weist unterschiedliche Konkretisierungen auf, die den Phasendes Entwicklungsprozesses entsprechen. Der Aspekt Gestalt enthältgrobe Festlegungen für die Bestimmung der prinzipiellen Lösung undweitergehende Festlegungen für die Bestimmung der Baustruktur. DerAspekt Verhalten weist für den Fall von Software beispielsweise fürdie frühen Entwicklungsphasen abstrakte Datentypen und für die spä-tere Entwicklungsphase Code auf“. [GEK01]

uct. For this purpose, the overall function of a system isbroken down into main subfunctions. These subfunc-tions are assigned suitable operating principles or solu-tion elements and the performance of the function istested in the context of the system.

Domain-specific design: On the basis of this jointlydeveloped solution concept, further concretizationusually takes place separately in the domains involved.More detailed interpretations and calculations are nec-essary to ensure the performance of the function, inparticular in the case of critical functions.System integration: The results from the individualdomains are integrated to form an overall system, to al-low the interaction to be investigated.Assurance of properties: The progress made with thedesign must be continually checked on the basis of thespecified solution concept and the requirements. Itmust be ensured that the actual system properties coin-cide with the desired system properties.Modeling and model analysis: the phases describedare flanked by the forming and investigating of the sys-tem properties with the aid of models and computer-aided tools for simulation.

Product: The result of a continuous macro-cycle is theproduct. In this case, a product is understood as mean-ing not exclusively the finished, actually existing prod-uct but the increasing concretization of the future prod-uct (product maturity). Degrees of maturity are, forexample, the laboratory specimen, the functional spec-imen, the pilot-run product, etc.A complex mechatronic product is generally not pro-duced within one macro-cycle. Rather, a number of cy-cles are required (Figure 3-3).

In a first cycle, for example, the product is functionallyspecified, first operating principles10) and/or solu-tion elements11) are selected and roughly dimen-sioned, checked for consistency in the system contextand realized in an exemplary form. The result is gener-

10) ”The operating principle refers to the interrelationship betweenphysical effect and geometrical and material-related features (effectivegeometry, effective movement and material). It allows the principle ofthe solution for performing a subfunction to be identified“. [PB97]11) ”A solution element is a realized and tried-and-tested solution forperforming a function. It is generally a module/subassembly which isbased on an operating principle. The computer-internal representationof a solution element comprises different aspects such as behavior andform. Each of these aspects has different concretizations, which corres-pond to the phases of the development process. The aspect of formcomprises rough stipulations for determining the solution in principleand more specific stipulations for determining the building structure.The aspect of behavior has for the case of software, for example, ab-stract data types for the early development phases and code for the laterdevelopment phase“. [GEK01]



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Regel ein Labormuster. Dies wird in einem zweitenZyklus weiter konkretisiert (Feindimensionierung derLösungselemente, Verhaltens- und Gestaltsimulation),um erste Funktionsmuster zu erstellen. Je nach Ent-wurfsfortschritt, Art und Komplexität der Entwick-lungsaufgabe sind gegebenenfalls weitere Makrozyk-len erforderlich, um zum serienreifen Produkt zu ge-langen. Die Anzahl der Makrozyklen und die zudurchlaufenden Teilschritte im V-Modell hängen vonder spezifischen Entwicklungsaufgabe ab.

ally a laboratory specimen. This is further concretizedin a second cycle (fine dimensioning of the solution el-ements, simulation of behavior and form), in order tocreate a first functional specimen. Depending on theprogress made with the design and the type and com-plexity of the development task, further macro-cyclesmay be required to arrive at the product that is readyfor mass production. The number of macro-cycles andthe substeps to be run through in the V model dependon the specific development task.

Bild 3-3. Durchlaufen mehrerer Makrozyklen mit zunehmender Produktreife

Fig. 3-3. Running through a number of macro-cycles with increasing product maturity



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


3.1.3 Prozessbausteine für wiederkehrende Arbeitsschritte

Einige Teilschritte, die beim Entwurf mechatroni-scher Systeme immer wieder auftreten, können kon-kreter in Form von teilweise vordefinierten Prozess-bausteinen beschrieben werden. Im Folgenden wer-den die Prozessbausteine Systementwurf, Modellbil-dung und -analyse, domänenspezifischer Entwurf,Systemintegration und Eigenschaftsabsicherung er-läutert.

SystementwurfDer Systementwurf beginnt mit dem Abstrahierender in der Anforderungsliste beschriebenen Vorstel-lungen. Vorfixierungen, die den möglichen Lösungs-raum unnötig einschränken, sollen dadurch vermie-den werden. Ziel ist es, das Wesentliche und Allge-meingültige der Problemstellung herauszuarbeiten.Dies wird z.B. erreicht durch Reduktion der Anfor-derungsliste auf wesentliche Aussagen und die lö-sungsneutrale Formulierung des Problems [PB97].

Aufstellen der Funktionsstruktur: Aus der Pro-blemspezifikation wird die Gesamtfunktion abge-leitet (vgl. Bild 3-4). Sie stellt die Zielfunktion fürdas Verhalten des Systems unter seinen Einsatzbedin-gungen dar. Die Einsatzbedingungen bilden die Ein-gangsgrößen, die Ausgangsgrößen beschreiben dasgewünschte Verhalten. Mit Hilfe der allgemeinenFlussgrößen Stoff, Energie und Information (vgl. Ab-

3.1.3 Process modules for recurrent working steps

Some substeps which keep recurring when designingmechatronic systems can be described in a more con-crete way in the form of partly predefined processmodules. The process modules of system design,modeling and model analysis, domain-specific de-sign, system integration and assurance of propertiesare explained below.

System designThe system design begins with the abstraction of theideas described in the requirements list. This is in-tended to avoid prefixed elements which possibly re-strict the solution space. The aim is to work out whatis essential and generally applicable in respect of thesetting of the problem. This is achieved for exampleby reduction of the requirements list to essentialstatements and solution-neutral formulation of theproblem [PB97].

Setting up the function structure: the overall func-tion is derived from the problem specification (cf.Figure 3-4). It represents the target function for thebehavior of the system under its operating conditions.The operating conditions form the input variables, theoutput variables describe the desired behavior. Withthe aid of the general flow variables of material, en-ergy and information (cf. Section 2.2.1), and block

Bild 3-4. Tätigkeiten beim Systementwurf, nach [KBS97; PB 97] Fig. 3-4. Activities in system design, according to [KBS97;PB 97]



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


schnitt 2.2.1) und der Blockdarstellung kann der Zu-sammenhang zwischen Eingangs- und Ausgangs-größen spezifiziert werden. In der Regel ist die zu lö-sende Aufgabe zu komplex, um unmittelbar aus derGesamtfunktion die technische Realisierung ableitenzu können. Deshalb ist eine Aufgliederung der Ge-samtfunktion in Teilfunktionen vorzunehmen. Teil-funktionen mechatronischer Systeme sind z.B. An-treiben, Steuern/Regeln, Messen, Übertragen etc. DieTeilfunktionen werden wiederum über Stoff-, Ener-gie- und Informationsflüsse zur Funktionsstrukturverknüpft, um das Verhalten zu beschreiben und früh-zeitig Inkonsistenzen zu erkennen. Ziel ist, die Funk-tionsstruktur so weit zu detaillieren, bis es gelingt,Wirkprinzipien und Lösungselemente zur Erfüllungder Teilfunktionen zu finden. Wenn dies für eine Teil-funktion nicht möglich erscheint, dann ist die Teil-funktion weiter aufzugliedern. Dies erfolgt als Wech-selspiel von Analyse- und Syntheseschritten (vgl.Abschnitt 3.1.1). So genannte „kanonische Funktio-nen“ stellen einen neuen Lösungsansatz dar, um denbeschriebenen Übergang von den abstrakten allge-meinen Fluss- und Funktionsgrößen zu geeignetenmechatronischen Lösungsprinzipien zu unterstützen.Kanonische Funktionen bestehen aus einem Satz vondomänenunabhängigen Funktionsverben und Funkti-onsgrößen. Zur Konkretisierung einer kanonischenFunktionsgröße steht jeweils nur eine physikalischeGröße aus jeder Domäne zur Auswahl. Dies erleich-tert die weitere Spezifikation. Zur Vertiefung der ka-nonischen Funktionen wird auf [Hua02] verwiesen.

Suche nach Wirkprinzipien und Lösungs-elementen zur Erfüllung von Teilfunktionen: Fürdie einzelnen Teilfunktionen werden geeignete Wirk-prinzipien und Lösungselemente gesucht. Die Erfül-lung einer Teilfunktion kann nicht immer als 1 : 1-Beziehung mit einem Wirkprinzip/Lösungselementrealisiert werden; vielmehr bestehen polyhier-archische Erfüllungsbeziehungen [Rot00]. Dies istz.B. bei tragenden Lösungselementen wie dem Ge-häuse der Fall, welches mehrere Teilfunktionen (Be-festigen, Tragen, Dichten etc.) erfüllt. Die Suche undZuordnung erfolgt in einem iterativen Prozess unterBerücksichtigung der Nutz- und Störfunktionen undder Kompatibilitätsbedingungen. Der Prozess wird solange fortgesetzt, bis alle Teilfunktionen durchgeeignete Wirkprinzipien und/oder Lösungselementeerfüllt werden [KBS97]. Kataloge (Kataloge fürphysikalische Effekte und Wirkprinzipien z.B.[Rot00], Produktkataloge) und elektronische Markt-plätze (z.B. CompoNET12) erleichtern die Suche.Zum Erfüllen der Gesamtfunktion werden die Wirk-

12) CompoNET: Online-Marktplatz für Zulieferkomponenten; http://www.CompoNET.de

representation, the interrelationship between inputvariables and output variables can be specified. Thetask to be solved is generally too complex to allow thetechnical realization to be derived directly from theoverall function. Therefore, the overall function hasto be divided up into subfunctions. Subfunctions ofmechatronic systems are, for example, driving, open-closed-loop control, measurement, transmission, etc.The subfunctions are in turn linked via material, en-ergy and information flows to form the functionstructure, to describe the behavior and detect incon-sistencies at an early time. The aim is to detail thefunction structure to the extent required to find oper-ating principles and solution elements for performingthe subfunctions. If this does not appear to be possi-ble for a subfunction, the subfunction has to be di-vided up further. This takes place as an alternation ofanalysis steps and synthesis steps (cf. Section 3.1.1).So-called canonical functions represent a new solu-tion approach, to support the described transitionfrom the abstract general flow and function variablesto suitable mechatronic solution principles. Canoni-cal functions comprise a set of domain-independentfunction verbs and function variables. For concretiz-ing a canonical function variable, only one physicalvariable from each domain is respectively availablefor selection. This makes further specification easier.For more on the canonical functions, you are referredto [Hua02].

Search for operating principles and solution ele-ments for performing subfunctions: For individualsubfunctions, suitable operating principles and solu-tion elements are sought. The performance of a sub-function cannot always be realized as a 1 : 1 relation-ship with an operating principle/solution element;rather, there are polyhierarchical performance rela-tionships [Rot00]. This is the case for example withsupporting solution elements such as the housing,which performs several subfunctions (fastening, sup-porting, sealing, etc.). The search and assignmenttakes place in an iterative process, taking the benefi-cial and disturbing functions and the compatibilityconditions into consideration. The process is contin-ued until all the subfunctions are satisfied by suitableoperating principles and/or solution elements[KBS97]. Catalogs (catalogs for physical effects andoperating principles, for example [Rot00], productcatalogs) and electronic market places (for exampleCompoNET12) make the search easier. To performthe overall function, the operating principles/solution

12) CompoNET: online market place for supplier components;http://www.CompoNET.de



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


prinzipien/Lösungselemente (über Stoff-, Energie-und Informationsflüsse) zur Wirkstruktur13)verknüpft. Ziel ist, die physikalischen Verträglich-keiten zwischen den Wirkprinzipien/Lösungsele-menten zu erkennen und einen störungsfreien Stoff-,Energie- und Informationsfluss sicherzustellen. Viel-fach ist die alleinige Wirkstruktur aber noch zu wenigkonkret, um das Lösungsprinzip beurteilen zu kön-nen. Die Wirkstruktur muss z.B. durch überschlägigeBerechnung oder Grobdimensionierung der Geomet-rie quantifiziert werden. Die weitere Konkretisierungder Wirkstruktur führt zur Baustruktur14). Mit ihrerHilfe werden die Verträglichkeiten zwischen denWirkprinzipien/Lösungselementen in Bezug auf dieGestalt (insbesondere bei räumlicher Integration)überprüft. Die Lösungselemente sind ferner in einStütz- und Hüllsystem einzubetten, das die funk-tionsgerechte Anordnung der Elemente und ihrZusammenwirken sicherstellt. Zur Optimierung derBaustruktur hinsichtlich Integrationsgrad, Vermei-dung von Störfunktionen etc. sind Gestaltungsprin-zipien wie z.B. die Integral- und Differentialbau-weise15) anzuwenden.

Konkretisieren zu prinzipiellen Lösungsvarian-ten: Die erarbeiteten Vorstellungen für eine Lösungsind in der Regel noch nicht konkret genug, um dasendgültige domänenübergreifende Konzept festzule-gen und den Entwurf in den beteiligten Fachdiszi-plinen fortsetzen zu können. Es sind weitere Aspektewie Störanfälligkeit, Gewicht, Lebensdauer etc. zuberücksichtigen. Zur Informationsgewinnung dienenu.a. orientierende Berechnungen (Finite-Elemente-Methode (FEM), Analyse von Mehrkörpersystemen(MKS); vgl. Abschnitt 3.3), skizzenhafte Gestal-tungsstudien, Bau von Anschauungsmodellen. DieWirkprinzipien und Lösungselemente werden auf derBasis der neugewonnenen Informationen so weitkonkretisiert bis prinzipielle Lösungsvarianten derAufgabenstellung erkennbar sind. Diese werdeneiner abschließenden Bewertung nach technischenund wirtschaftlichen Kriterien unterzogen.

13) Wirkstruktur: Die Kombination mehrerer Wirkprinzipien/Lösungs-elemente führt zur Wirkstruktur einer Lösung. In ihr wird das Zusam-menwirken mehrerer Wirkprinzipien/Lösungselemente und damit dasLösungsprinzip zum Erfüllen der Gesamtaufgabe erkennbar [PB97].

14) Baustruktur: Sie berücksichtigt die räumlichen Zusammenhängeund die Anforderungen der Fertigung, der Montage etc. In ihr werdenBauräume, später Bauteile und Baugruppen mit ihren zugehörigen Ver-bindungen festgelegt, die das konkrete Erzeugnis darstellen [PB97].15) Integralbauweise: Vereinigen mehrerer Einzelkomponenten zueinem Bauteil bzw. zu einem heterogenen System durch Funktionsinte-gration. Gründe: Bauraumverkleinerung, Gewichtsersparnis, Vermei-dung von Schnittstellen etc. Differentialbauweise: Auflösung einer Einzelkomponente in mehrereBestandteile durch Funktionstrennung. Gründe: Funktionssicherheit,Verfügbarkeit von Standardkomponenten, erleichterte Herstellung undWartung etc. [PB97]

elements are linked (via material, energy and infor-mation flows) to form the operating structure13).The aim is to identify the physical compatibilities be-tween the operating principles/solution elements andensure a trouble-free material, energy and informa-tion flow. Often, however, the operating structurealone is still insufficiently concrete to allow the solu-tion principle to be assessed. The operating structuremust be quantified for example by approximate cal-culation or rough dimensioning of the geometry. Thefurther concretization of the operating structure leadsto the building structure14). With its aid, the com-patibilities between the operating principles/solutionelements are checked with respect to the form (in par-ticular in the case of spatial integration). The solutionelements are also to be embedded in a supportingand enveloping system, which ensures the function-ally appropriate arrangement of the elements andtheir interaction. For optimizing the building struc-ture with regard to degree of integration, avoidance ofdisturbing functions etc., creation principles, such asfor example the integral and differential methodsof construction15) are to be applied.

Concretizing to form solution variants in princi-ple: The ideas worked out for a solution are generallynot concrete enough to stipulate the final cross-do-main concept and allow the design to be continued inthe technical disciplines involved. Further aspectssuch as fault susceptibility, weight, service life, etc.must be taken into consideration. Among the meansof obtaining information are orienting calculations(Finite Element Method (FEM), analysis of multi-body systems (MBS); cf. Section 3.3), outlined crea-tion studies, building of viewing models. The operat-ing principles and solution elements are concretizedon the basis of the newly obtained information untilsolution variants in principle of the defined object canbe identified. These are subjected to a final assess-ment on the basis of technical and commercial crite-ria.

13) Operating structure: The combination of a number of operatingprinciples/solution elements leads to the operating structure of a solu-tion. In it, the interaction of a number of operating principles/solutionelements, and consequently the solution principle for performing theoverall task, can be identified [PB97].14) Building structure: It takes into consideration the spatial interrelation-ships and the requirements of production, assembly, etc. Defined in it areinstallation spaces, later components and subassemblies with their asso-ciated connections, which represent the concrete product [PB 97].15) Integral method of construction: Unifying a number of individualcomponents to form a component or a heterogeneous system by func-tion integration. Reasons: reducing size of installation space, savingweight, avoiding interfaces, etc.Differential method of construction: Resolving an individual compo-nent into a number of constituent parts by function separation.Reasons: functional reliability, availability of standard components,facilitated manufacture and maintenance, etc. [PB97]



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Ergebnis des Systementwurfs ist ein domänenüber-greifendes Lösungskonzept, das die wesentlichenphysikalischen und logischen Wirkungsweisen deszukünftigen Produkts und die Art und Anordnungseiner Komponenten beschreibt.

Modellbildung und -analyseMechatronische Systeme sollten auf Grund ihrerkomplexen Struktur und des domänenübergreifendenCharakters im Rechner abgebildet werden. Ohne dieModellbildung des Gesamtverhaltens ist die Komple-xität mechatronischer Produkte nicht zu beherrschen.Die Modellierung und Analyse des Systems ge-schieht unter den Aspekten Dynamik, Erwärmung,Streufelder, Schwingungs-Geräusch-Simulation etc.Bei der Modellbildung und -analyse sind einige Be-sonderheiten zu beachten, die genauer in Ab-schnitt 3.2 beschrieben werden.

Domänenspezifischer EntwurfBei der Zuordnung von Wirkprinzipien und Lösungs-elementen zu Teilfunktionen erfolgt in der Regel einePartitionierung, das heißt eine Aufteilung der Funkti-onserfüllung unter den beteiligten Domänen. Der Be-griff Partitionierung ist im Hardware/Software-Code-sign eingeführt worden [Buc01]. Die Entwicklung inden relevanten Domänen erfolgt auf der Basis etab-lierter, domänenspezifischer Entwicklungsmethodi-ken, die durch eigene Denkweisen, Begriffsweltenund Erfahrungen geprägt sind. Zur Vertiefung wirdauf die jeweilige Literatur verwiesen: u.a. Maschi-nenbau (VDI 2221); Softwaretechnik: Phasenmo-delle [Pre94; Bei95], Wasserfallmodell [PB96],V-Modell [Brö95; Ver94], Spiralmodell [Boe88],Unified Modeling Language (UML) [Oes98]; Digi-talelektronik: Abstraktionsebenen [BGH96; Arm89],Phasenmodell [Esc93]. Einen umfassenden Über-blick liefert auch [GEK01].

SystemintegrationUnter Systemintegration wird der Zusammenschlussvon Teilen (Funktionen, Komponenten, Teilsysteme)zu einem übergeordneten Ganzen (zukünftiges Pro-dukt repräsentiert je nach Reifegrad als z.B. Labor-muster, Funktionsmuster, Vorserienprodukt) verstan-den. Entsprechend der Aufgabenstellung ist die ge-eignete Art der Integration zu wählen. Integrationsar-ten sind z.B. [KZB01]:

• Integration verteilter Komponenten: Kompo-nenten wie Aktoren, Sensoren und Leistungsstell-glieder werden über Signal- und Energieflüssemiteinander verbunden. Die Verarbeitung derSignale erfolgt mit Hilfe von Kommunikations-systemen (z.B. Sensor-Aktor-Bus, Feldbus etc.),

The result of the system design is a cross-domain so-lution concept, which describes the main physicaland logical operating characteristics of the futureproduct and the type and arrangement of its compo-nents.

Modeling and model analysisOn account of their complex structure and cross-do-main character, mechatronic systems should be de-picted in a computer. Without modeling the entire be-havior, it is not possible to deal with the complexityof mechatronic products. The modeling and analysisof the system takes place from the aspects of dynam-ics, heating, stray fields, vibration-noise simulation,etc. In modeling and model analysis, it is necessary totake into account some special aspects, which are de-scribed in more detail in Section 3.2.

Domain-specific designWhen assigning operating principles and solution el-ements to subfunctions, a partitioning is generallyperformed, i.e. dividing of the performance of thefunction among the domains involved. The term par-titioning has been introduced in hardware/softwarecodesign [Buc01]. The development in the relevantdomains takes place on the basis of established, do-main-specific development methodologies, which arecharacterized by their own ways of thinking, concep-tual ranges and experiences. For more, you are re-ferred to the respective literature: including mechan-ical engineering (VDI 2221); software technology:phase models [Pre94; Bei95], waterfall model[PB96], V model [Brö95; Ver94], spiral model[Boe88], Unified Modeling Language (UML)[Oes98]; digital electronics: abstraction levels[BGH96; Arm89], phase model [Esc93]. A compre-hensive overview is also provided by [GEK01].

System integrationSystem integration is understood as meaning thebringing together of parts (functions, components,subsystems) to form a superordinate whole (futureproduct represented according to degree of maturityas, for example, laboratory specimen, functionalspecimen, pilot-run product). The suitable type of in-tegration is to be chosen in accordance with the de-fined object. Types of integration are, for example[KZB01]:

• Integration of distributed components: Compo-nents such as actors, sensors and power actuatorsare connected to one another via signal and energyflows. The processing of the signals takes placewith the aid of communication systems (for ex-ample sensor-actor bus, field bus, etc.), that of the



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


die der Energieflüsse über Verkabelung undSteckverbinder. Vorteilhaft ist, dass Serienkompo-nenten verwendet werden können; Kabel- undSteckverbindungen bergen jedoch die Gefahr vonKontaktproblemen, Kabelbrüchen und Kurz-schlüssen insbesondere bei rauen Umgebungsbe-dingungen.

• Modulare Integration: Das Gesamtsystem setztsich aus Modulen definierter Funktionalität undstandardisierter Abmessungen in verschiedenenGrößenklassen zusammen. Die Kopplung erfolgtüber vereinheitlichte Schnittstellen wie z.B. DIN-Steckeranschluss, standardisierte stoff-, kraft-oder formschlüssige Verbindungen. Diese ineinem Baukastensystem enthaltenen Module kön-nen flexibel kombiniert werden und ermöglicheneine große Funktionsvielfalt. Modular integrierteSysteme weisen in der Regel auch ein größeresBauteilvolumen und höheren Material- und Bau-teilaufwand im Vergleich zu räumlich integriertenSystemen auf.

• Räumliche Integration: Alle Komponenten wer-den räumlich integriert und bilden eine komplexeFunktionseinheit, z.B. Integration aller Elementeeines Antriebssystems (Regler, Leistungsstell-glied, Motor, Übertragungselement, Wirkelement)in einem Gehäuse (siehe Beispiel „IntegrierterMehrkoordinatenantrieb“ in Abschnitt 4.4). Vor-teile sind u.a. ein kleinerer Bauraum, höhere Zu-verlässigkeit durch Reduktion der Schnittstellen,schnellere Datenübertragung/höhere Leistung undgeringerer Montageaufwand. Durch die räumlicheNähe der Komponenten können aber auch uner-wünschte Wechselwirkungen wie z.B. Erwär-mung, magnetische Streufelder, Schwingungen,Geräusche und Spannungsspitzen entstehen, diefrühzeitig zu berücksichtigen sind. ElektronischeKomponenten sind unter Umständen an das Ein-satzumfeld (Temperatur, Feuchtigkeit, Schwin-gungen etc.) anzupassen; zusätzliche Maßnahmenwie Kapselung oder Kühlung können erforderlichsein, um die Bauteilzuverlässigkeit sicherzustel-len. Räumliche Integration erfordert deshalb einsystematisches Vorgehen beim Entwurf, die früh-zeitige Beachtung des Gestaltungsprinzips Inte-gralbauweise (siehe Abschnitt 3.1.3 „Systement-wurf“) sowie die Unterstützung durch Modellbil-dung und IT-Werkzeuge.

Um einen hohen Integrationsgrad zu erreichen, sindbereits beim Systementwurf die Wirkprinzipien undLösungselemente unter Berücksichtigung der Nutz-und Störfunktionen auf Kompatibilität zu überprüfenund die Schnittstellen für die spätere Integration aus-zubilden (Grobdimensionierung). Während der Fein-

energy flows via cabling and plug-in connectors.It is advantageous that series components can beused; cable and plug-in connections entail therisk, however, of contact problems, cable breaka-ges and short-circuits, in particular under roughambient conditions.

• Modular integration: The overall system ismade up of modules of defined functionality andstandardized dimensions in various size classes.The coupling takes place via unified interfaces,such as for example a DIN plug and socket con-nection, standardized integral, nonpositive or po-sitive connections. These modules that are inclu-ded in a modular system can be flexibly combinedand make it possible to obtain great functional va-riety. Modularly integrated systems generally alsohave a larger component volume and higher mate-rial expenditure and component complexity incomparison with spatially integrated systems.

• Spatial integration: All components are spatiallyintegrated and form a complex functional unit, forexample integration of all elements of a drive sys-tem (controller, power actuator, motor, transferelement, operating element) into a housing (seefor example the ”Integrated multicoordinatedrive“ in Section 4.4). Advantages include a smal-ler installation space, greater reliability broughtabout by reduction of the interfaces, faster datatransmission/higher power and lower assembly ef-fort. However, the spatial proximity of the compo-nents also allows undesired interactions to arise,such as for example heating, stray magnetic fields,vibrations, noises and voltage peaks, which are tobe taken into consideration at an early time. Undersome circumstances, electronic components are tobe adapted to the operating environment (tempe-rature, humidity, vibrations, etc.); additionalmeasures such as encapsulation or cooling may berequired to ensure component reliability. Spatialintegration therefore requires a systematic proce-dure for design, early observance of the creationprinciple of an integral method of construction(see Section 3.1.3 ”System design“) and supportby modeling and IT tools.

To achieve a high degree of integration, the operatingprinciples and solution elements are to be checked forcompatibility, taking the beneficial and disturbingfunctions into consideration, and the interfaces for thelater integration (rough dimensioning) are to beformed already in the system design. During the fine



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


dimensionierung in den involvierten Fachdisziplinen(domänenspezifischer Entwurf) kann es jedoch zu Ver-änderungen der Wirkstruktur (durch Funktionsintegra-tion, Funktionstrennung etc.) und der Baustrukturkommen. Mögliche Inkompatibilitäten müssen des-halb bei der Systemintegration erkannt und eliminiertwerden (Bild 3-5).

Als Mittel bietet sich hier z.B. der MorphologischeKasten an [PB97]. Ein morphologischer Kasten ist einOrdnungsschema in Matrizenform. Den Zeilen wer-den die Teilfunktionen zugeordnet. In die Spalten wer-den die Lösungen (und gegebenenfalls die im Zuge desdomänenspezifischen Entwurfs gebildeten Varianten)eingetragen.

Zu den Lösungen werden in der Regel auch Informati-onen über deren Wechselwirkungen mit der Umge-bung abgelegt (Montagemöglichkeiten, Energie-,Stoff- und Informationsfluss, Versorgung etc.); dieseInformationen werden zur Verträglichkeitsbewertungder Lösungen benötigt.

Zur Integration des Gesamtsystems wird für jede Teil-funktion eine Lösung ausgewählt und alle Lösungenwerden zu einer Gesamtlösung verknüpft. Stehen miLösungen für die Teilfunktionen Fi zur Verfügung, er-hält man N = m1 · m2 ·...· mn theoretisch mögliche Ge-samtsystemvarianten. Durch Inkompatibilitäten ein-zelner Lösungen wird die Anzahl der Gesamtsystem-varianten meist deutlich eingeschränkt. Sind konsis-tente Gesamtsystemvarianten gefunden, muss aus die-sen die optimale Gesamtlösung ausgewählt werden.

dimensioning in the technical disciplines involved (do-main-specific design), however, there may be changesto the operating structure (due to function integration,function separation, etc.) and the building structure.Possible incompatibilities must therefore be detectedand eliminated during the system integration(Figure 3-5).

An example of a suitable means for this is the morpho-logical box [PB97]. A morphological box is an order-ing scheme in the form of a matrix. The subfunctionsare assigned to the rows. The solutions (and possiblythe variants formed in the course of the domain-spe-cific design) are entered in the columns.

Generally stored along with the solutions there is alsoinformation on their interactions with the environment(assembly possibilities, energy, material and informa-tion flow, supply, etc.); this information is required forthe compatibility assessment of the solutions.

For the integration of the overall system, a solution isselected for each subfunction and all the solutions areinterlinked to form an overall solution. If mi solutionsare available for the subfunctions Fi , thenN = m1 · m2 ·...· mn theoretically possible overall sys-tem variants are obtained. The number of overall sys-tem variants is usually greatly restricted by incompati-bilities of individual solutions. Once consistent overallsystem variants have been found, the optimum overallsolution must be selected from them.

Bild 3-5. Tätigkeiten bei der Systemintegration Fig. 3-5. Activities in system integration



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Im klassischen Maschinenbau liegt die Problematikder Systemintegration meist bei den gestaltbestim-menden Eigenschaften. Beim Entwurf mechatroni-scher Systeme sind vielfältige Wechselwirkungen(z.B. Verhalten, elektromagnetische Verträglichkeitetc.) zur Überprüfung der Verträglichkeiten zu berück-sichtigen. Neben dem Einsatz von IT-Werkzeugen zurSimulation von Wechselwirkungen (vgl. nächster Ab-schnitt „Eigenschaftsabsicherung“ sowie Ab-schnitt 3.3) ist eine enge Zusammenarbeit der Fachdis-ziplinen gefordert, da die Bewertung dieser Wechsel-wirkungen detailliertes Fachwissen verlangt.

EigenschaftsabsicherungBeim Durchlaufen der Phasen Systementwurf, domä-nenspezifischer Entwurf und Systemintegration sindnach den einzelnen Phasen immer wieder Lösungs-varianten auszuwählen und deren Eigenschaften an-hand der Anforderungsliste zu bewerten. Bei den Ei-genschaftsgrößen handelt es sich um zahlenmäßigeKennwerte, verbal formulierte Aussagen etc. Dieseso genannte Eigenschaftsabsicherung subsumiert diebeiden Begriffe Verifikation und Validierung, dieverschiedene Stufen zur Sicherung der gefordertenSystemeigenschaften beschreiben.

Verifikation meint allgemein den Nachweisder Wahrheit von Aussagen. Übertragen auftechnische Systeme ist hierunter die Überprü-fung zu verstehen, ob eine Realisierung (z.B.ein Software-Programm) mit der Spezifikation(in diesem Fall mit der Algorithmenbeschrei-bung) übereinstimmt. Bei der Überprüfung derGültigkeit eines Programms wird auch von derProgrammverifikation gesprochen. Die Verifi-kation wird im Allgemeinen formal realisiert.

Umgangssprachlich ist die Verifikation die Be-antwortung der Frage: Wird ein korrektes Pro-dukt entwickelt?

In classic mechanical engineering, the problem of sys-tem integration usually lies in the form-determiningproperties. When designing mechatronic systems, var-ious interactions (for example behavior, electromag-netic compatibility, etc.) have to be taken into consid-eration for checking the compatibilities. Apart fromthe use of IT tools for simulating interactions (cf. nextsection ”Assurance of properties“ and Section 3.3),close cooperation between the technical disciplines isrequired, since the assessment of these interactions re-quires detailed technical knowledge.

Assurance of propertiesWhen running through the phases of system design,domain-specific design and system integration, it isnecessary after the individual phases to keep select-ing solution variants and assess their properties on thebasis of the requirements list. The property variablesare numerical characteristic values, verbally formu-lated statements, etc. This so-called assurance ofproperties subsumes the two terms verification andvalidation, which describe different stages of ensur-ing the required system properties.

Verification means generally demonstratingthe truth of statements. Transferred to techni-cal systems, it is to be understood as meaningchecking whether the way in which somethingis realized (for example a software program)coincides with the specification (in this casewith the description of algorithms). Whenchecking the validity of a program, reference isalso made to program verification. The verifi-cation is generally realized in a formal manner.

In everyday language, verification is the an-swer to the question: Is a correct product beingdeveloped?



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Validierung meint ursprünglich die Gültig-keitsprüfung einer Messmethode in der empi-rischen Sozialforschung, das heißt inwieweitdie Testresultate tatsächlich das erfassen, wasdurch den Test bestimmt werden soll. Übertra-gen auf technische Systeme ist hierunter diePrüfung zu verstehen, ob das Produkt für sei-nen Einsatzzweck geeignet ist bzw. den ge-wünschten Wert erzielt. Hier geht die Erwar-tungshaltung des Fachexperten und des An-wenders ein. Die Validierung beinhaltet z.B.die Prüfung, ob die Beschreibung eines Algo-rithmus mit dem zu lösenden Problem überein-stimmt. Sie ist im Allgemeinen nicht formaldurchzuführen.

Umgangssprachlich ist die Validierung die Be-antwortung der Frage: Wird das richtige Pro-dukt entwickelt?

Mit Hilfe der Bewertung können verschiedene Lö-sungsvarianten untereinander verglichen oder im Ver-gleich zu einer idealisierten Lösung als Grad der An-näherung an diese eingeschätzt werden. In dieserRichtlinie soll nicht detaillierter auf die Bewertungund die damit verbundenen Schritte eingegangen wer-den (siehe VDI 2225). Vielmehr sollen die möglichenKombinationen von Modellen, Prototypen und Pro-dukten der Lösungsvarianten in ihren jeweiligen Sys-temgrenzen aufgezeigt werden; die integrierten Unter-suchungen mit Hilfe von IT-Werkzeugen stehen hier-bei im Vordergrund. Sie bieten bei wachsender Kom-plexität heutiger Funktionen die Möglichkeit, in sorg-fältig strukturierten, systematischen Entwicklungsab-läufen die Funktion, Sicherheit und Zuverlässigkeitder Systeme auch unter kritischen Bedingungen zu ve-rifizieren und zu validieren. Hierbei ist zwischen Ex-perimenten mit entsprechend ausgerüsteten Prototy-pen, in denen das gesamte System zum Einsatzkommt, und solchen mit isolierten Einzelkomponen-ten zu unterscheiden.

Derartige Untersuchungen können in einem virtuellen,realen oder einer Kombination aus virtuellem und rea-lem Versuch durchgeführt werden. Bei einem virtuel-len Versuch wird das gesamte zu untersuchende Sys-tem mit Hilfe von Modellen beschrieben und in seinemVerhalten simuliert (siehe Abschnitt 3.2). Dagegenmuss in einem realen Versuch das System physikalischrealisiert sein, um das Verhalten in dem jeweiligenKontext untersuchen zu können. Hierfür sind alle phy-sikalischen Lasten real nachzubilden. Bei mechani-schen Systemen handelt es sich hierbei beispielsweiseum Bewegungen, Kräfte und Momente, bei elektroni-schen Systemen um resistive, induktive und kapazitive

Validation originally means checking the va-lidity of a measuring method in empirical so-cial research, i.e. the extent to which test re-sults actually register what is intended to bedetermined by the test. Transferred to techni-cal systems, it is to be understood as meaningtesting whether the product is suitable for itsintended purpose or achieves the desiredvalue. The expectations of the technical expertand the user come into the equation here. Val-idation comprises, for example, checkingwhether the description of an algorithm coin-cides with the problem to be solved. It gener-ally does not have to be carried out in a formalmanner.

In everyday language, validation is the answerto the question: Is the right product being de-veloped?

With the aid of the assessment, various solution vari-ants can be compared with one another or appraised incomparison with an idealized solution as the degree ofapproximation to the latter. In this guideline, it is notintended to go into any more detail concerning the as-sessment and the associated steps (see VDI 2225).Rather, the possible combinations of models, proto-types and products of the solution variants are to bepresented in their respective system limits; integratedinvestigations with the aid of IT tools are at the fore-front of this. With increasing complexity of functionstoday, they offer the possibility of verifying and vali-dating the function, safety and reliability of the sys-tems, even under critical conditions, in carefully struc-tured, systematic development sequences. A dis-tinction is to be made here between experiments withcorrespondingly equipped prototypes, in which theoverall system is used, and those with isolated individ-ual components.

Such investigations can be carried out in a virtual ex-periment, a real experiment or a combination of these.In a virtual experiment, the entire system to be investi-gated is described with the aid of models and simulatedin its behavior (see Section 3.2). On the other hand, ina real experiment, the system must be physically real-ized, in order to be able to investigate the behavior inthe respective context. For this, all the physical loadsmust be replicated as they are in reality. In the case ofmechanical systems, these are for example move-ments, forces and moments, in the case of electronicsystems they are resistive, inductive and capacitiveloads. A combination of real and virtual parts of a sys-



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Lasten. Eine Kombination aus realen und virtuellenTeilen eines Systems kann in einer Hardware-in-the-Loop-Umgebung untersucht werden.

Hardware-in-the-Loop (HIL) ist die Integrationvon realen Komponenten (Bauteilen) und System-modellen in eine gemeinsame Simulationsumge-bung. Die HIL-Nachbildung (Simulation) dynami-scher Systeme durch physikalische und mathemati-sche Modelle muss dabei in Echtzeit und unter Nach-bildung der physikalischen Lasten erfolgen. Ein Bei-spiel ist die Simulation eines Gesamtfahrzeugs amRechner mit der Anbindung eines realen Steuergerä-tes und der Aktorik für eine Funktionsregelung zurFahrstabilitätsregelung. Ein entscheidender Vorteilder HIL ist der Funktionstest des Steuergerätes unterrealen Bedingungen bei gleichzeitiger Einsparung anzeit- und kostenintensiven Fahrmanövern.

Software-in-the-Loop (SIL) ist die Integration vonSystemmodellen in eine gemeinsame Simulati-onsumgebung mit dem modellierten Prozess (Regel-strecke); sowohl die zu entwickelnde Funktion alsauch der Prozess (Regelstrecke), auf den die Funk-tion einwirkt, werden modelliert. Die SIL-Nachbil-dung (Simulation) dynamischer Systeme durch ma-thematische Modelle muss dabei nicht in Echtzeit er-folgen. Ein entscheidender Vorteil der SIL ist derFunktionstest unter simulierten Bedingungen beigleichzeitiger Einsparung zeit- und kostenintensiverExperimente (z.B. Fahrmanöver). Ausgehend von ei-ner SIL-Umgebung können entweder die Funktion,der Prozess oder beide Teile physikalisch realisiertund im geschlossenen Kreis hinsichtlich ihres Ver-haltens analysiert werden.

Bild 3-6 zeigt beispielhaft die Arbeitsschritte der Ei-genschaftsabsicherung unter dem Gesichtspunkt derKopplung von Modellen und Prototypen.

tem can be investigated in a hardware-in-the-loop en-vironment.

Hardware-in-the-loop (HIL) is the integration ofreal components and system models in a commonsimulation environment. The HIL replication (simu-lation) of dynamic systems by physical and mathe-matical models must in this case take place in realtime and with the physical loads replicated. An exam-ple is the simulation of an entire vehicle on a compu-ter with the connection of a real control device andthe actor technology for functional control to providevehicle stability. A decisive advantage of HIL is thefunction test of the control device under real condi-tions while at the same time saving on time- and cost-intensive driving maneuvers.

Software-in-the-loop (SIL) is the integration of sys-tem models in a common simulation environmentwith the modeled process (controlled system); boththe function to be developed and the process (control-led system) on which the function acts are modeled.The SIL replication (simulation) of dynamic systemsby mathematical models does not have to take placein real time. A decisive advantage of SIL is the func-tion test under simulated conditions while at the sametime saving on time- and cost-intensive experiments(for example driving maneuvers). On the basis of anSIL environment, either the function, the process orboth parts can be physically realized and analyzedwith regard to their behavior in a closed loop.

Figure 3-6 shows by way of example the workingsteps of the assurance of properties from the aspect ofcoupling models and prototypes.

Bild 3-6. Arbeitsschritte der Eigenschaftsabsicherung am Bei-spiel des Kraftfahrzeugs

Fig. 3-6. Working steps of the assurance of properties in theexample of a motor vehicle



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


1) Funktionsnachweis: Eine neue oder veränderteFunktionalität eines Steuergerätes wird dabei alsModell in einem geschlossenen Regelkreis miteinem Streckenmodell (Prozessmodell) getestet.Diese Untersuchung wird als Software-in-the-Loop (SIL) bezeichnet.

2) Applikation: Die am Streckenmodell überprüfteFunktion kann dann an dem realen Prozess nach-geprüft und in einem ersten Schritt auf den Pro-zess abgestimmt werden.

3) Zielsoftware-/Schnittstellennachweis: Durchdie Kopplung des realen Steuergerätes mit demStreckenmodell in einer HIL-Umgebung kann dieFehlerfreiheit der Zielsoftware und der Schnitt-stellenkommunikation überprüft werden.

4) Integration: Die Integration des mit einer neuenFunktionalität ausgestatteten Steuergerätes in denrealen Prozess erlaubt die Erprobung des Ge-samtsystems und die Anpassung aller relevantenSignal- und Steuerdaten.

3.1.4 Integrativer Entwurf von Produkt und Produktionssystem

Aus dem eingangs erläuterten Begriffsverständnisder Mechatronik wird deutlich, dass ein Hauptmerk-mal mechatronischer Produkte die funktionale undräumliche Integration von Komponenten aus den Do-mänen Maschinenbau, Elektrotechnik und Informati-onstechnik ist. Um diese Integration zu erreichen, be-darf es einer frühzeitigen Abstimmung der spezifi-schen Entwurfsprozesse der involvierten Domänen[SFB01]. Für den Entwurf von Produktionssystemenergeben sich daraus zwei Forderungen:

1. Die für den Produktentwurf gültige Integrations-forderung muss auch an den Entwurf von Pro-duktionssystemen gestellt werden.

2. Das Produktkonzept wird entscheidend durch dieFertigungstechnologien (insbesondere Aufbau-und Verbindungstechnologien) geprägt. Der Ent-wurf von Produkt und Produktionssystemen mussdeshalb bereits in den frühen Entwurfsphasen in-tegrativ betrachtet werden.

Auf Grund der Fokussierung der vorliegenden VDI-Richtlinie auf den Produktentwurf soll an dieserStelle in Form eines Exkurses auf den Entwurf vonProduktionssystemen eingegangen werden. Zur weit-eren Vertiefung wird auf die einschlägige Literatur16)verwiesen.

16) vgl. [Agg89; Dan98; EBL95; ES99; Fel89; Gru00; Ket84; Sch95;Wil98]

1) Function demonstration: A new or changedfunctionality of a control device is in this casetested as a model in a closed control loop with asystem model (process model). This investigationis referred to as software-in-the-loop (SIL).

2) Application: The function checked on the systemmodel can then be rechecked on the real processand adjusted to match the process in a first step.

3) Target software/interface demonstration: Bycoupling the real control device with the systemmodel in an HIL environment, the freedom fromerrors of the target software and of the interfacecommunication can be checked.

4) Integration: the integration of the control deviceequipped with a new functionality into the realprocess allows the overall system to be tried outand the adaptation of all relevant signal and con-trol data.

3.1.4 Integrative design of product and production system

It is clear from the understanding of the term me-chatronics explained at the beginning that a main fea-ture of mechatronic products is the functional andspatial integration of components from the domainsof mechanical engineering, electrical engineeringand information technology. To achieve this integra-tion, early coordination of the specific design proc-esses of the domains involved is required [SFB01].For the design of production systems, this gives riseto two requirements:

1. The integration requirement that applies to theproduct design must also be imposed on the de-sign of production systems.

2. The product concept is decisively characterizedby the production technologies (in particular con-struction and connection technologies). The de-sign of a product and production systems musttherefore already be taken into account in an inte-grative manner in the early design phases.

On account of the fact that this VDI guideline focuseson product design, a digression is to be made at thispoint to consider the design of production systems.For more, you are referred to the relevant litera-ture16).

16) including [Agg89; Dan98; EBL95; ES99; Fel89; Gru00; Ket84;Sch95; Wil98]



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Integrativer Entwurf der unterschiedlichen ProduktionsprozesseVor allem die räumliche Integration der Komponen-ten in ein mechatronisches Produkt stellt neue Her-ausforderungen an den Entwurf der Produktionspro-zesse und deren Vernetzung: Erstens bedingt dies ei-nen Montageprozess, in dem mechanische, elektroni-sche und informationstechnische Komponenten zueiner Baueinheit integriert werden. Der (End-)Montageprozess ist daher in analoger Weise wie derProduktentwurfsprozess durch zahlreiche Schnitt-stellen und Wechselwirkungen zwischen den Kom-ponenten und deren Produktionsprozessen geprägt[Sch00]. Zweitens erfordert die funktionale undräumliche Integration der Komponenten im Produktauch integrierte Mechanik- und Elektronik-Prüfun-gen und Tests nach der Montage. Diese müssen so-wohl die mechanischen als auch die elektrischen undelektronischen Eigenschaften des Produkts mit ein-beziehen, um dessen einwandfreie Gesamtfunktionsicherzustellen. Diese Form der mechatronischenQualitätssicherung hat für die Erschließung der wirt-schaftlichen Potenziale mechatronischer Produkteeine hohe Bedeutung.

Daraus leiten sich für den Entwurf von Produktions-systemen für mechatronische Produkte folgende Ab-stimmungsbedarfe zwischen Mechanik- und Elektro-nik-Produktion ab:

• Entwicklung neuer Produktionstechnologien (z.B.Reduzierung der Einbringung von Prozesswärmeund -vibrationen)

• Abstimmung der domänenspezifischen Produkti-onsprinzipien (z.B. Festlegung von Varianten undwirtschaftlichen Stückzahlen)

• Entwicklung integrierter Produktionssysteme(z.B. (Laser-)Abgleichprozesse, in denen eineElektronik individuell auf eine Mechanik (z.B.Optik) justiert wird, um auf diese Weise Ferti-gungstoleranzen auszugleichen; Umspritzen oderVergießen von Elektronikkomponenten)

• Koordination von Änderungen (z.B. Serien-Ein-laufzeitpunkte, Aktualisierung von Prüfmittelnund -programmen)

• Kontrolle und Steuerung der Umlaufbestände(z.B. bei mangelnder Lagerbarkeit von Halb-erzeugnissen)

• Klärung von Qualitätsproblemen auf Komponen-ten- und Produktebene (z.B. bei Transportschädenan elektronischen Komponenten)

Integrativer Entwurf von Produkt und ProduktionssystemIn Wissenschaft und Praxis ist die Notwendigkeiteiner engen Verzahnung von Produkt- und Produk-

Integrative design of the different production processesIn particular, the spatial integration of the compo-nents into a mechatronic product presents new chal-lenges for the design of production processes andhow they are interconnected: Firstly, this requires anassembly process, in which mechanical, electronicand information-technical components are integratedto form a structural unit. The (final) assembly processis therefore characterized in a way analogous to thatof the product design process by numerous interfacesand interactions between the components and theirproduction processes [Sch00]. Secondly, the func-tional and spatial integration of the components in theproduct also requires integrated checks and tests ofthe mechanics and electronics after assembly. Thesemust include both the mechanical properties and theelectrical and electronic properties of the product inorder to ensure its satisfactory overall function. Thisform of mechatronic quality assurance is of verygreat significance for exploiting the commercial po-tentials of mechatronic products.

For the design of production systems for mechatronicproducts, this gives rise to the following requirementsfor coordination between mechanical production andelectronic production:

• Development of new production technologies (forexample reduction of the introduction of processheat and vibrations)

• Coordination of the domain-specific productionprinciples (for example stipulation of variants andprofitable numbers of units)

• Development of integrated production systems(for example (laser) adjustment processes, inwhich electronics are adjusted individually to me-chanics (for example optics) in order in this wayto compensate for production tolerances; encapsu-lation or potting of electronic components)

• Coordination of changes (for example times ofentry into mass production, updating of means oftesting and testing programs)

• Monitoring and control of the stocks in circulation(for example when semifinished products cannotadequately be stored)

• Clarification of quality problems at component le-vel and product level (for example in the case ofdamage to electronic components in transit)

Integrative design of product and production systemsIn business and in practice, the necessity for close in-termeshing of product design and production system



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


tionssystementwurf unumstritten. Ein integrierterEntwurf legt den Schwerpunkt der Betrachtungen aufdie zeitbezogene, produkt- bzw. projektspezifischeAbstimmung von Einzelaufgaben. Ziel ist es, die Ab-läufe zeitlich zu parallelisieren. Hieraus leitet sich dieForderung nach einer Erweiterung der rein produkt-orientierten Betrachtungsweise eines Produktent-wicklungsprozesses ab [CR92; Eve93; EBL95].

Neben der Reduktion der Entwicklungszeit ermög-licht der parallele Entwurf von Produkt und Produk-tionssystem eine Abstimmung von Entscheidungenbereits in den frühen Phasen; hierdurch können maß-gebliche Optimierungspotenziale erschlossen sowieaufwändige Änderungen vermieden werden. Eineenge Verzahnung von Produkt- und Produktionssys-tementwurf muss vor allem in der Phase der Vorbe-reitung und Produktionskonzipierung gewährleistetwerden. Drei Gründe können hierfür angeführt wer-den:

• Es ist während der Konzipierung zu überprüfen,ob entsprechende Produkt- und Produktionstech-nologien zum Aufbau und zur Verbindung derelektronischen Komponenten verfügbar und wirt-schaftlich produzierbar sind, damit diese den ver-änderten Umweltbedingungen (klimatischen, me-chanischen, magnetischen und biologischen)standhalten.

• Die Integration unterschiedlicher Domänen erfor-dert die Neudefinition der Kompetenzen im Be-reich Produkt- und Produktionssystementwurf fürdiese Domänen. Es muss frühzeitig entschiedenwerden, welche Kompetenzen in Entwicklung(Anforderungs-, Bewertungs- oder Entwicklungs-kompetenz) und Produktion (Integrations-, Proto-typen- oder Serienkompetenz) vorzuhalten sind.

• Durch die unterschiedliche Länge der Innovati-onszyklen von Mechanik und Elektronik gewinnteine enge Anbindung von Produkt- und Produkti-onssystementwurf an Bedeutung, damit Fort-schritte sowohl produkt- wie auch produktionssei-tig wirtschaftlich realisierbar sind.

Es gilt somit einen geeigneten Informationsaustauschzwischen Produkt- und Produktionssystementwurfvorzunehmen. Dieser ist in drei Dimensionen zu ko-ordinieren: Zeit, Inhalt und Intensität der Zusammen-arbeit. Die zeitliche Koordination bestimmt sich überden Technologiebereich (Produkt oder Produktion),aus dem die Innovation betrieben wird. Die Inhalteder Entwurfsprozesse, das heißt welche Planungs-schritte im Detail auszuführen sind, werden über dieArt des Planungsanlasses festgelegt (Neuplanung vs.Weiterentwicklung), während die Intensität der Ab-

design is undisputed. An integrated design puts theemphasis of considerations on the time-related, prod-uct- or project-specific coordination of individualtasks. The aim is to arrange the sequences temporallyin parallel. The requirement for expansion of thepurely product-oriented way of considering a productdevelopment process arises from this [CR92; Eve93;EBL95].

Apart from reducing the development time, the paral-lel design of a product and production system makesit possible to coordinate decisions already in the earlyphases; this allows decisive optimization potentials tobe exploited and elaborate changes to be avoided.Close meshing of product and production system de-sign must be ensured in particular in the phase ofpreparation and production conception. Three rea-sons for this can be cited:

• During the conception it must be checked whethercorresponding product and production technolo-gies for constructing and connecting the electro-nic components are available and can be producedcost-effectively to withstand the changed environ-mental conditions (climatic, mechanical, magne-tic and biological).

• The integration of different domains requires theredefinition of competences in the area of productand production system design for these domains.It must be decided at an early time which compe-tences in development (requirement, assessmentor development competence) and production (in-tegration, prototype or mass-production compe-tence) are to be provided.

• The different lengths of the innovation cycles formechanics and electronics makes it important forproduct and production system design to be clo-sely linked, in order that advances can be com-mercially realized both on the product side and onthe production side.

Consequently, a suitable exchange of informationmust take place between product design and produc-tion system design. This is to be coordinated in threedimensions: time, content and intensity of the coop-eration. The temporal coordination is determined ac-cording to the area of technology (product or produc-tion) from which the innovation is driven. Thecontents of the design processes, i.e. which planningsteps are to be taken in detail, are fixed according tothe kind of reason for planning (new planning vs. fur-ther development), while the intensity of the coordi-



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


stimmung aus der Art der Planungsorganisation unddes entsprechenden Projektfortschritts bestimmtwird. Letztendlich ist der Entwurfsprozess somit im-mer von der Ausgangssituation des jeweiligen Unter-nehmens abhängig, und es kann daher keine detail-lierte, allgemeingültige Vorgehensweise beschriebenwerden. Vielmehr muss jedes Unternehmen für sichsituationsspezifisch die entsprechende Vorgehens-weise zur Anbindung des V-Modells des Pro-duktionssystementwurfs an das des Produktentwurfsentwickeln bzw. festlegen.

Bild 3-7 zeigt die Vorgehensweise beim Entwurfmechatronischer Produktionssysteme, die sich wieder Entwurf mechatronischer Systeme am V-Modellorientiert (vgl. Bild 3-2).

nation is determined by the type of planning organi-zation and the corresponding progress made in theproject. Ultimately, the design process is conse-quently always dependent on the initial situation ofthe respective company and therefore a detailed, gen-erally applicable procedure cannot be described.Rather, each company must itself develop or laydown the appropriate procedure specific to the givensituation for linking the V model of the productionsystem design to that of the product design.

Figure 3-7 shows the procedure when designing me-chatronic production systems which are based on theV model in the same way as the design of me-chatronic systems (cf. Figure 3-2).

Bild 3-7. Iteratives Vorgehen beim Entwurf von Produktionssystemen für mechatronische Erzeugnisse



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Innerhalb eines V-Zyklus wird die zu lösendeGesamtaufgabe in Teilaufgaben unterteilt, konkre-tisiert und die Teillösungen im aufsteigenden Ast des„V“ wieder zur Lösung der Gesamtaufgabe zusam-mengeführt. Eine Konkretisierung des Produktions-systementwurfs erfolgt somit sowohl innerhalb dereinzelnen Phasen sowie über die Phasen hinweg biszur Ausführung der Planungen, mit der die Phase„Detail- und Ausführungsplanung“ abschließt. Un-terstützt werden die Entwurfsaktivitäten in allenPhasen mit Hilfsmitteln der Virtuellen Produk-tion/Digitalen Fabrik17), u.a. 3D-CAD-, Mehrkör-

17) Virtuelle Produktion/Digitale Fabrik: Bezeichnet den integriertenProzess der Produktentstehung und Produktionsgestaltung vom Ent-wurf bis zur Serienfertigung. Ziel ist, die Fertigung mit allen Aspektenim Computer zu planen und zu simulieren, bevor sie errichtet wird.Auf Basis einer zentralen und durchgängigen Datenbasis werdenMaschinen, Anlagen und Betriebsmittel in digitaler bzw. auch dreidi-mensionaler Form abgebildet und ihr dynamisches Verhalten mittelsmehrskaliger und hierarchischer Simulation dargestellt [WB01].

Within a V cycle, the overall task to be solved is sub-divided into subtasks, concretized and the subtasksare brought together again in the rising branch of the”V“ to solve the overall task. Concretizing the pro-duction system design consequently takes place bothwithin the individual phases and over the phases up tothe execution of the plans, which brings the ”detailedand implementation planning“ to a conclusion. Thedesign activities are supported in all phases by auxil-iary means of virtual production/digital fabrica-tion17), including 3D-CAD, multibody, FEM, mate-rial-flow simulation. The strength of simulation is

17) Virtual production/digital fabrication: Refers to the integrated pro-cess of product creation and production formation from design to massproduction. The aim is to plan and simulate production with all aspectsin a computer before it is set up. On the basis of the central and univer-sal database, machines, plants and operating means are depicted indigital form or else three-dimensional form and their dynamic behavioris represented by means of multiscalar and hierarchical simulation[WB01].

0

Fig. 3-7. Iterative procedure in the design of production systems for mechatronic products



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


per-, FEM-, Materialfluss-Simulation. Die Stärke derSimulation ist es, bereits vor der Realisierung vonPlanungsergebnissen die Leistungsfähigkeit derLösungsalternativen festzustellen, zu vergleichenund zu optimieren. Eine domänenübergreifende engeZusammenarbeit im Bereich des Produktionssystem-entwurfs ist insbesondere bis zur Festlegung der Pro-duktionsprinzipien notwendig. Danach sind in deneinzelnen Domänen die Technologieketten zu spezi-fizieren und auszugestalten.

Zusammenfassend ist festzuhalten, dass die räum-liche und funktionale Integration von Komponentenin mechatronischen Produkten einen integrativenEntwurf von Produkt und Produktionssystemen er-fordert – kurz: Die Integration der Domänen mussauch das Produktionssystem einschließen.

3.2 Modellbasierter SystementwurfZur effizienten, rechnerbasierten Entwicklung vonmechatronischen Systemen werden Abbildungen –so genannte Modelle – der Systeme im Rechner be-nötigt. Diese Modelle werden für alle Komponentendes zu betrachtenden Systems in Abhängigkeit vomUntersuchungsziel erstellt und berücksichtigen Ele-mente der involvierten Domänen. Die ganzheitlicheBetrachtung auf Modellebene unterstützt die Ent-wickler beim Entwurf eines mechatronischen Sys-tems.

Im Laufe des Systementwurfs entstehen verschie-denste Modelle, die jeweils einen bestimmten Aspektdes Systems beschreiben. Modellarten sind bei-spielsweise Anforderungsmodelle zur Darstellungvon Systemanforderungen oder Verhaltensmodelle,welche die Funktion abbilden. CAD-Beschreibungensind ebenfalls Modelle, welche die Gestalt eines Sys-tems enthalten. Einen besonderen Schwerpunkt beider Modellbildung mechatronischer Systeme bildendie Verhaltensbeschreibungen, da mit ihnen der funk-tionale Zusammenhang domänenübergreifend erfasstund formuliert werden kann.

Die beteiligten Fachgebiete der Mechatronik habenverschiedene Darstellungsformen für Verhaltensmo-delle entwickelt, z.B. das Blockschaltbild in der Re-gelungstechnik. In Anlehnung an die bekanntenschriftlichen Darstellungen wurden mit zunehmen-dem Computereinsatz rechnerunterstützte Werk-zeuge zur Modellbildung verfügbar; diese sind ent-sprechend der involvierten Domäne unterschiedlichausgeprägt (vgl. Abschnitt 3.3).

Da die Gesamtfunktion eines mechatronischen Sys-tems erst durch das Zusammenwirken der involvier-ten Fachdisziplinen erfüllt wird, besteht die Notwen-digkeit, die Modelle der Teildisziplinen zusammen-

that the capability of the solution alternatives can beestablished, compared and optimized already beforethe realization of planning results. A cross-domainclose cooperation in the area of production systemdesign is necessary in particular until the productionprinciples are stipulated. After that, the technologychains are to be specified and created in the individ-ual domains.

To sum up, it can be stated that the spatial and func-tional integration of components in mechatronicproducts requires an integrative design of product andproduction systems – in short: Integration of the do-mains must also include the production system.

3.2 Model-based system designFor the efficient, computer-based development ofmechatronic systems, models of the systems in acomputer are required. These models are created forall components of the system under consideration, independence on the objective of the investigation, andtake into consideration elements of the domains in-volved. Fully inclusive consideration at the modellevel supports the developers in the design of a me-chatronic system.

In the course of system design, a wide variety of mod-els respectively describing a specific aspect of thesystem are created. Model types are, for example, re-quirement models for representing system require-ments or behavior models, which depict the function.CAD descriptions are likewise models which containthe form of a system. The behavior descriptions areparticularly important in the case of modeling me-chatronic systems, since with them the functional in-terrelationship can be captured and formulated in across-domain way.

The technical areas of mechatronics that are involvedhave developed various forms of representation forbehavior models, for example the block diagram incontrol engineering. With increasing use of comput-ers, computer-aided tools for modeling became avail-able to mirror the known written representations;these tools are differently characterized in accord-ance with the domains involved (cf. Section 3.3).

Since the overall function of a mechatronic system isonly satisfied by the interaction of the technical disci-plines involved, there is the necessity to bring to-gether the models of the subdisciplines. The integra-



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


zuführen. Die Integration von Modellen auf derBasis von mathematischen Beschreibungen ist eineflexible und gut handhabbare Vorgehensweise, da dieMathematik auf Grund ihrer Allgemeingültigkeiteine normierende Darstellung für unterschiedlichsteDomänen bildet. Dabei ist jeweils die Frage zu klä-ren, welche Informationen mit welcher Art mathema-tischer Gleichung innerhalb einer Domäne formulier-bar sind und welche Korrelationen mit diesen Infor-mationen domänenübergreifend bestehen.

Idealerweise bauen Modelle späterer Entwicklungs-phasen auf Modellen früherer Phasen auf. Ausführ-bare Spezifikationen, die in frühen Entwicklungs-phasen grob die Funktion eines Systems beschrei-ben, können beispielsweise für den Aufbau von de-taillierteren Verhaltensmodellen genutzt werden.Verhaltensmodelle können Vorgaben für die geome-trische Ausgestaltung oder auch für Softwarealgo-rithmen sein. Diese so genannte „Durchgängigkeit“sollte sinnvollerweise über alle Entwicklungspha-sen bis hin zum endgültigen System erhalten blei-ben.

Das modellbasierte Vorgehen zum Entwurf mecha-tronischer Systeme bietet durch die Nutzung derModellbildung und der rechnerunterstützten Ana-lyse wichtige Zeit- und Kostenvorteile. Die Modell-bildung benötigt zunächst mehr Zeit und verursachtKosten, ermöglicht jedoch bezogen auf den gesam-ten Entwicklungsprozess zeit- und kostensparendeSekundäreffekte. Das Verhalten eines Systems odereiner Komponente ist bereits lange vor der Fertig-stellung des ersten Prototypen über realitätsnahe Si-mulationsmodelle überprüf- und analysierbar. So-mit können Iterationen zur Absicherung der Produk-teigenschaften bereits in einem virtuellen Entwick-lungsstadium erfolgen; das Produkt verfügt übereine wesentlich höhere Produktreife, wenn der wei-terhin notwendige Prototyp gebaut wird.

Wichtige Voraussetzung dieser Vorgehensweise ist,dass die simulierten Eigenschaften mit der Realitätausreichend übereinstimmen. Diese Überprüfung istjedoch insbesondere bei Neukonstruktionen in denfrühen Phasen nicht immer realisierbar. Die Anwen-dung der Modellbildung und Simulation erfordertdeshalb eine gewisse kritische Grundhaltung undeine dauernde Überprüfung der Plausibilität der er-zielten Untersuchungsergebnisse.

Das grundsätzliche Vorgehen beim modellbasier-ten Systementwurf gliedert sich in fünf Schritte(Bild 3-8):

tion of models on the basis of mathematicaldescriptions is a procedure which is flexible and easyto handle, since mathematics forms a standardizingrepresentation for a wide variety of domains on ac-count of its general applicability. To do so, it is nec-essary in each case to clarify the question as to whichinformation can be formulated with which type ofmathematical equation within a domain and whichcorrelations with this information exist in a cross-do-main way.

Ideally, models of later development phases arebuilt up on models of earlier phases. Implementablespecifications which in early development phasesroughly describe the function of a system can beused for example for building up more detailed be-havior models. Behavior models may be preceptsfor the geometrical configuration or else for soft-ware algorithms. It is appropriate for this so-called”universality“ to be retained over all developmentphases up to the final system.

The model-based procedure for the design of me-chatronic systems offers important advantages interms of time and costs by the use of modeling andcomputer-aided analysis. Modeling initially needsmore time and gives rise to costs, but it makes time-and cost-saving secondary effects possible in rela-tion to the entire development process. The behaviorof a system or a component can be checked and an-alyzed long before completion of the first prototypeby means of realistic simulation models. Conse-quently, iterations can already take place in an earlystage of development to assure the product proper-ties; the product has a much greater product matu-rity when the still necessary prototype is built.

An important precondition for this procedure is thatthe simulated properties coincide adequately withreality. However, in particular in the case of newconstructions, checking this cannot always be real-ized in the early phases. The use of modeling andsimulation therefore requires a certain critical atti-tude and ongoing checking of the plausibility of theinvestigation results obtained.

The basic procedure for model-based system de-sign is divided into five steps (Figure 3-8):



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


1. Zielformulierung: Zunächst sind Untersu-chungsziele und -aufgaben festzulegen, um diegeeigneten Methoden der Modellbildung aus-wählen zu können. Untersuchungsziele und -auf-gaben sowie Gründe für die Modellbildung kön-nen u.a. sein [Ber01]:

1. Objective: Firstly, investigation goals and tasksare to be stipulated, to allow the suitable methodsof modeling to be selected. The following may beamong the investigation goals and tasks and rea-sons for modeling [Ber01]:

Bild 3-8. Vorgehen beim modellbasierten Systementwurf

Fig. 3-8. Procedure for model-based system design



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


• Prinzipuntersuchungen an neu zu entwickeln-den mechatronischen Systemen (Unterstüt-zung des funktionsorientierten Entwurfs, Ana-lyse erster Lösungskonzepte, Generierung vonVorgaben für den domänenspezifischen Ent-wurf)

• zielgerichtete Reglerauslegung (lineare/nicht-lineare Analyse und Synthese zur Behandlungregelungstechnischer Aufgaben)

• Analyse und Optimierung bestehender mecha-tronischer Systeme (Feinmodellierung zur Lö-sung bestehender Probleme bzw. zur zielge-richteten Verbesserung, z.B. Kosten oderFunktionalität)

• Messeinrichtungen verursachen eine Rückwir-kung auf das System und verfälschen dieMesssignale (Gewicht und Wärmeleitung vonMesseinrichtungen etc.).

• Experimentelle Untersuchungen am Systemsind zu teuer, zu gefährlich oder nicht verant-wortbar (z.B. Fahrversuche im physikalischenGrenzbereich, Crashversuche mit Personen)bzw. nur mit großem Aufwand zu erbringen(z.B. Kälte-/Hitzetests).

• Experimentelle Untersuchungen dauern aufGrund der Systemzeitkonstanten zu lange(Werkstoffprüfungen, Verschleißuntersuchun-gen etc.).

• Reduzierung des Prototypenaufwands durch vo-rausgehende Simulationen (modellbasierte Inte-gration der entwickelten Teilsysteme, Test desZusammenwirkens der Systemkomponenten)

• Hardware-in-the-Loop-Simulationen zur Funk-tionsüberprüfung (strukturierter Aufbau desneuen oder verbesserten Systems, modularerSystemtest unter reproduzierbaren Einsatzbe-dingungen)

2. Modellbildung: Die Qualität des Modells ist ent-scheidend für die Güte der Analyseergebnisse.Nur wenn das Modell das System realitätsnah be-schreibt, kann die anschließende Modellanalyseauf die Wirklichkeit übertragbare Ergebnisse lie-fern. Das Vorgehen zur Modellbildung und dieverschiedenen Modellabstraktionsebenen wer-den in Abschnitt 3.2.1 näher erläutert.

3. Modellanalyse: Auf Basis des Modells werdendie Eigenschaften (z.B. Festigkeit mit Hilfe derFEM) und das Verhalten (z.B. Kinematik, Dyna-mik mit Hilfe der Simulation von Mehrkörper-systemen (MKS) [Hil83]) des Grundsystems un-tersucht (vgl. Abschnitt 3.2.2). Die Analyse lie-fert Erkenntnisse über das Systemverhalten fürdie nachfolgende Synthesephase.

• basic investigations carried out on mechatronicsystems that are to be newly developed (sup-port of the function-oriented design, analysis offirst solution concepts, generation of setpointselections for the domain-specific design)

• targeted controller design (linear/nonlinearanalysis and synthesis for the handling of con-trol-engineering tasks)

• analysis and optimization of existing me-chatronic systems (fine modeling for solvingexisting problems or for targeted improvement,for example costs or functionality)

• Measuring devices cause a reaction on the sys-tem and falsify the measuring signals (weightand heat conduction from measuring devices,etc.).

• Experimental investigations carried out on thesystem are too expensive, too dangerous or ir-responsible (for example driving tests at physi-cal limits, crash tests with persons) or can onlybe performed with great effort (for examplecold/heat tests).

• Experimental investigations take too long onaccount of the system time constants (materialstests, investigations into wear, etc.).

• reducing expenditure on prototypes by means ofpreceding simulations (model-based integrationof the developed subsystems, testing of the inter-action of the system components)

• hardware-in-the-loop simulations for functionchecking (structured setup of the new or im-proved system, modular system test under re-producible operating conditions)

2. Modeling: The quality of the model is decisivefor the quality of the analysis results. Only if themodel realistically describes the system can thesubsequent model analysis produce results whichcan be transferred to reality. The procedure formodeling and the various model abstraction levelsare explained in more detail in Section 3.2.1.

3. Model analysis: On the basis of the model, theproperties of the basic system are investigated (forexample strength with the aid of FEM) and its be-havior is investigated (kinematics, dynamics withthe aid of the simulation of multibody systems(MBS) [Hil83]) (cf. Section 3.2.2). The analysisproduces findings on the system behavior for thesubsequent synthesis phase.



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


4. Systemsynthese: In der Synthese werden dieSimulations- und Berechnungsergebnisse derModellanalyse auf das zu entwickelnde Systemübertragen. Wirkprinzipien und Lösungselementewerden feindimensioniert bzw. optimiert. Syn-these und Optimierung sind ganzheitlich zu be-trachten. Die Anforderungen an die Synthese er-geben sich aus der Modellanalyse. Falls es sichum einen kompletten oder teilweisen Neuentwurfdes Systems handelt, wird der Entwickler in derSynthesephase die endgültigen Parameter desSystems festlegen. Die Ergebnisse der Analyse-phase werden konkret umgesetzt.

5. Systemanalyse: Das festgelegte bzw. optimierteSystem wird nun von neuem analysiert und be-wertet. Gegebenenfalls sind Rücksprünge zu vor-hergehenden Schritten erforderlich. Dieses itera-tive Vorgehen ist um so effizienter, je schnellerdie Parameter des Gesamtsystems gegen eine op-timale Lösung konvergieren. Die Auswahl desModells ist herbei von großer Bedeutung.

3.2.1 ModellbildungDie erforderliche Güte des Modells ist grundsätzlichabhängig von der zu betrachtenden Problemstellung.Daher sollte, bevor mit der Modellierung begonnenwird, Klarheit über die Entwicklungsaufgabe beste-hen. Für Neuentwicklungen sind andere Modellie-rungsansätze zu wählen als bei der Weiterentwick-lung bzw. Optimierung existierender Produkte. Jenach Fragestellung variiert die Modellierungstiefe inHinblick auf die Berücksichtigung bestimmter physi-kalischer Effekte. So genügt in bestimmten Fällen dieModellierung eines aus mehreren Komponenten be-stehenden mechanischen Systems (z.B. Kfz) als einePunktmasse, während in anderen Fällen komplexeMehrkörpermodelle oder auch Finite-Elemente-Mo-delle aufgebaut werden müssen. Für eine im Sinneder Mechatronik ganzheitliche Vorgehensweise istdie Verbindung verschiedener, domänenspezifischerModelle mit angepassten Modellierungstiefen erfor-derlich, um Systeme domänenübergreifend und mo-dellbasiert entwickeln und validieren zu können.

Das Vorgehen bei der Modellbildung kann für unter-schiedliche Domänen der Mechatronik variieren. Inder Domäne Softwaretechnik beispielsweise können– auf Basis einer durchgeführten Anforderungs-analyse – die Zusammenhänge zwischen Anforde-rungen für das System und die Subsysteme struktu-riert und in einer Funktionsbeschreibung dargestelltwerden. Dabei wird eine Beschreibung der Strukturund des zeitlichen Verhaltens benötigt. Die Struktur-beschreibung kann beispielsweise mit der semifor-malen Funktionsbeschreibung nach Cartronic[BSD97] erfolgen.

4. System synthesis: In the synthesis, the simulationand calculation results of the model analysis aretransferred to the system to be developed. Operat-ing principles and solution elements are finely di-mensioned or optimized. Synthesis and optimiza-tion are to be considered in their entirety. Therequirements for the synthesis arise from themodel analysis. If a complete or partial new de-sign of the system is concerned, the developer willstipulate the final parameters of the system in thesynthesis phase. The results of the analysis phaseare implemented in a concrete form.

5. System analysis: The stipulated or optimizedsystem is then analyzed and assessed once again.It may be required to return to previous steps. Thisiterative procedure is all the more efficient thequicker the parameters of the overall system con-verge toward an optimum solution. The selectionof the model is of great significance here.

3.2.1 ModelingThe required quality of the model is fundamentallydependent on the problem to be considered. There-fore, before modeling is commenced, there should beclarity concerning the development task. For new de-velopments, other modeling approaches are to bechosen than in the case of the further development oroptimization of existing products. Depending on thequestion to be answered, the depth of modeling varieswith regard to the consideration for specific physicaleffects. For instance, in certain cases the modeling ofa mechanical system comprising a number of compo-nents (for example motor vehicle) as a point mass isadequate, while in other cases complex multibodymodels or else finite-element models have to be con-structed. For a fully inclusive procedure in terms ofmechatronics, the combination of various, domain-specific models with adapted modeling depths is re-quired to allow systems to be developed and validatedin a cross-domain and model-based manner.

The procedure for modeling may vary for differentdomains of mechatronics. In the domain of softwaretechnology, for example, the interrelationships be-tween requirements for the system and the subsys-tems may be structured and represented in a func-tional description – on the basis of a requirementsanalysis that has been carried out. In this case, a de-scription of the structure and of the behavior overtime is required. The structural description may takeplace for example with the semi-formal functionaldescription according to Cartronic [BSD97].



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Um das Verhalten mit der geforderten Genauigkeitzu beschreiben, werden Ersatzmodelle des Systemsauf verschiedenen Abstraktionsebenen gebildet(Bild 3-9):

Topologisches Modell: Zunächst ist die Topologie deszu simulierenden Systems zu modellieren. Sie be-schreibt die Anordnung und Verknüpfung funk-tionserfüllender Elemente (z.B. Lösungselemente,Baugruppen oder Module). Ein Element repräsentiertim Allgemeinen die drei Basisfunktionen kinemati-sche Funktion (z.B. Gelenkanzahl, Armlänge und Ge-lenkpositionen eines Roboters), dynamische Funktion(z.B. Bewegung von Massen unter Einwirkung vonKräften) und mechatronische Funktion (z.B. Rege-lung, Überwachung, Bahnplanung etc.). Die Topolo-gie mechanischer Elemente beispielsweise bestimmtim Wesentlichen die Kinematik des mechatronischenSystems; deshalb müssen diese Elemente vollständigim Simulationsmodell berücksichtigt werden. Andersstellt sich die Situation z.B. bei hydraulischen Elemen-ten dar. Hier können bereits auf topologischer Ebenesinnvolle Vereinfachungen getroffen werden, indemHydraulikbauteile durch stark vereinfachte Annahmenersetzt werden. Das Vorgehen hängt jedoch stark vonder zu Grunde liegenden Problemstellung und von derZielsetzung der Simulation ab. Der funktionsorien-tierte Entwurf, das heißt die abstrakte, lösungsneutraleModellierung einer Entwurfsaufgabe als Gesamtfunk-tion und die Aufgliederung in Teilfunktionen, ist einwichtiges Instrument, um systematisch von der Pro-duktfunktion zu einer geeigneten Topologie zu gelan-gen (vgl. Abschnitt 3.1.3).

In order to describe the behavior with the required ac-curacy, substitute models of the system are formed onvarious abstraction levels (Figure 3-9):

Topological model: Firstly, the topology of the systemto be simulated is to be modeled. It describes the ar-rangement and interlinking of function-performing el-ements (for example solution elements, subassembliesor modules). An element generally represents the threebasic functions, kinematic function (for examplenumber of joints, length of arm and positions of jointsof a robot), dynamic function (for example movementof masses under the effect of forces) and mechatronicfunction (for example control, monitoring, path plan-ning, etc.). The topology of mechanical elements forexample essentially determines the kinematics of themechatronic system; therefore, these elements must becompletely taken into consideration in the simulationmodel. The situation is different for example in thecase of hydraulic elements. Here, it is already possibleat the topological level to make meaningful simplifica-tions, in that hydraulic components are replaced bygreatly simplified assumptions. However, the proce-dure strongly depends on the underlying problem be-ing addressed and on the objective of the simulation.The function-oriented design, i.e. the abstract, solu-tion-neutral modeling of a design task as an overallfunction and the dividing up into subfunctions is animportant instrument to arrive systematically at a suit-able topology from the product function (cf.Section 3.1.3).

Bild 3-9. Modellabstraktionsebenen im Modellbildungsprozess Fig. 3-9. Model abstraction levels in the modeling process



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Physikalisches Modell: Ausgehend von der Topolo-giebeschreibung wird ein physikalisches Modell er-stellt. Diese Darstellung ist durch systemangepassteGrößen wie beispielsweise Massen und Längen beimechanischen oder Widerstände und Induktivitätenbei elektrischen Systemen definiert. Bei den mechani-schen Elementen werden dabei z.B. Anzahl und Ver-bindungen von Starrkörpern, Definition von flexiblenKörpern, Lagerreibung und -spiel oder Massenvertei-lungen festgelegt. Auf hydraulischer Seite umfasst dasphysikalische Modell z.B. Bauelemente, etwa hydrau-lische Kammern und Ventile, aber auch die Abbildungphysikalischer Effekte wie Leckagen, Reibungen oderHysteresen. Das physikalische Modell beschreibt dieSystemeigenschaften in domänenspezifischer Form.

Mathematisches Modell: Das mathematische Modellbildet die Grundlage zur Verhaltensbeschreibung desSystems. Hierzu wird das physikalische Modell in eineabstrakte, systemunabhängige Darstellung überführtund die oben beschriebenen physikalischen Eigen-schaften des Modells werden mit Hilfe von mathema-tischen Beschreibungen formuliert. Unterschiede inder Modellierungstiefe können sich hier beispiels-weise durch detailgetreuere hydraulische Leitungsmo-delle, detailliertere Reibungsmodelle, durch höherwer-tige Biegungsansätze bei der Berechnung elastischerStrukturen oder durch Berücksichtigung von Nichtli-nearitäten anstelle von Linearisierungen ergeben. Dasmathematische Modell integriert die unterschiedlichendomänenspezifischen Modelldarstellungen.

Numerisches Modell: Das mathematische Modellwird nun so aufbereitet, dass es algorithmisch behan-delt und einem rechnerunterstützten Verfahren z.B. zurSimulation zugeführt werden kann. Das numerischeModell hängt sehr stark von der verwirklichten Model-lierungstiefe, vom verwendeten Lösungsverfahren undvom mathematischen Modell (insbesondere im Hin-blick auf Nichtlinearitäten) ab. Das numerische Modellwird durch konkrete Zahlenwerte belegt (parametri-siert). Diese Zahlenwerte werden gegebenenfallsdurcheine Identifikation des realen Systems (falls vorhan-den) ermittelt (vgl. Vorgehen bei der Modellbildung).

Bild 3-10 zeigt die typischerweise zu durchlaufendenVorgehensschritte bei der Modellbildung, die unterUmständen iterativ wiederholt werden müssen.

Planen und Klären der Aufgabe: Auf der Basis derZielformulierung wird ein geeignetes Modell erarbei-tet. Dazu müssen die konkreten Anforderungen an dasModell der gewünschten Abstraktionsebene festgelegtwerden. Die allgemeinste Anforderung ist die hinrei-chende Abbildung von Eigenschaften des realen Sys-tems als Modell.

Physical model: Starting from the topological de-scription, a physical model is created. This representa-tion is defined by system-adapted variables, such as forexample masses and lengths in the case of mechanicalsystems or resistances and inductances in the case ofelectrical systems. In the case of the mechanical ele-ments, the number and connections of rigid bodies, thedefinition of flexible bodies, bearing friction and clear-ance or mass distributions are stipulated for example.On the hydraulic side, the physical model comprises,for example, components such as hydraulic chambersand valves, but also the replication of physical effects,such as leakages, frictions or hystereses. The physicalmodel describes the system properties in a domain-specific form.

Mathematical model: The mathematical modelforms the basis of the behavioral description of the sys-tem. For this purpose, the physical model is transferredinto an abstract, system-independent representationand the physical properties of the model describedabove are formulated with the aid of mathematical de-scriptions. Differences in the depth of modeling mayarise here for example due to more faithfully detailedhydraulic line models, more detailed friction models,due to more sophisticated bending evaluations in thecalculation of elastic structures or due to considerationof nonlinearities instead of linearizations. The mathe-matical model integrates the different domain-specificmodel representations.

Numerical model: The mathematical model is thenprepared in such a way that it can be algorithmicallyhandled and subjected to a computer-aided process, forexample simulation. The numerical model dependsvery strongly on the depth of modeling realized, on thesolving method used and on the mathematical model(in particular with regard to nonlinearities). The nu-merical model is provided with concrete numericalvalues (parameterized). These numerical values arepossibly determined by an identification of the realsystem (if present) (cf. procedure for modeling).

Figure 3-10 shows the procedural steps for mode-ling that are typically to be taken and under some cir-cumstances must be iteratively repeated.

Planning and clarifying the task: On the basis of theobjective, a suitable model is devised. For this purpose,the concrete requirements for the model of the desiredabstraction level must be stipulated. The most generalrequirement is the adequate replication of properties ofthe real system as the model.



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Theoretische bzw. experimentelle Modellbildung:Ziel dieser Phase sind mathematische Ersatzmodelledes Systems, die das Verhalten mit ausreichender Ge-nauigkeit beschreiben. Ausgehend von der Topologiewird das physikalische Modell in eine abstrakte,systemunabhängige Darstellung überführt (vgl.obenstehende Beschreibung der Abstraktionsebenen;Bild 3-9). Hierfür gibt es im Wesentlichen zweiWege:

1) Theoretische Modellbildung: Die Systemglei-chungen werden durch Anwenden der physika-lischen Grundgesetze abgeleitet, wobei die quan-titativen Informationen aus der Geometrie des be-treffenden Gebildes, aus Stoffkonstanten undempirischen Zusammenhängen gewonnen wer-den.

2) Experimentelle Modellbildung: Aus Messungenan dem zu beschreibenden System wird rückwärtsauf die Systemstruktur(-gleichungen) geschlos-sen. Auch die Kombination beider Wege ist ge-bräuchlich, um z.B. das Verhalten des zunächsttheoretisch aufgestellten Modells mit Messungenam realen System zu vergleichen bzw. um nochunbekannte Parameter durch Abgleich mit demrealen System zu bestimmen. Dies geschieht, so-fern möglich, durch experimentelle Analyse[Föl94]. Die meisten Methoden beruhen auf der

Theoretical or experimental modeling: The aim ofthis phase is to obtain mathematical substitute modelsof the system which describe the behavior with ade-quate accuracy. Starting from the topology, the phys-ical model is transferred into an abstract, system-in-dependent representation (cf. previous description ofthe abstraction levels; Figure 3-9). There are essen-tially two ways of doing this:

1) Theoretical modeling: The system equations arederived by applying the physical principles, thequantitative information being obtained from thegeometry of the formation concerned, from mate-rial constants and empirical interrelationships.

2) Experimental modeling: From measurements onthe system to be described, ex post facto conclu-sions are drawn with respect to the system struc-ture (equations). It is also common to combine thetwo ways, for example to compare the behavior ofthe initially theoretically set up model with meas-urements on the real system or to determine stillunknown parameters by adjustment with the realsystem. This takes place where possible by exper-imental analysis [Föl94]. Most methods are basedon the stimulation of the technical system with an

Bild 3-10. Vorgehen bei der Modellbildung Fig. 3-10. Procedure for modeling



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Anregung des technischen Systems mit einer an-gepassten Zeitfunktion und der Analyse der Zeit-antwort. Die Modellparameter werden daraufhinso angepasst, dass die Antwort des Modells derAntwort des realen Systems entspricht. Die amhäufigsten verwendete Anregungsfunktion ist dieSprung-Funktion.

Identifikation: Im Falle der Weiterentwicklungeines vorhandenen Produkts werden gemessene tech-nische Werte des realen Systems auf das Modellübertragen. Bei einer Neuentwicklung werden dieParameter entsprechend den Anforderungen festge-legt. Resultat der Phase bildet ein durch konkreteZahlenwerte belegtes Modell, das jedoch noch nichtverifiziert ist.

Verifikation/Validierung: Die Verifikation ermit-telt, ob ein Modell grundsätzlich plausibel und richtigist und ob es den eingangs aufgestellten Anforderun-gen genügt. Eine Aussage, ob das erstellte Modell einreales System hinreichend beschreibt und damit aucheventuell nicht spezifizierte Anforderungen erfüllt,liefert die Validierung (siehe auch in „Eigenschafts-absicherung“ Abschnitt 3.1.3 ). Für die Neuentwick-lung bietet sich an dieser Stelle eine Plausibilitätsprü-fung an, die ermittelt, ob das Modell einem realenSystem entsprechen kann. Dieser Vorgang erfordertin der Regel ein erhebliches Erfahrungswissen überrealistische technische Größen bzw. physikalischesVerhalten. Genügt das Modell den vorgegebenen An-forderungen (Genauigkeit, hinreichende Abbildungder Realität, Modellierungstiefe etc.), ist der Modell-bildungsprozess abgeschlossen. Das nun verifiziertebzw. validierte Modell kann anschließend in der Mo-dellanalyse untersucht werden. Werden die Anforde-rungen nicht erfüllt, so wird zur theoretischen bzw.experimentellen Modellbildung zurückgekehrt unddas Modell verbessert.

3.2.2 ModellanalyseDie Modellanalyse dient allgemein zur Ermittlungvon Eigenschaften für ein vorgegebenes System.Dieses System kann real vorhanden sein oder alsModell vorliegen. In vielen Fällen ist ein realesSystem vorhanden, aus dem ein Modell abgeleitetwerden kann. Zwei Zielrichtungen der Modellana-lyse können unterschieden werden: die Analyse zurFeststellung des Ist-Zustands und die Analyse desmöglichen Verhaltens. In beiden Fällen werdenKenntnisse über das System ermittelt (Dynamik, Fes-tigkeit etc.). Die Fragestellungen, welche an die Ana-lyse gerichtet werden, bestimmen das Vorgehen unddie Werkzeuge, mit denen das System analysiertwird. Auch eine Analyse an realen Modellen ist üb-lich, falls das rechnerunterstützte Modell zu komplexoder beispielsweise die Umwelt nicht oder nur

adapted time function and the analysis of the timeresponse. The model parameters are then adaptedin such a way that the response of the model cor-responds to the response of the real system. Thestimulation function used most frequently is thejump function.

Identification: In the case of the further developmentof an existing product, measured technical values ofthe real system are transferred to the model. In thecase of a new development, the parameters are fixedin a way corresponding to the requirements. The re-sult of the phase forms a model provided with con-crete numerical values, which however is not yet ver-ified.

Verification/validation: The verification determineswhether in principle a model is plausible and correctand whether it satisfies the requirements imposed atthe beginning. A statement as to whether the modelcreated adequately describes a real system, and con-sequently also satisfies possibly not specified re-quirements, is provided by the validation (see also”Assurance of properties“ in Section 3.1.3 ). For thenew development, it is appropriate at this point to per-form a plausibility check, which determines whetherthe model can correspond to a real system. This pro-cedure generally requires considerable empiricalknowledge of realistic technical variables or physicalbehavior. If the model satisfies the prescribed re-quirements (accuracy, adequate replication of reality,depth of modeling, etc.), the modeling process is con-cluded. The now verified or validated model can sub-sequently be investigated in the model analysis. If therequirements are not satisfied, a return is made to thetheoretical or experimental modeling and the modelis improved.

3.2.2 Model analysisThe model analysis generally serves for the determi-nation of properties for a prescribed system. Thesystem may exist in reality or as a model. In manycases there is a real system from which a model canbe derived. A distinction can be made between twopurposes for model analysis: analysis for establish-ing the actual state and analysis of possible behav-ior. In both cases, knowledge of the system is deter-mined (dynamics, strength, etc.). The questionswhich are directed at the analysis determine the pro-cedure and the tools with which the system is ana-lyzed. An analysis on real models is also customary ifthe computer-aided model is too complex or, for ex-ample, the environment cannot be mathematically orphysically reproduced, or only with difficulty. Thisapplies in particular in the case of strongly nonlinear



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


schwer mathematisch bzw. physikalisch zu erfassenist. Dies gilt im Besonderen bei stark nichtlinearemoder chaotischem Verhalten. Als Beispiel für solcheAnalysen sei hier das dynamische Verhalten vonSchiffen bei starkem Wellengang genannt, das ineinem künstlichen Wellenkanal mit einem maßstäbli-chen Modell untersucht wird. Durch die Entwicklungder Rechentechnik und der Analysewerkzeuge istaber abzusehen, dass Untersuchungen an realen Mo-dellen zunehmend durch Untersuchungen an rechner-gestützten Modellen verdrängt werden.

Abgesehen von diesen speziellen Fällen dient dieFeststellung des Ist-Zustands fast immer zum Aufbaubzw. der Parametrisierung von abstrakten rechnerge-stützten Modellen. In diesem Fall ist die Modellana-lyse ein Teil des Modellbildungsprozesses [Sch85].

Die Analyse des Modells eines Systems soll Aussa-gen über das Systemverhalten liefern. Mit einemModell können Systemzustände analysiert werden, indie das reale System nicht gebracht werden kann oderdarf. Beispielsweise kann mit einem FEM-Modellauf eine zerstörende Festigkeitsuntersuchung ver-zichtet werden; das Schwingverhalten einer Wind-kraftanlage bei Sturm kann bestenfalls mit großemAufwand untersucht werden. Die Modellanalyse isthier ein Verfahren, das auf der Modellbildung aufbautund das Modell als Hilfsmittel der Analyse benutzt.

Der konkrete Ablauf eines modellbasiertenSystementwurfs kann folgendermaßen aussehen:Für ein vorhandenes technisches System (z.B. eineWerkzeugmaschine) soll eine Regelung entworfenwerden. Zunächst wird auf Basis der vorhandenenGeometriemodelldaten (im Allgemeinen CAD) einMehrkörpersystemmodell aufgebaut (Modellbil-dung). Dieses abstrakte Modell wird anschließendmit dem realen System verglichen. Die freien Para-meter des Modells müssen ermittelt bzw. eingestelltwerden (Identifikation). Dies geschieht durchMessungen am realen System. Weitere Verfahren zurErmittlung des Systemverhaltens schließen sich an,beispielsweise die Modalanalyse. Auch soll die Ana-lyse ermitteln, welches Modell die konkrete Frage-stellung hinreichend gut beschreibt (Modellanalyse).Für die Verbesserung der Dynamik eines Fahrzeug-aufbaus müssen unter Umständen nur die Moden mo-delliert werden, die im relevanten Frequenzbereichliegen.

Für das parametrisierte Modell kann nun eine Rege-lung entwickelt werden (Systemsynthese). Die Struk-tur dieser Regelung ergibt sich im Wesentlichen ausder Struktur des Modells (bzw. aus der Struktur desSystems, aus dem das Modell abgeleitet wurde) undseines Übertragungsverhaltens. Das geregelte Ge-samtsystem wird wiederum analysiert, z.B. Fre-

or chaotic behavior. An example of such analyses thatmay be cited is the dynamic behavior of ships inheavy seas, which is investigated with a scale modelin an artificial wave tank. However, it is evident fromthe development of computing technology and analy-sis tools that investigations on real models will in-creasingly be replaced by investigations on compu-ter-aided models.

Apart from these special cases, establishing the ac-tual state almost always serves for setting up or pa-rameterizing abstract computer-aided models. In thiscase, the model analysis is part of the modeling proc-ess [Sch85].

The analysis of the model of a system is intended toprovide statements about the system behavior. With amodel it is possible to analyze system states intowhich the real system cannot or must not be brought.For example, with an FEM model it is possible to dis-pense with an investigation of ultimate strength; thevibrational behavior of a wind power generating plantin a storm can at best be investigated with great effort.Model analysis is a method here which is based onmodeling and uses the model as an auxiliary means ofanalysis.

The actual sequence of a model-based system de-sign may look as follows: A control system is to bedesigned for an existing technical system (for exam-ple a machine tool). Firstly, a multibody systemmodel is set up on the basis of the existing geometrymodel data (generally CAD) (modeling). This ab-stract model is subsequently compared with the realsystem. The free parameters of the model must be de-termined or set (identification). This takes place bymeasurements on the real system. Further methods ofdetermining the system behavior follow, for examplemodal analysis. The analysis is also intended to deter-mine which model describes the actual question ade-quately well (model analysis). To improve the dy-namics of a vehicle construction, under somecircumstances only the modes which are in the rele-vant frequency range have to be modeled.

For the parameterized model, a control system canthen be developed (system synthesis). The structureof this control system essentially arises from thestructure of the model (or from the structure of thesystem from which the model was derived) and itstransmission behavior. The overall controlled systemis in turn analyzed, for example frequency analysis,



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


quenzganganalyse, Eigenwertberechnung, Simula-tion etc. (Systemanalyse). Die Ergebnisse dieser An-alysephase dienen zur Optimierung des neu entwor-fenen geregelten Gesamtsystems.

3.3 WerkzeugeDie Entwicklung mechatronischer Systeme erfordertden Einsatz einer Vielzahl von Methoden. DerMethodeneinsatz wird durch IT-Werkzeuge unter-stützt. Ziel einer integrierten Entwicklung ist es, denEntwurfsprozess möglichst durchgängig rechner-unterstützt ablaufen zu lassen [EM00; KA01]. Hier-bei sind vier verschiedene Ebenen der Integration zuunterscheiden (s.u. Textkasten „KOMFORCE-Refe-renzmodell“).

Beispiele für die modelltechnische Integration sindVHDL-AMS18) und MechaSTEP19). MechaSTEPbasiert auf der STEP20)-Umgebung und liefert einneutrales Datenformat für den Datenaustausch vonSystemen der Domänen Fluidtechnik, Mechanik,Elektrotechnik und Regelungstechnik. Die prototypi-sche Anbindung von zwei Simulationsprogrammenaus der Mehrkörpersimulation ist bereits erfolgreichrealisiert worden; vereinzelte Implementierungenexistieren. Eine der zukünftigen Herausforderungenliegt darin, die neu entwickelten Modellansätze ininternationale Normungsgremien einzubringen[DK00]. Eine erste Normierung als Publicly Avai-lable Specification (PAS 1013) ist bereits erfolgt.

Einen relativ neuen fachübergreifenden Ansatz stelltModelica21) dar. Die objektorientierte SpracheModelica ist eine Weiterentwicklung der SpracheDymola22) mit Konzepten anderer interdisziplinärerBeschreibungssprachen. Sie ermöglicht die dynami-sche Simulation multidisziplinärer Systeme. Die Ob-jektorientierung bietet ferner die Möglichkeit, Mo-dellbibliotheken als Basis für die Systemsimulationaufzubauen und zu nutzen.

Die für den Entwurf mechatronischer Systeme ge-bräuchlichen Werkzeuge lassen sich in Klassen glie-dern. Die einzelnen Werkzeugklassen werden im Fol-genden beschrieben.

18) VHDL: Hardwarebeschreibungssprache, erweitert um Sprachmittelzur Definition analoger und diskreter Bauelemente (VHDL-AMS),zum standardisierten Austausch zwischen Simulationsumgebungenunterschiedlicher Domänen (ISO 1076.1 Proposal)19) MechaSTEP: STEP – Datenmodelle zur Simulation mechatroni-scher Systeme (PAS 1013)20) STEP (Standard for the Exchange of Product Model Data): Daten-modell zur einheitlichen Beschreibung von Produktdaten (ISO 10 303)21) Modelica: objektorientierte Sprache zur Modellbildung multidis-ziplinärer Systeme, http//: www.modelica.org22) Dymola: Beschreibungssprache zur Modellbildung kontinuierlicherdynamischer Systeme

eigenvalue calculation, simulation, etc. (system anal-ysis). The results of this analysis phase serve for op-timizing the newly designed overall controlled sys-tem.

3.3 ToolsThe development of mechatronic systems requiresthe use of a large number of methods. The use ofmethods is supported by IT tools. The aim of an inte-grated development is to allow the design process toproceed as far as possible in a computer-aided man-ner throughout [EM00; KA01]. In this case, a distinc-tion is to be made between four different levels of in-tegration (cf. KOMFORCE reference modelgraphic).

Examples of model-technical integration are VHDL-AMS18) and MechaSTEP19). MechaSTEP is based onthe STEP20) environment and produces a neutral dataformat for the data exchange of systems of the do-mains of fluid technology, mechanics, electrical engi-neering and control engineering. The prototypicallinking of two simulation programs from multibodysimulation has already been successfully realized; in-stances of implementation exist. One of the futurechallenges is to get international standardization bod-ies to adopt the newly developed approaches to mod-eling [DK00]. There has already been a first stand-ardization as a Publicly Available Specification(PAS 1013).

Modelica21) represents a relatively new, universal ap-proach. The object-oriented language Modelica is afurther development of the language Dymola22) withconcepts of other interdisciplinary descriptive lan-guages. It makes possible the dynamic simulation ofmultidisciplinary systems. The object orientation of-fers the possibility, furthermore, of setting up and us-ing model libraries as a basis for system simulation.

The customary tools for the design of mechatronicsystems can be divided into classes. The individualtool classes are described below.

18) VHDL: hardware descriptive language, extended by languagemeans for the definition of analog and discrete components (VHDL-AMS), for the standardized exchange between simulation environ-ments of different domains (ISO 1076.1 Proposal)19) MechaSTEP: STEP data models for the simulation of mechatronicsystems (PAS 1013)20) STEP (Standard for the Exchange of Product Model Data): datamodels for the consistent description of product data (ISO 10 303)21) Modelica: object-oriented language for the modeling of multidisci-plinary systems, http//:www.modelica.org22) Dymola:descriptive language for the modeling of continuous dyna-mic systems



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Integrationsebenen nach dem KOMFORCE-Referenzmodell *)Die Initiative KOMFORCE (Kommunikations-und Forschungskreis für Integrationstechnologienin Computer Aided Design und Engineering) hatzum Ziel, die für eine spezifische Produktentwick-lung relevanten IT-Werkzeuge zu einem integrier-ten Entwicklungsarbeitsplatz zusammenzuführen.Die Integration erfolgt auf vier Ebenen:

Verfahrenstechnische Ebene: Auf dieser Ebenewerden die Methoden und Werkzeuge ausgewählt,die für eine spezifische Produktentwicklung zumEinsatz kommen sollen. Die einzusetzenden Me-thoden werden auf der Basis von Aussagegüte undZeitaufwand bestimmt. Dazu bietet sich eine ABC-Klassifizierung an. Danach werden die entspre-chenden CAE-Werkzeuge ausgewählt.

Prozesstechnische Ebene: Auf der prozesstechni-schen Ebene wird der aktuelle Stand des Entwick-

lungsvorhabens analysiert, die Definition der Auf-gabenpakete unterstützt und deren Durchführungkontrolliert. Ein Bestandteil dieser Ebene ist dasProzessmanagement. Die Prozessmanagement-komponente plant/steuert den Einsatz der inte-grierten Werkzeuge.

Modelltechnische Ebene: Damit CAE-Werk-zeuge untereinander Informationen austauschenund kooperieren können, müssen sie das gleichekonzeptionelle Verständnis haben. Ziel der modell-technischen Integration ist es, einen für den An-wender transparenten Umgang mit verschiedenenProduktmodellrepräsentationen zu schaffen.

Systemtechnische **) Ebene: Auf dieser Ebenewird ein sicherer und konsistenter Informations-austausch der integrierten CAE-Werkzeuge reali-siert. Dafür muss ein gemeinsames Kommunikati-onsmedium existieren, das die Kommunikation desGesamtsystems gewährleistet.

Quelle: [GGK99]*) Das Referenzmodell entstand im Rahmen des Schwerpunktprogramms „Innovative rechnerunterstützte Konstruktionsprozesse: Integration vonGestaltung und Berechnung“ der Deutschen Forschungsgemeinschaft. **) Mit Systemen sind hier IT-Systeme und nicht mechatronische Systeme im Sinne der Richtlinie gemeint.



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Integration levels in accordance with theKOMFORCE reference model*)The KOMFORCE (Kommunikations- und Forsc-hungskreis für Integrationstechnologien in Com-puter Aided Design and Engineering [communica-tion and research group for integrationtechnologies in computer aided design and engi-neering]) initiative has the aim of bringing togetherthe IT tools relevant for a specific product develop-ment to form an integrated development work-place. The integration takes place on four levels:

Method-technical level: On this level, the meth-ods and tools which are to be used for a specificproduct development are selected. The methods tobe used are determined on the basis of informative-ness and time expenditure. An ABC classificationis appropriate for this. The corresponding CAEtools are selected on this basis.

Process-technical level: On the process-technical

level, the current state of the development projectisanalyzed, the definition of the task packages issupported and their implementation is monitored.One element of this level is process management.The process management component plans/con-trols the use of the integrated tools.

Model-technical level: In order that CAE toolscan exchange information and cooperate with oneanother, they must have the same conceptual un-derstanding. The aim of model-technical integra-tion is to create an environment with various prod-uct model representations that is transparent for theuser.

System-technical**) level: On this level, a reliableand consistent information exchange of the inte-grated CAE tools is realized. For this purpose, acommon communication medium which ensuresthe communication of the overall system must ex-ist.

Source: [GGK99]*) The reference model originated from the priority programme ”Innovative rechnerunterstützte Konstruktionsprozesse: Integration von Ge-staltung und Berechnung“ [innovative computer-aided construction processes: integration of creation and calculation] of the Deutsche For-schungsgemeinschaft [German research society].**) What is meant here by systems are IT systems and not mechatronic systems as specified by the guideline.



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Werkzeuge zur Beschreibung der AnforderungenAm Anfang einer Produktentwicklung bestehenmeist nur vage Vorstellungen, was ein Produkt leistensoll und kosten darf. Diese Vorstellungen werden inForm von Forderungen und Wünschen konkretisiertund in der Anforderungsliste bzw. im Lastenheftmeist in textueller Form dokumentiert.

Spezielle Werkzeuge zur Anforderungsbeschreibungunterstützen das systematische Erfassen und Glie-dern von Anforderungen, stellen Checklisten zur Ver-fügung und gewährleisten eine einheitliche Doku-mentation. Sofern die Anforderungen zu diesem Zeit-punkt bereits näher spezifiziert werden können (z.B.durch Vorgaben des Kunden), werden zusätzlichWerkzeuge eingesetzt, die auch beim Systementwurfzum Einsatz kommen. Dies sind z.B. geometrischeEigenschaften wie Bauräume oder Anschlussmaße(Beschreibung mit CAD-Werkzeugen), funktionaleEigenschaften (Beschreibung mit Werkzeugen zurVerhaltensmodellierung) sowie gewünschte Abläufein Form von Anwendungsfällen (Beschreibung mitAnwendungsfalldiagrammen). Die Beschreibung derAnforderungen kann unter Umständen bis zur so ge-nannten ablauffähigen Spezifikation der Anforderun-gen führen, mit der gewünschte Eigenschaften simu-liert werden können.

Werkzeuge zur Verwaltung der AnforderungenDie Notwendigkeit schneller Anpassungen an sichwandelnde Kundenwünsche, steigende Anforderun-gen an die Produkteigenschaften und der allgemeineKostendruck zwingen zu einer möglichst weitgehen-den Wiederverwendung von Entwicklungsergebnis-sen. Um die Wiederverwendbarkeit zu gewährleisten,ist eine strukturierte, nachvollziehbare und vollstän-dige Dokumentation der Anforderungen an das Pro-dukt von großer Bedeutung. Aber auch während deslaufenden Entwicklungsprojekts ist es wichtig zuwissen, welche Forderungen welche Auswirkungenauf die Produktgestaltung haben und wer wann wel-che Forderungen eingebracht hat. Hierfür kommenWerkzeuge zur Anforderungsverwaltung (synonymAnforderungsmanagement, Requirement Enginee-ring, Requirement Management) zum Einsatz. Sieunterstützen das Änderungsmanagement von Anfor-derungen, die Zuordnung zu Projekten und Verant-wortlichen bis hin zu formalen Überprüfungen aufVollständigkeit und Widerspruchsfreiheit.

Werkzeuge zur FunktionsmodellierungZiel der Funktionsmodellierung ist, die Entwurfsauf-gabe auf lösungsneutraler Ebene zu formulieren. Ausder Gesamtaufgabe einer Problemstellung lässt sichdie Gesamtfunktion für das System ableiten. Diese

Tools for describing therequirementsAt the beginning of the development of a productthere are usually only vague ideas as to what a prod-uct is intended to do and may cost. These ideas areconcretized in the form of requirements and wishesand documented, usually in textual form, in the re-quirements list or in the specification.

Special tools for the description of requirements sup-port the systematic recording and classifying of re-quirements, provide check lists and ensure consistentdocumentation. If the requirements can already bespecified in more detail at this time (for example byprecepts specified by the customer), tools which arealso used in the system design are additionally used.Examples of these are geometrical properties such asinstallation spaces or connection dimensions (de-scription with CAD tools), functional properties (de-scription with tools for behavior modeling) and de-sired sequences in the form of application cases(description with application case diagrams). The de-scription of requirements may in some circumstanceslead to the so-called executable specification of re-quirements, with which desired properties can besimulated.

Tools for managing requirementsThe necessity for rapid adaptations to changing cus-tomer requirements, increasing requirements onproduct properties and the general pressure of costsmake it necessary for development results to be re-used as much as possible. In order to ensure that thatthey can be reused, a structured, comprehensible andcomplete documentation of the requirements im-posed on the product is of great significance. How-ever, it is also important to know during the develop-ment project that is in progress which requirementshave which effects on the creation of the product andwho has introduced which requirements and when.Tools for requirement management (synonymouswith requirement engineering) are used for this. Theysupport the management of changes to requirements,the assignment to projects and persons responsiblethrough to formal checks for completeness and free-dom from contradictions.

Tools for function modelingThe aim of function modeling is to formulate the de-sign task on a solution-neutral level. The overallfunction for the system can be derived from the over-all task of a problem being addressed. This overall



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


wird weiter in Teilfunktionen zerlegt, die Teilfunk-tionen werden zur Funktionsstruktur verknüpft. ZurRepräsentation einer Funktion wird im Allgemeineneine Blockdarstellung (schwarzer Kasten, black box),zur Beschreibung der Verknüpfungen werden Fluss-größen (Stoff, Energie, Information) verwendet. MitHilfe von so genannten „System-Engineering-Werk-zeugen“ werden Soll- und Fehlverhalten von Funkti-onen und ihre Ein- und Ausgänge spezifiziert. Damitkönnen frühzeitige Untersuchungen zur Kompatibili-tät von Funktionen, Fehlerdiagnosen und Fehlermög-lichkeits- und Einflussanalysen (FMEA) durchge-führt werden. Der Übergang von der reinen Funkti-onsmodellierung (lösungsneutral, Beschreibung desSoll-Verhaltens) zur Prinziplösungsmodellierung(Zuordnung von Wirkprinzipien, physikalischenGrößen und Lösungselementen) ist fließend. Gefun-dene Lösungen können mit den gleichen Werkzeugenfrühzeitig evaluiert werden [GM01; MG02].

CAD-WerkzeugeCAD-Systeme ermöglichen die Modellierung derGestalt des zukünftigen Produkts. Grundlage bildenz.B. geometrische Anforderungen und erste gestalt-bestimmende Festlegungen, um ein bestimmtes Ver-halten zu erzielen. Durch die Auswahl geeigneterWirkprinzipien und Lösungselemente sowie die Be-stimmung der Geometrie-, Technologie- und Werk-stoffparameter wird die Gestalt zunehmend konkreti-siert (Grobdimensionierung). Im Wechselspiel mitBerechnungs- und Analyseverfahren (siehe FEM,MKS) werden die Parameter optimiert. Hierfür stelltdas CAD-System Abmessungen und ableitbare Grö-ßen zur Verfügung. Ergebnis des domänenspezifi-schen Entwurfs ist ein vollständiges CAD-Modelldes Produkts und seiner Komponenten, das neben ge-ometrischen Informationen (Abmessungen, Toleran-zen etc.) auch Strukturinformationen (Baustruktur,Stücklisten) und Fertigungsinformationen umfasst.

FEM-WerkzeugeFür detaillierte Analysen im Bereich der Strukturme-chanik und -dynamik, Elektromagnetik, Fluiddyna-mik, Akustik oder Temperaturfelder kommt die FiniteElemente Methode (FEM) zum Einsatz. Sie ist einVerfahren, das allgemeine Feldprobleme näherungs-weise löst. Dazu wird das betrachtete Kontinuumdurch eine endliche (finite) Anzahl kleiner Elementeangenähert (diskretisiert). Untersucht werden kannbeispielsweise, wie sich ein Bauteil unter statischerLast verformt und wo Spannungen auftreten (z.B. zumFestigkeitsnachweis); aber auch Analysen dynami-scher und nichtlinearer Vorgänge können durchgeführtwerden (z.B. Schwingungsanalyse, Crash-Analyse).

function is broken down further into subfunctions,the subfunctions are linked together to form the func-tion structure. For the representation of a function,generally a block representation (black box) is used,for the description of the interlinkages, flow variables(material, energy, information) are used. With the aidof so-called system engineering tools, desired behav-ior and misbehavior of functions and their inputs andoutputs are specified. Consequently, early investiga-tions with respect to the compatibility of functions,error diagnostics and failure mode and effects analy-sis (FMEA) are carried out. The transition from purefunction modeling (solution-neutral, description ofthe desired behavior) to solution-in-principle mode-ling (assignment of operating principles, physicalvariables and solution elements) is smooth. Solutionsfound can be evaluated with the same tools at an earlytime [GM01; MG02].

CAD toolsCAD systems make it possible to model the form ofthe future product. Geometrical requirements and in-itial form-determining stipulations form the basis forexample for achieving a specific behavior. By the se-lection of suitable operating principles and solutionelements and also the determination of the parame-ters relating to geometry, technology and materials,the form is increasingly concretized (rough dimen-sioning). In interaction with methods of calculationand analysis (see FEM, MBS), the parameters are op-timized. The CAD system provides dimensions andderivable variables for this. The result of the domain-specific design is a complete CAD model of the prod-uct and its components, which along with geometri-cal information (dimensions, tolerances, etc.) alsocomprises structure information (building structure,parts lists) and production information.

FEM toolsFor detailed analyses in the area of structure mechanicsand dynamics, electromagnetics, fluid dynamics,acoustics or temperature fields, the Finite ElementMethod (FEM) is used. It is a method which solves thegeneral field problems by approximation. For this pur-pose, the continuum considered is approximated by afinite number of small elements (discretized). It can beinvestigated, for example, how a component deformsunder a static load and where stresses occur (for exam-ple for demonstrating strength); however, analyses ofdynamic and nonlinear processes can also be carriedout (for example vibration analysis, crash analysis).The required geometry can generally be adopted di-



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Die benötigte Geometrie kann in der Regel direkt aus3D-CAD-Systemen übernommen werden. Die FEM-Analyse ist im Wechselspiel mit der Gestaltung vonBauteilen und Baugruppen vorzunehmen.

BEM-WerkzeugeNeben der Methode der Finiten Elemente ist dieBoundary Element Method (BEM; dt. Rand-elementemethode) ein weiteres wichtiges Diskreti-sierungsverfahren zur Berechnung von Anfangs-/Randwertproblemen, z.B. für die Untersuchung desFluidverhaltens. Die BEM hat gegenüber der FEMden Vorteil, dass nur die Oberfläche der betrachtetenStruktur zu diskretisieren ist, und nicht deren Volu-men. Dazu wird der Rand in Elemente unterteilt undes werden Randknoten eingeführt. Die Randelementewerden mit Ansatzfunktionen versehen. Hauptein-satzgebiete sind die Elektrostatik, Akustik, Hydro-mechanik und Thermodynamik.

Werkzeuge zur Simulation von MehrkörpersystemenDie Simulation von Mehrkörpersystemen (MKS)wird eingesetzt, um das Bewegungsverhalten kom-plexer Systeme zu untersuchen, die aus einer Vielzahlgekoppelter beweglicher Teile bestehen. Das Anwen-dungsspektrum reicht von der Überprüfung des Be-wegungsverhaltens einzelner, aus wenigen Bauteilenbestehender Baugruppen über die Identifikation vonKollisionsproblemen durch Bauteilbewegungen bishin zum Bewegungsverhalten eines Gesamtsystems(vgl. Bild 3-11). Ferner können mittels MKS-Simu-lation Kräfte und Momente bestimmt werden, diedurch Bewegungen auf das System einwirken. DieGestaltdaten können ebenfalls in der Regel aus einem3D-CAD-System übernommen werden bzw. werdenals vereinfachte 3D-Modelle mit Hilfe eines im MKS-System integrierten Volumenmodellierers erzeugt.Einige 3D-CAD-Systeme verfügen auch über inte-grierte Module für MKS-Untersuchungen [Hil83].

Werkzeuge zum fluidtechnischen EntwurfMit Hilfe von Computational Fluid Dynamics23)(CFD)-Werkzeugen können thermo- und fluiddyna-mische Vorgänge in einem abgegrenzten durch- bzw.umströmten Gebiet (Kontrollraum) analysiert wer-den, um sie zielgerichtet beeinflussen zu können.Eine CFD-Analyse liefert qualitative Aussagen (z.B.Art, Ausbreitung und Wirkung strömungsmecha-nischer Effekte) und quantitative Aussagen (Zahlen-werte für thermo-fluiddynamische Zustandsgrößen).Anwendungsgebiete sind u.a. [GEK01]:

23) Computational Fluid Dynamics: Gebräuchlicher englischer Begrifffür die numerische Strömungssimulation; Fluid ist der Oberbegriff fürFlüssigkeiten und Gase; Fluiddynamik (auch als Strömungsmechanikoder Strömungslehre bezeichnet) ist die Lehre von den Bewegungender Fluide unter den Einflüssen von Kräften.

rectly from 3D-CAD systems. FEM analysis is to beperformed in interaction with the creation of compo-nents and subassemblies.

BEM toolsAlong with the Finite Element Method, the BoundaryElement Method (BEM) is a further important discre-tizing method for the calculation of initial-/boundary-value problems, for example for the investigation offluid behavior. BEM has the advantage over FEMthat only the surface of the structure being consideredhas to be discretized, and not its volume. For this pur-pose, the boundary is subdivided into elements andboundary nodes are introduced. The boundary ele-ments are provided with basis functions. Main areasof use are electrostatics, acoustics, hydromechanicsand thermodynamics.

Tools for the simulation of multibodysystemsThe simulation of multibody systems (MBS) is usedto investigate the movement behavior of complex sys-tems which comprise a large number of coupled mov-able parts. The spectrum of applications ranges fromchecking the movement behavior of individual sub-assemblies, comprising few components, through theidentification of collision problems caused by compo-nent movements to the movement behavior of anoverall system (cf. Figure 3-11). Furthermore,forces and moments which act on the system due tomovements can be determined by means of MBS sim-ulation. The form data can likewise generally beadopted from a 3D-CAD system or be generated assimplified 3D models with the aid of a volume mod-eler integrated in the MBS system. Some 3D-CADsystems also have integrated modules for MBS inves-tigations [Hil83].

Tools for fluid-technical designWith the aid of Computational Fluid Dynamics23)(CFD) tools, thermodynamic and fluid-dynamicprocesses in a bounded area through or around whicha flow passes (control space) can be analyzed to allowthem to be influenced in a targeted manner. A CFDanalysis produces qualitative statements (for exampletype, extent and effect of flow-mechanical effects)and quantitative statements (numerical values forthermo- fluid-dynamic state variables). Applicationareas include [GEK01]:

23) Computational Fluid Dynamics: The customary English term fornumerical flow simulation; fluid is the generic term for liquids andgases; fluid dynamics (also referred to as flow mechanics or flow the-ory) is the theory of the movements of fluids under the influences offorces.



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Bild 3-11. Ergebnisdarstellung der Kinematikanalyse einesBelegdruckersRechts sind Beschleunigung, Geschwindigkeit und Position des Druckbalkens dargestellt [GL00].

Fig. 3-11. Representation of the results of kinematic analysis ofa document printerRepresented on the right are acceleration, speed and position ofthe compressed beam [GL00].

Bild 3-12. Reglergrundstruktur für einen Mehrkoordinatenantrieb (vgl. Beispiel Abschnitt 4.4) [Kov01]



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


• Kraftfahrzeugtechnik: Außenaerodynamik, Kli-matisierung des Fahrgastraums, Strömung undVerbrennung im Motor etc.

• Luft- und Raumfahrttechnik: Außenaerodyna-mik, Luftfahrtantriebe, Raketenantriebe etc.

• Energietechnik: Kraftwerkskomponenten wieDampferzeuger, Feuerungen, Kondensatoren,Dampfturbinen, Pumpen etc.

Darüber hinaus unterstützen Werkzeuge die Modell-bildung fluidtechnischer Systeme auf topologischerEbene. Die Modellerstellung erfolgt interaktiv unterVerwendung von Modellbibliotheken.

Werkzeuge zum regelungstechnischen EntwurfDie meisten Werkzeuge zum regelungstechnischenEntwurf setzen auf der Blockdiagrammdarstellungauf. Jeder Block hat ein genau definiertes Ein-/Aus-gangsverhalten. Die Verknüpfungen zwischen denBlöcken erfolgt durch rückwirkungsfreie gerichteteSignalleitungen. Durch die hierarchische Anordnungder Funktionsblöcke können auch komplexere Struk-turen anschaulich modelliert werden. Im Rahmen desSystementwurfs sind die aus der Modellierung derAnforderungen stammenden Modelle zu konkretisie-ren und zu partitionieren. Die Systemstruktur des zu-künftigen Produkts wird dabei immer detaillierter.Die Zuordnung einzelner Funktionen zu den späterenModulen des mechatronischen Produkts wird prä-ziser. Auch die erwarteten Rückwirkungen aus derBetrachtung der Fertigungsmöglichkeiten werden indie Modelle eingearbeitet. Das Ergebnis ist ein weit-gehend vollständiges, mit Blick auf die spätere Rea-lisierung partitioniertes Funktionsmodell des zu ent-wickelnden Produkts.

• automotive engineering: exterior aerodynamics,climatic control of the passenger compartment,flow and combustion in the engine, etc.

• aeronautical and aerospace engineering: exterioraerodynamics, aircraft engines, rocket engines,etc.

• energy technology: components of power genera-ting plants such as steam generators, furnaces,condensers, steam turbines, pumps, etc.

In addition, tools support the modeling of fluid-tech-nical systems on the topological level. Models arecreated interactively by using model libraries.

Tools for control-engineering designMost tools for control-engineering design are basedon block diagram representation. Each block has aprecisely defined input/output behavior. The links be-tween the blocks are provided by reaction-free direc-tional signal lines. The hierarchical arrangement ofthe function blocks allows even relatively complexstructures to be modeled in a clearly presented way.As part of system design, the models originating fromthe modeling of requirements are to be concretizedand partitioned. As this happens, the system structureof the future product becomes ever more detailed.The assignment of individual functions to the latermodules of the mechatronic product becomes moreprecise. The expected reactions from the considera-tion of the production possibilities are incorporated inthe models. The result is a largely complete functionmodel of the product to be developed that is parti-tioned with a view to the later realization.

Fig. 3-12. Basic controller structure for a multicoordinate drive (cf. example of Section 4.4) [Kov01]



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Werkzeuge für den ElektronikentwurfElektronik erfasst Kommando- und Sensorsignale,verarbeitet diese und gibt Meldungen und Aktoran-steuersignale aus. Die Elektronik kann die geforderteAnwenderfunktion in Form fest verdrahteter ana-loger oder auch digitaler Signalverarbeitung direktabbilden. Sie kann darüber hinaus Plattformenbilden, bei denen die Anwenderfunktionen ganz oderteilweise in programmierbaren analogen und digita-len Bausteinen realisiert werden. Die Elektronik kannaußerdem Plattformen bilden, auf denen Anwender-funktionen mehr oder weniger vollständig durch An-wendersoftware programmiert werden.

Die Entwicklung analoger bzw. digitaler Schaltungenunterstützen so genannte EDA24)-Programme, dieauf den Entwurf und die Simulation elektronischerSchaltungen sowie die Layout-Erstellung spezialisi-ert sind. Die geforderten Funktionen werden meist inForm von Stromlaufplänen oder über VHDL-Listenbeschrieben, aus denen sich über weitgehend autom-atisierte Prozesse die Fertigungsdaten für die Leiter-platten und die darauf verwendeten programmier-baren Bausteine erzeugen lassen. Für eine effizienteEntwicklung der Elektronik mechatronischer Sys-teme ist es wichtig, dass es eine möglichst automa-tisierte Ableitung der Stromlaufpläne oder VHDL-Listen aus dem Systemmodell gibt. Dazu muss beimSystementwurf die Partitionierung der verschiedenenFunktionen so weit getrieben werden, dass jedesModul des Systemmodells auf einer eigenen Elek-tronik-Komponente, also z.B. als Analogmodul, alsFPGA25) oder als Mikroprozessor mit Anwendersoft-ware abgebildet werden kann.

Werkzeuge für den ElektrikentwurfDie Elektrik verbindet alle elektrischen Komponen-ten eines mechatronischen Produkts miteinander. Siestellt die Versorgung aller elektrischen Komponentenmit elektrischer Energie sicher. Auch diese für einensicheren Betrieb unverzichtbaren Funktionen werdenzweckmäßigerweise schon im Systemmodell model-liert. Die Erzeugung der für die Verdrahtung nötigenStromlaufpläne könnte dann automatisiert aus demSystemmodell erfolgen.

Die Verlegung der elektrischen Leitungen zwischenden verteilten elektrischen bzw. elektronischenModulen hat Rückwirkungen auf die geometrischenEigenschaften des Produkts und muss in das CAD-Modell eingearbeitet werden.

24) EDA: Electronic Design Automation25) FPGA: Field-Programmable Gate Arrays

Tools for electronic designElectronics pick up command and sensor signals,process them and output messages and actor activa-tion signals. Electronics can directly replicate the re-quired user function in the form of hard-wired analogor digital signal processing. They can additionallyform platforms with which the user functions are re-alized entirely or partly in programmable analog anddigital modules. Electronics can also form platformson which user functions are programmed more or lesscompletely by user software.

The development of analog or digital circuits is sup-ported by so-called EDA24) programs, which are spe-cialized for the design and simulation of electroniccircuits and layout creation. The required functionsare usually described in the form of circuit diagramsor by means of VHDL lists, from which the produc-tion data for the printed circuit boards and the pro-grammable modules used on them can be generatedby means of largely automated processes. For an effi-cient development of the electronics of mechatronicsystems, it is important that there is a means that is asautomated as possible for deriving the circuit dia-grams or VHDL lists from the system model. For thispurpose, the partitioning of the various functionsmust be taken so far in the system design that eachmodule of the system model can be replicated on anelectronic component of its own, that is for exampleas an analog module, as FPGA25) or as a micropro-cessor with user software.

Tools for electric designElectrics connect all the electrical components of amechatronic product to one another. They ensure thesupply of all the electrical components with electricalenergy. It is expedient for these functions, which areindispensable for reliable operation, also to be al-ready modeled in the system model. The generationof the circuit diagrams necessary for wiring couldthen be performed in an automated manner from thesystem model.

The laying of the electrical lines between the distrib-uted electrical or electronic modules causes reactionson the geometrical properties of the product and mustbe incorporated into the CAD model.

24) EDA: Electronic Design Automation25) FPGA: Field-Programmable Gate Arrays



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Werkzeuge für den SoftwareentwurfSoftware steht im vorliegenden Zusammenhang fürEmbedded Software. Diese wird eingeteilt in Be-triebssystemsoftware, wie Laufzeitsteuerung undHardwaretreiber, und Anwendersoftware. Die Be-triebssystemsoftware kann wie ein spezielles Hard-waremodul betrachtet werden. Es stellt sicher, dassdie Anwendersoftware in die Zielelektronik geladenund in den geforderten Zeitintervallen bearbeitetwird, dass die Anwendersoftware Zugriff auf die Da-ten der angeschlossenen Sensoren hat und dass dieAnwendersoftware alle notwendigen Ausgaben aus-führen kann. Die Anwendersoftware bestimmt danndie Funktionen der durch Mikroprozessor gesteuer-ten Elektronikmodule, mit denen Steuer- und Rege-lungsfunktionen realisiert werden.

Im Rahmen der vorliegenden Richtlinie ist besondersdie Entwicklung der Anwendersoftware relevant. Diedort zu realisierenden Funktionen werden beim Sys-tementwurf definiert, modelliert und getestet. So ge-nannte CASE26)-Tools bieten grafische Editoren, mitderen Hilfe die Software modelliert und die Konsis-tenz zwischen Programmteilen sichergestellt werdenkann. Bei der folgenden formalen Umsetzung der sodefinierten Funktion in den in der Zielelektronik ab-lauffähigen Code gibt es keine weitere inhaltlicheVeränderung der Funktion. Deshalb ist heute verbrei-tet der Wunsch zu beobachten, den ablauffähigenCode durch eine automatisierte bzw. automatischeCode-Generierung direkt aus der in der Systemsimu-lation modellierten Anwendersoftware zu erzeugen.Dies schließt alle nötigen Umsetzungs- und Compi-lerprozesse ein. Dies wird durch spezielle Entwurfs-umgebungen unterstützt.

Werkzeuge zur Hardware-in-the-Loop-SimulationSobald einzelne Komponenten realisiert sind, müssendiese in einem ihrer späteren Umgebung nachemp-fundenen Umfeld getestet werden. Für diese Verifi-kation bzw. Validierung wird eine HIL-Umgebungaufgebaut, die der zu testenden Komponente bzw.dem zu testenden Produkt die reale Umgebung durcheine Echtzeitsimulation vorspiegelt (Bild 3-13).

Im Laufe der Entwicklung sind unterschiedlicheHIL-Umgebungen für Komponenten, Gruppen vonKomponenten und das Endprodukt aufzubauen. Beiden HIL-Tests werden idealerweise die gleichenTests durchgeführt wie bei den Offline-Tests.

26) CASE: Computer Aided Software Engineering

Tools for software designIn the present context, software stands for embeddedsoftware. This is divided into operating system soft-ware, such as run-time control and hardware drivers,and user software. The operating system software canbe regarded as a special hardware module. It ensuresthat the user software is loaded into the target elec-tronics and is processed in the required time intervals,that the user software has access to the data of theconnected sensors and that the user software can ex-ecute all the necessary outputs. The user softwarethen determines the functions of the microprocessor-controlled electronic modules, with which open-loopand closed-loop control functions are realized.

Within the present guideline, the development of usersoftware is particularly relevant. The functions to berealized there are defined, modeled and tested in thesystem design. So-called CASE26) tools offer graphiceditors, with the aid of which the software can bemodeled and the consistency between parts of a pro-gram can be ensured. In the following formal conver-sion of the function defined in this way into the codethat can be executed in the target electronics there isno further change in the content of the function.Therefore, today there is a widely observed desire togenerate the executable code by an automated or au-tomatic code generation directly from the user soft-ware modeled in the system simulation. This includesall necessary conversion and compiler processes.This is supported by special design environments.

Tools for hardware-in-the-loopsimulationAs soon as individual components are realized, theymust be tested in an environment resembling theirlater environment. For this verification or validation,an HIL environment is set up, which uses real-timesimulation to simulate the real environment for thecomponent or the product to be tested (Figure 3-13).

In the course of the development, different HIL envi-ronments are to be set up for components, groups ofcomponents and the end product. In the HIL tests,ideally the same tests as in the offline tests are carriedout.

26) CASE: Computer Aided Software Engineering



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49


Werkzeuge zur Validierung des Produktes im realen UmfeldIn der letzten Stufe wird überprüft, ob sich das kom-plette aus seinen Komponenten zusammengesetztereale Produkt in seinem realen Umfeld unter realenBetriebsbedingungen wie beabsichtigt verhält. ZurUnterstützung existieren Werkzeuge, die Messdateneines realen Systems in Echtzeit aufnehmen und ver-arbeiten können. Besteht das Produkt diese Validie-rung, steht einer Markteinführung nichts mehr imWege.

Produktdatenmanagement-SystemeIm Laufe der Produktentwicklung wird eine Vielzahlvon Informationen an verschiedenen Stellen im Un-ternehmen verarbeitet. Die Informationsmenge istnicht mehr überschaubar und der Zugriff nicht trans-parent, das heißt der Entwickler muss genau wissen,wo die Informationen zu finden sind. Aufgabe derProduktdatenmanagement-Systeme (PDMS) ist es,alle relevanten Daten über ein Produkt und die Pro-zesse der Produktentwicklung zu verwalten. DieFunktionalität moderner PDM-Systeme umfasst Pro-duktstrukturmanagement (Modell der Beziehungenzwischen Baugruppen und Einzelteilen, z.B. nachFertigungs- oder Montagegesichtspunkten), Doku-mentenmanagement (Konsistenzsicherung, Zugriffs-rechte etc.), Konfigurationsmanagement (Versions-verwaltung von Produktstrukturständen) und dieKlassifikation von Produktdaten. Neben der Verwal-tung von Produktdaten unterstützen PDM-Systemeauch die Planung, Steuerung und Überwachung vonAbläufen (Prozessmanagement) [GEK01].

Tools for validating the product in the real environmentIn the final stage, it is checked whether the completereal product, made up from its components, behavesin its real environment under real operating condi-tions in the way intended. Tools which can record andprocess measurement data of a real system in realtime exist to provide support. If the product passesthis validation, there is nothing preventing it from be-ing launched on the market.

Product data management systemsIn the course of product development, a considerableamount of information is processed at various placesin the company. The volume of information no longerallows an overview and access is not transparent, i.e.the developer must know exactly where informationis to be found. The task of the product data manage-ment system (PDMS) is to manage all relevant dataon a product and the processes of product develop-ment. The functionality of modern PDM systemscomprises product structure management (model ofthe relationships between subassemblies and individ-ual parts, for example from production or assemblyaspects), documentation management (ensuring con-sistency, rights of access, etc.), configuration man-agement (version management of product structurestates) and the classification of product data. Apartfrom the management of product data, PDM systemsalso support the planning, control and monitoring ofsequences (process management) [GEK01].

Bild 3-13. HIL-Umgebung für das Feder-/Neigemodul (vgl.Beispiel Abschnitt 4.3) [LLJ00]

Fig. 3-13. HIL environment for the spring/tilting module (cf.example of Section 4.3) [LLJ00]



A&

I-Nor

men

abon

nem

ent -

BA

SF A

ktie

nges

ells

chaf

t - K

d.-N

r.130

9388

- A

bo-N

r.000

0171

9/00

1/00

4 - 2

005-

01-0

5 13

:16:

49

Documents

Estrategia para emprender un proyecto