WO2020119882A1 - Procédé ainsi que système pour la transmission d'un paquet de données de triplets lisibles par machine spécifique à l'utilisation - Google Patents

Procédé ainsi que système pour la transmission d'un paquet de données de triplets lisibles par machine spécifique à l'utilisation Download PDF

Info

Publication number
WO2020119882A1
WO2020119882A1 PCT/EP2018/084197 EP2018084197W WO2020119882A1 WO 2020119882 A1 WO2020119882 A1 WO 2020119882A1 EP 2018084197 W EP2018084197 W EP 2018084197W WO 2020119882 A1 WO2020119882 A1 WO 2020119882A1
Authority
WO
WIPO (PCT)
Prior art keywords
database
data
unit
triples
request
Prior art date
Application number
PCT/EP2018/084197
Other languages
German (de)
English (en)
Inventor
Oliver Drumm
Sascha KUNZ
Original Assignee
Siemens Aktiengesellschaft
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 Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to PCT/EP2018/084197 priority Critical patent/WO2020119882A1/fr
Publication of WO2020119882A1 publication Critical patent/WO2020119882A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • the invention relates to a method for transmitting an application-specific data packet to a request unit, the data packet containing data from a technical system which comprises several components.
  • the invention also relates to a system for transmitting an application-specific data packet, the data packet containing data from a technical system comprising several components.
  • a planning tool can provide data regarding the technical system and its individual components.
  • the planning tool can V orhalten all data up to date and constantly. For this reason, it can make sense to link the planning tool with other sources of information.
  • the invention is based on the idea of converting data from respective databases into a machine-readable and / or machine-interpretable format. This can be implemented, for example, by digital voice assistants, such as those in the area of mobile end devices, in particular so-called
  • Smartphones are known. Such digital voice assistants are able to answer general questions. To do this, it is necessary to interpret a complex language construct and then search for suitable answers in suitable sources. However, in order for a computer to find the correct answer, the knowledge contained in the data, which is implicitly available on the Internet, for example, must be supplemented so that it is machine-readable and / or machine-interpretable. Such an expansion of the Internet is referred to as a semantic network, also with the English technical term "semantic web". In the semantic network, knowledge that is explicitly available is stored in a machine-interpretable manner.
  • Part of the present invention is to transfer knowledge of the semantic network, which are known from the field of mobile devices, to databases of technical systems.
  • the data packets contain data / information from the respective technical system.
  • a first aspect of the invention relates to a method for transmitting an application-specific data packet to a query unit, at least one of two database units, a server device and the query unit being spatially separated from one another, the data packet da contains a technical system, which comprises several components, with the steps:
  • the respective data from the different databases are converted into a machine-readable and / or machine-interpretable format, namely the triple in the present case.
  • the information contained in the respective data can be stored in a tripartite system in the triples.
  • the triples can each have a subject-predicate-object structure.
  • an object and a property can be linked in a particular way by the respective triples.
  • the first database unit can make available the respective triples which are generated by converting the data from the first database.
  • the second database unit can make available the respective triples that are generated by converting the data from the second database.
  • the first and the second database unit thus each convert the data of the respective database into a machine-readable format and provide the corresponding triples that are generated as part of the retrieval.
  • the request unit can be any end device of a user of the technical system.
  • the request unit is a control computer at the location of the technical system.
  • Such a control computer can be designed as a computer, laptop, or any other computing unit.
  • the request unit can be a mobile device, in particular a smartphone or a tablet computer, of the user of the technical system.
  • the request unit is designed to use the request to request an application-specific data packet relating to the technical system from the server device. Depending on the application, this can mean that the request requests specific information for a specific application. Providing such an application-specific data packet can therefore make it necessary to interpret the information contained in the respective triples of the first database unit and the second database unit.
  • each triplet When each triplet is retrieved, a part of each triplet can be retrieved from the first database unit and the second database unit. For example, at least one triple from the first database unit and the second database unit is retrieved by the server device. This is done in particular upon request from the request unit.
  • the respective triples, which are retrieved from the first and the second database unit can be selected based on the information contained therein based on the request from the query unit. For example, the respective triples of the first database unit and the second database unit are each interpreted in relation to the request.
  • the triples suitable for answering the query are then selected in accordance with the respective semantic meaning of the triples. These are then retrieved from the respective database units by the server device.
  • the server device then connects the respective triples from the first and second database units to the data packet.
  • the information contained in the triples can be interpreted.
  • the respective triples are machine-readable and / or machine-interpretable.
  • semantic knowledge can be generated which goes beyond the information content of the respective triples.
  • the linking of the respective triple from the first and the second database unit generates semantic knowledge that goes beyond the respective triple.
  • a formal description language for creating, publishing and distributing ontologies can be used.
  • the data packet can then be transmitted to the query unit in response to the query from the query unit.
  • the technical system can, for example, be a manufacturing plant, a plant in the process industry, for example in paper processing, food processing or building material processing, or a plant in the energy industry, for example for the extraction or processing of petroleum or natural gas products or for production or Distribution of electrical energy, act.
  • the triples which are retrieved from the first database unit, at least partially include system data which indicate which components the technical system comprises.
  • System data relating to the composition of the technical system in relation to the several components can be stored in the first database.
  • the system data can include information about the use or installation position of the individual components in the technical system.
  • the system data are converted by the first database unit in particular into the triples, so that an information content of the first database is provided by the corresponding triples. In this way, the provision of the data can be further improved.
  • the triples which are retrieved from the second database unit, relate exclusively to individual components of the technical system.
  • the data in the second database do not relate to the technical system as a whole, but only to individual components of the technical system.
  • the corresponding triples are thus converted from the data in the second database.
  • the second database or the second database unit is a device of a respective manufacturer of the individual components.
  • the second database or the second database unit thus enables component-specific data relating to the individual components of the technical system to be called up directly from the manufacturer.
  • Data in the second database can contain, for example, certificates, data sheets and / or operating instructions for the individual components.
  • a large number of second data banks and second database units are provided.
  • Each of the plurality of second databases or second database units can be assigned to a respective different manufacturer.
  • triples are retrieved from the several two-th database units, each of which only relates to individual components from the corresponding manufacturer. In this way, the networking of data can be improved.
  • the second database unit is selected for the retrieval of the respective triple, taking into account system data which are retrieved from the first database unit in the form of a respective triple. In other words, the second database unit for retrieving the respective triples is selected based on the system data.
  • the second database unit is selected from a plurality of second database units for retrieving the respective triples.
  • the request from the request unit relates to a specific component of the technical system.
  • the system data can then be used to check which manufacturer the component comes from.
  • the second database unit of the corresponding manufacturer is selected from the plurality of second database units.
  • the data packet is formed from the respective triples by the server device using a description language for ontologies as specified.
  • a description language for ontologies is specified, for example, by the "Web Ontology Language", or OWL for short.
  • the Web Ontology Language is a specification of the World Wide Web Consortium, or W3C for short.
  • the use of such a description language in accordance with the specification can An improved interpretation of the information contained in the respective triples takes place.
  • the corresponding description language can be used to generate the semantic knowledge from the respective triples. In this way, a further improved information content can be provided.
  • the query of the query unit is received by the server device in a format of a graph-based query language.
  • the request from the request unit is received by the server device in a SPARQL-compliant format.
  • the query language SPARQL is also specified by the World Wide Web consortium.
  • SPARQL is a graph-based query language, especially for RDF.
  • RDF Resource Description Framework
  • the data when converting the data of the first and / or the second database, the data are converted into triples that are compatible with a specification-based system for describing resources.
  • the data when the data of the first and / or the second database are converted, the data are converted into RDF-compliant triples.
  • RDF short for "Resource Description Framework”
  • RDF-compliant triples are particularly advantageous for providing machine-readable or machine-interpretable data or triple.
  • the data of the first and / or the second database is converted upon the request of the requesting unit.
  • the data of the first and / or the second database are only converted after the request for the request unit has been received by the server device.
  • only that part of the data from the first and / or the second database that is subsequently called up by the server device is converted in each case.
  • a larger proportion of the respective data of the first and / or the second database can also be converted in order to enable an interpretation of the corresponding data. The interpretation of the respective triples can then be used to determine which of the triples are to be retrieved by the server device.
  • the data of the first and / or the second database are advantageously not completely converted into the respective triples. This can save resources.
  • the respective triples are deleted again after the method has been carried out or after the data packet has been transmitted to the requesting unit. Thus, the conversion takes place again when a new request is made. In this way, the current data is currently available for retrieval.
  • the data of the first and / or the second database are converted independently of the request from the query unit and the triples are stored in the respective database unit.
  • the data of the first and / or the second database in particular completely, are converted into the respective triples.
  • the respective triples are then stored in the respective database unit.
  • the data in the first database are converted into respective triples by the first database unit and stored in the database unit.
  • the data of the second database are converted into the respective triples by the second database unit and stored in the second database unit.
  • the respective triples are then available for retrieval in the respective database unit, regardless of the request from the query unit. In this way it is ensured that a resource-saving call and / or a resource-saving interpretation of the corresponding triples are possible at all times.
  • an increased memory requirement is necessary.
  • the data of the first and / or the second database are repeatedly converted, in particular periodically, independently of the request from the requesting unit.
  • the triples stored in the first and / or in the second database unit are repeated, in particular periodically, based on the data of the respective database. On the- This way it can be ensured that the respective triples always have a predetermined degree of topicality.
  • the first database is the database of a planning tool for planning the technical system.
  • the first database is used to compile or plan the technical system. Even after the system has been completed, data required for operation, expansion and / or maintenance can be called up from the first database.
  • the first database can provide necessary information that enables it to be linked to other information sources, in particular the second database unit or a plurality of first database units, in an improved manner.
  • the planning tool can, for example, be executed locally on a computing device, in particular a computer, of a user or can be provided by a cloud, in particular as a cloud service.
  • the planning tool can be provided by a central server device in the cloud.
  • the planning tool can then be operated via a user interface on a user's end device. For this purpose, corresponding operating data can be transmitted from the user's terminal to the central server device and / or planning data can be transmitted from the central server device to the user's terminal.
  • a second aspect of the invention relates to a system for transmitting an application-specific data packet, the data packet containing data from a technical system, which comprises several components, with
  • a first database unit designed to convert data from a first database into respective triples
  • a second database unit designed to convert data from a second database into respective triples
  • a server device designed to retrieve respective triples from the first and second database unit in response to a request from the request unit, to link the respective triples from the first and second database unit to a data packet and to transmit the data packet to the request unit
  • the data of the first database and the second database each include data of the technical system and / or its components, wherein
  • At least one of the at least two database units, the server device and the query unit are spatially separated from one another.
  • the system is set up to carry out a method according to the invention.
  • the server device is set up to carry out the respective method steps which are disclosed in the context of the method according to the invention for the corresponding server device.
  • Advantageous embodiments and expedient further developments of the method according to the invention therefore also apply to the system according to the invention, even if these are not described again here for reasons of scarcity.
  • the first database unit can comprise a computing unit, in particular a computer, a microcontroller or an integrated circuit.
  • the second database unit can comprise a computing unit, in particular a computer, a microcontroller or an integrated circuit.
  • the server device can comprise a computing unit, in particular a computer, a microcontroller or an integrated circuit.
  • the first and the second database unit each comprise, for example, a computing unit, a storage unit and an interface.
  • An interface can be a hardware or software interface (for example PCI bus, USB or Firewire).
  • a computing unit can have hardware elements or software elements, for example a micropro- processor or a so-called FPGA (English acronym for "Field Programmable Gate Array”).
  • a storage unit can be used as non-permanent working memory (Random Access Memory, abbreviated RAM) or as permanent mass storage (hard disk, USB stick, SD card, solid state disk ) be realized.
  • FIG. 1 shows a block diagram of a system for transmitting an application-specific data packet
  • FIG3 in a schematic block diagram the difference between a virtual and a materialized provision of triples.
  • the system 1 shows a system 1 for transmitting an application-specific data packet 31 with respect to a technical system.
  • the system 1 comprises a request unit 2, a server device 3, a first database unit 4 and a second database unit 5.
  • the request unit 2 makes a request 30 for transmitting an application-specific data packets transmitted to the server device 3.
  • query 30 includes a question regarding the technical system and / or a component of the technical system.
  • the technical system has several components.
  • the server device 3 attempts to retrieve corresponding data for compiling a corresponding data packet 31 in response to the request 30 from the database units 4, 5.
  • a semantic interpretation of the request 30 is first carried out.
  • the corresponding data is then called up from the database units 4, 5.
  • the data of a respective database 11, 13 are converted into respective triples 10, 12.
  • data from a first database 11 are converted into respective triples 10 by the first database unit 4.
  • data from a second database 13 are converted into respective triples 12 by the second database unit 5.
  • the triples 10, 12 are provided in a machine-readable and / or machine-interpretable format.
  • the database units 4, 5 can be referred to as so-called SPARQL end points 14.
  • SPARQL endpoint 14 in English “SPARQL endpoint”, the contents of the databases 11, 13 of the server device 3 can be provided in a machine-readable and / or machine-interpretable manner.
  • information under different SPARQL endpoints 14 can be provided with one another
  • the two database units 4, 5 provide a respective SPARQL end point 14 as the source of information
  • SPARQL endpoints 14 can be combined into triples 10, 12 thanks to the provision.
  • the database unit 4 is a planning tool for planning the technical system.
  • the planning tool can either be carried out on a local computing device, in particular a computer, of a user or through a cloud, in particular as a cloud Service.
  • the planning tool can be provided by a central server device in the cloud.
  • the planning tool can then be operated by an operator interface on a user's end device.
  • corresponding operating data can be transmitted from the user's terminal to the central server device and / or planning data can be transmitted from the central server device to the user's terminal.
  • the database unit 4 thus enables data and / or information from the planning tool to be integrated into a semantic network.
  • the planning tool is opened with regard to cloud applications (for example
  • one of the following plants can be planned as the technical plant: A manufacturing plant, a plant in the process industry, for example in paper processing, food processing or building material processing or a plant in the energy industry, for example for the extraction or processing of petroleum or Natural gas products or for the production or distribution of electrical energy.
  • the second database unit 5 can be a documentation system from a manufacturer.
  • COMOS is an example of a planning tool.
  • Siemens Industry Online Support is an example of a manufacturer's documentation system.
  • the planning tool in the present case the first database unit 4, provides information about the composition of the technical system. Such information includes, for example, the order number, name, function and location of the respective components of the technical system in relation to the technical system.
  • documents such as a certificate or technical documentation are provided for respective components.
  • the corresponding documents are via the order number which is retrieved from the first database unit 4. is available. Accordingly, the query of the data of the second database unit 5 can also depend on a result of the query of the first database unit 4.
  • the structure as a SPARQL endpoint 14 allows both database units 4, 5 to be queried together with a SPARQL-compliant request.
  • query 30 from query unit 2 is thus SPARQL-compliant.
  • a combination of the triples 10, 12, which are received from both database units 4, 5, thus forms the order number in this example.
  • the order number is stored in both database units 4, 5 in a respective one of the triples 10, 12. In this way, the different information from the two database units 4, 5 can be linked.
  • the server device 3 links the respective triples 10, 12 from the first database unit 4 and the second database unit 5 to form a data packet 31. which each as
  • SPARQL endpoints 14 are executed, queried and connected to each other.
  • the generation of further relations and thus the generation of new relationships are made possible by the machine interpretability of the triples 10, 12.
  • By generating relations and relationships new semantic knowledge can be generated which goes beyond the information contained in the triples 10, 12.
  • the database 11 is the database of the planning tool.
  • the data for example a model and associated instances, are read from the database 11 and transferred to a triple memory 15.
  • the triple store 15 is in particular a so-called RDF triple store.
  • the triples 10 are stored in an RDF-compliant format in the RDF triple store.
  • This transfer or conversion takes place in particular with the help of a Programming interface of the corresponding database unit 4, 5.
  • the transfer or conversion can take place by means of a programming interface (“API”) of the planning tool.
  • API programming interface
  • a SPARQL end point 14 can then be used to access the triples 10 and make them available for retrieval.
  • selected ones of the triples 10 can then be transmitted to the server device 2.
  • the server device 3 retrieves the corresponding triples 10 by means of the query 16.
  • SPARQL endpoints are also available as open source implementations.
  • An example of an implementation in JAVA is, for example, a triple store called FUSEKI (Apache Jena).
  • the triples 10 are stored in the triple memory 15 during the materialistic implementation. These are then ready for retrieval in this triple memory 15.
  • the data or information contained in the database 11 is duplicated by the transfer from the database 11 into the triple memory 15.
  • the corresponding data or information is now stored both in the database 11 and in the triple memory 15.
  • a synchronization between the triple memory 15 and the database 11 must take place regularly. This synchronization takes place in particular periodically or continuously. For example, this synchronization can take place by repeated, in particular periodic or continuous, conversion of the database 11 into the triples 10.
  • an adaptation of the database 11 to changes in the triples 10 can be seen.
  • FIG. 3 shows in a block diagram, which is divided into two, both the materialized implementation 21 and a virtual implementation 20.
  • the database 11 is accessed by means of the query 16.
  • For the materia Implementation 21 is carried out as already described with reference to FIG. 2.
  • the data from the database 11 are provided by means of an intermediary 23, also referred to as a mediator, and by means of an adapter interface 24, also called a wrapper.
  • the adapter interface 24 or the wrapper can, for example, be provided by the programming interface of the planning tool.
  • the mediator 23, in particular the mediator can be provided by a corresponding SPARQL endpoint. In the present case, the mediator 23 is partially designed as a SPARQL endpoint.
  • the intermediary 23 is designed to receive and interpret the SPARQL-compliant query 16.
  • the adapter interface 24 is designed to convert the data from the database 11 into query triples, in particular RDF-compliant triples, upon query 16 to convert or convert. In particular, only the respective data are converted, which are actually requested by means of query 16.
  • the adapter interface 24 thus simulates a triple memory 15 without this actually being present in a memory. Instead, a conversion is always carried out only for a specific query 16. After answering query 16, the triples generated from the data in database 11 are in particular rejected.
  • a comparison of the possibilities that is, the materialized implementation 21 and the virtual implementation 20, shows in a practical comparison that the materialized implementation 21 enables more efficient provision of triples.
  • the triple memory 15 is available at any time for retrieval and interpretation of the triple 10 stored therein. Therefore, the materialized implementation 21 may be preferable.
  • 2 and 3 show the specific design of the database units 4, 5 by way of example using the first database unit 4. However, the explanations also apply to the second database unit 5 and each additional database unit.
  • step S1 data from a first database 11 are converted into respective triples 10 and data from a second database 13 into respective triples 12, the first and second databases 11, 13 each having the technical system and / or its affect several components.
  • step S2 respective triples 10, 12 are retrieved from the first and second database units 4, 5 by the server device 3. This takes place in particular in response to query 30 from query unit 2.
  • step S3 only part of the respective triples 10, 12, which are available in the respective database unit 4, 5, are retrieved in step S2.
  • step S3 the respective triples 10, 12 from the first and the second database unit 4, 5 are linked to form the data packet 31.
  • the data packet 31 is transmitted to the query unit 2 in response to the query 30.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé pour la transmission d'un paquet de données (31) spécifique à l'utilisation à une unité de demande (2), le paquet de données (31) concernant une installation technique, laquelle comprend plusieurs composants. Pour permettre une mise à disposition améliorée du paquet de données (31), les suivantes étapes sont prévues : - conversion de données d'une première base de données (11) en triplets (10) respectifs au moyen d'une première unité de base de données (4) et conversion de données d'une deuxième base de données (13) en triplets (12) respectifs au moyen d'une deuxième unité de base de données (4, 5), la première base de données (10) et la deuxième base de données (12) concernant respectivement l'installation technique et/ou ses plusieurs composants, - récupération des triplets (10, 12) respectifs à partir de la première et de la deuxième unité de base de données (4, 5) par le dispositif serveur (3) sur une demande de l'unité de demande (2), - liaison des triplets (10, 12) respectifs de la première et de la deuxième unité de base de données (4, 5) en un paquet de données (31) par le dispositif serveur (3) et - transmission du paquet de données (31) à l'unité de demande (2) par le dispositif serveur (3).
PCT/EP2018/084197 2018-12-10 2018-12-10 Procédé ainsi que système pour la transmission d'un paquet de données de triplets lisibles par machine spécifique à l'utilisation WO2020119882A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2018/084197 WO2020119882A1 (fr) 2018-12-10 2018-12-10 Procédé ainsi que système pour la transmission d'un paquet de données de triplets lisibles par machine spécifique à l'utilisation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2018/084197 WO2020119882A1 (fr) 2018-12-10 2018-12-10 Procédé ainsi que système pour la transmission d'un paquet de données de triplets lisibles par machine spécifique à l'utilisation

Publications (1)

Publication Number Publication Date
WO2020119882A1 true WO2020119882A1 (fr) 2020-06-18

Family

ID=64959278

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2018/084197 WO2020119882A1 (fr) 2018-12-10 2018-12-10 Procédé ainsi que système pour la transmission d'un paquet de données de triplets lisibles par machine spécifique à l'utilisation

Country Status (1)

Country Link
WO (1) WO2020119882A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140156638A1 (en) * 2012-11-30 2014-06-05 Orbis Technologies, Inc. Ontology harmonization and mediation systems and methods
US20160179979A1 (en) * 2014-12-22 2016-06-23 Franz, Inc. Semantic indexing engine

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140156638A1 (en) * 2012-11-30 2014-06-05 Orbis Technologies, Inc. Ontology harmonization and mediation systems and methods
US20160179979A1 (en) * 2014-12-22 2016-06-23 Franz, Inc. Semantic indexing engine

Similar Documents

Publication Publication Date Title
DE60118487T2 (de) Kommunikationsystem auf Basis von WDSL Sprache
WO2012110314A1 (fr) Procédé et dispositif pour l'analyse de paquets de données
DE10151116A1 (de) Verfahren zur Inbetriebnahme eines Bedien- und Beobachtungssystems von Feldgeräten
DE202014010898U1 (de) Hierarchische Stückelung von Objekten in einem dezentralen Speichersystem
WO2003038535A1 (fr) Procede permettant de faire fonctionner et d'observer des appareils utilisables in situ
DE112012002631T5 (de) Stream-Verarbeitung unter Verwendung einer Client-Server-Architektur
EP1258812A1 (fr) Base de données virtuelle de structures de données hétérogènes
EP1176482A1 (fr) Méthode et logiciel pour la génération d'un système de régulation ou de commande
WO2018091658A1 (fr) Concept de commande d'une transmission de messages entre des abonnés de communication d'un système d'automatisation
EP1653308B1 (fr) Procédé et dispositif pour enregistrer et mettre à disposition des informations
WO2003036401A2 (fr) Procede de detection de plusieurs appareils de champ dans une configuration d'appareils
DE102004030781A1 (de) SCADA-System und Verfahren zum Betreiben eines solchen Systems
WO2010060541A1 (fr) Procédé et dispositif de configuration distribuée de services télématiques dans des systèmes de véhicule à moteur
WO2020119882A1 (fr) Procédé ainsi que système pour la transmission d'un paquet de données de triplets lisibles par machine spécifique à l'utilisation
Schmitz et al. Kollaboratives wissensmanagement
WO2021190715A1 (fr) Procédé mis en œuvre par ordinateur et système de stockage distribué pour fournir des objets de données fiables
DE69522855T2 (de) Informationssystem zur Abfrage von aus betrieblichen Applikationen stammenden zentralisierten Informationen
DE10151117A1 (de) Verfahren zum Ausbilden einer Bedienfunktion von Feldgeräten und Feldgerät
EP1285315B1 (fr) Systeme de traitement d'informations et son procede d'exploitation
EP0825525B1 (fr) Procédé pour la création d'objets
WO2002019044A2 (fr) Dispositif et procede pour la surveillance, la commande et la regulation integrees de deroulements de procedes techniques complexes
EP1435026B1 (fr) Systeme et procede d'emission de donnees d'un appareil, en particulier d'un appareil d'automatisation, par l'intermediaire d'une interface normalisee avec remplacement de variables par l'intermediaire d'un serveur echo
EP1435025B1 (fr) Systeme et procede pour acceder a un appareil, en particulier a un appareil d'automatisation pourvu d'une interface normalisee
DE10108564A1 (de) Verfahren zur Suche nach in einem verteilten System aktuell oder früher gespeicherten Daten oder Daten enthaltenden Ressourcen unter Berücksichtigung des Zeitpunkts ihrer Verfügbarkeit
EP4300327A1 (fr) Procédé de fourniture de données d'un système d'automatisation, procédé de recherche destiné à la détermination de données d'un système d'automatisation, programme informatique, support lisible par ordinateur et dispositif de traitement de données

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

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18830156

Country of ref document: EP

Kind code of ref document: A1