Par Olivier Haas janvier 21, 2023
SDS (v1) est une plateforme d’exécution multi-nœuds et multi-tâches de machines à états distribuables et synchronisables du fait qu’elles tournent sur cette plateforme.
1. Caractéristiques-clés
2. Distributions
3. Cas d’utilisation
4. Vision
5. Positionnement
6. Agenda
7. Tarifs
1. Caractéristiques-clés
- Programmation via la définition d’automates / de machines à états.
- SDS intègre un moteur de machine à états ; la programmation de SDS est donc orientée machines à états.
- Autour des machines a états, des concepts supportent des fonctions avancées :
- Fonctionnalité, qui correspond à un sous-ensemble d’une machine à états.
- Contexte d’Exécution Appliqué, qui fixe, comme son nom l’indique, le contexte que l’on applique à l’exécution d’une instance de machine à états.
- Contexte d’Exécution Constaté, qui permet de définir en compréhension des états sur une instance de machine à états, ainsi que les événements d’entrée dans et de sortie de, un tel état défini en compréhension.
- etc.
- Des déclarations supplémentaires concernent les moniteurs, les flux attachés aux données voulues, le multiplexage/démultiplexage, etc.
- Développement graphique via atelier de modélisation UML.
- Des générateurs de code existent pour générer les fichiers sources compréhensibles par SDS à partir d’un éventail de diagrammes UML (dans le cadre de SysML ou non).
- Chargement, lancement, pilotage, via ligne de commande.
- Une instance SDS se présente sous la forme d’un serveur, présentant un shell, accessible soit en mode texte, soit en mode JSON.
- Transport d’instance d’exécution sur un réseau de nœuds SDS (Distribution).
- Une instance d’exécution d’une machine à états, s’exécutant sur un nœud SDS donné, peut à tout moment être arrêtée dans un état stable, passivée, déplacée sur un autre nœud, et enfin activée.
- Récursivité
- Une machine à état peut constituer et charger une machine à états.
- Modèle récursif de surveillance d’une machine à états par une autre.
- Une machine à états peut être déclarée comme surveillant une autre machine, ceci de façon récursive. Cette surveillance peut être asynchrone - et donc transparente du point de vue de la machine surveillée - ou synchrone - et donc réaliser une forme de programmation orientée aspect.
- Modèle récursif d’amorces.
- Une instance de machine à état peut provoquer le chargement d’une machine, et/ou une instanciation de machine, puis re-router des événements vers cette/ces instance(s), ceci de façon récursive.
- Spécialisation, héritage multiple.
- Une machine à états peut être spécialisée, via les états complexes. Le mécanisme autorise l’héritage multiple.
- Gestion de flux intégré.
- Par simple déclaration, une donnée peut être associée à une fenêtre de gestion de flux.
- Mux/Demux
- Afin de permettre les collaborations complexes entre instances de machines à états, les communications entre ces instances mettent en œuvre le multiplexage et le démultiplexage.
- Temps-réel.
- Modèle d’exécution synchrone ou asynchrone, au choix.
- SDS, chargé avec une couche de machines à états spécifique (fournie par S3CA) constitue un noyau temps réel (RTOS).
- Des ponts avec les méthodes SA-RT, AADL, Réseaux de Pétri, Diagrammes de Harel, Lustre, Esterel, SysML, etc., sont bien-sûr possibles.
- Support possible jusqu’au temps réel strict critique.
- Mode interprété / mode compilé.
- Le mode le plus riche de SDS est le mode interprêté, mais le mode compilé peut s’avérer plus pertinent lorsque certains mécanismes dynamiques ne sont pas requis et/ou lorsque la rapidité d’exécution doit être privilégiée.
- Génération de code pour passer du mode interprété au mode compilé.
- Lorsqu’une machine à états est testée (ou prouvée) avec succès, son code Java ou C++ peut être généré, afin d’obtenir le même comportement en mode compilé.
- Mode pas à pas (debug).
- Il est possible de se connecter à un nœud SDS puis de contrôler une instance de machine à état, avec toutes les fonctionnalités habituelles d’un debuggeur.
2. Distributions
- Java (déployable comme un .ear, typiquement sous WildFly)
- C++/Arduino
- ADA (Raspberry)
- D’autres portages sont bien-sûr possibles, en fonctions des besoins et opportunités qui pourraient se révéler.
3. Cas d’utilisation
3.1. Cas typique
- Dans l’atelier UML EnterpriseArchitect de Sparx, suivant un cadre défini et fourni par S3CA (avec profil UML associé), effectuez la modélisation de votre application. (En voici une illustration par quelques diagrammes)
- Avec les squelettes de génération de code fournis par S3CA, générez les srcipts de commandes SDS permettant de charger votre application dans un nœud SDS (ou un réseau de nœuds).
- Finalisez vos scripts de chargement de de lancement de vos applications dans votre réseau SDS.
- Placez vos scripts de chargement et de lancement dans votre exploitation.
S3CA peut prendre en charge tout ou partie de ce cycle en tant que prestation de service.
3.2. Variantes
- N’importe quel atelier de modélisation UML, autre qu’EnterpriseArchitect, peut convenir : les squelettes de génération de code SDS seront portés par S3CA à titre gratuit.
- L’intégration avec l’outil UML peut aller plus loin : les modèles de déploiement peuvent, par exemple, servir de base pour générer des scripts d’exploitation.
4. Vision
- La programmation par machine à états permet un cycle de développement plus sûr.
- Le passage d’une formule du lambda-calcul typé (Système F ou Calcul des constructions) à une machine à états permet la mise au point formelle (par atelier formel, en amont).
5. Positionnement
- Types d’applications envisagées :
- IoT
- Protocoles réseau
- Systèmes temps réel
- Robotique
- Systèmes d’Exploitation à la carte
- …
6. Agenda
- La distribution Java de SDS (v1) est en bêta-test, les fonctionnalités les plus importantes étant parfaitement fiabilisées. Un logiciel de transfert de fichiers, déjà en commercialisation, utilise SDS (v1). La clôture de cette phase de bêta-test est prévue pour février 2023.
- La distribution C++/Arduino est planifiée de février à juin 2023.
- La distribution ADA est planifiée de avril à juillet 2023.
7. Tarifs
- Les contextes pouvant être très différents, tant qualitativement que quantitativement, il nous semble plus pertinent d’aborder la question tarifaire dans le cadre d’une réponse globale à votre besoin : voici notre formulaire de contact.