aspice-architecture-review

name	aspice-architecture-review
description	SWE.2 software architecture review workflow for ASPICE 4.0 CL2 automotive embedded software. Use when reviewing an existing SAD, checking component allocations and interface completeness, verifying ASIL partition documentation and FFI measures, auditing requirement-to-component allocation, validating AUTOSAR SWC/port/runnable naming, or preparing the architecture for milestone review sign-off.
argument-hint	Paste or reference the SAD document, architecture diagram, or component table to review
user-invocable	true

ASPICE Architecture Review Skill (SWE.2)

When to Use

• Reviewing a Software Architecture Document (SAD) for ASPICE CL2 and ISO 26262 compliance
• Checking that all SWE-REQ-XXXX from the SRS are allocated to components
• Validating ASIL partition boundaries and Freedom-from-Interference (FFI) documentation
• Verifying AUTOSAR Classic SWC naming, port naming, and runnable conventions
• Verifying AUTOSAR Adaptive FC boundaries and ara:: service interface conventions
• Preparing the SAD for IN_REVIEW → APPROVED status transition

---

Workflow

Phase 1 — Load and Parse the Architecture Document

Extract from the SAD:

1. All SWC-XXXX component entries (with ASIL levels and platform tags)
2. All SWI-XXXX interface entries (with provider/consumer/protocol/ASIL)
3. The requirements-to-component allocation table
4. Any ASIL partition map or boundary diagram
5. HSI section (peripherals, clock, interrupt, memory map)

If any of these sections are missing, flag immediately:

• ❌ MISSING SECTION: Component table not found — required for SWE.2 compliance

Phase 2 — Requirement Coverage Check

Cross-reference every SWE-REQ-XXXX found in the SRS (or provided as input) against the allocation table:

SWE-REQ-ID	Allocated SWC	Status
SWE-REQ-0042	SWC-0003	✅ Allocated
SWE-REQ-0055	—	❌ UNALLOCATED — DEFECT

Rule: Every SWE-REQ-XXXX must have exactly one SWC-XXXX allocation.
Unallocated requirements are architecture defects — report as MAJOR finding.

Phase 3 — Interface Completeness Check

For each SWI-XXXX, verify:

• Provider SWC identified
• Consumer SWC identified
• Data type specified (use <stdint.h> types for C; strongly typed enum for C++)
• Signal range and unit stated
• ASIL level consistent with the higher of provider/consumer ASIL

Flag missing fields: ⚠️ INCOMPLETE SWI-XXXX: field <X> missing.

Phase 4 — ASIL Partition Verification

Identify all partition boundaries (ASIL A/B ↔ QM transitions):

1. Check partition diagram for boundary markers (dashed box).
2. For each boundary, verify all three FFI dimensions are documented:
   • Memory isolation measure
   • Timing isolation measure
   • Communication integrity measure (E2E profile for ASIL signals)

Partition Boundary Audit:
| Boundary         | Memory FFI | Timing FFI | Communication FFI | Status |
|------------------|-----------|------------|-------------------|--------|
| SWC-0001/SWC-0002| ✅ MPU    | ✅ OS task  | ✅ E2E Profile 02 | PASS   |
| SWC-0003/SWC-0004| ✅ MPU    | ⚠️ TBD     | ❌ No E2E         | FAIL   |

Any missing FFI dimension for an ASIL A/B boundary is a CRITICAL finding.

Phase 5 — AUTOSAR Conventions Audit

Classic Platform (if applicable):

• SWC names follow <Domain>_<Function>_Swc pattern
• Runnable names include period annotation (_10ms_Task) or event trigger (_On_<trigger>)
• Port names use R_<Interface> / P_<Interface> convention
• No shared global variables across SWC boundaries
• ASIL-relevant signals specify E2E protection profile

Adaptive Platform (if applicable):

• Service interfaces follow ara::<domain>::<service> namespace
• FC boundaries and inter-FC SOME/IP communication documented
• Service version and instance ID specified in interface table

Phase 6 — HSI Completeness Check

For ASIL A/B components, confirm the HSI section has:

• Peripheral list with pin/channel IDs
• Clock frequencies
• Interrupt priorities and latency budgets
• Memory map with ASIL partition boundaries

Flag: ⚠️ HSI-INCOMPLETE: <missing field> for any missing entry.

Phase 7 — Dependency Cycle Check

Review the component diagram for circular dependencies:

• A → B → A (direct cycle) → ❌ CIRCULAR: SWC-A depends on SWC-B which depends back on SWC-A
• Suggest dependency inversion or event/callback pattern as remediation.

Phase 8 — Produce Review Report

Architecture Review Report
==========================
SAD ID        : SAD-<PROJECT>-<VER>
Reviewer      : GitHub Copilot (automated architecture review)
Review Date   : <today's date>
ASIL Level    : <highest ASIL in architecture>

FINDINGS
--------
[ARC-001] Severity: CRITICAL | MAJOR | MINOR
  Category   : Partition FFI | Requirement allocation | Interface completeness | Conventions
  Component  : SWC-XXXX / SWI-XXXX
  Description: <specific finding>
  Remediation: <specific corrective action>

SUMMARY
-------
Total SWE-REQs checked    : <n>
Unallocated requirements  : <n>
FFI gaps                  : <n>
Interface gaps            : <n>
Convention violations     : <n>
Total Findings            : <n> (CRITICAL: <n>, MAJOR: <n>, MINOR: <n>)
Review Verdict            : APPROVED_FOR_REVIEW | NEEDS_REWORK

---

Output Artefacts

• Architecture Review Report with classified findings
• Updated allocation matrix (with gaps highlighted)
• Partition boundary audit table
• List of open findings to drive IN_REVIEW discussion

References

• SWE.2 Process Instructions
• SAD Prompt