Durchgängiger Prozess zur Umsetzung von automatisierten Komponenten- und Systemprüfungen im Automobilsektor

Author(s):
Torsten Bien - EDAG Engineering + Design AG

Industry:
Automotive, ATE/Instrumentation

Products:
LabVIEW, PXI/CompactPCI

The Challenge:
Entwicklung eines Konzepts und Systems, das den universellen Einsatz zur automatisierten Komponentenprüfung bis hin zur Systemprüfung im Automobilsektor bietet

The Solution:
Automatisches Durchlaufen von Testfällen, maschinelles Erfassen, Bewerten und Dokumentieren von Testergebnissen in einer Datenbank, wobei es sich um einen geschlossenen Validierungsprozess handelt, der aus der Datenbank gestartet und in dieser letztendlich beendet wird

Einführung

Die EDAG Engineering und Design AG hat ein Konzept und System entwickelt, welches den universellen Einsatz zur automatisierten Komponentenprüfung bis hin zur Systemprüfung im Automobilsektor bietet. Es werden Testfälle automatisch durchlaufen, Testergebnisse maschinell in einer Datenbank erfasst, bewertet und dokumentiert. Es handelt sich hierbei um einen geschlossenen Validierungsprozess, der aus der Datenbank gestartet und in dieser letztendlich beendet wird.

Der bisherige Funktions-Validierungsprozess

Bei bisherigen oder vergangenen Validierungsprozessen ist eine übliche Vorgehensweise, dass im ersten Schritt die Prüfspezifikation auf Basis der Funktionsbeschreibung (OEM-Lastenheft) und des Pflichtenheftes erstellt wird. Alle Dokumente werden hierbei in Papierform oder in einem Projektverzeichnis verwaltet. Änderungen, welche telefonisch oder via E-Mail bekannt gegeben werden, müssen in die Dokumente eingepflegt werden. Hierzu muss immer ein hoher Aufwand zur Sicherstellung der aktuellen Daten in allen Dokumenten betrieben werden.

Nach Erstellen der Prüfspezifikation erfolgt das manuelle Testen der Funktionalitäten nach Prüfvorschrift. Der Prüfingenieur stellt hierbei alle Aktionen direkt, über die Prüfperipherie oder über Hilfsmittel (z. B. Restbussimulation) am Prüfling ein. Er muss sicherstellen, dass alle Einstellungen korrekt erfolgen. Die in der Prüfvorschrift definierten Soll-Reaktionen werden mit den tatsächlichen Ist-Reaktionen verglichen und ausgewertet. Als weiterer Nachteil dieses Validierungsprozesses ist zu beachten, dass bei dieser Verifizierung unmöglich alle Schnittstellen mit definierten Werten eingestellt werden können, sondern nur diese, die der Funktionseinstellung dienen.

Letztendlich erfolgt die manuelle Dokumentation der Prüfergebnisse. Hierzu wird ein Dokument erstellt, welches die einzustellende Aktion, die definierte Sollreaktion, die tatsächliche Ist-Reaktion sowie das ausgewertete Ergebnis beinhaltet. Hier stellt sich die Frage: Können die festgestellten Ergebnisse immer wieder nachvollzogen werden? Diese Frage kann sich jeder Prüfingenieur selbst beantworten.

Der automatisierte Funktions-Validierungsprozess

Der automatisierte Validierungsprozess setzt bei der Durchgängigkeit an. Im besten Fall (abhängig von Systemlieferant und OEM) werden die Funktionsbeschreibung (OEM-Lastenheft), Pflichtenheft und Prüfspezifikation in einer Datenbank erstellt und gepflegt. Änderungen oder neue Requirements fließen über ein Änderungsmanagement direkt in die Datenbank ein. Es wird immer die Aktualität aller Daten sichergestellt.

Nach Erstellen der Prüfspezifikation erfolgt das automatisierte Testen der Funktionalitäten. Hierzu muss der Prüfingenieur die verbalen Beschreibungen der einzustellenden Aktionen sowie Soll-Reaktionen als ausführbare Prüfscripte in der Datenbank hinterlegen. Alle Einstellungen sowie das Rücklesen der Reaktionen erfolgen dann automatisch über die Mess- und Steuerbox. Die tatsächlichen Ist-Reaktionen werden aufgenommen und mit den Soll-Reaktionen automatisch verifiziert. Alle während eines Prüffalls anliegenden Schnittstellenwerte werden vom System erfasst und abgelegt.

Letztendlich erfolgt die automatische Dokumentation der Prüfergebnisse. Hierzu werden in der Datenbank neben den bereits definierten Aktionen, Sollreaktionen sowie deren Scripte, die tatsächliche Ist-Reaktion und das interpretierte Ergebnis maschinell abgelegt. Die Prüfungen können ohne großen Aufwand beliebig oft und immer reproduzierbar wiederholt werden.

Technische Realisierung

Der oben beschriebene automatisierte Funktions-Validierungsprozess wird wie in der Abbildung dargestellt realisiert.

Datenbank

Bevor der Prozess aus der Datenbank gestartet werden kann, müssen zunächst alle benötigten Scripte und deren Auswirkungen auf die physikalischen Schnittstellen des Testsystems festgelegt werden. Dies erfolgt mit der Applikation EDAG-Tabellenverwaltung, ein von EDAG entwickeltes Tool, welches dem Benutzer eine komfortable Plattform zur Definition und Verwaltung der Testscriptanweisungen sowie der Prüflings Ein- und Ausgänge mit entsprechender Zuordnung der Testsystem Schnittstellen bietet.

Letztendlich werden hier die Scriptbefehle mit den Prüflings- bzw. Testsystem-Schnittstellen und der Parameterübergabe zusammengeführt. Die Scripte können vom Anwender frei in der Namensgebung festgelegt werden, was wiederum den Vorteil bietet, Standardscripte zu definieren bzw. zu verwenden. Das Werkzeug EDAG-Tabellenverwaltung sorgt dafür, dass die Abhängigkeiten zwischen den Definitionsdateien immer korrekt bleiben und stellt gleichzeitig über die grafische Benutzeroberfläche eine einfache und komfortable Möglichkeit zur Bearbeitung bereit.

Als Datenbank kann entweder eine SQL-kompatible oder eine proprietäre Datenbank mit COM-Schnittstelle eingesetzt werden. Gerade in Betrachtung des Requirement Management bietet sich z.B. DOORS aus dem Hause Telelogic an, die über COM in den Gesamtprozess eingebunden wird. Aufgrund der weit verbreiteten Verfügbarkeit kann aber auch z. B. ACESS eingesetzt werden.
In der Datenbank befindet sich die Prüfspezifikation. Diese besteht aus der verbalen Beschreibung mit Aktion und Soll-Reaktion, den dazugehörigen Testfällen sowie jeweils einer Spalte für die zu dokumentierende Ist-Reaktion und dem entsprechenden Ergebnisstatus. Die Testfälle werden aus Testschritten (Testscripten) zusammengesetzt, die zuvor in der EDAG-Tabellenverwaltung definiert wurden und dem Anwender in der Datenbank zur Verfügung stehen.

Kodier-Interface

Das Kodierinterface ist ein EDAG-AddOn in der Datenbank und ermöglicht dem Anwender, dass die Scripte aus der Testfalldefinition automatisch extrahiert und kodiert werden können (Datensatz). Der Datensatz selbst enthält neben dem kodierten Testfall noch eine ID als Zusatzinformation. Diese ID gewährleistet beim späteren Datenbankimport die eindeutige Zuordnung der Ergebnisdaten zum entsprechenden Testfall.

Bedienoberfläche

Die Bedienoberfläche wurde in LabVIEW aus dem Hause National Instruments programmiert und dient zum Start der Prüfung. Hierzu erfolgt ein Download der kodierten Testfälle in die Ablaufsteuerung. Des weiteren wird dem Anwender online eine Visualisierung der Umgebungsvariablen und des Prüffortschrittes geboten. Aufgetretene Fehler der Prüflingsreaktion werden gleichfalls online kodiert dargestellt.
Zusätzlich können in dieser Applikation gewisse Eingriffe bezüglich Beginn und Ende der Testliste vorgenommen werden.

Mess- und Steuerbox

Als Mess- und Steuerbox wird ein PXI-System von NI eingesetzt, welches diverse Steuerkarten zur Stimulation der Prüflingseingänge, Messkarten zur Erfassung der Prüflingsausgänge sowie einen Prozessor zur Steuerung beinhaltet. Die Stimulation und Erfassung wird über Multi bzw. Digital IO-Karten realisiert, die diverse A/D-Kanäle, D/A-Kanäle, sowie digitale I/O-Kanäle (erzeugen und erfassen) enthalten.
Für die Kommunikationsrealisierung bzw. Kommunikationsüberwachung des Prüflings ist ein CAN Interface Board im System integriert. Die eigentliche Ablaufsteuerung, die zuvor durch das Einlesen der kodierten Testfälle bekannt gegeben wurde, wird durch den Prozessor realisiert. Hier erfolgt auch die Auswertung der Testfälle zur Laufzeit.
Die Ein- und Ausgänge der Mess- bzw. Steuerkarten sowie das Kommunikationsmodul sind mit dem Prüfling adaptiert.

Datenbank-Interface

Das Datenbank-Interface ist Bestandteil der Applikation EDAG-Tabellenverwaltung und bietet dem Anwender eine erste Möglichkeit zur Datenauswertung. Hierzu können alle Ergebnisdaten komfortabel visualisiert werden und die zu jedem Testfall automatisch erzeugten Result-Files geöffnet werden. Als nächster Schritt kann der automatische Datenbankimport erfolgen, wobei dem Anwender mehrere Importmöglichkeiten zur Verfügung stehen.

Prüfling

Das EDAG-Testsystem ist so konzeptioniert, dass Funktionalitäten verschiedenster elektronischer Steuergeräte oder Systeme der automatisierten Prüfung unterzogen werden können. Je nach Prüfling ist eine Peripherie notwendig, die z.B. die anzusteuernden Ersatzlasten, Originallasten oder andere für die Prüflingsfunktion benötigte Komponenten enthält.
Um Belange wie MMI (z.B. Schalter-/Tasteraktivierung über Roboter), Display- bzw. Bildauswertungen oder hardwarenahe Prüfungen (z. B. EMV-Prüfimpulse, Spannungsprüfungen, usw.) zu berücksichtigen, hat die EDAG Engineering und Design AG Lösungen anzubieten, die direkt in das System eingebunden werden können.

Zusammenfassung

Mit dem dargestellten Prozess und System stellt die EDAG Engineering und Design AG eine universelle Lösung für die durchgängige und reproduzierbare Funktionsvalidierung zur Verfügung. Die Dokumentierung der Ist-Reaktionen inklusive aller Einstellwerte und Ausgabewerte sowie die Ergebnisauswertung erfolgt vollautomatisch in eine Datenbank. Der Prozess kann auch problemlos von EDAG auf bereits vorhandene Testsysteme erweitert und angewendet werden.

EDAG führt mit diesem durchgängigen Prozess bereits sehr erfolgreich mehrere Serienprojekte aus den Bereichen von SW-Prüfungen elektronischer Komponenten und Funktionsprüfungen elektrischer / elektronischer Systeme für Systemlieferanten und OEMs durch.

Author Information:
For more information on this Case Study, contact:
Torsten Bien
EDAG Engineering + Design AG
Fulda

Browse All Case Studies »