If you've ever worked on an AUTOSAR Classic project, you know the drill. The architecture lives in a GUI tool that costs more than most engineers' monthly salary. The ARXML it produces is machine-readable XML that technically contains all the information but is practically unreadable for humans. Your git diffs are walls of noise. Your CI pipeline can't touch the toolchain because it requires a license server. And somewhere in a shared drive there's a PowerPoint with a system diagram that stopped being accurate three months ago.
ARForge was built to fix this from the ground up. It lets you describe AUTOSAR Classic SWCs and compositions in plain YAML, validate them against 191 semantic rules, and export standards-compliant ARXML — all from a CLI, on any machine, with no license dependencies.
The latest release adds two features that extend the pipeline from design all the way through to implementation.
PlantUML diagram generation
ARForge now generates PlantUML diagrams directly from your validated model. Two diagram types are supported.
System topology diagrams show the full composition: every component instance, every port, and every assembly connector between them. You see at a glance which SWC provides what interface, which one consumes it, and exactly how they're wired. The diagram is color-coded by SWC category and connector type, with a legend included.
Per-SWC diagrams show each component in isolation with its provides and requires ports, interface references, and runnable triggers. These are the diagrams you want open during an architecture review when you're discussing a single component without the noise of the full system.
arforge diagram demo-project/autosar.project.yaml --out build/diagrams
The output is standard PlantUML markup. It renders natively in VS Code with the PlantUML extension, in GitHub markdown preview, and in any PlantUML-compatible tool. The diagrams live in your repository alongside the YAML source that generated them.
The key property here is that the diagram is always a function of the validated model. When the model changes, you regenerate. There is no separate diagram file to keep in sync, no stale PowerPoint, no "I think this is still accurate." You run the command and the output reflects reality.
C code skeleton generation
ARForge now generates .c and .h implementation templates for every SWC in your composition, derived directly from your validated model.
What you get for each SWC:
- Runnable stubs with correct signatures matching your timing and event triggers (
TimingEvent,InitEvent,DataReceiveEvent,OperationInvokedEvent) - Typed local variable declarations for every sender-receiver read and write, with the correct implementation data type
- Client-server call stubs with correct argument lists derived from your interface definitions
- TODO markers and inline comments indicating where your application logic goes
- A header file with the matching declarations
arforge generate code demo-project/autosar.project.yaml --lang c --out build/code
The generated file header makes the origin explicit:
/* Generated by ARForge.
* SWC: PlatformSWC
* Category: application
* This file is a starter skeleton and does not contain application logic.
*/
A realistic example. If your SWC has a TimingEvent at 10ms and a client-server port that calls GetHealthStatus and GetVoltage, the generated runnable looks like this:
/* Trigger: TimingEvent(10 ms) */
void Cyclic_10ms(void)
{
/* Client-server calls */
/* Operation signature: uint8 GetHealthStatus(void) */
uint8 get_health_status_result = 0;
/* TODO: get_health_status_result = Rte_Call_Rp_FakeChipHandling_GetHealthStatus(); */
/* Operation signature: void GetVoltage(uint16* Value) */
uint16 get_voltage_value = 0;
/* TODO: Rte_Call_Rp_FakeChipHandling_GetVoltage(&get_voltage_value); */
}
The Rte_Call_ signatures are derived from the actual port name, interface name, and operation definition in your YAML model. They are not guessed or templated with placeholder names. If your model is valid, the signatures are correct.
What the pipeline looks like end to end
YAML model
│
▼
arforge validate ← 191 semantic rules, three severity levels
│
├──▶ arforge export ← standards-compliant ARXML, deterministic output
│
├──▶ arforge diagram ← PlantUML topology + per-SWC diagrams
│
└──▶ arforge generate ← .c and .h skeletons per SWC
The YAML is your single source of truth. Everything downstream is generated and regeneratable. Nothing needs to be kept manually in sync.
Why this matters for open source tooling in automotive
Commercial AUTOSAR tooling is not going away. Vector DaVinci and EB Tresos are deeply embedded in OEM and Tier 1 workflows and will stay there for production programs. That's not the problem ARForge is trying to solve.
The gap it fills is everything around that: greenfield architecture work done before a tool platform is selected, consultants and smaller suppliers who can't justify a license seat for design exploration, teams who want their AUTOSAR model to live in version control and participate in CI like any other codebase, and engineers who want to understand the architecture without opening a GUI.
Open source in safety-critical domains has a credibility problem because the bar for production use is legitimately high. But there's a large and real space between "not used in production" and "not useful." ARForge is not trying to replace your RTE vendor. It's trying to make the design and architecture layer accessible, version-controlled, and automatable without requiring a commercial toolchain to participate.
Getting started
git clone https://github.com/bzivkovic1986/arforge
cd arforge
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
# Validate the demo project
python -m arforge.cli validate examples/autosar.project.yaml
# Generate diagrams
python -m arforge.cli diagram examples/autosar.project.yaml --out build/diagrams
# Generate C skeletons
python -m arforge.cli generate code examples/autosar.project.yaml --lang c --out build/code
VS Code integration is included out of the box. YAML schema autocomplete, inline diagnostics, and task runner work automatically once you open the repo.
Full documentation at docs/index.md.
Apache-2.0. Runs on Linux and Windows. No license server, no GUI dependency, no commercial toolchain required.
Tags: autosar embedded opensource automotive cprogramming
Top comments (0)