Automatisierung des Integrationstest

Transkript

1 Automatisierung des Integrationstest Automatisierung des Integrationstests durch Nutzung eines Common Engineering Data Backbone MAN [Unternehmen] [optional: Marke] Verfasser Aktuelles Thema < 1 > Agenda 01 Einleitung / Integrationstest bei MAN 02 MAN Entwicklungsprozess 03 Steuergeräte-Architektur Integrationstestprozess Umsetzung 06 Tests im Detail 07 Zusammenfassung < 2 > [Optionaler Eintrag]

2 Integrationstest bei MAN Ausgangssituation Hohe Test-Überdeckung mit Komponententest und Systemtest Hohe Test-Komplexität sowohl bei der Testfallentwicklung, als auch beim Umgang mit HIL Geringer Automatisierungsgrad Regressionstests von SW-Modulen sehr aufwändig (teilweise muss die komplette Testspezifikation nochmal durchgeführt werden) Keine einheitlichen Testspezifikationen Testfokus liegt auf dem funktionalen Test Ist der Testfokus im Integrationstest noch richtig? 3 < 3 > Integrationstest bei MAN Unterscheidung Standardtest / funktionaler Test Integrations- Test aler Test ales Zusammenspiel von en muss getestet werden Test erfolgt im MIL und SIL auf PC Test erfolgt für einen definierten Softwarestand Softwarearchitektur (Taskzeit, Aufrufreihenfolge, etc.) wird aus Datenbank übergeben Test erfolgt unter Annahmen, die über den Standardtest nachgewiesen werden Standardtest Integration der en auf der Komponente muss getestet werden (Timing, Signalverbindungen zur Middleware) Es sollen weitgehend automatisierte Standardtests durchgeführt werden: UDS-Protokoll Test Fehlerspeichertest PIN-Test (Kurzschluss nach Ubatt, Unterbrechung, etc.) Schnittstellentest (PIN Middleware) Gatewaytest DIAG_IDs schreiben/lesen/abspeichern < 4 > [Optionaler Eintrag]

3 Integrationstest bei MAN Testziele alität: Nachweis über die korrekte Einbindung der hardware-seitigen Schnittstellen. Nachweis über die korrekte Integration (Schnittstellen und Zusammenspiel) von Applikation, Middleware und Basissoftware auf der Zielhardware. Nachweis über die korrekte Applikation von en der Basissoftware. Robustheit: Nachweis, dass das Steuergerät auch außerhalb des spezifizierten Bereichs ein definiertes Verhalten aufzeigt. < 5 > MAN Entwicklungsprozess Entwicklung nach V-Modell Anforderungen Abnahmetest sspezifikation Systemtest Architekturdesign Integrationstest Information in ASAM MSR Struktur (XML-basiert) sdesign Codierung Komponententest Information in ASAM MSR Struktur (XML-basiert) Common Engineering Data Backbone < 6 > [Optionaler Eintrag]

4 MAN Entwicklungsprozess sarchitektur 1.1 ECU 1 Fahrzeugfunktion Aktuator 1 Sensor ECU x Fahrzeug-System x.1 Fahrzeugfunktion x x.3 x.4 Aktuator x Sensor x Komponentenebene sebene < 7 > MAN Entwicklungsprozess Common Engineering Data Backbone Project- / Process- / Workflow-Management FDM TDM MDM FRM CDM SDM VDM easee.edm Oracle data base FDM: TDM: MDM: CDM: FRM: SDM: VDM: easee: Function-Data-Management / Requirement-Management Test-Data-Management Model-Data-Management Calibration-Data-Management Change-Management Service-Data-Management Vehicle-Data-Management electronic Automotive System Engineering Environment < 8 > [Optionaler Eintrag]

5 MAN Entwicklungsprozess Test-Data-Management (TDM) Testspezifische Informationen: Testpläne Test-Spezifikationen Tests Test-Ergebnisse Test-Umgebung Test-Coverage Berechnung Test-Aufwand Berechnung Konfiguration der Testumgebung Reporting TPRJ: /Variant;Version T_CYCLE: /Variant;Version (0 n) TEST: /Variant;Version (0 n) PARAMSET: /Variant;Version (0 n) SW: /Variant;Version FKN: /Variant;Version REQ: /Variant;Version 9 < 9 > Architektur Steuergeräteaufbau Test-Bereiche im Integrationstest Hardware bis Middleware Middleware bis Applikation Weitere en der Basissoftware < 10 > [Optionaler Eintrag]

6 Integrationstestprozess Übersicht Common Engineering Data Backbone TDX Test-Report TestOverviewReport TDX-L Manuell erstellte Testfälle TestDataGenerator UDS-Protokoll Test Fehlerspeichertest PIN-Test Schnittstellentest Gatewaytest Fehlerspeicher ificationlayer TestExecutionLayer < 11 > Integrationstestprozess im Detail ification-layer TestConfiguration-Layer TestData-Layer TestExecution-Layer -Editor -Editor TestDatenGenerator Test-Execution ControlDesk 4.2 TestResult TDX-L TDX-L TDX-L TDX DBC NDF ODX A2L Lokales Dateisystem Import/Export Testspezifikation/ Testergebnisse Export Steuergerätebeschreibungsdateien Common Engineering Data Backbone < 12 > [Optionaler Eintrag]

7 Umsetzung Framework in AutomationDesk Globale Einstellungen (Logginglevel, CANalyzer-File) Einstellungen für den HIL-Zugriff (HILAPI-MA-Port, ) Einstellungen aus der aktuellen Konfiguration (DBC, ) Einstellungen für RemoteCalibrationCOM Einstellungen für Diagnose-Zugriff Vorlage für Testspezifikation Folder für T_Cycles T_Cycle Testspezifikation nach der Ausführung mit Verdikt Logische Testspezifikation Ausführbare Testspezifikationen < 13 > Umsetzung Testblöcke in ehilautomationlib >100 TestBlöcke (vom Anwender verwendbar) Template-TestBlock für MAN-eigene TestBlöcke Implementierung der TestBlöcke Basisfunktionalitäten für HIL/ECU-Zugriff < 14 > [Optionaler Eintrag]

8 Umsetzung Import/Export von Testspezifikationen MAN-konforme TDX-Datei AutomationDesk-konforme XML- Dateien MyTest.xml TDX-Import xport MyTest.fdx + My.tsx XML-I/O AUD TDX-Import u. xport: Konvertierung zwischen TDX-XML und AutomationDesk-XML Namenskonventionen bzgl. der TDX-Dateien: xyz_tsi_l.xml: Logische Test-Spezifikation (TDX-Category TSi ) xyz_tsi_e.xml: Ausführbare Test-Spezifikation (TDX-Category TSi ) xyz_tri.xml: Ausgeführte Test-Spezifikation (TDX-Category TRi ) < 15 > Umsetzung Testdatengenerierung TDX-L TestDatenGenerator Logische Testspezifikation A2L DBC NDF ODX Common Engineering Data BackBone Testdatengenerierung () am Beispiel CAN-Test Für jede Botschaft wird eine erzeugt Für jedes Signal einer Botschaft wird ein TestCase erzeugt Ein TestCase besteht aus n TestSteps Testbasis ist die SAE J Ausführbare Testspezifikation(en) _CANmsg1 () TestCase_Sig1 Step 1 Step n TestCase_Sig2 Step 1 Step n < 16 > [Optionaler Eintrag]

9 Standardtests im Detail CAN-Schnittstellen-Test CAN-Standardtest Dieser Test überprüft das Sende-/Empfangsverhalten der ECU vom physikalischen CAN bis zur Middleware nach SAE J , sowie den MAN-spezifischen Anforderungen. ECU Virtuelle n Virtuelle 2 Virtuelle 1 CAN-In Reale Fkn 1 - Senden einer Nachricht bzw. eines Signals vom HIL - Zurücklesen von Wert u. Status über XCP CAN-Out - Setzen von Wert u. Status eines Signals über XCP - Zurücklesen der resultierenden CAN-Botschaft über den HIL CAN-Gateway - Senden einer Gateway-Botschaft über den HIL Diagnose Manager - Zurücklesen der weitergeleiteten CAN-Botschaft über den HIL CAN-OnRequest - Senden einer Anforderungs-Botschaft über den HIL - Zurücklesen der angeforderten CAN-Botschaft über den HIL Automatische Modellgenerierung - Das Template-Modell enthält einen RTI-CANMM-Block DIDs - Wenn ein neuer ECU-SW-Stand mit neuen DBC-Files kommt, wird das Modell neu gebaut Applikationen Middleware Basissoftware CAN IN DIG IN IN Reale Fkn 2 Nutzdaten- u. Status-Variablen -HIL CAN OUT DIG OUT OUT < 17 > Standardtests im Detail PIN-Test Pin-Standardtests Dieser Test überprüft die Hardwareschnittstellen des Steuergerätes vom physikalischen PIN bis zur Middleware. Pin-In - Setzen eines gültigen elektrischen Wertes über den HIL - Zurücklesen von Wert und Status über XCP HIL-Out XCP Pin-Out - Setzen von Wert und Status über XCP - Zurückmessen am Pin über den HIL HIL-In XCP Failure-Tests - Fehler mit der FIU aufschalten (z.b. Kurzschluss nach UBat) - Überprüfen der Statusvariable auf richtigen Fehlerzustand FIU-Relais Short to Ubat XCP < 18 > [Optionaler Eintrag]

10 Standardtests im Detail Diagnose-Protokoll-Test UDS- (Diagnose-) Standardtest Diagnose-Protokoll-Tests - Kommunikation zwischen Tester und ECU UDS = Unified Diagnostic Services, ISO Überprüfen der Response verschiedener Diagnose-Services - Tester ist in diesem Fall AutomationDesk über ControlDeskNG.Dsystem DID-Tests - Lesen und Schreiben von DIDs - DIDs werden aus der ODX gelesen - Für jeden DID wird ein TestStep generiert AutomationDesk Testblock ControlDesk 4.x DSystem Security und Flashen - Ausführen von entsprechenden Diagnose-Jobs ODX In2Soft MCD-3D-Server Protokolle - UDS on CAN, KWP on CAN u. KWP on KLine < 19 > Standardtests im Detail ale Diagnosetests ale Diagnosetests Testen der DiagnoseManager-alität. Die einzelnen Diagnose-Codes SPNs stehen in einer MAN-proprietären XML-Datei Richtigen Fehlereintrag inkl. Umweltbedingungen Fehler-Entprellung Vermeidung togglender Fehlereinträge Setzen der Fehler per XCP Selbstheilung Fehlerlöschung nach n Fahrzyklen Prioritätstests Verdrängung niederpriorer Fehler durch höherpriore Folgefehlertests Löschen von Folgefehlern bei ursächlichen Fehlern Fehlerhäufigkeit Überprüfung des Häufigkeitszählers Unterspannungstest Bei Unterspannung keine weiteren Fehlereinträge Kl.15 Applikationen Middleware Basissoftware HIL Kl.30 Fkn1 ECU Fkn2 - Diagnose Manager Reale Fkn3 en Fkn Status- Variablen Fehler speicher Lesen des Fehlerspeicher per UDS < 20 > [Optionaler Eintrag]

11 Zusammenfassung Erfolgsfaktoren für einen effizienten Integrationstest Einheitliche Steuergerätearchitektur unter Berücksichtigung der Anforderungen aus Integrationstest Zentrale Organisationseinheit für ECU-Architektur FDM TDM Zentrale Entwicklungsdatenbank Testautomatisierung mit Anbindung zur Entwicklungsdatenbank Effiziente Durchführung des Integrationstests < 21 > Haben Sie noch Fragen? Stefan Riegl Engineering Electric / Electronic Systems Function Test(EEFT) Stefan.Riegl@man.eu MAN [Unternehmen] [optional: Marke] Verfasser Aktuelles Thema < 22 > [Optionaler Eintrag]