ES2929124T3 - Procedimiento para la transmisión de datos a través de un bus de comunicación en serie, interfaz de bus diseñada de manera correspondiente, así como programa informático diseñado de manera correspondiente - Google Patents

Procedimiento para la transmisión de datos a través de un bus de comunicación en serie, interfaz de bus diseñada de manera correspondiente, así como programa informático diseñado de manera correspondiente Download PDF

Info

Publication number
ES2929124T3
ES2929124T3 ES19218441T ES19218441T ES2929124T3 ES 2929124 T3 ES2929124 T3 ES 2929124T3 ES 19218441 T ES19218441 T ES 19218441T ES 19218441 T ES19218441 T ES 19218441T ES 2929124 T3 ES2929124 T3 ES 2929124T3
Authority
ES
Spain
Prior art keywords
field
data
bus
bits
bit
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
ES19218441T
Other languages
English (en)
Inventor
Alexander Meier
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.)
Volkswagen AG
Original Assignee
Volkswagen 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
Application filed by Volkswagen AG filed Critical Volkswagen AG
Application granted granted Critical
Publication of ES2929124T3 publication Critical patent/ES2929124T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40006Architecture of a communication node
    • H04L12/40032Details regarding a bus interface enhancer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/407Bus networks with decentralised control
    • H04L12/413Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
    • H04L12/4135Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD] using bit-wise arbitration
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/36Handling requests for interconnection or transfer for access to common bus or bus system
    • G06F13/368Handling requests for interconnection or transfer for access to common bus or bus system with decentralised access control
    • G06F13/376Handling requests for interconnection or transfer for access to common bus or bus system with decentralised access control using a contention resolving method, e.g. collision detection, collision avoidance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/42Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4282Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/09Error detection only, e.g. using cyclic redundancy check [CRC] codes or single parity bit
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40052High-speed IEEE 1394 serial bus
    • H04L12/40084Bus arbitration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/4013Management of data rate on the bus
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40143Bus networks involving priority mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40143Bus networks involving priority mechanisms
    • H04L12/40156Bus networks involving priority mechanisms by using dedicated slots associated with a priority level
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40143Bus networks involving priority mechanisms
    • H04L12/40163Bus networks involving priority mechanisms by assigning priority to messages according to a message field
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40208Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215Controller Area Network CAN
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40267Bus for use in transportation systems
    • H04L2012/40273Bus for use in transportation systems the transportation system being a vehicle

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Small-Scale Networks (AREA)
  • Probability & Statistics with Applications (AREA)
  • Quality & Reliability (AREA)

Abstract

La invención se refiere a una extensión del protocolo de transmisión de datos CAN FD existente. El objetivo de la extensión es permitir el uso del protocolo IPv6 para el bus CAN. Para este propósito, el protocolo CAN FD se está desarrollando aún más de manera incompatible. Una medida de cambio se refiere al alargamiento del campo de datos (DF) que se coloca después de un campo de arbitraje (AF) en la trama de transmisión. Se puede ingresar cualquier número de bytes en el campo de datos extendidos (DF) dentro de un límite superior especificado. Dado que el campo de datos (DF) se transmite a una tasa de bits más alta que el campo de arbitraje (AF), el rendimiento de datos aumenta drásticamente. También se proporciona un campo final (EF) en la trama de transmisión. Se ingresa al menos un código de fin de trama en el campo de fin (EF), el código de fin de trama tiene una longitud de 11 bits (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Procedimiento para la transmisión de datos a través de un bus de comunicación en serie, interfaz de bus diseñada de manera correspondiente, así como programa informático diseñado de manera correspondiente
La invención se refiere al campo técnico de la transmisión de datos en serie entre componentes electrónicos, en particular aparatos de control, sensores y actores que están conectados a través de un sistema de bus. Tales aparatos de control se utilizan a menudo en automóviles. Los aparatos de control, sensores y actores conectados se utilizan también en otros campos de la técnica, p.ej. en la tecnología de la automatización, tecnología de procesos, etc. La invención se refiere igualmente a una interfaz de bus diseñada de manera correspondiente, así como a un programa informático diseñado de manera correspondiente.
En vehículos modernos se montan una pluralidad de aparatos de control. Solo para el tren motor se utiliza una multitud de aparatos de control, es decir, p.ej. aparato de control de motor, aparato de control de transmisión, aparato de control de ESP, aparato de control de chasis y otros. Además, también hay otros muchos aparatos de control que se montan en la zona de la carrocería de vehículo y proporcionan determinadas funciones de confort. Como ejemplos se mencionan los aparatos de control de elevadores de puertas o ventanas, aparatos de control de instalación de aire acondicionado, aparatos de control de ajuste de asiento, aparatos de control de airbag, entre otros. Hay además aparatos de control que figuran en el área del infoentretenimiento, como aparato de control de cámara para la observación del entorno, aparato de navegación, aparato de RADAR o LIDAR, módulo de comunicación y módulo de entretenimiento con TV, radio, vídeo y función de música. En particular, para el área del infoentretenimiento de la conexión interna en el vehículo de aparatos de control debe utilizarse en un futuro la comunicación IP en forma de IPv6 o IPv4. A este respecto se transmiten paquetes IP que pueden presentar una longitud de hasta 64 Kbyte. Si bien los paquetes IP pueden transmitirse segmentados, la utilización de comunicación IP requiere que se emplee una tecnología de bus que puede transmitir mensajes suficientemente grandes. A este respecto se requiere que como MTU (Máximum Transmission Unit), tal como se conocen por Ethernet, puedan transmitirse al menos paquetes con un tamaño de 1280 Byte. Sin embargo, ni el Bus CAN 2.0 clásico utilizado en el automóvil, que corresponde a Controller Area Network, ni el bus CAN FD ya ampliado, que corresponde a Controller Area Network Flexible Data Rate, cumplen con este requisito dado que transmiten mensajes con un tamaño máximo de solo 8 o 64 bytes. Esto hace que la utilización del bus CAN no sea adecuada cuando debe respaldarse la comunicación IPv6 exigida. En cuanto a otros detalles sobre el protocolo Ipv6 se remite a la especificación RFC 2460 del grupo de trabajo de ingeniería de internet IETF.
Normalmente los aparatos de control de las distintas categorías se conectan en cada caso con un bus independiente, diseñado de manera correspondiente para la categoría de aparatos. Por lo tanto, pueden utilizarse varios sistemas de bus distintos en el vehículo. Los distintos sistemas de bus pueden estar conectados entre sí a este respecto a través de puertas de enlace para permitir un intercambio de datos. En el área de los aparatos de control del tren motor se utiliza normalmente el bus CAN, también en el área de los aparatos de control de confort. En el área del infoentretenimiento también se utilizan otros sistemas de bus, como los sistemas de bus que se basan en la tecnología Ethernet, p.ej. AVB (Audio Video Bridging), que está basado en la familia de estándares según el estándar IEEE 802.1. También pueden utilizarse sistemas de bus en los que la transmisión de datos se produce a través de fibra óptica. Como ejemplos se mencionan el bus MOST (Media Oriented System Transport) o el bus D2B (Domestic Digital Bus).
Existe la posibilidad de emplear a través de CAN 2.0 o CAN FD un protocolo de transporte como ISO TP como capa intermedia para transmitir paquetes IPv6, con algunas desventajas, sin embargo.
El uso del protocolo de transporte ISO TP para la transmisión de paquetes IP tiene la desventaja esencial de que por ello se produce la necesidad de la segmentación. Esto aumenta la propensión a fallos y provoca unos gastos generales en la transmisión de los datos. Estos gastos generales se provocan por un lado debido al protocolo de transporte en sí mismo. Por otro lado, una gran parte de los gastos generales se provoca debido al protocolo CAN FD en sí mismo. Cada trama de transmisión CAN FD consta de una fase de arbitraje en la que se transmiten bits con una tasa binaria lenta y una fase de datos en la que realmente puede utilizarse la tasa binaria rápida indicada. Por consiguiente, la alta tasa binaria de la fase de datos puede utilizarse en menor medida cuanto más frecuente sea la fase de arbitraje. Esta desventaja es mucho más grave, dado que las tasas de transferencia de datos que pueden lograrse en la tecnología de bus CAN siguen siendo limitadas debido al procedimiento especial de acceso de bus.
Una ventaja esencial adicional del uso de la ISO TP es que se emplean conexiones punto a punto con control de estado según la ISO TP para la transmisión de datos. Esto prohíbe la utilización de las funcionalidades multidifusión del estándar Ipv6. Por otro lado, se pierde la propiedad positiva de que los paquetes IPv6 sean control de estado y puedan transmitirse independientemente de otros paquetes IPv6. En el uso de la ISO TP la transmisión de un paquete IPv6 depende de si el paquete anterior se ha transmitido con éxito.
Una desventaja en el uso de ISO TP para permitir la comunicación IPv6 a través de CAN FD es que mediante el principio con conexiones punto a punto con control de estado se generan tiempos de latencia muy largos durante la transmisión de datos, lo cual no es adecuado para aplicaciones en tiempo real en la que son importantes tiempos de reacción cortos. Hasta el momento, en el sector de la automoción apenas se ha utilizado comunicación IPv6 ya que esto significa un gasto de recursos elevado. El planteamiento habitual para permitir la comunicación IPv6 consiste en utilizar como tecnología de conexión la tecnología Ethernet costosa para el sector de la automoción.
Por la norma ISO 11898-1 2015-12-00 “ Road vehicles - Controller area network (CAN) - Part 1: Data link layer and physical signalling” se conoce una trama de transmisión con un campo de arbitraje y un campo de datos en la que para la fase de arbitraje se regula una tasa binaria baja, y para la transmisión de los datos en el campo de datos se regula una tasa binaria alta. El número de los bytes de datos está establecido para marcos de transmisión clásicos con 8 bytes como máximo. Están permitidos todos los valores intermedios. Para marcos de transmisión FD se permiten 64 bytes como máximo en el campo de datos. En este caso también son posibles valores de 12, 16, 20, 24, 32, o 48 bytes de datos.
Por el documento DE 102011 006884 A1 se conoce un procedimiento y un dispositivo para aumentar la capacidad de transmisión de datos en un sistema de bus en serie. También este documento muestra el uso de una trama de transmisión con un campo de arbitraje y un campo de datos en el que para la fase de arbitraje se regula una tasa binaria baja, y para la transmisión de los datos en el campo de datos se regula una tasa binaria elevada.
Por el documento DE 10 2011 122 843 A1 se conoce un procedimiento y un dispositivo de control para la transmisión de datos en serie con tamaño de mensajes flexible y longitud de bit variable.
Por del documento DE 11 2015 004473 T5 se conoce un protocolo de transmisión de datos de alta velocidad para fines de control.
Por el documento WO 2015 139 892 A1 se conoce una propuesta para un formato de transmisión de bus CAN ampliado en el que también puede transmitirse una exigencia de diagnóstico UDS sin segmentación en una trama de datos ampliada con 4096 bytes de longitud.
Por el documento US 2016 094 312 A1 se conoce una propuesta para la ampliación del formato de transmisión clásico bus CAN en el que la ampliación se refiere a la extensión del campo de datos a 64 bytes de longitud.
La invención se impone como meta evitar las desventajas descritas en la introducción de la comunicación IP en el sector de la automoción.
Este objetivo se resuelve mediante un procedimiento para la transmisión de datos a través de un bus de comunicación en serie, una interfaz de bus diseñada en correspondencia, así como un programa informático diseñado de manera correspondiente.
Las reivindicaciones dependientes contienen perfeccionamientos ventajosos y mejoras de la invención en correspondencia con la descripción siguiente de estas medidas.
Para resolver el objetivo se sigue el planteamiento de perfeccionar el protocolo CAN predominante en el sector de la automoción incompatible en sí para hacerlo apropiado para la comunicación IP. A este respecto, en lo sucesivo, el protocolo CAN ampliado propuesto como nuevo en este caso se denomina brevemente protocolo CAN EL.
La primera medida con la que se perfecciona el protocolo CAN FD existente consiste en un procedimiento para la transmisión de datos a través de un bus de comunicación en serie en el que los datos se transmiten con una trama de transmisión, en donde la trama de transmisión presenta al menos un campo de arbitraje y un campo de datos de modo que la longitud del campo de datos se amplía drásticamente en la trama de transmisión. A este respecto el campo de arbitraje sirve para regular el acceso de bus según el procedimiento CSMA-CR, que corresponde a Carrier Sense Multiple Access with Collision Resolution (acceso múltiple por detección de portadora con detección de colisiones) mediante la priorización de los mensajes con ayuda de un identificador. Como en el bus CAN FD, para la fase de arbitraje se regula una tasa binaria baja y para la transmisión de los datos en el campo de datos se regula una tasa binaria elevada. Mediante la prolongación del campo de datos útiles se evita la desventaja de que en el bus CAN FD, debido a la limitación establecida en él de la longitud del campo de datos útiles a como máximo 64 bytes, apenas se aprovecha la ventaja de la tasa binaria más alta en el caso del bus CAN EL ampliado propuesto en este caso. La medida ofrece la ventaja de una tasa binaria/ancho de banda claramente aumentados en la transmisión de datos. Esto significa también una eficiencia significativamente mejorada en la transmisión de grandes paquetes de datos. Al mismo tiempo se elimina la limitación presente en el bus CAN FD de que dentro del campo de datos útiles con tamaño máximo de 64 bytes solo son posibles determinados números de bytes. Por ello las posibilidades de utilización son aún más flexibles.
Adicionalmente, en la trama de transmisión se prevé un campo de fin y en el campo de fin se introduce al menos un código de fin de trama, en donde el código de fin de trama presenta una longitud de 11 bits.
Esta medida es ventajosa por regla general en el caso de un relleno de bits modificado. Mediante la emisión de códigos de fin de trama se fuerza una infracción de una regla de relleno de bits nueva de modo que los abonados que no estaban sincronizados correctamente identifican este hecho y pueden reiniciar el controlador CAN para sincronizarse de nuevo correctamente.
La variabilidad de la longitud del campo de datos útiles garantiza muchas posibilidades de utilización. Así no es necesario llegar a un compromiso cuando en función del caso de aplicación es importante una tasa neta de transferencia de datos o en otro caso es prioritaria la capacidad de tiempo real e importa más que los tiempos de latencia sean reducidos.
A este respecto es especialmente ventajosos cuando para la longitud variable del campo de datos se especifica un intervalo de 0 a 4096 bytes. Esto permite una buena interoperabilidad con la variante Ethernet de 1 Gbit empleada actualmente con frecuencia. Un enrutamiento entre una parte de la red de automóvil, donde se utiliza la variante de bus Ethernet de 1 GBit, sería posible sin segmentación. Esto hace posible sin problemas la utilización de la comunicación IP.
Asimismo, es ventajoso cuando la longitud del campo de arbitraje se establece en 32 bits.
En el estándar CAN FD se ha establecido una longitud de 29 bits para este campo. Esta medida simplifica el desarrollo de hardware para el bus CAN EL ampliado. Las longitudes de registro disponibles hoy en día son normalmente un múltiplo de un byte, es decir, un múltiplo de 8 bits.
Además, es ventajoso cuando en el protocolo CAN FD en la trama de transmisión se prevé un campo de control entre campo de arbitraje y campo de datos en el que al menos se prevé una sección para la indicación de longitud con respecto al campo de datos. En este caso es necesaria una prolongación de esta sección con el fin de indicar toda la longitud de 4096 bytes. Para ello son necesarios 13 bits.
Como en el protocolo CAN 2.0 y protocolo CAN FD es ventajoso cuando en la trama de transmisión se prevé un campo CRC en el que se prevé al menos una sección para un código de verificación CRC. El código de verificación sirve para la detección de errores según el algoritmo de verificación de redundancia cíclica conocido.
A este respecto, como en el protocolo CAN FD, es ventajoso cuando en la trama de transmisión se prevé un campo de inicio y el código de verificación se calcula a través de los campos campo de inicio, campo de arbitraje, campo de control y campo de datos.
Lo mismo sucede con la utilización del procedimiento de relleno de bits que, asimismo, ya se puede utilizar en el protocolo CAN 2.0 y el protocolo CAN FD. En este caso es ventajoso que la transmisión de los datos se realice de manera asíncrona y para garantizar el sincronismo de estación de emisión de datos y estación de recepción de datos se lleve a cabo una resincronización después de un relleno de bits, en donde la regla de relleno de bits se aplica a lo largo de las áreas desde el campo de inicio hasta el final del campo de datos, en donde el número de los bits de relleno insertados para el control se introduce en una sección del campo CRC. Mediante la inserción de un bit de relleno se fuerza un cambio de flanco en el bus que en el controlador CAN sirve para la resincronización del generador de ciclos que especifica el ciclo de muestreo para la recuperación de bits en la recepción de datos. A este respecto se utiliza una regla de relleno de bits modificada. El algoritmo de relleno de bits (codificación de trama) se modifica para el nuevo formato de transmisión en el sentido de que un bit de relleno no se inserta como en CAN 2.0 y CAN FD después de 5 sino solo después de 10 bits directamente consecutivos con el mismo nivel de bus. Por ello se necesitan menos bits suplementarios (“ overhead’) en la trama de datos y por ello aumenta la eficiencia de la transmisión de datos.
En el campo CRC la regla de relleno de bits según el protocolo ampliado no se utiliza. Por ello, adicionalmente, es ventajoso cuando en el campo CRC en posiciones predeterminadas de manera fija se inserta forzosamente un bit de relleno. Así también en el campo CRC se garantizan cambios de flanco y los controladores CAN de los abonados de bus permanecen sincronizados.
En un ejemplo preferido el campo CRC comienza con un bit de relleno predeterminado de manera fija y los bits de relleno adicionales predeterminados de manera fija se introducen a una distancia de 9 Bits en cada caso del campo CRC. El bit de relleno predeterminado de manera fija es complementario a este respecto a su bit precursor.
Una medida especialmente ventajosa se refiere a la concesión de los identificadores en el campo de arbitraje para priorizar los mensajes. Por lo tanto, el identificador en el campo de arbitraje se divide en las áreas de identificador de “contenido de mensaje” e identificador de “ aparatos” . Mediante la concesión correspondiente de los aparatos ID a un abonado de bus puede concedérsele la prioridad frente a otros abonados de bus. Por ello el comportamiento de red se puede planear/predecir y por tanto puede reaccionar en tiempo real. La condición límite es que a cada aparato se asocie un identificador de aparatos unívoco.
A este respecto es ventajoso cuando la sección con los bits de mayor valor para la priorización del contenido de mensaje se reserve y se prevea la sección con los bits de menor valor para la identificación de aparatos. Por ello el acceso de bus, como en el bus CAN, durante la fase de arbitraje decide principalmente sobre los contenidos de mensaje provistos con distinta prioridad y solo en segunda línea sobre los aparatos ID.
En una variante ventajosa un identificador de 32 bits de longitud se divide de modo que se reservan 24 bits para la priorización del contenido de mensaje y se prevén 8 bits para la priorización del aparato.
Como resumen, mediante las medidas presentadas, el protocolo CAN-FD se amplía ventajosamente de modo que pueden mantenerse los bajos costes de hardware, como se dan en el bus CAN-FD. También se mantiene el procedimiento de arbitraje descentralizado tan esencial para el sector de la automoción. Esto es ventajoso para el desarrollo adicional de la automoción, dado que en esta área no son necesarias especificaciones nuevas que afectan a todos los fabricantes. Mediante el mantenimiento del arbitraje descentralizado y el diseño especial del campo de arbitraje, el bus CAN EL ampliado sigue conservando su capacidad de tiempo real, lo cual es muy importante para la utilización en el automóvil.
Mediante la variabilidad integrada en la especificación del protocolo de bus CAN EL ampliado el protocolo de bus es capaz de adaptarse a la arquitectura de bus concreta. En función del tamaño de red planificado la tasa binaria puede adaptarse para poder poner en práctica así una arquitectura óptima en términos de costes. Por ejemplo, el bus ampliado puede cubrir incluso el caso especial de una red pequeña con solo 2 abonados (comunicación punto a punto). A este respecto la transmisión de datos podría realizarse con tasa binaria muy alta.
Para una interfaz de bus diseñada en correspondencia para el uso en el procedimiento propuesto para la transmisión de datos a través de un bus de comunicación en serie se aplican las ventajas correspondientes como se explica en relación con las etapas de procedimiento correspondientes.
Lo mismo sucede para un programa informático diseñado de tal manera que lleva a cabo las etapas del lado de emisión y/o las etapas del lado de recepción del procedimiento propuesto para la transmisión de datos en el procesamiento en una unidad de computación. En realidad, en el sector de la automoción los costes en el hardware desempeñan un papel central de modo que en este caso se utilizan controladores principalmente menos potentes asistidos por controladores CAN independientes en los cuales el protocolo de transmisión de datos se realiza mediante hardware especial. En otras áreas, p.ej. en el área de bus de campo para la tecnología de la automatización o la tecnología de procesos, también se utilizan microcontroladores más potentes para los cuales también se tiene en cuenta la solución de software para la implementación del protocolo de transmisión de datos ampliado.
Un ejemplo de realización de la invención está representado en los dibujos y se explica con más detalle a continuación mediante las figuras.
Estas ilustran:
Figura 1 el principio de la conexión de componentes electrónicos mediante bus CAN;
Figura 2 un diagrama de bloques para una red de a bordo de vehículo con aparatos de control de distinta categoría;
Figura 3 el formato de trama de transmisión detallado según un ejemplo de realización de la invención;
Figura 4 el resultado del cálculo de la tasa neta de transferencia de datos para la transmisión de datos en paquetes de distinta longitud según el formato de trama de transmisión propuesto;
Figura 5 el resultado del cálculo de la eficiencia para la transmisión de datos en paquetes de distinta longitud según el formato de trama de transmisión propuesto; y
Figura 6 un ejemplo del desarrollo de la fase de arbitraje, cuando dos nodos CAN acceden al bus simultáneamente.
La presente descripción ilustra los principios de la divulgación según la invención.
El bus CAN ya está estandarizado desde 1994. La norma ISO correspondiente tiene el número ISO 11898. Hay una norma para el área de alta velocidad de hasta 1 Mbit/s, que es la norma ISO 11898-2. Hay también una norma para el intervalo de baja velocidad de hasta 125 kBit/s; la norma ISO 11898-3. El aumento de la cantidad de datos produce cargas de bus cada vez mayores en los buses CAN. Esto lleva a un perfeccionamiento del bus CAN. El bus CAN ampliado se conoce por el término bus CAN FD. FD significa a este respecto Flexible Data Fíate (tasa binaria flexible). En esta variante de bus CAN se cambia la tasa binaria. Para la fase de arbitraje la tasa binaria sigue siendo baja, como en el bus CAN clásico. Para la transmisión de los datos útiles se cambia a una tasa binaria más alta. Si se transmite los datos útiles de un mensaje CAN-FD de manera más rápida, entonces se acorta la duración de la ocupación de bus; y la carga de bus se reduce. Si la duración de transmisión permanece en la misma trama como en los mensajes CAN clásicos, podrían transportarse cantidades de datos mayores con un mensaje CAN-FD. Así se ha realizado también en el caso de CAN FD.
En lugar del campo de datos útiles de 8 bytes de longitud, en un CAN FD se utiliza un campo de datos útiles de 64 bytes de longitud. La tasa binaria aumenta para la transmisión del campo de datos útiles en una conversión de, p.ej., 500 kbit/s a 2 Mbit/s.
De manera análoga al protocolo CAN clásico, p.ej. también el bus CAN FD conoce dos formatos de trama de datos: tramas estándar con identificadores de 11 bits y tramas extendidas con identificadores de 29 bits. Esto garantiza que puedan seguir existiendo protocoles adicionales como CANopen y SAE J1939 con adaptaciones correspondientes también bajo CAN FD y pueden aprovecharse las ventajas descritas.
Para CAN FD se ha renunciado a la introducción de un formato propio para tramas remotas. Sin embargo, en una observación más detenida, esto no es ninguna limitación. Debido a la ausencia de campo de datos un aumento de la tasa binaria sería ineficaz. No obstante, el protocolo CAN-FD permite exigir tramas de datos CAN FD con tramas remotas CAN.
La Figura 1 muestra el principio de la conexión de componentes electrónicos mediante bus CAN. Una red CAN es un sistema combinado formado por nodos CAN (componentes electrónicos (aparatos de control, sensores, actores) con interfaz CAN), que intercambian datos entre sí a través de sus interfaces CAN respectivas y un medio de transmisión (bus CAN) que conecta todas las interfaces CAN. Se representan tres nodos CAN 10. La estructura de bus del bus CAN es lineal. Por lo tanto, hay una línea de bus 15 a la que están conectados los tres nodos CAN 10. Como línea de bus 15 se utiliza en los casos de uso más frecuentes un cable no blindado de pares trenzados (Unshielded Twisted Pair - UTP), a través del cual se realiza una transmisión de señales simétrica. En la transmisión de señales simétrica las señales se transmiten como diferencias de tensión a través de dos líneas. El par de líneas se compone a este respecto de una CANH no invertida y una línea de señal CANL invertida. A partir de la diferencia de las señales que se aplican en estos dos hilos metálicos los receptores reconstruyen la señal de datos original. Esto tiene la ventaja de que mediante sustracción se eliminan interferencias en modo común que aparecen en los dos hilos metálicos de la línea de bus 15 y de este modo no influyen tanto en la transmisión.
Para evitar reflexiones de señal la línea de bus 15 en ambos extremos de línea está terminada con una resistencia terminal 13 del tamaño de la impedancia de onda característica de la línea de bus (120 Ohm).
Una interfaz CAN se compone de dos partes: el software de comunicación y el hardware de comunicación. Mientras que el software de comunicación comprende servicios de comunicación superiores, las funciones de comunicación básicas están implementadas normalmente en hardware: En este caso se diferencian dos componentes de hardware: El controlador CAN 14 proporciona un desarrollo unitario del protocolo de comunicación CAN, y esto reduce la caga del ordenador principal 16 en el que se ejecuta el software de comunicación ya mencionado. El transceptor CAN 12 proporciona el acoplamiento del controlador CAN 14 al bus CAN 15. Forma las señales para la transmisión de datos en el proceso de emisión y realiza el procesamiento de señales en caso de recepción. Esta estructura básica tampoco cambia nada cuando se utiliza el protocolo de bus CAN FD.
La Figura 2 muestra la estructura típica de una red de a bordo de un automóvil moderno. Con la referencia 151 se designa un aparato de control de motor. La referencia 152 corresponde a un aparato de control ESP y la referencia 153 designa un aparato de control de transmisión. En el automóvil puede haber presentes otros aparatos de control, como un aparato de control de dinámica de conducción, etc. La conexión de tales aparatos de control que se incluyen en su totalidad en la categoría del tren motor se produce normalmente con el sistema 104 de bus CAN de alta velocidad (Controller Area Network). Dado que se instalan distintos sensores en el automóvil y estos ya no se conectan solo a aparatos de control individuales, tales datos de sensor se transmiten asimismo a través del sistema de bus 104 a los aparatos de control individuales. Ejemplos de sensores en el automóvil son sensores de sensores de velocidad de ruedas, sensores de ángulo de dirección, sensores de aceleración, sensores de velocidad de giro, sensores de presión de ruedas, sensores de distancia, sensores de picado, sensores de contaminación del aire, etc. Los distintos sensores con los que está equipado el vehículo están designados en la figura 2 con la referencia 161, 162, 163. Con frecuencia se utiliza también otro bus CAN 106 adicional en el vehículo a través del cual se conectan principalmente componentes de confort. Estos son, p.ej., aparatos 134 de control de puerta, un aparato 133 de control de cuadro de instrumentos, un control 132 de instalación de aire acondicionado, un aparato 131 de control de palanca selectora y otros. Para tales componentes habitualmente es suficiente la variante del bus CAN de baja velocidad.
El automóvil moderno puede presentar sin embargo otros componentes adicionales como cámaras de vídeo 105, p.ej. como cámara de visión trasera o como cámara de monitorización al conductor, como también un aparato de LIDAR o RADAR para la realización de un regulador automático de velocidad por radar o para la realización de un aparato de advertencia de distancia o de advertencia de colisión.
Entre estos, con frecuencia se distingue un sistema de navegación 120 que igualmente se monta en la zona de la cabina. La ruta que se indica en un mapa puede representarse naturalmente también en la pantalla en la cabina. Otros componentes como un equipo de manos libres pueden estar presentes, pero no están representados en detalle. La referencia 110 designa también una unidad de a bordo. Esta unidad de a bordo 110 corresponde a un módulo de comunicación a través del cual el vehículo puede recibir y enviar datos móviles. Normalmente en este caso se trata de un módulo de comunicación de telefonía móvil, p.ej. según el estándar LTE. Todos estos aparatos se asocian al área del infoentretenimiento. Por lo tanto se conectan a través de un sistema 102 de bus diseñado según las necesidades especiales de esta categoría de aparatos. Este sistema de bus está diseñado según el estándar bus CAN EL ampliado propuesto en este caso. Como ejemplo adicional se muestra también un bus CAN 108 que solo conecta los dos componentes aparato 171 de control de asistencia al conductor y aparato de RADAR 172. Para este bus CAN se utiliza asimismo el bus CAN-EL ampliado. Esto muestra la amplia área de utilización del bus CAN-EL ampliado. Un sensor de RADAR o LIDAR o un número de cámaras y/o sensores de ultrasonido puede provocar ya una cantidad elevada de datos. Estos requisitos pueden cumplirse con el bus CAN EL como ya se ha descrito.
Con el fin de transmitir datos de sensor relevantes del vehículo a través de la interfaz de comunicación 110 a otro vehículo o a un ordenador central está prevista la puerta 140 de enlace. Esta está conectada con los dos sistemas 102 y 104 de bus diferentes. La puerta 140 de enlace está diseñada para convertir los datos que recibe a través del bus CAN 104 de modo que se convierten en el formato de transmisión del bus 102 de infoentretenimiento para que puedan distribuirse en los paquetes allí especificados. Para transmitir estos datos hacia el exterior, es decir, a otro automóvil o a un ordenador central, la unidad 110 de a bordo está equipada con la interfaz de comunicación para recibir estos paquetes de datos y, a su vez, convertirlos al formato de transmisión del estándar de telefonía móvil utilizado de manera correspondiente. Tal como se representa, la puerta 140 de enlace está conectada como aparato central tanto al Bus CAN 104 de alta velocidad como al bus CAN 106 de baja velocidad como también al bus CAN EL 102 y 108. Por lo tanto se encarga de todas las conversiones de formato necesarias cuando deben intercambiarse datos entre los distintos sistemas de bus.
La Figura 3 muestra el nuevo formato de trama de transmisión según el estándar CAN EL Bus. La propuesta se basa en la estructura de mensajes de las tramas MAC tal como se describe en la especificación ISO 11898-1 de 2015, en el capítulo 10.4. A este respecto se mantiene la funcionalidad y el significado de los campos individuales si en este caso no se tratan explícitamente modificaciones.
Existen muchos bits diferentes individuales en la trama de transmisión según la ISO 11898-1 que cumplen con los fines de control. Como preparación, en la siguiente tabla aparece una lista de los distintos bits de control con su nombre en inglés. En la siguiente mención de estos bits ya no se repite el nombre detallado.
Figure imgf000007_0001
La representación está seleccionada a este respecto de modo que los bits individuales por cada campo de la trama de transmisión están indicados en cada caso en una línea. Los campos campo de control, campo de datos y campo CRC se transmiten con tasa de transmisión de datos elevada. La tasa de transmisión de datos elevada se sitúa entre 2000 KBit/s y 12000 KBit/s. El incremento para el ajuste de la tasa de transmisión de datos asciende a 1000 KBit/s. Para las otras partes de la trama de transmisión, concretamente “campo de inicio” , “campo de arbitraje” y “campo final” sigue aplicándose la tasa de transmisión de datos baja que también se utiliza en el bus CAN Fd, es decir, la tasa de transmisión de datos puede situarse entre 500 KBit/s y 1500 KBit/s. El incremento para el ajuste de la tasa de transmisión de datos asciende en este caso a 250 KBit/s.
Al contrario que en la especificación mencionada se respalda de nuevo solo un formato de trama de transmisión. El nuevo formato de trama de transmisión se basa en el formato FEFF (“ FD Extended Frame Formar).
El campo de inicio SF con el bit SOF permanece invariable.
Después del campo de inicio SF, el bit de extensión0 y el bit de extensión1, que están reservados para futuras ampliaciones, se insertan en el campo de arbitraje AF. Estos bits no están presentes en el formato FEFF. Los bits de extensión0 y extensión1 se transmiten ambos con nivel de bus “ recesivo” .
La sección para el identificador en el campo de arbitraje AF se amplía a 32 Bit. Los 32 bits de la sección de identificador se transmiten de una sola vez y ya no en 2 secciones distintas como en el caso del CAN FD. Por consiguiente, se omiten también los bits SRR, RTR, RRS y IDE previstos de otro modo para el control de formato de la trama de transmisión.
En el campo de control CF la sección para la indicación de longitud del campo de datos se amplía a una longitud de 13 bits. En los bits DL0 a DL12 se indica la longitud del campo de datos útiles en el número de bytes. Con ello el valor numérico en esta sección indica exactamente el número de bytes en el campo de datos útiles. Con 13 bits puede codificarse el número máximo de 8192 bytes. Pero también puede codificarse con ello también cualquier otro número entero en el intervalo. La longitud del campo de datos debe comprender hasta 4096 bytes para que un paquete de Ethernet correspondiente pueda encontrar sitio en este. El área del campo de control con la indicación de longitud para el campo de datos d F puede indicar más bytes con 13 bits, se limita sin embargo estableciéndolo a 4096 bytes.
Por lo tanto, en el campo de datos DF prolongado puede anotarse un número de bytes discrecional dentro del límite superior establecido de 4096.
Los bits de control FDF, BRS y el bit reservado res y campo de control CF y campo de datos DF se omiten. Solo el bit ESI se mantiene en esta posición como bit de control.
El campo de datos DF en sí mismo puede presentar longitud variable. En este caso, en función de lo que se ajuste hasta 4096 bytes como máximo, lo que corresponde a una longitud de 32768 bits.
El campo CRC CF en el que se anota el código de verificación se amplía a una longitud CRC de 32 bits. El código de verificación se anota en los campos de bit CRC0 a CRC31.
Para el cálculo del código de verificación CRC se emplea el polinomio G(x) = x32 x26 x23 x22 x16 x12 x11 x10 x8 x7 x5 x4 x2 x 1.
A este respecto, el polinomio seleccionado corresponde al polinomio que se emplea en la especificación IEEE 802.3 para Ethernet.
La suma de verificación CRC puede calcularse desde el bit SOF hasta el último bit del contador de bits de relleno (Stuff0).
La longitud de la sección recuento de relleno (Stuff Count) en el campo CF CRC se modifica a 12 bits y afecta a los bits Stuff0 a Stuff11. En la sección recuento de relleno se anota el número de los bits de relleno insertados en la zona del bit SOF hasta el último bit del campo de datos DF. A este respecto se codifica de manera binaria el número de los bits de relleno. No obstante, la utilización del relleno de bits se simplifica con respecto al relleno de bits utilizado en el estándar CAN-FD. También en este punto el bus CAN-EL se ha optimizado con respecto al bus CAN-FD, como se describe a continuación en detalle.
La inserción de bits de relleno sirve para la sincronización en el caso de una transmisión de datos asíncrona. Para producir el sincronismo de los interlocutores sirve el flanco de señal del bit de inicio SOF de un mensaje CAN, que pasa de recesivo a dominante. Un mecanismo de resincronización a continuación del bit SOF proporciona el mantenimiento del sincronismo. El mecanismo de resincronización se basa en la valoración de flancos de señal que pasan de recesivo a dominante. Para que se mantenga la sincronización en este caso en el estándar CAN se inserta el mecanismo de relleno de bits. En la norma ISO 11898-1 se especifica que como muy tarde después de cinco bits homogéneos debe transmitirse un bit complementario, también, si después de cinco bits homogéneos siguiera un bit complementario de todas maneras. El receptor conoce la posición de los bits de relleno debido a la regla y puede ignorar los bits de relleno.
El algoritmo de relleno de bits (codificación de trama) se modifica para el nuevo formato de transmisión en el sentido de que un bit de relleno no se inserta después de 5 sino solo después de 10 bits directamente consecutivos con el mismo nivel de bus. Por ello se necesitan menos bits suplementarios en la trama de datos y por ello aumenta la eficiencia de la transmisión de datos.
El relleno de bits variable debe realizarse solo para los bits desde el SOF hasta el último bit del campo de datos DF. Desde el campo CF CRC se emplean bits de relleno predefinidos (FixedStuffx). Los bits de relleno predefinidos se insertan siempre después de 9 bits.
Son los bits FixedStuff0, FixedStuff1, FixedStuff2, FixedStuff3, FixedStuff4 y FixedStuff5. Los bits de relleno individuales en el campo CRC deben transmitirse en cada caso con el nivel opuesto del bit transmitido directamente antes.
Estos bits de relleno especificados de manera fija FixedStuff0, FixedStuff1, FixedStuff2, FixedStuff3, FixedStuff4 y FixedStuff5 provocan un cambio de flanco garantizado en la transmisión en el lugar deseado.
El bit FixedStuff0 se transmite entre el último bit de datos y el bit Stuff11.
El bit FixedStuff1 se transmite entre el bit Stuff3 y el bit Stuff2.
El bit FixedStuff2 se transmite entre el bit CRC26 y el bit CRC25.
El bit FixedStuff3 se transmite entre el bit CRC17 y el bit CRC16.
El bit FixedStuff4 se transmite entre el bit CRC8 y el bit CRC7.
El bit FixedStuff5 se transmite entre el bit CRC0 y el bit CRCDel.
El bit CRCDel que desempeña la función de un delimitador CRC permanece invariable y tiene la misma función que en el estándar CAN FD.
En el campo final EF ambos bits ACK y ACKDel permanecen invariables.
En el campo final EF la sección con la identificación EOF se amplía a 11 bits. Por lo tanto, en este caso, en lugar de los 7 bits recesivos habituales consecutivos en el bus CAN se transmiten 11 bits recesivos. La prolongación del símbolo EOF se debe a la modificación del algoritmo de relleno. Solo después de los 11 bits consecutivos del mismo nivel de bus se infringe la nueva regla de relleno. lo que se aprovecha en este caso.
En el bus CAN y bus CAN FD entre dos tramas de datos transmitidas se inserta un denominado campo de intermedio. En este caso se transmiten de nuevo 3 bits IFS2 a IFS0 recesivos consecutivos. Por esto los controladores CAN identifican que el bus se ha liberado. Esta regla se mantiene también en el formato de transmisión CAN EL.
Como se ha descrito se utilizan 2 tasas binarias distintas para la transmisión de los bits en la trama de transmisión. La posición de conmutación exacta se indica en la Figura 3 mediante la referencia BRSP.
La tasa binaria más lenta se denomina tasa binaria lenta.
La tasa binaria más rápida se denomina tasa binaria rápida.
Para la tasa binaria lenta se establece un intervalo entre 500 KBit/s y 1500 KBit/s. A este respecto se soportan todas las tasas binarias en pasos de 250 KBit/s.
Para la tasa binaria rápida se establece un intervalo entre 2000 KBit/s y 12000 KBit/s. A este respecto deben soportarse todas las tasas binarias en pasos de 1000 KBit/s.
Las tasas binarias más altas para la tasa binaria lenta y la tasa binaria rápida pueden soportarse opcionalmente. Un cálculo a modo de ejemplo de las tasas netas de transferencia de datos resultantes se muestra en la Figura 4. En esta, a lo largo de la abscisa se traza el número de los bytes de datos útiles transmitidos en la trama de transmisión hasta la longitud de paquete completa con 4096 bytes de datos útiles. A lo largo de la ordenada se traza la tasa neta de transferencia de datos resultante. No obstante, para el cálculo no se han tenido en cuenta los bits de relleno. Para la curva inferior A se cumple que como tasa binaria lenta se reguló 500 Kbit/s, y como tasa binaria rápida 4 MBit/s. Para la curva superior B se cumple que como tasa binaria lenta se reguló 1000 Kbit/s y como tasa binaria rápida 10 MBit/s. En la Figura 5 se representa el resultado de un cálculo a modo de ejemplo de la eficiencia de transmisión de datos. En esta, a lo largo de la abscisa se traza el número de los bytes de datos útiles transmitidos en la trama de transmisión hasta la longitud de paquete completa con 4096 bytes de datos útiles. A lo largo de la ordenada se traza la eficiencia resultante indicada en porcentajes. No obstante, para el cálculo no se han tenido en cuenta los bits de relleno. Para la curva superior C se cumple que como tasa binaria lenta se reguló 500 Kbit/s y como tasa binaria rápida 4 MBit/s. Para la curva inferior D se cumple que como tasa binaria lenta se reguló 1000 Kbit/s y como tasa binaria rápida 10 MBit/s.
El establecimiento de los identificadores para los mensajes CAN no está sometido en principio a ninguna limitación. Teniendo en cuenta la meta de optimizar el bus CAN para la transmisión de paquetes IP es útil aplicar unas directrices de concesión relativas a la concesión de ID. El seguimiento de las directrices de concesión es ventajoso en particular para el área de la comunicación IP.
Como en el bus CAN y CAN FD se emplea el identificador para realizar un concepto de priorización. Mediante el identificador se decide el nodo CAN que se impone en el bus. El procedimiento de acceso de bus corresponde al procedimiento CSMA-CR (Carrier Sense Múltiple Access with Collision Resolution, acceso múltiple por detección de portadora con resolución de colisiones). El procedimiento CSMA/CR garantiza que los nodos CAN dispuestos para la emisión solo accedan al bus CAN cuando esté libre. En accesos de bus simultáneos, el método del arbitraje de buses con bits en el que se basa el procedimiento CSMA/CR garantiza que siempre se imponga el nodo CAN con el mensaje CAN de prioridad más alta. En principio se aplica que cuanto más alta sea la prioridad del mensaje CAN antes puede transmitirse al bus CAN. Los mensajes CAN de prioridad más baja en caso de un diseño de sistema desfavorable incluso corren el peligro de no transmitirse. Por lo tanto la concesión de las ID es muy importante para la realización de un intercambio de datos determinístico.
Según el nuevo concepto los 32 bits del identificación se dividen en dos áreas [contenido de mensaje] y [aparato].
El área [contenido de mensaje] comprende los bits de mayor valor del identificador.
El área [aparato] comprende los bits de menor valor del identificador.
El tamaño de las áreas individuales puede seleccionarse según la necesidad, pero debe ser igual para todos los abonados dentro de una red CAN. En una forma de realización ventajosa se reservan 24 bits para el área [contenido de mensaje] y 8 bits para el área [aparato]. Con ello es posible efectuar una diferenciación precisa en cuanto a la prioridad de mensajes en la red. Si dos abonados quisieran enviar al mismo tiempo un mensaje con la misma prioridad, en el área [aparato] se decide qué abonado obtiene la prioridad.
Un número binario bajo en el área [contenido de mensaje] o [aparato] corresponde a una prioridad en realidad más alta. En el bus CAN en la fase de arbitraje se impone siempre el nivel de bus dominante. Un nodo CAN que identifica que él mismo ha enviado solo el nivel de bus recesivo pero identifica que se aplica el nivel dominante renuncia en el arbitraje.
Mediante la concesión correspondiente del dispositivo ID a un abonado de bus puede concedérsele la prioridad frente a otros abonados de bus. Por ello el comportamiento de red puede predecirse y por tanto puede reaccionar en tiempo real.
La Figura 6 ilustra el proceso del arbitraje:
En la parte superior de la representación las posiciones de bit individuales del campo de arbitraje AF están numeradas de 0 a 31. En el área [contenido de mensaje] para cada bit también se indica qué prioridad está asociada a cada posición de bit. A la posición de bit ID8 en el área [contenido de mensaje] le corresponde la prioridad más baja Priority0 y a la posición de bit ID31 por consiguiente le corresponde la prioridad más alta Priority23 en el área [contenido de mensaje]. Asimismo, el bit con el número ID0 en el área [aparato] tiene la prioridad más baja, y el bit con el número ID7 entonces la prioridad más alta.
En la zona central de la Figura 6 se representa un proceso de arbitraje donde dos aparatos de control St. A y St. B compiten por el bus. Al aparato de control St.A se ha asignado el dispositivo ID 00000010b y al aparato de control St.B se ha asignado el dispositivo ID 00000011b. En este caso se decide la concesión de bus en el área [contenido de mensaje]. En el caso representado gana el abonado St. B porque en el bit ID9 ha anotado “ 0” y el abonado St. A ha anotado allí un “ 1” . Un “ 0” anotado corresponde en el bus CAN al nivel de bus dominante.
En la zona inferior de la Figura 6 se representa un proceso de arbitraje donde de nuevo los dos aparatos de control St. A y St. B compiten por el bus. En el área [contenido de mensaje] ambos abonados envían el mismo mensaje CAN, en este caso en el área [contenido de mensaje] se emite la misma ID. Por ello la concesión de bus se decide en este caso primero en el área [aparato].
En el caso representado gana el abonado St. A porque en el último bit con el número ID0 ha anotado “ 0” y el abonado St. B ha anotado allí un “ 1 ” .
La divulgación no está limitada a los ejemplos de realización representados en este documento. Tienen cabida distintas adaptaciones y modificaciones que el experto consideraría gracias a su conocimiento especializado y que pertenecen también a la divulgación.
Todos los ejemplos mencionados en la presente memoria como también las formulaciones condicionales han den entenderse sin limitación a tales ejemplos citados especialmente. Así, por ejemplo, los expertos admiten que el diagrama de bloques representado en este caso representa una perspectiva conceptual de una disposición de circuito.
Debería entenderse que el procedimiento propuesto y los dispositivos correspondientes pueden implementarse en distintas formas de hardware, software, firmware, procesadores especiales o una combinación de estos. Los procesadores especiales pueden comprender circuitos integrados de aplicación específica (ASICs), computadora con conjunto de instrucciones reducido (Reduced Instruction Set Computer RISC) y/o matrices de puerta programable en campo (Field Programmable Gate Arrays FPGAs). Preferiblemente el procedimiento y el dispositivo propuestos se implementan como una combinación de hardware y software. El software se instala preferiblemente como un programa de aplicación en un dispositivo de memoria de programa. Normalmente se trata de una máquina basada en una plataforma informática que presenta hardware como, por ejemplo, una o varias unidades centrales (CPU), una memoria de acceso directo (RAM) y una o varias interfaces de entrada /salida (I/O). En la plataforma informática se instala normalmente además un sistema operativo. Los distintos procesos y funciones que se han descrito en este caso pueden ser parte del programa de aplicación, o una parte que se ejecuta a través del sistema operativo.
10 Nodo CAN
12 Transceptor CAN
13 Resistencia de terminación
14 Controlador CAN
15 Línea de bus
16 Ordenador principal
100 Sistema electrónico del automóvil
102 Bus CAN de infoentretenimiento
104 Bus CAN de alta velocidad
105 Cámara
106 Bus CAN de baja velocidad
108 Bus CAN de asistencia al conductor
110 Módulo de comunicación
120 Sistema de navegación
131 Unidad de mando
132 Aparato de control de instalación de aire acondicionado
133 Aparato de control de palanca selectora
134 Aparato de control de puerta
140 Puerta de enlace
151 Aparato de control de motor
152 Aparato de control de ESP
153 Aparato de control de transmisión
161 Sensor 1
162 Sensor 2
163 Sensor 3
171 Aparato de control de asistencia al conductor
172 Aparato de control de RADAR
A 1. Curva de ejemplo
B 2. Curva de ejemplo
C 3. Curva de ejemplo
D 4. Curva de ejemplo
St. t Estación A
St. E Estación B
Punto de conmutación de tasas binarias

Claims (14)

  1. REIVINDICACIONES
    i. Procedimiento para la transmisión de datos a través de un bus de comunicación en serie en el que los datos se transmiten con una trama de transmisión,
    en donde la trama de transmisión presenta al menos un campo de arbitraje (AF) y un campo de datos (DF), en donde el campo de arbitraje (AF) sirve para regular el acceso de bus según el procedimiento CSMA-CR, que corresponde a Carrier Sense Multiple Access with Collision Resolution mediante la priorización de los mensajes con ayuda de un identificador,
    en donde para la fase de arbitraje se regula una tasa binaria baja, y para la transmisión de los datos en el campo de datos (DF) se regula una tasa binaria elevada,
    en donde el campo de datos (DF) dentro de un límite superior establecido que es mayor de 64 bytes, presenta una longitud variable para un número discrecional de bytes,
    caracterizado por que
    en la trama de transmisión se prevé además un campo de fin (EF) y en el campo de fin (EF) se introduce al menos un código de fin de trama (End-of-Frame-Code), en donde el código de fin de trama presenta una longitud de 11 bis para forzar mediante el envío del código de fin de trama una infracción de una nueva regla de relleno de bits (Bitstuffing), de manera que los abonados que no estaban correctamente sincronizados identifican este hecho.
  2. 2. Procedimiento según la reivindicación 1, en donde el límite superior establecido se refiere al valor de 4096 bytes.
  3. 3. Procedimiento según la reivindicación 1 o 2, en donde la longitud del campo de arbitraje (AF) se establece en 32 bits.
  4. 4. Procedimiento según una de las reivindicaciones anteriores, en donde en la trama de transmisión se prevé un campo de control (CF) entre campo de arbitraje (AF) y campo de datos (DF) en el que al menos se prevé una sección para la indicación de longitud con respecto al campo de datos (DF).
  5. 5. Procedimiento según una de las reivindicaciones anteriores, en donde en la trama de transmisión se prevé un campo CRC (CRCF) en el que se prevé al menos una sección para el código de verificación CRC.
  6. 6. Procedimiento según la reivindicación 5, en donde en la trama de transmisión se prevé un campo de inicio (SF) y el código de verificación CRC se calcula a través de los campos campo de inicio (SF), campo de arbitraje (AF), campo de control (CF) y campo de datos (DF).
  7. 7. Procedimiento según la reivindicación 6, en donde la transmisión de los datos se realiza de manera asíncrona y para garantizar el sincronismo de estación de emisión de datos y estación de recepción de datos se lleva a cabo una resincronización según una regla de relleno de bits, en donde la regla de relleno de bits se aplica a través de las áreas desde el campo de inicio (SF) hasta el final del campo de datos (DF), en donde la regla de relleno de bits dice que un bit de relleno solo después de un número definido de bits directamente consecutivos se inserta con el mismo nivel de bus, en donde el número definido es un número natural mayor que el número 5, en donde el número de los bits de relleno insertados se anota en una sección del campo CRC (CRCF).
  8. 8. Procedimiento según una de las reivindicaciones anteriores, en donde en el campo CRC (CRCF) en posiciones predeterminadas de manera fija se inserta un bit de relleno.
  9. 9. Procedimiento según la reivindicación 8, en donde el campo CRC (CRCF) comienza con un bit de relleno predeterminado de manera fija y los bits de relleno predeterminados de manera fija adicionales se insertan en cada caso a una distancia de 9 bits del campo CRC (CRCF).
  10. 10. Procedimiento según una de las reivindicaciones anteriores, en donde el identificador en el campo de arbitraje (AF) se subdivide en las secciones identificador de “contenido de mensaje” e identificador de “ aparatos” .
  11. 11. Procedimiento según la reivindicación 10, en donde la sección con los bits de mayor valor se reserva para la priorización del contenido de mensaje y la sección con los bits de menor valor se prevé para la identificación de aparatos.
  12. 12. Procedimiento según la reivindicación 11, en donde el identificador presenta una longitud de 32 bits y la sección con los bits de mayor valor presenta una longitud de 24 bits y la sección con los bits de menor valor presenta una longitud de 8 bits.
  13. 13. Interfaz de bus diseñada para el uso en el procedimiento según una de las reivindicaciones anteriores.
  14. 14. Programa informático, caracterizado por que el programa informático está diseñado para realizar, en el procesamiento en una unidad de computación, las etapas en el lado de emisión y/o las etapas en el lado de recepción del procedimiento para la transmisión de datos según una de las reivindicaciones 1 a 12.
ES19218441T 2017-07-11 2018-06-06 Procedimiento para la transmisión de datos a través de un bus de comunicación en serie, interfaz de bus diseñada de manera correspondiente, así como programa informático diseñado de manera correspondiente Active ES2929124T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102017211860.1A DE102017211860B3 (de) 2017-07-11 2017-07-11 Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm

Publications (1)

Publication Number Publication Date
ES2929124T3 true ES2929124T3 (es) 2022-11-25

Family

ID=62684587

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19218441T Active ES2929124T3 (es) 2017-07-11 2018-06-06 Procedimiento para la transmisión de datos a través de un bus de comunicación en serie, interfaz de bus diseñada de manera correspondiente, así como programa informático diseñado de manera correspondiente

Country Status (6)

Country Link
US (2) US10530606B2 (es)
EP (2) EP3661131B1 (es)
KR (1) KR102023673B1 (es)
CN (1) CN109240970B (es)
DE (1) DE102017211860B3 (es)
ES (1) ES2929124T3 (es)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017211860B3 (de) * 2017-07-11 2018-09-20 Volkswagen Aktiengesellschaft Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm
EP3665875B1 (de) 2017-08-08 2022-03-16 Volkswagen Aktiengesellschaft Verfahren zur übertragung von daten über einen seriellen kommunikationsbus, entsprechend ausgelegte busschnittstelle sowie entsprechend ausgelegtes computerprogramm
US10439840B1 (en) * 2018-07-27 2019-10-08 Nxp B.V. Method and device for communicating data frames on a multi-master bus
DE102018218721A1 (de) * 2018-10-31 2020-04-30 Robert Bosch Gmbh Teilnehmerstation für ein serielles Bussystem und Verfahren zum Senden einer Nachricht in einem seriellen Bussystem
DE102018221681A1 (de) * 2018-12-13 2020-06-18 Robert Bosch Gmbh Teilnehmerstation für ein serielles Bussystem und Verfahren zur Kommunikation in einem seriellen Bussystem
DE102019201316A1 (de) * 2019-02-01 2020-08-06 Robert Bosch Gmbh Teilnehmerstation für ein serielles Bussystem und Verfahren zur Kommunikation in einem seriellen Bussystem
KR102006634B1 (ko) * 2019-03-06 2019-08-02 브이에스아이 주식회사 이종의 통신방식들 중 하나로 적응시킴으로써 이종 통신방식의 노드들이 단일 버스를 공유할 수 있게 하는 방법과 그 방법을 위한 기기
JP7114515B2 (ja) * 2019-03-14 2022-08-08 国立大学法人東海国立大学機構 通信装置、通信システム及びメッセージ調停方法
DE102019204115A1 (de) 2019-03-26 2020-10-01 Robert Bosch Gmbh Teilnehmerstation für ein serielles Bussystem und Verfahren zur Kommunikation in einem seriellen Bussystem
DE102019213783A1 (de) * 2019-09-11 2021-03-11 Robert Bosch Gmbh Teilnehmerstation für ein serielles Bussystem und Verfahren zur Kommunikation in einem seriellen Bussystem
DE102019218715A1 (de) * 2019-12-02 2021-06-02 Robert Bosch Gmbh Teilnehmerstation für ein serielles Bussystem und Verfahren zur Kommunikation in einem seriellen Bussystem
CN111130695B (zh) * 2019-12-10 2022-09-20 卡斯柯信号有限公司 通过冗余码字计算canopen协议crc的方法
KR20210073976A (ko) * 2019-12-11 2021-06-21 현대자동차주식회사 차량용 게이트웨이 및 차량용 게이트웨이의 제어방법
US20210255984A1 (en) * 2020-02-19 2021-08-19 Magna Electronics Inc. Vehicular sensor testing system with standardized i2c communication
GB2592967A (en) * 2020-03-12 2021-09-15 Warwick Control Tech Ltd A method for monitoring a network
CN112732511B (zh) * 2021-01-14 2022-10-25 上海镭隆科技发展有限公司 一种基于hdlc协议高性能高速同步422仿真器板卡
CN112765072A (zh) * 2021-01-28 2021-05-07 北京方天长久科技股份有限公司 一种串行互联总线数据帧格式及传输方法
DE102021206175A1 (de) * 2021-06-17 2022-12-22 Robert Bosch Gesellschaft mit beschränkter Haftung Ansteuerungssystem, Steuermodul und Verfahren zum Betreiben

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3042549B2 (ja) * 1991-08-23 2000-05-15 古河電気工業株式会社 多重伝送方式の受信応答方法
FI88841C (fi) * 1991-10-30 1993-07-12 Nokia Telecommunications Oy Foerfarande foer att behandla dataoeverfoeringsramar av vaexlande laengd med en kanalstyrenhet och foer att placera desamma till ett cykliskt buffertminne
KR101876602B1 (ko) * 2011-04-06 2018-07-09 로베르트 보쉬 게엠베하 직렬 버스 시스템에서 데이터 전송 보안의 조정 방법 및 장치
US9513988B2 (en) * 2011-04-06 2016-12-06 Robert Bosch Gmbh Method and device for increasing the data transmission capacity in a serial bus system
DE102011006884A1 (de) 2011-04-06 2012-10-11 Robert Bosch Gmbh Verfahren und Vorrichtung zur Erhöhung der Datenübertragungskapazität in einem seriellen Bussystem
EP2521319B1 (en) * 2011-05-02 2015-10-14 Robert Bosch GmbH Controller area network with flexible data-rate
DE102011122843A1 (de) 2011-06-29 2013-01-31 Robert Bosch Gmbh Verfahren und Vorrichtung zur seriellen Datenübertragung mit flexibler Nachrichtengröße und variabler Bitlänge
DE102012224024A1 (de) 2012-12-20 2014-06-26 Robert Bosch Gmbh Datenübertragung unter Nutzung eines Protokollausnahmezustands
US9419737B2 (en) * 2013-03-15 2016-08-16 Concio Holdings LLC High speed embedded protocol for distributed control systems
DE102014205120A1 (de) * 2014-03-19 2015-09-24 Robert Bosch Gmbh Teilnehmerstation für ein Bussystem und Verfahren zur Erhöhung der Übertragungskapazität in einem Bussystem
CN105593067B (zh) * 2014-04-17 2019-07-02 松下电器(美国)知识产权公司 车载网络系统、非法检测电子控制单元及非法检测方法
CN116545566A (zh) * 2014-05-26 2023-08-04 康西欧控股有限公司 用于分布式控制系统的高速嵌入式协议
US10673565B2 (en) * 2014-09-30 2020-06-02 Concio Holdings LLC Confirming data accuracy in a distributed control system
DE102015204714A1 (de) 2015-03-16 2016-09-22 Robert Bosch Gmbh Teilnehmerstation für ein Bussystem und Verfahren zur Datenübertragung in einem Bussystem
US10050983B2 (en) * 2015-11-13 2018-08-14 Kabushiki Kaisha Toshiba Communication system, receiving apparatus, receiving method, and computer program product
DE102017211860B3 (de) * 2017-07-11 2018-09-20 Volkswagen Aktiengesellschaft Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm

Also Published As

Publication number Publication date
KR20190006922A (ko) 2019-01-21
DE102017211860B3 (de) 2018-09-20
EP3661131B1 (de) 2022-09-07
US20200145254A1 (en) 2020-05-07
US20190020499A1 (en) 2019-01-17
US11146420B2 (en) 2021-10-12
EP3429136A1 (de) 2019-01-16
EP3661131A1 (de) 2020-06-03
CN109240970A (zh) 2019-01-18
KR102023673B1 (ko) 2019-09-23
CN109240970B (zh) 2022-06-03
EP3429136B1 (de) 2020-03-25
US10530606B2 (en) 2020-01-07

Similar Documents

Publication Publication Date Title
ES2929124T3 (es) Procedimiento para la transmisión de datos a través de un bus de comunicación en serie, interfaz de bus diseñada de manera correspondiente, así como programa informático diseñado de manera correspondiente
JP4116384B2 (ja) バスシステム上での情報伝送方法と装置およびバスシステム
US7801173B2 (en) Communication message conversion apparatus and communication message conversion method
CN110999226B (zh) 用于经由串行通信总线来传输数据的方法、对应设计的总线接口和对应设计的计算机程序
RU2597502C2 (ru) Способ и устройство для адаптируемой к размерам памяти последовательной передачи данных
US11256498B2 (en) Node, a vehicle, an integrated circuit and method for updating at least one rule in a controller area network
WO2017090351A1 (ja) 車載ゲートウェイ装置、電子制御装置、車載ネットワークシステム
US20160224501A1 (en) Adaptation device for a bus system, and method for operating a can subscriber station and a can fd subscriber station in a bus system
US20200382597A1 (en) Vehicle diagnostic communication apparatus, system including the same and method thereof
CN113841362B (zh) 用于串行总线系统的用户站和用于在串行总线系统中进行通信的方法
US10282332B2 (en) Subscriber station for a bus system and method for time-optimized data transmission in a bus system
KR20160135296A (ko) 버스 시스템용 가입자국, 그리고 버스 시스템에서의 전송 용량 증대 방법
WO2007024370A2 (en) System and method of optimizing the bandwidth of a time triggered communication protocol with homogeneous slot sizes
US10162777B2 (en) Transmission unit with checking function
Cook et al. Controller area network (can)
DE102017012214B4 (de) Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm
Seo et al. Development of network gateway between CAN and FlexRay protocols for ECU embedded systems
An et al. Analysis of CAN FD to CAN message routing method for CAN FD and CAN gateway
KR101704300B1 (ko) Can 메시지 송수신 방법 및 이를 실행하는 시스템
CN113196713B (zh) 串行总线系统的用户站和在串行总线系统中发送消息的方法
CN114338556A (zh) 一种can网络和车载以太网间的报文转发方法及网关系统
WO2021161303A1 (en) High bandwidth can-derivative communication
KR101506301B1 (ko) 캔 통신을 이용한 교통신호 제어시스템
GB2592672A (en) A high-speed data link (HSDL)-peripheral component interconnect express (PCIe) interface for establishing communication in vehicles
JP2022121402A (ja) シリアルバスシステムのための加入者局およびシリアルバスシステムにおける通信のための方法