AP Autosar overview

AP overview

• Ap Autosar Architecture(yellow[Non-PF Service], blue[Platform Foundation FCs], red[PF Service FCs])

  block-beta
  columns 5
  a1("AdaptiveApp")  a2("AdaptiveApp")  a3("AdaptiveApp") a4("ASW::XYZ \nNon-PF Service") a5("ASW::ABC \nNon-PF Service")
  ar1("ara::com \nCommunication \nManagement") ar2("ara::rest \nrest") ar3("ara::tsync \nTime Synchronization") ar4("ara::diag \nDiagnostics") ar5("ara::sm service \State \nManagement")
  block:ARA0:1
  columns 2
  ar6("IPC") ar7("SingalPDU") ar8("SOME/IP") ar9("DDS")
  end
  ar10("ara::per \nPersistency") ar11("ara::phm \nPlatform Health \nManagement") ar12("ara::log \nLog and Trace") ar13("ara::ucm service \nUpdate and Config \nManagement")
  ar14("ara::core \nCore") ar15("ara::exec \nExecution Management") ar16("ara::lam \nIdentity and Access Management")  ar17("ara::crypto \nCryptography") ar18("ara::nm service \nNetwork \nManagement")
  ar19("POSIX PSE51/C++ STL \nOperating System Interface"):4 space
  m("(Virtual) Machine/Container/Hardware"):5
  classDef APP_STYTE fill:#FFEC9E;
  classDef ARA_STYTE fill:#FFCBCB;
  classDef MACHINE_STYTE fill:#DFD0B8
  class a1,a2,a3,a4,a5 APP_STYTE
  class ar5,ar13,ar18 ARA_STYTE
  class m MACHINE_STYTE
  

• AA: Adaptive Applicaton
• ARA: Autosar Runtime for Adaptive Applications(consists of interfaces provided by FCs)
• FC*:Functional Clusters(Interfaces: APIs + Services)
  • AP Foundation FCs(API):(Directly call)
  • AP Service FCs(Service):(call via ara::com)
• Operating Syctem Interface
  • Standard OS interface(POSIX PSE51/C++ STL)
• Execution Management
  • Lifecycle management of platform(machine) and application(process) incl. privileges of access control and machine states
• State Management
  • Mainly responsible for the state switching of the entire machine state and its functional groups
  • Notify the EM to perform related state switching
• Platform Health Management
  • Alive supervision for application
• Communication Management
  • SOME/IP based including serialization and service discovery
  • publish/subscribe mechanism for intra- and inter-ECU communication
  • Conversion from data signal to service
• Log And Trace
  • Use AUTOSAR standards DLT, function like Glog, responsible for recording log of AP Autosar
• Core Types
  • Consisting of only data type and helper function
• Persistency
  • Provide storage services, including Key-value and stream storage
• Diagnostic
  • Event management and diagnostic service handing
• Update and Configure Management
  • Responsible for updating, installing, deleting and saving software records on the adaptive platform
• Cryptography
  • Provides APIS for common encryption operations and security key management
• Identity and Access Management
  • Introduce separations of privileges for adaptive applications and prevents privilege escalation during attacks
• Time Synchronization
  • For time synchronization between two systems, the accuracy can reach sub-microsecond level
• Network Management
  • Network state switching

Startup Sequence

• Machine staryup sequence
  • OS->EM->FC->AA
  • EM determines the startup order based on the machine manifest and the execution manifest

Application

• an AA/FC is a process in OS(single or multiple instances)
  • multiple threads
  • in different states(SM, EM, UCM)
  • communication
    • AA with POSIX OS: PES51
    • AA with AA or AP services: ara::COM
    • AA with AP Foundation: direct interface
• Manifest(arxml)
  • mainly comtains platform-related information such as recovery operations and service- and libary-related dependencies
  • will be read when deploying and updating application
• Configuration file
  • mainly contains static infomation such as version information

SOME/IP

• Service interface:(Proxy/skeleton)
  • Method: request & response method, fire & forget method
  • Event
  • Field: Notifier, Getter and Setter

Methodology

• Standardization of Arxml: describe services, applications, machines and their configuration
• Interaction of Arxml: how to exchange design information

Workflow

1. Develop platform and configure machine -> generate machine manifest(platform, machine information such as processor model, munbers of core, machine ip address, port, and so on)
2. Define services -> generate application design -> generate proxy and skeleton files(datatypes, service interfaces, components)
3. Develop software(implement skeleton by server -> call via proxy by client) -> generate executable
4. integrate software(configure path to executable file, numbers of instances, startup paramenters, environment variables, scheduling strategy, UID/GID) -> generate execution manifest
5. Define and configure service instances (service interface + service ID, method ID, event ID) -> generate service instance manifest
6. SW Package(executable, execution manifest, service instance manifest) -> machine A(deployment, authentication, installation + FCs & AAs startup, configure and shutdown)

Manifest

• describe Autosar model
• support configuration of AP product
• upload to AP product(combined with corresponding executable)

1. Application design: describes design-related models
   • datatypes
   • service interfaces
   • defines how to access other modules(COM, PER, PHM, Time Base…)
2. Machine manifest
   • service discovery configuration(ip address and port)
   • define machine states(on/off/start/restart/shut down)
   • define function group
   • functional clusters configuration
   • available hardware resourses(RAM, processor, numbers of core…)
3. Execution manifest: makes code indepentant of specific deployment scenarios
   • startup configuration
   • resource management(resource group)
4. Service instance manifest: SOC(SOME/IP) configuration
   • service interface deployment
   • service instance deployment(service ID, method ID and event ID)
   • E2E protection on configuration
   • cyber security protection on configuration
   • log and trace configuration