Bus CAN
CAN (acrónimo del inglés Controller Area Network) es un protocolo de comunicacionesdesarrollado por la firma alemana Robert Bosch GmbH,
basado en una topología bus para la transmisión de mensajes en entornos distribuidos. Además ofrece una solución a la gestión de la
comunicación entre múltiplesCPUs (unidades centrales de proceso).
El protocolo de comunicaciones CAN proporciona los siguientes beneficios:
Ofrece alta inmunidad a las interferencias, habilidad para el autodiagnóstico y la reparación de errores de datos.
Es un protocolo de comunicaciones normalizado, con lo que se simplifica y economiza la tarea de comunicar subsistemas de
diferentes fabricantes sobre una red común o bus.
El procesador anfitrión (host) delega la carga de comunicaciones a un periférico inteligente, por lo tanto el procesador anfitrión
dispone de mayor tiempo para ejecutar sus propias tareas.
Al ser una red multiplexada, reduce considerablemente el cableado y elimina las conexiones punto a punto, excepto en los
enganches.
Índice
Historia y evolución del protocolo CAN
Principales características de CAN
Tipos de bus CAN
CAN de alta velocidad
Extensiones del CAN de alta velocidad
CAN de baja velocidad tolerante a fallos
CAN FD (flexible data-rate)
Capa física
Niveles de tensión del bus
Cable y conectores
Sincronización de bits
Capa de enlace de datos
Acceso al medio (arbitraje)
Tipos de trama
Trama de datos
Formato base
Formato extendido
Trama remota
Trama de error
Trama de sobrecarga
Separación entre tramas
Bits de relleno (bit stuffing)
Protocolos basados en CAN
Véase también
Referencias
Enlaces externos
Historia y evolución del protocolo CAN
El desarrollo del protocolo CAN comenzó en 1983 en la empresa Robert Bosch GmbH (comúnmente conocida como Bosch). El protocolo fue
oficialmente lanzado en 1986 en el congreso de la Sociedad de Ingenieros Automotrices (SAE) en Detroit. Los primeros controladores CAN
llegaron al mercado en 1987 de la mano deIntel y Philips.1
Bosch publicó posteriormente varias versiones de la especificación CAN, siendo la última de ellas la especificación CAN 2.0, publicada en 1991.
Esta especificación consta de dos partes; la parte A para el formato estándar y la parte B para el formato extendido. Un dispositivo CAN que usa
el formato estándar utiliza identificadores de 11 bits y es comúnmente referido como dispositivo CAN 2.0A. Un dispositivo CAN que usa el
formato extendido utiliza identificadores de 29 bits y es comúnmente referido como dispositivo CAN 2.0B. Los estándares CAN 2.0A/B y otros
2
documentos de referencia relacionados con CAN son de acceso libre a través de Bosch.
En 1993 se publicó el estándar ISO 11898 del bus CAN y ha sido a partir de ese momento un estándar de la Organización Internacional para la
Normalización. Actualmente el bus CAN está estandarizado por las siguientes normas:
ISO 11898-1:2015, Part 1: Data link layer and physical signalling
ISO 11898-2:2003, Part 2: High-speed medium access unit
ISO 11898-3:2006. Part 3: Low-speed, fault-tolerant, medium-dependent interface
ISO 11898-4:2004, Part 4: Time-triggered communication
ISO 11898-5:2007, Part 5: High-speed medium access unit with low power mode
ISO 11898-6:2013, Part 6: High-speed medium access unit with selective wake-up functionality
ISO 16845:2004, Conformance test plan
En 2011 Bosch, en cooperación con los fabricantes de automóviles y otros expertos del bus CAN, comenzó a desarrollar la siguiente generación
del CAN: el protocolo CAN FD (flexible data-rate). El CAN FD es compatible hacia atrás, es decir, un controlador CAN FD es capaz de
comprender un mensaje CAN clásico (o CAN 2.0). Por el contrario, un controlador CAN clásico destruye un mensaje CAN FD emitiendo un
mensaje de error. El nuevo CAN FD es capaz de transmitir datos más rápido que 1 Mbps (la velocidad máxima del CAN clásico). Ambos
protocolos, el CAN clásico y el CAN FD, están estandarizados en la norma ISO/DIS1898-1.
1 34
Principales características de CAN
CAN se basa en el modelo productor/consumidor, el cual es un concepto, o paradigma de comunicaciones de datos, que describe una relación
entre un productor y uno o más consumidores. CAN es un protocolo orientado a mensajes, es decir la información que se va a intercambiar se
descompone en mensajes, a los cuales se les asigna un identificador y se encapsulan en tramas para su transmisión. Cada mensaje tiene un
identificador único dentro de la red, con el cual los nodos deciden aceptar o no dicho mensaje. Dentro de sus principales características se
encuentran:
Prioridad de mensajes.
Garantía de tiempos de latencia.
Flexibilidad en la configuración.
Recepción por multidifusión (multicast) con sincronización de tiempos.
Sistema robusto en cuanto a consistencia de datos.
Sistema multimaestro.
Detección y señalización de errores.
Retransmisión automática de tramas erróneas
Distinción entre errores temporales y fallas permanentes de los nodos de la red, y desconexión autónoma de nodos
defectuosos.
CAN fue desarrollado inicialmente para aplicaciones en los automóviles y por lo tanto la plataforma del protocolo es resultado de las necesidades
existentes en el área de la automoción. La Organización Internacional para la Estandarización (ISO, International Organization for
Standardization) define dos tipos de redes CAN: una red de alta velocidad (hasta 1 Mbit/s), bajo el estándar ISO 11898-2, destinada para controlar
el motor e interconectar lasunidades de control electrónico(ECU); y una red de baja velocidad tolerante a fallos (menor o igual a 125 kbit/s), bajo
el estándar ISO 11519-2/ISO 11898-3, dedicada a la comunicación de los dispositivos electrónicos internos de un automóvil como son control de
puertas, techo corredizo, luces y asientos.
Tipos de bus CAN
La especificación de los buses CAN esta recogida en el conjunto de estándares ISO 11898. Dicha especificación define las dos primeras capas, la
capa física y la capa de enlace de datos, del modelo OSI de interconexión de sistemas. Sobre la base de dichos estándares, los buses CAN se
pueden clasificar en dos tipos:
CAN de alta velocidad (hasta 1 Mbit/s).
CAN de baja velocidad tolerante a fallos (hasta 125 kbit/s).
CAN de alta velocidad
ISO 11898-2, también llamado CAN de alta velocidad, usa un único bus lineal terminado en cada extremo con sendas resistencias de 120 Ω. Es
importante que el valor de las resistencias de terminación coincida con la impedancia característica del bus, definida en 120 Ω, para evitar
reflexiones en la línea que podrían perturbar la comunicación. Con esta configuración la velocidad del bus es de un máximo de 1 Mbit/s.
Bus CAN de alta velocidad. ISO 11898-2
Extensiones del CAN de alta velocidad
La Organización Internacional para la Normalización (ISO) ha definido unas extensiones opcionales de la capa física del bus CAN de alta
velocidad (ISO 11898-2). Dichas extensiones están descritas en sus respectivos estándares y son útiles para sistemas con requisitos específicos.
También definen la compatibilidad con ISO 1898-2.
ISO 11898-5 especifica la capa física con tasas de transmisión de hasta 1 Mbit/s para sistemas que requieren bajo consumo de
energía cuando no hay comunicaciones activas en el bus de datos. ISO 11898-5 representa una extensión de ISO 11898-2 y
aquellas implementaciones que cumplan cualquiera de estas dos normas, es decir, los nodos CAN de alta velocidad con y sin
bajo consumo de energía, son interoperables entre sí y pueden coexistir en la misma red. 5
ISO 11898-6 es una extensión de ISO 11898-2 y de ISO 11898-5. Esta extensión especifica la capa física de un bus CAN de
hasta 1 Mbit/s, proporcionando un método selectivo de activación de nodos (wake-up) usando tramas CAN configurables. Las
implementaciones de ISO 11898-6, ISO 11898-2 e ISO 11898-5 son interoperables y se pueden usar en una misma red
simultáneamente.6
CAN de baja velocidad tolerante a fallos
ISO 11898-3, también llamado CAN de baja velocidad tolerante a fallos, puede utilizar un bus lineal, un bus en estrella o múltiples buses en
estrella conectados por un bus lineal. El bus está terminado en cada nodo por una fracción de la resistencia de terminación total. La resistencia de
terminación total debería ser un valor próximo a 100 Ω, pero no inferior a 100 Ω. Este estándar permite velocidades de hasta 125 kbit/s.
Bus CAN de baja velocidad tolerante a fallos. ISO 11898-3
CAN FD (flexible data-rate)
En 2011 Bosch comenzó a trabajar en una evolución del CAN. En 2012 lanzó CAN FD 1.0, que ofrece un aumento de la tasa de transferencia
después del arbitraje. De momento (2015), sólo se ha definido la capa de enlace de datos del CAN FD. La frecuencia se puede multiplicar hasta
por 8 y el número máximo de bytes por trama aumenta, siendo posible transmitir una mayor cantidad de datos en el mismo tiempo.4 La
especificación está recogida en el borrador de norma ISO/DIS 1898-1:2015.
1
Capa física
Define los aspectos del medio físico para la transmisión de datos entre nodos de una red CAN, las características materiales y eléctricas y la
transmisión del flujo de bits a través del bus.
Niveles de tensión del bus
La transmisión de señales en un bus CAN se lleva a cabo a través de dos cables trenzados. Las
señales de estos cables se denominan CAN_H CAN
( high) y CAN_L (CAN low) respectivamente.
El bus tiene dos estados definidos: estado dominante y estado recesivo. En estado recesivo, los
dos cables del bus se encuentran al mismo nivel de tensión (common-mode voltage), mientras
que en estado dominante hay una diferencia de tensión entre CAN_H y CAN_L de al menos
1,5 V. La transmisión de señales en forma de tensión diferencial, en comparación con la
transmisión en forma de tensiones absolutas, proporciona protección frente a interferencias
electromagnéticas.
La tensión en modo común puede estar, según la especificación, en cualquier punto entre -2 y Niveles de tensión del bus CAN
7 V. La tensión diferencial del bus (la diferencia entre CAN_H y CAN_L) en modo dominante
debe estar entre 1,5 y 3 V. No se especifica, en cambio, que la tensión de modo común, cuando el
bus está en modo recesivo, deba estar comprendida entre la tensión de CAN_L y la tensión de CAN_H cuando el bus está en modo dominante.
Esto permite la conexión directa entre nodos que operen a distintas tensiones, e incluso nodos que sufran diferencia de tensión entre sus
respectivas tierras.7 8
Cable y conectores
Los distintos nodos de un bus CAN deben estar interconectados mediante un par de cables
trenzados con una impedancia característica de 120 Ω, y puede ser cable apantallado o sin
apantallar. El cable trenzado proporciona protección frente a interferencias electromagnéticas
externas. Y si, además, está apantallado, la protección será mayor pero a cambio de un
incremento en el coste del cable.
Conector D-sub de 9 pines (DE-9)
El estándar CAN, a diferencia de otros estándares como el USB, no especifica ningún tipo de
conector para el bus y por lo tanto cada aplicación puede tener un conector distinto. Sin embargo,
hay varios formatos comúnmente aceptados como el conectorD-sub de 9 pines, con la señal CAN_L en el pin 2 y la señal CAN_H en el pin 7.
Las propiedades de la línea de transmisión limitan el ancho de banda de los datos. Orientativamente, se aceptan los siguientes valores como límite
9
de longitud del bus en función de la tasa de transferencia:
Longitud del bus Tasa de transferencia
(m) (kbit/s)
40 1000
100 500
200 250
500 100
1000 50
Sincronización de bits
Todos los nodos de un bus CAN deben trabajar con la misma tasa de transferencia nominal. Dado que el bus CAN no usa una señal de reloj
separada, factores como laderiva de reloj y la tolerancia de los osciladores causan que haya una diferencia entre la tasa de transferencia real de los
distintos nodos. Por ello es necesario un método de sincronización entre los nodos. La sincronización es especialmente importante en la fase de
arbitraje ya que durante el arbitraje cada nodo debe ser capaz de observar tanto los datos transmitidos por él como los datos transmitidos por los
demás nodos.
El requisito mínimo para un bus CAN es que dos nodos, estando en sendos extremos de la red con el máximo retardo de propagación entre ellos, y
cuyos controladores CAN tienen unas frecuencias de reloj en los límites opuestos de la tolerancia de frecuencia especificada, sean capaces de
recibir y leer correctamente todos los mensajes transmitidos por la línea. Esto incluye que todos los nodos muestreen el valor correcto de cada bit.
10
El controlador CAN espera que una transición del bus de recesivo a dominante ocurra en un determinado intervalo de tiempo. Si la transición no
ocurre en el intervalo esperado, el controlador reajusta la duración del siguiente bit en consecuencia. Dicho ajuste se lleva a cabo dividiendo cada
bit en intervalos o cuantos de tiempo (del latín quantum) y asignando los intervalos a los cuatro segmentos de cada bit: sincronización,
propagación, segmento de fase 1 y segmento de fase 2.
Ejemplo de cuantificación de un bit CAN con 10cuantos de tiempo por bit
Segmento de sincronización: es el intervalo de tiempo en el que se supone que ocurren las transiciones de recesivo a
dominante.
Segmento de propagación: es el intervalo de tiempo que compensa los retardos de propagación a lo largo de la línea.
Segmentos de fase 1 y 2: Se usan para llevar a cabo la resincronización de los nodos. El segmento de fase 1 puede ser
alargado o el 2 acortado para la resincronización. El punto de muestreo del bit se encuentra inmediatamente después del
segmento de fase 1. El punto de muestreo se encuentra habitualmente cerca del 75 % de la duración total del bit.
La configuración de los segmentos del bit se hacen sobre la base de la frecuencia de reloj de cada controlador CAN. Los segmentos se configuran
individualmente para cada controlador en un mismo bus. A efectos prácticos, la configuración de los segmentos del bit supone un compromiso
entre la tasa de transferencia y tolerancia de los osciladores.
Capa de enlace de datos
El protocolo CAN proporciona un acceso multimaestro al bus con una resolución determinista de las colisiones. La capa de enlace de datos define
el método de acceso al medio así como los tipos de tramas para el envío de mensajes.
Acceso al medio (arbitraje)
La especificación del CAN usa los términos “dominante” y “recesivo” para referirse a los bits, donde un bit dominante equivale al valor lógico 0 y
un bit recesivo equivale al valor lógico 1. El estado inactivo del bus es el estado recesivo (valor lógico 1). Cuando dos nodos intentan transmitir
bits diferentes se denomina colisión y el valor del bit dominante prevalece sobre el valor del bit recesivo. En ese caso el nodo que intentaba
transmitir el valor recesivo detecta la colisión y pasa a modo pasivo, es decir, deja de transmitir para escuchar lo que transmite el otro nodo. Por
esta razón es importante que todos los nodos estén sincronizados y muestreen todos los bits del bus simultáneamente.
El arbitraje se produce durante los primeros bits de una trama o mensaje, durante la transmisión de lo que se conoce como identificador del
mensaje. Al final del proceso de arbitraje sólo debe quedar un nodo con el control del bus. Por ello cada nodo debe manejar identificadores
únicos. Cuando un nodo pierde el arbitraje aplaza la transmisión de su trama para intentarlo de nuevo cuando finalice la trama actual. Conociendo
los identificadores de todos las tramas que intentan ser transmitidas, se puede establecer de manera determinista el orden en el que son
transmitidas. Así, una trama CAN con identificador más bajo (mayor número de bits dominantes en las primeras posiciones) tiene más prioridad
que una trama con identificador más alto.
Tipos de trama
Existen cuatro tipos de trama CAN:
Trama de datos (data frame)
Trama remota (remote frame)
Trama de error (error frame)
Trama de sobrecarga (overload frame)
Trama de datos
Una trama de datos CAN puede ser de uno de los dos siguientes formatos:
Formato base: con identificador de 11 bits.
Formato extendido: con identificador de 29 bits.
El estándar dice que un controlador CAN debe aceptar tramas en formato base, y puede o no aceptar tramas en formato extendido. Pero en
cualquier caso debe tolerar tramas en formato extendido. Es decir, que si un controlador está configurado para que sólo acepte tramas en formato
base no debe lanzar un error cuando reciba una trama en formato extendido, sino que simplemente no transmitirá el mensaje al procesador central.
Formato base
Trama CAN en formato base con las tensiones eléctricas del bus y sin bits de relleno
El formato de la trama es el siguiente:
Longitud
Nombre del campo Finalidad
(bits)
Inicio de trama 1 Demarca el comienzo de una transmisión.
Identificador - ID (verde) 11 Un identificador (único) que también representa la prioridad de la trama.
Petición de transmisión
1 Dominante (0) para tramas de datos y recesivo (1) para tramas de peticiones remotas.
remota - RTR (cián)
Bit de extensión de
1 Dominante (0) para el formato base (identificador de 11 bits).
identificador - IDE
Bit reservado (r0) 1 Bit reservado. Debe ser dominante (0), pero aceptado tanto dominante como recesivo.
Código de longitud de Número de bytes de datos en el mensaje, entre 0 y 8. Si este campo es mayor que 8 el
4
datos - DLC (amarillo) mensaje será de 8 bytes como máximo de cualquier modo.
0–64 (0-8 Datos de la trama (la longitud del campo viene dada por el código de longitud de datos
Campo de datos (rojo)
bytes) o DLC).
Verificación por redundancia cíclica. Código que verifica que los datos fueron
CRC 15
transmitidos correctamente.
Delimitador CRC 1 Debe ser recesivo (1).
Hueco de acuse de
1 El transmisor emite recesivo (1) y cualquier receptor emite dominante (0).
recibo - ACK
Delimitador ACK 1 Debe ser recesivo (1).
Fin de trama EOF 7 Debe ser recesivo (1).
Formato extendido
En el formato extendido los dos campos de identificador se combinan para formar el identificador de 29 bits. El formato de la trama es el
siguiente:
Longitud
Nombre del campo Finalidad
(bits)
Inicio de trama 1 Demarca el comienzo de una transmisión.
Identificador A - ID_A 11 Primera parte del identificador (único) que también representa la prioridad de la trama.
Sustituto de
transmisión remota - 1 Debe ser recesivo (1).
SRR
Bit de extensión de
1 Recesivo (1) para el formato extendido (identificador de 29 bits).
identificador - IDE
Identificador B - ID_B 18 Segunda parte del identificador (único) que también representa la prioridad de la trama.
Petición de
transmisión remota - 1 Dominante (0) para tramas de datos y recesivo (1) para tramas de peticiones remotas.
RTR
Bits reservados (r1,
2 Bit reservado. Debe ser dominante (0), pero aceptado tanto dominante como recesivo.
r0)
Código de longitud de Número de bytes de datos en el mensaje, entre 0 y 8. Si este campo es mayor que 8 el
4
datos - DLC mensaje será de 8 bytes como máximo de cualquier modo.
0–64 (0-8 Datos de la trama (la longitud del campo viene dada por el código de longitud de datos o
Campo de datos
bytes) DLC).
Verificación por redundancia cíclica. Código que verifica que los datos fueron transmitidos
CRC 15
correctamente.
Delimitador CRC 1 Debe ser recesivo (1).
Hueco de acuse de
1 El transmisor emite recesivo (1) y cualquier receptor emite dominante (0).
recibo - ACK
Delimitador ACK 1 Debe ser recesivo (1).
Fin de trama - EOF 7 Debe ser recesivo (1).
Trama remota
Generalmente los datos se transmiten como trama de datos. Sin embargo, es posible que un nodo requiera unos datos desde otro nodo. En ese
caso, el primero puede enviar una trama remota para pedir el envío de algún dato. El nodo que requiere la información envía entonces una trama
con una petición de transmisión remota (RTR = 1; recesivo). Las tramas remotas o de petición de transmisión remota sólo se diferencian de las
tramas de datos en que las tramas remotas no tienen campo de datos.
Trama de error
La trama de error es una trama especial que viola las reglas de formato de las tramas CAN. Se transmite cuando un nodo detecta un mensaje
erróneo, y provoca que los demás nodos también transmitan una trama de error. Un complejo mecanismo de contadores de error integrado en el
controlador asegura que un nodo no bloquee el bus con continuas tramas de error
.
Trama de sobrecarga
Es similar a la trama de error en cuanto a que viola el formato de las tramas CAN. Es transmitida por un nodo que se encuentra muy ocupado y el
bus proporciona entonces un retardo extra entre tramas.
Separación entre tramas
Las tramas de datos y remotas están separadas por al menos tres bits recesivos (1). Después de eso, si si detecta un bit dominante (0), es
considerado como el inicio de una nueva trama. Las tramas de error y de sobrecar
ga no respetan el espaciado entre tramas.
Bits de relleno (bit stuffing)
Para asegurar que hay suficientes transiciones recesivo-dominante y garantizar así la sincronización, un bit de polaridad opuesta es insertado
después de cinco bits consecutivos de la misma polaridad. Esta práctica es necesaria debido a la codificación sin vuelta a cerodel protocolo CAN.
Los bits insertados son eliminados por el receptor
.
Todos los campos de la trama son rellenados a excepción del delimitador CRC, el acuse de recibo ACK, y el fin de trama. Cuando un nodo detecta
seis bits consecutivos iguales en un campo susceptible de ser rellenado lo considera un error y emite un error activo. Un error activo consiste en
seis bits consecutivos dominantes y viola la regla de relleno de bits.
La regla de los bits de relleno implica que una trama puede ser más lar
ga de lo esperado si se suman los bits teóricos de cada campo de la trama.
Trama CAN antes y después de la adición debits de relleno (en morado)
Protocolos basados en CAN
Los estándares del bus CAN sólo especifican las dos primeras capas, la capa física y la capa de enlace de datos, según el modelo OSI. Puesto que
CAN no incluye tareas de capas superiores tales como direccionamiento, control de acceso, transporte de bloques de datos mayores que una
trama, etc., han ido surgiendo protocolos en capassuperiores basados en CAN, sobre todo en lacapa de aplicación.
Cabe mencionar los siguientes:
ARINC 825 (para la aviación)
CANaerospace (para la aviación)
CAN Kingdom
CANopen (para automatización industrial)
CCP / XCP
DeviceNet (para automatización industrial)
EnergyBus (para vehículos eléctricos)
GMLAN (de General Motors)
ISO 15765-4
ISO 11783 o ISOBUS (para la agricultura)
ISO 14229
SAE J1939 (para vehículos pesados)
ISO 11992 (para trailers pesados)
MilCAN
NMEA 2000 (para la industria marina)
OSEK
RV-C (para vehículos recreacionales)
SafetyBUS p (para la automatización industrial)
SmartCraft
Smart Distributed System (SDS)
VSCP (para la automatización de edificios)
Véase también
Protocolos de comunicación para el automóvil
FlexRay
LIN
MOST
Protocolos de comunicación genéricos
RS-232
RS-485
Referencias
1. «CAN History» ([Link] CAN in Automation.
2. Bosch Semiconductor CAN Literature([Link]
e_ip_modules/can_literature_1/can_literature.html)
Archivado ([Link] .[Link]/en/ubk_semiconductors/ip_mo
dules_3/produkttabelle_ip_modules/can_literature_1/can_literature.html)
el 19 de agosto de 2014 en laWayback Machine.
3. «CAN knowledge» ([Link] (en inglés). CAN in Automation. Consultado el 19 de agosto de
2015.
4. «CAN FD - The basic idea» ([Link] (en inglés). CAN in Automation. Consultado el
19 de agosto de 2015.
5. «ISO 11898-5:2007» ([Link] International Organization for
Standardization. Consultado el 22 de agosto de 2015.
6. «ISO 11898-6:2013» ([Link] International Organization for
Standardization. Consultado el 22 de agosto de 2015.
7. «AN228: A CAN Physical Layer Discussion» ([Link] . Microchip
Technology Inc. 2002. Consultado el 22 de agosto de 2015.
8. «SLLA337: Overview of 3.3V CAN Transcievers» ([Link] Texas Instruments Inc. 2013.
Consultado el 22 de agosto de 2015.
9. «SLLA 270: Controller Area Network physical layer requirements» ([Link] Texas
Instruments Inc. 2008. Consultado el 22 de agosto de 2015.
10. «AN1798: CAN bit timing requirements» ([Link] Freescale
Semiconductor. Consultado el 22 de agosto de 2015.
Enlaces externos
Wikimedia Commons alberga una categoría multimedia sobreBus CAN.
[Link]
[Link]
Enchufe OBD CAN-BUS, Enchufe OBD: Generalidades CAN-BUS
BMW CAN-CUS, Ocupación de los enchufes en los BMW CAN-BUS
2x2 VAG CAN-BUS, Ocupación de los enchufes 2x2 VAG CAN-BUS
Plataforma independiente de la discusión CANLIST(en inglés)
CAN Protocolo Tutorial (en inglés)
Obtenido de «[Link]
»
Se editó esta página por última vez el 8 ene 2018 a las 23:10.
El texto está disponible bajo laLicencia Creative Commons Atribución Compartir Igual 3.0 ; pueden aplicarse cláusulas adicionales.
Al usar este sitio, usted acepta nuestrostérminos de uso y nuestra política de privacidad.
Wikipedia® es una marca registrada de laFundación Wikimedia, Inc., una organización sin ánimo de lucro.