WO2008020127A1 - Systeme de traitement automatise de taches. - Google Patents

Systeme de traitement automatise de taches. Download PDF

Info

Publication number
WO2008020127A1
WO2008020127A1 PCT/FR2007/001366 FR2007001366W WO2008020127A1 WO 2008020127 A1 WO2008020127 A1 WO 2008020127A1 FR 2007001366 W FR2007001366 W FR 2007001366W WO 2008020127 A1 WO2008020127 A1 WO 2008020127A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
control
terminal
action
bus
Prior art date
Application number
PCT/FR2007/001366
Other languages
English (en)
Inventor
Pierre Tauveron
Original Assignee
Pierre Tauveron
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 Pierre Tauveron filed Critical Pierre Tauveron
Publication of WO2008020127A1 publication Critical patent/WO2008020127A1/fr

Links

Classifications

    • 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/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • 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

Definitions

  • the present invention relates to information systems, including automated task processing systems.
  • the invention relates to an automated task processing system comprising a set of at least one control terminal (HMI), a central server (SC), and a set (TA) of at least one terminal of action, wherein at least one control terminal (HMI) is connected to the central server (SC) via at least one data bus (VB) and capable and control at least one terminal action.
  • HMI control terminal
  • SC central server
  • TA set of at least one terminal of action
  • Conventional automated task processing systems typically include a terminal connected to a server in the form of client / server or server / server.
  • the data exchanges are point-to-point, with an exclusive transfer of data between a client and the server.
  • a central computer provides network services to terminal users.
  • Another mode of operation consists of an environment called peer-to-peer, in which there is no central computer and each computer (terminal) has a similar role.
  • Such systems especially in the client / server operating mode, are implemented for example in the form of PGI (management software packages).
  • PGIs generally manage functions
  • ERP generally manage the "production" functions, for example for controlling PLCs.
  • a bus topology is the simplest organization in which all computers are connected to the same transmission line via a cable (bus). This topology is easy to implement and has a simple operation. On the other hand, it is very vulnerable in that if only one of the connections is defective, the whole network is affected.
  • a hub is a unitary element that includes a number of junctions to which network cables from computers can be connected.
  • a hub provides communication between its various junctions. Star topologies are less vulnerable because one of the connections can be disconnected without the rest of the network being paralyzed, excluding the hub, without which no communication between the computers of the network is possible.
  • the computers are located on a loop and each communicates in turn. More precisely, the computers are connected to a "Multilation Access Unit” (MAU) which manages the communication between the computers connected to it by giving each of them a speaking time. Examples include token ring token ring topologies.
  • Private networks are networks belonging to the same organization. We distinguish classically two types of networks:
  • Local Area Network LANs are a set of computers belonging to the same organization (enterprise or other) and linked together in a small geographical area, often using the same technology (eg example Ethernet).
  • WANs Wide Area Networks
  • WANs interconnect multiple LANs across large geographic distances, as if they were part of a single LAN.
  • WANs eg the Internet
  • routers that determine the best path to reach a network node.
  • the present invention aims to overcome these disadvantages by providing a particularly flexible system.
  • the device according to the invention is essentially characterized in that said central server (SC) is connected to the set (TA) of at least one terminal action (21, 22) via at least one control bus (PB).
  • SC central server
  • TA set of at least one terminal action (21, 22)
  • PB control bus
  • the central server comprises a first server (VC: VIDEO) connected to a second server (PC: PROCESS).
  • VC VIDEO
  • PC PROCESS
  • the first server (VC) is connected to the second server (PC) via a third server (MC: MAIN).
  • MC MAIN
  • the data bus (VB) and / or the control bus (PB) comprises a virtual private network (VPN).
  • VPN virtual private network
  • the communication protocol on at least one of the buses (VB, PB) is of the MPLS type.
  • any type of file (voice, data, images) can transit over the network, the contents of the frames being identified for this purpose.
  • the protocol is preferably IPV6.
  • system can comprise at least one transaction server (ST) connected to the set of at least one control terminal (HMI) via at least one data bus (VB ), said transaction server being configured to perform an exclusive point-to-point data transfer.
  • ST transaction server
  • HMI control terminal
  • VB data bus
  • the transaction server (ST) and the central server (SC) communicate with each other by batch of data (batch).
  • FIG. 1 is a representation of an embodiment of the system according to the invention
  • FIG. 2 is a representation of an embodiment of a federation of systems according to the invention.
  • FIG. 3 is a representation of an embodiment of the central server according to the invention.
  • FIG. 1 represents a set of control terminals, for example a control screen 11, possibly a touch screen, a data reader 12 or a computer 13, a telephone / videophone 14, a personal assistant (PDA) 15, a camera (by example webcam) 16, etc.
  • a control screen 11 possibly a touch screen
  • a data reader 12 or a computer 13 possibly a data reader 12 or a computer 13
  • a telephone / videophone 14 possibly a personal assistant (PDA) 15
  • PDA personal assistant
  • camera by example webcam
  • Each of these control terminals is capable of communicating information of data / voice / picture type, and is connected to a central server SC via a local data bus VB.
  • the control terminals constitute a set of HMI man-machine interfaces, or "front office”.
  • This transport sub-architecture brings together all the visualization functions and allows, for example, the supervision and management of all the processes by the users through active or passive controls.
  • Each process comprises a set of tasks to be performed, the present description uses indistinctly the terms process or process anglicism.
  • At least one control terminal is capable of driving at least one action terminal.
  • the action terminals 21, 22 define a set TA of action terminals and constitute a production set BO ("back office").
  • a first 21 and a second programmable logic controller 22 are programmable logic controllers 22.
  • the action terminals TA are connected to the central server SC via a control bus PB different from the local data bus VB.
  • the central server SC stores a task model of the automated process.
  • the task model includes at least one of the elements included in the set: set of tasks, interactions between tasks, scheduling of tasks, parameters and events required to automate said process.
  • the task model is stored in another server, connected to the central server SC.
  • the task model can also be distributed, for example on a plurality of servers and / or TA action terminals. With this configuration, the load of the central server SC can be lightened and this one to exercise only functions of integration.
  • This transport sub-architecture manages, for example, the functions and processes by pooling, via the control bus PB, all the automata responsible for controlling the computer processes of the process under consideration.
  • the TA action terminals are connected to the process via dedicated process buses, PIB bus interfaces, which provide the links between the action terminals and the process interface unit devices, such as the digital acquisition board, analog, control card, counters, etc.
  • the execution of an action by an HMI control terminal triggers an action control command of at least one action terminal TA with reference to the task model.
  • the execution of an action by an HMI control terminal and / or an action terminal TA is also capable of updating the task model, for example for the treatment of possible errors or errors. drifts.
  • system may include an ST transaction server to which the VB data bus is connected.
  • This system defines a first domain DOMl, artificial, and corresponding for example to an activity "Research and development" of the organization of a company.
  • All or part of the systems thus created may possibly be federated with each other, as represented in FIG. 2.
  • the link between two domains can be direct by connecting to the same data bus VB.
  • the link can also be indirect by virtual continuity via a VPN virtual private network connection (Virtual
  • Private Network possibly including a router
  • the router ROUT is a device of the data bus VB whose role is to manage the transmissions, via the VPN, of all the necessary information from one point to another of the network.
  • an organization's network can evolve from a simple Intranet to a wide-area network integrating all the internal and external third parties of the organization, for example customers and suppliers.
  • the DOM domain defined previously may correspond to a third party.
  • all buses real or virtual
  • the communication protocol is preferably deterministic, that is to say that it allows source / destination identification.
  • the central server SC comprises a first server VC connected to a second server PC, each of which is connected to the data bus VB and to the bus PB control.
  • these two servers are interconnected by a third supervisory server MC.
  • This embodiment is preferential.
  • the central server SC comprises only one server provided with several modules, each module exerting the functions assigned respectively to the first server VC, second server PC and third server MC below.
  • the supervisor server MC ensures for example the implementation of software performing device management, the conduct of operator dialogs, access management databases, etc.
  • the first VC server ensures, for example, the implementation of software that manages visualization (background image, refreshments, etc.), record management, collection management data from the TA action terminals (eg PLCs), the processing of passive alarms by sending an alarm message, etc.
  • the second PC server provides for example the implementation of software performing the control and management of the implementation of software application / control (user software), monitoring functions (posted by an operator or by a user program and of which the trigger causes the start of a specific action (ASP) corrective that has been associated with it during its monitoring), etc.
  • software application / control user software
  • monitoring functions posted by an operator or by a user program and of which the trigger causes the start of a specific action (ASP) corrective that has been associated with it during its monitoring
  • ASP specific action
  • the central server SC is connected to (or comprises) backup means (not shown), at least one database 31, printing means
  • the system management server manages the system console, the watchdog console, the technical console.
  • the system console supervises the dialogue of the operators with the different MC, VC, PC servers during their respective initialization and during the operation phase.
  • the watchdog console monitors the redundancy of all system elements (servers, buses, etc.)
  • the technical console supervises: - the general state of the system (shutdown, start-up, control of PLCs, control of process interface cards, state of health of the process points involved in a majority logic processing control), management of system tools (modification of a database, download of a PLC, management of modifiable parameters, definition and modification of data collections, management of recording systems, etc.)
  • the central server coordinates for example the following functions: Operator dialogs (locking, unlocking consoles and desks, general commands, display of frames and screens, viewing and printing of reports, visualization and printing of graphic recordings), - management of passive, active, alarms and alarm monitoring. specific actions triggered on the out-of-bounds of a point, the flow of the process processing application programs and associated safety restoration programs (RCS), • - control of process control automations and interventions on standard controllers and on sequence controllers posted in programmable logic controllers, - control of safety automatisms (AS) posted in programmable logic controllers, management and control of data collections, management and control of editable parameters,
  • RCS safety restoration programs
  • AS safety automatisms
  • the content of the databases PUPITRES can be static, - management of the IMAGE databases containing the description of the synoptics and the frames of the dialogues with the operators, the content of the IMAGES data being able to be static.
  • - VB data bus provides transportation of all frames and messages needed for communications between all equipment interfacing with operators and • the central server for the conduct of a given process
  • the PB control bus ensures the transport of all the frames and messages necessary for communications between all the programmable controllers and the central server for the control of the given process.
  • This bipolar architecture supervised by the central server, defines a "control-command" type architecture that advantageously offers the ability to process the information in a combinatorial manner, as close as possible to the process if the programmable logic controller uses it to drive its own process. resources autonomously, or in concert between two or more programmable logic controllers and the central server if the process justifies it for reasons of synchronization of actions, combinations of actions or remote geographical sites or other reasons.
  • This architectural arrangement takes into account the requirements represented by the random, remote, hierarchical, synchronizing, structuring and combining events that are induced by the control of the progress of a process.
  • this bipolar "control-command" architecture locally bases a first level of star distribution by allowing, thanks to the control and the supervision of the central server, a distribution called "any to any” (any point of the network to any point of the network) between the different equipment connected to the two buses VB and PB.
  • each server For issues of load and performance, and because the resident programs of each server are preferably not the same (the functions being different), because the databases are preferably specific to each server, it may be appropriate to support the functions "controls" and functions "commands" by dedicated and separate servers.
  • the traditional activities / functionalities performed by a transactional server can be implemented, namely for example:
  • the set of production functions such as: o Assembly and assembly line, o Industrial press control chain, o Process chain of storage and filling process, o Continuous Casting Process Chain, o Centralized Building Management System The Test Conduct Feature Set, The Test Conduct Feature Set.
  • the system according to the invention by virtue of an MPLS-oriented VPN architecture, preferably using the -IPV6 protocol, makes it possible to perform combinatorial functions in a star-link topology.
  • bus VB and PB constitutes the elementary brick, base of a generalized and generic platform whose structure "Front Office""backoffice” as mentioned above.
  • coordinating the processing of transactional and / or combinatorial functions, and the two-level topology (or more) of star links offers the possibility of a platform adjustment in local mode or in global mode.
  • the bipolar "control-command" architecture ensures a first level, or Local Bus (LB), of star distribution (star Nl) by relying on a local continuity, at the level of a domain DOM, VB and PB buses, themselves representing subsets "Front Office” "back office”.
  • LB Local Bus
  • the VPN network assures by its characteristics (closed network, secure, "any to any") a second level, or Global Bus (GB), of star distribution (star N2) by federating in a virtual way (or in direct) all VB buses, specific to each local DOM, into a global bus which appears as the backbone of the system.
  • GB Global Bus
  • star N2 star distribution
  • Automated processes by virtue of the invention can correspond to hardware functions, for example mechanical functions, for production functions, or to immaterial functions, for example for services.
  • the present invention is advantageously implemented for the automation of a function corresponding to a set of at least two interdependent processes, each process comprising a set of tasks that are suitable to perform, that is to say a first and a a second process in which at least one of the tasks of the first process is influenced by, or even depends on, at least one of the tasks of the second process.
  • Each process is associated at least one HMI control terminal and one or more TA action terminal.
  • the TA and / or HMI control terminals may be distributed over one or more DOM domains as defined above.
  • the fuel filling function of a tank of a vehicle can be automated.
  • the filling function comprises a set of at least two processes: a first process for checking the tightness of the tank, and a second process for filling the tank with fuel.
  • the first process for verifying the tightness of the reservoir comprises a plurality of tasks, such as, for example: checking the internal pressure of the reservoir, test (s) of the valve (s) of test fluid distribution, test fluid injection, measurement of the evolution of the internal pressure under the effect of the test fluid, validation of the tank seal, etc.
  • the second fuel filling process of said tank comprises a plurality of tasks, such as for example: fuel availability, determination of the fuel volume required, test (s) of fuel dispensing valve (s), fuel injection, etc. .
  • the task template includes a process safety task scheduler such that the second process fuel injection task can not be performed until the validation task for the tank's water seal is complete. first process is not performed.
  • One of the parameters of the task model is the available volume of the reservoir, determined for example during the first process of verifying the tightness of the reservoir, by measuring the volume of distributed test fluid, and coming to update the fuel value. to be distributed for the task of determining the required fuel volume of the second process.
  • the invention can be implemented in the field of analyzes.
  • a first process comprises the tasks of performing initial analyzes.
  • the task model can control the implementation, possibly by other action terminals, of complementary analyzes, possibly on another domain.
  • initial analyzes can be performed by a given laboratory, and additional analyzes by another laboratory / hospital center.
  • the networks currently in service can for example serve as basic support for the deployment of the VB data bus.
  • the data transmitted within the system according to the invention are coded in XML format.
  • An XML document is always a tree structure, built from a single root. The nodes of the tree are identified by tags that can carry optional attributes. The number of nodes per level is unlimited. XML is therefore advantageously used in data manipulation and in data exchange systems between software.
  • the present invention makes it possible to federate on a platform mentioned above (server and associated terminals) currently heterogeneous processes (EDI, client / server, ERP). In addition, it describes how the software in these processes must be designed to achieve a seamless combination of all these products that allow complete automation of all the activities managed by these processes.
  • the aim of the invention therefore the level of production software is to make consistent and compliant process automation (• transactional and / or combinatorial) by bringing together in a single software package providing automated operation of all or part activities of an organization.
  • This process is called “predictive” in that it hierarchizes the order of realization of the software necessary for the automated processing of tasks (functional applications).
  • a process is defined as being a particular arrangement of a set of at least one task to be performed.
  • the predictive method is characterized by a successive stack of three software layers sequentially produced one after the other, and in such a way that all the components of the layer of a lower level cover the all the needs, events and scenarios necessary for the operation of the layer 'higher level.
  • the three hierarchical levels are:
  • o Level 1 system components
  • o Level 2 routines and primitives "service” recurrent to the function / task processed
  • o Level 3 application components of the function / task processed.
  • This level 0 makes it possible to provide circuits offering excellent reliability and a low error rate which make it possible to form modular mesh networks, deterministic if necessary, ensuring the safe transport of subscriber-to-subscriber information according to the basic principle "Any to any” VPN networks "IP / MPLS", especially through the IPV ⁇ protocol.
  • the architectures are both the local level (star N1) shaped "control / command” and the global level (star N2) shaped VPN so as to be reproducible ad libitum.
  • Level 1 system level, is based on the urbanization of infrastructures allowing the implementation of all the components in an automated context. It generically defines the role and system functions to be implemented for all users. It also deals with the specificities specific to a particular user, which by its particular arrangement allows the operation of all the system elements.
  • Level 1 focuses on defining all the components of the central systems and all the components of the peripheral systems.
  • the central systems include central servers (SCs), transactional servers (STs) and all the system components needed for their operation.
  • SCs central servers
  • STs transactional servers
  • Peripheral systems include all VB and PB bus equipment. Which includes for example:
  • PB namely: o elements TA 21, 22 of Figure 1, o programmable controller, industrial controller, equipment interfacing the process (digital acquisition card, analog, control card, meter, etc.).
  • the system software includes basic software, input / output processing software, and customized system software. Which includes:
  • OS operating systems
  • interrupt or "polling”
  • basic drivers system device drivers
  • redundancy control software load control software
  • - for input / output processing software o file description blocks, input / output control, element transfer list, static database management, dynamic, mirroring, data extraction, collection , backup-recovery tool - for customized system software: o dynamic porting, broadcast broadband, peer-to-peer.
  • level 2 The role of level 2 is to standardize message exchanges through standard routines, for example of the "business service” type, taking into account the requirements of level 1 and the transport level.
  • the first family is the catalog of technological tools providing repetitive and collective systems functions, such as Refresh GUIs, data collections, etc.
  • the second family is the catalog of technological tools managing repetitive and collective "professional services", automatic or event.
  • Level 2 The scope of Level 2 is to define all service routines and all core and peripheral software components that interface between Level 1 and Level 3. For example, by vertical integration by business line, the Level 2, organized around reusable software components, ensures the transfer of information between the management of physical events and their processing, at level 3, by content management packages. In this example, Level 2 reusable software components replicate the business activity. With this configuration, the eventual evolution of a task will not modify the initial components allowing its initial execution, at most it will be necessary to create new components.
  • This method comprises a complete step of modeling the process to be automated, possibly integrating the "crossed" elements, that is to say used by other processes to which it is linked.
  • the modeling step includes the definition of all the tasks to be performed for the realization of a given process, the definition of the possible links, for example of cause and effect, between them, as well as the interfaces between the different sectors involved in the process. performing a task.
  • the process to be modeled is preferably deterministic.
  • process modeling is an activity related to a given business sector, for example, marketing, sales or more generally business activities, research and development activities, manufacturing or production activities, service activities such as those deployed in banks and insurance, and functional activities specific to a company, such as general management, administrative management, human resources, finance-accounting-pay, etc.
  • the various elements necessary for carrying out the modeling step can for example be determined by a prior step of transversal reengineering.
  • This step defines a common language and to communicate with each other the different actors of a given process, while offering wide possibilities for dynamic changes.
  • the specification, writing and testing of this software production phase is a condition precedent of triggering the production of level 3 software.
  • the current reusable object oriented programming tools are suitable for the production of the level 2 software layer.
  • the method of the invention enhances the implementation and standardized use of business dictionaries and online directory services.
  • the level 3 software layer produces the application programs using for its processing the level 2 routines performed in a previous step.
  • process automation relies on the application level (level 3 layer) on a central component that automates the sequencing of tasks.
  • this central component is the central server as described above. It acts as a task monitor, ie a conductor supervising, monitoring, triggering the treatments corresponding to successive actions related to the automation of the process.
  • the process flow logic of this central server may be specified around pull-down menus dynamically generating the identification and composition of a controlled product or service required as part of a product / service order process. .
  • the method may comprise a step of integrating the outsourcing of information flows through application middleware programs. All of these integrated management packages are interfaced to the different databases natively.
  • the method according to the invention makes it possible to establish a precise order of arrangement in the production of all software components, from system components to application components. This ' allows to ensure coverage and overall consistency in this production capable of managing the automation of different processes.
  • the present invention is not limited to the present embodiment.
  • peripherals of the pilot bus it is possible to provide for example light clients or heavy customers, a portal, a collective workstation, a distribution and time management system, etc.
  • peripherals attached to the control bus it is possible to provide in particular a process interface over the air including digital acquisition cards, analog, control cards, counters, etc., or one or more bays.
  • control and implementation bay acquisition, measurements, specific controls, tests, etc., or the extension of robotic activities or the spatial management of autonomous robots.
  • the present invention can be implemented also for government organizations, health organizations, territorial organization, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Operations Research (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Data Mining & Analysis (AREA)
  • Computer And Data Communications (AREA)
  • Multi Processors (AREA)
  • Small-Scale Networks (AREA)

Abstract

L' invention concerne un système de traitement automatisé de tâches comprenant un ensemble (IHM) d'au moins un terminal de pilotage (11-16), un ensemble (BO) d'au moins un terminal d'action (21, 22), et un serveur central (SC), dans lequel au moins un terminal de pilotage (IHM) est relié au serveur central (SC) par l'intermédiaire d'au moins un bus de données (VB) et susceptible et piloter au moins un terminal d'action. Le système selon l'invention est essentiellement caractérisé en ce que ledit serveur central (SC) est relié à l'ensemble d'au moins un terminal d'action par l'intermédiaire d'au moins un bus de commande (PB).

Description

SYSTEME DE TRAITEMENT AUTOMATISE DE TACHES.
La présente invention concerne des systèmes d'information, notamment les systèmes de traitement automatisé de tâches.
Plus précisément, l'invention concerne un système de traitement automatisé de tâches comprenant un ensemble d'au moins un terminal de pilotage (IHM) , un serveur central (SC) , et un ensemble (TA) d'au moins un terminal d'action, dans lequel au moins un terminal de pilotage (IHM) est relié au serveur central (SC) par l'intermédiaire d'au moins un bus de données (VB) et susceptible et piloter au moins un terminal d'action.
Les systèmes classiques de traitement automatisé de tâches comprennent typiquement un terminal relié à un serveur sous forme de client/serveur ou de serveur/serveur .
Les échanges de données se font dans ce cas de point à point, avec un transfert exclusif de données entre un client et le serveur. Dans un tel environnement client/serveur, un ordinateur central fournit des services réseau aux utilisateurs des terminaux.
Un autre mode de fonctionnement consiste en un environnement dit d'égal à égal (en anglais peer to peer) , dans lequel il n'y a pas d'ordinateur central et chaque ordinateur (terminal) a un rôle similaire. De tels systèmes, notamment dans le mode de fonctionnement client/serveur, sont mis en œuvre par exemple sous forme de PGI (Progiciels de Gestion
Intégrée) ou sous forme d'ERP (Enterprise Ressources Planning) . Les PGI gèrent en général les fonctions
« support » d'une organisation, par exemple les fonctions administratives, financières, ou ressources humaines. Les
ERP gèrent généralement les fonctions « production », par exemple pour le pilotage d'automates.
Ces systèmes sont supportés par différentes topologies de réseau informatique, fonction du progiciel et du besoin local.
Plusieurs topologies de réseaux sont connues, pour une architecture client/serveur ou autre :
Une topologie en bus est l'organisation la plus simple dans laquelle tous les ordinateurs sont reliés à une même ligne de transmission par l'intermédiaire d'un câble (bus) . Cette topologie est facile à mettre en œuvre et possède un fonctionnement simple. En revanche, elle est très vulnérable en ce que si une seule des connexions est défectueuse, l'ensemble du réseau en est affecté.
Dans une topologie en étoile, les ordinateurs du réseau sont reliés à un système matériel central appelé concentrateur ou « hub ». Un hub est un élément unitaire comprenant un certain nombre de jonctions auxquelles il est possible de connecter les câbles réseau en provenance des ordinateurs. Un hub assure la communication entre ses différentes jonctions. Les topologies en étoile sont moins vulnérables car une des connexions peut être débranchée sans que le reste du réseau soit paralysé, à l'exclusion du hub, sans lequel aucune communication entre les ordinateurs du réseau n'est possible.
Pour un réseau possédant une topologie en anneau, les ordinateurs sont situés sur une boucle et communiquent chacun à leur tour. Plus exactement, les ordinateurs sont reliés à un répartiteur (« MAU » pour « Multistation Access Unit ») qui gère la communication entre les ordinateurs qui lui sont reliés en impartissant à chacun d'eux un temps de parole. On peut citer comme exemple les topologies d'anneau à jeton « token ring ».
Plusieurs types de réseaux sont connus.
On distingue les différents types de réseaux (privés) par leur taille (nombre de machines) , leur vitesse de transfert, ainsi que par leur étendue. Les réseaux privés sont des réseaux appartenant à une même organisation. On distingue classiquement deux types de réseaux :
• LAN « local area network », et • WAN « wide area network ».
Les LAN « Local Area Network », ou Réseaux Locaux, sont un ensemble d'ordinateurs appartenant à une même organisation (entreprise ou autre) et reliés entre eux dans une petite aire géographique, souvent à l'aide d'une même technologie (par exemple Ethernet) . Les WAN (« Wide Area Network » ou réseaux étendus) interconnectent plusieurs LAN à travers de grandes distances géographiques, comme si ils faisaient partie d'un même réseau local. Les WAN (par exemple l'Internet) fonctionnent grâce à des routeurs qui permettent de déterminer le meilleur trajet pour atteindre un nœud du réseau.
Quelle que soit la topologie utilisée, les systèmes classiques de traitement automatisé de tâches sont toutefois notamment contraints par leur technicité, donc leur manque de flexibilité, et leur coût.
La présente invention a pour but de remédier à ces inconvénients en proposant un système particulièrement flexible.
Avec cet objectif en vue, le dispositif selon l' invention, par ailleurs conforme au préambule cité ci- avant, est essentiellement caractérisé en ce que ledit serveur central (SC) est relié à l'ensemble (TA) d'au moins un terminal d'action (21, 22) par l'intermédiaire d'au moins un bus de commande (PB) .
Dans un mode de réalisation, le serveur central comprend un premier serveur (VC : VIDEO) relié à un deuxième serveur (PC : PROCESS) .
Avantageusement, le premier serveur (VC) est relié au deuxième serveur (PC) par l'intermédiaire d'un troisième serveur (MC : MAIN) . De préférence, le bus de donnée (VB) et/ou le bus de commande (PB) comprend un réseau privé virtuel (VPN) .
Grâce à cette configuration, les restrictions inhérentes dues aux différences entre LAN et WAN s'estompent et un LAN peut ainsi s'étendre sur une aire géographique beaucoup plus grande .
De préférence, le protocole de communication sur au moins l'un des bus (VB, PB) est de type MPLS.
Grâce à cette configuration, tout type de fichier (voix, données, images) peut transiter sur le réseau, le contenu des trames étant identifié à cet effet.
En particulier, le protocole est IPV6 de préférence .
En outre, le système selon l'invention peut comprendre au moins un serveur de transaction (ST) relié à l'ensemble d'au moins un terminal de pilotage (IHM) par l'intermédiaire d'au moins un bus de données (VB), ledit serveur de transaction étant configuré pour effectuer un transfert de données exclusif de point à point.
Dans un mode de réalisation, le serveur de transaction (ST) et le serveur central (SC) communiquent entre eux par lot de données (batch) .
D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante donnée à titre d'exemple illustratif et non limitatif et faite en référence aux figures annexées dans lesquelles :
- la figure 1 est une représentation d'un mode de réalisation du système selon l'invention,
- la figure 2 est une représentation d'un mode de réalisation d'une fédération de systèmes selon l'invention, et
- la figure 3 est une représentation d'un mode de réalisation du serveur central selon l'invention.
La figure 1 représente un ensemble de terminaux de pilotage, par exemple un écran de contrôle 11, éventuellement tactile, un lecteur de données 12 ou un ordinateur 13, un téléphone/visiophone 14, un assistant personnel (PDA) 15, une caméra (par exemple webcam) 16, etc.
Chacun de ces terminaux de pilotage est susceptible de communiquer des informations de type données/voix/image, et est relié à un serveur central SC par l'intermédiaire d'un bus local de données VB.
Les terminaux de pilotage constituent un ensemble d'interfaces homme machine IHM, ou encore « front office » (guichet) . Cette sous-architecture de transport rassemble toutes les fonctions de visualisation et permet par exemple la supervision et la gestion de l'ensemble des processus par les utilisateurs au travers de contrôles actifs ou passifs. Chaqμe processus comprend un ensemble de tâches à- réaliser, la présente description utilise indistinctement les termes processus ou l'anglicisme process.
Au moins un terminal de pilotage est susceptible de piloter au moins un terminal d'action.
Les terminaux d'action 21, 22 définissent un ensemble TA de terminaux d'action et constituent un ensemble BO de production (« back office ») . Par exemple un premier 21 et un deuxième 22 automate programmable.
Les terminaux d'action TA sont reliés au serveur central SC par l'intermédiaire d'un bus de commande PB différent du bus local de données VB.
De préférence, le serveur central SC stocke un modèle de tâches du processus automatisé.
Le modèle de tâches comprend au moins l'un des éléments compris dans l'ensemble : ensemble des tâches, interactions entre les tâches, ordonnancement des tâches, paramètres et événements nécessaires à l'automatisation dudit processus.
Dans un autre mode de réalisation, le modèle de tâches est stocké dans un autre serveur, relié au serveur central SC. Le modèle de tâches peut également être distribué, par exemple sur une pluralité de serveurs et/ou les terminaux d'action TA. Grâce à cette configuration, la charge du serveur central SC peut être allégée et celui-ci n'exercer que des fonctions d'intégration.
Cette sous-architecture de transport gère par exemple les fonctions et processus en mettant en commun par l'intermédiaire du bus de commande PB l'ensemble des automates chargés de piloter les traitements informatiques du processus considéré.
Les terminaux d'action TA sont reliés au process par l'intermédiaire de bus dédiés process, interfaces bus PIB, qui assurent les liaisons entre les terminaux d'action et les équipements unitaires d'interface process, tels que carte d'acquisition numérique, analogique, carte de commande, compteurs, etc..
L'exécution d'une action par un terminal de pilotage IHM déclenche une commande de pilotage d'action d'au moins un terminal d'action TA en référence au modèle de tâches.
Selon l'invention, l'exécution d'une action par un terminal de pilotage IHM et/ou un terminal d'action TA est susceptible en outre de mettre à jour le modèle de tâches, par exemple pour le traitement d'éventuelles erreurs ou dérives.
En outre, le système peut comprendre un serveur de transaction ST auquel le bus de données VB est relié.
Ce système définit un premier domaine DOMl, artificiel, et correspondant par exemple à une activité « Recherche et développement » de l'organisation d'une entreprise .
Dans cet ordre d'idée, on peut définir d'autres domaines de l'organisation, par exemple DOM2 pour l'activité « Production », DOM3 pour l'activité
« Logistique », DOM4 pour l'activité « Siège social », etc.
Tout ou partie des systèmes ainsi créés peuvent éventuellement être fédérés entre eux, comme représenté à la figure 2.
La liaison entre deux domaines peut être directe par connexion au même bus de données VB. La liaison peut également être indirecte par continuité virtuelle via une connexion de type réseau privé virtuel VPN (Virtual
Private Network) , comprenant éventuellement un routeur
ROUT. Dans ce cas, les informations sont de préférence cryptées par tout moyen connu. Le routeur ROUT est un périphérique du bus de données VB dont le rôle est de gérer les transmissions, via le VPN, de toutes les informations nécessaires d'un point à un autre du réseau.
Grâce à cette configuration, le réseau d'une organisation peut évoluer d'un Intranet simple jusqu'à un réseau étendu intégrant l'ensemble des acteurs tiers internes et externes de l'organisation, par exemple les clients et fournisseurs. Dans ce cas, le domaine DOM défini précédemment, peut correspondre à un tiers. De préférence, l'ensemble des bus (réels ou virtuels) constitue un réseau fermé et privé, de sorte à assurer un maximum de sécurité. De même, tous les composants peuvent être redondés. Enfin, le protocole de communication est de préférence déterministe, c'est-à- dire qu'il permet l'identification source/destination.
En référence à la figure 3 dans laquelle les éléments communs avec ceux de la figure 1 portent les mêmes références, le serveur central SC comprend un premier serveur VC relié à un deuxième serveur PC, dont chaque est relié au bus de données VB et au bus de commande PB. Avantageusement, ces deux serveurs sont reliés entre eux par un troisième serveur superviseur MC. Ce mode de réalisation est préférentiel. Toutefois, d'autres modes de réalisation sont envisageables, par exemple dans lesquels le serveur central SC ne comprend qu'un seul serveur muni de plusieurs modules, chaque module exerçant les fonctions attribuées respectivement au premier serveur VC, deuxième serveur PC et troisième serveur MC ci-dessous.
Dans la configuration de la figure 3, le serveur superviseur MC assure par exemple la mise en œuvre des logiciels réalisant la gestion des périphériques, le déroulement des dialogues opérateurs, la gestion des accès aux bases de données, etc.
Le premier serveur VC assure par exemple la mise en œuvre des logiciels réalisant la gestion de la visualisation (fond d'image, rafraîchissements...), la gestion des enregistrements, la gestion des collections de données en provenance des terminaux d'action TA (p. ex. automates programmables), le traitement des alarmes passives par émission d'un message d'alarme, etc.
Le deuxième serveur PC assure par exemple la mise en œuvre des logiciels réalisant le contrôle et la gestion du déroulement des logiciels d' application/de pilotage (logiciels utilisateurs) , les fonctions de surveillance (postées par un opérateur ou par un programme utilisateur et dont le déclenchement entraîne le démarrage d'une action spécifique (ASP) corrective qui lui a été associée lors de sa mise en surveillance), etc.
De préférence, le serveur central SC est relié à (ou comprend) des moyens de sauvegarde (non représentés), au moins une base de données 31, des moyens d'impression
32 et éventuellement un serveur de supervision du système
33.
Le serveur de supervision du système gère par exemple la console système, la console « watchdog », la console technique.
La console système supervise le dialogue des opérateurs avec les différents serveurs MC, VC, PC lors de leur initialisation respective et en phase d ' exploitation .
La console « watchdog » supervise la redondance de tous les éléments du système (serveurs, bus, etc.)
La console technique supervise: - l'état général du système (arrêt, démarrage, contrôle des automates programmables, contrôle des cartes d'interfaces process, état de santé des points process impliqués dans un contrôle de traitement en logique majoritaire), la gestion des outils systèmes (modification d'une base de données, téléchargement d'un automate programmable, gestion des paramètres modifiables, définition et modification des collections de données, gestion des systèmes d'enregistrement, etc.)
Dans le but d'assurer le bon fonctionnement et la conduite d'un ou de plusieurs processus dynamiques dont les caractéristiques événementielles et aléatoires peuvent être complexes, le serveur central, tel que décrit techniquement ci-dessus, coordonne par exemple les fonctions suivantes : prise en compte des dialogues opérateurs (verrouillage, déverrouillage des consoles et pupitres, commandes générales, visualisation des trames et des synoptiques, visualisation et impression des rapports, visualisation et impression des enregistrements graphiques) , - gestion des surveillances passives, actives, des alarmes et des actions spécifiques déclenchées sur le hors limite d'un point, déroulement des programmes applicatifs de traitement des processus et des programmes de remise en condition de sécurité (RCS) qui leur sont associés, • - contrôle des automatismes de régulation de process et interventions sur les contrôleurs standards et sur les contrôleurs de séquence postés dans les automates programmables, - contrôle des automatismes de sécurité (AS) postés dans les automates programmables, gestion et contrôle des collections de données, gestion et contrôle des paramètres modifiables,
- gestion des bases de données PROCESS contenant la configuration hardware des automates programmables, les paramètres digitaux et analogiques, les compteurs, les contrôleurs standards et les contrôleurs de séquence, certains des éléments des bases de données PROCESS pouvant être dynamiques,
- gestion des bases de données PUPITRES contenant la configuration hardware des pupitres, les séquences des points associés aux platines, les objets connectés tels que compteurs, seuils, débits, et leur description associée, le contenu des bases de données PUPITRES pouvant être statique, - gestion des bases de données IMAGES contenant la description des synoptiques et des trames des dialogues avec les opérateurs, le contenu des données IMAGES pouvant être statique.
Les informations nécessaires au bon fonctionnement conduite d'un ou de plusieurs processus sont véhiculées par deux bus distincts dont - les fonctionnalités sont les suivantes:
- le bus de données VB assure le transport de toutes les trames et messages nécessaires aux communications entre la totalité des équipements assurant l'interface avec • les opérateurs et le serveur central pour la conduite d'un processus donné,
- le bus de commande PB assure le transport de toutes les trames et messages nécessaires aux communications entre la totalité des automates programmables et le serveur central pour- la conduite du processus donné.
Cette architecture bipolaire, supervisée par le serveur central, définit une architecture de type «contrôle-commande» qui offre avantageusement la capacité de traiter les informations de façon combinatoire, au plus près du process si l'automate programmable utilise pour conduire ledit process ses propres ressources de façon autonome, ou de concert entre deux ou plusieurs automates programmables et le serveur central si le process le justifie pour des raisons de synchronisation d'actions, de combinaisons d'actions ou de sites géographiques distants ou d'autres raisons encore.
Cette disposition architecturale prend en compte les exigences que représentent les événements aléatoires, distants, à hiérarchiser, à synchroniser, à structurer, à combiner qui sont induits par le contrôle du déroulement d'un processus. De par sa structure, cette architecture bipolaire «contrôle-commande» fonde localement un premier niveau de distribution étoilée en permettant, grâce au contrôle et à la supervision du serveur central, une répartition dite « any to any » (n'importe quel point du réseau vers n'importe quel point du réseau) entre les différents équipements reliés aux deux bus VB et PB.
Pour des questions de charges et de performances, et parce que les programmes résidents de chaque serveur ne sont de préférence pas les mêmes (les fonctions étant différentes), parce que les bases de données sont de préférence propres à chaque serveur, il peut être opportun de faire supporter les fonctions «contrôles» et les fonctions «commandes» par des serveurs dédiés et distincts .
Grâce à l'invention, les activités/fonctionnalités classiques effectuées par un serveur transactionnel peuvent être mises en œuvre, à savoir par exemple :
- Gestion des activités bureautiques (serveur de fichiers, serveur d'imprimantes en réseaux),
- Gestion des activités administratives et financières (ressources humaines, gestion de la paye, comptabilité, immobilisations, télépaiements),
- Gestion des activités commerciales et marketing (serveur décisionnel, serveur de commerce électronique) , - Gestion des activités scientifiques et techniques (serveur de calcul) ,
- Gestion de la documentation, des publications, Gestion de la messagerie interne entreprise,
- Appropriation du contenu des EDI...
En outre, les activités/fonctionnalités de type combinatoires peuvent être mises en œuvre, à savoir par exemple :
- L'ensemble des fonctions de production, L'ensemble de fonctions de conduite de processus tels que: o Chaîne de montage et d'assemblage, o Chaîne de conduite de presse industrielle, o Chaîne de conduite de processus de stockage et de remplissage, o Chaîne de conduite de processus de coulée continue, o Gestion Technique Centralisée de bâtiment L'ensemble de fonctions de conduite d'essais, L'ensemble de fonctions de conduite de tests.
Le système selon l'invention, grâce à une architecture de type VPN orientée MPLS, de préférence utilisant le protocole -IPV6, permet de réaliser des fonctions combinatoire, dans une topologie de liaisons étoilées.
En effet, l'urbanisation telle' que décrite ci- dessus des bus VB et PB constitue la brique élémentaire, base d'une plate-forme généralisée et générique dont la structure « Front office» « back office» telle qu'évoquée ci-dessus assure la coordination du traitement des fonctions transactionnelles et/ou combinatoires, et dont la topologie à deux niveaux (ou plus) de liaisons étoilées offre la possibilité d'un ajustement de la plate-forme en mode local ou en mode global.
Au niveau local: l'architecture bipolaire «contrôle-commande» assure un premier niveau, ou Local Bus (LB) , de distribution en étoile (étoile Nl) en s ' appuyant sur une continuité locale, au niveau d'un domaine DOM, des bus VB et PB, eux-mêmes représentants des sous-ensembles «Front office» «back office ».
Au niveau global: le réseau VPN assure par ses caractéristiques (réseau fermé, sécurisé, « any to any ») un deuxième niveau, ou Global Bus (GB) , de distribution en étoile (étoile N2) en fédérant de façon virtuelle (ou en direct) l'ensemble des bus VB, propre à chaque DOM local, en un bus global qui apparaît alors comme l'épine dorsale du système.
Cela a pour conséquence la mise en place d'un «
Front office » global étendu permettant ainsi l'accès, en consultation ou en modification, à tous les acteurs d'un processus transactionnel et/ou combinatoire
(indifféremment exécuté dans tel ou tel DOM) selon un niveau personnel d'habilitation et ceci quelque soit leur rattachement à tel ou tel DOM.
Les processus automatisés grâce à l'invention peuvent correspondre à des fonctions matérielles, par exemple mécaniques, pour des fonctions de production, ou à des fonctions immatérielles, par exemple pour des services . La présente invention est avantageusement mise en œuvre pour l'automatisation d'une fonction correspondant à un ensemble d'au moins deux processus interdépendants, chaque processus comprenant un ensemble de tâches propres à réaliser, c'est-à-dire un premier et un deuxième processus dont au moins l'une des tâches du premier processus est influencée par, voire dépend de, l'une au moins des tâches du deuxième processus.
A chaque processus est associé au moins un terminal de pilotage IHM et un ou plusieurs terminal d'action TA.
Les terminaux d'action TA et/ou de pilotage IHM peuvent être répartis sur un ou plusieurs domaines DOM tels que définis précédemment.
A titre d'exemple, dans un mode de réalisation, la fonction de remplissage en combustible d'un réservoir d'un véhicule (spatial, aérien ou terrestre) peut être automatisée .
A cet effet, la fonction de remplissage comprend un ensemble d'au moins deux processus : un premier processus de vérification de l'étanchéité du réservoir, et un deuxième processus de remplissage en combustible dudit réservoir .
Le premier processus de vérification de l'étanchéité du réservoir comprend une pluralité de tâches, telles que par exemple : vérification de la pression interne du réservoir, test (s) de vanne (s) de distribution de fluide de test, injection de fluide de test, mesure de l'évolution de la pression interne sous l'effet du fluide de test, validation de l'étanchéité du réservoir, etc.
Le deuxième processus de remplissage en combustible dudit réservoir comprend une pluralité de tâches, telles que par exemple : disponibilité du combustible, détermination du volume de combustible nécessaire, test (s) de vanne (s) de distribution de combustible, injection du combustible, etc.
Dans cet exemple, le modèle de tâches comprend un ordonnancement des tâches relatif à la sécurité des processus tel que la tâche d'injection du combustible du deuxième processus ne puisse être mise ne œuvre tant que la tâche de validation de l'étanchéité du réservoir du premier processus n'est pas effectuée.
Un des paramètres du modèle de tâches est le volume disponible du réservoir, déterminé par exemple lors du premier processus de vérification de l'étanchéité du réservoir, par la mesure du volume de fluide de test distribué, et venant mettre à jour la valeur de combustible à distribuer pour la tâche de détermination du volume de combustible nécessaire du deuxième processus .
Dans un autre mode de réalisation, l'invention peut être mise en œuvre dans le domaine des analyses. A cet effet, un premier processus comprend les tâches consistant à effectuer des premières analyses. En fonction des résultats des premières analyses, le modèle des tâches peut piloter la mise en œuvre, éventuellement par d'autres terminaux d'action, d'analyses complémentaires, éventuellement sur un autre domaine.
Dans le domaine médical par exemple, des premières analyses peuvent ainsi être effectuées par un laboratoire donné, et des analyses complémentaires par un autre laboratoire / centre hospitalier.
Sur le plan réseau informatique, les réseaux actuellement en service peuvent par exemple servir de support de base au déploiement du bus de données VB.
De préférence, les données transmises au sein du système selon l'invention sont codées au format XML. Un document XML est systématiquement une structure arborescente, construite à partir d'une racine unique. Les nœuds de l'arbre sont identifiés par des balises (tags) pouvant porter des attributs facultatifs. Le nombre de nœuds par niveau est illimité. XML est donc avantageusement utilisé dans la manipulation des données et dans les systèmes d'échange de données entre logiciels.
La présente invention permet de fédérer sur une plate-forme ci-dessus évoquée (serveur et terminaux associés) des processus actuellement hétérogènes (EDI, client/serveur, ERP) . En outre, elle permet de décrire la façon dont les logiciels de ces processus doivent être conçus pour obtenir une combinaison homogène de tous ces produits permettant l'automatisation complète de l'ensemble des activités gérées par ces processus .
L'objectif de l'invention au niveau de la production des logiciels est donc de rendre cohérent et compatible l'automatisation de processus (transactionnels • et/ou combinatoires) en les réunissant dans un même ensemble logiciel assurant le fonctionnement automatisé de tout ou partie des activités d'une organisation.
A cet effet, pour la réalisation de systèmes informatiques, il est souhaitable de se référer à un nouveau procédé de production de logiciels, autre objet de la présente invention.
Ce procédé est dit « prédictif» en ce qu'il hiérarchise l'ordre de réalisation des logiciels nécessaires au traitement automatisé des tâches (applications fonctionnelles) .
On définit un processus comme étant un agencement particulier d'un ensemble d'au moins une tâche à réaliser .
Pour automatiser les processus, le procédé prédictif est caractérisé par un empilement successif de trois couches logicielles réalisées séquentiellement l'une après l'autre, et de telle façon que l'ensemble des composants de la couche d'un niveau inférieur couvre la totalité des besoins, événements et cas de figure nécessaires au fonctionnement de la couche ' de niveau supérieur.
Les trois niveaux hiérarchiques sont les suivants :
o Niveau 1 : composants systèmes, o Niveau 2 : routines et primitives «service» récurrentes à la fonction/tâche traitée, o Niveau 3 : composants applicatifs de la fonction/tâche traitée.
Ces trois niveaux se basent sur un niveau 0 correspondant au transport des informations (données) . Ce niveau 0 permet de fournir des circuits offrants une excellente fiabilité et un taux d'erreur faible qui permettent de constituer des réseaux maillés modulaires, déterministes si nécessaire, assurant en toute sécurité le transport des informations d'abonné à abonné selon le principe de base « any to any» des réseaux VPN « IP/MPLS », en particulier grâce au protocole IPVβ.
En outre, il peut être envisagé dans certains cas d'intégrer aux réseaux VPN des protocoles évolués fonctionnant en mode synchrone bidirectionnel avec une sécurité de type contrôle de redondance cyclique, et anticipation des échanges tels ceux très utilisés dans le réseau TRANSPAC X25, ou de façon similaire sur les modèles de protocole du type HDLC.
En ce qui concerne l'urbanisation de ces réseaux, telle que décrite ci-avant, les architectures sont de préférence génériques tant en ce qui concerne le niveau local (étoile Nl) façonné« contrôle/commande», qu'en ce qui concerne le niveau global (étoile N2) façonné VPN, de manière à pouvoir être reproductible ad libitum.
Le niveau 1, niveau système, s'appuie sur l'urbanisation des infrastructures permettant la mise en œuvre de tous les composants dans un contexte automatisé. Il définit de façon générique le rôle et les fonctions systèmes à mettre en œuvre pour tous les utilisateurs. Il traite aussi des spécificités propres à tel ou tel utilisateur permettant par son agencement particulier le fonctionnement de l'ensemble des éléments systèmes.
Le périmètre du niveau 1 s'attache essentiellement à définir tous les composants des systèmes centraux et tous les composants des systèmes périphériques.
Par exemple :
Les systèmes centraux comprennent des serveurs centraux (SC) , des serveurs transactionnels (ST) et tous les composants systèmes nécessaires à leur fonctionnement. Ce qui inclut par exemple : - la description des éléments composants les serveurs centraux et les serveurs transactionnels, à savoir : o carte CPU, carte RAM, carte contrôleur disque, bande, etc., carte mémoire partagée, carte interface de connexion aux bus VB et PB, carte interface diverse, - la description des périphériques systèmes propres aux serveurs centraux et aux serveurs transactionnels, à savoir : o disque fixe, disque amovible, console système, console « watchdog »
, périphérique de sauvegarde, ressources d'impression.
Les systèmes périphériques comprennent l'ensemble des équipements des bus VB et PB. Ce qui inclut par exemple :
la description des équipements rattachés au VB, à savoir : ' o les éléments IHM 11, 12, 13, 14, 15, 16 de la figure 1, o console technique, poste de surveillance, pupitre de conduite de process (video, synoptique, clefs) , routeur VPN - la description des équipements rattachés au
PB, à savoir : o éléments TA 21, 22 de la figure 1, o automate programmable, automate industriel, équipements interfaçant le process (carte d'acquisition numérique, analogique, carte de commande, compteur, etc. )
Les logiciels systèmes comprennent des logiciels de base, des logiciels de traitement des entrées/sorties, des logiciels systèmes customisés. Ce qui inclut:
- pour les logiciels de base: o systèmes d'opération (OS) orientés« interrupt » ou« polling», drivers de base système, drivers de périphérique, logiciel de contrôle de redondance, logiciel de contrôle de charge
- pour les logiciels de traitement des entrées/sorties : o blocs de description de fichier, de contrôle d'entrée/sortie, de liste de transfert d'éléments, gestion des bases de données statiques, dynamiques, miroirs, extraction des données, collection de données, outil de sauvegarde-restoration - pour les logiciels systèmes customisés : o portage dynamique, diffusion large « broadcast », pair à pair.
Le rôle du niveau 2 est de standardiser les échanges de messages au travers de routines standards, par exemple de type « service métier», en tenant compte des exigences du niveau 1 et du niveau transport.
Ces routines sont définies et créées dans le but d'assurer l'interface entre le niveau 1 système et le niveau 3 fonctionnel. A ce titre, elles peuvent être distinguées en deux familles génériques de catégorie différente :
- la première famille est le catalogue des outils technologiques assurant les fonctions systèmes répétitives et collectives, telles que les trames de rafraîchissement des IHM, les collections de données, etc. la deuxième famille est le catalogue des outils technologiques gérant les «services métiers» ' répétitifs et collectifs, automatiques ou événementiels .
Les primitives communes à toutes les applications fonctionnelles du processus à automatiser sont donc écrites lors de la réalisation de la production des logiciels de niveau 2.
Le périmètre du niveau 2 s ' attache à définir toutes les routines de service et tous les composants logiciels centraux et périphériques assurant l'interface entre le niveau 1 et le niveau 3. Par exemple, par une intégration verticale par secteur d'activité, le niveau 2, organisé autour de composants logiciels réutilisables, assure le transfert des informations entre la gestion des événements physiques et leur traitement, au niveau 3, par des progiciels de gestion du contenu. Dans cet exemple, les composants logiciels réutilisables du niveau 2 reproduisent donc l'activité de l'entreprise. Grâce à cette configuration, l'évolution éventuelle d'une tâche ne modifiera pas les composants initiaux permettant son exécution initiale, tout au plus sera-t-il nécessaire de créer de nouveaux composants.
Ce procédé comprend une étape complète de modélisation du processus à automatiser, intégrant éventuellement les éléments « croisés », c'est à dire utilisés par d'autres processus auxquels celui-ci est lié.
L'étape de modélisation comprend la définition de toutes les tâches à exécuter pour la réalisation d'un processus donné, la définition des éventuels liens, par exemple de cause à effet, entre elles, ainsi que les interfaces entre les différents secteurs intervenants dans la réalisation d'une tâche. Dans cet esprit, le processus à modéliser est de préférence déterministe.
Ainsi, la modélisation des processus est une activité qui se rattache à un secteur d'activité donné, par exemple des activités de marketing, de vente ou plus généralement de commerce, des activités de recherche et de développement, des activités manufacturières ou de production, des activités de services telles que celles déployées dans les banques et les assurances, enfin des activités fonctionnelles propre à une entreprise, telles que direction générale, direction administrative, ressources humaines, service finance-comptabilité-paye, etc.
Il appartient donc à la modélisation, dans une étape intermédiaire, de spécifier l'ensemble des routines et primitives « service» de niveau 2 d'un sous-ensemble fonctionnel cohérent.
Les différents éléments nécessaires à la réalisation de l'étape de modélisation peuvent par exemple être déterminés par un étape préalable de réingénierie transversale. Cette étape permet de définir un langage commun et de faire communiquer entre eux les différents acteurs d'un processus donné, tout en offrant de larges possibilités de modifications dynamiques.
De préférence, la spécification, l'écriture et les tests de cette phase de production logicielle sont une condition suspensive du déclenchement de la production des logiciels de niveau 3.
A titre exemple, les outils actuels de programmation orientés objets réutilisables sont adaptés à la production de la couche logicielle de niveau 2.
Avantageusement, le procédé selon l'invention renforce la mise en place et l'utilisation standardisée des dictionnaires métiers et des services d'annuaires en ligne.
La couche logicielle de niveau 3 produit les programmes applicatifs en utilisant pour ses traitements les routines de niveau 2, réalisés dans une étape précédente.
Comme tout noyau exécutif, l'automatisation des processus s'appuie au niveau applicatif (couche de niveau 3) sur un composant central chargé d'automatiser l'enchaînement des tâches.
De préférence, ce composant central est le serveur central tel que décrit précédemment. Celui-ci agit comme un moniteur de tâches, c'est-à-dire un chef d'orchestre supervisant, surveillant, déclenchant les traitements correspondants aux actions successives liées à l'automatisation du processus.
La logique d'enchaînement des traitements de ce serveur central peut être spécifiée autour de menus déroulants générant dynamiquement l'identification et la composition d'un produit commandé ou d'un service requis dans le cadre d'un processus de commande de produit/service .
Ces items informatiques peuvent alors être appréciés pour enclencher et dérouler tous les traitements nécessaires à une ligne de production automatisée ou à une demande de service automatisée.
En outre, le procédé peut comprendre une étape d'intégration de l ' externalisation des flux d'informations au travers des logiciels « middleware » applicatifs. L'ensemble de ces progiciels de gestion intégrés sont interfaces aux différentes bases de données de façon native .
On peut ainsi prévoir des interfaces automatiques constituées par des logiciels dont les fonctions comprennent l'agrégation / concaténation, selon des formats reconnus, de données à pré-enregistrer dans des fichiers de transferts propres à alimenter les batchs déjà évoqués, afin d'assurer les liens de communication entre un serveur transactionnel et un serveur central.
Le procédé selon l'invention permet d'établir un ordre d'agencement précis dans la production de l'ensemble des composants logiciels, des composants systèmes aux composants applicatifs. Cela ' permet d'assurer une couverture et une cohérence globale dans cette production capable de gérer l'automatisation de différents processus.
La présente invention n'est pas limitée au présent mode de réalisation.
Concernant les périphériques du bus de pilotage, il possible de prévoir notamment des clients légers ou clients lourds, un portail, un poste de travail collectif, un système de distribution et de gestion du temps, etc.
Concernant les périphériques rattachés au bus de commande (PB) , il est possible de prévoir notamment une interface process par voie hertzienne comprenant des cartes d'acquisition numérique, analogique, cartes de commande, compteurs, etc., ou encore une ou plusieurs baies. Par exemple, baie de commande et de mise en œuvre, d'acquisition, de mesures, de contrôles spécifiques, de tests, etc., ou encore le prolongement des activités robotisées ou la gestion spatiale de robots autonomes.
La présente invention peut être mise en œuvre également pour des organisations gouvernementales, organismes de santé, organisation territoriale, etc.

Claims

REVENDICATIONS
1. Système de traitement automatisé de tâches comprenant : un ensemble (IHM) d'au moins un terminal de pilotage (11-16), un ensemble (TA) d'au moins un terminal d'action (21, 22), et un serveur central (SC) , dans lequel au moins un terminal de pilotage (IHM) est relié au serveur central (SC) par l'intermédiaire d'au moins un bus local de données (VB) et susceptible et piloter au moins un terminal d'action (21, 22), caractérisé en ce que ledit serveur central (SC) est relié à l'ensemble d'au moins un terminal d'action (TA) par l'intermédiaire d'au moins un bus de commande (PB) distinct du bus local de données (VB) .
2. Système selon la revendication 1, comprenant en outre un modèle de tâches comprenant au moins l'un des éléments compris dans l'ensemble : ensemble des tâches, interactions entre les tâches, ordonnancement des tâches, paramètres et événements nécessaires à l'automatisation d'un processus donné.
3. Système selon la revendication 2, dans lequel l'exécution d'une action par un terminal de pilotage (IHM) déclenche une commande de pilotage d'action d'au moins un terminal d'action (TA) en référence au modèle de tâches, l'exécution d'une action par un terminal de pilotage (IHM) et/ou un terminal d'action (TA) étant susceptible en outre de mettre à jour le modèle de tâches .
4. Système selon l'une quelconque des revendications précédentes, dans lequel le serveur central comprend un premier serveur (VC : VIDEO) relié à un deuxième serveur (PC : PROCESS) .
5. Système selon la revendication 4, dans lequel le premier serveur (VC) est relié au deuxième serveur (PC) par l'intermédiaire d'un troisième serveur superviseur (MC : MAIN) .
6. Système selon l'une quelconque des revendications précédentes, dans lequel le bus de donnée
(VB) et/ou le bus de commande (PB) comprend un réseau privé virtuel (VPN) .
7. Système selon l'une quelconque des revendications précédentes, dans lequel le protocole de communication sur au moins l'un des bus (VB, PB) est de type MPLS.
8. Système selon la revendication 7, dans lequel le protocole est IPV6.
9. Système selon l'une quelconque des revendications précédentes, comprenant en outre au moins un serveur de transaction (ST) relié à l'ensemble d'au moins un terminal de pilotage (IHM) par l'intermédiaire d'au moins un bus de données (VB), ledit serveur de - -transaction étant configuré pour effectuer un transfert de données exclusif de point à point.
10. Système selon la revendication 9, dans lequel le serveur de transaction (ST) et le serveur central (SC) communiquent entre eux par lot de données (batch) .
PCT/FR2007/001366 2006-08-16 2007-08-10 Systeme de traitement automatise de taches. WO2008020127A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0607334A FR2905017B1 (fr) 2006-08-16 2006-08-16 Systeme de traitement automatise de taches.
FR0607334 2006-08-16

Publications (1)

Publication Number Publication Date
WO2008020127A1 true WO2008020127A1 (fr) 2008-02-21

Family

ID=38001953

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2007/001366 WO2008020127A1 (fr) 2006-08-16 2007-08-10 Systeme de traitement automatise de taches.

Country Status (2)

Country Link
FR (1) FR2905017B1 (fr)
WO (1) WO2008020127A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2988495B1 (fr) 2012-03-23 2016-07-15 Pierre Tauveron Procede de traitement automatise de taches

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001084271A2 (fr) * 2000-04-28 2001-11-08 Certia, Inc. Systeme et procede de distribution de contenu securise
US20020032582A1 (en) * 2000-09-14 2002-03-14 Feeney Robert J. System for medication dispensing and integrated data management
US20030009536A1 (en) * 2001-07-06 2003-01-09 Portris, Inc. Method and system for collaborative knowledge management
US20030088534A1 (en) * 2001-11-05 2003-05-08 Vernon W. Francissen Gardner, Carton & Douglas Method and apparatus for work management for facility maintenance

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2394808A (en) * 2002-11-01 2004-05-05 Canon Europa Nv E-Maintenance System

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001084271A2 (fr) * 2000-04-28 2001-11-08 Certia, Inc. Systeme et procede de distribution de contenu securise
US20020032582A1 (en) * 2000-09-14 2002-03-14 Feeney Robert J. System for medication dispensing and integrated data management
US20030009536A1 (en) * 2001-07-06 2003-01-09 Portris, Inc. Method and system for collaborative knowledge management
US20030088534A1 (en) * 2001-11-05 2003-05-08 Vernon W. Francissen Gardner, Carton & Douglas Method and apparatus for work management for facility maintenance

Also Published As

Publication number Publication date
FR2905017B1 (fr) 2010-04-30
FR2905017A1 (fr) 2008-02-22

Similar Documents

Publication Publication Date Title
US9170701B2 (en) Suggesting contextually-relevant content objects
US9158556B2 (en) Managing web content creation in a web portal
FR2869698A1 (fr) Procede pour le controle et le diagnostic de machines
US20100146479A1 (en) Architecture view generation method and system
CN105339941B (zh) 针对etl映射设计使用投影器和选择器组件类型
US20160217419A1 (en) Data analysis system and method to enable integrated view of customer information
EP2610761A1 (fr) Fourniture d'un contenu pertinent contextuel
EP3423907A1 (fr) Utilisation d'un noeud intelligent dans un système intelligent et universel de supervision de processus industriels
WO2019130009A1 (fr) Plate-forme de nuage hybride orchestre pour environnement multi-nuages
Pathak et al. IoT, AI, and Blockchain for .NET
FR3007000A1 (fr) Systeme de surveillance d'une plateforme avionique a architecture trois tiers
FR3069076A1 (fr) Systeme et procede pour delivrer dynamiquement du contenu
WO2008020127A1 (fr) Systeme de traitement automatise de taches.
WO2019121674A1 (fr) Systeme et procede pour configurer une infrastructure de video-surveillance
EP3881515B1 (fr) Système de supervision formelle de communications
FR2963125A1 (fr) Procede d'execution parallele d'un processus informatique par un bus applicatif
US20150363228A1 (en) Integrating software solutions to execute business applications
Chikhi et al. Knowledge management process through a cloud computing based approach
Mei et al. A service-based framework for mobile social messaging in PaaS systems
WO2019121676A1 (fr) Systeme de gestion de video-surveillance
Dahir et al. People, processes, services, and things: using services innovation to enable the internet of everything
EP2599046A1 (fr) Procédé d'exécution parallèle d'une pluralité de tâches ordonnées selon une table d'ordonnancement
Ducreux et al. Rapid prototyping of complete systems, the case study of a smart parking
Möhring Digital Twins in Production: The integration of semi-and unstructured data
US20230315580A1 (en) Disaster recovery in a cell model for an extensibility platform

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 07823418

Country of ref document: EP

Kind code of ref document: A1