Documentation

• 1: About Leda
• 1.1: Architecture
• 1.2: Features
• 1.3: Goals
• 1.4: Roadmap
• 1.5: Releases
• 1.5.1: Milestone 0.1.0-M1
• 1.5.2: Milestone 0.1.0-M2
• 1.5.3: Release Plan 0.1.0
• 1.5.4:
• 2: Getting Started
• 2.1: Introduction to SDV concepts
• 2.2: Download latest release
• 2.3: Running on Docker
• 2.4: Running on Raspberry Pi
• 2.4.1: CAN-Bus extensions
• 2.5: Running on QEMU
• 2.5.1: CAN Bus
• 2.5.2: Transferring Files
• 2.6: Running on Linux
• 2.7: Cheatsheet
• 2.8: Utilities
• 2.8.1: SDV Health
• 2.8.2: KantUI
• 2.8.3: SDV Device Info
• 2.8.4: SDV Provision
• 2.8.5: SDV MotD
• 2.8.6: CAN Forward
• 2.8.7: Kanto Auto Deployer (KAD)
• 2.8.8: SDV Container Exec
• 2.8.9: SDV Kanto-Ctl
• 2.8.10: Blueprint Selector
• 2.9: Wifi Configuration
• 2.9.1: Connecting to Wi-Fi networks
• 2.10: GPS Connectivity
• 3: Device Provisioning
• 3.1: Manual Provisioning
• 3.2: Provisioning with sdv-provision
• 3.3: Vehicle Update Manager
• 3.3.1: Configuration
• 3.3.2: Message Flow
• 3.4: Self Updates
• 3.4.1: Self Update Tutorial
• 3.4.2: RAUC Integration
• 3.4.3: API Reference
• 3.5: Container Management
• 3.5.1: Cloud Connectivity
• 3.5.2: Container Update Agent
• 3.5.3: Orchestration
• 3.5.4: Container Metrics
• 3.5.5: Container Registries
• 4: Vehicle Applications
• 4.1: Seat Adjuster
• 4.1.1: Architecture of Seat Adjuster
• 4.1.2: Develop Seat Adjuster
• 4.1.3: Deploy Seat Adjuster
• 4.1.4: Interact with Seat Adjuster
• 4.1.5: CAN Setup for Seat Adjuster
• 4.2: Dog Mode
• 4.3: VSS & Kuksa.VAL
• 4.3.1: Custom Vehicle Signals
• 4.4: CarSim
• 4.5: Velocitas VApps
• 4.6: Cloud2Device Messages
• 5: Vehicle Signals
• 5.1: Vehicle
• 5.1.1: ControlUnit
• 5.1.1.1: FrontLeft
• 5.1.1.1.1: Health
• 5.1.1.1.1.1: Network
• 5.1.1.1.1.1.1: CAN
• 5.1.1.1.1.1.1.1: IsNetworkOK
• 5.1.1.1.1.1.2: ETH
• 5.1.1.1.1.1.2.1: IsNetworkOK
• 5.1.1.1.1.2: Resources
• 5.1.1.1.1.2.1: Power
• 5.1.1.1.1.2.2: Temperature
• 5.1.1.1.1.2.3: Utilization
• 5.1.1.1.1.2.3.1: CPU
• 5.1.1.1.1.2.3.2: Memory
• 5.1.1.1.1.3: SWSupervision
• 5.1.1.1.1.3.1: IsAliveTriggered
• 5.1.1.1.1.3.2: IsDeadlineTriggered
• 5.1.1.1.1.3.3: IsLogicalTriggered
• 5.1.1.1.1.3.4: IsWatchdogTriggered
• 5.1.1.1.2: ID
• 5.1.1.2: FrontRight
• 5.1.1.2.1: Health
• 5.1.1.2.1.1: Network
• 5.1.1.2.1.1.1: CAN
• 5.1.1.2.1.1.1.1: IsNetworkOK
• 5.1.1.2.1.1.2: ETH
• 5.1.1.2.1.1.2.1: IsNetworkOK
• 5.1.1.2.1.2: Resources
• 5.1.1.2.1.2.1: Power
• 5.1.1.2.1.2.2: Temperature
• 5.1.1.2.1.2.3: Utilization
• 5.1.1.2.1.2.3.1: CPU
• 5.1.1.2.1.2.3.2: Memory
• 5.1.1.2.1.3: SWSupervision
• 5.1.1.2.1.3.1: IsAliveTriggered
• 5.1.1.2.1.3.2: IsDeadlineTriggered
• 5.1.1.2.1.3.3: IsLogicalTriggered
• 5.1.1.2.1.3.4: IsWatchdogTriggered
• 5.1.1.2.2: ID
• 5.1.1.3: RearLeft1
• 5.1.1.3.1: Health
• 5.1.1.3.1.1: Network
• 5.1.1.3.1.1.1: CAN
• 5.1.1.3.1.1.1.1: IsNetworkOK
• 5.1.1.3.1.1.2: ETH
• 5.1.1.3.1.1.2.1: IsNetworkOK
• 5.1.1.3.1.2: Resources
• 5.1.1.3.1.2.1: Power
• 5.1.1.3.1.2.2: Temperature
• 5.1.1.3.1.2.3: Utilization
• 5.1.1.3.1.2.3.1: CPU
• 5.1.1.3.1.2.3.2: Memory
• 5.1.1.3.1.3: SWSupervision
• 5.1.1.3.1.3.1: IsAliveTriggered
• 5.1.1.3.1.3.2: IsDeadlineTriggered
• 5.1.1.3.1.3.3: IsLogicalTriggered
• 5.1.1.3.1.3.4: IsWatchdogTriggered
• 5.1.1.3.2: ID
• 5.1.1.4: RearLeft2
• 5.1.1.4.1: Health
• 5.1.1.4.1.1: Network
• 5.1.1.4.1.1.1: CAN
• 5.1.1.4.1.1.1.1: IsNetworkOK
• 5.1.1.4.1.1.2: ETH
• 5.1.1.4.1.1.2.1: IsNetworkOK
• 5.1.1.4.1.2: Resources
• 5.1.1.4.1.2.1: Power
• 5.1.1.4.1.2.2: Temperature
• 5.1.1.4.1.2.3: Utilization
• 5.1.1.4.1.2.3.1: CPU
• 5.1.1.4.1.2.3.2: Memory
• 5.1.1.4.1.3: SWSupervision
• 5.1.1.4.1.3.1: IsAliveTriggered
• 5.1.1.4.1.3.2: IsDeadlineTriggered
• 5.1.1.4.1.3.3: IsLogicalTriggered
• 5.1.1.4.1.3.4: IsWatchdogTriggered
• 5.1.1.4.2: ID
• 5.1.1.5: Trunk
• 5.1.1.5.1: ID
• 5.1.1.5.2: Health
• 5.1.1.5.2.1: Network
• 5.1.1.5.2.1.1: CAN
• 5.1.1.5.2.1.1.1: IsNetworkOK
• 5.1.1.5.2.1.2: ETH
• 5.1.1.5.2.1.2.1: IsNetworkOK
• 5.1.1.5.2.2: Resources
• 5.1.1.5.2.2.1: Power
• 5.1.1.5.2.2.2: Temperature
• 5.1.1.5.2.2.3: Utilization
• 5.1.1.5.2.2.3.1: CPU
• 5.1.1.5.2.2.3.2: Memory
• 5.1.1.5.2.3: SWSupervision
• 5.1.1.5.2.3.1: IsLogicalTriggered
• 5.1.1.5.2.3.2: IsWatchdogTriggered
• 5.1.1.5.2.3.3: IsAliveTriggered
• 5.1.1.5.2.3.4: IsDeadlineTriggered
• 5.1.1.6: Central
• 5.1.1.6.1: ID
• 5.1.1.6.2: Health
• 5.1.1.6.2.1: Network
• 5.1.1.6.2.1.1: CAN
• 5.1.1.6.2.1.1.1: IsNetworkOK
• 5.1.1.6.2.1.2: ETH
• 5.1.1.6.2.1.2.1: IsNetworkOK
• 5.1.1.6.2.2: Resources
• 5.1.1.6.2.2.1: Power
• 5.1.1.6.2.2.2: Temperature
• 5.1.1.6.2.2.3: Utilization
• 5.1.1.6.2.2.3.1: CPU
• 5.1.1.6.2.2.3.2: Memory
• 5.1.1.6.2.3: SWSupervision
• 5.1.1.6.2.3.1: IsAliveTriggered
• 5.1.1.6.2.3.2: IsDeadlineTriggered
• 5.1.1.6.2.3.3: IsLogicalTriggered
• 5.1.1.6.2.3.4: IsWatchdogTriggered
• 5.1.2: Connectivity
• 5.1.2.1: IsConnectivityAvailable
• 5.1.3: Diagnostics
• 5.1.3.1: DTCCount
• 5.1.3.2: DTCList
• 5.1.4: Exterior
• 5.1.4.1: AirTemperature
• 5.1.4.2: Humidity
• 5.1.4.3: LightIntensity
• 5.1.5: MotionManagement
• 5.1.5.1: Steering
• 5.1.5.1.1: Axle
• 5.1.5.1.1.1: Row1
• 5.1.5.1.1.1.1: PositionOffsetTargetMode
• 5.1.5.1.1.1.2: PositionTargetMode
• 5.1.5.1.1.1.3: RackPosition
• 5.1.5.1.1.1.4: RackPositionOffsetTarget
• 5.1.5.1.1.1.5: RackPositionTarget
• 5.1.5.1.1.1.6: SteerAngle
• 5.1.5.1.1.1.7: SteerAngleOffsetTarget
• 5.1.5.1.1.1.8: SteerAngleTarget
• 5.1.5.1.1.2: Row2
• 5.1.5.1.1.2.1: SteerAngle
• 5.1.5.1.1.2.2: SteerAngleTarget
• 5.1.5.1.1.2.3: SteerAngleVelocityTarget
• 5.1.5.1.2: SteeringWheel
• 5.1.5.1.2.1: Angle
• 5.1.5.1.2.2: AngleTarget
• 5.1.5.1.2.3: AngleTargetMode
• 5.1.5.1.2.4: Torque
• 5.1.5.1.2.5: TorqueOffsetTarget
• 5.1.5.1.2.6: TorqueOffsetTargetMode
• 5.1.5.1.2.7: TorqueTarget
• 5.1.5.1.2.8: TorqueTargetMode
• 5.1.5.2: Suspension
• 5.1.5.2.1: Axle
• 5.1.5.2.1.1: Row1
• 5.1.5.2.1.1.1: RollTorque
• 5.1.5.2.1.1.2: Wheel
• 5.1.5.2.1.1.2.1: Left
• 5.1.5.2.1.1.2.1.1: DampingForce
• 5.1.5.2.1.1.2.1.2: DampingForceTarget
• 5.1.5.2.1.1.2.1.3: DampingRate
• 5.1.5.2.1.1.2.1.4: DampingRateTarget
• 5.1.5.2.1.1.2.2: Right
• 5.1.5.2.1.1.2.2.1: DampingForce
• 5.1.5.2.1.1.2.2.2: DampingForceTarget
• 5.1.5.2.1.1.2.2.3: DampingRate
• 5.1.5.2.1.1.2.2.4: DampingRateTarget
• 5.1.5.2.1.2: Row2
• 5.1.5.2.1.2.1: RollTorque
• 5.1.5.2.1.2.2: Wheel
• 5.1.5.2.1.2.2.1: Left
• 5.1.5.2.1.2.2.1.1: DampingForce
• 5.1.5.2.1.2.2.1.2: DampingForceTarget
• 5.1.5.2.1.2.2.1.3: DampingRate
• 5.1.5.2.1.2.2.1.4: DampingRateTarget
• 5.1.5.2.1.2.2.2: Right
• 5.1.5.2.1.2.2.2.1: DampingForce
• 5.1.5.2.1.2.2.2.2: DampingForceTarget
• 5.1.5.2.1.2.2.2.3: DampingRate
• 5.1.5.2.1.2.2.2.4: DampingRateTarget
• 5.1.5.2.2: DampingPrioTarget
• 5.1.5.2.3: RollPrioTarget
• 5.1.5.2.4: RollTorqueDistributionFrontMaximum
• 5.1.5.2.5: RollTorqueDistributionFrontMinimum
• 5.1.5.2.6: RollTorqueTarget
• 5.1.5.3: Brake
• 5.1.5.3.1: Axle
• 5.1.5.3.1.1: Row2
• 5.1.5.3.1.1.1: TorqueDistributionFrictionRightMaximum
• 5.1.5.3.1.1.2: TorqueDistributionFrictionRightMinimum
• 5.1.5.3.1.1.3: TorqueElectricMinimum
• 5.1.5.3.1.1.4: TorqueFrictionDifferenceMaximum
• 5.1.5.3.1.1.5: Wheel
• 5.1.5.3.1.1.5.1: Left
• 5.1.5.3.1.1.5.1.1: OmegaLower
• 5.1.5.3.1.1.5.1.2: OmegaUpper
• 5.1.5.3.1.1.5.1.3: Torque
• 5.1.5.3.1.1.5.1.4: TorqueArbitrated
• 5.1.5.3.1.1.5.1.5: TorqueFrictionMaximum
• 5.1.5.3.1.1.5.1.6: TorqueFrictionMinimum
• 5.1.5.3.1.1.5.2: Right
• 5.1.5.3.1.1.5.2.1: OmegaLower
• 5.1.5.3.1.1.5.2.2: OmegaUpper
• 5.1.5.3.1.1.5.2.3: Torque
• 5.1.5.3.1.1.5.2.4: TorqueArbitrated
• 5.1.5.3.1.1.5.2.5: TorqueFrictionMaximum
• 5.1.5.3.1.1.5.2.6: TorqueFrictionMinimum
• 5.1.5.3.1.2: Row1
• 5.1.5.3.1.2.1: TorqueDistributionFrictionRightMaximum
• 5.1.5.3.1.2.2: TorqueDistributionFrictionRightMinimum
• 5.1.5.3.1.2.3: TorqueElectricMinimum
• 5.1.5.3.1.2.4: TorqueFrictionDifferenceMaximum
• 5.1.5.3.1.2.5: Wheel
• 5.1.5.3.1.2.5.1: Left
• 5.1.5.3.1.2.5.1.1: OmegaLower
• 5.1.5.3.1.2.5.1.2: OmegaUpper
• 5.1.5.3.1.2.5.1.3: Torque
• 5.1.5.3.1.2.5.1.4: TorqueArbitrated
• 5.1.5.3.1.2.5.1.5: TorqueFrictionMaximum
• 5.1.5.3.1.2.5.1.6: TorqueFrictionMinimum
• 5.1.5.3.1.2.5.2: Right
• 5.1.5.3.1.2.5.2.1: OmegaLower
• 5.1.5.3.1.2.5.2.2: OmegaUpper
• 5.1.5.3.1.2.5.2.3: Torque
• 5.1.5.3.1.2.5.2.4: TorqueArbitrated
• 5.1.5.3.1.2.5.2.5: TorqueFrictionMaximum
• 5.1.5.3.1.2.5.2.6: TorqueFrictionMinimum
• 5.1.5.3.2: VehicleForceDistributionFrontMaximum
• 5.1.5.3.3: VehicleForceDistributionFrontMinimum
• 5.1.5.3.4: VehicleForceElectric
• 5.1.5.3.5: VehicleForceElectricMinimumArbitrated
• 5.1.5.3.6: VehicleForceMaximum
• 5.1.5.4: ElectricAxle
• 5.1.5.4.1: Row1
• 5.1.5.4.1.1: RotationalSpeed
• 5.1.5.4.1.2: RotationalSpeedMaximumLimit
• 5.1.5.4.1.3: RotationalSpeedMinimumLimit
• 5.1.5.4.1.4: RotationalSpeedTarget
• 5.1.5.4.1.5: Torque
• 5.1.5.4.1.6: TorqueMaximum
• 5.1.5.4.1.7: TorqueMaximumLimit
• 5.1.5.4.1.8: TorqueMinimum
• 5.1.5.4.1.9: TorqueMinimumLimit
• 5.1.5.4.1.10: TorqueTarget
• 5.1.5.4.2: Row2
• 5.1.5.4.2.1: RotationalSpeed
• 5.1.5.4.2.2: RotationalSpeedMaximumLimit
• 5.1.5.4.2.3: RotationalSpeedMinimumLimit
• 5.1.5.4.2.4: RotationalSpeedTarget
• 5.1.5.4.2.5: Torque
• 5.1.5.4.2.6: TorqueMaximum
• 5.1.5.4.2.7: TorqueMaximumLimit
• 5.1.5.4.2.8: TorqueMinimum
• 5.1.5.4.2.9: TorqueMinimumLimit
• 5.1.5.4.2.10: TorqueTarget
• 5.1.6: Service
• 5.1.6.1: DistanceToService
• 5.1.6.2: IsServiceDue
• 5.1.6.3: TimeToService
• 5.1.7: Driver
• 5.1.7.1: AttentiveProbability
• 5.1.7.2: DistractionLevel
• 5.1.7.3: FatigueLevel
• 5.1.7.4: HeartRate
• 5.1.7.5: IsEyesOnRoad
• 5.1.7.6: IsHandsOnWheel
• 5.1.8: Occupant
• 5.1.8.1: Row1
• 5.1.8.1.1: DriverSide
• 5.1.8.1.1.1: HeadPosition
• 5.1.8.1.1.1.1: Pitch
• 5.1.8.1.1.1.2: Roll
• 5.1.8.1.1.1.3: X
• 5.1.8.1.1.1.4: Y
• 5.1.8.1.1.1.5: Yaw
• 5.1.8.1.1.1.6: Z
• 5.1.8.1.1.2: Identifier
• 5.1.8.1.1.2.1: Issuer
• 5.1.8.1.1.2.2: Subject
• 5.1.8.1.1.3: MidEyeGaze
• 5.1.8.1.1.3.1: Azimuth
• 5.1.8.1.1.3.2: Elevation
• 5.1.8.1.2: Middle
• 5.1.8.1.2.1: HeadPosition
• 5.1.8.1.2.1.1: Pitch
• 5.1.8.1.2.1.2: Roll
• 5.1.8.1.2.1.3: X
• 5.1.8.1.2.1.4: Y
• 5.1.8.1.2.1.5: Yaw
• 5.1.8.1.2.1.6: Z
• 5.1.8.1.2.2: Identifier
• 5.1.8.1.2.2.1: Issuer
• 5.1.8.1.2.2.2: Subject
• 5.1.8.1.2.3: MidEyeGaze
• 5.1.8.1.2.3.1: Azimuth
• 5.1.8.1.2.3.2: Elevation
• 5.1.8.1.3: PassengerSide
• 5.1.8.1.3.1: HeadPosition
• 5.1.8.1.3.1.1: Pitch
• 5.1.8.1.3.1.2: Roll
• 5.1.8.1.3.1.3: X
• 5.1.8.1.3.1.4: Y
• 5.1.8.1.3.1.5: Yaw
• 5.1.8.1.3.1.6: Z
• 5.1.8.1.3.2: Identifier
• 5.1.8.1.3.2.1: Issuer
• 5.1.8.1.3.2.2: Subject
• 5.1.8.1.3.3: MidEyeGaze
• 5.1.8.1.3.3.1: Azimuth
• 5.1.8.1.3.3.2: Elevation
• 5.1.8.2: Row2
• 5.1.8.2.1: Middle
• 5.1.8.2.1.1: HeadPosition
• 5.1.8.2.1.1.1: Pitch
• 5.1.8.2.1.1.2: Roll
• 5.1.8.2.1.1.3: X
• 5.1.8.2.1.1.4: Y
• 5.1.8.2.1.1.5: Yaw
• 5.1.8.2.1.1.6: Z
• 5.1.8.2.1.2: Identifier
• 5.1.8.2.1.2.1: Issuer
• 5.1.8.2.1.2.2: Subject
• 5.1.8.2.1.3: MidEyeGaze
• 5.1.8.2.1.3.1: Azimuth
• 5.1.8.2.1.3.2: Elevation
• 5.1.8.2.2: PassengerSide
• 5.1.8.2.2.1: HeadPosition
• 5.1.8.2.2.1.1: Pitch
• 5.1.8.2.2.1.2: Roll
• 5.1.8.2.2.1.3: X
• 5.1.8.2.2.1.4: Y
• 5.1.8.2.2.1.5: Yaw
• 5.1.8.2.2.1.6: Z
• 5.1.8.2.2.2: Identifier
• 5.1.8.2.2.2.1: Issuer
• 5.1.8.2.2.2.2: Subject
• 5.1.8.2.2.3: MidEyeGaze
• 5.1.8.2.2.3.1: Azimuth
• 5.1.8.2.2.3.2: Elevation
• 5.1.8.2.3: DriverSide
• 5.1.8.2.3.1: HeadPosition
• 5.1.8.2.3.1.1: Pitch
• 5.1.8.2.3.1.2: Roll
• 5.1.8.2.3.1.3: X
• 5.1.8.2.3.1.4: Y
• 5.1.8.2.3.1.5: Yaw
• 5.1.8.2.3.1.6: Z
• 5.1.8.2.3.2: MidEyeGaze
• 5.1.8.2.3.2.1: Azimuth
• 5.1.8.2.3.2.2: Elevation
• 5.1.8.2.3.3: Identifier
• 5.1.8.2.3.3.1: Issuer
• 5.1.8.2.3.3.2: Subject
• 5.1.9: Chassis
• 5.1.9.1: Accelerator
• 5.1.9.1.1: PedalPosition
• 5.1.9.2: AxleCount
• 5.1.9.3: Brake
• 5.1.9.3.1: IsDriverEmergencyBrakingDetected
• 5.1.9.3.2: PedalPosition
• 5.1.9.4: ParkingBrake
• 5.1.9.4.1: IsAutoApplyEnabled
• 5.1.9.4.2: IsEngaged
• 5.1.9.5: SteeringWheel
• 5.1.9.5.1: Angle
• 5.1.9.5.2: Extension
• 5.1.9.5.3: HeatingCooling
• 5.1.9.5.4: Tilt
• 5.1.9.6: Axle
• 5.1.9.6.1: Row1
• 5.1.9.6.1.1: AxleWidth
• 5.1.9.6.1.2: SteeringAngle
• 5.1.9.6.1.3: TireAspectRatio
• 5.1.9.6.1.4: TireDiameter
• 5.1.9.6.1.5: TireWidth
• 5.1.9.6.1.6: TrackWidth
• 5.1.9.6.1.7: TreadWidth
• 5.1.9.6.1.8: Wheel
• 5.1.9.6.1.8.1: Left
• 5.1.9.6.1.8.1.1: AngularSpeed
• 5.1.9.6.1.8.1.2: Brake
• 5.1.9.6.1.8.1.2.1: FluidLevel
• 5.1.9.6.1.8.1.2.2: IsBrakesWorn
• 5.1.9.6.1.8.1.2.3: IsFluidLevelLow
• 5.1.9.6.1.8.1.2.4: PadWear
• 5.1.9.6.1.8.1.3: Speed
• 5.1.9.6.1.8.1.4: Tire
• 5.1.9.6.1.8.1.4.1: AirTemperature
• 5.1.9.6.1.8.1.4.2: IsPressureLow
• 5.1.9.6.1.8.1.4.3: Pressure
• 5.1.9.6.1.8.1.4.4: RubberTemperature
• 5.1.9.6.1.8.1.4.5: Temperature
• 5.1.9.6.1.8.2: Right
• 5.1.9.6.1.8.2.1: AngularSpeed
• 5.1.9.6.1.8.2.2: Brake
• 5.1.9.6.1.8.2.2.1: FluidLevel
• 5.1.9.6.1.8.2.2.2: IsBrakesWorn
• 5.1.9.6.1.8.2.2.3: IsFluidLevelLow
• 5.1.9.6.1.8.2.2.4: PadWear
• 5.1.9.6.1.8.2.3: Speed
• 5.1.9.6.1.8.2.4: Tire
• 5.1.9.6.1.8.2.4.1: AirTemperature
• 5.1.9.6.1.8.2.4.2: IsPressureLow
• 5.1.9.6.1.8.2.4.3: Pressure
• 5.1.9.6.1.8.2.4.4: RubberTemperature
• 5.1.9.6.1.8.2.4.5: Temperature
• 5.1.9.6.1.9: WheelCount
• 5.1.9.6.1.10: WheelDiameter
• 5.1.9.6.1.11: WheelWidth
• 5.1.9.6.2: Row2
• 5.1.9.6.2.1: Wheel
• 5.1.9.6.2.1.1: Left
• 5.1.9.6.2.1.1.1: AngularSpeed
• 5.1.9.6.2.1.1.2: Brake
• 5.1.9.6.2.1.1.2.1: FluidLevel
• 5.1.9.6.2.1.1.2.2: IsBrakesWorn
• 5.1.9.6.2.1.1.2.3: IsFluidLevelLow
• 5.1.9.6.2.1.1.2.4: PadWear
• 5.1.9.6.2.1.1.3: Speed
• 5.1.9.6.2.1.1.4: Tire
• 5.1.9.6.2.1.1.4.1: AirTemperature
• 5.1.9.6.2.1.1.4.2: IsPressureLow
• 5.1.9.6.2.1.1.4.3: Pressure
• 5.1.9.6.2.1.1.4.4: RubberTemperature
• 5.1.9.6.2.1.1.4.5: Temperature
• 5.1.9.6.2.1.2: Right
• 5.1.9.6.2.1.2.1: AngularSpeed
• 5.1.9.6.2.1.2.2: Brake
• 5.1.9.6.2.1.2.2.1: FluidLevel
• 5.1.9.6.2.1.2.2.2: IsBrakesWorn
• 5.1.9.6.2.1.2.2.3: IsFluidLevelLow
• 5.1.9.6.2.1.2.2.4: PadWear
• 5.1.9.6.2.1.2.3: Speed
• 5.1.9.6.2.1.2.4: Tire
• 5.1.9.6.2.1.2.4.1: AirTemperature
• 5.1.9.6.2.1.2.4.2: IsPressureLow
• 5.1.9.6.2.1.2.4.3: Pressure
• 5.1.9.6.2.1.2.4.4: RubberTemperature
• 5.1.9.6.2.1.2.4.5: Temperature
• 5.1.9.6.2.2: AxleWidth
• 5.1.9.6.2.3: SteeringAngle
• 5.1.9.6.2.4: TireAspectRatio
• 5.1.9.6.2.5: TireDiameter
• 5.1.9.6.2.6: TireWidth
• 5.1.9.6.2.7: TrackWidth
• 5.1.9.6.2.8: TreadWidth
• 5.1.9.6.2.9: WheelCount
• 5.1.9.6.2.10: WheelDiameter
• 5.1.9.6.2.11: WheelWidth
• 5.1.9.7: Wheelbase
• 5.1.10: ADAS
• 5.1.10.1: ABS
• 5.1.10.1.1: IsEnabled
• 5.1.10.1.2: IsEngaged
• 5.1.10.1.3: IsError
• 5.1.10.2: DMS
• 5.1.10.2.1: IsEnabled
• 5.1.10.2.2: IsError
• 5.1.10.2.3: IsWarning
• 5.1.10.3: EBA
• 5.1.10.3.1: IsEnabled
• 5.1.10.3.2: IsEngaged
• 5.1.10.3.3: IsError
• 5.1.10.4: EBD
• 5.1.10.4.1: IsEnabled
• 5.1.10.4.2: IsEngaged
• 5.1.10.4.3: IsError
• 5.1.10.5: ESC
• 5.1.10.5.1: IsEnabled
• 5.1.10.5.2: IsEngaged
• 5.1.10.5.3: IsError
• 5.1.10.5.4: IsStrongCrossWindDetected
• 5.1.10.5.5: RoadFriction
• 5.1.10.5.5.1: LowerBound
• 5.1.10.5.5.2: MostProbable
• 5.1.10.5.5.3: UpperBound
• 5.1.10.6: IsAutoPowerOptimize
• 5.1.10.7: PowerOptimizeLevel
• 5.1.10.8: TCS
• 5.1.10.8.1: IsEnabled
• 5.1.10.8.2: IsEngaged
• 5.1.10.8.3: IsError
• 5.1.10.9: ActiveAutonomyLevel
• 5.1.10.10: CruiseControl
• 5.1.10.10.1: AdaptiveDistanceSet
• 5.1.10.10.2: AdaptiveIntervalSet
• 5.1.10.10.3: IsActive
• 5.1.10.10.4: IsAdaptive
• 5.1.10.10.5: IsEnabled
• 5.1.10.10.6: IsError
• 5.1.10.10.7: SpeedSet
• 5.1.10.11: LaneDepartureDetection
• 5.1.10.11.1: IsEnabled
• 5.1.10.11.2: IsError
• 5.1.10.11.3: IsWarning
• 5.1.10.12: ObstacleDetection
• 5.1.10.12.1: Front
• 5.1.10.12.1.1: Center
• 5.1.10.12.1.1.1: Distance
• 5.1.10.12.1.1.2: IsEnabled
• 5.1.10.12.1.1.3: IsError
• 5.1.10.12.1.1.4: IsWarning
• 5.1.10.12.1.1.5: TimeGap
• 5.1.10.12.1.1.6: WarningType
• 5.1.10.12.1.2: Left
• 5.1.10.12.1.2.1: Distance
• 5.1.10.12.1.2.2: IsEnabled
• 5.1.10.12.1.2.3: IsError
• 5.1.10.12.1.2.4: IsWarning
• 5.1.10.12.1.2.5: TimeGap
• 5.1.10.12.1.2.6: WarningType
• 5.1.10.12.1.3: Right
• 5.1.10.12.1.3.1: Distance
• 5.1.10.12.1.3.2: IsEnabled
• 5.1.10.12.1.3.3: IsError
• 5.1.10.12.1.3.4: IsWarning
• 5.1.10.12.1.3.5: TimeGap
• 5.1.10.12.1.3.6: WarningType
• 5.1.10.12.2: Rear
• 5.1.10.12.2.1: Right
• 5.1.10.12.2.1.1: Distance
• 5.1.10.12.2.1.2: IsEnabled
• 5.1.10.12.2.1.3: IsError
• 5.1.10.12.2.1.4: IsWarning
• 5.1.10.12.2.1.5: TimeGap
• 5.1.10.12.2.1.6: WarningType
• 5.1.10.12.2.2: Center
• 5.1.10.12.2.2.1: Distance
• 5.1.10.12.2.2.2: IsEnabled
• 5.1.10.12.2.2.3: IsError
• 5.1.10.12.2.2.4: IsWarning
• 5.1.10.12.2.2.5: TimeGap
• 5.1.10.12.2.2.6: WarningType
• 5.1.10.12.2.3: Left
• 5.1.10.12.2.3.1: Distance
• 5.1.10.12.2.3.2: IsEnabled
• 5.1.10.12.2.3.3: IsError
• 5.1.10.12.2.3.4: IsWarning
• 5.1.10.12.2.3.5: TimeGap
• 5.1.10.12.2.3.6: WarningType
• 5.1.10.13: SupportedAutonomyLevel
• 5.1.11: Cabin
• 5.1.11.1: Convertible
• 5.1.11.1.1: Status
• 5.1.11.2: DriverPosition
• 5.1.11.3: IsAutoPowerOptimize
• 5.1.11.4: PowerOptimizeLevel
• 5.1.11.5: SeatPosCount
• 5.1.11.6: SeatRowCount
• 5.1.11.7: DoorCount
• 5.1.11.8: IsWindowChildLockEngaged
• 5.1.11.9: Seat
• 5.1.11.9.1: Row2
• 5.1.11.9.1.1: Middle
• 5.1.11.9.1.1.1: Airbag
• 5.1.11.9.1.1.1.1: IsDeployed
• 5.1.11.9.1.1.1.2: IsEnabled
• 5.1.11.9.1.1.2: Backrest
• 5.1.11.9.1.1.2.1: BottomLumbarSupport
• 5.1.11.9.1.1.2.2: HeatingCooling
• 5.1.11.9.1.1.2.3: IsLessLumbarSupportSwitchEngaged
• 5.1.11.9.1.1.2.4: IsLessSideBolsterSupportSwitchEngaged
• 5.1.11.9.1.1.2.5: IsLumbarDownSwitchEngaged
• 5.1.11.9.1.1.2.6: IsLumbarUpSwitchEngaged
• 5.1.11.9.1.1.2.7: IsMoreLumbarSupportSwitchEngaged
• 5.1.11.9.1.1.2.8: IsMoreSideBolsterSupportSwitchEngaged
• 5.1.11.9.1.1.2.9: IsReclineBackwardSwitchEngaged
• 5.1.11.9.1.1.2.10: IsReclineForwardSwitchEngaged
• 5.1.11.9.1.1.2.11: LumbarHeight
• 5.1.11.9.1.1.2.12: LumbarSupport
• 5.1.11.9.1.1.2.13: MidLumbarSupport
• 5.1.11.9.1.1.2.14: Recline
• 5.1.11.9.1.1.2.15: SideBolsterSupport
• 5.1.11.9.1.1.2.16: SideBolsterSupportLeft
• 5.1.11.9.1.1.2.17: SideBolsterSupportRight
• 5.1.11.9.1.1.2.18: TopLumbarSupport
• 5.1.11.9.1.1.2.19: UpperShoulderSupport
• 5.1.11.9.1.1.3: Headrest
• 5.1.11.9.1.1.3.1: Angle
• 5.1.11.9.1.1.3.2: Height
• 5.1.11.9.1.1.3.3: IsBackwardSwitchEngaged
• 5.1.11.9.1.1.3.4: IsDownSwitchEngaged
• 5.1.11.9.1.1.3.5: IsForwardSwitchEngaged
• 5.1.11.9.1.1.3.6: IsUpSwitchEngaged
• 5.1.11.9.1.1.4: HeatingCooling
• 5.1.11.9.1.1.5: Height
• 5.1.11.9.1.1.6: IsBackwardSwitchEngaged
• 5.1.11.9.1.1.7: IsBelted
• 5.1.11.9.1.1.8: IsCoolerSwitchEngaged
• 5.1.11.9.1.1.9: IsDecreaseMassageLevelSwitchEngaged
• 5.1.11.9.1.1.10: IsDownSwitchEngaged
• 5.1.11.9.1.1.11: IsForwardSwitchEngaged
• 5.1.11.9.1.1.12: IsIncreaseMassageLevelSwitchEngaged
• 5.1.11.9.1.1.13: IsTiltBackwardSwitchEngaged
• 5.1.11.9.1.1.14: IsTiltForwardSwitchEngaged
• 5.1.11.9.1.1.15: IsUpSwitchEngaged
• 5.1.11.9.1.1.16: IsWarmerSwitchEngaged
• 5.1.11.9.1.1.17: Massage
• 5.1.11.9.1.1.17.1: IsAvailable
• 5.1.11.9.1.1.17.2: Level
• 5.1.11.9.1.1.17.3: Status
• 5.1.11.9.1.1.17.4: SupportedTypes
• 5.1.11.9.1.1.17.5: TypeActive
• 5.1.11.9.1.1.18: NeckScarf
• 5.1.11.9.1.1.18.1: FanSpeed
• 5.1.11.9.1.1.18.2: HeatingCooling
• 5.1.11.9.1.1.19: OccupancyStatus
• 5.1.11.9.1.1.20: Position
• 5.1.11.9.1.1.21: SeatBeltHeight
• 5.1.11.9.1.1.22: Seating
• 5.1.11.9.1.1.22.1: HeatingCooling
• 5.1.11.9.1.1.22.2: IsBackwardSwitchEngaged
• 5.1.11.9.1.1.22.3: IsForwardSwitchEngaged
• 5.1.11.9.1.1.22.4: Length
• 5.1.11.9.1.1.22.5: SideBolsterSupportLeft
• 5.1.11.9.1.1.22.6: SideBolsterSupportRight
• 5.1.11.9.1.1.23: Tilt
• 5.1.11.9.1.2: PassengerSide
• 5.1.11.9.1.2.1: Airbag
• 5.1.11.9.1.2.1.1: IsDeployed
• 5.1.11.9.1.2.1.2: IsEnabled
• 5.1.11.9.1.2.2: Headrest
• 5.1.11.9.1.2.2.1: Angle
• 5.1.11.9.1.2.2.2: Height
• 5.1.11.9.1.2.2.3: IsBackwardSwitchEngaged
• 5.1.11.9.1.2.2.4: IsDownSwitchEngaged
• 5.1.11.9.1.2.2.5: IsForwardSwitchEngaged
• 5.1.11.9.1.2.2.6: IsUpSwitchEngaged
• 5.1.11.9.1.2.3: IsBackwardSwitchEngaged
• 5.1.11.9.1.2.4: IsCoolerSwitchEngaged
• 5.1.11.9.1.2.5: IsDecreaseMassageLevelSwitchEngaged
• 5.1.11.9.1.2.6: IsDownSwitchEngaged
• 5.1.11.9.1.2.7: IsForwardSwitchEngaged
• 5.1.11.9.1.2.8: IsIncreaseMassageLevelSwitchEngaged
• 5.1.11.9.1.2.9: IsTiltBackwardSwitchEngaged
• 5.1.11.9.1.2.10: IsTiltForwardSwitchEngaged
• 5.1.11.9.1.2.11: IsUpSwitchEngaged
• 5.1.11.9.1.2.12: IsWarmerSwitchEngaged
• 5.1.11.9.1.2.13: NeckScarf
• 5.1.11.9.1.2.13.1: FanSpeed
• 5.1.11.9.1.2.13.2: HeatingCooling
• 5.1.11.9.1.2.14: Seating
• 5.1.11.9.1.2.14.1: HeatingCooling
• 5.1.11.9.1.2.14.2: IsBackwardSwitchEngaged
• 5.1.11.9.1.2.14.3: IsForwardSwitchEngaged
• 5.1.11.9.1.2.14.4: Length
• 5.1.11.9.1.2.14.5: SideBolsterSupportLeft
• 5.1.11.9.1.2.14.6: SideBolsterSupportRight
• 5.1.11.9.1.2.15: Backrest
• 5.1.11.9.1.2.15.1: BottomLumbarSupport
• 5.1.11.9.1.2.15.2: IsLessLumbarSupportSwitchEngaged
• 5.1.11.9.1.2.15.3: IsLessSideBolsterSupportSwitchEngaged
• 5.1.11.9.1.2.15.4: IsLumbarDownSwitchEngaged
• 5.1.11.9.1.2.15.5: IsLumbarUpSwitchEngaged
• 5.1.11.9.1.2.15.6: IsMoreLumbarSupportSwitchEngaged
• 5.1.11.9.1.2.15.7: IsMoreSideBolsterSupportSwitchEngaged
• 5.1.11.9.1.2.15.8: IsReclineBackwardSwitchEngaged
• 5.1.11.9.1.2.15.9: IsReclineForwardSwitchEngaged
• 5.1.11.9.1.2.15.10: LumbarHeight
• 5.1.11.9.1.2.15.11: SideBolsterSupport
• 5.1.11.9.1.2.15.12: SideBolsterSupportLeft
• 5.1.11.9.1.2.15.13: SideBolsterSupportRight
• 5.1.11.9.1.2.15.14: UpperShoulderSupport
• 5.1.11.9.1.2.15.15: HeatingCooling
• 5.1.11.9.1.2.15.16: LumbarSupport
• 5.1.11.9.1.2.15.17: MidLumbarSupport
• 5.1.11.9.1.2.15.18: Recline
• 5.1.11.9.1.2.15.19: TopLumbarSupport
• 5.1.11.9.1.2.16: HeatingCooling
• 5.1.11.9.1.2.17: Height
• 5.1.11.9.1.2.18: IsBelted
• 5.1.11.9.1.2.19: Massage
• 5.1.11.9.1.2.19.1: IsAvailable
• 5.1.11.9.1.2.19.2: Level
• 5.1.11.9.1.2.19.3: Status
• 5.1.11.9.1.2.19.4: SupportedTypes
• 5.1.11.9.1.2.19.5: TypeActive
• 5.1.11.9.1.2.20: OccupancyStatus
• 5.1.11.9.1.2.21: Position
• 5.1.11.9.1.2.22: SeatBeltHeight
• 5.1.11.9.1.2.23: Tilt
• 5.1.11.9.1.3: DriverSide
• 5.1.11.9.1.3.1: IsBackwardSwitchEngaged
• 5.1.11.9.1.3.2: IsCoolerSwitchEngaged
• 5.1.11.9.1.3.3: IsDecreaseMassageLevelSwitchEngaged
• 5.1.11.9.1.3.4: IsDownSwitchEngaged
• 5.1.11.9.1.3.5: IsForwardSwitchEngaged
• 5.1.11.9.1.3.6: IsIncreaseMassageLevelSwitchEngaged
• 5.1.11.9.1.3.7: IsTiltBackwardSwitchEngaged
• 5.1.11.9.1.3.8: IsTiltForwardSwitchEngaged
• 5.1.11.9.1.3.9: IsUpSwitchEngaged
• 5.1.11.9.1.3.10: IsWarmerSwitchEngaged
• 5.1.11.9.1.3.11: NeckScarf
• 5.1.11.9.1.3.11.1: FanSpeed
• 5.1.11.9.1.3.11.2: HeatingCooling
• 5.1.11.9.1.3.12: Airbag
• 5.1.11.9.1.3.12.1: IsDeployed
• 5.1.11.9.1.3.12.2: IsEnabled
• 5.1.11.9.1.3.13: Backrest
• 5.1.11.9.1.3.13.1: BottomLumbarSupport
• 5.1.11.9.1.3.13.2: HeatingCooling
• 5.1.11.9.1.3.13.3: IsLessLumbarSupportSwitchEngaged
• 5.1.11.9.1.3.13.4: IsLessSideBolsterSupportSwitchEngaged
• 5.1.11.9.1.3.13.5: IsLumbarDownSwitchEngaged
• 5.1.11.9.1.3.13.6: IsLumbarUpSwitchEngaged
• 5.1.11.9.1.3.13.7: IsMoreLumbarSupportSwitchEngaged
• 5.1.11.9.1.3.13.8: IsMoreSideBolsterSupportSwitchEngaged
• 5.1.11.9.1.3.13.9: IsReclineBackwardSwitchEngaged
• 5.1.11.9.1.3.13.10: IsReclineForwardSwitchEngaged
• 5.1.11.9.1.3.13.11: LumbarHeight
• 5.1.11.9.1.3.13.12: LumbarSupport
• 5.1.11.9.1.3.13.13: MidLumbarSupport
• 5.1.11.9.1.3.13.14: Recline
• 5.1.11.9.1.3.13.15: SideBolsterSupport
• 5.1.11.9.1.3.13.16: SideBolsterSupportLeft
• 5.1.11.9.1.3.13.17: SideBolsterSupportRight
• 5.1.11.9.1.3.13.18: TopLumbarSupport
• 5.1.11.9.1.3.13.19: UpperShoulderSupport
• 5.1.11.9.1.3.14: Headrest
• 5.1.11.9.1.3.14.1: Angle
• 5.1.11.9.1.3.14.2: Height
• 5.1.11.9.1.3.14.3: IsBackwardSwitchEngaged
• 5.1.11.9.1.3.14.4: IsDownSwitchEngaged
• 5.1.11.9.1.3.14.5: IsForwardSwitchEngaged
• 5.1.11.9.1.3.14.6: IsUpSwitchEngaged
• 5.1.11.9.1.3.15: HeatingCooling
• 5.1.11.9.1.3.16: Height
• 5.1.11.9.1.3.17: IsBelted
• 5.1.11.9.1.3.18: Massage
• 5.1.11.9.1.3.18.1: IsAvailable
• 5.1.11.9.1.3.18.2: Level
• 5.1.11.9.1.3.18.3: Status
• 5.1.11.9.1.3.18.4: SupportedTypes
• 5.1.11.9.1.3.18.5: TypeActive
• 5.1.11.9.1.3.19: OccupancyStatus
• 5.1.11.9.1.3.20: Position
• 5.1.11.9.1.3.21: SeatBeltHeight
• 5.1.11.9.1.3.22: Seating
• 5.1.11.9.1.3.22.1: HeatingCooling
• 5.1.11.9.1.3.22.2: IsBackwardSwitchEngaged
• 5.1.11.9.1.3.22.3: IsForwardSwitchEngaged
• 5.1.11.9.1.3.22.4: Length
• 5.1.11.9.1.3.22.5: SideBolsterSupportLeft
• 5.1.11.9.1.3.22.6: SideBolsterSupportRight
• 5.1.11.9.1.3.23: Tilt
• 5.1.11.9.2: Row1
• 5.1.11.9.2.1: Middle
• 5.1.11.9.2.1.1: Airbag
• 5.1.11.9.2.1.1.1: IsDeployed
• 5.1.11.9.2.1.1.2: IsEnabled
• 5.1.11.9.2.1.2: Backrest
• 5.1.11.9.2.1.2.1: BottomLumbarSupport
• 5.1.11.9.2.1.2.2: HeatingCooling
• 5.1.11.9.2.1.2.3: IsLessLumbarSupportSwitchEngaged
• 5.1.11.9.2.1.2.4: IsLessSideBolsterSupportSwitchEngaged
• 5.1.11.9.2.1.2.5: IsLumbarDownSwitchEngaged
• 5.1.11.9.2.1.2.6: IsLumbarUpSwitchEngaged
• 5.1.11.9.2.1.2.7: IsMoreLumbarSupportSwitchEngaged
• 5.1.11.9.2.1.2.8: IsMoreSideBolsterSupportSwitchEngaged
• 5.1.11.9.2.1.2.9: IsReclineBackwardSwitchEngaged
• 5.1.11.9.2.1.2.10: IsReclineForwardSwitchEngaged
• 5.1.11.9.2.1.2.11: LumbarHeight
• 5.1.11.9.2.1.2.12: LumbarSupport
• 5.1.11.9.2.1.2.13: MidLumbarSupport
• 5.1.11.9.2.1.2.14: Recline
• 5.1.11.9.2.1.2.15: SideBolsterSupport
• 5.1.11.9.2.1.2.16: SideBolsterSupportLeft
• 5.1.11.9.2.1.2.17: SideBolsterSupportRight
• 5.1.11.9.2.1.2.18: TopLumbarSupport
• 5.1.11.9.2.1.2.19: UpperShoulderSupport
• 5.1.11.9.2.1.3: Headrest
• 5.1.11.9.2.1.3.1: Angle
• 5.1.11.9.2.1.3.2: Height
• 5.1.11.9.2.1.3.3: IsBackwardSwitchEngaged
• 5.1.11.9.2.1.3.4: IsDownSwitchEngaged
• 5.1.11.9.2.1.3.5: IsForwardSwitchEngaged
• 5.1.11.9.2.1.3.6: IsUpSwitchEngaged
• 5.1.11.9.2.1.4: HeatingCooling
• 5.1.11.9.2.1.5: Height
• 5.1.11.9.2.1.6: IsBackwardSwitchEngaged
• 5.1.11.9.2.1.7: IsBelted
• 5.1.11.9.2.1.8: IsCoolerSwitchEngaged
• 5.1.11.9.2.1.9: IsDecreaseMassageLevelSwitchEngaged
• 5.1.11.9.2.1.10: IsDownSwitchEngaged
• 5.1.11.9.2.1.11: IsForwardSwitchEngaged
• 5.1.11.9.2.1.12: IsIncreaseMassageLevelSwitchEngaged
• 5.1.11.9.2.1.13: IsTiltBackwardSwitchEngaged
• 5.1.11.9.2.1.14: IsTiltForwardSwitchEngaged
• 5.1.11.9.2.1.15: IsUpSwitchEngaged
• 5.1.11.9.2.1.16: IsWarmerSwitchEngaged
• 5.1.11.9.2.1.17: Massage
• 5.1.11.9.2.1.17.1: IsAvailable
• 5.1.11.9.2.1.17.2: Level
• 5.1.11.9.2.1.17.3: Status
• 5.1.11.9.2.1.17.4: SupportedTypes
• 5.1.11.9.2.1.17.5: TypeActive
• 5.1.11.9.2.1.18: NeckScarf
• 5.1.11.9.2.1.18.1: FanSpeed
• 5.1.11.9.2.1.18.2: HeatingCooling
• 5.1.11.9.2.1.19: OccupancyStatus
• 5.1.11.9.2.1.20: Position
• 5.1.11.9.2.1.21: SeatBeltHeight
• 5.1.11.9.2.1.22: Seating
• 5.1.11.9.2.1.22.1: HeatingCooling
• 5.1.11.9.2.1.22.2: IsBackwardSwitchEngaged
• 5.1.11.9.2.1.22.3: IsForwardSwitchEngaged
• 5.1.11.9.2.1.22.4: Length
• 5.1.11.9.2.1.22.5: SideBolsterSupportLeft
• 5.1.11.9.2.1.22.6: SideBolsterSupportRight
• 5.1.11.9.2.1.23: Tilt
• 5.1.11.9.2.2: PassengerSide
• 5.1.11.9.2.2.1: Airbag
• 5.1.11.9.2.2.1.1: IsDeployed
• 5.1.11.9.2.2.1.2: IsEnabled
• 5.1.11.9.2.2.2: Headrest
• 5.1.11.9.2.2.2.1: Angle
• 5.1.11.9.2.2.2.2: Height
• 5.1.11.9.2.2.2.3: IsBackwardSwitchEngaged
• 5.1.11.9.2.2.2.4: IsDownSwitchEngaged
• 5.1.11.9.2.2.2.5: IsForwardSwitchEngaged
• 5.1.11.9.2.2.2.6: IsUpSwitchEngaged
• 5.1.11.9.2.2.3: IsBackwardSwitchEngaged
• 5.1.11.9.2.2.4: IsCoolerSwitchEngaged
• 5.1.11.9.2.2.5: IsDecreaseMassageLevelSwitchEngaged
• 5.1.11.9.2.2.6: IsDownSwitchEngaged
• 5.1.11.9.2.2.7: IsForwardSwitchEngaged
• 5.1.11.9.2.2.8: IsIncreaseMassageLevelSwitchEngaged
• 5.1.11.9.2.2.9: IsTiltBackwardSwitchEngaged
• 5.1.11.9.2.2.10: IsTiltForwardSwitchEngaged
• 5.1.11.9.2.2.11: IsUpSwitchEngaged
• 5.1.11.9.2.2.12: IsWarmerSwitchEngaged
• 5.1.11.9.2.2.13: NeckScarf
• 5.1.11.9.2.2.13.1: FanSpeed
• 5.1.11.9.2.2.13.2: HeatingCooling
• 5.1.11.9.2.2.14: Seating
• 5.1.11.9.2.2.14.1: HeatingCooling
• 5.1.11.9.2.2.14.2: IsBackwardSwitchEngaged
• 5.1.11.9.2.2.14.3: IsForwardSwitchEngaged
• 5.1.11.9.2.2.14.4: Length
• 5.1.11.9.2.2.14.5: SideBolsterSupportLeft
• 5.1.11.9.2.2.14.6: SideBolsterSupportRight
• 5.1.11.9.2.2.15: Backrest
• 5.1.11.9.2.2.15.1: BottomLumbarSupport
• 5.1.11.9.2.2.15.2: IsLessLumbarSupportSwitchEngaged
• 5.1.11.9.2.2.15.3: IsLessSideBolsterSupportSwitchEngaged
• 5.1.11.9.2.2.15.4: IsLumbarDownSwitchEngaged
• 5.1.11.9.2.2.15.5: IsLumbarUpSwitchEngaged
• 5.1.11.9.2.2.15.6: IsMoreLumbarSupportSwitchEngaged
• 5.1.11.9.2.2.15.7: IsMoreSideBolsterSupportSwitchEngaged
• 5.1.11.9.2.2.15.8: IsReclineBackwardSwitchEngaged
• 5.1.11.9.2.2.15.9: IsReclineForwardSwitchEngaged
• 5.1.11.9.2.2.15.10: LumbarHeight
• 5.1.11.9.2.2.15.11: MidLumbarSupport
• 5.1.11.9.2.2.15.12: SideBolsterSupport
• 5.1.11.9.2.2.15.13: SideBolsterSupportLeft
• 5.1.11.9.2.2.15.14: SideBolsterSupportRight
• 5.1.11.9.2.2.15.15: TopLumbarSupport
• 5.1.11.9.2.2.15.16: UpperShoulderSupport
• 5.1.11.9.2.2.15.17: HeatingCooling
• 5.1.11.9.2.2.15.18: LumbarSupport
• 5.1.11.9.2.2.15.19: Recline
• 5.1.11.9.2.2.16: HeatingCooling
• 5.1.11.9.2.2.17: Height
• 5.1.11.9.2.2.18: IsBelted
• 5.1.11.9.2.2.19: Massage
• 5.1.11.9.2.2.19.1: IsAvailable
• 5.1.11.9.2.2.19.2: Level
• 5.1.11.9.2.2.19.3: Status
• 5.1.11.9.2.2.19.4: SupportedTypes
• 5.1.11.9.2.2.19.5: TypeActive
• 5.1.11.9.2.2.20: OccupancyStatus
• 5.1.11.9.2.2.21: Position
• 5.1.11.9.2.2.22: SeatBeltHeight
• 5.1.11.9.2.2.23: Tilt
• 5.1.11.9.2.3: DriverSide
• 5.1.11.9.2.3.1: Airbag
• 5.1.11.9.2.3.1.1: IsDeployed
• 5.1.11.9.2.3.1.2: IsEnabled
• 5.1.11.9.2.3.2: IsBackwardSwitchEngaged
• 5.1.11.9.2.3.3: IsCoolerSwitchEngaged
• 5.1.11.9.2.3.4: IsDecreaseMassageLevelSwitchEngaged
• 5.1.11.9.2.3.5: IsDownSwitchEngaged
• 5.1.11.9.2.3.6: IsForwardSwitchEngaged
• 5.1.11.9.2.3.7: IsIncreaseMassageLevelSwitchEngaged
• 5.1.11.9.2.3.8: IsTiltBackwardSwitchEngaged
• 5.1.11.9.2.3.9: IsTiltForwardSwitchEngaged
• 5.1.11.9.2.3.10: IsUpSwitchEngaged
• 5.1.11.9.2.3.11: IsWarmerSwitchEngaged
• 5.1.11.9.2.3.12: NeckScarf
• 5.1.11.9.2.3.12.1: FanSpeed
• 5.1.11.9.2.3.12.2: HeatingCooling
• 5.1.11.9.2.3.13: Backrest
• 5.1.11.9.2.3.13.1: BottomLumbarSupport
• 5.1.11.9.2.3.13.2: HeatingCooling
• 5.1.11.9.2.3.13.3: IsLessLumbarSupportSwitchEngaged
• 5.1.11.9.2.3.13.4: IsLessSideBolsterSupportSwitchEngaged
• 5.1.11.9.2.3.13.5: IsLumbarDownSwitchEngaged
• 5.1.11.9.2.3.13.6: IsLumbarUpSwitchEngaged
• 5.1.11.9.2.3.13.7: IsMoreLumbarSupportSwitchEngaged
• 5.1.11.9.2.3.13.8: IsMoreSideBolsterSupportSwitchEngaged
• 5.1.11.9.2.3.13.9: IsReclineBackwardSwitchEngaged
• 5.1.11.9.2.3.13.10: IsReclineForwardSwitchEngaged
• 5.1.11.9.2.3.13.11: LumbarHeight
• 5.1.11.9.2.3.13.12: LumbarSupport
• 5.1.11.9.2.3.13.13: MidLumbarSupport
• 5.1.11.9.2.3.13.14: Recline
• 5.1.11.9.2.3.13.15: SideBolsterSupport
• 5.1.11.9.2.3.13.16: SideBolsterSupportLeft
• 5.1.11.9.2.3.13.17: SideBolsterSupportRight
• 5.1.11.9.2.3.13.18: TopLumbarSupport
• 5.1.11.9.2.3.13.19: UpperShoulderSupport
• 5.1.11.9.2.3.14: Headrest
• 5.1.11.9.2.3.14.1: Angle
• 5.1.11.9.2.3.14.2: Height
• 5.1.11.9.2.3.14.3: IsBackwardSwitchEngaged
• 5.1.11.9.2.3.14.4: IsDownSwitchEngaged
• 5.1.11.9.2.3.14.5: IsForwardSwitchEngaged
• 5.1.11.9.2.3.14.6: IsUpSwitchEngaged
• 5.1.11.9.2.3.15: HeatingCooling
• 5.1.11.9.2.3.16: Height
• 5.1.11.9.2.3.17: IsBelted
• 5.1.11.9.2.3.18: Massage
• 5.1.11.9.2.3.18.1: IsAvailable
• 5.1.11.9.2.3.18.2: Level
• 5.1.11.9.2.3.18.3: Status
• 5.1.11.9.2.3.18.4: SupportedTypes
• 5.1.11.9.2.3.18.5: TypeActive
• 5.1.11.9.2.3.19: OccupancyStatus
• 5.1.11.9.2.3.20: Position
• 5.1.11.9.2.3.21: SeatBeltHeight
• 5.1.11.9.2.3.22: Seating
• 5.1.11.9.2.3.22.1: HeatingCooling
• 5.1.11.9.2.3.22.2: IsBackwardSwitchEngaged
• 5.1.11.9.2.3.22.3: IsForwardSwitchEngaged
• 5.1.11.9.2.3.22.4: Length
• 5.1.11.9.2.3.22.5: SideBolsterSupportLeft
• 5.1.11.9.2.3.22.6: SideBolsterSupportRight
• 5.1.11.9.2.3.23: Tilt
• 5.1.11.10: Door
• 5.1.11.10.1: Row2
• 5.1.11.10.1.1: DriverSide
• 5.1.11.10.1.1.1: IsChildLockActive
• 5.1.11.10.1.1.2: IsLocked
• 5.1.11.10.1.1.3: IsOpen
• 5.1.11.10.1.1.4: Position
• 5.1.11.10.1.1.5: Shade
• 5.1.11.10.1.1.5.1: IsOpen
• 5.1.11.10.1.1.5.2: Position
• 5.1.11.10.1.1.5.3: Switch
• 5.1.11.10.1.1.6: Switch
• 5.1.11.10.1.1.7: Window
• 5.1.11.10.1.1.7.1: IsOpen
• 5.1.11.10.1.1.7.2: Position
• 5.1.11.10.1.1.7.3: Switch
• 5.1.11.10.1.2: PassengerSide
• 5.1.11.10.1.2.1: IsChildLockActive
• 5.1.11.10.1.2.2: IsLocked
• 5.1.11.10.1.2.3: IsOpen
• 5.1.11.10.1.2.4: Position
• 5.1.11.10.1.2.5: Shade
• 5.1.11.10.1.2.5.1: IsOpen
• 5.1.11.10.1.2.5.2: Position
• 5.1.11.10.1.2.5.3: Switch
• 5.1.11.10.1.2.6: Switch
• 5.1.11.10.1.2.7: Window
• 5.1.11.10.1.2.7.1: IsOpen
• 5.1.11.10.1.2.7.2: Position
• 5.1.11.10.1.2.7.3: Switch
• 5.1.11.10.2: Row1
• 5.1.11.10.2.1: PassengerSide
• 5.1.11.10.2.1.1: IsChildLockActive
• 5.1.11.10.2.1.2: IsLocked
• 5.1.11.10.2.1.3: IsOpen
• 5.1.11.10.2.1.4: Position
• 5.1.11.10.2.1.5: Shade
• 5.1.11.10.2.1.5.1: IsOpen
• 5.1.11.10.2.1.5.2: Position
• 5.1.11.10.2.1.5.3: Switch
• 5.1.11.10.2.1.6: Switch
• 5.1.11.10.2.1.7: Window
• 5.1.11.10.2.1.7.1: IsOpen
• 5.1.11.10.2.1.7.2: Position
• 5.1.11.10.2.1.7.3: Switch
• 5.1.11.10.2.2: DriverSide
• 5.1.11.10.2.2.1: IsChildLockActive
• 5.1.11.10.2.2.2: IsLocked
• 5.1.11.10.2.2.3: IsOpen
• 5.1.11.10.2.2.4: Position
• 5.1.11.10.2.2.5: Shade
• 5.1.11.10.2.2.5.1: IsOpen
• 5.1.11.10.2.2.5.2: Position
• 5.1.11.10.2.2.5.3: Switch
• 5.1.11.10.2.2.6: Switch
• 5.1.11.10.2.2.7: Window
• 5.1.11.10.2.2.7.1: IsOpen
• 5.1.11.10.2.2.7.2: Position
• 5.1.11.10.2.2.7.3: Switch
• 5.1.11.11: Light
• 5.1.11.11.1: AmbientLight
• 5.1.11.11.1.1: Row1
• 5.1.11.11.1.1.1: DriverSide
• 5.1.11.11.1.1.1.1: Color
• 5.1.11.11.1.1.1.2: Intensity
• 5.1.11.11.1.1.1.3: IsLightOn
• 5.1.11.11.1.1.2: PassengerSide
• 5.1.11.11.1.1.2.1: Color
• 5.1.11.11.1.1.2.2: Intensity
• 5.1.11.11.1.1.2.3: IsLightOn
• 5.1.11.11.1.2: Row2
• 5.1.11.11.1.2.1: DriverSide
• 5.1.11.11.1.2.1.1: Color
• 5.1.11.11.1.2.1.2: Intensity
• 5.1.11.11.1.2.1.3: IsLightOn
• 5.1.11.11.1.2.2: PassengerSide
• 5.1.11.11.1.2.2.1: Color
• 5.1.11.11.1.2.2.2: Intensity
• 5.1.11.11.1.2.2.3: IsLightOn
• 5.1.11.11.2: InteractiveLightBar
• 5.1.11.11.2.1: Color
• 5.1.11.11.2.2: Effect
• 5.1.11.11.2.3: Intensity
• 5.1.11.11.2.4: IsLightOn
• 5.1.11.11.3: IsDomeOn
• 5.1.11.11.4: IsGloveBoxOn
• 5.1.11.11.5: PerceivedAmbientLight
• 5.1.11.11.6: Spotlight
• 5.1.11.11.6.1: Row1
• 5.1.11.11.6.1.1: DriverSide
• 5.1.11.11.6.1.1.1: Color
• 5.1.11.11.6.1.1.2: Intensity
• 5.1.11.11.6.1.1.3: IsLightOn
• 5.1.11.11.6.1.2: PassengerSide
• 5.1.11.11.6.1.2.1: Color
• 5.1.11.11.6.1.2.2: Intensity
• 5.1.11.11.6.1.2.3: IsLightOn
• 5.1.11.11.6.2: Row2
• 5.1.11.11.6.2.1: DriverSide
• 5.1.11.11.6.2.1.1: Color
• 5.1.11.11.6.2.1.2: Intensity
• 5.1.11.11.6.2.1.3: IsLightOn
• 5.1.11.11.6.2.2: PassengerSide
• 5.1.11.11.6.2.2.1: Color
• 5.1.11.11.6.2.2.2: Intensity
• 5.1.11.11.6.2.2.3: IsLightOn
• 5.1.11.11.6.3: Row3
• 5.1.11.11.6.3.1: DriverSide
• 5.1.11.11.6.3.1.1: Color
• 5.1.11.11.6.3.1.2: Intensity
• 5.1.11.11.6.3.1.3: IsLightOn
• 5.1.11.11.6.3.2: PassengerSide
• 5.1.11.11.6.3.2.1: Color
• 5.1.11.11.6.3.2.2: Intensity
• 5.1.11.11.6.3.2.3: IsLightOn
• 5.1.11.11.6.4: Row4
• 5.1.11.11.6.4.1: DriverSide
• 5.1.11.11.6.4.1.1: Color
• 5.1.11.11.6.4.1.2: Intensity
• 5.1.11.11.6.4.1.3: IsLightOn
• 5.1.11.11.6.4.2: PassengerSide
• 5.1.11.11.6.4.2.1: Color
• 5.1.11.11.6.4.2.2: Intensity
• 5.1.11.11.6.4.2.3: IsLightOn
• 5.1.11.12: RearviewMirror
• 5.1.11.12.1: DimmingLevel
• 5.1.11.13: Sunroof
• 5.1.11.13.1: Position
• 5.1.11.13.2: Shade
• 5.1.11.13.2.1: IsOpen
• 5.1.11.13.2.2: Position
• 5.1.11.13.2.3: Switch
• 5.1.11.13.3: Switch
• 5.1.11.14: HVAC
• 5.1.11.14.1: AmbientAirTemperature
• 5.1.11.14.2: IsAirConditioningActive
• 5.1.11.14.3: IsAutoPowerOptimize
• 5.1.11.14.4: IsFrontDefrosterActive
• 5.1.11.14.5: IsRearDefrosterActive
• 5.1.11.14.6: IsRecirculationActive
• 5.1.11.14.7: PowerOptimizeLevel
• 5.1.11.14.8: Station
• 5.1.11.14.8.1: Row1
• 5.1.11.14.8.1.1: Driver
• 5.1.11.14.8.1.1.1: AirDistribution
• 5.1.11.14.8.1.1.2: FanSpeed
• 5.1.11.14.8.1.1.3: Temperature
• 5.1.11.14.8.1.2: Passenger
• 5.1.11.14.8.1.2.1: AirDistribution
• 5.1.11.14.8.1.2.2: FanSpeed
• 5.1.11.14.8.1.2.3: Temperature
• 5.1.11.14.8.2: Row2
• 5.1.11.14.8.2.1: Driver
• 5.1.11.14.8.2.1.1: AirDistribution
• 5.1.11.14.8.2.1.2: FanSpeed
• 5.1.11.14.8.2.1.3: Temperature
• 5.1.11.14.8.2.2: Passenger
• 5.1.11.14.8.2.2.1: AirDistribution
• 5.1.11.14.8.2.2.2: FanSpeed
• 5.1.11.14.8.2.2.3: Temperature
• 5.1.11.14.8.3: Row3
• 5.1.11.14.8.3.1: Driver
• 5.1.11.14.8.3.1.1: AirDistribution
• 5.1.11.14.8.3.1.2: FanSpeed
• 5.1.11.14.8.3.1.3: Temperature
• 5.1.11.14.8.3.2: Passenger
• 5.1.11.14.8.3.2.1: AirDistribution
• 5.1.11.14.8.3.2.2: FanSpeed
• 5.1.11.14.8.3.2.3: Temperature
• 5.1.11.14.8.4: Row4
• 5.1.11.14.8.4.1: Driver
• 5.1.11.14.8.4.1.1: AirDistribution
• 5.1.11.14.8.4.1.2: FanSpeed
• 5.1.11.14.8.4.1.3: Temperature
• 5.1.11.14.8.4.2: Passenger
• 5.1.11.14.8.4.2.1: AirDistribution
• 5.1.11.14.8.4.2.2: FanSpeed
• 5.1.11.14.8.4.2.3: Temperature
• 5.1.11.15: Infotainment
• 5.1.11.15.1: IsAutoPowerOptimize
• 5.1.11.15.2: PowerOptimizeLevel
• 5.1.11.15.3: SmartphoneProjection
• 5.1.11.15.3.1: Active
• 5.1.11.15.3.2: Source
• 5.1.11.15.3.3: SupportedMode
• 5.1.11.15.4: SmartphoneScreenMirroring
• 5.1.11.15.4.1: Active
• 5.1.11.15.4.2: Source
• 5.1.11.15.5: HMI
• 5.1.11.15.5.1: DisplayOffDuration
• 5.1.11.15.5.2: Brightness
• 5.1.11.15.5.3: CurrentLanguage
• 5.1.11.15.5.4: DateFormat
• 5.1.11.15.5.5: DayNightMode
• 5.1.11.15.5.6: DistanceUnit
• 5.1.11.15.5.7: EVEconomyUnits
• 5.1.11.15.5.8: EVEnergyUnits
• 5.1.11.15.5.9: FontSize
• 5.1.11.15.5.10: FuelEconomyUnits
• 5.1.11.15.5.11: FuelVolumeUnit
• 5.1.11.15.5.12: IsScreenAlwaysOn
• 5.1.11.15.5.13: LastActionTime
• 5.1.11.15.5.14: SpeedUnit
• 5.1.11.15.5.15: TemperatureUnit
• 5.1.11.15.5.16: TimeFormat
• 5.1.11.15.5.17: TirePressureUnit
• 5.1.11.15.6: Media
• 5.1.11.15.6.1: Action
• 5.1.11.15.6.2: DeclinedURI
• 5.1.11.15.6.3: Played
• 5.1.11.15.6.3.1: Album
• 5.1.11.15.6.3.2: Artist
• 5.1.11.15.6.3.3: Genre
• 5.1.11.15.6.3.4: PlaybackRate
• 5.1.11.15.6.3.5: Source
• 5.1.11.15.6.3.6: Track
• 5.1.11.15.6.3.7: URI
• 5.1.11.15.6.4: SelectedURI
• 5.1.11.15.6.5: Volume
• 5.1.11.15.7: Navigation
• 5.1.11.15.7.1: DestinationSet
• 5.1.11.15.7.1.1: Latitude
• 5.1.11.15.7.1.2: Longitude
• 5.1.11.15.7.2: GuidanceVoice
• 5.1.11.15.7.3: Map
• 5.1.11.15.7.3.1: IsAutoScaleModeUsed
• 5.1.11.15.7.4: Mute
• 5.1.11.15.7.5: Volume
• 5.1.11.16: RearShade
• 5.1.11.16.1: IsOpen
• 5.1.11.16.2: Position
• 5.1.11.16.3: Switch
• 5.1.12: Body
• 5.1.12.1: IsAutoPowerOptimize
• 5.1.12.2: PowerOptimizeLevel
• 5.1.12.3: RearMainSpoilerPosition
• 5.1.12.4: Lights
• 5.1.12.4.1: Backup
• 5.1.12.4.1.1: IsDefect
• 5.1.12.4.1.2: IsOn
• 5.1.12.4.2: Beam
• 5.1.12.4.2.1: High
• 5.1.12.4.2.1.1: IsDefect
• 5.1.12.4.2.1.2: IsOn
• 5.1.12.4.2.2: Low
• 5.1.12.4.2.2.1: IsDefect
• 5.1.12.4.2.2.2: IsOn
• 5.1.12.4.3: Brake
• 5.1.12.4.3.1: IsActive
• 5.1.12.4.3.2: IsDefect
• 5.1.12.4.4: DirectionIndicator
• 5.1.12.4.4.1: Left
• 5.1.12.4.4.1.1: IsDefect
• 5.1.12.4.4.1.2: IsSignaling
• 5.1.12.4.4.2: Right
• 5.1.12.4.4.2.1: IsDefect
• 5.1.12.4.4.2.2: IsSignaling
• 5.1.12.4.5: Fog
• 5.1.12.4.5.1: Front
• 5.1.12.4.5.1.1: IsDefect
• 5.1.12.4.5.1.2: IsOn
• 5.1.12.4.5.2: Rear
• 5.1.12.4.5.2.1: IsDefect
• 5.1.12.4.5.2.2: IsOn
• 5.1.12.4.6: Hazard
• 5.1.12.4.6.1: IsDefect
• 5.1.12.4.6.2: IsSignaling
• 5.1.12.4.7: IsHighBeamSwitchOn
• 5.1.12.4.8: LicensePlate
• 5.1.12.4.8.1: IsDefect
• 5.1.12.4.8.2: IsOn
• 5.1.12.4.9: LightSwitch
• 5.1.12.4.10: Parking
• 5.1.12.4.10.1: IsDefect
• 5.1.12.4.10.2: IsOn
• 5.1.12.4.11: Running
• 5.1.12.4.11.1: IsDefect
• 5.1.12.4.11.2: IsOn
• 5.1.12.5: Mirrors
• 5.1.12.5.1: DriverSide
• 5.1.12.5.1.1: IsFolded
• 5.1.12.5.1.2: IsHeatingOn
• 5.1.12.5.1.3: IsLocked
• 5.1.12.5.1.4: Pan
• 5.1.12.5.1.5: Tilt
• 5.1.12.5.1.6: Yaw
• 5.1.12.5.2: PassengerSide
• 5.1.12.5.2.1: IsFolded
• 5.1.12.5.2.2: IsHeatingOn
• 5.1.12.5.2.3: IsLocked
• 5.1.12.5.2.4: Yaw
• 5.1.12.5.2.5: Pan
• 5.1.12.5.2.6: Tilt
• 5.1.12.6: Windshield
• 5.1.12.6.1: Front
• 5.1.12.6.1.1: IsHeatingOn
• 5.1.12.6.1.2: WasherFluid
• 5.1.12.6.1.2.1: IsLevelLow
• 5.1.12.6.1.2.2: Level
• 5.1.12.6.1.3: Wiping
• 5.1.12.6.1.3.1: Intensity
• 5.1.12.6.1.3.2: IsWipersWorn
• 5.1.12.6.1.3.3: Mode
• 5.1.12.6.1.3.4: System
• 5.1.12.6.1.3.4.1: ActualPosition
• 5.1.12.6.1.3.4.2: DriveCurrent
• 5.1.12.6.1.3.4.3: Frequency
• 5.1.12.6.1.3.4.4: IsBlocked
• 5.1.12.6.1.3.4.5: IsEndingWipeCycle
• 5.1.12.6.1.3.4.6: IsOverheated
• 5.1.12.6.1.3.4.7: IsPositionReached
• 5.1.12.6.1.3.4.8: IsWiperError
• 5.1.12.6.1.3.4.9: IsWiping
• 5.1.12.6.1.3.4.10: Mode
• 5.1.12.6.1.3.4.11: TargetPosition
• 5.1.12.6.1.3.5: WiperWear
• 5.1.12.6.2: Rear
• 5.1.12.6.2.1: IsHeatingOn
• 5.1.12.6.2.2: WasherFluid
• 5.1.12.6.2.2.1: IsLevelLow
• 5.1.12.6.2.2.2: Level
• 5.1.12.6.2.3: Wiping
• 5.1.12.6.2.3.1: Intensity
• 5.1.12.6.2.3.2: IsWipersWorn
• 5.1.12.6.2.3.3: Mode
• 5.1.12.6.2.3.4: System
• 5.1.12.6.2.3.4.1: ActualPosition
• 5.1.12.6.2.3.4.2: DriveCurrent
• 5.1.12.6.2.3.4.3: Frequency
• 5.1.12.6.2.3.4.4: IsBlocked
• 5.1.12.6.2.3.4.5: IsEndingWipeCycle
• 5.1.12.6.2.3.4.6: IsOverheated
• 5.1.12.6.2.3.4.7: IsPositionReached
• 5.1.12.6.2.3.4.8: IsWiperError
• 5.1.12.6.2.3.4.9: IsWiping
• 5.1.12.6.2.3.4.10: Mode
• 5.1.12.6.2.3.4.11: TargetPosition
• 5.1.12.6.2.3.5: WiperWear
• 5.1.12.7: BodyType
• 5.1.12.8: Hood
• 5.1.12.8.1: IsOpen
• 5.1.12.8.2: Position
• 5.1.12.8.3: Switch
• 5.1.12.9: Horn
• 5.1.12.9.1: IsActive
• 5.1.12.10: Raindetection
• 5.1.12.10.1: Intensity
• 5.1.12.11: Trunk
• 5.1.12.11.1: Front
• 5.1.12.11.1.1: IsLightOn
• 5.1.12.11.1.2: IsLocked
• 5.1.12.11.1.3: IsOpen
• 5.1.12.11.1.4: Position
• 5.1.12.11.1.5: Switch
• 5.1.12.11.2: Rear
• 5.1.12.11.2.1: IsLightOn
• 5.1.12.11.2.2: IsLocked
• 5.1.12.11.2.3: IsOpen
• 5.1.12.11.2.4: Position
• 5.1.12.11.2.5: Switch
• 5.1.13: Acceleration
• 5.1.13.1: Lateral
• 5.1.13.2: Longitudinal
• 5.1.13.3: Vertical
• 5.1.14: AngularVelocity
• 5.1.14.1: Pitch
• 5.1.14.2: Roll
• 5.1.14.3: Yaw
• 5.1.15: AverageSpeed
• 5.1.16: CargoVolume
• 5.1.17: CurbWeight
• 5.1.18: CurrentLocation
• 5.1.18.1: Altitude
• 5.1.18.2: GNSSReceiver
• 5.1.18.2.1: FixType
• 5.1.18.2.2: MountingPosition
• 5.1.18.2.2.1: X
• 5.1.18.2.2.2: Y
• 5.1.18.2.2.3: Z
• 5.1.18.3: Heading
• 5.1.18.4: HorizontalAccuracy
• 5.1.18.5: Latitude
• 5.1.18.6: Longitude
• 5.1.18.7: Timestamp
• 5.1.18.8: VerticalAccuracy
• 5.1.19: CurrentOverallWeight
• 5.1.20: EmissionsCO2
• 5.1.21: GrossWeight
• 5.1.22: Height
• 5.1.23: IsAutoPowerOptimize
• 5.1.24: IsMoving
• 5.1.25: Length
• 5.1.26: MaxTowBallWeight
• 5.1.27: MaxTowWeight
• 5.1.28: PowerOptimizeLevel
• 5.1.29: Powertrain
• 5.1.29.1: FuelSystem
• 5.1.29.1.1: AbsoluteLevel
• 5.1.29.1.2: AfterRefuelingFuelEconomy
• 5.1.29.1.3: AverageConsumption
• 5.1.29.1.4: ConsumptionSinceLastRefuel
• 5.1.29.1.5: ConsumptionSinceStart
• 5.1.29.1.6: CumulativeFuelEconomy
• 5.1.29.1.7: DriveFuelEconomy
• 5.1.29.1.8: HybridType
• 5.1.29.1.9: InstantantFuelEconomy
• 5.1.29.1.10: InstantConsumption
• 5.1.29.1.11: IsEngineStopStartEnabled
• 5.1.29.1.12: IsFuelLevelEmpty
• 5.1.29.1.13: IsFuelLevelLow
• 5.1.29.1.14: IsFuelPortFlapOpen
• 5.1.29.1.15: Range
• 5.1.29.1.16: RefuelPortPosition
• 5.1.29.1.17: RelativeLevel
• 5.1.29.1.18: SupportedFuel
• 5.1.29.1.19: SupportedFuelTypes
• 5.1.29.1.20: TankCapacity
• 5.1.29.1.21: TimeRemaining
• 5.1.29.2: RangeExtender
• 5.1.29.2.1: ChargeDepleting
• 5.1.29.2.1.1: EnergyConsumption
• 5.1.29.2.1.2: Range
• 5.1.29.2.2: ChargeSustaining
• 5.1.29.2.2.1: FuelEconomy
• 5.1.29.2.2.2: Range
• 5.1.29.2.3: CombinedFuelEconomy
• 5.1.29.2.4: OperatingMode
• 5.1.29.3: ElectricMotor
• 5.1.29.3.1: EngineCode
• 5.1.29.3.2: EngineCoolant
• 5.1.29.3.2.1: Capacity
• 5.1.29.3.2.2: Level
• 5.1.29.3.2.3: LifeRemaining
• 5.1.29.3.2.4: Temperature
• 5.1.29.3.3: MaxPower
• 5.1.29.3.4: MaxRegenPower
• 5.1.29.3.5: MaxRegenTorque
• 5.1.29.3.6: MaxTorque
• 5.1.29.3.7: Power
• 5.1.29.3.8: Speed
• 5.1.29.3.9: Temperature
• 5.1.29.3.10: TimeInUse
• 5.1.29.3.11: Torque
• 5.1.29.4: TractionBattery
• 5.1.29.4.1: BatteryConditioning
• 5.1.29.4.1.1: IsActive
• 5.1.29.4.1.2: IsOngoing
• 5.1.29.4.1.3: RequestedMode
• 5.1.29.4.1.4: StartTime
• 5.1.29.4.1.5: TargetTemperature
• 5.1.29.4.1.6: TargetTime
• 5.1.29.4.2: DCDC
• 5.1.29.4.2.1: PowerLoss
• 5.1.29.4.2.2: Temperature
• 5.1.29.4.3: AccumulatedChargedEnergy
• 5.1.29.4.4: AccumulatedChargedThroughput
• 5.1.29.4.5: AccumulatedConsumedEnergy
• 5.1.29.4.6: AccumulatedConsumedThroughput
• 5.1.29.4.7: CellVoltage
• 5.1.29.4.7.1: CellVoltages
• 5.1.29.4.7.2: IdMax
• 5.1.29.4.7.3: IdMin
• 5.1.29.4.7.4: Max
• 5.1.29.4.7.5: Min
• 5.1.29.4.8: Charging
• 5.1.29.4.8.1: AveragePower
• 5.1.29.4.8.2: ChargeCurrent
• 5.1.29.4.8.2.1: DC
• 5.1.29.4.8.2.2: Phase1
• 5.1.29.4.8.2.3: Phase2
• 5.1.29.4.8.2.4: Phase3
• 5.1.29.4.8.3: ChargeLimit
• 5.1.29.4.8.4: ChargeRate
• 5.1.29.4.8.5: ChargeVoltage
• 5.1.29.4.8.5.1: DC
• 5.1.29.4.8.5.2: Phase1
• 5.1.29.4.8.5.3: Phase2
• 5.1.29.4.8.5.4: Phase3
• 5.1.29.4.8.6: EvseId
• 5.1.29.4.8.7: IsCharging
• 5.1.29.4.8.8: IsDischarging
• 5.1.29.4.8.9: Location
• 5.1.29.4.8.9.1: Altitude
• 5.1.29.4.8.9.2: Latitude
• 5.1.29.4.8.9.3: Longitude
• 5.1.29.4.8.10: MaximumChargingCurrent
• 5.1.29.4.8.10.1: DC
• 5.1.29.4.8.10.2: Phase1
• 5.1.29.4.8.10.3: Phase2
• 5.1.29.4.8.10.4: Phase3
• 5.1.29.4.8.11: MaxPower
• 5.1.29.4.8.12: PowerLoss
• 5.1.29.4.8.13: StartStopCharging
• 5.1.29.4.8.14: Temperature
• 5.1.29.4.8.15: Timer
• 5.1.29.4.8.15.1: Mode
• 5.1.29.4.8.15.2: Time
• 5.1.29.4.8.16: TimeToComplete
• 5.1.29.4.8.17: ChargingPort
• 5.1.29.4.8.17.1: AnyPosition
• 5.1.29.4.8.17.1.1: IsChargingCableLocked
• 5.1.29.4.8.17.1.2: IsChargingCableConnected
• 5.1.29.4.8.17.1.3: IsFlapOpen
• 5.1.29.4.8.17.1.4: SupportedInletTypes
• 5.1.29.4.8.17.2: FrontLeft
• 5.1.29.4.8.17.2.1: IsChargingCableConnected
• 5.1.29.4.8.17.2.2: IsChargingCableLocked
• 5.1.29.4.8.17.2.3: IsFlapOpen
• 5.1.29.4.8.17.2.4: SupportedInletTypes
• 5.1.29.4.8.17.3: FrontMiddle
• 5.1.29.4.8.17.3.1: IsChargingCableConnected
• 5.1.29.4.8.17.3.2: IsChargingCableLocked
• 5.1.29.4.8.17.3.3: IsFlapOpen
• 5.1.29.4.8.17.3.4: SupportedInletTypes
• 5.1.29.4.8.17.4: FrontRight
• 5.1.29.4.8.17.4.1: IsChargingCableConnected
• 5.1.29.4.8.17.4.2: IsChargingCableLocked
• 5.1.29.4.8.17.4.3: IsFlapOpen
• 5.1.29.4.8.17.4.4: SupportedInletTypes
• 5.1.29.4.8.17.5: RearLeft
• 5.1.29.4.8.17.5.1: IsChargingCableConnected
• 5.1.29.4.8.17.5.2: IsChargingCableLocked
• 5.1.29.4.8.17.5.3: IsFlapOpen
• 5.1.29.4.8.17.5.4: SupportedInletTypes
• 5.1.29.4.8.17.6: RearMiddle
• 5.1.29.4.8.17.6.1: IsChargingCableConnected
• 5.1.29.4.8.17.6.2: IsChargingCableLocked
• 5.1.29.4.8.17.6.3: IsFlapOpen
• 5.1.29.4.8.17.6.4: SupportedInletTypes
• 5.1.29.4.8.17.7: RearRight
• 5.1.29.4.8.17.7.1: IsChargingCableConnected
• 5.1.29.4.8.17.7.2: IsChargingCableLocked
• 5.1.29.4.8.17.7.3: IsFlapOpen
• 5.1.29.4.8.17.7.4: SupportedInletTypes
• 5.1.29.4.9: CurrentCurrent
• 5.1.29.4.10: CurrentPower
• 5.1.29.4.11: CurrentVoltage
• 5.1.29.4.12: ErrorCodes
• 5.1.29.4.13: GrossCapacity
• 5.1.29.4.14: Id
• 5.1.29.4.15: IsGroundConnected
• 5.1.29.4.16: IsPowerConnected
• 5.1.29.4.17: MaxVoltage
• 5.1.29.4.18: NetCapacity
• 5.1.29.4.19: NominalVoltage
• 5.1.29.4.20: PowerLoss
• 5.1.29.4.21: ProductionDate
• 5.1.29.4.22: Range
• 5.1.29.4.23: StateOfCharge
• 5.1.29.4.23.1: Current
• 5.1.29.4.23.2: CurrentEnergy
• 5.1.29.4.23.3: Displayed
• 5.1.29.4.24: StateOfHealth
• 5.1.29.4.25: Temperature
• 5.1.29.4.25.1: Average
• 5.1.29.4.25.2: CellTemperature
• 5.1.29.4.25.3: Max
• 5.1.29.4.25.4: Min
• 5.1.29.4.26: TimeRemaining
• 5.1.29.5: AccumulatedBrakingEnergy
• 5.1.29.6: CombustionEngine
• 5.1.29.6.1: AspirationType
• 5.1.29.6.2: Bore
• 5.1.29.6.3: CompressionRatio
• 5.1.29.6.4: Configuration
• 5.1.29.6.5: DieselExhaustFluid
• 5.1.29.6.5.1: Capacity
• 5.1.29.6.5.2: IsLevelLow
• 5.1.29.6.5.3: Level
• 5.1.29.6.5.4: Range
• 5.1.29.6.6: DieselParticulateFilter
• 5.1.29.6.6.1: DeltaPressure
• 5.1.29.6.6.2: InletTemperature
• 5.1.29.6.6.3: OutletTemperature
• 5.1.29.6.7: Displacement
• 5.1.29.6.8: EngineCode
• 5.1.29.6.9: EngineCoolant
• 5.1.29.6.9.1: Capacity
• 5.1.29.6.9.2: Level
• 5.1.29.6.9.3: LifeRemaining
• 5.1.29.6.9.4: Temperature
• 5.1.29.6.10: EngineHours
• 5.1.29.6.11: EngineOil
• 5.1.29.6.11.1: Capacity
• 5.1.29.6.11.2: Level
• 5.1.29.6.11.3: LifeRemaining
• 5.1.29.6.11.4: Temperature
• 5.1.29.6.12: EOP
• 5.1.29.6.13: IdleHours
• 5.1.29.6.14: IsRunning
• 5.1.29.6.15: MAF
• 5.1.29.6.16: MAP
• 5.1.29.6.17: MaxPower
• 5.1.29.6.18: MaxTorque
• 5.1.29.6.19: NumberOfCylinders
• 5.1.29.6.20: NumberOfValvesPerCylinder
• 5.1.29.6.21: Power
• 5.1.29.6.22: Speed
• 5.1.29.6.23: StrokeLength
• 5.1.29.6.24: Torque
• 5.1.29.6.25: TPS
• 5.1.29.7: IsAutoPowerOptimize
• 5.1.29.8: PowerOptimizeLevel
• 5.1.29.9: Range
• 5.1.29.10: TimeRemaining
• 5.1.29.11: Transmission
• 5.1.29.11.1: ClutchEngagement
• 5.1.29.11.2: ClutchWear
• 5.1.29.11.3: DiffLockFrontEngagement
• 5.1.29.11.4: DiffLockRearEngagement
• 5.1.29.11.5: GearChangeMode
• 5.1.29.11.6: IsElectricalPowertrainEngaged
• 5.1.29.11.7: IsLowRangeEngaged
• 5.1.29.11.8: IsParkLockEngaged
• 5.1.29.11.9: PerformanceMode
• 5.1.29.11.10: Temperature
• 5.1.29.11.11: TorqueDistribution
• 5.1.29.11.12: CurrentGear
• 5.1.29.11.13: DriveType
• 5.1.29.11.14: GearCount
• 5.1.29.11.15: SelectedGear
• 5.1.29.11.16: TravelledDistance
• 5.1.29.11.17: Type
• 5.1.29.12: Type
• 5.1.30: RoofLoad
• 5.1.31: Trailer
• 5.1.31.1: IsConnected
• 5.1.32: TurningDiameter
• 5.1.33: WidthExcludingMirrors
• 5.1.34: WidthFoldedMirrors
• 5.1.35: WidthIncludingMirrors
• 5.1.36: IsBrokenDown
• 5.1.37: LowVoltageBattery
• 5.1.37.1: CurrentCurrent
• 5.1.37.2: CurrentVoltage
• 5.1.37.3: NominalCapacity
• 5.1.37.4: NominalVoltage
• 5.1.38: LowVoltageSystemState
• 5.1.39: Speed
• 5.1.40: StartTime
• 5.1.41: TraveledDistance
• 5.1.42: TraveledDistanceSinceStart
• 5.1.43: TripDuration
• 5.1.44: TripMeterReading
• 5.1.45: VehicleIdentification
• 5.1.45.1: AcrissCode
• 5.1.45.2: BodyType
• 5.1.45.3: Brand
• 5.1.45.4: DateVehicleFirstRegistered
• 5.1.45.5: KnownVehicleDamages
• 5.1.45.6: LicensePlate
• 5.1.45.7: MeetsEmissionStandard
• 5.1.45.8: Model
• 5.1.45.9: OptionalExtras
• 5.1.45.10: ProductionDate
• 5.1.45.11: PurchaseDate
• 5.1.45.12: VehicleConfiguration
• 5.1.45.13: VehicleExteriorColor
• 5.1.45.14: VehicleInteriorColor
• 5.1.45.15: VehicleInteriorType
• 5.1.45.16: VehicleModelDate
• 5.1.45.17: VehicleSeatingCapacity
• 5.1.45.18: VehicleSpecialUsage
• 5.1.45.19: VIN
• 5.1.45.20: WMI
• 5.1.45.21: Year
• 5.1.46: VersionVSS
• 5.1.46.1: Label
• 5.1.46.2: Major
• 5.1.46.3: Minor
• 5.1.46.4: Patch
• 6: Incubator
• 6.1: Cloud Connector
• 6.2: OpenTelemetry Integration
• 6.3: Self Update Agent
• 6.4: Vehicle Update Manager
• 7: Building Leda
• 7.1: Concepts
• 7.2: Metalayer
• 7.3: Setup development environment
• 7.3.1: Codespaces
• 7.3.1.1: Advanced topics
• 7.3.2: GitHub Runner
• 7.3.3: VSCode DevContainer
• 7.3.4: Building with kas/manually
• 7.3.5: Restricted Internet
• 7.4: Run the build
• 7.5: Automated Tests
• 7.5.1: Robot Keywords
• 7.5.2: Rust Tests
• 7.6: GitHub Workflow
• 7.7: Runqemu
• 7.8: License Compliance
• 7.9: Miscellaneous
• 7.9.1: Resource Consumptions
• 7.9.2: Partition Layout
• 7.10: Releasing
• 7.10.1: Validating
• 7.11: Developing and Maintaining Utils
• 7.11.1: Rust Utils
• 7.11.1.1: Communicating with Кanto-CM via gRPC
• 7.11.1.2: Kanto Auto deployer (KAD)
• 7.11.1.3: Kantui
• 7.11.2: Shell Utils
• 7.11.2.1: sdv-health
• 8: Customizing
• 8.1: Custom Distros
• 8.2: Deploying Containers
• 8.3: FAQ
• 9: Project Information
• 9.1: Community
• 9.2: Dependencies
• 9.3: Contribution Guidelines
• 9.4: Project Logo
• 9.5: Privacy Information
• 9.6: Security Policy
• 10:

1 - About Leda

The Eclipse Leda project will provide system image “recipes” to deliver a functional Linux-based image/distribution in the context of SDV (Software Defined Vehicle), by pulling together individual contributons from the SDV and the larger OSS community.

The Eclipse Leda distribution will work with build scripts, package definitions, image build pipelines, etc, with the goal to pull SDV projects and dependecies from the larger OSS community into a working Linux system. Such system images (or other useful forms of delivery, as determined by the project) will be made available for consumption for anyone who is interested in working with the SDV tech stack. These deliveries take the form of container (base) images, installable/flashable image files, etc (again to be evolved by the project team according to community needs). Also in scope is concise and useful documentation for consumers of the project’s deliverables, plus a method of delivering that documentation.

In the context described above - the ambition of SDV to build a technology ecosystem for software-defined vehicle concern - a prime challenge will be the combination of these initially diverse components into a coherent and useful whole: all the software components in the world will not have the impact needed to transform the automotive industry unless we can make them play together coherently an form a functional portfolio. As a first step towards that goal, this proposal (Eclipse Leda) is for a “SDV distribution” project that pulls together individual contributor pieces from SDV and the larger OSS community, to deliver a functional and always-available Linux-based image/distribution with two primary goals:

• be the crystalization point for functionally integrating diverse SDV-scope projects into a working whole

• deliver a continually available, always working starting image for developers interested in getting going with the SDV tech stack

1.1 - Architecture

Runtime Overview

The runtime overview shows the general layer architecture for the runtime of the SDV edge stack as implemented by the Leda quickstart image. Dotted lines indicate out-of-scope components. They may be non-Edge components (such as cloud services, or SDKs and additional development tooling for vehicle applications). Dotted lines for in-vehicle edge components indicate that they may be used, but are not pre-installed or pre-configured on the Leda quickstart image.

Deployment Overview

Eclipse Leda can be used in different deployment scenarios: on physical hardware, on virtual machines or installed on existing Linux distributions. Depending on the specific deployment, some features may not be applicable. Each deployment option is meant for different uses. The applicabability depend to your specific requirements.

• Option 1: Hardware - Suitable for proof-of-concepts, system integration tasks, access to actual physical actuators and sensors. However, an automated setup is much harder to realize, as additional hardware for remote controlling of power supply is needed. The constrained environment of a physical device is good to verify accidental assumptions made by application developers, such as resource consumptions (CPU, memory) or the existence of Linux tools, Kernel modules or device drivers.
• Option 2: Docker Containers - Good for quick startup and throw-away (ephemeral) uses, such as automated system testing or one-off troubleshooting. The access to physical hardware is limited and more complicated to set up. QEMU provides emulation of devices, such as CAN-Bus. Due to multiple nesting of abstraction technology (Docker + QEMU + OS), additional configuration of networking and device pass-thrus are necessary. It’s easy and cheap to spin-off many separate instances to simulate a whole vehicle system with multiple vehicle computers and simulated ECUs in the same vehicle network.
• Option 3: Package Installation - Good for existing devices with feature-rich functionality where the original OS should be used. Leda does not support self-update for this deployment option, as it relies on the master OS distribution channels. The constraints of an embedded device are not replicable easily on a PC-style host machine without additional effort. Package installation is good when the focus is on exploring the Vehicle Applications, SDKs, Vehicle Signal Abstractions etc.

Build Environment Overview

1.2 - Features

• Publish/Subscribe messaging infrastructure for cloud connectivity by Eclipse Kanto
  • local messaging for applications and SDV system components via an MQTT message broker
  • connection to a backend messaging hub, such as Azure IoT Hub or the IoT Suite
  • device identification and authentication for cloud connectivity by using TLS device certificates
• Container runtime
  • An OCI-compliant container orchestration for vehicle applications and services by Eclipse Kanto
  • containerd.io as the default container runtime. Both layers of container runtimes can be exchanged with other implementations
• A Vehicle Update Manager to orchestrate deployments of Vehicle Applications, configurations and base operating system updates
• An example Vehicle Seat Service implementation to showcase
  • the Eclipse Velocitas programming model,
  • the Eclipse Kuksa.VAL vehicle databroker and
  • the Covesa Vehicle Signal Specification
  • the communication with basic vehicle communication networks such as CAN-Bus (CAN Feeder)
• A Self Update Agent for firmware-over-the-air (FOTA) updates, using an A/B deployment strategy
  • Integration with RAUC
• An OpenTelemetry collector and example configurations to collect and publish logs and metrics of containerized Vehicle Applications to the cloud backend for further processing

The features of the reusable build recipes implemented as an OpenEmbedded metalayer meta-leda are:

• Build recipes for a Yocto-based distribution to build SDV-related software components
• Build recipes for customizations of the target device’s storage structure to enable A/B system updates
• Build recipes for pre-packaging container images into the device during the manufacturing process to minimize initial online provisioning time
• A customized minimal setup for use on constrained devices and a full setup with convenient developer tools
• Ready images for virtual devices, for automated testing and evaluation purposes, eg QEMU ARM-64
• Ready images for physical devices, for evaluation and demo purposes, eg Raspberry Pi 4

1.3 - Goals

The project aims to provide an integration point for Open Source components for the Software Defined Vehicle ecosystem.

In a complex architecture, there are many different ways of implementations and alternative solutions possible.

For embedded vehicle computer systems and their software stack, there are a lot of requirements to consider, depending on the actual use cases:

• Integration and High-Level Testing (System Integrators, Suppliers)
• Proof-of-Concept projects (Integrators, OEMs, ISVs)
• Experiments and Hackathons (Developers, Research)
• Development phase (Developers, OEMs)
• Open Source Collaboration (Developers, OEMs, ISVs, Open Source Organizations, Standardization Organizations)

Some of the requirements derived from the above are taken into account for Leda’s quickstart setups. Thereas some other requirements can only be met once the project is in a nearer production environment and by customizing the target device image. The following document will list some of these requirements and give an explanation on why they are set as goals in the Leda quickstart distribution.

Overview

• Provide an example operating system build and configuration for constrained in-vehicle devices: Suppliers and system integrators want a way to cusomize and optimize the base operating system as much as possible. This is to achieve a high efficiency, high level of reuse and cost benefits of the planned hardware. The build system for the operating system, and the selection of the underlying distribution is key to the convenience for new users, but also commercially a business decision with an impact on the future maintainability of the platform. The Yocto Project has been chosen as an established de-facto standard for customized Linux distributions for embedded systems. Leda provides an OpenEmbedded Meta-Layer, which can be used with many existing SDKs of SoC manufacturers. Additionally, Leda will strive for being easy to install on low-cost “evaluation boards” such as the Raspberry Pi, or development environments such as a virtual machine in the cloud.
• Integrate software-defined-vehicle Open Source components to showcase the available features and their state of maturity: The SDV ecosystem will grow and a lot of new software projects will be needed to solve the current problems and challenges. The Eclipse SDV ecosystem already contains many software packages, which independently make sense for their set goals. With Leda, we want to increase the integrational aspect, helping project leads, developers, contributors, users and architects to evaluate the SDV portfolio, how it can be integrated with each other and how a possible reference architecture implementation might be loooking like.
• Demonstrate the use and interaction of open protocols and specifications:
  • Vehicle Signal Specifications from the The Connected Vehicle Systems Alliance (COVESA) to establish a semantically useful abstraction model for vehicle signals.
  • OpenTelemetry specs and components, to show the possibilities of applying DevOps methodologies and technologies to operate, monitor and maintain fleets of vehicles and their distributed software applications
  • Eclipse IoT related specifications for software rollouts and digital twin representations

1.4 - Roadmap

• Initial Open Source contribution expected by Q2 2022 (Done)
• A first milestone build is expected end of 2022 (Done)
• Plan for the first release cycle to be created in Q1/2023 (In Progress - Q2/2023)
• Release cycles are planned every 3-6 months
• Release planning will be conducted together with corresponding Eclipse projects

Backlog

The Leda team maintains a backlog roadmap using GitHub projects at https://github.com/orgs/eclipse-leda/projects/1/views/1

Future Work

The project intends to be the integration and collaboration platform for Software defined Vehicle functionality.

Exemplary future work:

• Migrate to official Eclipse Kanto releases for Cloud Connector, Container Management and Vehicle Update Manager
• Include reference implementations from the Eclipse Software Defined Vehicle working group projects:
  • Eclipse Velocitas
  • Eclipse Kuksa
  • Eclipse SommR
  • Eclipse Chariott
  • Eclipse Muto
  • Eclipse Backend function Bindings (BfB)
  • Eclipse SDV Blueprints
• Include and showcase more features regarding development, operation and monitoring of Vehicle Services and Vehicle Applications

If you have feedback, please use GitHub Issues

1.5 - Releases

The Eclipse Leda project follows the Eclipse Release process. Please see Eclipse Project handbook for details about the process.

The release plans overview for Eclipse Leda is available at https://projects.eclipse.org/projects/automotive.leda/governance

1.5.1 - Milestone 0.1.0-M1

Release artifacts: https://github.com/eclipse-leda/leda-distro/releases/tag/v0.1.0-M1

Note: You need to uncompress eclipse-leda-raspberrypi.tar.xz multiple times until the plain .wic file is extracted, which can be flashed.

After download, continue with Getting Started

Release Notes

First pre-release of Eclipse Leda quickstart images, based on Yocto LTS release Kirkstone with Long Term Support until at least April 2024.

Minimal feature set to run software-defined-vehicle applications (such as Eclipse Velocitas apps) using COVESA Vehicle Signal Specification and the Eclipse Kuksa.VAL Databroker on virtual devices (QEMU), in Docker, or on physical consumer-grade devices (Raspberry Pi 4 64-Bit) for development, demonstration and prototyping purposes.

Includes example applications from Kuksa:

• Example Seat Service
• Example HVAC Service
• DBC Feeder replays a Tesla Model 3 CAN-Dump and feeds it into Kuksa.VAL Databroker

Change log

• Replaced k3s with Eclipse Kanto Container Management
• Replaced packages licensed under GPLv3 and similar licenses with alternatives
  • Replaced Grub with U-Boot
  • Replaced nano with kibi
  • Removed readline library
  • Removed bash
• RAUC Updates
  • Bundles available for each image type (Full, Minimal, Rescue)
  • Enabled verity format by default
  • Fixed the compatible configuration string
• Added and updated Leda utilities
• Build infrastructure improvements
  • Builds for Dockerized images
  • Switched to a BitBake build using kas for layer management
  • Added automated system tests using Robot framework and Dockerized environments
  • General cleanup of recipes, dependencies and structuring of the meta-leda sublayers to improve reusability
• Automatic deployment of containers based on container manifests with ad-hoc updates (filewatcher in kanto-auto-deployer)
• Preparation for AirGap installation of containers
• General improvements, such as Wifi network management

Known Issues

The following issues were known to the development team before starting the 0.1.0-M1 build cycle. They have been prioritized as non-critical and may be fixed for later releases.

• RAUC can not install in stream-mode on Raspberry Pi
• sdv-motd is confused by wlan interfaces
• growdisk on RPi4 with sfdisk instead of parted (signaling kernel)
• Partition sizes are not multiple of 4096 byte for Rauc block-hash-index
• sdv-provision produces an empty Device ID
• Missing/Outdated Kuksa databroker-cli
• sdv-image-minimal missing SDV edge components
• Home/End key navigation does not work with putty

OSS IP Compliance Report

Report scan-report-web-app_0.1.0-M1.html

1. Incorrectly detected license “biosl-4.0”

   • Rule: OCaaS Policy A9 License with no classification
   • Message: The license LicenseRef-scancode-biosl-4.0 found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is not categorized and / or evaluated for usage.
   • Evaluation: This license seems to be detected incorrectly by the tool being used, as it is an internal, proprietary license which is not used in the Eclipse Leda project.

2. Incorrectly detected license “GPL-1.0” for ORT configuration file

   • Rule: OCaaS Policy C1 Strict Copyleft
   • Message: License GPL-1.0-only found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is categorized as strict-copyleft which must not be used for BT11 Open Source Development service applications.
   • Evaluation: The scan tool incorrectly detects its own configuration file (.ort.original.yml) as being licensed under GPL-v1.0

3. Incorrectly detected license “GPL-2.0-only” for standard Leda license header (which is Apache Software License)

   • Rule: OCaaS Policy C1 Strict Copyleft
   • Message: License GPL-2.0-only found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is categorized as strict-copyleft which must not be used for BT11 Open Source Development service applications.
   • Evaluation: The scan tool incorrectly detects the Apache License header as GPL-2.0 license text

4. Incorrectly detected license “proprietary”

   • Rule: OCaaS Policy C3 Commercial
   • Message: License LicenseRef-scancode-proprietary-license found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is categorized as commercial and requires special handling.
   • Evaluation: The scan tool incorrectly detects its own configuration file (.ort.original.yml) as being licensed under proprietary licenses.

1.5.2 - Milestone 0.1.0-M2

Release artifacts: https://github.com/eclipse-leda/leda-distro/releases/tag/v0.1.0-M2

Note: You need to uncompress eclipse-leda-raspberrypi.tar.xz multiple times until the plain .wic file is extracted, which can be flashed.

After download, continue with Getting Started

Release Notes

First pre-release of Eclipse Leda quickstart images, based on Yocto LTS release Kirkstone with Long Term Support until at least April 2024.

Minimal feature set to run software-defined-vehicle applications (such as Eclipse Velocitas apps) using COVESA Vehicle Signal Specification and the Eclipse Kuksa.VAL Databroker on virtual devices (QEMU), in Docker, or on physical consumer-grade devices (Raspberry Pi 4 64-Bit) for development, demonstration and prototyping purposes.

Includes example applications from Kuksa:

• Example Seat Service
• Example HVAC Service
• DBC Feeder replays a Tesla Model 3 CAN-Dump and feeds it into Kuksa.VAL Databroker

Change log 0.1.0-M2

• Remove skopeo dependency from packagegroup-sdv-tools.bb
• Fix typo in SRCREV_FORMAT for pahocpp
• dd kernel config for RAUC stream mode to raspberrypi4-64 and qemuarm64
• Adding extra space in RPi for RAUC updates
• Backport Go 1.20 from Poky Mickledore
• Adding seatadjuster-app
• seatadjuster-app distribution

Change log 0.1.0-M1

• Replaced k3s with Eclipse Kanto Container Management
• Replaced packages licensed under GPLv3 and similar licenses with alternatives
  • Replaced Grub with U-Boot
  • Replaced nano with kibi
  • Removed readline library
  • Removed bash
• RAUC Updates
  • Bundles available for each image type (Full, Minimal, Rescue)
  • Enabled verity format by default
  • Fixed the compatible configuration string
• Added and updated Leda utilities
• Build infrastructure improvements
  • Builds for Dockerized images
  • Switched to a BitBake build using kas for layer management
  • Added automated system tests using Robot framework and Dockerized environments
  • General cleanup of recipes, dependencies and structuring of the meta-leda sublayers to improve reusability
• Automatic deployment of containers based on container manifests with ad-hoc updates (filewatcher in kanto-auto-deployer)
• Preparation for AirGap installation of containers
• General improvements, such as Wifi network management

Known Issues

The following issues were known to the development team before starting the 0.1.0-M1 build cycle. They have been prioritized as non-critical and may be fixed for later releases.

• RAUC can not install in stream-mode on Raspberry Pi
• sdv-motd is confused by wlan interfaces
• growdisk on RPi4 with sfdisk instead of parted (signaling kernel)
• Partition sizes are not multiple of 4096 byte for Rauc block-hash-index
• sdv-provision produces an empty Device ID
• Missing/Outdated Kuksa databroker-cli
• sdv-image-minimal missing SDV edge components
• Home/End key navigation does not work with putty

OSS IP Compliance Report

Report scan-report-web-app_0.1.0-M1.html

1. Incorrectly detected license “biosl-4.0”

   • Rule: OCaaS Policy A9 License with no classification
   • Message: The license LicenseRef-scancode-biosl-4.0 found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is not categorized and / or evaluated for usage.
   • Evaluation: This license seems to be detected incorrectly by the tool being used, as it is an internal, proprietary license which is not used in the Eclipse Leda project.

2. Incorrectly detected license “GPL-1.0” for ORT configuration file

   • Rule: OCaaS Policy C1 Strict Copyleft
   • Message: License GPL-1.0-only found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is categorized as strict-copyleft which must not be used for BT11 Open Source Development service applications.
   • Evaluation: The scan tool incorrectly detects its own configuration file (.ort.original.yml) as being licensed under GPL-v1.0

3. Incorrectly detected license “GPL-2.0-only” for standard Leda license header (which is Apache Software License)

   • Rule: OCaaS Policy C1 Strict Copyleft
   • Message: License GPL-2.0-only found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is categorized as strict-copyleft which must not be used for BT11 Open Source Development service applications.
   • Evaluation: The scan tool incorrectly detects the Apache License header as GPL-2.0 license text

4. Incorrectly detected license “proprietary”

   • Rule: OCaaS Policy C3 Commercial
   • Message: License LicenseRef-scancode-proprietary-license found for package ‘Unmanaged::leda-distro-fork:0716b55ff8f57319263d67ee16d90e64588b391d’ is categorized as commercial and requires special handling.
   • Evaluation: The scan tool incorrectly detects its own configuration file (.ort.original.yml) as being licensed under proprietary licenses.

1.5.3 - Release Plan 0.1.0

The release plan is available at https://projects.eclipse.org/projects/automotive.leda/releases/0.1.0

Release Date

-Thursday, June 1, 2023- - We didn’t meet the planned release date. Work is in progress on IT build infrastructure and OSS IP and license compliance.

New: Tuesday, August 1, 2023

Deliverables

The team plans to deliver the following features:

• Leda Quickstart Images for Qemu (x86_64, arm64), Raspberry Pi and Docker
• Yocto / OpenEmbedded meta-layer for better reusability of the Eclipse SDV Vehicle.Edge stack in customized distributions for constrained devices
• User documentation (Reference, Example Use Cases)
• Automated system tests using Robot Framework
• IP scanning with Eclipse Oniro Compliance Toolchain
• Pre-Integrated Eclipse SDV Vehicle.Edge stack

The core SDV.EDGE stack in Leda would contain the following components for the first release (based upon availability):

• Eclipse Kuksa.VAL: Data Broker
• Eclipse Kanto: Container Management, Vehicle Update Manager
• Eclipse Leda Incubator: Cloud Connector (Azure), Self Update Agent, Utilities (e.g kantui)

The following components are not yet released in public or did not yet finished the project review, and may only be added to the release on shorter notice:

• (Eclipse Backend-Function-Bindings)
• (Eclipse SommR)
• (OTA Client)

Compatibility

Compatibility to previous versions is not considered for this first release.

Internationalization

No efforts towards i18n are done in this release.

Target Environments

• Linux (virtual, qemu)
• Raspberry Pi 4 (consumer grade)

1.5.4 -

2 - Getting Started

1. Download latest Eclipse Leda release
2. Run Eclipse Leda
   • on emulated Qemu devices or
   • on Raspberry Pi 4
3. Configure device, e.g. provision the device
4. Explore the device tools
5. Develop your first Vehicle App using Eclipse Velocitas template
6. Deploy a Vehicle App to the device

2.1 - Introduction to SDV concepts

This page introduces the main concepts around Eclipse Leda, Eclipse Kuksa, Eclipse Velocitas, and Eclipse Kanto for developing and deploying applications for a software defined vehicle (SDV). The intention is to introduce the main concepts and how these projects interact. When you are already familiar with the general ideas of the Eclipse SDV, you can also jump to a hands-on tutorial on how to develop a seat adjuster application or replicate an Eclipse SDV Blueprint for managing vehicle fleets using Eclipse SDV concepts and technologies.

Abstract Architecture

For the software defined vehicle we may assume the following abstract architecture.

The architecture evolves around actuators and sensors in a vehicle, like the state of a passenger seat or a door, which get controlled by connected ECUs. These ECUs react to and produce signals, which they communicate over automotive communication systems like CAN or SOME/IP. To establish a more flexible interaction between these ECUs and make the overall vehicle more software-defined, we assume various vehicle applications which want to interact with the actuators and sensors, e.g., to control a seat based on a saved driver profile. The architecture contains a vehicle abstraction layer between the ECUs and the vehicle applications. This abstraction layer introduces a potential control point for security and safety considerations and generally decouples the application logic from the more deeply embedded soft- and hardware layers.

Vehicle Abstraction Layer

As the name implies the vehicle abstraction layers offers abstract ways to interact with the underlying vehicle.

Vehicle Signal Specification (VSS)

We need a joint data model for the potential signals with which an application can interact. We propose to use the Vehicle Signal Specification (VSS) from the Connected Vehicle Systems Alliance (COVESA) for this.

VSS essentially defines a rule set of how to express the definition of signals in a vehicle. This definition bases a tree structure where each domain, like body control, gets an individual sub-tree. The authors of VSS further provide a default tree of signals to be expected in a vehicle. However, it is common practice to tailor the default tree for a specific vehicle model by adding overlays.

VSS allows modeling and structuring of the data from a vehicle but does not define interfaces for the interaction with this data since this depends on the used communication technology and further circumstances like whether VSS data gets processed inside the vehicle or off-board.

For our architecture, we therefore add the Eclipse Kuksa.val databroker from the Eclipse Kuksa project.

Eclipse KUKSA.val databroker

The Eclipse Kuksa.val databroker acts as a vehicle abstraction layer by brokering VSS signals between vehicle applications and deeply embedded systems in the vehicle. Enabling this abstraction requires a vehicle-specific component to translate between the Kuksa.val databroker and the underlying transport systems and ECUs.
With Eclipse Kuksa, we refer to these software components as providers and further differentiate between actuation and data providers.

For actuators, the Kuksa.val databroker stores the desired and the current state. Typically, an application would perform a control operation by setting the target state and monitoring the current state. It is then the task of the actuation provider to perform the action while the data provider updates the current state according to signals sent on the vehicle bus. To get notified of any changes, applications, and providers can subscribe to specific signals at the Kuksa.val databroker.

The Kuksa.val databroker is written in Rust and offers communication over gRCP. To make life easier for developers using the Kuksa.val databroker there is a Python-client which can be integrated in own applications. When developing with other languages, you may have to generate client code yourself with the gRPC tooling. Either way, these clients allow the development of vehicle applications and providers.

Vehicle Application Development

When developing an application to interact with the abstraction layer, there are a couple of aspects to cover, which are not specific to a single application. Because of that, some projects are evolving around the application development phase.

Eclipse Autowrx and digital.auto Playground

A good starting point to figure out what signals are available is the website of the digital.auto playground based on Eclipse Autowrx.

In the next step, you can ideate on new applications, start coding, and get fast feedback using the prototyping feature of the playground. Once you are confident with the initial version, you can continue the development journey with the help of Eclipse Velocitas, which comes with several features making the life of vehicle application developers easier.

Eclipse Velocitas

Eclipse Velocitas™ is an open source project providing a development tool chain to create containerized Vehicle Apps, offering a development experience to increase the speed of a development team (velocity).

Among other things, Eclipse Velocitas provides a template repository. To kick-start the development of a new application, you can create an individual repository from this template. As an alternative, Eclipse Velocitas provides a CLI application with which you can configure the creation of a tailored vehicle application repository. Either way, the resulting repository contains skeleton code for the actual application and comes with pre-defined GitHub Actions workflows to automate the testing and releasing of applications as containers. The repository further contains the Dockerfile for a dev container that setups a development and vehicle environment on the developer machine. It is then possible to interact with this container through VSCode.

Another aspect of Eclipse Velocitas is the so-called vehicle model. Here it becomes possible to take a custom vehicle model expressed in VSS and generate a tailored SDK with specific domain classes to interact with a Kuksa.val databroker using the same model. This way, we can directly develop against the used vehicle model.

A typical Eclipse Velocitas application development flow then may contain the following steps:

• create Repository
• build and run Dev Container locally from VSCode
• start vehicle runtime in Dev container
• develop vehicle application and integration tests
• commit and push vehicle applications to trigger tests in GitHub Actions workflows
• trigger release workflow in GitHub

As a result of the Release workflow, the generated repository contains a Container image with the vehicle application. A target device, e.g., a vehicle or test device, can pull and execute this container.

Vehicle Providers and Emulation

The underlying assumption when developing a vehicle application against the vehicle abstraction layer is that components below the abstraction fulfill the requests coming from the application. In other words: Developers have to assume that there are providers for the signals with which their application interacts. For a production-ready vehicle, this should be the case. But during development and testing the creation of such providers adds overhead and is a potential cause for further errors. An alternative is to use pre-developed services or even a generalized vehicle mock service which acts as such a provider. Developers can alter the vehicle mock service by defining the desired behavior through a Python-based DSL.

Vehicle Application Runtime

The next step is to bring the application to the target device and the vehicle. There are various options for how to run and orchestrate vehicle application containers. Some originate from general IT scenarios like Kubernetes or Docker Compose, and others focus more on automotive and IoT-use cases like Eclipse Kanto. So a vehicle application developer now faces the challenge of picking a runtime and integrating this runtime with required infrastructure components like the Kuksa.val databroker or respective Kuksa.val providers to enable the vehicle application.

Eclipse Leda

Among other things, Eclipse Leda already provides such a target platform through a Linux-based distribution of pre-integrated Eclipse SDV components. See the architecture page for more details on the elements in Eclipse Leda. For the container execution, Eclipse Leda utilizes Eclipse Kanto, which implements lightweight management of OCI-compliant containers and comes by default with containerd. It is possible to manage the containers either through a CLI or by writing container manifest files and placing them in a dedicated folder on the file system from where Eclipse Kanto automatically performs them.

Service Exchange

Another challenge when deploying multiple components that need to collaborate as services is how they find and communicate with each other. In Eclipse Kanto, the discovery and exchange can happen over container indetifiers or topics on a local MQTT broker. The Eclipse SDV community already came up with other approaches for the service exchange topic like Eclipse uProtocol, Eclipse Chariott or Eclipse Zenoh.

Seat Adjuster

To see the explained concepts in action, it is best to build your own application. The Seat Adjuster is good starting point with specific examples.

2.2 - Download latest release

• Milestone 0.1.0-M1

Latest Release Artifacts

Note: There are no official releases yet. The artifacts available on the Release page are for testing the build and release workflows. They should be considered as unstable nightly builds from the main branch. Releases marked -M1, -M2, -RC1 etc. are preparations for official releases according to the Eclipse Release process.

Go to the Eclipse Leda Releases page and download the release archive for the respective machine. The release archives container the disk image and the respective Linux kernel:

Using GitHub CLI tool

To download all files of the latest release using the GitHub CLI:

• Install GitHub CLI, e.g. for Ubuntu:

  curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
  echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
  sudo apt update
  sudo apt install gh
  

• Authenticate to GitHub:

  gh auth login
  

• Download Leda latest release:

  On Linux:

  mkdir leda && cd leda
  
  gh release download \
    --pattern '*.zip' \
    --pattern 'eclipse-leda-*' \
    --repo eclipse-leda/leda-distro
  

  On Windows:

  gh release download --pattern "*.zip" --pattern "eclipse-leda-*" --repo eclipse-leda/leda-distro
  

• Continue with Running Eclipse Leda on QEMU or Running Eclipse Leda on Raspberry Pi 4

2.3 - Running on Docker

By using the dockerized Leda quickstart images, the SDV vehicle edge components can be evaluated on emulated X86-64 and ARM64 system images, without having to install QEMU and dependencies manually.

If you want to execute the image without Docker, please see Running on QEMU. This allows to tweak the startup script, modify the emulated hardware device and set up advanced network configurations.

There are two options to run Leda:

• Docker: Simple, restricted to one container
• Docker Compose: Advanced, allows networking between containers

Recommendations

• A Linux host with 4 vCPUs, 8GB of RAM and SSD storage is recommended
• Docker

Docker

The easiest way is to run a single instance of Leda in a Docker container:

• Run the Leda Docker quickstart image:

  docker run -it ghcr.io/eclipse-leda/leda-distro/leda-quickstart-x86
  

• Login with root

• Stop the Docker container

  shutdown now
  

  Note: If you need to stop the container from outside, use the docker stop <id> command from a separate terminal.

Privileged Containers

When run as a privileged container, QEMU will try to set up a TAP network and use KVM acceleration. Network and CPU will be faster, depending on the host system.

To be able to use these host devices, QEMU needs access to the following devices:

• /dev/kvm
• /dev/net/tun

Example command:

docker run -it --privileged --device=/dev/kvm:/dev/kvm --device=/dev/net/tun:/dev/net/tun ghcr.io/eclipse-leda/leda-distro/leda-quickstart-x86

Exposing additional ports

To also expose ports to connect to ssh, mqtt or the Kuksa databroker, add the port mappings to the Docker command:

docker run -it --privileged -p 2222:2222 -p 1883:1883 -p 30555:30555 ghcr.io/eclipse-leda/leda-distro/leda-quickstart-x86:latest

The following ports are specifically of interest and exposed by the docker container:

• 2222 for SSH (mapped internally to 22)
• 1880 - free slot reserved for user service
• 1883 for MQTT
• 8888 - free slot reserved for user service
• 30555 for Kuksa Databroker

Note: In unprivileged mode, only these ports are mapped by the Docker container and forwarded to the Leda system. In privileged mode, all TCP ports can be exposed, which will then be forwarded from the Docker container into the Leda system. See the entrypoint script for details.

Running ARM-64 version

To run the ARM-64 bit version of the image, use the leda-quickstart-arm64 container image:

docker run -it ghcr.io/eclipse-leda/leda-distro/leda-quickstart-arm64:latest

Docker Compose

A more convenient way to setup advanced scenarios is to use Docker Compose. There is a Docker Compose configuration for an Eclipse Leda setup in resources/docker-compose.

It will start up the following containers:

• Leda Quickstart image (QEMU x86-64)
• Leda Quickstart image (QEMU ARM-64)
• Web Server with pre-built RAUC Update Bundles
• MQTT Bridge
• DNS Proxy (Allows QEMU to use the Docker DNS)

Usage

Get the Docker Compose configuration file and additional dockerfiles from the https://github.com/eclipse-leda/leda-distro repository:

git clone --filter=blob:none https://github.com/eclipse-leda/leda-distro
cd leda-distro/resources/docker-compose

Starting the containers with:

docker compose up --detach --wait

Log in to a development shell inside of the docker network:

docker compose run --rm devshell

Stopping the containers:

docker compose down

Docker Compose Services

Checking all containers are running or exited successfully:

$ docker compose ps
NAME                 COMMAND                  SERVICE              STATUS              PORTS
leda-arm64           "/docker/leda-quicks…"   leda-arm64           running (healthy)   1883/tcp, 0.0.0.0:2002->2222/tcp, 0.0.0.0:30556->30555/tcp
leda-bundle-server   "/docker-entrypoint.…"   leda-bundle-server   running (healthy)   0.0.0.0:8080->80/tcp
leda-dns-proxy       "dnsmasq -k"             dns-proxy            running             53/tcp, 0.0.0.0:5353->53/udp
leda-initializer     "/bin/sh -c /root/le…"   leda-initializer     exited (0)          
leda-mqtt-broker     "/docker-entrypoint.…"   mqtt-broker          running (healthy)   0.0.0.0:1883->1883/tcp
leda-x86             "/docker/leda-quicks…"   leda-x86             running (healthy)   1883/tcp, 0.0.0.0:30555->30555/tcp, 0.0.0.0:2001->2222/tcp

Network setup

As the networking is a bit more complicated to set up with emulated network inside of QEMU, the following explanation is helpful to understand networking better.

• All docker compose containers are attached to a network called leda-bridge and leda-network and can see each other
• The QEMU instances use a TAP network inside of each leda-quickstart-xxx container and do a NAT network translation to their own container
• The Docker internal DNS server is being used. This is implemented by a DNS Proxy container, which will forward incoming DNS requests to the Docker DNS running on the 127.0.0.x network.
• In unprivileged mode: Only the exposed ports are forwarded from the docker container into the QEMU process: mosquitto 1883, ssh 2222 and kuksa.val databroker 30555. In privileged mode, all TCP ports are forwarded from the Docker container into the QEMU process and the special port 2222 is forwarded to ssh port.

Developer Shell

Developer Shell:

docker compose run --rm devshell

From there, you can log in to either Leda on QEMU x86-64, or log in to Leda on QEMU ARM-64.

ssh leda-x86
ssh leda-arm64

To run an additional terminal in the developer shell, execute this:

docker compose exec devshell /bin/bash

Interacting with Eclipse Leda

1. Check the general system status

sdv-health

Device Provisioning

1. Run the provisioning script:

   sdv-provision
   

2. Copy the fingerprints

3. Go to Azure IoT Hub, create a new device

4. Use the certificate’s common name (CN) as Device Id - on Leda, this defaults to a part of the MAC Address

5. Select X.509 Self-Signed authentication type and enter both fingerprints

6. Click Save

MQTT Broker Bridge

The Docker Compose setup will also start an Eclipse Mosquitto message broker as a bridge to both Leda instances. This allows a user or developer to monitor messages sent by or received by both virtual devices.

Connect your MQTT client to mqtt-broker.leda-network by using the exposed port 1883 on the host:

mosquitto_sub -h localhost -p 1883 -t '#' -v

Docker Networking

You need to enable IP forwarding from Docker containers to make networking work. The containers (leda-arm64, leda-x86) need to run with --privileged as they change iptables rules for proper forwarding of network packets.

See Docker documentation for bridge networking for details.

sudo sysctl net.ipv4.conf.all.forwarding=1
sudo iptables -P FORWARD ACCEPT

Each Eclipse Leda instance (ARM64, x86_64) is running within a QEMU emulated network (192.168.7.2), which itself is contained in a containerized network called leda-network (192.168.8.x).

The containers wrapping the QEMU instances will forward the following ports to the respective QEMU process:

• SSH on port 2222
• Mosquitto on port 1883

DHCP and DNS setup

Each Leda-QEMU container is running a local DHCP on the tap0 network interface and listens for DHCP requests by the Leda Distro running inside of QEMU. The DHCP server will respond with the same IP address (192.168.7.2) to the request from QEMU.

The DHCP response contains a DNS nameserver pointing to the dns-proxy.leda-network (192.168.8.14) IP, which in turn forwards to Docker’s internal 127.0.0.11 nameserver. This allows the QEMU guests to resolve Docker Compose Services by their service name, e.g. leda-bundle-server.leda-network.

Volumes

The /root path inside of the Leda containers is mounted as a volume and contains the raw disk image and runner scripts for the QEMU Leda distribution. Changes on the QEMU filesystem are made persistent on a copy of the QCOW2 disk image, so that restarting the device will keep any changes.

To reset to the original state, delete the respective docker volumes and restart the containers:

docker compose down
docker compose rm --force --stop --volumes
docker volume rm leda-arm64
docker volume rm leda-x86

Profiles

Profiles can be used to determine which containers (services) docker compose should be starting by default. This is mostly used to have the devshell container not start up by default.

• tools: Contains docker containers which are not essential at runtime, must useful for testing and development purposes

2.4 - Running on Raspberry Pi

What you need:

• A Raspberry Pi 4B (64 Bit) with 2 GiB of RAM or more, recommended is 8 GiB
• Network connection (Ethernet or Wifi) with transparent internet access
• Optional keyboard and display (makes it easier to troubleshoot)

Steps:

• Download the latest released SD-Card Image: eclipse-leda-raspberrypi.tar.xz

• Uncompress the SD Card image:

  apt-get install -y xz-utils
  tar xf eclipse-leda-raspberrypi.tar.xz
  bzip2 -d -f sdv-image-all-raspberrypi4-64.wic.bz2
  

• Flash the sdv-image-all-raspberrypi4.wic file to an SD-Card

  • On Linux:
    • Install bmap tools: sudo apt-get install -y bmap-tools
    • Insert SD Card and check which device is mounted: sudo fdisk -l
    • Unmount the device: sudo umount /dev/mmcblk[X]
    • sudo bmaptool copy --bmap sdv-image-all-raspberrypi4-64.wic.bmap sdv-image-all-raspberrypi4-64.wic /dev/mmcblk[X]
    • Note: Using bmap is much faster but works the same as with plain dd if=<wic-file> of=dev/mmcblk[x].
  • On Windows:
    • Raspberry Pi Imager
    • Balena Etcher

• Optional: If you need to adapt the network configuration eg Wifi credentials, edit the configuration files on the boot partition.

• Shutdown the Raspberry and insert the SD-Card into the Raspberry Pi SD-Card slot at the bottom

• Power on your Raspberry to boot the image

• Login with root

• Check disk space:

  • The raspberry-growdisk system service will do this automatically on first boot.

  • To manually enlarge the available disk space on the SD-Card, resize the disk partition: parted /dev/mmcblk0 resizepart 6 100% && resize2fs /dev/mmcblk0p6.

    Note: Due to changes in the disk partition, the partition number (6 in the example) may have changed.

  • Verify with df -h.

• Verify and wait until container runtime is started: systemctl status container-management

• Optional: Check the system health: sdv-health

• Continue with Device Provisioning

2.4.1 - CAN-Bus extensions

The Eclipse Leda quickstart image has CAN-Bus kernel modules and some CAN hardware drivers pre-installed. However, some hardware configuration needs to be adapted at boot time depending on the specific CAN-Extension being attached to the device.

On Raspberry Pi, there is a /boot/config.txt file where you can configure the dtoverlay options accordingly.

Note: After modification, the device requires rebooting for the changes to take effect.

MCP2515 based modules

Products:

• Waveshare RS485 CAN HAT for Raspberry Pi

dtoverlay=mcp2515-can0,oscillator=12000000,interrupt=25,spimaxfrequency=2000000

MCP2518FD based modules

Products:

• Waveshare 2-Channel Isolated CAN FD Expansion HAT for Raspberry Pi, Multi Protections

dtoverlay=2xMCP2517FD
#dtoverlay=2xMCP2518FD-spi0

2.5 - Running on QEMU

If you want to execute the image without building first, grab the latest release or build artifacts from https://github.com/eclipse-leda/leda-distro/

Recommendations

• A Linux host with 8 vCPUs, 16GB of RAM and SSD storage is recommended
• Your Linux user should be sudoer to allow TAP network interfaces to be set up

QEMU x86_64

• Install Qemu, e.g. for Ubuntu:

  sudo apt-get update -y
  sudo apt-get install -y xz-utils qemu-system-x86-64
  

• Download latest Eclipse Leda release

• Uncompress the archive

  tar xf eclipse-leda-qemu-x86_64.tar.xz
  

• Run QEMU on Linux:

  ./run-leda.sh
  

• Run QEMU on Windows:

  run-leda.cmd
  

  

• Login as root without password on login prompt

• Verify and wait until container runtime is started: systemctl status container-management

• Optional: Check the system health: sdv-health

  

  Note: The status of some containers (e.g. cloud connector) are expected to stay in FAILED status as long as the Device Provisioning steps are not completed.

• Continue with Device Provisioning

QEMU ARM 64-Bit

• Install Qemu, e.g. for ARM 64-Bit: sudo apt install qemu-system-aarch64

• Download latest Eclipse Leda release

• Uncompress the archive

  tar xf eclipse-leda-qemu-arm64.tar.xz
  

• Run QEMU on Linux:

  ./run-leda.sh
  

• Run QEMU on Windows:

  run-leda.cmd
  

• Login as root without password on login prompt

• Verify and wait until container runtime is started: systemctl status container-management

• Optional: Check the system health: sdv-health

  Note: The status of some containers (e.g. cloud connector) are expected to stay in FAILED status as long as the Device Provisioning steps are not completed.

• Continue with Device Provisioning

2.5.1 - CAN Bus

Note: The configuration mentioned in this chapter is already enabled in the run-leda.sh script.

QEMU

General documentation about using CAN-Bus in Qemu: https://www.qemu.org/docs/master/system/devices/can.html

Enabling Virtual CAN Bus interfaces (vcan)

No special parameters are necessary for qemu, as vcan is virtual:

runqemu qemux86-64 nographic slirp qemuparams="-m 2048"

Bring interface up:

ip link add dev vcan0 type vcan
ip link set vcan0 up

Enabling CAN Bus interfaces (can)

Standalone CAN within Qemu

To run a standalone CAN setup, qemu must be instructed to emulate a specific CAN hardware device. We will be using the kvaser_pci device in this example:

runqemu qemux86-64 nographic slirp qemuparams="-m 2048 -object can-bus,id=canbus0 -device kvaser_pci,canbus=canbus0"

After the image has booted, load the Linux Kernel Module kvaser_pci device driver and configure the CAN-Bus device (eg bitrate) before bringing the interface up:

root@qemux86-64:~# modprobe kvaser_pci

root@qemux86-64:~# dmesg | grep kvaser
[    9.565149] kvaser_pci 0000:00:04.0: initializing device 10e8:8406
[    9.569308] kvaser_pci 0000:00:04.0: reg_base=00000000d5a68095 conf_addr=000000002b3c7ef6 irq=20
[    9.596942] kvaser_pci 0000:00:04.0: xilinx version=13 number of channels=0

root@qemux86-64:~# ip link show type can
4: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can

Configure the interface:

root@qemux86-64:~# ip link set can0 type can bitrate 1000000
[  165.519919] kvaser_pci 0000:00:04.0 can0: setting BTR0=0x00 BTR1=0x14

root@qemux86-64:~# ip link set can0 up
[  186.906065] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready

root@qemux86-64:~# ip link show type can
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can 

Tunneling a CAN Interface from the Host

runqemu qemux86-64 nographic slirp qemuparams="-m 2048 -object can-bus,id=canbus0 -object can-host-socketcan,id=canhost0,if=can0,canbus=canbus0 -device kvaser_pci,canbus=canbus0"

Bring interface up:

ip link add dev can0 type can
ip link set can0 type can bitrate 1000000
ip link set can0 up
ip link show type can

Raspberry Pi CAN HAT Extensions

Supported boards:

• Boards with a Microchip MCP251x based CAN chip, such as Waveshare CAN HAT or PiCAN 2

Verify driver is loaded:

# dmesg | grep mcp
[    8.23543] mcp251x spi0.0 can0: MCP2515 successfully initialized

Verify SocketCAN network interface shows up:

# ip link show type can
3: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT roup default qlen 10

Continue with configuring the CAN chip and bring up the SocketCAN network interface:

# ip link set can0 type can bitrate 1000000
# ip link set can0 up
# ip link show type can

Linux Kernel Modules

The following Linux Kernel modules are available on the quickstart images:

Note: For QEMU, only kvaser_pci is used

Leda main Kernel

• peak_pciefd - Socket-CAN driver for PEAK PCAN PCIe/M.2 FD family cards
• m_can - CAN bus driver for Bosch M_CAN controller
• m_can_pci - CAN bus driver for Bosch M_CAN controller on PCI bus
• m_can_platform - M_CAN driver for IO Mapped Bosch controllers
• softing - Softing DPRAM CAN driver
• cc770_platform - Socket-CAN driver for CC770 on the platform bus
• cc770_isa - Socket-CAN driver for CC770 on the ISA bus
• cc770 - cc770CAN netdevice driver
• ifi_canfd - CAN bus driver for IFI CANFD controller
• kvaser_usb - CAN driver for Kvaser CAN/USB devices
• etas_es58x - Socket CAN driver for ETAS ES58X USB adapters
• ucan - Driver for Theobroma Systems UCAN devices
• peak_usb - CAN driver for PEAK-System USB adapters
• kvaser_pciefd - CAN driver for Kvaser CAN/PCIe devices
• kvaser_pci - Socket-CAN driver for KVASER PCAN PCI cards
• f81601 - Fintek F81601 PCIE to 2 CANBUS adaptor driver
• sja1000_isa - Socket-CAN driver for SJA1000 on the ISA bus
• plx_pci - Socket-CAN driver for PLX90xx PCI-bridge cards with the SJA1000 chips
• sja1000 - sja1000CAN netdevice driver
• ems_pci - Socket-CAN driver for EMS CPC-PCI/PCIe/104P CAN cards
• peak_pci - Socket-CAN driver for PEAK PCAN PCI family cards
• sja1000_platform - Socket-CAN driver for SJA1000 on the platform bus
• vxcan - Virtual CAN Tunnel
• c_can_platform - Platform CAN bus driver for Bosch C_CAN controller
• c_can - CAN bus driver for Bosch C_CAN controller
• c_can_pci - PCI CAN bus driver for Bosch C_CAN/D_CAN controller
• slcan - serial line CAN interface
• can_dev - CAN device driver interface
• vcan - virtual CAN interface
• can-isotop - PF_CAN isotp 15765-2:2016 protocol
• can-gw - PF_CAN netlink gateway
• can-j1939 - PF_CAN SAE J1939
• can-raw - PF_CAN raw protocol
• can-bcm - PF_CAN broadcast manager protocol
• can - Controller Area Network PF_CAN core

Raspberry Pi

The following Linux Kernel modules are available on the quickstart image for Raspberry Pi:

• can - Controller Area Network PF_CAN core
• vxcan - Virtual CAN Tunnel
• can-dev - CAN device driver interface
• can-bcm - PF_CAN broadcast manager protocol
• can-gw - PF_CAN netlink gateway
• can-raw - PF_CAN raw protocol
• can-isotop - PF_CAN isotp 15765-2:2016 protocol
• can-j1939 - PF_CAN SAE J1939
• vcan - virtual CAN interface
• slcan - serial line CAN interface
• mcp251x - Microchip 251x/25625 CAN driver
• mcp251xfd - Microchip 251xFD Family CAN controller driver
• ems_usb - CAN driver for EMS Dr. Thomas Wuensche CAN/USB interfaces
• gs_usb - Socket CAN device driver for Geschwister Schneider UG
• peak_usb - CAN driver for PEAK-System USB adapters

2.5.2 - Transferring Files

Sharing a directory with the guest

When you want to copy files between the host and the guest, an easy way is to use an SFTP tunnel. With sshfs, you can mount a local directory to a remote directory via SSH.

Pre-Requisites

Installation of needed packages:

• Run apt-get install sshfs on your host
• Enable CORE_IMAGE_EXTRA_INSTALL += " openssh-sftp-server" in local.conf of your image (e.g. in the local_conf_header section in your kas file)
• Verify SFTP connection working with sftp -P 2222 root@localhost

Transfering files from host to guest

When you want to copy files from the host to the guest, an easy way is to use an SFTP tunnel. With sshfs, you can mount a local directory to a remote directory via SSH.

• Create a mount point on your host: mkdir remote
• Open the SSH Filesystem tunnel: sshfs root@localhost:/ remote/ -p 2222
• Check files: ls -al remote/ - you should see the root filesystem of the device now
• You can now easily copy files: cp foo.txt remote/home/root/

Transfering files from guest to host

Note: The reverse direction, e.g. initiating an SSH tunnel from within the device to the host, is currently not supported by the installed software on the image.

2.6 - Running on Linux

To run the main components of the SDV EDGE stack on an existing Linux distribution (e.g. Debian, Ubuntu, Raspberry Pi OS), you need to install the following packages.

Please note that since this is not a full-system installation, but an additional installation, there are some differences compared to the usual Leda installation on Docker/QEMU/Devices using our Quickstart image:

• The Self-Update use case is not used, as the distribution-specific channels apply. E.g. it does not make sense to use the Leda infrastructure to flash a full system image.
• The configuration differs slightly and you need to put some more work into getting the examples to work out of the box. This may include different port numbers, different paths of volume mounts for containers etc.

Debian-based Linux distributions

Tested on x86_64 via Docker:

• Debian 11
• Debian 12
• Ubuntu 20.04
• Ubuntu 22.04
• Ubuntu 23.10

Note: Ubuntu 18.04 is not supported, as the glibc is outdated.

Pre-Requisuites

The SDV stack requires the following packages to be present on the target system:

• Mosquitto (adapt configuration, see below)

• Data folders

  • Storage for Self Update Bundles: mkdir -p /data/selfupdates

  • Device Certificates Folder:

    # Required by Cloud Connector
    mkdir -p /data/var/certificates/
    touch /data/var/certificates/device.crt
    touch /data/var/certificates/device.key
    

• systemd (Optional: You can also manually start the services)

• D-Bus (Optional: This is for Self Update Agent to RAUC integration)

• RAUC (Optional: Only for Self-Update Use Case or testing purposes)

Installation Steps

Note: The steps below are examples for x86 platform. If you deploy on ARM64 platform, adapt the filenames accordingly.

1. Update repository and install dependencies:

   apt-get update
   apt-get -y install ca-certificates mosquitto wget
   
   # Optional:
   apt-get -y install dbus rauc
   

2. Download the Debian package from the Eclipse Kanto release page

   wget "https://github.com/eclipse-kanto/kanto/releases/download/v0.1.0-M3/kanto_0.1.0-M3_linux_x86_64.deb"
   apt-get install -y ./kanto_0.1.0-M3_linux_x86_64.deb
   
   # Check if Kanto has been installed
   command -v container-management
   command -v kanto-cm
   systemctl status container-management
   

   Note: This will also install containerd.

3. Download the Debian packages from the Eclipse Leda Utilities release page:

   wget "https://github.com/eclipse-leda/leda-utils/releases/download/v0.0.2/eclipse-leda-utils_0.0.2.0.00680_all.deb"
   apt-get install -y ./eclipse-leda-utils_0.0.2.0.00680_all.deb
   command -v sdv-health
   
   wget "https://github.com/eclipse-leda/leda-utils/releases/download/v0.0.2/eclipse-leda-kantui_0.0.2.0.00680_amd64.deb"
   apt-get install -y ./eclipse-leda-kantui_0.0.2.0.00680_amd64.deb
   command -v kantui
   
   wget "https://github.com/eclipse-leda/leda-utils/releases/download/v0.0.2/eclipse-leda-kanto-auto-deployer_0.0.2.0.00680_amd64.deb"
   apt-get install -y ./eclipse-leda-kanto-auto-deployer_0.0.2.0.00680_amd64.deb
   command -v kanto-auto-deployer
   

4. Download the Debian package eclipse-leda-container-*.deb from the Eclipse Meta-Leda release page:

   wget "https://github.com/eclipse-leda/meta-leda/releases/download/0.1.0-M2/eclipse-leda-containers_0.1.0.2.0.422_all.deb"
   apt-get install -y ./eclipse-leda-containers_0.1.0.2.0.422_all.deb
   

5. Run the kanto-auto-deployer to deploy the core components:

   kanto-auto-deployer /var/containers/manifests
   

   To install the example containers, run the following:

   kanto-auto-deployer /var/containers/manifests/examples
   

Configuration Hacks

• Mosquitto must be configured to allow anonymous access and listen on the network interface available to the containers. The easiest (and least secure!) configuration would be:

  /etc/mosquitto/conf.d/public.conf:

  listener 1883 0.0.0.0
  allow_anonymous true
  

  Attention: Only apply this configuration on a device in a secured network, or adapt the configuration accordingly (e.g. specify internal IP address)

2.7 - Cheatsheet

This cheat sheet gives you an overview of common command line commands to interact with the tools available on the quickstart image.

General Commands

Configuring NTP

A failed download of container images may be caused by out-of-sync clock, thus failing the TLS certificate validation. A hardware device without hardware clock (such as the Raspberry Pi) relies on network time. In some (corporate) networks, there might be rogue NTP servers and it might be necessary to override the NTP sources.

To reset NTP server to a public server, follow these steps:

# Check NTP clock sync
timedatectl timesync-status
# Add your NTP server
vi /etc/systemd/timesyncd.conf
# Restart container management
systemctl restart container-management
systemctl restart kanto-auto-deployer

Reset container deployment

When things go really wrong and the container runtime is unable deploy containers properly, it may be necessary to reset the internal state. This is achieved by stopping the container runtime(s) and deleting the /var/lib/container-management folder:

# Stop all container runtimes
systemctl stop container-management 
systemctl stop containerd

# Delete the persistence of container management
# Attention! Here be dragons
rm -rf /var/lib/container-management

# Restart the container runtimes
systemctl start containerd
systemctl start container-management

# Redeploy the containers
systemctl restart kanto-auto-deployer

Running custom ad-hoc containers

To install arbitrary containers, create the container using the kanto-cm command line tool. If it’s not a background service, but a cli tool, adding the --t --i options allows console access.

root@qemux86-64:~# kanto-cm remove --name python
root@qemux86-64:~# kanto-cm create --name python --t --i --privileged docker.io/library/python:3.8.16-slim-bullseye
bf9deca4-dbf1-4132-9ba7-e0f378bd34a7
root@qemux86-64:~# kanto-cm start --name python --a --i
Python 3.8.16 (default, Jan 24 2023, 00:19:05) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> quit()

Raspberry Pi Overlays

Edit /boot/config.txt and reboot:

# Disable to fix non-working standard Raspberry Pi 7" display
# dtoverlay=vc4-kms-v3d

# PiCAN 2
# dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=25

# Waveshare RS485 CAN Hat
# dtoverlay=mcp2515-can0,oscillator=12000000,interrupt=25,spimaxfrequency=2000000

2.8 - Utilities

The quickstart image contains the following utilities. These utility scripts are meant to be convenience tools for users and developers. They help to experiment with the container deployment, device provisioning or vehicle data access.

• sdv-health: Show SDV software components health status
• kantui: A text user interface for kanto-cm to manage containers (start, stop, logs, redeploy all)
• sdv-device-info: Show and update device information
• sdv-provision: Generate device certificates and configuration of cloud connection
• sdv-motd: Message-of-the-Day shown after login prompt
• can-forward: Forwarding a CAN-bus network interface into a containerized Vehicle Application
• kanto-auto-deployer: Automatically deploys containers on boot. Runs as a systemd service, and can also be invoked by a user directly.
• sdv-ctr-exec: Execute arbitrary commands in existing containers
• sdv-kanto-ctl: Manage the Kanto Container Management configuration via CLI
• blueprint-selector: Deploy and fetch new SDV blueprints easily with an interactive CLI

Note: These scripts are not meant to be reused or called from production software. Their behaviour or command line syntax is not a stable API and should not be trusted for automation purposes. For details, please see leda-utils

2.8.1 - SDV Health

Health check

The sdv-health utility displays a status overview of some important dependencies and device configurations for the SDV edge stack. The sdv health utility can be configured using the sdv.conf configuration file.

Usage:

# sdv-health

Example output:

Version Information

The Leda image version and build time will be displayed at the top in the first category:

• OS Release: Year and codename of the release version
• Image Version: Name of the image and more specific version information, such as the git tag or commit id
• Build timestamp in yyyMMddHHmmss notation

Note: The information is read from the system base file in /etc/os-release:

root@qemux86-64:~# cat /etc/os-release 
BUILD_ID="20230309083051"
DISTRO_CODENAME="Dracon"
ID=leda
IMAGE_VERSION="0.0.5-41-g82f2b12"
NAME="Eclipse Leda"
PRETTY_NAME="Eclipse Leda 2023 (Dracon)"
VERSION="2023 (Dracon)"
VERSION_CODENAME="Dracon"
VERSION_ID=0.0.5-41-g82f2b12

Bus networks

If available, vehicle bus network information, such as the status of the CAN-Bus, will be displayed iin its own category. This helps to quickly identify if there problems with the hardware connectivity for automotive bus networks.

Ports

The health utility checks the TCP ports of specific services. This helps to identify if these services are up and running and potentiallyconnectable via external network interfaces.

Services and Containers

The services category shows the status of required and optional containers. The required containers are supposed to be up and running for the SDV.EDGE stack to be correctly up and running. If any of these core components have a failed state, the functionality is impacted.

The optional containers are for additional features and for example applications. These containers may not be necessary for each use case and hence will be marked as a warning if they are not up and running. The overview still helps to identify which containers are working properly.

Errors, Warnings, Failed states

When there are errors or warnings related to the status of SDV related components, the health utility will print out these error states, and if available also a more detailed error message.

In the following example, the health utility helps the troubleshooting process:

• The container runtime is properly started: “Kanto CM” is OK in the “SDV Ports” section and the “container-management” service is OK in the “SDV Services” section".
• Some containers are in state “OK”, which means there is no general issue with the container runtime.
• The cloud connector is in a “Stopped” state, which indicates that the user manually stopped the container by using “kanto-cm stop -n cloud-connector”.
• The sua container is in a “Exited” state, which indicates the process exited with an error code.

2.8.2 - KantUI

The KantoUI tool is a text-based user interface for conveniently managing containers in the Kanto Container Management. It supports simple navigation using keyboard and mouse to select a specific container. Commands to start, stop, remove and re-deploy containers are available along with a functionality to retrieve the application logs of a selected container.

Kanto User Interface

Usage:

kantui

Example output:

Command Line Options

Print command line help:

root@qemux86-64:~# kantui --help
kantui 0.2.0
A TUI for Kanto CM that allows easier management of deployed containers. Requires root.

USAGE:
    kantui [OPTIONS]

OPTIONS:
    -c, --config-file-path <CONFIG_FILE_PATH>
            Set a custom path for the kantui configuration file [default:
            /etc/kantui/kantui_conf.toml]

    -h, --help
            Print help information

    -V, --version
            Print version information

Note: All config values can be overridden through env variables prefixed with KANTUI_,
e.g. KANTUI_STOP_TIMEOUT=5 overrides the timeout before SIGKILL is sent to be 5 seconds.

Keyboard commands

• Arrow keys Up and Down to select a container
• Arrow keys Left and Right to select a column
• Enter to change the sort ordering of the currently selected column
• S to start the selected container which is currently not running
• P to stop the selected container
• R to remove a container
• L to show the log output of a container
• D to redeploy an existing container (rereads deployment descriptor)
• Q to quit kantui

Note: The mouse can be used to select ui items when holding the Shift key.

Starting, Stopping, Removing containers

To use the lifecycle commands on a container:

1. Select a container by using the mouse or the arrow keys.
2. The selected container is highlighted.
3. Press one of the lifecycle commands, e.g. s, p or r
4. Wait for the value in the State column to change, before issueing the next command.

Note: When using the lifecycle commands for containers (Start, Stop, Remove), it may take a few seconds before the UI is updated with the status changes. The amount of time before a container is forcefully killed is determined by the stop_timeout configuration option.

Show container Logs

To view the container’s log output:

1. Select a container by using the mouse or the arrow keys.
2. Press the L key
3. Log output will be displayed (tail, oldest messages first)
4. Use the arrow keys Up and Down or drag the scrollbar using your mouse to scroll through the log
5. Close the Log viewer by pressing Enter or clicking on the OK button

Note: The log output is not followed automatically. Close the dialog and reopen to see new output.

Redeploying containers

To redeploy a container, e.g. when a deployment descriptor has changed on disk:

1. Select a container by using the mouse or the arrow keys.
2. Press the P key to stop the container
3. Press the R key to remove the container
4. Press the D key to invoke the Kanto Auto Deployer, which will redeploy the missing containers

Note: Only containers managed by Kanto Auto Deployer will be redeployed.

Column Sorting

To sort a column:

1. Select the column using the Left and Right arrow keys
2. Press Enter to activate sorting
3. Press Enter again on a sorted column to invert sort order (Ascending -> Descending -> Ascending)

Note: The selected sort order is not persisted and will reset to the default on restart: By ID, ascending

Configuration File

The default location of the configuration file is /etc/kantui/kantui_conf.toml:

# General Configuration Options
socket_path = "/run/container-management/container-management.sock" # Path to kanto-cm unix socket
stop_timeout = 5 # timeout (integer) in seconds before a SIGKILL is sent after a SIGTERM

[keyconfig]
start_btn_name = "[S]tart"
start_kbd_key = "s"

stop_btn_name = "Sto[P]"
stop_kbd_key = "p"

remove_btn_name = "[R]emove"
remove_kbd_key = "r"

logs_btn_name = "[L]ogs"
logs_kbd_key = "l"

quit_btn_name = "[Q]uit"
quit_kbd_key = "q"

redeploy_btn_name = "Re[D]eploy"
redeploy_kbd_key = "d"
# Includes a shell lexer so anything that would be a valid shell command can be used
# No pipes/redirects allowed.
# N.B.: Command inherits kantui's privileges (root)
redeploy_command = "systemctl restart kanto-auto-deployer.service"

2.8.3 - SDV Device Info

Displays the current device configuration, such as Device ID.

Note: Requires the Cloud Connector component to be configured and running.

Usage:

sdv-device-info

Usage

Synposis: ./sdv-device-info [options] [command]

Full help:

root@qemux86-64:~# sdv-device-info --help
sdv-device-info v0.2
Usage: /usr/bin/sdv-device-info [options] [command]
Show SDV device configuration information
Example: /usr/bin/sdv-device-info show

Commands:
 show                 : Display configuration (default command)
 help                 : This message
 env                  : Format output for use in scripts

Options:
 --ansi | -a      : Don't use colored output.
 --norestart | -n : Do not automatically restart services
 --verbose | -v   : Enable verbose mode.
 --help | -h      : This message.

Use in scripts

To use device information on other scripts, it may be useful to source the device information variables into the current environment variable context:

Synposis: source ./sdv-device-info env

Example:

$ source ./sdv-device-info env
$ echo $DEVICE_ID
exampledevice1

2.8.4 - SDV Provision

The provisioning helper script can be used to manually perform a device provisioning with a cloud backend.

It is meant as a convenient tool for developers, who wish to connect their device to a selfmanaged cloud backend directly. In a production environment, the device provisioning functionality is implemented either by the Cloud Connector component.

The provisioning script currently supports the following backend and authentication options:

• Azure IoT Hub
  • Connection String
  • Device Certificates
• Azure IoT Device Provisioning Service
  • Device Certificates

Usage

The sdv-provision script is interactive and asks for the type of backend and authentication option:

root@qemux86-64:~# sdv-provision 
Checking Eclipse Leda Device Provisioning configuration...
- Certificates directory exists
Checking Device ID
- Based on network device: eth0
- Device ID: 52-54-21-4c-f9-5a
Checking whether either IdScope or ConnectionString is configured
 - Neither Id Scope file nor ConnectionString found, needs manual configuration
Do you want to use the global Azure IoT Device Provisioning Service (DPS) by using an Id Scope, or do you want to use a direct connection to a specific Azure IoT Hub using a Connection String?
d) Azure IoT Device Provisioning Service (DPS) with Id Scope
h) Azure IoT Hub with Connection String
Choose:d
Please enter your Id Scope of the Azure IoT Device Provisioning Service:example
Recreating the Cloud Connector container...
Checking device certificates
- All device certificates are present
- Primary device certificate: /data/var/certificates/device.crt
- Primary device private key: /data/var/certificates/device.key
- Secondary device certificate: /data/var/certificates/device2.crt
- Secondary device private key: /data/var/certificates/device2.key
Fingerprints (add these to the Azure IoT Hub Device)
- Primary thumbprint: 1B172ED3D06F4E25AFFEF675ADCE519457FFFFFF
- Secondary thumbprint: B6CD5EACE96E9D0448BCB0BAED2DEE87AFFFFFFF

Once a configuration has been selected, the script will:

• Generate a random Device Id (based on physical network address)
• Store the Device Id in /etc/deviceid
• Generate a primary self-signed device certificate pair
• Generate a secondary self-signed device certificate pair
• Store the certificates in /data/var/certificates/
• Reconfigure the container descriptor in /data/var/containers/manifests_dev/cloudconnector.json
• Restarting the Cloud Connector container
• Print the key fingerprints, used for onboarding the device in Azure IoT Device Provisioning Service

Reconfiguration

Note: Re-running the script will only print the existing configuration.

To reconfigure the device and use different options, perform the following steps:

1. Delete the generated files

   rm /data/var/certificates/azure.idscope
   rm /data/var/certificates/azure.connectionstring
   rm /data/var/certificates/device*.crt
   rm /data/var/certificates/device*.key
   

2. Rerun the script

   sdv-provision
   

2.8.5 - SDV MotD

The sdv-motd script provides an alternative motd profile, which displays some additional information after login.

The script does not have any command line options.

Example output:

2.8.6 - CAN Forward

The can-forward help script can be used to forward an existing CAN-Bus interface on the host system to a container process.

Note: Warning! The script does not yet support Kanto (or containerd) as a container runtime. It has been implemented for k3s.

Usage

root@qemux86-64:~# can-forward --help

Usage:  /usr/bin/can-forward {-h} {-p PID} {-c container} <hw_can>

  hw_can          Host CAN hw interface to forward. Default: can0
  -c container    Attemmpt to get netns PID from a running container: (docker, ctr). Default: seat_service
  -p PID          Use provided PID for transferring vxcan interface (e.g.: docker inspect -f '{{ .State.Pid }}' container)
  -h              Prints this message

The script performs the following steps:

• Find the process ID of the target container process
• Check and modprobe vxcan
• Check and modprobe can-gw
• Create a new virtual CAN interface (vxcanX)
• Create a new virtual CAN interface (vxcanX+1)
• Link both interfaces together
• Move the second interface (vxcanX+1) into the namespace of the target container
• Set up a bi-directional CAN-Bus packet forwarding between both interfaces using cangw

2.8.7 - Kanto Auto Deployer (KAD)

Automatically deploys containers to the Kanto Container Management based on deployment descriptors from a given path. All deployment descriptors in the manifests folder will be deployed (created and started) on startup of the service. The directory will then be monitored for creation of/changes to manifests and those changes will be redeployed.

Usage

Usage:

$ kanto-auto-deployer --help
kanto-auto-deployer 0.2.0
Automated deployment of Kanto Container Management Manifests

USAGE:
    kanto-auto-deployer [OPTIONS] [MANIFESTS_PATH]

ARGS:
    <MANIFESTS_PATH>    Set the path to the directory containing the manifests [default: .]

OPTIONS:
    -d, --daemon                   Run as a daemon that continuously monitors the provided path for
                                   changes
    -h, --help                     Print help information
    -s, --socket-cm <SOCKET_CM>    Set the path to the Kanto Container Management API socket
                                   [default: /run/container-management/container-management.sock]
    -V, --version                  Print version information

Example:

# Use container manifests from current working directory
root@qemux86-64:/data/var/containers/manifests# kanto-auto-deployer 
[2023-04-18T10:27:21Z INFO  kanto_auto_deployer] Running initial deployment of "/data/var/containers/manifests"
[2023-04-18T10:27:21Z INFO  kanto_auto_deployer] Reading manifests from [/data/var/containers/manifests]
[2023-04-18T10:27:21Z WARN  kanto_auto_deployer::manifest_parser] Failed to load manifest directly. Will attempt auto-conversion from init-dir format.
[2023-04-18T10:27:21Z INFO  kanto_auto_deployer] Already exists [cloudconnector]
[2023-04-18T10:27:21Z WARN  kanto_auto_deployer::manifest_parser] Failed to load manifest directly. Will attempt auto-conversion from init-dir format.
[2023-04-18T10:27:21Z INFO  kanto_auto_deployer] Already exists [databroker]

# Use container manifests from specified directory
root@qemux86-64:~# kanto-auto-deployer /data/var/containers/manifests/
[2023-04-18T10:27:44Z INFO  kanto_auto_deployer] Running initial deployment of "/data/var/containers/manifests"
[2023-04-18T10:27:44Z INFO  kanto_auto_deployer] Reading manifests from [/data/var/containers/manifests]
[2023-04-18T10:27:44Z WARN  kanto_auto_deployer::manifest_parser] Failed to load manifest directly. Will attempt auto-conversion from init-dir format.
[2023-04-18T10:27:44Z INFO  kanto_auto_deployer] Already exists [cloudconnector]
[2023-04-18T10:27:44Z WARN  kanto_auto_deployer::manifest_parser] Failed to load manifest directly. Will attempt auto-conversion from init-dir format.
[2023-04-18T10:27:44Z INFO  kanto_auto_deployer] Already exists [databroker]

Nоte: The warnings from the manifest_parser module are normal and expected when the manifest is in the Container Management Manifests Format

Usage as systemd service

In the Leda quickstart images, kanto-auto-deployer is installed as a systemd service.

Note the service uses the --daemon flag that asks KAD to continuously monitor the specified directory (see last line of logs).

The service unit configuration file is located in /lib/systemd/system/kanto-auto-deployer.service:

[Unit]
Description=Kanto Auto Deployer
After=network-online.target container-management.service
Wants=network-online.target container-management.service
Requires=container-management.service

[Install]
WantedBy=multi-user.target

[Service]
Restart=on-failure
RestartSec=5s
ExecStart=/usr/bin/kanto-auto-deployer /data/var/containers/manifests --daemon

Example output:

root@qemux86-64:/lib/systemd/system# systemctl status kanto-auto-deployer.service 
* kanto-auto-deployer.service - Kanto Auto Deployer
     Loaded: loaded (/lib/systemd/system/kanto-auto-deployer.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2023-04-18 10:22:10 UTC; 3min 55s ago
   Main PID: 525 (kanto-auto-depl)
      Tasks: 10 (limit: 4708)
     Memory: 1.4M
     CGroup: /system.slice/kanto-auto-deployer.service
             `- 525 /usr/bin/kanto-auto-deployer /data/var/containers/manifests --daemon

Apr 18 10:22:48 qemux86-64 kanto-auto-deployer[525]: [2023-04-18T10:22:48Z INFO  kanto_auto_deployer] Creating [sua]
Apr 18 10:23:04 qemux86-64 kanto-auto-deployer[525]: [2023-04-18T10:23:04Z INFO  kanto_auto_deployer] Created [sua]
Apr 18 10:23:04 qemux86-64 kanto-auto-deployer[525]: [2023-04-18T10:23:04Z INFO  kanto_auto_deployer] Starting [sua]
Apr 18 10:23:05 qemux86-64 kanto-auto-deployer[525]: [2023-04-18T10:23:05Z INFO  kanto_auto_deployer] Started [sua]
Apr 18 10:23:05 qemux86-64 kanto-auto-deployer[525]: [2023-04-18T10:23:05Z WARN  kanto_auto_deployer::manifest_parser] Failed to load manifest directly. Will attempt auto-conversion from init-dir format.
Apr 18 10:23:05 qemux86-64 kanto-auto-deployer[525]: [2023-04-18T10:23:05Z INFO  kanto_auto_deployer] Creating [vum]
Apr 18 10:23:10 qemux86-64 kanto-auto-deployer[525]: [2023-04-18T10:23:10Z INFO  kanto_auto_deployer] Created [vum]
Apr 18 10:23:10 qemux86-64 kanto-auto-deployer[525]: [2023-04-18T10:23:10Z INFO  kanto_auto_deployer] Starting [vum]
Apr 18 10:23:11 qemux86-64 kanto-auto-deployer[525]: [2023-04-18T10:23:11Z INFO  kanto_auto_deployer] Started [vum]
Apr 18 10:23:11 qemux86-64 kanto-auto-deployer[525]: [2023-04-18T10:23:11Z INFO  kanto_auto_deployer] Running in daemon mode. Continuously monitoring "/data/var/containers/manifests"

2.8.8 - SDV Container Exec

The sdv-ctr-exec wrapper allows to execute arbitrary user commands in existing containers. Kanto Container Management cli tool (kanto-cm) only allows to manage the lifecycle of a container, but does not allow to specify or override the entrypoint or command definitions of an existing container. The ctr command line tool of containerd allows the execution of additional tasks in a running container.

Usage

As a convenient tool, sdv-ctr-exec allows the simple execution of arbitrary commands inside of containers. This is especially useful for non-service-containers, or containers which have additional binaries (e.g. cli tools) embedded.

Usage:

root@qemux86-64:~# sdv-ctr-exec 
/usr/bin/sdv-ctr-exec -h to print this message

Usage:
/usr/bin/sdv-ctr-exec <container-id> <command>
or
/usr/bin/sdv-ctr-exec -n <container-name> <command>

Example:

# Executing a containerized cli tool using sdv-ctr-exec
kanto-cm create --i --t --network=host --name=kuksa-client ghcr.io/eclipse/kuksa.val/kuksa-client:master
kanto-cm start --name=kuksa-client
sdv-ctr-exec -n kuksa-client /kuksa-client/bin/kuksa-client --port 30555 --protocol grpc --insecure

Alternatives

containerd: ctr

The above commands are equivalent to the following commands:

# Executing a containerized cli tool using ctr
ctr --namespace kanto-cm image pull ghcr.io/eclipse/kuksa.val/kuksa-client:master
ctr --namespace kanto-cm container create --net-host --tty ghcr.io/eclipse/kuksa.val/kuksa-client:master kuksa-client
ctr --namespace kanto-cm tasks start --detach kuksa-client
ctr --namespace kanto-cm tasks exec --tty --exec-id sometask kuksa-client /kuksa-client/bin/kuksa-client --port 30555 --protocol grpc --insecure

containerd: nerdctl

Note: nerdctl is currently not installed on the Leda Quickstart images.

containerd: ctr and mounting

To execute a binary natively (outside of a containerized environment), the container image may be mounted to the host filesystem using the ctr snapshots mount commands.

This approach only works if the binary is compatible with the host environment (dependencies, libraries etc.).

$CONTAINER_IMAGE="ghcr.io/my-org/my-project/my-container"
ctr --namespace kanto-cm image pull $CONTAINER_IMAGE
ctr --namespace kanto-cm container create --net-host --tty $CONTAINER_IMAGE my-container
mkdir my-container
ctr --namespace=kanto-cm snapshots mount my-container my-container | $SHELL
cd my-container
./bin/my-application --help