WO2012013504A1 - Procédé d'exécution parallèle d'une pluralité de tâches ordonnées selon une table d'ordonnancement - Google Patents

Procédé d'exécution parallèle d'une pluralité de tâches ordonnées selon une table d'ordonnancement Download PDF

Info

Publication number
WO2012013504A1
WO2012013504A1 PCT/EP2011/062004 EP2011062004W WO2012013504A1 WO 2012013504 A1 WO2012013504 A1 WO 2012013504A1 EP 2011062004 W EP2011062004 W EP 2011062004W WO 2012013504 A1 WO2012013504 A1 WO 2012013504A1
Authority
WO
WIPO (PCT)
Prior art keywords
tasks
task
application bus
bus
report
Prior art date
Application number
PCT/EP2011/062004
Other languages
English (en)
Inventor
Yves Albrieux
Original Assignee
Tymis
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tymis filed Critical Tymis
Priority to EP11735635.2A priority Critical patent/EP2599046A1/fr
Publication of WO2012013504A1 publication Critical patent/WO2012013504A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time

Definitions

  • the present invention relates to the field of development platforms and implementation of expert systems.
  • Scripting languages like TCL (Tool Command Language) or more recently web-based languages such as perl or python, are multiplatform, extensible languages, easy to learn. They are defined as languages dedicated to "programming in the large", that is to say large-scale projects. Their goal is to provide the binder that will allow existing executables to be chained into more complex processing chains, and thus automations. However, if a scripting language proves very practical in the case of the execution of a sequence of applications on a machine, it is not really adapted to a collaborative operation in a company, where many machines are connected to a network, some machines being dedicated to certain applications or certain functionalities.
  • TCL Tool Command Language
  • perl or python are multiplatform, extensible languages, easy to learn. They are defined as languages dedicated to "programming in the large", that is to say large-scale projects. Their goal is to provide the binder that will allow existing executables to be chained into more complex processing chains, and thus automations.
  • a scripting language
  • Corba Software connection components called application buses (BA), or software buses, make it possible to exchange messages and data between a plurality of actors of a structure.
  • Distributed architectures such as Common Object Request Broker Architecture (Corba) use this type of application bus.
  • Corba manages multi-language and multi-platform interoperability aspects.
  • Corba is content to assemble software components but does not fully program business logic (which is most often a sequence of commands sent to different applications, especially office automation, but can be much richer than the simple assembly).
  • Corba offers solutions that are quite burdensome to set up because of the multi-language and multiplatform target.
  • BPPL Business process languages
  • BPEL4WS Business Process Execution Language for Web Services
  • XPDL XML Process Definition Language
  • workflows have been proposed to automate a number of business processes. complex business processes of the company. They provide a high-level description of these processes using activities that follow each other via constructors such as the sequence, the alternative, synchronization operations, and so on.
  • the workflow describes the validation circuit, the tasks to be performed between the different actors of a process, the deadlines, the modes of validation, and provides each of the actors with the information they need to carry out their task. It generally allows monitoring and identifies actors by specifying their role and how to best fulfill it.
  • the present invention aims to solve these difficulties by proposing a massively parallel processing method around an application bus.
  • the present invention thus relates, according to a first aspect, to a method of parallel execution of a plurality of tasks ordered according to a scheduling table, executed by at least one data processing unit connected to an application bus, to each task being associated with an estimated duration coefficient of the time of completion of said task, characterized in that a report is provided by the application bus when performing at least one task, the estimated duration coefficient of the task time of completion of said task being updated as a function of said report.
  • the report provided by the application bus during the execution of at least one task comprises logical information of whether or not the task is performed correctly, and time information of the actual duration of completion of said task;
  • the plurality of tasks ordered according to the scheduling table is obtained from a process by implementing the following steps:
  • the plurality of tasks ordered according to the scheduling table is executed in cycles, a plurality of compatible tasks being started in synchronism with each cycle.
  • the invention relates to a system comprising at least one data processing unit implementing the method according to the first aspect of the invention, a memory in which are stored said estimated duration coefficients of the realization time. of the plurality of tasks, and an input receiving the plurality of ordered tasks according to a scheduling table to be executed.
  • FIG. 1 is a diagram of an architecture of the application bus used in an embodiment of a parallel execution method according to the invention
  • FIG. 2 is a diagram of an architecture of the application bus connected to a station and a partner in an embodiment of a parallel execution method according to the invention
  • FIG. 3 is a diagram representing the steps of an embodiment of a parallel execution method according to the invention.
  • FIG. 4 is a diagram of the architecture of an interpreter used in one embodiment of a parallel execution method according to the invention.
  • FIG. 5 is a diagram representing an elementary task executable in a parallel manner by a parallel execution method according to the invention.
  • FIG. 6 is a diagram showing a platform structure for an embodiment of a parallel execution method according to the invention.
  • automata corresponds to a set of instructions gathering the know-how necessary to carry out a process. In other words, by reading the PLC via a program called an interpreter, one goes from state to state until having realized the process.
  • a new memory collects the document produced and compares it with the preparation memory so as to extract any changes to be made in the database (address correction for example) or even to enter a new prospect at from the collection of his address and his name in the mail.
  • This work can be done in parallel with the republishing of the first point for a new mail.
  • This process described here in French, is the analysis book that will be written in computer language to bring it within reach of the system that will execute it.
  • a real man-machine interface allows an automation engineer (the specialist who seeks to automate its processes) to easily describe or even graphically its process using tools developing memories and activities at will.
  • a PLC can itself become a new activity available in the tool palette.
  • the parallel execution method according to the invention is done via an application bus.
  • this bus is primarily intended to allow communication applications that are basically not designed to work together.
  • This bus operates for example under standard protocol (TCP / IP, ...) advantageously via ports easily accepted by firewalls, domain servers and conventional gateways, under highly secure procedure.
  • TCP / IP standard protocol
  • the data flowing in the bus 1 are encrypted. It is connected to at least one data processing unit (possibly remote), this unit ensuring its operation.
  • Recent applications and / or adapted to an application bus 1 can communicate with him live at a bus terminal.
  • a CIA is a kind of host driver with the resources needed for applications connected to bus terminals.
  • Both of these applications can be managed by the processing unit that manages the application bus 1, but can also be managed by other processing units to which the bus is connected.
  • An advantageous configuration thus comprises a machine called “Station”, on which a user intervenes, and a machine “Partner” on which the application bus is managed.
  • This architecture is shown in Figure 2.
  • the ISP component is an "Interface Station Partner". It is the link between the user of the station (via HMIs of any kind as dialog boxes, and the application bus 1 whose processing unit is on the partner.)
  • the interpreter, described above, is the program.
  • the various TB components are the bus terminals through which a plurality of tasks will be launched to the applications, executed on the station as on the partner.
  • the multiplexing / demultiplexing allows to circulate in parallel on the terminal.
  • channel 2 data for different applications or users.
  • the first step during the execution of a business process is therefore as we see in FIG. 3 a step 100 of writing this process in the form of an automaton, either manually from scratch by the automation engineer , or from other known automata.
  • the user works advantageously on a workstation comprising a human-machine interface, which allows him to intuitively manipulate the automata as explained above, and makes the link with the application bus 1.
  • These controllers are stored under a unique name for later use. Indeed, the user is of course not obliged to develop a new process each time, and can reuse a PLC already written.
  • the execution command is sent to the bus via the ISP, and any tasks requiring the intervention of the user during execution (an entry ...) will return to the ISP.
  • do not confuse the GUI of the ISP which are various menus and dialog boxes, with ⁇ development that allows you to create a PLC.
  • the automaton is then processed by the interpreter during a step 200. It should be noted that even if the automaton was realized on a workstation by a user, processing units other than that (or those) of this workstation can perform this processing. Indeed, as explained above, the application bus interconnects any partner machines and stations concerned, and the interpreter uses the application bus natively.
  • step 200 begins with a substep 210 of parsing performed by a module named the parser 5 during which the automaton is first resolved into a table representing the tasks to be performed (advantageously one per line) a priori parallel but some of which have constraints. Thus a customer who becomes a service farther will have to wait to be served before he can serve another client himself.
  • This is the analysis of the automaton.
  • Each task is an elementary action executable by a given processing unit to which the application bus is connected. Tasks will be described in more detail later in this description. During this analysis, the syntax of each line is simply checked. The reservations of the memory tables are made.
  • step 220 the task tables and their associated descriptors are "loaded" by the analyzer 5, which consists in providing an execution engine (a runtime, in English terminology). , compressed, in place of the automaton.
  • an execution engine a runtime, in English terminology.
  • Figure 4 shows this separation in two blocks, the first being the block of the analyzer 5, operating on the automata, and the block in run-time.
  • the DSP 6 (split in parallel sequences) is another module that performs the next substep 230. This is the first step of the second processing block, in run-time.
  • the DSP 6 collects possible monolithic sequences (to lighten the bus scheduling work) and prepares the scheduling documents that it submits to the bus, then launches a specialized task from its library including the setting up of a semaphore which will allow scheduling and methods of file transfers, CIA commands, etc.
  • the associated instructions will be presented as special commands internal to the bus terminal which controls a possible CIA. For example, a file read request is universal but is not done in the same way via the CIA of a word processor or the CIA of a spreadsheet.
  • the semaphores identify, for each task, possible dependence constraints, that is to say the need for other tasks to be performed beforehand. This is to list the antecedents of each task.
  • the job of finding a flow logic that respects these constraints is scheduling. Tasks that do not have such constraints do not have a blocking semaphore and terminate outside the application bus control. All the others are scheduled thanks to their semaphore which allows to unlock them at the desired moment and to know the termination.
  • the DSP 6 Based on the PERT method ("project evaluation and review technique"), a planning and scheduling method derived from graph theory, the DSP 6 generates in a fourth sub-part 240 a scheduling table (TO) for each task as a function of any identified dependency constraints.
  • TO scheduling table
  • These tables give, in particular, the optimal moments of triggering tasks. In theory, for the most part, these tasks can be performed simultaneously. On processes with thousands of tasks, saving time can be huge.
  • the method according to the invention makes maximum use of the massive parallelization capabilities of current computing and makes it possible, thanks to the scheduling tables, to handle as many different tasks as possible at the same time while respecting the constraints of dependence.
  • the DSP 6 provides each scheduling table to the rest of the application bus 1.
  • the set of semaphores is managed directly in channel 2. These semaphores can be either blocked or passing when starting tasks.
  • a module called the executor 7 submits the task to the scheduling of the system, that is to say the work to be done to organize the use of the resources of the machine (disk, memory, CPU, etc.) by the applications. which are entrusted to him.
  • the scheduling is carried out normally and without any intervention even at the level of the threading (word of English origin meaning threading, corresponding to a way of managing the execution of a set of instructions in machine language at the processor level) which is the responsibility of the host operating system.
  • This possible threading is carried out by the methods of the library of the platform and is therefore not seen by the automation analyst.
  • the latter finally acquires the scheduling tables for each task in near real time to develop and manage a general scheduling table.
  • Step 300 consists of the actual execution of the tasks by the processing unit or units connected to the application bus in accordance with the order imposed by the general scheduling table of the BA.
  • the tasks are either free in their operation and at their execution times, or advantageously framed by a description of the synchronizations to be performed. These synchronizations are simply empty processes interconnecting parallelized automata. Thus, the tasks are executed in cycles, a plurality of compatible tasks being started synchronously at each cycle. Such management facilitates the control of the smooth running of the process.
  • Each line of the code that makes up the automaton advantageously constitutes an elementary task, as explained above.
  • a line breaks down into various standardized parts that specify a recipient (the output) and its pretreatment, a transmitter (the input) and its processing instructions. It can be represented graphically (see Figure 5).
  • Each recipient and each emitter is a pointer that references any sort of shared object in memory.
  • the difficulty due to the parallelism of the tasks is that each task will read data, apply a processing and render data. It is understandable that the output of one task can become the input of another. Thus, if the two tasks take place in parallel, it is necessary to wait for the data to be processed by the first before being read by the second:
  • the automaton advantageously comprises processing blocks easily identifiable by tags. Thus one can cut in a more optimized way than the brutal "line to line” by asking an elementary task to realize several lines. It suffices to pass a sub-table of recipient / sender pairs to be executed sequentially. This simplifies the work of the application bus and optimizes the whole lot.
  • the DSP then also has the responsibility of operating the blocks and performing the monitoring of their sequences. Reports and Learning
  • the bus also has its own performance evaluation system. In addition to the objective of quality it allows predictive scheduling capable of learning.
  • An estimated duration coefficient of the completion time may be associated with each task.
  • This coefficient is a predicted duration, supplied to the DSP 6 and used for the generation of the scheduling tables via the PERT method. However, rather than a precise value in unit of time, it is a number proportional to the amount of information processed and depending on the type of treatment. It will be noted for example that a processing in RAM is very fast while a treatment requiring disk access is much longer. Similarly, we can see that there are several orders of magnitude between the times required by a human input (a few seconds) and a PLC input (a few microseconds). This figure will therefore not need extreme precision because it will be mainly for the automated scheduling operation. It will not be necessary most often to specify this coefficient which will be automatically evaluated.
  • the treatment times can be divided into five main categories:
  • HMI human activity
  • the application bus When scheduling tasks, the application bus will be able to quickly plan its resources and set up the synchronization mechanisms anyway necessary to mitigate any eventuality.
  • a report is issued once the task has been completed, during a step 400 (see FIG. 3).
  • This report also provided by the application bus 1, may concern only certain tasks, but advantageously is provided for any task having at least one scheduling constraint, or even for all tasks.
  • This report allows first of all to control the smooth running of the process, but it allows above all a feedback.
  • An optional module itself executed in parallel, preferentially retrieves these data to update the estimated duration coefficients of the new tables in acquisition.
  • the report advantageously comprises at least two pieces of information: logical information about whether or not the task is running smoothly, for example a Boolean variable, and time information of actual duration of completion of said task.
  • the application bus 1 ensures either the termination of the task and therefore a correct sequence of dependent tasks, or its continuation.
  • a decision table is used to process the programmed cases according to the termination code of each task. Thanks to the temporal information, the actual duration is compared with the estimated duration, and the latter is thus corrected if necessary.
  • the feedback loop is particularly visible in Figure 4: in case of correction, the scheduling is re-performed. If the DSP-executor block is advantageously in run-time, there is no need to return to the PLC, the tables and descriptors of each task being already loaded. Reordering is done very quickly.
  • a dashboard is kept in near real time as well as warning indicators in the event of a network anomaly.
  • Example of communication via the application bus is an example of a bus use in the case of Figure 2 of a station and a partner machine.
  • the arrows indicate the sequence of actions in table 1, some are simultaneous.
  • Partner Station
  • Active HMI j Offers a menu
  • HMI activation means the activation of a dialog box responsible for the exchanges concerning the launch of the phase of the business process concerned.
  • the completed guide is returned to the partner who stores it while the ISP finishes ⁇ (slip for example).
  • the partner then asks the ISP to activate an adapted CIA for the following treatment as well as the intended office application. It sends the assembly instructions that include:
  • Clauses can be standard, or off-standard if forced changes have been made (model changes) and stored;
  • the invention proposes systems that can implement a method according to the first aspect of the invention.
  • the first functionality requested from the application bus is to ensure the routing of all data between all the actors of all the interconnected configurations.
  • the system according to the invention comprises the workstation, the latter comprising first of all data display means and data acquisition means. It can be classically a screen and a keyboard with a mouse. This hardware is simply used to implement one or more human-machine interfaces allowing a user to compose his PLCs or to use them, and to interact with the ISP.
  • the system according to the invention then also comprises a data processing unit, which is the unit connected to the application bus, and a memory.
  • the processing unit should preferably be a multicore processor, i.e., a processor that can take advantage of parallel execution.
  • system according to the invention may not be content with a single workstation, but understand as explained above at least one partner machine.
  • the application bus serves as multiple stations (users) and multiple partners (PLCs) in MSMP configuration. It works in various configurations called “degraded" Simple / Multiple Station / Partner SSSP, SSMP, MSSP and MSMP. Finally, the application bus is able, as far as possible, to support the links of the real-time type required for certain devices (peripherals, control of production lines, etc.). It thus provides a bridge between the industrial world and the office world for example to obtain a real-time picture of the production.
  • the bus uses the connections and the existing physical media between the usual types of machines (file server, web server, application server, etc.).
  • two TCP / IP ports can be reserved for it (12 and 14 or 3012 and 3014) for its maximum throughput and optimized communications.
  • the communications are multiplexed and each segment has a priority.
  • the task synchronization messages are the highest priorities as well as any real-time links.
  • the scheduling operations of the application bus can be processed by a calculator, ideally vector, which is a processing unit of one of the partner machines, which can be dedicated.
  • a graphics card located on a partner is used as GPGPU (General-Purpose Computation on Graphics Processing Units).
  • GPGPU General-Purpose Computation on Graphics Processing Units
  • the application bus preferably operates in a secure environment.
  • the multiplexer / demultiplexer is thus provided with a strong encryption function.
  • the system used is random key encryption of variable lengths and automatically refreshed. Thus any attack is thwarted by a key change in a shorter time than that requested by the key search.
  • the strength of the whole is subject to a quality objective that makes the application bus performs particularly advantageously a tracing of its operations and transactions.
  • This tracing is of course not a priority and does not impact the performance of the whole. It is treated as an acquisition of data stored in cache and then saved in times of lower priority. An ancillary tool can make it possible to use these data on demand and at leisure to search the history of any event or extract any useful statistics, or to allow more precise adjustment of the parameters of the application bus so as to optimize the operation for a given configuration.
  • the invention thus provides a perfect architecture to be put in the hands of an expert in his profession without needing to be assisted by a computer scientist. Its associated human-machine interfaces allow on the one hand to describe a scene, the actors in the scene and the actions carried out as part of a business process, and on the other hand to keep a know-how to make it available. of all, to schedule all the tasks that constitute it, and especially to parallelise automatically without effort

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Operations Research (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Multi Processors (AREA)

Abstract

La présente invention concerne 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 du contenu dudit compte-rendu. L'invention concerne également un système à cet effet.

Description

Titre : Procédé d'exécution parallèle d'une pluralité de tâches ordonnées selon une table d'ordonnancement
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.

Claims

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.
PCT/EP2011/062004 2010-07-26 2011-07-13 Procédé d'exécution parallèle d'une pluralité de tâches ordonnées selon une table d'ordonnancement WO2012013504A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP11735635.2A EP2599046A1 (fr) 2010-07-26 2011-07-13 Procédé d'exécution parallèle d'une pluralité de tâches ordonnées selon une table d'ordonnancement

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1056108A FR2963126B1 (fr) 2010-07-26 2010-07-26 Procede d'execution parallele d'une pluralite de taches ordonnees selon une table d'ordonnancement
FR1056108 2010-07-26

Publications (1)

Publication Number Publication Date
WO2012013504A1 true WO2012013504A1 (fr) 2012-02-02

Family

ID=43768974

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/062004 WO2012013504A1 (fr) 2010-07-26 2011-07-13 Procédé d'exécution parallèle d'une pluralité de tâches ordonnées selon une table d'ordonnancement

Country Status (3)

Country Link
EP (1) EP2599046A1 (fr)
FR (1) FR2963126B1 (fr)
WO (1) WO2012013504A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2986346A1 (fr) 2012-01-27 2013-08-02 Tymis Procede d'utilisation d'une memoire partagee
FR2986344B1 (fr) 2012-01-27 2015-05-22 Tymis Procede d'execution parallele d'une pluralite de taches informatiques

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006061630A2 (fr) * 2004-12-10 2006-06-15 British Telecommunications Public Limited Company Ordonnanceur de flux de travaux
US20070112610A1 (en) * 2005-11-15 2007-05-17 General Electric Company System and method for clinical process decisioning
US20090171706A1 (en) * 2007-12-28 2009-07-02 International Business Machines Corporation Computer pattern system environment supporting business resiliency

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006061630A2 (fr) * 2004-12-10 2006-06-15 British Telecommunications Public Limited Company Ordonnanceur de flux de travaux
US20070112610A1 (en) * 2005-11-15 2007-05-17 General Electric Company System and method for clinical process decisioning
US20090171706A1 (en) * 2007-12-28 2009-07-02 International Business Machines Corporation Computer pattern system environment supporting business resiliency

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"The BPMS Report: TIBCO iProcess Suite 10.6", July 2007 (2007-07-01), XP002630376, Retrieved from the Internet <URL:http://www.fr.tibco.com/multimedia/analyst-bruce-silver-reviews-tibco-bpms_tcm18-2376.pdf> [retrieved on 20110328] *
DANIEL F ET AL: "Business Compliance Governance in Service-Oriented Architectures", ADVANCED INFORMATION NETWORKING AND APPLICATIONS, 2009. AINA '09. INTERNATIONAL CONFERENCE ON, IEEE, PISCATAWAY, NJ, USA, 26 May 2009 (2009-05-26), pages 113 - 120, XP031476090, ISBN: 978-1-4244-4000-9 *

Also Published As

Publication number Publication date
EP2599046A1 (fr) 2013-06-05
FR2963126A1 (fr) 2012-01-27
FR2963126B1 (fr) 2012-10-12

Similar Documents

Publication Publication Date Title
US11429433B2 (en) Process discovery and automatic robotic scripts generation for distributed computing resources
Rasheed et al. Requirement engineering challenges in agile software development
US8032635B2 (en) Grid processing in a trading network
Van der Aalst Business process management: a comprehensive survey
US20190138961A1 (en) System and method for project management using artificial intelligence
Hutchinson et al. Model-driven engineering practices in industry
US8620713B2 (en) Mechanism to control delegation and revocation of tasks in workflow system
US20060106846A1 (en) Cross-context task management
FR2869698A1 (fr) Procede pour le controle et le diagnostic de machines
Kim A model-driven workflow fragmentation framework for collaborative workflow architectures and systems
Vaisman An introduction to business process modeling
CN117289916B (zh) 数智化PaaS平台系统
Schuurman et al. Living labs versus lean startups: an empirical investigation
FR2931274A1 (fr) Procede de gestion de donnees pour atelier oriente service collaboratif
EP2599045A1 (fr) Procédé d&#39;exécution parallèle d&#39;un processus informatique par un bus applicatif
Weiss et al. Lead complementor involvement in the design of platform boundary resources: A case study of BMW's onboard apps
Camarinha-Matos et al. Hierarchical coordination in virtual enterprise infrastructures
WO2012013504A1 (fr) Procédé d&#39;exécution parallèle d&#39;une pluralité de tâches ordonnées selon une table d&#39;ordonnancement
Van den Heuvel et al. Software service engineering: Tenets and challenges
US8719335B2 (en) Framework for development of integration adapters that surface non-static, type-safe service contracts to LOB systems
Umapathy et al. Designing enterprise solutions with web services and integration patterns
CN107491559A (zh) 用于自动生成和执行数据库查询的系统与方法
Liu Integration of model driven engineering and ontology approaches for solving interoperability issues
CA3071892A1 (fr) Systeme informatique pour la visualisation de parcours logistique d&#39;entites dans le temps
Angelov et al. Supporting the diversity of B2B e-contracting processes

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11735635

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2011735635

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2011735635

Country of ref document: EP