ARForge v1.3.0 — validation profiles, architecture reports, and ARXML export fixes

#autosar #embedded #opensource #automotive

v1.3.0 focuses on making ARForge useful beyond modeling and export. Two new features address real workflow gaps: extensible validation for project-specific governance, and an architecture report command that produces documentation directly from the validated model. A round of ARXML export fixes continues the push toward rock-solid checker compatibility.

Validation extension system

The core validation set in ARForge covers 191 semantic rules. That's a solid baseline, but real projects have their own requirements on top of that: naming conventions, structural policies, rules specific to a team's process or an OEM's requirements. Until now, accommodating those meant modifying ARForge internals.

v1.3.0 introduces validation profiles. You write a YAML file that defines additional rules, enables or disables rules from the core set, and load it at validation time.

arforge validate project.yaml --profile profile.yaml

A profile can run alongside the core rules or replace them entirely:

profile:
  mode: core+extensions   # or: extensions-only
  rules:
    disable:
      - CORE-046           # disable specific core rule
    extensions:
      - id: PROJ-001
        description: "SWC names must start with 'Swc_'"
        severity: error
        target: swc
        check: name_prefix
        value: "Swc_"

The mechanism is built on the existing validation registry, so custom rules participate in the same finding code system, severity levels, and deterministic output ordering as core rules. The profile system is designed for:

Project-specific naming convention enforcement
Structural policies that vary per program or OEM
Selective disabling of rules that don't apply to a given project context
Team-specific governance without patching ARForge core

Architecture report command

Every AUTOSAR project eventually needs architecture documentation for reviews, integration handoffs, and pull requests. In most projects that documentation is written by hand, maintained separately from the model, and gradually drifts out of sync.

ARForge now generates it from the validated model directly.

arforge report project.yaml --out report.md

The generated Markdown report includes:

SWC count and list
Interface counts by kind: Sender-Receiver, Client-Server, Mode-Switch
Port counts: provides and requires
Component prototype count
Connector count
Unconnected ports summary
Unused elements summary
Basic timing relationships derived from runnable event definitions

The output is deterministic, renders natively in GitHub markdown, and works as a CI/CD artifact. A sample report header looks like this:

# ARForge Architecture Report — DemoSystem

## Summary

| Metric | Count |
|--------|-------|
| SWC types | 5 |
| Sender-Receiver interfaces | 4 |
| Client-Server interfaces | 3 |
| Mode-Switch interfaces | 1 |
| Component prototypes | 6 |
| Assembly connectors | 11 |
| Unconnected ports | 2 |
| Unused elements | 0 |

The report command complements validate. Validation tells you what is wrong. The report tells you what is there. Both are derived from the same source of truth — the validated YAML model.

For CI/CD workflows, you can generate the report on every commit and attach it as an artifact. Architecture documentation that writes itself and is always current.

ARXML export and schema fixes

v1.2.0 achieved the AUTOSAR File Checker passing with zero errors. v1.3.0 continues improving that baseline with a focused round of correctness fixes:

Client-server ARXML export structure corrected
CLIENT-COM-SPEC emission fixed
Operation references in client-server interfaces and ports corrected
Event tag naming in generated ARXML fixed
ModeDeclarationGroup export further improved
Monolithic and split export alignment maintained

Client-server communication in particular was an area with lingering structural issues. These fixes tighten the export to match what the AUTOSAR specification requires and what downstream tools expect.

The full pipeline

YAML model
    │
    ▼
arforge validate      ← 191 core rules + optional project profiles
    │
    ├──▶ arforge report     ← Markdown architecture summary
    │                          for reviews, PRs, CI/CD artifacts
    │
    ├──▶ arforge export     ← schema-valid, checker-passing ARXML
    │                          monolithic or split
    │
    ├──▶ 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

Every output is derived from the validated YAML model. Nothing is maintained separately. Nothing drifts.

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

# Generate architecture report
python -m arforge.cli report examples/autosar.project.yaml --out build/report.md

# Export ARXML
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