Bild 3: Der Entwicklungszyklus in Plattform-Paketen.

(Bild: PiNTeam)

| von Simon Moissl, Michael Rauscher, Martin Gruber
Bild 1: Aus dem Pilotprojekt wird eine Plattform. Je früher die Entscheidung für einen Re-Use-Ansatz fällt, desto mehr Synergien sind möglich.

Bild 1: Aus dem Pilotprojekt wird eine Plattform. Je früher die Entscheidung für einen Re-Use-Ansatz fällt, desto mehr Synergien sind möglich. PiNTeam

Ein gutes ECU-Produkt an den Start zu bringen, das ist der erste Schritt zum Erfolg. Wirklich duchstarten wird jedoch nur, wer daraus eine Produktplattform formen kann. Dieser Schritt ermöglicht eine gezielte Investition in ein Basisprodukt, das dann mit reduzierten Kosten und geringen Risiken in Projekte bei verschiedenen Anwendern umsetzbar ist (Bild 1).

Dabei spielt es keine Rolle, ob bereits bei Entwicklungsbeginn ein Ansatz wiederverwendbarer Plattformelemente geplant wird, oder dieser erst im Verlauf des Pilotprojektes oder im Rahmen weiterer Gespräche mit den Anwendern entsteht. Entscheidend ist: je früher die Entscheidung für einen Re-Use Ansatz fällt, desto größer sind die erzielbaren Synergien.

Eck-Daten: Plattform-Ansatz mit Generatoren für Software-Baukästen

Bei übergreifenden Plattformkonzepten ist es das Ziel, jedes Element des Software-Baukastens möglichst abgeschlossen und formal strukturiert nach einem wiederkehrenden Muster umzusetzen. Dies erleichtert die Integration in den Projekten und sorgt für eine gute Wartbarkeit im Projektverlauf. Der Kyoto-Ansatz unterstützt die Anwender in der Erstellung wiederverwendbarer Pakete, genannt GUnits.

Eine Plattform statt wiederkehrender Projekte

Bild 2: Re-Use-Anteile in einer Software-Lösung. Je besser die Abtrennung der wiederverwendbaren Anteile gelingt, desto leichter gelingt die Nutzung in Folgeprojekten.

Bild 2: Re-Use-Anteile in einer Software-Lösung. Je besser die Abtrennung der wiederverwendbaren Anteile gelingt, desto leichter gelingt die Nutzung in Folgeprojekten. PiNTeam

Eine aktuelle ECU-Software-Architektur vereint geschickt COTS-Produkte wie einen Classic Autosar Stack, produktspezifische Treiber und Applikationen sowie Integrationskomponenten anderer Entwicklungspartner. Je besser dabei die Abtrennung der wiederverwendbaren Anteile gelingt, desto leichter fällt später die Nutzung in den nächsten Projekten (Bild 2).

So gelingt es spielend, weitere Projekte durch den Einsatz eines solchen Baukastens effizient umzusetzen. Die Vorteile entstehen dabei entlang des kompletten A-SPICE-Zyklus. Vom Anforderungsmanagement bis hinein in die Tests profitieren die Anwenderprojekte von der bereits geleisteten Arbeit.

Der Classic-Autosar-Standard liefert für Projekte und Plattformen eine geeignete Basis. Die im Standard definierten Schnittstellen, Abstraktionsgrenzen und Konfigurationsoptionen eignen sich besonders für die Gestaltung wiederverwendbarer Applikationen. Definierte Austauschformate- und Modelle tun ihr Übriges bei der Ausgestaltung automatisierter Werkzeugketten und Workflows.

Spannend wird die Frage der Wiederverwendbarkeit im Bereich der Basis-Software. Über „Complex-Drivers“ lassen sich in Autosar-kompatiblen Basis-Software-Systemen maßgeschneiderte Module einbinden. So kann die generische Basis-Software bei Bedarf um spezifische Funktionen erweitert werden.

Auch im Bereich der Complex-Driver stellt der Classic-Autosar-Standard hilfreiche Mittel wie Schnittstellenvereinbarungen, Kompatibilitätsregeln und modellbasierte Konfigurationskonzepte bereit. Eine effiziente Nutzung dieser Grundlagen für die eigenen Plattform-Konzepte bedingt jedoch eine leistungsfähige Tool-Unterstützung.

Pakete statt Einzelteile liefern

Solange einzelne Software-Module nur innerhalb eines Projektes zum Einsatz kommen, ist die individuelle Ausgestaltung nur in diesem kleinen Kontext von Bedeutung. Datei- und Code Strukturen, Konfigurationsregeln und Dokumentation folgen dann den Projektregeln. Bei übergreifenden Plattformkonzepten muss aber das Ziel sein, jedes Baukastenelement möglichst abgeschlossen und formal strukturiert nach einem wiederkehrenden Muster umzusetzen. Die vereinfachte Integration in den Projekten sowie eine gute Wartbarkeit im Projektverlauf sind die Vorteile (Bild 3).

Synergieeffekte treten hier nicht nur durch die reine Wiederverwendung bereits hergestellter Module auf. Auch die Pflege während der Projektlaufzeit gestaltet sich mithilfe eines geeigneten QM-Konzeptes denkbar effizient. Dabei werden relevante Informationen zu den Re-Use-Paketen aus den Projekten in die Plattform-Entwicklung eingeliefert. Dabei kann es sich um Fehlfunktionen, Integrationsprobleme, unvollständige Dokumentation oder auch Funktionserweiterungen handeln. Die daraus entstehenden Updates oder Upgrades der Re-Use-Pakete lassen sich dann einfach und schnell in den relevanten Projekten übernehmen, ohne lange Integrationszyklen und manuelle Übernahmen in Kauf nehmen zu müssen.

Wie kann Kyoto helfen?

Der Kyoto-Ansatz unterstützt die Anwender in der Erstellung wiederverwendbarer Pakete. Solche Pakete werden in diesem Zusammenhang „GUnits“ (Generatoren-Einheit) genannt. Eine GUnit bringt alle notwendigen Bestandteile zum Einsatz in den Projekten mit. Zu den wichtigen Inhalten zählen die Parameterdefinition, Validierungsregeln, Templates und Meta-Informationen.

Anwender des Paketes müssen in der Lage sein, dieses zielgerichtet und effizient in das spezifische Projekt einzubinden. Die Parameterdefinition beschreibt alle Konfigurationsmöglichkeiten, über die das Paket an die spezifischen Anforderungen im Projekt anpassbar ist. Die in der Parameterdefinition beschriebenen Konfigurationsmöglichkeiten können komplexe Abhängigkeiten aufweisen. Validierungsregeln beschreiben diese Abhängigkeiten und informieren den Anwender bei Problemen. Templates enthalten die Abbildung in den Quellcode. Der Kyoto-Generator kombiniert die Templates während der Generierung mit den zuvor hinterlegten Konfigurationsparametern und erzeugt so das gewünschte Ergebnis. Ein Paket enthält zusätzlich Meta-Informationen, die für das Handling unabdingbar sind. Dazu gehören Versionsinformationen, Lizenzdaten und auch Verknüpfungen zu anderen Paketen. Mithilfe dieser Informationen kann Kyoto später erkennen, ob alle notwendigen Pakete verfügbar und in den korrekten, kompatiblen Versionen vorliegen.

Entwicklung der GUnits mit dem Designer

Software-Entwickler erwarten heute eine adäquate Entwicklungsumgebung inklusive intelligenter Editoren, Debuggern und Automatisierungswerkzeugen. Die Entwicklung geht leicht von der Hand, die Produktivität sowie Motivation bleiben auf einem hohen Niveau. Aus diesem Grund bringt Kyoto mit dem Designer eine vollumfängliche Entwicklungsumgebung für GUnits mit. Hier finden sich leistungsfähige Editoren für alle Dateiformate, umfangreiche Dokumentation sowie vollständige Debugging-Funktionen für alle aktiven Bestandteile einer GUnit.

Nutzer der GUnits sollen diese sorgenfrei in Projekten einsetzen können. Dafür muss die Qualität stimmen. Und nicht nur das: durch die Wiederverwendung der Pakete in mehreren Projekten entsteht ein großer Hebel, der die Qualität der Anwederprojekte in großem Umfang positiv wie negativ beeinflussen kann. Entsprechend ist die Qualität der GUnits von entscheidender Bedeutung. Kyoto Designer bringt hier Testumgebungen für alle aktiven Bestandteile der GUnits mit. Durch die strukturierte Erstellung von Test-Szenarien und Testfällen lassen sich damit Templates, Validierungsregeln oder auch Rechenregeln absichern. Standardisierte Testreports sind einfach und schnell in weiterführende Prozesse und KPI Dashboards integrierbar.

Ein Paket allein macht noch keinen Baukasten. Dieser entsteht durch die gesammelte Verfügbarkeit vieler Pakete im Verbund. Der Release-Zyklus des Kyoto Designer erlaubt die gesammelte Bereitstellung der entwickelten Pakete in beliebiger Kombination als Update-Site (siehe die Container in Bild 4). Diese Container bilden das Lieferartefakt der Plattform und stellen die Schnittstellte zu den Anwendern dar.

Übergeben werden die Container über zentrale Artefakt-Management Plattformen. Der fertiggestellte Container wird dort – für alle Projekte sichtbar – in standardisierter Form verfügbar. Ein einfacher, direkter und reproduzierbarer Rollout ist gewährleistet. Die Artefakt Repositories halten alle ausgelieferten Versionen verfügbar, ein regressiver Zugriff auf ältere Stände ist immer möglich.

GUnits anwenden mit dem Konfigurator

Bild 4: Der Kyoto Designer und der Konfigurator im Überblick. Der Designer ist eine vollumfängliche Entwicklungsumgebung für GUnits.

Bild 4: Der Kyoto Designer und der Konfigurator im Überblick. Der Designer ist eine vollumfängliche Entwicklungsumgebung für GUnits. PiNTeam

Die Entwickler und Integratoren im Anwenderprojekt setzen sich mit der Übernahme unterschiedlicher Zulieferungen in den Projektkontext auseinander. Entsprechend stellt der Kyoto-Konfigurator ein effizientes und übersichtliches Werkzeug bereit, um Baukastenelemente schnell und einfach in das Projekt zu integrieren. Die gewünschten Container werden per Update-Mechanismus direkt aus dem Artefakt-Repository in die Konfigurator-Umgebung übernommen.

Der Anwender kann sich nun auf die zielgerichtete Nutzung der bereits vorbereiteten Baukastenelemente konzentrieren. Dabei unterstützt der Kyoto-Konfigurator anhand der hinterlegten Parameterdefinitionen und stellt übersichtliche Editoren und Bearbeitungsmöglichkeiten bereit. Durch die verfügbare Live-Validierung, basierend auf den in der GUnit hinterlegten Validierungsregeln, verfügt der Anwender über ein direktes Feedback während der Konfigurationsarbeit. Eine Kommentarfunktion erlaubt die Ergänzung nützlicher Hinweise direkt an den Konfigurationsparametern. Dies erleichtert nicht nur Analyse und den Review, sondern lässt sich auch als zusätzliche Ebene für die Anforderungsverfolgung nutzen.

Weitere wiederverwendbare Pakete

Bild 5: Kyoto-Paketypen und ihre jeweiligen Features und Inhalte im Überblick.

Bild 5: Kyoto-Paketypen und ihre jeweiligen Features und Inhalte im Überblick. PiNTeam

Neben den generierbaren GUnits stehen zwei weitere Pakettypen zur Verfügung. Oftmals liefern Rahmenprozesse bereits Informationen, wie bestimmte GUnits zu konfigurieren sind. Hier wird eine sinnvolle Möglichkeit benötigt, um Informationen beliebiger Art in Konfigurationsdaten zu übernehmen. Dabei kommen IUnits ins Spiel. Diese beinhalten maßgeschneiderte Import-Logik, die bei der Entwicklung im Designer perfekt an die Vorprodukte anpassbar sind. Auch diese IUnits werden wie andere Bestandteile der Plattform in den Baukasten-Container gepackt. Sie stehen damit den Integratoren in den Projekten schnell und einfach zur Verfügung. Die Import-Logik wird also einmalig im Kyoto Designer entwickelt und danach in allen passenden Projekten wiederverwendet.

Dabei spielt das Format der bereitgestellten Vorinformationen keine große Rolle, alle gängigen Formate werden unterstützt. Ein Tool kommt selten allein! Für ein gutes Handling bei der Integration muss sich Kyoto daher in Werkzeugketten integrieren lassen. EUnits ermöglichen die Herstellung maßgeschneiderter externer Werkzeuganbindungen. Sie erlauben die Steuerung anderer Werkzeuge und die Anbindung des Datenstromes (Eingangs- und Ausgangsdaten) an den Kyoto-Konfigurator-Workspace. Externe Generatoren, Analysewerkzeuge oder auch Reporting-Tools lassen sich so bequem integrieren (Bild 5).

Kyoto in Safety-Projekten

Viele Generatoren-basierte Ansätze verlieren im Kontext sicherheitsrelevanter Projekte schnell an Vorteilen. Fehlt das Vertrauen in den Generator, so müssen generierte Artefakte manuell auf Korrektheit überprüft werden. Dies erzeugt erhebliche Mehraufwände und kostet wertvolle Zeit. Für den Kyoto-Generator ist aus diesem Grund ein Qualifizierungs-Kit verfügbar, dass bei Bedarf eine automatisierte Qualifizierung nach ISO26262 für den Einsatz bis ASIL-D bereitstellt.

Simon Moissl

Leitender Architekt KYOTO bei PiNTeam

Michael Rauscher

Projektleiter KYOTO und Rollouts bei PiNTeam

Martin Gruber

Chief Technology Officer bei PiNTeam

(na)

Kostenlose Registrierung

Der Eintrag "freemium_overlay_form_all" existiert leider nicht.

*) Pflichtfeld

Sie sind bereits registriert?