• Focus Métier

Ingénieur Système Embarqué

Focus métier

Ingénieur Système Embarqué, c’est quoi ?

L’Ingénieur Système Embarqué est comme un vrai développeur mais en plus petit ! Plus sérieusement, la partie programmation au stricto sensu est la même, puisqu’il s’agit du même langage : dans mon cas, le C. Avec les évolutions récentes dans le monde de la technologie, d’autres langages tels que le C++, le python et bien d’autres langages peuvent aussi être utilisés.

La principale différence est de taille ! Contrairement aux autres Développeurs, l’Ingénieur Système Embarqué a des contraintes de taille et de vitesse. Nous devons toujours faire en sorte que le programme que nous écrivons puisse tenir dans la puce que nous ciblons.

Par exemple, un système d’exploitation tel qu’Androïd occupe 2Go a lui tout seul et nous avons souvent moins de 2Mo sur les puces les plus courantes et quelques centaines de Mo si l’on ajoute des composants supplémentaires. Sur un ordinateur, il n’est pas rare de trouver 16Go de RAM, chez nous, cela se compte souvent en ko !

Dans la même logique, si un processeur de PC est souvent cadencé dans les 3GHz sur plusieurs cœurs, nos puces tournent plutôt dans les MHz et le plus souvent sur un cœur unique.

Le travail de l’Ingénieur Système Embarqué est donc le même que celui d’un Développeur, mais avec beaucoup plus de contraintes liées au matériel, ce qui donne une belle dimension au puzzle !

 

Et au quotidien, l’Ingénieur Système Embarqué ?

Au quotidien, tout dépendra du sujet sur lequel il travaille. Bien souvent, il travaillera sur du développement bas niveau, il devra donc lire de la documentation technique afin de comprendre comment tel composant va fonctionner et dialoguer avec le reste du système. Il existe des « OS » pour les puces les plus évoluées, mais ce n’est qu’un kernel temps réel glorifié. Tout se fait à la main !

Ensuite, l’Ingénieur Système Embarqué devra faire en sorte que l’ensemble des composants puisse communiquer comme il le faut, faire en sorte que cela aille vite, sans que cela ne plante.

Il y a un travail important d’optimisation, car certains composants imposent des minutages rigoureux, sous peine d’être inopérants, voire d’être détruits. Le travail de débogage est également un gros morceau dans la vie du développeur, mais dans notre cas, nous devons travailler avec des outils externes à la carte, ce qui ajoute vite une contrainte supplémentaire : ce système peut être capricieux et le temps requis pour téléverser le programme ralentit le travail.

En termes d’écosystème, il n’est pas rare que la cible embarquée soit amener à communiquer avec le reste du monde, c’est même de plus en plus fréquent avec le déploiement massif de l’IoT (Internet of Things).

Un exemple simple serait l’écosystème Garmin. L’entreprise doit faire en sorte que les montres, les GPS, les pèse-personnes, les capteurs de force… puissent communiquer avec leur serveur central afin de mettre en forme toutes ces données et ainsi permettre à l’utilisateur de les afficher sur un ordinateur, un smartphone ou une tablette.

Dans notre cas, cela signifie que notre cible « primitive » est en mesure de dialoguer avec des ordinateurs beaucoup plus performants, et donc, que l’on travaille avec les équipes qui gèrent et développent ces équipements.

Tout ceci implique de mettre en place des documentations, des tests, des validations, des réunions… C’est un exercice très instructif, puisque nos raisonnements respectifs sont biaisés par les technologies que nous utilisons. C’est aussi souvent l’occasion de découvrir d’autres technologies qui nous seraient inconnues autrement.

Si nous travaillons bien, nous pouvons donner l’illusion à l’utilisateur final que le système est simple. En conclusion, je propose une petite blague très répandue chez nous : un bon produit, c’est comme une bonne blague, s’il faut l’expliquer, c’est raté.