Discussion :

[f-leb]

la communauté,

Je suis tombé sur ce site : MÉTIER : Ingénieur en système embarqué

Quelles compétences pour devenir ingénieur ?

Voici les compétences techniques indispensables pour exercer le métier d’ingénieur en système embarqué :

• Maîtrise de l’électronique ;
• Connaissance approfondie des systèmes embarqués ;
• Maîtrise de la programmation informatique ;
• Connaissance pointue en nouvelles technologies ;
• Maîtrise de la conception de circuits électroniques ;
• Connaissance approfondie des différents réseaux de communication ;
• Connaissance solide en génie logiciel ;
• Maîtrise de la science cognitive ;
• Maîtrise de l’anglais technique et professionnel ;
• Connaissance approfondie du framework Arduino ;
  

Le dernier item en rouge m'a surpris, sans doute à tort mais ça fait un moment que j'ai quitté les études

Mais voici un vrai sujet de débat un étudiant qui fait des études d'ingénieur en système embarqué doit-il avoir « une connaissance approfondie du framework Arduino » pour exercer son métier ?

Si vous êtes étudiant ou enseignant dans le domaine, avez-vous étudié le framework Arduino dans votre parcours ? Et si vous êtes déjà un ingénieur expérimenté en système embarqué, avez-vous cette connaissance « approfondie », et trouvez-vous normal de disposer de cette compétence de nos jours ?

[Auteur]

La question que je me suis posé est qu'entendent-il par framework Arduino ? Est-ce que cela implique aussi les cartes ?

Par contre, deux choses m'ont surprises (dans les compétences) :
-1- rien sur les microcontrôleurs ou les PC monocarte (type Raspberry)
-2- c'est quoi pour eux "la science cognitive" ?
les sciences cognitives

Il y a des choses qui manquent ou qui sont mal définies.

[Delias]

Ben voyons.

Petite mise en perspective de ma réponse, mon premier métier est électronicien où j'ai appris sur les ancêtres d'Arduino (carte STK200 par exemple), puis j'ai continué mes études dans le domaine de l’énergie (convertisseur, machine électrique et réseau HT) domaine où je travail depuis 2008.

Arduino n'est rien de plus qu'une carte de développement* simplifiée pour permettre un accès à bas coût aux étudiants additionnée d'un framework qui masque tout une partie des connaissances normalement nécessaires. Cela permet d'arriver plus vite à un résultat, mais aller plus loin (et notamment passer sur d'autres architectures) sera d'autant plus difficile. Ce n'est pas adapté au domaine industrielle. Encore de la comm qui surf sur le buzz.

Vu de ce côté du Jura, je n'ai pas encore remarqué cette tendance, même si ce n'est plus vraiment dans mon cadre professionnel comme indiqué au début.
Cela fait une dizaine d'année que je suis abonné à deux newsletters de jobs pour des ingénieurs électriciens (spectre large). Il m'arrive parfois d'aller voir les offres qui concerne l'électronique et je n'ai pas encore croisé d'Arduino là dedans.
Par curiosité, j'ai été regardé les plans d'études actuels de l'école par laquelle je suis passé, on y fait toujours de l'assembleur sur AVR pour l'apprentissage de la structure des microcontrôleurs (en carte STK300 donc pas Arduino, probablement le cours que j'avais suivi). Du mélange C / assembleur sur Nintendo DS (domaine programmation embarquée) et encore du FPGA / DSP en VHDL et C. C'est aller très clairement au delà des simplifications d'Arduino et ne pas laisser de boite noir au milieu.

* une carte de développement c'est une carte électronique qui peut recevoir un microcontrôleur (parfois de plusieurs types possibles au seins de la même famille) qui est bâtie pour avoir le nécessaire au bon fonctionnement du micro et des accessoires utiles (bouton poussoirs, leds, écrans, etc...) Cela est utilisé au démarrage de la conception pour éviter de devoir, dès le début, s'occuper du hardware. Mais un produit fini se doit de ce passer de cette carte de développement qui n'est pas optimisée.

Delias

[f-leb]

La question que je me suis posé est qu'entendent-il par framework Arduino ? Est-ce que cela implique aussi les cartes ?

Par "framework" je suppose qu'ils entendent tous les outils de la plateforme : les (principales) cartes, les shields, le «langage Arduino», les bibliothèques standards, les sketches dans l'EDI standard, etc.

Par contre, deux choses m'ont surprises (dans les compétences) :
-1- rien sur les microcontrôleurs ou les PC monocarte (type Raspberry)
...

Bon, après ils ne prennent pas de risques en écrivant que dans les compétences techniques indispensables pour exercer le métier d’ingénieur en système embarqué, il faut avoir «une connaissance approfondie des systèmes embarqués», comme ça ils sont sûrs de ne rien oublier

[f-leb]

Arduino n'est rien de plus qu'une carte de développement* simplifiée pour permettre un accès à bas coût aux étudiants additionnée d'un framework qui masque tout une partie des connaissances normalement nécessaires. Cela permet d'arriver plus vite à un résultat, mais aller plus loin (et notamment passer sur d'autres architectures) sera d'autant plus difficile. Ce n'est pas adapté au domaine industrielle. Encore de la comm qui surf sur le buzz.

Attention, le débat n'est pas de savoir si la plateforme Arduino est adaptée à un usage industriel. On sait ce qu'il en est, et tu l'as bien résumé.

La question est de savoir si un étudiant du domaine doit aussi prendre connaissance de cette plateforme au cours de ses études, parce que c'est la plateforme la plus populaire du moment, mais dans le cadre d'une utilisation pour laquelle elle est normalement prévue : le prototypage rapide.

[f-leb]

Attention, le débat n'est pas de savoir si la plateforme Arduino est adaptée à un usage industriel. On sait ce qu'il en est, et tu l'as bien résumé.

Quoique, on oublie un peu vite qu'Arduino a aussi une gamme Pro...

[Delias]

Arduino a éventuellement un avantage pour le custom-made fait à petite échelle, là où le surcoût de production ne dépasse pas le gain sur la conception.

Ne maitriser qu'Arduino c'est fermer sa carrière à une niche. Apprendre à lire une doc de µC/µP et programmer selon les nécessités c'est avoir le choix pour ses réalisations. L'important pour pouvoir s'adapter c'est la compréhension de la mécanique interne d'un micro et cela Arduino ne l'apprend pas. Maitriser la programmation directe permet à l'inverse de programmer en Arduino sans trop d'apprentissage additionnel.

Certain le savent peut-être, mon principale hobby c'est le train miniature. On y retrouve un paquet d'Arduino et de Pi pour les réalisations personnelles ou de clubs, mais la totalité de la production industrielle, même issue pour une partie de développement personnel c'est de la programmation embarquée en direct. La taille plus que limitée, une alimentation généralement comprise entre 12V et 20V, une consommation à maitriser et la gestion des coûts l'impose alors même que l'on n'est pas sur de la production de masse.
Les décodeurs ESU V3 et V4 (l'une des grandes marques de l'électronique pour ce domaine) utilisaient des puces AVR très proche de celles de l'Arduino, sur une platine faisant même pas la moitié de la taille d'un Nano avec une tension d'alimentation nominale de 25V et même 35V en pics. Essayer de faire cela en restant sur Arduino...

Delias

[Vincent PETIT]

Salut,

Arduino a éventuellement un avantage pour le custom-made fait à petite échelle, là où le surcoût de production ne dépasse pas le gain sur la conception.

Exactement.

Là où je bossais (fabricant d'appareils électroniques avec ligne CMS + production + patati patata) Arduino est par exemple utilisé par le service Industrialisation (bureau des méthodes) pour faire des bancs de test automatique pour accélérer la production ou pour palier à tout un tas de petits problèmes ici est là qui demandent un peu d'électronique (faire un compteur, une mesure, ...) alors bien sûr tout ces montages ne sont pas vendus, ils sont utilisés en interne, donc ils restent sous forment carte de développement. Ça ne coûte pas cher, ça fait vite le job, c'est mis dans une boîte pour qu'on ne voit pas la filasse et c'est fini.

A l'inverse dans le service R&D juste à côté, là on y développait les produits électroniques qui seront vendus en moyenne série et qu'on peut appeler système embarqué, Arduino n'est pas utilisé, pas même pour un POC. La demande de maîtrise est trop grande, même en connaissant parfaitement le framework et à la fin le micro ne conviendra probablement pas.

Donc est ce qu'il faut une quelconque compétence Arduino pour être ingénieur en systèmes embarqué ??? Je dirai que ça dépend dans quelle entreprise et quel service tu tombes.

[f-leb]

Je pense que c'est dans l'internet des objets (iot) que les Arduino trouvent de plus en plus leur place dans l'industrie. Avec toujours dans l'idée de concevoir rapidement un prototype d'un objet connecté, voire un produit semi-fini pour des besoins précis en interne.

Evidemment, quand il s'agit de passer les tests de sécurité électrique ou de vérifier la compatibilité électromagnétique pour obtenir la conformité finale, l'industriel négligeant peut se trouver dans l'impasse avec son proto sur Arduino

[f-leb]

Donc est ce qu'il faut une quelconque compétence Arduino pour être ingénieur en systèmes embarqué ??? Je dirai que ça dépend dans quelle entreprise et quel service tu tombes.

C'est ça, par exemple en fouillant dans les annonces d'emplois, on trouve des choses étonnantes...

Dans la logistique :

Vous êtes intégré.e au sein du bureau d'étude et d'innovation, nouvelle structure (moins de 10 personnes) dédiée aux problématiques de mécanisation et robotisation des entrepôts logistiques. Vous participerez aux développements de solutions mécatroniques innovantes afin d'assister les opérateurs....

En tant qu'ingénieur système embarqué (H/F), votre mission consistera à participer au développement de tout système mécatronique conçu au bureau d'études, à savoir :
Développement du code embarqué bas niveau de robots mobiles : gestion moteurs, batterie, CANopen, etc...
Optimisation des performances (mise en place de tests et validation des nouvelles mises à jour)
Analyse de charge et dimensionnement électronique suivi d'un encadrement de prestataires pour la conception de cartes électroniques sur mesure et gestion des fournisseurs
Expertise et paramétrage des OS embarqués (Linux), driver, et firmware
Développement de modules autonomes (GPU pour gestion caméra, code C++ embarqué sur des modules Arduino, créations de postes de qualification ou d'analyse, etc...)
En tant qu'expert(e) système embarqué, vous aurez également en charge la maîtrise de nos architectures électroniques et vous serez en capacité de challenger des cartes électroniques du marché (type Raspberry Pi) avec des cartes développées sur mesure, en partenariat avec nos prestataires extérieurs.

Un secteur de pointe dans les activités de prototypage chez Valeo :

L’équipe Driving Assistance Research de Valeo est composée d’une équipe de 100 ingénieurs et docteurs en développement logiciel et prototypage. Cette équipe dynamique est chargée des études de faisabilité de systèmes innovants d’aide à la conduite et des véhicules autonomes, ainsi que la définition de la stratégie technologique concernant le véhicule autonome.
... Au sein du DAR, vous intégrerez l’équipe Prototypage et Intégration Systèmes, pour participer aux activités de prototypage pour le véhicule autonome.

[...]Vous êtes polyvalent(e), avec une bonne maîtrise de développement en C / C++, Python et souhaitez participer à l’élaboration des systèmes de véhicules autonomes prototypes et l’intégration des composants hardware et software, leur configuration et leur validation.
Vous êtes issu(e) d'un cursus ingénieur et vous avez des une appétence et des connaissances techniques en prototypage mécanique, électronique et software.

Bonus - Hautement apprécié :

• Connaissances, utilisation et réalisations de prototypes
• Systèmes embarqués : Arduino, RaspberryPi, NVIDIA Jetson, ...
• ...

Et même dans la conception d'Escape Game :

XXXXXXXXX est spécialisée dans la conception d’Escape Game sur-mesure haut-de-gamme pour les entreprises... Leader européen de l’Escape Game en entreprise, XXXXXXXXX intervient partout en Europe, aux Etats-Unis et au Canada...
XXXXXXXXX recherche un Ingénieur Électronicien / Système Embarqué [...] pour accompagner l’équipe sur la conception de mécanismes électronique de jeu pour les Escape Game...
Mission
- Conception de l’électronique des divers objets et assurer les logiques de communication entre eux
- Participer à l’élaboration et à la réalisation de concepts et techniques innovants, dans les domaines de l’électronique et de l’intégration notamment
- Réaliser des schémas électroniques
- Développer le code de pilotage sur les divers MCU (souvent Arduino IDE)
- Câbler et intégrer l’électronique dans les objets réalisés, à partir d’un schéma de câblage
- ...

[Guesset]

Bonjour,

Je me souviens que jeune ingénieur (ça fait un bail) je m'étais offusqué d'un code bâclé. Une amie également ingénieure - nul n'est parfait - m'avait dit que l'important n'était plus d'avoir la meilleure solution mais d'avoir une solution à temps. Elle n'était pas l'auteur du code donc n'avait rien à défendre. Sa réponse m'a d'autant plus choqué que j'avais conscience qu'elle avait raison.

Depuis, j'ai souvent vu des principes sains bafoués par les contraintes de coûts et de temps. L'embarqué ne fait pas exception. Alors pourquoi pas Arduino ? Compétences faciles à trouver donc peu chères. Développements rapides même si limités. Etc.

La qualité n'est pas le but. Bienvenue dans le monde réel.

Salutations

[Auteur]

Une amie également ingénieure - nul n'est parfait - m'avait dit que l'important n'était plus d'avoir la meilleure solution mais d'avoir une solution à temps.

c'est souvent que je dois faire face à ce genre de commentaires de la part de certains collègues : ils veulent une solution immédiate réalisée avec la méthode La Rache plutôt qu'une solution plus stable. Le problème, c'est que 15 jours plus tard je dois intervenir dessus pour y ajouter une fonctionnalité ou corriger un bug.

@f-leb :
je ne suis pas surpris, comme indiqué dans les réponses précédentes, pour du prototypage, une étude de faisabilité on passe par ces cartes. Même les constructeurs de cartes d'acquisition (Ni, MC, etc.) proposent désormais des Py Hat, des shields Arduino et des bibliothèques logicielles pour les piloter. Moi même, dans mon activité R&D, je les utilise pour certains développements qui ne nécessitent pas de contraintes particulières. Et souvent je déploie des solutions qui intègrent des Arduino.

[Vincent PETIT]

Salut,

Une amie également ingénieure m'avait dit que l'important n'était plus d'avoir la meilleure solution mais d'avoir une solution à temps.

A mes yeux c'est ce qui a amené la médiocrité partout où j'ai entendu ça. La solution à temps s'apparente souvent une béquille.

La bonne solution n'arrive jamais à temps, elle arrive avant

[Jay M]

j'ai souvent vu des principes sains bafoués par les contraintes de coûts et de temps.

ce sont des contraintes comme les autres dans le cahier des charges....

=>

Un bon ingénieur fait propre, dans le budget et dans les temps si tout cela a été estimé comme il faut. Sinon il ne perd pas son temps à bosser pour ce genre de boîte et va bosser ailleurs.
Un mauvais ingénieur fait du sale boulot tout le temps donc moins on lui donne de temps moins les dégâts seront considérables

[Guesset]

Bonjour,

Je crains que la réalité ne soit moins tranchée qu'entre bons et mauvais.

Par exemple, pourquoi tout ce qui peut être mis à jour doit l'être ? Peut être parce que les produits ne sont pas finis. Et cela ne concerne pas seulement les ordinateurs qui sont hors catégorie tellement ils s'en donnent à cœur joie.

Pourquoi les ingénieurs d'embarqué sont souvent moins bien payés que ceux qui interviennent en informatique des affaires. Leur travail est plutôt plus difficile (la qualité des cahiers des charges de l'informatique de gestion permet une forte dilution de responsabilités) mais il est moins visible.

Je ne suis pas d'accord avec l'idée que délais et coûts sont des contraintes comme les autres. Dans les écoles, c'est vrai. Mais qui n'a jamais vu un cahier des charges évoluer sans que le calendrier change ? Qui n'a jamais vu des systèmes biens conçus mais à la limite des composants d'où des pannes rapides ? Il suffit de maintenir quelques équipements pour voir qu'ils ne sont pas faits pour durer. Mais c'est plus un effet de contraintes de coûts qu'un objectif d'obsolescence. On pourrait croire que les ingénieurs qui les ont conçus sont mauvais, mais ce n'est même pas nécessaire. La mise en production industrielle va passer avec ses raboteurs de coûts "presque" sans effet sur la qualité et la pérennité du produits.

Vous aurez compris que je ne crois pas à un monde en deux teintes. Ce serait trop simple et comme le disais en substance Valéry : ce qui est simple est faux et ce qui est complexe est inutile

Salutations

[Jay M]

bien sûr ce n'est pas noir ou blanc

Cela dit - un bon ingénieur dans l'embarqué (dans les bonnes boîtes qui vendent bcp - par exemple les smartphone ces dernières années) paye beaucoup plus qu'un codeur SAP... On parle de x5 voire x10 de plus avec les plans d'actions gratuites etc. Mais faut être bon (il en va de même en ce moment pour la sécurité, la crypto, l'IA et le ML ou le big data en général)

[Guesset]

Bonjour,

La plupart des codeurs dans le domaine de l'informatique de gestion ne sont pas des ingénieurs ou seulement pour la facture

Les ingénieurs sont soit à un niveau de direction de projet soit à un niveau d'expert. De base, les salaires sont similaires entre ingénieur logiciel et embarqué. Mais la multiplicité de spécialisations qu'offre l'informatique de gestion leur permet de devenir expert de tel ou tel domaine (big data, sécurité, data scientist, bases de donnés, architecture des systèmes, etc.). C'est là que se fait la différence.

La mer y est beaucoup plus grande en taille comme en variété. Et je ne parle pas des consultants !

Salutations

[Jay M]

si on parle de société de service alors il y a effectivement souvent une grande différence entre la 'marchandise' proposée et la réalité