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

#autosar #embedded #opensource #automotive

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