ES2869256T3 - Procedimiento y sistema de control para el control y/o la supervisión de dispositivos - Google Patents

Procedimiento y sistema de control para el control y/o la supervisión de dispositivos Download PDF

Info

Publication number
ES2869256T3
ES2869256T3 ES18800489T ES18800489T ES2869256T3 ES 2869256 T3 ES2869256 T3 ES 2869256T3 ES 18800489 T ES18800489 T ES 18800489T ES 18800489 T ES18800489 T ES 18800489T ES 2869256 T3 ES2869256 T3 ES 2869256T3
Authority
ES
Spain
Prior art keywords
control
control commands
module
data
distributed database
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
ES18800489T
Other languages
English (en)
Inventor
Thomas Jetzfellner
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
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
Priority claimed from PCT/EP2018/060900 external-priority patent/WO2019081071A1/de
Priority claimed from PCT/EP2018/071066 external-priority patent/WO2019081086A1/de
Application filed by Siemens AG filed Critical Siemens AG
Priority claimed from PCT/EP2018/078902 external-priority patent/WO2019081434A1/de
Application granted granted Critical
Publication of ES2869256T3 publication Critical patent/ES2869256T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
    • H04L12/2818—Controlling appliance services of a home automation network by calling their functionalities from a device located outside both the home and the home network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • General Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Accounting & Taxation (AREA)
  • Human Resources & Organizations (AREA)
  • Mathematical Physics (AREA)
  • Power Engineering (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Operations Research (AREA)
  • Tourism & Hospitality (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Sistema de control para el control y/o la supervisión de dispositivos, que comprende: - un sistema de bases de datos distribuidas (BC) o un sistema de comunicación distribuida; - un primer módulo de marcado (110) para asignar registros de datos de marcado, en el que - en cada caso, uno de los registros de datos de marcado se asigna a comandos de control en función de los requisitos de ejecución, si los comandos de control correspondientes cumplen los requisitos de ejecución, - los comandos de control a los que se asigna uno de los respectivos registros de datos de marcado pueden ser ejecutados por nodos (BCN, BCN_D) del sistema de bases de datos distribuidas (BC) o del sistema de comunicación distribuida o por dispositivos (D, BCN_D), - los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan en los requisitos de ejecución; - un primer módulo de memoria (130) para almacenar los respectivos comandos de control con su registro de datos de marcado respectivo asociado en las transacciones de control, en el que - las transacciones de control se almacenan en el sistema de bases de datos distribuidas (BC) o por el sistema de comunicación distribuida; - las transacciones de control se transmiten a los dispositivos (D, BCN_D) o nodos (BCN, BCN_D) por medio del sistema de bases de datos distribuidas (BC) o el sistema de comunicación distribuida.

Description

DESCRIPCIÓN
Procedimiento y sistema de control para el control y/o la supervisión de dispositivos
La invención se refiere a un procedimiento y sistema de control para el control y/o la supervisión de dispositivos.
Los dispositivos tales como dispositivos de campo y dispositivos de fabricación están cada vez más conectados en red y, por ejemplo, pueden ser proporcionados/operados por diferentes operadores. A estos dispositivos se les transfieren a menudo secuencias de comandos que pueden ser ejecutadas por los dispositivos. La desventaja en este caso es que la ejecución de las secuencias de comandos en una red heterogénea de dispositivos de diferentes operadores es difícil de controlar; como puede verse, por ejemplo, en el documento DE 102011 018878 B3.
Un objetivo de la presente invención es encontrar una alternativa a las soluciones conocidas de los antecedentes de la técnica.
El objetivo se consigue mediante las características especificadas en las reivindicaciones independientes. En las reivindicaciones dependientes se presentan perfeccionamientos ventajosos de la invención.
La tecnología de las cadenas de bloques (en inglés Blockchains) o "Distributed Ledgers" es actualmente una tecnología muy discutida que puede implementarse en particular como un sistema de bases de datos distribuidas. Además de las aplicaciones para sistemas de pago descentralizados (por ejemplo, Bitcoin), se están desarrollando nuevas posibilidades de aplicación en la industria financiera. En particular, las transacciones entre empresas se pueden implementar de forma protegida contra manipulación sin un intermediario o cámara de compensación. Esto permite nuevos modelos de negocio sin un intermediario fiable, reduce los costes de transacción y se pueden ofrecer nuevos servicios digitales de manera flexible sin tener que establecer una infraestructura especialmente configurada y relaciones de confianza. Un registro de datos de transacción (o transacción para abreviar) protegido por una cadena de bloques incluye, por ejemplo, código de programa, que también puede denominarse "contrato inteligente".
De acuerdo con un primer aspecto, la invención se refiere a un sistema de control para el control y/o la supervisión de dispositivos, que comprende:
- un sistema de bases de datos distribuidas (BC), que presenta,
- una pluralidad de nodos (BCN, BCN D), en la que nodos (BCN, BCN_D) y dispositivos (D, BCN_D) están conectados entre sí a través de una primera red de comunicación (NW1);
- un primer módulo de marcado (110) para asignar registros de datos de marcado, en el que
- en cada caso, uno de los registros de datos de marcado se asigna a comandos de control en función de los requisitos de ejecución, si los comandos de control correspondientes cumplen los requisitos de ejecución,
- los comandos de control a los que se asigna uno de los respectivos registros de datos de marcado pueden ser ejecutados por los nodos (BCN, BCN_D) del sistema de bases de datos distribuidas (BC) o por los dispositivos (D, BCN_D),
- los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan en los requisitos de ejecución,
- el módulo de marcado es, en particular, un módulo de marcado de acuerdo con la invención;
- un primer módulo de memoria (130) para almacenar los respectivos comandos de control con su registro de datos de marcado respectivo asociado en las transacciones de control, en el que
- las transacciones de control se almacenan en el sistema de bases de datos distribuidas (BC);
- las transacciones de control se transmiten a los dispositivos (D, BCN_D) o nodos (BCN, BCN_D) por medio del sistema de bases de datos distribuidas (BC).
A menos que se indique lo contrario en la siguiente descripción, los términos "ejecutar", "calcular", "asistido por ordenador", "calcular", "determinar", "generar", "configurar", "reconstruir" y similares se refieren preferentemente a acciones y/o procesos y/o etapas de procesamiento que cambian y/o generan datos y/o convierten los datos en otros datos, siendo o pudiendo ser los datos representados, en particular, como magnitudes físicas, por ejemplo como pulsos eléctricos. En particular, el término "ordenador" debe interpretarse de la manera más amplia posible, en particular para abarcar todos los dispositivos electrónicos con propiedades de procesamiento de datos. Por tanto, los ordenadores pueden ser, por ejemplo, ordenadores personales, servidores, controladores lógicos programables (PLC), sistemas informáticos de mano, dispositivos PC de bolsillo, dispositivos de radio móvil y otros dispositivos de comunicación que pueden procesar datos con la ayuda de ordenadores, procesadores y otros dispositivos electrónicos para el procesamiento de datos.
En relación con la invención, puede entenderse que "asistido por ordenador" significa, por ejemplo, una implementación del procedimiento en la que, en particular, un procesador ejecuta al menos una etapa de procedimiento del procedimiento.
En relación con la invención, se puede entender que un procesador significa, por ejemplo, una máquina o un circuito electrónico. Un procesador puede ser, en particular, un procesador principal (en inglés, Central Processing Unit, CPU), un microprocesador o un microcontrolador, por ejemplo, un circuito integrado específico de la aplicación o un procesador de señales digitales, posiblemente en combinación con una unidad de memoria para almacenar comandos de programa, etc. Un procesador también puede ser, por ejemplo, un IC (circuito integrado), en particular una FPGA (matriz de puertas programables en campo) o un ASIC (circuito integrado específico de la aplicación), o un DSP (procesador de señales digitales) o un procesador gráfico GPU (unidad de procesamiento gráfico). Por procesador también puede entenderse un procesador virtualizado, una máquina virtual o una CPU de software. También puede ser, por ejemplo, un procesador programable que está equipado con etapas de configuración para ejecutar dicho procedimiento de acuerdo con la invención o que está configurado con etapas de configuración de tal manera que el procesador programable realice las características de acuerdo con la invención del procedimiento, el componente, los módulos u otros aspectos y/o subaspectos implementados de la invención.
Una "unidad de memoria" o "módulo de memoria" y similares pueden entenderse en relación con la invención, por ejemplo, como una memoria volátil en forma de memoria de acceso aleatorio (RAM) o una memoria permanente como un disco duro o un portador de datos.
En relación con la invención, puede entenderse que un "módulo" significa, por ejemplo, un procesador y/o una unidad de memoria para almacenar comandos de programa. Por ejemplo, el procesador está especialmente configurado para ejecutar los comandos de programa de tal manera que el procesador ejecuta funciones para implementar o materializar el procedimiento de acuerdo con la invención o una etapa del procedimiento de acuerdo con la invención.
Un módulo puede, por ejemplo, ser también un nodo del sistema de bases de datos distribuidas que, por ejemplo, implementa las funciones/características específicas de un módulo correspondiente. Los respectivos módulos pueden, por ejemplo, estar conformados también como módulos separados o independientes. Para ello, los módulos correspondientes pueden comprender, por ejemplo, otros elementos. Estos elementos son, por ejemplo, una o más interfaces (por ejemplo, interfaces de base de datos, interfaces de comunicación, por ejemplo, interfaz de red, interfaz WLAN) y/o una unidad de evaluación (por ejemplo, un procesador) y/o una unidad de memoria. Por ejemplo, los datos se pueden intercambiar (por ejemplo, recibir, transmitir, enviar o proporcionar) por medio de las interfaces. Por medio de la unidad de evaluación, los datos se pueden comparar, verificar, procesar, asignar o calcular, por ejemplo, de manera asistida por ordenador y/o automatizada. Por medio de la unidad de memoria, los datos pueden almacenarse, recuperarse o proporcionarse, por ejemplo, de manera asistida por ordenador y/o automatizada.
En relación con la invención, puede entenderse que "comprender", en particular con respecto a datos y/o información, significa, por ejemplo, el almacenamiento (asistido por ordenador) de la información correspondiente o una fecha correspondiente en una estructura de datos/registro de datos (que, por ejemplo, se almacena a su vez en una unidad de memoria).
En relación con la invención, puede entenderse que "asignar", en particular con respecto a datos y/o información, significa, por ejemplo, una asignación de datos y/o información asistida por ordenador. Por ejemplo, una segunda fecha se asigna a una primera fecha por medio de una dirección de memoria o un identificador único (en inglés, unique identifier (UID)), en el que, por ejemplo, la primera fecha se almacena junto con la dirección de memoria o el identificador único de la segunda fecha juntos en un registro de datos.
En relación con la invención, puede entenderse que "proporcionar", en particular en relación con datos y/o información, significa, por ejemplo, provisión asistida por ordenador. La provisión tiene lugar, por ejemplo, a través de una interfaz (por ejemplo, una interfaz de base de datos, una interfaz de red, una interfaz a una unidad de memoria). Los datos y/o la información correspondiente se pueden transmitir y/o enviar y/o recuperar y/o recibir a través de esta interfaz, por ejemplo, durante la provisión.
En relación con la invención, también puede entenderse que "proporcionar" significa, por ejemplo, cargar o almacenar, por ejemplo, una transacción con los datos correspondientes. Esto se puede hacer, por ejemplo, en o desde un módulo de memoria. También puede entenderse que "proporcionar" significa, por ejemplo, transmitir (o enviar o transferir) los datos correspondientes de un nodo a otro nodo en la cadena de bloques o el sistema de bases de datos distribuidas (o su infraestructura).
En relación con la invención, se puede entender que "proceso de contrato inteligente" significa, en particular, la ejecución de un código de programa (por ejemplo, los comandos de control) en un proceso mediante el sistema de bases de datos distribuidas o su infraestructura.
Puede entenderse que una "suma de verificación", por ejemplo, una suma de verificación de bloque de datos, una suma de verificación de datos, una suma de verificación de nodo, una suma de verificación de transacción, una suma de verificación de concatenación o similar significa, en relación con la invención, por ejemplo, una suma de verificación criptográfica o hash criptográfico o valor hash, que se forma o se calcula, en particular por medio de una función hash criptográfica un registro de datos y/o datos y/o una o más de las transacciones y/o una subárea de un bloque de datos (por ejemplo, el encabezado de bloque de un bloque de una cadena de bloques o el encabezado de bloque de datos de un bloque de datos del sistema de bases de datos distribuidas o solo una parte de las transacciones de un bloque de datos). Una suma de verificación puede ser, en particular, una o más sumas de verificación o uno o más valores hash de un árbol hash (por ejemplo, árbol de Merkle, árbol de Patricia). Además, también puede entenderse que significa, en particular, una firma digital o un código de autenticación de mensaje criptográfico. Por medio de las sumas de verificación se puede, por ejemplo, implementar protección criptográfica/protección contra manipulación para las transacciones y los datos almacenados en las mismas en diferentes niveles del sistema de bases de datos. Por ejemplo, si se requiere un alto nivel de seguridad, las sumas de verificación se generan y verifican a nivel de la transacción. Si se requiere un nivel de seguridad menos elevado, por ejemplo, las sumas de verificación se generan y verifican a nivel de bloque (por ejemplo, en todo el bloque de datos o solo en parte del bloque de datos y/o parte de las transacciones).
En relación con la invención, se puede entender que una "suma de verificación de bloque de datos" significa una suma de verificación que se calcula, por ejemplo, sobre parte de o todas las transacciones de un bloque de datos. Entonces, un nodo puede, por ejemplo, verificar/determinar la integridad/autenticidad de la parte correspondiente de un bloque de datos por medio de la suma de verificación de bloque de datos. Además o de forma alternativa, la suma de verificación de bloque de datos puede haberse formado en particular también mediante transacciones de un bloque de datos anterior/bloque de datos predecesor del bloque de datos. La suma de verificación de bloque de datos también se puede implementar por medio de un árbol hash, por ejemplo, un árbol de Merkle [1] o un árbol de Patricia, en el que la suma de verificación de bloque de datos es, en particular, la suma de verificación raíz del árbol de Merkle o un árbol de Patricia o un árbol hash binario. En particular, las transacciones se aseguran mediante sumas de verificación adicionales del árbol de Merkle o del árbol de Patricia (por ejemplo, utilizando las sumas de verificación de transacciones), con lo que las sumas de verificación adicionales son, en particular, hojas en el árbol de Merkle o árbol de Patricia. La suma de verificación de bloque de datos puede asegurar así las transacciones, por ejemplo, formando la suma de verificación raíz a partir de las otras sumas de verificación. La suma de verificación de bloque de datos se puede calcular, en particular, para transacciones de un bloque de datos específico de los bloques de datos. En particular, una suma de verificación de bloque de datos de este tipo se puede incluir en un bloque de datos posterior del bloque de datos particular para concatenar este bloque de datos posterior, por ejemplo, con sus bloques de datos anteriores y, en particular, para hacer a la integridad del sistema de bases de datos distribuidas verificable. De esta manera, la suma de verificación de bloque de datos puede, por ejemplo, asumir la función de suma de verificación de concatenación o incluirse en la suma de verificación de concatenación. El encabezado de un bloque de datos (por ejemplo, de un nuevo bloque de datos o del bloque de datos para el que se formó la suma de verificación de bloque de datos) puede comprender, por ejemplo, la suma de verificación de bloque de datos.
En relación con la invención, se puede entender que "suma de verificación de transacción" significa una suma de verificación que se forma en particular en una transacción de un bloque de datos. Además, por ejemplo, se puede acelerar el cálculo de una suma de verificación de bloque de datos para un bloque de datos correspondiente, ya que para este propósito, por ejemplo, las sumas de verificación de transacciones que ya se han calculado se pueden utilizar como hojas, por ejemplo, de un árbol de Merkle.
En relación con la invención, puede entenderse que una "suma de verificación de concatenación" significa una suma de verificación que, en particular, indica o hace referencia al bloque de datos anterior del sistema de bases de datos distribuidas para el bloque de datos respectivo del sistema de bases de datos distribuidas (a menudo denominado "hash de bloque anterior" en la literatura técnica) [1]. Para ello, se forma una suma de verificación de concatenación correspondiente, en particular, para el bloque de datos anterior correspondiente. Por ejemplo, una suma de verificación de transacción o la suma de verificación de bloque de datos de un bloque de datos (es decir, un bloque de datos existente del sistema de bases de datos distribuidas) se puede utilizar como suma de verificación de concatenación para concatenar un nuevo bloque de datos con un bloque de datos (existente) del sistema de bases de datos distribuidas. Sin embargo, también es posible, por ejemplo, que se forme una suma de verificación sobre un encabezado del bloque de datos anterior o sobre todo el bloque de datos anterior y se utilice como suma de verificación de concatenación. Esto también se puede calcular, por ejemplo, para varios de o todos los bloques de datos anteriores. Por ejemplo, también es posible utilizar el encabezado de un bloque de datos y la suma de verificación de bloque de datos para formar la suma de verificación de concatenación. Sin embargo, un bloque de datos respectivo del sistema de bases de datos distribuidas comprende preferentemente una suma de verificación de concatenación que se calculó para, o que se refiera a, un bloque de datos anterior, en particular más preferentemente el bloque de datos directamente anterior, del bloque de datos respectivo. También es posible, por ejemplo, que se forme una suma de verificación de concatenación correspondiente solo sobre parte del bloque de datos correspondiente (por ejemplo, el bloque de datos anterior). De esta manera, por ejemplo, se puede implementar un bloque de datos que comprende una parte protegida por integridad y una parte no protegida. Por tanto, podría implementarse un bloque de datos, por ejemplo, cuya parte protegida por integridad no se pueda modificar y cuya parte desprotegida también se pueda modificar posteriormente. En este contexto, debe entenderse, en particular, que protegido por integridad significa que un cambio en los datos protegidos por integridad se puede determinar mediante una suma de verificación.
Los datos que se almacenan en una transacción de un bloque de datos, por ejemplo, se pueden proporcionar en particular de diferentes formas. En lugar de los datos, por ejemplo, datos de usuario como datos de medición o datos/regímenes de propiedad de activos, por ejemplo, una transacción de un bloque de datos solo puede comprender la suma de verificación para estos datos. La suma de verificación correspondiente se puede implementar de diferentes formas. Esto puede ser, por ejemplo, una suma de verificación de bloque de datos correspondiente de un bloque de datos (con los datos correspondientes) de otra base de datos o del sistema de bases de datos distribuidas, una suma de verificación de transacción de un bloque de datos con los datos correspondientes (del sistema de bases de datos distribuidas u otra base de datos) o una suma de verificación de datos que se formó sobre los datos.
Además, la transacción correspondiente también puede comprender una referencia o una indicación sobre una ubicación de almacenamiento (por ejemplo, una dirección de un servidor de archivos e indicaciones sobre dónde se pueden encontrar los datos correspondientes en el servidor de archivos; o una dirección de otra base de datos distribuida que contiene los datos). Los datos correspondientes podrían proporcionarse, por ejemplo, también en una transacción adicional de un bloque de datos adicional del sistema de bases de datos distribuidas (por ejemplo, si los datos correspondientes y las sumas de verificación asociadas están comprendidos en bloques de datos diferentes). Sin embargo, también es concebible, por ejemplo, que estos datos se proporcionen a través de otro canal de comunicación (por ejemplo, a través de otra base de datos y/o un canal de comunicación protegido criptográficamente).
Por ejemplo, además de la suma de verificación, también se puede almacenar un registro de datos adicional (por ejemplo, una referencia o una indicación de una ubicación de almacenamiento) en la transacción correspondiente, que en particular indica una ubicación de almacenamiento donde se pueden recuperar los datos. Esto es particularmente ventajoso para mantener un tamaño de datos de la cadena de bloques o del sistema de bases de datos distribuidas lo más pequeño posible.
En relación con la invención, se puede entender que "protegido por seguridad" significa, por ejemplo, una protección que se implementa en particular mediante un procedimiento criptográfico. Por ejemplo, esto se puede implementar utilizando el sistema de bases de datos distribuidas para la provisión o transmisión o envío de datos/transacciones correspondientes. Esto se consigue preferentemente mediante una combinación de las diferentes sumas de verificación (criptográficas), en el sentido de que trabajan juntas, en particular de forma sinérgica para, por ejemplo, mejorar la seguridad o la seguridad criptográfica de los datos de las transacciones. En otras palabras, también puede entenderse que "protegido por seguridad" en relación con la invención significa "protegido criptográficamente" y/o "protegido contra manipulación", con lo que "protegido contra manipulación" también puede denominarse "protegido por integridad".
En relación con la invención, puede entenderse que "concatenación de/de los bloques de datos de un sistema de bases de datos distribuidas" significa, por ejemplo, que los bloques de datos contienen cada uno información (por ejemplo, sumas de verificación de concatenación) que se refiere o hace referencia a otro bloque de datos o varios otros bloques de datos del sistema de bases de datos distribuidas [1] [4] [5].
En relación con la invención, puede entenderse que "inserción en el sistema de bases de datos distribuidas" y similares significan, por ejemplo, que en particular una transacción o las transacciones o un bloque de datos con sus transacciones se transmite a uno o más nodos de un sistema de bases de datos distribuidas. Por ejemplo, si estas transacciones se validan con éxito (por ejemplo, por el o los nodos), estas transacciones se concatenan en particular como un nuevo bloque de datos con al menos un bloque de datos existente del sistema de bases de datos distribuidas [1] [4] [5]. Para ello, las transacciones correspondientes se almacenan, por ejemplo, en un nuevo bloque de datos. En particular, esta validación y/o concatenación puede ser realizada por un nodo fiable (por ejemplo, un nodo de minería, un oráculo de cadena de bloques o una plataforma de cadena de bloques). En particular, puede entenderse que una plataforma de cadena de bloques significa una cadena de bloques como un servicio (en inglés, blockchain as a service), como proponen en particular Microsoft o IBM. En particular, un nodo fiable y/o un nodo pueden almacenar, cada uno, una suma de verificación de nodo (por ejemplo, una firma digital) en un bloque de datos (por ejemplo, en el bloque de datos que han validado y generado, que luego se concatena), en particular para permitir la identificación del creador del bloque de datos y/o permitir la identificación del nodo. Esta suma de verificación de nodo indica qué nodo, por ejemplo, ha concatenado el bloque de datos correspondiente con al menos otro bloque de datos del sistema de bases de datos distribuidas.
En relación con la invención, puede entenderse que "transacción" o "transacciones" significan, por ejemplo, un contrato inteligente [4] [5], una estructura de datos o un registro de datos de transacciones que, en particular, comprenden, cada uno, una de las transacciones o varias transacciones. En relación con la invención, también se puede entender que "transacción" o "transacciones" significan, por ejemplo, los datos de una transacción de un bloque de datos de una cadena de bloques (en inglés blockchain). Una transacción puede comprender, en particular, un código de programa que, por ejemplo, implementa un contrato inteligente. Por ejemplo, en relación con la invención, también puede entenderse que una transacción significa una transacción de control y/o una transacción de confirmación. De forma alternativa, una transacción puede ser, por ejemplo, una estructura de datos que almacena datos (por ejemplo, los comandos de control). Una transacción puede comprender, en particular, un código de programa que, por ejemplo, implementa un contrato inteligente. Por ejemplo, en relación con la invención, también puede entenderse que una transacción significa una transacción de control y/o una transacción de confirmación. Una transacción de confirmación puede, por ejemplo, almacenarse en el sistema de bases de datos distribuidas después de la ejecución exitosa de las transacciones de control mediante un dispositivo (por ejemplo, el dispositivo almacena la transacción de confirmación en el sistema de bases de datos distribuidas). Una transacción de confirmación puede comprender, por ejemplo, una confirmación para una ejecución de los comandos de control de la transacción de control mediante uno de los dispositivos si un dispositivo correspondiente de los dispositivos ha ejecutado con éxito los comandos de control de la transacción de control. Para ello, la transacción de confirmación puede comprender, por ejemplo, una suma de verificación generada por el dispositivo correspondiente (por ejemplo, una suma de verificación de transacción) sobre los comandos de control ejecutados y/o una confirmación de la ejecución, que, por ejemplo, también está protegida por la suma de verificación. Una transacción de confirmación también se puede almacenar, por ejemplo, en el sistema de bases de datos distribuidas si el dispositivo ejecuta parcialmente los comandos de control y/o se interrumpe la ejecución de los comandos de control. Este puede ser el caso, por ejemplo, si se ha producido un desperfecto en el dispositivo durante la ejecución de los comandos de control que ya no permite la ejecución de los comandos de control (por ejemplo, se ha producido un desperfecto en un actuador o herramienta). Por ejemplo, otro dispositivo, que, por ejemplo, cumple los requisitos de ejecución para los comandos de control restantes no ejecutados, puede utilizar la transacción de confirmación para ejecutar estos comandos de control no ejecutados de la transacción de control correspondiente. Por consiguiente, la transacción de confirmación puede comprender, por ejemplo, el grado de ejecución o una indicación sobre la parte ejecutada de los comandos de control. De forma alternativa o además, una transacción de confirmación puede indicar los comandos de control que aún deben ejecutarse para una ejecución exitosa de los comandos de control de una transacción de control correspondiente. Por consiguiente, por ejemplo, una transacción de confirmación puede comprender un registro de datos que indica cuáles de los comandos de control aún deben ejecutarse o que indica cuáles de los comandos de control faltan para la ejecución exitosa de los comandos de control de una transacción de control correspondiente. Esto hace posible, por ejemplo, seguir procesando los comandos de control, incluso si se ha interrumpido la ejecución de los comandos de control en un dispositivo. Por consiguiente, por ejemplo, puede ser necesario en los requisitos de ejecución que más de un dispositivo (por ejemplo, dos o tres dispositivos o más dispositivos) cumplan los requisitos de ejecución de modo que la ejecución de los comandos de control también esté garantizada, incluso si, por ejemplo, un dispositivo falla durante la ejecución de los comandos de control de una transacción de control correspondiente.
De forma alternativa, una transacción puede ser, por ejemplo, una estructura de datos que almacena datos (por ejemplo, los comandos de control). Una transacción, por ejemplo, también puede denominarse mensaje (es decir, un mensaje de comunicación que almacena datos) o ser un mensaje que, por ejemplo, almacena los datos correspondientes (por ejemplo, comandos de control). Por tanto, con la invención las transacciones o mensajes correspondientes pueden intercambiarse. Las transacciones pueden comprender, por ejemplo, los comandos de control y/o datos de contrato y/u otros datos tales como datos de vídeo, datos de usuario, datos de medición, etc.
En relación con la invención, se puede entender que "comandos de control" o "transacciones de control" significan, por ejemplo, un contrato inteligente [4][5] o un código de programa ejecutable que es ejecutado, en particular, por el sistema de bases de datos distribuidas, con lo que, por ejemplo, el sistema de bases de datos distribuidas o nodos e infraestructura del mismo procesa o implementa los comandos de control correspondientes. En particular, los dispositivos/nodos se pueden controlar con los comandos de control. En particular, los dispositivos y/o los nodos pueden o deben ser controlados/activados con los comandos de control o los comandos de control de la/de una transacción de control. En particular, múltiples comandos de control o transacciones de control de uno o más bloques de datos dan como resultado una secuencia de comandos que, en particular, controlan una planta de fabricación con las máquinas de fabricación asociadas, controlan los dispositivos en una red de automatización o controlan los dispositivos en una red de suministro de energía o controlan dispositivos en el Internet de las cosas. En particular, los comandos de fabricación o las etapas de fabricación de un producto se codifican en los comandos de control o las transacciones de control (es decir, también en las secuencias de comandos). Los dispositivos (por ejemplo, el dispositivo correspondiente) son, por ejemplo, dispositivos de un sistema técnico y/o planta industrial y/o una red de automatización y/o una planta de fabricación y/o dispositivos en el Internet de las cosas, que en particular también son un nodo del sistema de bases de datos distribuidas. En este caso, los dispositivos pueden ser, por ejemplo, dispositivos de campo, que en particular también son un nodo del sistema de bases de datos distribuidas. Los dispositivos también pueden ser, por ejemplo, cajeros automáticos, en los que los comandos de control provocan una retirada de efectivo. Por ejemplo, los comandos de control se pueden derivar o determinar a partir de una secuencia de comandos. Por ejemplo, una transacción de control puede comprender uno o más comandos de control. Por ejemplo, una transacción de control puede comprender uno o más comandos de control. Por ejemplo, los comandos de control codifican el movimiento mecánico y/u otras variables físicas (por ejemplo, presión o temperatura) que son convertidas por un dispositivo/nodo correspondiente (por ejemplo, por un actuador correspondiente) en el movimiento mecánico correspondiente y/o las otras magnitudes físicas correspondientes. Los comandos de control se utilizan, por ejemplo, para controlar los actuadores de los dispositivos y/o nodos. Por consiguiente, un dispositivo/nodo correspondiente comprende, por ejemplo, un actuador. Por ejemplo, si un dispositivo/nodo es un robot, un actuador también se denominaría efector. Un dispositivo también puede ser un dispositivo o sistema mecatrónico, por ejemplo, un dispositivo/sistema mecatrónico que es, por ejemplo, un actuador y/o un dispositivo técnico lineal. Un dispositivo técnico lineal es, por ejemplo, un dispositivo para realizar movimientos de traslación. Un dispositivo correspondiente también puede ser un sistema de accionamiento, por ejemplo. Por medio de los comandos de control y los dispositivos y/o nodos, por ejemplo, también se puede regular y/o controlar un bucle de control, por ejemplo, evaluando las transacciones de confirmación para los comandos de control ejecutados por el sistema de control y generando los comandos de control correspondientes como una reacción a las transacciones de confirmación. Para estos nuevos comandos de control, por ejemplo, los requisitos de ejecución correspondientes se determinan de nuevo y luego, por ejemplo, se almacenan nuevamente en transacciones de control para que puedan ser ejecutados por los dispositivos correspondientes, por ejemplo, como se describe en la invención. Los comandos de control también pueden ser, por ejemplo, comandos de control para controlar dispositivos y/o procedimientos criptográficos (por ejemplo, autenticación de usuario o autentificación de usuario).
También se puede entender que los comandos de control significan, por ejemplo, secuencias de comandos o también transacciones de una base de datos o un sistema de bases de datos que deben ser ejecutadas por dispositivos o nodos del sistema de bases de datos distribuidas. El sistema de bases de datos puede ser, por ejemplo, el sistema de bases de datos distribuidas si hay, por ejemplo, transacciones a las que aún no han sido asignados o destinados requisitos de ejecución. De forma alternativa o además, el sistema de bases de datos puede ser otra base de datos, por ejemplo, una base de datos jerárquica convencional de la que se pueden recuperar las transacciones correspondientes. También se puede entender que los comandos de control significan, por ejemplo, secuencias de comandos o también transacciones que son proporcionadas por un sistema de entrada y que deben ser ejecutadas por el sistema de bases de datos distribuidas. Se puede entender que comandos de control significan, por ejemplo, secuencias de comandos o comandos de control con las que se controlan dispositivos mecánicos y/o eléctricos y/o electromecánicos y/o electrónicos.
En relación con la invención, se puede entender que "requisitos específicos de dispositivo" significan, por ejemplo, un determinado dispositivo que, por ejemplo, está determinada por un identificador único, dispositivos que pueden realizar acciones de control predefinidas (por ejemplo, un robot de producción que puede soldar piezas metálicas; un robot de pintura que puede aplicar colores específicos a una pieza de producción; dispositivos que establecen automáticamente conexiones eléctricas en una subestación) o dispositivos que ejecutan etapas de fabricación o comandos de control con una precisión y/o velocidad específicas (por ejemplo, tornos, fresadoras y máquinas de corte). De forma alternativa o además, los "requisitos específicos de dispositivo" también pueden requerir determinadas clases de dispositivos que se predefinen para la ejecución o procesamiento de los comandos de control. En particular, se entiende que una clase de dispositivo significa uno o más dispositivos (por ejemplo, dispositivos de esmerilado o dispositivos de aserrado) que, por ejemplo, son capaces de realizar determinadas acciones predefinidas (por ejemplo, esmerilar o aserrar un determinado material). En particular, los requisitos específicos de dispositivo son los requisitos que se imponen en los dispositivos y/o nodos correspondientes para ejecutar los comandos de control. Los datos específicos de dispositivo o las propiedades del dispositivo corresponden, por ejemplo, a los datos específicos de dispositivo o las propiedades del dispositivo reales y/o actuales de un dispositivo. Por ejemplo, se verifica si un dispositivo o una máquina de fabricación es capaz de ejecutar los comandos de control con la precisión predefinida que, por ejemplo, se predefine en los requisitos específicos de dispositivo. En particular, los requisitos específicos de dispositivo también pueden denominarse requisitos específicos de máquina y/o mecatrónica y/o producción. En particular, los datos específicos de dispositivo o las propiedades del dispositivo también se pueden denominar datos o propiedades del dispositivo específicos de máquina y/o mecatrónica y/o producción. En particular, los datos específicos de dispositivo o las propiedades del dispositivo también se pueden denominar información del dispositivo. En particular, los requisitos específicos de dispositivo especifican los requisitos que deben cumplir los datos específicos de dispositivo de un dispositivo. En otras palabras, los requisitos específicos de dispositivo especifican un valor "objetivo" que se compara con el valor "real" de los dispositivos. Los datos específicos de dispositivo representan, en particular, las propiedades actuales del dispositivo. Estas propiedades del dispositivo/datos específicos de dispositivo comprenden, por ejemplo, el UID de un dispositivo o un sistema, herramientas disponibles o procesos de fabricación compatibles (fresado, rectificado o impresión en 3D), precisión de fabricación, costes de fabricación, ubicación de los dispositivos, dirección de red para dirigir/controlar el dispositivo, usuarios autorizados, etc.
Los requisitos específicos de dispositivo también pueden ser, por ejemplo, requisitos de seguridad o requisitos relacionados con la ubicación (por ejemplo, indicación de país, indicación de GPS o código postal (CP)) que un dispositivo debe cumplir para ejecutar los comandos de control. Por ejemplo, puede ser necesario que el dispositivo tenga dispositivos de seguridad predefinidos o que sea necesaria una autenticación y/o autentificación específica/predefinida para la ejecución de los comandos de control en el dispositivo. Este puede ser el caso, por ejemplo, si alguien quiere retirar efectivo de un dispositivo (por ejemplo, un cajero automático). Los comandos de control son entonces, por ejemplo, la solicitud del cliente de realizar una retirada de efectivo. Por ejemplo, si un cliente correspondiente ha configurado que, por ejemplo, solo en países específicos, por ejemplo, Italia, Francia y Austria se permite una retirada de efectivo, esto se almacena en los requisitos específicos de dispositivo (y, en particular, si es necesario, implícitamente también en los requisitos de ejecución). Un cajero automático en Andorra posiblemente no permitiría o evitaría una retirada. De forma alternativa, esto también se puede evitar, por ejemplo, mediante otro nodo del sistema de bases de datos distribuidas o mediante un contrato inteligente del sistema de bases de datos distribuidas. También puede ser necesaria la autenticación específica del cliente, por ejemplo, debido a los requisitos de seguridad. Por ejemplo, que se introduzca un pin para una retirada (que no es necesariamente el caso en los EE. UU., por ejemplo) y/o que se requiera una longitud determinada de pin (por ejemplo, 8 caracteres) y/o que se requieran otros procedimientos de autenticación adicionales (por ejemplo, autenticación de 2 factores, Mobile-TAN, Google Authenticator)
De forma alternativa, el módulo de marcado también puede analizar más los comandos de control y, si, por ejemplo, el módulo de marcado ya ha determinado que los requisitos específicos de dispositivo no se han cumplido o no se pueden cumplir, crear una transacción de control que lo indique al dispositivo o al sistema correspondiente y, si es necesario, impida la ejecución de los comandos de control. De forma alternativa, por ejemplo, no se puede generar ninguna transacción de control y en algún momento hay un tiempo de espera para la ejecución de los comandos de control, por ejemplo, después de un período predefinido, que preferentemente es configurable. De forma alternativa o además, el módulo de marcado también puede, por ejemplo, no generar ningún registro de datos de marcado si no se cumplen los requisitos de ejecución. De forma alternativa o además, el módulo de marcado también puede, por ejemplo, generar un registro de datos de marcado para los comandos de control si no se cumplen los requisitos de ejecución. Por ejemplo, el registro de datos de marcado puede comprender la información "Exection = True" si los comandos de control correspondientes pueden ser ejecutados por los nodos y/o los dispositivos. Por ejemplo, el registro de datos de marcado puede comprender la información "Exection = False" si los comandos de control correspondientes no pueden ser ejecutados por los nodos y/o los dispositivos. En particular, un registro de datos de marcado comprende solo una simple indicación de si los comandos de control se pueden ejecutar, pero ninguna información adicional, como, por ejemplo, los requisitos de ejecución.
En relación con la invención, también se puede entender que "datos específicos de sistema" o "datos específicos de dispositivo" significan, por ejemplo, propiedades del sistema o propiedades del dispositivo de un dispositivo o de un sistema técnico. Los datos específicos de dispositivo o los datos específicos de sistema son, por ejemplo, propiedades del dispositivo o propiedades del sistema actuales. Los datos específicos de dispositivo o los datos específicos de sistema (o las propiedades correspondientes) pueden comprender los siguientes datos, por ejemplo, para un sistema técnico, los dispositivos de un sistema técnico o un dispositivo: el UID del dispositivo o sistema, herramientas disponibles o procesos de fabricación soportados (fresado, rectificado o impresión en 3D) del dispositivo o sistema, precisión de fabricación del dispositivo o sistema, costes de fabricación del dispositivo o sistema, ubicación del dispositivo o sistema, dirección de red para dirigir/controlar el dispositivo o sistema, usuarios autorizados para el dispositivo o sistema, nombre del dispositivo o sistema, etc.
Dependiendo de la implementación elegida, por ejemplo, los datos específicos de sistema se pueden implementar en uno o más dispositivos de un sistema técnico, por ejemplo, mediante un UID/dirección (red) del sistema técnico, también pueden dirigirse, identificarse o comunicarse con los dispositivos correspondientes del sistema técnico. De forma alternativa o además, por ejemplo, los datos específicos de dispositivo para un dispositivo o los dispositivos múltiples del sistema técnico pueden estar comprendidos en los datos específicos de sistema.
En relación con la invención, se puede entender que "sistema técnico" significa, por ejemplo, un dispositivo o múltiples dispositivos que están conectados comunicativamente entre sí y/o con un sistema de bases de datos distribuidas (por ejemplo, el primer sistema de bases de datos distribuidas).
En relación con la invención, se puede entender que "comandos de control presupuestos" significan, por ejemplo, comandos de control que deben ser ejecutados en particular por otros nodos (del sistema de bases de datos distribuidas) y/o por uno o más de los dispositivos antes de que se pueden ejecutar los comandos de control correspondientes. En particular, las transacciones de confirmación correspondientes para estos comandos de control ejecutados previamente se almacenan en el sistema de bases de datos distribuidas (por ejemplo, en bloques de datos del sistema de bases de datos distribuidas). En particular, en el caso de estos comandos de control ejecutados previamente o presupuestos, los requisitos específicos de dispositivo asignados a estos comandos de control ejecutados previamente también se verifican o se tienen en cuenta. Por medio de los requisitos de ejecución se garantiza en particular que, por ejemplo, se respete una secuencia de las etapas de fabricación al crear un producto. De este modo se consigue, por ejemplo, que se respete la secuencia de fabricación de forma significativa. Por ejemplo, se evita que una etapa de fabricación sea destruida por otra simplemente porque no se cumplió la secuencia de fabricación. De manera similar, un control de una red de suministro de energía se puede controlar en particular mediante, por ejemplo, las transformaciones o acopladores de tensión que se encienden o se conectan a la red de alimentación en el orden correcto. Si, por ejemplo, no se requieren comandos de control presupuestos para la ejecución de comandos de control o transacciones de control, los comandos de control presupuestos pueden estar vacíos. Por ejemplo, a estos se les puede asignar un cero, una cadena vacía o un valor que indique que no se necesitan comandos de control presupuestos. De forma alternativa, por ejemplo, no se puede asignar ningún requisito de ejecución a algunos de los comandos de control, con lo que se asigna al menos un requisito de ejecución en particular a al menos uno de los comandos de control. Por ejemplo, los comandos de control presupuestos son comandos de control que, por ejemplo, han sido convertidos por un dispositivo y/o nodo en un movimiento mecánico predefinido y/u otras variables físicas (por ejemplo, presión o temperatura) o deben convertirse (por ejemplo, para preparar una pieza de trabajo) antes de procesar los comandos de control. Con los comandos de control presupuestos (si se ejecutaron con éxito) entonces, por ejemplo, los actuadores de los dispositivos y/o los nodos se controlaron de tal manera que una pieza de trabajo se puso en el estado o estado de fabricación en que, por ejemplo, es posible o se hace posible un procesamiento adicional después de la ejecución de los comandos de control presupuestos. Por consiguiente, por ejemplo, los dispositivos/nodos correspondientes se pueden controlar con los comandos de control de la transacción de control de tal manera que se lleve a cabo un procesamiento adicional (por ejemplo, si se han ejecutado los comandos de control presupuestos y hay en particular transacciones de confirmación para ellos). Por medio de los comandos de control presupuestos y los dispositivos y/o nodos, por ejemplo, también se puede regular y/o controlar un bucle de control, por ejemplo, evaluando las transacciones de confirmación para los comandos de control ejecutados/presupuestos por el sistema de control y generando los comandos de control correspondientes como una reacción a las transacciones de confirmación. Los comandos de control presupuestos también pueden ser, por ejemplo, comandos de control con los que se activó un dispositivo y/o procedimiento criptográfico (por ejemplo, autenticación de usuario o autentificación de usuario). De forma alternativa o además, los comandos de control presupuestos se pueden predefinir, por ejemplo, la adquisición de determinadas variables medidas (por ejemplo, mediante un sensor). Por ejemplo, se predefine así que las transacciones correspondientes con los valores medidos correspondientes deben adherirse a intervalos de valores medidos o valores umbral predefinidos. Los valores medidos pueden ser, por ejemplo, un valor de una variable medida (por ejemplo, 30 °C) y/o la fecha/hora de la adquisición y/o la ubicación de la adquisición y/o el tipo de sensor y/o información adicional sobre el sensor (por ejemplo, precisión de la medición).
En particular, debe entenderse que "almacenamiento de transacciones en bloques de datos" y similares significan almacenamiento directo o almacenamiento indirecto. Se puede entender que almacenamiento directo, por ejemplo, significa que el bloque de datos correspondiente (del sistema de bases de datos distribuidas) o la transacción correspondiente del sistema de bases de datos distribuidas) comprende los datos respectivos. Se puede entender que almacenamiento indirecto, por ejemplo, significa que el bloque de datos correspondiente o la transacción correspondiente comprende una suma de verificación y opcionalmente un registro de datos adicional (por ejemplo, una referencia o una indicación de una ubicación de almacenamiento) para los datos correspondientes y, por lo tanto, los datos correspondientes no se almacenan en el bloque de datos (o la transacción) directamente (es decir, solo una suma de verificación para estos datos). En particular, al almacenar transacciones en bloques de datos, estas sumas de verificación se pueden validar, por ejemplo, como se explica, por ejemplo, en "Inserción en el sistema de bases de datos distribuidas".
En relación con la invención, se puede entender que un "código de programa" (por ejemplo, un contrato inteligente) significa, por ejemplo, un comando de programa o múltiples comandos de programa que se almacenan en particular en una o más transacciones. En particular, el código del programa puede ser ejecutado y es ejecutado, por ejemplo, por el sistema de bases de datos distribuidas. Esto se puede implementar, por ejemplo, por medio de un entorno de ejecución (por ejemplo, una máquina virtual), en el que el entorno de ejecución o el código del programa es preferentemente Turing-completo. El código del programa se ejecuta, preferentemente, mediante la infraestructura del sistema de bases de datos distribuidas [4][5]. Por ejemplo, una máquina virtual se implementa a través de la infraestructura del sistema de bases de datos distribuidas.
En relación con la invención, se puede entender que "canal de comunicación separado y/o directo" significa, por ejemplo, una transmisión de datos (por ejemplo, enviar, recibir, transmitir, proporcionar o transferir) por medio de un canal de comunicación, como se implementa, por ejemplo, mediante la red Lightning inicialmente solo para la transmisión de criptomonedas [9]. Por ejemplo, las transacciones/mensajes se pueden enviar más rápidamente a través de este canal y se puede almacenar una confirmación de este intercambio de datos en el sistema de bases de datos distribuidas. De esta manera, por ejemplo, se pueden transmitir comandos de control importantes y/o de tiempo crítico o transacciones de control a un dispositivo correspondiente a una velocidad más alta, por ejemplo, se puede evitar la transmisión de datos más lenta del sistema de bases de datos distribuidas (por ejemplo, al replicar los bloques de datos/transacciones). Por ejemplo, se puede configurar un canal de comunicación separado y/o directo para la invención y los aspectos citados, realizaciones ejemplares, modos de realización de la invención y sus variantes para la transmisión de datos entre un dispositivo (y/o nodo). Por ejemplo, en un canal de comunicación directo, las transacciones/mensajes se intercambian directamente entre un emisor (por ejemplo, el (primer) módulo de memoria y/o el (primer) módulo de determinación) y un receptor (por ejemplo, el dispositivo que va a ejecutar los comandos de control) sin que otros nodos y/o dispositivos del sistema de bases de datos distribuidas estén involucrados en este intercambio de datos. Por el contrario, con un canal de comunicación separado, los nodos y/o dispositivos del sistema de bases de datos distribuidas pueden estar involucrados en el intercambio de datos. Si el canal de comunicación separado y/o directo se estableció con éxito entre el emisor y el receptor (en particular, se estableció una conexión de comunicación como resultado), entonces los datos se pueden intercambiar entre el emisor y el receptor, por ejemplo, en forma de transacciones o mensajes. Por ejemplo, los datos necesarios para determinar la ejecutabilidad y/o las transacciones de control se pueden intercambiar entre el emisor y/o el receptor. Si, por ejemplo, el canal de comunicación se cierra/termina (es decir, se termina una conexión de comunicación en particular), entonces, por ejemplo, el resultado de la transmisión de datos se almacena, por ejemplo, en forma de transacciones (por ejemplo, como una transacción de confirmación de transmisión) en el sistema de bases de datos distribuidas (por ejemplo, en bloques de datos del sistema de bases de datos distribuidas). El resultado de la transmisión de datos puede ser, por ejemplo, una confirmación de la transmisión o recepción de las transacciones/mensajes correspondientes y/o un resultado de análisis y/o la última transacción/mensaje transmitido que se transmitió a través del canal de comunicación separado y/o directo antes de cerrar el canal de comunicación. La transacción con el resultado puede ser almacenada, por ejemplo, por el emisor y/o el receptor. El resultado del análisis puede ser, por ejemplo, la confirmación de la ejecutabilidad de los comandos de control por un dispositivo, en el que un dispositivo correspondiente ha confirmado, por ejemplo, que puede ejecutar los comandos de control. Esto puede, por ejemplo, almacenarse a su vez en una transacción (por ejemplo, en una transacción de confirmación de ejecutabilidad) y, por ejemplo, se puede almacenar en los requisitos de ejecución (por ejemplo, en los requisitos específicos de dispositivo). De forma alternativa o además, la transacción de confirmación de ejecutabilidad se almacena en el sistema de bases de datos distribuidas. La transacción de confirmación de ejecutabilidad comprende, por ejemplo, un identificador único para el dispositivo que puede ejecutar los comandos de control o que cumple los requisitos de ejecución correspondientes. De forma alternativa o además, la transacción de confirmación de ejecutabilidad comprende, por ejemplo, datos sobre la ejecución de, por ejemplo, lo bien que o en qué medida se cumplen los requisitos de ejecución (por ejemplo, lo rápido que se procesan los comandos de control, cuándo se procesan de manera segura, con que exactitud o con qué precisión se ejecutan los comandos de control, por ejemplo, al ejecutar comandos de control de fabricación). De forma alternativa o además, la transacción de confirmación de ejecutabilidad comprende, por ejemplo, datos específicos de dispositivo del dispositivo correspondiente que son relevantes para la ejecución de los comandos de control en los que, por ejemplo, los datos específicos de dispositivo fueron determinados por el dispositivo correspondiente en el momento de la confirmación de la ejecutabilidad por parte del dispositivo. Por ejemplo, la confirmación de la ejecutabilidad y la determinación de los datos específicos de dispositivo tienen lugar (aproximadamente) al mismo tiempo, por ejemplo, dentro de una ventana de tiempo de unos pocos segundos o minutos. Por ejemplo, los datos de la transacción de confirmación de ejecutabilidad también se pueden haber intercambiado entre el emisor y el receptor antes de que la transacción de confirmación de ejecutabilidad se almacene, por ejemplo, en el sistema de bases de datos distribuidas. La transacción de confirmación de ejecutabilidad puede, por ejemplo, seguir estando protegida criptográficamente (por ejemplo, puede estar cifrada o protegida mediante una suma de verificación de la transacción). Las transacciones de control, por ejemplo, también se pueden transmitir de manera análoga al dispositivo correspondiente que se supone que va a o que puede procesar los comandos de control. Para ello, se puede configurar otro canal de comunicación separado y/o directo entre el transmisor y el receptor, por ejemplo. De forma alternativa, el canal de comunicación mencionado anteriormente puede, por ejemplo, continuar utilizándose. Las transacciones de control correspondientes, por ejemplo, se transmiten luego al dispositivo correspondiente a través del canal de comunicación correspondiente. Si, por ejemplo, el canal de comunicación se cierra/termina de nuevo cuando la transferencia se ha completado (con éxito), el resultado de la transmisión es, por ejemplo, almacenado como una transacción de confirmación de transmisión en el sistema de bases de datos distribuidas. Por ejemplo, el último mensaje intercambiado a través del canal de comunicación también se puede almacenar en la transacción de confirmación de transmisión (por ejemplo, si se interrumpe el canal de comunicación) y la transacción de confirmación de transmisión, por ejemplo, se puede almacenar luego en el sistema de bases de datos distribuidas. Este mensaje intercambiado más recientemente puede usarse, por ejemplo, para continuar el intercambio de datos o la transmisión de datos cuando el canal de comunicación se establece nuevamente. La transacción de confirmación de transmisión también se puede proteger criptográficamente, por ejemplo. La transacción de confirmación de transmisión puede comprender, por ejemplo, los comandos de control y/o la transacción de control y/o el último mensaje intercambiado entre el emisor y el receptor. Una continuación del intercambio de datos o la transmisión de datos puede, por ejemplo, usarse también para otras transmisiones de datos y no está específicamente restringida a la transmisión de datos o al intercambio de datos de transacciones de control.
El canal de comunicación separado y/o directo es ventajoso para mejorar la velocidad de transmisión y/o la latencia de transmisión. Por ejemplo, también es posible un procedimiento híbrido en el que, por ejemplo, se usa un canal de comunicación correspondiente para comandos de control críticos en el tiempo (por ejemplo, con alta prioridad). Por ejemplo, sobre la base de los requisitos de ejecución (por ejemplo, hay comandos de control críticos en el tiempo o comandos de control para una aplicación en tiempo real) se puede determinar si los comandos de control correspondientes se transmitirán a través de un canal de comunicación separado correspondiente. De forma alternativa o además, el (primer) módulo de determinación puede determinar los requisitos de transmisión correspondientes para una transmisión de datos de las transacciones de control, por ejemplo, al determinar los requisitos de ejecución. Los requisitos de transmisión se pueden almacenar en los requisitos de ejecución, por ejemplo. Usando los requisitos de transmisión, el módulo de memoria puede determinar, por ejemplo, si las transacciones de control se almacenan en el sistema de bases de datos distribuidas a través de una transmisión al dispositivo correspondiente, o si el canal de comunicación separado y/o directo se usa para la transmisión de datos a el dispositivo correspondiente. La transmisión de datos puede tener lugar entonces, por ejemplo, a través del (primer) módulo de memoria, que para ello comprende, por ejemplo, un módulo de comunicación correspondiente (por ejemplo, una interfaz de red).
En relación con la invención, se puede entender que "contrato inteligente" significa, por ejemplo, un código de programa ejecutable[4][5] (véase en particular la definición de "código de programa"). El contrato inteligente se almacena preferentemente en una transacción de un sistema de bases de datos distribuidas (por ejemplo, una cadena de bloques), por ejemplo, en un bloque de datos del sistema de bases de datos distribuidas. Por ejemplo, el contrato inteligente se puede ejecutar de la misma manera que se explica en la definición de "código de programa", en particular en relación con la invención.
En relación con la invención, puede entenderse que "evidencia de prueba de trabajo" significa, por ejemplo, la resolución de una tarea computacionalmente intensiva que debe resolverse, en particular, en función del contenido del bloque de datos/contenido de una transacción específica [1][4][5]. Una tarea computacionalmente intensiva de este tipo también se conoce como un rompecabezas criptográfico, por ejemplo.
En relación con la invención, un "sistema de bases de datos distribuidas", que también puede denominarse base de datos distribuida, por ejemplo, puede entenderse que significa una base de datos distribuida de forma descentralizada, una cadena de bloques (en inglés, blockchain), un registro contable distribuido, un sistema de memoria distribuida, un sistema basado en tecnología de registro contable distribuido (DLT) (DLTS), un sistema de bases de datos a prueba de revisión, una nube, un servicio en la nube, una cadena de bloques en una nube o una base de datos peer-to-peer. Por ejemplo, también se pueden usar diferentes implementaciones de una cadena de bloques o un DLTS, como, por ejemplo, una cadena de bloques o un DLTS, que mediante un gráfico acíclico dirigido (DAG), un rompecabezas criptográfico, un gráfico hash o una combinación de las variantes de implementación mencionadas [6][7]. También se pueden implementar diferentes procedimientos de consenso (en inglés, consensus algorithms), por ejemplo. Esto puede ser, por ejemplo, un procedimiento de consenso usando un rompecabezas criptográfico, Gossip about Gossip, Virtual Voting o una combinación de los procedimientos mencionados (por ejemplo, Gossip about Gossip combinado con Virtual Voting) [6][7]. Si, por ejemplo, se usa una cadena de bloques, se puede implementar en particular mediante una implementación basada en Bitcoin o una implementación basada en Ethereum [1][4][5]. También puede entenderse que un “sistema de bases de datos distribuidas” significa, por ejemplo, un sistema de bases de datos distribuidas del cual al menos algunos de sus nodos y/o dispositivos y/o infraestructura están implementados por una nube. Por ejemplo, los componentes correspondientes se implementan como nodos/dispositivos en la nube (por ejemplo, como nodos virtuales en una máquina virtual). Esto se puede hacer por medio de VM-Ware, Amazon Web Services o Microsoft Azure, por ejemplo. Debido a la alta flexibilidad de las variantes de implementación explicadas, en particular los subaspectos de las variantes de implementación mencionadas pueden combinarse entre sí mediante, por ejemplo, un gráfico hash como cadena de bloques, con lo que la propia cadena de bloques, por ejemplo, también puede ser sin bloques.
Si, por ejemplo, se usa un gráfico acíclico dirigido (DAG) (por ejemplo, IOTA o Tangle), en particular, las transacciones o bloques o nodos del gráfico se conectan entre sí a través de bordes dirigidos. Esto significa en particular que (todos) los bordes (siempre) tienen la misma dirección, similar a, por ejemplo, la del momento. En otras palabras, en particular, no es posible comenzar o saltar a las transacciones o los bloques o los nodos del gráfico hacia atrás (es decir, contra la misma dirección común). Acíclico significa, en particular, que no hay bucles cuando se recorre el gráfico.
El sistema de bases de datos distribuidas puede ser, por ejemplo, un sistema de bases de datos distribuidas público (por ejemplo, una cadena de bloques pública) o un sistema de bases de datos distribuidas cerrado (o privado) (por ejemplo, una cadena de bloques privada).
Por ejemplo, si se trata de un sistema de bases de datos distribuidas público, esto significa que los nuevos nodos y/o dispositivos pueden unirse o ser aceptados por el sistema de bases de datos distribuidas sin prueba de autorización o sin autenticación o sin información de inicio de sesión o credenciales. En particular, los operadores de los nodos y/o dispositivos pueden permanecer en el anonimato en tal caso.
Si el sistema de bases de datos distribuidas es, por ejemplo, un sistema de bases de datos distribuidas cerrado, los nuevos nodos y/o dispositivos requieren, por ejemplo, una prueba de autorización válida y/o información de autenticación válida y/o credenciales válidas y/o información de inicio de sesión válida para poder unirse a o ser aceptados por el sistema de bases de datos distribuidas.
Un sistema de bases de datos distribuidas también puede ser, por ejemplo, un sistema de comunicación distribuida para el intercambio de datos o un sistema de comunicación peer 2 peer o una aplicación peer 2 peer. Esto puede ser, por ejemplo, una red o una red peer-2-peer.
Un/el sistema de bases de datos distribuidas también puede ser, por ejemplo, un sistema de bases de datos distribuidas descentralizado y/o un sistema de comunicación distribuida descentralizado.
En relación con la invención, por ejemplo, un bloque de datos de un sistema de bases de datos distribuidas (por ejemplo, una cadena de bloques o una base de datos peer to peer) puede denominarse "bloque de datos", que, según el contexto y la implementación, también puede denominarse "eslabón" o "bloque", que se implementa en particular como una estructura de datos y comprende preferentemente una o más de las transacciones. En una implementación, por ejemplo, la base de datos (o el sistema de bases de datos) puede ser un sistema basado en DLT (DLTS) o una cadena de bloques y un bloque de datos puede ser un bloque de la cadena de bloques o el DLTS. Un bloque de datos puede, por ejemplo, comprender información sobre el tamaño (tamaño de los datos en bytes) del bloque de datos, un encabezado del bloque de datos (en inglés block-header), un contador de transacciones y una o más transacciones [1]. El encabezado del bloque de datos puede comprender, por ejemplo, una versión, una suma de verificación de concatenación, una suma de verificación de bloque de datos, una marca de tiempo, una evidencia de prueba de trabajo y un nonce (valor único, valor aleatorio o contador que se usa para la evidencia de prueba de trabajo) [1][4][5]. Un bloque de datos también puede ser, por ejemplo, solo un área de memoria específica o un área de direcciones de los datos generales que se almacenan en el sistema de bases de datos distribuidas. Esto permite, por ejemplo, implementar sistemas de bases de datos distribuidas sin bloques (en inglés blockless), como, por ejemplo, IoT Chain (ITC), IOTA y Byteball. En particular, las funcionalidades de los bloques de una cadena de bloques y las transacciones se combinan entre sí de tal manera que, por ejemplo, las propias transacciones aseguran la secuencia o cadena de transacciones (del sistema de bases de datos distribuidas) (es decir, en particular, se almacenan de manera segura). Para ello, por ejemplo, las transacciones en sí pueden concatenarse entre sí con una suma de verificación de concatenación utilizando preferentemente una suma de verificación separada o la suma de verificación de transacción de una o más transacciones como suma de verificación de concatenación, que se almacena en la nueva transacción correspondiente cuando una nueva transacción se almacena en el sistema de bases de datos distribuidas. En un modo de realización de este tipo, un bloque de datos también puede comprender, por ejemplo, una o más transacciones, en el que en el caso más simple, por ejemplo, un bloque de datos corresponde a una transacción.
En relación con la invención, se puede entender que "nonce" significa, por ejemplo, un nonce criptográfico (abreviatura de: "used only once"[2] o "number used once"[3]). En particular, un nonce denota una única combinación de números o letras que se usa, preferentemente, solo una vez en el contexto respectivo (por ejemplo, transacción, transmisión de datos).
En relación con la invención, se puede entender que "bloques de datos anteriores de un bloque de datos (específico) del sistema de bases de datos distribuidas" significa, por ejemplo, el bloque de datos del sistema de bases de datos distribuidas que, en particular, es directamente anterior a un bloque de datos (específico). De forma alternativa, también puede entenderse que "bloques de datos anteriores de un bloque de datos (específico) del sistema de bases de datos distribuidas" significa, en particular, todos los bloques de datos del sistema de bases de datos distribuidas que son anteriores al bloque de datos específico. De esta manera, por ejemplo, la suma de verificación de concatenación o la suma de verificación de transacción solo se pueden formar en particular sobre el bloque de datos (o sus transacciones) directamente anterior al bloque de datos específico o sobre todos los bloques de datos (o sus transacciones) anteriores al primer bloque de datos.
En relación con la invención, se puede entender que un "nodo de cadena de bloques", "nodo", "nodo de un sistema de bases de datos distribuidas" y similares significan, por ejemplo, dispositivos (por ejemplo, dispositivos de campo), ordenadores, teléfonos inteligentes, clientes o participantes que realizan operaciones (con) el sistema de bases de datos distribuidas (por ejemplo, una cadena de bloques) [1][4][5]. Dichos nodos pueden, por ejemplo, realizar transacciones de un sistema de bases de datos distribuidas o sus bloques de datos o insertar o concatenar nuevos bloques de datos con nuevas transacciones en el sistema de bases de datos distribuidas por medio de nuevos bloques de datos. En particular, esta validación y/o concatenación puede ser realizada por un nodo fiable (por ejemplo, un nodo de minería) o exclusivamente por nodos fiables. Un nodo fiable es, por ejemplo, un nodo que tiene medidas de seguridad adicionales (por ejemplo, cortafuegos, restricciones de acceso al nodo o similares) para evitar la manipulación del nodo. De forma alternativa o además, por ejemplo, se puede insertar un nodo fiable cuando en un nuevo bloque de datos se inserta un bloque de datos correspondiente de un nodo específico o se indica su origen. Los dispositivos (por ejemplo, el dispositivo correspondiente) son, por ejemplo, dispositivos de un sistema técnico y/o planta industrial y/o una red de automatización y/o una planta de fabricación, que en particular también son un nodo del sistema de bases de datos distribuidas. En este caso, los dispositivos pueden ser, por ejemplo, dispositivos de campo, o dispositivos en el Internet de las cosas, que en particular también son un nodo del sistema de bases de datos distribuidas. Por ejemplo, los nodos también pueden comprender al menos un procesador para, por ejemplo, ejecutar su funcionalidad implementada por ordenador.
En relación con la invención, se puede entender que un "oráculo de cadena de bloques" y similares significan, por ejemplo, nodos, dispositivos u ordenadores que tienen un módulo de seguridad que comprende, por ejemplo, mecanismos de protección de software (por ejemplo, procedimientos criptográficos), dispositivos de protección mecánicos (por ejemplo, una carcasa con cerradura) o dispositivos de protección eléctricos (por ejemplo, protección contra manipulaciones o un sistema de protección que borra los datos del módulo de seguridad en caso de uso/tratamiento no autorizado del oráculo). El módulo de seguridad puede comprender, por ejemplo, claves criptográficas que son necesarias para calcular las sumas de verificación (por ejemplo, sumas de verificación de transacción o sumas de verificación de nodos).
En relación con la invención, se puede entender que un "ordenador" significa, por ejemplo, un ordenador (sistema), un cliente, un teléfono inteligente, un dispositivo o un servidor, que están dispuestos, cada uno, fuera de la cadena de bloques o no participan en el sistema de bases de datos distribuidas (por ejemplo, de la cadena de bloques) (es decir, no realiza ninguna operación con el sistema de bases de datos distribuidas o solo las consulta sin, no obstante, realizar transacciones, insertar bloques de datos o calcular evidencias de prueba de trabajo). De forma alternativa, también puede entenderse que un ordenador significa un nodo del sistema de bases de datos distribuidas. En otras palabras, puede entenderse que en particular un dispositivo significa un nodo del sistema de bases de datos distribuidas o también un dispositivo fuera de la cadena de bloques o del sistema de bases de datos distribuidas. Un dispositivo fuera del sistema de bases de datos distribuidas puede, por ejemplo, acceder a los datos (por ejemplo, transacciones o transacciones de control) del sistema de bases de datos distribuidas y/o ser accionado por nodos (por ejemplo, por medio de contratos inteligentes y/o oráculos de cadena de bloques). Si, por ejemplo, un nodo implementa un accionamiento o control de un dispositivo (por ejemplo, un dispositivo diseñado como un nodo o un dispositivo fuera del sistema de bases de datos distribuidas), esto puede, por ejemplo, realizarse por medio de un contrato inteligente, que se almacena en particular en una transacción del sistema de bases de datos distribuidas. Un dispositivo o nodo puede comprender un actuador, por ejemplo. Un dispositivo o nodo también puede ser un dispositivo o sistema mecatrónico, por ejemplo, un dispositivo/sistema mecatrónico que es, por ejemplo, un actuador y/o un dispositivo técnico lineal. Un dispositivo técnico lineal es, por ejemplo, un dispositivo para realizar movimientos de traslación. Un dispositivo correspondiente también puede ser un sistema de accionamiento, por ejemplo. Un dispositivo o nodo puede ser, por ejemplo, un dispositivo/nodo criptográfico (por ejemplo, para realizar autenticación de usuario o autentificación de usuario).
Con la invención es posible, en particular, implementar una infraestructura descentralizada para la ejecución de comandos de control. En particular, esto permite que los dispositivos en Internet de las cosas se controlen de manera descentralizada, incluso si los operadores individuales de dispositivos y/o grupos de dispositivos no confían entre sí. La preferencia ilegal por un nodo (por ejemplo, mediante fraude/soborno) puede resultar significativamente más difícil si, por ejemplo, se utiliza una implementación basada en cadena de bloques del sistema de bases de datos distribuidas, ya que la protección de confianza o la protección contra manipulación se implementa de manera análoga al Bitcoin para transacciones de control o transacciones de confirmación. En particular, no hay necesidad de una entidad central que autentique los nodos. Si, por ejemplo, el sistema de bases de datos se implementa mediante una cadena de bloques, que en particular implementa una criptomoneda como Bitcoin, entonces, por ejemplo, se puede proporcionar una facturación simple y eficiente para procesar los comandos de control a un cliente que ha configurado los comandos de control o que tiene una secuencia de comandos (de la que, por ejemplo, se derivan los comandos de control).
Además, por ejemplo, la seguridad cuando se opera el sistema de bases de datos distribuidas (por ejemplo, una cadena de bloques) se puede incrementar, ya que se introdujo una verificación adicional, en particular para la ejecución de los comandos de control. En otras palabras, en particular, las transacciones no verificadas o los comandos de control se convierten en transacciones verificadas, en los que la verificación se lleva a cabo, por ejemplo, sobre la base de las propiedades de nodo o dispositivo de los dispositivos o nodos (por ejemplo, los datos específicos de dispositivo) que deben ejecutar los comandos de control.
También es concebible, por ejemplo, que el procedimiento se pueda usar para mejorar o hacer más segura la retirada de efectivo en los cajeros automáticos si el cajero automático es, por ejemplo, un nodo del sistema de bases de datos distribuidas o usa un nodo del sistema de bases de datos distribuidas u otra interfaz para acceder a o recuperar las transacciones de control correspondientes del sistema de bases de datos distribuidas.
De forma alternativa o además, los requisitos de ejecución pueden, por ejemplo, comprender también especificaciones adicionales a considerar para la ejecución. Esto puede, por ejemplo, ser un requisito de que se deba pagar una determinada tarifa para que un comando de control pueda ser procesado por un nodo o dispositivo correspondiente. Esto puede almacenarse, por ejemplo, en los requisitos específicos de dispositivo en el sentido de que el dispositivo requiere el pago de una tarifa predefinida por su uso o para procesar comandos de control. La tarifa predefinida se puede pagar, por ejemplo, utilizando criptomonedas, que preferentemente también se documentan o almacenan en transacciones en el sistema de bases de datos distribuidas. También puede verificarse si se cumplen estos requisitos (por ejemplo, pago de tarifas), por ejemplo, mediante el módulo de marcado o la unidad de evaluación, mediante el cual se verifica, por ejemplo, si están disponibles las transacciones para el pago correspondiente de las tarifas en el sistema de bases de datos distribuidas. De forma alternativa, por ejemplo, también se puede verificar el saldo de una cuenta en un banco para determinar si se ha realizado el pago de la tarifa correspondiente. Cuando estas especificaciones de los requisitos de ejecución se han cumplido, por ejemplo, para los comandos de control correspondientes, estos pueden procesarse más y, como ya se explicó, almacenarse en transacciones de control.
En un primer modo de realización del sistema de control, los comandos de control presupuestos ya son comandos de control ejecutados para los cuales se almacena una confirmación de su ejecución en transacciones de confirmación (de los bloques de datos) del sistema de bases de datos distribuidas.
El sistema de control es ventajoso para, en particular, predefinir una secuencia para la ejecución o procesamiento de los comandos de control por el dispositivo correspondiente por medio de los comandos de control presupuestos.
En particular, los comandos de control presupuestos pueden ser comandos de control de la misma secuencia de comandos, que en particular deben ejecutarse antes de que los comandos de control sean ejecutados (actualmente) por el dispositivo correspondiente. En particular, en este caso los comandos de control presupuestos también se almacenaron en transacciones de control, que a su vez se almacenan en bloques de datos (es decir, un bloque de datos o varios bloques de datos) del sistema de bases de datos distribuidas.
En otros modos de realización del sistema de control, los requisitos de ejecución predefinen un límite de tiempo hasta el cual deben procesarse los comandos de control.
El sistema de control es ventajoso para, en particular, por medio de los requisitos de ejecución, para comandos de control predefinidos o seleccionados predefinir un límite de tiempo, hasta el cual los comandos de control deben ser procesados por el dispositivo correspondiente. Si se supera este límite de tiempo, por ejemplo, el módulo de verificación puede, en particular, proporcionar una señal de control para reaccionar ante la superación del límite de tiempo. Un empleado de producción, un técnico de servicio o una señal de alarma, por ejemplo, pueden ser informados o controlados automáticamente por medio de la señal de control. Por ejemplo, también se puede reiniciar el proceso de fabricación.
En otros modos de realización del sistema de control, los registros de datos de marcado comprenden identificadores únicos para los dispositivos y/o nodos que deben ejecutar los comandos de control correspondientes.
Esto es ventajoso para permitir que los dispositivos/nodos determinen rápidamente, por ejemplo, si los comandos de control correspondientes pueden, por ejemplo, ser ejecutados mediante un dispositivo específico. Por ejemplo, se asigna un identificador único (Unique Identifier (UID)) a los dispositivos o nodos. En particular, el sistema de control o el módulo de marcado conoce los identificadores únicos correspondientes de los dispositivos (por ejemplo, almacenados con los datos en dispositivos/nodos en la memoria de configuración) y, al asignar los comandos de control, asigna los identificadores únicos correspondientes a los comandos de control en sí mismos y/o mediante el registro de datos de marcado y/o mediante la transacción de control. Los identificadores únicos destinados o asignados son, en particular, los identificadores únicos correspondientes de los dispositivos o de los nodos que deben ejecutar los comandos de control.
En otros modos de realización del sistema de control, el sistema de control comprende un optimizador, que optimiza una ejecución de los comandos de control por parte de los dispositivos sobre la base de un criterio predefinido.
El sistema de control es ventajoso para optimizar, en particular, un proceso de fabricación de acuerdo con los criterios predefinidos. Los criterios predefinidos pueden ser, por ejemplo, el tiempo de fabricación, los costes incurridos o la energía a utilizar. Por ejemplo, el optimizador puede dividir una secuencia de comandos en comandos de control, que a su vez se almacenan en las transacciones de control. En este caso el optimizador divide la secuencia de comandos en los comandos de control según el criterio predefinido. Si, por ejemplo, el criterio es optimizar el tiempo de fabricación en la producción de un producto (por ejemplo, para mantener el tiempo de fabricación del producto lo más corto posible), la secuencia de comandos se descompone de tal manera que los componentes individuales sean fabricados en paralelo por varios dispositivos, es decir, los comandos de control correspondientes en las transacciones de control serán procesados por estos. Si, por ejemplo, el criterio es optimizar los costes de fabricación en la producción de un producto, la secuencia de comandos se descompone de tal manera que los componentes individuales sean producidos en serie por un dispositivo (por ejemplo, el dispositivo correspondiente) o tan pocos dispositivos como sea posible, es decir, los comandos de control correspondientes en las transacciones de control deben ser procesados por el correspondiente. Para controlar esto, por ejemplo, el optimizador transfiere la información correspondiente al módulo de marcado, de modo que el módulo de marcado almacena esta información en los requisitos de ejecución. El optimizador puede ser, por ejemplo, un módulo separado o una parte integral del módulo de marcado. De forma alternativa, el optimizador puede, por ejemplo, llevar a cabo la optimización basándose en los requisitos de ejecución o incluso crear los requisitos de ejecución él mismo y proporcionarlos al módulo de marcado.
En otros modos de realización del sistema de control, el sistema de bases de datos distribuidas es una cadena de bloques y los bloques de datos son bloques de la cadena de bloques, o el sistema de bases de datos distribuidas es un sistema de bases de datos peer-2-peer.
El sistema de control es ventajoso para, en particular, implementar una infraestructura de sistema de control descentralizado. Además, un sistema de control de este tipo se puede implementar, incluso si los operadores de los dispositivos no confían entre sí.
En otros modos de realización del sistema de control, los bloques de datos se concatenan entre sí mediante una función hash criptográfica.
En otros modos de realización del sistema de control, el sistema de control comprende, en el que el módulo de actividad está configurado para mostrar y/o documentar la actividad del sistema de control.
El sistema de control es ventajoso para que un administrador pueda verificar la actividad durante el funcionamiento, por ejemplo, mediante una lámpara de estado, una señal de latido o una señal de control. De forma alternativa, el módulo de actividad puede, por ejemplo, escribir información en un archivo para documentar, por ejemplo, estados del sistema o reinicios de nodos o módulos.
De acuerdo con otro aspecto, la invención se refiere a un módulo de marcado para un sistema de bases de datos distribuidas o para un sistema de control con un sistema de bases de datos distribuidas para controlar y/o supervisar dispositivos, que presenta:
- en particular una primera interfaz (810) para recibir o recuperar comandos de control;
- una primera unidad de evaluación (820) para asignar registros de datos de marcado, en la que
- en cada caso, uno de los registros de datos de marcado se asigna a los respectivos comandos de control en función de los requisitos de ejecución, si los comandos de control correspondientes cumplen los requisitos de ejecución,
- los comandos de control a los que se asigna uno de los respectivos registros de datos de marcado pueden ser ejecutados por nodos de un sistema de bases de datos distribuidas o por dispositivos, en el que
- los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan en los requisitos de ejecución;
El módulo de marcado es ventajoso para mejorar, en particular, la ejecución de comandos de control por dispositivos o nodos (por ejemplo, robots de fabricación, sistemas de control para una red de distribución de energía, terminales bancarias, cajeros automáticos, transferencias de dinero entre bancos) que están conectados entre sí a través de una red.
Además, por ejemplo, se puede aumentar la seguridad al operar una infraestructura distribuida (por ejemplo, un sistema de bases de datos distribuidas con dispositivos y/o nodos o con dispositivos que acceden al sistema de bases de datos distribuidas), que es implementada total o parcialmente mediante un sistema de bases de datos distribuidas (por ejemplo, una cadena de bloques). En particular, el término "comandos de control" debe entenderse de forma amplia. Además de la definición mencionada anteriormente, esto también puede involucrar transacciones que deben ser ejecutadas por un dispositivo (por ejemplo, un nodo en una cadena de bloques o un dispositivo fuera de la cadena de bloques, por ejemplo, el dispositivo D). En otras palabras, en particular, mediante el dispositivo las transacciones no verificadas se convierten en transacciones verificadas, en las que la verificación se lleva a cabo, por ejemplo, sobre la base de los requisitos específicos de dispositivo y los datos específicos de dispositivo que deben ejecutar los comandos de control.
Por medio de la invención, por ejemplo, se pueden garantizar los requisitos específicos de dispositivo necesarios para la ejecución de los comandos de control en el dispositivo. Los requisitos específicos de dispositivo también pueden ser, por ejemplo, requisitos de seguridad y/o requisitos específicos de la ubicación (por ejemplo, indicación del país, indicación de GPS o código postal) que un dispositivo debe cumplir para ejecutar los comandos de control. O, por ejemplo, los requisitos específicos de dispositivo para la ejecución también pueden requerir una autenticación y/o autentificación determinada/predefinida.
Este puede ser el caso, por ejemplo, si alguien quiere retirar efectivo de un dispositivo (por ejemplo, un cajero automático). Los comandos de control son entonces, por ejemplo, la solicitud del cliente de realizar una retirada de efectivo. Por ejemplo, si un cliente correspondiente ha configurado (por ejemplo, en su banco local o banca en línea) que, por ejemplo, solo en países específicos, por ejemplo, Italia, Francia y Austria se permite una retirada de efectivo, esto se almacena en los requisitos específicos de dispositivo (y, por tanto, en particular, implícitamente también en los requisitos de ejecución). Un cajero automático en Andorra posiblemente no permitiría o evitaría una retirada. También puede ser necesario un procedimiento de autenticación y/o autentificación específico de cliente, por ejemplo, debido a los requisitos de seguridad. Para ello, por ejemplo, se puede introducir o solicitar un pin para una retirada (que no es necesariamente el caso en los EE. UU., por ejemplo) y/o se puede requerir una longitud determinada de pin (por ejemplo, 8 caracteres) y/o es posible que se requieran otros procedimientos de autenticación adicionales (por ejemplo, autenticación de 2 factores, Mobile-Tan, Google Authenticator).
De forma alternativa, el módulo de marcado, por ejemplo, la unidad de evaluación, también puede analizar los comandos de control y, por ejemplo, si el módulo de marcado o la (primera) unidad de evaluación ya ha determinado que los requisitos específicos de dispositivo no se cumplen o no se pueden cumplir (por ejemplo, los comandos de control fueron enviados desde un país no aprobado o están destinados a un dispositivo o nodo en un país no aprobado), crear una transacción de control que lo indique al dispositivo o sistema correspondiente y preferentemente impida o prohíba la ejecución de los comandos de control. De forma alternativa, por ejemplo, no se puede generar ninguna transacción de control y/o registro de datos de marcado y en algún momento hay un tiempo de espera para la ejecución de los comandos de control, por ejemplo, después de un período predefinido. De forma alternativa o además, por ejemplo, se puede proporcionar una señal de control que, si los comandos de control no se pueden ejecutar, por ejemplo, informa a un técnico o controla una señal de advertencia.
También sería concebible, por ejemplo, que la banca en línea esté protegida de esta manera verificando los requisitos de seguridad y/o los requisitos relacionados con la ubicación del ordenador (es decir, el dispositivo que envía los comandos de control) y si la retirada está permitida mediante otro dispositivo.
Además, el módulo de marcado también puede comprender, por ejemplo, un primer módulo de asignación y/o un primer módulo de memoria y/o módulos adicionales, como se explicó en los ejemplos de modo de realización. Los nodos o dispositivos pueden entonces comprender, por ejemplo, un módulo de verificación y/o un módulo de ejecución, como se explicó en los ejemplos de modo de realización o modos de realización. En particular, otras características de los otros aspectos y ejemplos de modo de realización de la invención también pueden transferirse a este aspecto de la invención.
Los requisitos específicos de dispositivo para nodos o dispositivos pueden, por ejemplo, también estar relacionados con el usuario o comprender requisitos específicos de usuario. Por ejemplo, un primer usuario puede exigir un bajo nivel de precisión en la fabricación de una pieza de trabajo en los requisitos específicos de dispositivo que se le asignan. Por ejemplo, un segundo usuario puede exigir entonces un alto nivel de precisión en la fabricación de una pieza de trabajo en los requisitos específicos de dispositivo que se le asignan. De esta forma, por ejemplo, también se pueden almacenar requisitos de seguridad relacionados con el usuario. También es concebible, por ejemplo, que a tipos específicos o tipos de comandos de control, relacionados con el usuario o no, se les asignen requisitos específicos de dispositivo que el módulo de marcado tenga en cuenta o verifique. Por ejemplo, puede ser necesario que un comando de control para cargar firmware solo sea emitido por un dispositivo que cumpla con los requisitos de seguridad especificados, por ejemplo, para asegurarse de que el firmware no sea fácilmente accesible para todos en una planta de fabricación. Estos requisitos de seguridad predefinidos pueden, por ejemplo, requerir que solo determinado personal tenga acceso a un dispositivo correspondiente o que el dispositivo esté protegido por una contraseña y/u otros mecanismos criptográficos (por ejemplo,
el acceso solo es posible insertando una tarjeta con chip e introduciendo un pin).
Si el módulo de marcado determina, por ejemplo, que ningún nodo y/o dispositivo (por ejemplo, una planta de fabricación) admite o cumple los requisitos de ejecución, no se crea ningún registro de datos de marcado o se crea un registro de datos de marcado que indica que los comandos de control correspondientes no pueden ser ejecutados o pueden ser ejecutados. Además, el módulo de marcado puede, por ejemplo, considerar una política de ejecución que especifique qué comandos de control son aceptados y/o serán ejecutados por los nodos y/o dispositivos. Por ejemplo, se puede especificar a través de esta política de ejecución general que determinados comandos de control especificados generalmente no deben ser ejecutados por los dispositivos y/o nodos (por ejemplo, porque su ejecución es demasiado costosa o con un desgaste excesivo en un dispositivo (por ejemplo, una máquina herramienta)), aunque los dispositivos y/o nodos podrían ejecutar los comandos de control correspondientes. Una política de ejecución de este tipo puede, por ejemplo, también ser parte de los requisitos de ejecución o comprenderlos.
En otras palabras, el módulo de marcado puede servir como filtro para comandos de control o transacciones de control para, por ejemplo, prevenir la ejecución de comandos de control que no estén permitidos para ser ejecutados por los dispositivos y/o nodos o cuyos requisitos de ejecución no se cumplan. Esto en particular evita que dichos comandos de control o transacciones de control no deseados se distribuyan a los dispositivos y/o nodos en un sistema de bases de datos distribuidas o que verifiquen las transacciones de control ejecutables para los dispositivos y/o nodos. También se consigue que a los comandos de control ejecutables se les asigne, preferentemente, un registro de datos de marcado correspondiente.
De forma alternativa o además, los requisitos de ejecución pueden, por ejemplo, comprender también especificaciones adicionales a considerar para la ejecución. Esto puede, por ejemplo, ser un requisito de que se deba pagar una determinada tarifa para que un comando de control pueda ser procesado por un nodo o dispositivo correspondiente. Esto puede almacenarse, por ejemplo, en los requisitos específicos de dispositivo en el sentido de que el dispositivo requiere el pago de una tarifa predefinida por su uso o para procesar comandos de control. La tarifa predefinida se puede pagar, por ejemplo, utilizando criptomonedas, que preferentemente también se documentan o almacenan en transacciones en el sistema de bases de datos distribuidas. También puede verificarse si se cumplen estos requisitos (por ejemplo, pago de tarifas), por ejemplo, mediante el módulo de marcado o la unidad de evaluación, mediante el cual se verifica, por ejemplo, si están disponibles las transacciones para el pago correspondiente de las tarifas en el sistema de bases de datos distribuidas. De forma alternativa, por ejemplo, también se puede verificar el saldo de una cuenta en un banco para determinar si se ha realizado el pago de la tarifa correspondiente. Cuando estas especificaciones de los requisitos de ejecución se han cumplido, por ejemplo, para los comandos de control correspondientes, estos pueden procesarse más y, como ya se explicó, almacenarse en transacciones de control.
En otros modos de realización del módulo de marcado, el módulo de marcado comprende un optimizador, en el que el optimizador optimiza la ejecución de los comandos de control por los dispositivos sobre la base de un criterio predefinido.
En otros modos de realización del módulo de marcado, el módulo de marcado comprende un primer módulo de descomposición, en el que el primer módulo de descomposición está configurado para dividir una secuencia de comandos en los comandos de control correspondientes. Los comandos de control correspondientes se proporcionan, por ejemplo, al sistema de control o al primer módulo de marcado. Preferentemente, los comandos de control correspondientes se proporcionan al sistema de control a través del módulo de marcado de modo que, por ejemplo, el sistema de control transfiere las transacciones de control correspondientes con comandos de control a través del sistema de bases de datos distribuidas a los nodos o dispositivos.
En otros modos de realización del módulo de marcado, el módulo de marcado comprende un módulo de actividad, en el que el módulo de actividad está configurado para mostrar o documentar la actividad del módulo de marcado.
El módulo de marcado es ventajoso para que un administrador pueda verificar la actividad durante el funcionamiento, por ejemplo, mediante una lámpara de estado, una señal de latido o una señal de control. De forma alternativa, el módulo de actividad puede, por ejemplo, escribir información en un archivo para documentar, por ejemplo, estados del sistema o reinicios de nodos o módulos o del módulo de marcado.
En otros modos de realización del módulo de marcado, el módulo de marcado comprende una memoria de configuración que comprende datos específicos de dispositivo sobre los dispositivos y/o datos específicos de dispositivo sobre los nodos y/o los requisitos específicos de dispositivo.
El módulo de marcado es ventajoso para, en particular, acceder rápidamente a los datos específicos de dispositivo y/o para configurar los requisitos específicos de dispositivo para determinadas transacciones o dispositivos de antemano. La memoria de configuración se puede implementar, por ejemplo, mediante bloques o bloques de datos del sistema de bases de datos distribuidas. Los requisitos específicos de dispositivo para nodos o dispositivos pueden, por ejemplo, también estar relacionados con el usuario. Por ejemplo, un primer usuario puede exigir un bajo nivel de precisión en la fabricación de una pieza de trabajo en los requisitos específicos de dispositivo que se le asignan. Por ejemplo, un segundo usuario puede exigir entonces un alto nivel de precisión en la fabricación de una pieza de trabajo en los requisitos específicos de dispositivo que se le asignan. De esta forma, también se pueden almacenar requisitos de seguridad relacionados con el usuario. También es concebible, por ejemplo, que a tipos específicos o tipos de comandos de control, relacionados con el usuario o no, se les asignen requisitos específicos de dispositivo que el módulo de marcado tenga en cuenta para crear el registro de datos de marcado. Por ejemplo, puede ser necesario que un comando de control para cargar firmware solo sea emitido por un dispositivo que cumpla con los requisitos de seguridad especificados, por ejemplo, para asegurarse de que el firmware no sea fácilmente accesible para todos en una planta de fabricación. Estos requisitos de seguridad predefinidos pueden, por ejemplo, requerir que solo determinado personal tenga acceso a un dispositivo correspondiente o que el dispositivo esté protegido por una contraseña y/u otros mecanismos criptográficos (por ejemplo, el acceso solo es posible insertando una tarjeta con chip e introduciendo un pin).
En otros modos de realización del módulo de marcado, el módulo de marcado comprende una interfaz administrativa.
El módulo de marcado es ventajoso para, en particular, permitir una configuración del módulo de marcado. Por ejemplo, los requisitos específicos de dispositivo se pueden configurar a través de la interfaz administrativa y, preferentemente, se pueden almacenar en el sistema de bases de datos distribuidas.
En otros modos de realización del módulo de marcado, el módulo de marcado comprende una unidad de adquisición para adquirir datos específicos de dispositivo sobre los dispositivos o datos específicos de dispositivo sobre los nodos.
El módulo de marcado es ventajoso para, en particular, facilitar y acelerar la verificación y la creación de los datos específicos de dispositivo. Aunque el módulo de marcado podría solicitar estos datos de nuevo a los dispositivos o nodos para cada determinación individual, sin embargo, es más conveniente, en particular, que la unidad de adquisición solicite estos datos, por ejemplo, en tiempos o intervalos predeterminados, por ejemplo, y los almacene en una memoria de configuración o los nodos y dispositivos lo hagan de forma independiente, por ejemplo, después de encender, en momentos o intervalos predeterminados, en el que esta información se transmite a la unidad de detección. Si la unidad de adquisición se implementa, por ejemplo, como un contrato inteligente para el sistema de bases de datos distribuidas, esto también se puede hacer, por ejemplo, al conectarse al sistema de bases de datos distribuidas.
En otros modos de realización del módulo de marcado, el módulo de marcado es un nodo de un sistema de bases de datos distribuidas o un contrato inteligente de un sistema de bases de datos distribuidas o está conformado como un dispositivo.
En otros modos de realización del módulo de marcado, el módulo de marcado comprende un primer módulo de asignación para asignar los respectivos requisitos de ejecución a los comandos de control.
En otros modos de realización del módulo de marcado, la primera unidad de evaluación determina los requisitos de ejecución para la ejecución sobre la base de una ejecutabilidad de los comandos de control por un nodo de los datos distribuidos o un dispositivo, en el que, en particular, los requisitos de ejecución dependen de un resultado de una verificación de la ejecutabilidad de los comandos de control por un nodo del sistema de bases de datos distribuidas o un dispositivo.
De acuerdo con otro aspecto, la invención se refiere a un procedimiento para el control asistido por ordenador de dispositivos con las siguientes etapas de procedimiento:
- asignación de registros de marcado, en el que
- en cada caso, uno de los registros de datos de marcado se asigna a comandos de control en función de los requisitos de ejecución, si los comandos de control correspondientes cumplen los requisitos de ejecución, - los comandos de control a los que se asigna uno de los respectivos registros de datos de marcado pueden ser ejecutados por nodos de un sistema de bases de datos distribuidas (BC) o por dispositivos, en el que - los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan en los requisitos de ejecución;
- Almacenar los respectivos comandos de control con su respectivo registro de datos de marcado asociado en transacciones de control, en el que
- las transacciones de control se almacenan en el sistema de bases de datos distribuidas (BC);
- las transacciones de control se transmiten a los dispositivos (D, BCN_D) o nodos (BCN, BCN_D) por medio del sistema de bases de datos distribuidas (BC).
De acuerdo con otro aspecto, la invención se refiere a un procedimiento para el marcado asistido por ordenador de comandos de control con las siguientes etapas de procedimiento:
- Recibir (910) o recuperar comandos de control;
- asignación de registros de marcado, en el que
- en cada caso, uno de los registros de datos de marcado se asigna a los comandos de control en función de los requisitos de ejecución, si los comandos de control correspondientes cumplen los requisitos de ejecución,
- los comandos de control a los que se asigna uno de los respectivos registros de datos de marcado pueden ser ejecutados por nodos de un sistema de bases de datos distribuidas o por dispositivos,
- los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan en los requisitos de ejecución.
En otros modos de realización del procedimiento, el procedimiento comprende otras etapas de procedimiento para implementar las características funcionales o para implementar características adicionales del sistema de control. Además, se reivindica un producto de programa informático con comandos de programa para llevar a cabo los procedimientos mencionados de acuerdo con la invención, en el que uno de los procedimientos de acuerdo con la invención, todos los procedimientos de acuerdo con la invención o una combinación de los procedimientos de acuerdo con la invención pueden ser llevado a cabo por medio del producto de programa informático.
Además, se reivindica una variante del producto de programa informático con comandos de programa para configurar un dispositivo de creación, por ejemplo una impresora 3D, un sistema informático o una máquina de fabricación adecuada para la creación de procesadores y/o dispositivos, en el que el dispositivo de creación con los comandos de programa está configurado de tal manera que se cree dicho sistema de bases de datos distribuidas inventivo y/o el primer sistema de bases de datos distribuidas y/o el sistema de control y/o el dispositivo. Además, se reivindica un dispositivo de provisión para almacenar y/o proporcionar el producto de programa informático. El dispositivo de provisión es, por ejemplo, un soporte de datos que almacena y/o proporciona el producto de programa informático. De forma alternativa y/o además, el dispositivo de provisión es, por ejemplo, un servicio de red, un sistema informático, un sistema servidor, en particular un sistema informático distribuido, un sistema informático basado en la nube y/o un sistema informático virtual, que almacena y/o proporciona el producto programa informático preferentemente en forma de flujo de datos.
Esta provisión se realiza, por ejemplo, como descarga en forma de bloque de datos de programa y/o bloque de datos de comando, preferentemente como archivo, en particular como archivo de descarga, o como flujo de datos, en particular como flujo de datos de descarga, del producto de programa informático completo. Esta provisión puede tener lugar, por ejemplo, también como una descarga parcial, que consta de varias partes y, en particular, se descarga a través de una red peer-to-peer o se proporciona como un flujo de datos. Un producto de programa informático de este tipo se lee en un sistema, por ejemplo, utilizando el dispositivo de provisión en forma de soporte de datos y ejecuta los comandos de programa de modo que el procedimiento de acuerdo con la invención se ejecuta en un ordenador o el dispositivo de creación se configura en de modo que crea el sistema de bases de datos distribuidas de acuerdo con la invención y/o el primer sistema de bases de datos distribuidas y/o el sistema de control y/o el dispositivo.
Las propiedades, características y ventajas descritas anteriormente de esta invención así como el tipo y modo de cómo se consiguen, se entenderán de forma más clara y evidente en relación con la descripción esquemática siguiente de ejemplos de realización, que se aclaran más detalladamente en relación con las figuras. Estas muestran en una representación esquemática:
Fig. 1 un primer ejemplo de modo de realización de la invención;
Fig. 2 otro ejemplo de modo de realización de la invención;
Fig. 3 otro ejemplo de modo de realización de la invención;
Fig. 4 otro ejemplo de modo de realización de la invención;
Fig. 5 otro ejemplo de modo de realización de la invención;
En las figuras están previstos elementos con la misma función con las mismas referencias, en tanto no se indique otra cosa.
A menos que se indique lo contrario o ya se indique, los siguientes ejemplos de modo de realización tienen al menos un procesador y/o una unidad de memoria para implementar o ejecutar el procedimiento.
En particular, un experto en la técnica (relevante), con conocimiento de la o las reivindicaciones del procedimiento, por supuesto está familiarizado con todas las posibilidades para realizar productos o posibilidades de implementación que son habituales en la técnica anterior, de modo que en particular, no hay necesidad de una divulgación independiente en la descripción. En particular, estas variantes de implementación habituales conocidas por los expertos en la técnica pueden ser implementadas exclusivamente por hardware (componentes) o exclusivamente por software (componentes). De forma alternativa y/o además, el experto en la materia puede, dentro del alcance de su capacidad profesional, elegir en gran medida cualquier combinación deseada de acuerdo con la invención de hardware (componentes) y software (componentes) para implementar variantes de implementación de acuerdo con la invención.
En particular, puede producirse una combinación de hardware (componentes) y software (componentes) de acuerdo con la invención si parte de los efectos de acuerdo con la invención es proporcionada exclusivamente por hardware especial (por ejemplo, un procesador en forma de ASIC o FPGA) y/u otra parte por el software (basado en procesador y/o memoria).
En particular, en vista del gran número de opciones de implementación diferentes, es imposible y tampoco es conveniente o necesario para comprender la invención nombrar todas estas opciones de implementación. A este respecto, en particular todos los siguientes ejemplos de modo de realización están destinados a mostrar, a modo de ejemplo solamente, algunas formas en las que podrían verse tales implementaciones de la enseñanza de acuerdo con la invención.
En consecuencia, en particular, las características de los ejemplos de modo de realización individuales no se limitan al ejemplo de modo de realización respectivo, sino que se refieren en particular a la invención en general. Por consiguiente, las características de un ejemplo de modo de realización también pueden servir preferentemente como características de otro ejemplo de modo de realización, en particular sin que esto tenga que mencionarse explícitamente en el ejemplo de modo de realización respectivo.
La Fig. 1 muestra un primer ejemplo de modo de realización de la invención. La Fig. 1 muestra un sistema de control para controlar y/o supervisar dispositivos, en el que el sistema de bases de datos distribuidas se implementa, por ejemplo, mediante una cadena de bloques BC.
El ejemplo de modo de realización de un sistema de control para controlar y/o supervisar dispositivos puede comprender las siguientes características en una variante:
- por ejemplo, un sistema de bases de datos distribuidas (BC), que presenta,
- por ejemplo, una pluralidad de nodos (BCN, BCN_D), en la que nodos (BCN, BCN_D) y dispositivos (D, BCN_D) están conectados entre sí a través de una primera red de comunicación (NW1);
- por ejemplo, un primer módulo de marcado (110) para asignar registros de datos de marcado, en el que - por ejemplo, en cada caso, uno de los registros de datos de marcado se asigna a comandos de control en función de los requisitos de ejecución, si los comandos de control correspondientes cumplen los requisitos de ejecución,
- por ejemplo, los comandos de control a los que se asigna uno de los respectivos registros de datos de marcado pueden ser ejecutados por los nodos (BCN, BCN_D) del sistema de bases de datos distribuidas (BC) o por los dispositivos (D, BCN_D),
- por ejemplo, los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan en los requisitos de ejecución,
- por ejemplo, un primer módulo de memoria (130) para almacenar los respectivos comandos de control con su registro de datos de marcado respectivo asociado en las transacciones de control, en el que
- por ejemplo, las transacciones de control se almacenan en el sistema de bases de datos distribuidas (BC) (por ejemplo, en los bloques de datos del sistema de bases de datos distribuidas);
- por ejemplo, las transacciones de control se transmiten a los dispositivos (D, BCN_D) o nodos (BCN, BCN_D) por medio del sistema de bases de datos distribuidas (BC).
- por ejemplo, un primer módulo de verificación para verificar los respectivos registros de datos de marcado para una ejecución de los comandos de control de una de las transacciones de control mediante un dispositivo correspondiente
- por ejemplo, un módulo de ejecución para ejecutar los comandos de control mediante el dispositivo correspondiente en función de un resultado de la verificación;
- por ejemplo, un segundo módulo de memoria para almacenar el resultado de la ejecución de los comandos de control en transacciones de confirmación del sistema de bases de datos distribuidas (por ejemplo, en los bloques de datos del sistema de bases de datos distribuidas).
En detalle, la Fig. 1 muestra los bloques B, por ejemplo un primer bloque B1, un segundo bloque B2 y un tercer bloque B3, de la cadena de bloques BC.
Cada uno de los bloques B comprende varias transacciones T. Las transacciones T pueden comprender transacciones de control y/o transacciones de confirmación.
El primer bloque B1 comprende, por ejemplo, una primera transacción T1a, una segunda transacción T1b, una tercera transacción T1c y una cuarta transacción T1d.
El segundo bloque B2 comprende, por ejemplo, una quinta transacción T2a, una sexta transacción T2b, una séptima transacción T2c y una octava transacción T2d.
El tercer bloque B3 comprende, por ejemplo, una novena transacción T3a, una décima transacción T3b, una undécima transacción T3c y una duodécima transacción T3d.
Cada uno de los bloques B también comprende además una de las sumas de verificación de concatenación CRC, que se forma dependiendo del bloque predecesor directo. Por tanto, el primer bloque B1 comprende una primera suma de verificación de concatenación CRC1 de su bloque predecesor, el segundo bloque B2 una segunda suma de verificación de concatenación CRC2 del primer bloque B1, y el tercer bloque B3 una tercera suma de verificación de concatenación CRC3 del segundo bloque B2.
La suma de verificación de concatenación respectiva CRC1, CRC2, CRC3 se forma preferentemente usando el encabezado de bloque del bloque precedente correspondiente. Las sumas de verificación de concatenación CRC se pueden formar preferentemente usando una función hash criptográfica como, por ejemplo, SHA-256, KECCAK-256 o SHA-3. Por ejemplo, la suma de verificación de la concatenación también se puede calcular usando la suma de verificación de bloque de datos o el encabezado comprende la suma de verificación de bloque de datos (la suma de verificación del bloque de datos se explica a continuación).
Además, cada uno de los bloques puede incluir una suma de verificación de bloque de datos. Esto se puede implementar, por ejemplo, por medio de un árbol hash.
Para crear el árbol hash, se calcula una suma de verificación de transacción (por ejemplo, también un valor hash) para cada transacción de un (bloque de) dato(s). De forma alternativa o además, una suma de verificación de transacción, que fue creada preferentemente por el creador de la transacción al crear la transacción, se puede utilizar para este propósito.
Por lo general, como un árbol hash, se utiliza, por ejemplo, un árbol de Merkle o árbol de Patricia, cuyo valor hash raíz/suma de verificación raíz se almacena preferentemente como una suma de verificación de bloque de datos correspondiente en los bloques respectivos.
En una variante, la suma de verificación de bloque de datos se utiliza como suma de verificación de concatenación.
Además, un bloque puede tener una marca de tiempo, una firma digital, una evidencia de prueba de trabajo, como se explicó en los modos de realización de la invención.
La propia cadena de bloques BC se implementa mediante una infraestructura de cadena de bloques con varios nodos de cadena de bloques BCN, BCN_D. Los nodos pueden ser, por ejemplo, ordenadores, oráculos de cadena de bloques, nodos fiables o uno o más o todos los dispositivos que se deben controlar o supervisar. En otras palabras, los dispositivos en particular pueden diseñarse como nodos de cadena de bloques, que luego se denominan nodos de dispositivo BCN D, por ejemplo. Los dispositivos que, por ejemplo, no están diseñados como nodos de cadena de bloques y, por ejemplo, solo tienen acceso de lectura a la cadena de bloques, se denominan en particular dispositivos D externos a la cadena de bloques. Los nodos están conectados de forma comunicativa entre sí a través de una primera red NW1 (por ejemplo, una red de comunicación como Internet o una red Ethernet). Por medio de la infraestructura de la cadena de bloques, por ejemplo, al menos algunos de los bloques de datos B o todos los bloques de datos B de la cadena de bloques BC se replican para algunos o todos los nodos de la cadena de bloques.
En particular, puede entenderse que dispositivos significan dispositivos D externos a la cadena de bloques o nodos de dispositivo BCN_D.
El sistema de control, que se implementa por medio de la cadena de bloques BC, también comprende un primer módulo de marcado 110, un primer módulo de memoria 130, un primer módulo de verificación 140, un primer módulo de ejecución 150 y un segundo módulo de memoria 160, están conectados comunicativamente entre sí a través del sistema de control (por ejemplo, un bus) o a través de la cadena de bloques y su infraestructura (por ejemplo, la primera red NW1). La primera red (de comunicación) NW1 puede ser una red de radiotelefonía, una red Ethernet, una WAN, una LAN o Internet.
El primer módulo de marcado 110 está configurado para asignar registros de datos de marcado, en el que en cada caso, uno de los registros de datos de marcado se asigna a comandos de control en función de los requisitos de ejecución, si los comandos de control correspondientes cumplen los requisitos de ejecución. Los comandos de control a los que se asigna uno de los respectivos registros de datos de marcado pueden ser ejecutados por los nodos (BCN, BCN_D) del sistema de bases de datos distribuidas (BC) o por los dispositivos (D, BCN_D). Los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan en los requisitos de ejecución.
El módulo de marcado es, en particular, un módulo de marcado de acuerdo con una de las reivindicaciones 8 a 18 o la figura 4 o la figura 5.
De forma alternativa o además, la información sobre si se pueden ejecutar comandos de control también se puede almacenar en un registro de datos de marcado. Para ello, el registro de datos de marcado puede por ejemplo, comprender un valor de -1, que indica que la ejecución no está permitida, un valor de 0, que indica que la ejecución no es posible, o un valor de 1, que indica que la ejecución está permitida o es posible. En consecuencia, a los comandos de control no ejecutables (o comandos de control cuya ejecución no está permitida) se les puede asignar un registro de datos de marcado que indica si se pueden ejecutar o no los comandos de control correspondientes.
Como componente de software, el primer módulo de marcado 110 puede implementarse, por ejemplo, como un contrato inteligente que se ejecuta mediante la cadena de bloques o su infraestructura. Para ello, el contrato inteligente se almacena en transacciones, por ejemplo, que a su vez se almacenan en bloques de datos o bloques de la cadena de bloques BC.
Como componente de hardware, el primer módulo de marcado 110 puede implementarse, por ejemplo, mediante un oráculo de cadena de bloques y/o un nodo y/o dispositivo de la cadena de bloques, que en particular son fiables y utilizan un certificado digital o firma digital para firmar los requisitos de ejecución. En una variante, se asigna un módulo de marcado correspondiente a determinados dispositivos o nodos que, por ejemplo, se consideran particularmente críticos.
Opcionalmente, el sistema de control puede comprender un primer módulo de descomposición, que está diseñado, por ejemplo, como un módulo integral del primer módulo de marcado 110 o está diseñado como un módulo separado (por ejemplo, como un componente de software y/o hardware) análogo al primer módulo de marcado (por ejemplo, como un contrato inteligente de la cadena de bloques). El primer módulo de descomposición está configurado para descomponer una secuencia de comandos en los comandos de control correspondientes y ponerlos a disposición del sistema de control, en particular del primer módulo de marcado o del primer módulo de memoria.
La secuencia de comandos puede comprender comandos de control para una pluralidad de dispositivos, por ejemplo, máquinas de fabricación, de modo que creen un objeto o producto, por ejemplo, una turbina de gas o un motor eléctrico. De forma alternativa o además, la secuencia de comandos comprende una especificación del producto que deben implementar los dispositivos. La secuencia de comandos no tiene por qué estar dirigida necesariamente a la fabricación de un producto. Por ejemplo, también se puede utilizar para controlar una red de suministro de energía. La secuencia de comandos en sí puede ser, por ejemplo, un contrato inteligente que se almacenó en la cadena de bloques. Este contrato inteligente puede entonces, por ejemplo, ser evaluado por el sistema de control (o el primer módulo de descomposición y/o el primer módulo de marcado) con la cadena de bloques o su infraestructura.
La secuencia de comandos también se puede cifrar, por ejemplo, de modo que el primer módulo de marcado 110 o el primer módulo de descomposición deben descifrar primero la secuencia de comandos antes de que se pueda descomponer la secuencia de comandos.
De forma alternativa o además, los comandos de control de la secuencia de comandos se cifran y los requisitos correspondientes para su ejecución se almacenan en la secuencia de comandos como texto sin formato.
La secuencia de comandos en sí y/o los comandos de control pueden proporcionarse al sistema de control, por ejemplo, por un usuario, por una interfaz, por otra base de datos o por un dispositivo de entrada.
Como alternativa o además, los comandos de control y/o los requisitos de ejecución son cifrados por el primer módulo de marcado 110 para, por ejemplo, implementar la protección de conocimientos técnicos. Por ejemplo, incluir entonces el dispositivo D correspondiente para ejecutar los comandos de control y/o el primer módulo de verificación 140 y/o el primer módulo de ejecución 150, 150_D a través de los correspondientes medios criptográficos. Por ejemplo, los medios criptográficos son una clave criptográfica correspondiente para descifrar los comandos de control y/o los requisitos de ejecución.
El primer módulo de descomposición y el primer módulo de marcado primero descomponen la secuencia de comandos en comandos de control o determinan los comandos de control sobre la base de la secuencia de comandos, en la que los comandos de control también pueden ser un grupo de comandos de control o varios comandos de control. El primer módulo de marcado 110 conoce preferentemente los dispositivos y/o nodos disponibles y determina los requisitos de ejecución para los comandos de control (que también pueden ser un grupo de comandos de control). De forma alternativa, los requisitos de ejecución ya se pueden codificar/almacenar en la secuencia de comandos y el primer módulo de marcado 110 usa esta información para determinar los requisitos de ejecución para los comandos de control correspondientes.
Además, el sistema de control puede comprender un optimizador que, sobre la base de los requisitos de ejecución, optimiza la ejecución de los comandos de control por parte de los dispositivos sobre la base de un criterio predeterminado. De forma alternativa, el optimizador determina los requisitos de ejecución y los proporciona al primer módulo de marcado 110.
De este modo, el sistema de control puede, por ejemplo, optimizar un proceso de fabricación de acuerdo con los criterios predefinidos. Los criterios predefinidos pueden ser, por ejemplo, el tiempo de fabricación, los costes incurridos o la energía a utilizar. El optimizador puede ser, por ejemplo, un módulo integral del primer módulo de descomposición o del primer módulo de marcado. De forma alternativa, el optimizador puede estar conformado como un módulo independiente del sistema de control.
Si, por ejemplo, el optimizador es un módulo integral del módulo de descomposición o del módulo de marcado, puede realizar la optimización al descomponer la secuencia de comandos en comandos de control y al determinar los requisitos de ejecución. El primer módulo de descomposición o el primer módulo de marcado 110 tiene en cuenta el criterio predefinido por medio del optimizador, por ejemplo, cuando se descompone la secuencia de comandos en los comandos de control.
Si, por ejemplo, el criterio es optimizar el tiempo de fabricación en la producción de un producto (por ejemplo, para mantener el tiempo de fabricación del producto lo más corto posible), la secuencia de comandos se descompone y/o los requisitos de ejecución optimizados correspondientemente se calculan en de tal manera que los componentes individuales del producto se componen de varios dispositivos, es decir, los comandos de control correspondientes en las transacciones de control serán procesados por estos. Si, por ejemplo, el criterio es optimizar los costes de fabricación en la producción de un producto, la secuencia de comandos se descompone y/o los requisitos de ejecución optimizados correspondientes se calculan de tal manera que los componentes individuales sean producidos en serie por un dispositivo (por ejemplo, el dispositivo correspondiente) o tan pocos dispositivos como sea posible, es decir, los correspondientes nodos/dispositivos procesan los comandos de control correspondientes en las transacciones de control. Para controlar esto, por ejemplo, el optimizador transfiere la información correspondiente al módulo de marcado, de modo que el módulo de marcado almacena esta información en los requisitos de ejecución.
En una variante, el módulo de marcado es un módulo de marcado para un sistema de bases de datos distribuidas o para un sistema de control con un sistema de bases de datos distribuidas para controlar y/o supervisar dispositivos. En esta variante, presenta un procesador y opcionalmente una unidad de memoria. El procesador está configurado para asignar registros de datos de marcado para la ejecución de los comandos de control por parte de los dispositivos, con lo que una asignación solo tiene lugar si los dispositivos correspondientes cumplen los requisitos de ejecución. Además, puede comprender, por ejemplo, las variantes de realización y las características mencionadas en las figuras 4 y 5.
Los correspondientes registros de datos de marcado pueden, por ejemplo, comprender también un identificador de los respectivos dispositivos o nodos que van a ejecutar los comandos de control o las transacciones de control, de modo que esta información (identificación y especificación de viabilidad) se facilite en el momento de la verificación por los dispositivos y/o nodos.
En una variante, por ejemplo, el primer módulo de marcado puede comprender un primer módulo de asignación. El primer módulo de asignación está configurado para asignar los respectivos registros de datos de marcado a los comandos de control. El primer módulo de asignación puede diseñarse, por ejemplo, como un componente de software y/o de hardware, análogo al primer módulo de marcado 110 (por ejemplo, como un contrato inteligente de la cadena de bloques o como un nodo fiable de la cadena de bloques). El primer módulo de asignación puede implementarse en particular mediante la cadena de bloques o un contrato inteligente, o es un componente de software de la infraestructura de la cadena de bloques.
El primer módulo de memoria 130 está configurado para almacenar los respectivos comandos de control con su registro de datos de marcado respectivo asociado en las transacciones de control, en las que las transacciones de control se almacenan en bloques de datos B del sistema de bases de datos distribuidas (BC). Las transacciones de control se transmiten a los dispositivos D, BCN D por medio de los bloques de datos B, por ejemplo. Esto se logra, por ejemplo, porque los bloques de datos correspondientes se transmiten a través de la cadena de bloques a través de la primera red NW1 a los nodos correspondientes, por ejemplo, cuando se replican los bloques de datos para la cadena de bloques y/o nodos y/o nodos específicos. Por ejemplo, si se trata de un dispositivo externo a la cadena de bloques, se puede transmitir a dicho dispositivo a través de una interfaz (por ejemplo, una interfaz web) de la cadena de bloques, o dicho dispositivo mismo recupera los datos correspondientes de la cadena de bloques, por ejemplo, después de un intervalo de tiempo predeterminado.
Los comandos de control y el registro de datos de marcado asociado pueden almacenarse en dos transacciones de control diferentes, o pueden almacenarse en una sola transacción de control.
Cuando los comandos de control son determinados por el primer módulo de marcado 110, estos se determinan preferentemente de una manera específica de dispositivo. Esto significa en particular que inicialmente se forman grupos de comandos de control que pueden ser procesados completamente por un dispositivo correspondiente. Estos grupos de comandos de control también se pueden llamar simplemente comandos de control. A continuación, se calculan los requisitos de ejecución para estos grupos de comandos de control o comandos de control. De forma alternativa o además, los requisitos de ejecución o una parte de estos también se pueden especificar y, por ejemplo, almacenarse en una/la memoria de configuración. Una asignación de un registro de datos de marcado que permite ejecutar los comandos de control tiene lugar, en particular, solo si se cumplen los requisitos de ejecución para los comandos de control. En consecuencia, un registro de datos de marcado también puede almacenarse en transacciones de control que prohíben la ejecución de comandos de control mediante un registro de datos de marcado correspondiente que comprende una indicación correspondiente (por ejemplo, "Execution = Not Allowed").
El módulo de marcado puede ser, por ejemplo, también un módulo de marcado de acuerdo con la invención o uno de sus modos de realización o un módulo de marcado, como se explica en las Fig. 4 y/o 5.
El almacenamiento se puede implementar de diferentes formas. Por ejemplo, un comando de control o una pluralidad de comandos de control pueden almacenarse en una transacción de control específica, en la que esta transacción de control específica comprende los registros de datos de marcado correspondientes para el comando de control o la pluralidad de comandos de control. Este enfoque integral es ventajoso para acceder a los datos lo más fácilmente posible.
De forma alternativa, los registros de datos de marcado correspondientes pueden almacenarse en una transacción de control individual o separada, en la que la propia transacción comprende una referencia o una indicación de qué comando de control o qué comandos de control se refieren a estos registros de datos de marcado correspondientes. Esto se logra, por ejemplo, con un número de bloque (de un bloque) con las correspondientes transacciones (de control) (con comandos de control), una suma de verificación del bloque o la transacción que comprende los comandos de control. Esto es ventajoso si los registros de datos de marcado solo se determinan durante el procesamiento de los comandos de control por los dispositivos correspondientes. Un dispositivo (o el primer módulo de verificación 140 o el primer módulo de ejecución 150), por ejemplo, el dispositivo correspondiente que procesa los comandos de control o parte de los comandos de control de una transacción de control, el procesamiento de los comandos de control correspondientes solo comienza cuando los registros de datos de marcado correspondientes están disponibles en una transacción de control en la cadena de bloques. De lo contrario, el dispositivo o el primer módulo de verificación 140 o el primer módulo de ejecución 150 espera hasta que la cadena de bloques BC proporcione esta transacción de control con los registros de datos de marcado correspondientes.
El primer módulo de memoria 130 puede diseñarse, por ejemplo, como un componente de software y/o de hardware, análogo al primer registro de datos de marcado 110 (por ejemplo, como un contrato inteligente de la cadena de bloques o como un nodo fiable de la cadena de bloques). El primer módulo de memoria 130 puede implementarse en particular mediante la cadena de bloques o un contrato inteligente, o es un componente de software de la infraestructura de la cadena de bloques.
El primer módulo de verificación 140 está configurado para verificar si un registro de datos de marcado adecuado está disponible para un transacción de control o comando de control respectivo. El módulo de verificación 140 verifica después el registro de datos de marcado si este, por ejemplo, confirma la viabilidad de los comandos de control. Esta información se resume entonces, preferentemente, en un resultado de verificación y se pone a disposición del módulo de ejecución 150.
En particular, "uno de los comandos de control" significa uno o más de los comandos de control (en otras palabras, es, por ejemplo, uno o más comandos de control). De forma alternativa, debe entenderse que "con uno de los comandos de control" significa "al menos uno de los comandos de control". "Uno de los comandos de control" son preferentemente los comandos de control de una transacción de control correspondiente.
El primer módulo de verificación 140 puede diseñarse, por ejemplo, como un componente de software y/o de hardware, análogo al primer módulo de marcado 110 (por ejemplo, como un contrato inteligente de la cadena de bloques o como un nodo fiable de la cadena de bloques). El primer módulo de verificación 140 puede implementarse, en particular, mediante la cadena de bloques o un contrato inteligente o es un componente de software de la infraestructura de la cadena de bloques o es un componente de un nodo o de un dispositivo que puede ejecutar los comandos de control.
Si la verificación de los comandos de control de un bloque de datos que deben ser ejecutados por el dispositivo correspondiente ha sido completada por el primer módulo de verificación 140, entonces se proporciona un resultado de la verificación en un registro de datos. El primer módulo de verificación 140 puede, por ejemplo, realizar también verificaciones adicionales. Por ejemplo, se puede verificar la suma de verificación de la transacción o la suma de verificación del bloque de datos. Si la suma de verificación correspondiente es una firma digital o un certificado, se puede verificar, por ejemplo, si el emisor o
el generador de suma de verificación tiene derecho a que sus comandos de control sean procesados en el dispositivo o por el dispositivo.
Por ejemplo, también se puede verificar si el dispositivo en cuestión tiene un certificado digital requerido, que indica, por ejemplo, que el dispositivo en cuestión es fiable. Esto puede ser necesario, por ejemplo, cuando se trata de comandos de control que comprenden conocimientos técnicos que no deben ponerse a disposición del público.
También es concebible, por ejemplo, que los comandos de control estén cifrados criptográficamente y preferentemente solo el dispositivo D correspondiente comprenda medios (por ejemplo una clave correspondiente) para cancelar este cifrado criptográfico. Estos medios los puede comprender el propio dispositivo D correspondiente o el módulo de ejecución 150, 150_D comprende estos medios.
El módulo de ejecución 150, 150_D está configurado para ejecutar los comandos de control mediante el dispositivo correspondiente en función del resultado de la verificación (por ejemplo, el resultado de verificación). Si la verificación revela o si el resultado comprende una confirmación de la ejecución de los comandos de control, el dispositivo correspondiente ejecuta estos comandos de control. Por ejemplo, puede perforar un agujero en un componente de acuerdo con las especificaciones de los comandos de control especificados originalmente en la secuencia de comandos. Si la verificación revela o si el resultado no comprende una confirmación de la ejecución de los comandos de control, entonces se impide el procesamiento/ejecución de los comandos de control.
Si el resultado dice, por ejemplo, que los comandos de control no deben ser ejecutados por el dispositivo correspondiente, se puede proporcionar una señal de control, por ejemplo. Con la señal de control, por ejemplo, una alarma, un técnico de servicio o los comandos de control (preferentemente todos) que se generaron sobre la base de una secuencia de comandos pueden declararse no válidos, de modo que otros comandos de control de la secuencia de comandos ya no se ejecuten mediante otros dispositivos. Para ello, por ejemplo, una transacción de control correspondiente con dicho comando de control puede almacenarse para todos los dispositivos en un bloque de la cadena de bloques BC y transferirse a los dispositivos por medio de la cadena de bloques BC. Preferentemente, dicha transacción de control también comprende requisitos de ejecución que incluyen una prioridad. Esta prioridad es, preferentemente, más alta que la prioridad de los otros comandos de control. Con esta prioridad aumentada, el comando de control correspondiente es preferentemente procesado por los dispositivos para, por ejemplo, invalidar (declarar inválidos) los comandos de control restantes de la secuencia de comandos o para evitar su ejecución.
Si el primer módulo de verificación 140 es, por ejemplo, un módulo de la cadena de bloques BC, entonces el primer módulo de verificación 140 comprende, por ejemplo, una lista de los dispositivos con sus propiedades específicas de dispositivo, en base a lo cual se pueden verificar los requisitos específicos de dispositivo. De forma alternativa, el primer módulo de verificación 140 puede comprender una lista de los dispositivos y sus direcciones de red, y consultar las propiedades específicas de dispositivo correspondientes de los propios dispositivos. Esto es ventajoso para tener en cuenta el estado operativo actual de los dispositivos durante la verificación.
El primer módulo de ejecución 150, 150_D puede diseñarse, por ejemplo, como un componente de software y/o de hardware, análogo al primer módulo de marcado 110 (por ejemplo, como un contrato inteligente de la cadena de bloques o como un nodo fiable de la cadena de bloques). El módulo de ejecución puede implementarse, en particular, mediante la cadena de bloques o un contrato inteligente o es un componente de software de la infraestructura de la cadena de bloques o es un componente de un nodo (por ejemplo, un módulo de ejecución 150 de la cadena de bloques) o un dispositivo (por ejemplo, un módulo de ejecución 150_D de dispositivo) que puede ejecutar los comandos de control.
Si el primer módulo de ejecución es, por ejemplo, un módulo de la cadena de bloques, entonces el primer módulo de ejecución 150 comprende, por ejemplo, una lista de los dispositivos y sus direcciones de red para accionar los dispositivos para procesar los comandos de control.
El segundo módulo de memoria 160 está configurado para almacenar el resultado de la ejecución de los comandos de control en transacciones de confirmación de los bloques de datos del sistema de bases de datos distribuidas.
Si el procesamiento de los comandos de control mediante el dispositivo correspondiente fue exitoso, entonces esta información se almacena en una transacción de confirmación en la cadena de bloques. Si, por ejemplo, hay otros comandos de control que presuponen el procesamiento de los comandos de control que ya se han procesado (comandos de control presupuestos), estos otros comandos de control ahora pueden ser procesados por otro dispositivo correspondiente o el mismo dispositivo correspondiente, siempre que también se cumplan los requisitos de ejecución restantes. De forma alternativa o además, a los comandos de control que no han requerido previamente sus respectivos requisitos de ejecución (por ejemplo, requieren los comandos de control procesados, que, sin embargo, no fueron procesados en el primer intento de asignación) se les pueden asignar registros de datos de marcado correspondientes, si los comandos de control asumidos y procesados ahora se almacenan en transacciones de confirmación (es decir, están disponibles).
El segundo módulo de memoria 160 puede diseñarse, por ejemplo, como un componente de software y/o de hardware, análogo al primer módulo de marcado 110 (por ejemplo, como un contrato inteligente de la cadena de bloques o como un nodo fiable de la cadena de bloques). El segundo módulo de memoria 160 puede implementarse, en particular, mediante la cadena de bloques o un contrato inteligente o es un componente de software de la infraestructura de la cadena de bloques o es un componente de un nodo que puede ejecutar los comandos de control.
El sistema de control y/o el sistema de bases de datos distribuidas o sus nodos (por ejemplo, nodos de cadena de bloques, dispositivos (nodos de dispositivo y dispositivos externos a la cadena de bloques)) pueden, por ejemplo, comprender también además uno o más componentes adicionales, como, por ejemplo, un procesador, una unidad de memoria, otras interfaces de comunicación (por ejemplo, Ethernet, WLAN), un dispositivo de entrada, en particular un teclado de ordenador o un ratón de ordenador, y un dispositivo de visualización (por ejemplo, un monitor). El procesador puede comprender, por ejemplo, varios procesadores adicionales, que se pueden utilizar en particular para implementar otros ejemplos de modo de realización. El o los componentes adicionales también pueden, por ejemplo, estar conectados comunicativamente entre sí a través de la cadena de bloques o su infraestructura.
El procesador puede ser, por ejemplo, un ASIC que se ha implementado de manera específica de aplicación para las funciones de un módulo respectivo o todos los módulos del ejemplo de modo de realización (y/o otros ejemplos de modo de realización), en el que los componentes del programa o los comandos del programa se implementan, en particular, como circuitos integrados. El procesador puede ser, por ejemplo, también un FPGA, que está configurado en particular por medio de los comandos de programa de tal manera que el FPGA realiza las funciones de un módulo respectivo o todos los módulos del ejemplo de modo de realización (y/o otros ejemplos de modo de realización).
Dependiendo de la variante de implementación elegida, el sistema de bases de datos distribuidas puede comprender el primer módulo de verificación y/o el primer módulo de ejecución y/o el segundo módulo de memoria.
En esta variante de implementación, los dispositivos se mantienen simples, por ejemplo, sin dichos módulos correspondientes. Esto es ventajoso para simplificar al máximo los dispositivos y conectarlos al sistema de bases de datos distribuidas. En particular, se pueden usar de este modo dispositivos económicos.
En otra variante de implementación, los dispositivos comprenden un primer módulo de verificación de dispositivo y/o un primer módulo de ejecución de dispositivo y/o un segundo módulo de memoria de dispositivo. Dependiendo de la implementación elegida, el primer módulo de verificación y/o el primer módulo de ejecución y/o un segundo módulo de memoria pueden acceder a los módulos correspondientes de los dispositivos al realizar sus funcionalidades/tareas.
En otras palabras, el sistema de control o el sistema de bases de datos distribuidas conoce los módulos del dispositivo (por ejemplo, mediante datos almacenados en una tabla). El primer módulo de verificación 140 y/o el primer módulo de ejecución 150 y/o el segundo módulo de memoria 160 tienen información sobre cómo se pueden dirigir o accionar los módulos de dispositivo 150_D (por ejemplo, a través de una tabla interna del módulo que preferentemente se actualiza automáticamente, por ejemplo a través de mensajes de difusión en la primera red de comunicación NW1 o mediante el sistema de bases de datos distribuidas BC). El primer módulo de verificación y/o el primer módulo de ejecución y/o el segundo módulo de memoria implementan, preferentemente, solo la parte que distribuye o transfiere la información o tareas necesarias al dispositivo o dispositivos correspondientes (por ejemplo, las transacciones de control o las transacciones de confirmación o el resultado de la verificación por el módulo de verificación). La funcionalidad restante la implementan los módulos de dispositivo.
Esto es ventajoso para reubicar total o parcialmente las tareas de verificación más intensivas desde el punto de vista computacional del primer módulo de verificación o las tareas de ejecución del primer módulo de ejecución a los dispositivos correspondientes.
El sistema de control también puede comprender un módulo de registro opcional.
El módulo de registro puede diseñarse, por ejemplo, como un componente de software y/o de hardware, análogo al primer módulo de marcado 110 (por ejemplo, como un contrato inteligente de la cadena de bloques o como un nodo fiable de la cadena de bloques). El módulo de registro puede implementarse en particular mediante la cadena de bloques o un contrato inteligente, o es un componente de software de la infraestructura de la cadena de bloques. De forma alternativa, el módulo de registro puede implementarse como un nodo fiable específico cuya dirección de red se conoce públicamente, por ejemplo. Si, por ejemplo, se trata de un sistema de bases de datos distribuidas cerrado en el que sólo los nodos y/o dispositivos autorizados están conectados al sistema de control o al sistema de bases de datos distribuidas, en particular solo se conoce públicamente la dirección de red del módulo de registro.
El módulo de registro está configurado para añadir nuevos nodos y/o dispositivos al sistema de control. Tan pronto como un nuevo dispositivo y/o nodo desea unirse al sistema de control o al sistema de bases de datos distribuidas, el nuevo dispositivo o el nuevo nodo envía una consulta al módulo de registro. Esto se puede hacer directamente, por ejemplo, transfiriendo información de nodo y/o de dispositivo directamente al módulo de registro. Si esto se hace indirectamente, la consulta se reenvía entre los nodos y módulos del sistema de bases de datos distribuidas hasta que la consulta llega al módulo de registro.
La información del nodo y/o de dispositivo puede comprender lo siguiente:
- dirección de dispositivo/dirección de nodo
- operador del dispositivo/nodo
- alcance funcional del dispositivo/nodo
- claves criptográficas (por ejemplo, para verificar sumas de verificación/firmas digitales generadas por el dispositivo/nodo)
- otras propiedades que se necesitan al verificar los requisitos de ejecución La información del nodo y/o de dispositivo puede entonces, por ejemplo, almacenarse en el sistema de control (por ejemplo, en tablas correspondientes) de modo que la verificación y/o ejecución de los comandos de control o las transacciones de control puedan ser implementadas por los módulos correspondientes.
Si el sistema de bases de datos es, por ejemplo, un sistema de bases de datos distribuidas cerrado, el módulo de registro también verifica si el dispositivo/nodo está autorizado para acceder, en particular si el dispositivo/nodo es aceptado como parte del sistema de control o del sistema de bases de datos distribuidas. Para ello, el dispositivo/nodo proporciona información de autenticación (claves criptográficas, contraseñas, etc.), por ejemplo, que es verificada por el módulo de registro.
Si el sistema de bases de datos es un sistema de bases de datos distribuidas abierto, por ejemplo, entonces se registra la información de nodo y/o de dispositivo.
Dependiendo de la variante de implementación, el módulo de verificación 140 y/o el módulo de ejecución 150 y/o el segundo módulo de memoria 160 son módulos opcionales.
La Fig. 2 muestra un segundo ejemplo de modo de realización de la invención que implementa un control de dispositivos que se implementan como nodos en la cadena de bloques BC.
Esta variante también se puede implementar, por ejemplo, mediante el ejemplo de modo de realización de la Fig. 1 o es compatible con esta. Por consiguiente, el sistema de control de la Fig. 2 también puede presentar uno o más módulos del sistema de control de la Fig. 1.
El sistema de control, que se implementa como una cadena de bloques BC, proporciona varias transacciones T, que también pueden comprender transacciones de control.
Por ejemplo, la quinta transacción T2a es una primera transacción de control que comprende primeros comandos de control y un primer registro de datos de marcado asignado a uno de estos comandos de control. La sexta transacción T2b es, por ejemplo, una segunda transacción de control que comprende segundos comandos de control y un segundo registro de datos de marcado asignado a uno de estos comandos de control. El primer registro de datos de marcado indica que los primeros comandos de control pueden ser ejecutados por el primer nodo de dispositivo BCN_D_1. El segundo registro de datos de marcado indica a este respecto que los segundos comandos de control pueden ser ejecutados por el segundo nodo de dispositivo BCN_D_2. Para ello, los respectivos registros de datos de marcado pueden comprender, por ejemplo, un identificador único para los correspondientes dispositivos o nodos de dispositivo que deben ejecutar los comandos de control. Como alternativa o además, los comandos de control correspondientes pueden comprender un identificador único de este tipo para correspondientes los dispositivos o nodos de dispositivo que deben ejecutar los comandos de control.
En otras palabras, la invención mejora el sistema de bases de datos distribuidas en el sentido de que aumenta la seguridad de la ejecución de los comandos de control por parte de los dispositivos y/o nodos. Dado que el registro de datos de marcado contiene, preferentemente, solo muy poca información (por ejemplo, el identificador único y/o una indicación de que los comandos de control correspondientes pueden o no pueden ejecutarse), se requiere poco espacio de almacenamiento para esta información. Esto es particularmente ventajoso en el caso de una implementación basada en cadena de bloques para mantener el consumo de memoria total o la ocupación de memoria del sistema de bases de datos distribuidas lo más bajo posible. Otras soluciones, que, por ejemplo, almacenan todos los requisitos de ejecución (por ejemplo, dependencias en la ejecución de los comandos de control, especificaciones del dispositivo, datos cifrados, indicaciones sobre la optimización de los comandos de control, etc.) en las transacciones, son desventajosas en términos de una gran cantidad de consumo de espacio de memoria, especialmente cuando se utilizan enlaces de comunicación con poco ancho de banda, la recuperación de las solicitudes de ejecución llevaría demasiado tiempo para dirigir o controlar un dispositivo de manera sensata. En consecuencia, un registro de datos de marcado comprende, preferentemente, exclusivamente el identificador único (para el dispositivo/nodo que debe ejecutar los comandos de control) y/o una indicación de que los comandos de control correspondientes pueden ejecutarse y/o una indicación de que los comandos de control correspondientes no pueden ejecutarse.
En una primera etapa S1, los primeros comandos de control de la primera transacción de control se transfieren a través de la cadena de bloques al primer nodo de dispositivo BCN_D_1 y son ejecutados por el primer nodo de dispositivo BCN_D_1, si el conjunto de datos de marcado correspondiente lo permite. Después de que los primeros comandos de control hayan sido procesados con éxito por el primer nodo de dispositivo BCN_D_1, se escribe una confirmación de este procesamiento en una transacción de confirmación en una segunda etapa S2 y se almacena en un bloque de datos de la cadena de bloques. En este ejemplo de modo de realización, esta es la novena transacción T3a.
Un nodo de dispositivo debe entenderse aquí en particular que significa un nodo en la cadena de bloques que también es un dispositivo o tiene propiedades de dispositivo para procesar comandos de control.
Con la invención, las cadenas de comandos de control complejas (también llamadas secuencias de comandos) se pueden procesar de manera simple en una red (de automatización) en la que los nodos y/o los nodos de dispositivo y/o los dispositivos externos a la cadena de bloques están conectados entre sí, incluso si hay diferentes operadores de los nodos individuales y los dispositivos no se fían. En particular, el sistema de bases de datos distribuidas o la cadena de bloques verifica los comandos de control para determinar si se pueden ejecutar. Si, por ejemplo, los comandos de control y/o el registro de datos de marcado correspondiente no comprenden un identificador único correspondiente para el dispositivo/nodo que debe ejecutar los comandos de control, el propio sistema de bases de datos distribuidas puede utilizar un identificador único (por ejemplo, un número de serie o un número de inventario) del dispositivo/nodo correspondiente identificarlo y transmitir las transacciones de control correspondientes con los comandos de control y el registro de datos de marcado correspondiente al dispositivo/nodo. Para ello, el sistema de bases de datos distribuidas puede comprender, por ejemplo, un registro de dispositivos que contenga la información correspondiente a los dispositivos/nodos para identificarlos y transmitirles los datos correspondientes.
Un ejemplo de modo de realización de la invención, no mostrado, se refiere a un dispositivo tal como se explicó en la figura 1 o en la figura 2 con los ejemplos de modo de realización asociados.
El dispositivo comprende un primer módulo de comunicación, un primer módulo de verificación opcional, un primer módulo de ejecución opcional y un segundo módulo de memoria, que están conectados comunicativamente entre sí a través de un bus. Un bus también puede ser, en este caso, un flujo de programa simple o un intercambio de datos entre los componentes correspondientes.
El dispositivo puede por ejemplo, comprender también además uno o más componentes adicionales, como, por ejemplo, un procesador, una unidad de memoria, otras interfaces de comunicación (por ejemplo, Ethernet, WLAN), un dispositivo de entrada, en particular un teclado de ordenador o un ratón de ordenador, y un dispositivo de visualización (por ejemplo, un monitor). El procesador puede comprender, por ejemplo, varios procesadores adicionales, que se pueden utilizar en particular para implementar otros ejemplos de modo de realización. El o los componentes adicionales también pueden, por ejemplo, estar conectados comunicativamente entre sí a través del bus.
El procesador puede ser, por ejemplo, un ASIC que se ha implementado de manera específica de aplicación para las funciones de un módulo respectivo o todos los módulos del ejemplo de modo de realización (y/o otros ejemplos de modo de realización), en el que los componentes del programa o los comandos del programa se implementan, en particular, como circuitos integrados. El procesador puede ser, por ejemplo, también un FPGA, que está configurado en particular por medio de los comandos de programa de tal manera que el FPGA realiza las funciones de un módulo respectivo o todos los módulos del ejemplo de modo de realización (y/o otros ejemplos de modo de realización).
El primer módulo de comunicación, por ejemplo, una interfaz de Ethernet está configurado para recibir bloques de datos de un sistema de bases de datos distribuidas (por ejemplo, una cadena de bloques), en el que
- transacciones de control con comandos de control para el dispositivo se almacenan en los bloques de datos del sistema de bases de datos distribuidas,
- las transacciones de control comprenden registros de datos de marcado asignados a los comandos de control.
El primer módulo de verificación está configurado para verificar los respectivos registros de datos de marcado para una ejecución de los comandos de control de una de las transacciones de control mediante un dispositivo correspondiente.
El primer módulo de ejecución está configurado para ejecutar los comandos de control mediante el dispositivo correspondiente en función de un resultado de la verificación.
El segundo módulo de memoria está configurado para almacenar el resultado de la ejecución de los comandos de control en transacciones de confirmación de los bloques de datos del sistema de bases de datos distribuidas.
Los módulos se pueden implementar, por ejemplo, como componentes de hardware o como componentes de software o una combinación de componentes de hardware y de software. Por ejemplo, los componentes de software, como las bibliotecas de programas, se pueden utilizar para configurar el procesador con comandos de programa de las bibliotecas de programas de tal manera que implemente las funcionalidades del módulo correspondiente.
El dispositivo en sí puede ser un nodo de una cadena de bloques o de un sistema de bases de datos distribuidas.
Si el dispositivo tiene, por ejemplo, el primer módulo de verificación y/o el primer módulo de ejecución, esto es ventajoso para que el sistema de control reubique total o parcialmente tareas de control más intensivas desde el punto de vista computacional en el dispositivo (Figs. 1-2) o el sistema de bases de datos distribuidas (Fig. 4) o varios dispositivos del mismo tipo que el dispositivo.
La Fig. 3 muestra un tercer ejemplo de modo de realización de la invención como diagrama de flujo del procedimiento de acuerdo con la invención.
El procedimiento se implementa preferentemente con ayuda de un ordenador.
El ejemplo de modo de realización de un procedimiento para el control asistido por ordenador de dispositivos puede comprender, en una variante, las siguientes etapas de procedimiento:
- asignación de registros de marcado, en el que
- en cada caso, uno de los registros de datos de marcado se asigna a comandos de control en función de los requisitos de ejecución, si los comandos de control correspondientes cumplen los requisitos de ejecución, - los comandos de control a los que se asigna uno de los respectivos registros de datos de marcado pueden ser ejecutados por nodos de un sistema de bases de datos distribuidas (BC) o por dispositivos, en el que - los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan en los requisitos de ejecución;
- Almacenar los respectivos comandos de control con su respectivo registro de datos de marcado asociado en transacciones de control, en el que
- las transacciones de control se almacenan en el sistema de bases de datos distribuidas (BC);
- las transacciones de control se transmiten a los dispositivos (D, BCN_D) o nodos (BCN, BCN_D) por medio del sistema de bases de datos distribuidas (BC) (por ejemplo, por medio los bloques de datos del sistema de bases de datos distribuidas en el que se almacenan las transacciones de control)
- Verificar los respectivos registros de datos de marcado para una ejecución de los comandos de control de una de las transacciones de control mediante un dispositivo correspondiente;
- Ejecutar los comandos de control mediante el dispositivo correspondiente en función de un resultado de la verificación;
- Almacenar el resultado de la ejecución de los comandos de control en transacciones de confirmación del sistema de bases de datos distribuidas (por ejemplo, en los bloques de datos del sistema de bases de datos distribuidas).
El ejemplo de modo de realización de un procedimiento para el control asistido por ordenador de dispositivos puede comprender, en una variante, las siguientes etapas de procedimiento:
- por ejemplo, una asignación de registros de datos de marcado, en el que
- por ejemplo, en cada caso, uno de los registros de datos de marcado se asigna a comandos de control en función de los requisitos de ejecución, si los comandos de control correspondientes cumplen los requisitos de ejecución,
- por ejemplo, los comandos de control a los que se asigna uno de los respectivos registros de datos de marcado pueden ser ejecutados por nodos de un sistema de bases de datos distribuidas (BC) o por dispositivos, en el que
- por ejemplo, los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan en los requisitos de ejecución;
- por ejemplo un almacenamiento de los respectivos comandos de control con su respectivo registro de datos de marcado asociado en transacciones de control, en el que
- por ejemplo, las transacciones de control se almacenan en el sistema de bases de datos distribuidas (BC); - por ejemplo las transacciones de control se transmiten a los dispositivos (D, BCN_D) o nodos (BCN, BCN_D) por medio del sistema de bases de datos distribuidas (BC) (por ejemplo, por medio los bloques de datos del sistema de bases de datos distribuidas en el que se almacenan las transacciones de control)
- por ejemplo, verificar los respectivos registros de datos de marcado para una ejecución de los comandos de control de una de las transacciones de control mediante un dispositivo correspondiente;
- por ejemplo, una ejecución de los comandos de control mediante el dispositivo correspondiente en función de un resultado de la verificación;
- por ejemplo, un almacenamiento del resultado de la ejecución de los comandos de control en transacciones de confirmación del sistema de bases de datos distribuidas (por ejemplo, en los bloques de datos del sistema de bases de datos distribuidas).
En detalle, en este ejemplo de modo de realización se implementa un procedimiento para el control asistido por ordenador de dispositivos.
El procedimiento comprende una primera etapa de procedimiento 310 para asignar registros de datos de marcado, en el que
- en cada caso, uno de los registros de datos de marcado se asigna a comandos de control en función de los requisitos de ejecución, si los comandos de control correspondientes cumplen los requisitos de ejecución,
- los comandos de control a los que se asigna uno de los respectivos registros de datos de marcado pueden ser ejecutados por nodos de un sistema de bases de datos distribuidas (BC) o por dispositivos, en el que
- los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan en los requisitos de ejecución.
Esta etapa de procedimiento también puede comprender características adicionales que se dieron a conocer, por ejemplo, en relación con el módulo de marcado de los ejemplos de modo de realización anteriores. En particular, esta etapa de procedimiento puede comprender, por ejemplo, una verificación de los requisitos de ejecución, en la que se verifica si los dispositivos/nodos pueden ejecutar los comandos de control correspondientes o si se cumplen los requisitos correspondientes para la ejecución.
El procedimiento comprende una segunda etapa de procedimiento 320 para almacenar los respectivos comandos de control con su registro de datos de marcado respectivo asociado en las transacciones de control, en el que
- las transacciones de control se almacenan en el sistema de bases de datos distribuidas (BC);
- las transacciones de control se transmiten a los dispositivos (D, BCN_D) o nodos (BCN, BCN_D) por medio del sistema de bases de datos distribuidas (BC).
La transferencia o transmisión tiene lugar, por ejemplo, a través de la primera red de comunicación por medio del sistema de bases de datos distribuidas, como se explicó en los ejemplos de modo de realización anteriores.
El procedimiento comprende una tercera etapa de procedimiento 330 para verificar los respectivos registros de datos de marcado para una ejecución de los comandos de control de una de las transacciones de control mediante un dispositivo correspondiente. Esto se puede hacer, por ejemplo, mediante el propio dispositivo correspondiente o mediante el sistema de bases de datos distribuidas.
La verificación da un resultado que indica si el dispositivo correspondiente puede Y o no N ejecutar los comandos de control.
Por consiguiente, el procedimiento comprende una cuarta etapa de procedimiento para ejecutar 340 los comandos de control mediante el dispositivo correspondiente dependiendo del resultado de la verificación, en el que los comandos de control de la transacción de control se ejecutan si esto se permite o confirma Y por el resultado (de la verificación).
El procedimiento comprende una quinta etapa de procedimiento para almacenar 350 el resultado de la ejecución de los comandos de control en transacciones de confirmación de los bloques de datos del sistema de bases de datos distribuidas.
Si la verificación revela o si el resultado indica que los comandos de control no deben ser ejecutados N por el dispositivo correspondiente, se lleva a cabo una sexta etapa de procedimiento 360. Esto puede, por ejemplo, cancelar la ejecución de los comandos de control de la secuencia de comandos, por ejemplo, mediante un comando de control de cancelación para los comandos de control de la secuencia de comandos almacenado en una transacción, que a su vez se almacena en bloques de la cadena de bloques. De forma alternativa o además, estos u otros comandos de control resultantes de la secuencia de comandos pueden cancelarse total o parcialmente o declararse inválidos. De forma alternativa o además, se evita una ejecución/procesamiento de los comandos de control correspondientes.
De forma alternativa o además, la verificación se puede reiniciar en la sexta etapa de procedimiento y el procedimiento vuelve a la tercera etapa de procedimiento. De esta manera, es posible, por ejemplo, esperar hasta que, por ejemplo, el sistema de bases de datos distribuidas proporcione un registro de datos de marcado correspondiente. Para ello, se puede tener en cuenta, por ejemplo, un retardo de tiempo configurable, que indica en particular cuánto tiempo se tarda en volver a la tercera etapa de procedimiento. De forma alternativa o además, la espera o la repetición de las etapas de procedimiento pueden limitarse, por ejemplo, limitando el número de repeticiones a un número predeterminado de repeticiones y/o especificando un tiempo de espera máximo. Si se superan los valores correspondientes (tiempo de espera máximo, número de repeticiones), no se ejecutan los comandos de control correspondientes. A continuación, esto se documenta, preferentemente, en las transacciones del sistema de bases de datos distribuidas.
De forma alternativa o además, el resultado también se puede almacenar en una transacción de confirmación en la cadena de bloques (es decir, en un bloque de la cadena de bloques) en la sexta etapa de procedimiento.
Como se explica en los ejemplos de modo de realización anteriores, las etapas de procedimiento individuales pueden implementarse mediante diferentes componentes del sistema de control. Estos son, por ejemplo, el propio sistema de bases de datos distribuidas y/o los dispositivos y/o nodos del sistema de bases de datos distribuidas.
Por medio de la invención (de este ejemplo de modo de realización o de los anteriores), una secuencia de comandos se puede dividir fácilmente en comandos de control o transacciones de control, que luego se procesan mediante dispositivos apropiados. Esto está garantizado por la alta integridad de los datos, que se logra, por ejemplo, mediante una cadena de bloques (por ejemplo, para proteger contra la manipulación de los comandos de control que se procesarán en las transacciones de control). Debido a que el resultado del procesamiento de los comandos de control o las transacciones de control se almacena en las transacciones de confirmación, los dispositivos también se pueden supervisar con la invención. Las transacciones de confirmación también pueden comprender detalles del procesamiento de las transacciones de control/los comandos de control. Estos son, por ejemplo, tiempo de fabricación o problemas de fabricación que surgieron durante el procesamiento (por ejemplo, la fabricación de un producto). A este respecto, una transacción de confirmación también puede comprender información de que el procesamiento de los comandos de control no tuvo éxito. Si estos comandos de control ejecutados sin éxito son comandos de control presupuestos para otros/más comandos de control, el resultado de verificar los requisitos de ejecución mediante el módulo de marcado para estos otros/más comandos de control mostraría, en particular, que estos otros/más comandos de control no pueden ser ejecutados por un/el dispositivo correspondiente.
Sin embargo, si se cumplen los requisitos de ejecución para otros/adicionales comandos de control, se asigna un registro de datos de marcado que permite la ejecución.
Las etapas de procedimiento tres a seis (330-360) pueden ser etapas de procedimiento opcionales de acuerdo con la variante de implementación.
La Fig. 4 muestra un cuarto ejemplo de modo de realización de la invención como módulo de marcado 110.
El módulo de marcado 110 es adecuado para un sistema de bases de datos distribuidas o para un sistema de control con un sistema de bases de datos distribuidas para controlar y/o supervisar dispositivos o para dispositivos que ejecutan comandos de control (por ejemplo, en forma de transacciones).
El módulo de marcado 110 comprende una primera interfaz 410, una primera unidad de evaluación 420 y opcionalmente una memoria de configuración 430, que preferentemente están conectadas comunicativamente entre sí a través de un bus 401. Un bus también puede ser, en este caso, por ejemplo, un flujo de programa simple o un intercambio de datos entre los componentes correspondientes.
El módulo de marcado puede por ejemplo, comprender también además uno o más componentes adicionales, como, por ejemplo, un procesador, una unidad de memoria, otras interfaces de comunicación (por ejemplo, Ethernet, WLAN), un dispositivo de entrada, en particular un teclado de ordenador o un ratón de ordenador, y un dispositivo de visualización (por ejemplo, un monitor). El procesador puede comprender, por ejemplo, varios procesadores adicionales, que se pueden utilizar en particular para implementar otros ejemplos de modo de realización. El o los componentes adicionales también pueden, por ejemplo, estar conectados comunicativamente entre sí a través del bus.
El procesador puede ser, por ejemplo, un ASIC que se ha implementado de manera específica de aplicación para las funciones de un módulo respectivo (o una unidad) o todos los módulos del ejemplo de modo de realización (y/o otros ejemplos de modo de realización), en el que los componentes del programa o los comandos del programa se implementan, en particular, como circuitos integrados. El procesador puede ser, por ejemplo, también un FPGA, que está configurado en particular por medio de los comandos de programa de tal manera que el FPGA realiza las funciones de un módulo respectivo o todos los módulos del ejemplo de modo de realización (y/o otros ejemplos de modo de realización).
La primera interfaz 410 está configurada para recibir o recuperar comandos de control. Los comandos de control pueden ser, por ejemplo, transferidos a la primera interfaz 410 por un usuario por medio de una GUI. Sin embargo, los comandos de control también pueden ser proporcionados por un servidor u otra base de datos. Esto puede ser nuevamente un sistema de bases de datos distribuidas, por ejemplo, o una base de datos jerárquica. Si el módulo de marcado debe usarse, por ejemplo, en un sistema de control de acuerdo con la invención, los comandos de control o una secuencia de comandos pueden transmitirse al sistema de control de la misma manera que se describe en este ejemplo de modo de realización.
Los comandos de control también pueden ser proporcionados, por ejemplo, por un módulo de descomposición, como se explica en los ejemplos de modo de realización anteriores. El módulo de descomposición recibe o recupera a tal efecto los comandos de control o secuencias de comandos.
Los comandos de control o secuencias de comandos pueden ser, por ejemplo, transferidos al primer módulo de descomposición por un usuario por medio de una GUI y, por ejemplo, a través de una segunda interfaz o la primera interfaz 410. Sin embargo, los comandos de control o las secuencias de comandos también pueden ser proporcionados al módulo de descomposición por un servidor u otra base de datos. Esto puede ser nuevamente un sistema de bases de datos distribuidas, por ejemplo, o una base de datos jerárquica.
La primera unidad de evaluación 420 está configurada para asignar registros de datos de marcado, en la que
- en cada caso, uno de los registros de datos de marcado se asigna a los respectivos comandos de control en función de los requisitos de ejecución, si los comandos de control correspondientes cumplen los requisitos de ejecución,
- los comandos de control a los que se asigna uno de los respectivos registros de datos de marcado pueden ser ejecutados por nodos de un sistema de bases de datos distribuidas o por dispositivos, en el que
- los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan en los requisitos de ejecución;
La memoria de configuración comprende los datos específicos de dispositivo sobre los dispositivos y/o los datos específicos de dispositivo sobre los nodos y/o los requisitos específicos de dispositivo y/o los requisitos de ejecución. Como ya se ha explicado, los requisitos de ejecución se pueden especificar (por ejemplo, mediante los propios comandos de control o mediante una política) o los requisitos de ejecución se pueden calcular basándose en los comandos de control.
El módulo de determinación es ventajoso para mejorar, en particular, la ejecución de comandos de control por dispositivos o nodos (por ejemplo, robots de fabricación, sistemas de control para una red de distribución de energía, terminales bancarias, cajeros automáticos, transferencias entre bancos) que están conectados entre sí a través de una red.
Además, por ejemplo, se puede aumentar la seguridad al operar una infraestructura distribuida (por ejemplo, un sistema de bases de datos distribuidas con dispositivos y/o nodos o nodos/dispositivos que acceden al sistema de bases de datos distribuidas), que es implementada total o parcialmente mediante un sistema de bases de datos distribuidas (por ejemplo, una cadena de bloques). En particular, el término comandos de control debe entenderse de forma amplia. Además de la definición mencionada anteriormente, esto también puede involucrar transacciones que deben ser ejecutadas por un dispositivo (por ejemplo, un nodo en una cadena de bloques o un dispositivo fuera de la cadena de bloques, por ejemplo, el dispositivo D). En otras palabras, en particular, mediante el dispositivo las transacciones no verificadas se convierten en transacciones verificadas, en las que la verificación se lleva a cabo, por ejemplo, sobre la base de los requisitos específicos de dispositivo y los datos específicos de dispositivo (también de los requisitos de ejecución) que deben ejecutar los comandos de control.
Por medio de la invención, por ejemplo, se pueden garantizar o verificar los requisitos específicos de dispositivo necesarios para la ejecución de los comandos de control en el dispositivo. Los requisitos específicos de dispositivo también pueden ser, por ejemplo, requisitos de seguridad y/o requisitos específicos de la ubicación (por ejemplo, indicación del país, indicación de GPS o código postal) que un dispositivo debe cumplir para ejecutar los comandos de control. O, por ejemplo, los requisitos específicos de dispositivo para la ejecución también pueden requerir una autenticación y/o autentificación determinada/predefinida.
Los requisitos específicos de dispositivo para nodos o dispositivos pueden, por ejemplo, también estar relacionados con el usuario o comprender requisitos específicos de usuario. Por ejemplo, un primer usuario puede exigir un bajo nivel de precisión en la fabricación de una pieza de trabajo en los requisitos específicos de dispositivo que se le asignan. Por ejemplo, un segundo usuario puede exigir entonces un alto nivel de precisión en la fabricación de una pieza de trabajo en los requisitos específicos de dispositivo que se le asignan. De esta forma, también se pueden almacenar requisitos de seguridad relacionados con el usuario. También es concebible, por ejemplo, que a tipos específicos o tipos de comandos de control, relacionados con el usuario o no, se les asignen requisitos específicos de dispositivo que el módulo de marcado tenga en cuenta. Por ejemplo, puede ser necesario que un comando de control para cargar firmware solo sea emitido por un dispositivo que cumpla con los requisitos de seguridad especificados, por ejemplo, para asegurarse de que el firmware no sea fácilmente accesible para todos en una planta de fabricación. Estos requisitos de seguridad predefinidos pueden, por ejemplo, requerir que solo determinado personal tenga acceso a un dispositivo correspondiente o que el dispositivo esté protegido por una contraseña y/u otros mecanismos criptográficos (por ejemplo, el acceso solo es posible insertando una tarjeta con chip e introduciendo un pin).
Este puede ser el caso, por ejemplo, si alguien quiere retirar efectivo de un dispositivo (por ejemplo, un cajero automático). Los comandos de control son entonces, por ejemplo, la solicitud del cliente de realizar una retirada de efectivo. Si, por ejemplo, un cliente correspondiente ha configurado (por ejemplo, en su banco local o banca en línea) que, preferentemente, solo en países específicos, por ejemplo, Italia, Francia y Austria, se permite una retirada de efectivo, este se almacena en los requisitos específicos de dispositivo, que preferentemente se asignan a un usuario determinado. Un cajero automático en Andorra posiblemente no permitiría o evitaría una retirada. También puede ser necesaria la autenticación predefinida del cliente, por ejemplo, debido a los requisitos de seguridad. Por ejemplo, que se introduzca un pin para una retirada (que no es necesariamente el caso en los EE. UU., por ejemplo) y/o que se requiera una longitud determinada de pin (por ejemplo, 8 caracteres) y/o que se requieran otros procedimientos de autenticación adicionales (por ejemplo, autenticación de 2 factores, Mobile-TAN, Google Authenticator). De manera similar, por ejemplo, se puede realizar un cobro de una tarjeta de efectivo, en el que, por ejemplo, los requisitos específicos de dispositivo para la tarjeta de efectivo y el dispositivo para cargar predefinen los requisitos de seguridad. Por ejemplo, la tarjeta de efectivo o el dispositivo deben usar o tener procedimientos criptográficos predefinidos y/o procedimientos de autenticación para cargar para llevar a cabo el proceso de carga.
De forma alternativa o además, la (primera) unidad de evaluación también puede analizar más los comandos de control o analizarlos más extensamente. Si, por ejemplo, la unidad de evaluación ya determina que los requisitos específicos de dispositivo no se cumplen o no se pueden cumplir (por ejemplo, los comandos de control se enviaron desde un país no aprobado o están destinados a ejecutarse en un país no aprobado), la (primera) unidad de evaluación puede crear, por ejemplo, una transacción de control que indica al dispositivo, nodo o sistema correspondiente que no se puede ejecutar y, preferentemente, evita o prohíbe la ejecución de los comandos de control. De forma alternativa, por ejemplo, no se puede generar ninguna transacción de control y en algún momento hay un tiempo de espera para la ejecución de los comandos de control, por ejemplo, después de un período predefinido.
Para determinar esto, la (primera) unidad de evaluación compara los datos específicos de dispositivo para el dispositivo que debe ejecutar los comandos de control con los requisitos específicos de dispositivo, por ejemplo, para los comandos de control. Dependiendo del resultado de esta comparación, se genera una transacción de control que permite ejecutar los comandos de control en el dispositivo correspondiente, o no se crea ninguna transacción de control o se crea una transacción de control que prohíbe o impide la ejecución de los comandos de control. De forma alternativa o además, esta información también se puede almacenar en un registro de datos de marcado. Para ello, el registro de datos de marcado puede por ejemplo, comprender un valor de -1, que indica que la ejecución no está permitida, un valor de 0, que indica que la ejecución no es posible, o un valor de 1, que indica que la ejecución está permitida o es posible. En consecuencia, a los comandos de control no ejecutables se les puede asignar un registro de datos de marcado que indica si se pueden ejecutar o no los comandos de control correspondientes.
Si la (primera) unidad de evaluación determina sobre la base de los requisitos de ejecución que los comandos de control se pueden ejecutar (la comparación es, por lo tanto, positiva), a los comandos de control correspondientes se les asigna un registro de datos de marcado correspondiente que indica que los comandos de control pueden ejecutarse. Esto puede, por ejemplo, realizarse mediante un primer módulo de asignación que es, por ejemplo, un componente integral del módulo de marcado o es un componente integral de la unidad de evaluación.
A continuación, los comandos de control se transfieren, si es necesario junto con el registro de datos de marcado asociado, por ejemplo, a un primer módulo de memoria del módulo de marcado. Esta transferencia puede tener lugar, por ejemplo, mediante el módulo de asignación, la (primera) unidad de evaluación o el propio módulo de marcado.
El primer módulo de memoria está configurado para almacenar los respectivos comandos de control en las transacciones de control, en el que los comandos de control se almacenan en las transacciones de control, por ejemplo, junto con el registro de datos de marcado asignado, si los comandos de control pueden ser ejecutados por uno de los dispositivos (por ejemplo, un cajero automático).
Es decir, en función, por ejemplo, del resultado de la comparación, se determina si se almacena una transacción de control y/o con qué contenido se almacena una transacción de control.
Para el almacenamiento, las transacciones de control se pueden almacenar en bloques de datos (B) del sistema de bases de datos distribuidas (BC), en el que las transacciones de control en particular se transmiten a los dispositivos (D, BCN_D) o los nodos que usan los bloques de datos (B), siempre que se haya creado una transacción de control.
Además, el módulo de marcado 110 también puede comprender, por ejemplo, un primer módulo de asignación y/o un primer módulo de memoria y/o módulos adicionales, como se explicó en los ejemplos de modo de realización. Los nodos o dispositivos pueden entonces comprender, por ejemplo, un módulo de verificación y/o un módulo de ejecución, como se explicó en los ejemplos de modo de realización.
También sería concebible, por ejemplo, que la banca en línea esté protegida de la manera mencionada anteriormente verificando los requisitos de seguridad y/o los requisitos relacionados con la ubicación del ordenador (es decir, el dispositivo que envía los comandos de control) y determinar si la retirada o la transferencia está permitida mediante otro dispositivo. Para ello, por ejemplo, este ordenador puede ser un nodo del sistema de bases de datos distribuidas o un dispositivo, como ya se ha explicado.
La Fig. 5 muestra un quinto ejemplo de modo de realización de la invención como diagrama de flujo de un procedimiento de acuerdo con la invención.
El procedimiento se implementa preferentemente con ayuda de un ordenador.
En detalle, en este ejemplo de modo de realización se implementa un procedimiento para el marcado asistido por ordenador de comandos de control. El procedimiento también se puede usar, por ejemplo, para determinar la ejecutabilidad de los comandos de control, como se explica en la Fig. 4, por ejemplo.
El procedimiento comprende una primera etapa de procedimiento 510 para recibir o recuperar comandos de control.
El procedimiento comprende una segunda etapa de procedimiento 520 que asigna registros de datos de marcado, en el que
- en cada caso, uno de los registros de datos de marcado se asigna a los comandos de control en función de los requisitos de ejecución, si los comandos de control correspondientes cumplen los requisitos de ejecución,
- los comandos de control a los que se asigna uno de los respectivos registros de datos de marcado pueden ser ejecutados por nodos de un sistema de bases de datos distribuidas o por dispositivos,
- los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan en los requisitos de ejecución.
Por ejemplo, se verifica si un dispositivo cumple los requisitos específicos de dispositivo al verificar los datos específicos de dispositivo para el dispositivo correspondiente.
Los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan o se almacenarán en los requisitos de ejecución. El sistema de bases de datos distribuidas es, por ejemplo, una cadena de bloques.
Los nodos o dispositivos están conectados, por ejemplo, por medio del sistema de bases de datos distribuidas.
Para verificar la viabilidad de los comandos de control, se verifican, por ejemplo, los requisitos de ejecución. Para ello, los requisitos específicos de dispositivo o los comandos de control presupuestos se analizan y se comparan con los comandos de control ya ejecutados y los requisitos específicos de dispositivo para los dispositivos disponibles. Por ejemplo, en esta etapa por medio del registro de datos de marcado también se puede realizar una atribución específica o asignación de un nodo específico o un dispositivo específico que debe ejecutar los comandos de control. En particular, esto mejora la fiabilidad y seguridad de la ejecución o garantiza que la ejecución, por ejemplo, produce el resultado deseado. Este es, por ejemplo, que un producto ha sido fabricado con la precisión requerida.
Si bien la invención se ilustró y describió más detalladamente con el ejemplo de realización preferente, la invención no se ve limitada con los ejemplos dados a conocer y se pueden derivar otras variaciones por el especialista en la técnica, sin que se abandone el ámbito protector de la invención.
Bibliografía
[1] Andreas M. Antonopoulos "Mastering Bitcoin: Unlocking Digital Cryptocurrencies", O'Reilly Media, diciembre de 2014
[2] Roger M. Needham, Michael D. Schroeder "Using encryption for authentication in large networks of computers" a Cm : Communications of the ACM. Volumen 21, No. 12, diciembre de 1978
[3] Ross Anderson "Security Engineering. A Guide to Building Dependable Distributed Systems" Wiley, 2001 [4] Henning Diedrich "Ethereum: Blockchains, Digital Assets, Smart Contracts, Decentralized Autonomous Organizations", CreateSpace Independent Publishing Platform, 2016
[5] "The Ethereum Book Project/Mastering Ethereum" https://github.com/ethereumbook/ethereumbook, última actualización 5.10.2017
[6] Leemon Baird "The Swirlds Hashgraph Consensus Algorithm: Fair, Fast, Byzantine Fault Tolerance", Swirlds Tech Report SWIRLDS-TR-2016-01, 31.5.2016
[7] Leemon Baird "Overview of Swirlds Hashgraph", 31.5.2016
[8] Blockchain Oracles, última actualización 14.03.2018 https://blockchainhub.net/blockchain-oracles/
[9] Joseph Poon, Thaddeus Dryja: The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. 14 de enero de 2016, consultado el 30 de junio de 2018 (PDF; 3 MB, inglés).

Claims (11)

  1. REIVINDICACIONES
    i . Sistema de control para el control y/o la supervisión de dispositivos, que comprende:
    - un sistema de bases de datos distribuidas (BC) o un sistema de comunicación distribuida;
    - un primer módulo de marcado (110) para asignar registros de datos de marcado, en el que
    - en cada caso, uno de los registros de datos de marcado se asigna a comandos de control en función de los requisitos de ejecución, si los comandos de control correspondientes cumplen los requisitos de ejecución,
    - los comandos de control a los que se asigna uno de los respectivos registros de datos de marcado pueden ser ejecutados por nodos (BCN, BCN_D) del sistema de bases de datos distribuidas (BC) o del sistema de comunicación distribuida o por dispositivos (D, BCN_D), - los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan en los requisitos de ejecución;
    - un primer módulo de memoria (130) para almacenar los respectivos comandos de control con su registro de datos de marcado respectivo asociado en las transacciones de control, en el que - las transacciones de control se almacenan en el sistema de bases de datos distribuidas (BC) o por el sistema de comunicación distribuida;
    - las transacciones de control se transmiten a los dispositivos (D, BCN_D) o nodos (BCN, BCN_D) por medio del sistema de bases de datos distribuidas (BC) o el sistema de comunicación distribuida.
  2. 2. Sistema de control de acuerdo con la reivindicación 1, en el que los comandos de control presupuestos ya son comandos de control ejecutados para los que la confirmación de su ejecución se almacena en transacciones de confirmación del sistema de bases de datos distribuidas.
  3. 3. Sistema de control de acuerdo con una de las reivindicaciones anteriores, en el que
    - el sistema de bases de datos distribuidas es el sistema de comunicación distribuida o es una cadena de bloques y la cadena de bloques comprende bloques de datos,
    - los bloques de datos son bloques de la cadena de bloques.
  4. 4. Sistema de control de acuerdo con una de las reivindicaciones anteriores, en el que
    - los registros de datos de marcado comprenden identificadores únicos para los dispositivos y/o nodos que deben ejecutar los comandos de control correspondientes.
  5. 5. Sistema de control de acuerdo con una de las reivindicaciones anteriores, en el que los bloques de datos se concatenan entre sí mediante una función hash criptográfica (H).
  6. 6. Sistema de control de acuerdo con una de las reivindicaciones anteriores, en el que el sistema de control comprende un primer módulo de verificación y/o un primer módulo de ejecución y/o un segundo módulo de memoria.
  7. 7. Sistema de control de acuerdo con una de las reivindicaciones anteriores, en el que
    - el sistema de control o el módulo de marcado (110) comprende un módulo de actividad,
    - el módulo de actividad está configurado para mostrar o documentar la actividad del dispositivo y/o del módulo de marcado.
  8. 8. Dispositivo que comprende:
    - un primer módulo de comunicación, en el que el primer módulo de comunicación está configurado para recibir transacciones de control de un sistema de bases de datos distribuidas, en el que - las transacciones de control con comandos de control para el dispositivo se almacenan en el sistema de bases de datos distribuidas,
    - las transacciones de control comprenden registros de datos de marcado asignados a los comandos de control;
    - un primer módulo de verificación, estando configurado el primer módulo de verificación para verificar los respectivos registros de datos de marcado para una ejecución de los comandos de control de una de las transacciones de control mediante un dispositivo correspondiente;
    - un primer módulo de ejecución, en el que el primer módulo de ejecución está configurado para ejecutar los comandos de control mediante el dispositivo correspondiente en función de un resultado de la verificación.
  9. 9. Procedimiento para el control asistido por ordenador de dispositivos con las siguientes etapas de procedimiento:
    - asignación de registros de marcado, en el que
    - en cada caso, uno de los registros de datos de marcado se asigna a comandos de control en función de los requisitos de ejecución, si los comandos de control correspondientes cumplen los requisitos de ejecución,
    - los comandos de control a los que se asigna uno de los respectivos registros de datos de marcado pueden ser ejecutados por nodos de un sistema de bases de datos distribuidas (BC) o un sistema de comunicación distribuida o por dispositivos, en el que
    - los requisitos específicos de dispositivo y/o los comandos de control presupuestos se almacenan en los requisitos de ejecución;
    - Almacenar los respectivos comandos de control con su respectivo registro de datos de marcado asociado en transacciones de control, en el que
    - las transacciones de control se almacenan en el sistema de bases de datos distribuidas (BC) o por el sistema de comunicación distribuida;
    - las transacciones de control se transmiten a los dispositivos (D, BCN_D) o nodos (BCN, BCN_D) por medio del sistema de comunicación distribuida o el sistema de bases de datos distribuidas (BC).
  10. 10. Producto de programa informático con comandos de programa para realizar el procedimiento de acuerdo con la reivindicación 9.
  11. 11. Dispositivo de provisión para el producto de programa informático de acuerdo con la reivindicación 10, en el que el dispositivo de provisión almacena y/o proporciona el producto de programa informático.
ES18800489T 2017-10-23 2018-10-22 Procedimiento y sistema de control para el control y/o la supervisión de dispositivos Active ES2869256T3 (es)

Applications Claiming Priority (12)

Application Number Priority Date Filing Date Title
EP17197791 2017-10-23
EP18000033 2017-10-23
EP18000379 2018-01-22
EP18152750 2018-01-22
EP18162189 2018-03-16
EP18167956 2018-04-18
EP2018059891 2018-04-18
PCT/EP2018/060900 WO2019081071A1 (de) 2017-10-23 2018-04-27 Verfahren und steuersystem zum steuern und/oder überwachen von geräten
EP18174922 2018-05-29
PCT/EP2018/071066 WO2019081086A1 (de) 2017-10-23 2018-08-02 Verfahren und steuersystem zum steuern und/oder überwachen von geräten
PCT/EP2018/071065 WO2019081085A1 (de) 2017-10-23 2018-08-02 Verfahren und steuersystem zum steuern und/oder überwachen von geräten
PCT/EP2018/078902 WO2019081434A1 (de) 2017-10-23 2018-10-22 Verfahren und steuersystem zum steuern und/oder überwachen von geräten

Publications (1)

Publication Number Publication Date
ES2869256T3 true ES2869256T3 (es) 2021-10-25

Family

ID=70803398

Family Applications (1)

Application Number Title Priority Date Filing Date
ES18800489T Active ES2869256T3 (es) 2017-10-23 2018-10-22 Procedimiento y sistema de control para el control y/o la supervisión de dispositivos

Country Status (5)

Country Link
US (1) US11615007B2 (es)
EP (2) EP3673623B1 (es)
JP (1) JP7065956B2 (es)
CN (1) CN111492624B (es)
ES (1) ES2869256T3 (es)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10419225B2 (en) 2017-01-30 2019-09-17 Factom, Inc. Validating documents via blockchain
US10411897B2 (en) 2017-02-17 2019-09-10 Factom, Inc. Secret sharing via blockchains
US10817873B2 (en) 2017-03-22 2020-10-27 Factom, Inc. Auditing of electronic documents
EP3673623B1 (de) * 2017-10-23 2021-03-17 Siemens Aktiengesellschaft Verfahren und steuersystem zum steuern und/oder überwachen von geräten
US11170366B2 (en) 2018-05-18 2021-11-09 Inveniam Capital Partners, Inc. Private blockchain services
US10783164B2 (en) 2018-05-18 2020-09-22 Factom, Inc. Import and export in blockchain environments
US11134120B2 (en) 2018-05-18 2021-09-28 Inveniam Capital Partners, Inc. Load balancing in blockchain environments
US11276056B2 (en) 2018-08-06 2022-03-15 Inveniam Capital Partners, Inc. Digital contracts in blockchain environments
US11989208B2 (en) 2018-08-06 2024-05-21 Inveniam Capital Partners, Inc. Transactional sharding of blockchain transactions
US11328290B2 (en) 2018-08-06 2022-05-10 Inveniam Capital Partners, Inc. Stable cryptocurrency coinage
EP3715981A1 (de) * 2019-03-27 2020-09-30 Siemens Aktiengesellschaft Verfahren und steuersystem zum steuern einer ausführung von transaktionen
US11343075B2 (en) 2020-01-17 2022-05-24 Inveniam Capital Partners, Inc. RAM hashing in blockchain environments
CN114371628B (zh) * 2020-10-19 2023-11-10 中国移动通信集团辽宁有限公司 区块链系统、管理装置、智能家电的控制方法及智能家电
US12008526B2 (en) 2021-03-26 2024-06-11 Inveniam Capital Partners, Inc. Computer system and method for programmatic collateralization services
US12007972B2 (en) 2021-06-19 2024-06-11 Inveniam Capital Partners, Inc. Systems and methods for processing blockchain transactions

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10008973B4 (de) * 2000-02-25 2004-10-07 Bayerische Motoren Werke Ag Autorisierungsverfahren mit Zertifikat
DE10318031A1 (de) 2003-04-19 2004-11-04 Daimlerchrysler Ag Verfahren zur Sicherstellung der Integrität und Authentizität von Flashware für Steuergeräte
DE102006012275B4 (de) 2006-03-15 2007-12-20 Phoenix Contact Gmbh & Co. Kg Datenübertragungs- und verarbeitungssystem mit sicherem Erfassen von kritischen Zuständen
CN101504621B (zh) * 2009-04-01 2011-06-29 杭州华三通信技术有限公司 一种避免全局资源乱序的分布式系统、设备及其应用方法
US8553562B2 (en) * 2010-09-08 2013-10-08 Telefonaktiebolaget L M Ericsson (Publ) Automated traffic engineering for multi-protocol label switching (MPLS) with link utilization as feedback into the tie-breaking mechanism
DE102011018878B3 (de) 2011-04-28 2012-09-27 Deutsches Zentrum für Luft- und Raumfahrt e.V. Verfahren zum Synchronisieren der Datenbestände von Datenbanken
CN102169507B (zh) * 2011-05-26 2013-03-20 厦门雅迅网络股份有限公司 一种分布式实时搜索引擎的实现方法
CN102831012A (zh) 2011-06-16 2012-12-19 日立(中国)研究开发有限公司 多节点分布式系统中的任务调度装置和任务调度方法
DE102011081796A1 (de) * 2011-08-30 2013-02-28 Endress + Hauser Gmbh + Co. Kg Verfahren zum Bedienen eines Feldgerätes
US8468423B2 (en) 2011-09-01 2013-06-18 International Business Machines Corporation Data verification using checksum sidefile
EP3362965A4 (en) * 2015-10-13 2019-08-07 Transactive Grid Inc. USING A DISTRIBUTED CONSENSUS CONTROL BASED ON A BLOCK CHAIN
US10713654B2 (en) * 2016-01-21 2020-07-14 International Business Machines Corporation Enterprise blockchains and transactional systems
MX2018010050A (es) 2016-02-23 2019-01-21 Nchain Holdings Ltd Transacciones turing completas basadas en agente que integran retroalimentacion dentro de un sistema de cadena de bloques.
US10063572B2 (en) 2016-03-28 2018-08-28 Accenture Global Solutions Limited Antivirus signature distribution with distributed ledger
DE102016205289A1 (de) 2016-03-31 2017-10-05 Siemens Aktiengesellschaft Verfahren, Prozessor und Gerät zur Integritätsprüfung von Nutzerdaten
US9747586B1 (en) * 2016-06-28 2017-08-29 Cpn Gold B.V. System and method for issuance of electronic currency substantiated by a reserve of assets
FR3058292B1 (fr) * 2016-10-31 2019-01-25 Idemia Identity And Security Procede de fourniture d'un service a un utilisateur
US10257206B2 (en) * 2016-12-21 2019-04-09 International Business Machines Corporation Monitoring actions performed by a network of peer devices using a blockchain
US9992022B1 (en) * 2017-02-06 2018-06-05 Northern Trust Corporation Systems and methods for digital identity management and permission controls within distributed network nodes
US11095432B2 (en) * 2017-04-05 2021-08-17 Samsung Sds Co., Ltd. System for processing data based on blockchain and operating method thereof
KR101919590B1 (ko) * 2017-05-10 2019-02-08 주식회사 코인플러그 블록체인 데이터베이스 및 이와 연동하는 머클 트리 구조를 통해 사물 인터넷 기기에 대한 비용을 결제하는 방법, 이를 이용한 서버, 서비스 제공 단말, 및 사용자 전자 지갑
EP3673623B1 (de) * 2017-10-23 2021-03-17 Siemens Aktiengesellschaft Verfahren und steuersystem zum steuern und/oder überwachen von geräten
US10657261B2 (en) * 2017-11-30 2020-05-19 Mocana Corporation System and method for recording device lifecycle transactions as versioned blocks in a blockchain network using a transaction connector and broker service
US20190207748A1 (en) * 2017-12-29 2019-07-04 Seagate Technology Llc Blockchain storage device
US10873625B2 (en) * 2018-02-26 2020-12-22 International Business Machines Corpora ! Ion Service management for the infrastructure of blockchain networks
US11178579B2 (en) * 2018-03-27 2021-11-16 Skygrid, Llc System and method for unmanned transportation management
EP3565218B1 (en) * 2018-04-30 2023-09-27 Hewlett Packard Enterprise Development LP System and method of decentralized management of multi-owner nodes using blockchain
WO2020098845A2 (en) * 2020-03-13 2020-05-22 Alipay (Hangzhou) Information Technology Co., Ltd. Data authorization based on decentralized identifiers

Also Published As

Publication number Publication date
US20210200653A1 (en) 2021-07-01
CN111492624A (zh) 2020-08-04
EP3673623B1 (de) 2021-03-17
EP3673623A1 (de) 2020-07-01
EP3726438A1 (de) 2020-10-21
CN111492624B (zh) 2022-09-23
JP7065956B2 (ja) 2022-05-12
JP2021500789A (ja) 2021-01-07
US11615007B2 (en) 2023-03-28

Similar Documents

Publication Publication Date Title
ES2869256T3 (es) Procedimiento y sistema de control para el control y/o la supervisión de dispositivos
ES2866498T3 (es) Procedimiento y sistema de control para el control y/o la supervisión de dispositivos
KR102373685B1 (ko) 블록체인 iot장치를 위한 동작 시스템
US11640394B2 (en) Method, apparatuses and system for exchanging data between a distributed database system and devices
CN111492355B (zh) 用于控制和/或监控装置的方法和控制系统
CN110730973A (zh) 用于区块链的计算机辅助测试的方法和装置
ES2854289T3 (es) Procedimiento, equipos y sistema para proporcionar registros de datos con seguridad protegida
ES2866885T3 (es) Sistema y procedimiento para la vigilancia protegida criptográficamente de al menos un componente de un aparato o de una instalación
US11412047B2 (en) Method and control system for controlling and/or monitoring devices
CN111241557B (zh) 基于区块链的服务请求方法及装置
CN104471584B (zh) 对受保护数据集进行基于网络的管理
CN112669147B (zh) 基于区块链的服务请求方法及装置
US10805294B1 (en) Systems and methods for validating device permissions of computing devices to execute code on a decentralized database
WO2019199813A2 (en) Managed high integrity blockchain and blockchain communications that utilize containers
Buldin et al. Next generation industrial blockchain-based wireless sensor networks
US11231958B2 (en) Method and control system for controlling and/or monitoring devices
ES2812282T3 (es) Equipo y procedimiento de formación de bloques, equipo de nodo y procedimiento de confirmación de bloques
US11432156B2 (en) Security unit for an IoT device and method for running one or more applications for the secured exchange of data with one or more servers which provide web services
JP2023542824A (ja) 場所データを使用した秘密鍵の作成
US20220179384A1 (en) Method and control system for controlling an execution of transactions
Fiore Providing trust to multi-cloud storage platforms through the blockchain
Basile et al. Providing trust to multi-cloud storage platforms through the blockchain
JP2022108027A (ja) 制御装置、管理方法およびセキュリティプログラム
Sonawane et al. Secure Messaging Application Using Blockchain Technology