La simulation est votre chemin vers le succès des logiciels embarqués

En tant qu’ingénieur logiciel embarqué, il est facile de penser que tous les logiciels du produit reposent sur le matériel. La plupart des développeurs embarqués veulent accéder à une carte de développement dès le départ et commencer à écrire des logiciels, y compris moi-même. Ce n’est pas nécessairement faux; c’est juste familier et nous permet de comprendre les complexités et les problèmes du matériel. Cependant, si nous concevons correctement notre code d’application, nous pouvons alors utiliser la simulation et les tests sur la plupart de notre code sans le matériel sous-jacent. Un développeur peut simuler son code de différentes manières pour le prouver avant de l’intégrer réellement au matériel.

Tout d’abord, et peut-être le moyen le plus simple de simuler du code, c’est de le développer et de le tester sur un PC. Les développeurs peuvent utiliser GCC ou G++ pour exécuter leur code sur un ordinateur, puis générer et vérifier la sortie. C’est assez facile pour les développeurs Linux et Mac de le faire car ils accèdent directement à un terminal prenant en charge GCC ou G++. Les développeurs Windows peuvent avoir besoin d’installer Cygwin ou Mingw, ce qui est assez simple à configurer.

J’ai mentionné plus tôt qu’un logiciel bien conçu pouvait être simulé ou testé sur un PC. Un logiciel correctement conçu est conçu pour minimiser les dépendances et conçu pour être flexible et isoler les composants. Cette dernière architecture leur permet d’être exécutés et testés sans introduire toute la base de code. Ils peuvent être exécutés sur le PC et les entrées peuvent être alimentées via un fichier. Ensuite, les sorties peuvent être écrites dans un fichier pour être analysées ou même tracées si nécessaire.

Un bon exemple de cette technique est tiré d’un de mes projets récents où nous avons concentré la plupart de nos efforts de développement logiciel sur le matériel final depuis qu’il était disponible. Finalement, nous avons rencontré un problème où un algorithme d’application ne fournissait tout simplement pas le résultat attendu. C’était proche mais pas tout à fait correct. Cela nous a laissé une question intéressante : « Y a-t-il eu une interaction avec le matériel ou le RTOS, ou l’algorithme était-il simplement codé de manière incorrecte ? »

En règle générale, un développeur de logiciels embarqués jouait avec le logiciel sur le matériel pendant des semaines en essayant de comprendre ce qui pourrait causer le problème. Dans ce type de situation, une équipe parie pour trouver une solution dans un laps de temps raisonnable. En raison de la façon dont le logiciel a été conçu et mis en œuvre, j’ai pu extraire l’algorithme, que l’on aurait considéré comme dépendant du matériel, puis l’encapsuler dans un code de test que j’ai exécuté sur un PC. J’ai ensuite pu tracer le résultat et le comparer aux résultats attendus.

Cela a permis à un développeur d’effectuer une vérification de l’intégrité du logiciel. S’il correspondait, il y avait un problème avec la façon dont l’algorithme a été intégré dans le processeur intégré. Si cela ne correspondait pas, l’implémentation C nécessitait quelques ajustements.

Cela nous amène à une deuxième option pour simuler un logiciel embarqué, c’est-à-dire utiliser un outil tel que Matlab. Matlab peut permettre à une équipe de simuler des machines à états, des algorithmes et d’explorer le comportement d’un système. En fait, dans de nombreuses applications automobiles et aérospatiales, les équipes laisseront même Matlab générer le code intégré pour elles, et l’équipe n’aura alors plus qu’à maintenir leur modèle.

Dans l’exemple ci-dessus, l’algorithme avec lequel je travaillais avait été simulé dans Matlab. Je savais exactement ce qu’il était censé produire en fonction des entrées connues. La comparaison de la simulation du code C embarqué avec la sortie Matlab a ensuite fourni les détails pour montrer s’il y avait un problème avec l’algorithme ou quelque chose dans le système embarqué.

Les simulations peuvent également aider le développeur embarqué à comprendre le système dans son ensemble. Parfois, nous implémentons aveuglément des algorithmes sans vraiment comprendre comment ils fonctionnent, ce que signifient les entrées et à quoi devraient ressembler les sorties pour ces entrées. Parfois, nous pouvons nous en sortir, mais il est souvent essentiel que le développeur comprenne les détails si un problème survient.

La simulation peut aider à cela, surtout si tous les boutons et cadrans sont inclus. Un développeur peut augmenter le paramètre A et voir comment il modifie la sortie. Ensuite, le paramètre B peut être ajusté et ainsi de suite jusqu’à ce qu’ils comprennent parfaitement comment le système peut fonctionner. J’ai constaté que dans de nombreux cas, ce n’est pas tant l’algorithme que son interaction avec les comportements en temps réel qui est le problème.

Conclusion

Les développeurs de logiciels embarqués n’ont pas besoin de dépendre du matériel pour faire le travail. C’est génial quand le matériel est disponible, et cela peut permettre aux développeurs de surmonter les obstacles sur le matériel. En fin de compte, cependant, de nombreux algorithmes et fonctionnalités d’application peuvent être simulés et testés hors cible. Cette simulation peut prouver que le système fonctionne comme il le devrait ou aider à dépanner de petites nuances qui pourraient autrement prendre un temps considérable à déboguer. Les développeurs doivent ajouter une simulation hors cible à leur sac d’astuces s’ils ne le font pas déjà.