ALBRIEUX, Yves (60 rue des Chantiers, Versailles, Versailles, F-78000, FR)
| REVENDICATIONS 1. Procédé d'exécution parallèle d'une pluralité de tâches ordonnées selon une table d'ordonnancement, exécutées par au moins une unité de traitement de données connectée à un bus applicatif, à chaque tâche étant associé un coefficient de durée estimatif du temps de réalisation de ladite tâche, caractérisé en ce qu'un compte-rendu est fourni par le bus applicatif lors de l'exécution d'au moins une tâche, le coefficient de durée estimatif du temps de réalisation de ladite tâche étant mis à jour en fonction du contenu dudit compte-rendu. 2. Procédé selon la revendication 1 , dans lequel le compte-rendu fourni par le bus applicatif lors de l'exécution d'au moins une tâche comprend une information logique de bon déroulement ou non de ladite tâche, et une information temporelle de durée réelle de réalisation de ladite tâche. 3. Procédé selon l'une des revendications 1 à 2, dans lequel un compte-rendu est fourni pour toute tâche ayant au moins une contrainte d'ordonnancement. 4. Procédé selon l'une des revendications 1 à 3, dans lequel la pluralité de tâches ordonnées selon la table d'ordonnancement est obtenue à partir d'un processus en mettant en œuvre les étapes suivantes : - écriture du processus sous la forme d'un automate ; - détermination d'un enchaînement de tâches qui permet la résolution de l'automate, chaque tâche étant une action élémentaire exécutable par une unité de traitement donnée à laquelle ledit bus applicatif est connecté ; - identification, pour chacune desdites tâches, d'éventuelles contraintes de dépendance vis-à-vis des autres tâches ; - génération de la table d'ordonnancement des tâches en fonction des éventuelles contraintes de dépendance identifiées. 5. Procédé selon l'une des revendications 1 à 4, dans lequel la pluralité de tâches ordonnées selon la table d'ordonnancement est exécutée par cycles, une pluralité de tâches compatibles étant lancées de façon synchronisée à chaque cycle. 6. Procédé selon la revendication 5, dans lequel la synchronisation des tâches s'effectue en minimisant le temps total d'exécution à partir des coefficients de durée associés aux tâches exécutables. 7. Système comprenant au moins, une unité de traitement de données mettant en œuvre le procédé selon l'une des revendications 1 à 6, une mémoire dans laquelle sont stockés lesdits coefficients de durée estimatifs du temps de réalisation de la pluralité de tâches, et une entrée recevant la pluralité de tâches ordonnées selon une table d'ordonnancement à exécuter. |
DOMAINE TECHNIQUE GENERAL
La présente invention se rapporte au domaine des plateformes de développement et de mise en œuvre de systèmes experts.
Plus précisément, elle concerne un procédé d'exécution parallèle d'une pluralité de tâches ordonnées selon une table d'ordonnancement.
ETAT DE L'ART
La simplicité et la convivialité sont très loin d'être l'apanage des systèmes de développement informatiques actuels qui nécessitent le plus souvent l'intervention de spécialistes, qui sont de plus en plus difficiles à trouver. En outre, ces spécialistes ont des grandes compétences en informatique, mais n'ont pas le « savoir-faire métier », c'est-à-dire l'expérience qu'auront les professionnels auxquels sont destinés les outils, et ce dans des domaines qui peuvent être très variés.
En particulier, les applications bureautiques sont extrêmement utilisées dans tous les secteurs de l'économie. Le développement pour une entreprise de services d'un outil qui par exemple créerait automatiquement des devis nécessite ainsi non seulement des compétences en développement informatique, mais aussi, et c'est le plus important, la connaissance des règles employées au quotidien lors de la création d'un devis par les personnes de l'entreprise dont c'est le métier.
L'ambition des plateformes de développement est ainsi de se mettre à la portée « d'analystes métiers » capables d'exprimer un savoir faire métier pour l'exploiter par des automates logiciels qui permettront la réalisation de systèmes experts de très haut niveau.
Des langages de script comme TCL (Tool Command Language) ou plus récemment les langages dédiés au web comme perl ou python, sont des langages multiplateformes, extensibles, faciles à apprendre. Ils sont définis comme des langages dédiés à « programming in the large », c'est-à- dire des projets de grande envergure. Leur but est de fournir le liant qui va permettre à des exécutables existants d'être enchaînés dans des chaînes de traitement plus complexes, et donc des automatisations. Toutefois, si un langage de scripts s'avère très pratique dans le cas de l'exécution d'une séquence d'applications sur une machine, seul il n'est pas vraiment adapté à un fonctionnement collaboratif en entreprise, où de nombreuses machines sont connectées en réseau, certaines machines étant dédiées à certaines applications ou certaines fonctionnalités.
Des composants de connexion logicielle appelés les bus applicatifs (BA), ou bus logiciels, permettent de réaliser les échanges de message et de données entre une pluralité d'acteurs d'une structure. Des architectures dites réparties comme Corba (Common Object Request Broker Architecture) utilisent ce type de bus applicatif. Corba gère des aspects d'interopérabilité multi-langages et multiplateformes. Toutefois, Corba se contente d'assembler des composants logiciels mais ne permet pas de programmer complètement une logique métier (qui est le plus souvent une séquence de commandes envoyée à différentes applications, en particulier de bureautique, mais peut être beaucoup plus riche que du simple assemblage). De surcroit Corba offre des solutions assez lourdes à mettre en place du fait de la cible multi-langages et multiplateformes.
Les langages de processus métiers (généralement désignés sous la terminologie anglo-saxonne de business process) comme BPEL4WS (Business Process Execution Language for Web Services) ou XPDL (XML Process Définition Language) ou plus généralement les workflows ont été proposés pour automatiser un certain nombre de processus métiers complexes de l'entreprise. Ils proposent une description haut-niveau de ces processus à l'aide d'activités qui s'enchainent via des constructeurs comme la séquence, l'alternative, des opérations de synchronisation, etc. De façon plus pratique, le workflow décrit le circuit de validation, les tâches à accomplir entre les différents acteurs d'un processus, les délais, les modes de validation, et fournit à chacun des acteurs les informations nécessaires pour la réalisation de sa tâche. Il permet généralement un suivi et identifie les acteurs en précisant leur rôle et la manière de le remplir au mieux.
La description est de haut niveau et donc facilement compréhensible (même par des non-spécialistes) mais reste trop limitée dans les fonctionnalités.
Les solutions existantes se révèlent donc soit très lourdes à mettre en place, et donc peu intéressantes pour les entreprises qui recherchent en premier lieu la souplesse et l'agilité pour de tels outils, soit relativement limitées, et donc insuffisantes à moyen terme.
En outre, aucune n'a de manière générale cherché à tirer parti du parallélisme. En effet, l'informatique actuelle touche aux limites de ses possibilités, et l'augmentation de performance des processeurs ne passe plus par une gravure plus fine, mais par une multiplication du nombre de coeurs. Face à ces nouvelles architectures, l'informatique actuelle reste en retrait, car il est nécessaire de repenser de nombreux paradigmes de programmation.
Il y a un besoin de plateformes de développement de systèmes experts, adaptées au traitement massivement parallèle desquelles, puisse découler un gain sensible de productivité et de qualité.
PRESENTATION DE L'INVENTION La présente invention vise à résoudre ces difficultés en proposant un procédé de traitement massivement parallèle autour d'un bus applicatif.
Grâce à ces nouvelles possibilités offertes par ce bus applicatif, le développement de systèmes s'affranchit des contraintes techniques nouvelles engendrées par la programmation de processus parallélisés, lesquels s'avéreront d'ici peu incontournables au vu de l'évolution actuelle des processeurs. En outre, maîtriser l'exécution parallèle d'une pluralité de tâches n'est pas simple. En effet il est nécessaire de prévoir comment les ressources matérielles du ou des processeurs vont être exploitées par telle ou telle tâche. Le procédé selon l'invention permet de s'affranchir de cette difficulté grâce à un mécanisme d'auto-apprentissage astucieux qui ne nécessite pas la moindre intervention d'un spécialiste. L'efficacité du traitement parallèle est poussée au maximum.
De plus ce mécanisme introduit des contrôles de bon déroulement de l'exécution qui améliorent d'autant la qualité.
La présente invention se rapporte donc d'après un premier aspect à un procédé d'exécution parallèle d'une pluralité de tâches ordonnées selon une table d'ordonnancement, exécutées par au moins une unité de traitement de données connectée à un bus applicatif, à chaque tâche étant associé un coefficient de durée estimatif du temps de réalisation de ladite tâche, caractérisé en ce qu'un compte-rendu est fourni par le bus applicatif lors de l'exécution d'au moins une tâche, le coefficient de durée estimatif du temps de réalisation de ladite tâche étant mis à jour en fonction contenu dudit compte-rendu. Selon d'autres caractéristiques avantageuses et non limitatives de l'invention :
• le compte-rendu fourni par le bus applicatif lors de l'exécution d'au moins une tâche comprend une information logique de bon déroulement ou non de ladite tâche, et une information temporelle de durée réelle de réalisation de ladite tâche ;
• un compte-rendu est fourni pour toute tâche ayant au moins une contrainte d'ordonnancement ;
• la pluralité de tâches ordonnées selon la table d'ordonnancement est obtenue à partir d'un processus en mettant en œuvre les étapes suivantes :
- écriture du processus sous la forme d'un automate ;
- détermination d'un enchaînement de tâches qui permet la résolution de l'automate, chaque tâche étant une action élémentaire exécutable par une unité de traitement donnée à laquelle ledit bus applicatif est connecté ;
- identification, pour chacune desdites tâches, d'éventuelles contraintes de dépendance vis-à-vis des autres tâches ;
- génération de la table d'ordonnancement des tâches en fonction des éventuelles contraintes de dépendance identifiées.
• la pluralité de tâches ordonnées selon la table d'ordonnancement est exécutée par cycles, une pluralité de tâches compatibles étant lancées de façon synchronisée à chaque cycle.
• la synchronisation des tâches s'effectue en minimisant le temps total d'exécution à partir des coefficients de durée associés aux tâches exécutables. Selon un deuxième aspect, l'invention concerne un système comprenant au moins, une unité de traitement de données mettant en œuvre le procédé selon le premier aspect de l'invention, une mémoire dans laquelle sont stockés lesdits coefficients de durée estimatifs du temps de réalisation de la pluralité de tâches, et une entrée recevant la pluralité de tâches ordonnées selon une table d'ordonnancement à exécuter.
PRESENTATION DES FIGURES
D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels :
- la figure 1 est un schéma d'une architecture du bus applicatif utilisé dans un mode de réalisation d'un procédé d'exécution parallèle selon l'invention ; - la figure 2 est un schéma d'une architecture du bus applicatif connecté à une station et un partenaire dans un mode de réalisation d'un procédé d'exécution parallèle selon l'invention ;
- la figure 3 est un diagramme représentant les étapes d'un mode de réalisation d'un procédé d'exécution parallèle selon l'invention ;
- la figure 4 est un schéma de l'architecture d'un interpréteur utilisé dans un mode de réalisation d'un procédé d'exécution parallèle selon l'invention ;
- la figure 5 est un diagramme représentant une tâche élémentaire exécutable de façon parallélisée par un procédé d'exécution parallèle selon l'invention ;
- la figure 6 est un schéma représentant une structure de plateforme pour un mode de réalisation d'un procédé d'exécution parallèle selon l'invention.
DESCRIPTION DETAILLEE D'UN MODE DE REALISATION Les automates parallèles L'idée principale du procédé selon l'invention est que tout processus métier dont la gestion, en particulier la synchronisation, pourrait être demandée au bus applicatif peut être parcellisé en un ensemble de petits « automates ». Il faut comprendre qu'un « automate » correspond à un ensemble de consignes rassemblant le savoir-faire nécessaire à la réalisation d'un processus. En d'autres termes, en lisant l'automate via un programme appelé un interpréteur, on passe d'état en état jusqu'à avoir réalisé le processus.
Le mot « automate » ici n'a pas le sens qu'il a en théorie des graphes, en l'occurrence un ensemble d'états et de transitions. Il s'agirait plutôt d'un « mot » du langage reconnu par un FSA (automate à états finis), lequel serait plutôt représenté par l'interpréteur. L'intérêt d'un interpréteur par rapport à un compilateur réside dans sa capacité à exécuter immédiatement un automate qui lui-même peut faire appel à d'autres automates, voire en écrire dynamiquement et les faire fonctionner.
Prenons pour exemple un automate qui serait destiné à aider à la rédaction d'un courrier de réponse à une demande de prospect.
• Il faut tout d'abord proposer au rédacteur (la personne pour laquelle l'automate agit) la liste des modèles de courriers de réponse à une demande, qu'il fasse un choix, que l'automate prépare le travail et lui présente pour contrôle final.
• Il faut faire appel à une activité de lecture des titres des courriers disponibles à cette fin.
• Il faut demander au rédacteur de choisir dans cette liste le courrier qui va convenir.
• Il faut une activité permettant au rédacteur d'aller dans la base de données des prospects pour l'identifier. Ce travail peut être fait en parallèle avec le précédent suivant un ordre sans importance. L'automate attend d'être en possession des mémoires fournissant l'adresse du prospect et le courrier à élaborer. Il peut alors fusionner ces mémoires pour obtenir le document désiré.
• Ce document est présenté au rédacteur via une nouvelle activité : le traitement de texte. Il y est contrôlé par le rédacteur et éventuellement corrigé.
• Une nouvelle mémoire recueille le document produit et le compare à la mémoire de préparation de façon à en extraire les modifications à apporter éventuellement dans la base de données (rectification d'adresse par exemple) voire à réaliser la saisie d'un nouveau prospect à partir du prélèvement de son adresse et de son nom dans le courrier. Ce travail peut être fait parallèlement à la réédition du premier point pour un nouveau courrier. Ce processus, décrit ici en langue française, est le cahier d'analyse qui va être écrit en langage informatique pour le mettre à portée du système qui va l'exécuter.
Avantageusement, une véritable interface homme-machine permet à un automaticien (le spécialiste métier qui cherche à automatiser ses processus) de décrire facilement voire graphiquement son processus à l'aide d'outils élaborant mémoires et activités à volonté. Un automate peut lui-même devenir une nouvelle activité disponible dans la palette des outils. L'homme du métier saura adapter l'invention à toute interface homme- machine de son choix, des interfaces extrêmement ergonomiques étant connues.
Il reste que le pivot de la plateforme de l'automaticien est le langage dont la connaissance de la syntaxe permet à l'automaticien d'intervenir directement.
L'homme du métier saura également utiliser le langage de son choix, mais avantageusement un langage très simple décrit en une seule ligne la progression d'un processus élémentaire, d'un émetteur (ou encore serveur) vers un destinataire (ou encore récepteur). L'émetteur va produire une information pour le destinataire et au passage lui appliquer une valeur ajoutée (le traitement). Ceci se fait à l'aide de consignes éventuelles et la réception par le destinataire est accompagnée d'un compte-rendu du travail effectué afin de pouvoir éventuellement décider de la suite du processus. Ces briques élémentaires (cf. figure 5) sont enchaînées pour former le processus général, l'automate.
Architecture générale
En référence à la figure 1 , le procédé d'exécution parallèle selon l'invention se fait via un bus applicatif . A l'instar des ESB (bus de services d'entreprise), ce bus a avant tout pour fonction de permettre la communication des applications qui à la base ne sont pas pensées pour fonctionner ensemble. Ce bus fonctionne par exemple sous protocole standard (TCP/IP, ...) avantageusement via des ports facilement admis par les pare-feu, serveurs de domaines et passerelles classiques, sous procédure hautement sécurisée. Ceci forme le canal 2 d'échange du bus. Avantageusement, les données circulant dans le bus 1 sont cryptées. Il est connecté à au moins une unité de traitement de données (éventuellement à distance), cette unité assurant son fonctionnement.
Des applications récentes et/ou adaptées à un bus applicatif 1 peuvent communiquer avec lui en direct au niveau d'un terminal de bus.
Les anciennes applications qui ne connaissent pas ce bus 1 sont avantageusement prises en charge par des interfaces 3 spécifiques de chacune de ces applications, chargées de leur offrir l'adaptation spécifique leur permettant d'intégrer un terminal de bus (TB) : les CIA (communication interactive par automate). Un CIA est une sorte de pilote d'accueil disposant des ressources nécessaires aux applications connectées aux terminaux de bus.
Les unes comme les autres de ces applications peuvent soit être gérées par l'unité de traitement qui gère le bus applicatif 1 , mais peuvent aussi bien être gérées par d'autres unités de traitement auxquelles le bus est connecté. Une configuration avantageuse comprend ainsi une machine dite « Station », sur laquelle un utilisateur intervient, et une machine « Partenaire >> sur laquelle le bus applicatif est géré. Cette architecture est représentée sur la figure 2. Le composant ISP est une « Interface Station Partenaire ». Il fait le lien entre l'utilisateur de la station (via des IHM en tout genre comme des boites de dialogue, et le bus applicatif 1 dont l'unité de traitement est sur le partenaire. L'interpréteur, décrit précédemment, est le programme qui permet la lecture des automates. Les différents composants TB sont les terminaux de bus à travers lesquels une pluralité de tâches seront lancées vers les applications, exécutées sur la station comme sur le partenaire. Le multiplexage/démultiplexage permet de faire circuler en parallèle sur le canal 2 des données destinées à des applications ou des utilisateurs différents. Pour faire fonctionner ce bus applicatif 1 , on commence par l'alimenter avec un ou plusieurs automates 4, accompagnés de règles de liaison et de fonctionnement. Etapes du procédé
La première étape lors de l'exécution d'un processus métier est donc comme l'on voit sur la figure 3 une étape 100 d'écriture de ce processus sous la forme d'un automate, soit manuellement de toutes pièces par l'automaticien, soit à partir d'autres automates déjà connus. Dans le cas manuel, l'utilisateur travaille avantageusement sur une station de travail comportant une interface homme-machine, qui lui permet de manipuler intuitivement les automates comme expliqué précédemment, et fait le lien avec le bus applicatif 1 . Ces automates sont stockés sous un nom unique pour utilisation ultérieure. En effet, l'utilisateur n'est bien entendu pas obligé de développer un nouveau processus à chaque fois, et peut réutiliser un automate déjà écrit. Dans un cas comme dans l'autre, la commande d'exécution est envoyée au bus via l'ISP, et d'éventuelles tâches nécessitant l'intervention de l'utilisateur lors de l'exécution (une saisie...) repasseront vers l'ISP. Il ne faut toutefois pas confondre les IHM de l'ISP, qui sont divers menus et boites de dialogue, avec ΙΗΜ de développement qui permet de créer un automate.
L'automate est alors traité par l'interpréteur au cours d'une étape 200. Il faut noter que même si l'automate a été réalisé sur une station de travail par un utilisateur, des unités de traitement autres que celle (ou celles) de cette station de travail peuvent réaliser ce traitement. En effet, comme expliqué précédemment le bus applicatif interconnecte d'éventuelles machines partenaires et stations concernées, et l'interpréteur utilise nativement le bus applicatif.
Dans l'un ou l'autre de ces cas, l'étape 200 commence par une sous- étape 210 d'analyse syntaxique effectuée par un module nommé l'analyseur 5 durant laquelle l'automate est tout d'abord résolu en une table représentant les tâches à réaliser (avantageusement une par ligne) a priori parallèles mais dont certaines ont des contraintes. Ainsi un client qui devient service plus loin devra attendre d'être servi avant de pouvoir lui- même servir un autre client. C'est l'analyse de l'automate. Chaque tâche est une action élémentaire exécutable par une unité de traitement donnée à laquelle le bus applicatif est connecté. Les tâches seront décrites plus en détail plus loin dans cette description. Durant cette analyse, la syntaxe de chaque ligne est simplement vérifiée. Les réservations des tables de mémoire sont effectuées.
Dans une étape optionnelle 220, les tables de tâches et leurs descripteurs associés sont « chargées >> par l'analyseur 5, ce qui consiste en la mise à disposition d'un moteur d'exécution (un runtime, en terminologie anglo-saxonne), compressé, en lieu et place de l'automate. Les performances en sont d'autant améliorées, et surtout cela permet une grande souplesse si l'ordonnancement évolue en cours d'exécution du processus, comme il sera expliqué plus loin. La figure 4 montre cette séparation en deux blocs, le premier étant le bloc de l'analyseur 5, fonctionnant sur les automates, et le bloc en run-time.
Le DSP 6 (Découpeur en séquences parallélisées) est un autre module qui effectue la sous-étape suivante 230. C'est la première étape du second bloc de traitement, en run-time. Le DSP 6 rassemble les séquences monolithiques éventuelles (pour alléger le travail d'ordonnancement du bus) et prépare les descriptifs d'ordonnancement qu'il soumet au bus, puis lance une tâche spécialisée de sa bibliothèque comportant la mise en place d'un sémaphore qui permettra l'ordonnancement et les méthodes de transferts de fichiers, commandes CIA, etc. Les consignes associées se présenteront comme des commandes particulières internes au terminal de bus qui pilote une éventuelle CIA. Par exemple une demande de lecture de fichier est universelle mais n'est pas réalisée de la même façon via le CIA d'un traitement de texte ou le CIA d'un tableur. Les sémaphores identifient, pour chacune des tâches, d'éventuelles contraintes de dépendance, c'est-à-dire la nécessité que d'autres tâches soient exécutées préalablement. Il s'agit de lister les antécédents de chaque tâche. Le travail qui consiste à trouver une logique d'enchaînement qui respecte ces contraintes est l'ordonnancement. Les tâches qui n'ont pas de telles contraintes n'ont pas de sémaphore bloquant et se terminent hors contrôle du bus applicatif. Toutes les autres sont ordonnancées grâce à leur sémaphore qui permet de les débloquer à l'instant voulu et d'en connaître la terminaison.
En se basant sur la méthode PERT (« project évaluation and review technique », signifiant en français « technique d'évaluation et d'examen de projets »), une méthode de planification et d'ordonnancement découlant de la théorie des graphes, le DSP 6 génère lors d'une quatrième sous-partie 240 une table d'ordonnancement (TO) pour chaque tâche en fonction des éventuelles contraintes de dépendance identifiées. Ces tables donnent, en particulier, les instants optimaux de déclenchement des tâches. En effet, en théorie, pour une grande partie, ces tâches peuvent être exécutées simultanément. Sur des processus comprenant des milliers de tâches, le gain de temps peut être colossal. Le procédé selon l'invention exploite au maximum les capacités de parallélisation massive de l'informatique actuelle et permet grâce aux tables d'ordonnancement de traiter le plus possible de tâches différentes en même temps tout en respectant les contraintes de dépendance.
Le DSP 6 fournit chaque table d'ordonnancement au reste du bus applicatif 1 . L'ensemble des sémaphores est géré directement dans le canal 2. Ces sémaphores peuvent être soit bloqués soit passant lors du lancement des tâches. Un module appelé l'exécuteur 7 soumet la tâche au scheduling du système, c'est-à-dire le travail à faire pour organiser l'utilisation des ressources de la machine (disque, mémoire, unité centrale, etc.) par les applications qui lui sont confiées.
Le scheduling se réalise normalement et sans aucune intervention même au niveau du threading (mot d'origine anglaise signifiant enfilage, correspondant à une manière de gérer l'exécution d'un ensemble d'instructions en langage machine au niveau processeur) qui est du ressort du système d'exploitation hôte. Ce threading éventuel est réalisé par les méthodes de la bibliothèque de la plateforme et n'est donc pas vu de l'analyste automaticien.
De même l'automaticien n'a pas à se soucier de l'ordonnancement automatiquement mis en place par le découpeur et réalisé par le bus applicatif 1 .
Ce dernier fait finalement l'acquisition en temps quasi réel des tables d'ordonnancement de chaque tâche pour élaborer et gérer une table générale d'ordonnancement.
L'étape 300 consiste en l'exécution à proprement parler des tâches par la ou les unités de traitement connectées au bus applicatif en respectant l'ordre imposé par la table générale d'ordonnancement du BA.
Les tâches sont soit libres dans leur fonctionnement et au niveau de leurs instants d'exécution, soit avantageusement encadrées par une description des synchronisations à effectuer. Ces synchronisations sont tout simplement des processus vides reliant entre eux des automates parallélisés. Ainsi, les tâches sont exécutées par cycles, une pluralité de tâches compatibles étant lancées de façon synchronisée à chaque cycle. Une telle gestion facilite le contrôle du bon déroulement du processus.
On peut également noter que les différents modules utilisés, à savoir l'analyseur 5, le DSP 6 et l'exécuteur 7 fonctionnent eux-mêmes en parallèle.
Les tâches
Chaque ligne du code qui compose l'automate constitue avantageusement une tâche élémentaire, comme expliqué précédemment. Une ligne se décompose en diverses parties standardisées qui permettent de spécifier un destinataire (la sortie) et son traitement préalable, un émetteur (l'entrée) et ses consignes de traitement. On peut la représenter de manière graphique (voir figure 5). Chaque destinataire et chaque émetteur est un pointeur qui référencie toute sorte d'objet en mémoire accessibles de façon partagée. La difficulté due au parallélisme des tâches est que chaque tâche va lire des données, appliquer un traitement et rendre des données. On comprend que la sortie d'une tâche peut devenir l'entrée d'une autre. Ainsi, si les deux tâches se déroulent en parallèle il est nécessaire d'attendre que les données soient traitées par la première avant d'être lues par la seconde :
Objet initial T1 Objet modifié T2 Objet remodifié
Il est donc très avantageux d'avoir l'état de l'objet dans une table à accès parallèle (mécanisme IPC, « communication inter processus ») ou accès par guichet (un pointeur multi-accès vers la tâche), et une description des modifications à effectuer par la tâche.
On peut donc systématiquement créer les objets (dans la mémoire) avec des valeurs par défaut correspondant à leur nature, mais l'on peut également créer pour chaque tâche une table de destinataires et une autre d'émetteurs avec des valeurs par défaut correspondant aux traitements par défaut.
L'automate comporte avantageusement des blocs de traitement facilement identifiables par des étiquettes. Ainsi on peut découper de façon plus optimisée que le brutal "ligne à ligne" en demandant à une tâche élémentaire de réaliser plusieurs lignes. Il suffit de lui passer une sous-table de couples destinataire / émetteur à exécuter séquentiellement. On simplifie par là-même le travail du bus applicatif et on optimise beaucoup l'ensemble. Le DSP a alors également la charge d'exploitation des blocs et de réalisation du suivi de leurs séquences. Comptes-rendus et Apprentissage
Le bus possède par ailleurs son propre système d'évaluation de ses performances. Outre l'objectif de qualité il permet un ordonnancement prédictif capable d'apprentissage.
Un coefficient de durée estimatif du temps de réalisation peut être associé à chaque tâche. Ce coefficient est une durée prévisionnelle, fournie au DSP 6 et utilisé pour la génération des tables d'ordonnancement via la méthode PERT. Toutefois, plutôt qu'une valeur précise en unité de temps, c'est un chiffre proportionnel à la quantité d'information traitée et dépendant du type de traitement. On remarquera par exemple qu'un traitement en mémoire vive est très rapide alors qu'un traitement nécessitant des accès disques est bien plus long. De même, on constate qu'il y a plusieurs ordres de grandeur entre les temps nécessités par une saisie humaine (quelques secondes) et une saisie par automate (quelques microsecondes). Ce chiffre n'aura donc pas besoin d'une précision extrême car il sera essentiellement destiné à l'opération d'ordonnancement automatisé. Il n'y aura pas lieu le plus souvent de préciser ce coefficient qui sera automatiquement évalué. On peut en effet classer en cinq grandes catégories les temps de traitement :
- en registres et en cache (très rapide)
- en RAM (rapide)
- nécessitant des accès disque
- Nécessitant des accès réseau
- Nécessitant une activité humaine (IHM).
Lors de son ordonnancement des tâches, le bus applicatif sera ainsi en mesure de planifier rapidement ses ressources et de mettre en place les mécanismes de synchronisation de toute façon nécessaires pour palier à toute éventualité.
Comme l'on voit sur la figure 5, un compte-rendu (CR) est émis une fois la tâche accomplie, au cours d'une étape 400 (voir figure 3). Ce compte-rendu, fourni également par le bus applicatif 1 , peut ne concerner que certaines tâches, mais avantageusement est fourni pour toute tâche ayant au moins une contrainte d'ordonnancement, voire pour toutes les tâches.
Ce compte-rendu permet en effet tout d'abord de contrôler le bon déroulement du processus, mais il permet surtout un feed-back. Un module optionnel, lui-même exécuté en parallèle, récupère de façon préférentielle ces données pour mettre à jour les coefficients de durée estimatifs des nouvelles tables en acquisition.
Pour cela le compte-rendu comprend avantageusement au moins deux informations : une information logique de bon déroulement ou non de la tâche, par exemple une variable booléenne, et une information temporelle de durée réelle de réalisation de ladite tâche. Grâce à l'information logique, le bus applicatif 1 s'assure soit de la terminaison de la tâche et donc d'un enchaînement correct des tâches dépendantes, soit de sa poursuite. Une table de décisions permet de traiter les cas programmés suivant le code de terminaison de chaque tâche. Grâce à l'information temporelle, la durée réelle est comparée avec la durée estimative, et cette dernière est ainsi corrigée si nécessaire. La boucle de feed-back est particulièrement visible sur la figure 4 : en cas de correction, l'ordonnancement est réeffectué. Si avantageusement le bloc DSP-exécuteur est en run-time, il n'y a pas besoin de revenir à l'automate, les tables et les descripteurs de chacune des tâches étant déjà chargées. Le réordonnancement se fait ainsi très rapidement.
Un tableau de bord est tenu en temps quasi réel ainsi que des indicateurs d'alerte en cas d'anomalie réseau.
Exemple de communication par le bus applicatif Voici un exemple d'une utilisation du bus dans le cas de la figure 2 d'une station et d'une machine partenaire. Les flèches désignent l'enchaînement des actions dans la table 1 , certaines sont simultanées. Station Partenaire
ISP actif : Demande d'un service Initialisation, j
Active IHM j Propose un menu
Remplissage guide par usager J, Stockage pour réemploi futur éventuel J, Désactive IHM. Choix du CIA adapté, J,
Activation CIA + application J, Envoi des consignes de montage Montage de l'original ; stock local. Stockage pour réemploi futur éventuel J, Insertion des variables J, Fourniture des variables
Modifications usager ; stock local. Stockage pour réemploi futur éventuel J, Réactivation CIA. +application J, Envoi consignes démontage
Démontage/comparaison stocks. M. à ). memdos ; m. à j. hors standard ;
î 1 î 11 î 1 î 1 î Stockage compte rendu CIA J,
Ferme appli +Désactivation CIA. Fin service
Table 1 La demande de service implique que l'ISP soit actif. L'activation IHM signifie l'activation d'une boîte de dialogue chargée des échanges concernant le lancement de la phase du processus métier concernée.
Le guide rempli est retourné au partenaire qui le stocke pendant que l'ISP termine ΙΊΗΜ (bordereau par exemple). Le partenaire demande ensuite à l'ISP d'activer un CIA adapté au traitement qui va suivre ainsi que l'application bureautique visée. Il envoie les consignes de montage qui comportent :
1 ) les clauses à monter, c'est-à-dire l'ensemble des données prédéfinies pour l'objet en cours de réalisation, un modèle (par exemple, s'il s'agit d'un contrat, cela correspondra à un texte de base avec des trous aux endroits où il faudra rajouter les noms des sociétés, la date, les noms des participants...). Les clauses peuvent être standard, ou hors standard si des modifications forcées ont été faites (modifications du modèle) et stockées ;
2) Les variables existantes dans la mémoire dossier
(« memdos >>) ; 3) Des actions connexes pour demander au CIA de s'acquitter d'une série de tâches simples standardisées.
Systèmes
L'invention propose selon un deuxième aspect des systèmes pouvant mettre en œuvre un procédé selon le premier aspect de l'invention.
La première fonctionnalité demandée au bus applicatif est d'assurer l'acheminement de toutes les données entre tous les acteurs de toutes les configurations interconnectées.
Tous les acteurs peuvent être rassemblés dans une seule station, l'unité de traitement du bus applicatif étant celle de la station. Dans ce cas là, le système selon l'invention comprend la station de travail, celle-ci comprenant tout d'abord des moyens d'affichage de données et des moyens de saisie de données. Il peut s'agir classiquement d'un écran et d'un clavier avec une souris. Ce matériel sert tout simplement à mettre en œuvre une ou plusieurs interfaces homme-machine permettant à un utilisateur de composer ses automates ou d'en utiliser, et d'interagir avec l'ISP. Le système selon l'invention comprend alors également une unité de traitement de données, qui est l'unité reliée au bus applicatif, et une mémoire. Pour que le système ait un intérêt, l'unité de traitement doit être de préférence un processeur multicoeur, c'est-à-dire un processeur qui pourra tirer parti de l'exécution parallèle.
Alternativement le système selon l'invention peut ne pas se contenter d'une seule station de travail, mais comprendre comme expliqué précédemment au moins une machine partenaire. Il peut en outre y avoir plusieurs stations de travail contrôlées par des utilisateurs, les différentes stations ayant chacune une unité de traitement et utilisant les mêmes machines partenaires autour d'un bus applicatif unique, comme l'on voit sur la figure 6.
Le bus applicatif sert de Multiples Stations (usagers) et de Multiples Partenaires (automates) en configuration dite MSMP. Il fonctionne en diverses configurations dites « dégradées » Simple/Multiple Station/Partenaire SSSP, SSMP, MSSP et MSMP. Enfin, le bus applicatif est capable dans toute la mesure du possible de prendre en charge les liaisons du type temps réel nécessaires à certains dispositifs (périphériques, commande de chaînes de production, ...). Il offre ainsi une passerelle entre le monde industriel et le monde du bureau par exemple pour obtenir un tableau temps réel de la production.
Le bus utilise la connectique et les supports physiques existants entre les machines de types habituellement utilisés (serveur de fichiers, serveur Web, Serveur d'applications, etc.). En particulier, deux ports TCP/IP peuvent lui être réservés (12 et 14 ou 3012 et 3014) pour ses communications à débit maximum et optimisé. Les communications sont multiplexées et chaque segment possède une priorité. Les messages de synchronisation des tâches sont les plus prioritaires ainsi que les éventuelles liaisons temps réel.
Les opérations d'ordonnancement du bus applicatif peuvent être dans ce cas traitées par un calculateur, idéalement vectoriel, qui est une unité de traitement de l'une des machines partenaires, qui peut être dédié. Sur de moyennes configurations, une carte graphique située sur un partenaire est utilisée comme GPGPU (General-Purpose computation on Graphics Processing Units). En effet une carte graphique est un calculateur vectoriel complet.
Etant a priori réparti, le bus applicatif fonctionne préférentiellement dans un cadre sécurisé. Le multiplexeur/démultiplexeur est donc muni d'une solide fonction de cryptage. Le système utilisé est un cryptage par clefs aléatoires de longueurs variables et rafraîchies automatiquement. Ainsi toute attaque est déjouée par un changement de clef en un temps plus court que celui demandé par la recherche de clef. Il y a une clef par port et par sens de transmission. La transmission de la nouvelle clef aléatoirement calculée est elle-même sécurisée par la clef précédente. Ainsi, même si la clef initiale (utilisée une unique fois lors du login) est connue, il ne peut être question de pénétrer la suite des échanges. La solidité de l'ensemble est soumise à un objectif de qualité qui fait que le bus applicatif réalise de façon particulièrement avantageuse un traçage de ses opérations et des transactions. Ce traçage n'est bien entendu pas prioritaire et n'impacte pas les performances de l'ensemble. Il est traité comme une acquisition de données stockées en cache puis sauvegardées dans les temps de plus faible priorité. Un outil annexe peut permettre d'exploiter ces données à la demande et à loisir pour y rechercher l'historique de tout événement ou en extraire toute statistique utile, ou encore permettre le réglage plus précis des paramètres du bus applicatif de façon à en optimiser le fonctionnement pour une configuration donnée.
L'invention apporte donc une architecture parfaite pour être mis dans les mains d'un expert dans son métier sans avoir besoin d'être assisté d'un informaticien. Ses interfaces homme-machine associées permettent d'une part de décrire une scène, les acteurs dans la scène et les actions menées dans le cadre d'un processus métier, et d'autre part de conserver un savoir- faire pour le mettre à disposition de tous, d'ordonnancer l'ensemble des tâches qui le constituent, et surtout de paralléliser automatiquement sans effort
Ses fonctions d'apprentissage lui assurent une évolutivité et la garantie d'amélioration constante de ses performances, et ce sans qu'un utilisateur ait à intervenir.
Il rend les services de sécurisation des échanges, de traduction des langages, d'acheminement des données et des fichiers et de compte rendu du fonctionnement. Il sait dialoguer et piloter des applications hétérogènes intégrées au processus métier, et en particulier les applications bureautiques.
Next Patent: COMPOSITION