# BAP Layer Structure and Architecture
This document details the BAP protocol stack architecture and its relationship to the OSI model.
## BAP vs OSI Model Comparison
```plaintext
┌─────────────────────────────────┬─────────────────────────────────┐
│ OSI Model │ BAP Stack │
├─────────────────────────────────┼─────────────────────────────────┤
│ 7. Application Layer │ Vehicle Applications │
│ (User Interface) │ (Phone, MDI, Climate Control) │
├─────────────────────────────────┼─────────────────────────────────┤
│ 6. Presentation Layer │ BAP Dispatcher │
│ (Data Formatting) │ (Message Routing & Formatting) │
├─────────────────────────────────┼─────────────────────────────────┤
│ 5. Session Layer │ BAL - Application Layer │
│ (Dialog Control) │ (Session Management & Cache) │
├─────────────────────────────────┼─────────────────────────────────┤
│ 4. Transport Layer │ BPL - Protocol Layer │
│ (Reliable Transfer) │ (Retry, Heartbeat, Flow Control)│
├─────────────────────────────────┼─────────────────────────────────┤
│ 3. Network Layer │ BCL - Communication Layer │
│ (Routing & Addressing) │ (LSG Routing & Segmentation) │
├─────────────────────────────────┼─────────────────────────────────┤
│ 2. Data Link Layer │ CAN Protocol │
│ (Error Detection) │ (Frame Check, Arbitration) │
├─────────────────────────────────┼─────────────────────────────────┤
│ 1. Physical Layer │ CAN Transceiver │
│ (Bits & Signaling) │ (Electrical Signals) │
└─────────────────────────────────┴─────────────────────────────────┘
```
## BAP Protocol Stack Details
### Application Layer (OSI Layer 7)
**Vehicle-Specific Applications**
- Individual LSG implementations (Phone, Camera, etc.)
- User interface logic
- Business logic for each function
**Responsibilities:**
- Implement vehicle-specific features
- Process user inputs
- Generate display content
- Handle application state
### BAP Dispatcher (OSI Layer 6)
**Message Routing and Translation**
- Routes messages between LSGs and transport layers
- Translates between application formats and BAP messages
- Manages multiple concurrent LSG sessions
**Key Functions:**
```c
// Example dispatcher routing
void dispatch_message(bap_msg_t *msg) {
switch (msg->lsg_id) {
case LSG_PHONE: route_to_phone_handler(msg); break;
case LSG_CAMERA: route_to_camera_handler(msg); break;
case LSG_CLIMATE: route_to_climate_handler(msg); break;
}
}
```
### BAL - BAP Application Layer (OSI Layer 5)
**Session and State Management**
- Maintains connection state between FSG and ASG
- Implements cache synchronization
- Handles GetAll/StatusAll operations
- Manages transaction IDs (TAID) MQB Only*
**Core Components:**
- **FSG Manager**: Tracks registered functions and states
- **ASG Cache**: Stores last known values from FSGs
- **Session Controller**: Manages FSG-ASG relationships
### BPL - BAP Protocol Layer (OSI Layer 4)
**Reliable Message Delivery**
- Implements retry mechanisms
- Manages heartbeat generation and monitoring
- Handles acknowledgments
- Implements flow control
**Protocol Features:**
```plaintext
┌─────────────────────────────────────┐
│ Retry Logic: │
│ - Configurable retry attempts │
│ - Implementation-specific intervals │
│ - Timeout handling │
├─────────────────────────────────────┤
│ Heartbeat: │
│ - Interval configured during setup │
│ - Module-specific timing │
│ - Auto-reconnect on timeout │
└─────────────────────────────────────┘
```
### BCL - BAP Communication Layer (OSI Layer 3)
**Message Construction and Routing**
- Constructs BAP headers
- Implements multi-frame segmentation
- Routes based on LSG ID
- Manages message queues
**Multi-Frame Handling:**
```plaintext
Single Frame Path:
App Data → Add Header → Direct Send
Multi-Frame Path:
App Data → Add Header → Segment → Add Preambles → Sequential Send
```
### CAN Protocol Layer (OSI Layer 2)
**Standard CAN Features**
- Error detection (CRC)
- Message arbitration
- Acknowledgment handling
- Bit stuffing
### Physical Layer (OSI Layer 1)
**Hardware Interface**
- CAN-H/CAN-L differential signaling
- Voltage levels (recessive/dominant)
- Termination resistors
- Transceiver hardware
## Data Flow Example
### Sending a Phone Status Update (FSG → ASG)
```plaintext
1. Application Layer (Phone Module)
└─ "iPhone Connected, Signal: 4/5"
2. BAP Dispatcher
└─ Route to Phone LSG handler (0x28)
3. BAL (Application Layer)
└─ Create StatusArray message
└─ Assign TAID if needed
4. BPL (Protocol Layer)
└─ Set retry timer
└─ Reset heartbeat timer
5. BCL (Communication Layer)
└─ Build header: [Status|LSG:0x28|FCT:0x14]
└─ Check if multi-frame needed
6. CAN Protocol
└─ Add CAN ID (PQ: 0x123, MQB: 0x17332810)
└─ Calculate CRC
7. Physical Layer
└─ Transmit differential signals
```
## Platform-Specific Implementations
### PQ Platform Stack
```plaintext
┌─────────────────────────────────┐
│ Applications (FSG/ASG specific) │
├─────────────────────────────────┤
│ BAP Dispatcher (Software) │
├─────────────────────────────────┤
│ BAL (Unified Implementation) │
├─────────────────────────────────┤
│ BPL (Standard BAP) │
├─────────────────────────────────┤
│ BCL (PQ-specific) │
│ - 11-bit CAN IDs │
│ - Header-based LSG │
├─────────────────────────────────┤
│ CAN 2.0A Driver │
└─────────────────────────────────┘
```
### MQB Platform Stack
```plaintext
┌─────────────────────────────────┐
│ Applications (Enhanced FSG/ASG) │
├─────────────────────────────────┤
│ BAP Dispatcher (Hardware-assist)│
├─────────────────────────────────┤
│ BAL (Extended features) │
├─────────────────────────────────┤
│ BPL (Enhanced BAP, TAID) │
├─────────────────────────────────┤
│ BCL (MQB-specific) │
│ - 29-bit Extended CAN IDs │
│ - CAN ID-based LSG │
│ - Hardware filtering │
├─────────────────────────────────┤
│ CAN 2.0B Driver │
└─────────────────────────────────┘
```
## Inter-Layer Communication
### Message Structure Between Layers
```plaintext
Application → BAL:
{
function_id: 0x14,
operation: STATUS,
data: [payload],
callback: app_callback_func
}
BAL → BPL:
{
header: 0x3B14,
lsg_id: 0x28,
taid: 0x42,
data: [payload],
retry_count: 0
}
BPL → BCL:
{
priority: HIGH,
header: 0x3B14,
data: [payload],
segment_if_needed: true
}
BCL → CAN:
{
can_id: 0x123, // PQ
dlc: 8,
data: [0x3B, 0x14, payload...]
}
```
## Key Design Principles
1. **Layer Independence**
- Each layer only knows about adjacent layers
- Clean interfaces between layers
- Platform differences isolated to BCL
2. **Event-Driven Architecture**
- Asynchronous message passing
- Callback-based responses
- Non-blocking operations
3. **Resource Optimization**
- Minimal memory footprint
- Efficient buffer management
- Platform-specific optimizations
4. **Error Resilience**
- Each layer handles its own errors
- Graceful degradation
- Automatic recovery mechanisms
## Implementation Considerations
### Memory Management
- Pre-allocated buffers per LSG
- Ring buffers for message queues
- Static memory allocation preferred
### Thread Safety
- Mutex protection for shared resources
- Lock-free queues where possible
- ISR-safe message handling
### Performance Optimization
- Zero-copy message passing
- Hardware CAN filtering (MQB)
- Batch processing of multi-frame messages
## Related Documentation