Les normes ouvertes peuvent-elles vous protéger ?

Temps de lecture : 4 min

Ayant passé plus d’années que je ne veux peut-être l’admettre dans le secteur de la technologie, j’ai toujours eu un seul principe directeur fondamental que je me demande encore et encore : « Que veut le client ? » Bien sûr, il existe des variantes sur le thème: « De quoi le client a-t-il besoin pour réussir? ». Naturellement, dans le cadre du processus de découverte, je m’assois avec mon client ou partenaire et je lui demande directement. C’est la meilleure source d’information et, en supposant que vous écoutiez et que vous livriez, la meilleure chance de succès mutuel. Cependant, ce n’est pas toujours aussi simple. La technologie, de par sa nature même, permet toujours de nouveaux cas d’utilisation, produits et applications pilotés par des entreprises innovantes employant des personnes intelligentes. Le défi est que « à la pointe de la technologie » signifie souvent que toutes les exigences ne sont pas connues aussi tôt dans le cycle de développement que nous le souhaiterais.

J’ai également observé un autre changement fondamental de mentalité au fil des ans en travaillant avec certaines de ces organisations innovantes. Une partie du processus de réflexion sur le développement de produits tient compte de l’impact stratégique des décisions prises maintenant. Ce que je veux dire par là, c’est :

• Comment les choix qui sont faits aujourd’hui pourraient-ils avoir un impact sur les générations futures du produit en cours de développement ?
• L’innovation peut-elle être accélérée en introduisant la prochaine génération un peu plus tôt parce que l’évolutivité et la réutilisation ont été prises en compte dès le début ?

La réponse est généralement oui, mais ce n’est pas gratuit. Il y a toujours des compromis à faire.

« Et alors ? » Je vous entends demander. Eh bien, permettez-moi de placer ce préambule dans un contexte un peu plus proche de chez nous – la sécurité. Peut-être plus précisément, la sécurité fonctionnelle. Le développement de produits et de solutions pour la sécurité nécessite des efforts supplémentaires, des compétences accrues et plus de temps, qui est finalement mesuré en termes de coût et de calendrier. À titre d’exemple, pensez à l’airbag d’un véhicule. Je vais simplifier considérablement les systèmes modernes de contrôle des airbags pour faire valoir un point. Fondamentalement, le cas d’utilisation est simple – si le véhicule s’écrase, l’airbag se déploie. Il y a un capteur qui détecte l’accident généralement en fonction d’un seuil de force G et d’une charge explosive qui déploie réellement l’airbag. Le truc avec les airbags, c’est que vous espérez qu’il n’a jamais besoin de faire ce pour quoi il est conçu, mais à ce moment malheureux où il est nécessaire, il fait mieux son travail parfaitement. Ainsi, des fonctions supplémentaires sont conçues pour surveiller en permanence l’intégrité du système de contrôle. En cas de problème ou de défaut, un signal peut être envoyé pour indiquer qu’un service est nécessaire – le redoutable voyant d’avertissement du moteur. Avec cet exemple, il est facile de voir que cette fonction de sécurité supplémentaire nécessite des efforts, du temps et des coûts supplémentaires en termes de conception, de vérification, de validation et de certification de sécurité.

Examinons maintenant les implications plus larges. Les fonctions supplémentaires décrites ci-dessus qui garantissent un fonctionnement sûr et correct du système, y compris les activités de diagnostic et de surveillance, couvrent à la fois les domaines matériel et logiciel. Par exemple, ces systèmes incluent généralement des fonctionnalités de code de correction d’erreur (ECC) dans le silicium pour fournir une intégrité supplémentaire sur les bus de périphériques. L’ajout d’un microcontrôleur de surveillance externe serait un autre exemple de matériel. D’un point de vue logiciel, l’ensemble de la « pile » doit être considéré comme sûr. Cela inclurait le système d’exploitation en temps réel (RTOS), les applications, les pilotes, etc. C’est ce domaine particulier que je veux aborder plus en détail.

Généralement, pour toute entreprise qui développe à la fois des produits matériels et logiciels, l’investissement dans ces derniers dépasse de loin celui des premiers. Compte tenu de ce niveau d’investissement dans les logiciels, il devient de plus en plus important de concevoir des moyens de favoriser l’évolutivité et la réutilisation de ces investissements et, en termes simples, s’ils sont effectués correctement, peuvent entraîner un avantage concurrentiel significatif. Ce problème est aggravé lorsque la sécurité entre en jeu. C’est un défi que nous passons beaucoup de temps à essayer de résoudre ici à CoreAVI, mais c’est bien sûr quelque chose que l’industrie doit intensifier et résoudre ensemble. Une approche possible est l’adoption de normes ouvertes. Nous avons vu que cela fonctionnait très bien dans le monde du matériel avec des facteurs de forme de calcul standard tels que COM-Express et VPX. La même approche peut être appliquée dans le domaine des logiciels liés à la sécurité. Ce à quoi je fais spécifiquement référence, c’est la partie centrale de la pile logicielle qui se trouve entre le matériel et l’application. Dans un monde idéal, nous aimerions fournir une couche d’abstraction matérielle sûre et basée sur des normes ouvertes qui permettrait aux applications de s’asseoir sur n’importe quelle plate-forme matérielle, quelle que soit l’architecture CPU ou GPU sous-jacente. C’est le Saint Graal et c’est peut-être en étirant les domaines du possible aujourd’hui. Cependant, y parvenir avec une ou deux mises en garde est une réalité certaine.

À ce stade, je veux présenter Vulkan® SC, une dérivation critique de la norme industrielle Vulkan® API définie par le consortium Khronos. Le pilote Vulkan fournit une interface « mince » et hautes performances aux éléments de calcul sous-jacents, généralement le GPU. Cela pourrait être étendu pour prendre en charge d’autres éléments tels que les NPU. Ce pilote expose une API basée sur des normes à l’application. En collaboration avec d’autres partenaires de l’industrie et Khronos, CoreAVI a proposé Vulkan SC – une implémentation critique pour la sécurité qui tirerait parti de toutes les qualités de l’API Vulkan, mais pour une utilisation dans des conceptions fonctionnellement sûres. Par la suite, cette proposition a trouvé un écho et le groupe de travail Vulkan SC a été formé sous la présidence de CoreAVI. C’était il y a environ deux ans et demi. Aujourd’hui, grâce à l’engagement des membres du groupe de travail, nous en sommes au point où la norme Vulkan SC est sur le point d’être ratifiée. Nous ne devons pas sous-estimer l’impact de cette étape importante. Qu’est-ce que cela signifie ? Eh bien, je vais vous renvoyer au défi mentionné plus tôt – nous avons maintenant une solution à une partie du problème – un pilote critique de sécurité basé sur des normes ouvertes qui permet aux applications d’être efficacement portées sur diverses plates-formes matérielles tout en répondant aux exigences strictes de certification de sécurité telles que ISO 26262, DO-178C et IEC 61508. Évolutivité, réutilisation et sécurité – c’est fait !

En note de bas de page, l’histoire devient encore meilleure. En utilisant Vulkan SC comme couche fondamentale, CoreAVI a encore étendu cette philosophie basée sur des normes pour inclure des bibliothèques fonctionnellement sûres qui se trouvent directement sur le dessus pour fournir d’autres API populaires telles que OpenGL® SC1 et OpenGL® SC2, l’encodage et le décodage vidéo (H.264, etc.), les fonctions mathématiques BLAS et FFT et OpenVX™ pour des applications de calcul sûres telles que la vision par ordinateur et les réseaux de neurones.

En conséquence, avec la ratification de la norme Vulkan SC et les offres de bibliothèque complémentaires, je crois fermement que les développeurs ont maintenant le « port de choix ». Ils peuvent créer des applications pour des graphiques sécurisés et un déploiement de masse de calcul qui prennent en charge non seulement les plates-formes matérielles d’aujourd’hui, mais qui sont également efficacement évolutives pour les implémentations de demain. Cela stimule l’innovation, tout en réduisant considérablement les coûts et les calendriers de développement au service d’un monde plus sûr.