Mechatronische Ausbildung mit Hightech

Mechatronische Ausbildung mit Hightech-Spielzeugen – Restrukturierung einer
mechatronischen Rennbahn
"In Deutschland gibt es nach Aussagen von
Fachzeitschriften zu wenige technische
Nachwuchskräfte. Damit die Zahl der
Technikbegeisterten steigt, setzt ITQ schon seit
Jahren darauf, mit Hightech-Spielzeugen jung und
alt zu begeistern. Eines der Projekte, an dem sechs
Studenten im Team arbeiteten, hatte zum Ziel, eine
„Einzelkind-taugliche Rennbahn“ zu erarbeiten."
- Dr.-Ing. Rainer Stetter, ITQ GmbH (www.itq.de)
Die Aufgabe:
Steigerung der Technikbegeisterung mit Hilfe von Hightech-Spielzeugen für jung und alt in der mechatronischen Ausbildung
Die Lösung:
Vollständige
Kundenlösung
lesen
Gestaltung eines Hightech-Spielzeugs in Form einer "Einzelkind-tauglichen Rennbahn"
Autor(en):
Dr.-Ing. Rainer Stetter - ITQ GmbH (www.itq.de)
Diese Kundenlösung wurde im Tagungsband 2012 (http://www.amazon.de/Virtuelle-Instrumente-Praxis-2012-Embedded-Systeme/dp/3800734125/) des
Technologie- und Anwenderkongress "Virtuelle Instrumente in der Praxis" (http://www.ni.com/germany/vip) veröffentlicht.
Sie haben Fragen zu dieser NI-Lösung oder zu unseren Produkten? Zum Kontaktformular (http://www.natinst.de/services/beratung_nisolutions.php)
Kurzfassung
In vielen Fachzeitschriften konnte man in den letzten Monaten immer wieder Klagen hören, dass es viel zu wenig technische Nachwuchskräfte gibt. In der
Bundesrepublik Deutschland beispielsweise gibt es Hochrechnungen, dass derzeit ca. 100.000 Ingenieure fehlen. Obwohl dieser Trend nicht neu ist und
folglich die Jobchancen für junge Ingenieure gut sind, entscheiden sich dennoch viele junge Menschen gegen ein Ingenieurstudium. Damit die Zahl der
Technikbegeisterten steigt, setzt ITQ schon seit Jahren darauf, mit Hightech-Spielzeugen jung und alt zu begeistern. Das neueste Projekt, an dem in den
letzten Monaten sechs Studenten im Team arbeiteten, hatte zum Ziel, eine „Einzelkind-taugliche Rennbahn“ zu erarbeiten.
Ausgangssituation
Grundlage dieses Projekts ist eine handelsübliche Slot-Car-Rennbahn. Im Gegensatz zu einer handelsüblichen Rennbahn soll man nicht nur wie üblich
gegen eine andere Person, sondern auch gegen einen Computer-Gegner fahren und die Rennergebnisse wie Rundenzeiten und Bestenlisten
visualisieren können. Damit der „Computer-Gegner“ ähnlich wie ein Mensch vor Kurven und Engstellen abbremst, müssen die Position und die
Geschwindigkeit des Fahrzeugs sensorisch erfasst werden. Zur Bestimmung dieser Informationen wurden in die Bahn (mit einer Bahnlänge von ca. 6,4 m
pro Spur) insgesamt 104 Sensoren verbaut. Zum Einsatz kommen dabei Miniatur-Gabellichtschranken, die detektieren, ob die Finne des Fahrzeugs den
Sensor passiert. Um die Geschwindigkeit auf 5 % genau zu ermitteln, muss der Eintritt der Finne in die Lichtschranke bei einer maximalen
Fahrzeuggeschwindigkeit von 3,5 m/s innerhalb von 120 µs erfasst werden. Auf Basis der Eingangsdaten bzgl. Position und Geschwindigkeit musste eine
echtzeitfähige Reglerstruktur mit einer garantierten Antwortszeit unter 10 ms aufgebaut werden. Wie man anhand der technischen Daten sieht, klingt die
grundlegende Anforderung zunächst einmal sehr spielerisch, endet aber dann doch sehr schnell in einer handfesten mechatronischen Problemstellung.
Mit derartigen „Lern-Spaß-Projekten“ sollen aber nicht nur „lustige“ Ideen in die Tat umgesetzt, sondern auch moderne Entwicklungsmethoden auf eine
„nette“ Art vermittelt werden.
Eine in der Literatur häufig genannte Entwicklungsmethodik ist das sogenannte V-Modell. Eine der prinzipiellen Ideen des V-Modells ist, dass es in einem
Projekt verschiedene Rollen gibt, die in speziellen Phasen des Projekts zum Tragen kommen. Dieses Rollenmodell theoretisch zu vermitteln, ist
erfahrungsgemäß sehr schwierig. Deshalb wurde in dem Projekt jedem Student eine (entwicklungsphasen-)spezifische Rolle gegeben. So war ein
Student rein zur Erfassung der Anforderungen, ein weiterer zur Lösungsspezifikation und ein dritter zur Spezifikation der Tests verantwortlich.
Zur Umsetzung der funktionalen Anforderungen wurden zwei völlig unterschiedliche Technologien ausgewählt. Durch den Einsatz von zwei
verschiedenen Steuerungsplattformen sollte in dem Projekt gezeigt werden, dass durch detaillierte Spezifikation der Anforderungen und der Beschreibung
der technischen Aufgabenstellung eine hardwareunabhängige Implementierung wesentlich vereinfacht wird. Der Wunsch nach einer Unabhängigkeit vom
Hardwarehersteller ist in der Industrie ein stets gehegter, aber selten realisierter Wunsch. Um die Hardwareunabhängigkeit zu demonstrieren, setzte einer
der verbleibenden Studenten eine SPS mit zusätzlichen schnellen Eingangsmodulen von Phoenix Contact ein. Der zweite „Implementierer“ setzte NI
LabVIEW (http://www.ni.com/labview/buy/d/) mit FPGA-Modulen (http://www.ni.com/labview/fpga/) von National Instruments ein. Zur Visualisierung des
Rennens auf einem Monitor wurde eine Java-basierte Lösung eingesetzt, die durch den sechsten Studenten realisiert wurde. In Bild 1 ist die
Rollenverteilung anhand des V-Modells dargestellt.
1/6
www.ni.com
Bild 1: Verteilung der Rollen, veranschaulicht am V-Modell
Die Aufgabe des Anforderungsspezifikateurs war die industrietypisch grobe Vorgabe: „Entwickle eine einzelkindtaugliche Rennbahn“ weiter
runterzubrechen. Wie in realen Projekten stellte es sich heraus, dass man auf Basis einer groben Aufgabenstellung allein noch kein System entwickeln
kann. Während in realen Projekten dann der „gemeine“ Ingenieur doch gerne dazu neigt, das mühsame Nachfassen und Detaillieren von Anforderungen
durch ein intensives Trial-and-Error-Vorgehen in der Umsetzung und Testphase zu kompensieren, wurde dies in dem Rennbahnprojekt dadurch
verhindert, dass die Note des Studenten von der Güte und Vollständigkeit der erfassten Anforderungen abhing.
Zur Erfassung der Anforderungen und auch für die weiteren Projektphasen wurde eine Methodik eingesetzt, die an der TU München in der Vorlesung
„Mechatronische Entwicklungsprojekte in der Praxis“ gelehrt wird und auf den VDMA-Leitfäden Systemspezifikation und SW-Qualitätssicherung basiert.
Damit die Anforderungen an ein mechatronisches System sauber spezifiziert werden können, empfiehlt es sich, das zu beschreibende System ähnlich wie
ein rein mechanisches System gewissermaßen aus verschiedenen Blickwinkeln zu betrachten. Konkret bedeutet dies, dass das System aus einer rein
funktionalen Sicht und einer „haptischen“ Sicht betrachtet wurde. In Bild 2 ist der Funktionsstrukturbaum dargestellt, in dem hierarchisch geordnet die
erforderlichen Anforderungen zusammengefasst sind.
Bild 2: Funktionaler Strukturbaum
Auf Basis dieser Strukturdiagramme wurden dann die Anforderungen weiter detailliert. Insgesamt wurden dabei mehr als 140 Anforderungen im Detail
spezifiziert. Diese Anforderungen wurden in einer Anforderungsliste aufgenommen und hinsichtlich deren Status genau verfolgt. Mögliche Stati sind offen
(= sehr grob spezifiziert), vorgeschlagen (= Wert vorgegebenen, aber noch nicht freigegeben), spezifiziert (= Wert freigegeben) sowie gestrichen
(Anforderung verworfen). Den zeitlichen Verlauf der Anforderungen sowie den jeweiligen Umsetzungsgrad, basierend auf den beiden unterschiedlichen
Lösungsansätzen Phoenix Contact und National Instruments, ist den folgenden Übersichten zu entnehmen.
2/6
www.ni.com
Bild 3: Status der Anforderungen, Status der Umsetzung für Phoenix Contact und NI-Lösung
Wie man an den drei Grafiken schön sieht, ist auf Basis einer sauberen Anforderungsanalyse ein permanentes Tracking und Tracing des aktuellen Status
eines Projekts sehr gut möglich. Eine derartige Darstellung des Projektfortschritts ist natürlich nicht nur in „einem“ Spielprojekt möglich, sondern auch in
e i n e m
r e a l e n
P r o j e k t .
In diesem Spaßprojekt (in dem es durchaus ernst zuging) wurden aber nicht nur die Anforderungen sehr genau bestimmt und deren Umsetzungsgrad
permanent verfolgt, sondern auch sehr genau auf die eingesetzten Zeiten geachtet. Auf diese Weise können sehr interessante Aussagen über die
Aufwände in den einzelnen Phasen gemacht werden. (siehe Bild 4).
Bild 4: Verteilung der Aufwände in den einzelnen Phasen
Wie man anhand der Grafiken sieht, sind in das Projekt ca. 1000 (Jung-)Ingenieursstunden eingeflossen. Sehr interessant ist, dass für die Spezifikation
der Anforderungen und Lösung in Summe ungefähr so viele Stunden investiert wurden, wie für die Realisierung einer Lösungsvariante (Phoenix bzw. NI).
Ebenfalls beachtenswert ist, dass die interdisziplinäre Kommunikation zwischen den einzelnen Teammitgliedern in den frühen Phasen besonders hoch ist,
aber auch während der Realisierungsphase immerhin noch knapp über 20 % ausmachte. Diese Zeiten für Kommunikation und Abstimmung sowie für die
Einarbeitung in ein neues System/eine neue Aufgabe werden in realen Projekten sehr häufig ebenso wenig eingeplant wie der Umstand, dass für die
Anforderungs- und Lösungsspezifikation erhebliche Zeiten eingerechnet werden müssen. Deshalb ist es nicht weiter verwunderlich, dass die
Zeitabschätzung in realen Projekten sehr häufig um Faktor 2 bis 3 danebenliegen, da man anfangs glaubt, die Aufgabe sei ohnehin klar und könne ohne
große interne Abstimmung einfach umgesetzt werden.
Zusammenfassung
Zusammenfassend kann man sagen, dass mit diesem Lern-Spaß-Projekt sehr gut aufgezeigt werden konnte, wie Hightech Spaß machen kann und
strukturiertes Vorgehen die Umsetzung durchaus geradliniger werden lässt. Aus diesem Projekt lassen sich zudem nicht nur Rückschlüsse auf neue
Ansätze in der Lehre ableiten, sondern auch Erkenntnisse für reale Industrieprojekte.
Autor:
Dr.-Ing. Rainer Stetter
ITQ GmbH (www.itq.de)
Parkring 4
Garching b. München 85748
Deutschland
Tel: +49 (0)89 321981-70
Fax: +49 (0)89 321981-89
stetter@itq.de (mailto:stetter@itq.de)
3/6
www.ni.com
Bild 1: Verteilung der Rollen, veranschaulicht am V-Modell
Bild 2: Funktionaler Strukturbaum
4/6
www.ni.com
Bild 3: Status der Anforderungen, Status der Umsetzung für Phoenix Contact und NI-Lösung
Bild 4: Verteilung der Aufwände in den einzelnen Phasen
Rechtliche Hinweise
Diese Kundenlösung („Kundenlösung“) wurde von einem Kunden von National Instruments („NI“) entwickelt. DIESE KUNDENLÖSUNG WIRD IM „IST-ZUSTAND“
ZUR VERFÜGUNG GESTELLT UND NI ÜBERNIMMT KEINERLEI GARANTIEN. AUSFÜHRLICHERE ERLÄUTERUNGEN ZU ANDEREN EINSCHRÄNKUNGEN
ENTNEHMEN SIE BITTE DEN NUTZUNGSBEDINGUNGEN FÜR NI.COM.
5/6
www.ni.com
6/6
www.ni.com