ES2367790T3 - Sistema y procedimiento para la comunicación de datos en un sistema de video. - Google Patents

Abstract

Un procedimiento para el control y realización de auto-modelado de una cámara de vigilancia, controlable (14) configurada para proporcionar una señal de video sobre un medio de transmisión, comprendiendo el procedimiento, - conectar una nueva cámara de vigilancia de video (14) a un sistema de vigilancia existente, que comprende un controlador (12a); - transmitir un comando de auto-modelado (802) para la realización del auto-modelado desde una fuente de comandos integrada (12) en dicho controlador (12a) a dicha cámara de vigilancia controlable (14) sobre el medio de transmisión (18); - transmitir datos de respuesta (806) a dicha fuente de comandos (12) en dicho controlador (12a), siendo dichos datos de respuesta en contestación a dicho comando de auto-modelado (802) y configurándose para causar una representación de una pluralidad de información de ayuda disponible o funciones de la cámara para dicha cámara de vigilancia controlable (14); - transmitir un comando de comienzo de función (808) a dicha cámara de vigilancia controlable (14) en respuesta a dichos datos de respuesta (806), estando configurado dicho comando de comienzo de función (808) para causar que dicha cámara de vigilancia controlable (14) realice al menos una de dicha pluralidad de información disponible o funciones de cámara, en el que - dicho comando de respuesta (806) está configurado para causar que la fuente de comandos (12) represente un valor numérico asociado con cada una de dichas funciones disponibles para dicha cámara de vigilancia controlable (14) y - en el que dicha cámara de vigilancia (14) descarga nueva información de ayuda al controlador (12a) y actualiza dicho controlador (12a) de acuerdo con la nueva cámara de vigilancia instalada (14).

Description

Campo de la invención

La presente invención se refiere a sistemas de vigilancia de video que emplean cámaras de video controlables remotamente, y, más particularmente, a un sistema y un método para controlar y realizar el auto-modelado de un dispositivo de video controlable.

Antecedentes de la invención

Los sistemas de vigilancia de video están configurados convencionalmente como sistemas de circuito cerrado en los que una o más cámaras de video monitorizan de forma controlable áreas seleccionadas de interés. Las cámaras de video pueden transmitir señales de video sobre un cable a una consola de control en la que se conmutan las señales, se visionan sobre los monitores, etc. El cable sobre el cual se transmiten las señales de video puede usarse también para transmitir información desde la consola de control a la cámara, el multiplexor de video o el conmutador de video. Por ejemplo, pueden enviarse comandos desde la consola de control o el conmutador de video para controlar las características de desplazamiento-inclinación-zoom (PTZ) de una cámara de video de bóveda, la selección de la fuente de video dentro de un conmutador de video, descargando la cámara, actualizaciones del software del multiplexor o el conmutador de video, etc.

El cable coaxial ha sido el medio tradicional de elección para la transmisión de señales de video analógico desde la cámara a la consola de control. El proceso de transmisión de los datos de control sobre el medio de transmisión de video conduciendo los datos de control en la dirección opuesta con respecto a las señales de video se ha denominado comúnmente como el protocolo "Sobre El cable Coaxial" (UTC). Para impedir la activación del sistema por comandos que contienen errores de transmisión, las soluciones UTC convencionales o bien repiten los comandos transmitidos múltiples veces para proporcionar transmisiones redundantes, o usan comunicaciones bidireccionales por lo que se proporciona una señal de diálogo de confirmación por la cámara en respuesta al comando recibido.

El documento EP 0 726 673 A2 desvela un sistema de telemetría bidireccional en el cual los datos de telemetría se transmiten dentro de una secuencia de transmisión de imágenes de video a través de un medio de transmisión único.

El documento US 5.541.982 desvela la transmisión de señales de video y de audio a través de una red digital de servicios integrados por medios de bajo coste, que se realizan por un dispositivo en la forma de un adaptador de terminal al cual se conectan dispositivos de grabación de imagen y sonido y dispositivos de reproducción de imagen y sonido convencionales. El filtrado de comandos corrompidos típicamente requiere que el dispositivo que recibe los comandos verifique la suma de comprobación, la paridad, o el CRC de la señal transmitida. Los métodos de transmisión redundantes pueden requerir comandos consecutivos idénticos antes de actuar sobre ellos. Sin embargo, la verificación usando estas técnicas puede ser imposible cuando se corrompen múltiples comandos. Los esquemas bidireccionales actuales resuelven este tema transmitiendo un comando, por ejemplo a la cámara, durante un intervalo vertical de la señal de video y transmitiendo un mensaje de respuesta de confirmación positiva (ACK) de vuelta al controlador durante el siguiente intervalo vertical. Si el mensaje de respuesta indica una confirmación negativa (NACK), el controlador retransmitiría el comando sobre el siguiente intervalo vertical. Esta secuencia causa una latencia de dos periodos de tiempo vertical.

Ambos protocolos UTC redundante y bidireccional típicamente se han limitado a la transmisión/recepción de cuatro bytes de datos por periodo vertical de la señal de video. Esta restricción del tamaño del comando los ha hecho imprácticos para datos de comandos de velocidad variable de paquetes para todos los ejes de una cámara de bóveda de video dentro de una transmisión única. Con la cuenta de bytes limitada, el desplazamiento y la inclinación simultáneos de una cámara de video de bóveda ha requerido múltiples comandos.

Algunos protocolos de UTC han transmitido palabras de 16 bits en cada uno de los dos periodos de línea horizontal de la señal de video. Estos esquemas usan anchos de pulso más cortos para permitir que la palabra de comando se ajuste entre dos pulsos horizontales. Cuando se transmiten comandos UTC sobre largas distancias, los pulsos tienen tiempos de subida y caída más lentos y se retardan con respecto al video generado en el extremo de recepción. Los tiempos de subida y caída más lentos colocan un límite práctico sobre cuán estrechos pueden ser los anchos de pulso para facilitar la detección por circuitos de detección de bajo coste.

Los anchos de pulso usados convencionalmente cuando se transmiten palabras de 16 bits en una línea horizontal requieren que las palabras ocupen la mayor parte de un periodo horizontal. Para impedir que el último pulso de un comando UTC interfiera con el siguiente pulso de sincronismo horizontal de la cámara, la longitud del cable de transmisión debe limitarse. Por ejemplo, con cable coaxial RG59, la longitud debe ser inferior a 2500 pies (762 metros). Pulsos más anchos no son tan fácilmente degradables más allá de los límites utilizables debido a los tiempos de subida y caída, sin embargo pulsos más anchos reducen la longitud del cable utilizable debido a que reducen el margen entre el final de una palabra de comando y el siguiente impulso de sincronismo horizontal.

La longitud útil puede estirarse arrancando la transmisión antes de la señal del impulso de color. La corrupción de la señal del impulso de color durante el blanqueo vertical puede tener un efecto notable sobre la imagen dependiendo de la configuración del sistema. El solapamiento de comandos con el impulso de color puede requerir un circuito de detección más sofisticado en el extremo de la cámara para distinguir los pulsos de comandos débiles. Los datos de respuesta transmitidos por el dispositivo de la cámara están sujetos a los mismos retardos relacionados con el cable que la señal de video.

También, sistemas conocidos han requerido configuraciones complejas de repetidor para reconducir la señal de video con los datos de respuesta incorporados desde la bóveda de video, mientras que captura, almacena y reinserta los datos UTC desde el controlador en el siguiente intervalo vertical. Es deseable permitir series más largas de los medios de transmisión sin requerir caros repetidores, simplemente para evitar interferencia de comandos UTC. Para sistemas con medios de transmisión muy largos y pérdidas de señal razonables, por ejemplo de cable de fibra óptica, es deseable para el dispositivo que está suministrando la señal de video tener un receptor capaz de separar con precisión pulsos de comandos que solapan con pulsos de sincronismo horizontal o pulsos de color que se están transmitiendo en la dirección opuesta. Algunos protocolos de UTC sólo transmiten un byte de datos por línea horizontal. Este paquete de datos más pequeño permite retardos de transmisión más largos sin interferencia con el sincronismo horizontal. Los paquetes de un único byte también pueden codificarse con anchos de pulsos más anchos haciéndolos más tolerantes a la atenuación y los tiempos de subida y caída más largos asociados con recorridos de cables más largos o de menor coste o de menor calidad. Sin embargo, con el número limitado de líneas horizontales disponibles para la comunicación bidireccional durante un único periodo de blanqueo vertical, el enfoque de un único byte limita el tamaño total del comando a la mitad del disponible con esquemas de 16 bites por línea horizontal.

Otra dificultad asociada con los protocolos UTC convencionales es que hacen impracticables largas descargas de actualizaciones de firmware a través de series de comandos UTC de 4 bytes. Para añadir nuevas funciones a los sistemas de control de bóveda actuales, un operario usa teclas de función pre-numeradas o múltiples combinaciones de teclas para enviar comandos para controlar las nuevas funciones. La mayoría de controladores no proporcionan suficientes teclas de función libres para funciones futuras. El uso de múltiples combinaciones de teclas es engorroso debido a la dificultad de memorizar las combinaciones. Además, los comandos comunes y los usados más frecuentemente típicamente incluyen teclas dedicadas y claramente marcadas. Las nuevas funciones especiales tienden a usarse infrecuentemente, y, como tal, se beneficiarían de la mayoría de las etiquetas y pantallas de ayuda.

Las funciones que se necesitan realizar por teclas de funciones o secuencias de teclas no se conocen en el momento de fabricación del controlador y no están, por lo tanto, etiquetadas sobre el controlador. Algunos controladores tienen pantallas que pueden usarse para representar etiquetas o una ayuda para las teclas de funciones, pero las funciones deben conocerse en el momento de la fabricación, o deben instalarse actualizaciones para los controladores a medida que se añaden nuevas características. Cuando se desarrollan nuevas bóvedas de video con nuevas características que requieren nuevos comandos, los controladores instalados deben actualizarse o los operarios deberán forzarse a memorizar las teclas o secuencias de teclas para usar las nuevas características.

Las técnicas convencionales de UTC son por lo tanto ineficaces en la transmisión de comandos de control y datos sobre un medio de transmisión a una bóveda de video, conmutador, grabador, etc. De hecho, un simple control de movimiento de dispositivos de vídeo tipo bóveda tiene una latencia notable. También la transmisión de nuevas actualizaciones de software son los suficientemente lentas para considerarse imprácticas y añadir funciones de control a un sistema existente es difícil.

Por consiguiente, hay una necesidad de mejorar la velocidad de descarga de comandos de control y datos sobre un medio de transmisión a una bóveda de video, un conmutador, un grabador, u otro dispositivo de un sistema de vigilancia de video. Hay también una necesidad de un método fácil y eficaz de implementar nuevas funciones en un controlador de un sistema de video.

Sumario de la invención

La invención se expone en las reivindicaciones como un anexo a las mismas.

Breve descripción de los dibujos

Para un mejor entendimiento de la presente invención, junto con otros objetos, características y ventajas se hará referencia a la siguiente descripción detallada que debería leerse en conjunción con las siguientes figuras en las que los mismos números representan las mismas partes:

la FIG. 1 es un diagrama de bloque simplificado de una realización de ejemplo de un sistema de vigilancia de video en circuito cerrado en el cual se aplica un método consistente con la presente invención;

la FIG. 2 es una ilustración de un formato de datos de ejemplo de un comando y una respuesta consistente con la invención; la FIG. 3 es una ilustración de un formato de datos de ejemplo de un comando de movimiento de la cámara consistente con la invención; la FIG. 4 es una ilustración de un formato de datos de ejemplo de una respuesta al movimiento de la cámara consistente con la invención; la FIG. 5A es una representación del voltaje respecto al tiempo que ilustra esquemas de codificación de ejemplo útiles en un sistema consistente con la presente invención. la FIG. 5B es una representación del voltaje respecto al tiempo que ilustra la temporización para los datos de comandos y respuestas en un sistema consistente con la invención con respecto a un pulso de sincronismo horizontal; la FIG 6 es un diagrama de flujo de bloques de un método de ejemplo del control de una cámara de video consistente con la presente invención; la FIG. 7 es un diagrama de flujo de bloques de un método de ejemplo de descarga de datos a una cámara de video consistente con la presente invención; la FIG. 8 es un diagrama de flujo de bloques de un método de ejemplo de auto-modelado consistente con la presente invención; y la FIG. 9 es una vista perspectiva de un controlador de ejemplo consistente con la presente invención.

Descripción detallada

La presente invención se describirá en el presente documento en conexión con diversas realizaciones de ejemplo de la misma. Se entenderá que las realizaciones descritas en este documento se presentan a modo de ilustración, no de limitación. La presente invención puede incorporarse a una amplia diversidad de sistemas que requieren comunicación bidireccional sobre un cable de transmisión sin apartarse del espíritu y alcance de la invención. Además, aunque el cable coaxial ha sido el medio tradicional de elección para la transmisión de señales de video analógicas, los especialistas en la técnica reconocerán que otros medios tales como los cables de pares de hilos trenzados, el cable de fibra óptica, etc., se están haciendo elecciones comunes. La presente invención no está limitada a cualquier medio de transmisión particular. Como tal, un protocolo consistente con la invención puede ser más adecuadamente descrito como un protocolo "Sobre El Cable" para indicar su utilidad en la conexión con cualquier tipo de medio de transmisión.

Volviendo ahora a la FIG. 1, se ilustra, la forma de un diagrama de bloques simplificado, un sistema de ejemplo de vigilancia de video de circuito cerrado 10 consistente con la invención. El sistema 10 incluye: un dispositivo de control del sistema o controlador 12 para controlar el funcionamiento de una o más cámaras de video. Los especialistas en la técnica reconocerán que pueden controlarse una diversidad de dispositivos controlables de video, por ejemplo, conmutadores de matriz de video, multiplexores de video, grabadores de video y etc., pueden controlarse por otros dispositivos, y que los dispositivos controlables pueden configurarse también para controlar otros dispositivos controlables sobre la misma conexión de video o sobre conexiones separadas. Para simplificación de las realizaciones de ejemplo ilustradas en este documento, las comunicaciones de referencia entre una fuente de comandos de video y un dispositivo controlable de video usan un controlador de video como fuente de comandos genérica y una cámara de video o bóveda de video como un dispositivo de video genérico controlable.

Continuando con referencia a la FIG. 1, por simplicidad y facilidad de explicación sólo se ilustra explícitamente una cámara de video 14. El sistema 10 también incluye varios monitores de video, que no se muestran, y una matriz de conmutación 16 para encaminar señales de video desde las cámaras seleccionadas a través del dispositivo de control 12 de modo que las señales de video desde las cámaras seleccionadas se representan sobre monitores que también se seleccionan a través del dispositivo de control 12.

Cada una de las cámaras, incluyendo la cámara 14 está conectada a la matriz de conmutación 16 por medio de un medio de transmisión. De nuevo, por simplicidad, el medio de transmisión en la FIG. 1 es un cable 18 asociado con la cámara 14. El medio de transmisión puede ser sin embargo cualquier medio capaz de transmitir señales de video desde la cámara y señales de comandos hacia la cámara, tal como un cable coaxial, cable de pares trenzado, cable de fibra óptica, aire, etc.

La cámara 14 puede ser una cámara de video del tipo de bóveda en la cual las características de funcionamiento de la cámara incluyendo la dirección de visión, la condición de zoom, enfoque, etc., pueden cambiarse por control remoto. En particular, las señales de control se transmiten a la cámara 14. En respuesta a las señales de control recibidas en la cámara, los motores se controlan para cambiar las características de funcionamiento de la cámara.

Puede proporcionarse un circuito receptor de códigos de control y un controlador del motor 20, bien como parte integrante de la cámara o como un componente separado. Las señales de video generadas por la cámara 14 pueden sacarse desde la cámara 14 al circuito 20, que a su vez acopla las señales de video al cable 18 para su transmisión a la matriz de conmutación 16. Se entenderá que la referencia a la transmisión de datos o señales hacia y desde la cámara se pretende que indiquen la transmisión hacia y desde el circuito 20 sobre el cable 18 sobre el cual se proporciona la señal de video, independientemente de si el circuito 20 está integrado con la cámara o físicamente separado de la misma.

Las señales de control de la cámara generadas en el dispositivo de control 12 están acopladas sobre el cable coaxial 18 por la matriz de conmutación 16 para la transmisión a la cámara 14. Más específicamente, las señales de control transmitidas a través del cable 18 desde la matriz de conmutación 16 se reciben y se detectan en el circuito receptor 20 y, después de un acondicionamiento adecuado, se transmiten desde el circuito receptor 20 para controlar los motores (no mostrados separadamente) asociados con la cámara 14. Como también se verá, el circuito receptor 20 puede incluir también circuitería apropiada para la compensación de pérdidas y los efectos dependientes de la frecuencia a partir de la transmisión de video y las señales de control a través del cable coaxial 18.

Como se reconocerá por los especialistas en la técnica, una señal de video proporciona información para hacer que una imagen se represente sobre una pantalla de video o monitor por líneas horizontales. La imagen se arranca en la esquina superior izquierda de la pantalla de video y las líneas horizontales se escriben de izquierda a derecha en respuesta a la señal de video. Cuando se acaba una línea, se escribe la siguiente línea horizontal justo debajo de la línea anterior. En un enfoque, este proceso de escritura de líneas horizontales en respuesta a la señal de video se repite hasta que se completa una primera trama de video, por ejemplo 525 líneas horizontales. La señal de video entonces causa que la imagen comience de nuevo en la parte superior de la pantalla de video para comenzar la escritura de la siguiente trama de video.

En un enfoque de interfaz común, cada una de las tramas se divide en campos separados, cada uno con la mitad de la información de la imagen. El primer campo de imagen puede contener todas las líneas horizontales de número impar, y el segundo campo puede incluir todas las líneas horizontales con numeración par. Después de un campo, por ejemplo todas las líneas con numeración impar se barren desde arriba a abajo de la pantalla, el segundo campo, por ejemplo todas las líneas de numeración par, se barren desde arriba a abajo de la pantalla. Este proceso se repita, por ejemplo a 30 tramas por segundo, para producir la imagen de video.

Cuando se barre cada una de las líneas horizontales, el barrido se devuelve al lado izquierdo de la pantalla sin producir una imagen sobre la pantalla. Esto se lleva a cabo durante el intervalo de blanqueo horizontal llevando la señal de video a un nivel de blanqueo. Del mismo modo, después de que se barren todas las líneas horizontales para una trama y/o un campo, el barrido se vuelve desde la parte inferior de la pantalla a la parte superior de la pantalla sin producir una imagen. Esto se lleva a cabo durante el intervalo de blanqueo vertical llevando la señal de video a un nivel de blanqueo. Durante el periodo de blanqueo vertical, se barren varias líneas horizontales fuera del área de visión en la parte superior de la pantalla de video sin producir una imagen. Por ejemplo, el video de acuerdo con las normativas fijadas por el Comité de Normativas de Televisión Nacional (NTSC) incluye 525 líneas de barrido, pero 42 de las líneas horizontales en la parte superior de la pantalla, es decir 21 para cada uno de los campos verticales, comúnmente se borran durante el periodo de blanqueo vertical. Ventajosamente, un sistema y un método consistente con la presente invención se lleva a cabo la comunicación bidireccional sobre el cable 18 transmitiendo 8 bytes de datos en ambas direcciones, es decir hacia y desde la cámara, durante cualquier intervalo de blanqueo vertical de la señal de video. El uso de 8 bytes de datos para una señal de comando desde el controlador permite una respuesta de confirmación de 8 bytes de datos desde la cámara para seguir inmediatamente la señal de comando en el mismo periodo de blanqueo vertical. Esto reduce la latencia del comando atribuida a los protocolos de diálogo de UTC en un 50%, mejorando por lo tanto significativamente la facilidad de control de las cámaras de video en tiempo real, tales como los dispositivos de video de tipo de bóveda.

También una señal de comandos de 8 bytes proporciona suficiente espacio para un byte de cabecera de comando un byte de CRC de comprobación o suma de comprobación, y comandos simultáneos para todos los ejes, de un dispositivo de video de tipo bóveda, incluyendo las variables PTZ. Esto reduce drásticamente la latencia en comparación con las soluciones convencionales. De hecho, el control de los tres ejes simultáneamente con una señal de comando único y envío de respuesta de confirmación durante el mismo periodo de blanqueo vertical reduce la latencia a aproximadamente 1/6 de los protocolos convencionales.

Volviendo ahora a la FIG. 2, se ilustra un formato de la señal de comando de ejemplo 200 consistente con aspectos adicionales de la invención. Como se muestra, la señal de comando incluye 8 bytes de datos, es decir, dos bytes transmitidos sobre cada una de los números de líneas horizontales 11-14 durante el periodo de blanqueo vertical. Los números de línea horizontal 202 referenciados en la FIG. 2 corresponden a los números de línea común NTSC, donde el final de la línea Nº 3 sobre los campos impares, o el medio de la línea Nº 3 sobre los campos pares corresponden al arranque del pulso de blanqueo vertical. Se entenderá, sin embargo, que la presente invención tiene aplicabilidad a cualquier formato de la señal de video, incluyendo los formatos NTSC/EIA y PAL/CCIT.

Por ejemplo, las líneas horizontales en los sistemas de Alternancia de Fase por Línea (PAL) están normalmente numeradas de 1 a 625, con el pulso de blanqueo vertical al comienzo de la línea 1 para los campos pares o el medio de la línea 313 para los campos impares. Para convertir la trama de datos ilustrada para su uso en una normativa de video PAL, los comandos podrían sacarse sobre la línea horizontal NTSC identificada menos 3 para los campos pares, y más 310 para los campos pares. Es de entender que los datos transmitidos sobre las líneas números de 11

5

10

15

20

25

30

35

40

a 14, elegidos como la primera implementación de este protocolo y usadas para ilustrar esta invención, pueden sacarse sobre otras combinaciones de líneas, tales como 10-13, 12-15 o cualquier otro agrupamiento elegido de modo que no interfiera con la calidad del video transmitido.

La estructura de trama ilustrada 200 incluye un primer byte 204 incluyendo los bits 15-8, y un segundo byte de comando 206 transmitido sobre la línea 11. La línea 12 incluye los bytes de comando tercero 208 y un cuarto 210, y la línea 13 incluye los bytes de comando quinto 212 y sexto 214. El séptimo byte de comando 216 se transmite sobre la línea 14 junto con el byte de suma de Comprobación 218.

El primer byte 204 sobre la línea 11 puede incluir un indicador del Tipo de Mensaje 220 y un indicador de Paquetes Restantes 222. El indicador del Tipo de Mensaje 220 puede usarse para transmitir información a la cámara/bóveda de video indicando el tipo de comando que está transmitiendo. La Tabla 1 a continuación ilustra los comandos por Tipo de Mensaje de ejemplo junto con los valores binarios asociados de ejemplo para los bits en la sección del Tipo de Mensaje 220, es decir los bits 15-12.

TABLA 1

Tipo de Mensaje

Binario

Comando de Movimiento de Cámara

0010

Respuesta al Comando de Movimiento de Cámara

0011

Comando de Fijación de Fecha y Hora

0100

Respuesta al Comando de Fijación de Fecha y hora

0101

Petición de Obtención de Información de Configuración de Bóveda

0110

Respuesta de Información de Configuración de Bóveda

0111

Los especialistas en la técnica reconocerán que el controlador y la cámara/bóveda de video pueden configurarse para comunicar una diversidad de tipos de mensajes dependiendo de la funcionalidad del sistema. La sección del Tipo de Mensaje de cuatro bits deja espacio para tipos de mensajes adicionales asociados con patrones de bits particulares.

El indicador de Paquetes Restantes 222, es decir los bits 11-8 en el primer byte 204 pueden incluir un número binario indicando el número de paquetes de 8 bytes posteriores en el comando o respuesta actual. Esta información puede usarse por la cámara/bóveda para determinar el número de paquetes a recibir. Del segundo 206 hasta el séptimo byte 216 en un comando puede incluir datos de comando para causar que la cámara/bóveda realice el comando específico, o en el caso de respuesta, datos específicos indicando que el comando se recibió totalmente, indicando el estado de alarma, y/o indicando la información de configuración de la cámara/bóveda. El byte de Suma de Comprobación 218 puede formarse en una diversidad de formas conocidas por los especialistas en la técnica, por ejemplo el CRC o simplemente realizando la suma binaria de los primeros siete bytes.

La FIG. 3 ilustra un comando de movimiento de la cámara de ejemplo 300 formateado en el modo ilustrado en la FIG. 2. El comando del movimiento de la cámara ilustrado puede transmitirse para proporcionar el control total de la cámara, por ejemplo el control para todos los ejes del movimiento en una cámara de tipo de bóveda, en un paquete de 8 bytes. El control proporcional de desplazamiento y de inclinación se incorporan con controles de sólo velocidad

o velocidad de rampa, controles para zoom, enfoque, e iris y cualesquiera otras características especiales de la cámara seleccionadas por el operador.

En la línea 11 del comando ilustrado en la FIG. 3, un indicador del tipo de mensaje 220a conteniendo 0010 indica que el comando es un comando de movimiento de la cámara, y los bits de Paquetes Restantes indican que el comando no incluye ningún paquete restante. Los bits de 0-5 sobre la línea 11 indican las funciones de la cámara de control de Enfoque hacia cerca, Enfoque hacia lejos, Zoom de Aumento, Zoom de Disminución, Iris Abierto, e Iris Cerrado, respectivamente. El establecimiento de estos bits a uno puede hacer que comience el movimiento de la Cámara en la función asociada. Los bits 6 y 7 sobre la línea 11 pueden estar reservados para expansión.

En la línea 12 los bytes del tercer y cuarto comando incluyen los datos de control de inclinación y desplazamiento. El bit 15 sobre la línea 12 indica la dirección de inclinación, con un uno en esta localización indicando una inclinación hacia arriba y un cero indicando una inclinación hacia abajo. La velocidad de inclinación se indica en los bits 14-8 del tercer byte. El bit 7 sobre la línea 12 indica la dirección de desplazamiento, indicando un uno en esta localización un desplazamiento hacia la izquierda e indicando un cero un desplazamiento a la derecha. La velocidad de desplazamiento se indica en los bits 6-0 del cuarto byte.

La línea 13 incluye datos de Control de Raíl en el quinto byte 212a y datos de la Función de Bóveda Especial en el sexto byte 214a. Los datos de la Función de Bóveda Especial en el sexto byte pueden iniciar una función de bóveda especial en conexión con el comando transmitido. Los especialistas en la técnica reconocerán que la cámara/bóveda de video puede configurarse para realizar una diversidad de funciones de Bóveda Especiales incluyendo: reinicio de la bóveda, salida y entrada en el menú de la bóveda, vuelta (desplazamiento de 180 grados), continuar con auto iris y auto enfoque, correr la función de auto modelado (descrita más adelante), comenzar el patrón de piel de manzana, correr un patrón predefinido, etc.

La línea 14 incluye Datos Auxiliares en el byte séptimo 216a y una Suma de Comprobación 218a. Los Datos Auxiliares pueden contener un operando asociado con una Función Especial de Bóveda indicada en el byte sexto. Por ejemplo, un comando de reinicio de bóveda indicado en el byte sexto puede requerir una secuencia de bits particular en el campo de Datos Auxiliares para impedir la ocurrencia inadvertida de un comando de reinicio.

La FIG. 4 ilustra una respuesta de ejemplo a un comando del movimiento de cámara. La respuesta al comando de movimiento de la cámara ilustrada puede transmitirse desde la cámara en respuesta, por ejemplo, al comando de movimiento de la cámara ilustrado en la FIG. 3. En general, una señal de respuesta tiene el mismo formato que una señal de comando, pero en esta realización de ejemplo se transmite sobre las líneas horizontales 16-19 durante el mismo periodo de blanqueo vertical que el comando. En la realización de ejemplo ilustrada, no se transmite ningún dato de comando o respuesta sobre la línea 15 para acomodar los retardos de transmisión cuando se transmite por encima de 16 millas (25,75 km), por ejemplo sobre enlaces de fibra. Los especialistas en la técnica, sin embargo, reconocerán que los datos pueden transmitirse sin saltarse ninguna línea, si los retardos de transmisión del sistema no son significativos.

Como en el formado de la señal de comando, el formato de la señal de respuesta 400 incluye dos bytes transmitidos sobre cada línea con el Tipo de Mensaje 220b y los datos de Paquetes Restantes 222b en el primer byte (sobre la línea 16 para una respuesta), y una suma de Comprobación 218b en el byte octavo (línea 19). Los bytes del segundo al séptimo incluyen datos particulares para la respuesta transmitida y pueden usarse para indicar una entrada de alarma actual y la información de estado de la cámara/bóveda eliminando por lo tanto la necesidad de un comando de interrogación, dedicado, periódico en búsqueda de alarmas o información de estado de la bóveda. La eliminación de los comandos separados de interrogación normalmente requeridos para mantener el estado de la bóveda actual reduce adicionalmente la latencia de los comandos de control, mejorando la facilidad de control del sistema. En la respuesta de ejemplo ilustrada, la línea 16 incluye un Tipo de Mensaje 220b que contiene 0011 indicando que la respuesta es una respuesta a un comando de movimiento, y los bits de Paquetes Restantes 222b indican que la respuesta no incluye ningún paquete restante. Los bits 7-4 sobre la línea 16 indican el número de paquetes restante desde el último comando, y el bit 3 está reservado. El bit 2 es un bit PR indicando cuándo hay un patrón corriendo. El bit PR puede ser un uno cuando se está procesado o corriendo un comando de patrón, y cero cuando se termina el patrón. El bit 1 es un bit de confirmación positiva ACK indicando que el paquete se recibió con una suma de comprobación correcta durante el intervalo vertical actual, y un bit 0 puede ser un bit de confirmación negativa NACK indicando que el paquete se recibió con una suma de comprobación incorrecta durante el intervalo vertical actual.

La línea 17 incluye datos del estado de Entrada de Alarma en los bits 15-12 y el Complemento de los Estados de Entrada de Alarma sobre los bits 11-8, que proporcionan redundancia de alarma, impidiendo falsas alarmas. El byte cuarto 210b sobre la línea 17 y el quinto 212b y sexto 214 sobre la línea 18 están reservados. El byte séptimo 216b sobre la línea 19 incluye una suma de comprobación del último comando recibido, y el octavo byte es la Suma de Comprobación 218b del paquete de respuesta.

Como todos los comandos de control de movimiento se proporcionan en un simple comando de movimiento de la cámara, si no se recibe ningún comando por la cámara dentro de un periodo de tiempo predefinido, la cámara puede programarse para parar todo movimiento. Por ejemplo, en una realización si no se recibe ningún comando dentro de aproximadamente 300 ms, la cámara puede configurarse para parar todo movimiento. Esto elimina la posibilidad de que la cámara ejecute continuamente un comando recibido cuando la comunicación se ha interrumpido, y elimina la necesidad de enviar comandos de parada separados desde el controlador para detener el movimiento de la cámara.

Los especialistas en la técnica reconocerán que las señales de comando y respuesta pueden formatearse en una diversidad de formas para comunicar los comandos y las respuestas disponibles o deseadas sobre un sistema particular. En general, proporcionando 8 bytes de datos para un comando y 8 bytes de datos para una respuesta en el mimo campo vertical obtiene ventajosamente una tasa efectiva de bits en ambas direcciones de 3840 bps (4x16x60) para un sistema NTSC (60 Hz) y 3200 bps (4x16x50) para sistemas PAL (50 Hz). Esto proporciona una mejora significativa en el tiempo de respuesta de los comandos y en la latencia en comparación con las soluciones UTC convencionales dando como resultado una enorme ventaja en la facilidad de control de los dispositivos de video en tiempo real.

Los especialistas en la técnica reconocerán que un sistema y un método consistentes con la invención pueden implementarse por la programación apropiada del controlador y la cámara para transmitir y recibir las señales de comandos y respuestas en respuesta a la señal de video. Los datos pueden codificarse por la cámara y recibirse en una diversidad de formatos. La FIG. 5A ilustra un formado de codificación modulado por ancho de pulso, así como por los esquemas de codificación Bi-Fase-Marca, Bi-Fase-Espacio, y Mánchester. Los datos codificados en la FIG. 5A, por ejemplo corresponden a la secuencia de bits 01001110010110. Como se muestra, los datos modulados por ancho de pulso incluyen bits que tienen un valor representado por el ancho de pulso P. En contraste, los esquemas de codificación Bi-Fase-Marca, Bi-Fase-Espacio, y Mánchester codifican el valor de bit por la presencia o ausencia de una transición durante un periodo de bit, por ejemplo T1, T2, T3.

Ventajosamente, los datos codificados con codificación Bi-Fase-Espacio (FM 0), Bi-Fase-Marca (FM 1), Mánchester

o similar, permiten que los anchos de pulso se reduzcan a 2/3 en comparación con los esquemas de codificación de ancho de pulso simples, mientras que se mantiene la misma altura mínima y los mismos anchos de pulso bajos. La reducción de los anchos de pulso usando estos formatos de codificación de datos reduce el periodo de una palabra codificada de 16 bits desde 48 µs a 32 µs. Esto permite que la longitud de cable 18 aumente significativamente. Por ejemplo, si la tasa de propagación en el medio elegido es de 1,55 ns por pie (5,09 ns por metro), el uso de la codificación FM0 permitiría una longitud de 10,322 pies (3,15 metros) de cable extra sin causar interferencias con el siguiente pulso de sincronismo horizontal. Se observará que protocolos tales como FM0 y Bi-Fase tienen ventaja sobre los esquemas de codificación Mánchester, en que el borde delantero del primer pulso puede definirse como el borde delantero de la primera celda de bit y el primer bit puede ser de cualquier polaridad.

El controlador puede configurarse para transmitir una señal de comando, por ejemplo sobre el cable 18, durante un periodo de blanqueo de la señal de video. La señal de comando puede incluir cuatro palabras de dieciséis bits, como se ha descrito anteriormente, siguiendo el pulso de sincronismo horizontal sobre las líneas 11-14. La cámara puede configurarse para transmitir una respuesta a la señal de comando en las cuatro palabras de 16 bits que siguen al pulso de sincronismo horizontal sobre las líneas 16-19 durante el mismo periodo de blanqueo vertical que el comando.

En una realización de ejemplo, como se muestra en la FIG. 5B, los datos pueden estar codificadas en FM0/Bi-Fase Espacio con un periodo P de 2 µs por bit, y con un frente delantero 500 del primer bit 502 que es un frente de subida que se produce 9,7 µs desde el borde delantero 504 del pulso de sincronismo horizontal 506, más o menos 50 ns. En el esquema de codificación FM0 o Bi-Fase Espacio, la polaridad de los bits de datos puede codificarse por la presencia o ausencia de una transición en el medio del tiempo de bit, con un "1" indicado por la ausencia de una transición y un "0" indicado por una transición en el centro del tiempo de bit. Los datos FM0 en la FIG. 5B, por ejemplo, corresponden a un patrón de comando que comienza con una secuencia 110011. Para comandos o respuestas, el estado alto de FM0 puede estar 0,714V por encima del nivel de blanqueo. El voltaje específico utilizado en las respuestas debería ser suficientemente más bajo que un nivel de blanco de video de modo que no se afecten adversamente los circuitos de ACG en monitores comunes. La señal de comando o respuesta pueden permanecer en el nivel de blanqueo o volver al nivel de blanqueo en el extremo del último bit sobre cada una de las líneas horizontales.

En tal realización, los datos transmitidos desde la cámara o el controlador pueden estar dentro de más o menos 50 ns de la temporización de bit de modo que cada uno de los bits puede usarse para sincronización. Con esta tolerancia, la tolerancia acumulativa sobre la longitud de una palabra de 16 bits sería de un máximo de 800 ns desde el primer pulso 502 al final del último pulso. Por ejemplo, una transición detectada en el interior de una ventana de 0,5 µs a 1,5 µs medidos a partir de la transición del borde delantero de una celda de bit puede interpretarse como un cero. Fuera de esta ventana en el centro de un tiempo de bit, una transición puede interpretarse como la transición de comienzo del siguiente bit. Los detectores de ambos extremos de la cámara y del controlador pueden comenzar buscando el borde delantero del primer impulso aproximadamente 8,5 µs después del borde delantero, por ejemplo 504, del pulso de sincronismo horizontal, y continuar buscando el primer borde hasta aproximadamente 31,5 µs después del borde delantero. Esto permite un retardo de propagación máximo debido a la longitud de línea sin corromper el último pulso con el siguiente pulso de sincronismo horizontal.

La FIG. 6 es un diagrama de flujo de bloques de un método 600 consistente con una realización de ejemplo de la invención. Los diagramas de flujo de bloques usados en este documento para describir las diversas realizaciones incluyen secuencias particulares de las etapas. Puede apreciarse, sin embargo que la secuencia de etapas meramente proporciona un ejemplo de cómo puede implementarse la funcionalidad general descrita en este documento. Además, cada una de las secuencias de pasos no tienen que ejecutarse en el orden presentado salvo que se indique lo contrario.

En la realización ilustrada, la comunicación de datos bidireccional en un sistema de video se puede realzar de un modo consistente con la invención esperando el periodo de blanqueo vertical 602 de una señal de video transmitida sobre un medio de transmisión, por ejemplo como se indica por el pulso de sincronismo vertical. Durante el periodo de blanqueo vertical puede transmitirse un comando 604 a la cámara/bóveda sobre el medio de transmisión. El comando puede recibirse 606 en la cámara/bóveda, y la cámara puede transmitir una respuesta 608 sobre el medio de transmisión durante el periodo de blanqueo vertical en el que se transmitió el comando. Una señal de comando de 8 bytes puede transmitirse desde el controlador a la cámara, por ejemplo, como cuatro palabras de dieciséis bits sobre cada una de las líneas horizontales 11-14 durante el periodo de blanqueo vertical. En respuesta a la señal de comando, puede transmitirse una señal de respuesta de 8 bytes desde la cámara al controlador. Para acomodar el retardo de línea, la respuesta puede retardarse en una o más líneas horizontales. Por ejemplo, la respuesta puede transmitirse como cuatro palabras de dieciséis bits sobre cada una de las líneas horizontales 16-19.

Un sistema consistente con la invención, por ejemplo 100, puede estar configurado también para facilitar la descarga de grandes bloques de datos a la cámara de video desde un controlador a una tasa de datos elevada. La descarga de datos a la cámara/bóveda de video se requiere a menudo en los sistemas de video para acomodar actualizaciones de firmware, por ejemplo actualizaciones al firmware de la cámara/bóveda de video para facilitar nuevas funcionalidades. Las soluciones convencionales para la descarga de tales datos han seguido los enfoques tradicionales para la transmisión de datos de comandos y/o respuestas, es decir los datos se han transmitido usando el protocolo de señales de comandos UTC independientemente de su tamaño o propósito. Para descargar largos bloques de datos, sin embargo, los protocolos de UTC convencionales, por ejemplo usando comandos UTC de 4 bytes en cada uno de los periodos de blanqueo vertical, no han proporcionado una tasa de datos elevada.

Por supuesto, si la tasa de datos no es una seria preocupación en un sistema particular, los datos podrían transferirse reemplazando las señales de comandos y/o respuestas consistentes con la invención con datos. Esto permitiría al menos una mejora de la tasa de datos sobre los métodos convencionales. Consistente con la presente invención, sin embargo, puede llevarse a cabo una tasa de datos muy alta cerrando al menos una parte de la señal de video y transmitiendo continuamente datos.

La FIG. 7 es un diagrama de flujo de bloques de una realización de ejemplo de un método 700 de descarga de datos a una cámara/bóveda de video consistente con la invención. Como se muestra, los grandes bloques de datos pueden descargarse desde un controlador a una cámara/bóveda de video desactivando 702 al menos una porción de la señal de video desde la cámara de video durante al menos un campo vertical hasta que la comunicación bidireccional está completa. La señal de video que se ha desactivado puede reemplazarse a continuación con datos descargados 704 desde el controlador a la cámara sobre el mismo medio de transmisión normalmente utilizado para la señal de video. Una vez que la descarga está completa, la señal de video desde la cámara puede restablecerse

706.

En una realización, para mantener la sincronización de video durante la descarga sólo puede desactivarse la señal de video activa, es decir, la señal de video entera excepto los pulsos de sincronismo horizontal y vertical, durante el campo vertical. Para desactivar el video activo, la cámara puede reemplazar el video activo con un nivel de negro estable en respuesta a un comando desde el controlador indicando que se van a descargar los datos. El controlador puede entonces reemplazar la señal de video activo con datos, por ejemplo palabras de 16 bits, transmitidas sobre cada una de las líneas de video activas en el campo. En un sistema entrelazado NTSC, esto permitiría la transmisión de datos sobre cada una de las 247 líneas activas de video en cada uno de los campos verticales. La tasa de datos resultante para un sistema NTSC o PAL sería aproximadamente de 237 Kbps (NTSC: 247 líneas/campo x 16 bits/línea x 60 campos/segundo o PAL: 297 x 16 x 50). Aunque este enfoque proporciona una mejora significativa en comparación con los métodos actuales de descarga en un entorno UTC, los pulsos de comunicación insertados en todo el video activo pueden hacer el video inutilizable para el funcionamiento normal. Por consiguiente puede ser preferible desactivar completamente la señal de video durante la descarga.

La señal de video puede desactivarse completamente si no se requiere la sincronización de video normal o se implementa otro método de sincronización subrogado. Cuando la señal de video está completamente desactivada, la cámara podría configurarse para usar el medio de transmisión de video, como un medio de comunicaciones de datos dedicado, punto a punto, bidireccional, por ejemplo por la configuración apropiada de una UART normalizada, controladores SCC, etc. en el controlador y la cámara. Este enfoque permite transferencias de datos de velocidad muy alta de grandes paquetes de datos, limitados sólo por la tecnología de comunicaciones de datos utilizada.

Un sistema de video consistente con la invención también puede configurarse para proporcionar un auto-modelado de comandos de función especial de la cámara/bóveda, por el que pueden añadirse funciones de control y ayuda en línea para futuras cámaras/bóvedas sin actualización de los controladores del sistema. Se entenderá que el auto-modelado como se describe en este documento puede implementarse independientemente del método de comunicación entre el equipo de control y el equipo de cámara. El método de auto-modelado puede implementarse en sistemas con cables de control y de video separados, y/o en sistemas basados en comunicaciones de Frecuencia de Radio y de Infrarrojos.

La FIG. 8 es un diagrama de flujo de bloques de una realización de ejemplo de un método 800 para realizar el auto-modelado de funciones especiales de bóveda consistentes con la invención. Como se muestra, el auto-modelado puede realizarse enviando 802 un comando de función de bóveda especial desde el controlador a la cámara por ejemplo incluyendo una secuencia de bits apropiada en el sexto byte 214a del formato de la señal de comandos 300, ilustrado en la FIG. 3. La cámara puede configurarse para recibir 804 y responder 806 a un comando de función de bóveda especial enviando una respuesta que causa que el controlador represente un menú de las funciones de la cámara. El operario puede seleccionar una de las funciones representadas sobre el controlador, activar un comando 808 a enviar a la cámara para causar que la cámara realice la función especial correspondiente. Las cámaras programadas para soportar el auto-modelado consistente con la invención pueden descargar información de ayuda de la nueva función especial a los controladores sobre la base de que sea necesario, eliminando completamente por lo tanto la necesidad de actualizar los controladores a medida que nuevas funciones se hacen disponibles sobre los nuevos sistemas de cámaras/bóveda.

En una realización de ejemplo, un controlador 12a consistente con la invención puede incluir una interfaz que tiene un control de interfaz de usuario, tal como un botón de Función de Bóveda 904, y un teclado numérico 902, como se muestra por ejemplo en la FIG. 9. Activando el control de la interfaz de usuario, por ejemplo pulsando el botón de la Función de Bóveda, sin una entrada numérica anterior sobre el teclado 902 puede causar que se envíe el comando de auto-modelado a la cámara/bóveda activando la bóveda para representar una lista de menú numerado de funciones de control de bóveda especiales disponibles, (tales como inversión, bascular el filtro de corte activo/desactivo, reinicio, auto enfoque/iris, entrar el modo de establecimiento de bóveda, bascular el modo de ancho del rango dinámico, y etc.). Esto permite que los controladores que no estén equipados con una pantalla de representación de ayuda faciliten comandos de funciones especiales. Los textos más grandes sobre la pantalla cubren las capacidades disponibles en la mayoría de las bóvedas y algunas cámaras pueden tener un modo más amistoso para el usuario de representación de la información de ayuda de la función especial, incluso si la pantalla está disponible en el controlador. En casos donde no está disponible una pantalla en el controlador, la lista de comandos disponibles puede representarse sobre otro dispositivo, por ejemplo por una impresión desde una impresora conectada con el sistema.

Cada uno de los elementos de la lista del menú puede representarse con un valor numérico asociado, por ejemplo 1

255. Introduciendo un valor numérico sobre el teclado 902 asociado con una función listada específica, seguido por la pulsación del botón de la Función de Bóveda 904, puede activar el controlador para enviar el comando de función especial y el número introducido a la bóveda. Cuando la bóveda recibe el comando de función de bóveda especial con un número válido realiza la función seleccionada, sin tener en cuenta si el menú se representó anteriormente. Si se representó el menú, la bóveda puede borrar el menú de la pantalla del controlador en respuesta al comando. Cuando la función está completa, la bóveda puede reanudar el funcionamiento normal. Presionando el botón de Función de Bóveda 904 mientras que se está representando el menú, sin una entrada numérica, puede borrar el menú de la pantalla y reanudar el funcionamiento normal. Los especialistas en la técnica reconocerán que un control de la interfaz de usuario tal como el botón de la Función de Bóveda 904 puede tener una diversidad de formas, por ejemplo un botón sobre la pantalla en una interfaz gráfica de usuario o una tecla hardware sobre un controlador de teclado convencional para permitir el funcionamiento con cualquier tipo de interfaz de controlador. Para controladores con una pantalla de texto local 906 sobre la interfaz de usuario, puede recuperarse el menú numérico desde la bóveda para la representación local sobre el controlador usando comunicaciones de datos de dos direcciones. Las etiquetas de los botones de las funciones de bóveda revisados pueden entonces representarse continuamente en el controlador 12a eliminando la necesidad de recoger el menú de función especial sobre la pantalla de video.

Los menús de bóveda sobre la pantalla pueden configurarse también para permitir la recolocación de los valores numéricos por defecto asociados con las funciones especiales disponibles. Esto permite nuevas funciones a implementar sin necesidad de usar teclas de función crípticas o combinaciones de múltiples teclas para obtener nuevos y necesarios códigos de control. Como las funciones pueden seleccionarse sin que el menú de funciones se represente primero, permitirá a los usuarios seleccionar las funciones más rápidamente una vez que se conocen el número apropiado.

Se apreciará que la funcionalidad descrita para las realizaciones de la invención pueden implementarse en la cámara/bóveda de video o en otros componentes del sistema de video usando hardware, software, o una combinación de hardware y software, y las técnicas de procesamiento de señal bien conocidas . Si se implementa en software, se requieren un procesador y un medio legible por la máquina. El procesador puede ser cualquier tipo de procesador capaz de proporcionar la velocidad y funcionalidad requeridas por las realizaciones de la invención. Por ejemplo, el procesador podría ser un proceso de la familia de Pentium TM de procesadores fabricados por Intel Corporation, o la familia de procesadores fabricada por Motorola. Los medios legibles por la máquina incluyen cualquier medio capaz de almacenar instrucciones adaptadas para ser ejecutadas por un procesador. Algunos ejemplos de tales medios incluyen, pero sin limitarse a estos, memoria de sólo lectura (ROM), memoria de acceso aleatorio (RAM), ROM programable (PROM), ROM programable que se puede borrar (EPROM), ROM programable que se puede borrar electrónicamente (EEPROM), RAM dinámica (DRAM), disco magnético (por ejemplo un disco flexible y un disco duro), disco óptico (por ejemplo CD-ROM), y cualquier otro dispositivo que pueda almacenar información digital. En una realización, las instrucciones se almacenan sobre el medio en un formato comprimido y/o cifrado.

Como se usa en este documento, la frase "adaptado para ejecutarse en un ordenador" significa que abarca instrucciones almacenadas en un formato comprimido y/o cifrado, así como instrucciones que tienen que compilarse

o instalarse por un instalador antes de ejecutarse por el procesador. Además el procesador y el medio legible por la máquina puede ser parte de un sistema mayor que puede contener diversas combinaciones de dispositivos de almacenamiento legibles por una máquina a través de diversos controladores de I/O, que son accesibles por el procesador y que son capaces de almacenar una combinación de instrucciones del programa de ordenador y datos.

Se proporciona de este modo un sistema y un método por el que un comando de la cámara de video que proporciona el control total de la cámara sobre un medio de transmisión de la señal de video a una cámara/bóveda de video durante un periodo de blanqueo vertical de una señal de video. Se proporciona una respuesta por la cámara/bóveda durante el mismo periodo de blanqueo vertical en el cual se transmitió el comando. Esto mejora significativamente el tiempo de respuesta de los comandos, reduce la latencia de las alarmas y reduce las cabeceras de comunicaciones del sistema en comparación con las soluciones UTC anteriores, mejorando por lo tanto drásticamente la facilidad de control en tiempo real de los dispositivos de video del tipo de cámara/bóveda. Un sistema y método consistente con la invención puede también implementar un esquema de codificación con ancho de pulso reducido en comparación con los enfoques convencionales, facilitando por lo tanto una extensión significativa de la longitud útil del medio de transmisión usado para el control bidireccional y para transmitir una señal de video.

De acuerdo con otro aspecto de la invención, un sistema de video puede configurarse para permitir la descarga de grandes bloques de datos a una tasa de datos muy alta desactivando al menos una porción de la señal de video y transmitiendo datos continuamente. Esto mejora significativamente la eficacia de descarga de largas actualizaciones de firmware a las cámaras/bóvedas de video. También un sistema consistente con la invención puede configurarse para proporcionar una función de auto-modelado, por la que las nuevas funciones de la cámara/bóveda de video pueden implementarse sin requerir el uso de teclas de funciones crípticas o combinaciones de múltiples teclas para obtener nuevos códigos necesarios de control.

Las realizaciones que se han descrito en este documento son, sin embargo, algunas de las varias que usan la presente invención y se muestran en este punto a modo de ilustración y no de limitación. Por ejemplo, se han descrito en este documento formatos de comandos y respuestas incluyendo comandos de 8 bytes y respuestas de 8 bytes. Sin embargo, comandos y/o respuestas que incluyen un número diferente de bytes o de diferente formato pueden transmitirse durante un periodo de blanqueo vertical único en un modo consistente con la invención. Además, diversas características y ventajas descritas en este documento pueden combinarse o usarse separadamente.

Claims (14)

1. REIVINDICACIONES

   1. Un procedimiento para el control y realización de auto-modelado de una cámara de vigilancia, controlable (14) configurada para proporcionar una señal de video sobre un medio de transmisión, comprendiendo el procedimiento,

   -conectar una nueva cámara de vigilancia de video (14) a un sistema de vigilancia existente, que comprende un controlador (12a); -transmitir un comando de auto-modelado (802) para la realización del auto-modelado desde una fuente de comandos integrada (12) en dicho controlador (12a) a dicha cámara de vigilancia controlable (14) sobre el medio de transmisión (18); -transmitir datos de respuesta (806) a dicha fuente de comandos (12) en dicho controlador (12a), siendo dichos datos de respuesta en contestación a dicho comando de auto-modelado (802) y configurándose para causar una representación de una pluralidad de información de ayuda disponible o funciones de la cámara para dicha cámara de vigilancia controlable (14); -transmitir un comando de comienzo de función (808) a dicha cámara de vigilancia controlable (14) en respuesta a dichos datos de respuesta (806), estando configurado dicho comando de comienzo de función

   (808) para causar que dicha cámara de vigilancia controlable (14) realice al menos una de dicha pluralidad de información disponible o funciones de cámara, en el que -dicho comando de respuesta (806) está configurado para causar que la fuente de comandos (12) represente un valor numérico asociado con cada una de dichas funciones disponibles para dicha cámara de vigilancia controlable (14) y -en el que dicha cámara de vigilancia (14) descarga nueva información de ayuda al controlador (12a) y actualiza dicho controlador (12a) de acuerdo con la nueva cámara de vigilancia instalada (14).

2. 2.

   Un procedimiento de acuerdo con la reivindicación 1, en el que dicho comando de auto-modelado se transmite desde dicha cámara de vigilancia controlable (14) en respuesta a la activación de al menos un control de la interfaz de usuario sobre dicha fuente de comandos (12).

3. 3.

   Un procedimiento de acuerdo con la reivindicación 2, en el que dicho control de la interfaz de usuario comprende un botón sobre una interfaz de usuario de dicha fuente de comandos.

4. 4.

   Un procedimiento de acuerdo con la reivindicación 3, en el que dicho comando de comienzo de función (808) comprende datos que representan uno de dichos valores numéricos asociados con dicha al menos una de dicha pluralidad de información de ayuda disponible o funciones de la cámara.

5. 5.

   Un procedimiento de acuerdo con la reivindicación 1, en el que al menos dicho comando de auto-modelado (802) y dichos datos de respuesta se transmiten durante un único periodo de blanqueo vertical de dicha señal de video.

6. 6.

   Un procedimiento de acuerdo con la reivindicación 5, en el que dicho comando de auto-modelado y dichos datos de respuesta (806) se transmiten cada uno en porciones separadas, transmitiéndose cada una de dichas porciones separadas sobre la línea horizontal asociada de una pluralidad de líneas horizontales en dicho periodo de blanqueo vertical.

7. 7.

   Un procedimiento de acuerdo con una de las reivindicaciones anteriores, en el que cada una de dichas porciones separadas comprende 16 bits.

8. 8.

   Un procedimiento de acuerdo con la reivindicación 7, en el que cada uno de dichos 16 bits se codifica en un periodo de bit, estando representado un primer valor lógico de cada uno de dichos bits por la presencia de una transición durante dicho periodo de bit y estando representado un segundo valor lógico de cada uno de dichos bits por la ausencia de una transición durante dicho periodo de bit.

9. 9.

   Un sistema de vigilancia de video que comprende:

   un dispositivo de video controlable en la forma de una cámara de vigilancia (14) configurada para transmitir una señal de video sobre un medio de transmisión (18); y una fuente de comandos (12) que incluye un control de la interfaz de usuario para causar los datos de un comando de auto-modelado (802) a transmitir a dicha cámara de vigilancia controlable (14) sobre el medio de transmisión (18). estando configurada dicha cámara de vigilancia controlable (14) para transmitir datos de respuesta (806) a dicha fuente de comandos (12) en respuesta a dichos datos de comando de auto-modelado (802), estando configurados dichos datos de respuesta (806) para causar la representación de una pluralidad de información de ayuda disponible o funciones de cámara para dicha cámara de vigilancia controlable (14), en el que dicho comando de respuesta (806) está configurado para causar que dicha fuente de comandos (12) represente un valor numérico asociado con cada una de dichas funciones disponibles para dicha cámara de vigilancia controlable (14) y actualizar dicha fuente de comandos a nuevas funciones de la cámara conectada.

10. 10.

    Un sistema de acuerdo con la reivindicación 10, en el que dicha fuente de comandos (12) está configurada para transmitir un comando de comienzo de función (808) a dicha cámara de vigilancia controlable (14) en respuesta a dichos datos de respuesta (806), estando configurado dicho comando de comienzo de función (808) para causar que dicha cámara de vigilancia controlable (14) realice al menos una de dicha pluralidad de funciones disponibles.

    5 11. Un sistema de acuerdo con la reivindicación 10, en el que dicho control de la interfaz de usuario comprende un botón (904) sobre una interfaz de usuario de dicha fuente de comandos (12).
11. 12. Un sistema de acuerdo con la reivindicación 9, en el que dicho comando de comienzo de función (808) comprende datos que representan uno de dichos valores numéricos asociados con dicha al menos una función de dicha pluralidad de funciones disponibles.

    10 13. Un sistema de acuerdo con la reivindicación 9, en el que dicha fuente de comandos (12) y dicha cámara de vigilancia controlable (14) se configuran para transmitir dicho comando de auto-modelado (802) y dichos datos de respuesta (806) respectivamente, durante un único periodo de blanqueo vertical de dicha señal de video.
12. 14. Un sistema de acuerdo con la reivindicación 13, en el que dicha fuente de comandos (12) y dicha cámara de vigilancia controlable (14) están configuradas para transmitir dicho comando de auto-modelado (802) y dichos datos

    15 de respuesta (806) en porciones separadas, transmitiéndose cada una de dichas porciones separadas sobre la línea horizontal asociada de una pluralidad de líneas horizontales en dicho periodo de blanqueo vertical.

13. 15.

    Un sistema de acuerdo con la reivindicación 14 en el que cada una de dichas porciones separadas comprenden 16 bits.

14. 16.

    Un sistema de acuerdo con la reivindicación 15, en el que cada uno de dichos 16 bits está codificado en un

    20 periodo de bit, estando representado un primer valor lógico de cada uno de dichos bits por la presencia de una transición durante dicho periodo de bit y estando representado un segundo valor lógico de cada uno de dichos bits por la ausencia de transición durante dicho periodo de bit.