DEV Community

Bojan Zivkovic
Bojan Zivkovic

Posted on

Designing AUTOSAR Classic SWCs Without DaVinci Developer

#architecture #opensource #showdev #tooling

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"
Enter fullscreen mode Exit fullscreen mode 
# types/implementation_types.yaml
implementationDataTypes:
  - name: "Impl_VehicleSpeed_U16"
    baseTypeRef: "uint16"
Enter fullscreen mode Exit fullscreen mode 
# 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"
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode 
# interfaces/If_PowerState.yaml
interface:
  name: "If_PowerState"
  description: "Mode switch interface for ECU power state."
  type: "modeSwitch"
  modeGroupRef: "Mdg_PowerState"
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)