Autoren: Dipl.-Ing. Maximilian Apfelbeck und Dr.-Ing. Stephan Myschik, The MathWorks GmbH, Ismaning<\/p>\n
In Zukunft wird der Anteil an Robotern, die mit dem Menschen interagieren, rapide ansteigen. Sie sind mit einer gro\u00dfen Anzahl von Sensoren zum Erfassen der dynamischen Umgebung ausgestattet. Die Sensordaten werden bewertet und flie\u00dfen in Algorithmen ein, die f\u00fcr eine sichere Zusammenarbeit und Reaktion des Roboters sorgen. Die verwendeten Algorithmen m\u00fcssen auch gem\u00e4\u00df Sicherheitsstandards wie IEC 61508-3\u00a0<\/strong>[1]<\/strong>\u00a0entwickelt werden. Eine M\u00f6glichkeit, diesen Standards gerecht zu werden, ist die modellbasierte Entwicklung. Diese wird unter anderem schon in Automobilindustrie sehr erfolgreich eingesetzt. In diesem Vortrag wird eine Vorgehensweise zur Verifikation und Validierung von IEC 61508-3 konformen Softwarekomponenten kollaborierender Roboter anhand eines Beispiels diskutiert.<\/strong><\/p>\n „Ein Roboter darf kein menschliches Wesen verletzen \u2026“ ist das Erste der Asimov\u2019schen Gesetze [2]. Damit dieses Gesetz nicht verletzt wird, ist heutzutage ein sehr gro\u00dfer Prozentsatz der eingesetzten Roboter unterschiedlichster Gr\u00f6\u00dfe durch Z\u00e4une oder Lichtschranken vom Menschen getrennt. Diese Trennung muss jedoch durch andere Sicherheitsmechanismen ersetzt werden, so dass mit Robotern neue Applikationen und Einsatzgebiete, vor allem in der Mensch-Roboter-Interaktion, realisierbar werden. Beispiele f\u00fcr neue Anwendungen sind unter anderem der Einsatz von Robotern als Produktionsassistent [3] oder in der Pflege von bed\u00fcrftigen Personen.<\/p>\n Es gibt unterschiedliche technische L\u00f6sungen, um die Sicherheit in der Mensch-Roboter-Interaktion zu gew\u00e4hrleisten. Dies kann zum Beispiel durch das mechatronische Design realisiert werden. Ein Ansatz hierf\u00fcr ist die Begrenzung des dynamischen Bereiches des Roboters, so dass keine Verletzung des Menschen [4] bei Kontakt m\u00f6glich ist. Andere Optionen sind das Einbauen von mechanischen Klemmen, die bei einer \u00dcberbelastung durchrutschen, oder der Einsatz von seriellen-elastischen Aktuatoren [5]. Bei mechanischen Klemmen verhindert ein Durchrutschen der Klemme einen potentiell gef\u00e4hrlichen Mensch-Roboter-Kontakt. Jedoch ist diese L\u00f6sung kaum anwendbar, da eine Neukalibrierung des kompletten Systems n\u00f6tig w\u00e4re. Ein weiterer L\u00f6sungsansatz ist der Einsatz von Software und das \u00dcberwachen von Sensoren; dies l\u00e4sst sich mit wenig Aufwand erf\u00fcllen. Dazu wird der Roboter mit einer intelligenten, sensitiven Haut ausgestattet, die bei nicht-erwartetem oder hoch-energetischem Kontakt den Roboter stoppt [6]. F\u00fcr den Fall dass ein Werkzeug, wie zum Beispiel ein Schraubenzieher, potentiell gef\u00e4hrdend f\u00fcr den Menschen ist, wird mehr Intelligenz in den Algorithmen ben\u00f6tigt. Ein m\u00f6glicher L\u00f6sungsansatz wird in [7] vorgestellt. Ein Hauptargument f\u00fcr den Einsatz von derartiger \u00dcberwachungs- und Sicherheitssoftware ist der St\u00fcckkostenpreis. Dieser nimmt mit der Anzahl der Endprodukte ab. Bevor diese allerdings in einem fertigen Produkt verwendet werden darf, m\u00fcssen Fehlerfreiheit und eine Entwicklung in \u00dcbereinstimmung mit Sicherheitsnormen nachgewiesen werden.<\/p>\n Modellbasierte Entwicklung kann bei der Entwicklung von Regelungsalgorithmen oder \u00dcberwachungslogik f\u00fcr diese sicherheitsrelevanten Applikationen unterst\u00fctzen.\u00a0 Verifikations- und Validierungskonzepte zum Nachweis der korrekt implementierten Funktionalit\u00e4t im Hinblick auf Anforderungen oder Normen sind Bestandteile der Modellbasierten Entwicklungsmethodik.<\/p>\n Im ersten Teil dieser Ver\u00f6ffentlichung wird der modellbasierte Entwicklungsansatz am Beispiel eines Roboters gezeigt. Im zweiten Teil werden Verifikations- und Validierungsschritte diskutiert, so dass die Konformit\u00e4t der erzeugten Softwarekomponente nach dem IEC 61508-3 Standard nachweisbar ist. Abschlie\u00dfend werden Anwendungsbeispiele aus der Luftfahrt und der Medizintechnik f\u00fcr den erfolgreichen Einsatz des aufgezeigten Entwicklungsprozess pr\u00e4sentiert.<\/p>\n Im Folgenden wird anhand des V-Modells [8], siehe Abbildung 1 (PDF<\/a>), die Entwicklung sicherheitsrelevanter Algorithmen f\u00fcr Roboter erkl\u00e4rt. Ein Entwicklungsprozess nach dem V-Modell ist weit verbreitet. Der verwendete Roboter ist in Abbildung 2 als CAD-Modell dargestellt. Das Ziel ist es, „Pick and Place“ Applikationen f\u00fcr den Roboter zu entwickeln. Dabei soll erlaubt sein, dass sich ein Mensch im Arbeitsraum des Roboters befindet.<\/p>\n Neben der \u00fcbergeordneten Aufgabe, „Pick and Place“ Operationen durchzuf\u00fchren, werden technische Anforderungen, wie maximale Leistung, Bauraum oder Wiederholbarkeit, und sicherheitsrelevante Anforderungen im Anforderungsdokument definiert. Die Anforderungen sind vermehrt in einem Anforderungsmanagementsystem hinterlegt. Ein m\u00f6gliches Requirement zur Gew\u00e4hrleistung einer sicheren Mensch-Roboter-Kollaboration kann Folgendes sein:<\/p>\n Diese Situation kann zum Beispiel in dem Fall eines Kontaktes mit Objekten oder Menschen w\u00e4hrend des Betriebes auftreten.<\/p>\n Auf Basis des Anforderungsdokuments und des zu entwickelnden Systems wird in der modellbasierten Entwicklung als erster Schritt die Systemarchitektur definiert. Hier wird eine Segmentierung in unterschiedliche Einheiten durchgef\u00fchrt, und es werden die Schnittstellen zwischen den Komponenten definiert. Ein Roboter kann in Software und Hardware aufgeilt werden. Die Software ist in \u00dcberwachungslogik, koordinierenden Regler und Gelenkregler zerlegbar; die Hardware in Mechanik und Elektronik. Dieser Ansatz ist in Abbildung 3 (siehe\u00a0PDF<\/a>) dargestellt und wurde in Simulink\u00ae\u00a0<\/sup>umgesetzt.<\/p>\n Die Anforderungen werden f\u00fcr eine optimale Nachverfolgung mit den jeweiligen Komponenten bidirektional verkn\u00fcpft. Im weiteren Entwicklungsverlauf werden nun die einzelnen Komponenten funktional entwickelt und nach der Interpretation der Anforderungen modelliert. Ein Vorteil von Simulink\u00ae<\/sup>\u00a0ist, dass die Komponenten und somit die Requirements ausf\u00fchrbar sind. Somit erh\u00e4lt der Ingenieur sofortige R\u00fcckmeldung \u00fcber die Qualit\u00e4t seines Designs. Er kann fr\u00fchzeitig im Entwicklungsprozess Fehler erkennen und somit das Projektrisiko erheblich minimieren.<\/p>\n Die Erstellung der einzelnen Modellkomponenten wird durch speziell angepasste Werkzeuge sehr effizient unterst\u00fctzt. Die Mechanik kann aus CAD-Baugruppen in ein Mehrk\u00f6rpersystem bestehend aus Gelenken und Einzelk\u00f6rpern abgeleitet werden. Der CAD-Import in SimMechanics\u2122 stellt somit sicher, dass die korrekten Bauteilparameter, wie Masse, Schwerpunkt oder Schwerpunktslage, in der Simulation verwendet werden. Dar\u00fcber hinaus wird die grafische Repr\u00e4sentation der einzelnen Komponenten mit \u00fcbernommen. Dieser Ansatz kann die Modellierung des mechanischen Systems erheblich beschleunigen [9]. Abbildung 2 (siehe\u00a0PDF<\/a>) zeigt die grafische Darstellung der importierten Baugruppe. Das importierte System kann auch als Startpunkt f\u00fcr Kinematikoptimierung oder Aktuatorauslegung verwendet werden. Neben den Motoren k\u00f6nnen weitere physikalische Komponenten (Getriebe) oder f\u00fcr die Regelung relevante Effekte (Reibung, Spiel, Steifigkeit) sehr einfach mit der Mehrk\u00f6rpermechanik verkn\u00fcpft werden. Dies wird in Abbildung 4 (siehe\u00a0PDF<\/a>) gezeigt. Die Parametrierung dieser Komponenten kann oft aus Datenbl\u00e4ttern entnommen werden.<\/p>\n Zur Modellierung der Regler eignet sich am besten Simulink\u00ae<\/sup>; f\u00fcr die \u00dcberwachungslogik Stateflow\u00ae<\/sup>, siehe Abbildung 5 (siehe\u00a0PDF<\/a>).<\/p>\n Sobald die physikalische Strecke und erste Softwarekomponente modelliert sind, k\u00f6nnen erste virtuelle Tests des Gesamtsystems durchgef\u00fchrt werden. In kleinen Iterationsschritten wird nun immer mehr Intelligenz und Funktionalit\u00e4t zur Software hinzugef\u00fcgt und durchgehend getestet. Mit jedem Simulationslauf wird das aktuelle Modell gegen\u00fcber den Anforderungen validiert und verifiziert. Zus\u00e4tzlich l\u00e4sst sich eine optimale Parametrierung der Softwarekomponente in der Simulation ermitteln. Abbildung 5 zeigt das Ergebnis der Sprungantwort eines optimierten PID-Reglers f\u00fcr ein Robotergelenk.<\/p>\n Vorteile der modellbasierten Entwicklungsmethodik:<\/p>\n In folgender NASA-Studie [10] wird die Wichtigkeit, Fehler in fr\u00fchen Entwicklungsstadien zu finden, best\u00e4tigt. Je sp\u00e4ter ein Fehler innerhalb eines Projektes gefunden wird, umso teurer wird es, diesen zu beheben.<\/p>\n Nachdem das Softwaredesign komplett auf Modellebene entwickelt wurde und die Einhaltung der Anforderungen nachgewiesen ist, kann Produktionscode aus dem Modell mit dem Embedded Coder erzeugt werden. Dieser ist vom T\u00dcV S\u00fcd f\u00fcr die Software-Entwicklung f\u00fcr IEC 61508-3 kompatiblen Code vorqualifiziert [11].<\/p>\n Folgende Fragen in der Software-Verifikation und -Validierung k\u00f6nnen bei der modelbasierten Entwicklung positiv beantwortet werden [12]:<\/p>\n MathWorks hat einen Referenzworkflow [13] entwickelt, der bei der Beantwortung der beiden Fragen hilft. Dazu wird die Entwicklung in die Design-Verifikations- und Code-Verifikationsphase unterteilt.<\/p>\n Design-Verifikation<\/strong><\/p>\n Das Ziel dieser Phase ist es zu beweisen, dass das Modell die Anforderungen erf\u00fcllt und keine unerw\u00fcnschte Funktionalit\u00e4t beinhaltet. Dies wird sowohl durch statische Analysen als auch funktionale Tests gezeigt. Bei der statischen Analyse wird das Modell auf Konstrukte untersucht, die z.B. nicht-optimal f\u00fcr die Codegenerierung sind. Dar\u00fcber hinaus k\u00f6nnen vordefinierte oder eigene Modellierungsrichtlinien \u00fcberpr\u00fcft werden. Modelle, die in Produktionscode \u00fcberf\u00fchrt werden, sind auch im Hinblick auf die Konformit\u00e4t mit Sicherheitsstandard \u00fcberpr\u00fcfbar. Abbildung 6 (siehe\u00a0PDF<\/a>) zeigt das Ergebnis f\u00fcr die \u00dcberpr\u00fcfung eines Modellteils nach „Modeling Standards for IEC 61508“. Dieser Bericht unterst\u00fctzt bei der Identifikation von Modellierungsfehlern, Berichtigung und Dokumentation eines erfolgreichen Tests. \u00dcber eine Modell-Checksumme kann der Bericht eindeutig einem System und einer Modellversion zugeordnet werden.<\/p>\n Sobald die Modellierungsrichtlinien erfolgreich \u00fcberpr\u00fcft sind, wird eine Abdeckungsanalyse des Modells durchgef\u00fchrt. Ziel ist es, unerw\u00fcnschte Funktionalit\u00e4t oder fehlende Anforderungen aufzudecken. Ein m\u00f6gliches Beispiel f\u00fcr den im Abschnitt 2 gezeigten Roboter ist das Berechnen eines richtigen Ergebnisses der Inverskinematik. Die berechneten Gelenkwinkel m\u00fcssen in jedem Fall innerhalb der Gelenkbegrenzungen liegen. Dies kann z.B. durch das in Abbildung 7 (siehe\u00a0PDF<\/a>) gezeigte Konstrukt bewiesen werden.<\/p>\n Damit die funktionale Korrektheit der Inverskinematik nachgewiesen wird, m\u00fcssen die Ergebnischecks erf\u00fcllt werden. Abbildung 8 (siehe\u00a0PDF<\/a>) zeigt eine Verletzung dieser Checks aufgrund einer falschen Implementierung.<\/p>\n Au\u00dferdem muss auch eine komplette Modellabdeckung der Inverskinematik vorliegen. Das Ergebnis der Analyse eines spezifischen Testfalls in Abbildung 9 (siehe\u00a0PDF<\/a>) zeigt, dass\u00a0 bestimmte Bereiche der Inverskinematik nicht ausgef\u00fchrt werden. Mit diesem Test ist somit keine Aussage \u00fcber die funktionale Korrektheit bestimmter Modellteile zu beweisen. Alle Tests k\u00f6nnen automatisch durchgef\u00fchrt und dokumentiert werden. Neben diesen funktionalen Tests ist es auch m\u00f6glich, Testvektoren automatisch abzuleiten.<\/p>\n Nachdem alle statischen und funktionalen Tests erfolgreich durchgef\u00fchrt wurden und eine komplette Abdeckung der Anforderungen durch das Modell bewiesen wurden, wird automatisch Code aus dem Modell generiert. Abbildung 10 (siehe\u00a0PDF<\/a>) zeigt schematisch die Vorgehensweise bei der Code-Generierung. Der aus dem validierten Modell abgeleitete Code kann nun auf die Zielplattform \u00fcbertragen werden. Die Code-Generierung erzeugt einen Bericht, der bei der Nachverfolgbarkeit von den Anforderungen in das Modell und weiter in den Code unterst\u00fctzt.<\/p>\n Code-Verfifikation<\/strong><\/p>\n Zur kompletten Validierung des Algorithmus muss bewiesen werden, dass kein funktionaler Unterschied zwischen Modell und Objektcode vorliegt. Dazu werden Modell und Objektcode mit identischen Testvektoren angeregt. Der Objektcode wird direkt auf der Zielplattform ausgef\u00fchrt. Embedded Coder bietet dazu „Processor-in-the-Loop“-Simulation (PIL) an. Dies wird in Abbildung 11 (siehe\u00a0PDF<\/a>) gezeigt.<\/p>\n Die Ergebnisse der Simulation des verifizierten Modells werden neben den Testvektoren als Erwartungswerte abgespeichert. Bei der PIL-Simulation wird der Objektcode auf die Zielplattform \u00fcber eine Debug-Schnittstelle, zum Beispiel JTAG, \u00fcbertragen. Das auf den Prozessor \u00fcbertragene Simulink-Modell wird im PIL-Modus ausgef\u00fchrt. Die Kommunikation zwischen dem in Simulink ausgef\u00fchrten Robotermodell und dem Regler auf der Zielplattform wird \u00fcber die serielle Schnittstelle oder TCP\/IP hergestellt.<\/p>\n Korrekte Funktionalit\u00e4t des Objektcodes ist dann bewiesen, wenn eine ausreichend gute \u00dcbereinstimmung zwischen den beiden Simulationen (verifiziertes Modell und PIL) vorhanden ist. Einfl\u00fcsse unterschiedlicher Compiler oder Flie\u00dfkommazahl-Einheiten k\u00f6nnen Unterschiede zwischen Simulation und Objektcode verursachen. Neben dem Nachweis der funktionalen \u00c4quivalenz muss auch bewiesen werden, dass bei der Code-Generierung keine unerw\u00fcnschte Funktionalit\u00e4t eingef\u00fcgt wurde. Dies kann durch den Vergleich der Abdeckung auf Modell- und Code-Ebene sowie das \u00dcberpr\u00fcfen der Nachverfolgbarkeit, welche der Embedded Coder\u00ae durch eine automatische Dokumentation unterst\u00fctzt, gezeigt werden. Ein Nachverfolgbarkeitsbericht wird in Abbildung 12 (siehe\u00a0PDF<\/a>) gezeigt. Dieser Bericht enth\u00e4lt das komplette Mapping des Models auf den Code und eine Liste von Modellkomponenten, die wegen Codeoptimierung im erzeugten Code fehlen. Eine bidirektionale Verlinkung vom Modell zum Code sowie Links zu den Anforderungen sind ebenso dokumentiert, siehe Abbildung 13 (PDF<\/a>).<\/p>\n In den beiden vorausgehenden Abschnitten wird eine m\u00f6gliche Vorgehensweise zur Erzeugung von zertifizierbarer Software mit modellbasierter Entwicklung erl\u00e4utert. Dieser Prozess wird ganz oder in Teilen von vielen Unternehmen unterschiedlichster Industrien genutzt. Weinmann [15] verwendet Teile des beschriebenen Entwicklungsprozesses, um Software f\u00fcr neue Transportbeatmungsger\u00e4te zu entwickeln. Bei diesem Produkt ist die Komplexit\u00e4t der Algorithmen um ein Vielfaches h\u00f6her als in der Vergangenheit. Neben den Algorithmen wurde auch die Funktionalit\u00e4t der menschlichen Lunge und des Ventilators modelliert. Damit war es m\u00f6glich, das Gesamtsystem bestehend aus Software, Ger\u00e4t und Mensch vorab zu berechnen und eine Vielzahl unterschiedlicher Designalternativen zu evaluieren und zu testen. Dies war mit deren herk\u00f6mmlicher Entwicklungsmethodik nicht m\u00f6glich. Bevor Produktionscode erzeugt wurde, mussten die Algorithmen auch Abdeckungstests auf Modellebene bestehen. Der Wechsel zur modellbasierten Entwicklung beschleunigte den Entwicklungsprozess bei Weinmann, so dass die Zertifizierung f\u00fcr sicherheitskritische Systeme viel schneller m\u00f6glich ist. Die modellierten Systeme werden in zuk\u00fcnftigen Projekten zudem vielfach wiederverwendet.<\/p>\n Durch den Einsatz von modellbasierter Entwicklung beschleunigt Eurocopter die Entwicklung von DO-178B zertifizierter Software [16]. Die Hauptherausforderung bestand darin, dass Designfehler durch eine falsche Interpretation der Anforderungen oder falsche Implementierung der Systeme, die sich zwar richtig, aber nicht wie beabsichtigt verhielten, eingef\u00fchrt wurde. Eurocopter sch\u00e4tzt, dass ungef\u00e4hr 90% der Probleme, die sp\u00e4t im Projekt gefunden wurden, durch Fehler in der Spezifikations- oder Designphase eingef\u00fchrt wurden. Die Anzahl der Fehler wurde durch Einf\u00fchrung der modellbasierten Entwicklung aufgrund des fr\u00fchzeitigen Testens und der kontinuierlichen Verifikation und Validierung erheblich reduziert.<\/p>\n Die erstellten Modelle werden mit Modell-Standardchecks und Modellabdeckung auf Einhaltung von Modellierungsrichtlinien zur Erf\u00fcllung der DO-Norm analysiert. Der automatisch generierte Code wird nach erfolgreicher \u00dcberpr\u00fcfung in Objektcode kompiliert. Dieser wird gegen die schon vorhandenen Testvektoren getestet. Der beschriebene Prozess unterst\u00fctzt Eurocopter, um automatisch Code zu generieren, der dann f\u00fcr die DO-178B Norm der EASA zertifiziert wird. Mit dieser Vorgehensweise wurde die Zeit zum Testen der Software um 2\/3 reduziert, und die Requirements konnten viel fr\u00fcher eingefroren werden. Im Vergleich zu \u00e4hnlichen Projekten werden diese nun ungef\u00e4hr 1 Jahr fr\u00fcher endg\u00fcltig fixiert.<\/p>\n Diskutiert wurde eine Vorgehensweise zum Erstellen von zertifizierten Code nach IEC61508-3 f\u00fcr robotische Systeme. Die Anwendung dieses Software-Entwicklungsprozesses f\u00fchrt zu einer h\u00f6heren Softwarequalit\u00e4t, verminderten Entwicklungszeiten und zertifiziert Software mit weniger Aufwand. Dar\u00fcber hinaus unterst\u00fctzt die Modellierung der Algorithmen und Systeme und deren grafische Darstellung die technische Kommunikation sowie das Systemverst\u00e4ndnis in Projektteams. Modellbasierte Entwicklung hat das Potential, ein wichtiger Baustein f\u00fcr zuk\u00fcnftige Entwicklungen von kollaborierenden Robotern zu werden.<\/p>\n [1]\u00a0\u00a0 International Electrotechnical Commission: Functional safety of electrical\/electronic\/programmable electronic safety related systems \u2013 Part 3: Software requirements, IEC 61508-3 ed.2, Geneva, 2010.<\/p>\n [2]\u00a0\u00a0 Asimov, Isaac: Runaround, 1942.<\/p>\n [3]\u00a0\u00a0 Robert Bosch GmbH,\u00a0https:\/\/www.bosch-apas.com\/en\/apas\/start\/bosch_apas.html<\/a>.<\/p>\n [4]\u00a0\u00a0 ABB AG,\u00a0https:\/\/new.abb.com\/products\/robotics\/de\/yumi<\/a>.<\/p>\n [5]\u00a0\u00a0 Rethink Robotics,\u00a0https:\/\/www.rethinkrobotics.com\/baxter\/<\/a>.<\/p>\n [6]\u00a0\u00a0 MRK Systeme GmbH,\u00a0https:\/\/www.mrk-systeme.de\/produkte_interaction.html<\/a>.<\/p>\n [7]\u00a0\u00a0 Haddadin, Sami: Towards Safe Robots,\u00a0Springer Tracts in Advanced Robotics<\/a>, Vol. 90, 2013.<\/p>\n [8]\u00a0\u00a0 Friedrich, Jan; Kuhrmann, Marco; Sihling, Marc and Hammerschall, Ulrike: Das V-Modell XT F\u00fcr Projektleiter und QS-Verantwortliche kompakt und \u00fcbersichtlich, Springer-Verlag Berlin Heidelberg 2009.<\/p>\n [9]\u00a0\u00a0 Saneon GmbH,\u00a0https:\/\/www.saneon.de\/cms\/index.php\/en\/component\/content\/article\/1-aktuelle-nachrichten\/123-simulation-saneon.html<\/a>.<\/p>\n [10] NASA, Return on Investment for Independent Verification & Validation, 2004.<\/p>\n [11] T\u00dcV S\u00dcD Certificate, Z10 11 12 67052 014.<\/p>\n [12] Conrad, Mirco and Sandmann, Guido: A Verification and Validation Workflow for IEC 61508 Applications, SAE Technical Paper 2009-01-0271, 2009.<\/p>\n [13] The MathWorks, Inc.\u00a0https:\/\/www.mathworks.com\/products\/iec-61508\/<\/a>.<\/p>\n [14] The MathWorks, Inc.\u00a0https:\/\/www.mathworks.de\/products\/embedded-coder\/<\/a>.<\/p>\n [15] The MathWorks, Inc.\u00a0https:\/\/www.mathworks.com\/tagteam\/76574_91946v01_Weinmann_UserStory_final.pdf<\/a><\/p>\n [16] The MathWorks, Inc.\u00a0https:\/\/www.mathworks.com\/tagteam\/77159_92118v00_Eurocopter_UserStory_final.pdf<\/a><\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema\u00a0Qualit\u00e4t, Safety & Security<\/strong>.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Qualit\u00e4t, Safety & Security steht\u00a0hier\u00a0<\/a><\/strong>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nEinleitung<\/h2>\n
Modellbasierte Entwicklung entlang des V-Modells<\/h2>\n
\n
\n
Verifikation und Validierung von Modell und generiertem Code<\/h2>\n
\n
Anwendungen in der Industrie<\/h2>\n
Zusammenfassung<\/h2>\n
Referenzen<\/h2>\n
\nUnsere Trainings & Coachings<\/h2>\n
\nQualit\u00e4t, Safety & Security – Fachwissen<\/h2>\n