De la conception au code source : Tobias Kästner sur Zephyr
En amont de la conférence en ligne Elektor « Zephyr – The Open RTOS for Tomorrow’s Devices« , qui aura lieu le 5 novembre, nous nous sommes entretenus avec le conférencier Tobias Kästner sur l’importance de l’architecture fonctionnelle dans les projets embarqués modernes. L’architecte de solutions (médicales) IoT de la société de conseil inovex explique comment le framework Zephyr aide les développeurs à traduire les exigences de systèmes complexes en structures logicielles faciles à maintenir et flexibles.
Elektor : Lors de la conférence, vous ferez la présentation suivante : « Zephyr in Practice : De la conception fonctionnelle à la mise en œuvre efficace ». Pourquoi le thème de « l’architecture fonctionnelle dans Zephyr » est-il particulièrement pertinent à l’heure actuelle ?
Tobias Kästner : En fait, le thème de l’architecture fonctionnelle est toujours d’actualité. Pour moi, elle représente la première étape importante entre l’analyse des cas d’utilisation d’un système et les fonctions pertinentes du système que nous devons mettre en œuvre avec notre conception logicielle.
Comme je voudrais le montrer dans ma présentation, Zephyr offre ici des possibilités particulièrement intéressantes, qui me permettent d’arriver beaucoup plus facilement à une conception logicielle propre basée sur les résultats de mon analyse du système, c’est-à-dire l’architecture fonctionnelle.
Elektor : Que recommanderiez-vous aux développeurs qui débutent avec Zephyr et qui souhaitent mettre en place une architecture fonctionnelle ?
Tobias Kästner : Zephyr est un framework puissant et très complet. Se familiariser avec toutes les possibilités qu’il offre demande du temps et une certaine persévérance. Mais vous serez récompensé par le meilleur framwork technique pour la conception de logiciels embarqués disponible sur le marché aujourd’hui. Pour les architectes de logiciels en particulier, il offre de toutes nouvelles possibilités pour convertir leurs conceptions architecturales en code source.
Les architectures fonctionnelles sont issues de l’ingénierie des systèmes, où elles constituent une méthode reconnue d’analyse et de description des systèmes complexes. Zephyr est idéal pour concevoir des logiciels destinés précisément à ces systèmes complexes.
Elektor : Comment Zephyr permet-il d’obtenir un retour d’information plus rapide et des cycles de développement plus courts ?
Tobias Kästner : Zephyr est livré avec une large gamme de services prêts à l’emploi qu’il suffit d’activer dans vos propres applications.
Mes exemples préférés sont l’interpréteur de commandes et le cadre de journalisation. En tant que développeur, l’interpréteur de commandes, en particulier, me donne la possibilité d’essayer des fonctionnalités partielles initiales à un stade précoce avant de les combiner dans des applications plus importantes. Le modèle de pilote, qui a produit plusieurs centaines de pilotes ces dernières années, contribue également à accélérer les cycles de développement. Pratiquement tout ce dont quelqu’un a déjà eu besoin, où que ce soit, peut être implémenté à nouveau. Cela permet d’économiser du temps et des nerfs.
Elektor : Vous faites référence au système de configuration KConfig, qui est également utilisé dans le noyau Linux, et à la structure de données hiérarchique pour la description du matériel, Devicetree, pour la modélisation des caractéristiques du système. Pouvez-vous nous donner un exemple de la façon dont cela fonctionne dans la pratique ?
Tobias Kästner : Dans la pratique, j’utilise beaucoup KConfig pour modéliser mes projets de microprogrammes. L’intégration avec les symboles KConfig déjà présents dans Zephyr est transparente et s’appuie sur les mêmes outils et étapes du processus dans le système de construction. Cela me permet, par exemple, de n’activer que certaines fonctions à des fins de test, parce que tous les composants ne sont pas encore disponibles sur le prototype que j’ai devant moi. Je peux aussi facilement passer d’une implémentation multiple à une API commune en utilisant CONFIG_ACME_HEATER_TWOPOINT=y ou CONFIG_ACME_HEATER_PID=y, par exemple.
Ces « feature toggles » laissent toujours l’ensemble du code sur une seule branche et facilitent grandement l’intégration, en particulier dans les grandes équipes.
Elektor : Vous parlerez de l’importance de l’émulation pour la stratégie de développement et de test. Quels sont les outils ou les approches que vous recommandez ?
Tobias Kästner : Comme je viens de le décrire, la flexibilité de KConfig peut également être utilisée pour permettre soit l’implémentation « réelle », soit une émulation. Cela peut être décidé séparément et indépendamment pour chaque sous-fonctionnalité.
Ajoutez à cela l’excellente prise en charge des émulateurs offerte par Zephyr, et vous disposez de puissants modèles de processus pour le développement piloté par les tests, auquel nous attachons une grande importance dans les projets agiles.
Elektor : Quels ont été vos principaux enseignements lors de la mise en correspondance de l’architecture avec les composants de Zephyr ?
Tobias Kästner : Afin d’exploiter pleinement les possibilités offertes par Zephyr en tant que développeur ou architecte, la compréhension des trois composants KConfig, Devicetree et le système de construction basé sur CMake a certainement été la leçon la plus importante. C’est précisément l’interaction de ces trois technologies qui donne lieu à de nombreuses synergies qui rendent le travail avec Zephyr unique. Cet effort est récompensé par des architectures maintenables, à la fois stables et flexibles, qui peuvent être adaptées aux exigences changeantes du système avec un effort minimal et, surtout, prévisible.
Pour plus d’informations sur la conférence en ligne d’Elektor « Zephyr – The Open RTOS for Tomorrow’s Devices » du 5 novembre, consultez le site web de la conférence.
Inscrivez-vous dès aujourd’hui !
Note de l’éditeur : eeNews Europe est une publication d’Elektor International Media.
Si vous avez apprécié cet article, vous aimerez les suivants : ne les manquez pas en vous abonnant à :
