Standards und Modellierung

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.
In der Automotive-Entwicklung existieren inzwischen auf verschiedenen Stufen des Software Engineering zahlreiche verschiedene Standards, die das Ziel verfolgen, Prozesse zu optimieren und Systeme von Grund auf sicherer zu gestalten. Doch wie kann man diese verschiedenen Standards zusammenbringen und das Beste aus Ihnen herausholen, ohne sich als Entwickler zu verzetteln?

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.