Mecatrónica
Controlo de Câmara de Vídeo Vigilância
Read this doc on Scribd: Controlo de Câmara de Vídeo Vigilância
Controlo de Câmara de Vídeo Vigilância rftg.development.googlepages.com Data de criação: 20 de Janeiro de 2008 Última Actualização: 29 de Abril de 2008 Versão: v0.06 – 29/ABR/2008 Autor: Ricardo Filipe Teixeira Gomes AVISO LEGAL Este documento foi elaborado por Ricardo Filipe Teixeira Gomes, a quem se reservam todos os direitos. © 2008 Ricardo Filipe Teixeira Gomes Este documento encontra-se disponível para consulta e utilização desde que sejam respeitados todos os direitos de autor e/ou propriedade intelectual. A cópia parcial ou integral, através de qualquer tipo de meio, dos textos e imagens disponíveis neste documento encontra-se expressamente proíbida a menos que o utilizador respeite os direitos de autoria e/ou propriedade intelectual, citando para isso convenientemente o documento, e incluindo imperterivelmente uma referência clara à página web do autor: “www.rftg.development.googlepages.com”. O material contido neste documento constitui apenas uma informação de carácter geral baseada em experiências pessoais e não pretende de forma alguma influenciar o leitor sobre qualquer matéria específica. O conteúdo deste documento é fornecido como uma comodidade para os leitores e é constituído apenas por informação não vinculativa. O conteúdo deste documento é fornecido “como está” e não se oferece qualquer garantia sobre o mesmo. O autor do documento declina qualquer responsabilidade em caso de prejuízos que possam ocorrer pelo facto de alguém se basear na informação contida neste documento, uma vez que essa informação é de carácter meramente informativo, não se prometendo ou garantindo que seja precisa, completa e actualizada. O mesmo se aplica ao conteúdo de qualquer referência realizado no mesmo. Quaisquer conflitos decorrentes do uso ou relacionados com este documento, ou respeitantes a direitos de autor e/ou propriedade intelectual sobre materiais que façam parte deste documento deverão ser regidos pela Legislação Portuguesa e sujeitos à jurisdição dos tribunais de Portugal. A leitura deste documento e sua utilização pressupõe a aceitação destas condições. © 2008 Ricardo Filipe Teixeira Gomes. rftg.development.googlepages.com CONTROLO DE CÂMARA DE VÍDEO-VIGILÂNCIA Ricardo Filipe Teixeira Gomes Departamento de Engenharia Electrotécnica Instituto Superior de Engenharia do Porto 2008 Este relatório satisfaz, parcialmente, os requisitos que constam da Ficha de Disciplina de Laboratório de Mecatrónica, do 2º ano, do Mestrado em Engenharia Electrotécnica e de Computadores Candidato: Ricardo Filipe Teixeira Gomes, Nº 1020405, rftg.development@gmail.com Orientação científica: Lino Manuel Baptista Figueiredo Empresa: Supervisão: Lino Manuel Baptista Figueiredo, lbf@isep.ipp.pt Departamento de Engenharia Electrotécnica Instituto Superior de Engenharia do Porto 29 de Abril de 2008 Resumo Este trabalho visa o desenvolvimento de uma Dynamic Link Library (DLL) e de uma Aplication Programming Interface (API) capazes de disponibilizar métodos de alto nível que possibilitem o comando/diagnóstico de uma câmara de vídeo-vigilância SONYTM IPELA SNC-RZ25. Adicionalmente, visa também o desenvolvimento de uma aplicação demonstrativa das potencialidades da DLL e da API. Esta mesma aplicação proporciona ainda uma base de partida para o desenvolviemnto de uma aplicação de vídeo-conferência multiintervenientes e multi-espaços, totalmente independente do fabricante do equipamento. É proposta ainda uma arquitectura de um sistema de vídeo-conferência distribuído, e realizadas algumas considerações sobre a sua implementação. Palavras-Chave vídeo-vigilância, câmaras IP, SONYTM IPELA SNC-RZ25, vídeo-conferência. i Índice RESUMO .......................................................................................................................................................... I ÍNDICE .......................................................................................................................................................... III ÍNDICE DE FIGURAS ...................................................................................................................................V ÍNDICE DE TABELAS .............................................................................................................................. VII ACRÓNIMOS................................................................................................................................................ IX 1. INTRODUÇÃO ...................................................................................................................................... 1 1.1. 1.2. 1.3. 1.4. 2. CONTEXTUALIZAÇÃO ....................................................................................................................... 1 OBJECTIVOS ...................................................................................................................................... 3 CALENDARIZAÇÃO ........................................................................................................................... 3 ORGANIZAÇÃO DO RELATÓRIO ......................................................................................................... 4 ABORDAGEM AO PROBLEMA......................................................................................................... 5 2.1. 2.2. 2.3. CONDICIONANTES ............................................................................................................................. 6 MOTIVAÇÃO ..................................................................................................................................... 6 ENQUADRAMENTO ............................................................................................................................ 7 3. ARQUITECTURA DO SISTEMA........................................................................................................ 9 3.1. 3.2. 3.3. A DLL ............................................................................................................................................ 10 A API – FULL_FOR_SNC_RZ25 .................................................................................................... 17 A APLICAÇÃO CON2MEC .............................................................................................................. 19 4. 5. FUTUROS DESENVOLVIMENTOS ................................................................................................. 23 CONCLUSÕES ..................................................................................................................................... 27 REFERÊNCIAS DOCUMENTAIS ............................................................................................................. 29 iii Índice de Figuras Figura 1 Figura 2 Figura 3 Figura 4 Figura 5 Figura 6 Figura 7 Figura 8 Figura 9 Figura 10 Figura 11 Figura 12 Figura 13 Arquitectura do software desenvolvido .......................................................................... 9 class System .................................................................................................................. 12 class Exclusive_camera_control .................................................................................. 13 class DayNight ............................................................................................................. 14 class PanTiltZoomFocus .............................................................................................. 15 class Camera_control_mode ........................................................................................ 15 class Camera ................................................................................................................ 16 class Other_operation .................................................................................................. 17 Aspecto geral da aplicação CON2MEC com o painel de setas activo ......................... 20 Painel de barras deslizantes da aplicação CON2MEC ................................................. 20 ToolStrip de adição de nova câmara............................................................................. 21 Caixa de diálogo para introdução de dados de nova câmara ........................................ 21 Arquitectura de um sistema distribuído de vídeo-conferência ..................................... 24 v Índice de Tabelas Tabela 1 Calendarização do projecto ............................................................................................ 4 vii Acrónimos API DLL IP WWW HTTP URL JPEG – Application Programming Interface – Dynamic Link Library – Internet Protocol – World Wide Web – HyperText Transfer Protocol – Uniform Resource Locator – Joint Photographic Experts Group MJPEG – Motion JPEG MPEG Moving Picture Experts Group ix 1. INTRODUÇÃO Com o aumento das capacidades de transmissão das redes de dados actuais, surgem todos os dias novas aplicações, e novas prespectivas de desenvolvimento de produtos baseados na Internet. Estes desenvolvimentos suscitaram o interesse do ramo da Vídeo-vigilância, resultando no aparecimento das câmaras de vídeo-vigilância sobre Internet Protocol (IP). Actualmente, este tipo de dispositivos, devido ao seu baixo custo, facilidade de interacção ou elevada tecnologia são utilizadas em diversos outros tipos de aplicações, nomeadamente em vídeo-conferência. 1.1. CONTEXTUALIZAÇÃO A generalidade das câmaras de vídeo-vigilância sobre IP disponibilizam a imagem captada com recurso a um computador embebido que corre um servidor web. Desta forma possibilitam a monitorização da imagem através um simples browser. Este é o método mais simples de acesso às imagens captadas [1]. O formato mais comum das imagens disponibilizadas por este tipo de equipamento é o Joint Photographic Experts Group (JPEG). Neste caso, a designação “transmissão de vídeo” não é seguramente a mais correcta, dado que apenas são transmitidas imagens, ou 1 frames, em formato JPEG de cada vez que o servidor recebe uma solicitação por parte do cliente (por meio de um browser ou aplicação que implemente o mesmo mecanismo) [1][2]. Grande parte dos equipamentos já disponibiliza também a transmissão em formato Motion JPEG (MJPEG). Neste caso é apenas necessário o envio de um comando HyperText Transfer Protocol (HTTP) para que a câmara forneça uma sequência de frames em formato JPEG, a uma cadência predefinida, ou seja streams que na prática compõe um vídeo. Dispositivos tecnologicamente mais evoluídos já disponibilizam as imagens adquiridas em formatos que potenciam uma elevada qualidade de vídeo, tais com o Moving Picture Experts Group – 2 (MPEG-2) e MPEG-4 [2]. Ao olho humano, apesar de cadências de frames até 16 frames por segundo (fps) causarem a sensação de descontinuiade de imagem (tipicamente “piscar” da imagem), cadências superiores a 10 fps são suficientes para criar um vídeo capaz de transmitir a sensação de movimento. Actualmente, considera-se que um vídeo a 24 fps possui qualidade cinematográfica. Por norma os fabricantes de câmaras de vídeo-vigilância sobre IP fornecem, juntamente com o equipamento, todo um conjunto de software. As características deste tipo de software varia consoante os fabricantes, gamas e modelos dos equipamentos. Todos os equipamentos permitem a monitorização das imagens recolhidas, sendo que, caso o equipamento o permita, o seu controlo/diagnóstico remoto bem como a transmissão de áudio uni-direccional ou bi-direccional, e até vídeo. Alguns pacotes de software, mais completos, possuem uma solução integrada que permite a gestão do acesso a uma ou mais câmaras (criação de contas de utilizadores, atribuição de permissões, ...), monitorização simultânea de imagens capturadas por diversas câmaras, gravação das imagens recolhidas em formato digital, detecção de movimento, seguimento de movimento, vídeo-conferência, e diversas outras funcionalidades. Apesar de diversos equipamentos permitirem o controlo/dignóstico através do servidor web integrado no equipamento, recorrendo a comandos HTTP GET e POST, os protocolos de comunicação entre as aplicações de controlo/diagnóstico e os equipamentos são maioritariamente proprietários e fechados (por questões de segurança e/ou comerciais). 2 Contudo, a SONYTM tem desenvolvido um protocolo proprietário aberto com o objectivo de normalizar o comando/diagnóstico de equipamentos de vídeo. Este designa-se por VISCATM (Video System Control Architecture). Porém pressupõe o recurso a uma ligação RS-232 para estabelecer conexões entre os dispositivos[3]. 1.2. OBJECTIVOS Tendo como base uma câmara de vídeo-vigilância SONYTM IPELA SNC-RZ25, os principais objectivos propostos para este projecto são: • Desenvolvimento de uma Dynamic Link Library (DLL) e de uma Application Program Interface (API), em linguagem C#, por forma a possibilitar um controlo/diagnóstico do equipamento recorrendo a métodos de alto-nível; • Providenciar toda a documentação de apoio à interacção com DLL e API desenvolvidas directamente na DLL e na API; • Assegurar a robustez e fiabilidade da DDL e API desenvolvidas através da implementação de técnicas de tratamento de erros e excepções; • Desenvolvimento de uma aplicação capaz de integrar a monitorização simultânea de diversas câmaras IP, assim como o controlo/diagnóstico da câmara de vídeo-vigilância usada no decurso projecto; • Demostrar e validar as potencialidades da DDL e da API desenvolvidas, por meio da sua utilização na aplicação de monitorização, controlo e diagnóstico; • Garantir a escalabilidade, modularidade e flexibilidade da DDL, API e aplicação desenvolvidas, por forma a potenciar futuros desenvolvimentos; • Optimizar o desempenho da aplicação com recurso a multi-threading. 1.3. CALENDARIZAÇÃO Por forma a cumprir com os objectivos propostos, foi idealizada a distribuição temporal das diversas tarefas ao longo do período de tempo disponível para a realização do projecto. A Tabela 1 apresenta a referida calendarização. 3 Tabela 1 Calendarização do projecto Actividade \ Semana lectiva Relatório projecto preliminar Relatório de protótipo funcional Entrega do relatório final Elaboração da apresentação Preparação de arguência Estudo protocolo VISCATM Teste comando básico Pan-Tilt-Zoom Estudo/interpretação do “CGI command manual” Desenvolvimento da biblioteca “Full_for_SNC-RZ25” e respectivo suporte Desenvolvimento da aplicação “CON2MEC” Teste e correcção de erros Teste Finais Elaboração do relatório final Novembro 4ª 5ª 6ª 7ª 8ª Dezembro 9ª 10ª Interrupção Natal 11ª Janeiro 12ª 13ª 1.4. ORGANIZAÇÃO DO RELATÓRIO No Capítulo 1 é realizada uma breve apresentação e contextualização do presente trabalho, traçados os principais objectivos inerentes à sua realização e apresentado o cronograma previsto para a realização das suas tarefas elementares. No capítulo seguinte, 2, é feita uma breve abordagem do problema, sendo referidas algumas condionantes, a motivação e o respectivo enquadramento do projecto. Ao longo do 3º capítulo é descrita a arquitectura do sistema, explicando a DLL, API e aplicação desenvolvida. Segue-se o 4º capítulo, onde são perspectivados futuros desenvolvimentos, sendo, numa breve nota final, referidos os prioritários. O 5º e último capítulo apresenta algumas das conclusões fruto da realização deste projecto. 4 2. ABORDAGEM AO PROBLEMA A generalidade dos equipamentos de vídeo-vigilância sobre IP possuem software capaz de providenciar monitorização de imagem, e controlo/diagnóstico do equipamento. Este pode correr na máquina cliente ou no próprio equipamento, sendo acessível através de um browser web ou uma aplicação dedicada. Não obstante as vantagens de uma aplicação desenvolvida por profissionais dedicados de um determinado fabricante, factores como a falta de flexibilidade/modulariade, e código fechado das aplicações, limitam o seu uso e condicionam eventuais soluções de integração com equipamentos de diferentes fabricantes e tecnologias. Soluções capazes deste tipo de integração não são de todo comuns. Relativamente ao equipamento usado no projecto (câmara de vídeo-vigilância SONYTM IPELA SNC-RZ25), refira-se que o mesmo possui um servidor integrado que implementa diversos comandos HTTP GET e POST, de certa forma passíveis de serem considerados como métodos de alto-nível. Porém remanescem na sua sintaxe e semântica características de acções de baixo nível, assim como não é possível a abstracção desejável relativamente ao meio de comunicação. 5 2.1. CONDICIONANTES Os fabricantes de equipamentos deste tipo providenciam já aplicações e pacotes de software extremamente completos, os quais permitem o controlo/diagnóstico e monitorização. Em particular, o equipamento que será utilizado para desenvolvimento do projecto, possui um pacote de software extremamente completo com todas as funcionalidades já enumeradas. Claramente não fará sentido o desenvolvimento de uma aplicação semelhante. Tipicamente cada fabricante possuiu um conjunto de comandos/protocolos de comunicação distintos, pelo que, no âmbito deste projecto, não é exequível uma abordagem generalista ao nível do comando/diagnóstico de equipamentos que não o disponível para a realização do mesmo. O recurso ao IP assume vantagens na prespectiva do controlo/diagnóstico remoto (virtualmente a partir de qualquer local com acesso à World Wide Web (WWW)) e elimina a necessidade de duas cablagens distintas para o mesmo equipamento (comando + transmissão de imagem). Contudo apresenta algumas fragilidades em termos de segurança e eventuais requisitos de tempo-real. Em oposição, através de ligação RS232 é possível garantir o controlo em tempo-real e superar fragilidades de segurança. Contudo, apesar de continuar a ser possível monitorizar imagens a partir de qualquer local, a distança entre o equipamento e a estação de controlo/diagnóstico remota reduz-se a uma distância extremamente limitada (limites da norma RS-232). 2.2. MOTIVAÇÃO Analisada a informação adquirida, e as condicionantes enunciadas, existe um potencial problema que carece de ser resolvido. O desenvolvimento de uma aplicação de monitorização de câmaras de vídeo-vigilância sobre IP assume por si só um carácter irrelevante, dado que existem já diversas aplicações disponíveis na WWW que cumprem este requisito de uma forma bastante satisfatória. Porém uma aplicação capaz de concentrar a monitorização de diversas câmaras de vídeo-vigilância sobre IP, assim como disponibilizar o comando/diagnóstico da câmara disponível para este projecto, pode suscitar interesse. 6 Conhecido o objectivo de, futuramente, integrar o equipamento em causa numa aplicação de vídeo-conferência, a prespectiva de desenvolver uma DLL e uma API robustas, modulares e flexíveis assume um carácter importante, tanto mais porque, aquando do estudo do estado da arte realizado não foi encontrada nenhuma solução similar. As potencialidades inerentes à programação orientada aos objectos, sobretudo quando se recorre à linguagem C#, assim como o crescente números de programadores neste tipo de linguagem e a facilidade de aprendizagem da mesma, motiva a que o desenvolvimento de todo o código seja realizado nesta linguagem. 2.3. ENQUADRAMENTO A solução descrita ao longo deste trabalho visa enquadrar-se no desenvolvimemto de uma aplicação de vídeo-conferência, que permita a troca de imagens entre múltiplos espaços físicos e múltiplos utilizadores em simultâneo. A aplicação desenvolvida preenche já alguns destes requisitos, nomeadamente no que se refere monitorização e gestão de câmaras visualizadas. A independência da DLL e da API face à aplicação, asseguram que alterações a qualquer um destes componentes não comprometem a solução encontarda, potenciando desenvolvimentos futuros. 7 3. ARQUITECTURA DO SISTEMA O projecto realizado possuiu o seu âmbito limitado unicamente ao desenvolviemnto de software. A arquitectura do sistema desenvolvido baseia-se em três componentes fundamentais, representáveis pelo esquema de camadas da Figura 1: Aplicação API DLL: Camera … … … PanTiltZoomFocus Figura 1 Arquitectura do software desenvolvido 9 3.1. A DLL Os comandos HTTP GET e POST, disponibilizados pelo servidor presente no equipamento, são por si já passíveis de serem considerados como métodos para interacção com um objecto (a câmara), proporcionando um grande nível de abstracção face às acções de baixo nível inerentes ao funcionamento interno do equipamento. Contudo, não existe qualquer tipo de tratamento de erros e/ou excepções do lado do cliente, assim como alguma semântica ao nível dos comandos permanece ainda numa lógica de baixo nível (por exemplo, as posições de Pan encontram-se em formato hexadecimal e não em formato de graus angulares). Adicionalmente, todo o retorno resultante de inquiries ao dispositivo é recebido na forma de uma string, composta pela concatenação de diversos parâmetros em simultâneo. A DLL desenvolvida visa, através da introdução de uma nova camada de software, abstrair o programador de todos estes detalhes. Desta forma, o acesso ao dispositivo é realizado a um nível mais alto, recorrendo a métodos de formato homogéneo, semântica clara/directa e sintaxe simplificada. O facto do tratamento de erros/excepções ser providenciado ao nível da DLL assegura, de forma totalmente transparente, uma efectiva contenção da propagação de erros/excepções directamente na camada mais baixa, evitando a propagação para a camada de aplicação. A DDL é composta por várias classes de objectos, sendo que, cada uma das classes, dispõe de um conjunto específico de métodos. A estrutura implementada tem como objectivo recriar a estrutura de comandos apresentada em [4]. Cada classe de objectos não é mais do que um grupo de comandos (System, Exclusive camera control, Date and time, ...), sendo que, cada um dos seus métodos, do tipo public, correspondem a cada um desses comandos (WelcomeText “”, AbsoluteZoom “”, ...). Com isto pretende-se, além de diminuir o tempo de aprendizagem/interpretação necessário, organizar de forma simples os diversos comandos. A interacção com o equipamento é bidireccional, i.e., sempre que se verifique, existe um método que permite afectar uma determinada característica do equipamento (por exemplo: private string AbsolutePan(short pan_angle, short speed)), e um método complementar que permite saber o estado de uma determinada característica. Estes últimos 10 iniciam-se sempre por “get_” (por exemplo: pan_angle, short speed)). private string get_AbsolutePan(short Apesar de não serem implementados todos os métodos de cada uma das classes de objectos, correspondentes a cada um dos comandos dos diversos grupos de comandos, todos se encontram definidos e estruturados. Desta forma é assegurado que futuros desenvolvimentos cumpram os requisitos básicos de integração sem alteração da estrutura definida. Atente-se nas descrições seguintes. 3.1.1. ASPECTOS COMUNS A TODAS AS CLASSES Todas as classes de objectos possuem um conjunto de métodos e variáveis idênticos, fundamentais à implementação da estrutura definada, sendo estes os seguintes: • internal string set_LoginCredentials (string new_username, string new_password) – método que permite a definição das credências de acesso ao equipamento com o qual se pretende interagir; o nível de acesso definido – internal – torna este método vísivel apenas até ao nível da classe onde foi declarado; • • internal string set_URL (string new_URL) – método que permite a definição do Uniform Resource Locator (URL) do equipamento com o qual se pretende interagir; private Request(string action) – método usado para realizar o WebRequest formulado; o nível de acesso definido – private – torna este método vísivel apenas dentro da classe onde é criado; note-se que apenas recebe como parâmetro de entrada “string • • • • • action”; private string URL – variável que reserva o URL; somente pode ser defina pelo método set_URL; private string command_URL – varíavel que reserva a componente estática do comando a formular, comum ao respectivo grupo de comandos; private string action – variável que reserva a componente dinâmica do comando a formular; private string username – variável que reserva o valor do username; somente pode ser definida através do recurso ao método set_LoginCredentials; private string password – variável que reserva o valor da password; somente pode ser definida através do recurso ao método set_LoginCredentials; 11 Tal como pressupõe a programação orientada aos objectos, as variáveis e métodos sem interesse para as camadas superiores são protegidas, restrigindo-se o seu domínio ao seu âmbito de acção. 3.1.2. A CLASSE “SYSTEM” Este classe visa a implementação de comandos inerentes à interacção com o equipamento ao nível de identificação propriedades/características do sistema (modelo, número de série, controlo de eixos disponível, ...), assim como também ao nível estados básicos da sua camada de apresentação (texto de “boas vindas”, definição do modo de atribuição de URL, ...). A Figura 2 resume o conjunto dos métodos disponíveis na classe “System”. Note-se que os métodos que se pretende que sejam disponibilizados até às camadas mais altas do software surgem definidos com um nível de acesso do tipo public. Podemos ainda identificar a presença de um método particular – inq_system() private string – cujo objectivo é a realização do pedido inquiry, e recepção de resposta da qual resulta uma string com todos os parâmetros inerentes ao Inquiry Parameter “system” associado a system.cgi [4]. Este método será sempre chamado por qualquer um dos métodos “get_...” quando do seu uso. Figura 2 class System 12 Figura 3 class Exclusive_camera_control 3.1.3. A CLASSE “EXCLUSIVE_CAMERA_CONTROL” Nesta classe, além dos métodos comuns a todos as classes, surgem três métodos de controlo (e respectivos inquiries complementares associados) que condicionam o controlo do equipamento. De uma forma similar à classe “System”, existe uma função específica para o inquiry inerente a este grupo de métodos. 3.1.4. A CLASSE “DAYNIGHT” Relativamente à classe “DayNight” refira-se que apenas foram implementados os dois métodos mais importantes deste grupo: • • public string DayNightMode (string order) – permite definir a forma como o equipamento gere o modo de visão nocturna; public string DayNightOnOff (string order) – permite ligar/desligar o modo de visão nocturna. Adicionalmente foram ainda implementados os seus complementares (get_DayNightMode e get_DayNightOnOff), e também o método associado ao processo de inquiry (inq_camera). 13 Figura 4 class DayNight 3.1.5. A CLASSE “PANTILTZOOMFOCUS” É na classe “PanTiltZoomFocus” que se encontram definidos os métodos necessários ao controlo das funções mecânicas da câmara, assim como aquelas que permitem obter as coordenadas físicas do plano de visualização. Por forma a tornar a sua utlização mais intuitiva e simples, esta classe apresenta algumas diferenças no que se refere à semelhança dos seus métodos relativamente aos comandos apresentados em [4], pelo que será aconselhado considerar apenas a apresentação disponível neste trabalho. É de realçar que algum dos métodos que figuram nesta classe necessitam de recorrer a métodos da classe “Camera” por forma a cumprirem as suas funções. Desta forma o constructor da classe “PanTiltZoomFocus” surge sobrecarregado por um objecto “cam” do tipo de classe “Camera” – public PanTiltZoomFocus(Camera cam). Desta forma é permitido que dentro da classe “PanTiltZoomFocus” exista um objecto do tipo “Camera” (o “cam”), logo os métodos provenientes de “Camera” podem ser usados [5]. 14 Figura 5 class PanTiltZoomFocus 3.1.6. A CLASSE “CAMERA_CONTROL_MODE” Este classe providência os métodos necessários à definição parâmetros relacionados com o modo de controlo físico da câmara. Figura 6 class Camera_control_mode 15 3.1.7. A CLASSE “CAMERA” A classe “Camera” foi sem dúvida a mais extensa das desenvolvidas. Algumas das mais importantes e mais relevantes propriedades do equipamento, passíveis de serem controladas, figuram nesta classe. Figura 7 class Camera 16 3.1.8. A CLASSE “OTHER_OPERATION” Relativamente a esta classe, apenas foi implementado um método (além dos tidos com fundamentais). Este permite inicializar ou reiniciar o equipamento. Figura 8 class Other_operation 3.1.9. CLASSES NÃO IMPLEMENTADAS Todas as classes que não se encontram enumeradas anteriormente não foram desenvolvidas. Porém a sua estrutura e métodos/variáveis fundamentais foram implementadas. 3.2. A API – FULL_FOR_SNC_RZ25 Como referido no capítulo anterior, a DLL desenvolvida disponibiliza métodos que abstraem o programador de todos os aspectos inerentes à formulação e concretização dos comandos HTTP GET e POST, tratamento de erros e excepções, retorno de inquiries formatados e transdução de comandos de semântica de baixo nível. Porém, a intenção de integrar todos os objectos da DLL, aliada à necessidade de alguns métodos recorrerem a métodos de outros objectos, motivou a que fosse desenvolvida uma API. Com recurso à referida API, o programador, após incluir o namespace Full_for_SNC_RZ25, apenas terá que criar um objecto do tipo NetCam_SNC_RZ25 (ou um array deste tipo) para ter acesso aos diversos grupos de métodos, grupos esses que no fundo são objectos do domínio da API. 17 Por exemplo, caso pretenda alterar o contraste da imagem disponibilizada, alterar a orientação absoluta da câmara e saber qual o actual CODEC de imagem em uso, bastará o seguinte código: using Full_for_SNC_RZ25; ... { ... //criação do objecto NetCam_SNC_RZ25 cam1 = new NetCam_SNC_RZ25(); //colocar contraste = 5 cam1.Camera.Contrast(5); //Pan=30º; Tilt=60º; velocidade de deslocação=10 cam1.PanTlitZoomFocus.AbsolutePanTilt(20, 60, 10); //coloca o valor do CODEC em “CODEC_em_uso” string CODEC_em_uso = cam1.Camera.get_ImageCodec(); ... } ... Entre outras possibilidades, a referida API poderá, sem qualquer tipo de objecção/dificuldade, integrar de forma directa ou indirecta novos conjuntos métodos capazes de disponiblizar outro tipo de acções, com recurso aos métodos existentes. A título de exemplo, observe-se o seguinte extracto de código: ... //exemplo novo método que “varre” toda a área visível public void varrer_ambiente() { int tilt; for (tilt = -30; tilt ==90; tilt += 10) { PanTlitZoomFocus.AbsolutePanTilt(170, tilt, 20); While(PanTlitZoomFocus.getTilt() != tilt); While(PanTlitZoomFocus.getPan() != 170); PanTlitZoomFocus.AbsolutePanTilt(-170, tilt, 20); While(PanTlitZoomFocus.getPan() != -170); //eventualmente variar zoom, diminuir passo de “tilt”, variar velocidade, variar trajectória, agendar movimento, etc... } } 18 3.3. A APLICAÇÃO CON2MEC A aplicação desenvolvida – CON2MEC – apresenta-se como uma solução final capaz de providenciar funções de monitorização de diversas câmaras de vídeo-vigilância sobre IP, assim como de controlo/diagnóstico simultâneo de uma câmara SONYTM IPELA SNC-RZ25. Assumindo que a aplicação teria apenas uma thread, tendo em consideração que desde o momento em que é realizado um dado WebRequest, com vista na aquisição de um frame, até que se recebe a totalidade do frame, a aplicação não executaria qualquer outra acção. A solução para este problema é encontrada ao serem utilizadas técnicas de multi-threading. Desta forma múltiplas tarefas podem ser executadas “em simultâneo” no âmbito da mesma aplicação principal. Com o objectivo de proceder à implementação de técnicas de multhi-threading, mais eficientes e robustas, optou-se pela criação de um vector do tipo threads com oito posições, sendo que cada uma destas corresponde a cada uma das pictureBox que alojam a imagem apresentada. Sempre que uma câmara é adicionada uma nova thread é lançada, sendo que o método associado à mesma, camBox_handler (object position), private void desencadeia as acções necessárias à actualização da imagem da respectiva pictureBox a uma cadência de 10Hz. Esta situação verifica-se até que seja desligada a referida câmara no painel da aplicação, altura em que é chamado o método close_connection(short cam_number) para terminar a thread correspondente a câmara de índice cam_number do vector de threads. Tal como se pode observar na Figura 9, a aplicação CON2MEC disponibiliza uma série de comandos para interacção com a câmara utilizada no projecto. Em particular note-se que se encontra visível o comando PanTiltZoom através de um painel de setas. Alternativamente pode ser selecionado o comando PanTiltZoom por meio de barras deslizantes (seleccionando “slidebar control”) apresentado na Figura 10, o qual susbstitui a posição ocupada pelo painel de setas. A adicção de novas câmaras é facilmente realizada através do recurso ao menu “Configuration” -> “Add camera” -> “Add new camera”, tal como demonstra a Figura 11, que activa a caixa de diálogo representada na Figura 12. 19 Figura 9 Aspecto geral da aplicação CON2MEC com o painel de setas activo Figura 10 Painel de barras deslizantes da aplicação CON2MEC 20 Figura 11 ToolStrip de adição de nova câmara Figura 12 Caixa de diálogo para introdução de dados de nova câmara 21 4. FUTUROS DESENVOLVIMENTOS Um possível futuro desenvolvimento deste projecto poderá basear-se na construção de uma infraestrutura de vídeo-conferência fléxivel, escalável, distribuída e capaz de suportar um elevado número de intervenientes/espectadores. A Figura 13 apresenta um diagrama alargado de uma possível estrutura. A figura não refere qualquer detalhe relativamente às ligações lógicas estabelecidas entre cada um dos agentes, pelo que a seguinte descrição é fundamental. Devido ao facto de a câmara de vídeo-vigilância disponibilizar um serviço de gestão de acessos ao controlo, configuração e monitorização, através de um servidor integrado, será nele confiada a segurança do acesso ao referido equipamento. No entanto necessário garantir que, quer na rede de dados local (LAN), quer a montante do servidor multimédia (SERVER), a segurança de tais informações não será colocada em causa. 23 @My_domain1 Câmara controlada localmente via RS232 ou via ETHERNET Total transparência em redes SWITCHED ETHERNET Câmaras controladas remotamente via ETHERNET @My_domain1 LOCAL CAM SWITCH RS232 @My_domain2 ETHERNET SWITCH ` LOCAL CLIENT LOCAL ADMIN LOCAL CLIENT @My_domain3 LOCAL CLIENT SERVER Cliente remoto Restantes Serviços + INTERNET REMOTE CLIENT REMOTE CLIENT Total transparência face a redes Wireless ` REMOTE CLIENT REMOTE ADMIN Possibilidade de administração remota Câmara controlada remotamente via INTERNET Figura 13 Arquitectura de um sistema distribuído de vídeo-conferência 24 Cada dispositivo apenas tem a capacidade de gerir o acesso directo a 1 administrador e 9 utilizadores (recorrendo a autenticação USERNAME+PASSWORD). Existe ainda a possibilidade de permitir/impedir o acesso por políticas de limitação ao nível de IP. Em cada uma das câmaras deverá ser configurado um administrador com previlégios totais, através da atribuição de um par USERNAME+PASSWORD. O SERVER, que terá apenas como funcão disponibizar o conteúdo multimédia para a INTERNET ou LAN, deverá ser configurado exclusivamente com previlégio de acesso para leitura ao conteúdo multimédia de cada câmara. Desta forma serão estabelecidas ligações ponto-a-ponto seguras, passíveis de serem autenticadas por um conjunto USERNAME+PASSWORD, e sob total controlo do administrador. A segurança de acesso ao conteúdo multimédia disponibilizado pelo SERVER deverá ser controlada pelo mesmo ou outra entidade habilitada (por ex.: FIREWALL). Todo o conteúdo multimédia circulará exclusivamente via ETHERNET ou, de uma forma mais abstrata, via INTERNET. Porém, os dados relacionados com o controlo/configuração dos dispositivos, poderão circular via ETHERNET ou através de ligações ponto a ponto (ADMIN LOCAL CÂMARA) via RS232 recorrendo ao protocolo VISCATM. Tendo em conta as referidas particularidades, por questões de arquitectura do sistema, todos os cliente locais (LOCAL CLIENT), expecto se extritamente necessário, deverão aceder aos conteúdos por intermédio do SERVER, tal como se tratassem de clientes remotos (REMOTE CLIENT). Desta forma a escalabilidade local nunca é comprometida por limitações relacionadas com as características da câmara. Facilmente se depreende que a arquitectura proposta assegura uma total escalabilidade em termos de direcção e distribuição espacial dos intervenientes, i.e., implementa o conceito de vídeo-conferência multi-espaços e multi-utilizadores, em oposição ao clássico modelo de “duo-conferência”. Adicionalmente é ainda válido afirmar que a dinâmica de acessos ficará apenas dependente das capacidades do(s) SERVER(s), quer ao nível da gestão de acessos, quer ao nível da disponibilização dos serviços (internos/externos). Desta forma é aumentado o nível de segurança e quebrada a limitação do número de intervenientes na vídeo-conferência. Note-se porém que, por forma a atingir este objectivo, seria fundamental que numa primeira fase fosse desenvolvido o código necessário à aquisição e transmissão/recepção 25 de áudio via IP. Melhoramentos ao nível do formato de imagem apresentada deveriam ser conseguidos, apresentando-se o formato MJPEG como a alternativa mais fléxivel no contexto deste projecto. 26 5. CONCLUSÕES A realização deste projecto premitiu concluir, de forma clara, que as câmaras de vídeovigilância sobre IP apresentam inúmeras potencialidades ao nível do desenvolvimento de aplicações nas àreas da vídeo-vigilância, mas também da vídeo-conferência. Foi também possível concluir que, a interacção do programador com um servidor web, possuiu características vantajosas, sobretudo quando o objectivo é o desenvolvimento de pequenas aplicações, ou outras baseadas em HTTP. Porém este mesmo factor condiciona o desenvolvimento de aplicações de média ou grande escala. Devido ao carácter da aplicação CON2MEC foi possível provar que a implementação de DLLs e APIs dedicadas, apesar de consumirem consideráveis tempos de desenvolvimento, apresentam-se como a solução mais eficaz para este tipo de problemas. Não obstante as dificuldades encontradas no decurso do desenvolvimento do projecto, em todos os momentos foram claras as vantagens inerentes ao uso de uma linguagem de programação orientada aos objectos, tal como o C#. 27 Referências Documentais [1] Brick House Security – All About IP Network Video Cameras, Brick House Security, New York, 2007, http://www.brickhousesecurity.com/about-ip-network-videocameras.html. KIRILOV, Andrew – Camera Vision – video surveillance on C#, The Code Project, Latvia, 2006, http://www.codeproject.com/KB/AUDIO-VIDEO/CAMERAVIEWER.ASPX. SONY – EVI-D30/D31 Command List (Ver. 1.21), SONY, 1999. SONY – SNC-RZ25N/P CGI command manual version 1.1, SONY Corporation, 2006. ARCHER, Thomas – Inside C#, McGraw-Hill, 2002, ISBN 972-773-155-4. [2] [3] [4] [5] 29
Controlo de Câmara de Vídeo Vigilância rftg.development.googlepages.com Data de criação: 20 de Janeiro de 2008 Última Actualização: 29 de Abril de 2008 Versão: v0.06 – 29/ABR/2008 Autor: Ricardo Filipe Teixeira Gomes AVISO LEGAL Este documento foi elaborado por Ricardo Filipe Teixeira Gomes, a quem se reservam todos os direitos. © 2008 Ricardo Filipe Teixeira Gomes Este documento encontra-se disponível para consulta e utilização desde que sejam respeitados todos os direitos de autor e/ou propriedade intelectual. A cópia parcial ou integral, através de qualquer tipo de meio, dos textos e imagens disponíveis neste documento encontra-se expressamente proíbida a menos que o utilizador respeite os direitos de autoria e/ou propriedade intelectual, citando para isso convenientemente o documento, e incluindo imperterivelmente uma referência clara à página web do autor: “www.rftg.development.googlepages.com”. O material contido neste documento constitui apenas uma informação de carácter geral baseada em experiências pessoais e não pretende de forma alguma influenciar o leitor sobre qualquer matéria específica. O conteúdo deste documento é fornecido como uma comodidade para os leitores e é constituído apenas por informação não vinculativa. O conteúdo deste documento é fornecido “como está” e não se oferece qualquer garantia sobre o mesmo. O autor do documento declina qualquer responsabilidade em caso de prejuízos que possam ocorrer pelo facto de alguém se basear na informação contida neste documento, uma vez que essa informação é de carácter meramente informativo, não se prometendo ou garantindo que seja precisa, completa e actualizada. O mesmo se aplica ao conteúdo de qualquer referência realizado no mesmo. Quaisquer conflitos decorrentes do uso ou relacionados com este documento, ou respeitantes a direitos de autor e/ou propriedade intelectual sobre materiais que façam parte deste documento deverão ser regidos pela Legislação Portuguesa e sujeitos à jurisdição dos tribunais de Portugal. A leitura deste documento e sua utilização pressupõe a aceitação destas condições. © 2008 Ricardo Filipe Teixeira Gomes. rftg.development.googlepages.com CONTROLO DE CÂMARA DE VÍDEO-VIGILÂNCIA Ricardo Filipe Teixeira Gomes Departamento de Engenharia Electrotécnica Instituto Superior de Engenharia do Porto 2008 Este relatório satisfaz, parcialmente, os requisitos que constam da Ficha de Disciplina de Laboratório de Mecatrónica, do 2º ano, do Mestrado em Engenharia Electrotécnica e de Computadores Candidato: Ricardo Filipe Teixeira Gomes, Nº 1020405, rftg.development@gmail.com Orientação científica: Lino Manuel Baptista Figueiredo Empresa: Supervisão: Lino Manuel Baptista Figueiredo, lbf@isep.ipp.pt Departamento de Engenharia Electrotécnica Instituto Superior de Engenharia do Porto 29 de Abril de 2008 Resumo Este trabalho visa o desenvolvimento de uma Dynamic Link Library (DLL) e de uma Aplication Programming Interface (API) capazes de disponibilizar métodos de alto nível que possibilitem o comando/diagnóstico de uma câmara de vídeo-vigilância SONYTM IPELA SNC-RZ25. Adicionalmente, visa também o desenvolvimento de uma aplicação demonstrativa das potencialidades da DLL e da API. Esta mesma aplicação proporciona ainda uma base de partida para o desenvolviemnto de uma aplicação de vídeo-conferência multiintervenientes e multi-espaços, totalmente independente do fabricante do equipamento. É proposta ainda uma arquitectura de um sistema de vídeo-conferência distribuído, e realizadas algumas considerações sobre a sua implementação. Palavras-Chave vídeo-vigilância, câmaras IP, SONYTM IPELA SNC-RZ25, vídeo-conferência. i Índice RESUMO .......................................................................................................................................................... I ÍNDICE .......................................................................................................................................................... III ÍNDICE DE FIGURAS ...................................................................................................................................V ÍNDICE DE TABELAS .............................................................................................................................. VII ACRÓNIMOS................................................................................................................................................ IX 1. INTRODUÇÃO ...................................................................................................................................... 1 1.1. 1.2. 1.3. 1.4. 2. CONTEXTUALIZAÇÃO ....................................................................................................................... 1 OBJECTIVOS ...................................................................................................................................... 3 CALENDARIZAÇÃO ........................................................................................................................... 3 ORGANIZAÇÃO DO RELATÓRIO ......................................................................................................... 4 ABORDAGEM AO PROBLEMA......................................................................................................... 5 2.1. 2.2. 2.3. CONDICIONANTES ............................................................................................................................. 6 MOTIVAÇÃO ..................................................................................................................................... 6 ENQUADRAMENTO ............................................................................................................................ 7 3. ARQUITECTURA DO SISTEMA........................................................................................................ 9 3.1. 3.2. 3.3. A DLL ............................................................................................................................................ 10 A API – FULL_FOR_SNC_RZ25 .................................................................................................... 17 A APLICAÇÃO CON2MEC .............................................................................................................. 19 4. 5. FUTUROS DESENVOLVIMENTOS ................................................................................................. 23 CONCLUSÕES ..................................................................................................................................... 27 REFERÊNCIAS DOCUMENTAIS ............................................................................................................. 29 iii Índice de Figuras Figura 1 Figura 2 Figura 3 Figura 4 Figura 5 Figura 6 Figura 7 Figura 8 Figura 9 Figura 10 Figura 11 Figura 12 Figura 13 Arquitectura do software desenvolvido .......................................................................... 9 class System .................................................................................................................. 12 class Exclusive_camera_control .................................................................................. 13 class DayNight ............................................................................................................. 14 class PanTiltZoomFocus .............................................................................................. 15 class Camera_control_mode ........................................................................................ 15 class Camera ................................................................................................................ 16 class Other_operation .................................................................................................. 17 Aspecto geral da aplicação CON2MEC com o painel de setas activo ......................... 20 Painel de barras deslizantes da aplicação CON2MEC ................................................. 20 ToolStrip de adição de nova câmara............................................................................. 21 Caixa de diálogo para introdução de dados de nova câmara ........................................ 21 Arquitectura de um sistema distribuído de vídeo-conferência ..................................... 24 v Índice de Tabelas Tabela 1 Calendarização do projecto ............................................................................................ 4 vii Acrónimos API DLL IP WWW HTTP URL JPEG – Application Programming Interface – Dynamic Link Library – Internet Protocol – World Wide Web – HyperText Transfer Protocol – Uniform Resource Locator – Joint Photographic Experts Group MJPEG – Motion JPEG MPEG Moving Picture Experts Group ix 1. INTRODUÇÃO Com o aumento das capacidades de transmissão das redes de dados actuais, surgem todos os dias novas aplicações, e novas prespectivas de desenvolvimento de produtos baseados na Internet. Estes desenvolvimentos suscitaram o interesse do ramo da Vídeo-vigilância, resultando no aparecimento das câmaras de vídeo-vigilância sobre Internet Protocol (IP). Actualmente, este tipo de dispositivos, devido ao seu baixo custo, facilidade de interacção ou elevada tecnologia são utilizadas em diversos outros tipos de aplicações, nomeadamente em vídeo-conferência. 1.1. CONTEXTUALIZAÇÃO A generalidade das câmaras de vídeo-vigilância sobre IP disponibilizam a imagem captada com recurso a um computador embebido que corre um servidor web. Desta forma possibilitam a monitorização da imagem através um simples browser. Este é o método mais simples de acesso às imagens captadas [1]. O formato mais comum das imagens disponibilizadas por este tipo de equipamento é o Joint Photographic Experts Group (JPEG). Neste caso, a designação “transmissão de vídeo” não é seguramente a mais correcta, dado que apenas são transmitidas imagens, ou 1 frames, em formato JPEG de cada vez que o servidor recebe uma solicitação por parte do cliente (por meio de um browser ou aplicação que implemente o mesmo mecanismo) [1][2]. Grande parte dos equipamentos já disponibiliza também a transmissão em formato Motion JPEG (MJPEG). Neste caso é apenas necessário o envio de um comando HyperText Transfer Protocol (HTTP) para que a câmara forneça uma sequência de frames em formato JPEG, a uma cadência predefinida, ou seja streams que na prática compõe um vídeo. Dispositivos tecnologicamente mais evoluídos já disponibilizam as imagens adquiridas em formatos que potenciam uma elevada qualidade de vídeo, tais com o Moving Picture Experts Group – 2 (MPEG-2) e MPEG-4 [2]. Ao olho humano, apesar de cadências de frames até 16 frames por segundo (fps) causarem a sensação de descontinuiade de imagem (tipicamente “piscar” da imagem), cadências superiores a 10 fps são suficientes para criar um vídeo capaz de transmitir a sensação de movimento. Actualmente, considera-se que um vídeo a 24 fps possui qualidade cinematográfica. Por norma os fabricantes de câmaras de vídeo-vigilância sobre IP fornecem, juntamente com o equipamento, todo um conjunto de software. As características deste tipo de software varia consoante os fabricantes, gamas e modelos dos equipamentos. Todos os equipamentos permitem a monitorização das imagens recolhidas, sendo que, caso o equipamento o permita, o seu controlo/diagnóstico remoto bem como a transmissão de áudio uni-direccional ou bi-direccional, e até vídeo. Alguns pacotes de software, mais completos, possuem uma solução integrada que permite a gestão do acesso a uma ou mais câmaras (criação de contas de utilizadores, atribuição de permissões, ...), monitorização simultânea de imagens capturadas por diversas câmaras, gravação das imagens recolhidas em formato digital, detecção de movimento, seguimento de movimento, vídeo-conferência, e diversas outras funcionalidades. Apesar de diversos equipamentos permitirem o controlo/dignóstico através do servidor web integrado no equipamento, recorrendo a comandos HTTP GET e POST, os protocolos de comunicação entre as aplicações de controlo/diagnóstico e os equipamentos são maioritariamente proprietários e fechados (por questões de segurança e/ou comerciais). 2 Contudo, a SONYTM tem desenvolvido um protocolo proprietário aberto com o objectivo de normalizar o comando/diagnóstico de equipamentos de vídeo. Este designa-se por VISCATM (Video System Control Architecture). Porém pressupõe o recurso a uma ligação RS-232 para estabelecer conexões entre os dispositivos[3]. 1.2. OBJECTIVOS Tendo como base uma câmara de vídeo-vigilância SONYTM IPELA SNC-RZ25, os principais objectivos propostos para este projecto são: • Desenvolvimento de uma Dynamic Link Library (DLL) e de uma Application Program Interface (API), em linguagem C#, por forma a possibilitar um controlo/diagnóstico do equipamento recorrendo a métodos de alto-nível; • Providenciar toda a documentação de apoio à interacção com DLL e API desenvolvidas directamente na DLL e na API; • Assegurar a robustez e fiabilidade da DDL e API desenvolvidas através da implementação de técnicas de tratamento de erros e excepções; • Desenvolvimento de uma aplicação capaz de integrar a monitorização simultânea de diversas câmaras IP, assim como o controlo/diagnóstico da câmara de vídeo-vigilância usada no decurso projecto; • Demostrar e validar as potencialidades da DDL e da API desenvolvidas, por meio da sua utilização na aplicação de monitorização, controlo e diagnóstico; • Garantir a escalabilidade, modularidade e flexibilidade da DDL, API e aplicação desenvolvidas, por forma a potenciar futuros desenvolvimentos; • Optimizar o desempenho da aplicação com recurso a multi-threading. 1.3. CALENDARIZAÇÃO Por forma a cumprir com os objectivos propostos, foi idealizada a distribuição temporal das diversas tarefas ao longo do período de tempo disponível para a realização do projecto. A Tabela 1 apresenta a referida calendarização. 3 Tabela 1 Calendarização do projecto Actividade \ Semana lectiva Relatório projecto preliminar Relatório de protótipo funcional Entrega do relatório final Elaboração da apresentação Preparação de arguência Estudo protocolo VISCATM Teste comando básico Pan-Tilt-Zoom Estudo/interpretação do “CGI command manual” Desenvolvimento da biblioteca “Full_for_SNC-RZ25” e respectivo suporte Desenvolvimento da aplicação “CON2MEC” Teste e correcção de erros Teste Finais Elaboração do relatório final Novembro 4ª 5ª 6ª 7ª 8ª Dezembro 9ª 10ª Interrupção Natal 11ª Janeiro 12ª 13ª 1.4. ORGANIZAÇÃO DO RELATÓRIO No Capítulo 1 é realizada uma breve apresentação e contextualização do presente trabalho, traçados os principais objectivos inerentes à sua realização e apresentado o cronograma previsto para a realização das suas tarefas elementares. No capítulo seguinte, 2, é feita uma breve abordagem do problema, sendo referidas algumas condionantes, a motivação e o respectivo enquadramento do projecto. Ao longo do 3º capítulo é descrita a arquitectura do sistema, explicando a DLL, API e aplicação desenvolvida. Segue-se o 4º capítulo, onde são perspectivados futuros desenvolvimentos, sendo, numa breve nota final, referidos os prioritários. O 5º e último capítulo apresenta algumas das conclusões fruto da realização deste projecto. 4 2. ABORDAGEM AO PROBLEMA A generalidade dos equipamentos de vídeo-vigilância sobre IP possuem software capaz de providenciar monitorização de imagem, e controlo/diagnóstico do equipamento. Este pode correr na máquina cliente ou no próprio equipamento, sendo acessível através de um browser web ou uma aplicação dedicada. Não obstante as vantagens de uma aplicação desenvolvida por profissionais dedicados de um determinado fabricante, factores como a falta de flexibilidade/modulariade, e código fechado das aplicações, limitam o seu uso e condicionam eventuais soluções de integração com equipamentos de diferentes fabricantes e tecnologias. Soluções capazes deste tipo de integração não são de todo comuns. Relativamente ao equipamento usado no projecto (câmara de vídeo-vigilância SONYTM IPELA SNC-RZ25), refira-se que o mesmo possui um servidor integrado que implementa diversos comandos HTTP GET e POST, de certa forma passíveis de serem considerados como métodos de alto-nível. Porém remanescem na sua sintaxe e semântica características de acções de baixo nível, assim como não é possível a abstracção desejável relativamente ao meio de comunicação. 5 2.1. CONDICIONANTES Os fabricantes de equipamentos deste tipo providenciam já aplicações e pacotes de software extremamente completos, os quais permitem o controlo/diagnóstico e monitorização. Em particular, o equipamento que será utilizado para desenvolvimento do projecto, possui um pacote de software extremamente completo com todas as funcionalidades já enumeradas. Claramente não fará sentido o desenvolvimento de uma aplicação semelhante. Tipicamente cada fabricante possuiu um conjunto de comandos/protocolos de comunicação distintos, pelo que, no âmbito deste projecto, não é exequível uma abordagem generalista ao nível do comando/diagnóstico de equipamentos que não o disponível para a realização do mesmo. O recurso ao IP assume vantagens na prespectiva do controlo/diagnóstico remoto (virtualmente a partir de qualquer local com acesso à World Wide Web (WWW)) e elimina a necessidade de duas cablagens distintas para o mesmo equipamento (comando + transmissão de imagem). Contudo apresenta algumas fragilidades em termos de segurança e eventuais requisitos de tempo-real. Em oposição, através de ligação RS232 é possível garantir o controlo em tempo-real e superar fragilidades de segurança. Contudo, apesar de continuar a ser possível monitorizar imagens a partir de qualquer local, a distança entre o equipamento e a estação de controlo/diagnóstico remota reduz-se a uma distância extremamente limitada (limites da norma RS-232). 2.2. MOTIVAÇÃO Analisada a informação adquirida, e as condicionantes enunciadas, existe um potencial problema que carece de ser resolvido. O desenvolvimento de uma aplicação de monitorização de câmaras de vídeo-vigilância sobre IP assume por si só um carácter irrelevante, dado que existem já diversas aplicações disponíveis na WWW que cumprem este requisito de uma forma bastante satisfatória. Porém uma aplicação capaz de concentrar a monitorização de diversas câmaras de vídeo-vigilância sobre IP, assim como disponibilizar o comando/diagnóstico da câmara disponível para este projecto, pode suscitar interesse. 6 Conhecido o objectivo de, futuramente, integrar o equipamento em causa numa aplicação de vídeo-conferência, a prespectiva de desenvolver uma DLL e uma API robustas, modulares e flexíveis assume um carácter importante, tanto mais porque, aquando do estudo do estado da arte realizado não foi encontrada nenhuma solução similar. As potencialidades inerentes à programação orientada aos objectos, sobretudo quando se recorre à linguagem C#, assim como o crescente números de programadores neste tipo de linguagem e a facilidade de aprendizagem da mesma, motiva a que o desenvolvimento de todo o código seja realizado nesta linguagem. 2.3. ENQUADRAMENTO A solução descrita ao longo deste trabalho visa enquadrar-se no desenvolvimemto de uma aplicação de vídeo-conferência, que permita a troca de imagens entre múltiplos espaços físicos e múltiplos utilizadores em simultâneo. A aplicação desenvolvida preenche já alguns destes requisitos, nomeadamente no que se refere monitorização e gestão de câmaras visualizadas. A independência da DLL e da API face à aplicação, asseguram que alterações a qualquer um destes componentes não comprometem a solução encontarda, potenciando desenvolvimentos futuros. 7 3. ARQUITECTURA DO SISTEMA O projecto realizado possuiu o seu âmbito limitado unicamente ao desenvolviemnto de software. A arquitectura do sistema desenvolvido baseia-se em três componentes fundamentais, representáveis pelo esquema de camadas da Figura 1: Aplicação API DLL: Camera … … … PanTiltZoomFocus Figura 1 Arquitectura do software desenvolvido 9 3.1. A DLL Os comandos HTTP GET e POST, disponibilizados pelo servidor presente no equipamento, são por si já passíveis de serem considerados como métodos para interacção com um objecto (a câmara), proporcionando um grande nível de abstracção face às acções de baixo nível inerentes ao funcionamento interno do equipamento. Contudo, não existe qualquer tipo de tratamento de erros e/ou excepções do lado do cliente, assim como alguma semântica ao nível dos comandos permanece ainda numa lógica de baixo nível (por exemplo, as posições de Pan encontram-se em formato hexadecimal e não em formato de graus angulares). Adicionalmente, todo o retorno resultante de inquiries ao dispositivo é recebido na forma de uma string, composta pela concatenação de diversos parâmetros em simultâneo. A DLL desenvolvida visa, através da introdução de uma nova camada de software, abstrair o programador de todos estes detalhes. Desta forma, o acesso ao dispositivo é realizado a um nível mais alto, recorrendo a métodos de formato homogéneo, semântica clara/directa e sintaxe simplificada. O facto do tratamento de erros/excepções ser providenciado ao nível da DLL assegura, de forma totalmente transparente, uma efectiva contenção da propagação de erros/excepções directamente na camada mais baixa, evitando a propagação para a camada de aplicação. A DDL é composta por várias classes de objectos, sendo que, cada uma das classes, dispõe de um conjunto específico de métodos. A estrutura implementada tem como objectivo recriar a estrutura de comandos apresentada em [4]. Cada classe de objectos não é mais do que um grupo de comandos (System, Exclusive camera control, Date and time, ...), sendo que, cada um dos seus métodos, do tipo public, correspondem a cada um desses comandos (WelcomeText “
Apresentação do trabalho
Read this doc on Scribd: Controlo de Câmara de Vídeo Vigilância - Apresentação
Comandos de Inquiry e Respectivos Valores Retornados pela Câmara de Vídeo Vigilância SONY TM IPELA SNC-RZ25
Read this doc on Scribd: Comandos de Inquiry e Respectivos Valores Retornados pela Câmara de Vídeo Vigilância SONYTM IPELA SNC-RZ25
Código fonte da aplicação, API e DLL (brevemente disponível...)
Application source code, API and DLL (soon available...)