WO2012013503A1

WO2012013503A1 - Method for the parallel execution of a computer process by an application bus

Info

Publication number: WO2012013503A1
Application number: PCT/EP2011/062003
Authority: WO
Inventors: Yves Albrieux
Original assignee: Tymis
Priority date: 2010-07-26
Filing date: 2011-07-13
Publication date: 2012-02-02
Also published as: FR2963125B1; FR2963125A1; EP2599045A1

Abstract

The present invention relates to a method for the parallel execution of a computer process by an application bus connected to at least one data-processing unit, characterized in that said method includes the steps of: (a) writing the process in the form of an automaton; (b) determining a concatenation of tasks enabling the automaton to be solved, wherein each task is a basic action that can be executed by a given processing unit to which said application bus is connected; (c) identifying, for each of said tasks, potential dependence constraints relative to the other tasks; (d) generating a task schedule table on the basis of the identified potential dependence constraints; and (e) executing the tasks in parallel using the processing unit(s) while observing the order indicated by the schedule table. The invention also relates to systems therefor.

Description

Title: Method of parallel execution of a computer process by an application bus

GENERAL TECHNICAL FIELD

The present invention relates to the field of development platforms and implementation of expert systems.

More specifically, it relates to a method of parallel execution of a computer process by an application bus.

STATE OF THE ART

Simplicity and user-friendliness are far from being the prerogative of current IT development systems, which most often require the intervention of specialists, who are increasingly difficult to find. In addition, these specialists have great computer skills, but do not have the "professional know-how", that is to say, the experience that will be the professionals to whom the tools are intended, and that in areas that can be very varied.

In particular, office applications are widely used in all sectors of the economy. The development for a service company of a tool that for example would automatically create quotes thus requires not only computer development skills, but also, and most importantly, the knowledge of the rules used every day when creating an estimate by the people of the company whose job it is.

The ambition of the development platforms is thus to reach the range of "business analysts" capable of expressing a business know-how to exploit it by software automata that will allow the realization of expert systems of very high level.

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.

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. However, 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). In addition, Corba offers solutions that are quite burdensome to set up because of the multi-language and multiplatform target.

Business process languages (BPPL), such as Business Process Execution Language for Web Services (BPEL4WS) or XML Process Definition Language (XPDL), or more generally 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. In a more practical way, 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 description is high level and therefore easily understandable (even by non-specialists) but remains too limited in functionality.

The existing solutions therefore prove to be very cumbersome to set up, and therefore unattractive for companies seeking first and foremost the flexibility and agility for such tools, which is relatively limited and therefore insufficient in the medium term.

In addition, none has generally sought to take advantage of parallelism. Indeed, current computing touches the limits of its possibilities, and the increase in performance of processors no longer passes by a finer engraving, but by a multiplication of the number of hearts. Faced with these new architectures, current computing remains behind because it is necessary to rethink many programming paradigms.

There is a need for expert systems development platforms, adapted to massively parallel processing, which can result in a significant gain in productivity and quality.

PRESENTATION OF THE INVENTION The present invention aims to solve these difficulties by proposing a massively parallel processing method around an application bus.

Thanks to these new possibilities offered by this application bus, the development of systems is freed from the new technical constraints engendered by the programming of parallelized processes, which will soon prove unavoidable given the current evolution of the processors. In addition, this simple and fast programming is done directly by the business specialist, who does not need advanced knowledge in computer science.

In addition, an ancillary object of the invention is to achieve this objective while making the link between the current heterogeneous tools of office automation and management and even interfacing with the world of industrial automata.

The present invention thus relates, according to a first aspect, to a method of parallel execution of a computer process by an application bus connected to at least one data processing unit, characterized in that it comprises steps of:

(a) Writing the process as an automaton;

(b) determining a sequence of tasks that allows the resolution of the controller, each task being an elementary action executable by a given processing unit to which said application bus is connected;

(c) Identification, for each of said tasks, of any constraints of dependence on the other tasks;

(d) Generating a task scheduling table based on any identified dependency constraints;

(e) Parallel execution of the tasks by the processing unit (s) in the order indicated by the scheduling table.

According to other advantageous and nonlimiting features of the invention:

The tasks are executed in step (e) by cycles, a plurality of compatible tasks being started in synchronism with each cycle;

Tasks that are performed by a specific application are executed by specific interfaces of the application, said interfaces being controlled by the application bus;

• the data flowing in the application bus is encrypted; Step (a) is performed by a user on a workstation connected to the application bus via a human-machine interface;

Steps (b), (c), (d) and (e) are performed via an interpreter on a partner machine connected to the application bus.

According to a second and a third aspect, the invention relates to systems: one comprising a workstation comprising data display means, data acquisition means, a memory, a data processing unit implementing implement the method according to the first aspect of the invention, the data display means and the data acquisition means being in communication with said human-machine interface and the processing unit being a multicore processor; and the other comprising a workstation and at least one partner machine, the workstation including data display means, data input means, a memory, a data processing unit, and each partner machine comprising a processing unit, the processing unit of one of the partner machines implementing the method according to the first aspect of the invention, the data display means and the data acquisition means being in communication with said man-machine interface and said processing unit of one of the partner machines being a computer.

According to other advantageous and nonlimiting features of the invention:

The system consists of a plurality of workstations and / or partner machines, each comprising at least one processing unit and being served by the application bus;

• the different workstations and partner machines and are connected together via a TCP / IP type network.

PRESENTATION OF FIGURES Other features and advantages of the present invention will appear on reading the following description of a preferred embodiment. This description will be given with reference to the appended drawings in which:

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.

DETAILED DESCRIPTION OF AN EMBODIMENT

Parallel automata

The main idea of the method according to the invention is that any business process whose management, in particular synchronization, could be requested from the application bus can be divided into a set of small "automata". It should be understood that an "automaton" corresponds to a set of instructions gathering the know-how necessary to performing 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.

The word "automaton" here does not have the meaning it has in graph theory, in this case a set of states and transitions. It would be rather a "word" of the language recognized by an FSA (finite state machine), which would rather be represented by the interpreter. The advantage of an interpreter with respect to a compiler lies in its ability to immediately execute a PLC that itself can use other automata, or even write dynamically and make them work.

For example, consider a controller that would be used to help write a response mail to a prospect request.

It is first necessary to propose to the editor (the person for whom the automaton acts) the list of models of letters of response to a request, to make a choice, that the automat prepares the work and presents it for control final.

It is necessary to use an activity of reading the titles of the letters available for this purpose.

• The editor must be asked to choose from the list the mail that will be suitable.

You need an activity that allows the writer to go into the prospect database to identify it. This work can be done in parallel with the previous one following an unimportant order. The automat waits to be in possession of the memories providing the address of the prospect and the mail to elaborate. He can then merge these memories to obtain the desired document.

• This document is presented to the editor via a new activity: the word processor. It is checked by the editor and possibly corrected.

• A new memory collects the generated document and compares it with the preparation memory so that it can be extracted changes to be made in the database (address rectification for example) or even to enter a new prospect 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.

Advantageously, 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. Those skilled in the art will be able to adapt the invention to any human-machine interface of their choice, since extremely ergonomic interfaces are known.

It remains that the pivot of the platform of the automation engineer is the language whose knowledge of the syntax allows the automation engineer to intervene directly.

The skilled person will also be able to use the language of his choice, but advantageously a very simple language describes in a single line the progress of a basic process, a transmitter (or server) to a recipient (or receiver) . The issuer will produce information for the recipient and in passing to apply an added value (the treatment). This is done with the help of possible instructions and the reception by the recipient is accompanied by a report of the work carried out in order to be able to possibly decide on the continuation of the process. These elementary bricks (see Figure 5) are chained to form the general process, the automaton.

General Architecture With reference to FIG. 1, the parallel execution method according to the invention is done via an application bus 1. Like the ESB (Enterprise Service 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. This forms the bus exchange channel 2. Advantageously, 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.

The old applications which do not know this bus 1 are advantageously supported by specific interfaces 3 of each of these applications, responsible for offering them the specific adaptation allowing them to integrate a bus terminal (TB): the CIAs ( interactive communication by PLC). 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 all kinds as dialog boxes, and the application bus 1 whose processing unit is on the partner .The interpreter, described above, is the program that allows the reading of automata. The different 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. Multiplexing / demultiplexing makes it possible to circulate in parallel on the channel 2 data intended for different applications or users.

To operate this application bus 1, we start by feeding it with one or more controllers 4, accompanied by rules of connection and operation.

Process steps

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. In the manual case, 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. In either case, 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. However, 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, treatment units other than that (or those) of this workstation can perform this treatment. Indeed, as explained above, the application bus interconnects any partner machines and stations concerned, and the interpreter uses the application bus natively.

In either of these cases, step 200 begins with a parser sub-step 210 performed by a module named 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.

In an optional 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. The performance is all the better, and above all it allows great flexibility if the scheduling changes during the execution of the process, as will be explained later. 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 transfer methods files, 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, any dependency constraints, that is to say the need for other tasks to be executed 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.

Based on the PERT method (project evaluation and review technique), a planning and sequencing 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 dependency constraints identified. 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 via 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 entrusted to it.

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.

Similarly, the automation engineer does not have to worry about the scheduling automatically set up by the chopper and realized by the application bus 1.

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.

It can also be noted that the various modules used, namely the analyzer 5, the DSP 6 and the executor 7 operate themselves in parallel. Tasks 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:

Initial object T1 Modified object T2 Remodified object

It is therefore very advantageous to have the state of the object in a parallel access table (IPC mechanism, "inter-process communication") or access by window (a multi-access pointer to the task), and a description changes to be made by the task.

We can therefore systematically create the objects (in the memory) with default values corresponding to their nature, but we can also create for each task a table of recipients and another of emitters with default values corresponding to the processing by default.

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. Just pass him 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:

- in registers and in cache (very fast)

- in RAM (fast)

- requiring disk access

- Requiring network access

- Requiring human activity (HMI). 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.

As can be seen in FIG. 5, a report (CR) 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 the 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.

For this purpose 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. With the logic information, 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

Here 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.

Table 1 The service request implies that the ISP is active. 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:

1) the clauses to mount, that is to say the set of predefined data for the object in progress, a model (for example, if it is a contract, it will correspond to a basic text with holes where it will be necessary to add the names of the companies, the date, the names of the participants ...). Clauses can be standard, or off-standard if forced changes have been made (model changes) and stored;

2) Existing variables in the folder memory ("memdos");

3) Related actions to request the CIA to perform a series of standardized simple tasks.

Systems According to a second aspect, 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.

All the actors can be gathered in a single station, the processing unit of the application bus being that of the station. In this case, 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. For the system to be of interest, the processing unit should preferably be a multicore processor, i.e., a processor that can take advantage of parallel execution.

Alternatively the system according to the invention may not be content with a single workstation, but understand as explained above at least one partner machine. In addition, there may be several workstations controlled by users, the different stations each having a processing unit and using the same partner machines around a single application bus, as seen in Figure 6.

The application bus serves as multiple stations (users) and multiple partners (PLCs) in MSMP configuration. It operates 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.). In particular, 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.

In this case, 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. On average configurations, a graphics card located on a partner is used as GPGPU (General-Purpose Computation on Graphics Processing Units). Indeed a graphics card is a complete vector calculator.

Being distributed a priori, 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. There is a key per port and by direction of transmission. The transmission of the new randomly calculated key is itself secured by the previous key. Thus, even if the initial key (used once during the login) is known, there can be no question of penetrating further exchanges.

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 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

Its learning functions ensure scalability and the guarantee of constant improvement of its performance, without the need for a user to intervene.

It renders the services of exchange security, language translation, data and file routing and operation reporting. He knows how to dialogue and pilot heterogeneous applications integrated in the business process, and in particular the office applications.

Claims

A method for parallel execution of a computer process by an application bus connected to at least one data processing unit, characterized in that it comprises steps of:

(a) Writing the process as an automaton;

The method of claim 1, wherein tasks are performed in step (e) by cycles, a plurality of compatible tasks being started synchronously at each cycle.

3. Method according to one of claims 1 to 2, wherein tasks being performed by a specific application are performed by specific interfaces of the application, said interfaces being driven by the application bus.

4. Method according to one of claims 1 to 3, wherein the data flowing in the application bus are encrypted.

5. Method according to one of claims 1 to 4, wherein step (a) is performed by a user on a workstation connected to the application bus via a human-machine interface.

6. The method of claim 5, wherein steps (b), (c), (d) and (e) are performed via an interpreter on a partner machine connected to the application bus.

7. System comprising a workstation comprising data display means, data acquisition means, a memory, a data processing unit implementing the method according to claim 5, the data display means and the data acquisition means being in communication with said human-machine interface and the processing unit being a multicore processor.

A system comprising a workstation and at least one partner machine, the workstation including data display means, data input means, a memory, a data processing unit, and each partner machine comprising a processing unit, the processing unit of one of the partner machines implementing the method according to claim 6, the data display means and the data acquisition means being in communication with said man-machine interface and said processing unit of one of the partner machines being a calculator.

9. System according to one of claims 7 to 8, consisting of a plurality of workstations and / or partner machines, each having at least one processing unit and being served by the application bus.

10. System according to claim 9, wherein the different workstations and partner machines and are connected together via a network type TCP / IP.