Produits

Nous préférons les produits aux services. D’abord, parce que cela offre une certain liberté. Ensuite, parce que l’ambiance “entreprise” est rarement propice au travail créatif. Et l’ingénierie, c’est d’abord de la créativité. Nous travaillons, donc, dans notre future micro-ferme, quelque part dans les bocages de la Gâtine. L’informatique a cela de beau qu’elle permet de toucher un peu à tous les domaines. C’est pourquoi nos produits et nos réalisations vont dans tous les sens. Mais à bien y regarder, il y a un fil conducteur.

Et ce fil conducteur est de travailler avec des systèmes, dans le but de les développer ou de les construire, ou encore de les comprendre ou les schématiser.

Open System Simulation Solution

AVERTISSEMENT

Ce produit a été définitivement vendu à la société Spherea Test & Servrices. Les droits de propriété appartiennent donc, dorénavant, à Spherea.

Dans l’ordre d’importance, O3S (Open System Simulation Solution) est certainement notre pièce maîtresse, que nous avons réalisé en partenariat étroit avec Techniware.

O3S

Ce sont des types brillants travaillant chez notre client CASCO qui en donne la meilleure définition: O3S est à la fois un middleware et une boîte à outils pour la réalisation de plates-formes et bancs de test/validation, mais aussi d’outils de maintenance et de diagnostic.

En fait, on peut en faire à peu près ce qu’on en veux.

O3S offre d’abord de quoi échanger des données: en cela, on pourrait l’assimiler à un middleware de distribution de données temps réel (mou). On en distribue des objets (variables) d’une complexité quelconque (primitifs, aussi bien que des structures sans limite de profondeur).

O3S est donc bâti sur une structure de nœuds, qui sont des processus indépendants s’exécutant sur une machine physique ou virtuelle. Chaque nœud peut exécuter une ou plusieurs applications dans son contexte propre, lui donnant ainsi accès aux ressources physiques (E/S de toute sorte, comme les TOR, ANA, ETH, CAN, série etc.). En particulier, les services O3S donnent la possibilité de mapper automatiquement un objet O3S sur un message entrent ou sortant (TCP par exemple), ou encore sur une E/S plus simple, l’osque l’objet est primitif (ex: un booléen mappé sur une sortie TOR).

Architecture O3S

Pour illustrer, imaginons qu’une application cliente O3S (on appellera ce client simplement une application O3S) utilise un objet O3S nommé Toto qui est une simple variable entière. Si le client fait l’opération:

Toto = 5

dans un délais de maximum Nms, l’ensemble des applications s’exécutant sur n’importe quel nœud aura la mise à jour de la valeur de Toto (N étant le temps de cycle du rafraîchissement des données sur l’ensemble des nœuds: généralement 5ms pour une configuration standard basée sur des nœuds s’exécutant sous Linux).

Dans les faits, ce n’est pas vraiment plus compliqué que cela, cette instruction d’attribution étant fournie dans l’API de O3S pour à peu près n’importe quel langage (disponibles par défaut: C/C++, Python, Javascript/NodeJS).

Imaginons maintenant que dans la configuration physique de O3S (configuration des E/S), il existe un endpoint appelé O1. Ce endpoint correspondra, par exemple, à une sortie d’une carte ANA dont la valeur peut aller de 0V à 10V. Dans la configuration on fournit une règle qui dit que pour une valeur entière 1, la valeur des sorties de la carte sera de 1V. En faisant alors quelque chose du genre:

  Toto.attach(O1)
  ...
  Toto = 5

la valeur de la sortie passera à 5V. Simple.

Le but de tout cela est de donner à l’utilisateur la possibilité d’adresser le monde physique à partir de n’important quel comportement codé dans à peu près n’importe quel langage est s’exécutant sur un nœud O3S.

Ce comportement sera implémenté sous la forme d’une application, cette application pouvant nativement être de deux sortes:

  • Python: il s’agira d’une archive contenant un nombre quelconque de scripts Python ayant un point d’entrée comportant trois fonctions: init, run et stop (le nom n’a pas d’importance en fait);
  • C++: même principe, sauf que le point d’entrée sera dans ce cas une classe C++ comportant les trois méthodes.

Dans les deux cas, il est possible d’intégrer, en fait, des libraires écrites dans n’importe quel langage.

Il est possible cependant d’intégrer un comportement à O3S par deux autres mécanismes:

  • les bundles (ou plugins): il s’agira en général de comportement commun, autrement dit de fonctionnalités nouvelles fournies à l’ensemble des applications;
  • la spécialisation: tous les nœuds O3S n’ont pas besoin de toutes les fonctionnalités implémentées par le biais des bundles, justement. On choisira alors de créer des nœuds légers implémentant soit une fonctionnalité spécifique, soit un comportement applicatif lié au domaine d’utilisation.

Nœuds O3S

A noter sur l’application précédente, une notion d’application bien particulière: les tests. Comme O3S est orienté “réalisation d’outils de validation”, toute séquence d’actions peut-être automatisée (par exemple, toutes les actions d’un opérateur). Dans le cas d’une banc de test, par exemple, cette manière programmatique de gérer les interventions peut facilement constituer une séquence de test. Le langage étant libre (et ayant pensé qu’en créer un de plus serait stupide), vous pouvez le faire en Python ou Javascript, mais aussi Lua, TCL, Ruby etc. Ici nous parlons uniquement de langages de script, car évidemment plus appropriés pour ce type de besoin.

Lorsqu’on parle d’automatisation des actions opérateur, on sous-entend l’existence d’un ensemble de modules permettant l’interface entre l’utilisateur et une plate-forme O3S. Ces applications sont (à partir de la version 3.0.0), au nombre de 5:

  • Control Center (anciennement Platform Manager): permet l’administration de l’ensemble (charger/décharger des applications, des bundles, de la configuration, modifier la configuration d’un nœud, lancer/stopper des applications etc.);
  • Designer: permet la réalisation de synoptiques en lien avec l’état des variables O3S (autrement, permet de visualiser ou modifier les valeurs des variables O3S);
  • Scope: sorte d’oscilloscope pour les signaux (variables) O3S;
  • Console: donne accès à un ensemble de commandes en ligne spécifiques à O3S, ainsi qu’au shell du contexte où s’exécutent les nœuds (lorsque sous Unix/Linux);
  • Studio: environnement de développent intégré permettant le développement d’applications et bundles O3S. Deux versions coexistent: une basée sur Eclipse (historiquement la plus vieile, mais aussi la plus complète) et une basée sur Codebox, donc en HTML/Javascript.

En fait, à partir de la version 3.0.0 de O3S, on cherche à converger vers une seule technologie pour ces GUI: HTML/Javascript. La version Eclipse de Studio sera par conséquent maintenue tant que son alter ego HTML n’est pas parfaitement équivalent ou que nos clients en feront la demande.

A l’origine, les GUI de O3S étaient développées en Flex/Actionscript. La politique de Adobe a fini par avoir raison de notre amour pour cette solution. Cependant, nous gardons la possibilité de fournir ponctuellement ces applications à nos clients les plus exotiques, puisqu’elles sont vraiment belles et abouties.

GUI O3S

Un point essentiel de notre produit est sa disponibilités sur quasiment tous les OS: Linux, Mac OS X, Windows, mais aussi QNX et, potentiellement, Solaris.

Cette souplesse provient de la structure stratifiée de O3S qui a pour objectif d’être indépendants du matériel, à travers une forte portabilité OS. Pratiquement, ceci est réalisé grâce au framework Poco.

Strates O3S

Il est évident que pour mieux comprendre O3S, le mieux est de nous contacter.

Le fait est qu’une bonne équipe ne nécessite que 5 à 10 jours de formation pour être 100% autonome avec O3S. Cette stratégie d’offrir l’autonomie à nos clients à travers la simplicité, s’accompagne de la fourniture effective des codes sources, gage de transparence dans le plus pur esprit du logiciel ouvert. La seule chose qui nous empêche de rendre le code totalement libre, est l’obstination de nos chacals de compétiteurs ou plus généralement des grosses entreprises à se comporter comme des pilleurs, alors qu’ils défendent comme des hyènes un monde breveté où il faudra bientôt payer l’un d’entre eux pour avoir le droit de faire ses lacets.

Mais si O3S est simple pour un utilisateur lambda, c’est parce que nous l’avons conçu comme des utilisateurs. Il faut être honnête, si O3S est utilisable aujourd’hui à peu près sans limites dans tout domaines (attention, il ne s’agit tout de même pas d’une application sécu), à l’origine il a été conçu pour le développement de plates-formes de validation. LA conception fut basée sur des observations factuelle des failles et nœuds gordiens existant dans le développement de systèmes complexes.

Validation

En particulier, notre expérience se base sur le monde ferroviaire et les plates-formes de test permettant la validation usine d’un système complet.

Plate-forme de validation d'un système ferroviaire

Évidemment, à part quelques esprits étriqués, un ingénieur comprendra que les problématiques d’une telle situation seront grosso-modo les mêmes quelques soit le domaine d’application.

Grha

Cet autre produit a une histoire intéressante. Dès 2010, nous avons imaginé que le meilleur moyen de travailler efficacement est de travailler chez soi. Je vois venir ceux qui parlent de vie sociale, ou encore de capacité à s’y tenir, ou encore du travail en équipe.

La vérité est qu’il y a longtemps, tellement longtemps que les “mémoires courtes” que nous sommes l’ont oublié, l’idée d’aller quelque part loin, ailleurs que chez soi pour travailler aurait fait bien rire.

C’est certain que ceux qui n’ont rien à faire de leur famille, drogués à la machine à café, aux réunions puantes, aux embouteillages ou au métro, ou encore à la toute puissance du besoin d’être écoutés, préféreront à jamais ce qu’ils font aujourd’hui au fait de voir leurs gosses grandir, socialiser avec autre chose que des clones d’eux ou savoir travailler juste ce qui est nécessaire pas plus.

Mais ça, c’est leur problème (encore que, étant assez nombreux et souvent en situation de décider pour les autres, ils pourrissent le monde entier).

Pour notre part, nous avons construit une maison, maison qui sert à y loger, à y travailler, à s’y nourrir (avec une micro-ferme en train d’être réalisée autour). Grha est une application née de cette expérience. Il s’agit un outil d’aide fournissant à la fois les moyens de suivi simplifié du projet (une fois de plus, simplifié veut dire ce qu’il faut, mais pas plus) et la connaissance, potentiellement mise en commun pour faire tout seul, au maximum. Si l’auto-construction est à la mode, ce n’est pas seulement pour cause de crise, mais aussi parce que les normes ont fini par donner le monopole aux professionnels et presque totalement cessé de protéger les particuliers. Il s’agit d’une réponse qui consiste à dire: je fais moi-même parce que je sais ce que je veux et je suis sûr de l’obtenir ainsi.

Plus d’info sur le site.