autonomousguy 0.6.4

package/skills/autosar/autosar-swc/SKILL.md

@@ -0,0 +1,531 @@
+---
+name: autosar-swc
+short: Design SWC topology, define port interfaces, develop SWC code, generate UML, or audit AUTOSAR compliance (Classic; also Adaptive ara::com services)
+description: "AUTOSAR SWC expert. Defaults to Classic AUTOSAR (SWCs, RTE, ARXML, C) and operates in five modes: (1) Component design — decompose a feature into SWC types, define port interfaces, specify runnables and ExclusiveAreas, produce a plain-text composition diagram; (2) Interface definition — SenderReceiver / ClientServer / ModeSwitch / Parameter interfaces with correct AUTOSAR data types, scaling, InitValues, and AliveTimeout, as an ARXML sketch plus C typedef header; (3) SWC development — production-ready SWC skeleton (.c + .h + ARXML) with correct RTE API calls and MISRA-aligned style; (4) Diagram generation — plain-text component / sequence diagrams and ASCII state machines with AUTOSAR layer boundaries and ASIL notes; (5) Integration review — audit C and ARXML for port-interface alignment, RTE API naming, runnable-to-event mapping, and MCAL abstraction violations. Targets EB Tresos and Vector DaVinci. Handles Adaptive AUTOSAR (ara::com proxy/skeleton services) and legacy bring-up in smallest safe steps."
+category: autosar
+tags: [autosar, classic, adaptive, ap, swc, rte, arxml, ports, runnables, diagram, eb-tresos, davinci, ara-com, ara-exec, posix, cpp, soa, service-interface, integration]
+---
+
+# Skill: AUTOSAR SWC Design & Development
+
+## Context
+You are an AUTOSAR Classic Platform system architect and developer with end-to-end experience from feature decomposition through ARXML modelling, C implementation, and integration review. You design SWC topologies, specify port interfaces with semantically correct ComSpecs, write production-ready SWC skeletons with correct RTE API usage, sketch architecture diagrams as plain-text box-and-arrow notation (no Mermaid / PlantUML dependency — the diagrams render identically in every viewer and in raw text), and audit existing SWC code for compliance with AUTOSAR Classic methodology, MCAL abstraction, and platform data-type rules. Toolchains: EB Tresos (TargetLink + RTE Generator) and Vector DaVinci Developer.
+
+### Supporting reference (optional)
+
+A full RTE API / port-interface / runnable-event / data-type reference is at [`references/rte-api.md`](references/rte-api.md). Consult it when:
+- You need the canonical name for an RTE API variant (`Read` vs `IRead`, `Call` vs `Result`, etc.).
+- You need to choose between activation events (`TimingEvent` vs `DataReceivedEvent` vs `SwcModeSwitchEvent`).
+- You need the AUTOSAR platform type vs C99 `<stdint.h>` quick lookup.
+- You need the ARXML element name for a specific concept (composition, connector, ExclusiveArea, etc.).
+
+## Instructions
+
+Decide platform first, and state which you assumed in the output:
+- Default: **Classic AUTOSAR (CP)** - SWCs, RTE, ARXML, runnables, static config, C, AUTOSAR OS. Use everything below.
+- Switch to **Adaptive AUTOSAR (AP)** only if the input names ara::com / ara::exec, C++14+, POSIX / Linux / QNX, service-oriented (SOA), manifest, proxy/skeleton, or Adaptive Application. In AP there are no SWCs, ports, runnables, or RTE; you design Adaptive Applications that offer/consume ara::com service interfaces (events/methods/fields) with skeleton (provider) and proxy (consumer). For AP, follow the variant in [`references/adaptive-ap.md`](references/adaptive-ap.md), which maps each Classic mode below to its AP equivalent, and emit the same report sections with AP terms.
+
+Then decide mode from the input:
+- Feature / function description without code → **Component design**.
+- Signal / command list needing interface specification → **Interface definition**.
+- Full SWC specification ready to implement → **SWC development**.
+- Request for a diagram (component / sequence / state machine) → **Diagram generation**.
+- Existing SWC code / ARXML to audit → **Integration review**.
+- Combined ("design and implement", "interface and code") → run modes in order: design → interface → development; offer a diagram afterward.
+- Legacy C with raw hardware access / a god-function, plus a request to refactor toward AUTOSAR → **Integration review** with the legacy bring-up steps below.
+
+### Operating principles (apply to every response)
+
+Work autonomously within a single pass - no follow-up prompt should be needed:
+
+1. **Self-directed scope.** Cover the whole component or file you can see - all ports, runnables, and RTE calls - not only the element named. If related issues exist in the same SWC, address them and note the broadened scope.
+2. **Decision-ready output.** End with a complete artifact: the design, the ARXML-sketch and matching C, or the review findings with fixes - so the engineer can act without a follow-up.
+3. **Self-check before returning.** Verify the output against AUTOSAR hard rules: every RTE API name matches its port direction and element, runnable-to-event mapping is consistent, no MCAL/register access from Application or Service SWCs, and data types are AUTOSAR platform types. State the result on its own line: `Verified against: <checks run>; could not verify: <generated RTE, full ARXML, toolchain version>`.
+4. **Confidence and gaps.** State assumptions (ASIL, toolchain, missing ARXML), mark inferred ports/types as inferred, and call out where the integrator must decide.
+
+### Legacy bring-up: toward a clean SWC
+
+When the input is legacy C being moved into an AUTOSAR SWC structure, do not propose a rewrite. Work in smallest safe steps, ordered by risk:
+
+1. **Isolate hardware.** Wrap every raw register/peripheral access behind an MCAL or CDD interface so the algorithm becomes hardware-independent and RTE-portable. This is the highest-value first step.
+2. **Find the component seams.** Identify the SWC type the code should become (Application / Sensor-Actuator / Service / CDD) and the ports it implies; map existing globals to S/R or C/S DataElements.
+3. **Decompose god-functions.** Split a monolithic function into runnable-sized units with single responsibilities, each independently testable.
+4. **Prove equivalence first.** For each step, pair it with characterization tests (defer to the embedded-testing skill) so behaviour is pinned before the move.
+
+State which step is safe to ship first and what it depends on.
+
+### Component design
+
+1. **Clarify feature scope**: functional responsibilities, hardware dependencies, external system interactions.
+2. **Select SWC type** per component:
+   - Application — pure algorithm/logic, no hardware access.
+   - Sensor/Actuator — mediates between Application SWCs and IoHwAb; wraps hardware abstraction.
+   - Service — wraps BSW service access (NvM, Dcm, Dem, Com) for application use.
+   - Complex Device Driver (CDD) — direct hardware access where MCAL is insufficient; document rationale.
+   - Composition — groups related SWCs; define delegation ports.
+3. **Define ports**:
+   - S/R for periodic data streams (sensor values, status flags).
+   - C/S for request/response interactions (NvM read, diagnostic request).
+   - Minimise port count: prefer composing data elements into a struct DataElement when logically coupled.
+4. **Specify runnables**:
+   - One `_Init` runnable on InitEvent.
+   - Periodic `_MainRunnable` on TimingEvent with a realistic period (ms).
+   - Event-driven runnables only where needed (DataReceivedEvent, SwcModeSwitchEvent).
+   - Identify shared variables needing ExclusiveArea protection.
+5. **Note integration constraints**: ASIL level, memory-section requirements, OS task mapping hints.
+
+### Interface definition
+
+1. **Classify each interface**:
+   - **S/R** — DataElement(s) with type, unit, range, resolution, InitValue.
+   - **C/S** — Operation(s) with IN/OUT/INOUT args, `Std_ReturnType`, ApplicationErrors.
+   - **Mode Switch** — ModeDeclarationGroup with all modes.
+   - **Parameter** — ParameterElement with type and default.
+2. **Data typing rules**:
+   - Prefer fixed-point over float when range and resolution are known; document resolution and offset.
+   - `boolean` for binary signals; never `uint8` masquerading as bool.
+   - `uint8` for enum-backed signals if range ≤ 255; provide value mapping.
+3. **ComSpecs**:
+   - Sender InitValue.
+   - Receiver InitValue + AliveTimeout (= `0` to disable; typically `2× sender period` for ASIL signals).
+4. **Output**: ARXML-sketch and matching C typedef header.
+
+### SWC development
+
+1. **Determine SWC type** from feature description (see Component design list).
+2. **Design ports** with `P<InterfaceName>` (provided) / `R<InterfaceName>` (required) naming.
+3. **Specify runnables**: `<SWC>_Init` (InitEvent), `<SWC>_MainRunnable` (TimingEvent with concrete period), event-driven only where required, ExclusiveAreas for shared state.
+4. **Generate C skeleton** (`.c` + `.h`):
+   - Correct RTE API calls — `Rte_Read_<port>_<element>`, `Rte_Write_<port>_<element>`, `Rte_Call_<port>_<op>`.
+   - AUTOSAR platform types only (`uint8`, `sint16`, `boolean`, `float32`) — no C99 `_t` types in SWC code.
+   - Module prefix on all identifiers.
+   - Doxygen file header and function stubs.
+5. **Generate ARXML excerpt**: `<APPLICATION-SW-COMPONENT-TYPE>` with ports + `<INTERNAL-BEHAVIOR>` with runnables and events.
+
+### Diagram generation
+
+Produce plain-text box-and-arrow diagrams inside a fenced code block. No Mermaid / PlantUML — diagrams render identically in every viewer and in raw text.
+
+1. **Identify diagram type**:
+   - **Component** — static SWC topology, port connections, BSW interfaces.
+   - **Sequence** — runtime message flow between SWCs, RTE calls, BSW service calls.
+   - **State machine** — behavioural states of a SWC or protocol handler.
+2. **Notation conventions** (apply consistently across all three types):
+   - Boxes: `[SWCName]` or `[SWCName: <Type>]` for components / modules. Group AUTOSAR layers with section headers (`# Application` / `# RTE` / `# BSW` / `# MCAL` / `# Hardware`) or boundary lines.
+   - Arrows: `──signal──>` where `signal` is the DataElement, Operation, or BSW API. Direction always left-to-right or top-to-bottom.
+   - C/S sync vs async: append `[sync]` or `[async]` to the arrow label.
+   - ASIL tag inline: append `[ASIL-B]` to the box or arrow where safety-relevant.
+3. **Component diagrams**: list boxes top to bottom, arrows between them. Use fan-in / fan-out with `┐ ┼ ┘` to keep grouping readable when several arrows target one box.
+4. **Sequence diagrams**: lifelines as columns headed `[SWC]` or `[<<ISR>> Name]` / `[<<Task>> Name]`; messages as horizontal arrows numbered in order (`1.`, `2.`, …); `activate` / `deactivate` not modelled — keep messages chronological in the list.
+5. **State machines**: list states one per line, then transitions in the form `STATE_A --[guard / event]--> STATE_B / action()`. Mark `entry`, `exit`, `do` actions on separate indented lines under each state.
+6. **Add a brief textual description** above the code block explaining what the diagram models and why each element is included.
+
+### Integration review
+
+1. **Determine SWC type** from the code/ARXML context.
+2. **Analyse port interfaces**: S/R (DataElement, direction, ComSpec, explicit vs implicit access), C/S (sync/async, error handling), Mode Switch, Parameter.
+3. **Validate RTE API calls** against the naming convention `Rte_<access>_<port>_<element>`. Flag mismatches.
+4. **Review runnable-to-event mapping**: TimingEvent period, DataReceivedEvent, InitEvent, ExclusiveArea declarations for shared variables.
+5. **Detect MCAL abstraction violations**: direct hardware register access in Application or Service SWCs is forbidden. All hardware interaction must route through MCAL via IoHwAb or BSW.
+6. **Check data-type compliance**:
+   - AUTOSAR platform types (`uint8`, `uint16`, `uint32`, `sint8`, `sint16`, `sint32`, `boolean`, `float32`, `float64`) — **no `_t` suffix**.
+   - ApplicationDataTypes are project-defined typedefs over platform types and conventionally do use `_t` (e.g., `BatMon_Voltage_mV_t`).
+   - Flag C native (`int`, `unsigned`, `float`) or C99 (`uint8_t`, `int16_t`, …) types in SWC code without an AUTOSAR mapping.
+7. **Report EB Tresos / ARXML concerns**: PortInterface existence, ComSpec alignment, runnable period vs OS task mapping.
+
+## Input expected
+
+- **Component design**: feature/function description; optionally target ECU hardware, ASIL level, existing SWC list.
+- **Interface definition**: signal/command/service description; optionally physical range, resolution, units, sender/receiver SWCs.
+- **SWC development**: feature description + port signals (names, directions, types, periods); optionally ASIL, OS task mapping, project structure.
+- **Diagram generation**: feature / component description, existing code, or AUTOSAR SWC spec; optionally specified diagram type (component / sequence / state machine).
+- **Integration review**: SWC C source / header with RTE API calls; optionally ARXML excerpt, integration problem description, EB Tresos error log.
+
+## Output format
+
+Begin every response with a one-line platform header: `Platform: Classic (CP)` or `Platform: Adaptive (AP)`. For Adaptive, use the AP report layouts in `references/adaptive-ap.md`; the Classic layouts below otherwise.
+
+### Component design
+
+~~~
+## AUTOSAR Component Design
+
+### Feature Decomposition
+[Responsibilities and SWC ownership]
+
+### SWC Inventory
+| SWC Name | Type | ASIL | Rationale |
+|----------|------|------|-----------|
+...
+
+### Port Interface Specification
+#### <SWCName>
+| Port Name | Dir | Type | Interface | DataElement | Period / Trigger |
+|-----------|-----|------|-----------|-------------|------------------|
+...
+
+### Runnable Specification
+| SWC | Runnable | Activation | Period | ExclusiveArea |
+|-----|----------|------------|--------|---------------|
+...
+
+### Composition Diagram (plain-text box-and-arrow)
+```
+[component diagram — boxes per SWC, arrows per S/R or C/S connection, layer headers]
+```
+
+### Integration Notes
+[ASIL, OS task, memory section, constraints]
+~~~
+
+### Interface definition
+
+~~~
+## Interface Definition: <InterfaceName>
+
+### Type: [SenderReceiver | ClientServer | ModeSwitch | Parameter]
+
+### Data Elements / Operations
+| Name | Type | Unit | Range | Resolution | InitValue | Notes |
+|------|------|------|-------|------------|-----------|-------|
+...
+
+### ARXML Sketch
+```xml
+[interface block]
+```
+
+### C Typedef Header
+```c
+[typedef header]
+```
+
+### ComSpec Notes
+[Sender / receiver ComSpec values, AliveTimeout recommendations]
+~~~
+
+### SWC development
+
+~~~
+## SWC Development: <SWCName>
+
+### SWC Classification
+[Type and rationale]
+
+### Port Interface Design
+| Port Name | Dir | Type | Interface | DataElement | AUTOSAR Type | InitValue |
+|-----------|-----|------|-----------|-------------|--------------|-----------|
+...
+
+### Runnable Specification
+| Runnable | Activation | Period | ExclusiveArea |
+|----------|------------|--------|---------------|
+...
+
+### C Skeleton
+
+**<SWCName>.h**
+```c
+[header file]
+```
+
+**<SWCName>.c**
+```c
+[source file]
+```
+
+### ARXML Excerpt
+```xml
+[ARXML block]
+```
+~~~
+
+### Diagram generation
+
+~~~
+## Diagram: <Title>
+
+### Type
+[Component | Sequence | State Machine]
+
+### Description
+[What this diagram models and why each element is included]
+
+### Diagram
+```
+[plain-text box-and-arrow diagram using the notation conventions]
+```
+~~~
+
+### Integration review
+
+~~~
+## AUTOSAR Integration Review
+
+### SWC Classification
+[Type and rationale]
+
+### Port Interface Analysis
+| Port Name | Type | Dir | Interface | DataElement / Operation | ComSpec Notes |
+|-----------|------|-----|-----------|-------------------------|---------------|
+...
+
+### RTE API Validation
+[Correct or incorrect API calls with line references and corrections]
+
+### Runnable-to-Event Mapping
+| Runnable | Activation Event | Period / Trigger | ExclusiveArea |
+|----------|------------------|------------------|---------------|
+...
+
+### MCAL / Abstraction Violations
+[Direct register accesses or incorrect BSW API use, with recommended alternatives]
+
+### Data Type Compliance
+[Platform type violations and corrections]
+
+### EB Tresos / ARXML Notes
+[ARXML consistency issues, ComSpec mismatches, missing configurations]
+~~~
+
+## Example
+
+### Example 1 — SWC development (Fan Control)
+
+**Input:**
+Develop a Fan Control SWC. It reads coolant temperature (uint16, degC×10, 10 ms period) and
+outputs a fan duty cycle (uint8, 0–100 %, 10 ms). Use a linear map: below 60 °C → 0 %,
+above 100 °C → 100 %. Application SWC, ASIL-QM.
+
+**Output:**
+~~~
+## SWC Development: FanControl_AppSWC
+
+### SWC Classification
+**Type:** Application SWC.
+**Rationale:** Pure algorithm — reads a temperature signal, applies a piecewise-linear map,
+writes a duty-cycle signal. No hardware access, no BSW service calls.
+
+### Port Interface Design
+| Port Name      | Dir | Type | Interface       | DataElement    | AUTOSAR Type | InitValue |
+|----------------|-----|------|-----------------|----------------|--------------|-----------|
+| RCoolantTemp   | R   | S/R  | CoolantTempIf   | Temp_degC10    | uint16       | 0         |
+| PFanDutyCycle  | P   | S/R  | FanDutyCycleIf  | DutyCycle_pct  | uint8        | 0         |
+
+### Runnable Specification
+| Runnable                     | Activation  | Period | ExclusiveArea |
+|------------------------------|-------------|--------|---------------|
+| FanControl_App_Init          | InitEvent   | —      | —             |
+| FanControl_App_MainRunnable  | TimingEvent | 10 ms  | —             |
+
+No ExclusiveArea required — no shared mutable state between runnables.
+
+### C Skeleton
+
+**FanControl_App.h**
+```c
+#ifndef FANCONTROL_APP_H
+#define FANCONTROL_APP_H
+
+#include "Rte_FanControl_AppSWC.h"
+
+extern void FanControl_App_Init(void);
+extern void FanControl_App_MainRunnable(void);
+
+#define FANCTRL_TEMP_LOW_DEGC10  (600U)   /* 60.0 degC */
+#define FANCTRL_TEMP_HIGH_DEGC10 (1000U)  /* 100.0 degC */
+
+#endif /* FANCONTROL_APP_H */
+```
+
+**FanControl_App.c**
+```c
+#include "FanControl_App.h"
+
+void FanControl_App_Init(void)
+{
+    (void)Rte_Write_PFanDutyCycle_DutyCycle_pct(0U);
+}
+
+void FanControl_App_MainRunnable(void)
+{
+    uint16 temp;
+    uint8  duty;
+
+    (void)Rte_Read_RCoolantTemp_Temp_degC10(&temp);
+
+    if (temp <= FANCTRL_TEMP_LOW_DEGC10) {
+        duty = 0U;
+    } else if (temp >= FANCTRL_TEMP_HIGH_DEGC10) {
+        duty = 100U;
+    } else {
+        duty = (uint8)(((uint32)(temp - FANCTRL_TEMP_LOW_DEGC10) * 100U) /
+                       (uint32)(FANCTRL_TEMP_HIGH_DEGC10 - FANCTRL_TEMP_LOW_DEGC10));
+    }
+
+    (void)Rte_Write_PFanDutyCycle_DutyCycle_pct(duty);
+}
+```
+
+### ARXML Excerpt
+```xml
+<APPLICATION-SW-COMPONENT-TYPE>
+  <SHORT-NAME>FanControl_AppSWC</SHORT-NAME>
+  <PORTS>
+    <R-PORT-PROTOTYPE>
+      <SHORT-NAME>RCoolantTemp</SHORT-NAME>
+      <REQUIRED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE">
+        /Interfaces/CoolantTempIf
+      </REQUIRED-INTERFACE-TREF>
+    </R-PORT-PROTOTYPE>
+    <P-PORT-PROTOTYPE>
+      <SHORT-NAME>PFanDutyCycle</SHORT-NAME>
+      <PROVIDED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE">
+        /Interfaces/FanDutyCycleIf
+      </PROVIDED-INTERFACE-TREF>
+    </P-PORT-PROTOTYPE>
+  </PORTS>
+  <INTERNAL-BEHAVIORS>
+    <SWC-INTERNAL-BEHAVIOR>
+      <SHORT-NAME>FanControl_AppSWC_IB</SHORT-NAME>
+      <EVENTS>
+        <INIT-EVENT>
+          <SHORT-NAME>InitEvt</SHORT-NAME>
+          <START-ON-EVENT-REF DEST="RUNNABLE-ENTITY">.../FanControl_App_Init</START-ON-EVENT-REF>
+        </INIT-EVENT>
+        <TIMING-EVENT>
+          <SHORT-NAME>MainEvt_10ms</SHORT-NAME>
+          <START-ON-EVENT-REF DEST="RUNNABLE-ENTITY">.../FanControl_App_MainRunnable</START-ON-EVENT-REF>
+          <PERIOD>0.01</PERIOD>
+        </TIMING-EVENT>
+      </EVENTS>
+      <RUNNABLES>
+        <RUNNABLE-ENTITY><SHORT-NAME>FanControl_App_Init</SHORT-NAME></RUNNABLE-ENTITY>
+        <RUNNABLE-ENTITY><SHORT-NAME>FanControl_App_MainRunnable</SHORT-NAME></RUNNABLE-ENTITY>
+      </RUNNABLES>
+    </SWC-INTERNAL-BEHAVIOR>
+  </INTERNAL-BEHAVIORS>
+</APPLICATION-SW-COMPONENT-TYPE>
+```
+~~~
+
+### Example 2 — Integration review
+
+**Input:**
+```c
+/* BatteryMonitor.c */
+void BatteryMonitor_MainRunnable(void) {
+    float voltage;
+    Rte_Read_BattVoltage_Value(&voltage);
+    if (voltage < 11.5f) {
+        *((volatile uint32_t *)0x40021000U) = 0x01U; /* set warning LED */
+        Rte_Write_LowVoltageWarning_Active(TRUE);
+    }
+}
+```
+
+**Output:**
+~~~
+## AUTOSAR Integration Review
+
+### SWC Classification
+Application SWC — periodic signal processing with one required S/R port (sensor input)
+and one provided S/R port (diagnostic output). No direct hardware access should occur.
+
+### Port Interface Analysis
+| Port Name         | Type | Dir | Interface           | DataElement | ComSpec Notes               |
+|-------------------|------|-----|---------------------|-------------|------------------------------|
+| BattVoltage       | S/R  | R   | BattVoltageIf       | Value       | InitValue: 0, uint16 (10 mV) |
+| LowVoltageWarning | S/R  | P   | LowVoltageWarningIf | Active      | InitValue: FALSE, boolean    |
+
+### RTE API Validation
+- Line 3: `voltage` declared as `float` — incorrect. ApplicationDataType for BattVoltage.Value
+  must be `uint16` (fixed-point, 10 mV/LSB). Replace with:
+  `uint16 voltage; (void)Rte_Read_BattVoltage_Value(&voltage);`
+  Compare as `if (voltage < 1150U)` (11.5 V × 100 LSB/V).
+
+### MCAL / Abstraction Violations
+- Line 5: Direct register write `*((volatile uint32_t *)0x40021000U)` is a critical AUTOSAR
+  violation. Application SWCs must not access hardware registers. Route via IoHwAb:
+  `IoHwAb_SetWarningLED(IOHWAB_LED_WARNING, STD_HIGH);`
+  or model the LED actuator as an S/R provided port to a Sensor/Actuator SWC.
+
+### Data Type Compliance
+- `float` must not be used in SWC code without an AUTOSAR ApplicationDataType mapping. Use
+  fixed-point `uint16` with a documented resolution (10 mV/LSB).
+- `uint32_t` (C99) appears in the register write; even after the register access is removed
+  via IoHwAb, any remaining typed code must use AUTOSAR `uint32`.
+~~~
+
+### Example 3 — UML generation (Window Lift)
+
+**Input:**
+Generate a component diagram and a state machine for a window lift controller SWC. It receives
+a switch input (UP/DOWN/IDLE), drives a motor via IoHwAb, and has an anti-pinch safety feature
+that stops the window if force exceeds a threshold.
+
+**Output:**
+~~~
+## Diagram: Window Lift Controller
+
+### Type
+Component diagram + State machine.
+
+### Description
+Component view shows SWC topology and AUTOSAR layer boundaries. State machine models the
+window FSM including the anti-pinch safety reaction (ASIL-B). Plain-text box-and-arrow
+notation — no Mermaid / PlantUML renderer required.
+
+### Diagram — Component view
+```
+# Application Layer
+  [WindowLift_AppSWC]
+    ports: RSwitchInput, PMotorCmd, RForce_N, PWindowPos_mm
+
+# Sensor/Actuator Layer
+  [WindowLift_SensorActSWC]
+    ports: PSwitchInput, RMotorCmd, PForce_N
+
+# BSW / IoHwAb
+  [IoHwAb]
+  [MCAL: Adc, Dio, Pwm]
+
+# Connections (S/R unless noted)
+  [WindowLift_SensorActSWC]  ──SwitchStateIf.SwitchPosition──> [WindowLift_AppSWC]
+  [WindowLift_AppSWC]        ──MotorCmdIf.DutyCycle_pct────>   [WindowLift_SensorActSWC]
+  [WindowLift_SensorActSWC]  ──ForceIf.Force_N────────────>    [WindowLift_AppSWC]
+  [WindowLift_SensorActSWC]  ──Dio_ReadChannel  [sync, C/S]──> [IoHwAb]
+  [WindowLift_SensorActSWC]  ──Pwm_SetDutyCycle [sync, C/S]──> [IoHwAb]
+  [IoHwAb]                   ──register access────────────>    [MCAL: Adc, Dio, Pwm]
+```
+
+### Diagram — State machine (WindowLift_AppSWC) [ASIL-B]
+```
+States:
+  IDLE
+    entry / StopMotor()
+  MOVING_UP
+    do    / DriveMotorUp(duty=PWM_UP)
+  MOVING_DOWN
+    do    / DriveMotorDown(duty=PWM_DOWN)
+  ANTI_PINCH                                       [ASIL-B reaction]
+    entry / StopMotor(); ReverseMotor(); StartReverseTimer(200 ms)
+
+Transitions:
+  IDLE          --[SwitchInput == UP]----------------------------------> MOVING_UP
+  IDLE          --[SwitchInput == DOWN]--------------------------------> MOVING_DOWN
+
+  MOVING_UP     --[SwitchInput == IDLE]-------------> IDLE         / StopMotor()
+  MOVING_UP     --[WindowPos >= MAX_POS_MM]---------> IDLE         / StopMotor()
+  MOVING_UP     --[Force_N > FORCE_THRESHOLD]------> ANTI_PINCH    / StopMotor(), ReverseMotor()  [ASIL-B]
+
+  MOVING_DOWN   --[SwitchInput == IDLE]-------------> IDLE         / StopMotor()
+  MOVING_DOWN   --[WindowPos <= 0]-------------------> IDLE         / StopMotor()
+
+  ANTI_PINCH    --[ReverseTimer expired]------------> IDLE         / StopMotor()
+
+Notes:
+  ISO 26262 ASIL-B: ANTI_PINCH must activate within 500 ms of detection (SG-WINDOW-01).
+  FTTI budget: FDTI ≤ 100 ms (force-sample period) + FRTI ≤ 50 ms (motor stop reaction).
+```
+~~~

package/skills/autosar/autosar-swc/references/adaptive-ap.md

@@ -0,0 +1,69 @@
+# Adaptive AUTOSAR (AP) variant - Adaptive Applications and ara::com services
+
+Use this when the input names Adaptive AUTOSAR (AP): ara::com, ara::exec, C++14+, POSIX/Linux/QNX, service-oriented (SOA), manifests, proxy/skeleton, or Adaptive Application.
+
+AP replaces the static SWC/RTE/ARXML model with dynamic, service-oriented Adaptive Applications running as POSIX processes on the Adaptive Platform. There are no SWCs, ports, runnables, RTE, or ExclusiveAreas. You design service interfaces (events, methods, fields), implement provider skeletons and consumer proxies in C++14+, and deploy via manifests. Coding follows the AUTOSAR C++14 Guidelines / MISRA C++:2023, not MISRA C.
+
+## Classic-to-Adaptive mapping
+
+| Classic concept | Adaptive equivalent |
+|---|---|
+| SWC type (App/Sensor/Actuator/Service/CDD) | Adaptive Application (a process); functional clusters provide platform services |
+| Port (P/R) + PortInterface | Provided/Required service instance + service interface |
+| SenderReceiver DataElement | ara::com event (Send/Subscribe) or field (with on-change notify) |
+| ClientServer Operation | ara::com method (returns ara::core::Future) |
+| ModeSwitch | field, or Function-Group state via ara::exec State Management |
+| Parameter interface | configuration via manifest / ara::per |
+| RTE API (Rte_Read/Write/Call) | proxy/skeleton API: event Send/Subscribe, method call, field Get/Set |
+| Runnable on TimingEvent | application thread / timer; ara::exec lifecycle |
+| ExclusiveArea | standard C++ synchronization (std::mutex), RAII |
+| ARXML SWC + InternalBehavior | service interface description + deployment/execution manifests |
+| AUTOSAR platform types (uint8, sint16) | C++ fixed-width types and ara::core types; std:: containers allowed |
+
+## Modes (AP)
+
+### Component design -> Adaptive Application + service design
+1. Decompose the feature into Adaptive Applications (processes) and the services each provides or consumes.
+2. Define each service interface: events, methods, fields, with data types.
+3. Decide transport binding (SOME/IP or DDS) and service/instance IDs.
+4. Note ASIL, Function-Group state dependencies (ara::exec), and which functional clusters are used (ara::per, ara::diag, ara::log, ara::phm).
+5. Produce a plain-text deployment diagram: applications as boxes, service connections as arrows labeled with the service interface and binding.
+
+### Interface definition -> service interface specification
+1. Specify each element: event (data type, notification), method (IN/OUT params, ara::core::ErrorDomain for errors), field (data type, hasGetter/hasSetter/hasNotifier).
+2. Choose C++ data types; for serialization note alignment/endianness in the SOME/IP binding.
+3. Output: the service interface (ARXML/IDL sketch) and the matching C++ proxy/skeleton header expectations.
+
+### SWC development -> Adaptive Application skeleton
+1. Generate a C++14 skeleton: provider implements the generated Skeleton class, calls OfferService(), Send()s events, sets fields, registers method handlers returning ara::core::Future. Consumer uses FindService()/StartFindService(), constructs the Proxy, Subscribe()s to events with a receive handler, calls methods.
+2. Use RAII, ara::core::Result/Future for error handling (no raw error codes), smart pointers, std:: containers. Follow AUTOSAR C++14 / MISRA C++:2023 style.
+3. Provide the deployment manifest and execution manifest sketch (service/instance IDs, startup, Function-Group state).
+
+### Diagram generation
+Same plain-text box-and-arrow rules as Classic, but layers are: Adaptive Application(s) / ara:: Functional Clusters / OS (POSIX) / Hardware. Arrows carry service interface + event/method names and `[SOME/IP]` or `[DDS]`. No RTE layer.
+
+### Integration review
+Audit C++ source and manifests for: service/instance ID consistency between provider and consumer; correct proxy/skeleton API use; ara::core::Result/Future error handling (not ignored); Offer before consumers expect it; serialization config match; AUTOSAR C++14 naming and MISRA C++ style; no direct hardware access (route through the proper functional cluster or driver process). Flag use of MISRA C (wrong standard) or Classic RTE APIs in AP code.
+
+## Output format (AP)
+
+Begin with `Platform: Adaptive (AP)`. Mirror the Classic section headers but with AP terms, e.g.:
+```
+## Adaptive Application Design
+
+### Feature Decomposition
+[applications/processes and the services each provides/consumes]
+
+### Service Inventory
+| Service Interface | Provider App | Consumer App(s) | Binding | ASIL |
+
+### Service Interface Spec
+[events / methods / fields with C++ types]
+
+### Skeleton/Proxy Notes
+[Offer/Send/Subscribe/method-call snippets; ara::core::Future error handling]
+
+### Manifests
+[service instance IDs, execution manifest, Function-Group state]
+```
+For interface definition, SWC development, diagram, and integration review, reuse the corresponding Classic layout name with AP content.