ES2299911T3 - Procedimiento para la transmision de datos. - Google Patents

Abstract

Procedimiento para la transmisión de datos entre usuarios que se comunican por medio de un bus de datos, en el que para el intercambio de telegramas de datos entre los usuarios dentro del tiempo del ciclo (13a) predeterminado para el ciclo de transmisión (13) encuentra aplicación una primera y una segunda ventana de tiempo (11, 12), en el que la primera ventana de tiempo (11) sirve para la transmisión de datos de procesos y la segunda ventana de tiempo sirve para la transmisión de datos adicionales, en el que se puede predeterminar la longitud de los telegramas de datos que representan los datos adicionales dentro de la longitud de la ventana de tiempo (12) correspondiente, caracterizado porque los usuarios calculan, de acuerdo con la invención, a partir de la diferencia entre el tiempo del ciclo (13a) y la longitud de la ventana de tiempo (11) de los datos de proceso, la longitud admisible de los telegramas de datos para datos adicionales o están previstos un parámetro para el comienzo temporal y otro parámetro para el final de los telegramas de datos, que representan los datos adicionales, dentro del ciclo de transmisión.

Description

Procedimiento para la transmisión de datos.

La invención parte del campo de la transmisión de datos de acuerdo con la reivindicación independiente 1. Se ocupa especialmente de la transmisión de datos en tiempo real en combinación con pocos datos críticos de tiempo dentro de un periodo de transmisión.

En un sistema de comunicaciones se intercambian periódicamente telegramas de datos entre estaciones. Además de esta llamada comunicación cíclica, que se realiza de una manera preferida en tiempo real, existe la necesidad de una llamada comunicación no planificada o acíclica, en la que se pueden incorporar protocolos discrecionales dentro de una ventana de tiempo conectada con todos los usuarios.

El documento EP 1 312 992 muestra un procedimiento para la transmisión de un protocolo de valor elevado como TCP/IP sin influencia del tráfico cíclico de datos, en el que un aparato subordinado (esclavo) inicia la transmisión por medio de una solicitud de alarma y un aparato de orden superior (maestro) provoca a través de un campo de datos de identificación la llamada de otros conjuntos de datos de mensajes en el aparato subordinado. El maestro transmite los conjuntos de datos de mensajes utilizando una dirección de destino suministrada por el subordinado a otro subordinado.

El documento US 2002/0091838 muestra un método para la adaptación de la velocidad de los datos en un bus de campo, para controlar una cantidad de datos creciente. Se acuerda una velocidad de transmisión nueva con todos los usuarios del bus y es utilizada por éstos para la transmisión siguiente. Durante la puesta en servicio se realiza, dado el caso, una nueva convención entre todos los usuarios.

El documento EP-A-1355456 describe un procedimiento para la transmisión de datos entre usuarios que se comunican por medio de un bus de datos, siendo realizada la transmisión de datos en forma de ciclos de comunicación. En este caso, dentro de un ciclo de comunicación están previstos un segmento estático y un segmento dinámico. A través de un parámetro de configuración se puede predeterminar la longitud del segmento estático.

El documento EP-A-0 755137 publica un protocolo de red híbrido con un procedimiento de arbitraje y divisiones de tiempo que se pueden asignar de forma opcional. Se conoce a partir de Raph Beischner y col.; "Flexray requirements specifications", Xpoo2270307 una especificación de protocolo de la Norma "Flexray". En esta norma, dentro de un ciclo de comunicaciones están previstos un segmento estático y un segmento dinámico. Se conoce a partir de Séller M. y col.: "byteflight specification Versión 0.5 Draft", XP002201782 una especificación de protocolo de la Norma "Byteflight".

Durante las primeras estructuras de ensayo de la Firma solicitante se ha constatado que en función de la cantidad de datos específica del usuario en el canal en tiempo real se han podido presentar casos, en los que debido a la anchura de banda reducida, no se transmiten ya datos adicionales necesarios, cuando la longitud de su telegrama es demasiado grande. Este problema se plantea especialmente en el caso de conexión y desconexión dinámica de usuarios del bus. En el supuesto de que, por ejemplo, en el caso de una velocidad de transmisión de 100 Mbits/s esté prevista una duración del telegrama de 1500 bytes para datos adicionales acíclicos, resultaría una ventana de tiempo necesaria para ello de 1500 x 8 bits/byte/100 Mbit/s = 120 \muS. En el supuesto de que un ciclo de transmisión comprenda 120 \muS, se dispondría para los datos en tiempo real cíclicos solamente 8 \muS, lo que sería en la práctica demasiado
reducido.

Ahora el problema de la invención es presentan una solución, que asegura una probabilidad de transmisión lo más alta posible para datos adicionales.

Este problema se soluciona con la invención porque para el intercambio de telegramas de datos entre los usuarios dentro del tiempo del ciclo predeterminado para el ciclo de transmisión encuentra aplicación una primera y una segunda ventana de tiempo, en el que la primera ventana de tiempo sirve para la transmisión de datos de procesos y la segunda ventana de tiempo sirve para la transmisión de datos adicionales y en el que se puede predeterminar la longitud de los telegramas de datos que representan los datos adicionales dentro de la longitud de la ventana de tiempo correspondiente y en el que los usuarios calculan, de acuerdo con la invención, a partir de la diferencia entre el tiempo del ciclo y la longitud de la ventana de tiempo de los datos de proceso, la longitud admisible de los telegramas de datos para datos adicionales o están previstos un parámetro para el comienzo temporal y otro parámetro para el final de los telegramas de datos, que representan los datos adicionales, dentro del ciclo de transmisión.

El ciclo de transmisión se entiende en este caso como duración periódica de un cuadro de datos que se repite. El cuadro de datos comprende al menos dos canales (ventana de tiempo). Los datos de proceso son, en general, datos críticos de tiempo, mientras que los datos adicionales comprenden datos menos críticos de tiempo, por ejemplo datos de configuración. Estos datos de configuración se podrían introducir a través de una Interfaz de Usuario o podrían ser predeterminados por medio de un control. La transmisión debe asegurarse, en oposición a los datos en tiempo real, en general, dentro de un cuadro de tiempo mayor (milisegundos). Los telegramas de datos pueden contener bytes de datos, sumas de control, direcciones y otras informaciones para asegurar la transmisión y asociación de los datos.

Esta adaptación de la longitud del telegrama de datos en el canal adicional se vincula con condiciones marginales de tiempo, de manera que de acuerdo con la longitud de la ventana de tiempo del canal de datos de proceso, se emiten longitudes variables de los telegramas de datos en el canal adicional. Por lo tanto, se puede realizar sin más una adaptación dinámica, en función de la carga de datos, sin influir en el funcionamiento de los datos de proceso. Esta adaptación podría ser diferente incluso de un ciclo de transmisión a otro, según el "tiempo restante" que esté disponible todavía en la ventana de datos adicionales. Ventaja del procedimiento: los datos transmitidos en ambas ventanas de tiempo se pueden transmitir o bien se pueden influenciar de una manera totalmente independiente entre sí y se pueden adaptar a las condiciones de funcionamiento.

También sería ventajoso que los datos de proceso se transmitieran en tiempo real y cíclicamente, es decir, con cada ciclo. Esto haría que el procedimiento fuese adecuado para el empleo en buses de campo para la comunicación de guía y posibilitaría la canalización selectiva de datos adicionales, sin realizar una modificación de la velocidad de transmisión. Tiempo real significa aquí que los datos críticos de tiempo deben prepararse en el receptor para el procesamiento antes de que se produzca la pérdida de datos a través de desbordamientos intermedios o asincronicidad y, por lo tanto, antes de que resulten, por ejemplo, durante la activación de un servo motor, ciclos de movimiento a tirones y/o irregulares. Esto se puede conseguir a través de programación cuidadosa de los recursos, ciclos de sincronización suficientemente altos y empleo de módulos de hardware autónomos para la descarga de la CPU así como por medio de la utilización de sistemas de funcionamiento adecuados (Núcleo +, etc.).

Cuando los datos de proceso y/o los datos adicionales están distribuidos sobre más de dos ventanas de tiempo de la misma y/o de diferente longitud y/o de diferente secuencia dentro de un ciclo de transmisión, se obtiene una utilidad flexible del tiempo de transmisión disponible.

Un procedimiento de acuerdo con la invención, en el que el comienzo de la emisión para un telegrama de datos de los datos adicionales dentro de la longitud de la ventana de tiempo correspondiente es variable, eleva adicionalmente la flexibilidad. Dentro del canal de datos útiles no existe, por lo tanto, ninguna determinación del instante en el que debe emitirse. Esto significa que cada usuario que desea emitir puede establecer por sí mismo cuándo quiere emitir. Especialmente en el caso de realización de un modo de consulta, en el que en virtud de la consulta del usuario pueden resultar respuestas de otros usuarios, se podrían alojar dentro de la ventana de tiempo del canal adicional telegramas de consultas y telegramas de respuestas.

La duración de tiempo entre consulta y respuesta está determinada en este caso, por ejemplo, a través del tiempo de procesamiento de los usuarios consultados y depende del sistema.

Si se asocia a cada usuario dentro de la ventana de tiempo correspondiente para datos útiles un instante propio para el comienzo de la emisión, esto previene colisiones. Cuando ahora se permite a cada usuario un tiempo de emisión determinado, entonces se puede estimar de una manera relativamente sencilla si o cuándo podría estar ocupada la línea. Si en el peor de los casos todos los usuarios desean emitir al mismo tiempo, entonces éstos responden a una secuencia predeterminada, que da como resultado también los instantes de emisión mencionados. Si emite en primer lugar solamente un usuario, entonces obtiene automáticamente la prioridad máxima (ver más abajo).

También sería concebible establecer los instantes de emisión para el comienzo de la emisión dentro de cada ciclo de transmisión, por ejemplo cuando se modifica la longitud media de los telegramas de datos. Esta adaptación se podría realizar por medio de un generador aleatorio realizado en cada usuario o podría estar predeterminado por un mecanismo de control del orden superior. También sería concebible un intercambio de los instantes específicos de los usuarios para el comienzo de la emisión entre los usuarios del bus.

Los datos en el canal adicional se pueden transmitir de una manera ventajosa también acíclicamente, es decir, no con cada ciclo de transmisión. El canal solamente está disponible, por lo tanto, en caso necesario y no requiere condiciones en tiempo real. Puede funcional como canal de reserva y, dado el caso, liberar anchura de banda para datos de proceso.

Si los telegramas de datos en el canal adicional están incorporados en protocolos, como por ejemplo el HTTP (Hyper Text Transfer Protokoll), el FTP (File Transfer Protokoll), TELNET, etc., entonces éstos son utilizados para la representación de informaciones de estado y para la configuración de usuarios. Por lo tanto, también se puede realizar una transmisión segura y es posible la utilización de pilas estándar (módulos Firmware), como ya se ponen a disposición de serie por muchos sistemas operativos. Esto facilita la realización y, además, es todavía económico, puesto que estas pilas no deben adquirirse adicionalmente o incluso deben desarrollarse nuevas. Otra ventaja o bien la consecuencia de lo mencionado anteriormente es que es muy fácil una ruta, por ejemplo, desde un PC a través de un control hacia un accionamiento, puesto que el control solamente debe transferir el telegrama IP sin interpretación y, por lo tanto, posee una funcionalidad de puerto de acceso.

Si el procedimiento está diseñado de tal forma que los usuarios, a partir del conocimiento del tiempo del ciclo y del conocimiento de la longitud de la ventana de tiempo de datos de proceso, calculan por sí mismos la longitud admisible de los telegramas de datos para datos útiles, especialmente también por medio del conocimiento del tiempo de emisión planificado o bien predeterminado por cada usuario en el canal adicional, entonces éstos pueden adaptar sus estructuras de emisión y de recepción, respectivamente, de una manera correspondiente por sí mismos. La administración dinámica de la anchura de banda se podría automatizar entonces en la mayor medida posible entonces y en oposición al estado de la técnica, donde todos los datos relevantes deben predeterminarse a través de parámetros del bus de campo.

También podría ser útil que los telegramas de datos estuvieran distribuidos sobre varios ciclos de transmisión. Los telegramas de datos más largos, que no se pueden alojar ya en la ventana de tiempo en virtud de la anchura de banda demasiado reducida, se transmitirían, por lo tanto, a través de varios ciclos. En virtud de los requerimientos críticos de tiempo para los datos de proceso, este método podría ser especialmente interesante sólo para los datos adicionales.

Cuando al menos un usuario funciona como usuario principal de orden superior y comunica la longitud admisible del telegrama de los datos útiles a todos los otros usuarios que funcionan como usuarios secundarios, especialmente en el marco de una inicialización del sistema y/o durante una puesta en servicio, entonces el usuario principal asume, por decirlo así, como instancia intermedia la interfaz entre usuarios subordinados y planos de usuarios de orden superior. Esta estructura jerárquica facilita, sobre todo en aplicaciones complejas, la administración y el control y posibilita una elevación de la capacidad de cálculo. Los usuarios principales y los usuarios subordinados pueden ser idénticos en cuanto a su estructura, estando configurado el usuario principal, sin embargo, como maestro de comunicación y estando conectado a capas de comunicación más elevadas. Se posibilita una inicialización a través de parámetros, que se conocen, por ejemplo, en la comunicación de datos a través de buses de campo. Se puede prever un parámetro para el comienzo temporal y otro parámetro para el final dentro de un ciclo de transmisión. Sería concebible también una modificación, en la que el maestro predetermina para ambos ciclos de transmisión la posición del canal adicional a través de una identificación. Esto sería ventajoso especialmente en sistemas de comunicación con ciclo de comunicación constantemente variable.

Si un usuario secundario recibe desde el usuario principal una autorización de emisión, especialmente para datos de proceso, entonces se pueden evitar colisiones durante el intercambio de datos de proceso y se puede conseguir una utilización óptima de la anchura de banda. Esto se realiza prácticamente de tal forma que los usuarios depositan sus datos en un telegrama preparado por el maestro y éste lee entonces de nuevo el telegrama.

Cuando cada usuario puede enviar, según sus necesidades, datos útiles también sin autorización de emisión, los usuarios ocupan de forma totalmente libre el canal adicional, que es ocupado a continuación por el usuario más rápido durante el tiempo de duración del proceso de emisión (ver arriba). Este método de la comunicación se puede realizar sin mucho gasto. La porción predominante de la comunicación será, sin embargo, en tal caso también en el canal adicional un acoplamiento de maestro/subordinado, es decir, que el control consulta a los subordinados y los subordinados contestan solamente a esta consulta. De esta manera, se controla de una forma selectiva la ocupación a través del maestro. El maestro podría asumir, además, la función de control mencionada anteriormente y puede establecer y supervisar o bien una vez o en caso necesario también con cada ciclo de transmisión el instante para el comienzo admisible de la emisión de los usuarios.

El procedimiento de acuerdo con la invención es especialmente adecuado cuando los usuarios son accionamientos digitales, controles, registradores de medición inteligentes, PCs industriales o, muy en general, aparatos electrónicos con conexión de bus, especialmente para la realización o bien la regulación de ciclos de movimiento en procesos automatizados, en el que los datos de proceso son valores teóricos y/o valores reales para posición, velocidad y aceleración. La razón de ello es que en la técnica de automatización, especialmente en conexión con la comunicación de guía y la configuración de reguladores de accionamiento por medio de sistemas de bus, como SERCOS Interface® (SERCOS-III) deben transmitirse tanto datos de proceso críticos en tiempo real como también datos adicionales con pocos requerimientos críticos de tiempo. La inicialización del sistema mencionada anteriormente se realizaría en el caso de SERCOS Interface® por medio de los parámetros S/P. El procedimiento se podría trasladar también a otros buses como PROFINET o Powerlink.

La figura 1 muestra la representación esquemática de un ciclo de transmisión 13 con tiempo de ciclo predeterminado 13a t al menos con una primera ventana de tiempo 11 y con una segunda ventana de tiempo 12 a lo largo del eje de tiempo t, en el que la primera ventana de tiempo 11 contiene datos de proceso y la segunda ventana de tiempo 12 contiene datos adicionales. Se representan también dos telegramas de datos 16, 17 dentro de la ventana de tiempo 11 para datos de proceso con campos de datos (HDR/MST) para la sincronización y administración. Además, se muestra el comienzo del tiempo de emisión 14 con el tiempo de emisión 15 restante que resulta de ello en la ventana de
tiempo 12.

A continuación, se parte de que en un bus de datos con mecanismo de transmisión de acuerdo con la invención un usuario está configurado como usuario principal y otros usuarios funcionan como usuarios secundarios con la misma autorización.

El usuario principal emite, por ejemplo, dos telegramas de usuarios 16, 17 dentro de la ventana de tiempo 11, que se designa aquí como canal de datos de proceso. En el primer telegrama de datos 16 dentro de este canal de datos de proceso 11 pueden estar contenidos, por ejemplo, valores teóricos para accionamientos digitales, en el telegrama de datos 17 están contenidos valores reales. El canal de datos de proceso 11 puede comprender, en caso necesario, todavía otros telegramas de datos 16, 17 o parejas de telegramas de datos 16, 17, por ejemplo en función del número de los usuarios para el intercambio de datos de proceso relevantes para el funcionamiento (por ejemplo, datos de la velocidad o datos de la posición). Una comunicación preferida en tiempo real en el canal de datos de proceso 11 se repite en este caso con cada ciclo 13 y los datos son actualizados también con cada ciclo 13 según las necesidades y el caso de aplicación. La posición temporal de los telegramas de datos (t0, t1) dentro del canal de datos de proceso 11 y también la estructura del telegrama o bien el significado de los contenidos de los telegramas (valores teóricos, valores reales) se mantienen en este caso, en general, constante. Por lo tanto, esta estructura se da a conocer a todos los usuarios. A través de campos de datos adicionales existiría adicionalmente la posibilidad de identificar los usuarios secundarios por el usuario principal y de establecer una comunicación selectiva con éstos. Para la coordinación se podrían asignar también al usuario que funciona como usuario principal unos derechos en los usuarios secundarios para aprovechar de una manera óptima el canal de datos de proceso 11.

Dentro de la segunda ventana de tiempo 12, se trabaja con acceso opcional, es decir, que en caso necesario un usuario puede utilizar el canal sin asignación explícita de una autorización de emisión a través del usuario principal. Aquí solamente se transmiten pocos programas de datos críticos de tiempo por medio de protocolos, por ejemplo para la configuración, administración o para fines de diagnosis.

Cuando ahora un telegrama de datos necesita para datos adicionales una duración de tiempo más prolongada para la transmisión, que la que está prevista o bien se puede realizar dentro de la ventana 12 por ciclo 13, se acorta la longitud del telegrama a través del usuario emisor, de tal forma que es posible, sin embargo, una transmisión correspondiente dentro de la duración de los periodos. El telegrama se distribuye en este caso, dado el caso, sobre varios ciclos 13. De esta manera se asegura que se pueda aprovechar totalmente todo el tiempo del ciclo 13 de, por ejemplo, 62,5 \muS, 125 \muS, 250 \muS o múltiplos de ellos. Puesto que en el canal adicional 12 en raras ocasiones se trata de informaciones críticas de tiempo, a través de esta distribución sobre varios ciclos no se produce ninguna limitación relevante. La longitud admisible del telegrama para los datos adicionales depende, por lo tanto, del tiempo del ciclo 13 y de la longitud de la ventana de tiempo 11 necesaria para el canal de datos de proceso. Naturalmente, también sería concebible una distribución de los datos en tiempo real y de los datos adicionales sobre más de dos ventanas de tiempo 11, 12. Incluso la secuencia de estas ventanas de tiempo 11, 12 podría estar seleccionada de forma opcional dentro de un ciclo de transmisión, de manera que se realiza, por ejemplo, sobre una ventana de tiempo de proceso 11 una ventana de datos adicionales 12 y a continuación sigue de nuevo una ventana de datos de proceso 11. A tal fin debe estar definida fijamente sólo cuál de las ventanas de tiempo se consulta cíclicamente y cuál acíclicamente.

El comienzo de la emisión 14 para los datos adicionales en la ventana de tiempo correspondiente 12 se puede variar dentro de esta ventana de tiempo 12, con lo que la longitud del telegrama se incrementa o se reduce en función de este instante de la emisión. Esta longitud admisible del telegrama depende de la velocidad de transmisión deseada y del tiempo restante que está disponible. Por ejemplo: longitud de la ventana de datos 11, por ejemplo 20 \muS, longitud del ciclo de transmisión 12, por ejemplo 60 \muS. La longitud para la ventana de tiempo de datos útiles es en este ejemplo 40 \muS. A partir de la velocidad de transmisión deseada, por ejemplo 100 Mbit/s, se obtiene una longitud admisible de los telegramas de datos para los datos útiles de 100 Mbit/s * 40 \muS = 400 bit = 50 byte.

Este método de transmisión es especialmente adecuado para todas las aplicaciones, en las que es necesaria una regulación de ciclos de movimiento t los datos de proceso se pueden transmitir de una manera crítica de tiempo en forma de valores teóricos y/o valores reales para posición, velocidad, aceleración, eventualmente también presión y temperatura.

Claims (15)

1. Procedimiento para la transmisión de datos entre usuarios que se comunican por medio de un bus de datos, en el que para el intercambio de telegramas de datos entre los usuarios dentro del tiempo del ciclo (13a) predeterminado para el ciclo de transmisión (13) encuentra aplicación una primera y una segunda ventana de tiempo (11, 12), en el que la primera ventana de tiempo (11) sirve para la transmisión de datos de procesos y la segunda ventana de tiempo sirve para la transmisión de datos adicionales, en el que se puede predeterminar la longitud de los telegramas de datos que representan los datos adicionales dentro de la longitud de la ventana de tiempo (12) correspondiente, caracterizado porque los usuarios calculan, de acuerdo con la invención, a partir de la diferencia entre el tiempo del ciclo (13a) y la longitud de la ventana de tiempo (11) de los datos de proceso, la longitud admisible de los telegramas de datos para datos adicionales o están previstos un parámetro para el comienzo temporal y otro parámetro para el final de los telegramas de datos, que representan los datos adicionales, dentro del ciclo de transmisión.

2. Procedimiento de acuerdo con la reivindicación 1, en el que los datos de proceso se transmiten en tiempo real periódicamente y con cada ciclo de transmisión (13).

3. Procedimiento de acuerdo con una de las reivindicaciones anteriores, en el que los datos de proceso y/o los datos adicionales están distribuidos sobre más de dos ventanas de tiempo (11, 12) de la misma y/o de diferente longitud y/o de diferente secuencia dentro de un ciclo de transmisión (13).

4. Procedimiento de acuerdo con una de las reivindicaciones anteriores, en el que el comienzo de la emisión (14) para un telegrama de los datos adicionales es variable dentro de la longitud de la ventana de tiempo (12) correspondiente.

5. Procedimiento de acuerdo con la reivindicación 4, en el que a cada telegrama dentro de la ventana de tiempo (12) correspondiente está asociado un instante fijo para el comienzo de la emisión (14).

6. Procedimiento de acuerdo con la reivindicación 5, en el que el instante para el comienzo de la emisión (14) se fija de nuevo dentro de cada ciclo de transmisión (13), especialmente por medio de un generador aleatorio específico de los usuarios o de un mecanismo de control de orden superior.

7. Procedimiento de acuerdo con una de las reivindicaciones anteriores, en el que los datos se transmiten acíclicamente en un segundo canal.

8. Procedimiento de acuerdo con una de las reivindicaciones anteriores, en el que los telegramas de datos están incorporados en protocolos.

9. Procedimiento de acuerdo con una de las reivindicaciones anteriores, en el que los usuarios calculan la longitud admisible de los telegramas de datos para datos adicionales por medio del conocimiento del tiempo de emisión predeterminable por cada usuario en un canal adicional.

10. Procedimiento de acuerdo con la reivindicación 9, en el que los usuarios adaptan dinámicamente sus estructuras de emisión y de recepción sobre la base del conocimiento de la longitud de los telegramas de datos.

11. Procedimiento de acuerdo con una de las reivindicaciones anteriores, en el que los telegramas de datos están distribuidos sobre al menos dos ciclos de transmisión (13).

12. Procedimiento de acuerdo con una de las reivindicaciones anteriores, en el que al menos un usuario funciona como usuario principal de orden superior y comunica la longitud admisible del telegrama de los datos adicionales a todos los otros usuarios que funcionan como usuarios secundarios, especialmente en el marco de una inicialización del sistema y/o en una puesta en servicio.

13. Procedimiento de acuerdo con la reivindicación 12, en el que los usuarios secundarios reciben desde el usuario principal las autorizaciones de emisión, especialmente para datos de proceso.

14. Procedimiento de acuerdo con una de las reivindicaciones anteriores, en el que cada usuario puede enviar, según las necesidades, datos útiles también sin autorización de la emisión.

15. Procedimiento de acuerdo con una de las reivindicaciones anteriores, en el que los usuarios son accionamientos y/o controles digitales, especialmente para la realización o bien la regulación de ciclos de movimiento en procesos automatizados, en el que los datos de proceso son especialmente valores teóricos y/o datos de sistemas de medición eléctricos.