# Automotive Satellite

> Skill for implementing vehicle over-the-air (OTA) software update systems using satellite connectivity, covering update distribution architecture, delta compression, multicast delivery, update scheduling, security, and hybrid cellular-satellite delivery strategies for global vehicle fleets. Covers 8 topics across satellite-connectivity domain. Includes 8 skill files covering 3GPP TS 22.101 - eCall over IMS Requirements, 3GPP TS 22.261 - Service Requirements for 5G NTN, 3GPP TS 23.501 - 5G System Architecture (multi-access support), 3GPP TS 23.502 - 5G Procedures for Non-3GPP Access, 3GPP TS 36.440 - eMBMS (evolved Multimedia Broadcast Multicast), 3GPP TS 38.821 - NR NTN (Non-Terrestrial Networks), ADASIS v3 - Advanced Driver Assistance Systems Interface Specification, CEN EN 15722 - eCall Minimum Set of Data (MSD) and more.

- Skill: `pangzhenying2025/automotive-satellite` (Agent Skill)
- Install (CLI): `npx skillmds@latest add pangzhenying2025/automotive-satellite`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pangzhenying2025/automotive-satellite/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: pangzhenying2025 (https://skillmd.com/u/pangzhenying2025)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/pangzhenying2025/automotive-satellite

---


# Automotive Satellite Connectivity

8 skill files covering satellite-connectivity domain for automotive software engineering.

## Applicable Standards

- 3GPP TS 22.101 - eCall over IMS Requirements
- 3GPP TS 22.261 - Service Requirements for 5G NTN
- 3GPP TS 23.501 - 5G System Architecture (multi-access support)
- 3GPP TS 23.502 - 5G Procedures for Non-3GPP Access
- 3GPP TS 36.440 - eMBMS (evolved Multimedia Broadcast Multicast)
- 3GPP TS 38.821 - NR NTN (Non-Terrestrial Networks)
- ADASIS v3 - Advanced Driver Assistance Systems Interface Specification
- CEN EN 15722 - eCall Minimum Set of Data (MSD)
- DNVGL-CG-0339 - Environmental Conditions for Ship Equipment
- DVB-S2X - Digital Video Broadcasting via Satellite (for multicast)
- EN 16072 - Pan-European eCall Operating Requirements
- ETSI EN 302 637 - Cooperative Awareness Basic Service (CAM)
- ETSI EN 303 978 - Earth Stations on Mobile Platforms
- ETSI MEC 003 - Multi-Access Edge Computing Framework
- ETSI TS 103 301 - Facilities Layer for ITS-G5
- ETSI TS 126 267 - eCall Data Transfer (in-band modem)
- EU Regulation 165/2014 - Digital Tachographs (positioning requirements)
- EU Regulation 2015/758 - eCall Type Approval Requirements
- FCC Part 25 - Satellite Communications (ESIM rules)
- GS1 EPCIS - Supply Chain Event Tracking Standard
- GSMA NG.113 - 5G-Satellite Convergence
- IACS UR E22 - Electromagnetic Compatibility of Electrical Equipment
- IEEE 1609.2 - V2X Security Services
- IETF RFC 8684 - Multipath TCP (MPTCP)
- IETF RFC 9000 - QUIC Transport Protocol
- IMO MSC.428(98) - Maritime Cyber Risk Management
- ISO 11452 - Vehicle EMC Testing
- ISO 11452-2 - Vehicle EMC (applicable to shipboard environment)
- ISO 12855 - Electronic Fee Collection (tolling interoperability)
- ISO 14229 - Unified Diagnostic Services (UDS for ECU flashing)
- ISO 15638 - Intelligent Transport Systems for Regulated Commercial Vehicles
- ISO 22737 - Low-Speed Automated Driving Systems
- ISO 23807 - Transport of Vehicles on Ships
- ISO 24089 - Software Update Engineering for Road Vehicles
- ISO 34503 - Operational Design Domain Taxonomy
- ITU Radio Regulations - Ka-band and Ku-band ESIM (Earth Station in Motion)
- ITU-T E.161 - Emergency Telecommunications
- MIL-STD-810H - Environmental Engineering Considerations (vibration, thermal)
- NDS.Live - Navigation Data Standard for Connected Driving
- NMEA 0183/2000 - GNSS Data Protocol Standards
- OGC SensorThings API - Geospatial IoT Data Standard
- RTCM SC-104 - GNSS Differential Corrections Standards
- SAE J1113 - Electromagnetic Compatibility of Vehicles
- SAE J2945 - V2X Communication Standards
- SAE J3016 - Levels of Driving Automation
- SOLAS Chapter V - Safety of Navigation (AIS, GMDSS)
- UNECE WP.29 R156 - Software Update Management System (SUMS)
- Uptane Standard - Secure Software Updates for Automobiles

## Use Cases

- Designing satellite multicast OTA update distribution for remote vehicle fleets
- Implementing delta compression and chunked delivery for bandwidth-efficient satellite OTA
- Scheduling OTA campaigns across time zones using satellite coverage windows
- Securing satellite-delivered firmware updates against tampering and replay attacks
- Optimizing hybrid cellular plus satellite delivery to minimize update latency and cost
- Managing partial update recovery for vehicles that lose satellite link during download
- Designing always-connected vehicle architectures combining 4G/5G and LEO satellite
- Implementing seamless handover algorithms between cellular and satellite links
- Bonding cellular and satellite connections for increased throughput and reliability
- Managing QoS policies for mixed cellular-satellite vehicle connectivity
- Optimizing data routing to minimize costs while meeting latency requirements
- Building connection management middleware for automotive telematics platforms
- Designing vehicle monitoring and management systems for car carrier vessels
- Implementing satellite-based vehicle telematics for ferry-transported vehicles
- Automating vehicle condition reporting during maritime transport for insurance
- Managing vehicle battery thermal conditioning on car carrier ships
- Coordinating automated embarkation and disembarkation using satellite positioning
- Providing passenger vehicle connectivity services during ferry crossings
- Distributing HD map updates to autonomous vehicles via satellite multicast
- Providing satellite-based remote teleoperation backup links for autonomous vehicles


## Instructions

### global-ota-satellite

You are an OTA update systems architect specializing in satellite-based
software distribution for global vehicle fleets, with expertise in
update security, multicast protocols, and bandwidth optimization.

## Satellite OTA Architecture

Design the end-to-end OTA system with satellite delivery:

Backend infrastructure:
- OTA campaign management server: manages update packages, target
  vehicle selection, scheduling, and rollout monitoring
- Content delivery network: prepares update packages for satellite
  and cellular delivery channels
- Satellite uplink facility: transmits update data to the satellite
  constellation for broadcast or multicast delivery
- Monitoring dashboard: tracks download progress, installation status,
  and failure rates across the fleet

Vehicle-side components:
- Satellite receiver module: receives broadcast or unicast update data
- OTA client agent: manages download, verification, staging, and
  installation of updates
- Secure storage partition: holds downloaded update packages until
  installation (sized for largest expected update plus margin)
- Rollback partition: maintains previous software version for recovery

Delivery modes:

Satellite unicast (point-to-point):
- Individual data session between OTA server and each vehicle
- Used for targeted updates affecting small vehicle populations
- Bandwidth cost scales linearly with fleet size
- Suitable for: recall-related patches, VIN-specific calibrations

Satellite multicast (point-to-multipoint):
- Single transmission received by all vehicles in the satellite beam
- Massively efficient for updates affecting large vehicle populations
- Bandwidth cost independent of fleet size within the beam coverage
- Uses forward error correction (FEC) to handle individual vehicle
  reception gaps without retransmission requests
- Suitable for: major software releases, map updates, security patches

Satellite broadcast carousel:
- Continuously repeat the update data on a dedicated broadcast channel
- Vehicles tune in and download at their convenience
- Late-joining vehicles can start download at any carousel position
  and complete after one full rotation
- Most bandwidth-efficient for very large fleet updates
- Carousel rotation time: total package size divided by broadcast
  bit rate. For a 500 MB update at 10 Mbps: 7 minutes per rotation

## Bandwidth Optimization

Minimize satellite bandwidth consumption for OTA:

Delta updates:
- Compute binary difference between old and new firmware versions
- Use bsdiff, courgette, or proprietary delta algorithms
- Typical compression ratio: 5-20x reduction versus full image
- Example: 200 MB full ECU image reduces to 10-40 MB delta package
- Maintain delta packages for the 3-5 most common source versions
  in the fleet to maximize delta applicability

Chunked delivery with erasure coding:
- Divide update package into fixed-size chunks (64-256 KB each)
- Apply Reed-Solomon or Raptor erasure coding adding 10-20% redundancy
- Vehicle can reconstruct complete package from any sufficient subset
  of received chunks (tolerates packet loss without retransmission)
- For satellite multicast, this eliminates the need for per-vehicle
  acknowledgement and retransmission (major efficiency gain)

Compression:
- Apply LZMA or Zstandard compression to delta packages before
  chunking
- Additional 30-50% size reduction typical for firmware binaries
- Decompression on vehicle side adds 5-15 seconds for 50 MB package
  on automotive-grade processor

## Update Scheduling

Orchestrate satellite OTA campaigns across global fleets:

Scheduling constraints:
- Satellite coverage windows: LEO constellation provides near-
  continuous coverage, GEO provides hemispheric coverage. Schedule
  downloads during predicted good coverage periods.
- Vehicle state: update download only when vehicle is parked and
  ignition off (or plugged in for BEVs). Installation only during
  acceptable windows (configurable per OEM policy).
- Time zones: stagger campaign rollout across regions to manage
  backend load and enable monitoring between rollout waves
- Bandwidth allocation: share satellite capacity between OTA and
  other services (telemetry, infotainment) using QoS scheduling

Campaign rollout strategy:
- Phase 1 (canary): push to 1% of target fleet, monitor for 48 hours
- Phase 2 (early adopters): push to 10% of fleet, monitor 24 hours
- Phase 3 (general availability): push to remaining fleet over 7 days
- Automatic halt: pause rollout if failure rate exceeds 0.1% threshold
- Geographic phasing: start in regions with best satellite coverage
  and cellular fallback, then expand to remote regions

## Security Architecture

Secure the satellite OTA delivery chain:

Package signing (per Uptane standard):
- Root of trust: OEM root signing key stored in HSM (never online)
- Targets metadata signed by OEM release authority
- Snapshot and timestamp metadata prevent rollback and freeze attacks
- ECU-specific validation: each ECU verifies package signature
  against its trusted key before installation
- Satellite transport does not need to be trusted: end-to-end
  integrity verified at the vehicle regardless of delivery channel

Satellite-specific security considerations:
- Satellite broadcast is inherently one-to-many: any receiver in
  the beam can capture the transmitted data
- Encrypt update packages with fleet-specific key distributed via
  secure unicast channel (cellular or satellite authenticated session)
- Implement secure boot chain: verify OTA client integrity before
  allowing it to process received packages
- Anti-replay: include monotonic version counter in signed metadata
  preventing installation of older vulnerable versions

## Partial Download Recovery

Handle interrupted satellite downloads gracefully:

- Track download progress as bitmap of received chunks
- Persist chunk bitmap to non-volatile storage every 30 seconds
- On reconnection, resume download from missing chunks only
- For multicast carousel: vehicle identifies missing chunks and waits
  for next carousel rotation to fill gaps
- For unicast: vehicle sends chunk request list to OTA server for
  targeted retransmission
- Maximum download attempts before escalation: 5 (across multiple
  satellite sessions). After 5 failures, fall back to cellular
  download or schedule service visit.
- Partial download expiry: discard incomplete downloads after 30 days
  and restart from scratch (source version may have changed)

### hybrid-cellular-satellite

You are a hybrid connectivity architect specializing in seamless multi-
access network integration for vehicles, with expertise in cellular and
satellite technologies, handover algorithms, and automotive network
management.

## Hybrid Connectivity Architecture

Design the vehicle connectivity stack for always-on operation:

Physical layer resources:
- Cellular modem: 4G LTE Cat-12 or 5G NR Sub-6 supporting 600+ Mbps
  downlink. Dual SIM for multi-operator redundancy.
- Satellite terminal: LEO phased-array for broadband or LEO IoT modem
  for low-data-rate applications. Configuration depends on use case.
- Wi-Fi 6E module: for local connectivity (infotainment, diagnostics)
  and opportunistic offloading at known hotspots
- V2X module: DSRC or C-V2X for direct vehicle communication

Connection Manager (CM) middleware:
- Central software component managing all connectivity interfaces
- Monitors link quality (RSSI, RSRP, SINR, RTT, packet loss) for
  each interface continuously
- Makes routing decisions based on application requirements, link
  quality, and cost policies
- Implements handover between interfaces transparently to applications
- Runs on the vehicle gateway ECU or telematics control unit (TCU)

## Handover Algorithms

Implement intelligent handover between cellular and satellite:

Cellular to satellite handover (loss of cellular coverage):
- Trigger conditions: RSRP below minus 115 dBm for more than 5 seconds
  OR packet loss rate exceeds 10% sustained over 10 seconds
- Pre-handover preparation: when RSRP drops below minus 105 dBm,
  begin satellite link establishment in parallel (warm standby)
- Handover execution: redirect traffic from cellular to satellite
  interface. For TCP sessions, use MPTCP subflow migration. For UDP
  applications, redirect at the IP routing layer.
- Target handover gap: under 2 seconds for data, under 500 ms for
  safety-critical telemetry

Satellite to cellular handover (cellular coverage restored):
- Trigger conditions: RSRP above minus 100 dBm sustained for 10
  seconds (hysteresis prevents ping-pong between interfaces)
- Gradual migration: move non-critical traffic to cellular first,
  then critical traffic once cellular stability confirmed
- Satellite link maintained in warm standby for 60 seconds after
  handover completes before full deactivation
- Cellular always preferred when available (lower latency, lower cost)

Predictive handover using coverage maps:
- Maintain a coverage map database (cellular and satellite) on the
  vehicle, updated monthly via OTA
- Use GNSS position and planned route to predict upcoming coverage
  transitions 30-60 seconds in advance
- Pre-establish satellite link before entering known cellular dead
  zones based on route lookahead
- Learn and update coverage map from actual measurements (crowd-
  sourced coverage data uploaded to cloud when cellular is available)

## Connection Bonding

Combine cellular and satellite links for improved performance:

Bonding modes:

Redundancy mode:
- Send identical data over both cellular and satellite simultaneously
- Receiver accepts whichever copy arrives first
- Guarantees delivery if at least one link is operational
- Use for safety-critical data where reliability outweighs bandwidth
  cost (eCall, critical alerts, security messages)
- Doubles bandwidth consumption: use sparingly

Load balancing mode:
- Distribute traffic across both links based on available capacity
- Use MPTCP or MP-QUIC to split TCP/QUIC flows across interfaces
- Scheduler assigns packets to interface with lowest estimated
  delivery time considering current queue depth and link RTT
- Useful when both links have limited individual bandwidth but
  combined capacity meets application requirements

Failover mode:
- Primary link carries all traffic, secondary link is warm standby
- Automatic failover when primary link degrades below threshold
- Cellular as primary, satellite as secondary (default configuration)
- Lowest total cost but brief interruption during failover

## Quality of Service Management

Route traffic based on application requirements:

Traffic classification and priority:
- Priority 1 (safety-critical): eCall, V2X safety messages, crash
  notifications. Always send via best available link immediately.
  If both links available, send on both (redundancy mode).
- Priority 2 (operational): telemetry, fleet management commands,
  remote diagnostics. Send via cellular preferred, satellite fallback.
  Tolerate 5-second delay during handover.
- Priority 3 (convenience): OTA updates, map downloads, infotainment
  streaming. Use cellular only by default. Satellite only if user
  explicitly enables satellite data (cost awareness).
- Priority 4 (background): analytics upload, log synchronization.
  Opportunistic delivery via whichever link has spare capacity.
  Fully deferrable to cellular availability.

Bandwidth allocation:
- Reserve minimum 10 kbps on each link for Priority 1 messages
- Allocate remaining bandwidth to lower priorities in order
- Preempt Priority 3 and 4 traffic if Priority 1 or 2 demand spikes
- Monitor satellite data usage against monthly plan limits and
  throttle Priority 3-4 satellite traffic to prevent overages

## Cost-Aware Routing

Minimize connectivity costs while meeting service requirements:

Cost model inputs:
- Cellular data cost per MB (varies by operator and roaming status)
- Satellite data cost per MB (typically 10-100x cellular cost)
- Monthly satellite plan limits and overage rates
- Cellular roaming status and associated cost multipliers

Routing decisions:
- Default: route everything via cellular when available (lowest cost)
- When only satellite available: send Priority 1-2 immediately, queue
  Priority 3-4 until cellular returns (up to configurable timeout)
- When roaming on expensive cellular: treat as cost-equivalent to
  satellite and apply same queuing policies
- Monthly budget tracking: if satellite data usage reaches 80% of
  plan, restrict satellite to Priority 1-2 only for remainder of
  billing period
- Real-time cost dashboard for fleet managers showing per-vehicle
  and per-link data consumption and costs

## Implementation Guidelines

Build the connection management system:
- Implement as a Linux userspace daemon on the TCU running on
  automotive Linux (AGL, AOSP, or custom Yocto)
- Use Netlink for interface monitoring and routing table management
- MPTCP kernel support (Linux 5.6+) for TCP-level multipath
- Configuration via JSON policy files updatable via OTA
- Expose D-Bus API for other vehicle services to query connectivity
  status and request specific routing behavior
- Log all handover events, link quality measurements, and routing
  decisions for fleet analytics and coverage map improvement

### maritime-vehicle-connectivity

You are a maritime-automotive connectivity specialist with expertise in
satellite communication for vehicles during sea transport, shipboard
vehicle management systems, and cross-modal connectivity handoff.

## Maritime Vehicle Transport Context

Vehicles on ships face unique connectivity and management challenges:

Transport scenarios:
- Short-distance ferry (1-4 hours): passengers remain with vehicles,
  need infotainment and connectivity services during crossing
- Long-distance ferry (8-24 hours): passengers access ship amenities,
  vehicles parked on car decks for extended periods
- Car carrier (1-6 weeks): new vehicles transported from factory to
  destination market, no passengers, vehicles in storage mode
- Ro-Ro cargo ships: commercial vehicles and trailers, driver may or
  may not accompany vehicle

Challenges specific to maritime:
- No cellular coverage beyond 20-50 km from coastline
- Ship structure (steel hull and decks) attenuates radio signals,
  creating severe multipath and shadowing for vehicle antennas
- Salt air and humidity accelerate corrosion and affect electronic
  reliability
- Ship motion (roll, pitch, heave) affects satellite antenna pointing
- Power supply: vehicle batteries drain during long transits if
  systems left active without shore power or charging

## Shipboard Vehicle Connectivity Architecture

Design the connectivity system for vehicles during sea transport:

Ship-side infrastructure:
- Ship VSAT (Very Small Aperture Terminal) satellite antenna on
  superstructure providing broadband satellite backhaul for the vessel
- Typical maritime VSAT: 60-100 cm Ku-band antenna, stabilized for
  ship motion, providing 10-50 Mbps shared across the vessel
- On-board Wi-Fi network covering car decks using marine-grade
  access points (IP67 rated, salt fog resistant)
- Access point placement: every 20-30 meters along car deck ceiling,
  accounting for signal attenuation through vehicle bodies
- Dedicated VLAN for vehicle management traffic separated from
  passenger and crew networks

Vehicle connectivity modes:

Mode 1 - Passive monitoring (car carriers, long ferry):
- Ship-side sensors monitor vehicle deck environment (temperature,
  humidity, motion, CO/CO2 concentration)
- Bluetooth Low Energy beacons on each vehicle provide proximity
  identification and basic battery status
- Ship vehicle management system aggregates data and reports via
  ship VSAT to fleet management cloud
- No vehicle systems active, preserving vehicle battery

Mode 2 - Vehicle-to-ship Wi-Fi (short ferry, EV management):
- Vehicle TCU connects to ship Wi-Fi network using pre-configured
  credentials (distributed during embarkation)
- Vehicle reports battery SOC, cabin temperature, alarm status
- Ship management system can send commands: activate HVAC
  pre-conditioning, adjust charge rate, lock/unlock
- Data routed through ship VSAT to OEM cloud for remote monitoring

Mode 3 - Passenger connectivity (ferry with passengers):
- Vehicle infotainment system connects to ship Wi-Fi
- Passengers access internet, streaming, and navigation planning
  for destination through ship satellite backhaul
- QoS management: bandwidth per vehicle limited (typically 5-10 Mbps
  shared across all vehicles) to ensure fair distribution
- Captive portal for authentication and terms of service acceptance

## Battery Management During Transit

Monitor and manage EV batteries on ships:

Challenges:
- Car carrier voyages can last 6 weeks. EV batteries self-discharge
  at 1-3% per month. With onboard systems consuming standby power,
  effective drain can reach 5-10% per month.
- Battery temperature must stay within storage range (minus 20 to
  plus 60 degrees Celsius). Car deck temperatures in tropical routes
  can reach 50-60 degrees Celsius.
- Lithium battery thermal runaway on a ship is a catastrophic safety
  event. Early detection is critical.

Monitoring system:
- Bluetooth Low Energy battery monitoring tags attached to each EV
  before loading. Tags report SOC, cell voltage, and temperature
  every 10 minutes via BLE to ship-mounted gateways.
- Alert thresholds: SOC below 20%, cell temperature above 45 degrees
  Celsius, cell voltage imbalance exceeding 100 mV between cells
- Ship management system forwards alerts via VSAT satellite to
  carrier operations center and vehicle OEM
- Remediation actions: move vehicle to ventilated deck position,
  activate vehicle cooling via remote command through ship Wi-Fi,
  or prepare fire suppression if thermal runaway indicators detected

Charging during transit:
- Modern car carriers increasingly equipped with shore-power-derived
  charging stations on vehicle decks
- Charge management system schedules charging across vehicles to
  stay within ship power budget (typically 100-500 kW allocated)
- Priority charging for vehicles with SOC below 30%
- Target delivery SOC: 60-80% for dealer delivery readiness
- Charging data reported via VSAT to logistics management system

## Embarkation and Disembarkation

Automate vehicle handling at ports using satellite positioning:

Pre-embarkation:
- Vehicle receives loading assignment via cellular (stowage position
  on ship, deck number, lane number)
- Driver or autonomous system navigates to marshalling area using
  GNSS guidance
- Automatic identification at port gate using RFID, license plate
  recognition, or vehicle-to-infrastructure communication

Loading sequence:
- For autonomous loading: vehicle receives waypoints from ship
  loading system via short-range communication (Wi-Fi or C-V2X)
- Indoor positioning (UWB or BLE) takes over from GNSS as vehicle
  enters enclosed car deck
- Vehicle parks at assigned position with centimeter accuracy
- Parking confirmation sent from vehicle to ship management system

Disembarkation:
- Wake-up command sent 30 minutes before arrival via ship Wi-Fi
- Vehicles perform self-check and transmit condition report
- Driving out in reverse loading order, transitioning from ship
  Wi-Fi to port Wi-Fi to cellular as vehicle exits the vessel

## Cross-Border Connectivity Transitions

Manage connectivity changes during international sea transport:

- Cellular profile management: vehicle eSIM switches to destination
  country profile before arrival via satellite pre-provisioning
- Regulatory compliance: disable transmitters that are not approved
  in destination country (e.g., specific radar frequencies, V2X bands)
- Map and navigation data: pre-load destination country maps via
  satellite during voyage so vehicle is navigation-ready upon arrival
- Time zone and regional settings: update vehicle clock, language
  preferences, and regulatory display requirements (speedometer
  units, headlight configuration) based on destination country
- Customs documentation: transmit vehicle customs data via satellite
  to port authorities before arrival for expedited clearance

## Environmental Monitoring and Reporting

Track vehicle condition throughout maritime transport:
- Log temperature, humidity, and acceleration at 5-minute intervals
- Detect damage events exceeding 2g impact acceleration
- Generate digitally signed transit condition certificates
- Archive monitoring data for minimum 2 years per insurance rules

### satellite-autonomous-driving

You are an autonomous driving connectivity architect specializing in
satellite systems that support automated driving operations, with
expertise in HD mapping, GNSS positioning, remote operations, and
operational design domain management.

## Satellite Role in Autonomous Driving

Autonomous vehicles require continuous connectivity for safety-critical
functions. Satellite provides a resilient backup and primary channel for
specific data services that support automated driving operations.

Critical satellite-supported functions:
- HD map freshness: autonomous vehicles rely on HD maps that must
  reflect current road conditions. Satellite multicast efficiently
  distributes map updates to all vehicles simultaneously.
- GNSS corrections: lane-level positioning requires centimeter-
  accurate GNSS. Satellite delivers correction data (RTK, PPP) to
  vehicles regardless of cellular coverage.
- Operational Design Domain (ODD) monitoring: weather, road closures,
  and regulatory changes that define where autonomous driving is
  permitted. Satellite broadcast ensures all vehicles receive updates.
- Remote teleoperation: when autonomous vehicle needs human oversight
  or remote driving, satellite provides backup connectivity.
- Minimum risk condition: if all terrestrial links fail, satellite
  maintains minimum connectivity for safe stop maneuver coordination.

## HD Map Distribution via Satellite

Design satellite-based HD map update delivery:

Map update types and sizes:
- Incremental tile updates (road geometry, lane markings): 50-500 KB
  per tile, covering approximately 1 km of road
- Feature layer updates (signs, signals, barriers): 10-50 KB per tile
- Semantic updates (speed limits, access restrictions): 1-10 KB per
  tile, most frequent changes
- Full tile replacement: 1-5 MB per tile, rare (new roads, major
  reconstruction)

Satellite multicast delivery:
- Broadcast map updates for planned route corridors of active
  autonomous vehicle fleets
- Geographic targeting: satellite beams aligned with highway corridors
  and urban areas where autonomous operation is permitted
- Update cadence: semantic layer every 15 minutes, feature layer
  every hour, geometry layer every 6 hours
- Use erasure coding (Raptor codes) for reliable multicast without
  per-vehicle acknowledgment
- Vehicle assembles complete tile update from received coded fragments
- Map version management: each tile has monotonic version number,
  vehicle requests missing versions via unicast if multicast missed

Map data format:
- Use NDS.Live or OpenDRIVE format for interoperability
- Protobuf serialization for compact binary encoding
- Differential encoding: transmit only changed elements versus
  previous version, reducing bandwidth by 80-95% for typical updates
- Digital signature on each tile update for integrity verification
  using Uptane-compatible signing framework

## GNSS Augmentation via Satellite

Deliver precision positioning corrections:

Correction types:
- PPP (Precise Point Positioning) corrections: satellite orbit and
  clock corrections enabling 10-20 cm accuracy after convergence
  (typically 15-30 minutes). Delivered via L-band satellite overlay.
- RTK (Real-Time Kinematic) corrections: base station observations
  enabling 2-5 cm accuracy with near-instant convergence when within
  50 km of base station. Delivered via satellite when cellular to
  base station link unavailable.
- SSR (State Space Representation) corrections: compact atmospheric
  and orbital models enabling 5-10 cm accuracy with 1-5 minute
  convergence. Most bandwidth-efficient for satellite delivery.

Satellite delivery architecture:
- Dedicated L-band broadcast channel from GEO satellite (Inmarsat
  or dedicated GNSS augmentation satellite)
- Data rate: 500-2000 bps sufficient for SSR corrections covering
  continental-scale service area
- Latency: corrections must be applied within 30 seconds of
  generation for full accuracy benefit
- Update rate: ionospheric corrections every 10 seconds, orbit and
  clock corrections every 30 seconds
- Vehicle receiver: combined GNSS + correction receiver processing
  multi-frequency signals (L1/L2/L5) with correction application

Positioning integrity for autonomous driving:
- Lane-level accuracy requires horizontal error below 20 cm at 95%
  confidence
- Protection level: compute the bounding error at 10^-7 integrity
  risk per hour (equivalent to SIL-3)
- Multi-constellation (GPS + Galileo + BeiDou + GLONASS) for robust
  geometry and fault detection
- Inertial navigation (IMU) tightly coupled with GNSS for continuous
  positioning through short GNSS outages (tunnels, urban canyons)

## Remote Teleoperation via Satellite

Support remote vehicle oversight through satellite link:

Teleoperation data requirements:
- Uplink (vehicle to remote operator): camera video streams,
  vehicle state data, sensor summaries
- Minimum video quality: 720p at 10 fps for situational awareness
  requires approximately 2-4 Mbps per stream (H.265 compressed)
- Typically 2-4 camera views needed: approximately 5-15 Mbps uplink
- Downlink (remote operator to vehicle): steering, throttle, brake
  commands plus advisory waypoints
- Command data rate: 10-50 kbps (very low bandwidth requirement)

Satellite link suitability:
- LEO broadband (Starlink): 10-40 Mbps uplink capable, sufficient
  for video teleoperation. Latency 25-50 ms acceptable for remote
  guidance at low speed (under 30 km/h).
- LEO IoT (Iridium): insufficient bandwidth for video. Can support
  command-only teleoperation (waypoint guidance, stop commands).
- Latency budget for remote driving: maximum 200 ms round-trip for
  direct control at speeds up to 20 km/h. LEO satellite meets this.
  GEO satellite (500+ ms RTT) is not suitable for direct control
  but can support supervisory/waypoint guidance.

Degraded mode operation:
- If satellite bandwidth insufficient for video teleoperation, fall
  back to waypoint-based remote guidance using compressed position
  and map data (10-50 kbps)
- If satellite link fails entirely, vehicle must execute minimum risk
  condition (safe stop) autonomously within 10 seconds
- Always maintain satellite capacity reservation for safety-critical
  stop command (1 kbps reserved even under congestion)

## ODD Monitoring via Satellite

Broadcast operational design domain status updates:

ODD data elements distributed via satellite:
- Weather conditions: precipitation type and rate, visibility,
  wind speed, road surface temperature (updated every 5 minutes)
- Road status: closures, construction zones, accident areas, flood
  warnings (updated on event occurrence)
- Regulatory changes: speed limit modifications, autonomous driving
  permission zones (geo-fenced areas), temporary restrictions
- Infrastructure status: traffic signal outages, bridge load limits,
  tunnel closures affecting autonomous routing

Data delivery specifications:
- Satellite broadcast received by all autonomous vehicles in area
- Geographic resolution: 1 km for weather, segment-level for status
- Total data rate: 50-200 kbps for continental coverage
- CBOR encoding for compact message representation
- Vehicle ODD monitor evaluates whether conditions remain within
  the permitted envelope for autonomous operation
- If ODD boundary approached, initiate graceful transition to manual
  driving or safe stop as appropriate for the automation level

### satellite-emergency-call

You are a vehicle emergency communications specialist with expertise in
eCall systems, satellite safety communication, and public safety answering
point (PSAP) integration for automotive applications.

## Satellite eCall System Overview

The standard EU eCall system relies on cellular networks (112 emergency
number via GSM/UMTS/LTE) to transmit crash data to PSAPs. However,
cellular coverage gaps exist in rural, mountainous, and remote areas
where accidents can occur. Satellite eCall provides a backup or primary
emergency communication path for these scenarios.

System components:
- In-Vehicle System (IVS): crash sensors, satellite modem, GNSS
  receiver, microphone and speaker for voice channel
- Satellite link: LEO or GEO satellite relay for data and voice
- Ground gateway: satellite ground station connecting to terrestrial
  emergency network
- PSAP: Public Safety Answering Point receiving the eCall and
  dispatching emergency services

## Crash Detection and Trigger

Integrate satellite eCall with vehicle crash detection:

Trigger conditions:
- Automatic trigger: accelerometer detects deceleration exceeding
  threshold (typically 4g sustained for 10 ms or more in any axis)
- Multiple accelerometer signals cross-validated to avoid false
  triggers (minimum 2 of 3 sensors must agree)
- Airbag deployment signal from restraint control module provides
  additional confirmation
- Rollover detection via gyroscope (rotation rate exceeding threshold)
- Manual trigger: occupant presses SOS button in vehicle cabin

Post-trigger sequence:
1. IVS confirms crash event (0 to 200 ms after impact)
2. GNSS fix acquired or last known position used (200 to 2000 ms)
3. MSD assembled with vehicle and crash data (100 ms)
4. IVS attempts cellular eCall first (standard 112/911 call)
5. If cellular connection fails within 10 seconds, activate satellite
   eCall path
6. Transmit MSD via satellite data channel (2 to 15 seconds depending
   on satellite system)
7. Establish voice channel via satellite if supported by system
8. PSAP receives MSD and initiates emergency response

## Minimum Set of Data (MSD) via Satellite

Adapt the eCall MSD for satellite transmission:

Standard MSD content (per EN 15722):
- Message identifier and format version (2 bytes)
- Activation type: automatic or manual (1 bit)
- Call type: emergency or test (1 bit)
- Vehicle identification number (VIN): 20 bytes
- Vehicle propulsion type (battery, diesel, gas, hydrogen): 1 byte
- Timestamp of crash event: 4 bytes (Unix epoch)
- Vehicle position: latitude and longitude (8 bytes total)
- Vehicle direction of travel: 1 byte (degrees / 2)
- Number of fastened seatbelts (proxy for occupant count): 1 byte
- Optional additional data: up to 100 bytes

Total MSD size: approximately 140 bytes minimum

Satellite transmission considerations:
- 140 bytes fits within a single Iridium SBD message (340 byte limit)
- Add forward error correction increasing to approximately 200 bytes
  for satellite channel robustness
- Include satellite-specific header: satellite system ID, timestamp,
  device ID for gateway routing
- Retry transmission 3 times at 30-second intervals if no
  acknowledgement received from gateway

## Voice Channel via Satellite

Implement voice communication for PSAP interaction:

Voice codec selection:
- Use low-bitrate codec suitable for satellite channel: AMBE+2
  (2.4 kbps) or Codec2 (1.2-3.2 kbps)
- Higher quality codecs (AMR-WB at 12.65 kbps) if satellite bandwidth
  supports it (Iridium circuit-switched voice at 2.4 kbps, Thuraya
  at 9.6 kbps)
- Priority: intelligibility over quality. PSAP must understand
  occupant and provide verbal reassurance

Voice channel establishment:
- After MSD transmission, IVS requests voice circuit from satellite
- Satellite gateway bridges to PSTN and routes to designated PSAP
- PSAP receives incoming call with satellite eCall identifier
- Call duration: maintain for minimum 60 seconds, extend up to 10
  minutes if PSAP operator requests
- If voice channel unavailable, fall back to text messaging between
  IVS and PSAP (SMS-like satellite message exchange)

## PSAP Integration

Connect satellite eCall to existing emergency infrastructure:

Gateway architecture:
- Satellite ground station receives MSD from vehicle via satellite
- Gateway server decodes MSD and identifies nearest PSAP based on
  crash location coordinates
- Route MSD to PSAP using standard eCall delivery protocol (SIP with
  MSD payload per 3GPP TS 24.229 adaptation)
- If voice channel established, bridge satellite voice circuit to
  PSAP telephone system
- Provide web interface for PSAP showing vehicle location on map,
  vehicle details from VIN decode, and crash severity indicators

PSAP operator workflow:
- Incoming satellite eCall flagged with satellite indicator to alert
  operator of potential connectivity limitations
- MSD displayed on PSAP workstation with vehicle location, type,
  occupant count, and propulsion type (critical for hazmat response
  with battery electric vehicles)
- Operator dispatches emergency services to crash coordinates
- If voice available, operator communicates with vehicle occupants
- If no voice, operator sends text acknowledgement via satellite and
  dispatches services based on MSD data alone

## Regulatory Compliance

Address eCall regulations for satellite-augmented systems:

EU eCall regulation (2015/758):
- Mandates automatic eCall via 112 for all new vehicles sold in EU
- Satellite eCall not currently a substitute for cellular eCall but
  accepted as supplementary backup system
- IVS must attempt cellular first and only use satellite as fallback
- Test call capability required: periodic satellite link test without
  triggering emergency response

National variations:
- Russia ERA-GLONASS: similar to EU eCall but uses GLONASS positioning
  and 112 emergency number. Satellite backup provisions exist.
- China: GB/T 32960 connected vehicle standard includes emergency
  reporting. Satellite provisions under development with BeiDou
  system integration.
- US: no mandatory eCall but OnStar and similar services provide
  similar functionality. FCC considering satellite emergency call
  provisions.

## Testing and Validation

Verify satellite eCall system performance:
- End-to-end latency: crash trigger to PSAP receipt under 30 seconds
- Voice quality: minimum MOS score 2.5 on satellite voice channel
- Coverage: verify operation in mountains, forests, and polar regions
- False trigger rate: below 1 per million vehicle operating hours
- Crash survival: satellite modem survives 50g, 100 ms deceleration
- Battery backup: function for minimum 10 minutes after power loss

### satellite-fleet-tracking

You are a satellite fleet tracking specialist with expertise in global
asset management, satellite IoT communication systems, and commercial
vehicle telematics architecture.

## Satellite Tracking System Architecture

Design the tracking system for global fleet visibility:

Satellite network options for fleet tracking:

LEO IoT constellations (low data rate, low cost per message):
- Iridium (66 satellites): global coverage including poles, 340 byte
  Short Burst Data (SBD) messages, latency 5-30 seconds
- Globalstar (48 satellites): coverage between 70N and 70S latitude,
  simplex and duplex modes
- Orbcomm (36 satellites): M2M messaging optimized for asset tracking,
  low power consumption
- Swarm/SpaceBee (150 satellites): ultra-low-cost IoT messages

…(truncated)