Standards und Modellierung

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Willert Software Tools GmbH

AUTOSAR, ASPICE, SysML – hinter jedem neuen Standard steht das Ziel, Engineering-Prozesse zu optimieren. In der Fahrzeugentwicklung lässt sich jedoch kein Standard für sich allein einsetzen oder bewerten. Es gilt also, diese Standards strukturiert und aufeinander abgestimmt zu verwenden, um ihre Vorteile nutzen zu können.

Beim Engineering, das heißt auch in der Fahrzeugentwicklung, ist man mit zahlreichen Standards konfrontiert. Sie sollen Best Practices vermitteln und sowie die Qualität und Engineering-Experience insgesamt für die Industrie verbessern. Fast immer werden diese Ziele erreicht. Für den einzelnen Ingenieur ist jedoch nicht immer klar, welche Standards anzuwenden sind und inwieweit sie sich erfolgreich für bestimmte Aufgabenstellungen einsetzen lassen. Von Automotive-Ingenieuren wird oft verlangt, dass sie sich mit den verschiedensten Standards auskennen und diese bei der Entwicklung im Sinne ihrer Aufgabenstellungen kombinieren.

Unserer Erfahrung nach führt die individuelle Interpretation von Standards zu Verunsicherung und ist der Engineering-Effizienz eher abträglich als förderlich. Wir haben auch erkannt, dass der gezielte Einsatz dieser Standards einen Mehrwert und größere Flexibilität schafft – die Fahrzeugentwicklung wird effizienter und erfolgreicher. Bei unserer Methode richten wir unser Augenmerk auf die Notwendigkeit der Standards, den Datenfluss und auf die Aufgaben des Ingenieurs.

Der Datenfluss

Standards sind für die Fahrzeugentwicklung hilfreich und in jedem Fall auch erforderlich. Die Herausforderung liegt jedoch darin, diese Standards so anzuwenden, dass der Datenfluss zwischen den Engineering-Aktivitäten sichergestellt ist. Hier sind zwei Ziele zu erreichen: Zum einen soll das Duplizieren bzw. die Neuerstellung von Assets vermieden werden. Zum anderen sollen Konnektivität und Traceability in den Assets geschaffen werden, damit unser Designprozess robust ist. Der Datenfluss sorgt also für einen durchgängigen Entwicklungsprozess, der die Assets „zusammenhält“ und rückverfolgbar macht.

Wenn wir Standards verwenden, wollen wir von ihren Best Practices profitieren. Doch diese decken häufig nur einen kleinen Teil der Herausforderungen in der Fahrzeugentwicklung ab. Auch wir Toolintegratoren stehen vor diesen Herausforderungen, wenn wir Tools zusammenführen.

Um diesen Herausforderungen sowohl theoretisch als auch praktisch zu begegnen, richten wir unser Augenmerk auf das, was unserer Meinung nach für den Datenfluss ausschlaggebend ist: zum einen die Schnittstelle zwischen Tools und Standards und inwiefern diese Lösungen für die Problemstellung bieten; zum anderen der Übergang zwischen Tools und Datenformaten; hier wird der Datenfluss zwischen Tools und Aktivitäten potentiell behindert. Wir wollen diesen Übergang so gestalten, dass sich sowohl Standards als auch Tools bestmöglich nutzen lassen.

Standards organisieren

In unserer Datenfluss-Methode legen wir die Bedeutung der Standards fest und betrachten dabei zusätzlich, welche Rolle ein bestimmter Standard spielt. Es gibt dabei drei Kategorien von Standards, die wir nach folgenden Kriterien einordnen:

• Standards für Prozesse und Methoden – Diese definieren die Engineering-Praxis, nicht aber die Art der Ausführung;

• Standards für Datenaustausch und Konnektivität – Diese legen fest, wie wir Daten miteinander verbinden und die Tools integrieren; und

• Domänen-Standards – Diese definieren eine Engineering-Praxis oder -Aktivität in der Entwicklung von Assets.

Mit diesem Schichtenansatz für Standards können wir Datenfluss im Entwicklungsprozess ganzheitlich bestimmen und die domänenspezifischen Assets in einer synchronisierten Standardkonfiguration integrieren.

Gängige Standards im Automotive-Bereich

Im Automotive-Bereich lassen sich zahlreiche Standards anwenden. Unsere Ausführungen fokussieren sich auf die folgenden Standards in ihren speziellen Rollen.

• Der Engineering-Prozess fußt auf Methoden des Automotive SPICE. In dieser Rolle beschreibt ASPICE die Anforderungen der Engineering-Artefakte und die Rollen, die diese Artefakte bei der Entwicklung unserer Assets spielen.

• Engineering-Ergebnisse werden durch den AUTOSAR-Standard und dessen Datenaustauschformat ARXML gesteuert. In dieser Rolle beschreibt AUTOSAR die Entwurfssprache einer Fahrzeug- und einer Node-Architektur.

• Die Methoden des Systems Engineering werden mit der SysML beschrieben. Deren Ausdrücke liefern Ansätze, wie sich der Umstieg von Use-Cases auf Designblöcke verbessern lässt.

• Die Software-Engineering-Praxis lässt sich in Architekturdesigns in der UML beschrieben abbilden. Die UML ist eine natürliche Sprache für den Softwareentwickler, mit der sich der Übergang vom Softwarekonzept in die Implementierung darstellen lässt.

• Die Toolintegration lässt sich mithilfe von Webstandards und speziell Open Services for Lifecycle Collaboration beschreiben. Mit dem OSLC-Standard lassen sich verschiedene Tools bestimmen und im Sinne eines optimierten Engineering-Prozesses konsistent in einem Toolset integrieren.

Praktische Anwendung

Um das Integrationsmuster zu verdeutlichen, beleuchten wir eine praxisorientierte Anwendung von Standards im Automotive-Kontext.

Automotive SPICE liegt heute der Prozessgestaltung im Automotive-Bereich zugrunde. Es ist kein ausführbarer Prozess, bestimmt jedoch die Methoden und Ergebnisse, die ein effizienter Automotive-Engineering-Prozess liefern soll. Im Rahmen dieses Standards identifizieren wir die Kernsysteme und Software-Engineering-Methoden sowie auch unterstützende Prozesse wie z.B. Change- und Konfigurationsmanagement. Als einen kritischen Aspekt von ASPICE erkennen wir die geforderte Traceability zwischen den Assets. ASPICE spezifiziert nicht, mit welcher Methode sich Assets verbinden lassen; mithilfe des OSLC-Standards werden Repositories gekoppelt und Verbindungen zwischen Artefakten geschaffen. Wenn wir festlegen, dass unsere Repositories OSLC verwenden (oder entsprechende OSLC-Proxy-Elemente), kann das Fundament unserer Assets verbunden und über eine Reihe von Targets gesteuert werden. Damit wird die Absicht von ASPICE, bei jeder Änderung eine Impact-Analyse zu ermöglichen, erfüllt.

Um die Anforderungen aus ASPICE im Systems-Engineering zu erfüllen, definieren wir mit mithilfe der SysML den Inhalt der Applikation. Ein standardbasierter Datenfluss ermöglicht die Erfassung von Use-Cases, Interaktionen, Schnittstellen und Blöcken in einem evolutionären Prozess. Gleichzeitig schafft er mehr Verständnis sowie eine Designtiefe, die das Verhalten des Targets optimiert. Die Herausforderung bei der Einführung von SysML lag darin, dass ein Wechsel zur Automotive-Entwicklungssprache nicht möglich war. Um dieser Herausforderung zu begegnen, haben wir eine Brücke zwischen SysML und AUTOSAR geschaffen, die SysML-Blockelemente in AUTOSAR-Softwarekomponenten übersetzt; so lassen sich die Entwicklungsaktivitäten fortführen und gleichzeitig die Traceability sicherstellen.

Für bessere Traceability und Zugänglichkeit übertragen wir die AUTOSAR-Daten über einen Publisher in ein OSLC-Repository. ARXML ist zwar beim Datenaustausch hilfreich, unterstützt aber nicht die Traceability der Verbindungen. Durch das AUTOSAR-Design werden die AUTOSAR-nativen Assets und Beziehungen rückverfolgbar. Bei einer Weiterentwicklung des AUTOSAR-Designs, einschließlich Allokation und Netzwerkkonfiguration, sind diese Daten nun rückverfolgbar und steuerbar, und die Investition macht sich noch mehr bezahlt.

Um den Zielen von ASPICE im Systems-Engineering gerecht zu werden, müssen wir die Architektur und das Design unserer Software erfassen. AUTOSAR vereinfacht zum Teil diese Aufgabe, indem eine Standard-Laufzeitarchitektur vorgegeben wird. Dieses Software-Architekturdesign kann dann aus den Softwarekomponenten-Designs, Runnables und Interfaces bestehen. Die UML bietet eine natürliche Softwaresprache für die Abbildung des Designs, das bei Publikation in einem OSLC-Repository rückverfolgbar und verlinkt ist. Wenn die UML gemeinsam mit Codegenerierung eingesetzt wird, ist darüber hinaus der gesamte Lebenszyklus abgedeckt, von unseren ursprünglichen Requirements/SysML-Modell bis hin zu den einfachsten Designelementen.

Fazit: Standards in Schichten anwenden

Nach unserem Schichtenansatz bei der Integration von Standards beschreiben wir auf Basis von ASPICE zunächst das Ziel der Engineering-Aktivitäten. Als mittlere Schicht stellt der OSLC-Standard das Framework bereit, um die Interaktionen zwischen standardbasierten Beschreibungen zu definieren bzw. aufzulösen. Zu guter Letzt kommen AUTOSAR, UML und SysML als Domänen-Spezialisierungsstandards zum Einsatz, die im ASPICE-Kontext mittels OSLC die Traceability sicherstellen.

Der Vorteil dieser Designphilosophie ist, dass wir für unsere Engineering-Aufgaben gängige Standards und standardbasierte Tools verwenden können. Mit der effizienten Nutzung von OSLC und der Möglichkeit, über verschiedene Repositories Verbindungen herzustellen und aufrechtzuerhalten, schaffen wir einen durchgängigen Engineering-Prozess, der die Anforderungen von ASPICE erfüllt und in Sachen Anwendbarkeit und Wartbarkeit die herkömmlichen Methoden übertrifft. Bei dieser standardbasierten Integration profitieren wir zudem von den Vorteilen der Modellierung und führen den Datenfluss über das Modellierungstool hinaus über den gesamten Entwicklungsprozess weiter. Unser Ansatz ist innovativ und neuartig, weil er Standards so integriert und zusammenführt, dass die Effizienz im Engineering gesteigert wird.

Drei Wege zur Requirements Traceability Matrix

Functional Safety Software Engineering: Problemfälle Prozess & Qualität

Softwaredesign für die AUTOSAR Adaptive Platform

Modellbasiertes Software Engineering

Architekturprüfung für UML-Modelle

Dieser Beitrag stammt mit freundlicher Genehmigung der Autoren aus dem Tagungsband des Embedded Software Engineering Kongress 2018. Übersetzung: Sabine Pagler.

* Robert Baillargeon ist Senior-Systementwickler mit umfassenden Erfahrungen in Automotive-Systemen und Software-Design. Er ist Vice President of Engineering bei Sodius (seit April 2019 Sodius Willert).

* Walter van der Heiden ist Senior-Softwareentwickler mit umfassenden Erfahrungen im Bereich der Embedded-Software. Seit 2001 ist er CTO/ Senior Partner bei Willert Software Tools (seit April 2019 Sodius Willert).

(ID:46578936)