thongdt89/asr_bsw/autosar-system-reviewer

AUTOSAR System Reviewer

Workflow

1. Identify ECU lifecycle, wakeup, network mode, watchdog, and scheduling expectations.
2. Build or request an ARXML inventory if one is not already available.
3. Resolve references before mode, wakeup, and OS dependency checks.
4. For each asynchronous event, record its source, rate, worst-case burst, deadline, permitted jitter, processing cost, and safety/security relevance.
5. Select polling, interrupt, or hybrid handling. Prefer an interrupt only for a sporadic or deadline-critical event; keep ISR work bounded and defer noncritical processing to an OS task.
6. Review ISR category, priority, nesting, task/event activation, resource locking, priority inversion risk, and CPU-load budget. Treat driver or MCAL implementation details outside the ARXML scope as assumptions.
7. Use ../autosar-arxml-bsw-reviewer/scripts/check_system_modules.py for system module checks.
8. Use ../autosar-arxml-bsw-reviewer/scripts/check_os_schedule.py for OS and BSW main-function checks.
9. Load only the references needed for the task:

• ../autosar-arxml-bsw-reviewer/references/system_module_checks.md
• ../autosar-arxml-bsw-reviewer/references/system_module_semantic_model.md
• ../autosar-arxml-bsw-reviewer/references/os_schedule_checks.md
• ../autosar-arxml-bsw-reviewer/references/runnable_trigger_checks.md
• ../autosar-arxml-bsw-reviewer/references/ecuc_resource_configuration.md

Checks

• EcuM wakeup sources and driver/transceiver/channel connections.
• BswM rules, action lists, mode requests, and ComM/Nm/SM coordination.
• OS tasks, alarms, counters, events, ISRs, resources, and SchM exclusive-area risks.
• BSW main-function scheduling versus configured timing.
• Watchdog supervision of critical tasks and startup/shutdown behavior.
• Polling periods versus latency and jitter budgets; overload, missed-event, and burst-handling risk.
• ISR execution bounds, interrupt storm risk, deferred processing path, priority interactions, and task wakeup correctness.

Polling and Interrupt Decision

Use this review logic:

• Prefer polling for cyclic work, batchable updates, and behavior that tolerates one task period of delay.
• Prefer interrupts for wakeups, timer capture, bus/controller notifications, and deadline-critical sporadic events.
• Prefer hybrid handling for BSW communication: acknowledge or buffer the event in an ISR, then process routes, callbacks, diagnostics, memory, crypto, or application work in an event-driven or periodic task.
• Escalate any ISR that performs unbounded work, waits for a resource, writes nonvolatile memory, performs expensive crypto, or invokes application behavior without an explicit timing argument.

For each decision, produce this table:

Event | Source | Rate/Burst | Deadline/Jitter | Polling/Interrupt/Hybrid | ISR Bound | Deferred Task/Period | Priority | CPU/Locking Risk | Validation

Output

Report system findings with severity, affected module, evidence file/path, impact, recommendation, and validation method. Include the polling/interrupt decision table whenever scheduling or asynchronous event handling is in scope.