In diesem Abschnitt soll ausgehen von einem umfassendem Verständnis des Begriffs Mechatronik die Bedeutung eingebetteter Systeme (im engeren Sinne Mikrocontrollerlösungen) und ausgewählten Engineeringtechniken erörtert werden.

Mechatronik ist im Vergleich mit dem Maschinenbau, der Elektrotechnik aber auch der Elektronik und Informatik ein sehr junges Fachgebiet. Die Entstehung dieser fachlichen Domäne ist der sich ab der 1980er Jahre herausbildenden Struktur moderner Systeme geschuldet. Bis dahin gab es eine recht klare Abgrenzung zwischen mechanischen, elektrischen, elektronischen, optischen, pneumatischen und hydraulischen Systemen. Das schlug sich dann auch in der Ausbildung nieder. Oft traf man noch „reine“ Systeme wie zum Beispiel vollständig mechanische Lösungen an. Schon länger war, durch häufig anzutreffende elektro-mechanischer Systeme, die Elektro-Mechanik als eigene Fachdomäne anerkannt. Die Elektronik und Informatik durchdrangen jedoch zunehmen alle modernen Systementwürfe. So musste man in Deutschland bereits in den 1990er Jahren erkennen, dass eine Trennung zwischen Fahrzeugelektrik, -elektronik und -mechanik nicht mehr zeitgemäß war. Heute gibt es den Beruf des Kfz-Ektrikers oder des Kfz-Mechanikers nicht mehr. Es gibt nur noch Fahrzeugmechatroniker. Das Auto als Mechatronisches System ist hier nur ein Beispiel. Dieser Trend lässt sich auf alle modernen Systeme übertragen. Diese gegenseitige Durchdringung der fachlichen Domänen hat sich seit dem noch deutlich beschleunigt. Heute sind mechatronische Systeme zunehmen vernetzt und in das Internet integriert, so dass man inzwischen von cyber-physical-systems spricht. Internet der Dinge, Digitalisierung, Industrie 4.0, smart home, smart city usw. sind letztlich verschiedene Perspektiven auf ein und den selben Gegenstand. Moderne Systeme sind komplexe Gebilde sich überlappenden Teilsystemen verschiedener Fachdomänen. Nur im Zusammenspiel der verschiedenen Fachdomänen funktionieren diese Systemansätze und erreichen völlig neue Qualitätsmerkmale.

Eine Fachdomäne spielt dabei eine besondere Rolle. Es ist die zunehmende Verlagerung (Verschiebung/Abhängigkeit/…) der Funktionalität modernen Systemlösungen in die (von der) Domäne der Software zu beobachten.

Die Mikrorechner welche in modernen mechatronischen Systemen eine zentrale integrierende Rolle spielen kann man grob in zwei Kategorien einteilen. Zum einen zentrale Steuerungslösungen bei denen der Mikrorechner (Computer) meist durch die Präsenz eines Displays und vielleicht auch einer Tastatur oder anderen computer-typischer Ein und Ausgabegeräte zu erkennen ist. Zum anderen oft dezentraler versteckte also eingebettete Mikrorechner deren Präsenz für den Betrachter des Systems nicht erkennbar ist. Solche eingebetteten Mikrorechner sind oft sogenannte Mikrocontroller. Mikrocontroller sind eine besondere Kategorie von Mikrorechnern, man nennt diese auch Ein-Chip-Mikrorechner. Bei Mikrocontrollern sind alle Elemente eines funktionsfähigen Computers (Rechenwerk, Steuerwerk, Speicher, Ein- und Ausgabegeräte, usw.) auf einem integrierten Schaltkreis (Chip) integriert. Das bewirkt, dass es eines extrem geringen Schaltungsaufwandes bedarf um Mikrocontroller in ein System zu integrieren. Mikrocontroller lassen sich also sehr leicht in Systeme einbetten.

In der deutschen Sprache gibt es für das, oft sehr kompetente, kunstvolle und zutiefst die menschliche Seele befriedigende herstellen eines Gegenstandes ohne vorherige Planung also rein aus den Gedanken, Ideen und dem sich Herstellungsprozess selbst heraus kreativ Entstehenden ein spezifisches Wort: Basteln. Basteln ist scharf gegen die Arbeitsweise eines Ingenieurs abgegrenzt. Ingenieure planen, berechnen, konstruieren, simulieren, usw. bevor sie etwas herstellen. Diese Ingenieurtugenden im englischen mit dem Begriff des Engineering umrissen gelten natürlich auch für mechatronische Systeme und sollten auch für die fachliche Domäne der Herstellung von Software gelten.

Faktisch alle Aspekte des Software Engineering zielen auf die Beherrschbarkeit von Komplexität. Versuchen wir uns für das Problem der Komplexität zu sensibilisieren. Dazu führen wir ein kleines Experiment aus. Betrachten Sie die folgenden Darstellungen nacheinander (bitte die rechte Darstellung zuerst abdecken). Sie sollen die Menge der vorgelegten Streichhölzer ermitteln. Nehmen Sie sich je Bild nicht mehr als 3 Sekunden Zeit. Es geht also um das Wahrnehmen und das Verstehen.

In drei Sekunden werden Sie für die linke Darstellung nicht mehr als eine Schätzung der Streichholzanzahl abgeben können. Wiederholen wir das Experiment mit dem rechten Bild. Sie werden jetzt die exakte Anzahl der Streichhölzer in wesentlich weniger als drei Sekunden erfasst haben. Etwas Essentielles unterscheidet beide Bilder. Die Anzahl der Streichhölzer in beiden Darstellungen ist exakt die Selbe. Aber erst im zweiten Bild sind Sie in der Lage, die Anzahl wirklich mit einem oder auch zwei Blicken zu erfassen. Woran liegt das? Zum einen sorgte die Art der Anordnung, der Fachmann spricht hier von Strukturierung, dafür. Der zweite Aspekt ist der, dass Ihnen ein bekanntes Muster ja fast eine Art Symbol angeboten wurde.

Dieses Experiment lässt sich leicht weiter entwickeln bis zum Gebrauch von abstrakten vereinheitlichten Symbolen für die Darstellung von numerischen Sachverhalten. Der Weg zu einer einheitlichen Zahlendarstellung bedeutete Komplexität beherrschbar machen. Genau das ist auch die Herausforderung der Softwareentwicklung. Die Streichhölzer sind die einzelnen Programmzeilen, das Bild die gesamte Applikation. Beides gilt es zu beherrschen. Der Weg führt über standardisierte Symbole die strukturiert und nach den Regeln einer Sprache zu komplexen Aussagen zusammengesetzt werden. Es wird mit der UML eine standardisierte Konstruktionszeichnung der Software erstellt. Konstruktionszeichnungen sind für die Herstellung komplexer Systeme essentiell. Die Vorstellung, dass Systeme welche wir tagtäglich benutzen möglicherweise ohne eine ingenieurmäßige Konstruktion hergestellt wurden sollte uns beunruhigen.

Wie wir bis hier herausgearbeitet kennzeichnet mechatronische Systeme die Integration von:

• mechanischen Komponenten
• hydraulischen und pneumatischen Komponenten
• elektrischen Komponenten
• elektronischen Komponenten
• und Softwarekomponenten zu einem Gesamtsystem

Jede dieser Fachdomänen bedient sich spezifischer Engineering-Techniken insbesondere spezifischer normierter Konstruktionszeichnungen. So zum Beispiel:

• mechanische Konstruktionszeichnungen nach ISO 128, ISO 5455, ISO 5455, …
• hydraulische und pneumatische Konstruktionszeichnungen nach ISO 1219
• elektrische/elektronische Konstruktionszeichnungen nach IEC 60617

Auch die Software für mechatronische Systeme sollte mit entsprechenden Engineering-Techniken hergestellt und dokumentiert werden. Genauso wie es für das klassischen Engineering eine Vielzahl von Normen und Standards gibt, gibt es solche auch für die Softwareentwicklung. Die ISO 19505 auch als UML bekannt soll in diesem Kurs eine besondere Rolle zukommen. Software soll mit einigen grundlegenden Darstellungstechniken der UML entworfen, realisiert und dokumentiert werden. Aus dem gesamten Vorrat der UML werden wir folgende Darstellungstechniken besonders nutzen:

1. Anwendungsfalldiagramme um zu klären WAS die Software leisten soll (top level requirements)
2. Aktivitätsdiagramme um zu klären WIE die Software funktionieren soll (functional requirements)
3. Klassendiagramme um die Software zu konstruieren und zu dokumentieren
4. Zustandsdiagramme um die Logik der Software zu konstruieren und zu dokumentieren
5. Sequenzdiagramme um einzelne Algorithmen zu dokumentieren

Als letzter Baustein soll die ISO 19514, die SysML unserem Katalog der Engineering-Techniken vervollständigen. Die SysML (Systems Modelling Language) ist die jüngste hier vorgestellte Engineering-Technik. Sie wurde entwickelt unter dem Eindruck, dass es einer fachübergreifenden Modellierungssprache über die Domänen der Mechanik, Elektrik, Elektronik, Hydraulik, Pneumatik, und Software bedarf. Keine der domänenspezifischen Konstruktionssprachen ist in der Lage moderne mechatronische Systeme als ganzes in einem Modell abzubilden. Die SysML bietet hier Abhilfe. Sie tritt am die stelle bisheriger nicht normierter Übersichtsdarstellungen wie Blockdiagramme, Beziehungsdiagramme, Hierarchiediagramme, usw. Die SysML bietet einen normierten Rahmen zur Darstellung fachübergreifender Aspekte. Die SysML hat zahlreiche Anregungen aus der UML übernommen (SysML als UML-Profil). Wir werden also viele Ähnlichkeiten zwischen der UML und SysML feststellen. Aus der SysML werden wir in diesem Kurs folgende Darstellungstechniken nutzen:

1. Anwendungsfalldiagramme um zu klären WAS ein System leisten soll
2. Block-Definitions-Diagramme um zu klären aus welchen Komponenten ein System besteht
3. Interne-Block-Definitionsdiagramme um zu klären wie die Komponenten zusammenwirken

Dieser Embedded Systems Engineering Kurs soll bei den Teilnehmern ein breites interdisziplinäres Verständnis und Wissen aufbauen sowie praktische Fähigkeiten zur Realisierung eingebetteter Systeme ausbilden. Zu den konkreten Zielen des Kurses Zählen:

• Ein Grundverständnis moderner Systeme als mechatronische Einheiten und cyber physikalische Gebilde
• Rolle der Software in modernen Systemen
• Grundverständnis der Struktur eingebetteter Systeme
• Sensibilisierung für die Notwendigkeit eines hohen Niveaus des Engineering in allen Domänen
• Kenntnisse und Fähigkeiten zur Modellierung mit der UML und der SysML
• Kenntnisse und Fähigkeiten zur Realisierung von Mikrocontrollerlösungen mit der UML und in C++
• Sensibilisierung für die Bedeutung von korrekten Dokumentationen moderner Systeme

Als Softwareprozess bezeichnet man die festgelegte Reihenfolge von Aktivitäten, die vereinbarten Regeln, Techniken, Werkzeuge und die erwarteten Ergebnisse der Aktivitäten zur Herstellung von Software. Definierte Softwareprozesse sichern die Planbarkeit, Kontrollierbarkeit und Ergebnisqualität der Herstellung von Software. Für diesen Kurs wird der folgende einfache Softwareprozess als verbindlicher Arbeitsablauf vereinbart.

Die Einzelnen Aktivitäten haben folgende erwarteten Ergebnisse:

1. Anforderungsanalyse
   1. Nutzersicht als Anwendungsfalldiagramm (als SysML/UML Modell)
   2. geforderte Funktionalitäten als Aktivitätsdiagramme (als SysML/UML Modell)
   3. Testfälle (als Dokument)
   4. HRM Hardware Ressourcen Modell (als SysML Modell)
   5. SRS System Requirements Specification (als Dokument)
2. Systementwurf
   1. Klassenmodell der Konzeptstufe / Architekturmodell (als UML Modell)
   2. ggf. Zustandsmodell (als UML Modell)
   3. Systemdokumentation (als Dokument)
3. Implementation
   1. Klassenmodell der Realisierung (als UML Modell)
   2. Verhaltensmodelle der Realisierung (als UML Modell)
   3. Produktiver Code (als übertragbares Format der Zielplattform, *.hex, *.elf)
   4. Systemdokumentation (als Dokument)
4. Systemintegration
   1. das fertiggestellte System
5. Test and Übergabe
   1. das getestete System
   2. die technische Systemdokumentation (als Dokument)
   3. die Benutzerdokumentation (als Dokument)

• dem nächsten Kapitel
• zurück zur Übersicht