Safety and Security in AUTOSAR Adaptive

About 1774 wordsAbout 6 min

2026-03-25

Functional Safety in AUTOSAR Adaptive

ASIL Coverage of the Adaptive Platform

AUTOSAR Adaptive Platform Release 21-11 onward targets ASIL B qualification for the platform itself (specific Functional Clusters). Applications running on the platform can also be developed to ASIL B up to ASIL D, with certain architectural conditions.

ASIL Ceiling Matrix (Adaptive Platform Components):

  Component                     Maximum ASIL    Notes
  ────────────────────────────────────────────────────────────────────────
  ARA APIs (ara::com, etc.)     ASIL B          Platform has ASIL B safety manual
  Execution Management          ASIL B          EM is safety-relevant (process control)
  Platform Health Management    ASIL B          PHM is safety-relevant (monitoring)
  Communication Management      ASIL B          ara::com with E2E → ASIL B
  State Management              ASIL B          SM controls safety-relevant states
  ara::crypto                   ASIL B          Depends on HSM ASIL level
  ara::log                      QM             Logging is not safety-relevant
  ara::per                      QM → ASIL B     Depends on storage use case
  OS (Linux PREEMPT_RT)         QM             Linux itself is not ASIL certified
  OS (QNX 7.x)                  ASIL D capable  QNX has TÜV ASIL D certificate
  
  Key insight: To develop ASIL C/D Adaptive Applications, the underlying OS
  must be ASIL certified (QNX or equivalent), or the SoC hypervisor must 
  provide freedom-from-interference guarantees.

Freedom from Interference

ISO 26262 Part 6 requires that ASIL components are free from interference from lower-ASIL or QM components. In Adaptive, this requires:

Mixed-Criticality Architecture on a Single SoC:

  ┌──────────────────────────────────────────────────────────┐
  │                        SoC                               │
  │                                                          │
  │  ┌─────────────────────────────────────────────────────┐ │
  │  │             Hypervisor (ASIL D certified)            │ │
  │  └──────────────┬───────────────────────┬──────────────┘ │
  │                 │                       │                 │
  │  ┌──────────────┴────────┐ ┌────────────┴──────────────┐ │
  │  │  Safety Partition     │ │   QM Partition             │ │
  │  │  ASIL B/C/D           │ │   AUTOSAR Adaptive on      │ │
  │  │  AUTOSAR Classic or   │ │   Linux (ADAS, Infotainment)│ │
  │  │  QNX + safety AAs    │ │                             │ │
  │  └───────────────────────┘ └───────────────────────────┘ │
  │                                                          │
  └──────────────────────────────────────────────────────────┘

  Hypervisor provides:
  - CPU time partitioning (no runaway QM task starves ASIL task)
  - Memory isolation (QM OS cannot corrupt ASIL partition memory)
  - Peripheral access control (safety I/O only accessible to ASIL partition)
  
  Examples:
  - NVIDIA Drive Orin: Cortex-R5 safety island (ASIL D) + ARM Cortex-A (Linux, QM)
  - NXP S32G: M7 cores (ASIL D) + A53 cores (Linux)
  - Renesas R-Car V4H: CR7 lockstep (ASIL D) + CA76 (Linux + Adaptive)

Platform Health Management (PHM) — Complete Coverage

PHM is the watchdog and health monitoring Functional Cluster of AUTOSAR Adaptive. It allows applications to register supervised entities and report their health status.

Supervision Types

1. Alive Supervision

The application must "check in" with PHM at a configured rate. If check-ins stop (process crashed, hung), PHM detects the failure:

#include <ara/phm/supervised_entity.h>

// The ARXML configures: expected alive period = 50ms, tolerance ±10ms
ara::phm::SupervisedEntity se("/RadarApp/AliveSupervision/MainTask");

// Called in main processing loop (~20 Hz)
void MainProcessingLoop() {
    while (running) {
        DoRadarProcessing();
        
        // Report alive checkpoint
        se.ReportCheckpoint(ara::phm::CheckpointId{0});  // checkpoint ID 0 = "alive"
        
        std::this_thread::sleep_for(50ms);
    }
}

2. Deadline Supervision

Ensures an operation completes within a minimum and maximum time window:

// ARXML configures: min = 10ms, max = 100ms between checkpoint A and B
ara::phm::SupervisedEntity se("/RadarApp/DeadlineSupervision/FilterOp");

void RunFilterOperation() {
    se.ReportCheckpoint(ara::phm::CheckpointId{1});  // Start: checkpoint A
    
    RunExpensiveFilterAlgorithm();  // Must complete within 10–100ms
    
    se.ReportCheckpoint(ara::phm::CheckpointId{2});  // End: checkpoint B
    // PHM calculates time between checkpoint 1 and 2
    // If outside [10ms, 100ms] → supervision failure
}

3. Logical Supervision

Verifies that software executes in the correct sequence:

// ARXML defines valid execution graph:
// Checkpoint 1 → Checkpoint 2 → Checkpoint 3 → Checkpoint 1 (loop)
// Any other transition → logical supervision failure

void ProcessingPipeline() {
    se.ReportCheckpoint(1);  // Pre-processing
    PreProcess();
    
    se.ReportCheckpoint(2);  // Main processing
    MainProcess();
    
    se.ReportCheckpoint(3);  // Post-processing
    PostProcess();
    
    // Loop back to 1 — valid in the ARXML supervision graph
}

Recovery Actions Configured in ARXML

<PHM-SUPERVISED-ENTITY-INTERFACE>
  <SHORT-NAME>RadarMainTaskSupervision</SHORT-NAME>
  
  <!-- Supervision configuration -->
  <ALIVE-SUPERVISION>
    <EXPECTED-ALIVE-INDICATIONS>1</EXPECTED-ALIVE-INDICATIONS>
    <ALIVE-REFERENCE-CYCLE>50</ALIVE-REFERENCE-CYCLE>       <!-- 50ms -->
    <MIN-MARGIN>5</MIN-MARGIN>                              <!-- ±5ms tolerance -->
    <MAX-MARGIN>10</MAX-MARGIN>
    <SUPERVISION-STATUS-TOLERANCE-COUNT>3</SUPERVISION-STATUS-TOLERANCE-COUNT>
    <!-- 3 missed checkpoints before fault reported -->
  </ALIVE-SUPERVISION>
  
  <!-- What PHM should do on failure -->
  <RECOVERY-ACTION>
    <RECOVERY-NOTIFICATION>REPORT_TO_SM</RECOVERY-NOTIFICATION>
    <!-- SM will then: request ADAS FunctionGroup → Off state, trigger safe stop -->
  </RECOVERY-ACTION>
</PHM-SUPERVISED-ENTITY-INTERFACE>

ara::crypto — Complete Coverage

ara::crypto provides cryptographic services to AUTOSAR Adaptive Applications, backed by a Hardware Security Module (HSM) when available.

Cryptographic Services Overview

ara::crypto service categories:

  ┌─────────────────────────────────────────────────────┐
  │               ara::crypto                           │
  │                                                     │
  │  Symmetric Encryption     AES-128/256 CBC/GCM/ECB  │
  │  Asymmetric Encryption    RSA-2048/4096, ECC        │
  │  Digital Signatures       ECDSA, RSA-PSS, RSA-PKCS1 │
  │  Message Authentication   CMAC (AES), HMAC-SHA256   │
  │  Hashing                  SHA-256, SHA-384, SHA-512 │
  │  Key Derivation           HKDF, SP800-108           │
  │  Random Number Gen        TRNG via HSM              │
  │  Key Management           Generate, import, export  │
  │  TLS/DTLS                 TLS 1.3, DTLS 1.3         │
  └─────────────────────────────────────────────────────┘
         │
         ▼
  ┌─────────────────────────────────────────────────────┐
  │         Crypto Provider (pluggable)                 │
  │  ┌──────────────┐     ┌─────────────────────────┐  │
  │  │ HSM backend  │ OR  │ Software crypto library  │  │
  │  │ (SHE, TPM)  │     │ (OpenSSL, Mbed TLS)      │  │
  │  └──────────────┘     └─────────────────────────┘  │
  └─────────────────────────────────────────────────────┘

Code Examples

Digital Signature Verification

#include <ara/crypto/public/crypto_provider.h>

auto& provider = ara::crypto::GetDefaultProvider();

// Load a pre-stored public key (retrieved from key storage)
auto key_slot = provider.LoadPublicKey(key_id);

// Create a verification context
auto verify_ctx = provider.CreateMsgRecoveryPublicCtx(
    ara::crypto::AlgorithmId::kEcdsaSha256);

// Process the data to verify
verify_ctx->Update(data_buffer);

// Verify — returns ara::core::Result<bool>
auto result = verify_ctx->Verify(signature_buffer);
if (result.HasValue() && result.Value()) {
    ProcessAuthenticatedData();
} else {
    logger.LogError() << "Signature verification FAILED";
    RejectData();
}

AES-GCM Encryption / Decryption

auto encrypt_ctx = provider.CreateSymmetricBlockCipherCtx(
    ara::crypto::AlgorithmId::kAes128Gcm);

// Load AES key from secure key storage
auto key = provider.LoadSecretKey(aes_key_slot_id);
encrypt_ctx->SetKey(*key, ara::crypto::CryptoObjectUsage::kKryptoObjectEncrypt);

// Provide IV/nonce (must be unique per encryption operation)
std::vector<uint8_t> iv(12);  // 96-bit IV for GCM
provider.GenerateRandom(iv);

encrypt_ctx->Start(iv);
encrypt_ctx->Update(plaintext);
auto ciphertext_result = encrypt_ctx->Finish();

// ciphertext_result contains: ciphertext + 16-byte GCM authentication tag

HMAC Generation

auto mac_ctx = provider.CreateMessageAuthnCodeCtx(
    ara::crypto::AlgorithmId::kHmacSha256);

auto hmac_key = provider.LoadSecretKey(hmac_key_slot_id);
mac_ctx->SetKey(*hmac_key);
mac_ctx->Start();
mac_ctx->Update(message);
auto mac_result = mac_ctx->Finish(true /* produce MAC */);

// Verify on receiver side
auto verify_mac_ctx = provider.CreateMessageAuthnCodeCtx(
    ara::crypto::AlgorithmId::kHmacSha256);
verify_mac_ctx->SetKey(*hmac_key);
verify_mac_ctx->Start();
verify_mac_ctx->Update(message);

bool valid = verify_mac_ctx->Check(received_mac).HasValue();

ara::iam — Identity and Access Management

ara::iam controls which Adaptive Applications may access which services. This prevents a compromised or buggy AA from calling services it has no legitimate reason to access.

Access Control Model

Every AA has:
  - An Application Identity Certificate (X.509 certificate, signed by OEM CA)
  - A set of permissions declared in its Application Manifest
  
Every service has:
  - An access control policy: "only apps with permission X can call method Y"
  
Enforcement happens in CM:
  - When Proxy.FindService() is called, CM checks if the caller's identity
    certificate grants it the required service access permission
  - If not, FindService() returns empty (service not found — by policy)

IAM ARXML Configuration

<!-- Who is allowed to access RadarObjectService? -->
<IAM-STATEMENT>
  <REQUESTED-SERVICE-INSTANCE-REF>/Services/RadarService_Inst1</REQUESTED-SERVICE-INSTANCE-REF>
  
  <!-- Allow PathPlanningApp to subscribe to DetectedObjects event -->
  <ALLOWED-PROVIDER>
    <APPLICATION-REF>/Apps/PathPlanningApp</APPLICATION-REF>
    <SERVICE-ELEMENT>DetectedObjects</SERVICE-ELEMENT>
    <ACTION>SUBSCRIBE</ACTION>
  </ALLOWED-PROVIDER>
  
  <!-- Allow DiagnosticsApp to call ResetDetectionFilter method -->
  <ALLOWED-PROVIDER>
    <APPLICATION-REF>/Apps/DiagnosticsApp</APPLICATION-REF>
    <SERVICE-ELEMENT>ResetDetectionFilter</SERVICE-ELEMENT>
    <ACTION>CALL</ACTION>
  </ALLOWED-PROVIDER>
</IAM-STATEMENT>

SecOC — Secure OnBoard Communication for Adaptive

SecOC provides message authentication for SOME/IP messages to detect injection, replay, and tampering attacks. In AUTOSAR Adaptive R21-11+, SecOC is integrated as a transformer in the ara::com pipeline.

SecOC Transformer Chain

  Sending side:
  Application data (ObjectList)
       │
  ┌────┴──────────────────────────────────────────────────────┐
  │  SecOC Transformer                                        │
  │  1. Compute CMAC-AES128 over (data + FreshnessValue + DataID) │
  │  2. Append truncated MAC (e.g., 24 bits)                  │
  │  3. Append FreshnessValue counter                         │
  └────┬──────────────────────────────────────────────────────┘
       │
  ┌────┴──────────────────────────────────────────────────────┐
  │  SOME/IP Serializer + UDP                                 │
  └────────────────────────────────────────────────────────────┘
  
  Receiving side:
  UDP → Deserialize → SecOC Transformer:
  1. Extract FreshnessValue — check > stored value (anti-replay)
  2. Recompute CMAC with same key
  3. Compare with received MAC — if mismatch → discard + report
  4. If valid → deliver to application

SecOC configuration in ARXML:

<SECURED-I-PDU-PROPERTIES>
  <MESSAGE-LINK-REF>/IPDU/DetectedObjects_IPDU</MESSAGE-LINK-REF>
  <AUTH-INFO-TX-LENGTH>3</AUTH-INFO-TX-LENGTH>  <!-- 24-bit truncated MAC -->
  <FRESHNESS-VALUE-ID>10</FRESHNESS-VALUE-ID>
  <FRESHNESS-VALUE-TX-LENGTH>4</FRESHNESS-VALUE-TX-LENGTH>  <!-- 32-bit counter -->
  <DATA-ID>0x00AB</DATA-ID>
  <MESSAGE-AUTHENTICATION-CODE>CMAC_AES128</MESSAGE-AUTHENTICATION-CODE>
</SECURED-I-PDU-PROPERTIES>

TLS/DTLS in Adaptive Platform

For cross-ECU communication, SOME/IP can be transported over TLS 1.3 (for TCP-based methods) or DTLS 1.3 (for UDP-based events). This is configured in the Service Instance Manifest:

<REQUIRED-SOMEIP-SERVICE-INSTANCE>
  <TLS-SECURITY-LEVEL>TLS</TLS-SECURITY-LEVEL>
  <TLS-CRYPTO-CIPHER-SUITE>TLS_AES_256_GCM_SHA384</TLS-CRYPTO-CIPHER-SUITE>
  <CLIENT-CERTIFICATE-REF>/Crypto/PathPlannerCert</CLIENT-CERTIFICATE-REF>
  <ROOT-CA-CERTIFICATE-REF>/Crypto/OEM_RootCA</ROOT-CA-CERTIFICATE-REF>
</REQUIRED-SOMEIP-SERVICE-INSTANCE>

Mutual TLS (mTLS) is recommended for all safety-relevant or security-sensitive services.

ISO 26262 Work Products for an ASIL B Adaptive Application

Developing an ASIL B Adaptive Application requires these ISO 26262 Part 6 work products:

Work Product	Content
Software Safety Requirements	Derived from system-level ASIL B safety goals
Software Architecture Design	How the AA implements requirements, ara:: API usage, error handling
Software Unit Design	Detailed C++ class/function design per safety requirement
Software Unit Implementation	C++ source code written to MISRA C++ or AUTOSAR C++14 guidelines
Software Unit Verification	Unit tests with 100% MC/DC coverage for ASIL B
Software Integration Test	Tests of AA on target or HIL with ARA mocks
Dependent Failure Analysis	Analysis of common cause failures between AA and platform
Safety Manual Compliance	Documentation showing compliance with platform safety manual

ISO/SAE 21434 Cybersecurity in Adaptive Context

The ISO/SAE 21434 standard (Road Vehicles — Cybersecurity Engineering) applies to AUTOSAR Adaptive systems which have significant attack surface compared to Classic platforms.

TARA (Threat Analysis and Risk Assessment) for Adaptive Services

For each ara::com Service:
  1. Asset identification: what sensitive data does this service expose?
     Example: Camera feed (privacy), GPS location (tracking), Steering control
     
  2. Threat scenarios:
     - Spoofing: attacker impersonates a valid service provider
       → Mitigation: mTLS + ara::iam certificate-based identity
       
     - Tampering: attacker modifies messages in transit
       → Mitigation: TLS for SOME/IP, SecOC for CAN bridging
       
     - Replay: attacker records and replays old valid messages
       → Mitigation: SecOC FreshnessValue counter
       
     - Information disclosure: unauthorized subscriber reads sensitive events
       → Mitigation: ara::iam access control on service instances
       
     - Denial of Service: flood CM with FindService requests
       → Mitigation: rate limiting in CM; process isolation (EM cgroups)
       
  3. Risk assessment: CVSS score + automotive safety impact
  4. Security goals: derived security requirements for the system
  5. Cybersecurity concepts: architecture decisions (TLS, IAM, SecOC)

Secure Boot and Key Management

Secure Boot Chain for Adaptive Platform:

  Hardware Root of Trust (HSM/SHE)
         │ verifies signature of
         ▼
  Bootloader (Signed by OEM key)
         │ verifies signature of
         ▼
  OS kernel + initrd (Signed)
         │ verifies (dm-verity or IMA)
         ▼
  AUTOSAR Adaptive Platform services (Signed)
         │ ara::iam verifies application certificates
         ▼
  Adaptive Applications

Key storage:
  - AES keys for SecOC stored in HSM (hardware-protected)
  - TLS private keys for each AA stored in ara::crypto key slots
  - Keys provisioned at manufacturing via secure provisioning protocol
  - Key update: UCM + ara::crypto key import with OEM authorization

VAD

ASR

TTS

llama-swap

llama.cpp

EDK2-UEFI

U-Boot

Yocto

QEMU

QNX

AUTOSAR Adaptive

MISRA C++

ASIL

ASPICE

Conan

Artifactory

Jenkins

Safety and Security in AUTOSAR Adaptive