O3S

Le but de ce type de solution est de pouvoir permettre le test d’un système en usine en se situant aussi près que possible des conditions d’opération de l’utilisateur final. Ceci se fait grâce à la capacité à simuler tout ou une partie de l’environnement d’utilisation finale

, mais aussi une partie des équipements sous test eux-mêmes.

Lors des différentes itérations d’un projet, on peut basculer d’une situation à l’autre suivant les cas de figure suivants:

  • Le modèle dans la boucle (MIL – Model In the Loop): on teste et valide le modèle du système ou d’un composant du système
  • Le logiciel dans la boucle (SIL- Software In the Loop): on teste ou valide le code portable devant s’exécuter sur la cible finale
  • Le matériel dans la boucle (HIL – Hardware In the Loop): on valide le système dans les conditions d’utilisation, avec éventuellement la possibilité de combiner les trois cas de figure.

Pour notre part, nous distinguons également ce que nous appelons le schéma dans la boucle (SchIL – Schema In the Loop) du MIL. En effet, si un modèle est une approximation, le schéma est quand à lui une description complète. Quand il s’agit, par exemple, de faire de la génération de code à partir d’un modèle, on devrait plutôt parler de génération à partir d’un schéma, puisqu’il s’agit bien de la description complète du comportement qui va servir de source à la génération. Dans ce cas, introduire le code générer dans la boucle de test équivaut à tester, ou du moins utiliser le cas échéant, le schéma. Il ne s’agira pas non plus du logiciel dans la boucle, car le résultat de la génération sera dépourvu, la plupart du temps, des couches logicielles non fonctionnelles, par exemple.

Quelques situations de test possibles avec O3S

Développée en collaboration avec la société OpenTekhnia, Open System Simulation Solution est, donc, une solution de simulation permettant de mettre en œuvre des plates-formes d’intégration et validation pour les systèmes embarqués, distribués ou pas, plus généralement pour les systèmes automatisés multi-domaines, cela quel que soit le niveau de complexité requis. Elle se caractérise par:

  • Une modularité exceptionnelle basée sur une architecture matérielle en nuage Ethernet et/ou USB avec des unités de calculs diverses (PCs, PCs industriels, Macs, calculateurs embarqués, etc.) et des Remote I/Os Ethernet et/ou USB, mais aussi des cartes IO sur bus PCI, lorsque le besoin en performances est très présent;
  • Des capacités d’entrées/sorties couvrant la plupart des besoins standards (série, bus CAN, Modbus, E/S analogiques, E/S discrètes, Ethernet, etc.) et pouvant s’adapter facilement à tout besoin particulier (e.g.: signaux spécifiques simulant un odomètre de matériel roulant ferroviaire);
  • Des modèles de simulation pouvant être codés en utilisant des langages script comme Python, ou bien un langage comme C/C++ pour la tenue des performances les plus exigeantes, mais aussi Java, Ada 95 ou Fortran lorsque les projets le nécessite pour diverses raisons;
  • Une configuration qui s’effectue par le biais de fichiers XML. Sur ce point, tout le monde vous dira en général la même chose, du moins ces dernières années. Cependant, utiliser XML n’est pas suffisant pour la simplification du déploiement et de la configuration. Il faut un vrai travail de conception derrière pour que la représentation des données soit aussi simple, homogène et logique que possible, seuls ces facteurs pouvant assurer une interopérabilité avec les modèles de données métier;
  • Une capacité d’extension théoriquement sans limites, exceptée celle de la quantité d’information échangée à travers le réseau reliant les éléments de la plate-forme;
  • Un dimensionnement du nombre d’entrées/sorties gérées qui est limité uniquement par la puissance de calcul disponible grâce aux unités de calcul, c’est à dire par le nombre d’unités présentes;
  • Un temps de cycle du noyau temps réel de 10ms dans la version Linux/Xenomai, ce qui permet un cycle de lecture/écriture des E/S physiques de 100ms (autre exemple: temps de cycle de 1ms pour QNX).

Notre solution est entièrement basée sur des développements open source et du matériel du commerce largement répandu. Ceci veut dire que le code source est disponible pour nos clients, mais aussi que le coût des licences est fantastiquement réduit par rapport à des solutions concurrentes, grâce à l’utilisation du travail produit par la communauté open source. En tant que développeurs et intégrateurs, nous avons choisi uniquement les produits open source compatibles avec les exigences des développements industriels, puis nous avons amélioré la documentation, ainsi que la maintenabilité de ces produits. Le résultat est un produit de très haute qualité, entièrement ouvert et documenté, pour des prix qui rendent les solutions de simulation enfin réellement accessibles pour tous les projets.

Architecture fonctionnelle

L’architecture de O3S est très fortement conçue par couches. L’idée est d’isoler au maximum la réponse à chaque besoin de manière à pouvoir circonscrire les problèmes éventuels, mais aussi à simplifier le déploiement de la solution, point ô combien essentiel.

Ainsi, les couches sont-elles au nombre de quatre:

  • couche matérielle: calculateurs/unités de calcul (PU – Processing Units), cartes E/S standards, unités d’E/S spécifiques. Pour cette couche nous utilisons au maximum les produits disponibles dans le commerce en conseillant nos clients de faire les choix appropriés par rapport aux performances et fonctionnalités requises. En effet, nous ne vendons pas nous-même le matériel, sauf pour celui développé spécifiquement, ce qui permet de ne pas superposer inutilement les marges. Nous fournissons cependant toutes les informations sur les compatibilités à travers une librairie de références de composants, testée par nos soins;
  • couche OS: OS en fonction des besoins et performances. Notre solution est multi-plates-formes compatible avec Linux, Linux/Xenomai, MacOS X®, Windows®, mais aussi QNX® et VxWorks®;
  • cœur de simulation: il s’agit d’une couche temps réel distribuée fournissant tous les services nécessaires à la simulation, ainsi que les services d’extension à travers des bundles C++. Elle fournit également les interfaces utilisateurs de base, ainsi que les services permettant d’en créer de spécifiques;
  • couche métier: cette couche fournit les services pour l’importation et la création de modèles de simulation, le pilotage automatisé de la plate-forme et le développement de modules spécifiques (en complément des services type API fournis par le cœur).

Les couches de l’architecture O3S

Les commentaires sont fermés.