How AI Helps with AUTOSAR System Design and Configuration
AutoC moves from ECUC parameters onto the System layer: a turn-signal plus hazard-light walkthrough, from Plan (SWC split, ports, DataTypes) through a DaVinci Developer check.
How it started
Until now AutoC mostly stopped at the ECUC layer: parameters for BSW modules such as CanIf, PduR, and Com. The System layer was a different job — how to split SWCs, how to build ports, how to match interfaces, how to wire Mapping. That still meant clicking cell by cell in DaVinci Developer or ISOLAR.
DataTypes and PortInterfaces are the worst of the manual work. Type names, CompuMethods, Application / Implementation mappings, data elements on Sender-Receiver interfaces: miss one and RTE will not line up later.
That has changed. Atomic SWCs, compositions, and DelegationConnectors can be designed in Plan first, then written straight into the project. Below is a small turn-signal plus hazard-light example: how Plan splits the design, then what the generated result looks like in DaVinci Developer and in AutoC.
A test first
The requirements are made up, to see how Plan mode starts. The function is simple, but it still includes the usual pieces: arbitration, flash timing, a periodic Runnable, and four lamp outputs.
Assumed system requirements
Function:
The vehicle turn signals must respond to two independent inputs: the driver's turn switch, and the hazard (double-flash) switch. Both may need to drive the same set of lamps (front-left / rear-left / front-right / rear-right), so priority has to be explicit.
Details:
- Turn switch input: three states — left, right, off — from the stalk.
- Hazard switch input: two states — on, off — from a separate hazard button.
- Priority:
- When hazard is on, all turn lamps (both sides) flash in sync, regardless of the turn switch.
- When hazard turns off, control returns to normal single-side turn indication.
- Flash behavior:
- About 1.5Hz (period ~667ms, 50% on / 50% off).
- Turn indication and hazard flashing share the same timing mechanism — one flash cadence, not two.
- State changes:
- Any input change (turn switch or hazard on/off) must take effect immediately, restarting from the "on" phase. Do not continue the previous phase.
- The function runs periodically, with a 10ms cycle.
- Outputs: on/off for the four lamps, for a downstream lamp-driver module.
How Plan splits it
Drop the requirements into Plan. It does not start by writing ARXML. It splits inputs, arbitration, flashing, and outputs first, then maps those onto SWC boundaries.

The split is conservative: control logic lives in one atomic SWC; switch sources and the lamp driver stay as external neighbors. Hazard-wins, one flash cadence, and immediate phase restart all go into that SWC's behavior, instead of several components fighting over the lamps.
Architecture
Plan produced this structure. Composition C_TurnSignalHazard wraps atomic SWC TurnSignalHazardCtrl, with three outer ports: turn switch, hazard switch, and four-lamp command. Composition ports delegate to the inner atomic SWC; switch sources and the lamp driver connect later.
HZ["危险报警开关源 SWC"] -->|HazardSwitchStatus| CPH CPL -->|"LampLeftFront/LeftRear/RightFront/RightRear"| LD["车灯驱动 SWC(后续)"] -->
Implementation details from the Plan
None of this is a design doc written after the fact. It all came from the Plan AutoC generated.
Data types (DataTypes.arxml → /DataTypes)
| Element | Type | Key parameters |
|---|---|---|
CompuMethod_TurnSwitchStatus | COMPU-METHOD | CATEGORY=TEXTTABLE; 0=TURN_OFF, 1=TURN_LEFT, 2=TURN_RIGHT (left=1, right=2, off=0) |
TurnSwitchStatus | APPLICATION-PRIMITIVE-DATA-TYPE | CATEGORY=TYPECODE; compuMethod→CompuMethod_TurnSwitchStatus |
TurnSwitchStatus_Impl | IMPLEMENTATION-DATA-TYPE | baseType=uint8; compuMethod→CompuMethod_TurnSwitchStatus; default swDataDefProps |
ApplBoolean | APPLICATION-PRIMITIVE-DATA-TYPE | CATEGORY=TYPECODE; impl→platform boolean |
Appl_DataMappingSet | DATA-TYPE-MAPPING-SET | mapping: TurnSwitchStatus→TurnSwitchStatus_Impl, ApplBoolean→/AUTOSAR_Platform/ImplementationDataTypes/boolean |
Hazard uses ApplBoolean directly (TRUE=on). No extra enum, fewer types. The four lamps are four independent boolean data elements on the interface, so there is no ApplicationRecordDataType — ApplBoolean is enough for each element.
Only the turn switch gets its own TEXTTABLE: off / left / right, one Application type and one Implementation type, joined by Appl_DataMappingSet. That choice still holds when you open DaVinci later.
Port interfaces (PortInterfaces.arxml → /PortInterfaces) — all SENDER-RECEIVER-INTERFACE
| Interface | Data element | Element type |
|---|---|---|
TurnSwitchStatus_I | TurnSwitchStatus | TurnSwitchStatus (Appl) |
HazardSwitchStatus_I | HazardSwitchStatus | ApplBoolean |
LampCommand_I | LampLeftFront / LampLeftRear / LampRightFront / LampRightRear | each ApplBoolean |
All three interfaces are Sender-Receiver. Lamp command is not a record: four independent booleans, so a lamp driver can wire per channel without unpacking a struct.
Atomic application SWC (/ComponentTypes)
TurnSignalHazardCtrl (APPLICATION-SW-COMPONENT-TYPE)
PP LampCommand(interface=LampCommand_I)RP TurnSwitch(interface=TurnSwitchStatus_I)RP HazardSwitch(interface=HazardSwitchStatus_I)SwcInternalBehavior:RunnableEntity TurnSignalHazardCtrl_RunTimingEvent: period=10.0ms, offset=0- DataReceivePoints:
TurnSwitch,HazardSwitch - DataSendPoints:
LampCommand
PerInstanceMemoryVariable(platform implementation types):flashTick(uint16, 0..period-1)lastTurn(TurnSwitchStatus_Impl)lastHazard(boolean)
The runnable period matches the 10ms cycle in the requirements. flashTick drives the cadence; lastTurn / lastHazard detect input changes and restart from "on", instead of continuing the previous half-cycle.
Composition and connectors (/ComponentTypes)
C_TurnSignalHazard (COMPOSITION-SW-COMPONENT-TYPE)
SWCPrototype:TurnSignalHazardCtrl(type = the atomic SWC above)- Composition ports (same interfaces):
R-Port TurnSwitch,R-Port HazardSwitch,P-Port LampCommand
- Three
DelegationConnectors:C_TurnSignalHazard.TurnSwitch → TurnSignalHazardCtrl.TurnSwitchC_TurnSignalHazard.HazardSwitch → TurnSignalHazardCtrl.HazardSwitchC_TurnSignalHazard.LampCommand → TurnSignalHazardCtrl.LampCommand
The composition holds no logic; it only exposes ports. Switch-source SWCs and the lamp-driver SWC are not built this time. The composition boundary is left ready to connect later.
Implementation
After confirming the Plan, AutoC writes it into the project. DataTypes, PortInterfaces, the atomic SWC, the composition, and Delegation are generated in one pass — no starting from a blank Developer project.

Checking in DaVinci Developer
Import the result into DaVinci Developer and check that types, interfaces, SWC ports, and composition connectors match the Plan.

CompuMethod_TurnSwitchStatus Int To Phys matches: 0=TURN_OFF, 1=TURN_LEFT, 2=TURN_RIGHT.

The port interface shown is HazardSwitchStatus_I: S/R, one boolean data element. The other two interfaces are Sender-Receiver as well; lamp command is four independent booleans, not a record.

On atomic SWC TurnSignalHazardCtrl, Access Points for runnable TurnSignalHazardCtrl_Run also match: read TurnSwitch and HazardSwitch, write the four LampCommand elements.

The component diagram is those two inputs and one output. Composition C_TurnSignalHazard delegates its ports onto this inner SWC. Switch sources and the lamp driver are not connected yet.

Messages shows ID 40501: Invalid periodic runnable trigger offset. The Plan set TimingEvent offset to 0. Whether that needs a change depends on the project's periodic-trigger constraints. Being able to import into Developer and review is not the same as a clean message list.
Checking in AutoC
The same result is visible in AutoC. You do not have to open Developer just to see what was generated.

The object browser shows composition C_TurnSignalHazard, plus types such as ApplBoolean and TurnSwitchStatus.

Drop C_TurnSignalHazard in and ask what it is: AutoC pulls type, outer ports, and Delegation out of the model. Later port changes or extra mapping can stay in AutoC.
Wrap-up
AutoC used to configure BSW parameters. This time System-layer SWC design can go from requirements into the project. The example is small, but the chain is complete: DataTypes, PortInterfaces, atomic SWC, composition Delegation. Building types and ports by hand from a blank project is the step you can skip.
