MXPA05014131A - Equipo de red y un metodo para monitorear el arranque de tal equipo. - Google Patents

Abstract

La invencion se refiere a un equipo de red para la conexion a una red local y un metodo para monitorear el arranque de un equipo tal. Este equipo comprende una memoria persistente (4) para almacenar la dotacion logica informatica (software) (5, 6 , 7) y ventajosamente tambien comprende: los medios de comunicacion (8, 9) para la conexion a la red, - los medios (10) para monitorear el arranque del equipo con el fin de detectar una falla del software, los medios (10) para generar una senal de falla del software en respuesta a la deteccion de una falla sobre la red, e donde dicha notificacion es difundida sobre la red para la recepcion por al menos un servidor de software.

Description

EQUIPO DE RED Y UN MÉTODO PARA MONITOREAR EL ARRANQUE DE TAL EQUIPO DESCRIPCIÓN DE LA INVENCIÓN La presente invención se refiere a un equipo en red y a un método para monitorizar el arranque del software (dotación lógica informática) de tal equipo. El equipo de red autónomo, tal como un modem DSL, un puente o un encaminador (ruteador) o una combinación de los mismos, se utiliza por ejemplo para interconectar una red de área local ' con una red de acceso tal como la Internet. Comúnmente, el equipo autónomo comprende una memoria persistente, también llamada medio de memoria a bordo, tal cómo una memoria de solo lectura (ROM) y/o. una memoria de solo lectura programable, eléctricamente borrable (EEPROM por sus siglas en ingles) . Esta memoria contiene entre otros, datos y software necesarios para iniciar el arranque y la corrida del equipo tales como los parámetros de configuración del equipo, el software y la microprogramación ' (firmware) de introducción de instrucciones iniciales. Para asegurar su arranque, algunos equipos' autónomos contienen dos copias de algunos de los" elementos antericrmente mencionados, por ejemplo la configuración del equipo, el software de introducción de instrucciones iniciales y la microprogramación. Pero algunos moderas pueden tener una memoria persistente justo lo' suficientemente grande para contener una copia simple de estos datos. En ese caso, si estos datos son corrompidos, el equipo deja de funcionar adecuadamente hasta que la memoria persistente recupera una nueva microprogramación válida o la configuración, o el programa de introducción de instrucciones iniciales. Esta situación puede ocurrir, por ejemplo, cuando el . modem descarga el software perfeccionado · de un servidor apropiado. Ya que la memoria persistente puede mantener únicamente una copia del software, el software viejo es ' borrado antes de que sea completamente grabado o uno actualizado. Si la conexión es cortada o si el equipo tiene baja energía durante la descarga, el software es corrompido. Puede suceder también que" el equipo se detenga durante la fase de energización o reinicialice automáticamente debido a una falla del software o del hardware (equipo físico) . En tales casos, el equipo usualmente deja de funcionar adecuadamente y notifica el estado' del problema al usuario final por medio de un indicador de diodo emisor de luz (LED por sus siglas en ingles) . Se sabe, por ejemplo de la Patente de los Estados Unidos No. 6,526,092, el permitir que un modem descargue el código operativo actualizado sobre una linea telefónica, hacia una computadora personal anfitriona y reprograme la memoria del modem sobre un puerto serial proveniente de la computadora personal anfitriona. Este proceso está bajo el control del usuario. La presente invención proporciona un equipo de red para la conexión a un arreglo local, comprendiendo la red al menos un servidor de software, el equipo' comprende una memoria persistente para almacenar el software, caracterizado porque comprende: - los medios de comunicación para la conexión a la' red, medios para monitorizar el arranque del equipo con el fin de detectar una falla en el equipo, medios para generar una señal de falla del software en respuesta a la detección de una falla por el medio ' de monitoreo, y para enviar automáticamente una modificación en la falla sobre la red, en donde la notificación es difundida sobre la red para la recepción por al menos un servidor de software.

De este modo, el usuario no necesita intervenir en el proceso de corrección de fallas, a no ser que el servidor decida que esto es requerido. Preferentemente, el servidor comprende una aplicación para analizar el tipo de falla y para tomar automáticamente las acciones correctivas . En particular, de acuerdo a una modalidad preferida de la invención, cuando la falla es una falla de arranque del software, los medios para la generación de una señal de falla son adaptados para requerir la descarga automática del software de reemplazo en el medio de memoria 'proveniente del servidor de software. De este modo, esta memoria persistente de la modalidad necesita mantener únicamente una memoria de software y tiene el mismo nivel de robustez que un equipo que mantiene dos copias de software o datos. Venta osamente, la descarga de software es realizada sin ningún retraso. La presente invención propone también -un método para monitorizar el arranque del software de un equipo de la red, comprendiendo el equipo una memoria persistente para almacenar . el software y los medios de comunicación para 1-a conexión a una red, que comprende al menos un servidor de software, comprendiendo este proceso los. asos de : - monitorizar el arranque del " software del equipo con el fin de detectar una falla del arranque del software, generar una señal de falla del arranque del software en respuesta a la detección · de una falla de arranque del software, difundir automáticamente la señal de falla del software sobre la red, para la recepción por al menos un servidor de software. La enseñanza de la presente invención puede ser fácilmente comprendida al considerar la siguiente descripción detallada pero no restrictiva de una modalidad de la invención, junto con los dibujos, en donde: la Figura 1 muestra un diagrama de bloques de . un sistema que abarca el equipo de red de acuerdo a la presente modalidad; la Figura 2 describe esquemáticamente un diagrama de flujo de un método de procesamiento, adecuado para el uso en el sistema de la Figura 1, y de acuerdo con los principios de la presente modalidad; y la Figura 3 describe esquemáticamente u diagrama de flujo del método ilustrado en la Figura 2, con más detalle.

'La Figura 1 muestra un diagrama de bloque de un sistema que incorpora un equipo autónomo 1 de acuerdo a la presente invención. Este equipo de red 1 consiste en cualquier dispositivo ¦ capaz de procesar la comunicación de transferencia de datos. Éste puede ser, por ejemplo, un modem del tipo DSL u otro equipo de red autónomo. El equipo está conectado a una red área local 2, a la cual está también conectado un servidor 3 y/o un dispositivo con una aplicación de procesamiento de fallas (no mostrada) . El quipo de red 1 está provisto con medios de memoria 4 persistente a bordo, tal como una Memoria de Solo Lectura, Programable', Eléctricamente Borrable (EEPROM) . Esta memoria persistente mantiene una pluralidad de elementos o ítems. De acuerdo a la presente modalidad, ésta almacena entre otros datos, los datos y los programas de- software necesarios para el arranque y funcionamiento del equipo: por ejemplo, los parámetros 5 de configuración del equipo, un software 6 de introducción de inicialización, y una microprogramacion 7. ¦ La configuración del equipo 5, es un grupo de parámetros que contiene entre otros el número de serie y la dirección ge la red del modem. ¦La microprogramacion 7 consiste de cualquier software escrito en una memoria que no sea borrable por un software de nivel de aplicación, por ejemplo, que tiene una cierta protección. En la presente modalidad, la microprogramación consiste por ejemplo del sistema" operativo del modem. Aunque en lo subsiguiente la microprogramación puede ser reemplazada globalmente por una descarga, la microprogramación puede comprender elementos o items distintos, y la invención no está limitada a una descarga en volumen, sino que también se extiende a la prueba y descargas de elementos separados. Como un asunto de hecho, el equipo '. autónomo 1 comprende también una unidad de procesamiento de datos tal como un -microprocesador que corre los diferentes programas, y una memoria no persistente, no representada para fines de claridad. Antes de la ejecución, el software almacenado en la memoria persistente es copiada a la memoria no persistente (por ejemplo RAM) . El equipo autónomo comprende también un módulo 8 de transferencia de datos entre los medios 4 de memoria a bordo y los medios 9 de comunicación de la red, conectado a la red 2. Este módulo de transferencia 8 puede emplear por ejemplo el protocolo estandarizado de inicialización (BOOTP por sus acepción en ingles) , y el protocolo de transferencia de archivos (TFTP por sus siglas en ingles) para intercambiar información entre el servidor 3 y el equipo 1.vía la red de área local 2. El equipo que es. un modem DSL de acuerdo con la presente modalidad, comprende también una interconexión P'STN correspondiente y el conjunto de circuitos asociados para llevar a cabo sus funcionalidades de DSL. Estos elementos' son bien conocidos por si mismos y no representados en la Figura 1. Los módulos 8 y 10 pueden ser ya sea equipo físico experimentado o ser módulos de software corridos por el microprocesador a partir de la memoria no persistente. De acuerdo a esta invención, el equipo autónomo 1, comprende también los medios - de monitoreo 10 capaces de controlar el arranque del software del equipo. Estos medios de monitoreo 10 verifican, entre otras cosas, la validez, la presencia y el arranque correcto de la microprogramación 7, y la validez de los datos de configuración 5. La verificación de la copia del software de inicialización en la memoria persistente, es también posible, pero no será discutida cón más detalle. En el caso de algún problema durante el proceso de arranque en particular, estos medios de monitoreo 10 generan una señal de falla del arranque de la microprogramación, que es transmitida por el módulo de transferencia 8 y el medio de comunicación 9 a través de la red' 2 de transferencia de datos, hacia el servidor 3 de software.

Esta señal de falla, notificada al servidor "3 de software, está asociada a una petición BOOTP de descarga de la " microprogramación de reemplazo, por el servidor. Una porción . estructural del protocolo BOOTP utilizada para enviar esta señal de falla, especifica el tipo de- software que va a ser descargado o la señal de falla apropiada. Esta porción estructural puede ser, por ejemplo, el "campo opcional especifico del vendedor" del protocolo BOOTP. Se asume que una aplicación en la red 2 de transferencia de datos, ilustrativamente el servidor 3 de software, mantiene una base de datos en donde los códigos de programa y el software de reemplazo y/o los datos de configuración, están almacenados. En respuesta a esta petición de BOOTP, este servidor 3 transmite el software de reemplazo al equipo de la red, a través de la red 2, utilizando el protocolo FTP del módulo de transferencia 8, y los medios de comunicación 9. En la práctica,' el mensaje BOOTP comprende un número de estados de falla del equipo, siguiendo el proceso detallado más adelante. Otros dispositivos sobre la red de área local interpretarán estos estados y decidirán sobre una acción correctiva, que incluye típicamente una descarga del software de reemplazo, pero también puede- incluir la notificación de la información de falla a un usuario.

Ventajosamente, los medios de monitoreo 8 pueden también ser asociados a un botón 11 el cual puede ser operado manualmente por el usuario para disparar la petición de una descarga de microprogramación y/o software de inicialización, sobre la red. Preferentemente, una alarma 12 visual o sonora está conectada al medio de monitoreo 10 para notificar de una falla del arranque al usuario. La Figura 2 muestra un diagrama de flujo que ilustra una · versión simplificada del proceso de arranque del equipo autónomo 1, de acuerdo' a la presente modalidad. Los pasos mostrados se refieren principalmente a la prueba de la validez y .la presencia de un software como por ejemplo una microprogramación en la memoria 4. Al tiempo de la energía encendida (paso 20) del equipo autónomo 1, los medios de monitoreo 10 lanzan' un paso 21 de prueba de la microprogramación, concerniente a la microprogramación necesaria para arrancar el equipo 1. Si no se detecta ningún problema durante este paso de prueba, los medios de monitoreo 10 verifican, en el paso 22, si la microprogramación está almacenada en los medios de memoria 4 a bordo. Si la microprogramación falta, los medios de monitoreo 10 generan una señal F de falla del arranque del software, y reinicializan el equipo.1.

En el paso 23, si el paso de prueba 21 no es exitosamente realizado, los medios de monitoreo 10 piden la descarga de una microprogramación de reemplazo proveniente del servidor 3 de software, a través de la red de transferencia 2, mediante el uso del protocolo BOOTP del módulo de transferencia 8 y los medios de comunicación 9. En el paso 24, el servidor 3 de software descarga una microprogramación de reemplazo a través de la red de transferencia 2, mediante el uso del protocolo TFTP del módulo de. transferencia 8, y los medios de comunicación 9.. En el .paso 25, los medios de monitoreo 10 controlan la precisión de la descarga. Por ejemplo, cuando la descarga ha sido interrumpida, los medios de monitoreo 10 -generan una señal de falla F de microprogramación, especifica (que comprende la identificación del tipo de falla) , y reinicializan el equipo 1, de modo que puede ser iniciada una nueva descarga. Si las pruebas son correctamente realizadas, los medios de monitoreo 10 cargas, durante el paso 26, la microprogramación y ajustan una bandera de falla de arranque y.. un cronómetro para determinar un limite de tiempo de arranque.. La bandera es reajustada por la microprogramación, si ésta realiza su propiedad de arranque. Si el arranque del software no es completado una vez que es alcanzado el límite de tiempo del arranque, la bandera es todavía ajustada, y los medios de · monitoreo 10 generan una señal F de falla de arranque del software (que comprende también una identificación del tipo de falla, diferente del primer tipo de falla anterior) , y reinicializan el equipo 1. De otro modo, en el paso 27, cuando el arranque del software es apropiadamente ejecutado éste reajusta la bandera de arranque del software y no es generada en ninguna señal de falla. Ventajosamente, de acuerdo a la modalidad, el equipo de red 1 proporciona una petición automática y una descarga automática de un software de reemplazo en el caso de una falla de arranque de la microprogramacion, o ausencia de microprogramacion. De este modo, por ejemplo las fallas de arranque son reparadas automáticamente y el usuario incluso no avisa la existencia de una falla. Específicamente, el diagrama de bloques de la Figura 3 muestra los detalles del proceso de arranque del equipo autónomo, de acuerdo a la modalidad. El proceso comienza en el paso 30, cuando es iniciada una condición de energía encendida para el equipo de la red. El proceso de la Figura 3 es luego ejecutado por el medio de monitoreo 10, utilizando los protocolos bien conocidos BOOTP y TFTP. En el paso 31, son ejecutados los pasos iniciales. Típicamente, los medios de monitoreo 10 verifican la disponibilidad de la memoria persistente 4 y la operación apropiada de la memoria no persistente. En 'el paso 32, ventajosamente y de acuerdo con la presente invención, es realizada una determinación respecto a si existe una falla en la configuración del equipo, o si · el usuario final ha presionado el botón de activación 11 para pedir una descarga de software. Si una de estas situaciones ocurre, los medios de monitoreo 10 saltan en el paso 33, y controlan la validez de los datos de configuración almacenados en los medios de memoria 4 a bordo. Las ¦ configuraciones del equipo 5 son-frecuentemente aseguradas por una firma o una suma de verificación. Esta firma o suma de verificación es registrada en los medios 4 de memoria a bordo del equipo 1. Una manera clásica y fácil para controlar la validez de una configuración del equipo, consiste en recalcular su suma de · verificación" y compararla a la registrada. Si existe una mala concordancia, la configuración 5 del equipo ya no es válida. En ese caso, los medios de monitoreo 10 establecen una. bandera 34 de falla, correspondiente. Venta osamente, esta bandera 34 es codificada para distribuir información respecto al tipo de fallas encontradas. En el caso anteriormente mencionado, la bandera 34 de falla comprende un estado de . información que indica la presencia de una falla de configuración del equipo. Dependiendo del tipo de datos de configuración, la falla del. dato de configuración puede o no ser corregible a través de una descarga. En el último caso, el mensaje BOOTP emitido por el equipo es interpretado por otros . dispositivos de la red, indicando que el equipo ya no puede ser utilizado y tiene que ser considerado como muerto. Si _ la configuración es válida . en el paso 33, eso significa que el usuario final ha presionado el botón 11 para disparar la descarga de la microprogramación. De este modo, los medios de monitoreo 10 establecen también una bandera 35 de falla de arranque del software. Esta bandera de falla 35 especifica que el usuario ha requerido una descarga de microprogramación. Si no ha sido requerida una descarga y en ausencia de un problema de configuración del equipo, los medios de monitoreo 10 verifican, después del paso 32, la validez del programa 7 de microprogramación registrada en los medios de memoria 4 a bordo, durante el paso 36.· Una manera simple para hacer esto consiste en controlar la presencia y la validez de su patrón de verificación (FVP para Flash Verification Pattern por su acepción en ingles) . El patrón de verificación es una herramienta clásica para verificar la integridad -del software o los . datos. Cuando la microprogramación es exitosamente registrada en la memoria persistente 4, es calculado un patrón ¦ de verificación y también escrito en la memoria 4. Si el equipo sufre de una falla de energía u otro .problema durante el almacenamiento de la microprogramación, el patrón de verificación correspondiente a esta microprogramación no es ni almacenado ni erróneo. Por lo tanto, el paso 36, los medios de monitoreo 10 verifican la validez de la microprogramación con la ayuda del patrón de verificación de la microprogramación. Si el patrón no es válido, entonces es ajustada una bandera ; 37 de falla. Para los otros pasos de prueba, esta bandera de falla particular indica la naturaleza de la falla. En el paso 38, los medios de monitoreo 10 verifican el ajuste de las banderas de falla 34, 35, 37. Si al menos una bandera es establecida, los medios de monitoreo 10 automáticamente enviarán una señal de falla al servidor. 3, a través de la red de transferencia 2 utilizando el protocolo BOOTP del módulo de transferencia 8, y los medios de comunicación 9. Este mensaje contiene el estado de . la bandera de falla. Las aplicaciones agrupadas con los dispositivos de red, tal como una aplicación del servidor 3 de software, escuchan estas señales e interpretan la información del estado de falla. Después de la interpretación de esta información, estas aplicaciones deciden, preferentemente sin ninguna intervención de usuario final, respecto a, una acción que comprende al menos una del inicio de una descarga de la microprogramación hacia el equipo 1 de la red y/o la notificación del problema al usuario, por ejemplo en el caso de ocurrencia de una falla de configuración fatal, al usuario se le notifica ya que no puede ser posible la corrección de la. falla. El usuario puede también ser notificado si una descarga no es realizada correctamente después de un cierto número de intentos . Un contador de intentos puede ser implementado para este propósito e incrementarse apropiadamente después de cada petición de mensaje BOOTP, por ejemplo una descarga de microprogramación. Específicamente, el módulo de transferencia 8 indica el estado de problema en el "campo específico opcional del vendedor" de un mensaje del protocolo BOOTP apropiado enviado sobre- la red por el medio de monitoreo 10. Este campo es de uso estándar para comunicarle a una aplicación ciertas restricciones o información adicional del cliente. En otras palabras, el mensaje es preferentemente difundido sobre la red y no específicamente a un servidor predeterminado. Cualquiera de los dispositivos sobre la red puede actuar como un servidor, con la condición de que éste tenga la aplicación correcta para escuchar, analizar y responder al mensaje. . Después de su descarga, el software de reemplazo es almacenado en los medios .de memoria 4, a bordo, persistentes. Este paso tiene la referencia 39. En el paso 40, los medios de monitoreo 10 controlan que el software de reemplazo haya sido descargado sin ninguna interrupción y que éste haya sido correctamente grabado . Cuando el software descargado . es una microprogramación, la unidad de procesamiento de datos verifica la microprogramación de reemplazo y calcula su patrón de verificación instantánea (FVP por sus siglas en ingles) y lo registra en la memoria 4 en el paso 41. Si el software de reemplazo es dañado o incorrectamente descargado o grabado, los medios de monitoreo . 10 ajustan una bandera 42 de falla, correspondiente. Luego, el equipo autónomo 1 es reinicializado . Por supuesto, las banderas son almacenadas de una manera tal como para no ser afectadas por el proceso de reinicialización. En el paso 31, el dispositivo prueba si la bandera 42 está ajustada, y envía un mensaje BOOTP correspondiente para pedir una descarga de microprogramación . En el paso 43, si no ha sido detectada ninguna bandera de falla en el paso 38, los medios de monitoreo 10 controlan la presencia de la microprogramación en los medios de memoria 4 a bordo. Existen diferentes métodos disponibles para verificar esta presencia. Por ejemplo, la presencia de microprogramación puede ser verificada con la detección de un código de identificación especificado en un sitio fijo del código de microprogramación. Otros métodos pueden también ser utilizados de acuerdo con esta invención. Si no está registrado ningún software, los medios de monitoreo 10 establecen una bandera de falla 44 y el modem es reinicializado ¦ en el paso 30 para procesar la falla, con base en la bandera establecida, como se describió anteriormente. Si el paso 41 o el paso 43 son ejecutados sin ningún problema, los medios de monitoreo 10 establecen una bandera de arranque' y disparan un cronómetro de arranque, en el paso 45, antes de cargar e iniciar la., microprogramación en el paso 46. Después de un arranque exitoso, la bandera de arranque es reajustada por la'- microprogramación, confirmando que ésta inició adecuadamente. No obstante, si el arranque no es realizado antes de que ha transcurrido el tiempo de inicio, los medios de monitoreo 10 establecen una bandera 48 de problema y reinicializan el equipo en el paso 30 para procesar la falla correspondiente. Para resumir, el proceso de la Figura 3 define cinco estados de problema: - error en el arranque del software (microprogramación). : la microprogramación se detiene durante el arranque o se reinicializa sin arrancar correctamente ; configuración inválida; descarga de software fallida (microprogramación) , (por ejemplo, interrupción del proceso de descarga) ; ausencia de software; escritura del software descargado al patrón de verificación fallido de memoria persistente, incorrecto) . • Otros estados pueden disparar una descarga del software: un botón mecánico del dispositivo fue presionado por el usuario para pedir una descarga de microprogramación; la microprogramación recibió una petición sobre la red para realizar una actualización de la microprogramación. ' Las banderas son verificadas por los medios de monitoreo ya sea al comienzo del proceso de inicialización, o durante su ejecución. Una descarga puede ser requerida explícitamente, o la decisión para la descarga debe ser dejada a una aplicación que escuche los mensajes del dispositivo. Esta invención no está restringida a la modalidad preferida descrita con la presente. En particular cualquier tipo de software o datos pueden ser descargados . Y este proceso puede también ser realizado con protocolos que difieren de los protocolos TFTP y BOOTP.

Claims (18)

REIVINDICACIONES

1. Equipo de red para la conexión a una red local, comprende al menos un servidor de software, el equipo comprende una memoria persistente para almacenar software, caracterizado porque comprende: -. medios de comunicación para la conexión a la red, - medios para monitorizar el arranque del equipo con el fin de detectar una falla en el software; - medios para generar una señal de falla del software en respuesta a la detección de una falla por los medios de monitoreo, y para enviar automáticamente una notificación de la falla sobre la red, en donde la notificación es difundida sobre la red para la recepción por al menos un servidor de software.

2. Equipo según la reivindicación 1, caracterizado porque la señal de falla . comprende la información que especifica al menos una de las siguientes: - la naturaleza de la falla, - una identificación del software de reemplazo que va a ser descargado, - una identificación de la versión del software actualmente almacenado en la memoria persistente.

3. Equipo según cualquiera de las reivindicaciones precedentes, caracterizado porque el software comprende al menos uno de los siguientes: - un programa de inicialización, - datos de configuración, microprogramacion.

4. Equipo según la reivindicación 3, caracterizado porque el software que comprende la microprogramacion, los medios para monitorear el arranque comprenden: - medios para verificar la validez de un patrón de verificación de microprogramación actual, y - medios para generar una señal de falla de arranque especifica del software, cuando este patrón de verificación no es válido.

5. Equipo según la reivindicación 1, caracterizado porque los medios para monitorizar el arranque comprenden: - medios para calcular la suma de verificación del software actual, - medios para comparar esta suma de . verificación . calculada a una suma de verificación previamente almacenada, - medios para generar la señal de falla de arranque del software cuando esta suma de verificación calculada no es idéntica a aquella almacenada.

6. Equipo según la reivindicación 3, caracterizado porque la memoria que comprende la microprogramación, los medios para el monitoreo del arranque comprende: - medios para verificar la presencia de la microprogramacion en los medios de memoria, - medios para reinicializar el equipo autónomo, cuando no está almacenada la microprogramacion en la memoria, - medios 5. para generar una señal de falla de arranque del software, cuando no está almacenada la microprogramacion en los medios de .memoria.

7. Equipo según cualquiera de las 10 · reivindicaciones precedentes, caracterizado porque los medios para el monitoreo del arranque comprende: - medios para verificar la descarga del software de reemplazo en la memoria, - medios para reinicializar . el equipo, y medios para generar una señal de falla del arranque del software, 15 cuando es detectado un problema durante esta descarga.

8. Equipo según las reivindicaciones 3 ó 4 y 7, caracterizado porque el software comprende microprogramacion, y el equipo comprende: - medios para •20 escribir un patrón de verificación de microprogramacion de reemplazo correspondiente a la microprogramacion de reemplazo . descargada en la memoria, cuando 'una microprogramacion de reemplazo es adecuadamente grabada en esta memoria.

9. Equipo según cualquiera de las reivindicaciones precedentes, caracterizado porque los medios para monitorear el arranque comprenden: - medios para verificar el proceso de carga de un software, - medios para reinicializar el equipo autónomo, y medios para generar una señal de arranque del software, cuando aparecen problemas durante esta carga.

10. Equipo según cualquiera ' de las reivindicaciones precedentes, caracterizado porque los medios para monitorear el arranque del software comprenden r - un cronómetro para determinar un límite de tiempo' de arranque, '- medios para lanzar el arranque del software, estando adaptado el software para iniciar una indicación final hacia el medio de monitoreo después de la terminación del arranque, - medios para generar una señal de falla de arranqué del. software, si el arranque del software no es completado antes de la finalización del límite de tiempo.

11. Equipo según cualquiera de las reivindicaciones precedentes, caracterizado porque éste comprende además medios accionables por el usuario conectados a los medios de monitoreo, para hacer posible que un usuario pida manualmente la descarga del software de reemplazo.

12. Equipo según cualquiera de las reivindicaciones presentes, caracterizado porque comprende además una alarma conectada a los medios de monitoreo, para notificar de una falla del arranque al usuario.

13. ' Equipo según cualquiera de las. reivindicaciones precedentes, caracterizado porque los medios para generar una señal de falla de arranque del software comprende: - medios para verificar el ajuste de una bandera de falla, y - medios para generar la señal de falla del software, y para transmitirla sobre la red en respuesta a la detección de una bandera de falla ajustada.

14. Equipo según cualquiera de las reivindicaciones precedentes, combinadas con la reivindicación 2, en donde la indicación de la naturaleza de la falla comprende una serie de banderas de estado.

15. .Equipo según la reivindicación 14, en donde la notificación comprende además una identificación de la versión del software actualmente almacenado en la memoria persistente.

16. Método para monitorizar el arranque del software de un equipo de red, el equipo comprende una memoria persistente para almacenar el software y los medios de comunicación para la conexión a una red, que comprenden 'al menos un servidor de software, comprendiendo este proceso los pasos de: - monitorizar el arranque del software del equipo, con el fin de detectar una falla de arranque del software, - generar una señal de falla del arranque del software en respuesta a la detección de una falla del software de arranque, - difundir · automáticamente la señal de falla del software sobre la red, para la recepción por al menos un servidor de software. .

17. Método según la reivindicación 16, en donde la señal de falla de software comprende una petición hacia al menos un servidor de software, para la descarga de software de reemplazo en la memoria.

18. Método según la reivindicación 16, caracterizado porque la señal de falla de software comprende una identificación de la - falla para el análisis por al menos un servidor.