autonomousguy 0.6.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (30) hide show
  1. package/LICENSE +21 -0
  2. package/README.md +96 -0
  3. package/bin/validate.js +119 -0
  4. package/package.json +54 -0
  5. package/skills/autosar/autosar-bsw/SKILL.md +586 -0
  6. package/skills/autosar/autosar-bsw/references/adaptive-ap.md +104 -0
  7. package/skills/autosar/autosar-bsw/references/boot-nvm-power.md +127 -0
  8. package/skills/autosar/autosar-bsw/references/com-stack.md +118 -0
  9. package/skills/autosar/autosar-bsw/references/comms-protocol.md +130 -0
  10. package/skills/autosar/autosar-swc/SKILL.md +531 -0
  11. package/skills/autosar/autosar-swc/references/adaptive-ap.md +69 -0
  12. package/skills/autosar/autosar-swc/references/rte-api.md +149 -0
  13. package/skills/change-management/change-and-impact/SKILL.md +259 -0
  14. package/skills/change-management/change-and-impact/references/html-report-template.html +154 -0
  15. package/skills/code-quality/code-review/SKILL.md +287 -0
  16. package/skills/code-quality/code-review/references/adaptive-ap.md +30 -0
  17. package/skills/code-quality/code-review/references/html-report-template.html +154 -0
  18. package/skills/code-quality/misra/SKILL.md +306 -0
  19. package/skills/code-quality/misra/references/html-report-template.html +154 -0
  20. package/skills/code-quality/misra/references/rules.md +72 -0
  21. package/skills/debugging/embedded-debugging/SKILL.md +250 -0
  22. package/skills/debugging/embedded-debugging/references/adaptive-ap.md +33 -0
  23. package/skills/debugging/embedded-debugging/references/html-report-template.html +154 -0
  24. package/skills/requirements/requirements/SKILL.md +298 -0
  25. package/skills/safety/iso26262/SKILL.md +199 -0
  26. package/skills/safety/iso26262/references/asil-table.md +86 -0
  27. package/skills/testing/embedded-testing/SKILL.md +288 -0
  28. package/skills/workspace/codebase-analysis/SKILL.md +548 -0
  29. package/skills/workspace/codebase-analysis/references/adaptive-ap.md +77 -0
  30. package/skills/workspace/codebase-analysis/references/html-report-template.html +154 -0
@@ -0,0 +1,548 @@
1
+ ---
2
+ name: codebase-analysis
3
+ short: Scan a workspace and produce a per-component CODEBASE_MAP.md with SWRs, interfaces, dependencies, and RTE APIs (Classic and Adaptive)
4
+ description: "First-run skill that walks the entire repository, auto-detects Classic vs Adaptive AUTOSAR, and maps it accordingly. For Classic (default): identifies features and SWCs and documents referenced requirement IDs (SW-REQ-*, REQ-*, FSR-*, SYS-REQ-*), port interfaces (S/R, C/S, Mode Switch, Parameter), dependencies on other SWCs and BSW modules (Com, NvM, Dem, Dcm, IoHwAb, Os), and concrete RTE API calls (Rte_Read_*, Rte_Write_*, Rte_Call_*, Rte_IRead_*, Rte_IWrite_*). For Adaptive (C++14, POSIX, ara::): identifies Adaptive Applications, ara::com service interfaces, ara:: functional-cluster usage, and manifests. Also captures repository structure, ASIL zones, signal/service flow, and architectural concerns. Writes findings to .autonomousguy/CODEBASE_MAP.md so every subsequent skill can reference it without re-reading the codebase; can emit a self-contained HTML companion report under analysis/."
5
+ category: workspace
6
+ tags: [onboarding, analysis, autosar, classic, adaptive, ap, swc, bsw, swr, traceability, rte, ara-com, ara-exec, posix, cpp, manifest, mapping]
7
+ ---
8
+
9
+ # Skill: Codebase Analysis
10
+
11
+ ## Context
12
+ You are an experienced embedded automotive software architect performing a first-time onboarding analysis of an unfamiliar codebase. Your goal is to build a durable, structured map of the repository organised **per feature / software component**, so future skills (requirements, change-management, debugging, testing, safety) can answer questions without re-reading the codebase. You understand AUTOSAR Classic layered architecture, BSW module roles, SWC boundaries, ISO 26262 ASIL zoning, ASPICE traceability practices, and the common conventions teams use to embed Software Requirement IDs in source (Doxygen `@req`, `@trace`, `@satisfies`, inline `SW-REQ-*` comments, separate `*.trace` / `*.csv` files, DOORS export sidecars).
13
+
14
+ ## Instructions
15
+
16
+ ### Operating principles (apply to every response)
17
+
18
+ Work autonomously within a single pass - no follow-up prompt should be needed:
19
+
20
+ 1. **Self-directed scope.** Map the whole repository you can see, not only the directory named. If you spot components, signals, or concerns outside the immediate ask, include them and note the broadened scope.
21
+ 2. **Decision-ready output.** Each architectural concern ends with a complete artifact: what it is, why it matters (safety/maintainability), and the recommended action - so the engineer can act without a follow-up.
22
+ 3. **Self-check before returning.** Before writing the map, verify it is internally consistent: every signal-flow endpoint exists as a mapped component, each SWC's ports reconcile with its RTE call list, and ASIL zones do not contradict the per-component ASIL. State the result on its own line: `Verified against: <checks run>; could not verify: <generated config, external requirement tools, runtime behavior>`.
23
+ 4. **Confidence and gaps.** Mark inferred mappings as inferred (e.g. ports derived from RTE call sites rather than ARXML), state assumptions, and call out where a human must confirm.
24
+
25
+ ### 0. Detect platform first
26
+ Decide whether the repo is Classic or Adaptive AUTOSAR before mapping, and record it in the map's ECU Overview:
27
+ - **Classic (CP)** signals (default): `.arxml` ECU/SWC config, `Rte_*` calls, BSW module config (EB Tresos `.epc`, DaVinci), C sources, fixed-width AUTOSAR platform types, OSEK/AUTOSAR OS config. Use steps 1-6 below as written.
28
+ - **Adaptive (AP)** signals: C++14+ sources, CMake, `ara::` includes/usage (`ara::com`, `ara::exec`, `ara::diag`, `ara::per`, `ara::log`), service interface descriptions, deployment/execution manifests (JSON/ARXML), POSIX/Linux/QNX target. If AP, switch to the Adaptive mapping in [`references/adaptive-ap.md`](references/adaptive-ap.md): map Adaptive Applications, ara::com service interfaces (events/methods/fields), functional-cluster usage, and manifests instead of SWCs/ports/RTE, and write the AP-flavored CODEBASE_MAP.md structure from that file.
29
+ - **Mixed** (CP and AP coexisting, e.g. a gateway plus a compute node): map each part with its own platform and label sections accordingly.
30
+
31
+ ### 1. Discover repository structure
32
+ - List source directories, identify the build system (CMake, Makefile, EB Tresos project), and locate ARXML, DBC, configuration, and requirement / traceability files (`*.req`, `*.csv`, `traceability*`, `requirements*`, `doc/`, DOORS / Polarion exports).
33
+ - Note the AUTOSAR toolchain in use (EB Tresos / DaVinci) and any AUTOSAR release version.
34
+
35
+ ### 2. Identify features and Software Components
36
+ - A **feature** is a coherent piece of functionality (e.g., "Battery Cell Monitoring", "Window Lift", "Anti-Pinch"). Group SWCs that collaborate on the same feature.
37
+ - For each SWC: name, type (Application / Sensor-Actuator / Service / CDD / Composition), source / header files, runnables and likely activation events.
38
+
39
+ ### 3. Per-component documentation — for each SWC, capture all of:
40
+
41
+ #### 3a. Software Requirement IDs
42
+ Scan source comments, headers, separate trace files, and requirement docs for any of these patterns and attribute them to the SWC that implements them:
43
+ - `SW-REQ-<MOD>-NNN`, `SWR-NNN`, `REQ-NNN`, `FSR-NNN`, `TSR-NNN`, `SYS-REQ-NNN`
44
+ - Doxygen / structured tags: `@req`, `@trace`, `@satisfies`, `@implements`, `@requirement`
45
+ - Markdown / inline link patterns: `Requirement: SW-REQ-…`, `Implements SW-REQ-…`
46
+ - Sidecar files: `*.trace`, `requirements.csv`, `swr_map.json`, DOORS/Polarion exports
47
+
48
+ For each found ID, record the source location (file:line or document path) so future skills can verify.
49
+
50
+ #### 3b. Port interfaces
51
+ Enumerate every port the SWC defines or consumes:
52
+ - Direction: **P** (provided) / **R** (required) / **PR** (combined)
53
+ - Type: **S/R** (SenderReceiver), **C/S** (ClientServer), **Mode** (ModeSwitch), **Param** (Parameter)
54
+ - Interface short-name and the DataElement(s) or Operation(s) involved
55
+ - Source: ARXML if available, otherwise inferred from RTE API call sites
56
+
57
+ #### 3c. Dependencies
58
+ Two flavours:
59
+ - **SWC-to-SWC** — derived from S/R or C/S connections (in the composition / ARXML). Record direction: "this SWC consumes signal X from `OtherSWC`" or "this SWC provides signal Y to `OtherSWC`".
60
+ - **SWC-to-BSW** — BSW modules the SWC calls (Com, NvM, Dem, Dcm, IoHwAb, Os, MemIf, Fee), with the specific APIs invoked.
61
+
62
+ #### 3d. RTE interfaces (actual API surface)
63
+ The concrete list of RTE calls each SWC makes, as found in the C source:
64
+ - `Rte_Read_<port>_<element>` / `Rte_IRead_<runnable>_<port>_<element>`
65
+ - `Rte_Write_<port>_<element>` / `Rte_IWrite_<runnable>_<port>_<element>`
66
+ - `Rte_Call_<port>_<operation>` / `Rte_Result_<port>_<operation>`
67
+ - `Rte_Receive_<port>_<element>` / `Rte_Send_<port>_<element>`
68
+ - `Rte_Mode_<port>` / `Rte_Switch_<port>_<mode>`
69
+ - `Rte_Enter_<area>` / `Rte_Exit_<area>`
70
+ - `Rte_Trigger_<port>` / `Rte_Feedback_<port>`
71
+
72
+ This is the runtime contract — preserve the full list so traceability, integration review, and change-impact skills can use it.
73
+
74
+ ### 4. Cross-cutting maps
75
+ - **BSW module usage** — which BSW modules are called and by which SWCs.
76
+ - **Signal flow** — plain-text box-and-arrow diagram inside a fenced code block, from hardware inputs → SWCs → outputs (actuators, CAN, DTCs). No external rendering (Mermaid, PlantUML) so the map renders identically in every viewer and in raw text.
77
+ - **ASIL zones** — locate ASIL annotations (comments, pragmas, linker scripts, memory section names) and map SWCs / modules to their partition.
78
+
79
+ ### 5. Architectural concerns
80
+ Flag findings worth attention:
81
+ - Direct hardware register access in Application / Service SWCs (MCAL abstraction violation).
82
+ - Shared mutable globals between runnables or ISR/runnable without ExclusiveArea.
83
+ - Missing ARXML for SWCs whose RTE calls suggest ports.
84
+ - SWCs with no SWR references (untraced).
85
+ - ASIL-tagged SWCs without a Safety Goal trace.
86
+ - Inconsistent naming (mixing C99 `_t` types with AUTOSAR platform types in SWC code).
87
+
88
+ ### 6. Write the map
89
+ Output the full analysis to `.autonomousguy/CODEBASE_MAP.md` using the structure below. Print a one-screen summary to the console.
90
+
91
+ ## Input expected
92
+ - Access to the full repository (run from the workspace root).
93
+ - Optionally: a brief description of the ECU's main function, target hardware, AUTOSAR toolchain in use, and any external requirements tool (DOORS / Polarion / Jama) so the SWR-discovery step can look for that tool's sidecar exports.
94
+
95
+ ## Output format
96
+
97
+ Write `.autonomousguy/CODEBASE_MAP.md` with this structure:
98
+
99
+ ~~~markdown
100
+ # Codebase Map — <Project Name>
101
+ Generated: <date>
102
+
103
+ ## ECU Overview
104
+ [One paragraph: ECU function, target MCU, AUTOSAR toolchain, ASIL level, requirements toolchain if any]
105
+
106
+ ## Repository Structure
107
+ [Key directories and their roles, including where SWRs / traceability data live]
108
+
109
+ ## Features
110
+ - **<FeatureName>** — owning SWCs: <SWC list>
111
+ - **<FeatureName>** — owning SWCs: <SWC list>
112
+
113
+ ---
114
+
115
+ ## Per-Component Detail
116
+
117
+ ### Feature: <FeatureName>
118
+
119
+ #### Component: <SWCName>
120
+ - **Type**: Application / Sensor-Actuator / Service / CDD / Composition
121
+ - **Source files**: `<file.c>`, `<file.h>`
122
+ - **Runnables**: `<SWC>_Init` (InitEvent), `<SWC>_MainRunnable` (TimingEvent, 10 ms), …
123
+ - **ASIL**: QM / A / B / C / D
124
+
125
+ ##### Software Requirements (SWRs)
126
+ | Requirement ID | Source | Notes |
127
+ |----------------|----------------------------------|-----------------------------|
128
+ | SW-REQ-<MOD>-001 | `BatMon_App.c:42` (`@req`) | Implemented in MainRunnable |
129
+ | FSR-001 | `requirements/batmon.md` | Traced via `@satisfies` tag |
130
+ | … | … | … |
131
+
132
+ ##### Port Interfaces
133
+ | Port Name | Dir | Type | Interface | DataElement / Operation | Source |
134
+ |-----------|-----|------|-------------------|--------------------------|----------------|
135
+ | RBattVoltage | R | S/R | BattVoltageIf | Voltage_mV | ARXML / line N |
136
+ | PLowVoltageWarning | P | S/R | LowVoltageWarningIf | Active | ARXML / line N |
137
+ | RNvMService | R | C/S | NvMService | ReadBlock, WriteBlock | RTE call site |
138
+ | … | … | … | … | … | … |
139
+
140
+ ##### Dependencies
141
+ **SWC-to-SWC** (from composition / ARXML):
142
+ - Consumes `Voltage_mV` from `BattVoltage_SensorSWC` via `BattVoltageIf`
143
+ - Provides `Active` to `DisplayCtrl_AppSWC` via `LowVoltageWarningIf`
144
+
145
+ **SWC-to-BSW**:
146
+ - **Com** — `Rte_Write_PLowVoltageWarning_Active` (indirect via RTE → Com)
147
+ - **Dem** — `Rte_Call_RDemService_SetEventStatus`
148
+ - **NvM** — `Rte_Call_RNvMService_ReadBlock` (for calibration)
149
+
150
+ ##### RTE Interfaces (actual API surface)
151
+ | RTE API | Direction | Used In | Notes |
152
+ |------------------------------------------------------|-----------|-------------------------|----------------------|
153
+ | `Rte_Read_RBattVoltage_Voltage_mV` | Receive | `BatMon_App.c:55` | Explicit S/R |
154
+ | `Rte_Write_PLowVoltageWarning_Active` | Send | `BatMon_App.c:71` | Explicit S/R |
155
+ | `Rte_Call_RDemService_SetEventStatus` | Invoke | `BatMon_App.c:78` | Synchronous |
156
+ | `Rte_Enter_EA_BatMonState` / `Rte_Exit_EA_BatMonState` | Mutex | `BatMon_App.c:62, 88` | Protects filter state |
157
+ | … | … | … | … |
158
+
159
+ (Repeat the `#### Component: …` block for every SWC in the feature, then repeat the `### Feature: …` block for every feature.)
160
+
161
+ ---
162
+
163
+ ## Cross-Cutting Maps
164
+
165
+ ### BSW Module Usage
166
+ | BSW Module | Used By SWCs | Key APIs Called |
167
+ |------------|--------------|------------------|
168
+ | Com | … | … |
169
+ | Dem | … | … |
170
+ | NvM | … | … |
171
+ | … | … | … |
172
+
173
+ ### Signal Flow
174
+
175
+ Plain-text box-and-arrow notation. Boxes are `[SWC / module]`. Arrows are `──signal──>` where `signal` is the DataElement, Operation, or BSW API. Use multi-line arrows for fan-out / fan-in.
176
+
177
+ ```
178
+ [Sensor / ADC] ──────────────────> [SensorActSWC]
179
+ [SensorActSWC] ──Voltage_mV──────> [BatMon_AppSWC]
180
+ [BatMon_AppSWC] ──Active──────────> [DisplayCtrl_AppSWC]
181
+ [BatMon_AppSWC] ──SetEventStatus──> [Dem]
182
+ [BatMon_AppSWC] ──CAN signal──────> [Com]
183
+ ```
184
+
185
+ ### ASIL Zone Map
186
+ | Zone | ASIL | SWCs / Modules | Memory Section |
187
+ |-------------|------|--------------------------|----------------|
188
+ | Battery monitor | B | BatMon_AppSWC, BattVoltage_SensorSWC | `.text.asilB` |
189
+ | Display | QM | DisplayCtrl_AppSWC | `.text.qm` |
190
+
191
+ ## Architectural Concerns
192
+ 1. [CRITICAL] …
193
+ 2. [MAJOR] …
194
+ 3. [INFO] …
195
+ ~~~
196
+
197
+ ## Example
198
+
199
+ **Input:** Repository for a Body Control Unit (BCU). CMake build, EB Tresos, AUTOSAR Classic 4.3, ARM Cortex-M MCU. Requirements managed in DOORS, exported as `requirements/bcu.csv`. Highest ASIL on the ECU: B (brake lights, per SG-BRAKELT-01).
200
+
201
+ **Output (excerpt written to `.autonomousguy/CODEBASE_MAP.md`):**
202
+
203
+ ~~~markdown
204
+ # Codebase Map — BCU_ECU
205
+ Generated: 2026-06-17
206
+
207
+ ## ECU Overview
208
+ Body Control Unit for a passenger vehicle. Hosts exterior lighting (low beam, high beam,
209
+ brake, turn indicators), interior lighting, central locking, and wiper control. Target:
210
+ ARM Cortex-M class MCU. AUTOSAR Classic 4.3, EB Tresos 26. Highest ASIL: B (brake lights
211
+ allocated to SG-BRAKELT-01 — driver-visible brake indication). Requirements in DOORS,
212
+ exported as `requirements/bcu.csv`.
213
+
214
+ ## Features
215
+ - **Exterior Lights**
216
+ - sub-feature: **Low Beam Light** — owning SWCs: LowBeam_AppSWC
217
+ - sub-feature: **High Beam Light** — owning SWCs: HighBeam_AppSWC
218
+ - sub-feature: **Brake Lights (ASIL B)**— owning SWCs: BrakeLight_AppSWC
219
+ - shared SWCs (all sub-features): LightSwitch_SensorSWC, LightOutput_ActuatorSWC, LightDiag_ServiceSWC
220
+
221
+ ---
222
+
223
+ ## Per-Component Detail
224
+
225
+ ### Feature: Exterior Lights / Low Beam Light
226
+
227
+ #### Component: LowBeam_AppSWC
228
+ - **Type**: Application
229
+ - **Source files**: `LowBeam_App.c`, `LowBeam_App.h`
230
+ - **Runnables**: `LowBeam_App_Init` (InitEvent), `LowBeam_App_MainRunnable` (TimingEvent, 20 ms)
231
+ - **ASIL**: QM
232
+
233
+ ##### Software Requirements (SWRs)
234
+ | Requirement ID | Source | Notes |
235
+ |---------------------|----------------------------------------|----------------------------------------------------|
236
+ | SW-REQ-LOWBEAM-001 | `LowBeam_App.c:24` (`@req`) | Activate low beam when switch position = ON / AUTO |
237
+ | SW-REQ-LOWBEAM-002 | `LowBeam_App.c:48` (`@req`) | Auto-on when ambient light < 200 lux for ≥ 2 s |
238
+ | SW-REQ-LOWBEAM-003 | `LowBeam_App.c:71` (`@implements`) | Disable when high beam active to prevent double-on |
239
+ | SYS-REQ-LIGHT-014 | `requirements/bcu.csv` row 14 | DOORS link via SWR-001 |
240
+
241
+ ##### Port Interfaces
242
+ | Port Name | Dir | Type | Interface | DataElement / Operation | Source |
243
+ |--------------------|-----|------|---------------------|--------------------------|----------------|
244
+ | RSwitchPosition | R | S/R | LightSwitchIf | Position | ARXML |
245
+ | RAmbientLight_lux | R | S/R | AmbientLightIf | Illuminance_lux | ARXML |
246
+ | RHighBeamActive | R | S/R | HighBeamStateIf | Active | ARXML |
247
+ | PLowBeamRequest | P | S/R | LowBeamRequestIf | Active | ARXML |
248
+
249
+ ##### Dependencies
250
+ **SWC-to-SWC**:
251
+ - Consumes `Position` from `LightSwitch_SensorSWC` via `LightSwitchIf`.
252
+ - Consumes `Illuminance_lux` from `AmbientLight_SensorSWC` via `AmbientLightIf`.
253
+ - Consumes `Active` from `HighBeam_AppSWC` via `HighBeamStateIf`.
254
+ - Provides `Active` to `LightOutput_ActuatorSWC` via `LowBeamRequestIf`.
255
+
256
+ **SWC-to-BSW**:
257
+ - None directly (no BSW calls; all I/O goes through the actuator SWC).
258
+
259
+ ##### RTE Interfaces
260
+ | RTE API | Direction | Used In | Notes |
261
+ |-------------------------------------------------|-----------|--------------------------|--------------------|
262
+ | `Rte_Read_RSwitchPosition_Position` | Receive | `LowBeam_App.c:58` | Explicit S/R |
263
+ | `Rte_Read_RAmbientLight_lux_Illuminance_lux` | Receive | `LowBeam_App.c:62` | Explicit S/R |
264
+ | `Rte_Read_RHighBeamActive_Active` | Receive | `LowBeam_App.c:66` | Explicit S/R |
265
+ | `Rte_Write_PLowBeamRequest_Active` | Send | `LowBeam_App.c:104` | Explicit S/R |
266
+
267
+ ---
268
+
269
+ ### Feature: Exterior Lights / High Beam Light
270
+
271
+ #### Component: HighBeam_AppSWC
272
+ - **Type**: Application
273
+ - **Source files**: `HighBeam_App.c`, `HighBeam_App.h`
274
+ - **Runnables**: `HighBeam_App_Init` (InitEvent), `HighBeam_App_MainRunnable` (TimingEvent, 20 ms)
275
+ - **ASIL**: QM
276
+
277
+ ##### Software Requirements (SWRs)
278
+ | Requirement ID | Source | Notes |
279
+ |----------------------|--------------------------------------|---------------------------------------------------|
280
+ | SW-REQ-HIBEAM-001 | `HighBeam_App.c:26` (`@req`) | Activate high beam on stalk push (latched) |
281
+ | SW-REQ-HIBEAM-002 | `HighBeam_App.c:52` (`@req`) | Deactivate on second stalk push or low beam off |
282
+ | SW-REQ-HIBEAM-003 | `HighBeam_App.c:78` (`@req`) | Flash-to-pass: 500 ms pulse on stalk pull |
283
+ | SW-REQ-HIBEAM-004 | `HighBeam_App.c:95` (`@implements`) | Auto-suppress above vehicle speed signal valid |
284
+ | SYS-REQ-LIGHT-021 | `requirements/bcu.csv` row 21 | DOORS link via SWR-001 |
285
+
286
+ ##### Port Interfaces
287
+ | Port Name | Dir | Type | Interface | DataElement / Operation | Source |
288
+ |---------------------|-----|------|---------------------|--------------------------|----------------|
289
+ | RSwitchPosition | R | S/R | LightSwitchIf | Position | ARXML |
290
+ | RStalkEvent | R | S/R | StalkEventIf | Event | ARXML |
291
+ | RVehicleSpeed_kph | R | S/R | VehicleSpeedIf | Speed_kph | ARXML |
292
+ | PHighBeamRequest | P | S/R | HighBeamRequestIf | Active | ARXML |
293
+ | PHighBeamActive | P | S/R | HighBeamStateIf | Active | ARXML |
294
+
295
+ ##### Dependencies
296
+ **SWC-to-SWC**:
297
+ - Consumes `Position` from `LightSwitch_SensorSWC` via `LightSwitchIf`.
298
+ - Consumes `Event` from `LightSwitch_SensorSWC` via `StalkEventIf`.
299
+ - Consumes `Speed_kph` from external `VehicleSpeed_GwSWC` via `VehicleSpeedIf` (CAN gateway).
300
+ - Provides `Active` to `LightOutput_ActuatorSWC` via `HighBeamRequestIf`.
301
+ - Provides `Active` to `LowBeam_AppSWC` via `HighBeamStateIf`.
302
+
303
+ **SWC-to-BSW**:
304
+ - None directly.
305
+
306
+ ##### RTE Interfaces
307
+ | RTE API | Direction | Used In | Notes |
308
+ |------------------------------------------------------|-----------|--------------------------|--------------------|
309
+ | `Rte_Read_RSwitchPosition_Position` | Receive | `HighBeam_App.c:64` | Explicit S/R |
310
+ | `Rte_Read_RStalkEvent_Event` | Receive | `HighBeam_App.c:70` | Explicit S/R |
311
+ | `Rte_Read_RVehicleSpeed_kph_Speed_kph` | Receive | `HighBeam_App.c:103` | Explicit S/R |
312
+ | `Rte_Write_PHighBeamRequest_Active` | Send | `HighBeam_App.c:118` | Explicit S/R |
313
+ | `Rte_Write_PHighBeamActive_Active` | Send | `HighBeam_App.c:120` | State broadcast |
314
+
315
+ ---
316
+
317
+ ### Feature: Exterior Lights / Brake Lights (ASIL B)
318
+
319
+ #### Component: BrakeLight_AppSWC
320
+ - **Type**: Application
321
+ - **Source files**: `BrakeLight_App.c`, `BrakeLight_App.h`
322
+ - **Runnables**: `BrakeLight_App_Init` (InitEvent), `BrakeLight_App_MainRunnable` (TimingEvent, 10 ms)
323
+ - **ASIL**: B
324
+
325
+ ##### Software Requirements (SWRs)
326
+ | Requirement ID | Source | Notes |
327
+ |------------------------|----------------------------------------|-------------------------------------------------------------|
328
+ | SW-REQ-BRAKELT-001 | `BrakeLight_App.c:30` (`@req`) | Activate brake lights when brake pedal pressed |
329
+ | SW-REQ-BRAKELT-002 | `BrakeLight_App.c:56` (`@req`) | FTTI ≤ 100 ms from pedal switch active to light request out |
330
+ | SW-REQ-BRAKELT-003 | `BrakeLight_App.c:78` (`@implements`) | Plausibility check vs CAN brake pressure signal |
331
+ | SW-REQ-BRAKELT-004 | `BrakeLight_App.c:115` (`@req`) | Fault reaction: force-on if input plausibility fails |
332
+ | FSR-BRAKELT-001 | `requirements/bcu.csv` row 47 | Functional Safety Requirement from SG-BRAKELT-01 |
333
+ | SG-BRAKELT-01 | `BrakeLight_App.h:9` (`@trace`) | Safety Goal: "BCU shall activate brake lights within 100 ms of brake pedal application" |
334
+
335
+ ##### Port Interfaces
336
+ | Port Name | Dir | Type | Interface | DataElement / Operation | Source |
337
+ |------------------------|-----|------|------------------------|--------------------------|----------------|
338
+ | RBrakePedal_Switch | R | S/R | BrakePedalSwitchIf | Pressed | ARXML |
339
+ | RBrakePressure_bar | R | S/R | BrakePressureIf | Pressure_dbar | ARXML |
340
+ | PBrakeLightRequest | P | S/R | BrakeLightRequestIf | Active | ARXML |
341
+ | PBrakeLightFaultStatus | P | S/R | BrakeLightFaultIf | FaultActive | ARXML |
342
+ | RDemSetEvent | R | C/S | Dem_SetEventStatusIf | SetEventStatus | ARXML / RTE |
343
+
344
+ ##### Dependencies
345
+ **SWC-to-SWC**:
346
+ - Consumes `Pressed` from `BrakePedal_SensorSWC` via `BrakePedalSwitchIf`.
347
+ - Consumes `Pressure_dbar` from `BrakePressure_GwSWC` (CAN gateway from ESP) via `BrakePressureIf`.
348
+ - Provides `Active` to `LightOutput_ActuatorSWC` via `BrakeLightRequestIf`.
349
+ - Provides `FaultActive` to `LightDiag_ServiceSWC` via `BrakeLightFaultIf`.
350
+
351
+ **SWC-to-BSW**:
352
+ - **Dem** — `Rte_Call_RDemSetEvent_SetEventStatus` for `DEM_EVENT_BRAKELT_PLAUSIBILITY`.
353
+
354
+ ##### RTE Interfaces
355
+ | RTE API | Direction | Used In | Notes |
356
+ |----------------------------------------------------------|-----------|----------------------------|------------------------------------|
357
+ | `Rte_Read_RBrakePedal_Switch_Pressed` | Receive | `BrakeLight_App.c:88` | Explicit S/R, primary input |
358
+ | `Rte_Read_RBrakePressure_bar_Pressure_dbar` | Receive | `BrakeLight_App.c:92` | Plausibility cross-check input |
359
+ | `Rte_Write_PBrakeLightRequest_Active` | Send | `BrakeLight_App.c:131` | Explicit S/R |
360
+ | `Rte_Write_PBrakeLightFaultStatus_FaultActive` | Send | `BrakeLight_App.c:138` | Explicit S/R |
361
+ | `Rte_Call_RDemSetEvent_SetEventStatus` | Invoke | `BrakeLight_App.c:141` | Synchronous, ASIL-B event |
362
+ | `Rte_Enter_EA_BrakeLightState` / `Rte_Exit_EA_BrakeLightState` | Mutex | `BrakeLight_App.c:84, 144` | Protects debounce state from diag read |
363
+
364
+ ---
365
+
366
+ ### Feature: Exterior Lights / Shared Components
367
+
368
+ #### Component: LightSwitch_SensorSWC
369
+ - **Type**: Sensor/Actuator
370
+ - **Source files**: `LightSwitch_SA.c`, `LightSwitch_SA.h`
371
+ - **Runnables**: `SA_Init`, `SA_MainRunnable` (TimingEvent, 20 ms)
372
+ - **ASIL**: QM
373
+
374
+ ##### Software Requirements (SWRs)
375
+ | Requirement ID | Source | Notes |
376
+ |------------------------|----------------------------------------|-----------------------------------------------|
377
+ | SW-REQ-LIGHTSW-001 | `LightSwitch_SA.c:18` (`@req`) | Map Dio pattern → Position enum (OFF/AUTO/LOW)|
378
+ | SW-REQ-LIGHTSW-002 | `LightSwitch_SA.c:44` (`@req`) | Debounce 40 ms (2 consecutive scans) |
379
+ | SW-REQ-LIGHTSW-003 | `LightSwitch_SA.c:71` (`@implements`) | Stalk pull/push edge → StalkEvent |
380
+
381
+ ##### Port Interfaces
382
+ | Port Name | Dir | Type | Interface | DataElement / Operation | Source |
383
+ |------------------|-----|------|-----------------|--------------------------|----------------|
384
+ | PSwitchPosition | P | S/R | LightSwitchIf | Position | ARXML |
385
+ | PStalkEvent | P | S/R | StalkEventIf | Event | ARXML |
386
+ | RDio_ReadChannel | R | C/S | IoHwAbDioIf | ReadChannel | ARXML |
387
+
388
+ ##### Dependencies
389
+ **SWC-to-SWC**: Provides `Position` to `LowBeam_AppSWC`, `HighBeam_AppSWC`; `Event` to `HighBeam_AppSWC`.
390
+ **SWC-to-BSW**: **IoHwAb** — `Rte_Call_RDio_ReadChannel_ReadChannel`.
391
+
392
+ ##### RTE Interfaces
393
+ | RTE API | Direction | Used In | Notes |
394
+ |-----------------------------------------------|-----------|-------------------------|--------------|
395
+ | `Rte_Call_RDio_ReadChannel_ReadChannel` | Invoke | `LightSwitch_SA.c:62` | Synchronous |
396
+ | `Rte_Write_PSwitchPosition_Position` | Send | `LightSwitch_SA.c:88` | Explicit S/R |
397
+ | `Rte_Write_PStalkEvent_Event` | Send | `LightSwitch_SA.c:94` | Explicit S/R |
398
+
399
+ #### Component: LightOutput_ActuatorSWC
400
+ - **Type**: Sensor/Actuator
401
+ - **Source files**: `LightOutput_SA.c`, `LightOutput_SA.h`
402
+ - **Runnables**: `SA_Init`, `SA_MainRunnable` (TimingEvent, 10 ms)
403
+ - **ASIL**: B (inherits from BrakeLightRequest path; ASIL decomposition not claimed)
404
+
405
+ ##### Software Requirements (SWRs)
406
+ | Requirement ID | Source | Notes |
407
+ |------------------------|----------------------------------------|----------------------------------------------------------|
408
+ | SW-REQ-LIGHTOUT-001 | `LightOutput_SA.c:22` (`@req`) | Drive Pwm/Dio outputs from Low/High/Brake request inputs |
409
+ | SW-REQ-LIGHTOUT-002 | `LightOutput_SA.c:64` (`@req`) | Read current sense; flag bulb-out |
410
+ | SW-REQ-LIGHTOUT-003 | `LightOutput_SA.c:91` (`@implements`) | Latency budget ≤ 10 ms (one task period) per FSR-BRAKELT-001|
411
+
412
+ ##### Port Interfaces
413
+ | Port Name | Dir | Type | Interface | DataElement / Operation | Source |
414
+ |--------------------------|-----|------|------------------------|--------------------------|----------------|
415
+ | RLowBeamRequest | R | S/R | LowBeamRequestIf | Active | ARXML |
416
+ | RHighBeamRequest | R | S/R | HighBeamRequestIf | Active | ARXML |
417
+ | RBrakeLightRequest | R | S/R | BrakeLightRequestIf | Active | ARXML |
418
+ | PBulbStatus | P | S/R | BulbStatusIf | OutBitfield | ARXML |
419
+ | RDio_WriteChannel | R | C/S | IoHwAbDioIf | WriteChannel | ARXML |
420
+ | RAdc_ReadCurrentSense | R | C/S | IoHwAbAdcIf | ReadChannel | ARXML |
421
+
422
+ ##### Dependencies
423
+ **SWC-to-SWC**: Consumes from `LowBeam_AppSWC`, `HighBeam_AppSWC`, `BrakeLight_AppSWC`. Provides `OutBitfield` to `LightDiag_ServiceSWC`.
424
+ **SWC-to-BSW**: **IoHwAb** — Dio writes for bulb drives, ADC reads for current sense.
425
+
426
+ ##### RTE Interfaces
427
+ | RTE API | Direction | Used In | Notes |
428
+ |------------------------------------------------------|-----------|--------------------------|------------------------|
429
+ | `Rte_Read_RLowBeamRequest_Active` | Receive | `LightOutput_SA.c:104` | Explicit S/R |
430
+ | `Rte_Read_RHighBeamRequest_Active` | Receive | `LightOutput_SA.c:108` | Explicit S/R |
431
+ | `Rte_Read_RBrakeLightRequest_Active` | Receive | `LightOutput_SA.c:112` | Explicit S/R, ASIL-B |
432
+ | `Rte_Call_RDio_WriteChannel_WriteChannel` | Invoke | `LightOutput_SA.c:128,134,140` | Per output bit |
433
+ | `Rte_Call_RAdc_ReadCurrentSense_ReadChannel` | Invoke | `LightOutput_SA.c:160` | Bulb-out detection |
434
+ | `Rte_Write_PBulbStatus_OutBitfield` | Send | `LightOutput_SA.c:178` | Explicit S/R |
435
+
436
+ #### Component: LightDiag_ServiceSWC
437
+ - **Type**: Service
438
+ - **Source files**: `LightDiag_Svc.c`, `LightDiag_Svc.h`
439
+ - **Runnables**: `Svc_Init`, `Svc_MonitorRunnable` (TimingEvent, 100 ms)
440
+ - **ASIL**: QM (bulb-out DTCs are non-safety) — except `DEM_EVENT_BRAKELT_BULB_OUT` which inherits ASIL-B
441
+
442
+ ##### Software Requirements (SWRs)
443
+ | Requirement ID | Source | Notes |
444
+ |----------------------|--------------------------------------|------------------------------------------------------|
445
+ | SW-REQ-LIGHTDIAG-001 | `LightDiag_Svc.c:20` (`@req`) | Report bulb-out per circuit via Dem |
446
+ | SW-REQ-LIGHTDIAG-002 | `LightDiag_Svc.c:48` (`@req`) | Debounce 3-of-5 reads before raising DTC |
447
+ | SW-REQ-LIGHTDIAG-003 | `LightDiag_Svc.c:71` (`@implements`) | Brake-light bulb DTC requires NvM persistence (ASIL-B)|
448
+
449
+ ##### Port Interfaces
450
+ | Port Name | Dir | Type | Interface | DataElement / Operation | Source |
451
+ |------------------------|-----|------|------------------------|--------------------------|----------------|
452
+ | RBulbStatus | R | S/R | BulbStatusIf | OutBitfield | ARXML |
453
+ | RBrakeLightFaultStatus | R | S/R | BrakeLightFaultIf | FaultActive | ARXML |
454
+ | RDemSetEvent | R | C/S | Dem_SetEventStatusIf | SetEventStatus | ARXML / RTE |
455
+
456
+ ##### Dependencies
457
+ **SWC-to-SWC**: Consumes from `LightOutput_ActuatorSWC`, `BrakeLight_AppSWC`.
458
+ **SWC-to-BSW**: **Dem** (set event status for bulb-out and plausibility DTCs).
459
+
460
+ ##### RTE Interfaces
461
+ | RTE API | Direction | Used In | Notes |
462
+ |--------------------------------------------------|-----------|--------------------------|--------------------------|
463
+ | `Rte_Read_RBulbStatus_OutBitfield` | Receive | `LightDiag_Svc.c:88` | Explicit S/R |
464
+ | `Rte_Read_RBrakeLightFaultStatus_FaultActive` | Receive | `LightDiag_Svc.c:92` | Explicit S/R |
465
+ | `Rte_Call_RDemSetEvent_SetEventStatus` | Invoke | `LightDiag_Svc.c:110,118,124` | One call per DTC ID |
466
+
467
+ ---
468
+
469
+ ## Cross-Cutting Maps
470
+
471
+ ### BSW Module Usage
472
+ | BSW Module | Used By SWCs | Key APIs Called |
473
+ |------------|--------------------------------------------------------|-------------------------------------------------------------------|
474
+ | IoHwAb | LightSwitch_SensorSWC, LightOutput_ActuatorSWC | `Rte_Call_RDio_ReadChannel`, `Rte_Call_RDio_WriteChannel`, `Rte_Call_RAdc_ReadCurrentSense` |
475
+ | Dem | BrakeLight_AppSWC, LightDiag_ServiceSWC | `Rte_Call_RDemSetEvent_SetEventStatus` |
476
+ | Com | (indirect — `VehicleSpeed_GwSWC`, `BrakePressure_GwSWC` consume CAN signals; not detailed here) | (via PduR/Com routing) |
477
+
478
+ ### Signal Flow
479
+
480
+ ```
481
+ INPUTS
482
+ [Dio inputs] ──────────────────────> [LightSwitch_SensorSWC]
483
+ [Brake pedal switch] ──────────────────────> [BrakePedal_SensorSWC]
484
+ [CAN: ESP brake pressure] ──────────────────────> [BrakePressure_GwSWC]
485
+ [CAN: vehicle speed] ──────────────────────> [VehicleSpeed_GwSWC]
486
+
487
+ SWITCH / INPUT DISTRIBUTION
488
+ [LightSwitch_SensorSWC] ──Position────────────> [LowBeam_AppSWC]
489
+ [LightSwitch_SensorSWC] ──Position, StalkEvent─> [HighBeam_AppSWC]
490
+ [VehicleSpeed_GwSWC] ──Speed_kph───────────> [HighBeam_AppSWC]
491
+ [HighBeam_AppSWC] ──HighBeamState.Active─> [LowBeam_AppSWC] (suppress low beam when high active)
492
+
493
+ BRAKE LIGHT CHAIN (ASIL B)
494
+ [BrakePedal_SensorSWC] ──Pressed─────────────> [BrakeLight_AppSWC]
495
+ [BrakePressure_GwSWC] ──Pressure_dbar───────> [BrakeLight_AppSWC] (plausibility cross-check)
496
+
497
+ REQUEST AGGREGATION
498
+ [LowBeam_AppSWC] ──LowBeamRequest──┐
499
+ [HighBeam_AppSWC] ──HighBeamRequest──┼──> [LightOutput_ActuatorSWC]
500
+ [BrakeLight_AppSWC] ──BrakeLightRequest┘
501
+
502
+ ACTUATION
503
+ [LightOutput_ActuatorSWC] ──Dio_WriteChannel───> [Bulb outputs]
504
+ [LightOutput_ActuatorSWC] ──Adc_ReadChannel────> (current sense, internal)
505
+
506
+ DIAGNOSTICS
507
+ [LightOutput_ActuatorSWC] ──BulbStatus.OutBitfield─> [LightDiag_ServiceSWC]
508
+ [BrakeLight_AppSWC] ──FaultActive──────────> [LightDiag_ServiceSWC]
509
+ [LightDiag_ServiceSWC] ──Dem_SetEventStatus──> [Dem]
510
+ [BrakeLight_AppSWC] ──Dem_SetEventStatus──> [Dem] (ASIL-B event, direct)
511
+ ```
512
+
513
+ ### ASIL Zone Map
514
+ | Zone | ASIL | SWCs | Memory Section |
515
+ |-------------------------|------|--------------------------------------------------|----------------|
516
+ | Brake lights (safety) | B | BrakeLight_AppSWC, LightOutput_ActuatorSWC (mixed) | `.text.asilB` |
517
+ | Low / high beam | QM | LowBeam_AppSWC, HighBeam_AppSWC, LightSwitch_SensorSWC | `.text.qm` |
518
+ | Diagnostic | B/QM | LightDiag_ServiceSWC (brake DTC = B, others = QM) | `.text.asilB` (brake-related), `.text.qm` (others) |
519
+
520
+ ## Architectural Concerns
521
+ 1. **[CRITICAL]** `BrakeLight_App.c:131` writes `Rte_Write_PBrakeLightRequest_Active` while `LightOutput_ActuatorSWC` runs at the same 10 ms period in a different OS task. End-to-end FTTI is at risk of exceeding 100 ms (SW-REQ-BRAKELT-002) if both tasks land on the same priority without task-chaining; verify in OS configuration.
522
+ 2. **[MAJOR]** `LightOutput_ActuatorSWC` is mixed-ASIL (brake = B, low/high = QM) but lives in a single OS-Application. Either (a) split into two SWCs by ASIL, or (b) confirm Freedom-from-Interference via memory-protection and Dependent Failure Analysis (ISO 26262-9 §5).
523
+ 3. **[MAJOR]** `s_BrakeLight_DebounceCount` accessed from `BrakeLight_App_MainRunnable` and the diagnostic read path (`LightDiag_Svc.c:92`) — `EA_BrakeLightState` is declared but only entered on the writer side; the reader needs the same `Rte_Enter_EA_BrakeLightState` wrap.
524
+ 4. **[INFO]** `HighBeam_AppSWC` requirement SW-REQ-HIBEAM-004 ("auto-suppress above vehicle speed signal valid") has no test case referenced in `requirements/bcu.csv` — flag to the traceability skill.
525
+ 5. **[INFO]** `LightDiag_ServiceSWC` Dem event IDs are referenced by macro name but their numeric assignment lives in `Dem_Cfg.h` (generated). After regeneration the macro list should be cross-checked.
526
+ ~~~
527
+
528
+ ## HTML report (optional, additive)
529
+
530
+ `.autonomousguy/CODEBASE_MAP.md` is always the primary artifact. In addition, when the map is substantial, offer to write a self-contained HTML companion report - a scannable view of the component index and architectural concerns. It never replaces the Markdown map.
531
+
532
+ **Structure - progressive disclosure, lean not dense:**
533
+ - *Header (thin):* project name, timestamp, "Codebase analysis", scope (platform CP/AP/Mixed, AUTOSAR release).
534
+ - *Layer 1 - summary banner (always visible):* one row of 4-5 numbers - components mapped, BSW modules used, architectural concerns, untraced components (no SWR), highest ASIL present. Graspable in two seconds.
535
+ - *Layer 2 - grouped table (scannable):* one row per architectural concern (or per component). Lean columns only - location, component/area, one-line description, severity chip (Critical/Major/Info), "has fix/action" indicator. No detail text in rows. Include a search/filter box and sortable columns.
536
+ - *Layer 3 - expandable detail (`<details>`, collapsed by default):* per concern - the explanation, the evidence (file:line), and the recommended action; per component - its ports, dependencies, and RTE surface.
537
+ - *Footer (thin):* limitations, what could not be verified, inferred-data disclaimer (ports inferred from RTE call sites, etc.).
538
+
539
+ **Style:** one self-contained `.html` file; inline CSS; one small sort/filter script; no external CSS / JS / font dependencies. ASCII only, no em dashes. Severity and status shown as small colored chips, not walls of text. If in doubt, push detail into Layer 3 and keep Layers 1-2 minimal. Use [`references/html-report-template.html`](references/html-report-template.html) as the skeleton: fill the header, the Layer 1 stat cells, one lean table row per concern/component, and one collapsed `<details>` block per concern/component.
540
+
541
+ **Where to write it:**
542
+ 1. Detect a project root by walking up from the working directory for `.git` or another clear project marker.
543
+ 2. **Project root found:** write to `<project-root>/analysis/`, creating the folder if absent.
544
+ 3. **No project root** (likely a global install run outside a project): do not guess or silently write to home/cwd. Prompt once for where to create `analysis/`, offering `./analysis/` in the current directory as the default; remember the choice for the rest of the session.
545
+ 4. Always report the exact path written.
546
+ 5. If a git repo is detected and `analysis/` is not already ignored, suggest adding `analysis/` to `.gitignore`.
547
+
548
+ Filename: `analysis/codebase-analysis-<short-timestamp>.html` (for example `codebase-analysis-20260621-1930.html`) so repeated runs do not overwrite.
@@ -0,0 +1,77 @@
1
+ # Adaptive AUTOSAR (AP) variant - mapping an Adaptive codebase
2
+
3
+ Use this when step 0 detects an Adaptive AUTOSAR repo: C++14+, CMake, ara:: usage, manifests, POSIX/Linux/QNX.
4
+
5
+ AP has no SWCs, ports, runnables, RTE, or BSW. Map the equivalent AP concepts instead, keeping the same CODEBASE_MAP.md spirit (durable per-component map other skills reference).
6
+
7
+ ## What to scan for
8
+
9
+ - **Adaptive Applications**: each is a process/executable. Find them from CMake targets, `main()` entry points, and execution manifests. Record name, source dir, and the services it provides/consumes.
10
+ - **Service interfaces (ara::com)**: events, methods, fields. Find from generated proxy/skeleton headers and service interface descriptions. Record data types and binding (SOME/IP or DDS), service ID and instance ID.
11
+ - **Functional-cluster usage**: which ara:: clusters each app uses - ara::com (communication), ara::exec (Execution Management / lifecycle), ara::diag (diagnostics, replaces Dcm/Dem), ara::per (persistency, replaces NvM), ara::log (logging), ara::phm (health/watchdog). Record the concrete API surface (e.g. `OfferService`, `Subscribe`, `Send`, method calls, `OpenKeyValueStorage`).
12
+ - **Manifests**: Machine Manifest (network, transport), Execution Manifest (per process startup, Function-Group state deps), Service Instance Manifest (service-to-instance binding). Record key IDs and dependencies.
13
+ - **Requirement IDs**: same patterns as Classic (SW-REQ-*, REQ-*, FSR-*, SYS-REQ-*, Doxygen `@req`/`@trace`), scanned in C++ sources and docs.
14
+ - **ASIL zones**: from annotations, partitioning, and which Function-Groups/processes are safety-relevant.
15
+
16
+ ## CODEBASE_MAP.md structure (AP)
17
+
18
+ ```markdown
19
+ # Codebase Map - <Project Name> (Adaptive AUTOSAR)
20
+ Generated: <date>
21
+
22
+ ## Platform
23
+ Adaptive AUTOSAR (AP). Target: <Linux/QNX>. Toolchain/stack: <vendor AP stack>. Transport: SOME/IP | DDS.
24
+
25
+ ## Overview
26
+ [One paragraph: compute node function, OS, AP stack, ASIL, requirements toolchain]
27
+
28
+ ## Repository Structure
29
+ [Key dirs, CMake layout, where manifests and service interfaces live]
30
+
31
+ ## Adaptive Applications
32
+ - **<AppName>** - provides: <services>; consumes: <services>; clusters: ara::com, ara::per, ...
33
+
34
+ ---
35
+
36
+ ## Per-Application Detail
37
+
38
+ ### Application: <AppName>
39
+ - **Executable / source dir**: ...
40
+ - **ASIL**: QM/A/B/C/D
41
+ - **Function-Group state dependency** (ara::exec): ...
42
+
43
+ ##### Software Requirements
44
+ | Requirement ID | Source | Notes |
45
+
46
+ ##### Service Interfaces
47
+ | Service | Role (provide/consume) | Element (event/method/field) | Data Type | Binding | Service/Instance ID |
48
+
49
+ ##### Functional Cluster Usage
50
+ | Cluster | APIs Used | Purpose |
51
+ | ara::com | OfferService, Send, Subscribe | event provider/consumer |
52
+ | ara::per | OpenKeyValueStorage | persistence |
53
+ | ara::diag | DTC, monitor | diagnostics |
54
+ | ara::exec | ReportExecutionState | lifecycle |
55
+
56
+ ##### Manifests
57
+ - Execution Manifest: startup, state deps
58
+ - Service Instance Manifest: service -> instance binding
59
+
60
+ (Repeat per Adaptive Application.)
61
+
62
+ ---
63
+
64
+ ## Cross-Cutting Maps
65
+
66
+ ### Service Flow
67
+ Plain-text box-and-arrow: applications as boxes, arrows labeled with service interface + event/method and `[SOME/IP]` or `[DDS]`.
68
+
69
+ ### Functional Cluster Map
70
+ | Cluster | Used By Apps | Notes |
71
+
72
+ ### ASIL Zone Map
73
+ | Zone | ASIL | Apps / Function-Groups | Notes |
74
+
75
+ ## Architectural Concerns
76
+ - service/instance ID mismatches, missing offers, ignored ara::core::Result, serialization mismatches, MISRA C used where MISRA C++ applies, etc.
77
+ ```