Method for collecting industrial data

Abstract

The invention relates to a method of collecting industrial data within a factory (100) which includes industrial equipment which executes a process within a station (ST01, ST02) included in an operation (OP600; OP630).According to the invention, the method comprises the following steps: - instantiation of a physical data model on a local server (120), the model having a hierarchical structure, with a first class, respectively a second class, respectively a third class, comprising variables related to the process, respectively to the station, respectively to the operation, the first class depending on the second, which depends on the third, each variable having a type and a physical address for allocating a value of the variable on the industrial equipment or the station or the operation, the variables being drawn from a database of variables, - collection of data according to said data model, for each variable, the local server is connected to its physical address in order to record its value, - storage of the data on a remote server (140). Figure for the abstract: Fig. 1.

Description

Title of the invention: Method for collecting industrial data Technical field of the invention

[0001] The present invention relates generally to the exploitation of digital data in the context of industry.

[0002] It relates more particularly to a method of collecting industrial data on an industrial production line according to data models, and of storing this collected industrial data on a data server.

[0003] The invention finds a particularly advantageous application for many cases of data exploitation and analysis - process monitoring, traceability, conditional and predictive maintenance - on a large industrial scale, by responding to interoperability constraints, particularly for the automotive industry. State of the art

[0004] The fourth industrial revolution, or Industry 4.0, aims to implement new ways of organizing the means of production, notably by leveraging the Industrial Internet of Things (IIoT). The IIoT makes it possible to connect computer systems, industrial equipment, and sensors on industrial, manufacturing, assembly, and / or production lines. Data, known as industrial data, is thus captured directly on the industrial lines and transmitted to servers in real time.

[0005] Industry 4.0 relies in particular on the analysis, and even the exploitation, of the data thus captured. Data exploitation refers to use cases such as process monitoring, traceability, and condition-based and predictive maintenance. These data use cases make it possible, for example, to optimize, streamline, and / or simplify operations, from the scale of a production line to a global scale encompassing the various factories of an industrial group, for example, an automotive group.

[0006] Nevertheless, one of the major challenges facing the fourth industrial revolution is interoperability. This, as defined by the European Interoperability Framework, comprises four levels and aims to harmonize the industrial ecosystem.

[0007] Indeed, the latter suffers from the "silo" approach, where each domain has its own semantics and protocols. Thus, production chains end up segmented into a multitude of protocols and / or standards (Modbus, BAC-NET, 3964R, FlexRay, S7, CC-link, TPC, CAN Open, etc.), most often unable to exchange data directly, and / or to communicate using common technical standards. Similarly, the proliferation of vocabulary and processes depending on the trade within an industrial organization leads to redundancies and sub-optimization of production resources.

[0008] In particular, the heterogeneity of the industrial data collected hinders the implementation of Industry 4.0. Indeed, the data flows collected are very large, especially at the scale of an industrial group. Organizing and processing this heterogeneous data represents a waste of time and resources, notably with redundancies, increasing the costs of accessing the servers on which the data is usually stored.

[0009] Thus, interoperability aims to enable communication and information exchange between two systems, for example, between two communication protocols, such as the Open Platform Communication Unified Architecture protocol and the Message Queuing Telemetry Transport protocol. Making these protocols interoperable implies, in particular, compatibility of formats, data quality, and semantic preservation.

[0010] One proposed solution was to mediate the data, that is, to translate it into a form understandable by a target system.

[0011] However, this solution proves to be of little applicability on a large scale, as it generates significant access costs to data servers, but also high processing costs.

[0012] However, some automotive manufacturers collect approximately 800 gigabytes of industrial data per day, on more than 60 types of equipment which together account for nearly 8500 machines.

[0013] Furthermore, data mediation degrades the quality of the data collected.

[0014] Moreover, the quality of the industrial data collected is also degraded by the multiple translations necessary for data mediation.

[0015] A standardization approach is also known in the prior art. Such an approach uses a standard, intended for manufacturers, called OPC UA (for Unified Architecture), developed by the OPC Foundation. However, this standard adopts an equipment-centric view—that is, focusing on information associated with industrial equipment—which proves poorly suited to the industrial process-oriented approach adopted by some manufacturers, including the applicant. In particular, the OPC UA standard, and specifically the logic behind the structuring of the OPC UA Foundation's data models, does not allow for the optimal collection of information related to industrial processes, which is nevertheless necessary for manufacturers. Presentation of the invention

[0016] In order to remedy the aforementioned drawback of the prior art, the present invention proposes a method of collecting data according to a standardized structure, through the application of a single data model in the form of a digital modeling chain, which leads to an instantiation of the data model on computer systems.

[0017] More particularly, the invention proposes a method for collecting industrial data within a factory, the factory comprising at least one piece of industrial equipment adapted to carry out at least one industrial process within a station, included in an operation, in which the following steps are planned: - instantiation of a physical data model on a local server, the physical data model having a hierarchical structure in which at least a first class comprises variables related to the industrial process, a second class comprises variables related to the station, and a third class comprises variables related to the operation, the first class being hierarchically linked to the second class, and the second class being hierarchically linked to the third class, each variable having a type and a physical address for allocating a value of the variable on at least one piece of industrial equipment or station or operation, the variables being drawn from a database of variables, - Collection of industrial data according to the physical data model; for each variable, the local server is connected to the physical address of variable allocation in order to record a value for the variable. - storage of industrial data within a remote server.

[0018] Thus, thanks to the invention, and in particular, thanks to the design and use of standard data models, it is possible to implement industrial data collection according to a standardized data model. Advantageously, hierarchical logical links are established between the different variables collected using the standard data models, with the aim of representing the industrial process. The data is thus contextualized from the moment of collection. Such a data model, instantiated in a physical form, enables a standardized data exchange protocol with a storage server, regardless of the process, station, or operation considered. This standardization meets the need for interoperability, necessary for managing a large data flow from diverse sources, representative of industrial complexity.

[0019] This solution is easily scalable, meaning it is easily applicable to an increasing number of pieces of equipment, processes, stations, operations, and plants. This scalability is facilitated in particular by a standard industrial data format, advantageously limiting the need for multiple data acquisitions. Heterogeneous data, and semantic alignment across different industrial processes, facilitate data exploitation by the IT layer—that is, the information technology departments—of the company or manufacturer. In particular, a variety of different data models is limited, for example by pooling possible variables through a variable database.

[0020] The quality of the data collected is also preserved, because this data remains in the format in which it is collected from collection until use by a client.

[0021] Thus, the costs of accessing the servers, as well as processing costs, are advantageously reduced.

[0022] Other advantageous and non-limiting features of the method according to the invention, taken individually or in all technically possible combinations, are as follows: - The physical data model instantiation step generates at least one instantiation file on the local server, and the collection step is performed according to a hierarchical and standardized format and structure using at least one instantiation file defining the data model. - The variable database is a database listing pre-existing variables, - Pre-existing variables include generic pre-existing variables and specific pre-existing variables; generic pre-existing variables are used by a plurality of physical data models. - Pre-existing specific variables are grouped into a plurality of specific blocks and pre-existing generic variables are grouped into a plurality of generic blocks; the physical data model is built by assembling the generic and specific blocks to create the hierarchical structure; - The local server on which the physical data model is instantiated is an OPC Unified Architecture server. - The physical address for allocating the value of at least one variable is given by a configuration driver, the configuration driver generating an addressing script between a database of physical addresses and at least one variable instantiated on the local server, - the database of physical addresses is established taking into account the minimum industrial equipment of the factory (for example, based on the control software of each piece of equipment, which stores the data it measures or generates at different addresses than other equipment when the latter are not identical; typically, two drills of different brands store their data in different ways), - Industrial data collection is carried out at three industrial data collection points, each of these collection points corresponding to a memory area, where variables hierarchically linked by the physical data model are combined and collected simultaneously from this memory area, the three industrial data collection points comprising one collection point corresponding to the variables of the first class, one collection point corresponding to the variables of the second class and one collection point corresponding to the variables of the third class, - Industrial data is collected and stored in a time series format; - the method also includes a step of processing the industrial data by a client. - The data exploitation stage includes a step of tracking and identifying parts produced by at least one industrial process, - The data exploitation stage includes a condition-based maintenance stage on at least one piece of industrial equipment implementing at least one industrial process and / or a recall of parts produced by at least one industrial process, - at least one industrial process allows the manufacture of a part for an automotive vehicle.

[0023] Of course, the various features, variants, and embodiments of the invention can be combined in various ways, provided they are not incompatible or mutually exclusive. Detailed description of the invention

[0024] The following description with regard to the attached drawings, given by way of non-limiting examples, will make it clear what the invention consists of and how it can be carried out.

[0025] On the attached drawings:

[0026] [Fig-1] is a representation of an industrial data collection system, such as proposed in the present invention.

[0027] [Fig.2] illustrates, by means of a flowchart, a method of data collection industrials using the system of [Fig.1].

[0028] [Fig.3] illustrates an example of data instantiation according to the flowchart of the [Fig.2],

[0029] [Fig.4] represents the overall architecture implemented in the method of [Fig.2].

[0030] [Fig.5] is an example of a curve established from collected industrial data according to the method of [Fig.2].

[0031] In [Fig.1], an industrial data collection system 1 is shown. Such a system 1 is implemented in several factories 100 (only one of which is shown), for example, factories manufacturing and / or assembling mechanical parts, for example automotive parts.

[0032] This system 1 includes a data storage server, as well as means of control and communication between the data storage server and manufacturing equipment or machines (typically machining or assembly machines, molding machines...).

[0033] These manufacturing machines, or industrial machines, include for example sensors, which are functionally connected to the control means or controller, the latter then being functionally connected to the data storage server.

[0034] The 100 factories integrate within themselves multiple physical industrial assets, including industrial machines, industrial control systems, programmable logic controllers (PLCs), or computer numerical controls. These physical industrial assets are part of the operational technologies and implement industrial processes. These industrial processes then enable the manufacturing and / or assembly of mechanical parts, in this case automotive parts, and create added value.

[0035] In particular, the example of an industrial screw-driving process is considered here, without limitation. The implementation of this process requires industrial equipment or machines, in particular, screw-driving machines or screwdrivers 101, 102, 103. For example, these may be robotic screwdrivers or manual screwdrivers.

[0036] Furthermore, in the case of robotic screwdrivers, these screwdrivers can be automated and programmed to perform a series of predefined tasks, or they can be controlled by an operator.

[0037] Here, we consider an industrial screw-driving process using, for example, three different types of screwdrivers 101, 102, 103. In this example, there is a manual screwdriver, operated by hand by an operator, an automated screw-driving robot, and a screw-driving robot operated by an operator. Hereafter, reference is made, respectively, to the first screwdriver 101, the second screwdriver 102, and the third screwdriver 103.

[0038] These screwdrivers 101, 102, 103 come for example from different suppliers or from the same supplier, but are of different models.

[0039] For the purposes of this description, it is also assumed that the three screwdrivers 101, 102, 103 are located within the same factory 100. However, screwdrivers 101, 102, 103 implementation in factories 100% geographically distant from each other is also conceivable.

[0040] These screwdrivers 101, 102, 103 are connected to controllers 111, 112, 113; for example, each screwdriver 101, 102, 103 is connected to a specific controller. Thus, there are first, second, and third controllers 111, 112, 113 associated respectively with the first, second, and third screwdrivers 101, 102, 103. These controllers, particularly for robotic screwdrivers 102, 103, allow for the control and / or operation of actions performed by the screwdriver. In the case of the automated screwdriver, the controller allows, for example, the application of a chosen torque and / or screwing angle, or the control of screwing sequences, etc.

[0041] Screwdrivers 101, 102, 103 also include sensors, these sensors being specific to the type of industrial machine. Thus, the first, second, and third screwdrivers 101, 102, 103 include sensors such as temperature sensors, angle sensors, speed sensors, and torque sensors, etc.

[0042] These sensors can also be external to the industrial machine on which a measurement is taken.

[0043] In this example, it is assumed that each of the screwdrivers 101, 102, 103 includes both a temperature sensor, an angle sensor, a speed sensor, and a torque sensor.

[0044] These different sensors are connected to the controllers 111, 112, 113, that is to say that the sensors are likely to send information to the controllers 111, 112, 113, for example, via a wired or wireless connection.

[0045] The controller 111, 112, 113 receives data (industrial data) which is measured by the sensors. This industrial data is stored in a memory space that may be permanently or temporarily allocated. The location of this memory space, also called the physical address or physical allocation address, and the format of the industrial data depend on the screwdriver in question, but also on the controller associated with it, particularly the software installed on the controller and the communication protocol used. It is understandable that two screwdriver manufacturers would unfortunately not use the same standard data format.

[0046] Furthermore, data such as the date and time are also stored in a memory space allocated on each of the controllers 111, 112, 113. Thus, the industrial data collected are time-stamped.

[0047] For example, on the second screwdriver 102, the angle sensor measures a data point (or value) of the screwing angle applied by the screwdriver and transmits the measured data to the second controller at regular time intervals. Thus, each The value of the angle measured on the second screwdriver 102 is associated with a time data, for example the date and time of measurement.

[0048] A list, for example in Extensible Markup Language (XML) format, comprising, in a first column, a time data, corresponding to the date and time, given for example under the ISO 8601 standard, and in a second column, the screw angle data sent by the angle sensor, is recorded by the controller.

[0049] Industrial data, in particular data identifying the industrial machine on which the measurements taken by the sensor were acquired, are also pre-recorded, or recorded by the controller, in the same way as the previous examples. This includes, for example, information regarding the model and / or brand, serial number, etc., of the industrial machine in question.

[0050] Furthermore, industrial assets, for example, screwdrivers 101, 102, 103, exhibit a certain organization in order to implement a process. In the automotive industry in particular, these processes aim to create added value around motor vehicles by manufacturing mechanical parts to be integrated into them.

[0051] Thus, the industrial screwing process using the three screwdrivers 101, 102, 103 described above can take place at several stages, for example in the assembly of a motor vehicle.

[0052] These stages are described herein by the term "operation." In particular, the production of a motor vehicle comprises a succession of several operations OP600, OP630, each of these operations corresponding to the manufacture of a part. For example, a first operation OP600 consists of manufacturing the engine, and a second operation OP630 corresponds to the installation of the wheel arches.

[0053] Each operation then has at least one station, which corresponds to a step in the implementation of an operation. For example, it could be a wheel-screwing station, taking place during the second operation, or an oil filling station for the first operation OP600.

[0054] Finally, each station comprises at least one process. These processes, for example, in the case of the oil filling station, include a weighing process, a filling process, and a screwing process. Each of these processes involves industrial assets, including industrial equipment and controllers. Most often, each process involves its own specific industrial assets.

[0055] Here, it is considered that these two operations OP600, OP630 implement industrial screwing processes using at least one of the three industrial machines described above, i.e., the first, second and third screwdriver 101, 102, 103.

[0056] For example, the first operation OP600 includes an oil filling station ST01. This station ST01 includes a series of mechanical processes, including for example a process for screwing the oil cap, implementing the first screwdriver 101 for example.

[0057] The second operation OP630, related to the installation of the wheel barrels, comprises two stations, a rapid screwing station, identified as station ST01 and a torque screwing station, identified this time as station ST02.

[0058] Each of these stations ST01 and ST02 involves an industrial screwing process.

[0059] For example, station ST01 includes the rapid screwing process, implemented by the second screwdriver 102 here.

[0060] Station ST02 includes the process of screwing to the desired torque, implemented by the third screwdriver 103 previously presented.

[0061] Thus, as the OP600, OP630 operations are carried out by the operational technologies, the structure of which has been described above, the different processes implemented by the different industrial assets (industrial machines in particular) generate industrial data, which is collected by the data collection system 1.

[0062] The operational technologies (known as OT) contained in the manufacturing and / or assembly plant 100 in which the data collection system 1 illustrated in [Fig.1] is applied are complemented by information technologies (known as IT).

[0063] Once generated by sensors from physical measurements, industrial data exists in digital and dematerialized form. It is then managed by information technologies. These information technologies enable the control, management, and / or security of industrial data.

[0064] Thus, following their collection by the controllers 111, 112, 113 associated with the various screwdrivers 101, 102, 103, the industrial data is transmitted to a computer server associated with at least one database, in order to be stored and used. Various examples of using the industrial data thus collected are described alongside a data collection method in the remainder of this description.

[0065] For example, industrial data is routed to a server, more specifically a remote server 140, here, a Cloud platform (or Cloud server), also called a Cloud platform in French, and using cloud computing tools. However, the use of a computer server and at least one database implemented locally at plant 100 is also possible in other embodiments of the industrial data collection system 1 described here.

[0066] According to [Fig. 1], the Cloud comprises a set of physical infrastructures, including remote computer servers, configured to communicate with the computer infrastructures specific to each of the factories 100, via a computer network, for example a private internet network. Thus, industrial data can be exchanged between the factory 100 and the remote server 140.

[0067] For example, in the first embodiment, the controllers 111, 112, 113, in particular the first controller, the second controller and the third controller, associated respectively with one of the three screwdrivers 101, 102, 103, are connected to a local server 120 implemented in the factory 100. A factory 100 can have a multitude of local servers 120. Here, only one local server 120 is shown in [Fig.1].

[0068] This local server 120 is thus represented in [Fig. 1]. A communication protocol between the local server 120 and the controllers 111, 112, 113 connected to the screwdrivers 101, 102, 103 depends on the controller 111, 112, 113 and / or the screwdriver 101, 102, 103. It may be, for example, a Modbus TCP / IP, FTP, TGC, OPC DA protocol or proprietary protocols, depending, for example, on the software installed on the controller.

[0069] Due to the heterogeneity in industrial machines, these varied communication protocols are not necessarily interoperable.

[0070] This local server 120 is, for example, an OPC UA server, in particular, an OPC UA server with a communication driver. We are referring here specifically to an OPC UA server called, for example, a UDC server, for Unified Data Collector.

[0071] This local server 120 is then connected to a local aggregator 130 via a network, for example a local area network. In particular, the local aggregator 130 here corresponds to a central server of the factory 100. This central server is responsible for aggregating the communication streams from the various downstream UDC servers.

[0072] Furthermore, the local aggregator 130 also subscribes, via subscription rules, to variables of interest in order to route them to the remote server 140. These variables of interest, i.e., the collected data, are then processed by the remote server 140 according to various data processing methods. Thus, thanks to the subscription rules defined on the local aggregator 130, only the data actually needed by one or more clients is sent to the remote server 140. In practice, subscribing to data of interest is handled by the OPC UA protocol.

[0073] The local aggregator 130 of each of the factories 100 is connected to the Cloud platform or remote server 140 described above. In particular, this connection is carried out using the internet network, for example via fiber optic connections. Indeed, the amount of industrial data collected using the system described above reaches substantial volumes, even at the scale of a single factory. For example, approximately 800 gigabytes of industrial data are collected per day.

[0074] The entire system 1 described, comprising both an operational part, linked to the implementation of industrial processes or procedures, and a computer part, linked to the infrastructure necessary for the collection of industrial data generated within the processes, enables the implementation of the industrial data collection method.

[0075] This method of collecting industrial data aims in particular to make industrial data collected interoperable from the moment they are sent to the Cloud platform, by standardizing them from the moment of collection.

[0076] This interoperability offers several technical advantages. Indeed, interoperability through standardization makes it easy to exchange industrial data collected on a diverse range of industrial machines, each with different communication protocols and / or data formats.

[0077] Furthermore, interoperability represents a gain in the quality of the data collected, since subsequent translation of this data to make it compatible with a system and / or device and / or protocol is not necessary. However, these translations or transfers lead to corruption of the quality of the collected data.

[0078] Next, the routing, storage and access to industrial data on the Cloud platform or remote server 140 is facilitated.

[0079] Indeed, the routing of data collected according to the proposed method is limited to access points or data collection points. A hierarchical organization of industrial data, using data models 3, allows industrial data to be collected at upstream collection points, so as to simultaneously collect all downstream industrial data. In other words, data with logical links between them can be collected simultaneously. This allows for a significant increase in the amount of data that can be collected by a manufacturer within its factories 100.

[0080] The data collection rate is also increased, allowing, for example, real-time data exploitation and / or more precise temporal monitoring of the various industrial processes.

[0081] In addition, the method makes it possible to reduce any redundancies around the data, which results in a reduction of the storage memory spaces required within the Cloud platform.

[0082] Moreover, the access costs for customers, i.e. operators of the collected industrial data, to the Cloud platform are advantageously reduced thanks to the implementation of the method.

[0083] The industrial data collection method is illustrated in [Fig. 2]. This method comprises a preliminary step S0, a first step SI, a second step S2, and a third step S3. Details of the implementation of steps S0 and SI are shown in [Fig. 4]. In particular, links are established with the physical elements of the data collection system 1 and / or the software means used.

[0084] For descriptive purposes, this method is applied in a first embodiment to the collection of industrial data on one of the industrial screwing processes described above.

[0085] In particular, we are interested here in the collection of industrial data related to the first operation OP630 of installing the wheel barrels, and to the two stations included in this operation. These two stations use the second screwdriver 102 and the third screwdriver 103.

[0086] The proposed method for collecting industrial data in an organized and standardized manner is based on the technical implementation within the industrialist's IT infrastructure of a data model 3.

[0087] As shown in [Fig. 3], this data model 3 allows industrial data to be presented in a defined format, notably by hierarchizing it. Data model 3 thus structures industrial data in an optimized way, for the purpose of its collection and storage on the Cloud platform.

[0088] This method therefore consists of applying the data model within a factory 100 or a group of factories 100, through the data collection system 1.

[0089] This data model 3, once physically instantiated, i.e. programmed in such a way as to specify its parameters such as type and / or address, within the computer infrastructure of the industrial manufacturer's fleet of 100 factories, allows the collection of industrial data in a structured, standardized, and contextualized manner.

[0090] To this end, the physical instantiation of the data model 3 within the IT infrastructure takes into account rules established upstream to structure a digital modeling chain. This digital modeling chain ensures a transformation from a conceptual data model 30 to the physical data model 32, that is to say, the data model 3 physically instantiated within the IT infrastructure.

[0091] The digital modeling chain has two functions: a model design function, through the conceptual model and a logical model, and then a model implementation function, through a physical model. The latter, being instantiated on the computer structure, allows the implementation of the proposed method 2.

[0092] The model design function establishes a set of conceptual rules, taking into account the processes and / or station and / or operation, and their integration within plants 100. These rules also take into account the operators and teams of operators implementing or controlling these processes and / or stations and / or operations.

[0093] For this purpose, the model design function has two aspects, the conceptual aspect (through the conceptual data model 30) and the logical aspect (through the logical data model 31).

[0094] Establishing the conceptual data model 30, or conceptual model, constitutes a preliminary step S0 of the method, since the conceptual data model 30 affects the technical implementation of the data model 3 instantiated within computer technologies.

[0095] The conceptual data model 30 makes it possible to establish a data model 3 taking into account both the specificities of each process and / or station and / or operation.

[0096] On the other hand, the conceptual data model 30 reduces to a minimum the variables required for the data model 3. These variables allow, for at least some of them, the representation of different industrial data, which are sometimes common over several processes and / or stations and / or operations, such as, for example, a rotation speed variable, or a screw angle variable.

[0097] Thus, in the preliminary step S0, a logic or standard for structuring industrial data is defined. This corresponds to a process-oriented vision, rather than an equipment-oriented vision.

[0098] This structuring standard determines a hierarchical structure of the collected industrial data, and this structure is retained until the industrial data is routed to the remote server 140, i.e. the Cloud platform.

[0099] The management of the hierarchy of industrial data at the local server 120 and local aggregator 130 levels is handled by the OPC UA protocol. This protocol links the different nodes using reference information and identifiers. Here, the term "node" is used in its technical sense within the OPC UA protocol. Specifically, nodes correspond, for example, to objects, including variables, classes, and references. Each node represents a basic piece of information within the OPC UA protocol.

[0100] Between the local aggregator 130 and the remote server 140, the hierarchical structure of the data is preserved, for example, through a prefixing system. Indeed, prefixing the variables (i.e., the collected industrial data) allows the hierarchy established in the OPC UA protocol to be maintained within the MQTT protocol implemented on the remote server 140.

[0101] The structuring standard adopts a similar organization to that used in the operational part, described above. Thus, the industrial data is organized conceptually as follows:

[0102] A third class, corresponding to an operation class or operation type, allows operations to be represented, such as the first operation OP600 or the second operation OP630. This operation class is linked by a logical hierarchical link to a second class or several second classes (or types) representing stations ST01 or ST02.

[0103] Each of the station classes is then linked to one or more third classes, corresponding to process classes, which, once instantiated, will correspond, for example, to one of the screwing processes described previously. Finally, each process class is linked, by a logical hierarchical link, to one or more phase classes.

[0104] These classes or types define models on the basis of which objects are instantiated.

[0105] Each of these hierarchically organized classes, linked by logical relationships between them, is then associated with various complementary data, representing, for example, industrial machines or tools, information about a manufactured part, a location, or controllers 111, 112, 113. The hierarchical organization of the classes is designed to replicate the existing hierarchy in industrial processes. This class hierarchy then allows for the hierarchical organization of objects instantiated based on these classes.

[0106] The transformation of this conceptual hierarchical structure into a physical instantiation is described below.

[0107] Furthermore, during this preliminary S0 stage of designing the data model 3, standardized naming rules are also established for the variables or data collected.

[0108] This effort to standardize variable names has the technical effect of contributing to the interoperability of the collected technical data, and thus facilitating its use by clients accessing the remote server 140 (Cloud platform). Furthermore, this effort helps limit potential variable redundancies, which represents a cost saving for clients. In particular, clients only subscribe to (i.e., are connected to) specifically chosen variables, as is customary in the operation of such remote servers 140. Client subscription is made easier thanks to the standardization of variable names.

[0109] The standardization effort results in the establishment of a single dictionary of variables 40.

[0110] Establishing such a unique dictionary of variables 40 requires modeling workshops.

[0111] These modelling workshops bring together modelling experts and industrial process experts, whose function is to select and formalise the variables to be included in the instantiated physical data model 32.

[0112] These selected variables must meet the needs of the data customers, i.e. the operators of the industrial data collected according to this method 2. These selected variables are then added to a list of pre-existing variables.

[0113] During the modeling workshops, the formalization of variables consists of finding a name for each variable to be integrated into a data model 3. This variable name must be unique and easily understandable for the subsequent use of the variable. The use of prefixes, for example, clarifies the context surrounding the variable in question. In order to avoid duplication of variable names, it is also verified that the chosen variable name does not already exist within the single dictionary of variables 40.

[0114] Thus, the OP600, OP630 operations, including screwing processes, are described by variables specific to this type of process, such as variables corresponding to a torque (Torque), an angle (Angle), identification key (Idkey), tool serial number (ToolSerialNumber), last calibration date (LastCalibrationDate), etc.

[0115] Other variables are common to other operations and / or stations and / or processes, and are therefore reused. For example, the variables Speed, Tolerance, and Cycle are shared between screwing and milling processes.

[0116] The naming of these common variables is defined during the modeling workshops, in particular, during the formalization of the variables. Furthermore, prefixes and suffixes can be added to the names of the selected variables to allow for data contextualization. This data contextualization is redundant with the hierarchical structure, which also fulfills this role. However, this data contextualization via specific naming rules advantageously ensures the preservation of the hierarchy imposed on the data collected by the data model, even when the protocol used does not allow it, for example at the remote server level.140

[0117] For example, the selected variable Speed ​​can be suffixed and / or prefixed with the following prefixes and / or suffixes: CMD (for control variables), Min, Max, Final (for variables corresponding to a measured final value), Act (for variables corresponding to a current value), etc.

[0118] These prefixing and / or suffixing rules have the advantage of being able to aggregate data, even before the application of method 2. For example, to retrieve variables from a tool belonging to a specific process, the variables can be prefixed as follows: Station_ <nr>_Process_ <nr>_Tool_ <nr>_ID, where the values <nr>are replaced by process, station and operation identification codes.

[0119] This prefixing of the collected variables advantageously allows the established hierarchical structure to be preserved, and in particular the dependencies between the different variables, in order to contextualize them.

[0120] The design of the data model 3, taking place in a preliminary step S0 of the proposed method 2, also includes the establishment of modularity rules.

[0121] These modularity rules, once instantiated and applied within data collection method 2, facilitate its scalability. Indeed, the modularity rules make it possible to limit the number of different data model types (i.e., classes) 3.

[0122] When designing a data model 3 for a chosen operation, the variables, particularly those selected and formalized during the modeling workshops, are classified into two distinct categories. Two types of variables are then distinguished in the conceptual model: generic variables and specific variables.

[0123] Generic variables are variables that can be reused for other processes, stations, or operations. Typically, variables used for filling an engine's oil sump (filling speed, maximum volume, etc.) can be reused for filling any other container with any other liquid (fuel, coolant, etc.).

[0124] Specific variables, on the other hand, are specific to a process, a station, or an operation, and cannot be used elsewhere. For example, in the screw-driving process, variables such as angle or temperature are applicable to many other processes. Conversely, variables such as those related to the screwdriver are specific to the screw-driving process and cannot be reused elsewhere.

[0125] To further facilitate modularity, it is also proposed in the preliminary step S0 of setting up the data models to divide them into blocks, these blocks corresponding either to generic blocks or to specific blocks. These blocks contain variables from the single variable dictionary, and a distinction is made between specific blocks, containing specific variables, and generic blocks, containing generic variables.

[0126] Variables used within several processes are included in generic blocks, while variables specific to a process are integrated into specific blocks.

[0127] This distribution of variables according to these two categories advantageously reduces the complexity of data modeling, in particular, the creation of new data models. Indeed, the variables needed for modeling an industrial process are grouped into categories that can be reused for other industrial processes with similarities.

[0128] Thus, to model an industrial process within a factory 100, a data model is created by agglomerations of generic bricks and specific bricks.

[0129] Moreover, scaling up is easier to achieve, since to build a new data model, for new processes, already established building blocks can be used.

[0130] Advantageously, the data models 3 are established from specific and / or generic building blocks, these containing variables that come from a single variable dictionary 40, and are organized hierarchically according to a process-oriented structure, offering a high degree of modularity. Thus, advantageously, a wide variety of industrial processes can be represented by data models established following the digital modeling chain. The number of different model types is nevertheless limited, which reduces the need to create new data models to account for new processes, and also results in data models that are easier to maintain and / or update, and easier to scale.

[0131] For example, to model the first and second operations OP600, OP630, generic building blocks, shared by the two corresponding operation classes, are as follows:

[0132] A brick containing the variables of an OPC UA library, an internal industrial brick containing a library of variables common to all the industrial processes, a brick called "Industrial Asset" or industrial asset, linked to factories 100 for example vehicles and mechanics.

[0133] Next, the operation class associated with the first operation OP600 has its own specific building blocks. For example, building blocks containing variables related to the engine, in particular, to oil filling.

[0134] Similarly, the operation class associated with the second operation OP630 has specific bricks, such as a brick related to screwing.

[0135] Once its conceptual form is established, the data model 3, obeying the conceptual rules defined above, is instantiated on the infrastructures, for the implementation of the data collection method.

[0136] Instantiation includes integrating the models into the IT infrastructure, defining variable types, and connecting the variables to corresponding physical addresses on the different industrial machines, which constitutes the operational part.

[0137] The implemented physical data model 32 has the advantage of addressing the plurality of communication protocols used within the operational part, and allows the industrial data collected by the controllers 111, 112, 113 to be routed to the form platform in a single format, namely that of the OPC UA protocol. This protocol, already mentioned previously, preserves the semantics and hierarchical structure of objects, particularly variables (i.e., nodes, in the technical vocabulary associated with this OPC UA protocol).

[0138] The transition from a conceptual data model 30 to a logical data model 31, in a format understandable by a computer system, is done using a standard, via a modeling tool.

[0139] For example, the chosen format corresponds, for instance, to the XLM format, and the standard corresponds to the OPC UA modeling standard. Alternatively, in other embodiments, other standards may be adopted, although existing prior art standards are currently less optimized than the OPC UA protocol.

[0140] The modeling tool corresponds to a computer tool enabling the implementation of the conceptual data models 30 on the local server 120. In other words, this computer tool allows the definition of the types (or classes) required in the OPC UA protocol, such as, for example, the operation classes, the station classes, and the process classes.

[0141] During this step of setting up the logical data model 31, the modeling tool also defines hierarchical links between the established classes.

[0142] For example, it is decided to impose a rule according to which a process class is necessarily contained in a station class, and that a station class is necessarily contained in an operation class.

[0143] The modelling tool refers, for example, to a commercial UML (Unified Modelling Language) modelling and design software.

[0144] Thus, for each conceptual data model 30, corresponding for example to a specific process, a logical model is created. In this logical model, the variables, their type, and the structures are established.

[0145] For example, in the first station ST01 of the first operation OP630, the second screwdriver 102 is used in a process. Thus, in the logic model, the process, here screwdriving, is defined as a class. This class includes attributes (or variables), such as an identifier, a torque, and a rotational speed. Each attribute has a type (for example, a string). In English, a floating-point number or float...and one or more (floating) values ​​for the identifier, torque, and rotation speed respectively.

[0146] The variables used for the logical data model 31 are drawn from a variable database, which incorporates the single variable dictionary 40 established previously. Within this computer database, stored in a memory space on the local server 120, pre-existing variables are stored and classified as generic and specific. These variables are aggregated into modular components, comprising specific and generic components. The logical data model 31 is constructed by assembling these components, according to the modeling needs of each industrial process.

[0147] Similarly, a station class is defined, and includes variables of a type. For example, the station class here includes variables related to a manufactured part, for example, a unique identifier, in the form of a string.

[0148] The same applies to operations OP600, OP630, also represented on local server 120 by an operation class, including variables, such as a location variable, in the form of a string.

[0149] In order to maintain the structuring standard defined for the conceptual data model 30 in the logical data model 31, the conceptual hierarchy established between process classes, station classes and operation classes is maintained, in order to reflect the organization of operational technologies.

[0150] To achieve this, logical links are created between the operation classes, the station classes, and the process classes. For example, a possible logical link is the notion of hierarchy, as is used in the OPC UA protocol. Thus, it is defined in the local server 120 that a process class is linked to a station class, the station class being itself linked to an operation class.

[0151] In the OPC UA protocol, these logical hierarchical links between nodes, including classes, objects, variables, etc., are managed through reference information and identifiers linking the nodes to each other.

[0152] The logic model is implemented in the computer infrastructure of plant 100, in particular within the OPC UA server in the first embodiment.

[0153] In order to collect industrial data, the first SI step of method 2 includes an instantiation of the conceptual data model 30 on the industrial manufacturer's IT infrastructure. In other words, the instantiation of the model consists in particular of linking variables of the logical data model 31 to a physical address corresponding to these variables.

[0154] A first sub-step SI 1 consists of taking into account physical or material constraints.

[0155] Variables, whose type and structure have been defined in the logical model, are thus associated with their physical address, that is, the physical address of the corresponding variable allocated in a memory location of the controller. This physical address, also called here the machine physical address, indicates a location where a variable is stored in a machine of a specific make and model. Thus, for the same industrial process, therefore modeled by the same data model 3, an instance can be different from one brand of industrial machine to another, because the physical addresses can be different.

[0156] In order to carry out addressing, that is to say the association between a variable and its physical address in order to achieve the instantiation of the physical data model 32 on the local server 120, software tools implemented by the industrialist's IT infrastructure are used here.

[0157] It is this addressing, physically linking an organized and contextualized variable according to an ordered structure by means of the conceptual data model 30 and the logical data model 31, with its physical address, which makes it possible to retrieve data from industrial machines in a structured way for example by the OPC UA protocol.

[0158] The first SI step involves a software tool for configuring assets or industrial resources.

[0159] In practice, when a logical data model 31 is defined, it is loaded into a project which is exported to the local server 120, i.e., the OPC UA server. The asset configuration software tool assists in instantiating the logical data model 31, transforming it into a physical data model 32, taking into account the hardware requirements present within the plant 100. During instantiation, the asset configuration software tool is used to select the type of data model to load onto the local server 120, which protocol to use, etc.

[0160] This asset configuration software tool creates 4L configuration drivers for each of the models associated with an operation

[0161] These configuration drivers manage address mapping. This address mapping software tool automatically maps variables from data models to physical addresses on industrial machines. Without these drivers, specific development must be carried out for each type of process.

[0162] These configuration drivers 41 connect, for a specific piece of equipment used in one of the processes of an operation, the variables of the model instantiated on the local server 120 (i.e. the OPC UA server), and the physical address of the required variables.

[0163] These configuration drivers 41 are specific to industrial equipment, for example to their type, brand, model, etc. In particular, they allow the automatic connection between variables and physical addresses.

[0164] For this purpose, the configuration drivers 41 rely on a computer library 42 containing addressing information for the various industrial equipment in the operational part. This computer library 42 is also called the physical address database.

[0165] The content of this physical address database includes archiving information for different makes, models, etc., of the various industrial equipment in the operational section. The content is thus established based on the industrial equipment of plant 100. From this computer library 42, the configuration driver 41 returns an addressing script. This addressing script contains, for a variable searched on a given piece of equipment, a physical address for allocation.

[0166] For example, in system 1 described above, computer library 42 contains addressing information for the first screwdriver 101, the second screwdriver and the third screwdriver 103.

[0167] The value manager 41, for the first, second and third screwdrivers 101, 102, 103, indicates for each of the variables, the associated physical address (which depends on the controller used in each screwdriver).

[0168] For example, for the first screwdriver 101, the value manager 41 returns, among other things, a physical address IA for the identifier variable, a physical address 2A for the torque variable, and a physical address 3A for the rotation speed variable. The same applies to the second screwdriver 102, where the physical addresses IB, 2B, and 3B are returned, and to the third screwdriver 103, with the physical addresses IC, 2C, and 3C.

[0169] Finally, the data model 3 is instantiated on the local server 120, in its physical form. In particular, in the embodiment described, and in accordance with the system 1 detailed previously, the data model 3 is instantiated on the local OPC UA server, located upstream of the data aggregator 130.

[0170] The first instance SI step therefore includes a second substep S12 focusing on instantiating the model in the OPC UA server. This step consists of creating an instance of the data model 3 corresponding to the machine on which data is collected. In practice, this involves, for example, instantiating objects corresponding to the operation, station, and process classes for the industrial process in question.

[0171] This instantiation is done using a software tool. This tool is referred to here as the server configuration software tool 50, or instance configurator.

[0172] The server configuration software tool 50 performs, in particular, settings such as a choice of location, a choice of data model according to the operation / station / process to be modeled, as well as a choice of configuration drivers 41 according to the industrial machines used in the operation to be modeled.

[0173] By choice of location, it is understood in particular to mean a geographical location of plant 100.

[0174] This local server configuration software tool 120 takes as input a physical data model 32, that is, the logical data model 31, whose physical addresses of variables are indicated by means of pre-registered configuration drivers 41, as well as addressing scripts, or connection scripts. These connection scripts or addressing scripts are generated from the computer library 42 containing the addressing information.

[0175] The local server 120 configuration software tool 50 generates the instantiation of the data model 3 on the industrial manufacturer's IT infrastructure, more specifically, the instantiation on the local server 120 to a given factory 100.

[0176] Instantiation is performed on the local server 120, here an OPC UA server, which loads the data models and enables data collection according to the corresponding OPC UA protocol. This OPC UA server then collects, in a structured manner, the data on the various controllers 111, 112, 113 associated with the different devices.

[0177] Files (here, two) are generated during instantiation, for a given operation.

[0178] This instantiation is carried out upstream of the data collection, and remains functional as long as the operation for which the data model is instantiated does not undergo any modification.

[0179] Furthermore, during instantiation, a class is customized according to the needs of the process in question. For example, a process class, corresponding to a screwing process, can be instantiated in an operation corresponding to screwing on the oil cap, and then the same class corresponding to a screwing process can be instantiated for another operation, for example, an operation to screw on the wheel nuts. This results in two instances of a customized class in order to collect data on two distinct but similar operations.

[0180] The files generated by the configuration software tool 50, also called instantiation files 51, are used by the local server 120 for data collection, which is the subject of the second step S2 of method 2.

[0181] For the operations of an industrial manufacturer, these instantiation files 51 all share the same format and are communicated to the local server 120 via the same communication standard. Here, the instantiation files 51 are all in XLM format.

[0182] In this example, a first instantiation file is designated as the instance NodeSet, according to the common terminology in the OPC UA protocol. This first instantiation file contains the configuration of the instance of the data model of the machine on which the data is collected. This first instantiation file is loaded by the local server 120, here the OPC UA server.

[0183] In particular, this instance NodeSet file used by the OPC UA server specifies the structure and data characteristics.

[0184] This facilitates interoperability and communication between different devices and applications, by standardizing the representation of information.

[0185] The second file is a configuration file that allows the physical connection of variables instantiated in the local server 120 and the industrial machines. The connection is made via communication protocols specific to each of the industrial machines, and using appropriate connection methods.

[0186] For example, in the case of the screw-driving process, the first screwdriver 101 is connected to the first controller. This is then connected to the local server 120, as described in for the associated system 1.

[0187] The second step S2 of the method includes the actual collection of industrial data.

[0188] This second step S2 is illustrated by the example of the second operation OP630, of setting up the wheel barrels.

[0189] The data model 3 of such an example has been described previously.

[0190] This second operation OP630 comprises a first and second station ST01, ST02, each of which includes a screwing process, using two different industrial machines.

[0191] The two stations ST01 and ST02 operate sequentially. A part, for example, here a nearly assembled vehicle, moves from the first to the second station via a sled, that is, a platform on which the vehicle rests. This platform moves automatically from one station to the other.

[0192] Thus, at the first station ST01, the second screwdriver 102 intervenes, as part of a screwing process.

[0193] The data are then collected according to the instantiated physical data model 32, allowing the acquired data to be prioritized according to these models when they are sent back to the local server 120.

[0194] Indeed, in the OPC UA protocol, the hierarchical organization of objects according to a tree structure is managed by references linking the objects to each other. This The data tree, for example, includes branches defining levels of the hierarchical structure.

[0195] Thus, in the OPC UA architecture, it is possible to collect industrial data at the branch level, which correspond to data collection points.

[0196] These data collection points correspond, for example, to memory areas. At a given collection point, variables, logically linked by a hierarchical relationship defined by the data model 3, are combined into a set or aggregate so that they can be collected simultaneously from a corresponding memory area. The data collected at the same data collection point are hierarchically dependent on the same object, i.e., the same branch of the tree. In other words, the data or variables combined to form the set are hierarchically linked to one another.

[0197] Here, industrial data are collected according to three levels or collection points: a level or collection point corresponding to the operation, a level or collection point corresponding to the station and a level or collection point corresponding to the process.

[0198] By collection point corresponding to an operation, station, or process, it is understood that a memory area combining the dependent variables of a given operation class, station class, or process class is defined as follows. In other words, these variables, which are combined for the purpose of collection, are those contained within the same class.

[0199] Thus, data associated with a collection point or operational level, including data related to controller variables, means of production, and geographical location, are sent back to the local server 120, via dedicated connection means.

[0200] In particular, this data can be collected regularly, for example whenever its value changes. The collection and storage of industrial data is done in a single format, for example, in a time series format.

[0201] Data corresponding to the station collection level or point are also sent back to the local server 120 in the same way. A station contains, for example, an instantiated object corresponding to a manufactured part. This object includes variables such as its unique identification number. The station also contains an instantiated object corresponding to a resource unit. This resource unit represents a water supply and thus includes variables such as the water flow rate and temperature.

[0202] Finally, data related to a process collection level or point is sent back to the local server 120. Here, the screwing process includes the following variables: identifier, torque, rotation speed.

[0203] Since the physical addresses of the different variables are known to the server, the variables are collected in an organized manner at the indicated addresses, and organized according to the nodes. Thus, the collected data is organized, contextualized, and also interoperable.

[0204] This data is transmitted at regular intervals, for example, based on the performance of the protocol or communication language used (periodic polling, automatic notification of state changes from the controller on which data is collected), or as soon as a change in value is detected. The transmitted data is associated with temporal information by the local server 120, synchronized with a time server.

[0205] Once the various processes of the first station have been executed, the sled (or transport platform) moves the motor vehicle to the second station. There, too, industrial data is collected during the execution of the processes. In particular, for the screw-driving process operated by the third screwdriver 103, the following industrial data is collected, again according to the defined collection points: - Data linked to an operational collection point, including data related to controller variables, production means, and geographical location, is sent to the local server 120 via dedicated connection methods. - Data linked to the station collection point, as well as variables corresponding to a machined part and a resource unit. - Data related to the process collection point including the following variables: identifier, torque, rotation speed.

[0206] The structure and content of data model 3 is identical to that of the first station. However, the physical address of the industrial assets differs, as does the temporal information.

[0207] The data collected in the form of data model 3 are then routed in a third stage S3 from the local server 120 to the remote server 140, via the local aggregator 130.

[0208] As mentioned previously, this local aggregator 130 aggregates the communication streams from the local server 120. In addition, the local aggregator 130 also manages subscriptions to variables of interest, in order to communicate them to remote servers.

[0209] The local aggregator 130 also allows for preliminary sorting of the data to be sent to the remote server 140, by subscribing only to the data required by data clients. Indeed, storing data on the remote server 140 represents a significant storage cost. Thus, although all collected data is routed to the local server 120, i.e., the OPC UA server, a sorting process is performed at the local aggregator 130 level to avoid flooding the remote server 140 with data not used by clients.

[0210] This sorting is performed via subscriptions defined by subscription rules and managed by the local aggregator 130. However, collecting all the data by the local server 120 proves advantageous when a new use case arises. Indeed, the local aggregator 130 can then subscribe to new variables, since they already exist and are collected by the local OPC UA servers.

[0211] Furthermore, prefixing the collected variables according to the rules established during the development of the conceptual data model 30 allows the hierarchical structure defined between the variables, previously handled by the OPC UA protocol, to be preserved. Thus, even if the remote server 140 uses a different communication protocol, for example, an MQTT protocol, the collected variables remain contextualized.

[0212] There are many possible uses or applications for this method. In particular, but not limited to, predictive maintenance, condition-based maintenance, traceability, or performance monitoring.

[0213] In a first embodiment of use of the method, a case of quality control using the proposed data collection method 2 is described.

[0214] In this first embodiment, the method is used to collect industrial data at regular time intervals. Here, we are particularly interested in the first station of the first operation OP630 described above.

[0215] The industrial screwing process implemented in the first station ST01 uses the second screwdriver 102.

[0216] As described previously, the local server 120 collects industrial data at regular time intervals via the application of the proposed method. In particular, this data consists of rotational speed data, measured by a dedicated screwdriver sensor.

[0217] These rotation speed data, time-stamped, are collected by local server 120, aggregated by aggregator 130, before being sent to remote server 140.

[0218] This data is then analyzed, in particular through graphical processing.

[0219] An example of a time curve of the rotational speed measured on the second screwdriver 102 is reproduced in [Fig. 5]. This curve represents for The second screwdriver 102, the average speed value over several successive screw operations performed by the second screwdriver 102. Such a curve exhibits, over a time period, a rotational speed defect. The motor vehicles affected by this rotational speed defect are easily identifiable, thanks to the structure applied by data model 3. Indeed, the data is contextualized, and information about the part is linked to the speed, the station, the instrument, etc.

[0220] This makes it easy to track vehicles affected by the rotation speed defect. A fourth step, S4, of the method involves removing vehicles identified as defective through tracking. This results in financial savings due to reduced downtime and / or recall costs.

[0221] Indeed, predictive maintenance can be carried out in a targeted manner on sensitive machines, before a breakdown occurs, thereby reducing or even eliminating downtime. Furthermore, a malfunction is more easily detected during the production cycle, before the vehicles are marketed. Costly recalls, which are also detrimental to the manufacturer's image, are thus avoided.

[0222] These monitoring operations take place, for example, in real time and are contextualized by the data model 3. Indeed, this contextualization during collection reduces the costs of accessing the data.

[0223] The standardized data model also makes it possible to increase their deployment speed on a wide variety of industrial processes, plants, but also on different controllers and automation components.

[0224] More generally, all use cases implementing the proposed method 2 present a simplified data exploitation. Indeed, since the data is transmitted in an interoperable format to the different clients, it is then possible to develop generic algorithms, valid for any type of data, regardless of the operation concerned.

[0225] The present invention is in no way limited to the embodiment described and represented, but a person skilled in the art will be able to make any variation in accordance with the invention.< / nr> < / nr> < / nr> < / nr>

Claims

Demands

1. Method for collecting industrial data within a plant (100), said plant (100) comprising at least one piece of industrial equipment adapted to perform at least one industrial process within a station (ST01), included in an operation (OP600; OP630), said method comprising the following steps: - instantiation of a physical data model (32) on a local server (120), said physical data model (32) having a hierarchical structure in which at least a first class comprises variables related to the industrial process, a second class comprises variables related to the station (ST01, ST02), and a third class comprises variables related to the operation (OP600, OP630), said first class being hierarchically linked to said second class, and said second class being hierarchically linked to said third class, each variable having a type and a physical address (IA, 2A,3A) allocation of a value of said variable on at least one piece of industrial equipment or said station or said operation, said variables being taken from a variable database, - collection of industrial data according to said physical data model (32), for each variable, said local server (120) being connected to said physical address (IA, 2A, 3A) of allocation of said variable, in order to record a value of said variable, - storage of industrial data within a remote server (140).

2. Industrial data collection method according to claim 1, wherein said physical data model instantiation step (32) generates at least one instantiation file on said local server (120) and said collection step is operated in a hierarchical and standardized format and structure using said at least one instantiation file defining said data model (3).

3. Method of collecting industrial data according to any one of claims 1 to 2, wherein said variable database is a database listing pre-existing variables.

4. Method of collecting industrial data according to claim 3, wherein said pre-existing variables comprise generic pre-existing variables and specific pre-existing variables, said generic pre-existing variables being used by a plurality of physical data models (32).

5. Industrial data collection method according to claim 4, wherein said specific pre-existing variables are grouped into a plurality of specific building blocks and said generic pre-existing variables are grouped into a plurality of generic building blocks, said physical data model (32) is constructed by assembling the generic building blocks and the specific building blocks, in order to create said hierarchical structure.

6. Method of collecting industrial data according to any one of claims 1 to 5, wherein the local server (120) on which said physical data model (32) is instantiated is an "OPC Unified Architecture" server.

7. Method of collecting industrial data according to any one of claims 1 to 6, wherein said physical address (IA, 2A, 3A) of allocation of said value of said at least one variable is given by a configuration driver (41), said configuration driver (41) generating an addressing script between a database of physical addresses and said at least one variable instantiated on said local server (120).

8. Method of collecting industrial data according to claim 7, wherein the database of physical addresses is established taking into account said at least one industrial plant equipment (100).

9. A method for collecting industrial data according to any one of claims 1 to 8, wherein the industrial data is collected at three industrial data collection points, each of these collection points corresponding to a memory area, where variables hierarchically linked by the physical data model (32) are combined and collected simultaneously from this memory area, the three industrial data collection points comprising a collection point corresponding to the variables of said first class, a collection point corresponding to the variables of said second class, and a collection point corresponding to the variables of said third class.

10. Method of collecting industrial data according to any one of claims 1 to 9, wherein the industrial data is collected and stored by the local server (120) in a time series format.

11. Method of collecting industrial data according to any one of claims 1 to 10, wherein the method further includes a step of exploiting the industrial data by a customer.

12. Method of collecting industrial data according to claim 11, wherein the data exploitation step includes a step of tracking and identifying parts produced by at least one industrial process.

13. Method of collecting industrial data according to claim 11 or 12, wherein the data exploitation step includes a condition maintenance step on at least one piece of industrial equipment implementing at least one industrial process and / or a recall of parts produced by at least one industrial process.

14. Method of collecting industrial data according to any one of claims 1 to 13, wherein at least one industrial process enables the manufacture of a motor vehicle part.

Images