Stellar SR6P7 — AUTOSAR Classic — BSW Target & Integration Plan

1) BSW cible (scope demandé)

Objectif : définir un socle AUTOSAR Classic sur Stellar SR6P7 (ETAS Tresos) avec un ordre d’intégration pragmatique (bring-up → CAN → COM/Diag → NvM).

MCAL (SR6P7)

Mcu clock/reset/PLL

Port mux/pad config

Dio digital I/O

Gpt timers

Icu input capture (si besoin)

Pwm actionneurs (si besoin)

Wdg watchdog HW

WdgIf interface watchdog

Can driver CAN

Fls Flash driver

Eep/Fee EEPROM ext. / émulation

Services / Abstraction

ECU Abstraction : CanTrcv (si transceiver pilotable) + CanIf
Services : Det, Dem, Dcm, Com, PduR, CanSM, CanTp (diag CAN), EcuM, BswM, SchM, NvM, MemIf, Fee, FlsIf, Crc
OS : AUTOSAR OS (Osek/AUTOSAR OS) via Tresos (tâches + alarmes)

Recommandations d’architecture

Bring-up minimal Mcu + Port + Dio + Gpt + Det + Os
CAN stack (min) Can + CanIf + CanSM (+ Com/PduR selon besoins)
Diag Dcm + Dem + CanTp + CanIf + PduR
NvM NvM + Fee + Fls + MemIf + Crc

Remarque : la sélection exacte dépend du package MCAL/BSW livré (ETAS/tiers) pour SR6P7 et de la disponibilité des modules.

1bis) Découpage cible (dans Tresos)

MCAL : configuration Mcu/Port/Dio/Gpt/Can/Fls/... + export du code C/H
OS : tâches, alarmes, ISRs, ressources (priorités, périodes)
Communication : CanIf/CanSM, PduR, Com (si signaux), CanTp (si UDS)
Diag : Dcm (services UDS) + Dem (événements DTC)
NvM : NvM + Fee/Fls/MemIf/Crc

2) Plan d’intégration (ordre recommandé)

Phase A — Infrastructure projet

Toolchain + linker + startup (souvent fourni par le package SR6P7 / IDE)
Intégration du code généré Tresos (dossiers + includes)
Ajout d’un main.c minimal qui appelle les init BSW

Critère OK build + flash sur kit, entrée dans main().

Phase B — Bring-up MCAL + OS

Mcu_Init + Mcu_InitClock + Mcu_DistributePllClock (selon MCAL)
Port_Init
Dio test (toggle LED)
Gpt_Init + test tick
OS : tâches + alarmes (1ms/10ms/100ms)

Critère OK LED toggle en tâche 100ms, tick 1ms stable.

Phase C — CAN de base

Can_Init
CanIf_Init
CanSM_Init + transitions (NoCom → FullCom)
Test TX/RX via callback CanIf_RxIndication

Critère OK trames reçues / envoyées, bus stable.

Phase D — COM stack (si signaux)

PduR_Init, Com_Init
Mapping PDU → signals
Cycliques : Com_MainFunctionRx/Tx

Critère OK signaux se mettent à jour (TX périodique + RX).

Phase E — Diag UDS

Dem_Init
Dcm_Init
CanTp_Init + PduR_Init routing diag
Périodiques : Dcm_MainFunction, Dem_MainFunction

Critère OK session diag répond (ex : ReadDataByIdentifier) via outil UDS.

Phase F — NvM

Fls_Init, Fee_Init, NvM_Init
Périodiques : Fls_MainFunction, Fee_MainFunction, NvM_MainFunction
Test : lecture/écriture d’un bloc NvM, reset, relecture

Critère OK données persistantes après reset.

3) “Main functions” (tick) — exemple

1ms : CanIf_MainFunctionRx/Tx (si requis), CanSM_MainFunction, CanTp_MainFunction (selon config)
10ms : Dcm_MainFunction, Dem_MainFunction
10/100ms : NvM_MainFunction, Fee_MainFunction, Fls_MainFunction
10ms : Com_MainFunctionRx/Tx

Les fréquences exactes dépendent des recommandations ETAS + de la configuration.

3bis) Template scheduling (OS tasks / alarms) — proposition

Objectif : éviter de tout mettre en 1ms et isoler les tâches « lourdes ».

Task_1ms (high prio) - CanSM_MainFunction() (si configuré cyclique) - CanIf_MainFunctionRx() / CanIf_MainFunctionTx() (si requis par vendor) - CanTp_MainFunction() (si diag via CanTp) Task_10ms (medium prio) - Com_MainFunctionRx() / Com_MainFunctionTx() - Dcm_MainFunction() - Dem_MainFunction() Task_100ms (low prio) - NvM_MainFunction() - Fee_MainFunction() - Fls_MainFunction() (souvent si driver asynchrone)

La liste exacte dépend de la config Tresos + doc ETAS (certains modules demandent des main functions, d’autres utilisent uniquement des callbacks/ISRs).
Si Fls/Fee sont « blocking », éviter de les appeler dans une tâche trop fréquente.

4) Dossier projet

src/ : code applicatif (main + app)
include/ : headers applicatifs
generated/ : dépôt du code généré Tresos (à copier/mapper ici)
config/ : notes et exports (arxml, etc.)

4bis) Workflow ETAS Tresos (pratique)

Étape 1 — Import / configuration

Créer un workspace Tresos + importer les ARXML (ou projet de base ETAS).
Configurer l’OS (tâches/alarmes) au plus tôt (bring-up).
Configurer MCAL minimal : Mcu, Port, Dio, Gpt.

Étape 2 — Génération

Générer le code (BSW/MCAL/OS selon ton package).
Récupérer : sources .c/.h, MemMap.h, Compiler_Cfg.h/Compiler.h (si fournis), fichiers *_Cfg.c/h.

Étape 3 — Intégration dans ce scaffold

Copier ou référencer le code généré dans generated/.
Ajouter les include paths : generated/ + sous-dossiers vendor.
Ajouter les sources générées au build (IDE ou script).
Vérifier : mapping sections (MemMap), startup + vector table + linker script.

Étape 4 — Bring-up tests

Test Dio (LED)
Test Gpt tick (oscillo ou toggles)
Lancement OS + exécution tâches périodiques

4ter) Checklist d’intégration — points critiques

Horloges (Mcu) : fréquence core/peripheral correcte avant Port/Can.
Interruptions : ISR OS vs non-OS, priorité, mapping.
CAN : bit timing, mapping pins, transceiver, wake-up.
MemMap : sections conformes (sinon erreurs de link).
Main functions : appelées au bon period (sinon timeouts diag / com / nvm).

5) Prochaines infos nécessaires

Pour aligner le squelette à 100% avec ton environnement :

IDE/build : Stellar Studio ? IAR ? GCC ?
Package MCAL/OS/BSW exact livré par ETAS pour SR6P7 (nom/version)
Bus diag : UDS sur CAN classique ou CAN-FD ?

6) Objectifs de validation (milestones)

M1 (bring-up)

OS up + LED toggle + tick stable.

M2 (CAN)

TX/RX stable sur bus.

M3 (Diag)

UDS répond (ReadDID / SessionControl).

M4 (NvM)

Write/read block + reset + relecture OK.

7) Safety (ISO 26262) — focus ASIL D

Note Cette section est un cadre générique (mécanismes typiques + intégration BSW). Les capacités exactes du SR6P7 et la manière de les activer doivent être confirmées avec la documentation Safety SR6P7 et ton package MCAL/BSW (ETAS/tiers).

Objectifs ASIL D (vision système)

Détecter rapidement les fautes (CPU, mémoire, horloges, communication).
Réagir de manière déterministe (safe state, reset contrôlé, dégradation).
Tracer les défauts (événements, DTC, reset reason, compteurs) pour analyse.

Mécanismes safety typiques côté MCU/plateforme

Watchdog : WDG HW (fenêtré si possible) + supervision du servicing.
Horloges : clock monitor / supervision PLL.
Mémoire : ECC/parity + CRC d’intégrité sur zones critiques.
CPU : lockstep / monitors / traps (si disponibles).
Self-tests : BIST (LBIST/MBIST) au boot et/ou périodiques.
Protection : MPU, isolation stack/données safety.
Alim/Reset : brown-out, reset supervision, reset reason.

Mécanismes safety typiques côté BSW

DET : indispensable au bring-up pour capturer erreurs d’API/config.
DEM/DCM : diagnostic des fautes (DTC/UDS) si la diag est activée.
OS : timing protection, stack monitoring, memory protection (si dispo).
SchM : protection des zones critiques (exclusive areas).
E2E (COM) : CRC, compteur, alive counter, timeout, plausibilité (si signaux safety).
NvM : CRC des blocs, gestion d’erreurs, valeurs par défaut safe.

Recommandations d’intégration (pragmatiques)

Bring-up safety minimal : préparer/activer WDG, log reset reason, DET.
Définir le safe state : sorties, CAN (NoCom), diag, NVM.
Créer une tâche de health monitoring (10/100ms) : alive, délais, checks.
Si communication safety : E2E + timeouts + plausibility + stratégie de dégradation.
Décider des données safety-relevant en NVM : CRC + safe defaults + recovery.

Checklist ASIL D (exemples)

Watchdog fenêtré configuré + politique de servicing (qui/quand/conditions).
Reset reason lu au boot + journalisation + compteur de resets (option NVM).
Timeouts CAN Rx/Tx + réaction (NoCom / safe state) documentée.
Appel des main functions au bon period (sinon timeouts Diag/Com/NvM).
CRC/signatures sur config critique (si applicable) + gestion d’erreur.

Questions à clarifier (spécifiques SR6P7)

Quels mécanismes SR6P7 sont disponibles/activables (lockstep, monitors, BIST, ECC) ?
Quelle stratégie de safe state : HW (PMIC/reset) vs SW (degraded mode) ?
Comment le package MCAL/OS expose ces mécanismes (APIs, callbacks, config) ?