Réussissez votre entreprise en comblant le fossé entre les logiciels et le matériel dans les systèmes embarqués
Les phases de conception et de prototypage des solutions technologiques sont généralement longues et cruciales pour la réussite des entreprises. Les investissements initiaux peuvent être importants dans ces projets. Par conséquent, les enjeux et les attentes sont élevés ! Alors que nous subissons encore les conséquences de la pandémie en termes de retards de livraison et de pénuries de composants électroniques, les entreprises subissent souvent une pression énorme pour atteindre le marché et livrer leurs stocks à temps.
Il y a aussi la lutte constante pour les ressources matérielles, car les applications nécessitent souvent des capacités de traitement croissantes. Cela signifie que le matériel sera probablement surdimensionné au départ et obsolète avec le temps. Vous devrez donc revoir votre conception pour ajouter constamment des capacités matérielles à vos produits technologiques et augmenter inutilement les coûts et les investissements.
Enfin, trouver du personnel expérimenté, maîtrisant à la fois les systèmes embarqués, le matériel et les logiciels, n'est pas toujours chose aisée. Dans certaines entreprises, des ingénieurs sans expérience en systèmes embarqués dirigent et développent des projets technologiques. Ils peuvent donc opter pour des kits de développement (Jetson Nano, Arduino, Raspberry PI) en raison de leur familiarité avec ces systèmes et de leurs fonctionnalités standard facilitant l'intégration avec d'autres systèmes. Les cartes de développement ont des applications industrielles uniques, et vous pourrez en apprendre davantage à leur sujet dans cet article de blog. Mais ce n'est peut-être pas le cas pour la production de masse.
Tous ces facteurs peuvent influencer négativement le choix du langage de programmation, de l'architecture des algorithmes et du développement global des applications. Parfois, la décision se résume à utiliser un système d'exploitation standard plutôt qu'un système personnalisé ou spécialisé, avec un code de collage Stack Overflow au lieu d'un algorithme propriétaire. Cela entraîne des ressources inexploitées, des composants matériels surdimensionnés, des retards inutiles et des coûts supplémentaires de reconception ou de recertification. Ainsi, au départ, cette solution peut sembler rentable, mais elle peut s'avérer moins avantageuse par la suite. Pire encore, en fonctionnement normal, un matériel fonctionnant à pleine capacité peut entraîner un échauffement, une réduction du temps moyen entre pannes et des coûts de réparation plus élevés.
Architecture de l'algorithme
Analysons le cheminement habituel des entreprises vers l'architecture algorithmique. Malheureusement, certains ingénieurs travaillant sur des systèmes embarqués se mettent à programmer sans aucun plan ni conception. Le problème est que vous ne découvrirez qu'après coup si votre algorithme est efficace ou non.
Nous allons décrire deux exemples d'algorithmes idéaux : linéaire et logarithmique. Supposons que chaque opération de base prenne une seconde. Dans le cas des algorithmes linéaires, le temps d'exécution augmente avec le nombre d'entrées, comme le montre le tableau 1. Si cet algorithme se comportait de manière logarithmique, son temps d'exécution resterait stable avec l'augmentation du nombre d'entrées (tableau 2). Par exemple, les algorithmes de recherche binaire présentent un comportement logarithmique.
Tableau 1. Relation entre les entrées et le temps d’exécution d’un algorithme linéaire.
Saisir | Temps d'exécution |
10 | 0,00000001 |
100 | 0,0000001 |
1 000 | 0,000001 |
1 000 000 000 | 1 |
Tableau 2. Relation entre les entrées et le temps d’exécution de l’algorithme logarithmique.
Saisir | Temps d'exécution |
10 | 3.3E-09 |
100 | 6.6E-09 |
1 000 | 1.0E-08 |
1 000 000 000 | 3.0E-08 |
Ces deux exemples sont rarement rencontrés dans la réalité, car les algorithmes se comportent rarement de manière linéaire ou logarithmique. L'algorithme « Tri stupide » peut servir d'exemple de résultats obtenus sans planification ni conception préalables à la programmation. Il s'agit d'un algorithme de structuration basé sur un test aléatoire sur un groupe de cartes à comportement factoriel (tableau 3). Avec 100 entrées, nous disposons de 3,2E+183 ans pour le résoudre. Selon la NASA, l'âge de l'Univers est de 13,7E9 ans, ce qui implique que si nous exécutions l'algorithme à la date de sa création, il fonctionnerait toujours sans solution. Il est préférable d'éviter les algorithmes factoriels, comme l'algorithme « Tri stupide », afin d'éviter de gaspiller des ressources matérielles.
Tableau 3. Relation entre les entrées et le temps d’exécution d’un algorithme factoriel.
Saisir | Temps d'exécution | Durée en années |
10 | 10 | 3.171E-7 |
100 | 1,0E+191 | 3.2E+183 |
1 000 | ? | ? |
1 000 000 000 | ? | ? |
En réalité, le matériel a ses limites. En général, les échelles de temps des systèmes embarqués sont difficiles à appréhender par l'homme. C'est pourquoi nous allons définir une échelle plus facile à comprendre pour cette analyse. Pour un processeur typique de 3,9 GHz équipant les ordinateurs standards de 2014, on peut estimer qu'un cycle CPU dure 1 seconde, comme indiqué dans le tableau 4. Dans ce cas, la lecture d'un fichier sur le disque dur pourrait prendre, dans le pire des cas, 1,5 an, ou 32 secondes en mémoire RAM. Comme vous pouvez le constater, un algorithme mal conçu gaspille des ressources. Par conséquent, vous pourriez penser qu'un matériel plus robuste et doté de capacités accrues est nécessaire pour revoir votre méthode de développement logiciel.
Tableau 4. Temps d’exécution des processus réguliers dans un ordinateur dans une échelle plus facile à comprendre.
Activité | Temps | Échelle humaine |
Cycle du processeur | 0,256 ns | 1 seconde |
Cache L1 | 1,026 ns | 4 secondes |
Cache L2 | 3,077 ns | 12 secondes |
Cache L3 | 6,154 ns | 24 secondes |
R.A.M. Mémoire | 8,4 ns | 32 secondes |
Disque dur – meilleur scénario | 2,9 ms | 132 jours |
Disque dur – pire des cas | 12 ms | 1.5 ans |
SDD | 85 μs | 3 jours et 20 heures |
Changement de contexte | 10 μs | 10,8 heures |
Quantum | 100 ms | 12,4 ans |
Comment réussir en affaires en développant des produits technologiques ?
Grâce à une architecture algorithmique rigoureuse, vous devez constituer une équipe comprenant au moins un ingénieur expérimenté en systèmes embarqués. Ce professionnel sera le mieux placé pour concevoir l'architecture des algorithmes destinés à un matériel spécifique. Il améliorera les logiciels pour qu'ils s'adaptent parfaitement au matériel (et non l'inverse), ce qui vous permettra d'optimiser votre retour sur investissement et d'éviter bien des soucis opérationnels et de fabrication.
Un ingénieur systèmes embarqués élabore des stratégies, planifie et programme pour éviter les erreurs courantes lors du développement logiciel et est capable d'anticiper les capacités matérielles. Cela signifie que les défis peuvent être réduits et qu'il sera plus facile de réussir. Qui sait ! Vous pourriez même devenir le héros de l'Industrie 4.0, de l'Internet des objets, de la robotique ou du traitement d'images dans votre entreprise.
Si vous souhaitez continuer à lire sur ce sujet, vous pouvez consulter ce blog. Vous pouvez également consultez cette page pour plus d'informations sur les systèmes embarqués.