DEV Community: Bojan Zivkovic

ARForge v1.2.0 — Schema-valid ARXML, SubComposition support, and zero checker errors

Bojan Zivkovic — Tue, 14 Apr 2026 12:06:09 +0000

ARForge just hit a milestone that separates it from "tool that generates something that looks like ARXML" to "tool that generates correct ARXML."

v1.2.0 passes the AUTOSAR File Checker with zero errors. Monolithic export. Split export. Both clean.

If you work with AUTOSAR Classic, you know exactly why that line matters.

Why this release is different

Previous versions of ARForge could model SWCs and compositions in YAML, validate them against 191 semantic rules, and export ARXML that was structurally plausible. But plausible is not the same as correct. Real AUTOSAR toolchains run checkers. Schema validators catch things that look right but aren't. Until now, ARForge output had gaps that would surface under that scrutiny.

v1.2.0 closes those gaps. The generated ARXML is schema-valid, checker-passing, and consistent whether you export monolithic or split by SWC.

What's new

Full SubComposition support

This is the feature that makes ARForge usable on real projects rather than examples.

Real AUTOSAR system designs have hierarchy. A top-level composition contains sub-compositions, which contain component instances, which have ports connected at multiple levels. Without SubComposition support, any non-trivial architecture hit a modeling wall immediately.

v1.2.0 adds full support for:

Nested compositions as first-class model artifacts
Delegation ports connecting outer composition ports to inner component ports
Internal port connections within sub-compositions
Correct ARXML generation for the full hierarchy

In YAML, a sub-composition looks like this:

subCompositions:
  - name: "PowertrainSubSystem"
    typeRef: "PowertrainComposition"
    delegationPorts:
      - outerPort: "Pp_VehicleSpeed"
        innerComponent: "SpeedSensor_1"
        innerPort: "Pp_VehicleSpeed"

The export handles the full ARXML hierarchy correctly, including port mappings between levels.

Schema-valid ARXML across both export modes

A persistent issue in earlier versions was that monolithic and split exports produced subtly different structures. Running a checker on one would pass where the other failed. This created a reliability problem — you couldn't trust the output without knowing which export mode had been validated.

v1.2.0 unifies the export logic. Both modes now produce identical structure, deterministic element ordering, and schema-compliant output. The checker result is the same regardless of how you export.

# Both of these now produce schema-valid, checker-passing output
arforge export demo-project/autosar.project.yaml --out build/out
arforge export demo-project/autosar.project.yaml --out build/out --split-by-swc

ModeDeclarationGroup fixes

Mode handling had a number of structural issues that caused schema violations. v1.2.0 fixes them properly:

Correct CATEGORY = EXPLICIT_ORDER handling
Proper ON-TRANSITION-VALUE and per-mode VALUE support
Fixed placement of INITIAL-MODE-REF
Correct emission of MODE-DECLARATIONS
Resolved unresolved mode references that previously caused checker failures

These weren't cosmetic fixes. Invalid ModeDeclarationGroup structure produces ARXML that downstream tools reject. The generated output now matches what the AUTOSAR specification requires.

YAML model enhancements

New modeling capabilities on the YAML side to support the above:

modeDeclarationGroups:
  - name: "BswMApplicationMode"
    category: "EXPLICIT_ORDER"
    modes:
      - name: "STARTUP"
        value: 0
        onTransitionValue: 255
      - name: "RUN"
        value: 1
        onTransitionValue: 255
      - name: "SHUTDOWN"
        value: 2
        onTransitionValue: 255

The checker result

Both exports. This is the line that matters for anyone who needs to hand off ARXML to a downstream tool, an integration partner, or a customer. The output is correct.

Known limitations

Being transparent about what is not yet modeled:

HandleOutOfRange in ComSpecs
supportsMultipleInstantiation
handleTerminationAndRestart
Runnable symbol
ModeSwitchEvent activation
Full delegation port data element mapping

These are warning-level findings in the checker, not errors. They do not affect the validity of the generated output. They are on the roadmap.

Breaking change

The ModeDeclarationGroup ARXML structure changed. If you were relying on the previously generated (invalid) structure, the new output will differ. The old structure was schema-invalid. The new one is correct.

Where ARForge stands now

YAML model
    │
    ▼
arforge validate      ← 191 semantic rules, three severity levels
    │
    ├──▶ arforge export     ← schema-valid, checker-passing ARXML
    │                          monolithic or split, identical structure
    │
    ├──▶ 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

The pipeline now produces output you can trust at every stage. The ARXML is correct. The diagrams reflect the actual model. The C skeletons derive from validated port definitions.

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
python -m arforge.cli validate examples/autosar.project.yaml

# Export — schema-valid, checker-passing
python -m arforge.cli export examples/autosar.project.yaml --out build/out

# 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 with YAML schema autocomplete and inline diagnostics is included out of the box.

Full release notes at github.com/bzivkovic1986/arforge/releases/tag/v1.2.0.

Apache-2.0. Runs on Linux and Windows. No license server, no GUI dependency, no commercial toolchain required.

Tags: autosar embedded opensource automotive cprogramming

ARForge just became a full AUTOSAR Classic design pipeline — PlantUML diagrams and C code generation, zero vendor tooling

Bojan Zivkovic — Wed, 08 Apr 2026 08:27:44 +0000

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

Designing AUTOSAR Classic SWCs Without DaVinci Developer

Bojan Zivkovic — Wed, 25 Mar 2026 09:05:47 +0000

I spent over a decade working in Classic AUTOSAR. In every company I worked at, the same frustration kept showing up: SWC design was locked inside a proprietary GUI tool, ARXML files were unreadable in code review, validation was a manual process, and the license costs were significant enough that not every engineer on the team had access.

So during some free time I built ARForge — a lightweight, open source tool that lets you design AUTOSAR Classic SWCs in plain YAML, validate them with a semantic rule engine, and export standards-compliant ARXML. No GUI, no license server. Runs on Linux and Windows. Fits into a CI pipeline.

This article walks through a complete example — from defining interfaces and SWC types to wiring a composition and exporting ARXML.

The problem with current tooling

If you have worked with DaVinci Developer, you know the pain points:

Every change produces a large XML diff that is nearly impossible to review meaningfully in a pull request
Validation is tied to the tool — you cannot run it in CI without the license
The tool is GUI-first, which makes scripting and automation awkward
License costs mean not everyone on the team has access, creating bottlenecks

None of these are engineering problems. They are tooling problems. The underlying AUTOSAR modeling concepts — SWC types, ports, runnables, interfaces, compositions — are not inherently complex. They just need a better authoring format.

YAML is that format. It is human-readable, diff-friendly, version-controllable, and trivially scriptable. Every change to a SWC definition is a meaningful, reviewable line in a pull request.

What ARForge supports

ARForge targets a practical AUTOSAR Classic 4.2 subset that covers the design layer:

Base, implementation, and application data types with constraints, units, and compu methods
Sender-Receiver interfaces with data elements and full ComSpec (implicit, explicit, queued)
Client-Server interfaces with operations, arguments, return types, possible errors, sync/async call modes
Mode-Switch interfaces with ModeDeclarationGroup support
SWC types with ports, runnables, and all standard event kinds: TimingEvent, InitEvent, OperationInvokedEvent, DataReceiveEvent, ModeSwitchEvent
Runnable access definitions (reads, writes, calls, raisesErrors) validated against port direction and interface kind
System compositions with component prototypes and port-level assembly connectors
191 stable semantic validation finding codes across all supported constructs
Deterministic ARXML export, monolithic or split by SWC

A complete example

Let's build a small system: a SpeedSensor SWC that publishes vehicle speed and manages the ECU power state, and a SpeedDisplay SWC that consumes both.

Step 1 — Define the data types

# types/base_types.yaml
baseTypes:
  - name: "uint16"
    bitLength: 16
    signedness: "unsigned"
    nativeDeclaration: "uint16"

# types/implementation_types.yaml
implementationDataTypes:
  - name: "Impl_VehicleSpeed_U16"
    baseTypeRef: "uint16"

# types/application_types.yaml
applicationDataTypes:
  - name: "App_VehicleSpeed"
    implementationTypeRef: "Impl_VehicleSpeed_U16"
    constraint:
      min: 0
      max: 250
    unitRef: "km_per_h"
    compuMethodRef: "CM_VehicleSpeed_Kph"

Step 2 — Define a mode declaration group

Mode declaration groups are first-class model artifacts in ARForge. They are defined once and referenced by mode-switch interfaces.

# modes/power_state.yaml
modeDeclarationGroups:
  - name: "Mdg_PowerState"
    description: "Power state modes for the ECU."
    initialMode: "OFF"
    modes:
      - "OFF"
      - "ON"
      - "SLEEP"

Step 3 — Define the interfaces

# interfaces/If_VehicleSpeed.yaml
interface:
  name: "If_VehicleSpeed"
  description: "Sender-receiver interface for the current vehicle speed."
  type: "senderReceiver"
  dataElements:
    - name: "VehicleSpeed"
      typeRef: "App_VehicleSpeed"

# interfaces/If_PowerState.yaml
interface:
  name: "If_PowerState"
  description: "Mode switch interface for ECU power state."
  type: "modeSwitch"
  modeGroupRef: "Mdg_PowerState"

Step 4 — Define the SWC types

This is where the design intent lives. The SpeedSensor provides a speed value on a cyclic 10 ms runnable and manages the power state mode port.

# swcs/SpeedSensor.yaml
swc:
  name: "SpeedSensor"
  description: "SWC type that publishes the current vehicle speed."
  ports:
    - name: "Pp_VehicleSpeed"
      direction: "provides"
      interfaceRef: "If_VehicleSpeed"
    - name: "Pp_PowerState"
      direction: "provides"
      interfaceRef: "If_PowerState"
  runnables:
    - name: "Runnable_PublishVehicleSpeed"
      timingEventMs: 10
      writes:
        - port: "Pp_VehicleSpeed"
          dataElement: "VehicleSpeed"

The SpeedDisplay requires both. It reads speed cyclically and also reacts to the power state entering ON.

# swcs/SpeedDisplay.yaml
swc:
  name: "SpeedDisplay"
  description: "SWC type that reads vehicle speed and reacts to power state."
  ports:
    - name: "Rp_VehicleSpeed"
      direction: "requires"
      interfaceRef: "If_VehicleSpeed"
    - name: "Rp_PowerState"
      direction: "requires"
      interfaceRef: "If_PowerState"
  runnables:
    - name: "Runnable_ReadVehicleSpeed"
      timingEventMs: 10
      reads:
        - port: "Rp_VehicleSpeed"
          dataElement: "VehicleSpeed"
    - name: "Runnable_OnPowerOn"
      modeSwitchEvents:
        - port: "Rp_PowerState"
          mode: "ON"

Notice that the modeSwitchEvents trigger references a mode name directly. ARForge validates that ON is declared in Mdg_PowerState and that Rp_PowerState is a requires port on a mode-switch interface. If either is wrong, you get a stable finding code before any ARXML is generated.

Step 5 — Wire the composition

The system file instantiates SWC types as component prototypes and connects their ports.

# system.yaml
system:
  name: "DemoSystem"
  composition:
    name: "Composition_DemoSystem"
    components:
      - name: "SpeedSensor_1"
        typeRef: "SpeedSensor"
      - name: "SpeedDisplay_1"
        typeRef: "SpeedDisplay"
    connectors:
      - from: "SpeedSensor_1.Pp_VehicleSpeed"
        to: "SpeedDisplay_1.Rp_VehicleSpeed"
      - from: "SpeedSensor_1.Pp_PowerState"
        to: "SpeedDisplay_1.Rp_PowerState"

Connector endpoints use InstanceName.PortName syntax. The distinction between SWC type and component prototype is correctly modeled — you can instantiate the same type multiple times.

Step 6 — The project manifest

The aggregator manifest ties everything together.

# autosar.project.yaml
autosar:
  version: "4.2"
  rootPackage: "DEMO"

inputs:
  baseTypes: "types/base_types.yaml"
  implementationDataTypes: "types/implementation_types.yaml"
  applicationDataTypes: "types/application_types.yaml"
  units:
    - "units/units.yaml"
  compuMethods:
    - "compu_methods/compu_methods.yaml"
  modeDeclarationGroups:
    - "modes/*.yaml"
  interfaces:
    - "interfaces/If_VehicleSpeed.yaml"
    - "interfaces/If_PowerState.yaml"
  swcs:
    - "swcs/SpeedSensor.yaml"
    - "swcs/SpeedDisplay.yaml"
  system: "system.yaml"

Step 7 — Validate and export

# Validate — runs 191 semantic rules, exits non-zero on any error finding
python -m arforge.cli validate autosar.project.yaml

# Export — blocked if validation has errors
python -m arforge.cli export autosar.project.yaml --out build/out --split-by-swc

Validation output looks like this when something is wrong:

[ERROR]   CORE-028-MSE-UNKNOWN-MODE    Runnable 'Runnable_OnPowerOn': modeSwitchEvent references unknown mode 'STARTUP' on port 'Rp_PowerState'
[WARNING] CORE-050                     SR consumer 'SpeedDisplay_1.Rp_VehicleSpeed' runs faster than its producer

Summary: 1 error, 1 warning, 0 info

Finding codes are stable across versions. You can grep for them, suppress specific ones in CI, or use them as references in bug reports.

The validation engine

This is where ARForge goes beyond a simple generator. The semantic validation layer catches problems that an XML schema cannot — things like:

a runnable reading from a port that doesn't exist on the SWC
a modeSwitchEvent referencing a mode not declared in the group
a CS port with async ComSpec trying to set a timeout
a requires SR port that a runnable reads from but which has no incoming connector in the composition
a sender-receiver consumer running at a shorter period than its producer
a port declared on an SWC type but never accessed by any runnable

191 rules, organized by domain, each with a stable CORE-XXX identifier. Every rule has explicit test fixtures for both valid and invalid inputs in the test suite.

CI integration

Because ARForge is a CLI tool with deterministic output and stable exit codes, it drops into any pipeline without modification:

# Example GitHub Actions step
- name: Validate AUTOSAR model
  run: python -m arforge.cli validate autosar.project.yaml

This is something DaVinci Developer fundamentally cannot do. Your ARXML is generated from a validated, version-controlled source of truth on every push.

VS Code integration

ARForge ships with a .vscode/ configuration that enables YAML schema autocomplete and inline diagnostics for all ARForge file types out of the box. Install the Python and YAML (Red Hat) extensions, open the repo, and the editor knows what fields are valid in an SWC file, an interface file, or a system file without any manual setup.

What it is not

ARForge covers the SWC design layer. It is not a DaVinci replacement for production integration workflows at large Tier-1s — it does not generate RTE contract headers, configure BSW modules, or manage OS task mapping. It is also not a round-trip tool yet: ARXML import is planned but not implemented, so it works best for greenfield design or as a parallel design environment.

The target audience is engineers who want the design phase to feel like software engineering — text files, version control, automated validation, CI — rather than a proprietary GUI session.

Getting started

git clone https://github.com/bojanzivkovic/arforge
cd arforge
python -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate
pip install -r requirements.txt

# Run the included example
python -m arforge.cli validate examples/autosar.project.yaml
python -m arforge.cli export examples/autosar.project.yaml --out build/out --split-by-swc

# Run the test suite
pytest -q

The repository includes a complete working example project and a corpus of invalid model fixtures — one per validation rule — that you can use as a reference for what each rule checks.

Feedback, issues, and pull requests are welcome on GitHub. If you are working in Classic AUTOSAR and have thoughts on the tool, the feature gaps, or what would make it useful in your workflow — I would genuinely like to hear from you.

ARForge is an independent open source project, unaffiliated with any AUTOSAR tooling vendor. Licensed under Apache-2.0.