Sistema de Vídeo-Vigilância sobre Ethernet com QoS Dinâmica

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO Sistema de Vídeo-Vigilância sobre Ethernet com QoS Dinâmica João Pedro Ramos Reis Mestrado Integrado em Engenharia Electrotécnica e de Computadores Orientador: Luís Miguel Pinho de Almeida (PhD) 17 de Abril de 2013 c João Pedro Ramos Reis, 2013 Resumo O uso de aplicações multimédia embarcadas em sistemas industriais é uma realidade crescente nos nossos dias. Este uso deve-se principalmente à necessidade tanto de melhorar as interações entre os operadores e o sistema como também de melhorar técnicas de decisão e controlo. Um exemplo é a supervisão de processos com vídeo que incorpora transmissão e processamento de vídeo num ambiente distribuído. Normalmente, estes sistemas dependem de protocolos de transmissão em tempo real, particularmente Real Time-Ethernet (RTE), para fornecerem serviços de comunicação de baixa latência. No entanto os protocolos RTE convencionais oferecem canais Constant Bit-Rate (CBR) e modelos estáticos de gestão de Qualidade de Serviço, propriedades que entram em conflito com o facto das fontes de dados multimédia gerarem tipicamente tráfego Variable Bit-Rate (VBR). Este conflito leva a que a adaptação VBR para CBR seja difícil e gera ineficiência no uso de largura de banda. Neste trabalho foi desenvolvido um sistema de monitorização de vídeo em cenários industriais, constituido por várias câmaras e uma estação de monitorização. Neste cenário as várias câmaras produzem conteúdo vídeo e enviam para a estação de monitorização onde os vários streams podem ser visualizados em separado e onde nos é possível gerir a Qualidade de Serviço (QoS) de cada stream individualmente e a QoS geral do sistema. Para tal ser possível, este sistema foi implementado sobre o protocolo de rede FTT-SE que permite a criação de canais de comunicação adaptáveis cujas propriedades podem ser alteradas on-line. Os resultados mostram que o modelo de gestão de QoS é apropriado para este tipo de cenário, e que a arquitetura implementada fornece um sistema robusto de gestão de QoS. i ii Abstract The use of multimedia applications within industrial systems has become commonplace. This integration derives from the need to improve both interaction between the system and the operators and the decision and control techniques. An example is process supervision with video which incorporates multimedia transmission and processing in a distributed environment. Normally, industrial systems rely on real-time network protocols, particularly Real Time-Ethernet (RTE), to provide low latency communication services. However the conventional RTE protocols offer Constant Bit-Rate (CBR) channels with static Quality of Service (QoS) management models, properties which conflict with the most common Variable Bit-Rate (VBR) nature of the multimedia traffic. This conflict makes the VBR to CBR adaptation difficult and increases the inefficiency on bandwidth usage. In this work a video surveillance application was developed, consisting of several cameras and a monitoring station. In this scenario the various cameras produce multimedia content which is sent to the monitoring station where the multiple streams can be viewed separately and where is possible to manage individually each stream’s QoS as well as the global QoS of the system. To accomplish this goal, this system used the FTT-SE network protocol that provides adaptable real time communication channels, which operational parameters can be changed at run time. The results show that this model of QoS management is appropriate for this type of scenario, and the implemented architecture provides a robust QoS management system. iii iv Agradecimentos Em primeiro lugar, e acima de tudo, à minha mãe, que sempre me apoiou incondicionalmente e ajudou em tudo o que foi possível. Por ser um exemplo de trabalho árduo, honestidade e bondade e por toda a força que consegue ter mesmo nas situações mais adversas. Ao meu orientador Professor Doutor Luís Almeida, pela constante disponibilidade, acessibilidade, paciência e ajuda prestada, tanto a nivél teórico como a nivel prático. Por toda a motivação que me foi dando ao longo deste semestre. A Zahid Iqbal e Luís Silva pela ajuda a nível prático e pela imensa paciência. Aos meus amigos pelos conselhos, ajuda, apoio e que me enriqueceram e contribuíram para o sucesso do trabalho A todos vocês o meu maior agradecimento João Reis v vi “A problem well stated is a problem half solved” Charles F. Kettering vii xiv LISTA DE TABELAS Abreviaturas e Símbolos CBR Constant Bit Rate VBR Variable Bit Rate GOP Group Of Pictures IP Internet Protocol MCA Media Control Applications MES Multimedia Embedded Systems QoS Quality of Service TCP Transport Control Protocol UDP User Datagram Protocol JPEG Joint Photographic Experts Group MJPEG Motion JPEG MPEG Moving Picture Experts Group xv Capítulo 1 Introdução Este trabalho foi desenvolvido no âmbito do Mestrado Integrado em Engenharia Eletrotécnica e de Computadores. O objetivo principal foi criar uma aplicação de monitorização vídeo para ambientes industriais, sobre uma rede de dados baseada em tecnologia Ethernet e executando o protocolo de rede FTT-SE, que permite uma gestão dinâmica e adaptativa da Qualidade de Serviço (QoS) de cada stream de vídeo e do sistema geral. 1.1 Contexto e Motivação Verifica-se hoje em dia uma crescente necessidade de incorporação de processamento de informação multimédia em aplicações nos mais diversos domínios aplicacionais, desde controlo industrial a gestão de espaços públicos, às comunicações pessoais, à instrumentação médica, etc. Esta presença advém da necessidade de melhorar a interação dos operadores/utilizadores com o sistema e também da necessidade de criar estratégias para aproximar o comportamento humano em tarefas de comunicação, controlo e decisão, recorrendo por exemplo a algoritmos de análise de vídeo e som. No domínio particular das aplicações de controlo industrial, esta integração deu origem às chamadas MCA (Media Control Applications), que englobam tarefas como inspeção automática de equipamento ou rastreamento de objetos. Dentro das MCA é possível definir duas classes genéricas relativamente aos seus requisitos de pontualidade: Supervised Multimedia Control Systems, classe esta cujo ênfase está na qualidade de processamento dos dados multimédia não apresentando restrições em termos de pontualidade dos dados, e Multimedia Embedded Systems (MES) que para além dos requisitos de qualidade de processamento apresenta também requisitos de pontualidade dos dados, sendo necessário suportar tráfego em tempo real, o que torna esta classe mais complexa e exigente. Normalmente, a transmissão de dados multimédia está associada a um de tráfego de bitrate variável, devido às técnicas de compressão usadas. Contudo, muitas das aplicações MES estão implementadas em protocolos de comunicação tempo-real que fornecem canais de comunicação 1 2Introdução de bitrate constante, daí que é necessário uma adaptação do tráfego Variable Bit-Rate (VBR) para esses canais Constant Bit-Rate (CBR). Esta adaptação é complexa e pode levar a desperdício de largura de banda ou então a insuficiência, causando perda de frames. Deste problema surge a necessidade do uso de um protocolo de comunicação em tempo real dinâmico que assegure os requisitos de pontualidade das aplicações e forneça também isolamento temporal entre streams multimédia para evitar a interferência mútua e permita adaptar mutuamente os canais e os streams para minimizar o desperdício de largura de banda sem causar perda significativa de frames. O protocolo FTT-SE apresenta uma boa solução para os requisitos das aplicações MES devido à sua capacidade intrínseca de configuração dinâmica de QoS que possibilita gerir on-line a compressão dos streams multimédia e largura de banda dos canais atribuidos a cada stream de acordo com os requisitos da aplicação fornecendo a cada instante a melhor QoS possível a cada stream. No entanto, é necessário recorrer a um middleware que forneça a abstração necessária para a gestão destes parâmetros por parte da aplicação. O middleware apresentado em [3] fornece uma interface que permite a reconfiguração dos canais de configuração enquanto garante que os requisitos de tempo real sejam cumpridos. Contudo, para poder usufruir de maior flexibilidade na gestão de QoS das várias câmaras, foi decidido implementar essa funcionalidade ao nível de aplicação, usando o protocolo FTT-SE. Este trabalho centra-se essencialmente no desenvolvimento dessa camada de gestão dinâmica da QoS de um conjunto de câmaras que se podem ligar e desligar em run-time. 1.2 Estrutura da Dissertação Para além da introdução, esta dissertação contém mais 5 capítulos. No capítulo 2, é descrito o estado da arte e são apresentados trabalhos relacionados. No capítulo 3, é apresentada a arquitetura da solução proposta. No capítulo 4, é apresentada a implementação da solução proposta. No capítulo 5, são apresentados testes e resultados. No capítulo 6, são apresentadas as conclusões e trabalho futuro. Capítulo 2 Contexto e Revisão Bibliográfica 2.1 Compressão e Transmissão de Conteúdos Multimédia 2.1.1 Compressão Multimédia As técnicas de compressão multimédia tiram partido de dados redundantes no conteúdo a comprimir para obter uma redução no tamanho dos dados. Estas técnicas de compressão tentam identificar redundância espacial, tal como similaridades em entre pixeis vizinhos, e também redundância temporal, tal como similaridades entre imagens consecutivas. Os compressores estão categorizados em duas classes gerais, dependendo do seu modo de operação e do tipo de redundância que eliminam: compressores de imagem, que tiram partido de redundância espacial, tal como o standard JPEG ou o mais recente JPEG2000, e compressores de vídeo que tiram partido da redundância temporal, sendo os mais comuns os standards MPEG-2, H.263, MPEG-4 parte 2 e parte 10 [4]. A escolha da técnica de compressão adequada deve ser cuidadosa, e é necessário ter em conta os requisitos da aplicação e as limitações do sistema. Numa comparação inicial é possível concluir que a compressão de vídeo consegue obter maiores rácios de compressão quando comparada com a compressão de imagem, impondo assim menores requisitos de largura de banda. Em contrapartida, na codificação de vídeo o frame-rate é mantido constante, sendo que quando há variações na largura de banda disponível, o compressor atua na qualidade da imagem para conseguir manter o frame-rate constante. Este facto é uma desvantagem em aplicações MES, como por exemplo monitorização vídeo, onde é necessário manter uma qualidade de imagem suficientemente boa. Outro facto a considerar é a complexidade computacional de cada tipo de compressão e latência que a compressão introduz no sistema. Em compressão de imagem o custo computacional é baixo uma vez que cada imagem é processada individualmente. Já na compressão de vídeo a compressão/descompressão dos dados tem maior custo computacional, visto que as imagens são processadas em blocos de várias frames consecutivas (GoP), o que introduz uma latência considerável, associada à dimensão do GoP. Refira-se ainda que em cada GoP as imagens são obtidas 3 4Contexto e Revisão Bibliográfica por diferença a uma imagem (frame) de referência. A perda dessa frame corresponde à incapacidade de recuperar as frames de todo o GoP. A compressão de imagem, standard JPEG, é então uma escolha adequada para aplicações MES devido à sua robustez a erros, baixa complexidade computacional e ainda menor latência. 2.1.2 Transmissão Multimédia Devido à dificuldade em suportar comunicação de tempo-real, a Internet é pouco adequada à transmissão de conteúdos multimédia interativos ou com requisitos de latência baixa. Contudo, nos últimos anos a transmissão de conteúdos multimédia pela Internet tem sido motivo de pesquisa. As soluções mais comuns baseiam-se na pilha protocolar TCP/UDP/IP complementada por protocolos tais como RTP (Real Time Protocol)[5], RTSP (Real Time Streaming Protocol)[6] ou até SIP (Session Initiation Protocol)[7] que têm como objetivo controlar a carga submetida à rede, a partir da análise de vários parâmetros da rede, tais como a largura de banda usada, perda de pacotes e atrasos. Outras soluções tentam diferenciar o tipo de tráfego, IntServ [8] e DiffServ [9], por forma a garantir uma prioridade a certos tipos de tráfego. No entanto estas tecnologias IP introduzem latência na comunicação o que, do ponto de vista de aplicações MES que têm requisitos de pontualidade rígidos, é uma desvantagem. Em [10] é mostrado um exemplo que faz uso de buffers de memória tanto no lado do produtor como do consumidor para conseguir suavizar as variações de bit-rate. Outro exemplo são [11] e [12] que também fazem uso de buffers e são baseados em redes IP standard, no entanto estas técnicas requerem uma fase de processamento complementar anterior à compressão o que aumenta a complexidade computacional e por sua vez a latência. Outro exemplo são os algoritmos de Rate Control de baixo delay [13]–[1] que se focam no problema da latência e conseguem uma boa performance para as aplicações para as quais foram concebidos. No entanto, estes algoritmos foram desenvolvidos para o uso em aplicações tais como vídeo-conferência ou vídeofonia que são cenários bastante estáticos em termos de variações no conteúdo multimédia, o que as torna pouco adequadas para o uso em aplicações MES que normalmente englobam cenários mais dinâmicos. É de considerar também que o tráfego multimédia, em particular streaming de vídeo, é uma fonte de tráfego VBR (Variable Bit Rate) e, normalmente, os protcolos de comunicação em tempo real fornecem canais de comunicação CBR (Constant Bit Rate), daí que é necessário uma adaptação do tráfego VBR para a transmissão em canais CBR. Esta adaptação pode ser feita de várias formas. É possível fazer esta adaptação alocando a largura de banda média gerada pela fonte multimédia, garantindo mais eficiência do ponto de vista da largura de banda, mas em contrapartida irá gerar perda de informação ou atrasos na transmissão quando as necessidades de largura de banda forem superiores à largura de banda alocada. Outra possibilidade é alocar um canal com largura de banda igual à máxima gerada pela fonte multimédia, garantindo a integridade dos dados mas ao mesmo tempo levando a um sobre-dimensionamento e a eventuais desperdícios de largura de banda. Em [2] os autores tiram partido do mecanismo dinâmico e multidimensional de gestão de QoS do protocolo FTT-SE para fazer uma adaptação dinâmica do tráfego VBR para canais CBR. 2.2 O Protocolo FTT-SE 5 2.2 O Protocolo FTT-SE O protocolo FTT-SE é um protocolo de comunicação em tempo real baseado no paradigma Master/Multi-Slave que tira partido das vantagens da micro-segmentação Ethernet. Neste protocolo existem dois tipos de nós, o nó Master e os nós slave, sendo que o nó Master tem como função a coordenação da transmissão dos nós slave. As comunicações são organizadas em slots de duração temporal fixa, Elementary Cycle (EC) que são ativadas por uma mensagem do nó master chamada Trigger Message (TM) que contém os ID’s das mensagens a transmitir dentro de cada EC. Este protocolo reserva uma parte do EC para tráfego em tempo real, assegurando o isolamento temporal entre classes de tráfego, possibilitando o foco em tráfego multimédia. Existe ainda a possibilidade de definir políticas de agendamento de tráfego conforme necessário e ainda fazer alterações nos requisitos de comunicação, o que facilita a gestão da largura de banda on-line fornecendo assim um mecanismo dinâmico de gestão de de QoS. Figura 2.1: Arquitetura FTT-SE para uma rede com um único switch Ethernet, como mostrado em [1] 2.3 Modelo de gestão de QoS em FTT-SE Em [2] os autores consideram um sistema constituído por pfontes multimédia, que enviam Mstreams para um sink, havendo apenas um produtor multimédia por nó. O modelo de gestão de QoS proposto considera, ao nível aplicacional, cada stream caracterizado pela sua prioridade relativa normalizada, os factores de quantificação possíveis, os valores possíveis do tamanho de cada frame após a compressão e os valores possíveis de intervalos entre frames. Neste modelo, o gestor QoS é responsável por receber pedidos de adição ou remoção de fontes multimédia e por receber pedidos de re-negociação de QoS dos diversos nós. É ainda responsável por alocar a largura de banda para cada canal de acordo com critérios baseados em QoS. Esta 6Contexto e Revisão Bibliográfica Figura 2.2: Modelo de gestão de QoS proposta em [2] entidade está implementada no nó Master. Cada nó, que é uma fonte de dados multimédia, contém uma sub-camada de QoS que interopera com o gestor de QoS e que é responsável por manter os dados de stream de vídeo dentro da largura de banda do canal que lhe foi atribuído. Esta subcamada é capaz de fazer renegociação de recursos com o gestor sempre que necessário,adaptando o tamanho dos canais às necessidades de cada momento. No consumidor multimédia, que é também um nó Slave, a sub-camada é capaz de fazer pedidos de renegociação de recursos em resposta, por exemplo, a pedidos do operador. 2.3.1 A sub-camada de QoS Esta sub-camada, contida em todos os nós, tem como função mapear os parâmetros QoS da aplicação para parâmetros QoS da rede. É também responsável por manter a largura de banda do stream multimédia dentro da largura de banda do canal atribuído, o que é conseguido adaptando o valor do nível de quantificação, ou re-negociando a largura de banda do canal com o gestor QoS (fig. 2.3). A adaptação do fator de quantificação é baseada no modelo R(q) (Eq. 2.1) , onde os parâmetros αeλsão considerados constantes, βé especifico de cada frame e ¯q=100 −qé o nível de compressão que varia simetricamente com o nível de quantificação q, sendo 100 o valor máximo considerado. R(q) = α+β ¯qλ(2.1) Este processo ocorre frame a frame , sendo que a sub-camada de QoS tenta manter o valor de quantificação dentro do intervalo permitido. Quando o fator de quantificação sai fora do intervalo permitido é usado o valor mais próximo baseado numa função de saturação. Este processo pode levar a eventuais perdas de frames quando a adaptação do valor de quantificação não for suficiente para reduzir uma largura de banda excessiva. Quando esta situação ocorre um certo número de vezes, definido por Quality Change Threshold (QCT) em que este valor significa o valor máximo 2.3 Modelo de gestão de QoS em FTT-SE 7 de frames perdido sem que ocorra renegociação, a sub-camada de QoS inicia uma renegociação de recursos com o gestor QoS para tentar obter mais largura de banda para o respetivo canal. Figura 2.3: Adaptação de tráfego VBR em canais CBR como proposto em [2] 2.3.2 O gestor QoS O gestor QoS tem como função distribuir a largura de banda da rede, US, pelos canais que a usam. É também responsável por receber pedidos de renegociação por parte dos nós. Quando há um pedido de renegociação, a sub-camada de QoS desse nó estima o novo tamanho dos buffers de transmissão, Ci u, determinado por forma a satisfazer as necessidades do stream a cada instante. Após este calculo, a sub-camada de QoS envia o valor da largura de banda do canal desejada ao gestor QoS que irá determinar, para cada canal, uma distribuição da largura de banda pelos canais tendo em conta o máximo e mínimo especificados. Esta distribuição pode ser feita de acordo com diferentes políticas que podem ser implementadas ao nível do gestor de QoS sem necessidade de alterações ao nível da rede. Em [2] os autores implementam um algoritmo baseado em prioridades que irá distribuir a largura de banda pelos canais de acordo com a sua prioridade relativa. Após a distribuição da largura de banda pelos canais o gestor de QoS irá efetuar um mapeamento do valor da largura de banda para os parâmetros operacionais de cada canal FTT, (Ci,Ti). Visto que diferentes valores de Ci,Tipodem produzir o mesmo valor de largura de banda este mapeamento deve calcular um valor que se aproxime, sem exceder, da largura de banda calculada pelo algoritmo de distribuição. Em [2] os autores adotam um algoritmo que tenta maximizar o custo da transmissão Citentando aproximar este valor o mais possível do valor de Ci urequerido pela aplicação. 14 Metodologia e Arquitetura do Sistema Capítulo 4 Implementação Este capitulo descreve a implementação das várias componentes das aplicações Monitor e Câmara, que foram apresentados no capitulo anterior. 4.1 Aplicação Monitor O processo principal da aplicação monitor, representado na fig. 4.1 , começa por inicializar o protocolo FTT e os componentes da biblioteca OpenCV que serão usados. De seguida é inicializada a base de dados. Para a inicialização do FTT foi usada a API CommonBridge que permite uma maior transparência da interface genérica do FTT para a aplicação. Mais detalhes sobre esta interface podem ser consultados nos anexos. Após a inicialização é lançada a thread de controlo de admissão e de seguida lança a interface do utilizador (UI). O processo principal só termina quando ambas as threads da UI e de controlo de admissão terminarem, ou quando o utilizador forçar a terminação da aplicação. 4.1.1 Protocolo para Gestão de QoS O protocolo criado para permitir a interação entre a aplicação monitor e as câmaras para realizar a gestão global de QoS consiste num conjunto de frames específicas, identificadas com códigos de controlo. A estrutura base dos códigos de controlo é apresentada em na figura 4.2. O atributo node_ id contém o ID do nó para o qual o código é dirigido ou, no caso de ser um pedido proveniente de um nó câmara, contém o ID do nó que fez o pedido. O atributo code contém o código de controlo. Este parâmetro pode ter vários valores, representando vários casos. Estes valores são definidos como se pode ver na figura 4.3 e representam: •PERM_JOIN: é usado para dizer a um nó que se ligou à rede que foi admitido no sistema 15 16 Implementação Inicialização do FTT , módulo OpenCV e Base de Dados Inicialização da thread de controlo de admissão Aguarda terminação das threads Inicialização da thread da UI Figura 4.1: Monitor - Processo Principal +node_id : unsigned int +code : int «struct» Control_Code Figura 4.2: Estrutura da informação de controlo do protocolo •CANT_JOIN: é usado para dizer a um nó que se ligou à rede que não tem permissão para se ligar ao sistema •INCREASE_BW: é usado nos pedidos de renegociação quando um dos nós necessita de mais largura de banda •DECREASE_BW: é usado nos pedidos de renegociação quando um dos nós tem disponível mais largura de banda do que aquela que precisa. 4.1.2 Controlo de Admissão Como referido anteriormente o controlo de admissão é implementado numa thread POSIX que corre em loop até que a aplicação seja terminada e que faz pedidos constantes à interface do FTT através do método FTTSE_Node_Event(). Este método é bloqueante, ou seja, o processo 4.1 Aplicação Monitor 17 +node_id : unsigned int +code : int «struct» Control_Code +PERM_JOIN +CANT_JOIN +INCREAESE_BW +DECREASE_BW «enumeration» code Figura 4.3: Códigos de controlo possíveis que fez este pedido fica bloqueado até que a chamada retorne. Deste modo, o controlo de admissão só irá atuar quando ocorrer um evento. Os parâmetros de entrada deste método são as variáveis onde irá guardar o tipo de evento e o ID do nó associado ao evento, neste caso node_id e event_type. Quando o event_type é 0, o que significa que o nó node_id se desconectou, o primeiro passo é remover o nó em questão da base de dados e de seguida é necessário invocar o método redist_on_remove() do gestor de QoS de modo a que a largura de banda que foi libertada seja distribuída pelos restantes nós. No caso de event_type ser 1, ou seja quando um novo nó se conecta, o primeiro passo é invocar o método redist_new_node() do gestor QoS, que irá tentar retirar largura de banda aos nós existentes, sem comprometer os seus requisitos mínimos, e caso não seja possível garantir a largura de banda mínima para o novo nó este método retorna 0 e é enviado um código de controlo ao nó a informar que não é possível conectar-se ao sistema. Quando o gestor QoS consegue redistribuir a largura de banda por forma a que o nó se possa conectar esse nó é adicionado a base de dados, é enviado um código de controlo a informar que foi permitida a conexão e de seguida é criado o canal FTT que esse nó irá usar, cujos parâmetros operacionais são baseados na largura de banda que o gestor decidiu. E por fim é criada uma thread de display para este novo nó, que será responsável por fazer a descompressão e display do vídeo proveniente do canal FTT associado ao nó. A implementação desta thread é detalhada em 4.1.4 É possível visualizar o algoritmo na figura 4.4 A implementação dos métodos do gestor QoS é discutida na secção seguinte. 4.1.3 Gestor de QoS É neste módulo que está contida a implementação dos métodos que permitem fazer a gestão da largura de banda. Quando uma nova câmara se conecta ao sistema, a thread de controlo de admissão faz um pedido ao gestor de QoS, que deve determinar se é possível a inclusão desse novo nó no sistema por forma a que garanta os requisitos minimos tanto das câmaras que já se encontram ligadas como da nova câmara. Para tal foi criado o método redist_on_new_node(). Este método começa por copiar os dados de todos os canais na base de dados, recorrendo ao método copy_to_redist_set() implementado no módulo da base de dados, para um array de estruturas que foi criado para este fim. Este array, redist_set, contém os valores de largura de banda atual e os valores de largura de banda exigidos de cada canal e contem ainda os valores dos fatores de qualidade atual. O parâmetro de entrada deste método é o ID do nó que se está a tentar ligar ao sistema, o qual é 18 Implementação FTT-SE_Node_Status (&event_ype,&node_id) event_type Remove o nó da base de dados event_type=0 event_type=1 Chama função redist_new_node() do módulo de QoS ret = redist_new_node() Envia código de controlo ao nó a indicar que não é possivel conetar-se ret=0 Adiciona novo nó à base de dados ret=1 Cria novo canal FTT para o novo nó Envia código de controlo ao nó a informar que se pode conetar Cria uma display thread para o novo nó Redistribui a largura de banda que ficou disponivel: redist_on_remove() Figura 4.4: Thread de controlo de admissão 4.1 Aplicação Monitor 19 colocado na ultima posição de redist_set com valores de largura de banda nulos de modo a não influenciar nos cálculos. Algoritmo 4.1.1: REDIST_ON_NEW_NODE(node_id,avail_bw) comentário: Tenta redistribuir a largura de banda quando numa nova câmara se ligou n←num_channels()+1 comentário: Número de canais ligados redist_set set[n] copy_to_redist_set(set) comentário: Copia informação de todos os canais para o redist_set restart ←1 new_bw ←0 bw_to_dist ←avail_bw while restart 6=0 do                                                        channel_count ←0 restart ←0 for i←0to n do (if set[i].node_id 6=0 do channel_count++ new_bw ←bw_to_dist/channel_count if new_bw <MIN_BW do return (0) for i←0to n do            if new_bw <set[i].required_bw do      restart ←1 set[i].node_id ←0 bw_to_dist =bw_to_dist −set[i].required_bw for i←0to n do (if set[i].node_id 6=0 do set[i].new_bw =new_bw return (1) De seguida calcula iterativamente, os novos valores de largura de banda para todos os canais presentes, dividindo a largura de banda disponível pelo número de canais. Contudo é necessário verificar se ao retirar esse valor, os requisitos de largura de banda ainda são cumpridos. Para tal é percorrido o array redist_set e são verificados os requisitos e, quando o valor calculado viola os requisitos de um dos canais esse canal é removido de redist_set e todo o processo é repetido até que seja encontrado um valor que satisfaça os requisitos de largura de banda de todos os canais. Após este cálculo, se a largura de banda calculada for inferior à largura de banda minima este 20 Implementação método retorna 0, o que significa que não foi possível a adaptação. Se o valor calculado estiver de acordo com os requisitos minimos, é então alterado o valor da nova largura de banda para cada nó em redist_set e é retornado 1. É de notar que as câmaras, cujo valor após distribuição violou os requisitos não são incluídas em redist_set pois os seus valores de largura de banda não serão afetados. A implementação está detalhada no algoritmo 4.1.1. Quando uma câmara se desconecta é necessário distribuir pelas outras câmaras a largura de banda que ficou disponível, maximizando desta forma a utilização dos recursos. Numa primeira etapa, a câmara que desconectou será removida da base de dados e o valor da largura de banda que esta estava a usar é guardado em leftover que de seguida será distribuído pelas restantes câmaras. Esta distribuição pode ser feita de forma equitativa, distribuindo a mesma percentagem da largura de banda disponível a todas as câmaras. No entanto, se for atribuída mais largura de banda às câmaras com valores de compressão mais altos os valores de compressão nessas câmaras irá diminuir. Deste modo, a qualidade de serviço global do sistema irá melhorar. Considerando ¯qsum como sendo a soma dos valores de compressão de todas as câmaras, e ¯qio valor de compressão da câmara ifoi definido Pi=¯qi ¯qsum . É de notar que o valor de compressão ¯qé igual a 100−q, sendo qo fator de qualidade. Ao fazer a distribuição, Pidefine a percentagem da largura de banda que a câmara iirá receber. A implementação do algoritmo de distribuição está definida em 4.1.2. Algoritmo 4.1.2: REDIST_ON_REMOVE(node_id) comentário: Remove a câmara node_id do sistema e redistribui a sua largura de banda db_entry =channel_db_seach(node_id) le ftover=db_entry →actual_bw channel_db_channel_delete(db_entry) n←num_channels() redist_set set[n] copy_to_redist_set(set) for i←0to n do ¯qsum+=set[i].compression for i←0to n do (Pi= ¯qi/¯qsum set[i].new_bw=le ftover ∗Pi apply_qos_changes(set) Além da distribuição de largura de banda quando há conexão ou desconexão de câmaras, este modo é também responsável por receber pedidos de renegociação ou pedidos do utilizador para aumento ou diminuição de largura de banda. 4.1 Aplicação Monitor 21 No caso de um pedido de aumento, este método tenta aumentar a largura de banda da câmara em questão em 10%. Para tal, é necessário remover largura de banda dos restantes nós garantindo que os requisitos de todos os nós são cumpridos. Esta distribuição é feita iterativamente, recalculando a cada iteração a largura de banda a retirar a cada câmara. Numa primeira fase, irão ser contados os canais aos quais podemos retirar largura de banda. De seguida, é calculado o valor a retirar a cada canal. Se a largura de banda a retirar não garantir os requisitos o canal em questão é retirado de redist_set e a largura de banda é recalculada. Este processo ocorre até se encontrar um valor de largura de banda que garanta os requisitos de todos os canais aos quais vai retirar. Se não for possível retirar largura de banda suficiente para aumentar a largura de banda da câmara pedida este método retorna 0 e caso seja possível retorna 22 Implementação 1. A implementação está detalhada no algoritmo 4.1.3. Algoritmo 4.1.3: REDIST_ON_INCREASE(node_id,avail_bw) comentário: Redistribui a largura de banda quando há um pedido de aumento para a câmara node_id n←num_channels() comentário: Número de canais ligados redist_set set[n] copy_to_redist_set(set) comentário: Copia informação de todos os canais para o redist_set restart ←1 new_bw ←0 db_entry =channel_db_seach(node_id) initial_bw=(db_entry →actual_bw)bw_dist=(db_entry →actual_bw)∗0.1 while restart 6=0 do                                                    channel_count ←0 restart ←0 for i←0to n do (if set[i].node_id 6=0 do channel_count++ new_bw ←bw_dist/channel_count if new_bw =0 do return (0) for i←0to n do      if set[i].actual_bw-new_bw <set[i].required_bw do (restart ←1 set[i].node_id ←0 for i←0to n do            if set[i].node_id 6=0 do set[i].new_bw =set[i].actual_bw −new_bw if set[i].node_id =node_id do set[i].new_bw =initial+bw_dist return (1) Quando é feito um pedido de diminuição de largura de banda, é invocado o método redist_on_decrease() que irá remover 10% da largura de banda do canal em questão e irá distribuir por todas as outras câmaras. Foi escolhido um aumento de 10% pois é o suficiente para que seja possível notar a mudança de qualidade de imagem, pois com aumentos inferiores a este valor não é percetível a influência na qualidade da imagem. A distribuição é feita usando o mesmo método 4.1 Aplicação Monitor 23 que foi usado em 4.1.2 para dar mais largura de banda às câmaras com maior valor de compressão. A implementação deste método é detalhada no algoritmo 4.1.4. Algoritmo 4.1.4: REDIST_ON_DECREASE(node_id) comentário: Diminui a largura de banda da câmara node_id em 10% e redistribui db_entry =channel_db_seach(node_id) le ftover=(db_entry →actual_bw)∗0.1 n←num_channels() redist_set set[n] copy_to_redist_set(set) for i←0to n do ¯qsum+=set[i].compression for i←0to n do                      Pi= ¯qi/¯qsum if set[i].node_id =node_id do set[i].new_bw=set[i].actual_bw +le ftover ∗Pi else do set[i].new_bw=set[i].actual_bw −le ftover apply_qos_changes(set) Foram detalhados em cima os 4 métodos implementados para a gestão de QoS, mas após o cálculo das larguras de banda de todos os canais é necessário guardar esses valores na base de dados , e de seguida mapear para os valores(C,T)correspondentes como discutido no Capitulo 3. Para tal foi implementado o método apply_qos_changes() que recebe como valor de entrada oredist_set calculado após a distribuição e faz as alterações na base de dados. De seguida este método invoca a função que faz o mapeamento dos valores de largura de banda para os parâmetros da rede FTT. Este mapeamento pode ser feito de várias formas, visto que a um valor de largura de banda podem corresponder vários pares (C,T)diferentes. Para tal, foi fixado neste gestor de QoS um conjunto discreto de períodos e o mapeamento será feito tentando maximizar o tamanho do canal. 30 Implementação à aplicação Monitor para tentar aumentar a largura de banda do canal associado com a câmara. De uma forma análoga quando a largura de banda gerada está abaixo do limite inferior W∗(1−3δ), o contador over_cnt é incrementado e quando isto acontece QCT vezes seguidas é feito um um pedido de renegociação à aplicação monitor para retirar largura de banda do canal associado com a câmara. A certo ponto é produzida uma frame kque gera uma largura de banda Rkque está dentro do intervalo: W(1−3δ)≤Rk≤W(1−δ)(4.1) De seguida, a próxima frame (k+1) é produzida. Se a condição 4.1 se verificar, o fator de qualidade não é alterado, como discutido anteriormente. Caso isto não aconteça é necessário adaptar o fator de qualidade, qk+1, baseado na variação de R(q)entre as frames kek+1, i.e, ∆Rk,k+1. De seguida é então calculado o valor de qk+1que será usado aquando da quantificação da frame k+2 (ver Figura 2.3). Para tal, num primeiro passo, seguindo o procedimento em [15], é necessário recalcular como deve mudar βkde tal modo que a estimativa seja aproximada ao pretendido. βk+1=∆Rk,k+1qλ+βk(4.2) Por fim, usado o valor de Rk+1obtido será calculado o fator de qualidade, qk+1que será usado para gerar a frame k+2: qk+1=Rk+1−α βk+1−1/λ (4.3) Os métodos qosRenegotiateMoreBW() eqosRenegotiateLessBW() são responsáveis por enviar um código de controlo ao monitor para a renegociação. A implementação do módulo de QoS está detalhada no algoritmo 4.2.1. Este mecanismo possibilita uma gestão de QoS que tenta minimizar desperdícios de largura de banda, sem comprometer os requisitos mínimos e máximos das câmaras. Capítulo 5 Testes e Resultados Este capitulo apresenta os resultados dos testes realizados. Aborda os testes para a modelação de R(q)e apresenta um cenário de funcionamento do sistema com duas câmaras. 5.1 Modelo R(q) Como foi discutido no Capitulo 3o módulo de QoS da aplicação câmara usa o modelo R(q) para estimar um valor do fator de qualidade baseado na largura de banda que tem disponível. No entanto, este modelo varia consoante o tipo de cenário que está a ser capturado. Como foi mencionado no Capitulo 2, numa aplicação de monitorização industrial as frames capturadas apresentam grande similaridade entre si, de modo que se considera que os parâmetros αeλdo modelo R(q) são constantes e que o valor de βirá ser adaptado dinamicamente quando há um adaptação de q no gestor QoS da aplicação câmara, como descrito no Capitulo 4. Foram então considerados três cenários de teste diferentes, o primeiro para inferir o impacto da iluminação no modelo R(q), o segundo para inferir o impacto da variabilidade do conteúdo da imagem, e o último para testar a validade da adaptação dinâmica do parâmetro βdo modelo R(q). As frames apresentadas nas figuras foram capturadas com fator de qualidade 70. Para tal foi capturada uma frame para cada cenário e foi usado o compressor JPEG para todos os valores de qualidade possíveis (de 1 a 100) para obter os valores de largura de banda produzidos, considerando um período de transmissão de 60ms. Para o último teste, foi usada a frame de baixa complexidade e foi acrescentada uma pessoa à mesma cena de modo a provocar uma alteração de cenário. De seguida foram obtidos os parâmetros de R(q)usando o Microsoft Excel para a minimização do erro quadrático médio. Os resultados obtidos para o primeiro teste são apresentados nas figuras 5.1 e5.2. Como é possível observar nos resultados obtidos, a aproximação que se obteve para R(q)está bastante próxima dos valores experimentais. Vê-se ainda que a similaridade entre os dois modelos 31 32 Testes e Resultados 0 500 1000 1500 2000 2500 3000 10 20 30 40 50 60 70 80 90 100 Largura de Banda (KBytes/s) Fator de Qualidade Dados Experimentais Previsão (a) Dados de R(q) num cenário com baixa iluminação (b) Frame Usada Figura 5.1: Cenário de Baixa Iluminação 0 500 1000 1500 2000 2500 3000 10 20 30 40 50 60 70 80 90 100 Largura de Banda (KBytes/s) Fator de Qualidade Dados Experimentais Previsão (a) Dados de R(q) num cenário com iluminação normal (b) Frame Usada Figura 5.2: Cenário de Iluminação Normal obtidos para iluminações diferentes é notável pelo que é possível concluir que a iluminação não tem um impacto muito significativo neste modelo. Para o segundo teste, foram então usados dois cenários onde a diferença de complexidade visual entre ambos fosse elevada. No primeiro cenário foi capturada uma zona com poucas variações de cor e com poucos objetos, enquanto que no segundo cenário foi capturada uma zona com bastantes objetos de várias cores. Os resultados obtidos para o segundo teste são apresentados em 5.3 e5.4. 0 500 1000 1500 2000 2500 3000 10 20 30 40 50 60 70 80 90 100 Largura de Banda (KBytes/s) Fator de Qualidade Dados Experimentais Previsão (a) Dados de R(q) num cenário com baixa complexidade visual (b) Frame Usada Figura 5.3: Cenário de Baixa Complexidade Visual É possível verificar que em cenários de mais complexidade visual a largura de banda gerada é 5.1 Modelo R(q)33 0 500 1000 1500 2000 2500 3000 3500 10 20 30 40 50 60 70 80 90 100 Largura de Banda (KBytes/s) Fator de Qualidade Dados Experimentais Previsão (a) Dados de R(q) num cenário com alta complexidade visual (b) Frame Usada Figura 5.4: Cenário de Alta Complexidade Visual maior do que em cenários de menor complexidade para valores mais altos de qualidade, tal como era previsto. São apresentados na tabela 5.1 os valores obtidos para todos os parâmetros em cada cenário de teste. O último cenário de teste consistiu em usar a frame capturada num cenário de baixa complexidade visual e inserir um ator no cenário de modo a que a complexidade visual aumentasse. Ambas as frames usadas podem ser vistas na figura 5.5. (a) Frame 1 (b) Frame 2 Figura 5.5: Cenário de Alteração de Complexidade Para testar a validade do modelo neste cenário, foi necessário testar o impacto da adaptação do parâmetro βaquando a mudança de cena. Para este cenário foi considerado q=50 aquando da adaptação. Como é possível verificar na figura 5.6, ao manter os parâmetros αeλ(sendo α= -232824 e λ= 0,456) e alterando o valor de βo modelo R(q)vai-se aproximar bastante do modelo previsto para a frame 2. Nota-se que em valores de qualidade mais baixos a aproximação é melhor, e piora quando os valores de qualidade são mais altos. De seguida foi testado o impacto dos parâmetros αeλ. Para tal usaram-se os valores de αe λda frame 2 e a previsão de βcalculada anteriormente. Como é possível verificar na figura 5.7 , αeλtêm algum impacto para valores de qualidade menores. No entanto aproximando apenas β obtém-se um modelo bastante próximo do modelo real do cenário da frame 2. 34 Testes e Resultados 0 500 1000 1500 2000 2500 3000 3500 111 21 31 41 51 61 71 81 91 Largura de Banda (KBytes/s) Fator de Qualidade R(q) da frame 1 com baixa complexidade R(q) exato da frame 2 com média complexidade R(q) estimado para a frame 2 após aumento da complexidade da imagem (complexidade média) Figura 5.6: Resultado da adaptação de βpara q= 50 0 500 1000 1500 2000 2500 3000 3500 111 21 31 41 51 61 71 81 91 Largura de Banda (KBytes/s) Fator de Qualidade R(q) após alteração apenas de Beta R(q) após alteração de beta, alpha e lambda Figura 5.7: Resultado da adaptação de βpara q= 50, e usando os valores de αeλda frame 2 Estes resultados mostram que ao adaptar o valor do parâmetro βdinamicamente obtém-se um modelo R(q)dinâmico, mais robusto a variações de conteúdo e torna possível aplicar esta arquitetura em variados cenários de vigilância industrial. 5.2 Teste Operacional do Sistema 35 Cenário α β λ Baixa Iluminação -162778 2924062 0,55 Iluminação Normal -246558 3037886 0,45 Baixa Complexidade -232842 3008203 0,46 Alta Complexidade -520142 3848216 0,37 Média Complexidade -414678 3573713 0,39 Tabela 5.1: Valores dos parâmetros para os diferentes cenários de teste 5.2 Teste Operacional do Sistema Para testar o funcionamento do sistema desenvolvido foi considerado um cenário com duas câmaras, com um limite de largura de banda para o teste operacional de 2Mbps e um período de transmissão mínimo de 60ms. Numa fase inicial apenas a câmara 1 está ligada e passado algum tempo é ligada a câmara 2. De seguida é aumentada a largura de banda da câmara 1 em 10% e por fim é desligada a câmara 1. A figura 5.8 apresenta a evolução da largura de banda utilizada por cada câmara. Como é possível verificar na figura 5.8 durante aproximadamente 1800 frames, o que equivale a aproximadamente 2 minutos com um período de transmissão de 60ms, a câmara 1 usa toda a largura de banda disponível, pois apenas esta está ligada. Aquando da ligação da câmara 2 a largura de banda é distribuída pelas 2 câmaras , pelo que a largura de banda usada pela câmara 1 passa para aproximadamente metade. Ao aumentar a largura de banda da câmara 1, nota-se o impacto na câmara 2 que perde cerca de 10% de largura de banda que foi alocada para a câmara 1. Por fim a câmara 1 é desligada e nota-se que a câmara 2 passa a usar toda a largura de banda disponível. 36 Testes e Resultados Figura 5.8: Evolução da largura de banda das câmaras Capítulo 6 Conclusão O propósito desta dissertação foi criar um sistema de monitorização de vídeo em tempo-real e para cenários industriais, com um controlo dinâmico de Qualidade de Serviço, tirando partido do protocolo de rede FTT-SE. Para tal foi concebida uma arquitetura que tornasse possível a implementação deste sistema e que cumprisse os objetivos propostos. A arquitetura proposta contém todos os mecanismos e algoritmos necessários para a gestão dos recursos da rede, em particular de canais, incluindo controlo de admissão de câmaras e controlo de larguras de banda. Esta solução, quando comparada com os sistemas de monitorização de vídeo convencionais, apresenta isolamento entre transmissões de vídeos distintos conseguido com a utilização de canais FTT, assim como uma gestão dinâmica da largura de banda desses canais que permite maximizar o uso da largura de banda disponível eliminando a necessidade de sub ou sobre-dimensionamento de canais de comunicação. Um aspeto particularmente importante é a utilização de um modelo R(q)que relaciona o fator de qualidade da codificação JPEG com o tamanho da respetiva frame. Os resultados obtidos mostram que o modelo R(q)é um modelo robusto e viável para a gestão de QoS proposta para este sistema, e que a arquitetura implementada cumpre todos os requisitos de funcionalidade. 6.1 Trabalho Futuro O trabalho desta dissertação pode ser continuado de diversas formas, por forma a completar ou complementar aspetos que não puderam ser explorados por falta de tempo. Um aspeto que seria interessante explorar seria a identificação de todos os parâmetros do modelo R(q)online, permitindo desta forma ter sempre a melhor aproximação possível o que introduziria robustez e eliminaria a necessidade de fazer esta modelação para diferentes cenários. Isto possibilitava a utilização desta aplicação em ambientes em que há mudanças constantes no cenário. 37 38 Conclusão Outro aspeto a estudar seria permitir o uso de câmaras IP, criando uma gateway entre a câmara e a aplicação que convertesse pacotes IP para pacotes FTT. Visto que estas são muito frequentes em monitorização de vídeo, isto permitiria implementar esta arquitetura de gestão dinâmica de QoS com controlo de largura de banda em cenários onde as câmaras IP são utilizadas. Um outro aspeto a considerar seria a interface com o utilizador, visto que a interface criada neste trabalho é muito simples. Poder-se-ia assim criar uma interface gráfica mais apelativa e funcional, como por exemplo poder agrupar conjuntos de streams numa só janela ou usar uma interface touch screen para o controlo dos streams individuais. Finalmente, seria também interessante implementar esta arquitetura de controlo sobre o middleware iLAND, que permitiria construir aplicações reconfiguráveis, orientadas a serviços, com ajuste dinâmico da largura de banda utilizada nas ligações dos serviços. Anexo A API CommonBridge Este anexo contém os detalhes da API CommonBridge usada para a comunicação com a interface aplicacional do FTT-SE. A API CommonBridge foi desenvolvida com o intuito de fornecer uma interação com a interface aplicacional do protocolo FTT-SE, e fornecer um nível de abstração mais elevado ao nível da aplicação. Esta API contém um conjunto de métodos que passo a descrever. •FTTSE_Init Este método inicializa o protocolo FTT-SE na interface de rede ifface que lhe é fornecida. •FTTSE_Shutdown Este método tem como função terminar o protocolo FTT-SE •FTTSE_Create_Channel Este método tem como função criar uma canal de comunicação FTT •FTTSE_Register_Tx Este método permite à aplicação registar-se como produtor num canal FTT especificado •FTTSE_Register_Rx Este método permite à aplicação registar-se como consumidor num canal FTT especificado •FTTSE_Destroy_Channel Este método permite à aplicação destruir um canal FTT especificado •FTTSE_UnRegister_Tx Este método permite à aplicação cancelar o registo como produtor num canal FTT especificado •FTTSE_UnRegister_Rx Este método permite à aplicação cancelar o registo como consumidor num canal FTT especificado 39