Open-source repositories for the teams that build vehicle software, from the SDV platform to the battery.
Pick your assistant, copy the prompt and paste it into Claude, ChatGPT, Gemini or Grok.
Claude
Read https://automotivecloudwatch.com/repositories/automotive.md and map it to my team. Ask me up to four short questions first: my team, my program and its stage, what we already run, and any hard constraints. Then give me one written assessment: a short summary, three maps (already running, not running yet, still done by hand), the top 10 repositories rated for impact and effort, a setup check, and a 30-day plan that starts with the one repository to try today.ChatGPT
Open https://automotivecloudwatch.com/repositories/automotive.md with your browsing tool and read all of it, then map it to my team. Ask me up to four short questions first: my team, my program and its stage, what we already run, and any hard constraints. Then give me one written assessment: a short summary, three maps (already running, not running yet, still done by hand), the top 10 repositories rated for impact and effort, a setup check, and a 30-day plan that starts with the one repository to try today. If browsing is off or the link will not open, tell me and I will paste the file.Gemini
Read https://automotivecloudwatch.com/repositories/automotive.md and map it to my team. If you cannot open the link, tell me and I will paste the file. Ask me up to four short questions first: my team, my program and its stage, what we already run, and any hard constraints. Then give me one written assessment: a short summary, three maps (already running, not running yet, still done by hand), the top 10 repositories rated for impact and effort, a setup check, and a 30-day plan that starts with the one repository to try today.Grok
Fetch and read https://automotivecloudwatch.com/repositories/automotive.md, then map it to my team. If you cannot open the link, say so and I will paste the file. Ask me up to four short questions first: my team, my program and its stage, what we already run, and any hard constraints. Then give me one written assessment: a short summary, three maps (already running, not running yet, still done by hand), the top 10 repositories rated for impact and effort, a setup check, and a 30-day plan that starts with the one repository to try today.You get a written assessment of your team: a short summary, three maps of what you run, what you lack and what you still do by hand, the top 10 repositories rated for impact and effort, a setup check and a 30-day plan.
Your assistant will also offer, with one yes or no question, to keep watch: a new edition lands every two weeks, and on a yes it reads each one the day after and tells you only what changed for your team. You can cancel anytime.
Plain text for an assistant: /repositories/automotive.md /repositories/automotive.json
Edition 1, checked 2026-10-19
Most open-source lists in our industry are ranked by stars. That tells you what is popular. It does not tell an SDV platform lead which middleware will still have a maintainer when the vehicle is in its fifth year of service, or tell a validation engineer which simulator can stand behind a safety case.
So this library is built around the teams that own the problems instead of around technologies.
Edition 1, checked 2026-10-19, lists 41 repositories across 7 teams. By level that is 10 Start here, 20 Practitioner, 11 Deep end.
3 teams share the most entries, 7 each; EV, Battery and Powertrain Software has the fewest, 4. 16 entries carry a license flag (weak or strong copyleft, a non-standard license or no license detected), so read the license before you plan around them. Last activity runs from 2025-10-23 to 2026-10-19, as checked on 2026-10-19.
This is the first edition, so nothing has moved yet.
SDV Platform 5 Automotive Software Development 7 Connected Vehicle 5 ADAS and Autonomous Driving 7 Simulation, Validation and Test 7 Vehicle Cybersecurity and OTA 6 EV, Battery and Powertrain Software 4
Own the vehicle compute foundation, including the reference platform, operating systems, hypervisors and workload orchestration that every other team deploys onto.
5 repositories
The main repository of Eclipse S-CORE, an open automotive software core that OEMs and suppliers are building together as a shared base for SDV platforms.
Follow it to see which non-differentiating platform pieces the industry is choosing to build in the open, and how requirements and safety work are handled in an open process.
A workload and container orchestrator written in Rust and sized for embedded vehicle computers rather than data centers.
Reach for it when you need Kubernetes-like declarative workload management on a central compute ECU without the footprint of Kubernetes.
A Linux Foundation real-time operating system that runs on a very wide range of microcontrollers and is backed by a large silicon vendor community.
It is the most practical open RTOS to evaluate for zone controllers and sensor nodes, with a safety certification effort and modern build tooling.
The read-only GitHub mirror of the Xen type 1 hypervisor, which also underpins several automotive virtualization efforts on Arm.
Study it to understand how mixed-criticality partitioning works on a central compute SoC, and note that patches go through the mailing list rather than pull requests.
A small microkernel with a machine-checked mathematical proof that its implementation matches its specification.
Read it when you want to know what formally verified isolation actually buys you and what it costs in system design effort.
Own ECU and embedded software delivery, from AUTOSAR classic and adaptive models to SOME/IP and DDS middleware, CAN tooling, coding standards and toolchains.
7 repositories
A Python library for reading, writing and generating AUTOSAR XML (ARXML) models.
Use it to script ARXML generation or checks in CI instead of clicking through a commercial authoring tool for every change.
The widely used open C++ implementation of SOME/IP, the service-oriented protocol that AUTOSAR Adaptive and many Linux ECUs use over Ethernet.
It is the quickest way to prototype or test SOME/IP service discovery and messaging on Linux without a full AUTOSAR stack.
An Eclipse implementation of the OMG DDS publish and subscribe standard written in C.
Evaluate it when your architecture specifies DDS, since it is lightweight, standards based and also one of the ROS 2 middleware options.
The standard command line tools for Linux SocketCAN, such as candump, cansend and the ISO-TP utilities.
These are the first tools to install on any Linux bench or target that has a CAN interface.
A Python library that gives one API across many CAN interfaces and adapters.
Use it to write test scripts, loggers and quick tools that work the same whether the hardware is a USB dongle or SocketCAN.
A static analyzer for C and C++ that also offers a MISRA C checking add-on.
It is a low-cost first line of static analysis in CI and a way to see what a MISRA checker reports before investing in a qualified tool.
The source of Ferrocene, a Rust compiler toolchain qualified for use in ISO 26262 and IEC 61508 projects.
Follow it if you are weighing Rust for safety-related ECUs, since a qualified compiler is one of the gating items for that decision.
Own the path from vehicle signals to applications and the cloud, including vehicle data models, databrokers, V2X and vehicle to cloud transport.
5 repositories
The COVESA Vehicle Signal Specification, a tree-structured catalog of standard names and types for vehicle signals.
Adopting it gives apps, cloud services and suppliers a common signal vocabulary instead of a different data model for every program.
Tooling that validates VSS files and exports them to formats such as JSON, CSV, protobuf and GraphQL.
Use it when you extend VSS with your own signals and need to generate code and schemas from one source of truth.
A lightweight in-vehicle server written in Rust that stores current VSS signal values and exposes them over gRPC.
It is a practical starting point for separating vehicle apps from the networks that provide their data.
A Rust protocol and library that combines publish and subscribe, queries and storage, and runs from microcontrollers up to the cloud.
Consider it when vehicle data has to cross the boundary between in-vehicle networks, edge and cloud with one protocol instead of several bridges.
An open C++ implementation of the ETSI ITS-G5 V2X protocol stack, covering GeoNetworking, the BTP transport and security.
Use it to prototype or test European V2X messaging such as CAM and DENM without a commercial stack, keeping in mind that it targets research and test use.
Own the perception, planning and control stacks behind driver assistance and automated driving, along with the safety monitors that bound them.
7 repositories
The entry repository of Autoware, an open full-stack automated driving system built on ROS 2.
Start here to see a complete open architecture covering sensing, localization, planning and control, with the bulk of the code in the linked autoware_universe repository.
Baidu's open automated driving platform, including perception, prediction, planning and its own Cyber RT middleware.
It is a useful comparison point to Autoware, showing a large production-minded stack with a different middleware and architecture.
An open driver assistance system that adds adaptive cruise and lane centering to many supported production cars.
Study it to see an end-to-end learned driving model shipped to real users, with a strong engineering culture around testing and logging.
The research code for a planning-oriented end-to-end driving model that unifies perception, prediction and planning in one network.
Read it to understand the end-to-end approach that many current AD research and product programs build on.
NVIDIA's hub for its Alpamayo family of reasoning vision-language-action driving models, with training recipes, tools and links to models and datasets.
Use it to follow how large reasoning models are being applied to driving, and note that the older NVlabs/alpamayo repository now points here.
A large community collection of DBC files and car interface code describing CAN messages for many production vehicles.
It is a useful reference for how real vehicles lay out their CAN traffic and a ready source of decoders for logging work.
Firmware for a CAN interface that enforces a per-vehicle safety model on what driver assistance software may send to the car.
It is a compact, readable example of an independent safety monitor that limits commands from a complex AI system.
Own SIL, HIL and scenario-based testing, the measurement data that comes back from rigs and vehicles, and traceability from requirements to test evidence.
7 repositories
An open driving simulator built on Unreal Engine with sensors, traffic, weather and a Python API.
It is the default open choice for closed-loop testing of perception and planning, and integrates with Autoware and ROS 2.
A lightweight player for ASAM OpenSCENARIO XML scenarios with OpenDRIVE road support.
Use it to author, run and debug standardized test scenarios quickly before moving them to a heavier simulator or HIL setup.
A modular research simulator from NVIDIA for closed-loop testing of end-to-end driving policies with data-driven sensor rendering.
Look at it when you need to evaluate learned driving policies in closed loop on reconstructed real-world scenes rather than hand-built maps.
A JAX-based multi-agent driving simulator that replays scenarios from the Waymo Open Motion Dataset on accelerators.
It is useful for fast large-scale planning research, but the license is non-commercial, so treat it as a research reference.
A Python library for validating and simulating Functional Mock-up Units that follow the FMI standard.
Use it to script co-simulation and regression tests of FMUs exported from Simulink, Modelica or other modeling tools.
A Python library and GUI for reading, writing and processing ASAM MDF measurement files.
Reach for it when you need to script analysis of MDF logs from test drives or HIL rigs without relying only on vendor desktop tools.
A text-based tool for writing, linking and tracing requirements and specifications, with HTML and ReqIF export.
Consider it when you want requirements and traceability in Git alongside code instead of in a separate database.
Own secure software delivery to the fleet, including the update threat model, signed metadata, on-vehicle update clients and rollout backends.
6 repositories
The source of the Uptane standard, a security framework for over-the-air updates designed to survive compromise of individual servers or keys.
Read it before designing or buying an OTA system, because it sets out the threat model and the roles your architecture should cover.
A C++ client that implements the Uptane update process on the vehicle side.
It shows how Uptane metadata checks, primary and secondary ECUs and image installs fit together in real code.
The reference Python implementation of The Update Framework, the signed metadata design that Uptane builds on.
Read it to understand roles, key rotation and rollback protection in update metadata before you judge any OTA vendor's security claims.
An update client for embedded Linux that installs signed image bundles into redundant A/B slots.
Use it when you need atomic, fail-safe system updates with rollback on a Linux ECU built with Yocto or similar.
An update agent for embedded Linux that supports image, file and script based updates with signing and encryption.
It is a flexible alternative to RAUC when your update strategy needs more options than a strict A/B image swap.
An Eclipse backend for managing software rollouts to large fleets of devices.
Pair it with an update client to get campaign management, staged rollouts and device grouping without writing a server from scratch.
Own battery modeling and management software and the charging communication stack between the vehicle, the charger and the grid.
4 repositories
A Python framework for physics-based battery models, from simple equivalent circuits to detailed electrochemical models.
Use it to explore cell behavior, aging and parameter sensitivity before committing to a BMS algorithm or test plan.
An open battery management system from Fraunhofer IISB with firmware and hardware designs for research and development.
It is one of the few complete open BMS references with functional safety in mind, useful for learning and prototyping.
The core of EVerest, a Linux Foundation Energy software stack for EV chargers that covers OCPP, ISO 15118 and hardware drivers.
Use it to understand or build charger-side software, and to test vehicle charging behavior against an open reference implementation.
A Python implementation of the ISO 15118 vehicle to charger communication protocol, including Plug and Charge.
Reach for it when you need to test or prototype the vehicle side or charger side of high-level charging communication.
Suggest a repository or a correction
Want a note when a new edition lands? Subscribe free on the ACW Substack. Subscribe free
The other libraries: Robotics and Physical AI Manufacturing All repositories