Automotive Engineers: Don’t Miss These 15 GitHub Repositories!

Automotive Engineers_ Don't Miss These 15 GitHub Repositories!
Top 15 GitHub Repositories Every Automotive Engineer Should Know

Top 15 GitHub Repositories Every Automotive Engineer Should Know 🚗💻

A visual guide to open-source projects in CAN, ECUs, AUTOSAR, SOME/IP, ADAS and autonomous driving

Are you an automotive engineer looking to upgrade your skills? A modern vehicle runs on more than 100 million lines of code spread over dozens of ECUs, several network types and, increasingly, a central compute platform. Most of that code is proprietary, but a surprising amount of the underlying knowledge is open on GitHub. These 15 repositories let you read real code for vehicle networks, middleware, simulators, safety firmware and full self-driving stacks.

How to use this guide. Each repository gets a short card: what it is, why it matters, the skills it builds, and a first step you can take today. Tables scroll sideways on small screens. Licences and features change over time, so confirm details on each repository page before using the code in a product.

The big picture: where each repo fits

Before diving in, it helps to see how a vehicle’s software is layered. Sensors and actuators sit at the bottom, ECUs and buses carry signals, middleware moves data between processes, and the autonomy stack sits on top. Every repository below belongs to one or more of these layers.

Autonomy and ADAS openpilot · Apollo · Autoware perception, planning, control Simulation and test CARLA · CANdevStudio · BUSMASTER Middleware and services vsomeip · iceoryx · KUKSA · autoas Vehicle networks and tools opendbc · panda · CANopenNode RTOS and embedded Zephyr RTOS Learning map: Awesome Automotive (curated list)
Figure 1: The 15 repositories mapped onto vehicle software layers

Quick reference table

#RepositoryMain languageDomainLevel
1openpilotPython, C++ADASIntermediate
2opendbcPython, CCAN signalsBeginner
3Apollo AutoC++Autonomous drivingAdvanced
4AutowareC++ (ROS 2)Autonomous drivingAdvanced
5CARLAC++, PythonSimulationIntermediate
6vsomeipC++Automotive EthernetIntermediate
7autoas/asCAUTOSAR-style stackAdvanced
8CANdevStudioC++ (Qt)CAN simulationBeginner
9pandaC, PythonCAN hardwareIntermediate
10Awesome AutomotiveMarkdownResource listBeginner
11Eclipse KUKSARust, Python, GoVehicle APIsIntermediate
12Eclipse iceoryxC++Zero-copy IPCAdvanced
13CANopenNodeCCANopen stackIntermediate
14BUSMASTERC++Bus analysisBeginner
15Zephyr RTOSCEmbedded RTOSIntermediate

Background: the vehicle network in one page

To get value from the repositories, you need a mental model of how data moves in a car. Classic ECUs talk over CAN, a broadcast bus where every message has an identifier and up to 8 data bytes (64 with CAN FD). Newer domain and zonal controllers use automotive Ethernet and service-oriented protocols such as SOME/IP. Diagnostics run over UDS, usually on top of ISO-TP.

NetworkTypical speedPayloadTypical use
LINup to 20 kbit/s8 bytesMirrors, seats, window switches
CAN (classical)up to 1 Mbit/s8 bytesPowertrain, body, chassis
CAN FDup to ~8 Mbit/s data phaseup to 64 bytesFaster ECU links
FlexRay10 Mbit/sup to 254 bytesSafety-critical chassis (legacy)
100/1000BASE-T1 Ethernet100 Mbit/s to 1 Gbit/sup to 1500 bytesCameras, domain controllers, SOME/IP
Central computeADAS / autonomy Ethernet backbone (SOME/IP) Powertrain GW Body GW Chassis GW CAN CAN / LIN CAN FD ECM TCU BCM Door ESC EPS Simplified: real vehicles vary by OEM
Figure 2: A simplified in-vehicle network with an Ethernet backbone, gateways and CAN buses

Part 1: Driver assistance and autonomous driving

1. openpilot

PythonC++ADAScomma.ai

github.com/commaai/openpilot

openpilot is an open-source driver assistance system from comma.ai. It adds features such as adaptive cruise control and lane centering to a large list of supported production cars by reading camera and CAN data, running neural networks on-device, and sending steering and speed commands back through a CAN interface.

Why it matters

It is one of the few complete, production-quality ADAS codebases you can read end to end: a driver monitoring model, a driving model, a planner, a lateral and longitudinal controller, and per-car interface code. It also shows how real teams think about safety limits, such as torque rate limits and driver override.

Skills you build

  • Vehicle interfaces and CAN message handling per car brand
  • Longitudinal and lateral control (PID, MPC concepts)
  • Inter-process messaging with a publish/subscribe model
  • On-device ML inference constraints

First step

Browse the selfdrive directory and read how a car interface translates high-level commands into CAN messages. Then replay a recorded drive to see the pipeline without any hardware.

openpilot is research software. It is not a substitute for an attentive driver, and using it on public roads is subject to local law.

2. opendbc

PythonCCANDBC

github.com/commaai/opendbc

opendbc is a collection of DBC files and Python tooling that describe CAN messages for many vehicles, along with parsers and packers that turn raw bytes into named signals. Recent versions also host car-specific interface and safety logic that sits close to the bus.

Why it matters

A DBC file is the common language of CAN work. Reading a large, real-world collection teaches you how signals are laid out: start bit, length, byte order, factor, offset and units. That is exactly what you need when you debug a bus trace or write a gateway.

BO_ 304 GAS_PEDAL: 8 PCM
 SG_ GAS_POS : 7|8@0+ (0.4,0) [0|100] "%" EON

The snippet above shows a message with ID 304 and one signal: 8 bits starting at bit 7, big-endian, scaled by 0.4 to give a percentage. (Illustrative example, not a real vehicle definition.)

First step

Pick one DBC, find a speed or pedal signal, and decode a few bytes by hand. Then confirm your result using the Python parser.

3. Apollo Auto

C++Autonomous drivingBaidu

github.com/ApolloAuto/apollo

Apollo is Baidu’s open autonomous driving platform. It is a modular stack with perception, prediction, planning, control, localization, mapping and a custom runtime (Cyber RT) designed for deterministic scheduling of autonomy components.

Why it matters

Apollo shows what an industrial-scale L4 architecture looks like: HD map handling, multi-sensor fusion, scenario-based planning, and a task-scheduling framework built for latency. It is large, so treat it as a reference to study module by module.

First step

Read the module list, then follow one data path, for example from a camera frame to a detected object to a prediction. Do not try to build everything on day one.

4. Autoware

C++ROS 2Autonomous driving

github.com/autowarefoundation/autoware

Autoware is an open-source autonomous driving stack built on ROS 2 and maintained by the Autoware Foundation. It covers localization with lidar, perception, planning, control and vehicle interface layers, with a strong focus on real-world deployments such as shuttles and robotaxis.

Why it matters

If your company already uses ROS 2, Autoware is the natural bridge into autonomous driving. Its architecture documentation is a good example of how to decompose a self-driving system into well-defined interfaces.

First step

Run the planning simulator on a sample map, then change one parameter such as a speed limit and watch the effect on the trajectory.

Sensorscameras Detectobjects Predictmotion Planning Controlactuators Localization + maps Shared shape of Apollo, Autoware, openpilot openpilot merges several stages into one model
Figure 3: A generic autonomy pipeline

How the three stacks compare

AspectopenpilotApolloAutoware
GoalDriver assistance on production carsFull self-driving platformFull self-driving platform
MiddlewareCustom messagingCyber RTROS 2
Hardware needsSmall, dedicated deviceIndustrial compute plus sensorsGPU computer plus sensors
Sensor focusCamera firstMulti-sensor fusionLidar-heavy localization
Codebase sizeModerateVery largeLarge, modular
Best for learningCAN, control, ADASSystem architectureROS 2 autonomy

5. CARLA Simulator

C++PythonSimulation

github.com/carla-simulator/carla

CARLA is an open-source driving simulator built on Unreal Engine. It provides cities, weather, traffic, pedestrians and a sensor suite (RGB, depth, semantic segmentation, lidar, radar), controlled through a Python API.

Why it matters

Real testing is expensive and risky. CARLA lets you test perception and control ideas safely, generate labelled training data, and replay edge-case scenarios again and again. It also connects to ROS and to scenario runners for systematic testing.

import carla
client = carla.Client("localhost", 2000)
world = client.get_world()
bp = world.get_blueprint_library().filter("vehicle.*")[0]
vehicle = world.spawn_actor(bp, world.get_map().get_spawn_points()[0])
vehicle.set_autopilot(True)

First step

Spawn a vehicle, attach a camera, and save frames to disk. Then change the weather and compare.

Part 2: Vehicle networks, tools and hardware

6. vsomeip

C++SOME/IPCOVESA

github.com/COVESA/vsomeip

vsomeip is an open-source implementation of SOME/IP (Scalable service-Oriented MiddlewarE over IP), the protocol used by AUTOSAR for service-oriented communication on automotive Ethernet. It supports service discovery, request/response, events and fields.

Why it matters

As vehicles move to zonal and centralised architectures, signal-based CAN is giving way to services. vsomeip lets you run a real service provider and consumer on a laptop and watch the packets in Wireshark.

Provider Client 1. OfferService (SD) 2. SubscribeEventgroup 3. SubscribeAck 4. Method request 5. Response / notification
Figure 4: SOME/IP discovery, subscription and method call

First step

Build the examples, run one service and one client, and capture the traffic. Identify the SOME/IP header fields: service ID, method ID, length, client ID, session ID, protocol version, interface version, message type and return code.

7. autoas / as

CAUTOSARClassic and Adaptive concepts

github.com/autoas/as

This project is an open-source automotive software platform that implements many AUTOSAR-style modules, such as communication, diagnostics, memory and OS-related layers, and runs on a PC for experimentation. Check the repository README for the current scope and which modules are covered.

Why it matters

Commercial AUTOSAR stacks are expensive and closed. Reading an open implementation lets you see how PduR routes PDUs, how ComM manages networks, and how Dcm handles UDS requests.

LayerExample modulesRole
ApplicationSoftware componentsYour feature logic
RTERuntime environmentConnects SWCs to the basic software
ServicesNvM, Dcm, Dem, EcuMMemory, diagnostics, mode management
CommunicationCom, PduR, CanIf, CanTpSignal and PDU routing
Drivers (MCAL)Can, Spi, Adc, PortHardware access

First step

Trace one CAN frame as it moves from the driver up through CanIf and PduR to a signal in Com.

8. CANdevStudio

C++QtCAN simulation

github.com/GENIVI/CANdevStudio

CANdevStudio is a graphical tool for simulating a CAN network. You drag and drop nodes (CAN device, signal sender, signal viewer, raw viewer), connect them and generate traffic without needing a real car. It can use SocketCAN and other backends on supported platforms.

Why it matters

It is a low-friction way to prototype a bus, test a DBC, or teach CAN to new team members. Pair it with a virtual CAN interface on Linux and you can practise with zero hardware.

sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0
cansend vcan0 123#11223344
candump vcan0

First step

Create a vcan0 interface, load a DBC in CANdevStudio and send a periodic signal. Watch it in candump.

9. panda

CPythonCAN hardwarecomma.ai

github.com/commaai/panda

panda is the firmware and Python library for comma.ai’s USB vehicle interface, which exposes CAN, and other buses depending on the model, to a host computer through OBD-II or a harness. It runs on an STM32 microcontroller and enforces safety rules before messages reach the vehicle.

Why it matters

It is a rare open example of embedded firmware that is both a bus adapter and a safety gate. You see interrupts, USB handling, CAN driver code and a safety model that blocks unsafe commands, all in readable C.

VehicleCAN bus pandaSTM32 MCU opendbcsignals Your codeapp / ADAS USB between panda and host
Figure 5: A typical open CAN tooling chain
Safety. Only transmit on a vehicle bus if you fully understand the consequences. Start with read-only work on a bench ECU or a simulated bus.

10. Awesome Automotive

Curated listResources

github.com/ajay-bhojani/Awesome-Automotive

A curated list of automotive tools, standards, courses, articles and projects. Think of it as a map of the field rather than a codebase.

Why it matters

The automotive domain is wide: diagnostics, functional safety, cybersecurity, testing, simulation, standards. A good list shortens your search time and often leads to repositories you would not otherwise find.

First step

Pick one category you know little about, such as diagnostics or cybersecurity, and open three links from it.

Part 3: Middleware, vehicle APIs and real-time systems

11. Eclipse KUKSA

RustPythonVehicle abstractionEclipse SDV

github.com/eclipse-kuksa

KUKSA is an organisation of projects under the Eclipse Software Defined Vehicle ecosystem. Its core idea is a vehicle abstraction layer: a data broker exposes signals defined by the COVESA Vehicle Signal Specification (VSS), and apps read or write them through a common API instead of talking to raw buses.

Why it matters

This is the pattern behind software-defined vehicles. An app asks for Vehicle.Speed and does not care whether it comes from CAN, SOME/IP or a simulator. That portability is the whole point.

Vehicle appsnavigation, fleet, eco-driving Data broker (VSS signals, gRPC API)Vehicle.Speed · Vehicle.Cabin.Door.Row1.Left.IsOpen Providers / feeders (CAN, SOME/IP, simulator) Real vehicle buses and ECUs
Figure 6: Vehicle abstraction with a signal broker

First step

Run the data broker in a container, set a speed value with the CLI and read it back from a small client.

12. Eclipse iceoryx

C++Zero-copy IPCEclipse

github.com/eclipse-iceoryx/iceoryx

iceoryx is a shared-memory inter-process communication framework. A publisher writes data once into shared memory and subscribers receive a reference, so large payloads such as camera frames and point clouds are never copied.

Why it matters

Autonomy stacks move gigabytes per second between processes. Copying that data costs CPU time and adds jitter. iceoryx shows how to design for bounded latency, and it is used as a transport option in ROS 2 and in the AUTOSAR Adaptive world.

ApproachCopies per messageLatency behaviourGood for
Socket / network2 or moreGrows with payload sizeCross-machine links
Message queue2Depends on sizeSmall control messages
Shared memory (iceoryx)0Roughly constantImages, lidar, big buffers

First step

Run the publisher and subscriber examples, then send a large payload and compare against a socket-based test.

13. CANopenNode

CCANopen

github.com/CANopenNode/CANopenNode

CANopenNode is a free and open-source CANopen protocol stack written in C, designed for microcontrollers, with an object dictionary, PDOs, SDOs, heartbeat, NMT and emergency messages.

Why it matters

CANopen is common in off-highway vehicles, buses, agricultural machines, medical devices and industrial automation. The stack teaches how a higher-layer protocol is built on raw CAN and how an object dictionary describes a device.

ServicePurposeTypical use
NMTStart, stop and reset nodesNetwork control
HeartbeatShow a node is aliveMonitoring
SDORead or write dictionary entriesConfiguration
PDOFast process dataSensor values, setpoints
EMCYReport errorsFault handling

First step

Run the Linux example on vcan0 and use an SDO read to fetch the device name from the object dictionary.

14. BUSMASTER

C++Bus analysisWindows

github.com/rbei-etas/busmaster

BUSMASTER is an open-source application for simulating, analysing and testing data bus systems such as CAN and LIN. It offers message logging, database import, signal watch, replay and node simulation.

Why it matters

It shows what a classic bus tool contains. Understanding trace logging, signal watch lists and node simulation will make you faster with any commercial tool you use at work.

First step

Load a database file, connect to a supported adapter or simulation, and build a simple node that answers a request.

The project is mainly aimed at Windows. Check the repository for current maintenance status before relying on it.

15. Zephyr RTOS

CRTOSLinux Foundation

github.com/zephyrproject-rtos/zephyr

Zephyr is a scalable, open-source real-time operating system for resource-constrained devices. It supports many architectures and boards, a CAN controller API, ISO-TP, networking, device tree configuration and a strong community around security and safety certification work.

Why it matters

Automotive ECUs depend on real-time scheduling, deterministic interrupts and clean hardware abstraction. Zephyr is a modern, readable example of all three, and its CAN subsystem is a good way to move from theory to a running node.

const struct device *can = DEVICE_DT_GET(DT_CHOSEN(zephyr_canbus));
struct can_frame f = { .id = 0x123, .dlc = 2, .data = {0x11, 0x22} };
can_send(can, &f, K_MSEC(100), NULL, NULL);

First step

Build the CAN counter sample for a supported board or for the native simulator, then add a second thread that sends a periodic message.

Comparing everything at a glance

RepositoryHardware needed?Runs on a laptop?Best for
openpilotOptional (for real cars)Yes, with replayADAS design
opendbcNoYesCAN signal decoding
ApolloOptionalYes, heavyArchitecture study
AutowareOptionalYes, simulatorROS 2 autonomy
CARLAGPU recommendedYesTesting and data
vsomeipNoYesSOME/IP
autoas/asNoYesAUTOSAR concepts
CANdevStudioNoYesCAN prototyping
pandaYes, for firmware usePython parts yesEmbedded and safety
Awesome AutomotiveNoYesDiscovery
KUKSANoYesSDV APIs
iceoryxNoYesHigh-speed IPC
CANopenNodeOptionalYes, with vcanCANopen devices
BUSMASTEROptionalWindowsBus analysis
ZephyrOptionalYes, native simEmbedded C and RTOS

Rough effort to get started

Relative setup effort, from the author’s judgement (longer bar means more effort).

opendbc
CANdevStudio
CANopenNode
vsomeip
Zephyr
CARLA
openpilot
Autoware
Apollo

A learning roadmap

You do not need to read all 15 repositories. Pick a track that matches your job and work through it in order.

Track A: Network and ECU engineer opendbc CANdevStudio Zephyr Track B: Service-oriented and SDV vsomeip KUKSA iceoryx Track C: ADAS and autonomy CARLA openpilot Autoware Side quests: panda, CANopenNode, BUSMASTERApollo is an alternative to Autoware
Figure 7: Three suggested tracks
WeekTrack ATrack BTrack C
1Decode DBC signals by handRun a vsomeip service and clientSpawn a car in CARLA
2Simulate a bus with vcanCapture SOME/IP in WiresharkLog sensor data
3Send CAN from ZephyrRead VSS signals through KUKSARead the openpilot controls code
4Add ISO-TP and a UDS requestTry zero-copy with iceoryxRun Autoware’s planning simulator

How to read a large open-source codebase

  1. Start with the README and docs. Learn the vocabulary before the code.
  2. Build and run something small. A working example beats ten hours of reading.
  3. Follow one data path. For example: CAN frame in, signal out, decision made.
  4. Read the tests. They show intended behaviour and edge cases.
  5. Change one thing. Break it on purpose, then fix it.
  6. Take notes and draw diagrams. You will remember far more.

Safety, licensing and ethics

Safety. Never test experimental code on a moving vehicle without proper safeguards, training and legal permission. Use simulators and bench setups first.
Licences. These projects use different licences, including permissive and copyleft types. Before reusing code in a commercial product, read the licence and consult your legal team.
Security. Respect vehicle cybersecurity. Only work on vehicles and ECUs you own or have written permission to test.

Final thoughts

From CAN communication and ECU development to real-time operating systems and AI-powered driving, these repositories turn abstract standards into code you can run. Start with one small win: decode a signal with opendbc, simulate a bus with CANdevStudio, or send a frame from Zephyr. Then climb toward service-oriented middleware and full autonomy stacks. Add two or three of these projects to your learning roadmap this month, keep notes, and share what you learn with your team.

Repository details change over time. Always confirm features, licences and maintenance status on GitHub.