What is ARForge
ARForge is an open-source CLI tool for AUTOSAR Classic SWC design. Instead of a GUI tool locked behind a license server, you describe your software components, interfaces, data types, and system composition in plain YAML. ARForge validates the model against 191 semantic rules and generates standards-compliant ARXML, PlantUML architecture diagrams, and C code skeletons — all from the command line, on any machine, with no vendor dependency.
The core principle: your AUTOSAR model should live in version control like any other source artifact, with readable diffs, CI integration, and no license gating.
v1.5.0 adds two features that push ARForge closer to modeling real-world AUTOSAR Classic architectures correctly.
Runnable mode conditions
AUTOSAR Classic supports mode-dependent execution: a runnable can be constrained to execute only when the system is in a specific mode. This is a real modeling requirement for any project that uses mode management — power modes, application modes, diagnostic modes — and until now ARForge had no way to express it.
v1.5.0 adds runnable-level mode condition support.
In YAML, it looks like this:
runnables:
- name: "Runnable_ActiveControl"
timingEventMs: 10
modeCondition:
modeGroupRef: "BswMApplicationMode"
mode: "RUN"
This models the intent that Runnable_ActiveControl is only active when the system is in RUN mode. The condition flows through the full pipeline:
- YAML schema validates the structure
- Semantic validation checks the mode reference against the declared ModeDeclarationGroup
- The mode condition is exported into the generated ARXML
- The export is schema-valid, confirmed against the AUTOSAR File Checker This completes the mode-switch modeling support that was already in place for ModeDeclarationGroup definitions, ModeSwitch interfaces, mode provider and user ports, and ModeSwitchEvent runnable triggers. The runnable-level constraint was the missing piece.
External ARXML package layout support
ARXML has a package namespace structure. In a real project that structure matters: downstream tools, integration scripts, and OEM requirements often expect generated ARXML elements to sit at specific package paths. Until now ARForge used a fixed internal package organization with no way to customize it.
v1.5.0 introduces external package layout profiles.
You define the package structure in a separate layout file:
packageLayout:
name: "OemStandardLayout"
packages:
dataTypes: "/ActiveEcuC/DataTypes"
interfaces: "/ActiveEcuC/PortInterfaces"
swcs: "/ActiveEcuC/SwComponentTypes"
composition: "/ActiveEcuC/SwComponentTypes"
The project file references the layout:
system:
name: "DemoSystem"
packageLayoutRef: "layouts/oem-standard.layout.yaml"
...
Elements can also be assigned to package paths explicitly if they need to deviate from the layout defaults:
swc:
name: "PlatformSWC"
packagePath: "/ActiveEcuC/Platform/SwComponentTypes"
...
This gives teams clean separation between three concerns that were previously mixed together: the package layout definition, the model elements themselves, and the generated ARXML namespace paths. Teams working with multiple OEM programs or integration targets can maintain separate layout profiles and switch between them without touching the model.
The scaffold (arforge init) now includes optional guidance for package layout usage so the feature is discoverable without being forced on every new project.
Pretty-printed ARXML
Generated ARXML is now properly indented.
This sounds minor but it has a practical impact. Anyone who has tried to open a raw single-line ARXML file in a text editor or a diff tool knows the experience: an unreadable wall of XML where finding a specific element requires a search. Pretty-printed output makes manual inspection and review possible without additional tooling.
The indented output is also friendlier for git diff when ARXML files are committed alongside YAML source, which is a workflow ARForge is designed to support.
Determinism is maintained: the output ordering is stable across runs, so pretty-printing does not introduce noise into diffs.
Schema and validation alignment
The runnable schema was updated to consistently handle mode conditions across the full pipeline. A common failure mode in tool development is schema, parser, validator, and exporter drifting out of sync with each other — accepting structures that can't be validated, or validating structures that can't be exported. This release tightens that alignment for mode-related modeling specifically.
The full pipeline
YAML model
│
▼
arforge validate ← 191 core rules + optional project profiles
│
├──▶ arforge diff ← structured Markdown architecture diff
│ direct Git integration
│
├──▶ arforge report ← Markdown architecture summary
│ for reviews, PRs, CI/CD artifacts
│
├──▶ arforge export ← schema-valid, checker-passing ARXML
│ pretty-printed, external package layout support
│
├──▶ arforge diagram ← PlantUML topology + per-SWC diagrams
│ renders in VS Code and GitHub markdown
│
└──▶ arforge generate ← .c and .h skeletons per SWC
correct Rte_ signatures from model
Getting started
git clone https://github.com/bzivkovic1986/arforge
cd arforge
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
# Initialize a new project
python -m arforge.cli init my-project
# Validate
python -m arforge.cli validate my-project/autosar.project.yaml
# Export with external package layout
python -m arforge.cli export my-project/autosar.project.yaml --out build/out
# Full pipeline
python -m arforge.cli diff my-project/autosar.project.yaml --base-git-ref origin/main --out build/diff.md
python -m arforge.cli report my-project/autosar.project.yaml --out build/report.md
python -m arforge.cli diagram my-project/autosar.project.yaml --out build/diagrams
python -m arforge.cli generate code my-project/autosar.project.yaml --lang c --out build/code
Full release notes at github.com/bzivkovic1986/arforge/releases/tag/v1.5.0.
Apache-2.0. Runs on Linux and Windows. No license server, no GUI dependency, no commercial toolchain required.
