Figure 4.17: Modeling of the diagnostic validation mapping

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: AUTOSAR-Metamodell-Ausschnitt (UML-Klassendiagramm) der Adaptive Platform (AUTOSAR_TPS_ManifestSpecification).
• Technischer Zweck: Modellierung des Mappings zwischen der deklarativen Diagnosekonfiguration (Diagnostic Management / ara::diag) und den Softwarekomponenten einer konkreten Applikation.
• Funktionale Einordnung: Verknüpft die softwareunabhängige Definition der Service-Validierung (DiagnosticServiceValidationInterface) mit dem Prozesskontext (ProcessDesign) und dem konkreten Bereitstellungs-Port (PPortPrototype) innerhalb eines Executables. Dient dem Diagnostic Daemon als Konfigurationsgrundlage zur Laufzeitprüfung eingehender UDS-Service-Requests (Validierung von Session-, Sicherheits- oder Umgebungsbedingungen vor Serviceausführung).

2. Komponenten, Entitäten & Schnittstellen

Metaklassen der Schnittstellenseite (Links)

• PortInterface (Spezialisierung von ARElement, AtpBlueprint, AtpBlueprintable, AtpType): Abstrakte Basisklasse aller AUTOSAR-Port-Schnittstellen.
• DiagnosticPortInterface: Spezialisierte Schnittstellenklasse für Diagnosezwecke, abgeleitet von PortInterface.
• DiagnosticServiceValidationInterface: Konkrete Spezifikation der Validierungsschnittstelle (abgeleitet von DiagnosticPortInterface). Definiert die Methoden/Signaturen, über die eine Applikation die Zulässigkeit diagnostischer Anfragen bestätigt oder ablehnt.
• PPortPrototype (Spezialisierung von AbstractProvidedPortPrototype): Definiert den konkreten Bereitstellungs-Port (Provided Port) einer Software-Komponente.
  • Stereotyp «isOfType»: Typisiert den Port über die Assoziation +providedInterface [0..1] {redefines atpType} gegen PortInterface (hier konkretisiert als DiagnosticServiceValidationInterface).

Metaklassen der Mapping- & Prozessseite (Rechts)

• Process (Spezialisierung von AbstractExecutionContext): Repräsentiert die OS-Prozessinstanz zur Laufzeit. Referenziert über +design [0..1] das zugehörige ProcessDesign.
• ProcessDesign (ARElement): Deklarative Entwurfsdefinition des Prozesses vor dem finalen Deployment auf eine Machine.
• DiagnosticSwMapping (abgeleitet von DiagnosticMapping): Basisklasse für Mappings von Diagnoseartefakten auf Software-Elemente.
• DiagnosticServiceValidationMapping (abgeleitet von DiagnosticSwMapping): Zentrales Mapping-Element.
  • Assoziation +process [0..1] mit Stereotyp «atpSplitable»: Verweist auf das ProcessDesign. Ermöglicht ARXML-Split (Aufteilung über mehrere Manifest-Dateien/Autorengrenzen hinweg).
  • Zielgerichtete Abhängigkeit +pPortPrototypeInExecutable [0..1] mit Stereotypen «instanceRef,atpUriDef»: Definiert die URI-basierte Instanzreferenz auf den konkreten PPortPrototype im Kontext des Executables.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm selbst modelliert statische Manifest-Zusammenhänge; die daraus resultierende Laufzeitsequenz gestaltet sich wie folgt:

1. Request-Eingang: Der ara::diag-Daemon empfängt eine UDS-Service-Anfrage (z. B. RoutineControl $31, WriteDataByIdentifier $2E oder DiagnosticSessionControl $10).
2. Validierungs-Lookup: Der Daemon ermittelt anhand des DiagnosticServiceValidationMapping, welcher Prozess (Process) und welcher Port (PPortPrototype) für die Validierung des angeforderten Services zuständig ist.
3. IPC-Call: Der Daemon ruft synchron oder asynchron über die generierten Service-Schnittstellen (DiagnosticServiceValidationInterface) die Validierungsmethode der Applikation auf.
4. Entscheidung & Rückmeldung:
   • Positiv: Applikation bestätigt die Ausführbarkeit (NRC 0x00 / Success) → Service-Handler führt die eigentliche Diagnosefunktion aus.
   • Negativ: Applikation liefert einen Negative Response Code (NRC, z. B. $22 ConditionsNotCorrect oder $33 SecurityAccessDenied) → Daemon bricht die Kette ab und sendet die NRC-Antwort direkt an den Diagnosetester.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Generierung & ARXML-Splitting (RS_MANI_00005, RS_MANI_00061):
  • Durch «atpSplitable» an +process kann das Diagnose-Mapping in separaten Diagnose-Beschreibungsdateien gepflegt werden, unabhängig vom Prozess-Design-Manifest des Basis-Integrators.
  • «instanceRef,atpUriDef» erfordert eine lückenlose und konsistente Pfadangabe (URI) zur Auflösung des PPortPrototype über die Hierarchie RootSwComponentPrototype → SwComponentPrototype → PPortPrototype innerhalb des Ziel-Executable.
• Applikations-Entwicklung (ara::diag):
  • Entwickler müssen eine Klasse implementieren, die von der aus dem DiagnosticServiceValidationInterface generierten Basisklasse erbt.
  • Methoden müssen strikt echtzeit- und reentrant-fähig sein, da Verzögerungen bei der Validierung unmittelbar zu UDS-Timeout-Überschreitungen (P2/P2*-Timer) führen.
• Konfigurations-Restriktionen:
  • Kardinalität 0..1: Ist kein DiagnosticServiceValidationMapping für einen Dienst konfiguriert, führt der Daemon standardmäßig keine anwendungsspezifische Vorab-Validierung durch; die Validierungslogik verbleibt dann zwingend im regulären Service-Handler.