Juzzle

Juzzle est une plateforme de développement open source de mise au point et d'exploitation de simulateurs, utilisée depuis de nombreuses années dans les domaines de la simulation scientifique par la communauté industrielle française.

Cet environnement se positionne d'une part comme outil d'interopérabilité, permettant de faire cohabiter des simulateurs de technologies hétérogènes (Matlab, C, scilab, Java, SystemC, etc.), mais aussi en tant qu'environnement de développement collaboratif, et enfin en tant que plateforme d'exploitation orienté grid computing, grâce à sa fonctionnalité intégrée de distribution de calculs sur un réseau hétérogène.

(liste non exhaustive) :

• Définition d’applicatifs de type Federation, offrant la possibilité de définir graphiquement une chaîne de traitement hiérarchisée et hétérogène (chaque module pouvant être développé dans une technologie différente). Plusieurs moteurs d’exécutions sont alors disponibles en fonction du domaine d’application : séquenceur de test pour les bancs d’expérimentation, moteurs de simulation numérique (time driven, data driven, SystemC, etc.).
• Possibilité d’interfaçage avec des moteurs externes (gratuits ou soumis à licence)
• Environnement de développement intégré pour des machines Java, C, Fortran, Ada
• Environnement de développement intégré pour des fédérations Java, C, Fortran, Ada (appel de l’éditeur syntaxique des codes sources directement depuis l’éditeur graphique de la fédération, génération de codes d’interfaçage, appel automatique au compilateur et à l’édition de lien).
• Exploitation de toute machine respectant une interface Machine et Node Juzzle,
• Exécution d’études statistiques réalisées sur toute machine Juzzle,
• Exécution d’études de cas (variation de paramètres d’entrée de la machine par combinaisons déterminées à l’avance),
• Exécution locale, à distance, multi-machine, et différée de toute machine Juzzle,
• Interfaçage pour le post-processing avec Matlab, scilab, octave, et Excel
• Possibilité de créer une machine réalisant l’enchaînement de plusieurs autres machines Juzzle, avec la définition d’un script d’enchaînement (possibilité d’exécuter plusieurs fois une même machine, de faire des tests sur les résultats obtenus, etc.)
• Interfaçage avec d’autres plateformes de développement comme SystemC, ptolemy, SPW, etc.
• Nombreuses fonctions d’importation/exportations (XML en particulier).

Parmi les quelques notions fondamentales, la notion de ‘machine’ est la plus importante. C’est elle qui regroupe tous les simulateurs développés puis exploités.

Un simulateur (une machine) est une entité permettant à l’utilisateur de définir :

• Un ensemble de paramètres
• Un ensemble de résultats
• Le traitement permettant d’obtenir les résultats en fonction des paramètres

La déclaration des paramètres et résultats est réalisée de manière universelle quel que soit le type de simulateur mis en œuvre. Par contre, la définition du traitement peut être réalisée de différentes manières. Le paragraphe suivant présente les différents moyens mis à disposition de l’utilisateur pour développer un nouveau simulateur (un nouvelle machine).

Le traitement de ce type de simulateur est décrit par l’utilisateur dans un script. JUZZLE permet d’utiliser différents langages :

• C
• Java
• Fortran77
• Ada95

Pour chacun de ces langages, il prend en charge automatiquement la conversion des paramètres spécifiés via les IHM JUZZLE en données compréhensibles par le langage utilisé. Lors de l’exécution du simulateur, il génère l’exécutable associé au script, en utilisant le compilateur disponible, et lance l’exécutable natif obtenu. Après la fin de l’exécution, il prend en charge automatiquement la transformation des données produites par le script en données XML compréhensibles par Juzzle.

Ainsi, ce type de simulateur permet de réutiliser des codes algorithmiques existant sans effectuer d’opération de portage.

Il est possible de définir un simulateur en réutilisant des programmes natifs (‘.exe’, ‘dll’…) sans avoir à connaître le code originel du programme.

Comme pour tout simulateur, l’utilisateur déclare les paramètres et résultats correspondant aux codes interfacés. Il spécifie alors la méthode d’exploitation des programmes natifs sous forme de script de commande système, comme s’il utilisait une fenêtre console courante.

Une fois ces opérations effectuées, les opérations d’initialisation et de suivi de l’exécution s'effectuent automatiquement.

Ce type de simulateur est essentiel dans un contexte de réutilisation de l’existant. Il permet de réutiliser sans aucune modification les anciens programmes bâtis sur des technologies obsolètes ou dont le code ne peut plus être modifié.

Si la déclaration des paramètres et résultats des simulateurs est toujours réalisée sous JUZZLE, l’exécution de la simulation peut être déléguée à un outil tiers :

• Matlab
• Microsoft Excel
• Scilab
• Octave

Cette liste correspond aux produits interfacés dans le cadre de la version freeware de Juzzle, mais Silicom a réalisé de très nombreuses interfaces supplémentaires dans le cadre de projets spécifiques à ses clients (exemple : interfaçage avec un outil de cartographie, avec un outil d’optimisation de graphes, avec un outil de calcul d’antennes, etc.).

Tout comme pour les autres types de simulateurs, la plateforme prend en charge la migration des paramètres depuis JUZZLE vers le logiciel utilisé et le rapatriement des résultats depuis l’outil vers JUZZLE. Dans tous les cas, L’utilisateur définit le traitement à mettre en œuvre en utilisant le formalisme de l’outil exploité.

Par exemple, pour utiliser Matlab, l’utilisateur définit les scripts Matlab permettant de calculer les résultats en fonction des paramètres. Pour utiliser Excel, l’utilisateur définira une feuille Excel où il spécifiera les cellules d’entrée et les cellules de sortie.

Contrairement aux simulateurs présentés dans les paragraphes précédents, l’entité ‘Fédération’ permet de connecter et paramétrer plusieurs modèles, chacun représentant une partie du système à simuler. Les liens entre les différentes entités représentent les canaux d’échanges de données dynamiques entre modèles. Ainsi, la modélisation de chaque entité élémentaire (nœud) est plus simple à la fois en termes de spécification mais aussi de développement et de test.

De nombreux outils commerciaux utilisent déjà cette méthodologie pour la construction de simulateur. La prise en charge de l’exécution d’une fédération JUZZLE repose sur l’utilisation d’une entité appelée ‘moteur de simulation’. il existe plusieurs types de moteurs :

• Moteur par flux de données
• Moteur événementiel
• Moteur SystemC

C’est ce moteur de simulation qui coordonne les traitements, parallèles ou non, des différents modèles élémentaires.

Cette approche, très utilisée, répond à de nombreuses contraintes :

• Parallélisation des développements. Les modèles élémentaires sont développés et validés unitairement avant d’être intégrés.
• Réutilisation de fonctions élémentaires. Par exemple, une fonction de génération de bruit intégrée sous forme de modèle élémentaire peut être réutilisée dans différents autres contextes.
• Simplicité de la structure en vue d’une maintenance aisée.

En plus des outils de simulation basée sur diverses technologies (Matlab, C, Java, Fortran, Excel…), l’atelier offre un ensemble de services pouvant être utilisés quelle que soit la technologie de simulation employée. Ces services transverses sont appelés : services génériques.

Le chaînage de simulation est un service permettant à l’utilisateur de définir une simulation comme un enchaînement, de simulateurs. Chacun des simulateurs est basé sur une technologie quelconque. Les exécutions sont réalisées de façon séquentielle.

Par ailleurs, des paramètres globaux peuvent être définis aux niveaux supérieurs et être utilisés par chacun des simulateurs. De même, JUZZLE permet de définir des dépendances entre les résultats d’un premier simulateur et les paramètres d’un deuxième.

Il est ainsi possible pour une simulation complexe, d’automatiser la mise en œuvre de simulation de calibrage préliminaire. L’utilisateur n’a alors plus besoin d’intervenir ce qui, d’une part facilite la mise en œuvre de simulation et d’autre part minimise le risque d’erreur de manipulation.

Un fois mis au point, tout simulateur est voué à être exploité. Parmi les méthodes d’exploitation les plus connues, les études paramétriques et statistiques sont incontournables.

Ces deux services sont proposés de manières générique, c’est-à-dire indépendamment des technologies utilisées par le simulateur exploité.

La mise en œuvre d’une étude s’effectue en deux étapes :

• Définition de la machine (du simulateur) exploité. Quelle que soit la technologie utilisée, ce simulateur est vu comme un modèle quelconque avec des paramètres, des résultats et une méthode de calcul.

Déclaration des jeux de paramètres. Dans le cas d’une étude paramétrique, il s’agit de définir exhaustivement les cas de simulation à mettre en œuvre. Dans le cas d’une étude statistique, les paramètres sont définis à l’aide de lois aléatoires (gaussienne, uniforme…)

• Dans tous les cas, l’exécution de l’étude se traduit par la mise en œuvre de ‘N’ cas de simulation, chaque cas étant attaché à un jeu de paramètre particulier. L’automatisation de l’enchaînement des cas et la synthèse des résultats de simulations sont automatiquement pris en charge.

Différents services proposés mène à l’exécution de plusieurs cas de calcul. Lorsque ces cas sont indépendants, il est possible d’externaliser l‘exécution des calculs.

L’exécution déportée permet d’utiliser un poste de travail distant pour l’exécution du calcul dans sa globalité. Ainsi le poste de l’utilisateur reste disponible pour soit d’autres simulations, soit d’autres activités… L’exécution distribuée permet de répartir l’exécution de ‘n’ cas de calculs indépendants sur plusieurs postes de travail distants, la plate-forme se chargeant de coordonner les échanges de données et la synthèse des résultats.

Dans tous les cas, ces services ont pour but d’augmenter la capacité de calcul effective pour un parc informatique donné. En particulier, la mise en œuvre de campagnes de calculs le week-end permet de mettre en œuvre des simulations impossible à mettre en œuvre en semaine.