FAQ

Non…car désormais les systèmes embarqués – mêmes les plus critiques – sont de plus en plus connectés ce qui impose de les concevoir en y intégrant les contraintes de cyber-sécurité
o De plus, les contraintes de souveraineté et de développement durable (consommation énergétique, etc…) imposent d’optimiser le traitement des données depuis leur source, ce qui se traduit par un fort développement de l’IA embarquée (CF plan IA embarqué https://www.entreprises.gouv.fr/fr/numerique/enjeux/intelligence-artificielle-embarquee=

Bien sûr que non !!! car bien que chaque marché de système embarqué ait ses contraintes (et ses normes spécifiques), les fondamentaux restent les mêmes (robustesse, safety, frugalité des ressources de calcul, notions de temps réel, etc…) et au contraire chaque industrie recherche à valoriser les solutions éprouvées par d’autres. Ainsi le ferroviaire s’intéresse à la 5G pour remplacer ses réseaux GSM-R, l’aéronautique à l’optimisation de la certification au travers des validations des systèmes ADAS (Advanced Driver Assistance Systems) de l’automobile, et à sa manière d’intégrer peu à peu l’IA embarquée…
o De plus, toutes les industries sont intéressées par la manière avec laquelle les Telecoms ont intégré les méthodes de développement agile, les techniques de containarisation de la donnée, ou les technologies Open-Source, que cve soit en logiciel (intérêt pour le nouveau langage Rust par exemple) ou dans le hardware (architectures Risc-5, etc…
o Et de nouveaux marchés se font jour (médical, agriculture,…)

Comprendre pour éviter…contrairement aux idées reçues (et à la perception des étudiants…), les activités de test, de V&V (Validation & Verification) représentent un acquis fondamental, car c’est là que tous les errements et les erreurs de développement se révèlent ainsi que …leurs conséquences sur la qualité, les délais et les coûts !
o Il est donc fréquent qu’un ingénieur débutant soit affecté à ce type de tâche, dont il sortira après quelque temps pour valoriser son expérience dans des acticités de spécifications ou de développement…

Plus qu’une question de niveau, il s’agit plutôt de comprendre et d’aimer traiter les enjeux pesant sur ces systèmes, robustes, performants, de plus en plus connectés et souvent considérés « critiques », qu’il s’agisse du temps de réaction (notion de temps réel, de « latency », ..), de la résistance au hasard pouvant conduire à l’accident grave (safety) ou à ce qui n’est pas le fruit du hasard – malveillance, piratage – (cyber sécurité), à la nécessité de travailler sous contraintes de moyens (capacité de calcul, mémoire, données disponibles, …)
o l’ensemble devant – et permettant – de relever les défis imposés par le développement durable, qu’il s’agisse d’optimiser les énergies consommées – ou rejetées – (par exemple dans les véhicules autonomes et électriques, …), d’allonger la durée de vie, de permettre le recyclage, et de lus en plus la souveraineté (« privacy » des données, composants électroniques, …)

Oui, je secteur des systèmes embarqué manque d’ingénieurs et de techniciens…car tous les marchés nécessitent des systèmes embarqués de plus en plus performants, conçus et ….fabriqués en France ou en Europe, qu’il s’agisse d’automobiles ou de trains connectés et de plus en plus autonomes, de nouveaux modes de mobilités (EVTOL – Electric Vertical and Take Off Landing), de capteurs intelligents et frugaux en énergie (médical, …), …

Oui, et de plus en plus…
o Le secteur des télécommunications a été pionnier en la manière car il a su extraire et adapter le monde IT à ses contraintes de performances, certaines ressemblant à celles des systèmes embarqués : méthodes agiles de développement, emploi de blocs logiciel Open Source , traitement de l’information (containarization/ Kubernetes, …) et développement Secure by Design, etc…
o Mais il est vrai que les systèmes embarqués ont longtemps résisté – et d’une certaine manière résistent encore en raison des contraintes majeures de safety, qui porte aussi bien sur les approches (déterministes, …), les méthodes de développement (Requirement based engineering, …), cycles « en V », indépendance du développement et du test, etc… les « boîtes à outils » logicielles (Scade, …) que des langages utilisés (Ada, C voire C++, …)
o Cependant des volontés « d’ouverture » de l’OT vers l’IT existent, sur l’ensemble des dimensiosn citées ci-dessus, allant jusqu’à l’emploi de nouveaux langages (exemple le Rust…)