1 / 20

Razorcat Development GmbH Witzlebenplatz 4 14057 Berlin Tel.: 030 – 536 357 0

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.

morty
Download Presentation

Razorcat Development GmbH Witzlebenplatz 4 14057 Berlin Tel.: 030 – 536 357 0

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. 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

  4. Problematisch: Testbeschreibung und Umsetzung in eine Testprozedur V&V Matrix r a Test Definition Initial Conditions … Step 1 … Step 2 … Step 3 … 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

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

  6. 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

  7. 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 Was bieten heutige Testsysteme ?

  8. 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

  9. 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%

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

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

  12. Erstellen der Test Definition auf Basis der Anforderungen Anforderungen Test Definition 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.

  13. Umsetzung der Test Definition in CCDL TestStep 1, Timeout 99 [s]: { // Action: Set lever position to 2 setCTRL.LeverPositionto 2 // Check for motor speed of system // - Set a trigger variable if the event occured settrigger T1 whenCTRL.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 setCTRL.MotorSpeedtooffset 110 [rpm] (RQMT:4711-1) // Check if system detects the failure condition within T1 .. T1 & 100 [ms]: { expectCTRL.BreakState => ENGAGED (RQMT:4711-1) expectCTRL.FailureWarning => 1 (RQMT:4711-1) } } TestStep 1, Timeout 99 [s]: { // Action: Set lever position to 2 setCTRL.LeverPositionto 2 // Check for motor speed of system // - Set a trigger variable if the event occured settrigger T1 whenCTRL.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 setCTRL.MotorSpeedtooffset 110 [rpm] (RQMT:4711-1) // Check if system detects the failure condition within T1 .. T1 & 100 [ms]: { expectCTRL.BreakState => ENGAGED (RQMT:4711-1) expectCTRL.FailureWarning => 1 (RQMT:4711-1) } }

  14. Umgang mit redundanten Signalen/Subsystemen setHLSF[1;2].RL206_GADIRU[1;2;3]_CASto 200 [kts] Das ist die zusammengefasste Schreibweise für: setHLSF1.RL206_GADIRU1_CASto 200 [kts] setHLSF1.RL206_GADIRU2_CASto 200 [kts] setHLSF1.RL206_GADIRU3_CASto 200 [kts] setHLSF2.RL206_GADIRU1_CASto 200 [kts] setHLSF2.RL206_GADIRU2_CASto 200 [kts] setHLSF2.RL206_GADIRU3_CASto 200 [kts]

  15. 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 Testauswertung in CCDL

  16. Grafische Visualisierung des Testablaufs

  17. 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 dependent of test engine TE abstraction layer Test Engine (TE) (e.g. ADS2, Concurrent, dSPACE, ...)

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

  19. 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

  20. Vielen Dank für Ihre Aufmerksamkeit.

More Related