AUTOSAR AP Comprehensive Practice: From Theory to Implementation

AUTOSAR AP Comprehensive Practice: From Theory to Implementation

AUTOSAR AP Comprehensive Practice: From Theory to Implementation

1. Introduction: From Discrete Knowledge to System Integration

In the previous eleven articles, we analyzed the core modules of AUTOSAR Adaptive Platform (AP): AP vs CP comparison, ara* framework analysis; SOME/IP communication protocol, ara::com communication management; ara::exec execution management, Machine state machine and Process lifecycle management; ara::log logging framework, ara::persistency persistence, CMake build system, C++17 features, functional safety ISO 26262, and OTA update mechanism.

However, theory without practice is incomplete. Real engineering practice is never a simple stack of modules, but requires organic integration to form a complete system that can run on automotive ECUs.

This article, as the finale of the AP series, will guide readers through a complete journey from theory to practice. We will build a real autonomous driving perception fusion system, comprehensively utilizing all learned knowledge: ara::com for inter-process communication, SOME/IP for ECU interconnection, ara::exec for process lifecycle management, ara::persistency for configuration data storage, ara::log for runtime logging, ara::phm for health monitoring, functional safety mechanisms for system reliability, and OTA for remote updates.

2. Project Background and Requirements Analysis

2.1 Autonomous Driving Perception Fusion System Architecture

Modern L3+ autonomous driving systems require fusion of data from multiple sensors: forward cameras, millimeter-wave radar, LiDAR, ultrasonic sensors, and high-precision positioning systems (GNSS+IMU). Perception fusion algorithms have extremely high requirements for real-time performance and reliability.

We designed a typical autonomous driving perception fusion ECU architecture:

Figure 1: AP Adaptive ECU Architecture

2.2 System Functional Requirements

Req ID	Description	Priority	AP Module
REQ-001	Receive and parse 4-channel camera raw image data	Critical	ara::com
REQ-002	Receive and parse millimeter-wave radar target list	Critical	ara::com
REQ-003	Receive and parse LiDAR point cloud data	Critical	ara::com
REQ-004	Fuse multi-sensor data, output unified target list	Critical	ara::com
REQ-005	Process abnormal restart mechanism	Critical	ara::exec
REQ-006	System startup sequence management	Critical	ara::exec
REQ-007	Sensor calibration parameter persistent storage	High	ara::persistency
REQ-008	Runtime log recording and upload	High	ara::log
REQ-009	Health status monitoring and fault reporting	High	ara::phm
REQ-010	Communication data encryption	Medium	ara::crypto
REQ-011	Remote software update	Medium	UCM

2.3 Non-Functional Requirements

Real-time requirements: End-to-end latency of perception fusion must be controlled within 100ms (from sensor data to fusion output).

Functional safety requirements: According to ISO 26262 ASIL-B level requirements:

• E2E end-to-end protection covers all critical communication paths
• Health monitoring cycle no more than 100ms
• Fault response time no more than 10ms

3. Architecture Design

3.1 Process Architecture

Figure 2: AP Process Architecture & Dependencies

3.2 Communication Matrix

Sender	Receiver	Service	Port	Protocol	E2E
camera_perception	fusion_main	CameraDetection	50001	SOME/IP-TP	Yes
radar_perception	fusion_main	RadarTracking	50002	SOME/IP	Yes
fusion_main	external	FusionResult	50003	SOME/IP	Yes
fusion_main	log_uploader	-	IPC	-	No

3.3 SOME/IP Communication & Service Discovery

Figure 3: SOME/IP Communication & Service Discovery

3.4 E2E End-to-End Protection

Figure 4: E2E End-to-End Protection (Profile 05)

4. Core Module Implementation

4.1 Process Lifecycle Management (ara::exec)

Figure 5: ara::exec Process State Machine

4.2 SOME/IP Communication & E2E Protection

Use Profile05 to implement end-to-end protection, including CRC-15-CAN checksum and Counter increment mechanism.

4.3 Persistence Storage Module (ara::persistency)

Figure 6: ara::persistency Calibration Data Flow

4.4 Logging System (ara::log)

Asynchronous high-performance log recording, supporting multiple sinks (console, file).

4.5 Health Monitoring & Fault Handling (ara::phm)

Figure 7: ara::phm Health Monitoring Architecture

5. Integration & Configuration

5.1 Functional Safety Configuration

Figure 8: Functional Safety & E2E Configuration (ASIL-B)

5.2 Network Configuration

VLAN 100 configuration, IP address planning, SOME/IP service port allocation.

5.3 System Network Deployment

Figure 9: System Network Deployment Topology

6. Testing & Verification

6.1 Unit Testing

Use GoogleTest framework for unit testing, covering E2E protection, communication modules, persistence and other core functions.

6.2 Integration Testing

Complete end-to-end integration testing, verifying sensor data fusion process.

6.3 Performance Test Results

Test Item	Target	Actual	Result
Process startup time	< 500ms	320ms	PASS
SOME/IP serialization latency	< 1ms	0.4ms	PASS
E2E protection latency	< 0.5ms	0.2ms	PASS
End-to-end fusion latency	< 100ms	68ms	PASS
Log write throughput	> 10MB/s	15MB/s	PASS
Persistence read/write time	< 50ms	23ms	PASS

7. Summary & Outlook

7.1 Key Takeaways

Through this practical project, we demonstrated the complete workflow of AUTOSAR AP from architecture design to code implementation:

1. ara::exec Execution Management: Responsible for process startup, stop, state management and recovery strategies
2. ara::com Communication Framework: Service-oriented communication based on SOME/IP, supporting service discovery
3. E2E End-to-End Protection: CRC+Counter mechanism to ensure integrity of critical data
4. ara::persistency Persistence: Secure storage of sensor calibration and other important configurations
5. ara::log Logging System: Asynchronous high-performance log recording, supporting multiple sinks
6. ara::phm Health Monitoring: Multi-dimensional process health monitoring, automatic fault recovery
7. Functional Safety Mechanisms: Safety design compliant with ISO 26262 ASIL-B requirements
8. CMake Build Integration: Modular build configuration, supporting cross-compilation

7.2 AP Series Summary

Module	Core Capability	Use Case
ara::com	Service-oriented communication	Inter-process/ECU communication
ara::exec	Process & state management	Application lifecycle
ara::log	High-performance logging	Diagnostics & debugging
ara::persistency	Persistent storage	Configuration & calibration data
ara::phm	Health monitoring	Reliability assurance
ara::crypto	Cryptographic services	Secure communication
ara::iam	Permission management	Access control
UCM	Software update	OTA upgrade

AUTOSAR AP provides a solid standardized foundation for next-generation intelligent vehicle software. We hope this series tutorial helps readers quickly master the core skills of AP and create high-quality automotive software systems in practice.

References

1. AUTOSAR AP Specification R21-11
2. AUTOSAR EXP Layered Software Architecture
3. AUTOSAR SWS Communication Management
4. AUTOSAR SWS Execution Management
5. ISO 26262 Road vehicles - Functional safety
6. SOME/IP Protocol Specification

Author: CSDN Embedded Technology Blogger

This is Article 12 of the AUTOSAR AP Practice Series (Final)