Implementação de Técnicas de Tolerância a Falhas em Célula de Manufactura

Vista previa del material en texto

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY 
CAMPUS ESTADO DE MÉXICO 
IMPLEMENTACION DE DISTINTAS TECNICAS DE 
TOLERANCIA A FALLAS EN UNA CiELDA De 
MANUFACTURA 
Asesor: 
Comite de 
Tesis: 
TESIS QUE PARA OBTENER EL GRADO DE 
MAESTRO EN CIENCIAS COMPUTACIONALES 
PRESENTA 
LAURA ELENA ZAVALA VEGiA 
Dr. Jesús Sánchez Velázquez 
Dr. Fabian García Nocetti 
Dr. Carlos Rodríguez Lucatero 
Dr. Isaac Rudomín Goldberg 
Atizapán de Zaragoza, Edo de Mex., Diciembre 1998 
Resumen 
En esta tesis se hace la implementación de varias técnicas de, tolerancia a fallas( tanto 
en hardware como en software) para el controlador paralelo distribuido (PARDICO) que 
será utilizado en una celda flexible de manufactura. El cont·olador hace uso de una 
topología de red reconfigurable basada en transputers y forma parte del proyecto 
"Tecnologías de Comunicación Avanzadas en Robótica y Celdas Flexibles de 
Manufactura" el cual está financiado por la National Sciencie Foundation (NSF) y el 
Consejo Nacional de Ciencia y Tecnología (CONACyT). 
El sistema desarrollado cuenta con un módulo de supervisión para la detección de 
errores, un módulo de monitoreo que permite conocer el estado global del sistema . y un 
módulo extra que utiliza la redundancia en hardware y software para su recuperación en 
caso de que ocurra algún error. Dentro de los posibles e1·rores que se atacaron se 
encuentran: error en los enlaces de comunicación: error en uno o mas procesadores y 
error en uno o mas procesos. Para cumplir con el objetivo se hizo uso de 
procedimientos especiales para la comunicación confiable dentro de la red de 
transputers, el paralelismo que proporciona el procesador, y la capacidad de 
reconfiguración de la red 
Debido a las características de la interfaz utilizada para la comunicación con los 
elementos de la celda, la parte de configuracion del sistema está hecha en lenguaje 
Occam mientras que la parte de procesos y procedimientos está hecha en C, por lo que 
se proporciona además una guia para la programación usando ambos lenguajes. 
CONTENIDO 
1. Introducción ................ .. ...... .. ............... .. .................... .. ...... ... ..... ........ .. ....... .. ....... .. ....... ... ...... ... ....... .. .............. .. ..... 6 
1.1 Definición de una Celda Flexible de Manufactura .............. .... ..... .... .. ... ... .... .. ....... .. ................ .. ........ .... ........ 7 
1.2 Antecedentes ............................ .. .................. . ............ ....... .. .... .. .... .. ... ..... ......... .. ......... .......... .. .... .. .... 8 
1. 3 Objetivos ............................................................. .... .. .. ................... .... ...... . ................. .. ... ....... ... ......... .. .......... 1 O 
2. Problemática ............... .. ........................... .. ...... .. ..... .. ....... ....... .. ..... .. .. ... .... ...... .. ........ .. ...... .......... .. ........................ 12 
2.1 Trabajos ya desarrollados para el proyecto "Tecnologías de Comunicación Avanzadas en Robótica y 
Celdas Flexibles de Manufactura" ........................... .. .................... .. ........ .. ................................. .. .......... .. ............ 12 
2.1.1. Interfaz bidireccional de comunicación entre dos transputers y un elemento de la Celda .................... 12 
21.2 Protocolo de Comunicación ....................... .. .......... .... .. .. ........ .. ............ .. ........ .. ................................ 13 
2.1.3 Arquitectura reconfigurable de una red de transputers para el controlador de una CFM ............ ... ........ 14 
2.2 Puntos susceptibles a error en el controlador de la celda de manufactura .................................................... 18 
3. Tolerancia a Fallas en Una Celda de Manufactura .................... .. ............ .. ... .. ......................... .. ..... .... .. ...... 22 
3.1 Tolerancia a Fallas en Sistemas Paralelos y Distribuidos ...... .. ... ..... .. ..... .. ......................... .. .. .. ....... .. ..... 22 
3.1.1 Definición de falla ............... .. .................. .. . ........... .................... ............... .. ........... .. ..... 23 
3.1.1.1 Fallas francas ............................. .. .. ............... .. .. . ....... .. .............. 23 
3.1.1.2 Fallas transitorias............................... .. ................ .. .. . ...... .. ....... ........... .. ..................... 24 
3.1.1.3 Fallas temporales ........ .. ..................... .. ..................... .. ........................ .. ........... .. .......... .. ................. 24 
3.1.1.4 Fallas temporales ............ .. ................................................... .. ................ .. ....... ... ........ .. ................. 24 
3.1.2 Características de un sistema tolerante a fallas...... .... .. ........ .. .............. .. ...... .. ....... .. .. ........ .. ..... 25 
31.3 Detección de error .............. .. ..................... .. .... ... .. ... .. ... ..... .. ..... .. .......... .. ....... .. .. ....... .. ........... 27 
3.1.4 Estimación de los daños............................. .. ...... .. ...... . .... ..... .. .. ......... .. ............................. .. ........ 28 
3.1.5 Recuperación del error .............................. .. ..... .. ...... .. ... .. ..... .. . ............................ ............ ·•· ..... 29 
3.1.6 El manejo de la falla y el restablecimiento .................................. ......... .. ....... ... ......... ....... ..................... 30 
3.1. 7 La redundancia dentro de la tolerancia a fallas ............ ... .. ... .. ............. .. ......... .......... ............ ......... ...... 30 
3.1.7.1 Redundancia en Hardware ..... ......... ...................................... .......... ......... .......... .............. ............... 30 
3.1.7.2 Redundancia en Tiempo ........... .............. ......................... ........ .................................... ..................... 34 
3.1.7.3 Redundancia en Software ...................................... ........ ........ .. ........ .. ........ ......... ... ......... ............... 34 
3.2 Programación en sistemas distribuidos y paralelos ............. ........ ............................ .......... ... .......... .. ............. 35 
3.2.1 Formas de paralelismo .......................................................................... ................................................. 35 
3.2.2 Máquinas paralelas ........................... .. ....... : ..... .. ...... ........ ....... .. ............... ........ .. ..................... ............... 36 
3.2.3 El transputer .............................................. ............. ............................... ............ .. ........ ......... ... ...... .. ..... 37 
3.2. 3.1 Comu~icación: Enlaces y Canales ..... ....................... ..... ......... ................ ............ ........... .. ............ 39 
3.2.3.2 Timesharing ................... ...... .......... ............. ........ ....... .............. ......... .......... ......... ............ ... ............ .40 
3.2.3.3 Procesos, tareas y threads ........... .. ............. ........ .. ..... .. ............. ........... ........ ........... .......... .. ............ .40 
3.2. 3 4 lserver, Afserver, Pserver ..................... ..... .. ................ .. .... .......... ....... ............................. .... ............ .41 
3.2.3.5 Lenguajes ..................................... ............. .. ....... .. .... ............... . ...... .. .......... .. ................................ 41 
3.3 Implementación de un sistema tolerante a fallas en transputers ...... .. ....... ......... ... ...... ......... ............. ............ 42 
4. Implementación .............. ............... ......... ............. .. ............ .. ...... ........ ........ .. ...... .. ................. ......... ............. ......... .43 
4.1 Criterios de Diser,o .......... ............... .. ..... ........ .............. ... ........... ......... .. ....................................................... .43 
4.2 Análisis del problema .............. .. ............ ..... .. .... ...... .. ... .. . ... ...... ... ............... ...... .... ....... ............. ....... 44 
4.2.1 Redundancia en el controlador ..... ...... .. .... ...... .. ...... ... . . ............ ........ .. ............... ... .......... ..... 48 
4.2.1.1 Redundancia en Hardware ........................................... ... . .......... ................................... .48 
4.2.1.2 Redundancia en Software ...................... .. .................. .. ... .... ........ ....... ... .............................. .. ........ 49 
4.2.2 Tolerancia a Fallas en el subsistema de comunicación ........ ................ ....... .. ...... .. ........... ................... 50 
4.2.3 Sistema de supervisión: monitores ................. .. ...... ....... .. .... .. ...... .. ........ ................... ............. .. .... .... ..... 52 
4.2.3.1 Monitor Distribuido vs. Monitor Centralizado .............. ................ .. ..... ... ..... .. ................. .. ............. 56 
4.2.4 Detección de fallas y Recuperación de Fallas ........................ .. ................................ ......... .. ......... .. ....... 60 
4.2.4.1 Error en los enlaces de comunicación ............................ ....... ........ ........... ........... ................ ........... 62 
4.2.4.2 Error en los procesos del controlador ...... ................. .. 
4.2 4.3 Error en el procesador ........ .. ........... .. ................ .. 
···· ·········· ································ ··········· .... 62 
············· ·· ········· ······················ ··········· .. 63 
2 
4.2.4.4 Error en el procesador del host ...................... .. ..... .. .. ........... .. ........ ......... ... ........ ........... .. ....... .. ..... 64 
4.2.4.5 Error en un segundo proceso del controlador .... .... . . ......... ···················· ·· ... ······ ······ .... 65 
4.2.4.6 Error en un procesador de respaldo ..... ..... ............... ... . ·· •·················· ··········· ··················· .... 65 
4.2.4.7 Error en el procesador de monitoreo global ...... ....... . . .. ......... .................. .......................... 69 
4.2.5 Precauciones en la programación ....... ..... ......................................... ............................. ........................ 69 
4.2.5.1 Procedimientos para el manejo del uso extraordinario de enlaces .................. ........... ............ ........ 70 
4.2.5.2 Reinicializar el sistema .... ..................................................... ............................................................ 71 
4.3 Resultados ......... ....... ....................... .............. ........ ...................................... ........... .......... .. ......... .......... .. ...... 73 
5 Conclusiones y Recomendaciones a Futuro .......... ............................. ................................................................. 80 
5.1 Conclusiones .................................................. ................ ............. .......... ................ .. ........ ........... ........... ... ...... 80 
5.2 Recomendaciones a Futuro ...... ......... ............... ..................... .. ............. .. ....... ................... ......... .... .......... ....... 81 
6. Bibliografía .......................................................................................... .......... ....................................................... 83 
APENDICE A..... ............ ......... ................ ....... ......... . .. . ............... . . .. ...... ... ...... .......... ...................... 86 
A.1 Programas con lenguajes mezclados................ ........................ . . .... .......... ........ ......... .. ............ .. ........ 86 
A.1.1 Definición de la interfaz tipo 2 ......... ....... ...... ................ ....... ........ ......... ....................................... ........... 87 
A.1.2 Definición de la interfaz tipo 3 .......... ....... ........ ....... ........ ............................... .. ....................................... 88 
A.2 Llamada de procedimientos de interfaz Occam ............ .. ..................... . ...... ......... ............................... ....... 88 
APENDICE B ..... ........ .. ....... .......... ............................... ...... ........ ......... ....... .. ................ ......... ..................... .............. 91 
B.1 Comunicación confiable en canales duros (entre procesos) ..................................... ........................ .......... 91 
B.2 Descripción de funciones para comunicación con ser'lalización de error por temporizador ................... ....... 91 
B.3 Descripción de funciones para comunicación con ser'lalización de erro~ por canal ................................ ...... 94 
APENDICE C ..... .......... ........ ... .............................. ................ ............ .. ........................ ............ .......... ...... . 
C.1 Pseudocodigo y Programas .......... ...... ....... .................. ... . 
. .... 98 
.. 98 
C.1.1 Red de transputers ............................... . ...... ........ ................... . ................... ........... ....... ... ............... 98 
C.1.2 Archivo de configuración ..... ..................... ........ .............................. .................... ............ ....... .. ........ . .... 98 
C 1. 3 Esquema del Archivo de Configuración ..... ..................... .. .................. .............................. ... ..... .. ......... 103 
3 
C. 1.4 Aplicación ......... ... ...... .... .... .. ........ ..... ...... ..... .............. ... ... . . . ..... 105 
C.1.4.1 Módulo Host: .............. ........ .... ........ . . ... 105 
Interfaz Occam: ... ............... .. .................. .. ... ...... ............... .. ............... ............. .... ............................. .. ..... 105 
Programa en C .. ..... ......... ...... .. ....... .. ...... .. .......... ..... ............. ........ .. .................................. .................. .. 105 
Nodo en el archivo de configuración ..... .. ........ ... ............ .. .. .. .... ... .. ......... .... .. ....... .. ... ....... ............... 105 
Descripción .. .. .... ....... .. ... ................... ......... ....... ........... ....... .... .. ..... ... .. .. ... .. ... .... ...... .. ...... ... .............. .. .... . 105 
Flujo ... ........ .. ... .... ... .... .... .. .......... ........... .. ... .... .... .................... .. ................................................ .. ............. 106 
Código ........... .. .. ..... .. : ................................. ............. .. ...... .. ..... .. ...... .. .. ... ...... ...... ... ......... .. ........ ... ...... .. .... 107 
Forma de Compilarlo ........ .. ...................... ... .... .. ....... .. ......... .. .............. . ..... ... ..................... .. .............. .... 119 
C 1.4.2 Módulo Controlador: ........... .. ........... .. .... ..... .... .. .. .... .. . .. ... 120 
Interfaz Occam .... ..... ..... .. .. ... ... .. ... ..... ... ....... .. .... ..... ... ... .. .... .... .. .... ... ... ... .. .. .... ... ...... ....... ... ... .... .... .... .... 120 
Programa en C .................. ...... ............ .. .......... ... ...................... ... ..................... ... ........ .... .... ... .. .. .. 120 
Nodo en el archivo de configuración ...... .. ..... ... .. .. ... ... ... .. ... ............ .. .. .... ..... .. ... .... ... .... .. ...... .. .. .... .. .. ..... 120 
Descripción ..... ......... ............................ .... ..... .............. .... ........ .... ... .. ...... ..... ... ...... ... ...... ........ .... .. ......... .. . 120 
Flujo ........................................................................................................................ ...... .. ... .... ..... ..... ....... . 120 
Código: .. ..... .... ........ .... ...... .... .. .... .... .. ........ .. .... .... .... ............. ........ .. ..... ... .... .. ...... ... ... ..... .......... ..... ....... ... . 121 
Forma de Compilarlo ... ........ ... ........ ....... ......... .. ...... .... .. .... .. ... ... . .. ... .......... .... ..... .......... .. .. .. .... ... .......... 127 
C.1.4. 3 Módulo Controlador de Respaldo: .... .. . . ... .. ..... ... ...... .. ...... .. .. ... ..... ...... .. ...... ............ .. ..... .. ....... . 128 
Interfaz Occam ........ ... ........................... . .. .. .... ................. ..... 128 
Programa en C ... ...................... .. ........ . .. .. .... .... .. .. ........ .. ........... ... 128 
Nodo en el archivo de configuración . ... .. . .. . .. .. .. . .. .. .. .. .... . ..... ...... .... ..... .. ... .. ...... ... .... ..... .... .. ... 129 
Descripción ......................... ....... .. ..... .... .... .... .. ...... ..... .......... .... .. ......... .. .. . .. . ... .. ... ... .............. 129 
Flujo..... . ....... .... ............. .. .................... .. ... .. ........ ............. .... .... ...... .. ...... .. .. . ... .. ......... .. ..... .. ... .... 129 
Código ...................... ... ............................. ............ ..... .... ... ........ .. ... .. ......... .... ..... ........ ............ .. ............. 129 
Forma de Compilarlo .. .... ...... ..... .... .. .. ......... .. .. ... ... ... .. .............. ... . . ...... .... ... .. ........ ...... .. ... .. .. .. ... .... 134 
C.1.4.4 Módulo SIO: . .. . .. .. .... . .. .. .. . .. .. ... .... .. .... .. .. .... ... ...... .. .. . . .. ........ .... ....... .... ........... ..... .. .. ..... ........... 135 
Programa en Occam ....... ......... ...... .. .. ... ........ ... .... .. ......... ........ . ..... ..... .. .. .. ...... .. ..... ........ .... 135 
Nodo en el archivo de configuración .... ... .. . ............. ... . .. .......... .. .. ....... ... ... .. ..... .. ... .. .... 135 
4 
Descripción ....... .. ...... .. ....................................................... ..... .. ...................................................... ........ 135 
Flujo ............. .. .. .......................... .. ...... .. ....... ....... .. ...... ....... .. ..... .. ........ ....................................... .. ..... ..... 136 
Código .... ....... .. ..... ....................... ........ ........ ........ ........ ............... ........ .. ........................... ............ ........ 136 
F arma de Compilarlo ......... ......................... ... .... ..... .................. .. ... ...... .. ................... ......... .... ......... ... .... 141 
C.1.4.5 Módulo Monitor Local: .................................................................. ...... .. .................... ... ........... ...... 141 
Interfaz Occam ........................ .. .... .. ...... ........ ... .... .. .. .... .... ..... .. ...... ... ...... ... ...... .. ......... .. .......................... 141 
Programa en C .................................................................... .. ........ ................ .. .................... .. ............ .. ... 141 
Nodo en el archivo de configuración .... .... .. .. .. .... .. .. ..... .. .. . . .. .. .. . .. .. .. .. .. .. ...... .................... .. ... .... .... ..... 141 
Descripción ....... .. ..... .... ..... ........ .. ...... .. ..... .. . .... .. ..... ... ..... .. .... .. ........ .. ..... .. ........ ... ......... .. ...................... 141 
Flujo .............................................................. ......... .. .............................. ... ................. .. ........ .. .............. 141 
Código ...... ................. ..................................................... .. ........................................... .. ...... .. ... .. ............ 142 
Forma de Compilarlo ......................................................... .............. .. ........................ .... ......................... 144 
C.1.4.6 Módulo Monitor Global: ................................................................................................................ .. 145 
Interfaz Occam .......................... .. ........ ....... . ............. .... ............................ ... ...... ......... .. ....................... 145 
Programa en C .... .... .... .. ........ .. ...... .. .... .. ...... .. ...... .. ...................... .. .................................. ........... .. .. ....... 145 
Nodo en el archivo de configuración ................................. .. ...................... .. ................ .. ... ......... .. ......... 145 
Descripción ...................................... .. .................. .. ........ .. ........... .. ...... .. ........ .. .. ...... .. ........ ............ ....... 145 
Flujo........................... ........ .. .... .... .... .. ............................ .. ............. . .......................... .... ...... .. .. .. ...... 145 
Código ....................................................................................... ............... .. ....... .... ..... .. .. ........................ 148 
Forma de Compilarlo ................. .............. ..... .................... .. .. .. ....... .. . .... .. ... ........................... .. .............. 155 
C 1.4. 7 Módulo Principal:.. ........... .. ............. ... .... .................. .. .. .. .... .... .. .. .... ...... .. ....... .. .................... .. ...... 157 
Programa en C ..................................... .. ...... ....... .. .... .... ............ ........ .. ...... .. ......... ... ............................. 157 
Descripción ............................................ .. ......................... . . .... .. ....... ... ..................................... 157 
Flujo ...... ... .................................................. .. ......... .. ........ . ..... ....... .. ...... .. ...... .. .. ....... .. ........... .............. 157 
Código .... .. ........ .. .............................................. .. ............................. .. ................... .. ........ ... ........ .. ........... 157 
Forma de Compilarlo ........................... . ............................ .. ...... .. ............... .. ..... .. ...................... .......... 158 
C.2 Archivos de Configuración........... . ... . .. ... .. . .. . .. . ...... .. .. ........ .. .. ...... .. .. . 
C.3 Forma de ejecutar el programa .................... .. .... .. .... .. .. ..... .. ... .. ...... . . . ................. . . ......... , t. 
... 158 
. .. 159 
5 
1. Introducción 
El propósito de las empresas de manufactura es entregar los productos que demanda el mercado en el 
menor tiempo posible y al menor costo aprovechando al máximo los recursos disponibles como materia 
prima y energía . Una Celda de Manufactura es un conjunto de robots y máquinas que trabajan en 
conjunto para construir algún producto (ver figura 1.1) . En la época actual se ha visto la necesidad de 
automatizar los procesos de operación de la empresa para poder llevar acabo dichos objetivos. lo que 
dio origen a las celdas integradas por computadora. 
Una Celda Integrada por Computadora (CIM) es un conjunto de robots y máquinas controlados por 
computadora que trabajan de manera conjunta para fabricar un produci:o[16]. 
EJE • BANDA1 
._________..,(~ 
CINCINNATI ~ 
111111111111111111111111111111111111111@51 =C@ 
BANDA 2 G ROBOT 2 
TABLA 
ROBQT1 
Figura 1.1. Celda de Manufactura 
Aunque actualmente este tipo de centros existen en un buen número de fábricas en todo el mundo , 
presentan la desventaja de que la planeación de susactividades es estática, además de que realizan 
trabajos repetitivos sin inteligencia. En el caso de que sea necesario un cambio en el procedimiento de 
producción en este tipo de celdas, es necesaria la planeación meticulosa de cuándo y cómo deben 
interactuar sus partes para la nueva forma en que van a trabajar. Este tipo de cambios se traduce en 
inconvenientes de tiempo y esfuerzo para la empresa. 
Es así que la Celda Integrada empieza a ser inadecuada para las necesidades actuales de flexibilidad 
de configuración y robustez de la operación . Las ciencias computacionales pueden ayudar a 
flexibilizar las celdas de manufactura . empleando técnicas de lnte:ligencia Artificial y de Tolerancia a 
6 
Fallas para la implementación de los controladores de los elementos de la celda y de esta manera. 
superar las deficiencias de la CIM. 
1.1 Definición de una Celda Flexible de Manufactura 
Actualmente se ha desarrollado el concepto de Celdas Flexibles de Manufactura (CFM) para referirse a 
las CIM's a las cuales se les añade las siguientes características [21 ]: 
• Flexibilidad de planeación, lo que implica un formato de planeación más amigable además de que 
puede adaptarse a los cambios del medio ambiente y de los objetivos. 
• Reconfigurabilidad. que es la capacidad de poderse adaptar a los rnquerimientos de fabricación de 
diferentes productos. 
• Detección y aislamiento de fallas. lo cual permite tolerar fallas dentro del proceso de fabricación. 
La CFM normalmente es coordinada por un sistema de control distribuido el cual lleva a cabo el control 
de los elementos de la celda y el control de las comunicaciones entre los mismos. Este sistema de 
control realiza la planeación, temporización . asignación de órdenes. control y verificación de las tareas 
necesarias para fabricar el producto. La integración de todas las func ones de la CFM se hace por 
medio de un sistema de datos distribuido , ya que los elementos de la celda se encuentran distribuidos 
en el espacio de trabajo. 
La presente tesis se desarrolla dentro del proyecto "Tecnologías de Comunicación Avanzadas en 
Robótica y Celdas Flexibles de Manufactura" [16] financiado por la National Science Foundation (NSF) 
y por el Consejo Nacional de Ciencia y Tecnología (CONACyT); en el cual participan los Campus 
Estado de México y Morelos del Instituto Tecnológico y de Estudios Superiores de Monterrey (ITESM) 
y la Universidad de Texas (UT) en Austin. El proyecto está estructurado de tal manera que la UT 
estudiará el problema de las comunicaciones dentro del robot inteligente. mientras que el ITESM 
estudiará las comunicaciones entre los componentes de la celda de manufactura , lo cual implica la 
arquitectura del controlador de la celda, tecnologías de comunicación en redes reconfigurables. 
interfaces entre los robots y el controlador , softwares de comunica.ciones. detección e identificación de 
fallas en la celda, simulación visual y planificación flexible. 
7 
El problema de las Celdas Flexibles de Manufactura (CFM) ha sido estudiado por el Instituto 
Tecnológico y de Estudios Superiores de Monterrey (ITESM) y la Universidad de Texas en Austin (UT) 
desde hace tiempo. La UT ha desarrollado estructuras modulares de robots desde hace 20 años . 
mientras que el ITESM cuenta con años de experiencia desarrollando celdas de manufactura, 
específicamente en el campus Estado de México (ITESM-CEM) y Momios (ITESM-CM). El énfasis del 
ITESM-CEM ha sido el diseño de la estructura del hardware del controlador de la celda. del software 
operacional y de comunicaciones. así como de un ambiente de simulación visual de la celda. 
1.2 Antecedentes 
Desde principios de los 90's el ITESM ha participado fuertemente en la automatización total de Celdas 
de Manufactura. En 1992 se trabajó en el diseño y construcción de un controlador de celda (ver figura 
1 2) (17], en donde el canal de comunicación entre la computadora (control de piso) y la tarjeta madre 
era único y de baja velocidad (RS-232), El envío de información entre los componentes del CIM y la 
computadora (control de piso) se hacía por medio de varios elementos intermedios con el siguiente 
flujo de información: 
Computadora --> Interfaz--> Tarjeta Madre--> Interfaz--> UPl's --> Interfaz--> Robots 
MIP 
Taiieta; 
Perifuica; 
f.'.$232 
M«qiJÍlw 
Ci11.ci.iu1«ti I 
1-+------1 IBM 7575 1 
RS232 . 
i-+-R-.S2_3_2 -1 Bw~~ 1 
Figura 1.2. Diagrama a bloques del controlador 
El diseño de éste controlador trajo consigo las siguientes deficiencias: 
• Al utilizar una interfaz RS232 a 2400 bps entre la computadora y los robots, se creó un cuello de 
botella en la transferencia de datos debido a la desproporción de velocidad. 
• El envio de información es demasiado lento debido a que la información tiene que fluir por tres 
interfaces. 
8 
• La arquitectura diseñada no es tolerante a fallas debido a que existen tres puntos únicos de falla 
(interfaces) en los que si se genera un error, produce un aislamie,nto en uno o varios elementos 
(robots). 
En atención a este proyecto y con miras a solucionar los problemas anteriores se propuso un 
controlador paralelo para celdas flexibles de manufactura [16], ver figura 1.3: 
a: 
~ 
...J o a: .... 
z 
o 
u 
I PROCESADOR OcoNMUTADOR @) INTERFl,Z 
Figura 1.3. Controlador de la Celda de Manufactura 
El controlador es un sistema distribuido, debido a la distribución fisica de los elementos en las celdas 
de manufactura. Por ser distribuido, tiene problemas como sincronización, retardos de comunicación. 
etc. El controlador también es paralelo , ya que está compuesto de varios procesadores que controlan 
cada elemento de la celda de manufactura. 
Se eligió el diseño de un controlador paralelo para poder implementar la tolerancia a fallas y para poder 
soportar operaciones complejas en tiempo real. El ambiente de procesamiento paralelo permite 
estrategias de control más complejas, a la vez que se mejora el desempeño del sistema ya que puede 
explotarse la redundancia inherente del sistema. Para este tipo de ambientes, se han venido usando 
procesadores que permitan el procesamiento paralelo y distribuido c:::,mo es el caso de los transputers 
[1 ][2][3] . 
El transputer cuenta con múltiples enlaces de comunicación, lo que lo convierte en un atractivo 
procesador sobre el cual construir sistemas tolerantes a fallas. Ofrece interconexiones flexibles. esto es 
. se pueden tener diferentes topologías de red de procesadores y ser reconfigurables de acuerdo a las 
necesidades del sistema. Tiene características de autoverificación gracias al uso extraordinario de 
enlaces y proporciona una forma muy robusta de redundancia deoido a que tiene la posibilidad de 
maneiar algoritmos paralelos . 
9 
En el Campus Toluca se trabajó en la interfaz del controlador de la celda basada en un 
microcontrolador MC8751 [7]. la cual permite comunicar a cualquiera de dos transputers con un 
elemento de la celda de manufactura en forma half-duplex (ver sección 2.1.1 ), cada transputer tiene 
como función ejecutar una rutina de tareas especificas mandando comandos al elemento de la celda 
de manufactura que le corresponde. El protocolo usado para establecer y mantener la comunicación 
entre los elementos de la celda de manufactura y el sistema distribuido paralelo (controlador) se 
desarrolló en [6]. dicho protocolo está dividido en tres niveles siguiendo el modelo de referencia OSI 
para redes locales (ver sección 2.1.2) . 
En un trabajo posterior [9] se estudió y propuso la topología de la a·quitectura distribuida sobre una 
tarjeta IMS 8008, la cual contiene la red de procesadores (transputers) del controlador y puede ser 
configurada con ayuda del un conmutador IMS C004 integrado a la tar.1eta. 
1.3 Objetivos 
Bajo el marco de la necesidades de tolerancia a fallas en el controlador implementado en [6][7] y [9] 
para una Celda Flexible de Manufactura. queriendo cubrir así los requisitosde capacidad de 
reconfiguración. detección y aislamiento de errores en hardware y en software. se establecieron los 
siguientes objetivos en el presente proyecto: 
1) Implementar la detección de fallas por medio de un monitor que valide periódicamente el 
comportamiento del sistema. Como el controlador de los elemen·:os de la celda de manufactura es 
un conjunto de procesos que se ejecutan en paralelo . es necesario que alguien (en este caso el 
monitor) se de por enterado del estado de cada uno de los elementos para poder decidir si el 
sistema esta trabajando de forma satisfactoria 
2) Hacer uso de la redundancia en hardware· en caso de que falle un procesador. En trabajos 
anteriores [9] se planteó una topología con características que proporcionan una redundancia en 
hardware de 2 a 2. esto es 2 procesadores (transputers) por dos elementos de la celda de 
manufactura. Es necesario desarrollar los programas que puedan hacer uso de los elementos que 
se encuentran redundantes o secundarios para ser empleado~; en caso de que falle el elemento 
principal. 
3) Hacer uso de la redundancia en software en caso de que falle un proceso. Si un proceso falla, 
debe ejecutarse una copia en otro procesador que pueda seguir y reemplazar al primero; es 
necesario además seguir con el mismo plan de trabajo que se estaba ejecutando en un principio. 
Por esto se desarrollará software que permita el uso de una parte de memoria secundaria en el 
procesador de respaldo para ejecutar dicho plan . 
10 
4) Proporcionar una guía que permita hacer uso de software hecho en Occam y ANSI e Toolset , así 
como de las herramientas disponibles para implementar el uso seguro de enlaces de comunicación 
entre transputers. Dichas funciones se implementarán para hacer procedimientos que ayuden a la 
comunicación entre los módulos que conforman el sistema tolerante! a fallas. 
Este proyecto siguió lo criterios necesarios para poder implementar la tolerancia a fallas en el 
controlador y que no fueron contemplados en [6] y [7], dichos criterios fueron proporcionar redundancia 
en hardware, optimizar el uso de la tarjeta para maximizar el espacio disponible en la misma, y la 
posibilidad de reconfigurar la red de procesadores para ejecutar c,tro plan de operación o aislar 
elementos con error (ver sección 2.1.3). 
En el presente trabajo se implementan técnicas de tolerancia a fa.llas en software con ayuda de 
procesos que se encargan de la supervisión del controlador y otros que se encargan de recuperar la 
operación normal en caso de alguna falla en el controlador. Estas técnicas fueron posibles gracias a la 
redundancia del controlador propuesto en [5, 1 O] para la CFM. Esto requirió del estudio de las 
diferentes técnicas para monitoreo de sistemas distribuidos, el establi=cimiento de estados globales. la 
comunicación entre procesos y entre procesadores y la reconfiguración de la red de procesadores. 
En el capítulo 2 de esta tesis se revisa a detalle el trabajo hecho anteriormente en otros Campus 
respecto al proyecto global de la celda flexible de manufactura y se d1=fine el problema. En el capitulo 3 
se definen los criterios de diseño y se plantea una solución de acuerdo al ambiente paralelo para cada 
punto susceptible a error; también se especifica el desarrollo en software necesario para poder crear 
los procesos que se encargarán de supervisar el sistema, detect21r una falla y restablecerse de la 
misma. Después del diseño, la implantación de los algoritmos se detalla en el capítulo 4, así como el 
uso de algunas funciones especiales predefinidas en los lenguajes usados (ANSI C Toolset y Occam 
2) . Finalmente en el capítulo 5 se dan las conclusiones y recomendaciones a futuro. con base a las 
experiencias obtenidas durante el desarrollo del presente trabajo. 
Como referencia se proporcionan varios apéndices que serán de utilidad al lector para el uso de las 
herramientas de software con las que cuenta el transputer. En el apéndice A se dan ejemplos y 
recomendaciones del uso de las funciones que involucran el uso extraordinario de enlaces tanto en C 
como en Occam para la transmisión segura de datos sobre un canal. Como para desarrollar el código 
de los procesos se hizo uso tanto del lenguaje C como del lenguaje Occam, en el apéndice B se da 
una explicación de la forma en que se hacen programas híbridos, es decir , que usan lenguaje Occam 
y lenguaje C paralelo . Finalmente en el Apéndice C Se proporciona el pseudo código y el código 
fuente de los distintos procesos que se usaron para implementar la tolerancia a fallas. 
11 
2. Problemática 
Como se explicó en el capítulo anterior, el proyecto "Tecnologías d•: Comunicación Avanzadas en 
Robótica y Celdas Flexibles de Manufactura" se ha dividido en varios módulos de los cuales ya se han 
desarrollado trabajos que sirvieron como base para definir la forma en la que se van a manejar las 
posibles fallas que se presenten en el sistema. Para dar continuidad a dichos proyectos. se debe lograr 
que el plan de trabajo que se envíe al controlador pueda seguir ejecutándose aún en presencia de 
alguna falla en sus distintos componentes. En este capítulo se hace cna descripción más detallada de 
los trabajos ya hechos y en base a ello se definen los posibles puntos de error en el controlador. 
2.1 Trabajos ya desarrollados para el proyecto "Tecnologías de Comunicación Avanzadas en 
Robótica y Celdas Flexibles de Manufactura" 
En el marco de este proyecto alumnos del ITESM en el Campus T:iluca y en el Campus Estado de 
México desarrollaron un controlador paralelo para celdas flexibles de manufactura el cual es una 
máquina de múltiples transputers con interfaces RS232 y topología reconfigurable, la cual se detalla a 
continuación. 
2.1.1. Interfaz bidireccional de comunicación entre dos transput1?rs y un elemento de la Celda 
La mayoría de los robots de una celda de manufactura manejan como interfaz la serial (RS232), la 
paralela (centronics) o MAP (Token bus). En el ITESM Campus Toluca . Alarcón [7] trabajó en el 
desarrollo de un circuito para sincronizar la velocidad del enlace del transputer (20 megabits/s) con la 
velocidad de la interfaz RS232 (20 kilobits/s) (ver figura 2.1 ). 
Los procesadores se alojan en los módulos TRAM's, el circuito C011 actúa como una adaptador de 
interfaz transformando la entrada serial de 20 Mbps que proviene del transputer a una señal de 8 bits . 
El circuito 74LS373 es un registro de 8 bits el cual permite a la interfaz operar en ambas direcciones. El 
microcontrolador 8751 lee datos de sus puertos y los envía , dependiendo de la dirección de la 
comunicación, al robot o al C011. 
Este circuito permite a cualquiera de dos procesadores (transputers) comunicarse con un elemento de 
la celda de manufactura en modo half-duplex por medio de un protocolo a nivel físico para sincronizar 
los elementos con las diferentes velocidades. El software y el ha·dware de esta interfaz es capaz de 
implementar un conmutador 2x1 . lo que permite tener rutas alternas entre dos procesadores y un 
elemento de la celda de manufactura. 
12 
8751 
RS232C 
ROBOT 
Figura 2.1 Interfaz conmutada 2 x 1 
Esta interfaz ocupa la mitad del tamaño de una tarjeta de PC y cuesta 1 O veces menos que un circuito 
similar proporcionado por el fabricante llamado SI0-232, aunque el SI0-232 tiene la capacidad de un 
conmutador 2x2 lo que permitiría a un procesador manejar de forma indistinta dos robots, o que un 
robot sea manejado por cualquiera de dos procesadores[1 O]. 
2.1.2 Protocolo de Comunicación 
El controlador de software hecho en el ITESM campus Toluca [6] esta dividido en tres niveles. 
siguiendo el modelo OSI para redes locales: físico, enlace y red, y aplicación .. El propósito principal de 
estos niveles que se ejecutan en cada transputer es establecer y mantener la comunicación entre los 
elementos del sistema paralelo/distribuido (transputers y robots), en cfüerentesniveles de abstracción. 
El nivel físico se encarga de la transmisión de bytes sobre los enlaces físicos. La comunicación 
transputer-transputer se implementa por hardware, mientras que eil microcontrolador MC8751 en la 
interfaz del controlador de la celda contiene el protocolo entre los robots y los transputers. Este 
protocolo fue diseñado para sincronizar los robots con los transputers. 
En la figura 2.2 se muestra el intercambio de información (para mayor claridad es sólo en un sentido) 
entre una fuente RS-232 . el microcontrolador y el adaptador de e1lace C011. El protocolo comienza 
cuando un robot envía un dato serial al microcontrolador. Después de recibir 8 bits, el dato se presenta 
en paralelo al adaptador de enlace, y se envía una señal lval. El adaptador de enlace envía una señal 
serial al transputer y cuando recibe un reconocimiento, envía una señal lack al microcontrolador para 
terminar la comunicación. 
13 
o 
a. 
:E 
w 
¡= 
MAX 232 MC8751 C011 
R,D 
IAck 
NIVEL DE 
RED/ENLACE 
DE 
DATOS 
T805 
.....--
Ack 
Figura 2.2. Protocolo a Nivel Físico 
NIVEL DE 
APLICACION 
El nivel de enlace/red es el responsable de establecer y mantener la comunicación entre un par de 
elementos en el sistema, incluso aunque no estén conectados directamente. 
El intercambio de datos entre el robot y el transputer se maneja como un protocolo punto a punto [6]. 
2.1.3 Arquitectura reconfigurable de una red de transputers para ol controlador de una CFM 
El esquema presentado en [6] supone que uno de los transputers está controlando a un robot, y en 
caso de que dicho procesador tenga un error, una ruta alterna permitirá que sea controlado por el otro 
transputer. 
En un trabajo posterior [9] se considera además de la reconfiguración por hardware (rutas alternas) la 
reconfiguración por software gracias al uso de canales virtuales y de una red de transputers totalmente 
conectada. 
La base de este trabajo fue la tarjeta 8008 la cual se encuentra alojaoa en una PC en modo pipeline 
(ver figura 2.3). Soporta hasta 10 transputers y todos ellos tienen sus enlaces conectados a un 
conmutador reconfigurable (IMS C004) 32x32, lo que permite establecer rutas de comunicación 
redundantes. 
14 
TARJETA IMS 8008 
, 5 6 2 o 4 7 3 8 9 
HOST - 510 
C=JBElBBBB • • 
RS-232 
ELEMENTO DE LA RS-23:! ELEMENTO DE LA 
CELDA DE CELDA DE 
MANUFACTURA 
PUERTO A PUERTO A 
MANUFACTURA 
RS-232 
ELEMENTO DE LA RS-232 ELEMENTO DE LA 
CELDA DE CELDA DE 
MANUFACTURA 
PUERTO B PUERTO B 
MANUFACTURA 
Figura 2.3 Distribución del hardware del controlador paralelo 
Para definir la topología base del controlador [9] , se siguieron los siguientes criterios: 
• Necesidades de aplicación: El controlador se comunica con todos los elementos de la celda y 
coordina sus acciones. 
• Redundancia de Hardware: Proporcionar un cuadro que permita implementar técnicas de tolerancia 
a fallas. 
• Optimización de la tarjeta: Como la celda de manufactura tiene varios elementos y es necesaria la 
redundancia en hardware, se maximizó el uso del espacio disponible en la tarjeta. 
Reconfigurabilidad: El controlador debe cambiar su configuración para ejecutar otros planes o aislar los 
elementos con error. 
La topología base (ver figura 2.4) consiste de cuatro transputers para manejar 4 elementos de la celda. 
Por cada elemento de la celda se considera que debe existir un transputer que lo controle. Existen dos 
enlaces por cada interfaz a los transputers, de tal manera que puedan ser accesados por cualquiera de 
ellos para la redundancia en hardware. 
El conmutador permite a los transputers T1, T2, T3 y T4 controlar cuatro elementos de la celda de 
manufactura. Existen dos enlaces desde cada interfaz a los transputers, por lo que puede ser 
accesada por cualquiera de los dos para redundancia en hardware. Esta topología tiene también varias 
rutas alternas que permiten al controlador cambiar su configuración. El transputer TS se tiene 
contemplado para usarse como monitor de todo el sistema, por lo c,ue está conectado a todos los otros 
transputers. Esto no es físicamente posible debido a que el transputer sólo cuenta con cuatro enlaces. 
pero se pueden implementar enlaces por software llamados enlaces virtuales . 
15 
Ti = Número de transpu1er 
SIOi = Número de inlcrfacc SIO 
Figura 2.4. Topología base seleccionada 
Un enlace virtual es una conexión entre transputers que usa varios enlaces físicos y que se 
implementa gracias a ruteo de mensajes a través de la red. 
Para proporcionar la capacidad de reconfiguración del controlador y poderse adaptar a los cambios 
debidos a planeación y fallas, se implementó redundancia en procesadores a partir de la topología 
base. La base de lo anterior es el uso del conmutador IMS C004 como se muestra en la figura 2.5. 
o so 
2 
T1 
S1 S2 S3 S4 S5 S6 
1 2 1 2 2 1 2 1 2 1 2 .... SIO 
2 
o 3 o 3 o 3 o 3 o 3 o 3 
IMS C004 
Puntos de conexión del C004 
Número del enlace correspondiente al transpuler conectado en la ranura ( slot) 
sx = número de la ranura (slot) en la taf)eta IMS 9006 
S7 S8 S9 
2 2 
o 3 o 3 o 3 
19 
Figura 2.5. Relación de los puntos de conexión del C004 para obtener la topología base 
Los transputers vienen por fabricante , conectados en forma de pipeline, las conexiones para el pipe 
line son las que se forman con los enlaces 2 y 1 de cada transpute1·. Para poder emplear el resto de los 
16 
enlaces se configura un archivo con las conexiones extras. Un ejemp'.o de una conexión extra en la 
figura es la que va del transputer T1-enlace3 al S101-enlace0 . por medio de las entradas de 
comunicación 1 O y 11 del conmutador C004. Este nuevo enlace es una ruta alterna para llegar al S101 
además de la que se forma del pipe original con la ruta transputer T1-enlace2 y S101-enlace1. 
En la topología base se establecieron 4 rutas alternas (lineas gruesas). de tal manera que cada 
transputer tiene dos enlaces con su interfaz 1/0 correspondiente. 
En la figura 2.6 se muestran los cinco enlaces virtuales que usa el controlador. lo que completa la red 
de transputers interconectada. Dos de los enlaces se usan para el proceso monitor de TS. el cual 
necesita comunicación con cada uno de los otros procesadores del controlador. El resto de los enlaces 
virtuales se usan para implementar la conexión entre los procesadores y el controlador. Esta red 
totalmente conectada es necesaria para los requerimientos del nivel de~ aplicación. 
RLTTA ALTERNA 1 ¡f'· • .,. .... • • ~ = 
~ 
u 
.... 
\ 
.. .. 
'. 
\ 
.. 
IIIITA ALTERNA 2 
! 
.. ... 
• 1 
"• /. • • ••·•"•' • • •• • ....... • s •• • • JI 
RUTA ALTERNA 4 
Ti = Número de transputer 
S!Oi = Número de interface SIO 
[nlacl':-. 101alrnen1e nnualc~ 
En\acc::s lis1cos. car, colocac1oncs de canales v1nualcs 
-············ Enlaces Íls1cns. oor1 colocac1oncs de canales direc1os 
Figura 2.6. Enlaces de comunicación 
El nivel de aplicación tiene dos funciones principales: ejecución y supervisión. La ejecución recaerá en 
un sistema multiagentes, mientras que la supervisión está implementada por un monitor y bloques de 
recuperación. La principal motivación del uso de un sistema multiagentes inteligente para controlar la 
celda de manufactura, es incrementar la flexibilidad [191[20]. Lo anterior será posible gracias a que la 
red de transputers está completamente conectada a través de los e,nlaces virtuales. 
17 
El sistema de supervisión es el responsable de implementar un software tolerante a fallas. Para la 
implementación . debe involucrarse el uso de la redundancia tanto en hardware como en software. 
2.2 Puntos susceptibles a error en el controlador de la celda de manufactura 
Para continuar con el proyecto se debe desarrollar software que permita a los procesadores interactuar 
entre ellos con el propósito de ejecutar un plan de actividades el cual se recibe por medio de la interfaz 
con el usuario. Así. la filosofía funcional se resume en recibirun plan ce actividades. ejecutar el plan de 
actividades. monitorear la ejecución de las mismas y tolerar fallas. 
En el sistema de manufactura, las fallas pueden ser de hardware o de software. Estas pueden ser 
tratadas por medio de la redundancia de componentes o por reconfiguración de sus elementos. Es por 
esto que el sistema tolerante a fallas debe detectar y localizar la falla para después aislarla (evitando 
su propagación) y recuperarse de ella. Un sistema de comunicación basado en un "bus" único entre 
robots es muy vulnerable a fallas, por ello el uso de una red con múltiples caminos y capacidad de 
reconfiguración disminuye la vulnerabilidad del sistema de comunicaciones. 
Tomando como base la topología elegida en [9], un transputer monitor debe estar conectado a todos 
los demás. De esta manera existe un procesador que actúa corno árbitro para determinar si los 
canales de comunicación o alguno de los transputers falló. Esto no podría ser posible físicamente 
porque los transputers solo tienen cuatro enlaces, pero pueden implementarse rutas extras por 
software por medio de rutas virtuales. 
Debido a las características de la tarjeta IMS 8008., sólo un transputer puede establecer comunicación 
con el huésped. Dicho transputer puede tener otras funciones, ya sea como controlador de un 
elemento de la celda ó como el monitor de los procesos. 
La topología base de la red contempla un transputer raíz conectado a una malla de cuatro transputers 
y dos módulos SIO [1 O]. El módulo SIO es la interfaz que se va a e1cargar de hacer el intercambio de 
mensajes entre el controlador formado por una red de transputers y el sistema de robots. Cada SIO en 
la topología base está conectado a dos transputers para el manejo de dos elementos de la celda, lo 
cual permite tener rutas alternas entre los robots y el controlador. 
El hardware presentado en [9] contempla el uso de rutas alternas las cuales se podrían utilizar en caso 
de fallas, La topología base puede cambiar entonces a otra que conserve las características de 
comunicación entre los elementos de la red de transputers y los elementos de la celda (ver figura 2.2). 
En el caso de la redundancia en Software. se plantea en [9] el uso de canales virtuales y 
reconfiguración de procesos. 
18 
La redundancia en el software se usará para darle a cada procesador la capacidad de ejecutar una 
copia de otra tarea de procesamiento del sistema en caso de falla. El estado de cada tarea del sistema 
se almacenará al final de cada cambio significativo en paralelo. De esta manera se puede recuperar el 
estado del sistema a partir de un bloque de recuperación después de que se detecte una falla 
(recuperación de error hacia atrás [2]). 
Para que fuera posible la reconfiguración por sotfware es necesaria una conectividad mayor a la 
proporcionada por hardware, por lo que se optó por el uso de canales virtuales (ver figura 2. 7). Un 
canal virtual es un canal entre dos procesos localizados en procesadores que no tienen conexión 
física, es decir que no están unidos por un canal directo. Los procesos se enlazan por ruteo a través de 
procesadores intermedios que están conectados físicamente y que permiten establecer una ruta del 
origen al destino. Los canales virtuales permiten implantar redes de topologías arbitrarias que pueden 
ser configuradas y modificadas dinámicamente. 
u a 
u.. .. /. ........ -··- - .... ·-· - - ·~ - = = - - j 
RUTA ALT[R!'IA 4 Enl;iccs lotalmenie v,rtuales 
Ti= Número de Lransputer Enli\ces lis1cos. con c:Jlocac1oncs de canales v1nualcs 
SIOi = Número de interface SIO ••.•• • ••.•••. Enlaces lis1cos. coo rnlocilCIUncs de i.:anales dircc1os 
Figura 2.7. Topología con Rutas Alternas y Canales Virtuales 
De lo anterior podemos deducir que los errores de los cuales es neceisario recuperarse para que el 
sistema continúe funcionando son: 
19 
• Falla en alguno de los enlaces entre procesadores. La conexión física entre un procesador y otro 
es el medio de comunicación para enviar instrucciones a un robot y para coordinar sus acciones 
con otro controlador, por lo que no debe perderse dicha comunicación 
• Falla en alguno de los procesadores. El elemento principal de,I controlador es el procesador 
(transputer) ya que es el elemento que ejecuta el plan de trabajo en conjunto con los otros 
procesadores. 
• Falla en alguno de los procesos. Aunque el procesador no falle, e~; posible que el proceso que esté 
ejecutando se quede en espera infinita y bloquee todo el funcionamiento de la celda, lo que podría 
evitarse si otro proceso tomara su lugar 
• Desconocimiento del estado global del sistema. La ejecución del plan de trabajo es de forma 
dinámica y paralela, ya que mientras una parte del controlador está ejecutando ciertas 
instrucciones . otra parte puede estar ejecutando otras que son independientes de la primera, por lo 
que es necesario conocer el estado global en caso de reiniciar el sistema. 
Para poder implementar la tolerancia a fallas se tiene que partir de las siguientes premisas: 
• El paso de mensajes se hace por las rutas principales pero pued,en hacerse también rutas alternas 
(redundantes) entre los procesadores. 
• Un sistema de monitoreo se ejecuta en un transputer . recibiendo periódicamente el estado de 
cada elemento de la celda. 
• Los procesadores deben ser capaces de ejecutar varios procesos concurrentemente para que . si 
hay una falla, otro procesador tome su lugar. 
• Cada transputer controla un robot con un código primario o principal, y tiene un área auxiliar en 
donde reside el bloque de recuperación de otro transputer. corno se muestra en la figura 2.8. La 
versión primaria del código siempre se usa, a menos que falle una prueba de aceptación o se 
detecte que expiró algún tiempo límite de comunicación. En el caso de que la falla sea de un 
procesador, el código auxiliar localizado en otro procesador toma el control del elemento de la 
celda correspondiente. 
• El plan de trabajo debe cargarse desde un principio tanto en la parte principal del procesador como 
en la parte secundaria 
• Debe definirse un tiempo finito de ejecución para poder detectar retardos erróneos 
20 
..... 
Q.) -::, 
Cl. 
1/) 
e: 
ctl ..... 
1-
Q.) 
"O 
ctl . ¡;: 
o 
E 
Q.) 
~ 
Datos Datos 
Principales Auxiliares 
Codigo Codigo 
Principal Auxiliar 
Micro Kernel 
Figura 2.8 Estructura del Agente 
Como se puede concluir, los elementos que sirven como base de la implantación del sistema tolerante 
a fallas de la celda de manufactura son el procesamiento paralelo y distribuido de una red de 
procesadores (transputers) y la redundancia que se puede obtener de la topología base. En el 
siguiente capitulo se describe la tolerancia a fallas en este tipo de sisti~mas 
21 
3. Tolerancia a Fallas en Una Celda de Manufactura 
Actualmente existe una creciente preocupación por hacer más confiables los sistemas 
computacionales de tal manera que tengan un nivel aceptable de servicio y que pueda ser mantenido 
en presencia de fallas. En el mejor de los casos , un sistema debe ccntinuar operando sin perder su 
funcionalidad, y en el peor de los casos, puede seguir funcionando con una pequeña degradación en 
su desempeño. La tolerancia a fallas es la capacidad que tiene un sistema de operar correctamente en 
presencia de falla, y es deseable que esté presente en aplicaciones como sistemas de navegación, 
sistemas de control, sistemas computacionales, etc. 
La ventaja de tener redundancia y alta respuesta en los sistemas de procesamiento da la pauta para 
poder detectar, aislar y recuperarse de fallas de hardware. Los múltiples enlaces de comunicación con 
los que cuenta el transputer, lo hace un atractivo procesador sobre el cual construir sistemas tolerantes 
a fallas. Ofrece flexibilidad en sus conexiones, y puede proporcionarse redundancia en forma robusta y 
todo esto en tiempo real. 
En este capítulo se describen técnicas de tolerancia a fallasen software y hardware. Se describe 
también el uso de distintas formas de redundancia y se hace referencia a algunos conceptos de 
paralelismo y de programación del transputer, que es el elemento procesador de la celda. Finalmente, 
en base al paralelismo y redundancia que proporciona la arquitectura del transputer y la 
reconfigurabilidad, se implementa la tolerancia a fallas eri una Celda Flexible de Manufactura 
3.1 Tolerancia a Fallas en Sistemas Paralelos y Distribuidos 
Los sistemas paralelos y distribuidos se vuelven cada vez más presentes en una gran variedad de 
áreas de aplicación las cuales incluyen bancos, sistemas financieros, control de tráfico aéreo, 
tecnologías médicas y sistemas críticos. Los sistemas distribuidos se caracterizan por tener sus 
componentes distribuidos geográficamente , los cuales deben cooperar correctamente entre ellos para 
llevar acabo un objetivo en común. 
A medida que crece el número de componentes de un sistema también se incrementa la probabilidad 
de que alguno de sus componentes falle. Aunque las fallas en un sistema distribuido pueden ser 
normalmente toleradas una vez que han sido identificadas. una falla no identificada puede resultar en 
el mal funcionamientos del sistema o incluso en la pérdida del mismo. El evitar el mal funcionamiento 
22 
del sistema es la motivación de la existencia de la tolerancia a fallc,s en los sistemas paralelos y 
distribuidos. 
3.1.1 Definición de falla 
El ciclo de mal funcionamiento de un sistema es el siguiente : primero se genera una falla ( daño que 
normalmente es un defecto físico o imperfección que ocurre dentro de un componente ) de Hardware o 
Software, por una debilidad en el componente en particular. La falla generará un error que en si es la 
manifestación de la falla, el cual puede ser un cálculo erróneo ó una unidad de información incorrecta. 
Finalmente el error ocasiona un mal funcionamiento del sistema, como una acción que no se ejecuta 
como se esperaba ya sea en calidad o en cantidad, y que finalmente es lo que percibe el usuario [4]. 
La tolerancia a fallas es la c:apacidad del sistema de seguir funcionando apropiadamente después de 
que ha ocurrido una falla. 
Un error es temporal por naturaleza. Puede ser latente o detectado: un error es latente mientras no se 
ha reconocido como tal; se· dice que ha sido detectado cuando se ha identificado ya sea por los 
mecanismo de detección de error que analizan el estado del sistema o por el efecto del error sobre el 
servicio. Generalmente un error propaga otros errores nuevos . dentro d,~ otras partes del sistema. 
Las fallas pueden clasificase como 
• Fallas francas: 
• Fallas transitorias: 
• Fallas temporales y; 
• Fallas bizantinas 
3.1.1.1 Fallas francas 
Las fallas francas (crash en inglés) se pueden presentar en cualquier momento . En el instante en que 
un elemento tiene la falla, dE~tiene todas las operaciones que estaba realizando y no realiza nada mas 
a partir de ese momento a menos que sea reparado y reinicializado. Desde el punto de vista de 
enlaces de comunicación, el enlace no se considera operacional si es incapaz de transmitir algún 
mensaje. Desde el punto de vista de procesos, éste deja de ejecutarse y , cuando asi sea el caso, deja 
de enviar mensajes. Ejemplos de este tipo de fallas son la falla de un proceso, un interbloqueo en el 
sistema. una ruptura de un cable. así como una falla del controlador. 
23 
3.1.1.2 Fallas transitorias 
En las fallas transitorias, el proceso puede producir un resultado falso pero continúa trabajando 
normalmente; un proceso pL1ede perder un mensaje pero libera el resto de los mensajes que pasan por 
él. Aunque los resultados pueden estar dentro del marco especificado, pueden estar ausentes. Como 
ejemplos de fallas transitoria.s está la pérdida de un mensaje, o la supresión de un proceso para evitar 
un interbloqueo. A este tipo de falla también se le conoce como intermitente o de omisión. 
3.1.1.3 Fallas temporales 
Las fallas temporales se llaman también fallas de temporización o desempeño. Estas fallas están 
ligadas a la noción de tiempo y descansan sobre la existencia de un especificación precisa de 
comportamientos temporales.. El mensaje llega antes o después del momento previsto. Ejemplos de 
estas fallas son el retardo de un mensaje, un reloj muy rápido, o la sobrecarga de un proceso que 
ocasiona un adelanto del vencimiento de su ejecución. 
3.1.1.4 Fallas temporales 
Las fallas bizantinas reúnen a todas las fallas no consideradas en las categorías anteriores. Se 
conocen también como fallas universales o maliciosas. Todo comportamiento fuera de lo especificado, 
es calificado como un comportamiento bizantino. Por ejemplo: un cambio en la política del orden en las 
transmisiones es una alteración de especificaciones y , por lo tanto . una falla bizantina. 
En la figura 3.1 se muestra la jerarquización del tipo de fallas que puede!n ocurrir en elementos como 
procesadores. enlaces comunicación , interfaces, etc., que son elementos que pueden integrar una 
celda de manufactura y que ya se describieron en párrafos anteriores 
24 
Fallas transitorias 
(omisión de transmisión) 
Fallas Francas (Crash) 
Fallas temporales 
(omisión de recepción) 
Omisiones Generales 
Fallas arbitrarias o biizantinas 
Figura 3.1. Tipos de Fallas 
En el momento del diseño de los diferentes componentes de un sistema tolerante a fallas. es común 
tomar en cuenta las hipótesis que involucran un solo tipo de falla, como alguna de las que se señalaron 
anteriormente. De esta manera el sistema es tolerante al tipo de falla escogida. Una de las hipótesis 
más frecuentes es la tolerancia a fallas de omisión. 
3.1.2 Características de un sistema tolerante a fallas. 
Para poder certificar que un componente no funciona bien. primero se tiene que definir qué es lo que 
ese componente debe hacer. Eso implica que es necesario establecer la especificación del supuesto 
comportamiento del sistema. 
Durante el diseño y la implementación de un sistema es posible que las especificaciones cambien. Una 
vez que se cuenta con la definición de cómo debe comportarse el sistema se tiene un criterio para 
juzgar el funcionamiento del sistema. 
La especificación debe ser exacta, consistente, completa y autoritativa. Por exacta queremos decir que 
no deben existir circunstancias para las cuales no se pueda distinguir un funcionamiento aceptable de 
uno inaceptable. Una especificación es autoritativa desde el punto de vista que no debe tener dudas 
sobre el buen o mal funcionamiento del sistema y no admite Jna autoridad mayor. Se considera 
completa si esta definido para todas las posibles circunstancias. Así mismo debe de ser capaz de 
tomar una decisión aunque las circunstancias produzcan situaciones conflictivas. 
25 
Finalmente el sistema tolerante a fallas contará con alguna o varias de lé1S siguientes características: 
• Confiabilidad: Es la probabilidad condicional de que el sistema actúe correctamente dentro de un 
intervalo de tiempo, si se asume que al inicio del intervalo el sistema se comportó correctamente. 
Este tipo de característica es deseable en un sistema donde es intolerable cualquier mal 
funcionamiento, incluso por lapsos muy pequeños. 
• Disponibilidad: Es la probabilidad de que el sistema opere correctamente y se encuentre disponible 
para llevar acabo sus funciones en cierto instante de tiempo (a difernncia de la confiabilidad que se 
refiere a un periodo de tiempo). Depende de qué tan frecuente se encuentre inoperante el sistema 
y qué tan rápido se recupere. 
• Seguridad: Es la probabilidad de que se ejecute un sistema sin que dañe otras partes del mismo; 
en otras palabras , si el sistema falla , que falle de manera segura. 
• Ejecución: Es la probabilidad de que el desempeño del sistema permanezca arriba de cierto nivel 
operativo. 
• Mantenimiento: Es la forma de cuantificar qué tan fácil es reparar un sistemacuando falla; es decir, 
la probabilidad de que un sistema regrese a su estado operacional em cierto tiempo. Debe tomarse 
en cuenta de que para llegar al punto de operación normal al ocur'ir una falla debe pasar por su 
localización, reparación y finalmente operación normal. 
• Pruebas: Es la facilidad de hacer pruebas de manera integral en el sistema para identificar y 
localizar un problema específico. 
Algunos sistemas no necesitan de tolerancia a fallas debido a la poca importancia del tiempo de 
recuperación que puedan tener o a lo poco crítica que sea su operación en tiempo real. Las 
aplicaciones que requieran tolerancia a fallas pueden clasificarse como sigue: 
• Aplicaciones de larga vida, donde se requiere de un 95% de operación, como en los vuelos 
espaciales. 
• Aplicaciones de cálculos críticos, donde los cálculos efectuados durante la operación son muy 
importantes para el buen comportamiento del sistema. como las referentes a la seguridad humana. 
limpieza del ambiente, protección de equipo, sistemas de control industrial, etc. En estos casos la 
tolerancia a fallas es muy útil ya que simplifican mantenimientos coslosos ó difíciles de ejecutar. 
• Aplicaciones de alta disponibilidad, en los que se debe recibir el servicio en el momento en que se 
solicita. 
26 
En el caso que nos compete, como en cualquier sistema de control, tenemos una aplicación donde es 
necesario que todos los componentes del sistema trabajen correctamente la mayoría del tiempo, o en 
caso de que alguno fallara, llevar al sistema a un estado seguro para poder reiniciar posteriormente. 
Cuando ocurre una falla en un sistema, es necesario que cuente con las herramientas necesarias para 
poder enfrentarse a ellas. Estas herramientas pueden dividirse en módulos que se encargan de las 
siguientes funciones: 
• Detección del error: para volver un sistema tolerante a fallas, hay que definir una estrategia para 
detectar los errores que han provocado una falla. 
• Estimación de los daños: una vez que se ha detectado el error, hay que medir el nivel de daños 
ocasionados al sistema. 
• Restablecimiento del error: tienen como objeto transformar el estado erróneo del sistema en un 
estado no-erróneo. gracias al cual es sistema pueda volver.ª funcionar. 
• El manejo de la falla y el restablecimiento: se define la activación de los servicios redundantes de 
manera que se pueda asegurar la continuidad del servicio. 
3.1.3 Detección de error. 
La mayoría de las técnicas de detección de error se basan en excepciones, las cuales son 
comportamientos del sistema que están fuera de la especificación ::le funcionamiento. Cuando se 
alcanza una excepción, se invoca al manejador de excepciones , el cual tomara una decisión de 
acuerdo a la excepción en particular. 
Consideremos el sistema S, el cual proporciona el servicio f(s). Si el comportamiento de S no es el 
especificado entonces S ha fallado. 
Como el objetivo de la tolerancia es prevenir las fallas, puede tomarse ,~n cuenta interceptar las salidas 
producidas por el sistema S y verificar si sus resultados se encuentran dentro de las especificaciones. 
Esto implica el diseño de un nuevo sistema S' el cual consiste de un módulo de servicio (igual al 
original) pero con un módulo de verificación de resultados. 
La verificación sólo se basa en la especificación del sistema. Como no debe haber fallas entre el 
sistema y la verificación, deben se independientes. Lo anterior es dificil de llevarse acabo en la 
realidad, por lo que los sistema sólo usan verificaciones de aceptación, que es lo que se considera un 
comportamiento aceptable del sistema., lo cual no ofrece ninguna garantía de ausencia de errores no-
detectados. 
Existen varios tipos de verificaciones, dependiendo del momento en que se hagan. Es más usado es/a 
verificación de último momento. Este tipo de verificaciones se hacen después de que se generaron los 
27 
resultados justo antes de que los libere el sistema. Esto es porque Jna vez que el resultado dejó el 
sistema. no puede aplicarse ningún mecanismo de tolerancia a fallas; y también porque se asegura 
que ninguna actividad del sistema queda sin verificar. 
La mayoría de los sistemas usan verificaciones que pueden ser cualquiera de los siguientes: 
• Verificación de réplica: Involucra una copia de la actividad que se está verificando para encontrar 
errores de consistencia El tipo de réplica depende del tipo d1! falla a detectar. Este tipo de 
verificación es de las más poderosas pero también de las más caras para detectar errores 
• Verificación de tiempo: Se usa cuando la especificación indique limitantes de tiempo para proveer 
el servicio. Si alguna parte del servicio no se proporciona en el tiempo especificado se produce una 
excepción de timeout que indica la falla del componente. 
• Verificación de regresión: Se usa en sistemas donde hay una relación uno a uno entre los datos de 
entrada y los datos de salida. A partir de la salida del sistema, calcula la entrada que debió 
producirla. y compara las entradas calculadas con las entradas actuales. en caso de diferencia se 
alcanza una excepción. 
• Verificación de codificación: Se basa en la redundancia que existe en la representación de un 
objeto que se usa dentro del sistema. Dentro de los objetos se introducen datos redundantes los 
cuales tienen una relación fija con los datos que representan el valor del objeto. De esta forma 
pueden detectarse los errores que resulten de una corrupción de cualquier tipo de dato. 
• Verificación de razonamiento: Se verifica si el estado de los diferentes objetos en el sistema es 
"razonable", en base al uso y propósito de dichos objetos. 
• Verificaciones estructurales: Se refiere a la verificación de las estructura de datos en un sistema 
computacional. Dicha verificación puede ser de la integridad semántica de los datos, que se refiere 
a la consistencia de la información contenida en la estructura de datas; o de la consistencia de la 
estructura. 
• Verificaciones de diagnóstico: Están involucrados específicamente con la verificación de los 
componentes del sistema, más que en la verificación del comportamiento del sistema mismo. 
Involucra probar un componente con un conjunto de entradas cuyas salidas sean conocidas 
3.1.4 Estimación de los daños. 
Antes de que algún método de recuperación de error empiece a ejecutarse a partir de que se ha 
detectado el error, es necesario que el sistema adopte estrategias de estimación de daños con el 
objeto de establecer más precisamente la extensión del daño dentro del sistema. 
28 
Estas estimaciones se basan en la estructura sobre la cual el diseñador asume que el sistema estará 
funcionando. debido a que esta estructura es la que le permite al diseñador identificar la posible 
actividad que puede seguir el sistema después de una transición de error, y los posibles flujos de 
información. La estructura se deriva de las restricciones conocidas o a~;umidas. del flujo de información 
del sistema. De esta manera se confina el daño causado por una falla. 
La técnica más simple y más pesimista para una estimación de daños es la estática, la cual consisten 
en asumir que una vez que se ha alcanzado una excepción. todos los objetos involucrados . desde el 
inicio del cálculo hasta que se alcanzó la excepción, han sido dañados. 
Hay otras técnicas menos pesimistas que intentan proporcionar medie a dinámicas dentro del sistema 
operacional para calcular un estimado del daño. Esto involucra medidas que exploren las estructuras 
de datos del sistema y determinen el tamaño del daño. Como dicha exploración tiene que detectar 
errores, puede hacerlo con las técnicas antes mencionadas. 
Estas medidas de exploración son difíciles de implementar de una forma efectiva en un sistema 
computacional y normalmente sólo se usan en situaciones muy especificas y simples. En la práctica 
las situaciones inesperadas y complejas requieren de algunaforma de asistencia manual para 
determinar el nivel de daño que fue causado por una falla. 
3.1.5 Recuperación del error. 
Una vez que se ha detectado el error y determinado el daño ocasionado. se puede restablecer el 
servicio para continuar operando. 
Una vez que se alcanza una excepción, se invoca al manejador de excepciones. Si el diseñador puede 
predecir los posibles errores de una excepción en particular. se habla de un daño anticipado. de otra 
forma es un daño no anticipado. 
En los daños anticipados es posible implementar una recuperación de error eficiente, mientras en un 
daño no anticipado se adopta una política de supresión de errores lo que implica reemplazar el estado 
total del sistema (reinicializar). 
En general existen dos técnicas de recuperación:. 
• Recuperación hacia adelante: Se pone el sistema en un estado de coherencia futura el .cual no ha 
sido visitado. Esta técnica es eficaz cuando los algoritmos fun::ionan en ambientes que son 
capaces de predecir situaciones previsibles. 
• Recuperación hacia atrás: Tiene por objetivo regresar el sistema a un estado anterior al de la 
aparición de la falla. 
29 
3.1.6 El manejo de la falla y el restablecimiento. 
Aquí se describen las técnicas para erradicar las fallas del sistema de tal forma que el sistema pueda 
seguir funcionando. Esta técnicas deben proporcionar una forma de tratar a la falla . Se divide en dos 
etapas que son la ubicación de la falla y la reparación del sistema. 
Una de las .. estrategias más fáciles es la de ignorar la falla y esperar que todo se comporte bien. 
Para poder tratar una falla hay que conocer su ubicación; la excepción debe indicar claramente el 
componente que falló . 
Cuando se ha localizado la falla. uno o más componentes del sistema se consideran como averiados. 
Para prevenir que estos componentes alteren el comportamiento futuro del sistema se hace una 
especie de reparación del sistema. es decir , se intenta reparar el componente averiado. Estas técnicas 
de reparación se basan en reconfigurar el sistema de tal forma que las características de los 
componentes sospechosos sean modificadas. 
La técnicas de reparación se pueden clasificar en 
• Manuales: las acciones las realiza algún agente extremo al sistema 
• Dinámicas: las acciones son realizadas por el sistema. pero solo en respuesta a instrucciones 
dadas por el medio ambiente 
• Espontáneas: todas las acciones son iniciadas y realizadas por el mismo sistema. 
Se debe tomar la decisión de sí puede reanudarse la actividad interna del componente después de que 
la excepción ha sido manejada por el sistema. Si no puede reanudarse. se debe señalar una excepción 
que termine la actividad del componente. 
3.1.7 La redundancia dentro de la tolerancia a fallas. 
Las soluciones de tolerancia a fallas caen en dos categorías: 
• enmascaramiento de fallas y 
• detección, diagnóstico y recuperación de fallas . 
En el enmascaramiento de fallas, el comportamiento de un componente erróneo se enmascara . 
normalmente por medio de la votación de la salida de cálculos redundantes . 
Una de las formas más comunes de obtener tolerancia a fallas es la redundancia , que consiste en el 
uso de información, recursos o tiempo, adicionales a los necesarios para la operación normal. En los 
sistemas computacionales, la redundancia puede obtenerse duplicando hardware. software y/o datos 
3.1. 7 .1 Redundancia en Hardware 
30 
La redundancia en hardware consiste en la replicación de componentes en alguna de las sus tres 
formas; pasiva. activa e híbrida [11]: 
En la redundancia pasiva. se enmascara la ocurrencia de fallas pero no ofrece detección, aislamiento 
o reparación del módulo que falló. No se necesita ninguna acción del sistema o del operador. 
Normalmente usa mecanismos de votación para enmascarar. Un com.~onente llamado votador evalúa 
el comportamiento de los módulos restantes; si decide que alguno falló, elige a alguno de los restantes 
para tomar su lugar y así enmascarar la falla, asegurándose de que, cada memoria tiene los datos 
correctos. La desventaja es que se genera un punto único de falla ya que al fallar el votador, falla todo 
el sistema por lo que la confiabilidad recae en un sólo elemento. Para evitar esto puede haber 
redundancia también en los votadores. 
Un método común de redundancia pasiva es el triple modular redundancy o TMR. El objetivo del TMR. 
usado en el ambiente pasivo, es enmascarar un falla triplicando el hardware y haciendo una votación 
sobre los resultados. La forma más típica de votación en hardware es lo que vota la mayoría. como se 
ilustra en la figura 3.2. Un esquema más confiable del TMR se muestra en la figura 3.3 Aquí todos las 
rutas están triplicadas tantas veces como partes tiene el sistema. Inminentemente debe alcanzarse un 
resultado. Esta técnica impide que los datos sean corrompidos. 
MODULO 1 
ENTRA DA 
MODULO 2 V E:t 
SALIDA 
MODULO 3 
Figura 3.2 Redundancia Modular Triple (TMR) con un votador ideal 
31 
MODULO 1 voTA3~ 
ENTRADAS 
MODULO 2 
MODULO 3 E7 
Figura 3.3 Redundancia Modular Triple (TMR) con votadores no ideales 
En la redundancia activa o dinámica, no se enmascara la falla , pero se detecta su localización de tal 
manera que un componente extra pueda ser cambiado para reemplazar al componente con falla. Esta 
técnica detecta la existencia de fallas y ejecuta una acción para remover o aislar el hardware dañado 
del sistema. Para poder llevarlo a cabo es necesaria la capacidad de reconfiguración. Se usa en 
aplicaciones donde pueden aceptarse temporalmente resultados erróneos o retardos mientras el 
sistema se reconfigura. 
MODULO 1 
OETECCION 
DE ERROR 
CON MU- SALIDAS ENTRADAS 
MODULO 2 TADOR 
Na 1 
DETECCION 
DE ERROR :;::::; CD 
• o • 
MODULO 3 
DETECCION 
DE ERROR 
Figura 3.4 Redundancia Activa usando la replicación de espera 
Una técnica de replicación activa es el reemplazo . En éste caso, una unidad se encuentra en 
operación mientras que una o varias unidades más se encuentran en espera. Se usan diferentes 
32 
esquemas de detección de fallas para determinan cuando remover la unidad de la operación y usar el 
componente extra para reemplazarla, ver la figura 3.4 
Esta técnica regresa el sistema a completa operación después de una falla. pero puede ser necesario 
que se interrumpa el procesamiento mientras el reemplazo entra. l::sta interrupción del procesamiento 
puede no tolerarse. por lo que se usa los que se llama "hot swapping" . En esta técnica el elemento que 
va a reemplazar al que está operando, opera al mismo tiempo que la unidad que está en línea y está 
preparado para ocupar su lugar en cualquier momento. 
ENTRADAS 
o 
D 
o 
SALIDAS DE 
ELEMENTOS 
~----,ACTIVOS 
2 
e, 
• 
o 
N 
RESPALDO 
---l~ 1 1----~ 
• • 
DETECTOR DE DESACUERDOS +----------, 
o • o o o o 
CONMUTADOR 
o o o 
IDENTIFICACION 
DE DESACUERDO 
Figura 3.5 . Redundancia N-Modular (NMR) 
SALIDA 
El concepto básico de la replicación híbrida es combinar las bondades de los métodos pasivo y activo 
para generar un sistema que tenga enmascaramiento de fallas, localización de la falla características 
de detección de falla así como posibilidad de hacer un reemplazo de: la unidad que ya no funciona. Usa 
una máscara para evitar generar resultados erróneos. y reconfiguración para remover el hardware 
dañado. Una de las técnicas más importantes es la redundancia N-modular, o NMR (N-modular 
redundancy), con refacciones o reemplazo, ver figura 3.5 
Esta técnica consiste de un núcleo NMR con un conjunto de recursos de respaldo. Este sistema 
permanece con configuración de NMR básico hasta que el detector de desacuerdos determina que una 
33 
unidad ha fallado. Una vez que se identifica, la unidad errónea si= cambia y se reemplaza con un 
respaldo. Este tipo de replicación se usa en aplicaciones que exigen una alta integridad. 
3.1.7.2 Redundancia en Tiempo 
La redundancia en tiempo usa