Diesen Artikel herunterladen - HANSER automotive

hanser.automotive.de

Diesen Artikel herunterladen - HANSER automotive

Entwicklungswerkzeuge

Sicher auf

Multi-Core umsteigen

Die Einführung von Multi-Core-Systemen erhöht das Risiko, den Ressourcenbedarf

falsch einzuschätzen und bei der späteren Integration böse Überraschungen zu

erleben. Mit einem sorgfältig aufgebauten virtuellen Integrationsmodell lassen sich

Probleme frühzeitig erkennen und vermeiden. Darüber hinaus sorgt ein entwicklungsbegleitender

Soll-Ist-Vergleich für eine nachhaltige Risikominimierung.

Obgleich sich die Automobilindustrie

schon seit einiger Zeit mit der reibungslosen

Einführung von Multi-

Core-Systemen beschäftigt, birgt deren

erstmaliger Einsatz nüchtern betrachtet

immer noch signifikante Risiken. Zu den

klassischen Problemen der Migration eines

Systems auf eine neue Hardware

(Entwicklungsumgebung, Compiler, Debugger

etc.) gesellen sich neuartige Fragestellungen

aus dem Bereich Software-

Architektur. Kann man bei Single-Core-

Systemen noch auf explizite Architektur-

Konzepte verzichten (und alles „irgendwie

coden“), müssen wir beim Übergang

zu Multi-Core-CPUs mindestens die Frage

nach der Funktionsverteilung auf die

Kerne beantworten. Hinzu kommen Fragen

nach effizienter Ressourcenauslastung

und der damit verbundenen Vorhersage

des Zeitverhaltens. Insbesondere

letztere ist jedoch essentiell für die qualifizierte

Auswahl der Hardware-Plattform

und deren Fähigkeit, die Ressourcenanforderungen

der implementierten Funktionen

zu erfüllen.

Diese Fragestellungen treffen vor allem

den Integrationsverantwortlichen

für das Steuergerät. Das kann der Bauteileverantwortliche

seitens des OEMs

sein, oder auch der Projektverantwortliche

auf Seiten des Tier-1-Zulieferers, jeweils

zusammen mit dem Ecu-Software-Architekten.

Um die Komplexität der Entwicklung

von Multi-Core-Steuergeräten zumindest

annähernd auf das Maß von klassischem

Entwurf für Einzelprozessor-

Systeme zu reduzieren, ist ein systematisches

Vorgehen anzuraten, das sich an

dem etablierten V-Modell – grob gegliedert

in Konzept-, Entwicklungs- und Integrationsphase

– orientiert. In diesem

Artikel werden zwei wesentliche Prozessbestandteile

vorgestellt, die geeignet

sind, die aufkommenden Probleme

beherrschbar zu machen:

WWZum einen empfehlen wir das frühzeitige

Erfassen des Timing-relevanten

Wissens in einem „Virtuellen

Integrationsmodell“ bereits in der

© Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-automotive.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern

Alle Bilder: Symtavision

38 HANSER automotive 10 / 2013

© Carl Hanser Verlag, München


Entwicklungswerkzeuge

wendigen Schritte zur Durchführung

dieser Methodik erläutert.

Planung – Teil 1:

Machen Sie Ihre Timing-

Annahmen explizit

Eine der ersten Fragestellungen, für die

ein virtuelles Integrationsmodell herangezogen

werden kann, ist die Prüfung,

wann die Migration auf eine Multi-Core-

Plattform durch die erwartete Funkti-

Bild 1: Begleitung

des klassischen,

auf die Funktion

fokussierten Entwicklungsprozesses

durch die

Planung und Verteilung

der Ressourcen

und die

prozessbegleitende

Validierung.

Konzeptphase. Anhand eines solchen

Modells lassen sich mögliche

Integrationsprobleme früh erkennen

und Gegenmaßnahmen planen, inkl.

des Vorhaltens von Reserven.

WWZum anderen brauchen wir einen

entwicklungsbegleitenden Soll-Ist-

Vergleich. Der tatsächliche Ressourcenverbrauch

wird erst im Zuge der

Implementierung festgelegt. Hier

gilt es, durch einen systematischen

Abgleich des „Soll“-Zustands (basierend

auf dem virtuellen Integrationsmodell)

mit dem „Ist“-Zustand

(basierend auf Beobachtung der

tatsächlichen Implementierung)

Abweichungen frühzeitig zu erkennen

und Gegenmaßnahmen einzuleiten.

Dieses Vorgehen stellt in komplexen

Migrationsvorhaben sicher, dass signifikante

Integrationsprobleme von Anfang

an vermieden werden können oder zum

frühestmöglichen Zeitpunkt sichtbar

werden. Im Folgenden werden die notonslast

notwendig ist. Das Thema Multi-Core

ist kein Selbstzweck und in der

Planung sollten die Fähigkeiten der Zulieferer,

die Kosten, und natürlich die relevanten

Produktionstermine berücksichtigt

werden (Bild 1). Daher gilt es,

zunächst ein geeignetes Timing-Modell

aufzustellen, das alle bestehenden Informationen

enthält und eine erste

quantifizierte Vorhersage liefert. Ein solches

Integrationsmodell oder Timing-

Modell benötigt anfangs nur eine gerin-

© Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-automotive.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern

»


Entwicklungswerkzeuge

Bild 2: Schematischer Ablauf der Systemauslegung unter gegebenen

Unsicherheiten.

ge Menge an Informationen: Funktionen

und Software-Teile erfassen wir als

abstrakte Zeitverbraucher mit einfachen

Eigenschaften: Laufzeit, Zykluszeit,

Kommunikationsaufkommen etc.

Ergänzt wird dieses Modell durch eine

erste Schedulingkonfiguration, um die

virtuelle Integration zu vervollständigen.

Code benötigen wir nicht.

WWFür bestehende Implementierungen,

die lediglich auf die neue Hardware

portiert werden, stellen wir den

Ressourcenbedarf und die zeitlichen

Anforderungen zusammen, z. B. aus

Messungen bestehender Steuergeräte.

Für diese Funktionen kann

zunächst mittels einer einfachen

Skalierung das im serienübergreifenden

Einsatz typische Wachstum der

Prozessorlast modelliert werden,

z. B. „alles 30% schneller“.

WWFür neu zu implementierende Funktionen

werden fundamentale Kennzahlen

zusammengetragen, um den

Ressourcenbedarf in etwa einzuschätzen.

Welche Datenraten sind

zu erwarten? Handelt es sich um

eine komplexe Funktion oder um

eine einfache Zustandsmaschine?

Welche Art der Implementierung

»

die Ausführungszeiten von unveränderten

Funktionen bei einer Migration

auf diese Hardware?

Es ist eine Tatsache, dass wir diese Aspekte

zu Projektbeginn nur recht grob

abschätzen können. Viel zu oft führt

dies leider dazu, dass die Daten zu diesem

Zeitpunkt gar nicht erst zusammengestellt

werden. Damit bringen wir

uns leichtfertig um die Möglichkeit einer

vorausschauenden Planung, die oft

mit überraschend wenig Aufwand sehr

gute Ergebnisse erzielen kann. Daher

sagen wir: Nehmen Sie die Ihnen bekannten

Daten, auch wenn es „wenig“

erscheint. Es sind die besten Daten, die

Sie haben. Nutzen Sie sie! Planen Sie!

Machen Sie die Informationen explizit

sichtbar. Nur so können wir eine fokussierte

Recherche durchführen, und nur

so kann mit den gegebenen Unsicherheiten

belastbar gearbeitet werden.

Planung – Teil 2:

Unsicherheiten absichern

Um den gegebenen Unsicherheiten

Rechnung zu tragen, sollte das virtuelle

Integrationsmodell Reserven vorsehen.

Machen Sie auch diese explizit. Planen

Sie Zeitverbraucher als Platzhalter ein, z.

B. für noch nicht ausspezifizierte Funktionen,

und für das „Grundrauschen“ von

Interrupts und Basissoftware. Schlagen

Sie Sicherheitsabstände auf kritische

Funktionen auf. Haben Sie keine Angst

Natürlich hat man zu Beginn eines Steuergeräte-

Projektes nur wenig belastbare Daten. Aber es

sind die besten, die Sie haben. Nutzen Sie sie!

Dr. Kai Richter, CEO Symtavision

empfehlen die Vorserienentwickler?

Gab es vergleichbare Funktionen,

aus denen man die Timing-Anforderungen

grob ableiten kann?

WWAußerdem muss die Hardwareplattform

(oder die zur Auswahl stehenden

Kandidaten) selbst modelliert

werden. Welche Architekturen stehen

zu Auswahl (Single-Core, Multi-

Core, Speicherarchitektur, Betriebssysteme,

Scheduling- und Sicherheits-Konzepte)?

Wie verhalten sich

vor groben Schätzungen. Auf dieser ersten

Ebene spielt die Genauigkeit der einzelnen

Werte eine untergeordnete Rolle.

Wichtig ist, überhaupt ein Referenzmodell

zu erstellen, an dem sich dann die

Umsetzung messen lassen kann. Spätere

Anpassungen und Korrekturen sind jederzeit

möglich. Für eine Ressourcen-effiziente

und gleichzeitig zuverlässige

Systemauslegung empfiehlt sich das im

Bild 2 dargestellte und im Folgenden vorgestellte

Vorgehen.

© Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-automotive.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern

40 HANSER automotive 10 / 2013

© Carl Hanser Verlag, München


Entwicklungswerkzeuge

WWDie Funktionslaufzeiten und Aktivierungsraten

werden nach bestem

Wissen angenommen. Für Funktionen

mit außergewöhnlicher Unsicherheit

werden explizite Zeit-Reserven

angenommen (z. B. in Höhe

von 25% der Laufzeit). Oftmals

können Erfahrungswerte aus vergangenen

Projekten hinzugezogen

werden (Stichwort: Funktionshub).

WWVirtuelle Integration“: Legen Sie

eine initiale, sinnvolle Software-Architektur

fest (vor allem Mapping zu

Cores und optional schon Teile des

Schedules), manuell oder mittels

einfacher Heurisiken. Dieses Vorgehen

nimmt eine Optimierung zu

»

einem späteren Zeitpunkt nicht

vorweg, erlaubt aber trotzdem eine

erste Einschätzung des möglichen

Lösungsraums.

WWSensitivitätsanalyse. Prüfen Sie

anhand des virtuellen Integrations-

Modells, wie robust das System

gegenüber Änderungen an den o. g.

Anforderungen reagiert. Scheduling-

Analyse-Werkzeuge können das

heute automatisieren. Dabei werden

sich einige Komponenten als weniger

kritisch herausstellen, aber es

wird auch Elemente mit einer knappen

Auslegung geben. Für diese gilt

es, die Spezifikation so früh wie

möglich so genau wie möglich zu

erfassen und gegebenenfalls die

Annahmen zu überdenken.

WWZeigt die Sensitivitätsanalyse auf,

dass das System in ausreichendem

Maße mit einer Abweichung von

den Annahmen umgehen kann, wird

ein Referenzmodell abgeleitet, dass

eine zentrale Rolle im weiteren Entwicklungsprozess

spielt.

Dieses Referenzmodell können wir

frühzeitig im Entwicklungsprozess aufstellen,

viel früher als dies oftmals gedacht

wird. Ein solches Vorgehen ist bei

vielen unserer Kunden etabliert. Tatsächlich

werden sich im Laufe der Umsetzung

und Implementierung Abweichungen

zum Referenzmodell einstellen,

aber wir können das Referenzmodell

jederzeit anpassen.

Validierung – Teil 1:

Das Frühwarnsystem

Das Referenzmodell ist nun das Rückgrat

bei der weiteren Entwicklung des

Steuergeräts. Es bietet die folgenden

Vorzüge:

WWDer aktuelle Planungsstand bezüglich

der zeitlichen Anforderungen

der einzelnen Funktionen und deren

Mit den virtuellen Integrationsmodellen von

SymTA/S reduzieren unsere Kunden (z. B. Bosch,

Denso, u.v.m.) Migrations-Risiken beim Umstieg auf

Multi-Core von Anfang an.

Dr. Simon Schliecker, Senior Application Engineer bei Symtavision

Implementierung ist optimal dokumentiert.

WWIm Gegensatz zu Verhaltensmodellen

(Code) erfordert das Modell

keine Implementierung der einzelnen

Funktionen, kann aber die relevanten

Timing-Eigenschaften in sich

aufnehmen.

Ein entscheidender Beitrag zur Risikominimierung

kommt nun dem kontinuierlichem

Abgleich der Referenzmodells

mit der tatsächlichen Implementierung

zu. Dabei ist es durchaus üblich, dass

einige Teilfunktionen bereits einen relativ

reifen Entwicklungsstand haben und

z. B. auf Eval-Boards oder frühen Integrationsstufen

bereits ausgemessen

werden können, während andere Funktionen

noch komplett fehlen.

Ohne das Integrationsmodell wäre

dann keine abschließende Prüfung der

Teile möglich. Anhand des Referenzmodells

können wir hingegen prüfen, ob

eine vorliegende Implementierung die

Erwartungen erfüllt oder hinsichtlich

der Integration Ressourcenprobleme zu

erwarten sind. Im ungünstigen Fall haben

wir aufkommende Problem frühzeitig

erkannt und können entsprechende

Gegenmaßnamen einleiten: Entwe-

»

© Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-automotive.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern

www.hanser-automotive.de


Entwicklungswerkzeuge

Bild 3: Handlungsmöglichkeiten bei von der Erwartung abweichenden Implementierungen.

der wird das Referenzmodell an die Gegebenheiten

angepasst (durch „Verbrauch“

der eingeplanten Implementierungsreserven)

oder es werden alternative

Implementierungen geprüft, die einen

effizienteren Ressourceneinsatz

nach sich ziehen. Beiden Aspekte werden

in Bild 3 illustriert.

Diese Gegenüberstellung kann mit

jedem neuen Implementierungsstand

wiederholt werden. Wir empfehlen einen

Soll-Ist-Vergleich mindestens zu

den Integrationsstufen bzw. Musterlieferungen.

Mit jeder Integrationsstufe

werden die neu hinzugekommenen Implementierungen

mit den ursprünglichen

Annahmen abgeglichen, so dass

schließlich eine Validierung des integrierten

Gesamtsystems möglich wird.

Validierung Teil 2 –

Implementieren und

Optimieren

Eine weitere zentrale Funktion des Timing-Referenzmodells

ist die Unterstützung

bei der Implementierung und

Optimierung einzelner Funktionen oder

des Gesamtsystems. Insbesondere

die neuen Freiheitsgrade (Mapping der

Teil-Funktionen bzw. Runnables auf

die einzelnen Cores, Festlegung des

Schedules, Verteilung der Daten) bergen

ein großes Optimierungspotenzial.

Sobald eine adäquate Bedatung

des Timing-Modells aufgrund der guten

Planungslage oder der fortschreitenden

Implementierung existiert, können

wir modellbasiert sehr effizient

eine Reihe von Architektur-Alternativen

konfigurieren und diese nach verschiedenen

Gesichtspunkten (zum

Beispiel Minimierung der Verarbeitungslatenz,

Nivellierung der Prozessorlast,

Maximierung der Nähe der Daten

zu den Funktionen oder Maximierung

der Zeitreserven) bewerten. Hierbei

ist Erfahrung und Intuition gefragt,

die algorithmisch ergänzt werden kann

durch etablierte Entwurfs-Regeln (zum

Beispiel Gruppierung von Runnables

anhand der Deadlines oder Asil-Einstufung)

oder durch Optimierungs-

Heuristiken.

Zusammenfassung

Die Einführung von neuen Technologien

wie Multi-Core-Prozessoren erhöht das

Risiko, den Ressourcenbedarf falsch einzuschätzen

und bei der Integration verschiedener

Softwarefunktionen relativ

spät im Projekt große Überraschungen

zu erleben. Hier kann ein sorgfältig aufgebautes

Virtuelles Integrationsmodell

dabei helfen, die Probleme frühzeitig zu

erkennen und zu vermeiden. Durch die

Kombination mit dem entwicklungsbegleitenden

Abgleich des „Soll“-Modells

mit tatsächlichen „Ist“-Daten aus der

Implementierung erfolgt eine nachhaltige

Risikominimierung. W (oe)

Dr. Kai Richter ist CTO bei

Symtavision.

Dr. Simon Schliecker ist Senior

Application Engineer bei

Symtavision.

© Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-automotive.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern

42 HANSER automotive 10 / 2013

© Carl Hanser Verlag, München

Weitere Magazine dieses Users
Ähnliche Magazine