Architecture for software-defined vehicles, down to the silicon.
Central compute changes what an architecture has to cover. Safety-relevant and consumer software share one processor, a hypervisor sits between them, and a safety microcontroller watches over it all. We design those platforms and the safety arguments that go with them.
Every layer of the central compute platform
We write platform software requirements and architecture at the level the implementation teams build from, and we keep the safety and security work attached to it.
High-performance compute
Automotive compute platforms from the major silicon vendors: safety manual and assumption-of-use mapping, safe operating modes, and the hardware monitors behind them.
Hypervisors and mixed criticality
Type-1 hypervisor partitioning between a safety host and Linux or Android guests, AUTOSAR Adaptive applications, and the freedom-from-interference argument across them.
Safety microcontroller
Health supervision between the main processor and an ASIL D safety microcontroller: alarm handling, watchdogs and the reaction policy when something fails.
Camera and display paths
Surround-view and driver-monitoring cameras, safety-relevant display content, and the latency budgets that decide whether they meet their safety goals.
Security and content protection
HSM-backed secure boot, key handling and secure communication, plus DRM for premium media, designed alongside the safety architecture instead of bolted on after it.
Updates and degradation
Over-the-air updates with safe rollback, platform health monitoring, and degradation strategies that keep essential functions running when something fails.
Zonal networks and the ECUs that stay
A software-defined vehicle still has zone controllers, gateways and classic ECUs, and most of them speak AUTOSAR. We design the service and signal architecture between them, the SOME/IP and CAN FD communication, diagnostics over UDS, and the network management that wakes the vehicle and puts it to sleep.
- Service-oriented communication with SOME/IP, and signal-based CAN and CAN FD
- End-to-end protection for safety-relevant signals
- Time-sensitive networking and time synchronization across zones
- UDS diagnostics and fault reporting across the vehicle
- Interfaces defined once and generated for every target with SST
Keep the design in a model you own
Many SDV programs buy the vehicle's foundation layer from one supplier and spread the architecture across many tools. SST keeps requirements, safety analysis and design in one model the automaker owns, and deploys it to AUTOSAR, Linux, Android or the SST Runtime.
Designing a central compute platform?
We can review an architecture you already have, write the platform safety requirements, or take ownership of a domain such as supervision, camera paths or over-the-air updates.