Valeo: Softwarevalidierung für Embedded-Controller

Author(s):
Wilfried Dietrich - Testerentwicklung bei Software + Systeme Erfurt GmbH
Tilo Thiessenhusen - Testerentwicklung bei Software + Systeme Erfurt GmbH

Industry:

Products:
Real-Time Module, LabVIEW, Software

The Challenge:
Validierung sicherheitskritischer Software für embedded Controller unter Ausschluss der Umgebungsschaltung des µControllers.

The Solution:
Aufbau eines flexiblen Testsystems bestehend aus NI-Komponenten unter LabVIEW Real-Time zur gezielten Stimulation der Controllereingänge, sowie zur zeitgenauen Beobachtung der Controllerreaktionen.

Sicherheitskritische Software für embedded Controllerapplikationen im Auto

Ein herausragendes und besonders auffälliges Beispiel für die immer umfassendere Durchdringung unseres Alltagslebens mit computerbasierten Funktionen ist zweifellos der Automobilbau.

Die ständig steigenden Ansprüche an Komfort, Leistungsfähigkeit und Sicherheit, die den modernen Fahrzeugbau prägen, bringen es mit sich, dass immer mehr Fahrzeugfunktionen durch den Einsatz von Elektronik bestimmt sind. Im Kern dieser fortwährend wachsenden Zahl von elektronischen Fahrzeugkomponenten ist zumeist ein µController zu finden, womit die zwangsläufig dazugehörige Software zu einer tragenden Säule für die gesamte Baugruppe wird. Insbesondere dann, wenn die entsprechende Baugruppe sicherheitsrelevante Funktionen wahrnimmt, kommt der Validierung der eingesetzten Software eine essenzielle Bedeutung im Entwicklungsprozess zu.

Als Hersteller elektrischer Schließsysteme für Fahrzeuge ist die Firma Valeo Sicherheitssysteme GmbH Erdweg umfassend mit dieser Problematik konfrontiert. Im konkreten Fall war die Aufgabe die Entwicklung einer elektrischen Lenksäulenverriegelung (ELV). Mit dem Übergang zu elektronisch codierten Schließsystemen in den Fahrzeugen verliert der Fahrzeugschlüssel zunehmend seine althergebrachte, mechanisch bestimmte Form und Funktion. Damit wird der Wechsel vom direkt manuell betätigten Lenksäulenschloss klassischer Bauart zu einer elektronisch ansteuerbaren elektromechanischen Baugruppe zur unmittelbaren konstruktiven Notwendigkeit. Der sicherheitskritische Aspekt dieser Baugruppe ist auch für den außenstehenden Betrachter direkt greifbar und muss zwei Eigenschaften aufweisen: Zum einen geht es hier natürlich in gewohnter Weise um den Schutz des Fahrzeugs vor Diebstahl (security-critical function), d. h. die Baugruppe muss in hohem Maße sowohl mechanisch als jetzt eben auch elektronisch manipulationsresistent sein.

Gleichzeitig sind jedoch auch hohe Anforderungen die Insassensicherheit (safety-critical function) betreffend zu erfüllen. So darf z. B. das Verriegeln der Lenksäule unter keinen Umständen während des Fahrbetriebes ausgelöst werden. Das sind aber wiederum nur Einzelaspekte aus einem wesentlich umfangreicheren Anforderungskatalog an die Baugruppe. Unter diesen Randbedingungen wird aus der scheinbar so einfachen Zielstellung einer elektromechanischen Betätigung der Lenksäulenverriegelung eine hochkomplexe und facettenreiche Steuerungsaufgabe.

 

Validierung sicherheitskritischer Software mit LabVIEW RT

Das korrekte Funktionieren der Baugruppe wird letztlich immer erst durch das perfekte Zusammenspiel von Mechanik, Elektronik und Software gewährleistet. Um die Komplexität bei der Validierung aller Funktionen der Baugruppe beherrschbar zu gestalten, ist man bemüht, zunächst die Teilkomponenten einer getrennten Validierung zu unterziehen. Im Falle der notwendigerweise sehr hardwarenah programmierten Software ist diese nur schwer von dem für die ELV eingesetzten µController zu lösen, um sie einer getrennten Verifikation zugänglich zu machen. Deshalb hat sich die Firma Valeo Sicherheitssysteme GmbH Erdweg zu folgender Teststrategie entschlossen:

Das korrekte Funktionieren der Software sollte bezogen auf die Reaktionen an den Controllerpins unter Ausschluss der übrigen zur ELV gehörenden Elektronik verifiziert werden. Die normale Umgebungselektronik des Controllers sollte im Testfall durch ein entsprechendes Testbett simuliert werden. Mit dieser Vorgehensweise ist es möglich, das Verhalten der Software nicht nur in einer korrekt funktionierenden Umgebung zu testen, sondern auch gezielt Fehlerszenarien einzustellen, die potenziell möglich und damit beherrschbar sein müssen, die aber mit der realen Umgebungshardware nicht kontrollierbar, reproduzierbar und eventuell auch nicht reversibel darstellbar sind.

Der Auftrag für die Entwicklung eines geeigneten Testsystems erging an die Firma Software + Systeme Erfurt GmbH. Ergänzende Entwicklungsforderungen waren, dass der Tester aus Gründen der Wartbarkeit und der Systempflege weitestgehend aus Industriestandardkomponenten mit guter Verfügbarkeit und Service bestehen sollte, in Kombination mit einer gut zu beherrschenden und für weitere Entwicklungen offenen und flexiblen Systemsoftware. Dies stand u. a. deshalb im Vordergrund, da dieser Tester gleichzeitig als Musterimplementation für andere, ähnlich gelagerte Projekte dienen sollte (und dient). Eine Recherche der Marktsituation ergab, dass dieses Anforderungsprofil besonders vorteilhaft mit Komponenten der Firma National Instruments in Verbindung mit deren Programmier- und Anwendungsumgebung LabVIEW RT umsetzbar war.

LabVIEW qualifizierte sich für diese Aufgabe insbesondere durch die anschauliche Widerspiegelung der Testerstruktur in der Programmierumgebung, sowie durch seine umfassenden Möglichkeiten bei der Aufbereitung und Darstellung der aufgezeichneten Testdaten. In der echtzeitfähigen Version LabVIEW RT ist das System zudem in der Lage, die erforderlichen Stimuli zeitgenau absolut bzw. ereignisbezogen bereitzustellen, wie auch den jeweiligen Zustand sämtlicher Beobachtungspunkte in der erforderlichen Zykluszeit von 1 ms aufzuzeichnen.

 

Der Gesamtaufbau des Testers besteht aus Stromversorgungsmodulen, einem Standard-PC, auf dem das Bedienfrontend für die Testvorbereitung und Auswertung läuft, sowie einem Rack, das den RT-Rechner und die I/O-Karten von National Instruments enthält. Diese I/O-Karten sind mit einer Adapterkarte verbunden, die einen mit der zu verifizierenden Software programmierten und zur ELV baugleichen µControllerchip trägt. Zur Ansteuerung der ELV muss ein spezieller, serieller Kommunikationskanal bereitgestellt werden. Da ein Verhaltensmodell des Kommunikationspartners der ELV bereits vorlag, wurde dieses auf einem zweiten, ebenfalls auf der Adapterkarte untergebrachten Controller implementiert. Dieses Verhaltensmodell realisiert die Erzeugung der erforderlichen Kommandosequenzen und wickelt das dazugehörige Protokoll ab. Dieses Verhaltensmodell wird vor Testbeginn aus LabVIEW heraus parametrisiert und kann hinsichtlich bestimmter Ereignisse aus LabVIEW heraus über digitale Steuerleitungen getriggert werden. Damit kann sowohl eine korrekte, als auch eine gezielt fehlerhafte Kommunikation zum ELV-Controller realisiert werden. Die gesamte während eines Tests ablaufende Kommunikation wird fortlaufend mitgeschnitten, mit Zeitstempeln und Fehlercodes versehen und nach Ende eines Durchlaufs über die serielle Schnittstelle an das LabVIEW-System zur Aufzeichnung und Darstellung übergeben. Die Stimulation der übrigen digitalen und analogen Eingänge des ELV-Controllers erfolgt über Ausgänge des LabVIEW-Systems.

Parallel dazu wird der elektrische Zustand aller Pins des Controllers über Eingänge des LabVIEW-Systems erfasst, aufgezeichnet, und es werden teilweise sofort Reaktionen ausgelöst. So werden die zum Controller gehenden Signale, wo erforderlich, aus den vom Controller kommenden Signalen abgeleitet und in Echtzeit durch LabVIEW RT zugewiesen. Das so programmierbare Antwortverhalten lässt sich dabei gezielt im Sinne einer Fehlersimulation beeinflussen. Die Durchführung eines bestimmten Tests erfolgt skriptbasiert. Mit der Erstellung dieser einfach strukturierten Skripts legt der Testingenieur die Parameter der Stimulikanäle fest, bestimmt entweder, zu welchem absoluten Zeitpunkt ein bestimmter Stimulikanal einen bestimmten Wert annehmen soll bzw. auf welches Ereignis hin innerhalb welcher Zeitspanne ein Stimulikanal seinen Wert oder seine Signalform ändern soll. Darüber hinaus kann festgelegt werden, welchen Wertebereich ein bestimmtes vom Controller ausgegebenes Signal innerhalb eines absolut oder ereignisrelativ bezogenen Zeitfensters annehmen darf oder nicht. Dieses Skript wird vor Testbeginn von der LabVIEW-Applikation eingelesen, interpretiert und in Steuertabellen umgesetzt. Der eigentliche Testdurchlauf erfolgt mittels einer synchronisierten Echtzeitschleife, die auf minimale Zykluszeit optimiert wurde. Nach Ende des Tests werden die Skriptinformationen zur automatisierten Bewertung der Aufzeichnungsdaten herangezogen. Durch die grafische Aufbereitung der Auswertung können fehlerhafte Stellen im Ablauf anschaulich hervorgehoben und schnell einer Analyse durch den Test- bzw. Entwicklungsingenieur zugänglich gemacht werden.

Die bisherigen Einsatzerfahrungen bei der Firma Valeo Sicherheitssysteme GmbH Erdweg zeigen, dass das Testsystem den gestellten Anforderungen gerecht wird, leicht zu handhaben ist und mit überschaubaren Aufwand an die Erfordernisse anderer Projekte angepasst werden kann.

 

 

Author Information:
For more information on this Case Study, contact:
Wilfried Dietrich
Testerentwicklung bei Software + Systeme Erfurt GmbH

Browse All Case Studies »