Electronique Mag - Le journal de l'électronique.

La pratique courante veut que la plupart des grands fournisseurs de CAO électronique procèdent à une étude de cas sur site du système existant d’un prospect, étude dont le budget peut aller chercher dans les millions de dollars.

L’étape suivante à laquelle ils s’attèlent consiste à déployer un ingénieur « Field Application » sur site (FAE) pour produire du code manuellement. L’objectif ? Une solution de conception intégrée. Au lieu de cela, le résultat est un processus long et coûteux qui souvent ne parvient pas à intégrer ne serait-ce que la majorité des fonctionnalités souhaitées par le prospect, notamment pour ce qui concerne le contrôle de version.

Malheureusement, les formateurs en ingénierie électronique n’enseignent généralement pas le contrôle de version.

Le contrôle de version a en fait évolué pour devenir une pratique recommandée en matière de logiciel. Il est devenu une nécessité absolue pour les développeurs «  Soft » car les programmes ont atteint des proportions telles que ceux-ci ont eu besoin d’équipes de conception de plus en plus importantes. Essayer de gérer des volumes de code sans un système de contrôle de version efficace relève de l’enfer. Le contrôle de version permet à plusieurs membres d’une équipe de travailler simultanément sur un logiciel sans risquer de perdre ou d’écraser le code d’un autre membre.

À moins que la seule activité d’une entreprise soit de concevoir des cartes électroniques, la plupart des professionnels du métier de l’électronique sont conscients que les équipes logicielles sont nettement plus importantes en nombre que leurs homologues chargés du « Hardware ». Les équipes de conception « Hardware » ayant généralement tendance à être plus petites, elles ont souvent adopté des systèmes de contrôle de documents assortis de plans de numérotation des révisions.

Les membres de l’équipe partagent des dossiers qui sont rangés sur un serveur, voire dans une armoire de classement  ! Ces solutions relèvent de la démarche dite de « l’organisation en boîtes ». Ce qui amène la question : s’agit-il vraiment de contrôle de version ?

La complexité en développement logiciel
 Au cours des 20 dernières années, les logiciels ont connu une croissance extrêmement rapide et sont devenus de plus en plus complexes. Avec chaque nouvelle version d’un logiciel, le code devait être régulièrement mis à jour pour intégrer des fonctionnalités nouvelles ou améliorées et des corrections de bogues. Pour faire face à cette situation, l’industrie du logiciel a mis en oeuvre des pratiques de conception modulaire, autrement dit une forme de réutilisation des conceptions. Cependant, la conception modulaire et la réutilisation des segments de code ont fait naître d’autres défis.

Les entreprises ont constaté que la réutilisation des modules logiciels apportait de nombreux avantages. Les modules ont permis une fiabilité accrue parce que les logiciels réutilisés avaient déjà été testés dans les systèmes de travail. La réutilisation réduisait également le risque lié au processus, puisque les fonctionnalités, le risque et le coût des logiciels existants étaient déjà connus. En outre, les logiciels réutilisables permettent une utilisation efficace des spécialistes, puisque le logiciel incarne leurs connaissances. Aspect peut-être le plus convaincant, les équipes de conception ont réalisé que la réutilisation entraînait une accélération du développement et une réduction du temps consacré au codage et à la validation. Par conséquent, elles pouvaient atteindre leurs objectifs, à savoir écourter les délais de mise sur le marché et produire plus rapidement de nouvelles itérations des versions de produits.

Toutefois, la mise en oeuvre de la réutilisation des conceptions de logiciels n’était pas sans difficulté.

L’application généralisée des modules logiciels ne s’improvise pas. Tout d’abord, les modules doivent être maintenus et les processus de développement doivent être adaptés dans les versions ultérieures. Les modules réutilisés peuvent également devenir de plus en plus incompatibles avec les changements de système dans les versions ultérieures, ce qui entraîne une augmentation des coûts de maintenance. Pour apporter une réelle valeur ajoutée, les éléments réutilisés doivent être détectables dans la bibliothèque, compris, et parfois adaptés.

Dans les versions suivantes, les éléments de conception nouveaux ou mis à niveau sont susceptibles d’imposer des conditions préalables et des dépendances auxquelles doivent se conformer les éléments réutilisés. Aspect peut-être le plus difficile de l’écosystème IP, de nombreuses sociétés pensent qu’elles peuvent et doivent réécrire les éléments parce qu’elles s’imaginent qu’elles peuvent les améliorer ou les posséder.

Comment la complexité logicielle donne naissance à une démarche d’équipe
 Dans un environnement d’équipe de développement, plusieurs personnes touchent le même code. Pour gérer leur équipe, les ingénieurs responsables ont besoin de visibilité sur le travail de celle-ci. Première exigence : l’équipe avait besoin d’un référentiel unique de stockage sécurisé pour ses divers modules de conception. Une fois ce référentiel établi, l’équipe de conception avait besoin d’un historique progressif des modifications apportées au code source. Pour que la réutilisation soit efficace dans un environnement d’équipe, il fallait également une méthode efficace pour l’archivage et le désarchivage des sources de conception.

Au cours des 20 dernières années, les équipes de conception de logiciels se sont rendu compte qu’un système efficace de gestion de la conception doit faciliter la collaboration entre les membres de l’équipe. Comme nous le laissons entendre plus haut, le système doit également créer et maintenir un historique progressif en temps réel des modifications apportées au code source. Cela signifie également que le système capturait des métadonnées pour chaque changement, avec en outre une indication de l’auteur du changement. Cela facilitait la traçabilité complète, autrement dit l’aptitude à documenter l’identité des membres de l’équipe ayant travaillé sur les modules, le nom des modules en question, les modifications apportées et la date de celles-ci. Cela permettait également l’amélioration des comptes-rendus et du suivi, de telle sorte que les ingénieurs responsables pouvaient suivre la productivité et l’avancement de la conception. Toutes ces avancées ont abouti à la responsabilisation de tous les membres de l’équipe.

Le contrôle de version en conception « Hardware »
 Les équipes de conception PCB sont généralement constituées de 1 à 20 concepteurs, avec une moyenne d’environ 5 dans la plupart des entreprises de conception. Les aberrations statistiques, comme par exemple les grands constructeurs de semi-conducteurs, peuvent employer des équipes de FAE comptant des centaines de collaborateurs chargés du travail de conception de référence. En règle générale, les équipes de conception de matériel de taille petite à moyenne conservent les données des conceptions électroniques sur le disque dur individuel de chaque concepteur. Malheureusement, personne ne sait vraiment où se trouve l’ensemble des données de la conception considérée.

Les entreprises ayant pris conscience de ce problème se sont engagées à conserver leurs connaissances d’entreprise dans une base de données dédiée. Les équipes de conception de cartes électroniques ont eu quelques difficultés à mettre en oeuvre le contrôle de version parce que le processus et les outils sont encore largement fondés sur des principes du génie logiciel. Sans système de contrôle de version intégré dans leurs outils de CAO électronique, les concepteurs de matériel ont essayé des programmes de contrôle de version autonomes dotés de capacités d’archivage et de désarchivage. Toutefois, les solutions non intégrées s’effondrent parce que le concepteur et/ou le gestionnaire individuel ne peut faire aucune comparaison visuelle avec le schéma ou le PCB d’une version à l’autre.

Dans un logiciel de CAO électronique à contrôle de version totalement intégré, les membres de l’équipe peuvent voir l’état de l’ensemble des modèles, des mises à jour des normes réglementaires concernées et des modifications apportées aux conceptions. Par conséquent, tous les membres de l’équipe sont automatiquement avertis lorsque survient un changement. Dans le logiciel, un responsable ou un membre de l’équipe peut exécuter un « outil de différenciation » dans le logiciel en cours de développement pour identifier, résoudre et valider les changements entre les versions.

Cependant, les outils de CAO électronique produisent une sortie binaire et graphique, et non pas une sortie sous forme de texte, comme c’est le cas pour le code logiciel. Cela rend l’identification des changements via un outil textuel non intégré, extrêmement difficile et facilement source d’erreurs. Les responsables et les concepteurs ont besoin de voir les changements sous forme graphique, de les fusionner dans la conception, et de valider le changement. Autrement dit, aucune de ces fonctions n’est proposée par les systèmes de contrôle de version non intégrés.

Adaptation des bonnes pratiques en conception « Hardware »
 Les pratiques de conception « Hardware » doivent changer en raison des pressions concurrentielles, comme l’indique le rapport d’étude de l’Aberdeen Group intitulé «  Need to Save PCB Design Time ? » (Besoin de gagner du temps sur la conception de PCB ?). Ce rapport est basé sur des entretiens et des enquêtes menées auprès de 133 sociétés d’électronique. Une fois que l’équipe chargée de l’étude avait rassemblé toutes les données, elle a procédé à une évaluation concurrentielle des entreprises interrogées. Il est ressorti de tout cela trois catégories de participants à l’enquête ; les meilleurs dans leur catégorie, les moyens et les retardataires.

Comme le montre la Figure 1 , chacune des trois catégories de sociétés a démontré des niveaux de performances communs pour les cinq principaux paramètres :

 1. Processus (les approches adoptées pour gérer les données des PCB)
 2. Organisation (à qui sont exposées les données)
 3. Gestion des connaissances (comment sont gérées les connaissances contenues dans les données sur les PCB)
 4. Gestion des performances (aptitude de l’organisation à mesurer ses résultats pour améliorer ses pratiques de gestion des données sur les PCB)
 5.Technologie (outils appropriés utilisés pour prendre en charge la gestion des données sur les PCB)

Le contrôle de version, comme l’observe le compterendu d’Aberdeen, relève de la catégorie de la « Gestion des connaissances ». Il faut noter que la catégorie « Connaissances » de la Figure 1 cite trois éléments :

 1. Schéma et routage du PCB sont synchronisés
 2. Schéma et BOM sont synchronisés
 3. Et enfin, il y a un contrôle de version pour chaque donnée relative au PCB

N’importe quel logiciel de contrôle de version autonome peut procéder au check-in et au check-out de base. Cependant, les équipes de conception découvrent rapidement qu’elles ne peuvent pas verrouiller automatiquement un élément emprunté. Il en résulte que certains travaux de conception sont écrasés ou perdus. Les membres de l’équipe sont également incapables de comparer visuellement les révisions dans le schéma ou le PCB. Ils apprennent aussi à leur grand désarroi que la solution manque de fonctionnalités intégrées de gestion de données. Le fait de fusionner le travail collaboratif réalisé sur différentes parties du projet pose d’autres problèmes de consommation de temps.

Les outils de CAO électronique à système de contrôle de version intégré (VCS) offrent toutes les fonctionnalités de check-in et de check-out, y compris le verrouillage des éléments qui ont fait l’objet d’un check-out. Comme les homologues en logiciel, un VCS intégré établit un référentiel unique pour tous les projets. Tous les modules et composants de conception sont archivés dans le référentiel de contrôle de version. Chaque fichier individuel contient de vastes métadonnées, y compris un enregistrement des modifications de conception, le concepteur, la date du changement, etc.

Lorsque deux membres de l’équipe (ou plus) désarchivent simultanément un élément, le fichier est formellement désarchivé au premier utilisateur. Selon le back-end de contrôle de version réel, l’utilisateur verrouille soit automatiquement soit manuellement le fichier pour en interdire l’accès à tous les autres membres de l’équipe. Si un deuxième utilisateur désarchive le même fichier, il ne peut travailler que sur une copie. Une fois que le premier concepteur a fini de travailler sur le fichier et le sauvegarde dans le référentiel, cette action libère le verrou. Si le deuxième concepteur rouvre le fichier à présent débloqué, son travail sera marqué comme « obsolète ». Il pourra passer en revue les modifications apportées par le premier concepteur et fusionner le travail effectué auparavant sous forme de copie dans le fichier et le vérifier à nouveau si besoin.

Pour établir un historique incrémental, le responsable de l’ingénierie du projet effectue le check-in initial et étiquette le projet comme REV 0. Cela devient le point de départ de la conception. Toutes les modifications sont ensuite maintenues de manière incrémentale uniquement. Etant donné que les sauvegardes à répétition de la conception entière avec un nouveau numéro de révision prennent des volumes absolument énormes d’espace de stockage de données, le système enregistre uniquement les modifications incrémentales.

Une source potentielle de modifications de conception est un processus appelé « ramification ». La ramification permet à l’équipe de conception d’explorer des scénarios hypothétiques en tant que ramifications de la ligne principale de développement. Tout membre de l’équipe autorisé peut établir une ramification en tout point de la ligne de développement principale. Si la version V1.0 est publiée, la ramification permet des corrections mineures. Le procédé de ramification permet à ces corrections, le cas échéant, d’être intégrées dans les versions de produit ultérieures.

Les équipes de conception qui utilisent des outils de CAO électronique à système de contrôle de version totalement intégré bénéficient de nombreux avantages, le premier étant la réduction du nombre d’erreurs. La responsabilisation et la productivité s’améliorent car chaque ingénieur peut visualiser qui apporte des modifications à la conception et constater le travail de la personne en question. Chaque membre de l’équipe peut alors poser facilement des questions à ce concepteur concernant ce changement spécifique. En outre, tous les membres de l’équipe pouvant voir le travail de chacun, la productivité s’améliore.

Après la mise en oeuvre d’un VCS intégré, la documentation et les rapports s’améliorent également. Chaque fois qu’un membre de l’équipe ré-archive un fichier, il doit ajouter un commentaire. Cela facilite la gestion de projet, l’assurance qualité et la conformité aux normes, et permet d’obtenir des produits certifiés aux normes actuelles de l’industrie concernée. En outre, avec des comparaisons visuelles ou graphiques complètes entre deux révisions différentes, les membres de l’équipe peuvent voir les modifications surlignées les unes à côté des autres.

La solution de conception électronique parfaitement intégrée et synchronisée
 Altium Designer satisfait les besoins de contrôle de version des équipes de conception « Hardware ». Il constitue le seul système de conception électronique à contrôle de version parfaitement intégré. Toutes les données de conception sont maintenues dans une zone de stockage unique et restent totalement synchronisées. Le système affiche les modifications sous forme de 1 à 4 panneaux qui apparaissent à l’écran. Cette fonction évoluée souligne toutes les modifications intervenues, tant au niveau du schéma que du PCB. Toutes ces modifications sont également documentées sous forme de texte pour faciliter la consultation par la direction.

http://www.altium.com