Timing and resource budgets: periods, priorities, deadlines, memory, with roll-up checks and a `budgets` report

Abierto
  • ¿Algo no está bien?
#368 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, rust, yaml
Área
backend, testing, tooling

Línea de trabajo

Start by reading the existing wcet and quantities handling, the W893 budget checks, and the validate command. The proposal spans model fields, roll-up validation, schedulability and latency checks, a budgets report, and requirement links; the acceptance criteria define the expected capacity and utilization results. The issue leaves scheduling and measurement sources open, so the design needs resolution before implementation.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Part of #363 (item 7).

Current state

wcet: (free text) and quantities: ({kind: ftti|latency|wcet|reaction, value, unit}) exist; budgets on them are checked (W893). Periods, priorities, deadlines and memory budgets are not modelled, so a statement such as "the fastest control task uses at most 70 % of the CPU and RAM and flash at most 80 %" (REQ-GTI-SYS-072 in the grid-tie model, and the MCU decision ADR-GTI-MCU-001) is prose that nothing can check.

Proposal

  1. Fields on tasks and parts. period, deadline, priority, wcet (structured, with units), stack, and static memory ram, flash, nvm on software parts/tasks; capacities on the hardware element they are allocated to (cpuMips or clock, ramKb, flashKb).
  2. Roll-up checks in validate (opt-in once capacities exist): sum of ram/flash/stack of everything allocated to an element against its capacity with a configurable margin (default from a requirement or a project setting); CPU utilisation from wcet/period per core with a schedulability bound (rate-monotonic or the utilisation bound, configurable); wcet greater than deadline; end-to-end latency along a chain of tasks against a latency quantity.
  3. Report. syscribe budgets [--config C] [--json]: per hardware element and core, used versus capacity, margin, and the largest contributors.
  4. Link to requirements: a margin requirement can be checked by a budget (verificationMethod: analysis with a budget reference).

Acceptance (tests first)

  • Adding a part that exceeds RAM capacity makes validate fail with the contributors named; at 79 % versus an 80 % margin it passes.
  • Utilisation above the bound is reported with the task list.
  • Grid-tie model: REQ-GTI-SYS-072 becomes a checked budget on the STM32G474.

Open questions

  • Multicore and interrupt-level scheduling models (start with fixed-priority preemptive on one core).
  • Where measured values come from (static analysis output ingested like test results).

Part of #272 (executable MBSE / software design).

Generated by Claude Code

Lenguaje dominante
Rust
Estrellas
8
Forks
1
Merge medio
3 h 35 min
PR fusionados (30 d)
69

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de sjames/syscribe

Todos los issues de sjames/syscribe

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.