Il s'agira d'utiliser des modèles d'appareils qui ne sont pas les plus simples, comme par exemple des SoC (System on Chip) ou des cartes de circuits imprimés avec de nombreux appareils intégrés à bord. Dans le développement de ces dispositifs eux-mêmes, deux étapes peuvent être distinguées. Le matériel est développé en premier. C'est un processus lent - cela peut prendre un an ou plus.
Après l'apparition de la première révision de l'appareil physique et des vérifications de base effectuées, l'appareil est transféré aux développeurs de logiciels. À partir de ce moment, la deuxième phase commence - le développement du logiciel pour l'appareil. Il peut s'agir de micrologiciels, BIOS, BSP / CSP (Board and CPU Support Package) pour divers systèmes d'exploitation, ainsi que des pilotes.
D'ailleurs, dans le développement de puces, souvent appelées "silicium", ces phases sont appelées "pré-silicium" et "post-silicium" ou simplement "silicone".
En théorie, le développement de logiciels est possible avant l'apparition d'un appareil physique. Cependant, dans la pratique, très peu le font. Le développement sans possibilité de lancements intermédiaires et de débogage, et c'est précisément ce pour quoi l'appareil est requis, est un travail très ingrat, j'ai rencontré peu de masochistes de ce type. Tout le monde attend le "matériel", mais celui-ci, comme je l'ai écrit plus haut, n'apparaîtra que dans un an.
En outre, il y a un autre problème avec le matériel. La première révision est publiée en édition limitée et distribuée une pièce à la fois. En termes simples, il n'y a pas assez de cartes et de puces pour tout le monde. Il y a des files d'attente, des conflits, il s'agit d'agression. Et si vous avez accidentellement brûlé un appareil, ce qui est très facile, tout développement s'arrête jusqu'à ce qu'un autre appareil soit trouvé. Souvent, il n'est pas trouvé, il est nécessaire d'en produire un nouveau, puis d'attendre la livraison. Cela ralentit considérablement le processus.
Et puis les simulateurs viennent au secours des développeurs de logiciels!
La création d'un modèle d'appareil virtuel commence simultanément avec la conception de l'appareil physique. Mais comme la création et la sortie d'un modèle sont beaucoup plus faciles, les premières versions de ces modèles n'apparaissent généralement pas dans un an, mais beaucoup plus tôt. En utilisant de tels modèles, les développeurs de logiciels peuvent démarrer immédiatement leurs tâches sans attendre le «matériel».
Oui, il n'y aura pas toutes les fonctionnalités, mais les programmeurs aux premières étapes n'ont pas besoin de tout cela. Jusqu'à ce que l'appareil soit fabriqué, les équipes d'architectes matériels, de modélisateurs et de développeurs de logiciels doivent avoir des plans clairs et cohérents qui reflètent les fonctionnalités spécifiques à réaliser à quel stade. À chaque itération et à chaque étape, le modèle virtuel se développe avec des fonctionnalités supplémentaires, qui, à leur tour, sont utilisées par les développeurs de logiciels pour écrire un pilote ou créer un micrologiciel pour cette fonctionnalité particulière.
Dans cette approche, les développeurs de modèles et de logiciels utilisent des spécifications communes. En exécutant un logiciel sur un modèle, ils vérifient essentiellement le travail de chacun.
Un avantage supplémentaire est la validation du "matériel" malgré le fait que le matériel lui-même n'est même pas encore là. Cela semble surprenant à première vue, mais nous parlons ici d'erreurs architecturales dans la conception de l'appareil, dont certaines peuvent être détectées lors de l'exécution d'un logiciel sur un modèle. Et c'est très cool, car il est possible de corriger ces bogues dans le matériel avant sa sortie. Sinon, ces erreurs conduiraient à la nécessité de rééditer les prochaines révisions, et c'est un plaisir assez coûteux.
Nous avons eu un cas où 10 blocs de traitement du flux de données entrant ont été implémentés dans un appareil complexe, et les registres de contrôle et de gestion nous ont permis de travailler avec seulement la moitié d'entre eux. Cela a été implémenté dans la version précédente de l'appareil et les architectes ont simplement oublié d'agrandir cette partie. Lorsque nous avons créé le modèle et que l'autre équipe a écrit et exécuté le pilote, il s'est rapidement avéré que toutes les fonctionnalités avancées n'étaient pas disponibles. L'architecture et les spécifications ont été corrigées à temps avant la création du prototype physique de l'appareil.
Les grandes entreprises d'appareils peuvent prendre en charge tout un écosystème construit autour de leurs produits. Cet écosystème comprend de nombreuses autres entreprises, y compris celles qui produisent des logiciels pour cet équipement. Par exemple, il peut s'agir de fabricants de BIOS, appelés IBV (Independent BIOS Vendors), dont les plus connus sont AMI, Insyde, Phoenix. Ces sociétés reçoivent également des modèles du fabricant de matériel et commencent le développement avant l'apparition du périphérique physique. Par exemple, pour les plates-formes Intel, le simulateur Simics est utilisé, qui peut être lu plus en détail dans l'article Ecosystem Partners Shift Left with Intel for Faster Time-to-Market .
Évidemment, la création de modèles nécessite des coûts supplémentaires. Le montant des coûts dépend bien sûr du type de modèles (fonctionnels, par cycle, etc.), mais en général, le coût de création d'un modèle peut être supposé être approximativement égal au coût d'écriture du logiciel pour l'appareil. Toutes les entreprises ne sont pas disposées à payer ce prix pour une version antérieure, c'est pourquoi cette approche est courante dans les grandes entreprises. Ils ont des budgets suffisants pour cela, et un lancement plus précoce d'un produit sur le marché augmente considérablement leurs revenus. Bien que récemment, il y ait eu une tendance à une utilisation plus répandue des simulateurs pour le développement de logiciels et dans les petites entreprises.
Souvent, pour réduire les coûts, le modèle n'implémente pas toutes les fonctionnalités possibles, mais seulement le minimum nécessaire pour certains scénarios d'utilisation de l'appareil. Par exemple, si un périphérique réseau n'est pas prévu pour être utilisé dans les VLAN, mais uniquement pour mettre à jour le micrologiciel et le télécharger via tftp, il n'est pas nécessaire d'implémenter la logique avec des balises VLAN, mais la fonctionnalité pour les scénarios de démarrage de périphérique sur le réseau et les mises à jour du micrologiciel doivent être entièrement implémentées le volume.
Quel est le résultat final?
Si nous supposons que le temps de développement du matériel et du logiciel est approximativement égal l'un à l'autre (voir l'image ci-dessus), alors l'utilisation de modèles peut considérablement, presque 2 fois, réduire le temps de mise sur le marché d'un produit (appelé TTM - Time To Market) , puisque le développement du «matériel» et du logiciel se fait en parallèle, et non séquentiellement. Pour cela, le terme Shift Left est souvent utilisé, qui vient du domaine des tests, où il signifiait tester le plus tôt possible. Le même terme s'applique au développement logiciel, qui semble se décaler vers la gauche dans la chronologie lorsqu'il est exécuté sur le simulateur.
Au moment où la première révision de l'équipement apparaît, il ne reste plus qu'à vérifier la fonctionnalité du logiciel sur du matériel réel. Idéalement, les erreurs et les correctifs ne devraient pas être significatifs et cette étape n'introduit pas de grands retards, puisque le code a déjà été écrit et débogué sur le modèle.
Cette approche n'est pas «gratuite», elle nécessite un budget supplémentaire et une équipe de programmeurs, il faut donc bien comprendre combien ces coûts vont rapporter dans un cas ou un autre.
Ce n'est pas le seul cas d'utilisation des simulateurs. Je parlerai de la recherche architecturale et de la création d'environnements complexes dans les articles suivants. Ne changez pas.