Simplifiez le débogage pour réduire la complexité du développement de systèmes embarqués • TechCrunch

La complexité associée avec le développement des systèmes embarqués augmente rapidement. Par exemple, on estime que la complexité moyenne des projets logiciels dans l’industrie automobile a augmenté de 300 % au cours de la dernière décennie.

Aujourd’hui, chaque élément matériel est piloté par un logiciel et la plupart du matériel est composé de plusieurs cartes électroniques exécutant des applications synchronisées. Les appareils ont de plus en plus de fonctionnalités, mais ajouter des fonctionnalités signifie augmenter la complexité du développement et du débogage. Un rapport de l’Université de Cambridge a révélé que les développeurs consacrent jusqu’à 50 % de leur temps de programmation au débogage.

Heureusement, il existe des moyens pratiques de réduire la complexité du débogage des systèmes embarqués. Nous allons jeter un coup d’oeil.

Plus tôt c’est mieux

Le débogage ne sera efficace que si vous disposez des bonnes informations.

Des bugs apparaîtront pendant toute la durée de vie d’un produit : lors du développement, des tests et sur le terrain. La résolution ultérieure d’un bogue peut augmenter les coûts jusqu’à 15 fois et entraîner la frustration des utilisateurs, en plus de créer des défis associés à la mise à jour des appareils embarqués en production.

Cependant, identifier les bogues aux premières étapes du développement de votre produit vous permettra de les suivre tout en les hiérarchisant par gravité. Cela vous permettra de déboguer avant que d’autres dépendances et variables ne soient introduites plus tard dans le cycle de vie, ce qui rend les bogues plus faciles et moins coûteux à résoudre.

Gérer la gestion des versions

Pour répliquer correctement un bogue, vous devez être en mesure d’avoir un appareil exactement dans le même état qu’il était lorsque le bogue est apparu pour la première fois. Avec les appareils intégrés, il y a trois variables distinctes à examiner lorsque des problèmes surviennent :

  1. La version du logiciel. Il s’agit de la version de chaque fonctionnalité. Cela s’applique au code que vous créez ainsi qu’aux dépendances potentielles, telles que les bibliothèques importées.
  2. La version planche. Plus précisément, la conception de la planche. La conception de la carte change constamment à mesure que des composants sont ajoutés/supprimés ou déplacés.

Laisser un commentaire