Estudo de viabilidade para utilização da Webcam como Sensor de Luminosidade para controle do Backlight do Monitor

Estudo de viabilidade para utilizac¸a˜ o da Webcam como Sensor de Luminosidade para controle do Backlight do Monitor Glauco Gomes1 , Igor Gavriloff1 1

CITS – Centro Internacional de Tecnologia de Software Rua do Semeador, 702 - CEP 81270-050 - Curitiba - Paran´a - Brasil [email protected], [email protected]

Abstract. This study demonstrates the feasibility of using a Webcam as an Ambient Light Sensor (ALS) device for automatic backlight control of notebooks according to the ambient brightness. The result is to determine the possibility of achieving significant gains through power management to preserve notebook capacity and battery life, as well as reducing production costs. To explore this scenario, we use the native Linux and Windows APIs for Power Management and Sensors to automatically adjust the monitor backlight for optimal brightness, according to ambient lighting conditions. Resumo. Este estudo demonstra a viabilidade de utilizar uma Webcam como um Sensor de Luminosidade para controle autom´atico do backlight de notebooks de acordo com o brilho identificado no ambiente. O resultado pretende determinar a possibilidade de conseguir importantes ganhos atrav´es do gerenciamento de energia para preservar a capacidade e vida u´ til da bateria dos notebooks, bem como a reduc¸a˜ o os custos de produc¸a˜ o. Para explorar este cen´ario, utilizamos as APIs nativas do Linux e Windows para Gerenciamento de Energia e Sensores para ajustar automaticamente o backligth do monitor do notebook para um configurac¸a˜ o de brilho ideal, conforme as condic¸o˜ es de iluminac¸a˜ o do ambiente.

1. Introduc¸a˜ o O recurso de gerenciamento autom´atico da luminosidade em notebooks e´ exclusivamente realizado atrav´es de sensores espec´ıficos e propriet´arios. Os diversos fabricantes disponibilizam este recurso apenas em seus modelos de notebooks mais caros, considerados como topo da linha (high-level). Apesar do maior custo na produc¸a˜ o de equipamentos com este recurso, uma vez que h´a necessidade de adicionar um componente sensor para realizar esta func¸a˜ o, os fabricantes o disponibilizam como diferencial competitivo que pode influenciar na decis˜ao de compra do consumidor final. Este estudo de viabilidade pretende investigar esta tecnologia e avaliar a utilizac¸a˜ o da Webcam, dispositivo presente na maioria dos notebooks, como sensor de luminosidade para controle autom´atico do backlight do monitor, regulando seu brilho conforme as condic¸o˜ es de luminosidade do ambiente. A partir do resultado encontrado, espera-se que o gerenciamento autom´atico da luminosidade nos monitores dos notebooks seja acess´ıvel para modelos de notebooks mais simples (entry-level), contribuindo ainda na preservac¸a˜ o da capacidade e vida u´ til da bateria destes equipamentos.

1.1. Objetivo e Escopo Os objetivos do estudo e escopo do trabalho de pesquisa, em raz˜ao da sua abrangˆencia, s˜ao claramente identificados a seguir: • • • •

Compreender e realizar o levantamento de formas de controlar o backlight. Estudar possibilidade de utilizar uma Webcam como sensor de luminosidade. Realizar levantamento de outras tecnologias j´a existentes com este prop´osito. Investigar a utilizac¸a˜ o concorrente da Webcam como sensor e como dispositivo de captura. • Avaliar como obter os parˆametros de luminosidade a partir da imagem capturada pela Webcam • Obter os dados de gest˜ao de energia do sistema operacional. • Determinar a possibilidade de integrar a soluc¸a˜ o ao sistema de gest˜ao de energia do sistema operacional,para trac¸ar perfis de pr´e-configurac¸o˜ es de luminosidade.

2. Abreviaturas e Definic¸o˜ es Siglas e Abreviac¸o˜ es ACPI Advanced Configuration and Power Interface. 3–5, 7, 9, 12, 18, 27, 28 ALR Ambient Light Response. 9 ALS Ambient Light Sensor. 12, 14, 28, 34 API Application Programming Interface. 4, 5, 8, 24, 25, 27–30, 34 BIOS Advanced Configuration and Power Interface. 3–5, 9, 12, 27 CCD Charge-Coupled Device. 14 CMOS Complementary Metal-Oxide-Semiconductor. 14 CPU Central Processing Unit. 6–8, 34 DDC/CI Display Data Channel / Command Interface. 3, 5 FPS Frames per Second. 7 I2C/SMBus I2C Bus ou Inter IC ou IIC / System Management Bus. 3, 5, 12, 27 LED Light Emitter Diode. 9 VESA Video Electronics Standards Association. 3 WDM Windows Driver Model. 22, 23, 27 XML eXtensible Markup Language. 30, 31, 33

Nomenclaruras backlight Iluminac¸a˜ o do painel de monitores LCD. 1–6, 9, 10, 12, 27, 29, 30, 32 daemon Programa executado como processo em segundo plano. 18, 34 driver Arquivo que cont´em as func¸o˜ es a serem integradas a um sistema operacional para controlar um determinado perif´erico. 12, 15, 18, 22, 23, 27 kernel N´ucleo ou parte principal de um sistema operacional. 4, 26, 27, 35 lux Unidade de iluminˆancia. 9, 12 pixel Ponto luminoso do monitor. Menor unidade de uma imagem digital. 10, 11 2

3. Controle de Luminosidade no Monitores A implementac¸a˜ o nos monitores que apresentam recurso de controle do backlight e´ , normalmente, propriet´aria. Entretanto, para homologar um hardware como ”Compat´ıvel com o Windows Vista”, a Microsoft estabeleceu uma diretiva [Microsoft(2009c)] trazendo a necessidade de o fabricante prover uma Advanced Configuration and Power Interface (ACPI) BIOS [Microsoft(2009a)] compat´ıvel e funcional que inclua o controle do backlight do monitor. Com isto, novos hardwares poder˜ao ser controlados atrav´es de uma interface comum e centralizada. 3.1. Monitores de Desktops Os monitores de v´ıdeo possuem uma conex˜ao bidirecional atrav´es de um barramento serial I2C Bus ou Inter IC ou IIC / System Management Bus (I2C/SMBus) pelo qual e´ realizada a comunicac¸a˜ o com o PC. A placa de v´ıdeo e´ a respons´avel de apresentar ao sistema operacional uma interface de comunicac¸a˜ o. A interface de comunicac¸a˜ o entre o PC e o monitor de v´ıdeo e´ padronizada (Video Electronics Standards Association (VESA) 2004-10), denominada Display Data Channel / Command Interface (DDC/CI). Esta interface permite tanto configurar parˆametros no monitor assim como obter informac¸o˜ es do mesmo. Alguns parˆametros s˜ao normatizados, entretanto outros s˜ao propriet´arios do fabricante do monitor. O parˆametro de controle de brilho da tela e´ um parˆametro num´erico cuja faixa de valor – e o brilho que este valor representa – varia conforme o fabricante, podendo variar at´e mesmo entre diferentes modelos de um mesmo fabricante.

Figura 1. Controle do monitor externo

3.2. Monitores de Notebooks Neste tipo de equipamento o controle do backlight pode ocorrer tanto por DDC/CI para equipamentos legados assim como por controle da Advanced Configuration and Power Interface (BIOS) ACPI em equipamentos recentes. Para os casos em que o controle se d´a via DDC/CI os comandos normalmente s˜ao propriet´arios do fabricante. J´a nos casos em que o controle se d´a pelo ACPI o controle 3

e´ padronizado e poss´ıvel de ser utilizado nativamente por Application Programming Interfaces (APIs) existentes no sistema operacional (tanto no Windows – a partir do Vista – como no Linux).

Figura 2. Controle do monitor no Linux

3.3. Controle do Monitor no Linux O controle de luminosidade do monitor pelo Linux pode ser realizado atrav´es do subsistema ACPI deste sistema operacional. Este subsistema encarrega-se de realizar toda a comunicac¸a˜ o para com o monitor, codificando e interpretando todos os dados. E´ necess´ario que a BIOS ACPI disponibilize as informac¸o˜ es de backlight ao kernel para que esta funcionalidade esteja presente. As informac¸o˜ es de brilho neste subsistema possuem uma representac¸a˜ o textual bastante clara. Eis um exemplo da leitura de capacidade de um monitor: # cat /proc/acpi/video/VGA/LCD/brightness levels: current:

0 10 20 30 40 50 60 70 70

Para alterar o brilho um simples comando e´ capaz de realizar esta tarefa: # echo -n 60 > /proc/acpi/video/VGA/LCD/brightness Uma interface alternativa recentemente implementada tamb´em est´a dispon´ıvel: # cat /sys/class/backlight/acpi video0/max brightness 7 # cat /sys/class/backlight/acpi video0/actual brightness 6 # cat /sys/class/backlight/acpi video0/brightness 6 4

3.4. Controle do Monitor no Windows 3.4.1. Windows XP Este sistema operacional n˜ao possui suporte nativo para controlar o monitor via DDC/CI nem via ACPI. Como este sistema operacional saiu de linha, soluc¸o˜ es para ele n˜ao ser˜ao estudadas. 3.4.2. Windows Vista e superiores Uma nova API disponibilizada pela Microsoft foi introduzida no sistema operacional Windows Vista. Esta API e´ denominada Monitor Configuration [Microsoft(2009d)]. Ela oferece algumas rotinas de alto n´ıvel para lidar com a BIOS ACPI. Existe tamb´em a possibilidade de realizar um acesso de baixo n´ıvel ao barramento I2C/SMBus nos casos em que os controles s˜ao propriet´arios do fabricante. Com esta API o controle de brilho do monitor e´ bastante simples. A utilizac¸a˜ o desta API se d´a atrav´es de c´odigo em linguagem C [Wikipedia(2009b)]. Abaixo, pseudoc´odigo para realizar a manipulac¸a˜ o do brilho do monitor neste sistema operacional: EnumDisplayMonitors GetPhysicalMonitorsFromHMONITOR GetMonitorCapabilities if (MC CAPS BRIGHTNESS) { GetMonitorBrightness SetMonitorBrightness }

4. Variac¸a˜ o da Iluminac¸a˜ o do Monitor conforme o Ambiente A utilizac¸a˜ o de um dispositivo de sensoriamento de luminosidade para controlar o brilho do monitor permite obter um aumento na durac¸a˜ o da carga da bateria de at´e 41%, segundo afirmac¸a˜ o da Capella Microsystems, Inc [The Free Library(2009)]. 4.1. Durac¸a˜ o da Bateria em Relac¸a˜ o a` Iluminac¸a˜ o do Monitor Para avaliar qual o real impacto que uma gest˜ao da iluminac¸a˜ o do monitor conforme a luminosidade do ambiente teria na durac¸a˜ o da bateria, realizaram-se dois ensaios de descarga da bateria. O equipamento utilizado foi um notebook Positivo Mobile [TecMundo(2009)]1 . Em ambos os ensaios, os sistemas de economia de energia foram desativados. Cada ensaio foi realizado especificamente sob uma condic¸a˜ o diferente da iluminac¸a˜ o do monitor. 1

Positivo Mobile T457P: Intel Core i3, 500GB HD, 4GB RAM DDR3, monitor LED backlight 14,1”, som e Webcam integrados.

5

˜ Figura 3. Carga da bateria em duas condic¸oes do backlight do monitor

As curvas obtidas no ensaio (Figura 3) s˜ao coerentes com o resultado esperado: o monitor com o grande brilho (backlight no m´aximo, n´ıvel 7) durou menos do que com um brilho m´ınimo. O valor m´ınimo considerado foi a menor iluminac¸a˜ o do backlight em que ainda era poss´ıvel ler o conte´udo presente na tela (n´ıvel 1). O monitor era capaz de apresentar uma iluminac¸a˜ o menor, contudo a tela tornava-se ileg´ıvel. O ganho apurado na durac¸a˜ o da bateria foi de aproximadamente 20%, valor este consideravelmente distante do valor que os fabricantes alegam conseguir com sensores dedicados [The Free Library(2009)]. O ganho real a ser obtido e´ fortemente dependente conforme o ambiente em que o equipamento ser´a utilizado (ex.: um local escuro, ou um local bem iluminado). 4.2. Utilizando uma Webcam como Sensor de Luminosidade A Webcam e´ um dispositivo que est´a presente na grande maioria dos notebooks modernos. Havendo a possibilidade de utiliz´a-la como sensor de luminosidade, torna-se desnecess´aria a implantac¸a˜ o de um dispositivo adicional e ainda consegue-se agregar valor ao equipamento. Em contrapartida, n˜ao e´ poss´ıvel obter um valor padronizado, o que exigiria uma calibrac¸a˜ o espec´ıfica para os diferentes modelos de Webcams existentes nos notebooks. 4.2.1. Energia consumida para realizar o processamento da imagem Para estudo do consumo da Webcam e da Central Processing Unit (CPU) foram criados dois programas que realizam a captura da imagem e descartam o conte´udo capturado, sendo um destes programas desenvolvido para Linux e o outro para Windows. O programa realiza a captura constante de imagens da Webcam a` uma taxa de um quadro por 6

segundo (1 Frames per Second (FPS)). Este software tem o u´ nico objetivo de servir de base para se determinar qual e´ o impacto que a Webcam e a CPU do notebook causam na durac¸a˜ o da bateria. No Linux e´ poss´ıvel obter informac¸o˜ es da bateria com facilidade. Estes dados s˜ao disponibilizados pelo sistema ACPI, acess´ıvel pelo caminho /proc/acpi/battery. O procedimento realizado consistiu em monitorar a carga remanescente da bateria, pois esta e´ a u´ nica informac¸a˜ o disponibilizada – a tens˜ao presente e a corrente n˜ao s˜ao fornecidas pela bateria do modelo de notebook utilizado (Positivo Mobile). Inicialmente, fez-se um ensaio com os valores obtidos do ACPI quanto a` carga da bateria para verificar se estes eram confi´aveis. Cada um destes ensaios foi realizado em espac¸os de tempo de 5 (cinco) minutos. Estes ensaios podem ser visualizados na Figura 4. Para analisar se h´a um “efeito mem´oria” da bateria quando ela e´ descarregada e recarregada, duas descargas com a mesma caracter´ıstica de carga foram realizadas. O resultado foi de que ou n˜ao h´a efeito mem´oria, ou o mesmo e´ desprez´ıvel. Um segundo ensaio para determinar se os dados eram coerentes consistiu em realizar descargas da bateria sob diferentes condic¸o˜ es de utilizac¸a˜ o da CPU: sistema totalmente ocioso (apenas atividade de disco e atualizac¸a˜ o a interface gr´afica), metade de utilizac¸a˜ o (apenas um dos n´ucleos do processador) e utilizac¸a˜ o completa (com os dois n´ucleos do processador). O resultado foi novamente aprovado qualitativamente, pois, conforme se aumentava a carga de processamento, mais r´apida era a descarga da bateria (e consequentemente menor o tempo de durac¸a˜ o desta).

˜ Figura 4. Curva de descarga parcial da bateria em diferentes condic¸oes de carga da CPU

O software para Linux obteve um desempenho tal que a utilizac¸a˜ o de CPU ficou ligeiramente abaixo de 1% de utilizac¸a˜ o. O sistema em repouso (sem este software) consome cerca de 3% devido a` s atividades de disco, atualizac¸a˜ o da tela pelo ambiente gr´afico e demais ac¸o˜ es do sistema. Para avaliar o impacto deste software na durac¸a˜ o da bateria, realizaram-se dois novos ensaios que consistiam em deixar a m´aquina ligada at´e a descarga total da bateria. Em ambos os ensaios, os recursos de economia de energia foram 7

desabilitados para haver um consumo de energia constante. No primeiro ensaio a m´aquina foi deixada ligada com o software de captura da Webcam desenvolvido em execuc¸a˜ o; e no segundo ensaio a m´aquina permaneceu ociosa (apenas atividades de disco, ambiente gr´afico, etc). Houve um problema no registro dos dados no ensaio da m´aquina ociosa, por este motivo a curva para este foi extrapolado no gr´afico. Os resultados destes ensaios podem ser visualizados na Figura 5 e na Figura 6. O que se pode observar e´ que o software causou muito pouco impacto na durac¸a˜ o da bateria: a durac¸a˜ o da bateria foi reduzida em apenas 3 (trˆes) minutos aproximadamente.

Figura 5. Curva de descarga completa da bateria

˜ visual e Figura 6. Curva de descarga completa da bateria com aproximac¸ao ˜ da curva sem Webcam extrapolac¸ao

J´a o software para Windows teve um desempenho insatisfat´orio: a simples captura de imagem consumiu 22% da CPU. A causa desse resultado pode ter sido a API utilizada para realizar a captura (AVICAP). Existe a chance de que com um estudo mais aprofundado para encontrar uma API mais recente utilizando D IRECT X 2 a performance possa ser aprimorada. 2

M ICROSOFT D IRECT X. Colec¸a˜ o de APIs que tratam de tarefas relacionadas a programac¸a˜ o de jogos para o sistema operacional Microsoft Windows [Wikipedia(2009a)].

8

4.2.2. Obtenc¸a˜ o de luminosidade atrav´es da Webcam As Webcams realizam a medic¸a˜ o do n´ıvel de iluminac¸a˜ o do ambiente atrav´es do pr´oprio sensor de captura de imagens. Esta informac¸a˜ o n˜ao e´ repassada ao host (computador hospedeiro) – com excec¸a˜ o da pr´opria imagem j´a regulada pela cˆamera. Algumas das cˆameras possuem Light Emitter Diodes (LEDs) de iluminac¸a˜ o para quando o ambiente est´a escuro. Neste caso a informac¸a˜ o tamb´em permanece apenas internamente na cˆamera. A alternativa para realizar uma medic¸a˜ o da iluminac¸a˜ o do ambiente e´ em se obter a imagem que a cˆamera est´a capturando e realizar um processamento nesta imagem por software. O valor obtido por esta an´alise n˜ao ser´a a grandeza lux [Wikipedia(2009f)], ir´a representar numericamente uma percepc¸a˜ o de luminosidade. A curva desta representac¸a˜ o num´erica dever´a ser mapeada subjetivamente quanto ao n´ıvel de luminosidade que o ambiente se encontra e qual o respectivo ajuste necess´ario no backlight do monitor. Este mapeamento e´ semelhante ao Ambient Light Response (ALR) proposto pela especificac¸a˜ o ACPI BIOS 3.0b (pag. 282) – diferenciando-se apenas que a especificac¸a˜ o baseia-se em lux e o valor num´erico computado a partir da imagem e´ arbitr´ario. Por exemplo, a Tabela 1, a seguir, exemplifica uma representac¸a˜ o hipot´etica desta curva: Valor Computador Representac¸a˜ o Brilho Relativo do Backlight 125 Ambiente muito claro 10% ˜ do valor computado com a luminosidade perTabela 1. Exemplo de associac¸ao cebida

Uma Webcam pode operar em dois modos no que diz respeito a` luminosidade: com ou sem controle autom´atico de luminosidade. Quando a cˆamera est´a trabalhando com controle autom´atico de luminosidade, ela ir´a fazer internamente o ajuste dos controles de brilho e contraste da imagem. Os valores destes controles ajustados pela cˆamera n˜ao s˜ao acess´ıveis pelo host (computador hospedeiro). Como uma mudanc¸a nestes controles modificam a luminˆancia da imagem capturada, este modo n˜ao e´ adequado para a finalidade desejada. Resta ent˜ao a utilizac¸a˜ o da cˆamera com controle manual de brilho e contraste. Se a cˆamera estiver sendo usada apenas com o prop´osito de sensor de iluminac¸a˜ o do ambiente, esta abordagem e´ v´alida. Entretanto esta abordagem deixa de ser v´alida caso se queira utilizar a cˆamera simultaneamente como um dispositivo de captura de imagem padr˜ao (em programas tais como M SN, S KYPE, G OOGLE TALK, dentre outros). Nesta situac¸a˜ o em que os controles est˜ao fixos, distorc¸o˜ es na imagem podem ocorrer (imagem muito clara ou muito escura, por exemplo) causando uma insatisfac¸a˜ o do usu´ario. Assim, ou a cˆamera retorna ao modo autom´atico (ou ao que o programa de v´ıdeo-chamada solicitar) e o mecanismo de sensoriamento de iluminac¸a˜ o deixa de atuar (j´a que os controles de brilho estar˜ao “descalibrados”); ou ent˜ao se implementa um mecanismo “autom´atico” dos controles via software. Esta implementac¸a˜ o, entretanto, aumentar´a consideravelmente a complexidade do sistema de sensoriamento. Al´em de ser necess´ario desenvolver um algoritmo para realizar este controle “autom´atico” do brilho, a curva de percepc¸a˜ o levantada ter´a que levar 9

em considerac¸a˜ o tamb´em o efeito que estes controles causam na luminˆancia dos pixels [Wikipedia(2009g)], possivelmente gerando uma fam´ılia de diferentes curvas para os diferentes valores dos controles. 4.2.3. Processamento de imagem para obter a luminosidade do ambiente O processo proposto para realizar o controle do backlight do monitor consiste em capturar a imagem, obter um valor num´erico que represente a luminosidade desta imagem, associar este valor ao brilho do monitor conforme uma curva e realizar o ajuste do monitor propriamente dito. O diagrama apresentado na Figura 7 representa este processo:

Figura 7. Diagrama do conceito implementado

A curva que associa a luminosidade da imagem capturada com o brilho desejado do monitor e´ levantada subjetivamente. E´ certo que esta curva ser´a diferente conforme o modelo de webcam utilizado na captura de imagem e tamb´em do monitor do equipamento. As formulac¸o˜ es para realizar o c´alculo da luminosidade (brilho) da imagem capturada s˜ao apresentadas no artigo ”Brightness Calculation in Digital Image Processing” [Sergey Bezryadin(2007)]. A primeira abordagem para obter o parˆametro num´erico da luminosidade calculada atrav´es da imagem capturada foi atrav´es de histograma de imagem. Um histograma e´ uma curva que representa em valores discretos a quantidade de pixels (eixo-y) que apresentaram um determinado valor (eixo-x). Os valores dos pixels (eixo-x) e´ o brilho do pixel. O brilho para este caso foi obtido atrav´es de uma m´edia aritm´etica das componentes R (red), G (green) e B (blue) do pixel (Equac¸a˜ o 1). B = (R + G + B)/3

(1)

Nos testes foram utilizadas as Webcams de 3 (trˆes) notebooks (1 Dell, e 2 Positivo Inform´atica) e 3 (trˆes) Webcams externas USB (2 gen´ericas e 1 Creative Labs). Todas as cˆameras utilizadas nos testes possu´ıam auto-brilho embutido. Existem algumas cˆameras no mercado em que e´ poss´ıvel desabilitar este recurso, no entanto, nestas cˆameras que estavam a disposic¸a˜ o n˜ao havia esta possibilidade (n˜ao permitem desabilitar). A atuac¸a˜ o do mecanismo de auto-brilho pode ser acompanhado na Figura 8. Nesta ilustrac¸a˜ o mostra-se 3 quadros capturados quando a cˆamera foi tirada de um ambiente claro para um ambiente escuro. A imagem capturada, o histograma associado e o centro do histograma s˜ao mostrados em cada coluna. Em todos os casos, o controle de auto-brilho das cˆameras fazia que os centros dos histogramas sempre estivessem pr´oximos mesmo sob diferentes condic¸o˜ es de iluminac¸a˜ o (Figura 9). Este comportamento causado pelo auto-brilho inviabiliza a implementac¸a˜ o. 10

ˆ ˜ do autoFigura 8. Sequencia de quadros de ambiente escuro mostrando atuac¸ao ˆ brilho da camera

ˆ ´ Figura 9. Sequencia de quadros com diferentes ambientes e valor medio do histograma

A segunda abordagem experimentada utiliza a formulac¸a˜ o de BCH (Equac¸o˜ es 2 e 3) para calcular o brilho dos pixels. Esta formulac¸a˜ o aproxima-se melhor da percepc¸a˜ o do olho humano. Na m´etrica empregada, os parˆametros X, Y e Z s˜ao respectivamente os valores R, G e B dos pixels. Nesta abordagem o valor de luminosidade percebida e´ calculado realizando a m´edia aritm´etica do brilho de todos os pixels capturados. B=

√

D2 + E 2 + F 2

(2)

onde:       D 0.2053 0.7125 0.4670 X(r) E  =  1.8537 −1.2797 −0.4429 .  Y (g)  F −0.3655 1.0120 −0.6104 Z(b)

(3)

A equac¸a˜ o 2 traz o brilho (B) obtido atrav´es do modelo BCH. Nesta abordagem o parˆametro num´erico que represente o brilho percebido do ambiente apresenta uma boa variac¸a˜ o entre os valores m´ınimos (ambiente escuro) para os 11

valores m´aximos (ambiente claro) mesmo com a atuac¸a˜ o do mecanismo de auto-brilho da cˆamera. Uma vez que existe um range de valores e´ poss´ıvel a caracterizac¸a˜ o de uma curva que represente a percepc¸a˜ o do brilho do ambiente. Esta curva foi levantada para o notebook Positivo Mobile utilizado para os testes, conforme apresentado na Tabela 2. Bilho Percebido (B) Percepc¸a˜ o Subjetiva Valor do Backlight 0 ≤B

6 7 8 9 10 11 12 13

int c d e c l main ( ) { / / D e f i n e and i n i t i a l i z e o u r r e t u r n v a r i a b l e s . LPWSTR p R e t B u f = NULL ; ULONG b u f S i z e = MAX PATH ∗ s i z e o f (WCHAR) ; ULONG u I n d e x = 0 ; BOOLEAN b R e t = FALSE ;

14

/ / Open t h e d e v i c e l i s t , q u e r y i n g a l l d e v i c e s i f ( ! DevicePowerOpen ( 0 ) ) { p r i n t f ( ”ERROR : The d e v i c e d a t a b a s e f a i l e d t o i n i t i a l i z e . \ n ” ) ; r e t u r n FALSE ; }

15 16 17 18 19 20 21

// // // // //

22 23 24 25 26

Enumerate t h e d e v i c e l i s t , s e a r c h i n g f o r d e v i c e s t h a t s u p p o r t waking from e i t h e r t h e S1 o r S2 s l e e p s t a t e and a r e c u r r e n t l y p r e s e n t i n t h e s y s t e m , and n o t d e v i c e s t h a t h a v e d r i v e r s i n s t a l l e d but a r e not c u r r e n t l y a t t a c h e d t o t h e system , such as in a laptop docking s t a t i o n .

27

p R e t B u f = (LPWSTR) L o c a l A l l o c ( LPTR , b u f S i z e ) ;

28 29

w h i l e (NULL ! = p R e t B u f && 0 ! = ( b R e t = DevicePowerEnumDevices ( u I n d e x , DEVICEPOWER FILTER DEVICES PRESENT , PDCAP WAKE FROM S1 SUPPORTED | PDCAP WAKE FROM S2 SUPPORTED , ( PBYTE ) pRetBuf , &b u f S i z e ) ) ) { p r i n t f ( ” D e v i c e name : %S\ n ” , p R e t B u f ) ;

30 31 32 33 34 35 36 37 38

/ / F o r t h e d e v i c e s we f o u n d t h a t h a v e s u p p o r t f o r waking from / / S1 and S2 s l e e p s t a t e s , d i s a b l e them from waking t h e s y s t e m . b R e t = ( 0 ! = D e v i c e P o w e r S e t D e v i c e S t a t e ( ( LPCWSTR) pRetBuf , DEVICEPOWER CLEAR WAKEENABLED, NULL) ) ;

39 40 41 42 43 44

i f (0 != bRet ) { p r i n t f ( ” Warning : F a i l e d t o s e t d e v i c e s t a t e . \ n ” ) ; } u I n d e x ++;

45 46 47 48 49

}

50 51

/ / Close the device l i s t . DevicePowerClose ( ) ; i f ( p R e t B u f ! = NULL) L o c a l F r e e ( p R e t B u f ) ; p R e t B u f = NULL ;

52 53 54 55 56

r e t u r n TRUE ;

57 58

} Listing 1. Exemplo de Uso da Device Power API

16

Nesse exemplo a lista de dispositivos e´ aberta e fechada uma vez. Se as func¸o˜ es DevicePowerOpen e DevicePowerClose n˜ao forem chamadas, a lista de dispositivos teria que ser aberta e fechada a cada chamada pelas func¸o˜ es DevicePowerEnumDevices e DevicePowerSetDeviceState. 5.1.6. Particularidades Windows Vista

A seguir, trataremos sobre as interfaces, o monitoramento de eventos e a verificac¸a˜ o do estado de energia dos dispositivos no Windows Vista. Interfaces para o gerenciamento de energia O Windows Vista usa a mensagem WM PO para notificar eventos em aplicac¸o˜ es de gest˜ao de energia. A mensagem inclui um conjunto de c´odigos de transmiss˜ao de energia que identificam os diversos eventos. E´ poss´ıvel se inscrever nestes eventos usando duas novas func¸o˜ es que foram introduzidas no Windows Vista: RegisterPowerSettingNotification UnregisterPowerSettingNotification Notificac¸o˜ es de gest˜ao de energia fornecem informac¸o˜ es completas sobre o status de gerenciamento de energia do sistema e seus componentes. Usando notificac¸o˜ es, sua aplicac¸a˜ o pode eliminar a necessidade de consultar o sistema (o que consome energia). Monitorizac¸a˜ o de eventos de gerenciamento de energia A func¸a˜ o RegisterPowerSettingNotification solicita a notificac¸a˜ o dos eventos gest˜ao de energia. A mensagem WM POWERBROADCAST e´ enviada com estes eventos atrav´es da notificac¸a˜ o PBT POWERSETTINGCHANGE. GUID ACDC POWER SOURCE: As alterac¸o˜ es da fonte de alimentac¸a˜ o DC para alimentac¸a˜ o AC / DC, ou a uma fonte de curto prazo, DC, como um dispositivo UPS. A notificac¸a˜ o indica que estas trˆes fontes de energia est˜ao ativas. GUID MONITOR POWER ON: A tela e´ ligada ou desligada, seja pelo usu´ario ou pela tela do sistema-func¸a˜ o de obturac¸a˜ o. A notificac¸a˜ o indica se o monitor est´a ligado ou desligado. GUID BATTERY PERCENTAGE REMAINING: A carga da bateria diminui ou aumenta. A notificac¸a˜ o indica o valor percentual para o novo n´ıvel de carga. GUID POWERSCHEME PERSONALITY: O usu´ario passa para um plano de energia com uma configurac¸a˜ o/esquema diferente. A notificac¸a˜ o indica o tipo de configurac¸a˜ o / esquema novo (Equilibrado, Economia de energia ou Alto desempenho). Use o GUID para registrar para cada classe de notificac¸a˜ o e para identificar a notificac¸a˜ o de entrada que e´ enviada com a mensagem WM POWERBROADCAST. Verificar o estado de energia dos dispositivos do sistema Planos de energia no Windows Vista incluem o per´ıodo de tempo ocioso para v´arios dispositivos do sistema, como o v´ıdeo e o disco r´ıgido. Considere retardar o uso 17

de dispositivos que est˜ao desligados de energia quando o computador est´a salvando. Para verificar o estado de energia de um dispositivo de armazenamento, e´ poss´ıvel utilizar a func¸a˜ o GetDevicePowerState. 5.2. Linux Nesse t´opico veremos como ACPI e o Linux trabalham juntos. 5.2.1. ACPI e Linux O ACPI e´ dividido em dois componentes: o driver ACPI e o daemon ACPI (ACPID). O daemon ACPID e´ tem um objetivo claro e simples: monitorar /proc/acpi/event e responder aos eventos. Exemplo 1: Para determinar a vers˜ao do driver e os estados suportados. bash $ cat /proc/acpi/info version: states:

20030619 S0 S1 S3 S4 S4 S5

Exemplo 2: Para obter informac¸o˜ es do sistema de gerenciamento de energia. bash $ acpi {V Thermal 1:

ok, 47.1 degrees C

Thermal 2:

ok, 45.1 degrees C

AC Adapter 1:

offline running off battery

AC Adapter 1:

online running off AC power

5.2.2. Obtendo informac¸o˜ es da bateria Para obter informac¸o˜ es da bateria basta verificar o seguinte arquivo: /proc/acpi/battery/BAT0/state Exemplo 1: present:

yes

capacity state:

ok

charging state:

discharging running off battery

present rate:

unknown

remaining capacity: present voltage:

3920 mAh watch this number

14800 mV

Exemplo 2: present:

yes 18

capacity state:

ok

charging state:

discharging

present rate:

unknown

remaining capacity: present voltage:

3840 mAh getting smaller

14800 mV

Exemplo 3: present:

yes

capacity state:

ok

charging state:

charging AC adapter plugged in

present rate:

unknown

remaining capacity: present voltage:

3840 mAh

14800 mV

Para obter informac¸o˜ es gerais da bateria: bash $ cat /proc/acpi/battery/BAT0/info present:

yes

design capacity:

3920 mAh

last full capacity:

3920 mAh

battery technology:

rechargeable

design voltage:

14800 mV

design capacity warning: design capacity low:

30 mAh

20 mAh

capacity granularity 1:

10 mAh

capacity granularity 2:

3470 mAh

model number:

Bat0

serial number: battery type:

Lion

Exemplo na linguagem de programac¸a˜ o Python: 1

# ! / u s r / b i n / env p y t h o n

2 3

i m p o r t o p t p a r s e , s u b p r o c e s s , s t r i n g , os , t i m e , d a t e t i m e

4 5

def getAllProcInfo ( ) :

6 7 8 9 10

ls = [] try : l s = os . l i s t d i r ( ” / proc / a c p i / b a t t e r y ” ) e x c e p t OSError :

19

11

p r i n t ” E r r o t r y i n g t o c a t c h i n f o r m a t i o n (−h show h e l p m e s s a g e ) ”

12 13 14

15 16

for bat in ls : p = s u b p r o c e s s . Popen ( ” c a t / p r o c / a c p i / b a t t e r y /% s / i n f o ” % b a t , s h e l l = True , s t d o u t = s u b p r o c e s s . PIPE ) p r i n t p . stdout . read ( ) getProcInfo (0)

17 18 19

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

20 21

def getProcInfo ( color ) :

22 23

24 25 26 27 28

# p = s u b p r o c e s s . Popen ( ” c a t bbo . b a t t e r y ” , s h e l l = True , s t d o u t = s u b p r o c e s s . PIPE ) o n l y f o r t e s t i n g ls = [] try : l s = os . l i s t d i r ( ” / proc / a c p i / b a t t e r y ” ) e x c e p t OSError : p r i n t ” E r r o t r y i n g t o c a t c h i n f o r m a t i o n (−h show h e l p m e s s a g e ) ”

29 30 31

for bat in ls : p = s u b p r o c e s s . Popen ( ” c a t / p r o c / a c p i / b a t t e r y /% s / i n f o ” % b a t , s h e l l = True , s t d o u t = s u b p r o c e s s . PIPE )

32 33

#verify if battery exists

34 35 36 37 38 39 40

stream = p . stdout . r e a d l i n e ( ) i f s t r e a m . r f i n d ( ” no ” ) == −1: d e l t a =0 for i in range (2 ,4) : result = (p . stdout . readline () ) . split () delta = string . atoi ( result [ i ]) − delta ;

41 42 43

44 45

if color : s t r e a m = ”\ n D i f f e r e n c e between \033[0;31 mdesign c a p a b i l i t y \ 0 3 3 [ 0 ; 3 7 mand \ 0 3 3 [ 0 ; 3 1 m l a s t f u l l c a p a b i l i t y \ 0 3 3 [ 0 ; 3 7 mis \ 0 3 3 [ 0 ; 3 3 m” + s t r ( d e l t a ) + ” \ 0 3 3 [ 0 ; 3 7m. \ n ” else : s t r e a m = ” \ n D i f f e r e n c e b e t w e e n d e s i g n c a p a b i l i t y and l a s t f u l l c a p a b i l i t y i s ” + s t r ( d e l t a ) + ”\n”

46 47 48 49

50

d a t e = d a t e t i m e . d a t e t i m e . now ( ) l o g f i l e = open ( ’ . b a t t e r y a n a l y s i s ’ , ’ a ’ ) l o g f i l e . w r i t e ( s t r ( d e l t a ) + ” ” + s t r ( t i m e . mktime ( d a t e . t i m e t u p l e ( ) ) ) + ”\n” ) ; logfile . close () ;

51 52 53

e l s e : # nao tem print ””

54 55 56

r e t u r n stream −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

57 58 59

d e f nome ( ) : return ” battery analysis ”

20

60 61

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

62 63 64

65

66

67

d e f main ( ) : p = optparse . OptionParser ( description = ’ Veritfy the l a s t f u l l capacity of your b a t t e r y ’ , prog= ’ b a t t e r y a n a l y s i s ’ , v e r s i o n = ’ b a t t e r y a n a l y s i s 0 . 1 ’ , u s a g e = ’%p r o g [ options ] ’ ) p . a d d o p t i o n ( ’−− a l l ’ , ’−a ’ , a c t i o n = ’ s t o r e t r u e ’ , h e l p = ’ show a l l c o n t e n t s o f / p r o c / a c p i / b a t t e r y // i n f o ’ ) p . a d d o p t i o n ( ’−−c o l o r s ’ , ’−c ’ , a c t i o n = ’ s t o r e t r u e ’ , h e l p = ’ add c o l o r s in delta values ’ ) options , arguments = p . p a r s e a r g s ( )

68 69 70 71 72 73 74 75 76

i f l e n ( a r g u m e n t s ) == 0 : if options . all : getAllProcInfo () e l i f options . colors : print getProcInfo (1) ; else : print getProcInfo (0) ; −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

77 78 79

if

name main ( )

== ’

main

’:

80 81

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− Listing 2. Exemplo Python

5.2.3. AcpiTool Acpitool e´ um cliente ACPI. Simplesmente lˆe /proc/acpi e mostra as informac¸o˜ es. Fornece informac¸o˜ es sobre status da bateria, presenc¸a de adaptador AC, etc. Acpitool tamb´em permite que a m´aquina seja colocada em standby (caso o notebook disponha deste suporte).

6. Utilizac¸a˜ o Concorrente de Cˆamera Webcam como Sensor e como Captura Nos sistemas operacionais Windows e Linux, quando uma aplicac¸a˜ o assume o controle de uma Webcam, este dispositivo fica bloqueado para ser utilizado por outras aplicac¸o˜ es, apresentando uma mensagem de erro toda vez que tentamos simular o uso concorrente como demonstra a mensagem capturada no Windows e apresentada na Figura 12:

Figura 12. Mensagem de erro no Windows

21

A comunicac¸a˜ o entre o sistema operacional e os dispositivos f´ısicos de hardware e´ realizada atrav´es dos drivers de dispositivos, cuja func¸a˜ o e´ receber requerimentos do software e cuidar para que cada solicitac¸a˜ o seja executada, permitindo que o software interaja com o dispositivo. Neste t´opico citaremos as soluc¸o˜ es propostas para utilizac¸a˜ o concorrente de uma Webcam nos sistemas operacionais Windows e Linux. 6.1. Windows No sistema operacional Windows a partir da vers˜ao Windows 98 a Microsoft criou o padr˜ao Windows Driver Model (WDM) [Microsoft-MSDN(2009l)], com o objetivo de criar uma plataforma de drivers que sejam compat´ıveis com toda a fam´ılia Windows. Nos modelos de drivers antigos, utilizados pelo Windows 3.x e pelo Windows 95, o driver continha todas as rotinas necess´arias para controlar o dispositivo, sendo que a maioria dessas rotinas eram repetidas em todos os drivers. Esta redundˆancia contribu´ıa para aumentar o trabalhado no desenvolvimento de novos drivers e na possibilidade de surgirem erros e bugs. Outra deficiˆencia e´ a falta de portabilidade, j´a que cada driver incorpora as rotinas adequadas ao sistema operacional ao qual se destina. A ideia do modelo WDM e´ incorporar todas estas rotinas repetitivas ao pr´oprio sistema operacional, em arquivos chamados drivers de classe. Um driver de classe e´ justamente o que cont´em todas as rotinas repetitivas. Para aumentar a versatilidade, existem drivers de classe diferentes para cada tipo de dispositivo. Os drivers de classe j´a acompanham o sistema operacional, por isso, com todas as func¸o˜ es b´asicas j´a embutidas no pr´oprio sistema operacional, os drivers de dispositivo contˆem apenas as func¸o˜ es mais espec´ıficas, sendo aquelas que mudam de um dispositivo para o outro. Existem trˆes tipos de drivers WDM: 1. Bus Driver – Serve um barramento de E/S, tais como IEEE 1394, podendo ser qualquer dispositivo f´ısico, l´ogico ou virtual conectado. 2. Function Driver – driver de um dispositivo individual. Geralmente escrito pelo fabricante do dispositivo. 3. Filter Driver – driver opcional que agregam valor ou modificam o comportamento de um dispositivo. Implementado em um n´ıvel acima ou abaixo de um driver. O Filter Driver intercepta pedidos para um dispositivo, avalia esses pedidos e pode modificar o conte´udo ou o destino do pedido. E´ de extrema importˆancia que o programador compreenda os diferentes tipos de drivers WDM para saber que tipo de glsdriver que est´a escrevendo. A Figura 13 mostra a relac¸a˜ o entre os trˆes tipos de drivers (Bus Driver, Function Driver e Filter Driver) para cada dispositivo [Microsoft-MSDN(2009g)]. 22

˜ entre os tipos de drivers WDM Figura 13. Relac¸ao

A soluc¸a˜ o proposta e´ a implementac¸a˜ o de um Upper-Level Filter Driver. Este e´ um driver opcional para agregar valor ou modificar o comportamento do dispositivo. Este Filter Driver funcionar´a como uma esp´ecie de “espi˜ao”, interceptando a comunicac¸a˜ o do driver com a aplicac¸a˜ o que estiver utilizando o dispositivo. Desta forma o controle de luminosidade ter´a acesso a` s imagens, sem interferir no processo normal das aplicac¸o˜ es. A Figura 14 demonstra a estrutura do sistema.

Figura 14. Estrutura do Sistemas

23

6.2. Linux No sistema operacional Linux encontramos algumas poss´ıveis soluc¸o˜ es, sendo a u´ ltima a mais satisfat´oria. Segue abaixo a descric¸a˜ o de todas as soluc¸o˜ es encontradas. 6.2.1. Interceptar os m´etodos da API Video4Linux2 No sistema operacional Linux a comunicac¸a˜ o com o dispositivo Webcam pode ser realizada atrav´es da API Video4Linux2 [LWN.net(2009b)]. Basicamente esta API se relaciona com o dispositivo atrav´es dos seguintes m´etodos: • • • •

Open() - abre o dispositivo. Write() - escreve no dispositivo Read() - realiza a leitura do dispositivo Close() - fecha a conex˜ao com o dispositivo Pseudoc´odigo de utilizac¸a˜ o da Video4Linux2:

1

/ ∗ Video f o r L i n u x Two ∗ /

2 3

# i n c l u d e

4 5 6 7 8 9

s t r u c t v412 format fmt Char ∗ d e v i c e = ” / dev / v i d e o ” ; Char ∗ d a t a ; I n t vid ; Int n;

10 11 12 13 14

v i d = open ( d e v i c e , O RDONLY) ; e r r = i o c t l ( v i d , VIDIOC G FMT , &f m t ) ; d a t a = malloc ( fmt . s i z e i m a g e ) ; n = r e a d ( vid , data , fmt . s i z e i m a g e ) ;

15 16 17

if (n) f w r i t e ( data , ( s i z e t ) n , 1 , s t d o u t ) ; ˜ da Video4Linux2 Listing 3. Exemplo de utilizac¸ao

Neste caso a soluc¸a˜ o testada, foi o desenvolvimento de uma biblioteca para manipular a Webcam, atendendo todas as chamadas de func¸a˜ o da API Video4Linux2, que seriam interceptadas e desviadas utilizando-se a vari´avel de ambiente LD PRELOAD. A biblioteca centralizaria toda comunicac¸a˜ o com o dispositivo, fornecendo as imagens para todas as aplicac¸o˜ es que estiverem requisitando estas informac¸o˜ es de forma concorrente. Normalmente o DL (Dynamic Linker) utiliza as Shared Libraries para atender as chamadas de func¸o˜ es externas, onde a LD PRELOAD instrui o DL para carregar bibliotecas adicionais para um programa, al´em do que foi especificado em sua compilac¸a˜ o. Dessa forma o usu´ario pode adicionar ou substituir funcionalidades quando executar a aplicac¸a˜ o. Essa t´ecnica e´ chamada de DLL Injection. As Figuras 15 e 16 demonstram o processo de comunicac¸a˜ o. A Figura 15 mostra o processo utilizando a biblioteca com o LD PRELOAD interceptando a comunicac¸a˜ o e a Figura 16 apresenta o processo normal do Linux. 24

˜ utilizando a nova biblioteca Figura 15. Comunicac¸ao

˜ normal do Linux Figura 16. Comunicac¸ao

Esta soluc¸a˜ o n˜ao foi adotada devido ao alto consumo de processamento gasto no monitoramento de todas as chamadas de func¸a˜ o da API Video4Linux2, o que comprometeria de forma significativa o desempenho do equipamento. 6.2.2. Video4Linux Loopback Device Utilizamos para testes a biblioteca vloopback que cria dois novos devices virtuais “/dev/video1” e “/dev/video2” [Vreeken(2009)], sendo o primeiro de entrada e o segundo de sa´ıda, onde utilizamos o device v´ıdeo0 para fornecer as imagens para nossa aplicac¸a˜ o, deixando o device de sa´ıda do loopback “/dev/v´ıdeo2” para as outras aplicac¸o˜ es do usu´ario. Esta soluc¸a˜ o n˜ao foi adota, pois a biblioteca vloopback n˜ao possui mais suporte, funcionando apenas com a antiga biblioteca de v´ıdeo do Linux “Video4Linux”. Como a grande maioria dos devices est´a utilizando a nova vers˜ao “Video4Linux2”, a vloopback n˜ao atenderia as necessidades. 6.2.3. V4L2 Virtual Device A soluc¸a˜ o proposta e´ a utilizac¸a˜ o do pacote V4L2 Virtual Device, sendo um software Open Source licenciado sobre a licenc¸a GNU, que funciona de forma similar a biblioteca vloopback, com a diferenc¸a de que utiliza a nova biblioteca de v´ıdeo do Linux “Video4Linux2” [Bouffard(2009)]. 25

Neste caso a aplicac¸a˜ o de controle de luminosidade utilizar o device “/dev/video0” para obter as imagens necess´arias e retransmitiria essas informac¸o˜ es para a entrada do loopback “/dev/video1”, que alimentaria o device virtual “/dev/video2” utilizado pelas aplicac¸o˜ es do usu´ario, permitindo dessa forma a sua utilizac¸a˜ o concorrente. A Figura 17 demonstra este fluxo.

˜ do V4L2 Virtual Device Figura 17. Utilizac¸ao

Para utilizar esta soluc¸a˜ o existe a necessidade de portar este pacote para a vers˜ao 2.6.28 do kernel do Linux, pois o seu desenvolvimento foi homologado para vers˜ao 2.6.18.

26

7. Conclus˜ao dos Experimentos Realizados 7.1. Estudo do Consumo da Webcam 7.1.1. Windows Inconclusivo. E´ necess´ario realizar um estudo aprofundado sobre outras APIs de captura de v´ıdeo para determinar se alguma pode apresentar desempenho satisfat´orio.

7.1.2. Linux Vi´avel. O consumo de energia da Webcam causou um impacto praticamente insignificativo: reduc¸a˜ o de 3 minutos na durac¸a˜ o da bateria (104 minutos capturando, e 107 minutos sem capturar). 7.2. Interferˆencia da Utilizac¸a˜ o Concorrentes 7.2.1. Windows Vi´avel. E´ poss´ıvel considerar o desenvolvimento de um Upper-Level Filter Driver para interceptar a comunicac¸a˜ o do driver da Webcam com a aplicac¸a˜ o, e fornecer as imagens para o sistema de controle de luminosidade. H´a necessidade de um estudo mais aprofundado do padr˜ao WDM e da complexidade para o desenvolvimento desta soluc¸a˜ o.

7.2.2. Linux Vi´avel. Utilizac¸a˜ o do V4L2 Virtual Device, para compartilhar as imagens atrav´es de devices virtuais. H´a necessidade de um esforc¸o para portar este pacote para vers˜ao 2.6.28 do kernel do Linux. 7.3. An´alise da Imagem Capturada para obter Parˆametro de Luminosidade Vi´avel. Independente do sistema operacional. 7.4. Tipos de Display que permitem Controle da Luminosidade N˜ao h´a uma regra espec´ıfica. O controle de luminosidade ou backlight depende do fabricante e modelo do display. 7.5. Interac¸a˜ o do Sistema Operacional com o Display para Controle da Luminosidade 7.5.1. Windows Ok. Uma API oferece algumas rotinas de alto n´ıvel para lidar com a BIOS ACPI. Existe tamb´em a possibilidade de ser realizado um acesso de baixo n´ıvel ao barramento I2C/SMBus nos casos em que os controles s˜ao propriet´arios do fabricante. 27

7.5.2. Linux Ok. O controle de luminosidade do monitor pelo Linux pode ser realizado atrav´es do subsistema ACPI deste sistema operacional. Este subsistema encarrega-se de realizar toda a comunicac¸a˜ o com o monitor, codificando e interpretando todos os dados. 7.6. Mapeamento de APIs para Controlar a Luminosidade do Display 7.6.1. Windows Ok. A API e´ denominada Monitor Configuration. Com esta API o controle de brilho do monitor e´ bastante simples. A utilizac¸a˜ o se d´a atrav´es de c´odigo em linguagem C. 7.6.2. Linux Ok. No Linux as informac¸o˜ es de controle de luminosidade do display podem ser obtidas atrav´es do filedescriptor /proc/acpi/video/VGA/LCD/brightness, ou ainda atrav´es de uma interface alternativa recentemente implementada, chamada /sys/class/backlight/acpi video0. 7.7. Mapeamento de APIs para Gerenciamento de Energia do Sistema Operacional 7.7.1. Windows Ok. Existe uma API espec´ıfica para gerenciamento de energia. 7.7.2. Linux Ok. No Linux as informac¸o˜ es a respeito do gerenciamento de energia se d˜ao atrav´es do filedescriptor (bateria) /proc/acpi/battery/BAT0/state e (AC Power) /proc/acpi/ac adpter/AC/state . 7.8. Viabilidade de Criac¸a˜ o de Prot´otipo Utilizando a Webcam como Sensor de Luminosidade 7.8.1. Windows Vi´avel. Apesar de n˜ao ter sido desenvolvido um prot´otipo para este sistema operacional, identificamos um software desenvolvido durante um concurso de inovac¸o˜ es da Microsoft [diTii.com(2009)], que realiza esta tarefa. O nome deste programa e´ BLUntrl 5 . Ele n˜ao est´a dispon´ıvel para download, mas atrav´es de v´ıdeos demonstrando sua atuac¸a˜ o deduz-se que e´ poss´ıvel realizar uma implementac¸a˜ o neste sistema operacional. 7.8.2. Linux Vi´avel. O estudo de consumo foi conduzido atrav´es do desenvolvimento de um prot´otipo funcional para este sistema operacional. 5

BLUntrl. BackLight Unit coNTRoL: An ordinary webcam as an ALS to control the BLUs of all attached monitors according to the ambient brightness.

28

8. Proposta de Desenvolvimento do Software de Gest˜ao de Iluminac¸a˜ o Esta sec¸a˜ o do documento tem como finalidade apresentar um roteiro de apoio ao desenvolvimento de um software de Gest˜ao de Iluminac¸a˜ o, abordando as funcionalidades desejadas, a forma visual e controles pretendidos e a divis˜ao em blocos funcionais do c´odigo a ser desenvolvido. As atividades necess´arias para realizar o desenvolvimento n˜ao ser˜ao apresentadas uma vez que cada projeto apresenta seus guias de pr´aticas, processos e metodologias de desenvolvimento. 8.1. Descric¸a˜ o do Software de Gest˜ao de Iluminac¸a˜ o O software a ser desenvolvido realiza a gest˜ao da iluminac¸a˜ o do monitor controlando o backlight deste. O objetivo principal e´ o de proporcionar um maior conforto visual ao usu´ario. Assume-se que este software ser´a utilizado em notebooks. Ao controlar o brilho do backlight do monitor, reduzindo-o automaticamente conforme o ambiente em que o equipamento se encontra, e´ poss´ıvel aumentar a durac¸a˜ o da carga da bateria. Entretanto este e´ um efeito secund´ario por n˜ao ser mensur´avel, pois isto ir´a variar conforme as condic¸o˜ es de iluminac¸a˜ o. Este software dever´a ser executado nos sitemas operacionais Windows e Linux. Como existem diferenc¸as na forma em que estes sistemas operacionais implementam o acesso a` s funcionalidades de hardware para controle do backlight e tamb´em para captura da imagem da cˆamera, a implementac¸a˜ o para cada um destes ser´a ligeiramente diferente. A Figura 19 apresenta um diagrama funcional para auxiliar a evitar duplicidade (desnecess´aria) de c´odigo. A linguagem a ser seguida e´ a C++ pois as APIs em ambos os sistemas utilizam esta linguagem. Para que seja realizada a gest˜ao da iluminac¸a˜ o do backlight, o software permanecer´a em execuc¸a˜ o de segundo plano. Este ir´a ser executado como se fosse um programa ´ normal para o usu´ario, apresentando apenas um ´ıcone na Area de Notificac¸a˜ o do Windows [Wikipedia(2009h)] (i.e. System Tray) para sinalizar que ele est´a rodando. Este ´ıcone dar´a acesso a` uma interface gr´afica para modificar parˆametros do software assim como habilitar ou desabilitar seu funcionamento.

Figura 18. Ideia de acesso ao software

E´ interessante que a instalac¸a˜ o do software seja simples, ou seja, n˜ao exija nenhuma configurac¸a˜ o por parte do operador (instalador). Para tanto e´ necess´ario que o software reconhec¸a qual e´ o equipamento no qual ele est´a sendo instalado. A raz˜ao disto e´ que cada equipamento ter´a uma Webcam diferente e um monitor com caracter´ısticas de brilho tamb´em diferentes. 29

Um banco de dados em formato eXtensible Markup Language (XML) relacionando as poss´ıveis Webcams e backlights de monitores far´a parte da instalac¸a˜ o do software. Sendo um arquivo XML garante que este banco de dados seja cross-plataform [Wikipedia(2009c)]. O instalador do software ir´a verificar se o equipamento est´a no banco de dados no ato de instalac¸a˜ o. Caso n˜ao esteja significa que ele n˜ao foi homologado e a instalac¸a˜ o dever´a ser abortada. 8.2. Blocos Funcionais Como este software ter´a uma vers˜ao para Windows e outra para Linux, para garantir a reusabilidade de c´odigo entre estas plataformas prop˜oe-se que o sistema tenha os blocos funcionais apresentados na Figura 19.

Figura 19. Blocos funcionais do software

Neste diagrama, os blocos que est˜ao pintados na cor verde-claro s˜ao aqueles cujo c´odigo dever´a ser o mesmo independentemente do sistema operacional. J´a os blocos em verde-escuro s˜ao aqueles cuja implementac¸a˜ o e´ dependente do sistema operacional. N˜ao est˜ao presentes no diagrama os blocos necess´arios para realizar a leitura dos arquivos de configurac¸a˜ o (XML e “*.ini”) e da detecc¸a˜ o do equipamento. A leitura dos arquivos de configurac¸a˜ o e´ poss´ıvel de ser u´ nica entre os sistemas operacionais se utilizar uma API cross-plataform para lidar com XML; e no caso de arquivos “*.ini” utilizando recursos de abstrac¸a˜ o que provavelmente a API de User Interface (UI) [Microsoft-MSDN(2009k)] fornece. 8.3. Banco de dados com as caracter´ısticas de cˆameras e equipamentos Estrutura proposta para o banco de dados XML com as caracter´ısticas dos equipamentos: 1 2 3 4 5 6 7

< c o n t r o l e i l u m i n a c a o> < / c a m e r a>

30

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

< / c a m e r a> < / c a m e r a s> < / and> < / match> < / e q u i p a m e n t o> < / e q u i p a m e n t o s> < / c o n t r o l e i l u m i n a c a o> Listing 4. Database XML

Se este software for apenas embarcado em notebooks (ocasi˜ao em que a imagem do sistema operacional e´ preparada pelo pr´oprio fabricante durante o processo de fabricac¸a˜ o do equipamento), n˜ao e´ necess´ario verificar constantemente os perif´ericos (no caso, a Webcam) que est˜ao instalados no equipamento, pois existir´a uma relac¸a˜ o un´ıvoca entre eles. Neste caso, a estrutura do banco de dados XML pode ser mais simples: 1 2 3 4 5 6 7 8 9 10 11 12 13

< / and> < / match> < / e q u i p a m e n t o> < / e q u i p a m e n t o s> Listing 5. Database XML

8.4. GUI de Configurac¸a˜ o A interface gr´afica de configurac¸a˜ o do mecanismo de controle de iluminac¸a˜ o deve ser comum entre os sistemas operacionais Windows e Linux. Ela deve apresentar trˆes graus (ou categorias) de luminosidade: Escuro, Normal e Claro. A criac¸a˜ o de novas categorias mostrou-se ser pouco eficiente durante o processo de desenvolvimento do prot´otipo concebido na fase de estudos do projeto. As figuras apresentadas para este software n˜ao s˜ao reais. Elas foram criadas em 31

um editor de imagens (GIMP 6 ) para representar visualmente as propostas de interface do software. A primeira proposta de interface na Figura 20 apresenta uma configurac¸a˜ o b´asica dos n´ıveis de claridade do ambiente ajustada por um controle deslizante (slider) e uma entrada de dados (num´erica) para ajusta da iluminac¸a˜ o do monitor.

´ ´ Figura 20. Ideia de interface grafica basica

O controle deslizante representa as faixas de condic¸o˜ es de iluminac¸a˜ o do ambi´ ente. E poss´ıvel considerar o desenvolvimento de um assistente (conhecido como Wizard7 [Wikipedia(2009i)]) para ajudar o usu´ario no processo de calibrac¸a˜ o destas faixas de valores (e.g. “Coloque seu notebook em um ambiente escuro/normal/claro e inicie o processo de calibrac¸a˜ o.”). O usu´ario, entretanto, pode apenas indicar o n´ıvel do backlight para cada uma das condic¸o˜ es de iluminac¸a˜ o do ambiente. E´ necess´ario considerar que a apresentac¸a˜ o de imediato dos controles que permitam a manipulac¸a˜ o do algor´ıtimo de ajuste pode tornar a interface complexa e sujeita a` uma configurac¸a˜ o inadequada do usu´ario, o que poderia acarretar no mau funcionamento do software. Portanto, a implementac¸a˜ o deste controle deve ser bem avaliada pela equipe de desenvolvimento. H´a tamb´em uma caixa de selec¸a˜ o que permite o usu´ario habilitar ou desabilitar o controle autom´atico da iluminac¸a˜ o do monitor do notebook. Quando selecionada, o software est´a habilitado a operar automaticamente no sistema operacional, a partir da configurac¸a˜ o realizada (com ou sem calibrac¸a˜ o). A segunda proposta de interface na Figura 21 sugere uma configurac¸a˜ o mais avanc¸ada possibilitando a alterac¸a˜ o dos n´ıveis de iluminac¸a˜ o que representam as diferentes condic¸o˜ es de iluminac¸a˜ o do ambiente detectado pela Webcam. A curva tem apenas 6 7

GNU Image Manipulation Program (GIMP): https://www.gimp.org Wizard, sequˆencia de telas no estilo passo-a-passo.

32

um efeito ilustrativo, a funcionalidade fica nas a´ reas preenchidas com uma tonalidade escura, m´edia e branca para representar as regi˜oes de decis˜ao.

´ Figura 21. Ideia de interface grafica avanc¸ada

O n´ıvel detectado no momento pela Webcam e´ mostrado por um indicador e uma linha vermelha. Os n´ıveis a serem considerados na decis˜ao s˜ao configurados pelo controle deslizando abaixo do gr´afico. Os controles deslizantes n˜ao podem ultrapassar um ao outro, ou seja, o controle da esquerda sempre permanecer´a a` esquerda, e vice-versa, havendo um travamento (ou barreira) entre eles. Significado dos bot˜oes colocados nas interfaces gr´aficas apresentadas: • Restaurar Padr˜ao: volta a configurac¸a˜ o para aos valores do XML. • Cancelar: descarta as modificac¸o˜ es e continua a usar os valores atuais. • Aplicar: para aplicar sem fechar a janela. Diferentemente do que est´a desenhado nas Figuras 20 e 21, para haver uniformidade, os mesmos bot˜oes devem ser utilizados em todas as janelas. O mecanismo de controle do brilho do monitor possui trˆes parˆametros que s˜ao ajust´aveis: Tempo de Guarda, Histerese de N´ıvel e Intervalo de Amostragem. O Tempo de Guarda e´ um intervalo de tempo que o software ir´a aguardar para que uma nova condic¸a˜ o de brilho seja confirmada. A Histerese de N´ıvel cria um offset para mais e para menos nas Mudanc¸as de N´ıvel. O Tempo de Guarda e a Histerese tˆem como prop´osito tornar o mecanismo est´avel, evitando mudanc¸as intermitentes no brilho do monitor. O intervalo de amostragem indica a periodicidade em que os quadros de imagens dever˜ao ser obtidos da Webcam. 33

N˜ao existe grande ganho ao permitir que o usu´ario final modifique algum destes trˆes parˆametros. Ao contr´ario: a configurac¸a˜ o incorreta destes pode acarretar no comportamento inadequado do algor´ıtimo, podendo, inclusive, impactar a performance do sistema como um todo (i.e. um intervalo de amostragem muito pequeno pode elevar a ocupac¸a˜ o da CPU). Para que estes parˆametros n˜ao fiquem hard-coded [Wikipedia(2009d)] no c´odigofonte do software, eles podem ser configurados a partir de um arquivo de configurac¸a˜ o criado durante o processo de instalac¸a˜ o. 8.5. Peculiaridades na implementac¸a˜ o para Windows 8.5.1. Gest˜ao do Brilho 100% via software Apesar do Windows possuir uma API para ALS, n˜ao sugerimos a utilizac¸a˜ o no desenvolvimento deste software. A implementac¸a˜ o integral por software pode facilitar a criac¸a˜ o de um c´odigo cross-plataform. Entretanto, caso este requisito seja de menor relevˆancia e o software n˜ao seja executado no Linux, a utilizac¸a˜ o da API nativa do Windows para ALS poderia acelerar o desenvolvimento. 8.5.2. Captura de imagem da Webcam Utilizar uma API que proporcione maior desempenho (menor ocupac¸a˜ o da CPU) e´ determinante na arquitetura do software. A equipe de desenvolvimento deve escolher a API com muita atenc¸a˜ o. Durante a etapa de estudos, a escolha da API foi determinada como cr´ıtica. 8.5.3. Filter Driver para utilizac¸a˜ o concorrente Incluir o desenvolvimento de um Filter Driver para capturar as imagens de Webcam pelo software de gest˜ao de iluminac¸a˜ o simultaneamente com algum software que o usu´ario possa vir a utilizar (Skype, MSN, etc). 8.6. Peculiaridades na implementac¸a˜ o para Linux 8.6.1. Desabilitar fade-out de inatividade Este comportamento e´ controlado pelo GNOME Power Manager [GNOME(2009b)] (no GNOME 8 ) e pelo Power Devil [KDE UserBase(2009)] (no KDE 9 ). Deve-se encontrar uma forma de desabilitar este recurso. Este comportamento n˜ao foi levantado nos estudos. As alternativas poss´ıveis s˜ao: realizar a comunicac¸a˜ o direta com o daemon via D-Bus [freedesktop.org(2009)] ou acessar o mecanismo de configurac¸a˜ o disponibili10

8

GNU Network Object Model Environment (GNOME): https://www.gnome.org K Desktop Environment (KDE). A partir de 2009, apenas KDE: https://www.kde.org 10 D-Bus ou DBus e´ um mecanismo de comunicac¸a˜ o entre processos e chamada de procedimento remoto que possibilita a comunicac¸a˜ o entre v´arios programas de computador (processos) rodando simultaneamente na mesma m´aquina. 9

34

zado pela distribuic¸a˜ o Linux (GConf 11 [GNOME(2009a)] no GNOME; desconhecido no KDE). 8.6.2. V´ıdeo Loopback E´ necess´ario portar 12 o V4L2 Virtual Device para o kernel 2.6.31.

9. Potencial de Pesquisas Futuras A partir dos resultados encontrados nos experimentos realizados, sugerimos a an´alise de viabilidade para construc¸a˜ o de um recurso com detecc¸a˜ o dos movimentos do usu´ario do notebook a partir da Webcam embarcada, para, intuitivamente, suspender o monitor quando o usu´ario n˜ao estiver mais em frente ao notebook.

11

GConf e´ um sistema para armazenar preferˆencias de aplicativos. Destina-se a preferˆencias do usu´ario. Portar e´ um termo frequentemente empregado para descrever o processo de tornar um programa que foi escrito para um sistema operacional espec´ıfico plenamente funcional para outro sistema operacional. Por exemplo, fazer um programa escrito para o Windows e movˆe-lo para o Linux. No uso em quest˜ao, refere-se a tornar o V4L2 Virtual Device plenamente funcional no kernel 2.6.31 uma vez que foi homologado para o kernel 2.6.18 do Linux. 12

35

Referˆencias [ACPI.info(2009)] @online ACPI.info. Acpi specification, Dezembro 2009. URL http: //acpi.info/DOWNLOADS/ACPIspec30b.pdf. [Bouffard(2009)] Jean-Michel Bouffard. V4l2 virtual device (v4l2vd), Dezembro 2009. URL http://v4l2vd.sourceforge.net. [diTii.com(2009)] @online diTii.com. Backlight unit control (bluntrl): Turn a webcam as a windows 7 sensors api, Dezembro 2009. URL https://tinyurl.com/ nyfev8j. [freedesktop.org(2009)] @online freedesktop.org. What is d-bus?, Dezembro 2009. URL https://www.freedesktop.org/wiki/Software/dbus. [GNOME(2009a)] @online GNOME. Gconf configuration system, Dezembro 2009a. URL https://projects.gnome.org/gconf. [GNOME(2009b)] @online GNOME. Gnome power manager, Dezembro 2009b. https://projects.gnome.org/gnome-power-manager.

URL

[HP(2009)] @online HP. Hp compaq nc8230 series notebook pcs, Dezembro 2009. URL http://h10010.www1.hp.com/wwpc/pscmisc/vac/us/ product_pdfs/nc8230.pdf. [KDE UserBase(2009)] @online KDE UserBase. Kde power devil, Dezembro 2009. URL https://userbase.kde.org/Power_Devil. [LWN.net(2009a)] @online LWN.net. Introduce acpi als device driver, Dezembro 2009a. URL https://lwn.net/Articles/348576. [LWN.net(2009b)] @online LWN.net. The video4linux2 api: an introduction, Dezembro 2009b. URL https://lwn.net/Articles/203924. [Microsoft(2009a)] @online Microsoft. Acpi-compliant bios (em inglˆes), Dezembro 2009a. URL https://msdn.microsoft.com/en-us/library/ windows/hardware/ff540487(v=vs.85).aspx. [Microsoft(2009b)] @online Microsoft. Integrating ambient light sensors with windows 7 computers, Dezembro 2009b. URL https://msdn. microsoft.com/en-us/windows/hardware/drivers/sensors/ supporting-ambient-light-sensors. [Microsoft(2009c)] @online Microsoft. Acpi in windows vista - powerpoint (em inglˆes), Dezembro 2009c. URL http://download.microsoft.com/download/ 5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/CPA002_WH06. ppt. [Microsoft(2009d)] @online Microsoft. Monitor configuration (em inglˆes), Dezembro 2009d. URL https://msdn.microsoft.com/en-us/library/ dd692962(VS.85).aspx. [Microsoft-MSDN(2009a)] @online Microsoft-MSDN. Deviceiocontrol function, Dezembro 2009a. URL https://msdn.microsoft.com/en-us/library/ aa363216(VS.85).aspx. 36

[Microsoft-MSDN(2009b)] @online Microsoft-MSDN. Getsystempowerstatus function, Dezembro 2009b. URL https://msdn.microsoft.com/en-us/library/ aa372693(VS.85).aspx. [Microsoft-MSDN(2009c)] @online Microsoft-MSDN. Ioctl battery query information control code, Dezembro 2009c. URL https://msdn.microsoft.com/en-us/ library/aa372698(VS.85).aspx. [Microsoft-MSDN(2009d)] @online Microsoft-MSDN. Ioctl battery query status control code, Dezembro 2009d. URL https://msdn.microsoft.com/en-us/ library/aa372699(VS.85).aspx. [Microsoft-MSDN(2009e)] @online Microsoft-MSDN. Ioctl battery query tag control code, Dezembro 2009e. URL https://msdn.microsoft.com/en-us/ library/aa372700(VS.85).aspx. [Microsoft-MSDN(2009f)] @online Microsoft-MSDN. Ioctl battery set information control code, Dezembro 2009f. URL https://msdn.microsoft.com/en-us/ library/aa372701(VS.85).aspx. [Microsoft-MSDN(2009g)] @online Microsoft-MSDN. Kernel-mode driver architecture, Dezembro 2009g. URL https://msdn.microsoft.com/en-us/library/ windows/hardware/ff557560(v=vs.85).aspx. [Microsoft-MSDN(2009h)] @online Microsoft-MSDN. Power management reference, Dezembro 2009h. URL https://msdn.microsoft.com/en-us/library/ aa373170(VS.85).aspx. [Microsoft-MSDN(2009i)] @online Microsoft-MSDN. Pbt apmpowerstatuschange event, Dezembro 2009i. URL https://msdn.microsoft.com/en-us/ library/aa372715(VS.85).aspx. [Microsoft-MSDN(2009j)] @online Microsoft-MSDN. Registerpowersettingnotification function, Dezembro 2009j. URL https://msdn.microsoft.com/en-us/ library/aa373196(VS.85).aspx. [Microsoft-MSDN(2009k)] @online Microsoft-MSDN. Ui user interface, Dezembro 2009k. URL https://msdn.microsoft.com/en-us/library/ windows/desktop/aa372390(v=vs.85).aspx. [Microsoft-MSDN(2009l)] @online Microsoft-MSDN. Introduction to wdm - windows driver model, Dezembro 2009l. URL https://msdn.microsoft.com/en-us/ library/windows/hardware/ff548158(v=vs.85).aspx. [Microsoft-MSDN(2009m)] @online Microsoft-MSDN. Wm powerbroadcast message, Dezembro 2009m. URL https://msdn.microsoft.com/en-us/library/ aa373247(VS.85).aspx. [Sergey Bezryadin(2007)] Dmitry Ilinih Sergey Bezryadin, Pavel Bourov. Brightness calculation in digital image processing, Dezembro 2007. URL https://www.researchgate.net/publication/285554890_ Brightness_Calculation_in_Digital_Image_Processing. [SMBus.org(2009)] @online SMBus.org. Smbus specifications, Dezembro 2009. http://smbus.org/specs. 37

URL

[TecMundo(2009)] @online TecMundo. Review: Notebook positivo mobile t457p, Dezembro 2009. URL https://www.tecmundo.com.br/analise/ 4137-analise-notebook-positivo-mobile-t457p.htm. [The Free Library(2009)] @online The Free Library. Ambient light sensor chip increases battery life in notebooks and cell phones (em inglˆes), Dezembro 2009. URL https: //www.thefreelibrary.com/Ambient+Light+Sensor+Chip+ Increases+Battery+Life+in+Notebooks+and...-a0149762652. [Vreeken(2009)] Jeroen Vreeken. Video4linux loopback device, Dezembro 2009. URL http://lavrsen.dk/foswiki/bin/view/Motion/ VideoFourLinuxLoopbackDevice. [Wikipedia(2009a)] @online Wikipedia. Microsoft directx (em inglˆes), Dezembro 2009a. URL https://en.wikipedia.org/wiki/DirectX. [Wikipedia(2009b)] @online Wikipedia. Linguagem c, Dezembro 2009b. URL https://pt.wikipedia.org/wiki/C_(linguagem_de_programa% C3%A7%C3%A3o). [Wikipedia(2009c)] @online Wikipedia. Cross-plataform, Dezembro 2009c. URL https: //en.wikipedia.org/wiki/Cross-platform. [Wikipedia(2009d)] @online Wikipedia. Hard-code, Dezembro 2009d. URL https://pt. wikipedia.org/wiki/Hard_code. [Wikipedia(2009e)] @online Wikipedia. Kerbel, Dezembro 2009e. URL https://pt. wikipedia.org/wiki/N%C3%BAcleo_(sistema_operacional). [Wikipedia(2009f)] @online Wikipedia. Lux, Dezembro 2009f. wikipedia.org/wiki/Lux.

URL https://pt.

[Wikipedia(2009g)] @online Wikipedia. Pixel, Dezembro 2009g. URL https://pt. wikipedia.org/wiki/Pixel. [Wikipedia(2009h)] @online Wikipedia. Notification area (em inglˆes), Dezembro 2009h. URL https://en.wikipedia.org/wiki/Notification_area. [Wikipedia(2009i)] @online Wikipedia. Wizard, Dezembro 2009i. URL https://pt. wikipedia.org/wiki/Assistente_(software). [Wikipedia(2009j)] @online Wikipedia. Xml (extensible markup language), Dezembro 2009j. URL https://pt.wikipedia.org/wiki/XML. [Youtube(2009)] @online Youtube. Bluntrl - youtube video, Dezembro 2009. URL https: //www.youtube.com/watch?v=Y9V9aL1vnHI.

38