Mechatronische Ausbildung mit Hightech
Transcription
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 [email protected] (mailto:[email protected]) 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