Figure 4.6: AP development workflow

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hybrides Methoden-, Artefakt- und Deployment-Workflow-Diagramm der AUTOSAR Adaptive Platform (AP). Es kombiniert einen Modellierungs- und Build-Prozess (offboard) mit dem Zielsystem-Laufzeitmodell (onboard / machine A).
• Technischer Zweck & Einordnung: Spezifikation des durchgängigen AP-Entwicklungszyklus gemäß AUTOSAR-Methodologie:
  • Entwurfszeit: Technologieunabhängige Definition von Service-Schnittstellen, maschinenspezifische Allokation, Implementierung und Paketierung.
  • Laufzeit: Auslieferung über das Update & Configuration Management (UCM), Persistierung von Manifestdaten und deterministische Prozessinstanziierung sowie Überwachung durch das Execution Management (EM).

2. Komponenten, Entitäten & Schnittstellen

Offboard-Entwicklungsdomäne (Design- & Build-Artefakte)

• Aktivitäten (Engineering Steps):
  • Define Services: Erstellung serviceorientierter Verträge (SOA).
  • Develop Software: Quellcode-Implementierung der Applikationslogik gegen AUTOSAR-APIs.
  • Develop Platform and Configure Machine: Hardware-, OS- und Netzwerktopologie-Konfiguration.
  • Integrate Software: Cross-Kompilierung/Linken sowie Bündelung von Binaries und Laufzeitparametern.
  • Define and Configure Service Instances: Bindung von Services an Protokolle und konkrete Endpunkte.
• Modell- & Dateiartefakte (ARXML / Binär):
  • Service Interface Description: Formales ARXML-Modell (ServiceInterface) mit Methoden, Events und Fields.
  • Adaptive Application: Quellcode-Artefakt (C++), basierend auf generierten Proxies/Skeletons.
  • Machine Manifest: ARXML-Deskriptor der Ausführungsumgebung (Hardware, Network Endpoints, OS-Resourcen, Crypto-Stacks).
  • SW Package: Standardisierter Deployment-Container (UCM-Package), aggregiert:
    • executable: Kompiliertes und gelinktes ELF-Binary.
    • Execution Manifest: ARXML-Spezifikation für Prozessinstanziierung, Startup-Configs, Scheduling-Policies, Resource Groups und POSIX-Berechtigungen.
    • Service Instance Manifest: ARXML-Spezifikation für Protokollbindings (z. B. SOME/IP, IPC), Instanz-IDs und Port-Mappings.

Onboard-Domäne (machine A / Target Runtime)

• Funktionscluster & Core-Entitäten:
  • SW Configuration Management (UCM): Plattform-Cluster für Empfang, Signatur-/Integritätsprüfung, Entpacken und Installation von Softwarepaketen.
  • installed executable 1: Im Ziel-Dateisystem abgelegtes ELF-Binary.
  • processed manifests / data base: Vom UCM geparste und validierte Manifest-Datenbank.
  • Execution Management (EM): Zentraler Bootstrapping- und Lifecycle-Manager (ara::exec); konfiguriert das OS und überwacht Prozesse.
  • OS: POSIX-konformes Betriebssystem (Subset PSE51 oder höher mit Speicherschutz/MMU).
  • process 1-1 (loaded executable instance): Isolierte OS-Prozessinstanz des Executables im eigenen virtuellen Adressraum.
  • other functional clusters: Laufzeitmodule (ara::com, ara::per, ara::diag, ara::crypto, ara::phm), gekapselt hinter standardisierten C++-APIs.

Schnittstellen & Beziehungen

• ARXML-Datenfluss: Service Interface Description und Machine Manifest steuern die Code-Generierung und Deployment-Manifeste.
• Paket-Schnittstelle: Offboard SW Package → Onboard SW Configuration Management.
• Runtime-APIs:
  • Execution Management API (ara::exec): Zustandsrückmeldung (State Reporting) zwischen process 1-1 und EM.
  • OS API: Standardisierte POSIX-Systemaufrufe (Threads, Filesystem, Signale).
  • Cluster APIs: C++14/C++17 Klassenbibliotheken für IPC/SOME/IP (ara::com), Persistenz (ara::per) etc.

3. Dynamisches Verhalten & Sequenzablauf

1. Schnittstellen- & Systemdesign (Offboard):
   • Definition des Service Interface entkoppelt von der Transportebene.
   • Festlegung der Maschinenparameter im Machine Manifest.
2. Generierung & Implementierung (Offboard):
   • Toolgestützte Generierung typisierter C++-Klassen (Proxies/Skeletons) aus dem Service Interface.
   • Implementierung der Adaptive Application.
3. Integration & Paketierung (Offboard):
   • Übersetzung/Linken der Applikation zum ELF-executable.
   • Auflösung von Deployments: Erstellung des Execution Manifest (Prozessparameter) und Service Instance Manifest (Zuweisung zu Netzwerkschnittstellen des Machine Manifest).
   • Generierung des signierten SW Package.
4. Deployment & persistente Konfiguration (Onboard):
   • Transfer des Pakets an SW Configuration Management.
   • UCM authentifiziert das Paket, legt das installed executable 1 im Filesystem ab und überführt Manifestdaten strukturiert in die interne data base.
5. Prozessinstanziierung & Lifecycle (Onboard):
   • EM liest Startup-Parameter und Abhängigkeiten synchron aus der data base.
   • EM parametriert OS-Ressourcengruppen (z. B. POSIX-Scheduling, CPU-Affinitäten, Limits).
   • EM initiiert den Prozessstart (fork/exec) → process 1-1 entsteht.
   • Synchroner/asynchroner Handshake: process 1-1 meldet über ara::exec::ApplicationClient seinen Status (kRunning) an das EM.
   • Prozess tritt über ara::com in die Service-Kommunikation ein.

4. Normative Relevanz & Entwickler-Hinweise

• Strikte Entkopplung von Code und Deployment-Parametern: Der C++-Applikationscode enthält keinerlei IP-Adressen, Socket-Ports, SOME/IP-IDs oder Scheduling-Prioritäten. Jede Anpassung erfolgt ausschließlich über Service Instance Manifest bzw. Execution Manifest.
• 1:n-Instanziierung (Executable zu Process): Ein einzelnes kompiliertes executable kann im Execution Manifest mehrfach instanziiert werden (z. B. process 1-1, process 1-2). Jede Instanz erhält individuelle Startup-Argumente, Resource Groups und POSIX-Privilegien.
• Lifecycle-Vertrag (API-Pflichten):
  • Jeder Prozess muss ara::core::Initialize() zu Beginn und ara::core::Deinitialize() bei Terminierung aufrufen.
  • Nach der Initialisierung muss der Prozess seinen Zustand zwingend via ReportApplicationState(ApplicationState::kRunning) an das EM melden. Ein Unterlassen führt zum Timeout und terminiert den Prozess durch das EM.
• Konsistenzgarantie via UCM: Binaries dürfen auf POSIX-Ebene niemals manuell deployed oder kopiert werden. Ohne korrespondierende Einträge in den processed manifests der Manifest-Datenbank kann das EM den Prozess weder schedulen, absichern noch überwachen.