Les offres d'ingénieur validation logiciel embarqué demandent presque toutes les mêmes outils : un banc HIL dSPACE ou NI, CANoe et CANalyzer, CAPL ou Python, et un outil d'exigences comme DOORS ou Polarion. Le travail consiste à rédiger le plan de validation, à écrire et automatiser les tests, à les dérouler sur banc et à suivre les anomalies jusqu'à la clôture, dans un cycle en V.
Un CV peut aligner dSPACE, CANoe et ISO 26262 après une seule campagne exécutée à partir de scripts écrits par d'autres. Les questions d'entretien doivent faire décrire ce que la personne a construit : un test qu'elle a automatisé, une faute injectée, une exigence qu'elle a refusée parce qu'elle n'était pas testable, un échec intermittent dont elle a trouvé la cause.
Si vous disposez d'une trace CANoe ou d'un extrait d'exigences, montrez-les en entretien et demandez une lecture commentée. Le PDF compte 30 questions sur six axes, un cas de 20 minutes sur un banc HIL et une grille de 1 à 4.
Bancs, bus et outils d'un ingénieur validation HIL
Bancs dSPACE (SCALEXIO, ControlDesk, AutomationDesk)
SCALEXIO est le simulateur temps réel qui fait tourner le modèle de l'environnement et génère les signaux envoyés au calculateur. ControlDesk sert au pilotage manuel et à la mesure, AutomationDesk à l'écriture des tests automatisés, en graphique ou en Python. Les offres citent aussi les modèles ASM de dSPACE.
NI VeriStand et TestStand
L'autre grande famille de bancs, chez NI, désormais filiale d'Emerson. VeriStand pilote le banc temps réel, TestStand séquence les tests et appelle des modules écrits en LabVIEW, C, .NET ou Python. Un candidat dSPACE apprend NI assez vite, et l'inverse aussi.
Vector CANoe, CANalyzer et CAPL
CANalyzer observe et analyse les bus, CANoe simule aussi les calculateurs absents et exécute des tests. CAPL est le langage de script de ces outils, écrit en événements (réception d'un message, timer). Vector en est à la version 20 de CANoe, pilotable depuis d'autres outils par son interface COM.
Bus CAN, CAN FD, LIN et Ethernet embarqué
Les réseaux qui relient les calculateurs. Le CAN reste le plus courant, le CAN FD porte des trames plus longues, le LIN sert aux organes simples, l'Ethernet embarqué aux gros débits. Les messages sont décrits dans des bases DBC ou ARXML qu'il faut garder à la bonne version.
Diagnostic UDS et calibration XCP
UDS est le protocole de diagnostic : lecture et effacement des codes défaut, lecture d'identifiants, reprogrammation. XCP donne accès aux variables internes du calculateur pendant qu'il tourne, avec CANape ou ETAS INCA. Un ingénieur validation s'en sert pour voir ce que le bus ne montre pas.
Python, pytest et ecu.test
Python sert à automatiser les tests, à piloter les outils par leurs API et à dépouiller les mesures. Certaines équipes utilisent pytest ou Robot Framework, d'autres ecu.test de tracetronic, qui relie plusieurs outils de banc. Le langage compte moins que la structure des scripts.
DOORS, Polarion et traçabilité
IBM DOORS (et DOORS Next) et Siemens Polarion gèrent les exigences et leurs liens avec les tests et les résultats. La traçabilité dans les deux sens est demandée par ASPICE et par les normes de sûreté. Vérifiez que la personne sait ce qu'est un lien suspect et une baseline.
MIL, SIL, HIL et ASAM XIL
Le même logiciel se teste en modèle (MIL), en code compilé sur PC (SIL, par exemple avec dSPACE VEOS) puis sur le vrai calculateur (HIL). La norme ASAM XIL définit une interface commune aux bancs, qui permet de réutiliser les tests d'un niveau à l'autre.
Normes de sûreté et Automotive SPICE
Selon le produit, la validation suit ISO 26262, DO-178C, EN 50716 ou IEC 61508. Le niveau de criticité fixe les méthodes de test et la traçabilité attendues. Automotive SPICE évalue la maturité des processus, dont la vérification logicielle.
L'ingénieur validation logiciel embarqué travaille en fin de cycle en V, entre l'équipe de développement et l'équipe système. Selon les équipes, il écrit surtout les plans et cas de test à partir des exigences, il développe et maintient les bancs et leurs scripts, ou il déroule les campagnes et analyse les défaillances. Beaucoup de postes mélangent les trois. Le poste demande à la fois des notions d'électronique (signaux, alimentation, câblage), des réseaux embarqués et de l'automatisation en CAPL ou Python. La norme de sûreté du produit fixe le niveau de formalisme attendu.
Ce qu'un ingénieur validation embarqué doit démontrer
- Architecture de banc HIL et simulation temps réel
- Bus CAN, CAN FD et diagnostic UDS
- Automatisation en CAPL, Python ou TestStand
- Conception des tests et traçabilité des exigences
- Injection de fautes et analyse des défaillances
- Niveaux MIL, SIL, HIL et normes de sûreté
Cinq questions pour l'entretien d'un ingénieur validation HIL
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · junior à confirmé
Que simule un banc HIL autour du calculateur testé, et qu'est-ce qu'il ne simule pas ?
Une bonne réponseLe calculateur réel reçoit des signaux de capteurs produits par un modèle temps réel de son environnement, qui tourne sur un simulateur (dSPACE SCALEXIO, NI PXI avec VeriStand). Le banc lit ses sorties, charge ses actionneurs ou les simule, et joue sur les bus les messages des calculateurs absents. Il ne reproduit pas tout : thermique, compatibilité électromagnétique, usure, tolérances mécaniques. La fidélité dépend du modèle et de son pas de calcul, et des essais sur le système réel restent nécessaires.
Signal d'alerte« Un PC qui lance des tests », ou une confusion entre SIL et HIL. Croire que le banc remplace tous les essais réels.
Question 2 · confirmé
Un message CAN attendu toutes les 10 ms n'arrive plus au calculateur testé. Comment le vérifiez-vous dans CANoe ?
Une bonne réponseLa trace et les statistiques du bus dans CANoe ou CANalyzer, avec la base DBC à la bonne version pour retrouver l'identifiant et la période. Ensuite l'état du bus : trames d'erreur, nœud émetteur passé en bus-off, terminaison à 120 ohms, débit configuré. Dans un test automatisé, la périodicité se vérifie avec une tolérance, par une fonction de contrôle de cycle ou un timer CAPL.
Signal d'alerteRegarder uniquement la valeur du signal sur un panneau, sans vérifier si la trame circule ni à quelle période.
Question 3 · confirmé
Vous automatisez 200 tests sur un banc. Comment structurez-vous les scripts pour qu'un autre ingénieur les reprenne ?
Une bonne réponseUne couche d'accès au banc séparée des tests (API ASAM XIL, interface COM de CANoe, API de VeriStand), une bibliothèque de fonctions communes, les paramètres et seuils hors du code. Chaque test porte l'identifiant de l'exigence vérifiée, ses préconditions et sa remise à l'état initial. Les scripts sont dans Git, relus avant fusion, et le rapport cite les versions du logiciel, du modèle et du banc.
Signal d'alerteUn script unique avec des temporisations et des adresses codées en dur, compris de son seul auteur.
Question 4 · junior à confirmé
Une exigence dit : « le système doit réagir rapidement à une surtension ». Que faites-vous avant d'écrire le test ?
Une bonne réponseIl signale l'exigence comme non testable et demande le seuil de tension, le délai de réaction, la réaction attendue et la condition de retour à la normale. Une fois l'exigence corrigée, il écrit des cas aux valeurs limites (juste sous le seuil, au seuil, au-dessus), tient compte de la tolérance de mesure du banc et relie chaque cas à l'exigence dans DOORS ou Polarion.
Signal d'alerteChoisir lui-même une valeur de seuil et un délai « raisonnables », puis déclarer l'exigence couverte.
Question 5 · confirmé
Comment vérifiez-vous qu'un calculateur détecte un capteur débranché ou en court-circuit ?
Une bonne réponsePar une injection de faute électrique avec la carte d'insertion de défauts du banc (FIU) : circuit ouvert, court-circuit à la masse ou à la batterie, court-circuit entre broches. Il mesure le délai de détection, contrôle la réaction attendue (mode dégradé, valeur de repli), lit le code défaut en UDS (service 0x19), puis vérifie la disparition du défaut et son effacement (service 0x14).
Signal d'alerteChanger seulement la valeur du capteur dans le modèle. Le diagnostic électrique du calculateur n'est alors jamais sollicité.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Questions fréquentes sur le recrutement en validation HIL
Quels outils un ingénieur validation HIL doit-il connaître ?
Un environnement de banc (dSPACE avec ControlDesk et AutomationDesk, ou NI avec VeriStand et TestStand), un outil de bus comme CANoe ou CANalyzer, un langage d'automatisation (CAPL, Python), le diagnostic UDS et un outil d'exigences comme DOORS ou Polarion. Les outils exacts varient d'une équipe à l'autre. La méthode de test, la lecture d'une trace et la traçabilité se transposent d'un environnement à l'autre.
Faut-il exiger une expérience sur dSPACE précisément, ou NI suffit-il ?
Pour un profil confirmé, l'expérience d'un banc se transfère bien. Les notions sont les mêmes : modèle temps réel, entrées et sorties, restbus, injection de fautes, séquencement des tests. Comptez quelques semaines d'adaptation à l'outil. Exigez plutôt la maîtrise des bus et du diagnostic, et une expérience réelle d'automatisation. Pour un poste qui consiste à développer le banc lui-même, la connaissance du matériel de l'éditeur pèse davantage.
Quelle différence avec un automaticien de test logiciel classique ?
L'automaticien web ou applicatif teste un logiciel à travers son interface ou ses API, sur des environnements qu'on duplique facilement. L'ingénieur validation HIL teste un calculateur réel, avec des signaux électriques, des bus, du temps réel et un banc rare à partager. Il travaille sur exigences tracées, souvent sous une norme de sûreté. Les réflexes d'automatisation se partagent, le reste du métier demande une base en électronique et en réseaux embarqués.
Comment organiser un test technique pour un ingénieur validation HIL ?
Trois exercices courts suffisent : une exigence floue à réécrire puis à décliner en cas de test, une trace CAN à lire avec un message manquant, un script CAPL ou Python à relire avec une temporisation fixe et un verdict mal placé. Comptez une heure, en direct, avec commentaires à voix haute. Vous voyez la rigueur sur les exigences et la pratique réelle des outils, sans avoir besoin d'un banc.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
