Razorcat Development GmbH CCDL – Einfache und mächtige Testbeschreibungssprache für Zulassungstests und Zertifizierung Michael Wittner Razorcat Development GmbH Witzlebenplatz 4 14057 Berlin Tel.: 030 – 536 357 0 Fax: 030 – 536 357 60 support@razorcat.com www.razorcat.com

Wie kann nachvollziehbar dokumentiert werden, dass alle Anforderungen durch Tests abgedeckt sind? V&V Matrix r a a r a Anforderung 1 a ? Anforderung 2 a Test 4 Ergebnis 4 Anforderung 3 Test 3 Ergebnis 3 Test 2 Ergebnis 2 Test 1 Ergebnis 1

Herausforderungen für einen Test-Ingenieur Testmethodik Systemverständnis Testanlage Test Definition Step 1 … Step 2 Step 3 Test Procedure while () … if (x < y) for () SUT

Problematisch: Testbeschreibung und Umsetzung in eine Testprozedur V&V Matrix r Test Definition Initial Conditions … Step 1 Step 2 Step 3 a Test Procedure while () … if (x < y) for () a r a Anforderung 1 a ? Anforderung 2 a Test 4 Ergebnis 4 Anforderung 3 Test 3 Ergebnis 3 Test 2 Ergebnis 2 Test 1 Ergebnis 1

Bisheriges Vorgehen: Aufteilung auf verschiedene Testrollen Nachteile Programmierer braucht Systemverständnis und muss die Testanlage genau kennen Missverständnisse bei der Umsetzung in ein Testprogramm Schlechte Dokumentation Testanlagen- spezifisches Script/Programm (Python, C, ...) Dokumentation ? Test Definition Tester Programmierer manuelle Umsetzung

Zielstellung für eine Testbeschreibungssprache Leicht erlernbar Intuitiv lesbar Echtzeitfähig Direkte Verweise auf einzelne Anforderungen möglich Kapselung von testanlagen- und SUT-spezifischen Funktionen Umgang mit Redundanz (Signale/Subsysteme) Check Case Definition Language (CCDL) Chronologische und ereignisbasierte Stimulation Synchrone und asynchrone Prüfung der Systemreaktionen

Was bieten heutige Testsysteme ? C-Code, Python Wenig für Testerstellung geeignet Gute Programmierkenntnisse notwendig Keine Testauswertung Keine Dokumentation TTCN-3 Ebenfalls Programmierung erforderlich Eher für message-basierte Systeme geeignet Grafische Testbeschreibungen Wichtige Informationen zum Teil versteckt Dokumentation aufwendig/schwierig

Testbeschreibung und Testdurchführung mit CCDL automatische Übersetzung Ausführung auf der Testanlage Test Definition (CCDL) Test Prozedur (testanlagen- spezifisch) CCDL Compiler Tester Testanlagen- und A/C spezifische Funktionen Programmierer

Einsatz der CCDL in Airbus-Zertifizierungs-Testprogrammen Test der Landeklappensteuerung (High-Lift-System) in Bremen A400M A320 SFCC Re-Design A350 (aktuell laufende Testkampagne) Performance-Steigerung im Testprozess mit CCDL gegenüber Programmierung der Testprozeduren in Python über 100%

Einfaches Beispielsystem Motor Sensor Break Controller (SUT) Lever Fault Indicator

Typisches Testszenario einer Landeklappensteuerung Aktionen (chronologisch) Asynchrones Überwachen der Systemreaktionen Zeit [s] Definierter Zeitraum Laufzeit eines Testschritts Wählhebel setzen Bremse offen Normale Geschwindigkeit System bewegt sich Bei Erreichen einer Bedingung: Fehlersituation erzeugen Bremse schließt halbe Geschwindigkeit Warte, bis Endposition erreicht ist

Erstellen der Test Definition auf Basis der Anforderungen RQMT:0815-1 The motor shall operate the system at a speed of 1000 rpm RQMT:4711-1 If any overspeed (more than 1100 rpm) is detected, the system shall stop the motor and activate the break within 100 ms. A fault warning shall be indicated. Initialisierung des Systems Setze den Wählhebel auf Position 1 Warte, bis die Normalgeschwindigkeit ereicht ist. Simuliere einen Sensorfehler: Setze einen künstlichen Offset auf den gemessenen Wert. Prüfe, ob das System nach 100 ms gestoppt wird.

Umsetzung der Test Definition in CCDL Test Step 1, Timeout 99 [s]: { // Action: Set lever position to 2 set CTRL.LeverPosition to 2 // Check for motor speed of system // - Set a trigger variable if the event occured set trigger T1 when CTRL.MotorSpeed >= 1000 [rpm] (RQMT:0815-1) // When system is in state "ready for this test": // Set failure condition: Manipulate sensor when T1: // Manipulate sensor value set CTRL.MotorSpeed to offset 110 [rpm] (RQMT:4711-1) // Check if system detects the failure condition within T1 .. T1 & 100 [ms]: { expect CTRL.BreakState => ENGAGED (RQMT:4711-1) expect CTRL.FailureWarning => 1 (RQMT:4711-1) } Test Step 1, Timeout 99 [s]: { // Action: Set lever position to 2 set CTRL.LeverPosition to 2 // Check for motor speed of system // - Set a trigger variable if the event occured set trigger T1 when CTRL.MotorSpeed >= 1000 [rpm] (RQMT:0815-1) // When system is in state "ready for this test": // Set failure condition: Manipulate sensor when T1: // Manipulate sensor value set CTRL.MotorSpeed to offset 110 [rpm] (RQMT:4711-1) // Check if system detects the failure condition within T1 .. T1 & 100 [ms]: { expect CTRL.BreakState => ENGAGED (RQMT:4711-1) expect CTRL.FailureWarning => 1 (RQMT:4711-1) }

Umgang mit redundanten Signalen/Subsystemen set HLSF[1;2].RL206_GADIRU[1;2;3]_CAS to 200 [kts] Das ist die zusammengefasste Schreibweise für: set HLSF1.RL206_GADIRU1_CAS to 200 [kts] set HLSF1.RL206_GADIRU2_CAS to 200 [kts] set HLSF1.RL206_GADIRU3_CAS to 200 [kts] set HLSF2.RL206_GADIRU1_CAS to 200 [kts] set HLSF2.RL206_GADIRU2_CAS to 200 [kts] set HLSF2.RL206_GADIRU3_CAS to 200 [kts]

Testauswertung in CCDL Zeitlich genau definierbare Auswertungsintervalle Eine Real-Time-Zeitscheibe als kleinste Einheit Asynchrone Trigger-Bedingungen Für Stimulation Für Auswertung Zuordnung der Testergebnisse zu den annotierten Anforderungen Übernahme ins Testmanagement-System Anforderungsbasierte Auswertung der Tests

Grafische Visualisierung des Testablaufs

Architektur der CCDL Implementierung Compiler Übersetzung CCDL ==> C Execution Framework Real-Time Laufzeitumgebung Stimulation/Auswertung User Functions Library Implementierung testanlagen- oder SUT-spezifischer Funktionen Test Engine Abstraction Layer Interface zur Testanlage Beliebig portierbar CCDL Procedure Configuration Files Compiler Generated Test Program (C Code) independent of test engine Execution Framework User Functions Library TE abstraction layer dependent of test engine Test Engine (TE) (e.g. ADS2, Concurrent, dSPACE, ...)

Vergleich TTCN-3 und CCDL Vorteile der CCDL Kompakte, gut lesbare Notation Implizite Behandlung von Timeouts Implizites Setzen von Passed/Failed-Ergebnissen

Zusammenfassung CCDL Leicht erlernbar, intuitiv lesbar Echtzeitfähig Direkter Verweis auf Anforderungen Eingebettet in einen kompletten Testprozess  Umfassende Automatisierung im Testprozess und in der Nachweisführung

Vielen Dank für Ihre Aufmerksamkeit.