Você está na página 1de 121

Codificación Turbo para Protocolos de

Comunicaciones Industriales

por

Pablo Ariel Briff

Director de Tesis: Ing. Alberto Dams

Facultad de Ingenierı́a
Universidad de Buenos Aires

14 de junio de 2006
Buenos Aires, Argentina
i
Agradecimientos

Al Ing. Alberto Dams, por haber tomado el desafı́o de ayudarme con este
proyecto de investigación desde su posición de tutor.

Al Ing. Gabriel Venturino, por haberme comentado “...últimamente están


muy de moda los códigos turbo...”.

A todos aquellos profesores del área de Comunicaciones a los cuales con-


sulté para progresar en este trabajo y que pacientemente contestaron mis
preguntas y corrigieron mis errores.

Al Dr. Ing. Jorge Castiñeira, de la Universidad Nacional de Mar del Pla-


ta, por su invaluable ayuda via e-mail y sus excelentes apuntes relacionados
con el tema de codificación turbo.

A Sergio, por entender que la facultad es una prioridad.

A mis amigos Cristian y Martı́n, por ser mis amigos.

A ese excelente grupo de amigos de la facultad con los cuales compartı́ tan-
tos momentos agradables al tiempo que me formé como profesional.

A mi familia, mi mamá Zulma, mi hermana Romina, mi tı́o Héctor y mis


abuelas Zulema y Marı́a, por su apoyo incondicional y constante respaldo.

A Jesica, por su colaboración con algunas traducciones pero fundamen-


talmente por tanta paciencia a lo largo de todos estos años.

Gracias.

ii
Índice general

II

1. Introducción 8

2. Códigos turbo 11
2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Esquema de transmisión . . . . . . . . . . . . . . . . . . . . . 12
2.2.1. Codificador RSC . . . . . . . . . . . . . . . . . . . . . 12
2.2.2. Concatenación en paralelo . . . . . . . . . . . . . . . . 13
2.2.3. Interleaver . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4. Selección de redundancia . . . . . . . . . . . . . . . . . 17
2.3. Esquema de recepción . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1. Detección por sı́mbolo . . . . . . . . . . . . . . . . . . 20
2.3.2. LLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.3. LLR del canal . . . . . . . . . . . . . . . . . . . . . . . 20
2.4. Algoritmos de decodificación . . . . . . . . . . . . . . . . . . . 21
2.4.1. Algoritmos MAP . . . . . . . . . . . . . . . . . . . . . 22
2.4.2. LLR del bit dk . . . . . . . . . . . . . . . . . . . . . . 23
2.4.3. El coeficiente γk . . . . . . . . . . . . . . . . . . . . . . 23
2.4.4. El coeficiente αk . . . . . . . . . . . . . . . . . . . . . 24
2.4.5. El coeficiente βk . . . . . . . . . . . . . . . . . . . . . . 25
2.4.6. Λk : su relación con αk , βk y γk . . . . . . . . . . . . . . 25
2.4.7. Información extrı́nseca . . . . . . . . . . . . . . . . . . 26
2.4.8. Decodificación iterativa . . . . . . . . . . . . . . . . . . 28
2.4.9. Log-MAP y Max-Log-MAP . . . . . . . . . . . . . . . 29
2.4.10. Inicialización de ᾱk y β̄k . . . . . . . . . . . . . . . . . 32
2.5. Curvas BER vs. Eb /N0 . . . . . . . . . . . . . . . . . . . . . . 32

3. Protocolo Profibus 34
3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2. El sistema bus de campo Profibus . . . . . . . . . . . . . . . . 34

1
ÍNDICE GENERAL 2

3.2.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.2. Capa fı́sica . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.3. Formatos de tramas . . . . . . . . . . . . . . . . . . . . 38
3.3. Ejemplo de red Profibus . . . . . . . . . . . . . . . . . . . . . 39

4. Canal de comunicaciones 41
4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2. Modelo del canal . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.1. Canal AWGN . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.2. Ruido térmico . . . . . . . . . . . . . . . . . . . . . . . 47
4.3. Canal fı́sico en Profibus DP . . . . . . . . . . . . . . . . . . . 48
4.3.1. Especificaciones técnicas . . . . . . . . . . . . . . . . . 48
4.3.2. Tasa de transmisión de datos vs. distancia de cable . . 51
4.3.3. Niveles de ruido . . . . . . . . . . . . . . . . . . . . . . 51

5. Profibus Turbo 53
5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2. Esquema propuesto . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.1. Posible implementación y retardo asociado . . . . . . . 55
5.2.2. Factibilidad económica . . . . . . . . . . . . . . . . . . 56
5.3. Propiedades del canal propuesto . . . . . . . . . . . . . . . . . 56
5.3.1. BER y Eb /N0 . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.2. Niveles de ruido para la Eb /N0 propuesta . . . . . . . . 58
5.3.3. Atenuaciones para distintas tasas de datos . . . . . . . 58
5.4. Mejoras obtenidas . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4.1. Tasa de transmisión constante . . . . . . . . . . . . . . 59
5.4.2. Distancia de cable constante . . . . . . . . . . . . . . . 61

6. Simulaciones 68
6.1. Modelo en Simulink . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2. Grados de libertad . . . . . . . . . . . . . . . . . . . . . . . . 72
6.3. Resultados de las simulaciones . . . . . . . . . . . . . . . . . . 74
6.3.1. Algoritmo Log-MAP . . . . . . . . . . . . . . . . . . . 74
6.3.2. Algoritmo Max-Log-MAP . . . . . . . . . . . . . . . . 76

7. Conclusiones 77

A. Fundamentos matemáticos 79
A.1. Lı́mite de Shannon . . . . . . . . . . . . . . . . . . . . . . . . 79
A.2. Expresión de la LLR del canal . . . . . . . . . . . . . . . . . . 80
A.3. Probabilidad a priori de dk . . . . . . . . . . . . . . . . . . . . 80
ÍNDICE GENERAL 3

A.4. Expresión extendida de P (Y |X) . . . . . . . . . . . . . . . . . 81


A.5. Expresión de γk . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.6. Expresión de αk . . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.7. Expresión de βk . . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.8. Transformada de Fourier de un pulso rectangular . . . . . . . 83

B. Interfaz RS485 86

C. Descripción del protocolo Profibus 89


C.1. Servicios de capa de enlace . . . . . . . . . . . . . . . . . . . . 89
C.2. Protocolo de MAC y de enlace de datos . . . . . . . . . . . . . 95

D. Código fuente de Matlab 102


D.1. Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
D.2. Esquema de Transmisión/Recepción Turbo . . . . . . . . . . . 104
D.3. Algoritmo Log-MAP . . . . . . . . . . . . . . . . . . . . . . . 109
D.4. Algoritmos accesorios . . . . . . . . . . . . . . . . . . . . . . . 113
D.4.1. Construcción de las matrices del trellis . . . . . . . . . 113
D.4.2. Conversor de binario a polar . . . . . . . . . . . . . . . 114
D.4.3. Conversor de polar a binario . . . . . . . . . . . . . . . 114
D.4.4. Detección de errores . . . . . . . . . . . . . . . . . . . 114
D.4.5. Curva de BER vs. Eb /N0 sin codificación . . . . . . . . 114
D.4.6. Resolución ecuación para distancia constante . . . . . . 115
Índice de figuras

2.1. Codificador RSC de tasa k = 1/2 [5] . . . . . . . . . . . . . . 12


2.2. Concatenación en paralelo de codificadores RSC [5] . . . . . . 13
2.3. Esquema de terminación de trellis para un codificador RSC [10] 14
2.4. BER con terminación de trellis, tamaño del bloque=100 [9] . . 15
2.5. BER con terminación de trellis, tamaño del bloque=1000 [9] . 15
2.6. Comparación entre interleavers de bloque, convolucionales y
pseudoaleatorios [12] . . . . . . . . . . . . . . . . . . . . . . . 17
2.7. Esquema de decodificación turbo [6] . . . . . . . . . . . . . . . 19
2.8. Doble cálculo del algoritmo de Viterbi del algoritmo MAP . . 22
2.9. Proceso de decodificación iterativa [7]. . . . . . . . . . . . . . 30
2.10. BER vs Eb /N0 para un código de tasa 1/2 y un tamaño de
interleaver de 256x256 [5] . . . . . . . . . . . . . . . . . . . . . 33

3.1. Pila del protocolo Profibus[14] . . . . . . . . . . . . . . . . . . 36


3.2. Formatos de tramas Profibus [14] . . . . . . . . . . . . . . . . 39
3.3. Ejemplo práctico de una red Profibus [21] . . . . . . . . . . . 40

4.1. Esquema de un sistema de comunicaciones con un canal de


ruido aditivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2. Ejemplo de evento de ruido aditivo . . . . . . . . . . . . . . . 45
4.3. Correlación del ruido y su transformada de Fourier . . . . . . 46
4.4. Cable utilizado en Profibus DP . . . . . . . . . . . . . . . . . 48
4.5. Atenuación del cable de Profibus DP en función de la frecuencia 51
4.6. Máximas distancias del cable de Profibus DP vs. tasa de trans-
misión de datos [18]. . . . . . . . . . . . . . . . . . . . . . . . 52

5.1. Esquema propuesto para Profibus Turbo . . . . . . . . . . . . 54


5.2. BER vs Eb /N0 para transmisión sin codificación . . . . . . . . 57
5.3. Detalle de la figura 4.5 para el rango de frecuencias de 250KHz
a 1MHz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4. R2 para distancia de cable igual a 400 metros . . . . . . . . . 64

4
ÍNDICE DE FIGURAS 5

5.5. R2 para distancia de cable igual a 200 metros . . . . . . . . . 65


5.6. R2 para distancia de cable igual a 100 metros . . . . . . . . . 66

6.1. Esquema de transmisión/recepción con codificación turbo . . . 70


6.2. Componentes del bloque Turbo Decoder . . . . . . . . . . . . 71
6.3. Resultados de las simulaciones realizadas por [8] . . . . . . . . 73
6.4. K=3, G=7, F=5, 100 tramas transmitidas . . . . . . . . . . . 74
6.5. K=5, G=21, F=37, 100 tramas transmitidas . . . . . . . . . . 75
6.6. K=5, G=21, F=37, 100 tramas transmitidas . . . . . . . . . . 76

A.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

B.1. Esquema de bus RS485 de dos hilos [19] . . . . . . . . . . . . 87


B.2. Esquema de bus RS485 de cuatro hilos [19] . . . . . . . . . . . 87

C.1. Interacciones del servicio SDA [14] . . . . . . . . . . . . . . . 92


C.2. Interacciones del servicio SDN [14] . . . . . . . . . . . . . . . 93
C.3. Interacciones del servicio SRD [14] . . . . . . . . . . . . . . . 93
Índice de cuadros

3.1. Relación entre el bit-rate y la distancia del cable para RS-485


PHY y cable tipo A [20] . . . . . . . . . . . . . . . . . . . . . 37

4.1. Especificaciones técnicas del canal fı́sico para Profibus DP [17] 49


4.2. Niveles de ruido para Profibus PA . . . . . . . . . . . . . . . 52

5.1. Atenuación en función de la tasa de datos . . . . . . . . . . . 58

C.1. Servicios FDL [20] . . . . . . . . . . . . . . . . . . . . . . . . 90

6
Objetivo

El objetivo de la tesis es mejorar los protocolos estándar de comunicacio-


nes industriales, tomando como ejemplo el protocolo abierto Profibus, me-
diante la introducción de la técnica de codicación Turbo, obteniendo resulta-
dos que justifiquen el esfuerzo tecnológico agregado. Dichas mejoras pueden
significar una mayor velocidad de transmisión para la misma distancia de
cable especificada, o bien una mayor distancia de cable respecto de la esta-
blecida por la norma para cada velocidad en particular.
Asimismo, la inversión económica en los equipos existentes debe ser pequeña
frente al valor actual de los mismos de manera de lograr aceptación en el
mercado.

7
Capı́tulo 1

Introducción

El transporte de la información siempre ha sido objeto de estudio en el


área de la ingenierı́a. Las aplicaciones que requieren transporte y manejo de
información varı́an ampliamente, por lo que para cada caso en particular de-
ben conocerse las condiciones a las cuales se someterán las señales eléctricas,
y en consecuencia encontrar un posible esquema que solucione el problema en
cuestión; en términos generales, la solución dista de ser trivial en la mayorı́a
de los casos.

Aunque lo antedicho es válido, el área de ingenierı́a de control ha sido du-


rante largos años reacia a implementar soluciones que impliquen complejos
esquemas de transmisión y recepción de datos, siendo suficiente para cumpli-
mentar los requerimientos de los procesos los lazos de corriente de 4 a 20 mA.
Con el advenimiento de las redes de datos y la integración de la información
mediante el concepto de IT (Information Technology), los sistemas de control
de procesos industriales han migrado bajo la moción de que todo aquello que
no se integra a una red de datos IP ha de ser arcaico y obsoleto. Este nuevo
paradigma de transmisión de la información se ha traducido en una reestruc-
turación de los esquemas de medición de las magnitudes fı́sicas en cuestión
(temperatura, presión, caudal, nivel, entre otros), adoptando topologı́as de
red similares a aquellas caracterı́sticas de las redes IP, incluso introduciendo
el uso de routers, switches, hubs, firewalls, siguiendo las anteriores el modelo
de redes cliente/servidor, definiendo ası́ el concepto de red de control. En
otras palabras, se ha migrado completamente hacia una estructura que has-
ta mediados de los ’90 era representativa de un sistema de comunicaciones
clásico. Esto permite que una red de control se comporte como un sistema de
comunicaciones, donde interactúan controladores, transductores, actuadores,
servidores y estaciones de operación, mediante el uso de protocolos abiertos
y propietarios.

8
Introducción 9

Los protocolos que comunican los equipos antedichos en general basan


su funcionamiento en el modelo en capas OSI (Open Systems Interconnect)
definido por ISO (International Standards Organization), ya que con el trans-
curso del tiempo los protocolos que se imponen en el mercado son los que
cumplen con algún estándar internacional. Será objeto de estudio de esta te-
sis uno de los protocolos mundialmente más utilizados en las redes de control,
el protocolo estándar Profibus.

Sin pérdida de generalidad, la información es transportada por un me-


dio inmerso en un entorno que inevitablemente genera alteraciones en la
señal representativa de los datos, debido a interferencias con señales elec-
tromagnéticas espurias y otras degradaciones debidas a la atenuación de las
ondas al producirse el fenómeno de propagación. Debido a esto, es desea-
ble introducir una técnica que mejore dicha condición, con la finalidad de
obtener mayores distancias de propagación y tasas de transmisión, sin degra-
dación de la calidad de la comunicación. Esto último no está contemplado
en la mayorı́a de los protocolos de comunicaciones industriales, los cuales
retransmiten en caso de error sin incursionar en mejoras de la integridad de
los datos. Aunque la retransmisión no altera significativamente la ingenerı́a
de control de procesos, conforme evolucionan las tecnologı́as se acrecienta la
funcionalidad montada sobre las redes existentes, por lo que no será deseable
en los próximos años retransmitir los datos en una red de control ya que esto
devendrá en una pérdida de sincronismo y deterioro de los recursos del siste-
ma. Adicionalmente, existe un compromiso actual entre la máxima distancia
de cable admitida para una determinada tasa de transmisión, el cual en la
mayorı́a de los casos prácticos se soluciona introduciendo equipos repetidores
o bien reduciendo la tasa de datos, desaprovechando nuevamente los recursos
del sistema.

Esto último será uno de los principales objetivos de esta tesis, buscando
entonces la maximización del producto de la distancia de cable y la tasa de
transmisión, mediante la introducción de la técnica de codificación turbo,
actualmente en uso en las tecnologı́as de redes de telefonı́a celular de tercera
generación (3G).

La viabilidad de la aplicación de la técnica propuesta en esta tesis se po-


tencia con la reciente introducción en el mercado de las versiones inalámbri-
cas de los protocolos industriales. Un ejemplo de éstos es Wireless Profibus,
el cual ha sido lanzado al mercado en el año 2002 y actualmente se encuentra
Introducción 10

en expansión en la industria.

Uno podrı́a cuestionarse si la aplicación de esta técnica deberı́a proponer-


se únicamente para los protocolos industriales inalámbricos, por ser éstos los
que sufren las mayores alteraciones en la señal transmitida debido a propagar-
se las ondas por un medio no guiado; sin embargo, existen ciertas aplicaciones
industriales en las cuales es imprescindible transmitir las señales eléctricas
por un medio guiado, debido a que pueden existir áreas con peligro de ex-
plosión, denominadas áreas Ex-Haz (Explosion Hazardous), en las cuales
la alimentación de los equipos allı́ situados debe ser transportada por el par
de cobre, sin admitirse fuentes de alimentación instaladas localmente1 .

De esta manera, en esta tesis se estudiará la aplicación de la técnica de


codificación turbo a protocolos industriales sobre medios guiados2 , es decir,
no inalámbricos.

1
Por dicha razón, la versión Profibus PA (Process Automation) transporta la alimen-
tación de los equipos en el mismo cable por el cual viajan los datos.
2
Especialmente guiados por cobre.
Capı́tulo 2

Códigos turbo

2.1. Introducción
Los códigos turbo fueron introducidos por primera vez por Berrou, Gla-
vieux y Thitimajshima en el año 1993. Dichos códigos ofrecen las ganancias
de codificación más elevadas de los códigos existentes hasta el momento,
trabajando de esta manera en las cercanı́as del lı́mite de Shannon, es de-
cir Pe = 0 para una Eb /N0 = 0dB 1 , ofreciendo una excelente mejora en el
funcionamiento del sistema2 . Las simulaciones presentadas originalmente se
encontraban a tan solo 0, 7dB del lı́mite teórico de Shannon, medido a una
BER = 10−5 , con 18 iteraciones en el proceso de decodificación.

Los fundamentos de esta técnica de codificación/decodificación se basan


en aumentar el umbral de decisión dura mediante un proceso de decodifi-
cación iterativa; para esto se utilizan técnicas de decisión suave entre los
diferentes decodificadores, decidiendo en última instancia mediante una de-
cisión dura con una confiabilidad mucho mayor que la que se tendrı́a sin
la implementación del lazo iterativo. Esta mejora trae aparejada una mayor
complejidad en el receptor y un mayor retardo introducido por el proceso de
decodificación.

A continuación se establecerán las bases teóricas de esta técnica, tanto


para el esquema de transmisión como para el de recepción. El modelo del
canal que vincula el transmisor y el receptor será discutido en el capı́tulo 4.
1
Ver Apéndice A sección A.1.
2
Los resultados obtenidos en el paper inicial fueron tan excepcionales que el mismo fue
rechazado por los estudiosos de la teorı́a de información y codificación; cuatro años más
tarde, en una nueva presentación, fue condecorado con el premio 1997 Information Theory
Society Paper Award otorgado por la IEEE Information Theory Society.

11
Códigos turbo 12

2.2. Esquema de transmisión


2.2.1. Codificador RSC
Los códigos turbo proponen un esquema de codificación RSC (Recursive
Systematic Convolutional) por tener éste una mejor respuesta de BER (Bit
Error Rate) que los códigos NSC (Non Systematic Convolutional) para bajos
valores de Eb/N o. El esquema de transmisión es como se muestra en la figura
2.1:

Figura 2.1: Codificador RSC de tasa k = 1/2 [5]

Se puede observar que el dato dk entrante al codificador genera dos sa-


lidas: Xk , denominada salida sistemática, e Yk , llamada salida codificada.
Dicho esquema transforma un dato de información en dos datos codificados,
duplicando ası́ el ancho de banda de transmisión, debido a que en el interva-
lo de tiempo en el cual se transmitirı́a un solo bit sin codificación, deberán
alojarse dos bits correspondientes al proceso de codificación. Estos dos bits
conllevan información redundante del antedicho bit de información, aunque
dicha redundancia de datos implica una duplicación del ancho de banda ne-
cesario, obteniéndose tempranamente la primera relación de compromiso en
el sistema propuesto; es decir, la duplicación de la información, que garantiza
una mayor integridad de los datos en el receptor, trae aparejada un sacrificio
del ancho de banda del sistema.

Debido a que por cada bit de información se transmiten dos bits de código,
la energı́a del bit de información Eb y la del bit de sı́mbolo3 Ec se relacionan
según:

Eb = 2Ec (2.1)
3
Algunos autores como por ej. [1] prefieren llamarlo bit de código.
Códigos turbo 13

Esta ecuación será de mucha utilidad al estudiar el esquema de recepción


en la sección 2.3.1.

2.2.2. Concatenación en paralelo


El esquema de codificación turbo propone la concatenación de dos codi-
ficadores RSC en paralelo, introduciendo el uso de un permutador de datos
o interleaver, y la técnica de selección de datos o puncturing.

El diagrama en bloques del transmisor puede observarse en la figura 2.2.

Figura 2.2: Concatenación en paralelo de codificadores RSC [5]

Debido a la naturaleza recursiva de los codificadores RSC, no es posible


terminar el trellis en el estado “todos ceros” simplemente transmitiendo una
cantidad de ceros igual a K − 1, siendo K la longitud restringida, como se
harı́a con un codificador NSC. Debido a esto, para llevar al trellis al estado
de todos ceros es necesario introducir una modificación en el esquema de
transmisión.

La figura 2.3 muestra un esquema donde se conmuta la llave a la posición


B cuando se desea terminar el trellis.

La técnica de terminación de trellis es válida para el primer codificador,


ya que el mismo opera sobre los datos de la fuente inalterados; sin embargo,
Códigos turbo 14

Figura 2.3: Esquema de terminación de trellis para un codificador RSC [10]

debido a que la presencia del interleaver la entrada que llevará al primer codi-
ficador al estado de todos ceros no hará lo propio con el segundo. El hecho de
no terminar el trellis del segundo codificador deriva en una sutil desmejora
de la respuesta de la curva de BER vs. Eb /N0 cuando el tamaño del bloque
es superior a 100.

En la figura 2.4 se observa que el beneficio de terminar ambos trellises es


de 0,2dB cuando el tamaño del bloque es 100, lo cual se puede considerar
una ganancia apreciable, mientras que en el caso de un tamaño de bloque de
1000, representado en la figura 2.5, la ganancia al terminar ambos trellises
asciende a tan sólo 0,02dB respecto del caso en que solamente se terminara
el trellis del codificador superior (es decir, el que no se encuentra afectado
por la presencia del interleaver).
Códigos turbo 15

Figura 2.4: BER con terminación de trellis, tamaño del bloque=100 [9]

Figura 2.5: BER con terminación de trellis, tamaño del bloque=1000 [9]

Por lo tanto, en el caso de trabajar con tamaños de bloques cercanos


a 1000, es despreciable la ventaja introducida por terminar ambos trellises,
comparada con la complejidad necesaria para lograr lo antedicho.

2.2.3. Interleaver
El interleaver mostrado en el transmisor de la figura 2.2 se ha introducido
con el fin de aumentar la distancia libre [1] del diagrama de trellis resultan-
Códigos turbo 16

te al tiempo que se esparcen los posibles errores en ráfaga en la fuente de


datos. De esta manera, el interleaver cumple la función de evitar que se ge-
neren palabras código de bajo peso (medido como la distancia de Hamming)
simultáneamente en todas las salidas codificadas. Esto último facilita la de-
tección y corrección de errores, ya que ningún camino del trellis de cada
codificador tendrá un peso menor a la distancia libre, y cuanto mayor sea
ésta, mayor será la confiabilidad de la decisión.

En el receptor, su función es diferente: es el encargado de poner en fase


los bits sistemáticos recibidos, no afectados por el interleaver del transmi-
sor, y la redundancia del segundo codificador, afectada por el interleaver del
transmisor. Adicionalmente, debido a que es necesario poner en fase las in-
formaciones extrı́nsecas intercambiadas por los decodificadores de manera de
ser interpretada correctamente, es el interleaver el encargado de cumplir esta
función.

Gracias a la presencia del interleaver en el receptor, es posible que ambos


decodificadores ejecuten el mismo código de detección independientemente
de la secuencia transmitida, sin necesidad de contemplar en la programación
de los mismos la existencia y naturaleza de los interleavers.

La naturaleza del interleaver puede ser muy variada; debido a que su fun-
ción es reordenar los datos, esta operación puede ser realizada de diferentes
maneras:

• Formando una matriz con el bloque de datos, leyéndola fila a fila y


escribiéndola columna a columna, efectuando una simple permutación,
denominado interleaver de bloque.

• Reordenando los datos de acuerdo a un algoritmo convolucional, utili-


zando registros de desplazamiento y multiplexores, denominado inter-
leaver convolucional o mutiplexado.

• En forma pseudoaleatoria, denominado interleaver pseudoaleato-


rio4 .

Los diversos tipos de interleavers son utilizados bajo distintas condicio-


nes y relaciones de compromiso. En general, un interleaver de bloque tiene
4
Algunos autores hablan de interleavers aleatorios; como ya se verá en la sección 2.3,
si realmente fueran aleatorios el receptor serı́a incapaz de reordenar los datos permutados,
lo cual es necesario para el correcto funcionamiento de la técnica de decodificación.
Códigos turbo 17

mejor performance que uno aleatorio para pequeños tamaños de bloques, es


decir menor a 100 bits, invirtiéndose lo antedicho para bloques de grandes
tamaños; adicionalmente, el interleaver aleatorio siempre tiene mejor factor
de dispersión de errores, denominado factor de spreading, que el interleaver
de bloques. En la figura 2.6 se muestra una comparación entre los diferentes
tipos de interleavers antes mencionados.

Figura 2.6: Comparación entre interleavers de bloque, convolucionales y pseu-


doaleatorios [12]

En general, la performance de los interleavers pseudoaleatorios mejora al


aumentar el tamaño del mismo, en perjuicio del retardo introducido por el
almacenamiento y procesamiento de los datos.

2.2.4. Selección de redundancia


En la figura 2.2 se muestra una llave selectora de datos de redundancia,
cuya función es evitar que el código transmitido sea de tasa k = 1/3, lo cual
implicarı́a una triplicación del ancho de banda necesario para transmitir los
datos que origina la fuente, convirtiéndolo en uno de tasa k = 1/2; dicha
Códigos turbo 18

técnica, denominada puncturing, trae aparejada la pérdida de uno de los da-


tos codificados por cada bit de fuente dk ; en esencia, uno de los dos bits de
redundancia es descartado en cada instante de tiempo.

El criterio de selección de datos de redundancia es tal que los bits de pari-


dad en las posiciones impares corresponden a las salidas del primer codifica-
dor, mientras que las posiciones pares corresponden a las salidas del segundo
codificador.

Supongamos que la fuente dk genera los datos:

d1 d2 d3 d4 ... dn dn+1

La secuencia codificada transmitida luego del proceso de puncturing es:

X1 , Y11 X2 , Y22 X3 , Y13 X4 , Y24 ... Xn , Y2n Xn+1 , Y1(n+1)

donde Xk = dk corresponde al dato sistemático, Y1k e Y2k son las salidas


del primer y segundo codificador, respectivamente, k indica el instante de
tiempo del bit transmitido y n es un instante de tiempo par arbitrario.

Los datos transmitidos ingresan al canal industrial y son afectados por


ruido y otras perturbaciones, para finalmente llegar al receptor. El canal in-
dustrial será tratado en el capı́tulo 4 cuando se describa una modelización
adecuada del mismo, mientras que el esquema de recepción y decodificación
turbo será tratado en la sección 2.3, presentándose la técnica de decodifica-
ción iterativa.

2.3. Esquema de recepción


Hasta este momento se ha visto el esquema de transmisión de datos, con la
introducción de dos codificadores RSC, un interleaver y un selector de datos.
A continuación se hará foco en el estudio del esquema receptor, cuya función
es recuperar en última instancia los datos originales producidos por la fuente
dk , en formato binario. El receptor opera sobre valores polares obtenidos
luego de la afección del canal ruidoso a los datos transmitidos descriptos en
la sección 2.2.
Códigos turbo 19

En la figura 2.7 se presenta el esquema de recepción de un decodificador


turbo 5 .

Figura 2.7: Esquema de decodificación turbo [6]

donde y 0 representa el dato sistemático recibido, y 1 e y 2 son las salidas


del primer y segundo codificador, respectivamente, todos afectados por ruido
del canal, Λe (1) es la información extrı́nseca6 comunicada por el primer
decodificador al segundo, Λe (2) es la información extrı́nseca comunicada por
el segundo decodificador al primero, y ûr es la estimación de los bits de fuente
luego de aplicar decisión dura en la última iteración.

Habiendo presentado el esquema, a continuación se explicará cada uno de


los componentes del decodificador turbo y los algoritmos que fundamentan
dicha técnica.

Fundamentalmente, la propiedad más significativa del proceso de decodi-


ficación turbo es su caracter iterativo7 el cual lo diferencia del resto de las
técnicas de decodificación conocidas.

5
En el paper original de Berrou, Glavieux y Thitimajshima [5] no está especificada la
entrada al segundo decodificador correspondiente a los datos sistemáticos recibidos pasados
por el interleaver.
6
En la sección 2.4.7 se explicará detalladamente el significado de esta magnitud.
7
El término Códigos Turbo hace alusión al mecanismo de realimentación cı́clica del
motor turbo.
Códigos turbo 20

2.3.1. Detección por sı́mbolo


2.3.2. LLR
Una magnitud que será de utilidad es la denominada Relación de Proba-
bilidad Logarı́tmica o LLR 8 para el bit bi , cuya definición es como sigue:
!
P (bi = +1)
L(bi ) = ln (2.2)
P (bi = −1)
La relación también puede ser definida para probabilidades condicionales.
Se define la relación LLR para el bit bi dado que se ha recibido la secuencia
Y:
!
P (bi = +1|Y )
L(bi |Y ) = ln (2.3)
P (bi = −1|Y )
La ecuación 2.3 es fundamental ya que es la que se evalúa a la entrada
y a la salida de los decodificadores de decisión suave que implementan la
decodificación turbo.

2.3.3. LLR del canal


Siguiendo una metodologı́a análoga a la establecida en la sección 2.3.2,
se puede expresar la relación LLR para la entrada del receptor yi habiéndose
transmitido el bit sistemático xi , también llamada relación LLR del canal 9 :
!
P (yi |xi = +1)
L(yi |xi ) = ln (2.4)
P (yi |xi = −1)
Operando se obtiene una relación que será de utilidad10 :

L(yi |xi ) = Lc yi (2.5)


donde Lc es denominada confiabilidad del canal y se relaciona con Eb /N0
utilizando la ecuación 2.1 según:
Ec Ec Eb
Lc = 2 2
=4 =2 (2.6)
σ N0 N0
8
Del inglés, Log-Likelihood Ratio.
9
En el caso de haber un esquema de modulación/demodulación, este valor representarı́a
la salida del detector óptimo, el cual produce valores positivos o negativos en función del
sı́mbolo analógico recibido [1].
10
Ver Apéndice A sección A.2
Códigos turbo 21

Esta magnitud será importante cuando la relación Eb /N0 sea elevada; de


no ser ası́, cobrará mayor importancia la denominada información extrı́nseca.

2.4. Algoritmos de decodificación


Hasta aquı́ sólo se ha incursionado en definiciones que por sı́ solas no
implementan ni explicitan ninguna técnica de decodificación. A continuación
se presentarán los algoritmos utilizados en la decodificación turbo.

Existen una diversidad de algoritmos utilizados para decodificar una se-


cuencia recibida, entre los cuales se destacan el algoritmo de Viterbi (VA),
Viterbi con decisión suave (SOVA), y los algoritmos de máxima probabilidad
a posteriori (MAP). Si bien uno podrı́a pensar que todos son aptos para
cualquier proceso de decodificación, se hará una breve comparación entre los
tres para justificar el por qué de la elección del último.

• El algoritmo de Viterbi (VA) minimiza el error de trama encontrando


la el camino con menor métrica en el trellis [1]. Sin embargo, este no
es apto para la decodificación turbo por producir decisiones duras,
lo cual, como se verá más adelante, es indeseable durante el proceso
iterativo.

• El algoritmo SOVA produce salidas suaves a partir de entradas suaves,


con la desventaja de una mayor complejidad de procesamiento que VA.
Esto no serı́a un inconveniente salvo por la existencia de un sesgo en
la decisión, indeseable a la hora de decodificar [12]. Se ha desarrollado
una versión mejorada de dicho algoritmo denominada Improved SOVA
que corrige dicho sesgo [15].

• El algoritmo MAP fue introducido en el año 1974 como una técnica


óptima para estimar probabilidades a posteriori (APP) para un pro-
ceso de Markov de estado finito sobre un canal discreto sin memoria
(DMC). Éste deriva de algoritmos propuestos por Chang y Hancock
para remover la interferencia intersimbólica (ISI). También se lo cono-
ce como algoritmo BCJR debido a sus cuatro creadores: Bahl-Cocke-
Jelinek-Raviv. Opera sobre entradas suaves, produciendo también sa-
lidas suaves. Es el algoritmo utilizado por excelencia en el proceso de
decodificación turbo, aunque se han introducido diferentes variaciones
del mismo, por razones que serán vistas a continuación.
Códigos turbo 22

2.4.1. Algoritmos MAP


El algoritmo de MAP es un algoritmo de recursión hacia adelante y atrás
que minimiza la probabilidad de error de bit. Lamentablemente el algoritmo
tiene serios problemas de convergencia11 en su versión original, por lo
que se han desarrollado las versiones Log-MAP y Max-Log-MAP12 , los
cuales posibilitan su implementación práctica.
El algoritmo de MAP calcula la APP para cada sı́mbolo de código produci-
do por un proceso de Markov, afectado por un canal ruidoso, a partir de la
observación Y a la entrada del receptor.

Sintetizando, un decodificador MAP ejecuta un doble algoritmo de Viterbi


[22], tanto hacia adelante como hacia atrás, para los diferentes caminos del
trellis , como puede verse en la figura 2.8.

Figura 2.8: Doble cálculo del algoritmo de Viterbi del algoritmo MAP

Los diferentes coeficientes utilizados como métricas para la decisión serán


detallados en las secciones subsiguientes.
11
Durante el desarrollo de las simulaciones para esta tesis me he enfrentado con dichos
problemas de convergencia. Estos se presentan inclusos para relaciones Eb /N0 muy bajas
(0,3dB) y al comenzar el proceso iterativo (en la tercera iteración).
12
Esta versión es la más utilizada en la práctica aunque teóricamente es considerada
subóptima por utilizar una aproximación cuya validez es relativa, como se verá más ade-
lante.
Códigos turbo 23

2.4.2. LLR del bit dk


Sean P (dk = +1|Y ) y P (dk = −1|Y ) la probabilidad de que la fuente
haya producir un bit de información ’1’ y ’0’ dada la observación Y , respec-
tivamente, se puede definir la LLR para el k-ésimo bit como:

P (dk = +1|Y )
Λk = ln (2.7)
P (dk = −1|Y )
Es simple ver que si Λk es mayor que cero, finalmente se decidirá que se
ha enviado un ’1’, mientras que si es menor que cero se decidirá por cero. Es
decir:
(
1 si Λk > 0
dˆk = (2.8)
0 si Λk < 0
Consideremos una fuente de Markov con U estados, u = {0, 1, 2, ..., U −
1}, y supongamos que el estado sk pertenece al conjunto de estados u. El
algoritmo de MAP calcula las APPs encontrando primero la probabilidad
de transición de estado de la fuente de Markov P (sk → sk+1 |Y ) habiendo
recibido la secuencia Y . El término sk representa el estado de la fuente de
Markov en el tiempo k mientras que sk → sk+1 simboliza la transición de la
fuente del estado sk al sk+1 en el tiempo k + 1, siendo la probabilidad de la
transición cero si ésta no es posible 13 .
Usando el teorema de Bayes, y siguiendo la notación utilizada en [12], dicha
probabilidad se puede expresar como:

P (sk−1 → sk , Y )
P (sk−1 → sk |Y ) = (2.9)
P (Y )
Se define, según [5], P (sk−1 → sk , Y ) como producto de tres factores:

P (sk−1 → sk , Y ) = αk−1 (sk−1 )γk (sk−1 → sk )βk (sk ) (2.10)


A continuación se explicarán estos tres coeficientes fundamentales en esta
teorı́a de detección.

2.4.3. El coeficiente γk
El término γk+1 (sk → sk+1 ) simboliza la métrica de la rama del trellis
asociada con la transición del estado sk al sk+1 ; el coeficiente γk puede ser
calculado según [5]:
13
Recordemos que en una fuente de Markov no todas las transiciones son posibles desde
un estado arbitrario sm a otro sn ; basta con trazar el diagrama de trellis para darse cuenta
cuáles están permitidas en función de las entradas al codificador.
Códigos turbo 24

γk (sk−1 → sk ) = P (yk |xk )P (xk |sk , sk−1 )P (sk , sk−1 ) (2.11)


El primero de estos tres términos, P (yk |xk ) puede ser calculado a partir
de la observación yk y conocimiento del trellis de la fuente de Markov. Este
simboliza la probabilidad de recibir la medición yk dado que entró al canal,
es decir se transmitió, el sı́mbolo xk .

El segundo término, P (xk |sk , sk−1 ) es necesariamente 1 o 0, debido a que


dado que si la fuente de Markov se encontraba en el estado sk−1 en el tiempo
k − 1 y evolucionó al estado sk en el tiempo k, el bit xk queda determinado
por dicha transición, debido a que el codificador RSC es una máquina de
estados determinı́stica. Debido a esto, se puede omitir el mismo teniendo en
cuenta la salida xk que la transición de estados genera14 .

El tercer término P (sk , sk−1 ) es equivalente a calcular la probabilidad a


priori 15 de un bit de fuente dk , es decir:

P (sk , sk−1 ) = P (dk ) = C1 edk L(dk )/2 (2.12)


Entonces, reescribiendo la ecuación 2.11 usando la ecuación 2.12 se ob-
tiene:

γk (sk−1 → sk ) = P (dk )P (yk |xk ) (2.13)


Finalmente operando se obtiene16 :
Lc
γk (sk−1 → sk ) = Cedk L(dk )/2 e y d
2 1k k γk extr (sk−1 → sk ) (2.14)
con:
Eb Pm
(yik xik )
γk extr (sk−1 → sk ) = e 2σ (2.15)
2 i=2

2.4.4. El coeficiente αk
El coeficiente αk simboliza la probabilidad conjunta de recibir la secuencia
Y y que la fuente de Markov se encuentre en el estado sk :
14
Para ser estrictos, la transición de estados no genera la salida sistemática xk sino que
la entrada dk = xk es la que se encarga de producir la transición de estados; sin embargo
es válido el análisis de transiciones de estados desde el punto de vista de la salida.
15
Ver Apéndice A sección A.3
16
Ver Apéndice A sección A.5
Códigos turbo 25

αk (sk ) = P (Y, sk ) (2.16)


Desarrollando la expresión en la ecuación 2.16 se obtiene17 :
U
X −1
αk (sk ) = αk−1 (sk−1 )γk (sk−1 → sk ) (2.17)
sk−1 =0

Como puede observarse, este coeficiente se calcula utilizando una recur-


sión hacia adelante, a diferencia del coeficiente βk , cuya expresión será intro-
ducida a continuación.

2.4.5. El coeficiente βk
Este coeficiente simboliza la probabilidad de recibir la secuencia Y dado
que la fuente de Markov se encuentra en el estado sk :

βk (sk ) = P (Y |sk ) (2.18)


Trabajando de manera similar a lo hecho para el coeficiente αk , se obtiene
la siguiente expresión18 :
U
X −1
βk (sk ) = βk+1 (sk+1 )γk+1 (sk → sk+1 ) (2.19)
sk+1 =0

Comparando con la expresión de αk en la ecuación 2.17, se ve que la


ecuación 2.19 es una recursión hacia atrás.
Habiéndose encontrado los coeficientes αk y βk para todos los estados del
trellis quedan determinadas las APPs de cada bit; las mismas se relacionan
con las probabilidades de transición de estados según:
X
P (dk = i|Y ) = P (sk−1 → sk |Y ) (2.20)
Si

donde i = {0, 1} y Si es el conjunto de todas las transiciones del estado


sk−1 al estado sk asociadas al bit dk = i.

2.4.6. Λk : su relación con αk , βk y γk


Volviendo a la definición introducida en la ecuación 2.7, se procede a
calcular la LLR del k-ésimo bit, Λk , como:
17
Ver Apéndice A sección A.6.
18
Ver Apéndice A sección A.7.
Códigos turbo 26

Λk = L(dk |Y ) (2.21)
αk−1 (sk−1 )γk (sk−1 → sk )βk (sk )
P
Λk = ln PS1 (2.22)
S0 αk−1 (sk−1 )γk (sk−1 → sk )βk (sk )

La ecuación 2.22 es fundamental debido a que es la base del proceso


de decodificación iterativa, y es la que se deberá implementar, aunque no tal
como se la expone en esta ecuación por presentar problemas de convergencia,
en el receptor. Finalmente, al terminar el proceso iterativo, la decisión del
bit dˆk se realiza tal como se ha expuesto en la ecuación 2.8, notándose que el
signo de Λk determina la estimación del bit dk transmitido, mientras que su
módulo establece la confiabilidad de esta decisión. Entonces, es objetivo de la
técnica de decodificación turbo incrementar el módulo de dicha magnitud
con el fin de mejorar la confiabilidad de la decisión, obteniéndose una relación
de compromiso entre el retardo de procesamiento y la confiabilidad.

2.4.7. Información extrı́nseca


En esta sección se introducirá el concepto más importante y abstracto de
esta teorı́a: la información extrı́nseca. Cuando uno se adentra en el tema de
codificación turbo, éste es tal vez el concepto que más demora en entender,
fundamentalmente por su origen e impacto en el proceso de decodificación.

Consideremos la ecuación 2.22, reescribiéndola en función de sus compo-


nentes, y reemplazando dk por +1 en el numerador y por −1 en el denomi-
nador:

αk−1 (sk−1 )γk (sk−1 → sk )βk (sk )


P
Λk = ln PS1 (2.23)
S0 αk−1 (sk−1 )γk (sk−1 → sk )βk (sk )
Lc
y
αk−1 (sk−1 )eL(dk )/2 e → sk )βk (sk )
P
S1 2 1k γk extr (sk−1
= ln P −Lc (2.24)
y1k
αk−1 (sk−1
S0 )e−L(dk )/2 e 2 γk extr (sk−1 → sk )βk (sk )
= L(dk ) + Lc y1k + Le (dk ) (2.25)

con:

→ sk )βk (sk )
P
αk−1 (sk−1 )γk extr (sk−1
Le (dk ) = ln PS1 (2.26)
S0 αk−1 (sk−1 )γk extr (sk−1 → sk )βk (sk )
Le (dk ) es la denominada información extrı́nseca, la cual cada decodifica-
dor le proporciona al otro sobre cada bit de información dk ; Le (dk ) es distinto
Códigos turbo 27

para cada decodificador debido a que el conjunto de bits a partir del cual se
formaron los bits de código es diferente para cada codificador, por la exis-
tencia del interleaver. Es importante notar que la información extrı́nseca es
información ganada a partir del proceso de decodificación, y no a partir de
las mediciones del canal yik .

Es interesante recalcar una propiedad observable en la ecuación : cuando


la relación Eb /N0 sea grande, predominará el término Lc y1k , por lo que Λk
será calculada a partir de la observación del canal del bit sistemático y1k ;
sin embargo, cuando la relación Eb /N0 sea pequeña, como suele serlo en los
ambientes industriales, Λk será determinada a partir del cálculo de la in-
formación extrı́nseca Le (dk ). Este es un dato no menor, ya que nos indica
que para ambientes hostiles con un alto nivel de ruido electromagnético, la
confiabilidad de la decisión será dada por la información extrı́nseca, la cual
incrementa al avanzar el proceso iterativo de decodificación.

De esta manera, cada decodificador proporciona a su par la siguiente


información:

Le (dk ) = Λk − L(dk ) − Lc y1k (2.27)


Le (dk ) es utilizado por el decodificador actuante (es decir, el que recibe
este parámetro) como información a priori para cada bit dk , para la nueva
iteración.

Como conclusión, la técnica de decodificación turbo basa su funciona-


miento en el incremento de la información a priori de cada bit dk , mediante
el uso de un proceso iterativo.

La información extrı́nseca es, en cierta forma, una medida de la confiabi-


lidad de cada decodificador al estimar los bits de mensaje dk transmitidos,
basado solamente en los bits de paridad recibidos, y el conocimiento de la
estructura de trellis de cada codificador. Los decodificadores están condicio-
nados a intercambiar solamente información extrı́nseca debido a que de esta
manera se suprime el sesgo introducido por la información sistemática reci-
bida del canal por cada decodificador, afectada cada uno por un evento de
ruido diferente, tal como se verá en la sección 2.4.8.
Códigos turbo 28

2.4.8. Decodificación iterativa


El proceso iterativo tiene como finalidad incrementar la información extrı́nse-
ca de cada bit dk aumentando ası́ la confiabilidad de la decisión a tomar luego
de la última iteración, lógicamente utilizando decisiones duras.

Como se mencionó en la sección 2.4.7, cada decodificador toma la infor-


mación extrı́nseca Le (dk ) proporcionada por su par como información a priori
L(dk ) para la siguiente iteración. Según [7], se entiende por información a
priori a aquella utilizada por el decodificador y que no proviene ni de los
bits recibidos del canal, ni de las restricciones del proceso de codificación, es
decir, conocimiento de la estructura de trellis. Es inmediato notar que el pri-
mer decodificador no posee información a priori de los bits dk en la primera
iteración, por lo que, inicialmente, el ‘0’ y el ‘1’ son equiprobables para los k
bits de fuente. Es decir, para la primera iteración del primer decodificador se
cumple: P (dk = +1) = 1 − P (dk = −1) = 0,5 , por lo que, refiriéndonos a la
ecuación 2.2 y reemplazando dk = bi , resulta L11 (dk ) = 0, donde el subı́ndice
indica el número de decodificador, y el superı́ndice el número de iteración.

Con la información a priori (por ahora nula) y la del canal (bit sistemáti-
co y de redundancia), el primer decodificador genera la APP del bit dk , Λ11k ,
la cual es usada en la ecuación 2.27 para producir la información extrı́nseca
que utilizará el segundo decodificador como información a priori, L12 (dk ). Di-
cha información extrı́nseca producida por el primer decodificador deberá ser
procesada por un interleaver de la misma naturaleza 19 que el utilizado en el
transmisor. Esto debe realizarse para poner en fase la información entregada
por el primer decodificador al segundo, ya que el segundo opera sobre bits
sistemáticos y de redundancia permutados; de esta manera, el segundo deco-
dificador realiza la siguiente asignación: L12 (dk ) = I{L1e1 }, donde I{·} simbo-
liza el proceso de interleaving. Como se explicó en la sección 2.2.4, los bits
de paridad son eliminados alternativamente, por lo que deberá completarse
con ceros aquellas posiciones donde se ha descartado datos de redundacia;
adicionalmente, es fácil notar que la cantidad de bits sistemáticos emitidos
(y recibidos) duplica a la cantidad de bits de redundancia entregados por
cada codificador, por lo que en el proceso inverso deberá rellenarse con ceros
en las posiciones donde no hayan habido datos transmitidos por alguno de
los codificadores, ya que el algoritmo opera con vectores de bits de canal de
igual dimensión.

19
Es por esta razón que el interleaver no puede ser aleatorio, sino que debe ser pseudo-
aleatorio, ya que es necesario conocer exactamente la forma de reproducirlo en el receptor.
Códigos turbo 29

Siguiendo el mismo razonamiento, siempre para la primera iteración, el


segundo decodificador considera como información a priori la entregada como
información extrı́nseca por el primero, pasada por el interleaver, y junto con
las mediciones del canal (mismo bit sistemático que el primer decodificador,
aunque pasado por el interleaver por la razón antedicha, y su correspondiente
bit de redundancia o cero, si éste ha sido suprimido en el transmisor) calcula
una nueva información extrı́nseca para cada bit dk , Λ12k , la cual deberá ser
pasada por un deinterleaver encargado de reordenar los datos para que pueda
ser interpretada por el primer decodificador como información a priori en la
segunda iteración. Éste repite la operación inicial, aunque ahora considera la
información a priori entregada por el segundo decodificador luego del dein-
terleaver, es decir: L21 (dk ) = I{L1e2 }−1 , donde I{·}−1 simboliza el proceso de
deinterleaving.

De esta manera, se incrementa la confiabilidad de la decisión debido a que


la información a priori de cada bit dk crece, en módulo, y con signo en fun-
ción de cada bit transmitido, positivo para dk = +1, negativo para dk = −1,
conforme lo hace la cantidad de iteraciones realizadas.

Este proceso iterativo se encuentra resumido en la figura 2.9, donde Yjp


simboliza la información del canal del decodificador j, con j = {1, 2}, para
la iteración número p.

2.4.9. Log-MAP y Max-Log-MAP


Como se ha visto en la sección 2.4.1, los algoritmos MAP presentan pro-
blemas de convergencia, inestabilidad numérica y gran complejidad de imple-
mentación. Para solucionar este inconveniente, se han desarrollado versiones
logarı́tmicas de estos algoritmos, ya que trabajar con logaritmos transforma
los productos en sumas y se eliminan las exponenciales, quedando sólo sus
exponentes como sumandos. Sin embargo, debido a que los algoritmos im-
plementan sumas de exponenciales, a las cuales se aplicarán logaritmos, es
necesario encontrar una aproximación adecuada a dicha operación. Por dicha
razón se utiliza la siguiente aproximación:

ln (ex + ey ) = max(x, y) + fc (|y − x|) (2.28)


donde fc (u) = ln(1 + e−u ).
Códigos turbo 30

La suma se realiza entonces tomando el máximo de los sumandos, y corri-


giendo con un factor en función de la diferencia de los mismos.

Figura 2.9: Proceso de decodificación iterativa [7].


Códigos turbo 31

La versión Max-Log-MAP es considerada subóptima debido a que apro-


xima la operación tomando solamente el máximo de los sumandos, lo cual
es válido, especialmente cuando los sumandos son desiguales20 . Sin embar-
go, la versión Log-MAP considera el factor de corrección fc , por lo que su
performance es igual a la de la versión MAP. Generalmente se tabulan una
cierta cantidad de valores de |y − x| en una tabla de manera de no realizar
el cálculo del factor de corrección durante el proceso de decodificación.

Con las aproximaciones antedichas, γk (sk−1 → sk ), αk−1 (sk−1 ) y βk (sk )


se tranforman en:

γ̄k (sk−1 → sk ) = ln γk (sk−1 → sk ) (2.29)


= ln P (dk ) + ln P (yk |xk ) (2.30)
ᾱk (sk ) = ln αk (sk ) (2.31)
U
X −1
= ln ᾱk−1 (sk−1 )γ̄k (sk−1 → sk ) (2.32)
sk−1 =0

= máx [ᾱk−1 (sk−1 ) + γ̄k (sk−1 → sk )] (2.33)
sk−1 ∈A

β̄k (sk ) = ln βk (sk ) (2.34)


U
X −1
= ln β̄k+1 (sk+1 )γ̄k (sk → sk+1 ) (2.35)
sk+1 =0

= máx ∗ [β̄k+1 (sk+1 ) + γ̄k (sk → sk+1 )] (2.36)


sk+1 ∈B

donde la operación máx∗ [.] simboliza máx(x, y) para el algoritmo Max-


Log-MAP y máx(x, y) + fc (|y − x|) para la versión Log-MAP. El conjunto
A contiene a todos los estados sk−1 conectados al estado sk , mientras que el
conjunto B contiene a todos los estados sk+1 conectados al estado sk .

Habiendo calculado ᾱk (sk ) y β̄k (sk ) para todos los estados del trellis, se
obtiene la APP del bit dk como:

Λk = máx∗ [ᾱk−1 (sk−1 ) + γ̄k (sk−1 → sk ) + β̄k (sk )] +


S1

− máx∗ [ᾱk−1 (sk−1 ) + γ̄k (sk−1 → sk ) + β̄k (sk )] (2.37)


S0

donde i = {0, 1} y Si es el conjunto de todas las transiciones del estado


sk−1 al estado sk asociadas al bit dk = i.
20
Si |y − x| ≥ 2,5 , se puede considerar que e−|y−x|  1, pudiendo omitirse el factor de
corrección fc .
Códigos turbo 32

2.4.10. Inicialización de ᾱk y β̄k


Supongamos una trama de longitud N , y asumamos que cada codificador
constituyente comienza en el estado “todos ceros”. Para el tiempo k = 0, se
inicializa αk según:
(
1 si j = 0
α0 (sj,0 ) = (2.38)
0 6 0
si j =
donde sjk simboliza el número de estado j en el tiempo k.
Análogamente, para el tiempo k = N , se inicializa βk según:
(
1 si j = 0
β0 (sj,N ) = (2.39)
0 6 0
si j =
Si no se termina el trellis, entonces todos los estados tienen la misma
probabilidad de ser el estado final, por lo que se inicializa βk según:

β0 (sj,N ) = 1 ∀j (2.40)
Observando las ecuaciones 2.31 y 2.34, es inmediato notar que al aplicar
logaritmo natural, las condiciones iniciales para ᾱk y β̄k se transforman en:
(
0 si j = 0
ᾱ0 (sj,0 ) = (2.41)
−∞ 6 0
si j =
(
0 si j = 0
β̄0 (sj,N ) = (2.42)
−∞ 6 0
si j =
Si no se termina el trellis en el estado de “todos ceros”, resulta:

β̄0 (sj,N ) = 0 ∀j (2.43)

2.5. Curvas BER vs. Eb/N0


En la figura 2.10 se presenta la curva de BER vs. Eb /N0 obtenida en
el paper original de codificación turbo [5]. Si bien dichas gráficas varı́an en
función del tamaño y tipo de interleaver y la longitud de la trama, el mismo
puede ser usado como referencia de las ganancias de codificación aportadas
por la técnica de codificación turbo.

Refiriéndonos a la curva BER vs. Eb /N0 sin codificación expuesta en la


figura 5.2 (capı́tulo 5), es importante notar en la figura 2.10 que para una
BER = 10−5 se obtiene una ganancia de codificación de 8,85dB, para 18
Códigos turbo 33

iteraciones, empeorando la misma conforme disminuye la cantidad de itera-


ciones.

Otra particularidad importante de destacar es que para muy baja rela-


ción Eb /N0 (menor a 0,5dB) la transmisión sin codificación otorga una curva
de BER vs. Eb /N0 mejor que la transmisión con codificación debido a que
la redundancia introducida no permite obtener una mejora en la respuesta
para tan bajas relaciones Eb /N0 [1].

Figura 2.10: BER vs Eb /N0 para un código de tasa 1/2 y un tamaño de


interleaver de 256x256 [5]
Capı́tulo 3

Protocolo Profibus

3.1. Introducción
En este capı́tulo se introducirán los aspectos relevantes de los sistemas de
bus de campo Profibus. Se brindará una breve descripción de su arquitectura,
las diferentes capas fı́sicas, los servicios de capa de enlace, los protocolos de
capa MAC y de enlace, y las propiedades más importantes con respecto al
comportamiento en tiempo real. Los servicios de capa de enlace (y su interfaz)
son el común denominador del cableado Profibus existente.

3.2. El sistema bus de campo Profibus


Profibus es un estándar alemán desde 1991, el cual también fue adoptado
como estándar europeo en 1996. Profibus está diseñado para ofrecer servicios
de tiempo real en ambientes industriales hostiles. Ha ganado un uso genera-
lizado, la organización internacional de usuarios de Profibus 1 establece que
hay más de 2 millones de dispositivos Profibus en más de 200000 instalacio-
nes hechas en fábricas y procesos de automatización, haciendo de Profibus el
bus de campo más popular de Europa [14].

En esta sección se presentan las caracterı́sticas más relevantes de Profibus.

3.2.1. Arquitectura
Profibus apunta a una amplia gama de aplicaciones en fabricación y con-
trol. Ofrece diferentes perfiles, por ej. diferentes grupos de protocolos y ser-
vicios de capa de aplicación. Los perfiles de comunicación denotan diferentes
1
Para más información, visitar www.profibus.org .

34
Protocolo Profibus 35

grupos de protocolos, mientras los perfiles de aplicación distinguen entre los


diferentes grupos de servicios de capa de aplicación, y los perfiles fı́sicos dis-
tinguen entre diferentes tecnologı́as de transmisión.

El perfil de comunicaciones de Profibus-DP (Periferia descentralizada)


está diseñado para conectar diferentes actuadores de sensores (o esclavos) a
un solo controlador, usando un esquema de votación cı́clica (en inglés, cyclic
polling) con una sola estación maestro. La estación maestro es la única esta-
ción que controla el medio. En este perfil sólo las capas uno (capa fı́sica) y
dos (MAC y capa de enlace) del modelo de referencia OSI están cubiertas.
Las unidades de capa de aplicación usan la interfaz de capa de enlace para
obtener servicios de esta última.

El perfil de comunicaciones de Profibus-FMS (Especificación de mensaje


bus de campo) está destinado a la distribución de controles de aplicación, con
muchos nodos inteligentes. El rol de ser la estación maestro es alternado cada
vez entre un grupo de estaciones. Profibus-FMS cubre la capa uno, dos y siete
del modelo de referencia OSI (figura 3.1). El PHY cubre la transmisión fı́sica a
nivel de bit. La capa de enlace de información de bus de campo (FDL) provee
funcionalidad MAC y transmisión de información semi-confiable (funcionali-
dad de capa de enlace). La capa de aplicación está subdividida en servicios
de capa de aplicación o Especificación de mensaje de bus de campo (FMS),
y la interfaz de la capa baja, esta última proveyendo por ejemplo, dirección
de conexión. La parte de la pila del protocolo Profibus que trata con inter-
cambio de información puede verse en la Figura 3.1.

Para ambos perfiles de comunicación, Profibus es una tecnologı́a LAN,


donde un número de estaciones comparten un mismo medio fı́sico. La falta de
funcionalidad de ruteo y un esquema de direccionamiento apropiado impide
la conexión de diferentes redes LAN Profibus para formar redes más grandes.

Por su generalidad, se hará mayor foco en la descripción de Profibus-FMS


ya que cubre el caso de múltiples estaciones maestro. Las capas fı́sicas y de
enlace coinciden en Profibus DP y FMS, por que el objeto de esta tesis no se
verá afectado por la descripción del funcionamiento de las capas superiores.

3.2.2. Capa fı́sica


Profibus está definido por diferentes capas fı́sicas: una versión RS-485,
una versión en fibra óptica y una versión especial (IEC 1185-2) para ser usa-
da en ambientes explosivos.
Protocolo Profibus 36

Figura 3.1: Pila del protocolo Profibus[14]

La versión RS-485 usa transmisión serie sobre un par trenzado blindado


(STP). Dos tipos de cables están estandarizados, sin embargo, uno de ellos
ya no es usado.
La información está codificada sin retorno a cero (NRZ). La transmisión es
orientada a byte; para soportar la adecuada sincronización de bytes las ca-
pas MAC se agregan un bit de inicio y parada a cada byte de información,
imponiendo un mı́nimo de cambios de niveles de señal. La unidad básica de
la topologı́a fı́sica es conocida como segmento y tiene una estructura bus, es
decir, todas las estaciones adjuntas a un segmento ven las mismas señales.
El máximo número de estaciones en un mismo segmento es 32.

Los segmentos pueden ser unidos usando repetidores, un máximo de tres


Protocolo Profibus 37

repetidores está permitido entre cualquier par de estaciones.

El esquema de direccionamiento de Profibus restringe a 127 el número de


estaciones en una misma LAN Profibus con múltiples segmentos.

El grupo de bit-rates disponibles versus la distancia máxima entre cual-


quier par de estaciones puede verse en el cuadro 3.1.

Cuadro 3.1: Relación entre el bit-rate y la distancia del


cable para RS-485 PHY y cable tipo A [20]

Bitrate (kbps) 9.6 19.2 93.75 187.5 500 1500 12000


máx. distancia (m) 1200 1200 1200 1000 400 200 100

La versión IEC 1185-2, Profibus PA (Process Automation), usa un bit-rate


fijo de 31,25kbps y codificación Manchester sobre cable STP, alcanzando una
distancia máxima de 1900 metros por segmento, lo que permite su utilización
en plantas industriales de tamaño considerable. Esta versión le permite a los
dispositivos pequeños obtener su alimentación de energia desde los cables.
Más aún, sus propiedades eléctricas son tales que las fallas de hardware no
crean chispas. Es por esto que los dispositivos de campo cableados pueden
ser usados en ambientes explosivos. El cableado permite topologı́as de bus y
árbol, nuevamente la unidad básica es un mismo segmento. Los segmentos
puede ser conectados por medio de repetidores. Los acopladores de segmen-
tos especiales permiten la conexión de segmentos IEC 1185-2 con segmentos
RS 485, mientras los dispositivos de enlace subsumen a un mismo segmento
IEC 1185-2 dentro de una sola estación RS 485.

La versión en fibra óptica está intencionada para uso en ambientes hosti-


les, es decir, donde existen fuertes interferencias electromagnéticas. Pueden
emplearse diferentes tipos de fibra (monomodo, multimodo) en una topologı́a
de anillo.

Como se ha mencionado anteriormente, Profibus ofrece servicios de capa


de enlace, sin embargo, el alcance de esta tesis se limita a la capa fı́sica, por
lo que la descripción de dichos servicios son incluidos en el apéndice C de
manera de poder referirnos a ellos sin perder el foco principal de este trabajo.

A continuación, se realizará una descripción de los formatos de tramas


posibles en Profibus, debido a que es de interés conocer sus tamaños y dis-
posición de bytes.
Protocolo Profibus 38

3.2.3. Formatos de tramas


Profibus soporta cinco tipos diferentes de tramas, como puede verse en
la figura 3.2. Excepto la trama de acuse de recibo corto (SC) de un byte de
largo, todas los otros tipos de trama comienzan con un delimitador de inicio
(cada tipo de trama con uno diferente), y lleva consigo al menos un byte de
dirección de destino (DA) y un byte de dirección fuente. El byte de control
de trama (FC) tiene diferentes significados cuando es transmitido desde la
iniciadora a la estación que responde y viceversa. Cuando es enviado a la
iniciadora, el byte FC lleva consigo información de control: FCB y FCV, una
etiqueta de tipo de servicio (SDA, SDN, SRD, manejo de trama), o el código
de respuesta en caso de tramas de acuse de recibo (acuses de recibo positivos
o negativos, códigos de error para indicar tramas de pedidos malformados,
falta de memoria etc.). El byte de secuencia de chequeo de trama (FCS) es
una simple suma de comprobación, computada por la trama sin información,
la trama con capacidad de información fija y la trama con capacidad de in-
formación variable. El byte FCS es la suma MODULO-256 de todos los bytes
localizados entre el campo DA (inclusive) y campo FCS de la trama. El acuse
de recibo corto y la trama de token no tienen ninguna suma de comprobación.

La versión RS485 de Profibus usa transmisión serie con codificación NRZ.


Cada byte de información es transmitido con once bits: un bit de inicio, un
bit de parada, ocho bits de información y un bit de paridad.

A continuación en la figura 3.2 se observan los diferentes tipos de tramas


del protocolo Profibus, según los diferentes tipos de mensajes enviados por
los dispositivos. En el apéndice C se detallan dichos mensajes y su secuencia
cronológica y orden de prelación. Nótese en dicho apéndice que el proto-
colo utiliza conceptos de intercambios de mensajes conocidos de anteriores
protocolos, como por ejemplo LAP-B y TCP.
Protocolo Profibus 39

Figura 3.2: Formatos de tramas Profibus [14]

3.3. Ejemplo de red Profibus


En esta sección se muestra un ejemplo práctico de una red de control
integrada a una red TCP/IP sobre Ethernet.

Se distinguen claramente dos redes: la red cliente/servidor de sobre Ether-


net TCP/IP, desde la cual el usuario u operador puede acceder a mediciones
en tiempo real, configuraciones y tomar acciones desde plataformas con di-
versos sistemas operativos; en contraposición, la red de control se encarga
de comunicar equipos de campo, controladores y otros dispositivos, siendo
esta última red objeto de estudio de esta tesis. Los protocolos que corren
sobre esta red pueden ser variados: Profibus, Modbus, Fieldbus Foundation,
HART, entre los más difundidos. El esquema de la figura 3.3 se limita a una
red donde se comunican equipos Profibus DP y PA con un controlador que
interactúa con ambas redes.
Protocolo Profibus 40

Figura 3.3: Ejemplo práctico de una red Profibus [21]


Capı́tulo 4

Canal de comunicaciones

4.1. Introducción
Como definición genérica, el canal de comunicaciones es el medio fı́sico
utilizado para enviar una señal del transmisor al receptor. Se puede decir que
el canal de comunicaciones provee de una conexión entre el transmisor y el
receptor.

Entre los diferentes medios fı́sicos se destacan:

• Guiados

Canales alámbricos Las lı́neas de par trenzado y de cable coaxil son


canales electromagnéticos guiados que proveen de un ancho de
banda relativamente modesto. Los primeros alcanzan un ancho de
banda del orden del megahertz, mientras que los segundos tienen
un ancho de banda utilizable de cientos de megahertz. Las señales
transmitidas por medios guiados sufren de distorsión de amplitud
y fase, debido al fenómeno de dispersión, presente en medios en los
cuales la velocidad de grupo no es igual a la velocidad de fase de
las ondas1 , a lo que se suma ruido aditivo. Adicionalmente, para
el caso de par trenzado, ocurre el fenómeno de diafonı́a (crosstalk )
entre canales fı́sicamente adyacentes. Para compensar las distor-
siones de amplitud y fase, suelen utilizarse filtros ecualizadores de
canal entre el transmisor y el receptor.
1
Esto se debe a que el módulo de la respuesta en frecuencia del canal no es constante
en amplitud, ni su fase lineal para todas las frecuencias. Se dice entonces que el medio es
dispersivo.

41
Canal de comunicaciones 42

Canales de fibra óptica La fibra óptima ofrece un ancho de banda


varios órdenes de magnitud mayor que el cable coaxil. Son guı́as
de ondas que basan su funcionamiento en el fenómeno de reflexión
total debido a la diferencia de permitividades relativas entre la
fibra (de vidrio y plástico) y el aire. Dependiendo del material del
cual estén fabricadas, variarán la atenuación y dispersión que éstas
presenten, obteniéndose en los mejores casos cientos de kilómetros
de distancia de propagación de las ondas lumı́nicas. El transmisor
generalmente es un láser o un diodo LED que modula la intensidad
lumı́nica con la señal transmitida, para una determinada longitud
de onda, siendo el receptor un fotodiodo que produce una salida
eléctrica en función de la intensidad lumı́nica recibida. Las fuentes
de ruido en los canales de fibra óptica son los fotodiodos y los
amplificadores electrónicos.

• No guiados

Canales de electromagnéticos inalámbricos En un sistema de comu-


nicaciones inalámbrico, la energı́a es acoplada al medio de propa-
gación mediante el uso de una antena, la cual adapta las señales
eléctricas del medio guiado al no guiado, y viceversa, cuyas dimen-
siones dependen de la frecuencia de trabajo. Los problemas que
presentan las señales transmitidas por este canal varı́an según la
frecuencia de operación; si se transmiten señales de muy baja fre-
cuencia (VLF), el globo terrestre actúa como guı́a de ondas para
estas señales, siendo las tormentas eléctricas una fuente de ruido;
si se trabaja en frecuencias medias (MF), las ondas se propagan
por la superficie terrestre, como es el caso de las ondas de AM2 ,
siendo las fuentes de ruido el ruido atmosférico, el inducido por
el hombre y el ruido térmico de los componentes en el receptor;
las ondas de alta frecuencia (HF) se propagan por el espacio libre,
sufriendo el fenómeno de desvanecimiento por caminos múltiples
(multipath), también llamado desvanecimiento de Rayleigh, debi-
do a la recepción de la misma señal por diferentes caminos con
diferentes fases y amplitud atenuada. En HF, las fuentes de ruido
son el ruido térmico y atmosférico; Para señales de muy alta fre-
cuencia (VHF), el modo de propagación es lı́nea de vista (LOS), lo
cual indica literalmente que el transmisor y el receptor deben ver-
2
Las ondas de AM también se propagan por rebote en la capa ionosférica, alcanzando
mayor distancia de propagación durante la noche.
Canal de comunicaciones 43

se en lı́nea recta para establecer el enlace3 . Tanto en VHF como


en UHF (ultra alta frecuencia), las principales fuentes de ruido
son el ruido térmico del receptor y el ruido cósmico captado por
la antena, mientras que las condiciones climáticas, como ser la llu-
via, tienen un papel preponderante en la atenuación de las ondas
electromagnéticas.
Aunque este tipo de canal es uno de los más utilizados en los
sistemas de comunicaciones, el objetivo de esta tesis es estudiar
los canales guiados, especialmente los canales alámbricos, en
el ambiente industrial, por lo que no se realizará una descripción
detallada de los canales no guiados, o inalámbricos.

Cualquiera sea el medio fı́sico utilizado, la principal caracterı́stica es que


la señal transmitida es afectada en forma aleatoria debido a una gran varie-
dad de mecanismos, como ser ruido térmico aditivo generado por dispositi-
vos electrónicos, ruido inducido por el hombre, como por ejemplo la ignición
del motor de un automóvil, o bien generados por la atmósfera, tı́picamente
relámpagos durante tormentas eléctricas.

4.2. Modelo del canal


En la gran mayorı́a de las aplicaciones sobre canales guiados, la señal
aleatoria que se suma a la señal transmitida puede modelarse como un pro-
ceso aleatorio Gaussiano, por lo que en la sección 4.2.1 se estudiará el ruido
blanco Gaussiano aditivo, o AWGN.

La figura 4.1 muestra el transmisor que genera los sı́mbolos s(i) (t) a partir
de los datos de fuente m(i) , el canal de ruido aditivo n(t) y el receptor al cual
llega la señal perturbada r(t).
Sin embargo, si el canal estuviera limitado en ancho de banda, como es el
canal de telefonı́a fija (limitado a 4KHz), serı́a necesario introducir un análisis
de canal de filtro lineal [2], el cual considera la transferencia del filtro para
estimar la señal recibida. Si en cambio el canal fuera inalámbrico, se pueden
utilizar varios modelos, yendo desde el más simple, AWGN, pasando por el
modelo de canal de filtro linear variante en el tiempo[2], o planteando un
3
Esto es condición necesaria pero suficiente, debido a la existencia del margen denomi-
nado Elipsoide de Fresnel; igualmente aunque el transmisor y el receptor no se vieran, el
enlace podrı́a funcionar debido a la difracción de las ondas alrededor de un obstáculo de
dimensiones comparables a la longitud de onda de operación.
Canal de comunicaciones 44

Figura 4.1: Esquema de un sistema de comunicaciones con un canal de ruido


aditivo

modelo de canal con memoria para considerar errores en ráfaga, como lo son
el modelo de Gilbert-Elliot[16] y el modelo bipartito[13], los cuales modelan
al canal como una fuente de Markov con probabilidades de transición hacia
estados “buenos” y “malos”. De esta manera, el canal tiene memoria de los
eventos de ruido ocurrido, por lo que la probabilidad de error de bit deja de
ser independiente para cada bit en el caso de ocurrir una ráfaga, ya que ésta
afecta a un conjunto de bits consecutivos en el tiempo.

4.2.1. Canal AWGN


Como se ha mencionado en la sección 4.1, la forma de onda aleatoria n(t)
que se suma a la señal transmitida s(t) en el canal, como se observa en la
ecuación 4.1 , puede ser modelado como un proceso aleatorio Gaussiano en
la mayorı́a de los casos de importancia.

r(t) = s(t) + n(t) (4.1)


Aproximemos n(t) como una secuencia de pulsos aleatorios w(t) de du-
ración Ts :
+∞
X
n(t) = ni w(t − iTs − δ) (4.2)
i=−∞

donde los pesos ni son variables aleatorias Gaussianas, Ts es un incre-


mento de tiempo arbitrario y δ es un retardo cualquiera uniformemente dis-
tribuido entre [0, Ts ], necesario para que n(t) sea estacionario. La figura 4.2
muestra un posible evento de ruido aditivo, según la ecuación 4.2.
Un proceso Gaussiano estacionario queda completamente determinado
por su media y su función de correlación. Si se asume que la media del
proceso es nula,

E[n(t)] = 0 (4.3)
Canal de comunicaciones 45

Figura 4.2: Ejemplo de evento de ruido aditivo

se calcula la correlación según:

 
+∞
X +∞
X
R(τ ) = E  ni nj w(t − iTs − δ)w(t + τ − jTs − δ) (4.4)
i=−∞ j=−∞
 
+∞
= σ 2 Eδ 
X
w(t − iTs − δ)w(t + τ − jTs − δ) (4.5)
i=−∞

= σ 2 ∆Ts (τ ) (4.6)

donde σ 2 = E[ni 2 ] es la varianza de las muestras de ruido ni . Nótese que


en la ecuación 4.5 la esperanza se calcula sobre el retardo variable δ.

Consideremos ahora la densidad espectral de potencia de ruido N (f ) del


proceso aleatorio n(t); debido a que n(t) no es una función determinı́stica, no
puede obtenerse su transformada de Fourier. Sin embargo, se calcula N (f )
como la transformada de Fourier de la correlación del ruido R(τ ).
Z +∞
N (f ) = R(τ )e−j2πτ f dτ (4.7)
−∞

donde f es la frecuencia.
La figura 4.3 muestra la correlación del ruido y su correspondiente trans-
formada de Fourier. Nótese que la secuencia de ruido de la ecuación 4.2 se
conforma de sumas de infinitos rectángulos. Al correlacionar, es decir convo-
lucionar, rectángulos de igual duración, Ts , se obtiene una función triangular
como la de la figura 4.3, cuya transformada de Fourier es una sinc cuadrado.
Se obtienen resultados de interés cuando la duración de los pulsos alea-
torios Ts tiende a cero:
Canal de comunicaciones 46

Figura 4.3: Correlación del ruido y su transformada de Fourier

lı́m N (f ) = σ 2 (4.8)
Ts →0

lı́m R(τ ) = σ 2 δ(τ ) (4.9)


Ts →0

Es decir, a medida que la duración de los pulsos de ruido tiende a cero, la


correlación entre ellos se aproxima a una delta de Dirac, y la transformada
de Fourier de la correlación tiende a ser constante para todas las frecuencias,
con una potencia de σ 2 W/Hz, por lo que se obtiene el denominado ruido
blanco 4 , el cual debe ser filtrado utilizando un filtro pasabajos que atenúe
frecuencias mayores a las que utilice el sistema en cuestión.
Se define la densidad espectral de potencia de ruido de a ambos lados del
espectro como5 :
N0
σ2 = (4.10)
2
En general, en las comunicaciones digitales es de importancia encontrar
la relación entre la energı́a del bit de fuente, Eb , y la densidad espectral de
potencia de ruido, N0 :
Eb Eb
= 2 (4.11)
N0 2σ
Si se reescribe la expresión de Eb /N0 en función de la relación S/N y la
tasa de datos R se tiene:
Eb S SW
= W Ts = (4.12)
N0 N N R
4
Recibe este nombre por analogı́a con la luz blanca, la cual contiene componentes de
todas las frecuencias con la misma intensidad lumı́nica.
5
Si se define la densidad espectral monolateral igual a N0 , resulta σ 2 = N0 , ver [5].
Canal de comunicaciones 47

con lo cual se observa que, si la relación S/N se mantiene constante de-


bido a que no ha cambiado el ancho de banda del receptor W ni la potencia
recibida S, cuya variación sólo se debe a la atenuación del medio fı́sico6 , en-
tonces la relación Eb /N0 es inversamente proporcional a la tasa de datos R.
De esta manera, una duplicación de la tasa de datos significará una dismi-
nución a la mitad de la relación Eb /N0 medida en veces.

Es importante aclarar que W , el ancho de banda del canal de comuni-


caciones, es a priori independiente de la señal transmitida, aunque es lógico
pensar que para transmitir información a R bps se limite W mediante un
filtro a un valor cercano a R/2 (ver Apéndice A sección A.8), de manera que
si se hace W = R/2 la ecuación 4.12 puede reescribirse según:
Eb SW 1S
= = (4.13)
N0 N R 2N
En decibeles, la expresión se reduce a:
Eb 1S S
 
= 10 log( )= − 3dB (4.14)
N0 dB 2N N dB

Potencia de ruido AWGN


Consideremos un sistema receptor limitado en banda a B Hz. Si el ruido
tiene una densidad espectral de potencia a ambos lados del espectro igual a
N0 /2 W/Hz , la potencia de ruido AWGN que se desarrollará en ese ancho
de banda será:
N0
N= 2B = N0 B (4.15)
2

4.2.2. Ruido térmico


Una de las fuentes más importantes de ruido AWGN es el ruido térmico.
Éste se debe a la agitación aleatoria de los electrones debido a la energı́a
térmica. Dicho movimiento aleatorio produce una señal independiente de la
señal recibida y es detectada en adición a la señal de información. Debido
a que este ruido es generado por muchos dispositivos, se lo puede modelar
como un proceso Gaussiano.
6
En este caso habrá que tener en cuenta la variación de la atenuación del medio fı́si-
co con la frecuencia de transmisión, encontrando aquellos rangos de frecuencia para los
cuales la atenuación permanece constante. Este efecto serı́a mucho más crı́tico en canales
inalámbricos en los cuales la atenuación depende fuertemente de la frecuencia debido al
fenómeno de propagación.
Canal de comunicaciones 48

Potencia y tensión de ruido térmico


Para ver el efecto del ruido en la señal recibida, se deberá tener en cuenta
la potencia de la señal de ruido relativa a la señal deseada, surgiendo ası́ la
relación SNR en comunicaciones analógicas, y Eb /N0 en comunicaciones di-
gitales.
Para encontrar la potencia de ruido térmico N , primero se debe conocer la
temperatura en grados Kelvin en el receptor y el ancho de banda del receptor,
según indica la ecuación 4.16:

N = kT B (4.16)
donde k = 1,38 · 10−23 W/(HzK) es la constante de Boltzmann, T es la
temperatura del receptor en grados Kelvin, y B es el ancho de banda de ruido
efectivo en el receptor en Hz.
Asimismo, la tensión de ruido térmico Vn sobre un resistencia de valor R
se calcula como:

Vn = kT BR (4.17)

4.3. Canal fı́sico en Profibus DP


Hasta aquı́ se ha visto el modelo matemático del canal de comunicaciones.
En esta sección se mostrarán las especificaciones del canal fı́sico del protocolo
Profibus DP, en cuanto a atenuación, máxima longitud del cable en función
de la tasa de transferencia de datos, aplicaciones, etc.

El cable utilizado como canal fı́sico en Profibus DP es el que se muestra


en la figura 4.4. Sus especificaciones técnicas serán dadas en la sección 4.3.1.

Figura 4.4: Cable utilizado en Profibus DP

4.3.1. Especificaciones técnicas


A continuación en el cuadro 4.1 se muestran las especificaciones técnicas
del canal fı́sico de Profibus DP, incluyendo la versión de seguridad intrı́nseca.
Canal de comunicaciones 49

Cuadro 4.1: Especificaciones técnicas del canal fı́sico para


Profibus DP [17]

Modelo NDC110-NO (CDN110)


NDC110-EX (CDE110-Ex)
Aplicación Cable de bus de campo estándar para aplicaciones
cero halógeno para Profibus DP/FMS. Recomen-
dado para instalaciones en interiores y exteriores,
ubicaciones secas y húmedas, en gabinetes, ban-
dejas y conductos. No apto para enterrado direc-
to. Especialmente aplicable a ubicaciones donde
las caracterı́sticas de bajo nivel de humo y cero
halógeno son importantes (por ej, edificios públi-
cos, hospitales, estaciones de energı́a)
Habilitado para In- A nivel de información
dustrialIT
Estándar EN 50170 Parte 2 y Parte 3
Clasificación Tipo A
Interfaz RS 485 (-IS)
Conductor cobre plano sólido
AWG 22/1, ø = 0,64mm
Aislación polietileno espumado con capa superficial
Código de colores cable núcleo-a: verde, cable núcleo-b: rojo
Pantalla cinta de aluminio con revestimiento plástico, por
fuera superficie metálica en contacto con un cable
de drenaje de cobre enlatado y trenza de cable.
Revestimiento exte- componente bajo nivel de humo y cero halógeno,
rior color: violeta (NDC110-NO), azul [IS] (NDC110-
EX)
Diámetro total 8,1 ± 0, 3mm
Peso aprox. 78 kg/km
Máxima tensión de ti- 80N
rado
Mı́nimo radio de tor- 5 x diámetro total del cable
sión
Rango de temperatura -40...+75 ◦ C durante la operación, 5...+50 ◦ C para
la instalación
Resistente a UV UL 1581 artı́culo 1200
Resistente a aceite ICEA S-82-552
Canal de comunicaciones 50

Propagación de llama UL 13 prueba de bandeja vertical, IEC 60332-3


Densidad de humo baja, IEC 61034
Libre de halógeno Sı́, IEC 60754-1, 0 %
Grado de acidez de ga- IEC 60754 part 2, (pH > 4,3, c > 10µS/mm)
ses
Índice de oxı́geno del IEC 60332-3, min. 35 %
revestimiento exterior
Protección a explosión
(NDC110-EX only) para aplicaciones EEx i[IS],
Clase I/II división 2 de acuerdo con NEC 501-4(b)
y NEC 502-4(b) o Zona 1/2, grupo II, de acuedo
con 60079-14.
Aprobación FISCO FISCO no para componentes pasivos
Aprobación CE, UL (listado como PLTC de acuerdo con UL
13)
Propiedades eléctricas a 20◦ C
Resistencia del con- máx. 110Ω/km
ductor (lazo)
Resistencia de la pan- nom. 9Ω/km
talla
Atenuación a 0.25 / nom. 6 / 9 / 12 / 18 / 40 / 123 / 214 dB/km
0.625 /1.25 / 3.125 /
16 / 100 / 300 MHz
Inductancia nom. 0.65 mH/km
Capacitancia mutua máx. 30nF/km
Capacitancia de des- máx. 1500pF/km
balance a tierra
Impedancia ≥ 3M Hz 150 ± 15Ω
Tensión de prue- 1500 V
ba (cable/cable y
cable/pantalla)
Tensión de operación máx. 300 V

En la figura 4.5 se grafica la atenuación del canal fı́sico de Profibus DP


en función de la frecuencia.
Canal de comunicaciones 51

Figura 4.5: Atenuación del cable de Profibus DP en función de la frecuencia

4.3.2. Tasa de transmisión de datos vs. distancia de


cable
Existe una relación de compromiso entre la máxima distancia del cable y
la tasa de transmisión de datos. Esto se debe a que al aumentar la tasa de
transmisión de datos, los bits poseen menos energı́a por tener una duración
menor, en consecuencia existe una disminución en la relación Eb /N0 , la cual
limita la máxima distancia de cable; adicionalmente, el medio fı́sico genera
atenuaciones en la señal eléctrica, siendo éstas mayores conforme aumenta la
tasa de transmisión de datos. De esta manera existe una máxima distancia
de cable para una determinada velocidad de transmisión. En la figura 4.6 se
grafican estos lı́mites en función de la tasa de datos, diferenciando el caso en
que el medio fı́sico utilice la interfaz RS485 o RS232C7 .

4.3.3. Niveles de ruido


En esta sección se verán los niveles de ruido considerados como lı́mites
para la calidad de la transmisión de la información en Profibus. Si bien la
7
Por razones que se ven claramente en la figura 4.6, no se utiliza esta interfaz.
Canal de comunicaciones 52

Figura 4.6: Máximas distancias del cable de Profibus DP vs. tasa de trans-
misión de datos [18].

norma Profibus DP no establece dichos valores, y sólo considera como criterio


limitante la atenuación del medio fı́sico, estos niveles se tornan muy influ-
yentes en la versión Profibus PA debido a que ésta utiliza la interfaz MBP
(Manchester Bus Powered) la cual es desbalanceada y no cancela el ruido
AWGN.

El cuadro 4.2 muestra los niveles en milivolts pico a pico y la condición


de la lı́nea para cada caso.

Cuadro 4.2: Niveles de ruido para Profibus PA

Nivel de ruido Condición de la lı́nea


(Promedio, pico a pico)
≤ 25 mV Excelente
20...25 mV Buena
50...75 mV Marginal
≥ 75 mV Mala

Estos valores servirán como referencia para el caso de Profibus DP, aun-
que es necesario valerse de información adicional para considerar la validez
de dichas magnitudes de ruido.

Debido a que en esta tesis se consideran enlaces propensos a errores8 , los


cuales incrementan la tasa de error BER, se propondrá un nivel de ruido
máximo de 270 mV, muy superior a los niveles máximos adoptados en Pro-
fibus PA, situándonos en la condición más desfavorable, para analizar ası́ la
respuesta de la propuesta presentada en esta tesis bajo estas condiciones.
8
En inglés suele denominarse a este tipo de enlaces prone links.
Capı́tulo 5

Profibus Turbo

5.1. Introducción
Durante años se ha trabajado con diferentes versiones de Profibus para
cada aplicación en particular. Un claro ejemplo de esto es la versión Profibus
PA, la cual transmite datos a una tasa fija de 31.25 Kbps alcanzando distan-
cias máximas de 1900 metros. Claramente, en contraste con Profibus DP, el
cual trabaja a velocidades de hasta 12 Mbps con una distancia máxima de
100 metros para dicha tasa, se está sacrificando velocidad de transmisión de
datos por distancia de cable. Esto es lógico y razonable, ya que un estableci-
miento o planta industrial puede tener dimensiones del orden del kilómetro y
en consecuencia es necesario tender cables de hasta 2000 metros de longitud
para comunicar los equipos transmisores, actuadores y otros equipos de cam-
po con los gabinetes en donde se encuentran los controladores o procesadores
de datos.

En este capı́tulo se propone un esquema innovador de transmisión de


datos para el protocolo Profibus DP, con la meta de alcanzar distancias del
orden de las alcanzadas con Profibus PA, pero con tasas de transmisión de
datos mucho mayores, con la finalidad de soportar servicios y funcionalidades
en los equipos de campo. Esto además implicará un mejor aprovechamiento
de los recursos del bus, ya que el mismo estará ocupado por un tiempo mucho
menor que el actual para transferir el mismo volumen de datos.

Adicionalmente, la propuesta es innovadora desde el punto de vista de


la codificación turbo, debido a que la misma tradicionalmente ha sido usada
exclusivamente para enlaces inalámbricos, debido a su baja relación S/N y
la necesidad de obtener ganancias de codificación notables para mejorar la

53
Profibus Turbo 54

BER, mientras que en esta tesis se utiliza dicha técnica en medios cableados
por cobre.
Por último, este nuevo esquema introduce el uso de la codificación tur-
bo en el ámbito de las comunicaciones industriales, algo nunca hecho
hasta el momento.

5.2. Esquema propuesto


La figura 5.1 muestra el esquema propuesto para la transmisión y re-
cepción de Profibus DP con codificación turbo. El esquema es totalmente
genérico y aplicable a cualquier otro protocolo de comunicaciones industria-
les sobre medios guiados, salvo diferencias en la capa fı́sica, sobre la cual
opera. El algoritmo de decodificación turbo no toma acciones sobre capas
superiores ni debe hacerlo para garantizar la BER y Eb /N0 objetivo.

Figura 5.1: Esquema propuesto para Profibus Turbo


Profibus Turbo 55

5.2.1. Posible implementación y retardo asociado


Si bien la implementación del esquema propuesto se encuentra fuera del
alcance y los objetivos de esta tesis, se propone a continuación una posible
implementación de los algoritmos de codificación y decodificación turbo.

Los algoritmos MAP pueden ser implementados sobre DSP’s o FPGA’s,


siendo estas últimas las más utilizadas por presentar menos retardo de proce-
samiento que los primeros. Existen diversos circuitos integrados que realizan
la codificación y decodificación turbo, a diferentes tasas de datos y con dis-
tintos polonomios generadores. Para el caso particular de esta tesis, es conve-
niente utilizar un codificador de 16 estados (longitud restringida K = 5) con
un circuito integrado que trabaje hasta al menos 12 Mbps. La empresa Tre-
llisWare Technologies ha desarrollado el circuito integrado TWT 100204D/E
con las caracterı́sticas anteriormente mencionadas [23]. Uno de los paráme-
tros más importantes al proponer una implementación es la latencia o retardo
introducido por el procesamiento de los datos.

Para el circuito integrado TWT 100204D/E, el cual opera con un reloj


del 46,6666 MHz, y utiliza un codificador con tasa k = 1/3, con 8192 bits de
datos, el retardo de decodificación1 está dado por la ecuación 5.1:

Latency = 5041T p (5.1)


donde p es el número de iteraciones y T = 1/46,6666nseg = 21,42nseg.
Para 8 iteraciones, el retardo es de 864,19µseg.

Para nuestro caso, la trama entrante es de 2816 bits (256 bytes, repartidos
entre 246 bytes de datos y 10 bytes de overhead, cada byte acompañado por
un bit de inicio, uno de parada y uno de paridad, con un total de 11 bits
por byte de información) y el código es de tasa k = 1/2, por lo que la
relación entre la cantidad de datos que procesa el decodificador de la hoja de
datos y los datos procesados por la solución propuesta en esta tesis es (8192 ·
3)/(2816 · 2) = 4,3636. De esta manera, es razonable pensar que el retardo de
procesamiento especificado en la hoja de datos del decodificador se divida por
dicho número, siendo entonces igual a 198µseg para 8 iteraciones. Con la tasa
de bits más elevada, 12 Mbps, este retardo equivale a 12M bps · 198µseg =
2376bits. Es decir, el retardo de procesamiento es inferior al tamaño de una
trama (2816 bits), por lo que bastará con agregar un buffer con capacidad
para almacenar una trama en el decodificador turbo.
1
El retardo de codificación puede ser considerado despreciable.
Profibus Turbo 56

5.2.2. Factibilidad económica


En esta sección se analizará la factibilidad económica de la solución pro-
puesta y su impacto en el precio final del equipo Profibus.

El precio de un equipo comercial Profibus varı́a de acuerdo a sus presta-


ciones y servicios agregados; generalmente los equipos más económicos son
los transmisores (de caudal, presión, nivel, temperatura, entre los más comu-
nes), ya que se limitan a medir una magnitud fı́sica y comunicarla median-
te una señal eléctrica al procesador de datos o controlador. Las válvulas y
actuadores suelen ser más costosos debido a la electrónica de accionamiento
involucrada, generalmente haciendo uso de la energı́a neumática o hidráulica.

De esta manera, se utilizará como patrón de comparación a un transmi-


sor, de manera de situarse en la peor condición, en este caso, el equipo más
económico, donde tendrá mayor impacto la introducción de la FPGA que
implemente los algoritmos de decodificación. El precio de un equipo transmi-
sor Profibus de ABB oscila entre los U$S 800 y U$S 1000; aunque el precio
pueda parecer elevado, la prestación y confiabilidad ofrecida por el equipo
paga la inversión realizada, por lo que quienes diseñan una planta industrial
que brindará elevadas ganancias diarias no suelen efectuar grandes ahorros
en los equipos involucrados en el proceso de producción.

Por otra parte, una FPGA de la firma Altera utilizada para W-CDMA
que implementa el cálculo de CRC, decodificación turbo, selección de re-
dundancia, interleaving y modulación en QAM para una tasa de 14,4M bps,
cuesta unos U$S 7 por unidad [24]. Recordemos que para este tipo de análi-
sis económico el hardware representa un costo recurrente mientras que el
firmware no agrega costo por unidad por ser no recurrente.

De esta manera, luego de un breve análisis, se puede concluir que el


impacto sobre el precio final del equipo que implemente Profibus Turbo se
ve incrementado en menos del 1 por ciento del valor actual.

5.3. Propiedades del canal propuesto


5.3.1. BER y Eb /N0
Consideremos ahora que la señal transmitida se encuentra inmersa en un
entorno en el cual las interferencias y el ruido electromagnético descripto en
el capı́tulo 4 son tales que generan una BER que en el peor caso alcanza un
Profibus Turbo 57

valor de 10−4 . Para transmisión sin codificación, esto representa un valor de


Eb /N0 igual a 8,37dB, según puede observarse en la figura 5.2. De la figura
mencionada puede destacarse que para una BER de 10−5 , valor que muchos
autores consideran como lı́mite de buen funcionamiento de un enlace, la re-
lación Eb /N0 asciende a 9,55dB.

Los enlaces mencionados en el párrafo anterior, denominados en inglés


prone links, imparten alteraciones a la señal transmitida debido al elevado
nivel de ruido electromagnético proveniente de diversas fuentes. En un am-
biente industrial, dichas fuentes son fundamentalmente los motores y bombas
que se accionan en la planta durante el proceso, tubos flourescentes, fuentes
conmutadas, entre otros equipos, los cuales contribuyen con ruido electro-
magnético durante su funcionamiento transitorio o permanente.

Figura 5.2: BER vs Eb /N0 para transmisión sin codificación


Profibus Turbo 58

5.3.2. Niveles de ruido para la Eb /N0 propuesta


Siguiendo el razonamiento establecido en la sección 5.3.1, para obtener
una relación Eb /N0 = 8,31dB, considerando una tensión mı́nima de 1V en el
receptor, y utilizando la ecuación 4.14, la tensión de ruido debe ser de:
1V
8,31dB = 20 log − 3dB ⇒ V n = 272mV (5.2)
Vn

5.3.3. Atenuaciones para distintas tasas de datos


Según lo establecido en el Apéndice A sección A.8, para una tasa de datos
de R bps, el ancho de banda de la señal asociada puede ser aproximado a R/2
Hz. De esta manera, y refiriéndonos a la figura 4.5, se construye el cuadro
5.1 para cada tasa de datos del protocolo Profibus.

Cuadro 5.1: Atenuación en función de la tasa de datos

Tasa (kbps) Atenuación (dB/100m)


9.6 0.5
19.2 0.5
93.75 0.5
187.5 0.5
500 0.6
1000 0.8
1500 1
3000 1.28
12000 2.3
24000 3.3

Es importante notar que el cuadro anterior surge de plantear el ancho de


banda de una señal de R bps y evaluar la curva de atenuación vs. frecuen-
cia para una frecuencia igual a R/2 Hz. Indudablemente esto no fue lo que
realizaron quienes establecieron la cota de distancia en el estándar Profibus,
ya que los niveles impuestos en la norma son absolutamente conservadores y
holgados.
Profibus Turbo 59

5.4. Mejoras obtenidas


5.4.1. Tasa de transmisión constante
En esta sección se estudiarán los casos en los cuales la tasa de transmisión
permanece constante, siendo la variable de estudio la máxima longitud de
cable.

Para el estudio de esta sección se supondrá una BER igual a 10−4 , por lo
que se debe procurar que la relación Eb /N0 caiga hasta 1dB trabajando con
un esquema de decodificación turbo de hasta 10 iteraciones si es necesario2
(ver figura 2.10). Sin embargo, son los bits de código los que ingresan al canal
de comunicaciones y los que son atenuados por el mismo, de manera que una
Eb /N0 = 1dB equivale a una Ec /N0 = 1dB − 3dB = −2dB por utilizarse
código de tasa k = 1/2, por lo que, partiendo de una señal de 2V , con un
nivel de ruido Vn = 272mV la señal recibida Vr debe ser de:
−2+3
Vr = Vn 10 20 = 242,42mV (5.3)
Por lo tanto, se deben atenuar los bits de código:
2V
LcdB = 20 log = 18,33dB (5.4)
Vr
A continuación se estudiará la máxima distancia del cable resultante de
plantear la atenuación de la ecuación 5.4, refiriéndonos al cuadro 5.1, para
diferentes tasas de trasmisión de interés.
Es importante aclarar que para una tasa R bps de datos de fuente corres-
ponde una tasa 2R de datos de código, por lo que la atenuación del canal
fı́sico sobre los bits de código ocurrirá a una frecuencia R Hz.

Tasa 500Kbps
De acuerdo al cuadro 5.1, con una atenuación de bits de código de 0,8dB/100m,
para lograr una Eb /N0 = 1dB, la máxima longitud del cable es:
18,33dB
D= = 2291 m (5.5)
0,8dB/100m
Es decir, la nueva máxima distancia para 500Kbps es 5,72 veces la dis-
tancia impuesta por la norma para dicha tasa (400m).

2
No es conveniente aumentar demasiado la cantidad de iteraciones debido al retardo
introducido, ver sección 5.2.1.
Profibus Turbo 60

Adicionalmente, la nueva distancia máxima para 500Kbps es aún su-


perior a la máxima distancia establecida por la norma para Profibus PA
(1900 m), el cual transmite a velocidad constante e igual a 31,25Kbps. Es
decir, si se transmite la alimentación por el bus de datos del esquema pro-
puesto en esta tesis, es posible obtener la misma prestación que Profibus PA
pero con un incremento de velocidad de 16 veces. De esta manera, dicha
técnica podrı́a desplazar a Profibus PA por otorgar mejores prestaciones para
mayores distancias de cables.

Tasa 1, 5M bps
Siguiendo un razonamiento análogo al efectuado para la tasa de 500Kbps,
y refiriéndonos al cuadro 5.1, con una atenuación de 1,28dB/100m para los
bits de código emitidos a 3M bps, para lograr una Eb /N0 = 1dB, la máxima
longitud del cable es:
18,33dB
D= = 1432 m (5.6)
1,28dB/100m
Es decir, la nueva máxima distancia para 1,5M bps es 7,61 veces la dis-
tancia impuesta por la norma para dicha tasa (200m).

Tasa 12M bps


Se analizará el último caso para tasa constante, siendo éste el caso de la
mayor tasa de datos establecido por Profibus. Siguiendo el mismo razona-
miento que para las tasas de 500Kbps y 1,5M bps , nuevamente refiriéndonos
al cuadro 5.1, con una atenuación de 3,3dB/100m para los bits de código
emitidos a 24M bps, para lograr una Eb /N0 = 1dB, la máxima longitud del
cable es:
18,33dB
D= = 555.45 m (5.7)
3,3dB/100m
Es decir, la nueva máxima distancia para 12M bps es 5,55 veces la dis-
tancia impuesta por la norma para dicha tasa (100m).

A lo largo de esta sección se ha supuesto la utilización de un filtro en


el receptor con frecuencia de corte igual a R Hz, de manera de mantener la
relación W/(2R) = 1/2, donde 2R es la tasa de bits de código que ingresan
al canal por utilizarse un código de tasa k = 1/2.
Profibus Turbo 61

5.4.2. Distancia de cable constante


En esta sección se estudiarán los casos en los cuales la máxima distan-
cia del cable permanece constante, siendo la variable de estudio la tasa de
transmisión de datos.

Consideremos la variación de la relación Eb /N0 con la tasa de datos R.


Reescribiendo la ecuación 4.12, y considerando que la densidad espectral de
ruido N0 permanece constante, se obtiene:
Eb SW S 1
= = (5.8)
N0 N R N0 R
De esta manera, se aprovechará la relación de la ecuación 5.8 para ob-
tener una Eb /N0 = 1dB incrementando la tasa de datos R tanto como sea
necesario.

El escenario estudiado en esta sección es más complejo que el estudiado


en la sección 5.4.1, ya que en esta última el hecho de conocer a priori la tasa
de transmisión permitı́a conocer la frecuencia a la cual calcular la atenuación
en función de la distancia; en cambio, la situación difiere en esta sección
por el hecho de que, al tiempo que se desea determinar cuánto es posible
aumentar la tasa R para reducir la Eb /N0 a 1dB, es necesario conocerla
para calcular la atenuación para una distancia conocida. De esta manera, es
necesario plantear una ecuación que contemple la atenuación en función de R
además de la relación existente entre Eb /N0 y R mencionada en la ecuación
5.8. Dicho de otra manera, se puede reescribir la ecuación 5.8 explicitando la
dependencia de la potencia recibida S en función de la tasa de datos R, es
decir:

Eb S(R) 1
= (5.9)
N0 N0 R
Al igual que en la sección 5.3.1, se supondrá una BER = 10−4 , lo cual sig-
nifica una Eb /N0 = 8,37dB sin codificación, para cada distancia determinada.

Tomando 10 log(·) a ambos miembros de la ecuación 5.8, resulta:


Eb S
 
= (R) + 10 log(W ) − 10 log(R) (5.10)
N0 dB N dB

Sea R1 la tasa de datos determinada por la norma Profibus para una


determinada distancia, y sea R2 la nueva tasa de datos propuesta para al-
Profibus Turbo 62

canzar una relación Eb /N0 = 1dB, es posible plantear la siguiente variación


de manera de determinar R2 :

!
Eb S R2
   
∆ = 1dB − 8,37dB = −7,37dB = ∆ − 10 log (5.11)
N0 dB N dB R1

Además, es importante aclarar que:


! !
Eb Ec
 
∆ =∆ (5.12)
N0 dB N0 dB
 k 
Si consideramos que ∆ NS corresponde a la variación de atenuación
dB
debido al incremento de la tasa de datos de R1 a R2 , y es igual a − ∆LcdB ,
siendo LcdB la atenuación definida por la figura 4.5, se puede reescribir la
ecuación 5.11 como:
R2
7,37dB = ∆ LcdB + 10 log (5.13)
R1
Como puede observarse, en la ecuación 5.13 no aparece el ancho de banda
del canal W ; esto se debe a que se lo ha considerado constante y al efectuar
la diferencia, éste se cancela. Sin embargo, a diferencia de la sección 5.4.1,
aquı́ se supone W > R1 de manera de poder incrementar R cumpliendo con
el teorema de la capacidad de Nyquist; es más, el mı́nimo valor que éste pue-
de tomar es W = R2 , de manera de poder emitir datos de fuente a una tasa
R2 , teniendo los bits de código una tasa 2R2 .

De esta manera, el objetivo de esta sección será resolver la ecuación 5.13


para encontrar la nueva tasa R2 , con R2 > R1 .

Nótese que si la atenuación en función de la frecuencia fuera plana (es


decir, constante), el término ∆ LcdB de la ecuación 5.13 serı́a nulo, por lo
que para cualquier tasa de datos inicial R1 el incremento de tasa R2 /R1 serı́a
igual a 100,737 = 5,46 veces. Sin embargo, debido al incremento de la atenua-
ción conforme aumenta la tasa de datos, este valor se transforma en una cota
superior.

Se analizarán tres diferentes distancias máximas de cable para diferentes


aplicaciones, y para cada caso en particular se calculará el incremento de ta-
sa de transmisión de datos de manera de alcanzar una relación Eb /N0 = 1dB.
Profibus Turbo 63

Figura 5.3: Detalle de la figura 4.5 para el rango de frecuencias de 250KHz


a 1MHz

Distancia 400m
Según la norma Profibus, para una distancia de 400 metros corresponde
una tasa de transmisión de datos de fuente R1 = 500Kbps, es decir una
tasa de bits código de 2R1 = 1M bps, lo cual corresponde a un ancho de
banda de aproximadamente 500KHz, por lo que se deberá encontrar una
relación para la atenuación en función de la frecuencia alrededor de dicho
valor. Según se observa en la figura 5.3, la pendiente de la recta que vincula la
atenuación con la frecuencia es de 0,8dB/100KHz hasta 626KHz, cayendo
a 0,48dB/100KHz luego de dicho valor, y considerando que en este caso
R1 = 500Kbps, se puede reescribir la ecuación 5.13 como:
626 − 500 R2 − 626 R2
7,37 = 0,8 + 0,48 + 10 log (5.14)
100 100 500
con R2 medido en Kbps y ambos lados de la igualdad en dB. Nótese que
el primer término a la derecha del igual representa la atenuación del medio
fı́sico obtenida entre 500 KHz y 626 KHz, mientras que el segundo plantea
la atenuacı́ón del mismo desde 626 KHz en adelante.
Profibus Turbo 64

Resolviendo gráficamente en Matlab la ecuación 5.14 escrita en forma


homogénea, se obtiene R2 = 1177Kbps, es decir 2,35 veces la tasa de datos
establecida por la norma, tal como se observa en la figura 5.4. Entonces,
mediante la introducción de la codificación turbo, es posible aumentar la
tasa de datos en un 135 por ciento para una distancia de cable de 400
metros.

Figura 5.4: R2 para distancia de cable igual a 400 metros

Distancia 200m
Para una distancia de cable de 200 metros la tasa de datos establecida por
Profibus es de 1,5M bps, es decir una tasa de bits código de 3M bps, lo cual
corresponde a un ancho de banda de aproximadamente 1,5M Hz, por lo que
la curva de la figura 5.3 sufre un cambio de pendiente. La nueva pendiente
es 0,48dB/100KHz, y considerando que en este caso R1 = 1500Kbps, es
posible reescribir la ecuación 5.13 como:
Profibus Turbo 65

R2 − 1500 R2
7,37 = 0,48 + 10 log (5.15)
100 1500
Nuevamente, resolviendo gráficamente en Matlab la ecuación 5.15 escrita
en forma homogénea, se obtiene R2 = 2,554M Hz, es decir, 1,7 veces la tasa
de datos establecida por la norma, tal como se observa en la figura 5.5. Es
decir, se puede incrementar la tasa de transmisión impuesta por la norma
Profibus en un 70 por ciento.

Figura 5.5: R2 para distancia de cable igual a 200 metros

Distancia 100m
Se analizará por último el caso de distancia de cable igual a 100 me-
tros. La norma Profibus establece varias tasas de datos para dicha distancia,
por lo que se elegirá la más alta, 12M bps, es decir una tasa de bits código
de 24M bps, lo cual corresponde a un ancho de banda de aproximadamente
Profibus Turbo 66

12M Hz. Debido a que la curva de atenuación en función de la frecuencia con-


serva la pendiente de 0,48dB/100KHz hasta los 100 MHz, para encontrar la
nueva tasa de datos R2 es necesario resolver la siguiente ecuación:
R2 − 12000 R2
7,37 = 0,48 + 10 log (5.16)
100 12000
Como en los casos anteriores, resolviendo gráficamente en Matlab la ecua-
ción 5.16 escrita en forma homogénea, se obtiene R2 = 13,43M Hz, es decir,
1,12 veces la tasa de datos establecida por la norma, tal como se observa en
la figura 5.6. Es decir, se puede incrementar la tasa de transmisión impuesta
por la norma Profibus en un 12 por ciento.

Figura 5.6: R2 para distancia de cable igual a 100 metros

Es claro que para una distancia de cable de 100 m y tasa de datos de


12 Mbps no se obtienen grandes beneficios práctico al introducir la
técnica de codificación turbo. La imposibilidad de una mejora a tan elevada
frecuencia es producto de la gran atenuación del medio fı́sico empleado
Profibus Turbo 67

y su gran sensibilidad para variaciones de frecuencia en el rango de los MHz.

Sin embargo, la técnica introducida en esta tesis tiene como objetivo me-
jorar tasas de datos para grandes distancias de cable, mucho mayores que
100 metros, por lo que este último no es un caso de interés.

Es importante contrastar los casos estudiados en esta sección, donde se


considera a la tasa de datos R una variable, por lo que la atenuación para
una distancia constante sufre una gran variación con R, mientras que en la
sección 5.4.1 la tasa de datos es constante, concluyendo que la atenuación del
medio fı́sico de Profibus es mucho más sensible a las variaciones de frecuencia
que a las variaciones de distancia, para distancias del orden de los 100 o 1000
metros.
Capı́tulo 6

Simulaciones

6.1. Modelo en Simulink


A continuación se presenta el modelo implementado en Matlab 7.1 (R14)
en el paquete de simulación de modelos Simulink1 .
En la figura 6.2 puede observarse una fuente de Bernoulli que arroja “1”
o “0” en función de la probabilidad de cero p0 ; la misma es utilizada como
fuente aleatoria de datos. Los datos generados por este bloque se utilizan
para:

• transmitirlos en forma sistemática hacia el canal de comunicaciones.

• ingresarlos a un codificador RSC para su posterior transmisión luego


de la selección de redundancia, realizada por el bloque Puncture.

• ingresarlos al interleaver para codificarlos con un codificador RSC idénti-


co al caso anterior para su posterior transmisión luego de la selección
de redundancia.

Los datos son entrelazados con un bloque Interlacer e ingresados en for-


mato polar al canal AWGN, al cual se le pasa como parámetro la relación
Es Eb
N0
= N 0
− 3dB por ser un código de tasa k = 1/2, ya que el canal opera
sobre los bits de código y no de fuente.

1
A pesar que Simulink es una herramienta muy práctica ya que se obtiene visualmente
la información de la configuración, sufre de problemas de retardos al invocar las funciones
S que corren en los bloques; inclusive, la implementación de lazos de realimentación es
complicada y puede haber errores en tiempo de ejecución, por lo que la mayor parte de las
simulaciones se han realizado sobre código fuente que replica la configuración mostrada en
esta sección. Dicho código fuente puede ser encontrado en el Apéndice D.

68
Simulaciones 69

Al llegar al receptor, los datos son desentrelazados mediante el bloque


Puncture y se rellena con ceros en las posiciones de redundancias donde se
realizó puncturing en el transmisor. El conjunto de datos diferenciado por
datos sistemáticos y las redundancias de ambos codificadores ingresan al blo-
que Turbo Decoder donde corre la lógica de iteraciones y los algoritmos MAP.

La figura 6.2 describe los componentes del decodificador turbo. Pueden


distinguirse los decodificadores Dec1 y Dec2, sobre los cuales corren los algo-
ritmos de decodificación Log-MAP introducido en la sección 2.4.9. El código
fuente de Matlab puede encontrarse en el Apéndice D2 . Las entradas de Dec1
son los datos sistemáticos X, la redundancia del codificador sin interleaver
Y 1 y la información extrı́nseca entregada por Dec2 pasada por un deinterlea-
ver, conectada mediante el bloque DataStoreRead, cuyo valor inicial es cero.
Las entradas de Dec2 son los datos sistemáticos X pasados por el interleaver,
la redundancia del codificador con interleaver Y 2 y la información extrı́nseca
entreagada por Dec1 pasada por un interleaver. El bloque ForIterator es el
encargado de repetir la ejecución del bloque Turbo Decoder tantas veces se
haya configurado en dicho bloque.

Finalmente, a la salida del bloque Turbo Decoder se realiza decisión dura


con un umbral de decisión en cero, obteniéndose los datos decodificados en
binario, para su posterior contraste con los datos originados en la fuente y el
trazado de la curva BER vs. Eb /N0 .

2
Sin duda los algoritmos MAP son los de mayor peso y relevancia en esta tesis, sin
embargo se incluyen todos los códigos fuentes de los archivos que contribuyen a obtener
los resultados de las simulaciones mostradas en este capı́tulo.
Simulaciones 70

Esquema de transmisión/recepción

Figura 6.1: Esquema de transmisión/recepción con codificación turbo


Simulaciones 71

Decodificación turbo

Figura 6.2: Componentes del bloque Turbo Decoder


Simulaciones 72

6.2. Grados de libertad


La obtención de resultados favorables en las simulaciones no es una tarea
simple, aún cuando el modelo implementado sea correcto, ya que los mismos
varı́an de acuerdo a las condiciones de simulación. En el caso de la respuesta
de los códigos turbo, es decir, curvas de BER vs. Eb /N0 , la performance
es muy dependiente de diversas variables y grados de libertad, listados a
continuación:

• Tamaño de la trama

• Tipo de interleaver

• Longitud restringida y polinomio generador del codificador RSC

• Cantidad de iteraciones del lazo de decodificación

De todos estos grados de libertad, el tamaño de la trama queda fijo por


el protocolo en cuestión, en este caso Profibus (2816 bits), por lo que no es
posible variar dicha cantidad para obtener mejores resultados.

En cuanto al tipo de interleaver, generalmente se suele utilizar interlea-


vers en bloque para tamaños de tramas menores a 1000 bits, dejándose el
uso de interleavers aleatorios cuando la trama supere dicho valor, por lo que
se propone en esta tesis el uso de interleavers aleatorios3 con capacidad
de almacenamiento igual al tamaño de la trama.

En cuanto al polinomio generador y la longitud restringida, existen infini-


dad de combinaciones posibles, ya sea para generar la salida o la realimenta-
ción, aumentando o disminuyendo la memoria del codificador, aunque luego
de repetidos intentos y simulaciones, y en congruencia con lo explicitado por
[5], el codificador que exhibe mejor respuesta es aquel con longitud restringi-
da K = 5 y polinomio generador G = 21, F = 37 expresado en octal, donde
G representa las conexiones de salida y F las conexiones de realimentación;
el esquema de dicho codificador fue introducido en el capı́tulo 2. Adicional-
mente, se ha tomado como referencia los resulados obtenidos en [11] para
distintos tipos de generadores, longitudes restringidas y tamaños de tramas,
concluyendo que los códigos de tasa k = 1/3 presentan mejor respuesta que
los propuestos en esta tesis (k = 1/2), a expensas de un mayor ancho de
banda y retardo de procesamiento, por lo que no se considera viable dicha
3
Recordar que en realidad los interleavers son pseudoaleatorios, de manera de poder
realizar el proceso inverso de deinterleaving.
Simulaciones 73

opción. Asimismo, los resultados obtenidos por [8], observados en la figura


6.3, fueron igualmente satisfactorios a expensas de un tamaño de trama de
123x123 = 15129 bits, por lo que no es posible implementar dicha solución
en el esquema propuesto en esta tesis.

Figura 6.3: Resultados de las simulaciones realizadas por [8]

Entonces, la cantidad de iteraciones será la variable de ajuste por


excelencia para obtener los resultados propuestos en el capı́tulo 5.
Simulaciones 74

6.3. Resultados de las simulaciones


6.3.1. Algoritmo Log-MAP
En esta sección se presentan los resultados de las simulaciones realizadas
en Matlab, habiendo implementado el algoritmo de decodificación Log-MAP.

El objetivo es obtener una BER = 10−4 con una una Eb /N0 = 1dB, con
una cantidad de iteraciones menor o igual a 10. En todos los casos la longitud
de la trama se mantiene constante e igual a 2816 bits.

Codificador con K = 3

Figura 6.4: K=3, G=7, F=5, 100 tramas transmitidas

La figura 6.4 muestra la curva de BER vs. Eb /N0 para un codificador


con un polinomio generador igual a [7,5] con longitud restringida K = 3.
Puede observarse que los resultados obtenidos distan ampliamente de los
deseados luego de 5 iteraciones, ya que se obtiene una BER = 10−4 para una
Eb /N0 = 5,5dB. Por dicha razón, y vislumbrando la necesidad de realizar
muchas más iteraciones para abordar al objetivo, se ha decidido cambiar el
codificador de K = 3 por uno de K = 5, en busca de mejores resultados.
Simulaciones 75

Codificador con K = 5
En la figura 6.5 se observa que a Eb /N0 = 1dB se obtiene una BER de
2 · 10−4 para 8 iteraciones y de 2 · 10−5 para 10 iteraciones. De esta manera,
se puede dar por alcanzado el objetivo de BER = 10−4 a los fines prácticos
luego de 8 iteraciones. Realizando 2 iteraciones más se supera ampliamente
el objetivo planteado, aunque a costa de un incremento en el retardo de
procesamiento.

Figura 6.5: K=5, G=21, F=37, 100 tramas transmitidas

El hecho de que con el codificador de K = 5 se consiga una mejor per-


formance que con el codificador de K = 3 se debe a que el primero es una
fuente de Markov de 16 estados mientras que el segundo sólo posee 4 estados,
por lo que las estimaciones hacia adelante y hacia atrás vistas en el capı́tulo
2 son más exactas para el codificador de K = 5 que para el de K = 3. Sin
embargo el retardo de procesamiento es mayor en el caso del codificador de
16 estados que para el de 4 estados, ya que el algoritmo MAP rastrea hacia
adelante y hacia atrás el trellis, por lo que el codificador con mayor memoria
necesitará rastrear mayor cantidad de ramas.
Simulaciones 76

6.3.2. Algoritmo Max-Log-MAP


En esta sección se muestran los resultados obtenidos a partir de imple-
mentar los algoritmos Max-Log-MAP en Matlab. Debido a que es conocido su
rendimiento subóptimo repecto de las versiones MAP y Log-MAP, no tendrı́a
sentido simular para un codificador de K = 3 ya que es esperable obtener
peores resultados que los vistos en la figura 6.4, por lo que sólo se han reali-
zado simulaciones para un codificador con K = 5, para 1,7,8 y 10 iteraciones,
de manera de poder contrastar los resultados con aquellos presentados en la
figura 6.5.

Codificador con K = 5
En la figura 6.6 se observa que a Eb /N0 = 1dB la BER todavı́a se en-
cuentra cercana 10−1 incluso luego de 10 iteraciones. Para 10 iteraciones, se
obtiene una BER = 10−4 para una Eb /N0 ∼ = 1,4dB, por lo que la solución
en este caso tiene un rendimiento bastante inferior al observado para el caso
de Log-MAP y 8 iteraciones. De esta manera, se concluye que el algoritmo
Log-MAP tiene mejor performance que la versión Max-Log-MAP, a expensas
de mayor retardo de procesamiento.

Figura 6.6: K=5, G=21, F=37, 100 tramas transmitidas


Capı́tulo 7

Conclusiones

En esta tesis se ha introducido un esquema innovador donde se propone


la utilización de la codificación y decodificación turbo para redes de pro-
tocolos industriales, tomando como ejemplo el protocolo estándar Profibus.
Este nuevo concepto de codificación turbo para redes de datos industriales
no es privativo del protocolo, ya que la técnica opera sobre la capa fı́sica del
mismo, pudiendo implementarse en otros protocolos además del estudiado en
esta tesis.

Se han planteado dos escenarios bien discriminados: en el primero, se in-


tencionaba incrementar la máxima distancia del cable para una determinada
tasa de datos; en el segundo, se mantuvo constante la distancia del cable,
incrementando la tasa de transferencia de datos, hasta alcanzar en todos los
casos una BER = 10−4 para una relación Eb /N0 = 1dB.

Los resultados alcanzados mediante planteos teóricos y simulaciones de-


muestran que es posible incrementar hasta 7,61 veces la máxima distan-
cia del cable explicitada en la norma del protocolo para 1,5 Mbps, mientras
que es factible aumentar hasta un 135 por ciento la tasa de transferencia
de datos impuesta por la norma Profibus para una distancia de cable de 400
metros.

Sin embargo, tal vez el resultado obtenido más destacable es aquel que
denota la posibilidad de extender la máxima distancia de cable a 2291 me-
tros para una tasa de 500 Kbps, superando ası́ la máxima distancia impuesta
por Profibus PA (1900 metros, a una tasa de 31,25 Kbps), transmitiendo en-
tonces a una mayor distancia con una tasa de datos 16 veces superior.

77
Conclusiones 78

También se ha comprobado que es mucho más beneficioso aumentar la


distancia del cable a tasa constante que el proceso inverso, ya que la curva
de atenuación en función de la frecuencia del medio fı́sico es muy sensible
a variaciones de frecuencia en el orden de los MHz. De hecho, aumentar la
tasa de datos para una longitud de cable constante no retribuye una gran
mejora, al menos en comparación con el incremento de la máxima distancia
de cable para tasa de datos constante. Afortunadamente, el campo industrial
es un escenario muy beneficioso para este tipo de relaciones de compromiso,
ya que al manejarse distancias del orden de los 1000 metros es generalmente
más provechoso incrementar la distancia de transmisión que la tasa de datos.

Las simulaciones arrojaron resultados satisfactorios para el esquema pro-


puesto, obteniéndose una BER = 2 · 10−4 luego de 8 iteraciones para una
longitud de trama de 2816 bits, utilizando codificadores de longitud restrin-
gida K = 5, implementándose el algoritmo Log-MAP. Se ha analizado la
posibilidad de implementar la versión Max-Log-MAP con un esquema de
hasta 10 iteraciones, habiendo encontrado un rendimiento bastante inferior
al algoritmo Log-MAP, por lo que se propone la implementación de este últi-
mo, en perjuicio del retardo de procesamiento.

Adicionalmente, el impacto sobre el precio final de cada equipo que im-


plemente Profibus Turbo es menor al 1 por ciento de su valor actual, lo cual
posibilita la implementación desde el punto de vista económico.

Resumiendo, es posible mejorar notablemente la performance del proto-


colo Profibus mediante la introducción de la técnica de codificación y deco-
dificación turbo, y un adecuado análisis espectral de la señal transmitida en
el canal de comunicaciones.

Esta tesis deja abierta una puerta hacia la introducción de la codificación


turbo en el campo de las comunicaciones industriales. Si bien este trabajo se
ha enfocado en los protocolos cableados, con el advenimiento de las versiones
inalámbricas de los protocolos industriales, este nuevo concepto será proba-
blemente recibido con gran aceptación en futuras aplicaciones.
Apéndice A

Fundamentos matemáticos

A.1. Lı́mite de Shannon


Según el teorema de Nyquist, la capacidad del canal C y el ancho de
banda utilizado W se relacionan mediante la siguiente ecuación [6]:

C = 2W log2 M (A.1)
C = 2W k (A.2)
C
= 2k (A.3)
W
donde k es la tasa del código y M es la cantidad de sı́mbolos del alfabeto
código.
En un canal AWGN (Aditive White Gaussian Noise), se define la capacidad
de Shannon como:
CEb
 
C = W log2 1 + (A.4)
W N0
Utilizando la ecuación A.3 y reemplanzando en A.4 se obtiene:

Eb 22k − 1
≥ (A.5)
N0 2k
Por lo tanto, para un código con tasa k=1/2, se obtiene la siguiente
inecuación, con la Eb /N0 medida en veces:
Eb
≥1 (A.6)
N0

79
Fundamentos matemáticos 80

De la ecuación anterior se desprende que para un código con tasa k = 1/2


el lı́mite teórico de la relación Eb /N0 es 0dB para transmisión libre de errores.

Es importante no confundir este resultado con el conocido lı́mite de Shan-


non, el cual surge de suponer que la señal transmitida puede ocupar un ancho
de banda infinito reduciendo la eficiencia espectral C/W a cero, lo cual es
equivalente a decir que la tasa de código k tiende a cero. Este lı́mite establece
que la energı́a del bit de fuente, Eb , debe cumplir lo siguiente:

Eb 22k − 1
lı́m = lı́m = −1,59dB (A.7)
k→0 N0 k→0 2k
El lı́mite expresado por la ecuación A.7 establece una cota inferior para
la energı́a de bit Eb frente a una densidad espectral de potencia de ruido N0 ,
para establecer una comunicación confiable libre de errores.

A.2. Expresión de la LLR del canal


Según [7], considerando un canal AWGN y teniendo en cuenta transmisión
polar xi = ±1, las probabilidades descriptas en 2.4 son iguales a:

1 Eb 2
P (yi |xi = +1) = √ e− 2σ2 (yi −1)
2πσ
1 Eb 2
P (yi |xi = −1) = √ e− 2σ2 (yi +1)
2πσ
Eb 2
e− 2σ2 (yi −1)
L(yi |xi ) = ln Eb 2
e− 2σ2 (yi +1)
Eb Eb
= − 2 (yi − 1)2 + − 2 (yi + 1)2
2σ 2σ
Eb
= 2 2 yi
σ

A.3. Probabilidad a priori de dk


Refiriéndonos a la ecuación 2.2, reemplazando bi por dk , se tiene:
!
P (dk = +1)
L(dk ) = ln (A.8)
P (dk = −1)
Además siempre debe cumplirse:
Fundamentos matemáticos 81

P (dk = +1) = 1 − P (dk = −1) (A.9)


Despejando resulta [7]:

P (dk = +1)
eL(dk ) = (A.10)
1 − P (dk = −1)
Finalmente se llega a una expresión general de la probabilidad a priori
P (dk ) del bit dk :

e−L(dk )/2 dk L(dk )/2


P (dk = ±1) = −L(d )
e = C1 edk L(dk )/2 (A.11)
1+e k

con dk = ±1 y C1 una constante cualquiera no nula que no interesa para


el proceso de decodificación.

A.4. Expresión extendida de P (Y |X)


Sea una fuente de Markov que genera m salidas codificadas (incluyendo
las posibles salidas sistemáticas). Consideremos la probabilidad condicional
de recibir la secuencia Y dado que se ha transmitido la secuencia X:

m
Y
P (Y |X) = P (yik |xik ) (A.12)
i=1
m
1 Eb Pm 2
e 2σ2 i=1 (yik −xik )
Y
= √ (A.13)
i=1 2πσ
1 Eb Pm
(y 2 +xik 2 )
Eb Pm
(y x )
= √ m
e 2σ 2 i=1 ik e 2σ 2 i=1 ik ik (A.14)
( 2πσ)
Eb Pm
(yik xik )
= C2 e 2σ2 i=1 (A.15)

donde i representa al ı́ndice de la salida codificada mientras que k re-


presenta el tiempo. En el caso de un codificador como el de la figura 2.2,
k = {1, 2, 3} representando k = 1 a la salida sistemática, k = 2 la salida del
primer codificador y k = 3 la del segundo codificador (el que hace uso del
interleaver).

A.5. Expresión de γk
Refiriéndonos a la expresión de γk en la ecuación 2.13, y combinándola
con las ecuaciones A.11 y A.15 se tiene:
Fundamentos matemáticos 82

γk (sk−1 → sk ) = P (dk )P (yk |xk ) (A.16)


Lc
Pm
= Cedk L(dk )/2 e 2 i=1
(yik xik )
(A.17)
Lc Lc
Pm
= Cedk L(dk )/2 e 2
(y1k x1k )
e 2 i=2
(yik xik )
(A.18)
Lc Lc
Pm
= Cedk L(dk )/2 e 2
(y1k dk )
e 2 i=2
(yik xik )
(A.19)
de donde se observa que x1k = dk por ser éste el dato sistemático.

Renombrando el último término de la ecuación A.19 se obtiene:

Lc
γk (sk−1 → sk ) = Cedk L(dk )/2 e 2
(y1k dk )
γk extr (sk−1 → sk ) (A.20)

A.6. Expresión de αk
Refiriéndonos a [7], quien utiliza la notación Y1n para describir la secuencia
{y1 , ..., yn }, se desarrolla:

αk (sk ) = P (Y, sk ) (A.21)


= P (Y1k−1 , yk , sk ) (A.22)
U −1
P (sk−1 , sk , Y1k−1 , yk )
X
= (A.23)
sk−1 =0
U −1
P (sk−1 , Y1k−1 )P (sk , yk |sk−1 Y1k−1 )
X
= (A.24)
sk−1 =0
U
X −1
= αk−1 γk (sk−1 → sk ) (A.25)
sk−1 =0

A.7. Expresión de βk

U −1
n
X
βk (sk ) = P (sk+1 , Yk+1 |sk ) (A.26)
sk+1 =0
U −1
n
X
= P (sk+1 , Yk+1 |sk )P (Yk+2 |sk+1 ) (A.27)
sk+1 =0
U
X −1
= βk+1 (sk+1 )γk (sk+1 → sk ) (A.28)
sk+1 =0
Fundamentos matemáticos 83

A.8. Transformada de Fourier de un pulso


rectangular
Consideremos un pulso g(t) de duración T y amplitud unitaria:
(
1 si |t| < T /2
g(t) = (A.29)
0 si |t| > T /2
Su correspondiente transformada de Fourier es [4]:
ωT
G(ω) = T sinc( ) (A.30)

Es decir, el primer cero de la transformada se encuentra en ω = 2π
T
, por
ω 1
lo que f = 2π = T = R para dicha situación, donde R es la tasa de datos.

Tomando como ejemplo una tasa de R = 1,5M bps se grafica la transfor-


mada de Fourier del pulso asociado, como puede verse en la figura A.1. Puede
observarse que el primer cero de la sinc ocurre para f = R = 1,5M Hz 1 .
Consideremos ahora una secuencia arbitraria de bits, a una tasa R bps.
El peor caso sucede cuando dicha secuencia es alternada, ya que el ancho de
banda para dicha tasa de datos es máximo. Una secuencia de “1” y “0” a una
tasa R bps alternados puede formarse a partir de convolucionar la señal en el
tiempo con un tren de deltas de Dirac espaciadas un tiempo 2/R entre sı́, de
manera que cada semiperı́odo representa un bit. Convolucionar dos señales
en el dominio del tiempo equivale a multiplicar sus transformadas de Fourier
en el dominio de la frecuencia, por lo que se estará multiplicando el espectro
del pulso original por el correspondiente al tren de deltas. Debido a que un
tren de deltas de Dirac en el tiempo se transforma en otro tren de deltas
en el espectro, se estará muestreando la señal original en el espectro, y si la
señal en el tiempo es suficientemente larga como para considerarla periódi-
ca, dichas muestras representarán los coeficientes del desarrollo en series de
Fourier de la señal periódica en cuestión.

Sea c(t) la secuencia alternada periódica y p(t) el tren de deltas de Dirac


espaciados en 2/R en el tiempo, se obtiene:
+∞
X 2k
c(t) = g(t) ∗ p(t) = r(t) ∗ δ(t − ) (A.31)
k=−∞ R
1
R se mide en bits/seg, mientras que f se mide en Hz, aunque por simplicidad de
notación se igualan las magnitudes numéricamente.
Fundamentos matemáticos 84

Figura A.1:

Sea P (ω) la transformada de Fourier de p(t), su expresión es:

4π +∞
X
P (ω) = δ(ω − kπR) (A.32)
R k=−∞
De esta manera, la tranformada de c(t), C(ω) es:

C(ω) = πRG(ω = πR) (A.33)


Debio a que ω = 2πf , muestrear en ω = kπR es equivalente a hacer-
lo en f = kR/2. El espectro normalizado resultante de la señal periódica
se muestra en la figura A.2. Nótese que sólo aparecen los armónicos impares
del tipo (2k + 1)R/2, con k = 0, 1, 2, ..., n por tratarse de una señal cuadrada.

Para determinar el ancho de banda de la señal, se utilizará el criterio de


los√3dB de caida de potencia, análogo a plantear la caida de la amplitud a
1/ 2 ∼= 0,707 del valor pico del módulo de la transformada. Siguiendo con el
ejemplo de la secuencia de 1,5M bps, puede verse en la figura A.2 que para el
primer armónico en f = R/2 = 750KHz la amplitud vale aproximadamente
0,65, siendo el valor pico 1 debido a que se ha normalizado el gráfico. De
Fundamentos matemáticos 85

esta manera, el ancho de banda de la señal se puede aproximar al primer


armónico, es decir 750KHz en banda base.

Figura A.2:

Generalizando, para una señal en banda base de R bps es posible aproxi-


mar su ancho de banda de 3dB a R/2 Hz.

Razonando en forma distinta a la habitual, si se piensa en un canal li-


mitado a R/2 Hz, según el teorema de la capacidad de Nyquist descripto en
la ecuación A.1, es posible transmitir una cantidad de información igual a R
bps (sin codificación), por lo que es coherente pensar que una señal de R bps
puede ser limitada a un ancho de banda de R/2 Hz, tal como se ha planteado
en esta sección.
Apéndice B

Interfaz RS485

Introducción
La interfaz RS485, al igual que la interfaz RS422, ha sido desarrollada
para la transmisión en serie de datos de alta velocidad a grandes distancias y
encuentra creciente aplicación en el sector industrial. Mientras que la RS422
sólo permite la conexión unidireccional de hasta 10 receptores en un trans-
misor, la RS485 está concebida como sistema Bus bidireccional con hasta 32
hosts. Fı́sicamente las dos interfaces sólo se diferencian mı́nimamente. El Bus
RS485 puede instalarse tanto como sistema de 2 hilos o de 4 hilos. Dado que
varios transmisores trabajan en una lı́nea común, tiene que garantizarse con
un protocolo que en todo momento esté activo como máximo un transmisor
de datos.
La norma RS485 define solamente las especificaciones eléctricas para recep-
tores y transmisores diferenciales en sistemas de bus digitales. La norma ISO
8482 estandariza además la topologı́a de cableado con una longitud máxima
de 500 metros.

Bus de 2 hilos RS485


El Bus de 2 hilos RS485 se compone según la figura B.1 del cable propio
de Bus con una longitud máxima de 500 metros. Los hosts se conectan a
este cable a través de una lı́nea adaptadora, denominada stub, de máximo 5
metros de largo. La ventaja de la técnica de 2 hilos reside esencialmente en
la capacidad multimaster, en donde cualquier participante puede intercam-
biar datos en principio con cualquier otro. El bus de 2 hilos es básicamente
apto sólo half-duplex; es decir, puesto que sólo hay a disposición una vı́a de
transmisión, siempre puede enviar datos un solo participante. Sólo después
de finalizar el envı́o, pueden por ejemplo responder otros hosts. La aplica-

86
Interfaz RS485 87

ción más conocida basada en la técnica de 2 hilos es el protocolo industrial


PROFIBUS.

Figura B.1: Esquema de bus RS485 de dos hilos [19]

Bus de 4 hilos RS485


La técnica de 4 hilos usada, por ejemplo, por el bus de medición DIN
(DIN 66 348) sólo puede ser usada por aplicaciones Master/Slave. Conforme
a la figura B.2 se cablea aquı́ la salida de datos del maestro a las entradas
de datos de todos los esclavos. Las salidas de datos de los esclavos están
concebidas conjuntamente en la entrada de datos del maestro.

Figura B.2: Esquema de bus RS485 de cuatro hilos [19]

Medio fı́sico de transmisión


Los datos en serie se transmiten sin referencia de masa como diferencia de
tensión entre dos lı́neas correspondientes. Para cada señal a transmitir existe
Interfaz RS485 88

un par de conductores que se compone de una lı́nea de señales invertida y otra


no invertida. La lı́nea invertida se caracteriza por regla general por el ı́ndice
“A” o “-”, mientras que la lı́nea no invertida lleva “B” o “+”. El receptor
evalúa solamente la diferencia existente entre ambas lı́neas, de modo que las
perturbaciones de modo común en la lı́nea de transmisión no falsifican la
señal útil. Los transmisores RS485 ponen a disposición bajo carga un nivel
de salida de ±2V entre las dos salidas; los módulos de recepción reconocen
el nivel de ±200mV como señal válida. La asignación tensión de diferencia
al estado lógico se define del modo siguiente:

A − B < −0,3V = MARK = OFF = Nivel Lógico 1 (B.1)

A − B > +0,3V = SPACE = ON = Nivel Lógico 0 (B.2)

Longitud de lı́neas
Usando un método de transmisión simétrico en combinación con cables
de pares de baja capacidad y amortiguación (par trenzado o twisted pair,
TP) pueden realizarse conexiones muy eficaces a través de una distancia de
hasta 500m con altas tasas de transmisión. El uso de un cable TP de alta
calidad evita por un lado la diafonı́a entre las señales transmitidas y por el
otro reduce adicionalmente el efecto del apantallamiento, la sensibilidad de
la instalación de transmisión contra señales perturbadoras entremezcladas.
En conexiones RS485 es necesario un terminador al final del bus para obligar
al nivel de pausa en el sistema cuando no esté activo ningún transmisor de
datos, y evitar adicionalmente posibles reflexiones debidas a desadaptaciones
del bus.
Apéndice C

Descripción del protocolo


Profibus

C.1. Servicios de capa de enlace


La capa de enlace le ofrece cuatro tipos de servicios a las capas superiores:
tres servicios de tipo asincrónico y uno cı́clico (o servicio de votación). Todos
los servicios excepto el servicio cı́clico le permiten al usuario distinguir entre
dos prioridades: información de alta prioridad (importante) e información de
baja prioridad (menos importante). El tipo de alta prioridad está dedicado
al intercambio de información esporádica sensible al tiempo y crı́tica para
la seguridad (por ejemplo, alarmas), mientras que el tipo de baja prioridad
es usado para todo lo demás. Los servicios cı́clicos pertenecen a la prioridad
baja, sin embargo, las reglas de asignación de ancho de banda son diferentes
a aquellas destinadas a información ordinaria de baja prioridad.

Aunque no está claramente especificado en el estándar, es razonable asu-


mir para los tipos de servicios asincrónicos que dentro de cada tipo de prio-
ridad los pedidos del servicios son procesados en orden “el primero que entra
es el primero que sale” (FIFO)[14], sin tener en cuenta el tipo de servicio.
En otras palabras, conceptualmente hay dos filas de pedidos, una para pedi-
dos de baja prioridad y otra para pedidos de alta prioridad. Cada pedido en
principio, sin tener en cuenta su tipo de servicio, es colocado dentro de uno
de estas filas de acuerdo a su prioridad. Para los servicios de tipo cı́clicos, se
mantiene una especie de tabla de votación.

Para la discusión sobre servicios se usará la terminologı́a del modelo de


referncia OSI: se accede a los servicios a través de un punto de acceso de ser-

89
Descripción del protocolo Profibus 90

vicio (SAP), y generalmente cuatro servicios primitivos están involucrados


en la comunicación entre el proveedor del servicio y el usuario del mismo:
pedido, indicación, respuesta y confirmación. Como convención, al referirnos
a un servicio primitivo perteneciente a un servicio A, se usará el término
A.primitivo, por ejemplo, FDL DATA ACK.REQUEST. Para todos los ser-
vicios hay una distinción entre los roles de la estación iniciadora y la estación
contestadora. El tratamiento del servicio es iniciado cuando una entidad de
la capa de aplicación (llamada usuario FDL) en una estación iniciadora hace
un pedido primitivo. Es más, una unidad de datos de protocolo (PDU) es la
forma de comunicación entre dos entidades pares.

Cuadro C.1: Servicios FDL [20]

Servicio SDA SDN SRD CSRD


ACK inmediato sı́ no sı́ sı́
Orientado a conexión no no no configuración
conexión local
Datos en ACK no - sı́ sı́
Ocurrencia acı́clica acı́clica acı́clica cı́clica

Un atributo esencial de varios de los servicios primitivos son las infor-


maciones de dirección. La información de dirección consiste en un byte de
dirección y un punto de acceso de servicio opcional (SAP). Profibus soporta
tres tipos de direcciones: una dirección unicast tiene un byte de direción con
un valor entre 0 y 126 (por ello, el número de estaciones de una LAN Profibus
es restringido), y opcionalmente un SAP puede ser usado. Para direcciones
multicast y direcciones de broadcast el byte de direción tiene un valor de 127
y la dirección de grupo/dirección multicast es seleccionada a través del valor
SAP.

Para cada pedido primitivo exactamente una confirmación primitiva es


creada, la cual contiene información sobre el éxito del pedido. Por la presun-
ción FIFO discutida anteriormente, dentro de una misma clase de prioridad
las primitivas de confirmación ocurren en el mismo orden que las correspon-
dientes primitivas de pedido. El estándar perscribe que una vez iniciado el
paquete de transmisión, no puede ser interrumpido por otros pedidos. Dicho
de otra manera: Profibus no permite prerrogativas al manejar pedidos. Esta
propiedad es llamada propiedad de atomicidad.

Profibus no utiliza respuestas primitivas. Todos los servicios están di-


señados de manera que la instancia de FDL de una estación contestadora
Descripción del protocolo Profibus 91

puede generar tramas de respuesta inmediatamente, sin interactuar con ins-


tancias de capas superiores.

Los servicios de Profibus son explicados en las secciones siguientes, un


corto resumen de los servicios puede verse en el cuadro C.1.

SDA: Envı́o de información con acuse de recibo


El servicio de envı́o de información con acuse de recibo (SDA) es basica-
mente un servicio de datagrama semi-confiable. Un bosquejo de sus interac-
ciones puede verse en la figura C.1.
El usuario FDL en la estación iniciadora es quien inicia este servicio. Este
prepara un bloque de datos de hasta 246 bytes de largo, elige una prioridad,
provee el byte de dirección de destino y punto de acceso a servicio destino
(DSAP) para que la estación objetivo y su propio SAP como punto de ac-
ceso de servicio fuente (SSAP). Toda esta información es transmitida con el
pedido de servicio primitivo FDL DATA ACK a la instancia FDL a través
del SAP local. La dirección de destino es solicitada a la dirección unicast.

Tiempo después la instancia FDL local intenta enviar el bloque de datos


dentro de una única trama a la estación contestadora. Quien responde tiene
que acusar recibo de la trama usando un acuse de recibo de capa MAC inme-
diato. El acuse de recibo no transporta información. Si el iniciador no recibe
respuesta dentro de un tiempo pre-especificado (llamado slot time, TSL ), éste
repite la trama.

El número total de pruebas está acotado. Cuando el resultado de la trans-


misión de prueba es conocido, es decir, un acuse de recibo es recibido o el
máximo número de pruebas es agotado, el usuario FDL local es informado
sobre este resultado con la primitiva FDL DATA ACK.CONFIRM. Adicio-
nalmente, esta primitiva contiene la información de dirección y nivel de prio-
ridad pasado con el correspondiente primitivo FDL DATA ACK.REQUEST .

Cuando la instancia FDL en el iniciador ha comenzado a procesar una


primitiva FDL DATA ACK.REQUEST X, es necesario conseguir el resul-
tado tan rápido como sea posible,es decir, no está permitido procesar otros
pedidos Y o pasar el token mientras se está procesando X.

En la estación contestadora, a la primera recepción de una trama de da-


tos se genera una primitiva FDL DATA ACK.INDICATION, la información
es transmitida como un parámetro. Si quien responde identifica la trama
Descripción del protocolo Profibus 92

Figura C.1: Interacciones del servicio SDA [14]

como retransmitida (por el protocolo de bit alternado), es reconocida su re-


cepción y silenciosamente descartada. La capa FDL asegura que para cada
pedido primitivo FDL DATA ACK se genera, como máximo, una indica-
ción primitiva FDL DATA ACK y exactamente una confirmación primitiva
FDL DATA ACK.

SDN: Envı́o de información sin acuse de recibo


El servicio de envı́o de información sin acuse de recibo es básicamente un
servicio de datagrama sin aviso de recepción, aplicable a direcciones broad-
cast, unicast y multicast. Un bosquejo de las interacciones puede ver en la
figura C.2.
El usuario en el iniciador transmite una primitiva FDL DATA.REQUEST
a la instancia FDL. Esta primitiva carga los mismos parámetros que una
primitiva FDL DATA ACK.REQUEST descripta en la sección anterior. La
dirección de destino puede ser unicast, multicast o broadcast. Luego, la ins-
tancia MAC transmite una trama con la información y luego produce una
primitiva FDL DATA.CONFIRM para el usuario FDL local. Todas las es-
taciones a las cuales se dirige y exitosamente reciben la trama, crean una
indicación primitiva FDL DATA y entrega la información a su usuario FDL,
como resultado, no confirmando ninguna recepción adecuada. Ninguna esta-
ción tiene permitido enviar acuse de recibo.
Descripción del protocolo Profibus 93

Figura C.2: Interacciones del servicio SDN [14]

SRD: Envı́o y respuesta con datos


El servicio de envı́o y recepción de datos (SRD) es básicamente el mis-
mo que el servicio SDA, sin embargo, el acuse de recibo enviado por quien
responde puede llevar información consigo1 . Un bosquejo de las interacciones
puede verse en la figura C.3.

Figura C.3: Interacciones del servicio SRD [14]


1
Algunos autores, como por ejemplo [3], denominan a esta técnica piggybacking.
Descripción del protocolo Profibus 94

El usuario FDL en la estación contestadora puede colocar una cantidad


de información (hasta 246 bytes) junto con un SAP asociado y una prioridad
dentro un buffer interno de la instancia FDL. Esto se hace usando la primitiva
FDL REPLY UPDATE.REQUEST . Luego de llenar el buffer, la instancia
FDL genera la primitiva FDL REPLY UPDATE.CONFIRM correspondien-
te. Un parámetro adicional (reuse information) de la primitiva de pedido
indica, si la información es usada para responder uno solo o múltiples pedi-
dos. El usuario FDL en la estación contestadora puede escribir este buffer en
cualquier momento.

El servicio restante procede de una manera similar al servicio SDA (usan-


do las primitivas FDL DATA REPLY.REQUEST,
FDL DATA REPLY.CONFIRM y FDL DATA REPLY.INDICATION). Sin
embargo, si quien responde genera su acuse de recibo, chequea si existe un
buffer para el SAP pedido, y, de ser ası́, escribe los contenidos de este buffer
dentro de una trama ACK inmediata. Esta información pasa al usuario FDL
en la estación iniciadora con la primitiva FDL DATA REPLY.CONFIRM .
Si los contenidos del buffer debieran ser transmitidos solo para un mismo
pedido, el buffer es vaciado. Necesariamente las repeticiones de tramas, por
ejemplo, debido a ACK corruptos, son manejadas almacenando en un buffer
la trama de ACK por el tiempo que sea necesario.

Si la trama de acuse de recibo es errónea, la estación iniciadora retrans-


mite su trama de petición. Quien responde luego retransmite la última trama
sin reconstruirla. Si el usuario FDL en la estación contestadora usa la primi-
tiva FDL REPLY UPDATE.REQUEST entre la primera y segunda trama
ACK, no tiene consecuencias en la retransmisión.

CSRD: Envı́o cı́clico y respuesta con datos


El servicio de envı́o y recepción cı́clico de datos (CSRD) es el servicio
Profibus más complicado, y no discutido en su totalidad. Las medidas de
performance en tiempo real definidas anteriormente se enfocan totalmente a
mensajes de alta prioridad, mientras que el servicio CSRD es, a priori, de
baja prioridad.

Al comienzo de este servicio, el usuario FDL local, le provee a la instan-


cia FDL local, una lista de direcciones de estaciones unicast (poll list, lista
de votación). La instancia FDL local mantiene para cada estación en esta
lista un marcador y un buffer opcional. El usuario FDL local puede poner un
bloque de datos (hasta 246 bytes) dentro de este buffer, junto con el SAP,
Descripción del protocolo Profibus 95

prioridad y reuso de información, es decir, los contenidos del buffer pueden


ser enviados sólo una vez o en varias veces. En la estación contestadora la
instancia FDL puede destinar buffers también, los cuales son manejados igual
que el servicio SRD.

Las estaciones en la lista de votación son consultadas en forma circular2 .


Para cada estación en la lista de votación se envı́a una trama de petición, la
cual puede cargar información, si el buffer asociado existe y no está vacı́o.
Si los contenidos del buffer debieran ser transmitidos sólo una vez, el buffer
es vaciado. A la estación contestadora se le solicita que envı́e un acuse de
recibo inmediato, el cual puede también cargar los contenidos del correspon-
diente buffer. Por cada petición la estación iniciadora lleva a cabo un número
de retransmisiones predeterminado. Si todos los intentos fallan, la estación
contestadora es marcada como “muerta” modificando la variable del mar-
cador. Tiempo después, la estación muerta es pingueada nuevamente por la
instancia FDL local, sin embargo, no se llevan a cabo retransmisiones. Si la
estación muerta responde, es marcada como “viva” y la instancia FDL local
procede con su normal operatoria.

C.2. Protocolo de MAC y de enlace de datos


En la capa MAC, Profibus combina dos principios: comunicación maes-
tro/esclavo para intercambio de información y pasaje de token para manejar
el derecho a iniciar paquetes de transmisiones. Además, se distinguen dos
tipos de estaciones: las estaciones activas pueden participar en el proceso
de pasaje de token, mientras que las estaciones pasivas no pueden hacerlo.
Una estación activa que, en ese momento, posee el token, es llamada estación
master, todas las otras estaciones cumplen el rol de estaciones esclavas. So-
lo a la estación master se le permite iniciar la transferencia de información,
una estación esclava sólo puede, tal vez, transmitir información si solo tiene
que enviar un acuse de recibo inmediato a un marco dirigido a si mismo.
Es por ello, que las primitivas de servicios FDL DATA ACK.REQUEST,
FDL DATA.REQUEST y FDL DATA REPLY.REQUEST sólo pueden ser
realizados en estaciones activas.

Pasaje de token y mantenimiento del anillo


El protocolo del pasaje de token de Profibus es similar al protocolo To-
ken Bus IEEE 802.4 y usa un medio de broadcast. Se forma un anillo lógico
2
En forma de round-robin.
Descripción del protocolo Profibus 96

ascendiendo direcciones de estaciones. El espacio de direcciones es pequeño,


una dirección de estación está en el rango de 0 a 126. Cada estación (a la
que se denominará TS: Esta Estación) conoce a través del mecanismo de
mantenimiento de anillo explicado debajo, la dirección de su sucesor lógico
(NS: Próxima Estación) y su predecesor lógico (PS: Previa Estación). Si TS
recibe una trama token válida con TS como dirección de destino, chequea
si fue enviado a través de su PS o no. De ser ası́, el token es aceptado, de
otra manera la trama es descartada. En el segundo caso, si la misma trama
token es recibida nuevamente como la siguiente trama, el token es aceptado
y quien envı́a el token es registrado como nuevo PS y la lista de estaciones
activas (LAS) es actualizada. De todas formas, luego de aceptar el token TS
determina el tiempo de retención del token THT (de acuerdo a una varian-
te simplificada del protocolo de token temporizado con tiempo objetivo de
rotacion del token TT T RT ) y tiene permitido enviar información durante el
THT. Si ya no hay información o el THT expira, se le solicita al TS pasar el
token a NS a través de una trama token. Este debe hacerse si TS es el único
miembro del anillo (NS=TS=PS), y TS debe aceptar el token de la misma
manera como si P S 6= T S. Luego de mandar una trama token, TS escucha
en el medio en busca de alguna actividad. Esto puede ser la recepción de un
encabezado válido de token (indicando que NS ha aceptado el token) o la re-
cepción de alguna transmisión errónea. Sin embargo, TS escucha en el medio
solo durante el tiempo slot TSL el cual es tipicamente elegido muy corto, por
ejemplo, dentro del rango de 100µseg a 400µseg. Si transcurrido este tiem-
po, no hay actividad en el medio, la trama token es repetida (claramente,
es necesario que las estaciones activas reaccionen lo suficientemente rápido
a las tramas token, de otra manera ocurren colisiones). Si nuevamente no
hay actividad, y una tercera prueba es también infructuosa, se asume al NS
muerto y TS determina la próxima estación en el anillo (es decir, el sucesor
de NS), hace de este el nuevo NS y trata de pasarle el token, siguiendo las
mismas reglas. La nueva estación puede ser determinada desde el LAS, el
cual es actualizado a través del mecanismo de mantenimiento. Si el TS no
encuentra otra estación, se envı́a una trama token a sı́ mismo.

Una regla especial de protocolo es la siguiente: TS debe leer nuevamente


del medio todas las tramas de token que transmite, bit por bit (denominada
propiedad de eco, o hearback ), a fin de detectar un transceptor defectuoso
y resolver colisiones. Si TS encuentra alguna diferencia con la primera vez,
espera alguna respuesta (la cual bien puede ocurrir debido a errores sin de-
tectar en la trama de token). Si no hay actividad en el medio, repite la trama
de token. Si TS nuevamente encuentra una diferencia, descarta el token in-
mediatamente y se remueve a sı́ mismo del anillo. La razón para esto es la
Descripción del protocolo Profibus 97

presunción de que el transceptor está defectuoso y sus resultados no son con-


fiables.

El mecanismo de mantenimiento del anillo funciona de dos maneras di-


ferentes. Primero, si la estación es nuevamente encendida, es necesario que
escuche pasivamente en el medio, hasta que haya recibido dos ciclos sucesivos
idénticos y además tenga una vista válida sobre todo el anillo lógico (conocido
como estado de escucha de token). Durante este tiempo no se permite enviar
o responder a tramas de información o aceptar el token. Cada dirección de
estación encontrada en una trama de token perteneciente a estos dos ciclos
es incluida dentro de la LAS. Luego de construir una vista válida la estación
puede entrar en el anillo si otra estación le pasa el token. La segunda regla
requiere que cada estación inspeccione cada trama de token correctamente
recibida e incluya la fuente y la dirección de destino en la LAS. Una regla
importante aquı́ es la siguiente: si TS ya se siente incluı́da en el anillo lógico y
lee una trama de token, donde TS es “salteada” (es decir, la dirección de TS
está realmente dentro del rango de direcciones abarcadas por quien envı́a y
por quien recibe la trama de token) se remueve a sı́ misma del anillo y se com-
porta como recién encendida. A fin de que otra estación pueda pasar el token
a una estación nuevamente encendida, cada estación a mantiene una lista
de huecos (GAPL, gap list), que contiene todas las direcciones de estaciones
posibles entre a y su NS b. Es necesario, que una estación a, periódicamente
consulte todas las direcciones en su GAPL a través del envı́o de una trama
FDL STATUS.REQUEST a una sola dirección c y a la espera de una ranura
de tiempo TSL por una respuesta, lo cual indica el estado actual de c (lis-
ta/no lista para el anillo). Una estación que trata de detectar dos ciclos de
token idénticos responderá con un estado de “no listo”. Durante cada ciclo
de token, a consulta al menos una dirección de estación en su GAPL. Si la
estación en la GAPL responde como “lista”, a cambiará su NS, acortará su
GAPL, actualizará su LAS, y luego enviará una trama de token a la nueva
estación. El perı́odo para buscar en la GAPL es creado por un timer especial
(gap timer ), el cual es configurado como un múltiplo entero (factor de hueco,
el estándar requiere valores entre 1 a 100) del tiempo objetivo de rotación de
token TT T RT .

Para dejar el anillo es suficiente detener todas las transmisiones. En este


caso PS detectará la pérdida de estación cuando trate de pasar el token a
TS, sin éxito. Un mecanismo especial es usado para la inicialización del anillo
o para manejar la pérdida de token debido a la caı́da del sistema del pro-
pietario actual del token: cada estación escucha permanentemente el medio.
Cada vez que el medio se vuelve inactivo, TS pone en funcionamiento un
Descripción del protocolo Profibus 98

temporizador especial, el temporizador de expiración (timeout timer ), con el


valor de timeout TT O . El temporizador es reseteado cada vez que el medio
se vuelve activo. Si el temporizador expira (sin transmisión en el medio por
algún tiempo), TS “pide el token”, es decir, comienza a comportarse como el
propietario actual del token y lleva a cabo algunas transmisiones de tramas:
envı́a tramas de información o pasa el token a su actual NS. Si TS no estaba
en estado de escucha de token al momento de expirar el temporizador, no
hay cambio en su estado interno, especı́ficamente en su LAS, NS y PS. En
el otro caso, puesto que la estación aún no tiene una visión válida del anillo,
entiende que el anillo está vacı́o y ası́mismo como el único miembro de LAS.

El valor de timeout depende linealmente de la dirección de la estación n


[14]:

TT O (n) = (6 + 2n)TSL (C.1)


Esto puede conducir a colisiones, y es necesaria la caracterı́stica de (hear-
back ) para resolverlas. Una situación donde las colisiones pueden ocurrir es la
siguiente: consideremos que en un anillo vacı́o dos estaciones son nuevamen-
te encendidas en momentos diferentes, de manera que sus temporizadores
expiran simultáneamente. Cuando ambas estaciones comienzan a transmi-
tir tramas de token, la colisión resultante induce a errores hearback. Ambas
estaciones se retiran del anillo y detienen las tranmisiones, mientras inician
sus temporizadores de expiración simultáneamente. Debido a las diferentes
direcciones de estaciones los temporizadores expiran en momentos diferentes,
y ahora un anillo puede ser construido sin más colisiones.

Asignación de ancho de banda


Luego de recibir el token, una estación activa computa su tiempo de re-
tención del token (THT ) restando el tiempo de rotación real de token TRR
(tiempo medido entre los arribos de dos token) del tiempo objetivo de rota-
ción de token TT T RT :

TT H = TT T RT − TRR (C.2)
El tiempo de rotación real de token es medido constantemente como el
tiempo entre sucesivos arribos de token. Se inicia un temporizador (de fija-
ción de token) con el TT H calculado.

Luego de recibir el token, se le permite a la estación master manejar


una trama de alta prioridad incluyendo retransmisiones necesarias, a pesar
Descripción del protocolo Profibus 99

del valor del THT (el manejo de una trama incluyendo las retransmisiones
se conoce como “ciclo”). Es por ello, que esta caracterı́stica sólo puede ser
explotada en los servicios SDA, SDN y SRD, puesto que los servicios CSRD
son llevados a cabo con baja prioridad.

Si más mensajes de alta prioridad están disponibles y el THT no ha expi-


rado, la estación continúa con ciclos de alta prioridad. Excepto por el primer
ciclo, es necesario que al comienzo de un nuevo ciclo de baja o alta priori-
dad, no haya expirado el temporizador de fijación de token. Si el éste expira
mientras tanto, se le permite terminar el ciclo a la estación, incluyendo todas
las retransmisiones. Entonces la estación debe pasar el token a su NS.

Primero, la estación debe llevar a cabo todos los ciclos de alta priori-
dad disponibles, hasta que el temporizador expire o la cola de alta prioridad
se vacı́e. En el segundo caso, la estación pude proceder con tramas de ba-
ja prioridad o tramas cı́clicas, si el THT no ha expirado. Luego de haber
comenzado, el servicio de baja prioridad es no-prerrogativos, es decir, los
pedidos de alta prioridad recién llegados son manejados por sobre la llegada
del próximo token. Esto continúa hasta que no haya tramas para transmitir
o el temporizador de fijación de token expire.

El servicio de baja prioridad comienza atravesando la lista de votación


del servicio CSRD. Si todas las estaciones en la lista son consultadas y el
temporizador de fijación de token no ha expirado, la estación procede ma-
nejando ciclos de baja prioridad asincrónicos (servicios SDA, SDN y SRD)
hasta que éste expire. Si la lista de votación puede ser atravesada con un ciclo
de token no hay tiempo restante para información de baja prioridad, la cola
de baja prioridad es manejada por sobre la llegada del próximo token don-
de luego de procesar pedidos de baja prioridad hay aún tiempo para ciclos
de baja prioridad. Luego de esto, la lista de consulta es recorrida nuevamente.

Si el recorrer la lista de consulta toma más tiempo del que el THT per-
mite, la lista restante es manejada en los ciclos de token subsiguientes, sin
interrupción de tramas de baja prioridad asincrónicas. Estas últimas son ma-
nejadas si la lista de votación es recorrida completamente.

Algunas tramas especiales para el mantenimiento del anillo


(FDL STATUS.REQUEST) son tratadas como tramas de baja prioridad
asincrónicas.
Descripción del protocolo Profibus 100

El protocolo descripto hasta ahora es una variante del famoso protocolo


Token Temporizado el cual es también usado en los estándares FDDI y IEEE
802.4. Se lo conoce por ser capaz de tranmitir información multimedia.

Protocolo de enlace de datos


La capa de enlace de datos de Profibus provee un servicio semi-confiable
para los servicios SDA Y SRD, con un número obligatorio de retranmisio-
nes, dado por el parámetro global max retry. La realimentación necesaria es
provista por acuses de recibo inmediatos de la capa MAC, los cuales pueden
o no llevar datos también. Todas las pruebas por el protocolo son llevadas a
cabo subsecuentemente, no se permite ninguna otra transmisión de trama o
pasaje de token mientras tanto. Si el resultado de la transmisión de trama
es conocido (recepción exitosa de un acuse de recibo o pruebas max retry
sin recibir un acuse de recibo) las capas superiores son notificadas con una
primitiva de confirmación. A fin de permitir al receptor distinguir entre nue-
vas tramas y retransmitidas, se utiliza una variante del famoso protocolo bit
alternante.

La instancia FDL del iniciador mantiene para cada posible estación ob-
jetivo a una variable de estado (distinguiendo entre “muerta” y “viva”, y un
bit de cuenta de trama (FCB). La variable de estado se cambia de acuerdo a
la siguiente regla: si la estación objetivo está “viva” y no responde a ninguna
prueba perteneciente a un ciclo (es decir, si no envia un ACK a la trama de
pedido y todas sus transmisiones max retry), es marcada como muerta. Si un
ciclo es direccionado a una estación muerta, ninguna retransmisión es lleva-
da a cabo dentro del servicio CSRD. Si una estación como muerta responde
nuevamente, es marcada como viva. La instancia FDL de quien responde
mantiene para cada posible dirección de estación una FCB. Es más, mantie-
ne un buffer global para el último acuse de recibo de trama (buffer de acuse
de recibo).

El FCB le permite a la estación contestadora, distinguir entre nuevas tra-


mas y tramas retransmitidas. Es transmitida como parte del encabezado de
trama, junto con una bit cuenta de trama válida (FCV), la cual indica, si el
FCB es válido o no.

Cuando la iniciadora envı́a una trama a la contestadora por primera vez,


o si la estación contestadora despierta luego de estar muerta, ambas esta-
ciones tienen que sincronizar en un valor FCB. Para ello, la iniciadora envı́a
tramas con F CV = 0 y F CB = 1 a la estación contestadora, sin embargo,
Descripción del protocolo Profibus 101

tales tramas no son retransmitidas. Luego de que la estación contestadora


ha respondido, la iniciadora envı́a todas las tramas siguientes con F CV = 1
e invierte el FCB luego de cada ciclo terminado.

Si a la estación receptora le llega una trama con F CV = 1 y F CB =


X, chequea si este FCB era diferente del que fue guardado en su tabla o
no, una nueva trama de acuse de recibo es generada, guardada en el buffer
global y transmitida a la iniciadora, y una primitiva de indicación es generada
por el usuario FDL de la estación contestadora. Si la estación contestadora,
recibe una trama de la estación “b” sin dirección luego de recibir una trama
con F CV = 1 de la estación “a”, considera el último ciclo de “a” como
terminado. Si la estación contestadora, recibe dos tramas sucesivas desde la
misma estación, ambas con F CV = 1 y el mismo FCB, concluye que la
última trama es una retransmisión. En este caso sólo el contenido del buffer
de acuse de recibo es retransmitido, y ninguna otra acción es llevado a cabo.
Apéndice D

Código fuente de Matlab

D.1. Principal
% funcion principal donde se setean los parámetros de la simulación

function bermaxrand

clear all

% parametros de poly2trellis
% K: Longitud restringida
% G: Codegenerator en octal
% F: Feedback connection en octal

% para el ejemplo de Casti, K=3, G=7, F=5


%K=3 ; G=7; F=5;

% Paper de Berrou
K=5; G=21; F=37; % este codificador tiene muy buena performance

% asigno el vector de realimentacion para terminar el trellis del primer


% codificador
assignin(’base’,’F’,F);

trellis = poly2trellis(K,G,F);
% asigno la estructura al workspace ’base’
assignin(’base’,’trellis’,trellis);

102
Código fuente de Matlab 103

% Genero la matriz de conexiones y salidas del trellis

trellismat;

EbNovector = 0:0.5:2;

iteracionesvector = [8 10];

% Trama de longitud N
N=53*53;
assignin(’base’,’N’,N);

CantTramas=100; % cantidad de tramas que se transmiten, por cada una se


% realiza el proceso de decodificacion

% distintos trazos para diferentes iteraciones en un mismo grafico


trazo = [’-’ ’:’ ’-.’ ’--’];

contador = 0;

% vector con el valor de BER para cada EbNo


bervector = zeros(length(EbNovector),1);

for j = 1:length(iteracionesvector)

iteraciones = iteracionesvector(j);
assignin(’base’,’iteraciones’,iteraciones);

for i = 1:length(EbNovector)

EbNo = EbNovector(i);
assignin(’base’,’EbNo’,EbNo);

totalerrors = 0;

for k=1:CantTramas

% funcion que simula el esquema Tx-canal-Rx


turbo;
Código fuente de Matlab 104

% errors es una funcion


totalerrors = totalerrors + errors;

contador = contador + 1;
progreso = 100*contador/(length(iteracionesvector)*...
length(EbNovector)*CantTramas)

end

bervector(i) = totalerrors/(N*CantTramas);

end

semilogy(EbNovector,bervector, trazo(j));
xlabel(’Eb/No [dB]’);
ylabel(’BER’);
hold on
end

D.2. Esquema de Transmisión/Recepción Tur-


bo
% funcion que replica el esquema de transmisión / recepción turbo

function turbo

% esta funcion crea el escenario de transmisión/recepción

N = evalin(’base’,’N’); % traigo las variables del workspace


EbNo = evalin(’base’,’EbNo’);
iteraciones = evalin(’base’,’iteraciones’);
trellis = evalin(’base’,’trellis’);
F = evalin(’base’,’F’); % realimentacion del codificador

% calculo la memoria del codificador (igual a K-1)

M = log2(trellis.numStates);

Sigma = 10^(-EbNo/20); % EbNo esta en dB, Eb = 1


Código fuente de Matlab 105

Lc = 2/(Sigma^2);

%transmito N-M bits de información, necesito M bits para terminar el


%trellis

source = polar2bin(sign(randn(N-M,1))); %source vale 0 o 1

%Genero la redundancia sin interleaver

[X1p_temp FinalState] = convenc(source,trellis, 0);

%Termino el trellis del primer codificador


%la realimentacion debe incluir a todos los estados (o hay q cambiar el
%codigo)

tailbits = zeros(M,1);
tailbitscoded = zeros(M,1);

% paso de octal a binario las conexiones de realimentacion del codificador


F_dec = oct2dec(F);
F_bin = dec2bin(F_dec, M);

for n=1:M
FinalStateBin = dec2bin(FinalState, M);
weight=0;
for m=1:M
% si F_bin(m+1) == ’1’, ese registro esta realimentado
% F_bin(1) es la conexion de la entrada al codificador (no
% pertenece a los estados del codificador

if FinalStateBin(m) == ’1’ & F_bin(m+1) == ’1’


weight = weight + 1;
end
end

tailbits(n) = mod(weight,2); % si el estado tiene cantidad de ’1’ par,


% entonces a la X-OR debe entrar un cero

% ahora ingreso al codificador con el tail bit


PreviousState = FinalState;
Código fuente de Matlab 106

[tailbitscoded(n) FinalState] = ...


convenc(tailbits(n),trellis, PreviousState);

end

% le agrego a los bits del primer codificador los tailbits codificados

X1p_bin = [X1p_temp; tailbitscoded];

% ahora renombro la fuente agregando los tailbits

source = [source; tailbits];


assignin(’base’,’source’,source);

%Genero el bit sistematico incluyendo tailbits

Xs_bin = source;

%Genero la redundancia pasando a ’source’ por un interleaver aleatorio

source_int = randintrlv(source,12345);

X2p_bin = convenc(source_int,trellis, 0);

%Ahora armo la secuencia de salida X


%Genero una matriz de salida, la primera columna es Xs
%La segunda tiene en las posiciones impares la paridad sin interleaver
% y en las pares la paridad con interleaver

X_bin = zeros(N,2);

X_bin(:,1) = Xs_bin;

for i=1:N/2
X_bin(2*i-1,2) = X1p_bin(2*i-1);
X_bin(2*i,2) = X2p_bin(2*i);
end

% paso las secuencias de salida a formato polar


Código fuente de Matlab 107

X = bin2polar(X_bin);

%Genero el ruido gaussiano del canal de comunicaciones

Ruido = Sigma*randn(N,2);

%En el receptor

Y = zeros(N,2);
Y = X + Ruido;

% La información extrı́nseca inicialmente es nula

Le1 = zeros(N,1);
Le2 = zeros(N,1);

% Relleno las redundancias en las posiciones impares para el primer


% decodificador y las pares para el segundo

Yp1 = zeros(N,1);
Yp2 = zeros(N,1);

for i=1:N/2
Yp1(2*i-1) = Y(2*i-1,2);
Yp2(2*i) = Y(2*i,2);
end

%Genero las secuencias que van a entrar a cada decodificador

Inputdec1 = zeros(3*N,1);
Inputdec2 = zeros(3*N,1);

% Lazo de iteraciones

for i=1:iteraciones
Código fuente de Matlab 108

Inputdec1 = [Le2 Y(:,1) Yp1];

%Ingreso al Dec1, y recibo como salida la Le1

%le aviso a decmax que es el decoder 1 para que ponga beta(N+1,1)=0;


decoder = 1;
assignin(’base’,’decoder’,decoder);

dec1output = decmax(Inputdec1);

% La segunda columna de la salida de Dec1 no tiene utilidad

Le1 = dec1output(:,1);

% Preparo la entrada para Dec2

% interleave de la información extrı́nseca Le1


Le1_int = randintrlv(Le1,12345);

% interleave de la información sistemática Y(:,1)


Y1_int = randintrlv(Y(:,1),12345);

Inputdec2 = [Le1_int Y1_int Yp2];

decoder = 2;
assignin(’base’,’decoder’,decoder);

dec2output = decmax(Inputdec2);

Le2 = randdeintrlv(dec2output(:,1),12345);

end

% decisión dura de la salida decodificada de Dec2


dec2output_hard = sign(dec2output(:,2));

% paso la decisión dura a binario


dec2output_hard_bin = polar2bin(dec2output_hard);
Código fuente de Matlab 109

% deinterleave de la secuencia decodificada


decout = randdeintrlv(dec2output_hard_bin,12345);

assignin(’base’,’decout’,decout);

D.3. Algoritmo Log-MAP


function Output = decmax(InputMux)

% algoritmo de decodificacion Log-Map

N = evalin(’base’,’N’); % traigo las variables del workspace


EbNo = evalin(’base’,’EbNo’);
trellis = evalin(’base’,’trellis’);
Mat = evalin(’base’,’Mat’);
decoder = evalin(’base’,’decoder’);

Lb = zeros(N,1);
X = zeros(N,1);
Y = zeros(N,1);

% demultiplexo las se~


nales de entrada en Lb, X e Y1
for i = 1:N,
% La informacion a priori de cada bit del dec1 es la extrinseca del
% dec2, y viceversa
Lb(i,1) = InputMux(i);
% bit recibido sistematico afectado por ruido
X(i,1) = InputMux(i + N);
% bit de redundancia recibido afectado por ruido
Y(i,1) = InputMux(i + 2*N);
end

% EbNo esta en dB, Eb = 1


Sigma = 10^(-EbNo/20);

Lc = 2/(Sigma^2);

% en el archivo ’trellismat’ se define la matriz Mat


Código fuente de Matlab 110

% Cálculo de los GAMAS

% Modificacion de Gama por PAB

Gama = zeros(N,trellis.numStates,trellis.numStates);
Gama(:,:,:) = - Inf;
for i = 1:N,
for k = 1:trellis.numStates,
for j = 1:trellis.numStates,
if Mat(j,k,1) ~= 0;
% Mat(j,k,1) = bi = x_sist
Gama(i,j,k) = Mat(j,k,1).*Lb(i)/2 + ...
Lc/2*(X(i).*Mat(j,k,1)+Y(i).*Mat(j,k,2));
end
end
end
end

% Cálculo de los ALFAS Log MAP

Alfa=zeros(N,trellis.numStates);
Alfa(1,:)=-Inf;
Alfa(1,1)=0;

for i=2:N;
for k=1:trellis.numStates;
for j=1:trellis.numStates;
A(j)= Gama(i-1,j,k) + Alfa(i-1,j);
end
if A(1)==-Inf & A(2)==-Inf;
Pru=-Inf;
else
Pru= max(A(1),A(2)) + log(1+exp(-1*abs(A(1)-A(2))));
end

for j=3:trellis.numStates
if A(j)~=-Inf;
Pru= max(Pru,A(j)) + log(1+exp(-1*abs(Pru-A(j))));
end
end
Código fuente de Matlab 111

Alfa(i,k)= Pru;
end
end

% Cálculo de los BETAS

Beta=zeros(N+1,trellis.numStates);

if decoder == 1
% Si es el Primer Decodificador, el último Beta(1) debe ser 0
Beta(N+1,:)=-Inf;
Beta(N+1,1)=0;
else
% Si es el Segundo Decodificador, todos los últimos Betas deben ser
% 0
Beta(N+1,:)=0;
end

for i=N:-1:2;
for j=1:trellis.numStates; % j es el estado actual
for k=1:trellis.numStates; % k es el estado proximo
B(k)= Beta(i+1,k) + Gama(i,j,k);
end
if B(1)==-Inf & B(2)==-Inf;
Pru=-Inf;
else
Pru=max(B(1),B(2)) + log(1+exp(-1*abs(B(1)-B(2))));
end

for k=3:trellis.numStates
if B(k)~=-Inf;
Pru= max(Pru,B(k)) + log(1+exp(-1*abs(Pru-B(k))));
end
end
Beta(i,j)= Pru;
end
end

Lb_y=zeros(N,1); % Cálculo de los L(b/y)


Código fuente de Matlab 112

for i=1:N;

for k=1:trellis.numStates;
for j=1:trellis.numStates;
if Mat(j,k,1)==1;
Numer(k) = Alfa(i,j) + Gama(i,j,k) + Beta(i+1,k);
elseif Mat(j,k,1)==-1;
Denom(k) = Alfa(i,j) + Gama(i,j,k) + Beta(i+1,k);
end
end
end

% comienzo con los dos primeros elementos de Numer y Denom

if Numer(1)==-Inf & Numer(2)==-Inf


NumerAux=-Inf;
else
NumerAux=max(Numer(1),Numer(2)) + ...
log(1+exp(-1*abs(Numer(1)-Numer(2))));
end

if Denom(1)==-Inf & Denom(2)==-Inf


DenomAux=-Inf;
else
DenomAux=max(Denom(1),Denom(2)) + ...
log(1+exp(-1*abs(Denom(1)-Denom(2))));
end

% continúo con el resto de los elementos

for k=3:trellis.numStates

if Numer(k)~=-Inf % PAB - Lo agrego para evitar el NaN


NumerAux=max(NumerAux,Numer(k)) + ...
log(1+exp(-1*abs(NumerAux-Numer(k))));
end

if Denom(k)~=-Inf % PAB - Lo agrego para evitar el NaN


DenomAux=max(DenomAux,Denom(k)) + ...
log(1+exp(-1*abs(DenomAux-Denom(k))));
end
Código fuente de Matlab 113

end

Lb_y(i)=NumerAux - DenomAux;

end

% Ahora la Información Extrı́nseca es comunicada al otro Decodificador


% como parametro de salida

Le = Lb_y - Lc*X - Lb;

Output = [Le Lb_y];

D.4. Algoritmos accesorios


D.4.1. Construcción de las matrices del trellis
function trellismat

trellis = evalin(’base’,’trellis’);

% Hago una matriz cuya primera dimension sea el estado anterior,


% la segunda el estado actual y la tercera la es el vector de salida
%( 1: sistematico, 2: salida codif )

Mat = zeros(trellis.numStates,trellis.numStates,2);

% Mat(u’,u,bits)
polar = [-1 ; +1];
for col = 1:2,
for i = 1:trellis.numStates,
Mat(i,trellis.nextStates(i,col)+1,1) = polar(col);
% la primera columna esta asociada a las transiciones del 0 (-1
% en polar)
% la segunda columna esta asociada a las transiciones del 1 (+1 en
% polar)
end
end
Código fuente de Matlab 114

for k = 1:trellis.numStates,
for j = 1:trellis.numStates,
% esta condicion detecta si la transicion de j a k es posible
if Mat(j,k,1) ~= 0;
% guardo en la matriz la salida codificada a partir del estado
% actual y el bit entrante al codif; la paso a polar (0 -> -1 ,
% 1 -> +1)
Mat(j,k,2) = bin2polar(trellis.outputs(j, ...
polar2bin(Mat(j,k,1)) + 1));
end
end
end

assignin(’base’,’Mat’,Mat);

D.4.2. Conversor de binario a polar


function y = bin2polar(x)
y = 2*x-1;

D.4.3. Conversor de polar a binario


function y = polar2bin(x)
y = (x + 1)/2;

D.4.4. Detección de errores


function errores = errors

source = evalin(’base’,’source’);
decout = evalin(’base’,’decout’);
N = evalin(’base’,’N’);

errores = sum(abs(source - decout));

D.4.5. Curva de BER vs. Eb /N0 sin codificación


clear;
%EbNovector = 0:8;
EbNovector = 0:0.2:2;
bervector = zeros(length(EbNovector),1);
Código fuente de Matlab 115

N=1000000;
%cantrep=10;

%for k=1:cantrep

source = sign(randn(N,1));
assignin(’base’,’source’,source);

for i = 1:length(EbNovector)
EbNo = EbNovector(i);
assignin(’base’,’EbNo’,EbNo);
Sigma = 1/sqrt(2)*10^(-EbNo/20); % EbNo esta en dB
n = Sigma*randn(N,1);
r=source+n;
%r=awgn(source,EbNo + 3);
decout = sign(r);
assignin(’base’,’decout’,decout);
bervector(i) = errors/N;
end

semilogy(EbNovector,bervector)
xlabel(’Eb/No [dB]’)
ylabel(’BER’)
title(’BER vs Eb/No sin codificación’)
hold on

D.4.6. Resolución ecuación para distancia constante


x=626:1:2000;
f=0.8*(626-500)/100 + 0.48*(x-626)/100 + 10*log10(x/500)-7.37;
plot(x,f)
title(’R2 para distancia de cable 400 metros’)
xlabel(’R [Kbps]’)
ylabel(’Homogénea en función de R2’)

figure

x=1500:1:3500;
f=0.48*(x-1500)/100+10*log10(x/1500)-7.37;
plot(x,f)
title(’R2 para distancia de cable 200 metros’)
Código fuente de Matlab 116

xlabel(’R [Kbps]’)
ylabel(’Homogénea en función de R2’)

figure

x=12000:1:15000;
f=0.48*(x-12000)/100+10*log10(x/12000)-7.37;
plot(x,f)
title(’R2 para distancia de cable 100 metros’)
xlabel(’R [Kbps]’)
ylabel(’Homogénea en función de R2’)
Bibliografı́a

[1] B. Sklar, “Digital Communications”, 2o Edición, Prentice Hall, 2001.


[2] J. Proakis, “Digital Communications”, 4◦ Edición, McGraw-Hill, 2001.
[3] W. Stallings, “Data and Computer Communications”, 6o Edición, 1999.
[4] A. Oppenheim and A. Willsky, “Signals and Systems”, 2◦ Edición, Pren-
tice Hall, 1997.
[5] C. Berrou, A. Glavieux, and P. Thitimajshima, “Near Shannon limit
error-correcting coding and decoding: Turbo-codes” Proceedings, 1993
IEEE International Conference on Communication, Geneva, Switzer-
land, pp. 1064-1070, 1993.
[6] C. Schlegel, L. Pérez, “Trellis and Turbo Coding”, IEEE Press Editorial
Board, 2004.
[7] J. Castiñeira, Apunte curso de posgrado de Teorı́a de la Información y
Codificación dictado en el departamento de electrónica de la Facultad
de Ingenierı́a de la UNMDP, 2004.
[8] J. Castiñeira, “Resultados de simulaciones con interleavers aleatorios y
de bloque para distintas longitudes de trama”, 2004.
[9] P. Guinand, J. Lodge, “Trellis termination for turbo encoders”, 1994.
[10] Fu-hua Huang, “Trellis termination and concepts”, 1997.
[11] Fu-hua Huang, “Performance analysis of turbo codes”, 1997.
[12] B. Puckett, “Implementation and Performance of an Improved Turbo
Decoder on a Configurable Computing Machine”, 2000.
[13] A. Willig, “A New Class Of Packet- And Bit-Level Models For Wireless
Channels”, 13th IEEE Intl. Symp. on Personal, Indoor and Mobile Radio
Communications, Septiembre 2002.

117
BIBLIOGRAFÍA 118

[14] A.Willig, “Investigations on MAC and Link Layer for a wireless PRO-
FIBUS over IEEE 802.11”, 2002.

[15] L. Papke, P. Robertson, and E. Villebrun, “Improved decoding with the


SOVA in a parallel concatenated (turbo-code) scheme”, Proceedings,
IEEE International Conference on Communications, pp. 102-106, 1996.

[16] E. Elliot. “Estimates of error rates for codes on burst-noise channels”.


Bell Systems Technical Journal, Septiembre 1963.

[17] ABB Automation Products GmbH, Profibus Cable Datasheet, 2006.

[18] ABB Automation Products GmbH, Profibus Presentation, 2006.

[19] Wiesemann und Theis GmbH, RS485 Information, 2005.

[20] PNO Profibus Nutzerorganisation, “Profibus Specifications”, Edición


1.0, 1998.

[21] ABB Profibus Presentation, 2003.

[22] N. Chan, “Design and Prototyping of a Turbo Decoder Using the Ber-
keley Emulation Engine (BEE)”, 2001.

[23] TrellisWare Technologies Inc., “TWT 100204D/E Turbo Deco-


der/Encoder Datasheet”, 2003.

[24] Altera Corp., “HSDPA-Low-Cost-FPGA Co-Processor for Channel


Coding”, www.altera.com, 2006.

Você também pode gostar