Systèmes enfouis.

Souvent, le matériel est conçu par un groupe puis passé à un deuxième groupe qui développera la deuxième partie du projet : le logiciel. Ceci peut amener à certaines assomptions sur le matériel qui résulteront en difficultés dans le processus de mise au point.

Dans son article "Minimizing risk: embedded software and today's medical devices", décrit  une séquence spécifique mettant en valeur cette déconnexion entre le matériel et le logiciel prend toute sa valeur et décrit comment l'éviter. Dans notre cas, la connectivité avec un port USB défaillante a causé une perte de données. Toutes les fonctions du circuit enfoui ont été activées, ce qui l'a forcé à envoyer des signaux intermittents à travers le bus, obligeant le calculateur hôte à stopper le port USB.

En réalité, le matériel enfoui s'est fait déborder par le logiciel. Les données ont été collectées auprès d'un patient qui été analysé par un système médical complexe. Le système a du être redémarré ce qui a obligé le patient à reprendre un rendez vous un peu plus tard. Il n'est pas bien difficile de comprendre pourquoi ceci peut être un problème pour l'utilisateur final. Cela coûte du temps et de l'argent, nos ressources les plus précieuses.

Mais pourquoi est ce arrivé ? Le logiciel a été écrit avec l'assomption que le contrôleur USB ne serait jamais défaillant.. En fait, le processus de récupération des données était directement lié à la transmission des données. Le système avait besoin de stocker des données  pendant qu'il effectuait le test, même en cas de rupture de l'alimentation ou d'arrêt système. Mais du fait que l'on avait assumé que le port USB ne serait jamais défaillant, ce cas d'usage avait été considéré au niveau de la conception logicielle.

Comment résoudre ce problème au cas ou il apparaitrait. Des nombreux tests envisageant une grande variété de cas auraient certainement mis en évidence le problème. Qu'arrive t il lorsqu'un problème est identifié en fonctionnement mais lorsque la cause n' est pas connue ? Voici le moment d'utiliser des outils de mise au point et plus spécialement un analyseur de protocole. Dans ce cas, un analyseur de protocole USB tel que le Beagle USB 480 Power Protocol Analyze .serait de la plus grande utilité..

Nous avons déjà travaillé avec une société fabricant des appareils méicaux offrant un problème similaire, le seul moyen d'identifier la cause a été d'èffecteur des tests, intensivement : Ils obtenaient des coupures d'alimentations complètes du bus USB pendant certaines séquences de test mais étaient incapables d'en déterminer la cause, ce qui les empêchait de résoudre le problème. Sur le terrain, il n'est commercialement pas possible d'avoir des pannes imprévues comme des pertes d'alimentation. Ceci rendait la résolution de ce problème en laboratoire de la plus haute importance.

Peu après avoir pris connaissance de ce problème, nous avons introduit le Beagle USB 480 Power Protocol Analyzer - Ultimate Edition. Cet appareil a été conçu pour suivre les transferts de données USB ainsi que les évènements VBUS de l'alimentation. Ceci leur a permis de corréler les événements sur le bus, avec les pertes d'alimentation, ce qui leur a permis d'identifier la configuration fautive.

En plus il faut savoir que l' Ultimate edition offre un système de déclenchement sur état avancé qui leur a permis de mettre au point les conditions permettant de répéter le problème. A ce niveau là :  La capture offrant les données les plus récentes pour analyse.. Grâce à l'utilisation de l'analyseur Beagle USB 480 Power, le problème a été identifié et résolu en quelques semaines permettant à la production de repartir.

Vous envisagez l'utilisation d'un analyseur de protocole ou d'un autre outil de développement pour résoudre votre problème ?