DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_TR_SystemTests FIG-f5132034385910b9 932 × 854 px 5 Release(s)

Figure 11.3: Sequence diagram of STS_E2E_00001.

SHA-256 Inhalts-Fingerabdruck: f5132034385910b9bf40d40273604ab299a045895f0df95e58955ded392afd1e

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-description@2 · erstellt am 2026-10-07

1. Diagrammtyp & Architektur-Kontext

  • Diagrammtyp: UML-Sequenzdiagramm (sd STS_E2E_00001) mit Interaktionsrahmen (loop) und Swimlanes/Subsystem-Gruppierungen.
  • Kontext: AUTOSAR Adaptive Platform System Tests (AUTOSAR_AP_TR_SystemTests).
  • Funktionale Einordnung: Verifikation der End-to-End-Absicherung (ara::com E2E-Protection / SOME/IP-Binding) über Netzwerkgrenzen hinweg zwischen zwei Steuergeräten (ECU1, ECU2), gesteuert und validiert durch ein automatisches CI/CD-Testframework (Jenkins / E2E Tester). Es implementiert die Verifikationstestfälle zu RS_E2E_08529, RS_E2E_08534 und RS_E2E_08545 bis RS_E2E_08548.

2. Komponenten, Entitäten & Schnittstellen

  • Knoten & Instanzen (Execution Environments & Lifelines):
    • ECU1 / E2E-APP1: Sender-Applikation auf Adaptive Platform ECU 1 (Service Provider / Event Producer).
    • ECU2 / E2E-APP2: Empfänger-Applikation auf Adaptive Platform ECU 2 (Service Consumer / Event Subscriber).
    • Jenkins / E2E Tester: Testautomatisierungs-Orchestrierer (Test Execution Harness) zur Erfassung von Soll-/Ist-Daten und E2E-Zuständen.
  • Schnittstellen & Interaktionen:
    • Offer Service / Request Service: Service-Discovery-Phase über SOME/IP-SD bzw. ara::com-Service-Discovery (OfferService(), FindService() / Subscription).
    • Send E2E protected Data: Inter-ECU-Datenübertragung (E2E-geschützte Event-/Field-Serialisierung mit Header, CRC, Sequence Counter, Data ID).
    • GetProfileCheckStatus(): Interne API-Methode der ara::com-E2E-Integrationsschicht zur Abfrage des Profil-Prüfstatus (ProfileCheckStatus bzw. ara::com::e2e::CheckStatus).
    • Teststeuerschnittstellen (RPC / Test-API): Get Recived Data And Check Status (ECU2 → Tester) sowie Get Send Data (ECU1 → Tester).

3. Dynamisches Verhalten & Sequenzablauf

  1. Service-Initialisierung & Discovery:
    • E2E-APP1 publiziert den Service via Offer Service.
    • E2E-APP2 fordert den Service an bzw. abonniert Events via Request Service.
  2. Zyklische Testschleife (loop for 10 times (certain cycle time)):
    • Payload-Übertragung: E2E-APP1 sendet serialisierte, E2E-geschützte Daten an E2E-APP2.
    • E2E-Validierung auf Empfängerseite: E2E-APP2 ruft synchron GetProfileCheckStatus() auf, um den E2E-Header auszuwerten (Prüfung von Sequenzzähler, CRC, Data ID, State-Machine-Zustand Ok, Repeated, WrongSequence etc.).
    • Status- & Daten-Erfassung:
      • E2E Tester fragt von E2E-APP2 empfangene Nutzdaten und den CheckStatus ab (synchrone Antwort via Return-Pfad).
      • E2E Tester fragt von E2E-APP1 die tatsächlich abgesendeten Rohdaten (Get Send Data) ab.
    • Soll-Ist-Abgleich: E2E Tester führt intern Check Data aus (Validierung auf Byte-Identität der Payload und Korrektheit des E2E-Ergebnisses Ok).
    • Zyklussteuerung: E2E-APP1 wartet (Wait for more than cycle time (only one cycle)) bis zur Initiierung des nächsten Zyklus, um das konfigurierte Zykluszeitintervall einzuhalten.

4. Normative Relevanz & Entwickler-Hinweise

  • E2E-Konfiguration in Adaptive Core: Beide Kommunikationsendpunkte müssen deckungsgleiche E2E-Profile (EndToEndTransformationDescription, z. B. Profile 01, 04, 07 oder 22) und identische Data-IDs / Alive-Counter-Fenster in den Manifesten (ServiceInstanceToMachineMapping) konfiguriert haben.
  • API-Vertrag (ara::com):
    • Die empfangende Applikation (E2E-APP2) erhält E2E-Statusinformationen typischerweise über Samples/Pointer (SamplePtr) und die E2E-Status-Abfrage (GetProfileCheckStatus()), um fehlerhafte oder manipulierte Frames gemäß ASIL-Einstufung vor der Weiterverarbeitung zu verwerfen.
    • Das Systemtest-Design erzwingt eine Test-Backdoor bzw. diagnostische Schnittstelle auf Applikationsebene, um Sendedaten und E2E-Prüfstatus zur Laufzeit an eine CI/CD-Testbench (Jenkins) zu spiegeln.
  • Timing & Jitter: Das Timing (Wait for more than cycle time) verifiziert die Robustheit der E2E-Zustandsmaschine bezüglich Timeout- und Alive-Counter-Überwachung (RS_E2E_08534, RS_E2E_08546). Ein Überschreiten des Max-Delta-Counters führt normativ zum Übergang in SM_INVALID bzw. CheckStatus::kWrongSequence.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Erkannte Spezifikationsbelege & Anforderungen auf dieser Seite

RS_E2E_08529 Wortlaut noch nicht übernommen RS_E2E_08534 RS_E2E_08545 RS_E2E_08546 RS_E2E_08547 RS_E2E_08548 Wortlaut noch nicht übernommen

Vorkommen in AUTOSAR-Releases (6)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R21-11 AUTOSAR_TR_AdaptivePlatformSystemTests S. 147 11.3 Figure 11.3: Sequence diagram of STS_E2E_00001.
R21-11 AUTOSAR_TR_AdaptivePlatformSystemTests S. 147 11.3 Figure 11.3: Sequence diagram of STS_E2E_00001.
R22-11 AUTOSAR_TR_AdaptivePlatformSystemTests S. 147 11.3 Figure 11.3: Sequence diagram of STS_E2E_00001.
R23-11 AUTOSAR_AP_TR_SystemTests S. 144 11.3 Figure 11.3: Sequence diagram of STS_E2E_00001.
R24-11 AUTOSAR_AP_TR_SystemTests S. 144 11.3 Figure 11.3: Sequence diagram of STS_E2E_00001.
R25-11 AUTOSAR_AP_TR_SystemTests S. 132 11.3 Figure 11.3: Sequence diagram of STS_E2E_00001.