pontifÍcia universidade catÓlica do...
TRANSCRIPT
PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ
ESCOLA POLITÉCNICA
PROJETO FINAL EM ENGENHARIA DE COMPUTAÇÃO
PROPOSTA DE UMA FERRAMENTA DE REALIDADE AUMENTADA PARA
APRIMORAR A TOMADA DE DECISÃO EM SISTEMAS DE SUPERVISÃO E
CONTROLE NO ONS
EDUARDO LAMY LOPES
MARCOS VITOR TIBES CECCATTO
ORIENTADOR: ANDERSON LUÍS SZEJKA
ANDERSON LUÍS SZEJKA
4° BIMESTRE
CURITIBA
2019
RESUMO
A evolução e digitalização nos sistemas SCADA (Supervisory Control and Data
Acquisition) está aliada a um volume de informação cada vez maior. Dessa forma, a
análise dos dados gerados por cada dispositivo tecnológico é preponderante para a
detecção de eventos anormais no sistema, assim como para o diagnóstico de
problemas do próprio sistema.
Atualmente os sistemas do tipo que possuem resultados na forma de gráficos
tridimensionais não possuem uma maneira de apresentá-los para os operadores sem
separar as informações em vários gráficos bidimensionais. Essa estratégia acaba
exigindo uma maior habilidade e treinamento dos operadores para que consigam
identificar e interpretar quais informações apresentadas são importantes e tomar uma
decisão rapidamente.
O trabalho desenvolvido faz parte de um projeto maior que está sendo
desenvolvido entre a Siemens, PUCPR e o ONS (Operador Nacional do Sistema
Elétrico). Tem por objetivo implementar um ambiente tridimensional em que seja
possível interagir através de tecnologias de realidade aumentada aplicadas com os
gráficos críticos do sistema SCADA de controle de sistemas elétricos. O trabalho
desenvolvido é capaz de diminuir a carga cognitiva requerida pelos operadores do
sistema SCADA, acelerando a tomada de decisão em tempo real.
Palavras-chave: SCADA; Realidade Aumentada; Gráficos Tridimensionais.
SUMÁRIO
RESUMO ..................................................................................................................... 2
1 INTRODUÇÃO ............................................................................................... 8
1.1 PROBLEMÁTICA ............................................................................................ 9
1.2 OBJETIVO .................................................................................................... 11
1.2.1 OBJETIVO GERAL ....................................................................................... 11
1.2.2 OBJETIVOS ESPECÍFICOS......................................................................... 11
1.3 JUSTIFICATIVA ............................................................................................ 11
1.4 METODOLOGIA DO PROJETO ................................................................... 12
1.5 ESTRUTURA DO DOCUMENTO ................................................................. 14
2 REVISÃO BIBLIOGRÁFICA ........................................................................ 15
2.1 SISTEMA SCADA ......................................................................................... 15
2.1.1 DIGITALIZAÇÃO DE SISTEMAS SCADA .................................................... 15
2.2 TECNOLOGIAS DE REALIDADE VIRTUAL E AUMENTADA ...................... 16
2.2.1 REALIDADE VIRTUAL ................................................................................. 16
2.2.2 REALIDADE AUMENTADA .......................................................................... 16
2.3 ORGANON ................................................................................................... 17
2.3.1 INFORMAÇÕES E DADOS .......................................................................... 18
2.3.1.1 CÁLCULO E DETERMINAÇAO DA REGIAO DE SEGURANÇA ................. 18
2.3.1.2 ESTRUTURA DO ARQUIVO EMSCLIENT.OUT .......................................... 20
2.4 PROGRAMAÇÃO GRÁFICA ........................................................................ 22
2.4.1 CONFIGURAÇÕES DO UNITY .................................................................... 22
3 PROPOSTA CONCEITUAL DA FERRAMENTA DE REALIDADE
AUMENTADA PARA APRIMORAR A TOMADA DE DECISÃO EM SISTEMAS DE
SUPERVISÃO E CONTROLE NO ONS ................................................................... 25
3.1 DEFINIÇÃO DO HARDWARE ...................................................................... 25
3.2 DEFINIÇÃO DO SOFTWARE ....................................................................... 26
3.3 ARQUITETURA DA SOLUÇÃO .................................................................... 27
3.3.1 FLUXO DE DADOS ...................................................................................... 28
3.3.2 GESTOS PREDEFINIDOS DO HOLOLENS ................................................ 29
3.3.3 APLICAÇÃO DE UM HOLOGRAMA DE GRÁFICO 3D BASEADO NOS
RESULTADOS DE ANÁLISE DO ORGANON .......................................................... 30
3.3.4 ARQUIVO DE COORDENADAS DO PONTO DE OPERAÇÃO E DAS
REGIÕES DE SEGURANÇA .................................................................................... 30
3.3.5 CONSTRUÇÂO DO PROGRAMA DE COMUNICAÇÂO SOCKET .............. 33
3.3.5.1 CÓDIGO CLIENTE ....................................................................................... 33
3.3.5.2 CÓDIGO SERVIDOR ................................................................................... 35
3.3.6 CONSTRUÇÃO DO GRÁFICO 3D NO UNITY ............................................. 36
3.4 PLANO DE TESTES ..................................................................................... 43
3.4.1 AMBIENTE DE DESENVOLVIMENTO, DADOS E HOLOGRAMA .............. 43
3.4.1.1 T01 - Teste do Ambiente de Desenvolvimento ............................................. 44
3.4.1.2 T02 - Teste de Configuração do Unity para HoloLens .................................. 45
3.4.1.3 T03 - Teste criação de um Holograma simples no HoloLens Emulator ........ 46
3.4.1.4 T04 - Adição de funções ao projeto básico ................................................... 47
3.4.1.5 T05 - Teste de Holograma com HoloLens Emulator no Microsoft HoloLens 48
3.4.1.6 T06 - Teste de Comportamento do Holograma ............................................ 49
3.4.1.7 T07 - Teste de Atualização do Hologramas .................................................. 50
3.4.1.8 T08 - Teste de Envio e Leitura de Dados ..................................................... 51
3.5 ANÁLISE DE RISCOS .................................................................................. 52
4 DESENVOLVIMENTO .................................................................................. 53
4.1 CRONOGRAMA ........................................................................................... 53
5 SUSTENTABILIDADE E IMPACTO AMBIENTAL ....................................... 55
6 CONCLUSÃO ............................................................................................... 56
7 TRABALHOS FUTUROS ............................................................................. 58
7.1 COMANDOS POR VOZ................................................................................ 58
7.2 CONEXÃO DIRETA COM O ORGANON ..................................................... 58
7.3 SUPORTE PARA DADOS HISTÓRICOS ..................................................... 58
REFERÊNCIAS ......................................................................................................... 59
APENDICE A –CÓDIGO GERADOR DE ARQUIVO CSV........................................ 60
APENDICE B – CÓDIGO FILE WATCHER .............................................................. 62
APENDICE C – CÓDIGO SERVIDOR ...................................................................... 64
LISTA DE ILUSTRAÇÕES
Figura 1 – Região de segurança projetada em dois subespaços de geração ........... 10
Figura 2 – Representação gráfica da metodologia do projeto ................................... 12
Figura 3 – Nomograma com áreas assinaladas ........................................................ 20
Figura 4 – Main Camera no Unity .............................................................................. 22
Figura 5 – Configuração plataforma no Unity ............................................................ 23
Figura 6 – PlayerSettings – Publishing Settings ........................................................ 24
Figura 7 – PlayerSettings – XR Settings ................................................................... 24
Figura 8 – Microsoft HoloLens ................................................................................... 25
Figura 9 – Diagrama de Blocos do Projeto ................................................................ 28
Figura 10 – Fluxo de Dados do Projeto ..................................................................... 28
Figura 11 – Arquivo CSV com coordenadas ............................................................. 31
Figura 12 – Hierarquia do Projeto no Unity ............................................................... 37
Figura 13 – Configuração do Cube Bounding Box .................................................... 37
Figura 14 – Scripts do MRTK adicionados ao Cube Bounding Box .......................... 38
Figura 15 – Configuração do script Bounding Box .................................................... 39
Figura 16 – Configuração do script Near Interaction Grabbable ............................... 39
Figura 17 – Configuração do script Manipulation Handler ......................................... 40
Figura 18 – Configuração do script Transform Scale Handler ................................... 41
Figura 17 – Cronograma do Projeto .......................................................................... 54
LISTA DE TABELAS
Tabela 1 – Teste 1 .................................................................................................... 44
Tabela 2 – Teste 2 .................................................................................................... 45
Tabela 3 – Teste 3 .................................................................................................... 46
Tabela 4 – Teste 4 .................................................................................................... 47
Tabela 5 – Teste 5 .................................................................................................... 48
Tabela 6 – Teste 6 .................................................................................................... 49
Tabela 7 – Teste 7 .................................................................................................... 50
Tabela 8 – Teste 8 .................................................................................................... 51
Tabela 9 – Tabela de riscos ...................................................................................... 52
LISTA DE ABREVIATURAS
ONS Operador Nacional do Sistema Elétrico
SCADA Surpervisory Control and Data Acquisition
UX User Experience
VR Realidade Virtual
AR Realidade Aumentada
SoC System on Chip
CPU Unidade Central de Processamento
GPU Unidade de Processamento Gráfico
HPU Unidade de Processamento Holográfico
LPDDR3 Low Power Double Data Rate
SRAM Static Random Access Memory
eMMC Embedded Multimedia Card
LE Low Energy
IDE Ambiente de Desenvolvimento Integrado
SDKs Kits de Desenvolvimento de Software
8
1 INTRODUÇÃO
Com o avanço do uso de tecnologias de realidade virtual e de realidade
aumentada nos últimos anos, é possível realizar a abstração de recursos
computacionais para um ambiente de computação virtual buscando melhorar a
utilização desses recursos por meio de uma plataforma operacional integrada
unificada para usuários e aplicativos com base na agregação de recursos
heterogêneos e autônomos. Mais recentemente, a virtualização em todos os níveis
(sistema, armazenamento e rede) tornou-se importante novamente como uma
maneira de melhorar a segurança, confiabilidade e disponibilidade do sistema, reduzir
custos e oferecer maior flexibilidade.
O sistema Organon do ONS (Operador Nacional do Sistema Elétrico) é um
sistema para avaliação da segurança de redes elétricas de potência que realiza
processos de análise estática e dinâmica de operações em tempo real, a qualidade e
interpretação dos dados são de importante necessidade. Como os sistemas SCADA
(Supervisory Control and Data Acquisition) necessitam de uma base de dados
confiável em tempo real, o ONS utiliza o sistema SCADA aplicado no controle de
sistemas elétricos para realizar aquisição de dados no sistema Organon.
Um dos problemas enfrentados por sistemas SCADA aplicados em controle de
sistemas elétricos é o desafio na apresentação e visualização de resultados utilizando
gráficos tridimensionais. Atualmente, os sistemas SCADA desse tipo fazem essa
representação dividindo informações (que deveriam estar em um único gráfico 3D) em
múltiplos gráficos 2D e gerando um grau de dificuldade para os operadores
conseguirem extrair as informações representadas de maneira precisa. Os
operadores do sistema Organon passam por longos treinamentos para estarem aptos
a interpretar as informações que estão segmentadas e para tomar uma decisão
baseada nos resultados do sistema SCADA. O sistema do Organon possui um
procedimento veloz na obtenção dos dados, porém a interpretação dos operadores
não segue a mesma velocidade.
Devido a essa diferença de velocidade de processamento do sistema Organon
em relação a velocidade de interpretação dos operadores sobre as representações
dos dados do sistema SCADA, encontra-se um gargalo no processamento da
informação. Considerando isso, propõe-se desenvolver uma ferramenta de realidade
aumentada com a capacidade de representação gráfica tridimensional do sistema
9
SCADA em controle de sistemas elétricos, para reduzir o gasto cognitivo e empoderar
com informações para uma tomada de decisão acertiva.
1.1 PROBLEMÁTICA
O Brasil possui um sistema de produção e transmissão de energia elétrica
composto majoritariamente por hidroelétricas com múltiplos proprietários.
Caracterizado como um sistema hidro-termo-eólico de grande porte, denominado
Sistema Interligado Nacional (SIN), é composto por quatro subsistemas: Sul,
Sudeste/Centro-Oeste, Nordeste e maior parte da região norte. A integração dos
subsistemas, realizado através da malha de transmissão, possibilita maior
economicidade e segurança ao mercado de trabalho. Isso só é possível pois, a
conexão entre os sistemas elétricos, proporcionam ganhos sinérgicos, transferência
de energia entre os subsistemas e propicia diversidade entre os regimes hidrológicos
das bacias.
Na prática, a automação de qualquer processo de avaliação de segurança está
relacionada a operação prática de planejamento da entidade de utilidade ou do
operador do sistema relevante. No Organon, três funções básicas de avaliação
estática e dinâmica são implementadas:
1. Transferência máxima entre dois subsistemas.
2. Região de segurança máxima para três subsistemas.
3. Máxima capacidade de carga e capacidade de carga máxima limitada por
contingência.
Além disso, funções são fornecidas para recomendar ações preventivas com base
em tais avaliações. É necessária uma ação preventiva quando uma ou mais
contingências levarão o estado do sistema para uma condição na qual pelo menos um
critério de segurança é violado. Essa ação, como a geração de um redespacho, move
o estado do sistema para um novo ponto de operação seguro.
Situações surgem onde os limites de transferência são altamente dependentes
dos padrões de geração em três áreas. Portanto, a geração de redespacho em apenas
dois padrões pode fornecer estimativas imprecisas do limite de transferência. Neste
ponto, o objetivo é buscar uma região segura na superfície bidimensional definida por
10
Pa + Pb + Pc = K, onde Pa, Pb e Pc são as gerações nas áreas e K é constante se as
perdas forem negligenciadas.
Figura 1 - Região de segurança projetada em dois subespaços de geração
A Figura 1 mostra três regiões, onde a região verde representa a região segura
de operação, a região amarela representa violação de um limite e a região em
vermelho representa onde o sistema fica instável.
A interpretação do que está contido na Figura 1 ainda é lenta e requer bastante
conhecimento do operador. Caso o ponto de operação da rede passe a sofrer
alterações, o operador deverá lidar com as três projeções do ponto se movimentando
ao mesmo tempo e em direções diferentes.
Sendo assim, a motivação do desenvolvimento deste trabalho se encontra na
pergunta: É possível, através de tecnologias de realidade aumentada aplicadas em
gráficos críticos do sistema SCADA de controle de sistemas elétricos, reduzir o gasto
cognitivo e empoderar com informações para uma tomada de decisão assertiva?
Para responder esta pergunta, este trabalho busca desenvolver uma ferramenta
de realidade aumentada em que seja possível representar os resultados do sistema
SCADA utilizado pelo ONS em um único gráfico 3D interativo, buscando aprimorar a
velocidade com que decisões são tomadas em sistemas de supervisão e controle no
ONS.
11
1.2 OBJETIVO
O objetivo desse trabalho foi dividido em dois subtópicos nesta seção, sendo
eles o objetivo geral e os objetivos específicos.
1.2.1 OBJETIVO GERAL
Propor e desenvolver uma ferramenta que utilize realidade aumentada e
técnicas de User Experience (UX) para reduzir a carga cognitiva e aprimorar com
informações mais precisas a tomada de decisão dos operadores do ONS em tempo
real.
1.2.2 OBJETIVOS ESPECÍFICOS
1. Estudar como são realizadas as análises de segurança de sistemas de
potência e como é a estrutura dos resultados utilizados na delimitação das
regiões de segurança desses sistemas.
2. Estudar técnicas de realidade aumentada, técnicas de UX, equipamentos,
softwares e linguagens de programação.
3. Modelagem: propor a arquitetura de uma ferramenta que será desenvolvida
com tecnologias de realidade aumentada e técnicas de UX e definir casos de
teste para a ferramenta proposta.
4. Desenvolvimento: utilizar as linguagens de programação estudadas para
transformar a modelagem proposta para a ferramenta em um sistema real e
funcional.
5. Validação: a validação da ferramenta será realizada através dos casos de
teste definidos durante a etapa de modelagem.
6. Elaborar documentação: registrar cada processo executado durante o
trabalho, visando a replicabilidade dos resultados e testes em trabalhos
futuros.
1.3 JUSTIFICATIVA
Atualmente os sistemas do tipo SCADA que possuem resultados na forma de
gráficos tridimensionais não possuem uma maneira de apresentá-los para os
12
operadores sem separar as informações em vários gráficos bidimensionais. Essa
estratégia acaba exigindo uma maior habilidade e treinamento dos operadores para
que consigam identificar e interpretar quais informações apresentadas são
importantes e tomar uma decisão rapidamente. O Organon possui um procedimento
veloz na obtenção dos dados, porém a interpretação dos operadores não segue a
mesma velocidade.
1.4 METODOLOGIA DO PROJETO
A metodologia utilizada no projeto consiste em duas grandes partes: estudos
teóricos e desenvolvimento. Cada uma contendo cinco subdivisões, e segue o fluxo
representado na Figura 2.
Figura 2 - Representação gráfica da metodologia do projeto
Primeiramente realizou-se um estudo voltado a maneira em que ocorrem as
análises de segurança em sistemas de potência para se familiarizar com vários
conceitos e para entender melhor o que caracteriza cada região de segurança definida
na análise. Em seguida, realizou-se um estudo voltado aos dados gerados por meio
13
da análise de segurança para entender como os sistemas conseguem gerar as
divisões entre cada região de segurança, assim como, aprender a manipular esses
dados que são a base do projeto.
Posteriormente realizou-se um estudo voltado para as tecnologias de realidade
aumentada e tecnologias de UX para ajudar na seleção de softwares e equipamentos
em fases posteriores do projeto e para a etapa de desenvolvimento. Pesquisou-se
técnicas e métodos de UX com as melhores características atrativas e funcionais
encontradas no mercado. Realizou-se então um levantamento de quais softwares e
equipamentos estavam disponíveis no mercado para desenvolvimento com realidade
aumentada que atendessem a esses requisitos de UX, assim como quais linguagens
de programação e motores de jogos são mais adequados e acabam facilitando a
implementação. Como já abordado, o Hardware de AR escolhido foi o HoloLens da
Microsoft, assim, realizou-se uma pesquisa de como desenvolver para Unity, por ser
um programa de desenvolvimento de formas 3D aceito pelos óculos de realidade
aumentada.
Na parte de desenvolvimento, inicialmente foi elaborado a arquitetura da
ferramenta e seus casos de testes. Em seguida foi feita a construção de um holograma
de gráfico 3D gerado sem aquisição de dados. A adição de funcionalidades de
atualizar o gráfico 3D e de gerar um alarme que reposiciona o gráfico 3D para o foco
da visão do usuário quando o ponto de operação da rede passa para uma região mais
crítica. E por fim, a geração do gráfico 3D através de dados.
Para melhor ilustrar os procedimentos do projeto, uma representação gráfica foi
criada, conforme na Figura 2.
14
1.5 ESTRUTURA DO DOCUMENTO
A estrutura deste documento está subdividida em nove seções. A primeira faz
uma descrição sobre os problemas enfrentados pelo ONS e os aspectos tecnológicos
relevantes ao problema em questão. A segunda seção trata o estado da arte,
explorando o sistema Organon, Realidade Aumentada (AR), Sistemas SCADA e
Digitalização dos Sistemas Elétricos. Na terceira, tem-se o diagrama de blocos
ilustrando a visão geral do sistema a ser desenvolvido. A quarta seção apresenta as
tecnologias que serão utilizadas. A etapa de testes para validação do projeto encontra-
se na quinta seção. A sexta seção trata da análise de riscos aos quais o projeto está
sujeito. Na sétima seção encontra-se o cronograma elaborado para as etapas e as
atividades que fazem parte do projeto. A oitava seção apresenta a conclusão sobre o
projeto desenvolvido. E finalmente, a última seção corresponde a referências
bibliográficas que foram utilizadas durante todo o projeto.
15
2 REVISÃO BIBLIOGRÁFICA
Criar um projeto com a capacidade de gerar gráficos 3D interativos através das
suas projeções utilizando tecnologias de realidade aumentada em sistemas de
supervisão e controle aplicados em sistemas elétricos é uma aplicação muito
específica. Dessa forma, não existe hoje uma tecnologia no mercado que consiga
suprir uma necessidade tão específica.
Como no desenvolvimento são utilizados diversos equipamentos e sistemas, é
necessário apresentá-los e justificar a seleção para o projeto.
2.1 SISTEMA SCADA
É uma arquitetura de sistema de controle que utiliza computadores,
comunicações de dados em rede e interfaces gráficas de usuário para realizar o
gerenciamento e a supervisão de processos de alto nível. Os sistemas SCADA
utilizam outros dispositivos periféricos, como controlador lógico programável (PLC) e
controlador proporcional integral derivativo (PID) discretos, para fazer interface com a
planta de processo ou maquinaria. As interfaces de operação que permitem o
monitoramento e a emissão de comandos de processo, como alterações do ponto de
ajuste do controlador, são tratadas por meio do sistema SCADA. A lógica de controle
em tempo real e os cálculos do controlador são executados por módulos em rede que
se conectam aos sensores de campo e aos atuadores.
O conceito SCADA foi desenvolvido como um meio universal de acesso remoto
a uma variedade de módulos de controle locais, que podem ser de diferentes
fabricantes, permitindo acesso através de protocolos de automação padrão. Na
prática, os sistemas SCADA de grande porte cresceram para se tornar muito
semelhantes aos sistemas de controle distribuídos em função, mas usando vários
meios de interface com a fábrica. Eles podem controlar processos em larga escala
que podem incluir vários locais e trabalhar em grandes ou pequenas distâncias.
2.1.1 DIGITALIZAÇÃO DE SISTEMAS SCADA
A evolução e digitalização nos sistemas SCADA está aliada a um volume de
informação cada vez maior. Dessa forma, a análise dos dados gerados por cada
16
dispositivo tecnológico é preponderante para a detecção de eventos anormais no
sistema, assim como para o diagnóstico de problemas do próprio sistema.
A digitalização nos sistemas SCADA traz uma série de benefícios, dentre eles
é possível destacar:
• Melhoria contínua na qualidade da energia
• Maior confiabilidade na operação das subestações e equipamentos
• Otimização dos investimentos e redução dos custos de instalação,
manutenção e operação
• Redução do espaço físico requerido nas salas de controle para alocar
os sistemas de controle e de proteção
• Acesso à informação sobre o sistema de transmissão da empresa em
tempo real, permitindo uma melhoria substancial na qualidade da
tomada de decisão no caso de necessidade de manobras e de análise
de atuação do sistema de proteção
2.2 TECNOLOGIAS DE REALIDADE VIRTUAL E AUMENTADA
Esta seção foi reservada para esclarecer a diferença entre Realidade Virtual
(VR) e Realidade Aumentada (AR).
2.2.1 REALIDADE VIRTUAL
Realidade virtual é uma interface de usuário-computador high-end que envolve
simulação em tempo real e interação através de múltiplos canais sensoriais. Essas
modalidades sensoriais são visuais, auditivas, táteis, olfativas e gustativas.
Segundo Kirner [1], realidade virtual é uma interface avançada para aplicações
computacionais, onde o usuário navega e interage em tempo real, em um ambiente
3D gerado por computador, utilizando dispositivos multissensoriais.
2.2.2 REALIDADE AUMENTADA
Segundo Azuma [2], em realidade aumentada os objetos virtuais
complementam em vez de suplantar o mundo real, preservando a ilusão de que os
17
dois coexistem requer alinhamento e registro adequados dos objetos virtuais para o
mundo real.
Segundo Azuma [3], realidade aumentada é um sistema que permite ao usuário
ver o mundo real, com objetos virtuais sobrepostos ou compostos com o mundo real.
Esse sistema tem as seguintes três características: combina real e virtual, é interativo
em tempo real e é registrado em 3D.
2.3 ORGANON
O Organon é um sistema de avaliação da segurança de sistemas de potência
aplicado tanto a problemas de natureza estática, quanto de natureza dinâmica. Esse
sistema emprega computação de alto desempenho e algoritmos com grande robustez
numérica, possibilitando uma modelagem detalhada da rede elétrica em ambiente de
processamento distribuído. O programa contém módulos para cálculo de fluxo de
potência, fluxo de potência continuado, simulação eletromecânica e rotinas de
diagnóstico automático para detecção de instabilidade e verificação de critérios, tais
como os definidos nos procedimentos de rede do ONS.
O fluxo de potência convencional é baseado no algoritmo denominado “Full
Newton”, que incorpora todos os modelos de equipamentos, tais como tapes de
transformadores, elos de corrente contínua, dentre outros. O fluxo de potência por
dinâmica sintética é um algoritmo que proporciona a solução de casos de difícil
convergência, utilizando o princípio de que a resposta dinâmica de um sistema de
potência estável converge para um ponto de equilíbrio estável. A obtenção de uma
solução robusta e menos dependente das condições iniciais durante a solução do
problema de fluxo de potência é fundamental para a determinação de uma correta
região de segurança.
O Organon também é equipado com um fluxo de potência continuado,
possibilitando a mudança automática de pontos de operação de acordo com as novas
condições do sistema. Neste método os pontos de equilíbrio são traçados à medida
que um parâmetro varia no sistema, sendo as equações de fluxo de potência
reformuladas de maneira a incluir o parâmetro de bifurcação. Esta técnica tem-se
mostrado útil para a determinação precisa do máximo carregamento de sistemas,
sendo no Organon esta técnica também utilizada para a definição de uma região de
segurança através da exploração da vizinhança de um ponto de operação.
18
A simulação eletromecânica é implementada considerando a solução simultânea
da rede elétrica e da dinâmica do sistema, resultando em um sistema de equações
diferenciais e algébricas de difícil integração numérica e que requer a adoção de
métodos de solução com rápida atenuação de oscilações numéricas.
Todas essas ferramentas estão integradas em um único ambiente com interface
gráfica amigável que possibilita a entrada de dados através de arquivos, linhas de
comandos janelas de diálogo, seleção de menus e a visualização de resultados via
relatórios e gráficos. O sistema pode ser utilizado tanto para tarefas simples como na
solução de um caso de fluxo de potência no modo interativo e monousuário, quanto
para cálculos mais complexos como na obtenção de uma região de segurança
dinâmica em ambiente de tempo real, atualizando os resultados de forma automática
e em intervalos de tempo predefinidos através do processamento distribuído. Essa
flexibilidade possibilita uma maior integração entre as equipes de estudos de
planejamento e programação da operação com as de operação em tempo real do
ONS.
2.3.1 INFORMAÇÕES E DADOS
Nessa seção será abordado mais especificamente o processo de Cálculo e
Determinação da Região de Segurança, assim como a estrutura do arquivo de saída
do sistema Organon (EMSCLIENT.OUT), utilizado para geração do XML dos dados
da Região segura que posteriormente é enviado para o sistema SAGE de supervisão
e controle (desenvolvido pela COPEL e utilizado no ONS). O XML é um padrão lido
pelo aplicativo VisorChart e permite que os nomogramas sejam exibidos no SAGE.
2.3.1.1 CÁLCULO E DETERMINAÇAO DA REGIAO DE SEGURANÇA
O cálculo da região de segurança consiste em avaliar a condição do sistema
elétrico em um ponto de operação inicial, bem como em sua vizinhança. Essa análise
pode ser de natureza estática, onde se identificam problemas de violação de faixas
operativas e de sobrecargas em equipamentos, limites de tensão e de máximo
carregamento da rede. Na região de segurança dinâmica, além dos problemas citados
anteriormente, também são avaliados critérios tais como nível de amortecimento das
oscilações, afundamento da tensão e a própria condição de instabilidade
eletromecânica. A exploração da vizinhança do ponto de operação é feita basicamente
19
através da mudança do despacho de geração em três grupos de usinas definidos a
priori.
O processo inicia com a avaliação do ponto de operação inicial. Nessa
avaliação são simuladas diversas contingências definidas a priori. Em seguida é feita
uma busca em direções radiais, a partir do ponto inicial, com análise da lista de
contingências para cada novo ponto de operação gerado, até que se encontre o limite
naquela direção. Esse limite pode ser realmente um limite de segurança, ou apenas
um limite de geração, no qual todos os geradores de um grupo atingiram sua
capacidade máxima ou mínima de geração.
O limite de segurança na região de segurança estática indica a falta de
convergência do fluxo de potência na simulação de pelo menos uma contingência. Na
região de segurança dinâmica, o limite de segurança indica a ocorrência de
instabilidade na simulação eletromecânica de pelo menos uma contingência. Quando
ocorre um ponto inseguro no deslocamento em uma direção, é iniciada uma busca
binária de forma a identificar dois pontos sucessivos, nos quais o sistema é seguro
em um ponto e inseguro no outro e a distância entre eles é inferior a uma tolerância
definida. Esse último ponto seguro é considerado o limite da região naquela direção.
Os dois primeiros grupos de geração governam o deslocamento na região de
segurança. Entretanto, é necessário definir um terceiro grupo de geração que
acomode os excessos ou déficits de geração que ocorrem quando há a elevação ou
redução simultânea da geração naqueles dois grupos. Caso haja a violação de algum
critério estabelecido durante o processo de deslocamento em uma direção, o ponto
com a violação é identificado e assinalado o critério violado. A região de segurança
pode apresentar então contornos que separam sub-regiões em que há a violação de
critérios das que não há essa violação.
Nos Nomogramas fornecidos pelo Organon, a área delimitada pela curva
externa que contorna a figura representa a região contendo pontos de operação em
que é garantido a estabilidade transitória do sistema, mesmo na ocorrência da pior
contingência para o sistema estudado. Esta curva contém duas regiões: uma
assinalada pela área verde escuro, onde apesar de segura poderá haver violação em
critérios e outra, em amarelo, requerendo a necessidade de tomadas de ações
corretivas (normalmente pós-distúrbio), de modo a sanar sobrecarga em pelo menos
um equipamento da rede.
20
Uma estreita área assinalada entre as curvas verde claro e magenta indica que
poderá haver, para pontos de operação localizados na área verde escuro, violação do
critério estabelecido no Procedimentos de Rede de máxima variação de tensão de
10% e para pontos localizados na área verde escuro superiores a curva verde claro
violações do critério de tensão mínima admissível na rede de 90%.
Figura 3 - Nomograma com áreas assinaladas
Pontos de operação na região sinalizada pela cor vinho podem representar um
desempenho inseguro, ou apenas o esgotamento, para o número de máquinas
sincronizadas, dos recursos de geração que permitam a excursão nos eixos pré-
estabelecidos
2.3.1.2 ESTRUTURA DO ARQUIVO EMSCLIENT.OUT
• Linha 1 - Diretório onde o arquivo se encontra.
• Linha 2 - Número relacionado ao tipo de análise da região de segurança.
• Linha 3 - Número de direções para a região de segurança.
• Linha 4 - TimeStamp para verificação, índice da instância e formato humano do
TimeStamp: Dessa forma, é possível saber a qual simulação e instância o arquivo
se refere.
• Linha 5 - Tempo em segundos para o término da simulação.
21
• Linha 6 - Código de execução da simulação e o texto associado.
• Linha 7 - Código de avaliação da segurança e o texto associado.
• Linha 8 e 9 - Título do caso de lastro físico, onde o Organon obtém de um arquivo
extensão STM.
• Linha 10 - Identificação dos campos dos registros e os identificadores de cada
grupo.
• Linha 11 - Valores para o ponto de operação.
• Linha 12 - Valores para as gerações máximas.
• Linha 13 – Valores para as gerações mínimas.
• Linha 14 até registro com terminador ‘-9’ – Bloco de resultados para o Tabular.
• Blocos de Registros contendo as coordenadas dos vértices dos nomogramas:
O registro inicial de cada bloco contém o número de registros subsequentes do
bloco. Cada um desses registros traz a abscissa e ordenada do vértice e o texto a ser
exibido quando se passa o mouse por ele (tooltip). Os blocos são ordenados da
seguinte forma: vértices das curvas de Região de Segurança (VS), Limite Térmico
(TL), Limite de Tensão (VV) e por fim o Limite para os nomogramas G1xG2, G1xG3,
G2xG3 e Ábaco (UDT).
• Bloco de valores para Máscaras adicionais no Ábaco:
Para o Ábaco, além das 5 curvas descritas para os 3 nomogramas de geração
anteriores, pode haver mais duas curvas. Dois blocos de Registros contendo as
coordenadas dos vértices das máscaras do Nomograma 4. O primeiro e o segundo
bloco contêm as coordenadas referentes as máscaras. O registro inicial de cada bloco
contém o número de registros subsequentes do bloco. Cada um desses registros traz
a abscissa e ordenada do vértice e o texto (se existir) a ser exibido, quando se passa
o mouse por ele (tooltip).
• Bloco de Resultados para Violações no Ponto de Operação:
Blocos de Registros contendo as informações referentes às violações no ponto
de operação. O registro inicial de cada bloco contém o número de registros
subsequentes do bloco. Cada um desses registros traz o identificador da contingência
e do equipamento associado à violação. O número de registros no arquivo para cada
tipo de violação não é necessariamente o mesmo e pode ser zero.
22
2.4 PROGRAMAÇÃO GRÁFICA
Como o projeto envolve o desenvolvimento com realidade aumentada, as
linguagens de programação que mais se destacam são C# e C/C++, uma vez que são
utilizadas nos principais motores de jogos disponíveis, Unity e Unreal Engine,
respectivamente.
Motor de jogo é um programa ou conjunto de bibliotecas que simplificam e
abstraem o desenvolvimento de aplicações que possuem gráficos em tempo real,
renderização de gráficos 2D ou 3D e detecção de colisão. Para poder utilizar essas
plataformas de desenvolvimento no projeto é necessário realizar algumas
configurações de produto.
2.4.1 CONFIGURAÇÕES DO UNITY
Segundo a Microsoft [4], é necessário realizar a configuração do Unity antes de
iniciar o desenvolvimento de um programa para o HoloLens. Esses ajustes são
divididos em três tipos, câmera principal (Main Camera), Plataforma (Platform) e
ajustes de jogador (Player Settings). Na câmera principal (Figura 4), alterou-se a cor
de fundo (Backgrounds) para preta sólida, pois no HoloLens a cor preta de fundo é
considerada transparente. Em seguida diminuiu-se a distância da câmera entre a
renderização do objeto (Clipping Planes) para 0.85, valor recomendado na
documentação para que o objeto não inicie muito próximo ou muito distante do
operador.
Figura 4 – Main Camera no Unity
23
A segunda configuração é realizada na plataforma, onde é escolhido o tipo de
plataforma e feito a sua configuração. Primeiramente é selecionado a plataforma
Universal Windows Platform (UWP), que possui as opções de configurações para o
dispositivo HoloLens, em seguida é escolhida a versão do SDK utilizada, versão alvo
do Visual Studio e o dispositivo alvo, que para o projeto é utilizado o HoloLens.
Figura 5 – Configuração plataforma no Unity
Para a terceira a última etapa da configuração do Unity, em PlayerSettings
(Figura 6 e Figura 7) ativa-se os recursos necessários para operação do óculos,
SpatialPerception e Microphone. Sem eles o dispositivo não seria capaz de
reconhecer o ambiente em sua volta e os comandos de voz. É importante que o
suporte a realidade virtual seja ativado para que os projetos sejam compatíveis com
os objetos 3D
24
Figura 6 – PlayerSettings – Publishing Settings
Figura 7 – PlayerSettings – XR Settings
25
3 PROPOSTA CONCEITUAL DA FERRAMENTA DE REALIDADE AUMENTADA
PARA APRIMORAR A TOMADA DE DECISÃO EM SISTEMAS DE
SUPERVISÃO E CONTROLE NO ONS
Esta seção é dedicada a modelagem, definição de hardware e software,
critérios de teste e análise de riscos do projeto.
3.1 DEFINIÇÃO DO HARDWARE
Durante as primeiras fases de planejamento do projeto, tinha-se em mente a
utilização da tecnologia VR para seu desenvolvimento, visto que esta é uma interface
acessível e amplamente utilizada no desenvolvimento de aplicações de mercado,
consequentemente apresenta inúmeras referências bem documentadas.
Posteriormente considerou-se que UX é um fator importante no desenvolvimento do
projeto e que AR deveria ser uma tecnologia a ser considerada. Isso porque através
da tecnologia de AR é possível visualizar o holograma ao mesmo tempo em que se
observa o mundo real, proporcionando melhor conforto e agilidade nas tomadas de
decisão. Sendo assim, para o trabalho foram escolhidos a tecnologia de AR e o
Microsoft HoloLens (Figura 8) por ser uma das ferramentas mais avançadas e
completas na parte de AR disponível no mercado atualmente.
Figura 8 - Microsoft HoloLens
O Microsoft HoloLens possui uma unidade de medição inercial (que inclui um
acelerômetro, giroscópio e um magnetômetro), quatro sensores de “compreensão do
ambiente” (dois de cada lado), uma câmera de profundidade com eficiência energética
e com campo de visão de 120° x 120°, uma câmera vídeo fotográfica de 2.4
26
megapixels, uma matriz de quatro microfones e um sensor de luz ambiente. Além de
um Intel Cherry Trail SoC (System on Chip) contendo a CPU (Unidade central de
processamento) e a GPU (Unidade de processamento gráfico), o HoloLens possui
uma HPU (Unidade de processamento holográfico) da Microsoft. O SoC e a HPU
possuem 1GB de memória LPDDR3 (Low Power Double Data Rate) e compartilham
8MB de SRAM (Static Random Access Memory), com o SoC também controlando
64GB de eMMC (Embedded Multimedia Card) e executando o sistema operacional
Windows 10. A HPU usa 28 processadores de sinais digitais personalizados da
Tensilica para processar e integrar dados dos sensores, além de lidar com tarefas
como mapeamento espacial, reconhecimento de gestos e reconhecimento de voz e
fala. O HoloLens contém uma bateria interna recarregável, com vida útil média de 2 a
3 horas de uso ativo ou 2 semanas de tempo de espera, podendo ser operado durante
o carregamento. Possui Wi-Fi IEEE 802.11ac, micro USB 2.0 e conectividade sem fio
Bluetooth 4.1 Low Energy (LE). A velocidade de transmissão pode chegar a 450Mbps
quando utilizado em uma rede Wi-Fi, 480Mbps se utilizado com a conexão via cabo
USB e 24Mbps se utilizado uma conexão Bluetooth.
3.2 DEFINIÇÃO DO SOFTWARE
A escolha do software se dá pela escolha do Microsoft HoloLens como
hardware a ser utilizado no projeto. Sendo assim, o software escolhido para o projeto
segue as recomendações para desenvolvimento do fabricante.
Segundo a documentação disponibilizada pela Microsoft [4], o desenvolvimento
de aplicações com o HoloLens utiliza uma série de ferramentas e kits de
desenvolvimento de software (SDKs) diferentes. É recomendado pela Microsoft utilizar
o Unity ao DirectX por questões de facilidade.
Para o projeto, será necessário utilizar o sistema operacional Windows 10 (pois
é o sistema que o HoloLens é compatível), o ambiente de desenvolvimento integrado
(IDE) Visual Studio 2017, o HoloLens Emulator, o Unity 2018.3.14f1 e o Mixed Reality
Toolkit.
O Microsoft Visual Studio 2017 é uma IDE que será utilizada juntamente com o
Unity 2018.3.14f1 e o Mixed Reality Toolkit para desenvolver os gráficos
tridimensionais. Os gráficos serão testados utilizando o emulador HoloLens (incluído
27
no IDE do Visual Studio 2017) ou com o HoloLens Development Edition, onde é
possível testar diretamente no HoloLens.
3.3 ARQUITETURA DA SOLUÇÃO
A solução proposta utiliza o Microsoft HoloLens como hardware e um software
desenvolvido utilizando o ambiente de desenvolvimento Microsoft Visual Studio 2017
com o motor de jogo Unity para construir um holograma de um gráfico 3D com base
em dados resgatados diretamente de um arquivo de coordenadas dentro do Microsoft
HoloLens, que representa o arquivo gerado como resultado da análise de segurança
feita pelo Organon.
Primeiramente para que os dados do Organon sejam enviados para dentro do
HoloLens, criou-se um meio de comunicação entre os dois através de Sockets, cada
um dos dois lados da comunicação gera arquivos para controle de dados.
O foco principal da solução é o gráfico 3D. Ele possui as funcionalidades de
ampliar, reduzir, rotar e reposicionar, de maneira que o operador consiga interagir com
o gráfico através dos gestos predefinidos do HoloLens, para facilitar a interpretação
dos resultados de análise do Organon, reduzir a carga cognitiva necessária pelo
operador e aprimorar a tomada de decisões em tempo real quanto a ações de
contingência.
O diagrama de blocos a seguir (Figura 9) apresenta uma visão geral dos
relacionamentos abordados. Cada parte do diagrama é identificada dentro do círculo
localizado no seu canto superior esquerdo. O escopo do projeto será abordado nos
itens B, C e D junto com o detalhamento da aplicação.
28
Figura 9 - Diagrama de Blocos do Projeto
3.3.1 FLUXO DE DADOS
Para facilitar a visualização do fluxo de dados, este foi separado em quatro
etapas conforme a Figura 10:
Figura 10 – Fluxo de Dados do Projeto
29
O primeiro item do fluxo de dados representa a utilização de um script em C#
dedicado para criar um arquivo CSV contendo as coordenadas dos pontos que serão
plotados no gráfico 3D. O segundo item do fluxo representa a utilização de um script
em C# dedicado a enviar o arquivo CSV pela rede Wi-Fi até uma porta do HoloLens.
O terceiro item representa o armazenamento do arquivo CSV no sistema de
arquivos do HoloLens, executado quando o arquivo chega pela rede Wi-Fi.
Por fim, o quarto item representa a atualização do gráfico 3D, gerada quando o
sistema de arquivos do HoloLens finaliza o armazenamento do arquivo recém-
chegado.
3.3.2 GESTOS PREDEFINIDOS DO HOLOLENS
O Microsoft HoloLens possui uma série de gestos predefinidos (Figura ) que
podem ser utilizados para interagir com qualquer holograma. Esses gestos são
importantes para que o usuário tenha uma UX melhor e consiga manipular e alterar
os hologramas conforme desejado. Para o Microsoft HoloLens reconhecer um gesto,
é necessário que o usuário posicione suas mãos dentro do campo de visão das
câmeras do HoloLens e realize um dos gestos, como na imagem a seguir:
Figura 11 - Gestos predefinidos no Microsoft HoloLens
30
3.3.3 APLICAÇÃO DE UM HOLOGRAMA DE GRÁFICO 3D BASEADO NOS
RESULTADOS DE ANÁLISE DO ORGANON
Com os gestos predefinidos, o usuário consegue navegar pelo menu de
aplicações instaladas no HoloLens e iniciar a aplicação chamada “Organon” com
comando de voz ou com gestos. A aplicação se resume a um holograma em forma de
cubo, o usuário pode interagir com esse holograma utilizando os gestos predefinidos.
O cubo é composto por: um ponto Vermelho que representa o ponto de
operação do Sistema de potência sendo analisado pelo Organon, três eixos
nomeados que representam quais são os parâmetros sendo monitorados pelo
Organon, uma região de segurança em Vermelho que representa onde o Sistema de
potência estará instável, uma região de segurança em Amarelo que representa um
estado de alerta onde um dos parâmetros sendo analisado passou do limite
considerado seguro, uma região de segurança em Verde que representa onde é
seguro para o Sistema de potência.
A aplicação utiliza um script codificado em C# para acessar um arquivo de
coordenadas e buscar onde cada vértice está localizado dentro do cubo para então
criar cada região (Vermelho, Amarelo e Verde) e o ponto de operação.
Quando o ponto de operação é atualizado para uma região de maior
instabilidade (da região Verde para Amarela ou da região Amarela para Vermelha), o
cubo e a legenda são reposicionados para o foco do usuário. Dessa forma, se o
usuário fixar os hologramas em um espaço e não estiver olhando diretamente para
eles quando o ponto de operação for atualizado para uma região mais instável, a
aplicação irá trazer os hologramas até o seu foco, como forma de alertá-lo que houve
uma mudança do estado de segurança do Sistema de potência.
3.3.4 ARQUIVO DE COORDENADAS DO PONTO DE OPERAÇÃO E DAS
REGIÕES DE SEGURANÇA
O ponto de operação e cada vértice que compõem as regiões de segurança
estão definidas dentro de um arquivo CSV, como no exemplo representado pela
Figura 11 com os dados salvos manualmente através de uma conexão USB com um
computador, para simular o resultado da análise de rede do Organon. Os
pontos seguem um padrão dentro do arquivo: cada ponto possui uma componente
31
para cada eixo cartesiano (X, Y e Z) com valores entre 0.000 e 1.000, sendo que 1.000
representa o último ponto que é possível ter no eixo, pois atinge o limite da região do
cubo. Cada linha do arquivo representa um vértice (ou ponto) que será inserido no
gráfico 3D para delimitar cada uma das regiões de operação.
Figura 11 – Arquivo CSV com coordenadas
Cada coluna do arquivo é referente a uma das regiões, na primeira linha encontra-
se a definição de cada região responsável pelos pontos em suas colunas, são elas:
• Primeira coluna para o ponto de operação,
• Segunda coluna para a região verde de operação (Região segura).
• Terceira coluna para a região amarela de operação (Região de
instabilidade).
• A região vermelha não necessita de um conjunto de vértices definidos
no arquivo, pois ela se encontra entre a região Amarela e os limites do
cubo.
A separação de cada vértice de uma região foi feita através das linhas do
arquivo CSV, de maneira que seus pontos fiquem agrupados em uma mesma célula.
Para facilitar a identificação de cada conjunto de dados de um cubo, realizou-se a
separação através de arquivos, com identificação única através de um Timestamp.
Com essa organização do arquivo de coordenadas é possível fazer uma leitura
de cima para baixo das partes mais internas do cubo para as mais externas, facilitando
a construção do holograma 3D do cubo.
No projeto se utilizou um código de geração de arquivos CSV para facilitar a
simulação dos dados gerados pelo Organon, com intuito de ampliar a velocidade de
desenvolvimento e obter a possibilidade de simular ambientes próximos do real
mesmo sem ter acesso ao sistema Organon.
32
A funcionalidade do código é bastante simples, sua operação básica se baseia
no princípio da manipulação de vetores String e leitura/escrita em arquivos. No
primeiro bloco do código inicializou-se as bibliotecas utilizadas no programa.
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading; using System.Threading.Tasks; using Linq.Csv; using System.IO;
Além das bibliotecas padrões do sistema, foram adicionadas bibliotecas para
trabalhar com sistema de threads e manipulação de arquivos.
No segundo bloco do programa foi feita a identificação única do arquivo, a
aquisição dos dados e a primeira manipulação dos dados. A identificação única é feita
através do Timestamp que é adicionado ao nome do arquivo. Com os dados coletados
pela função ReadLine(), que coleta o que foi digitado pelo usuário, o programa salva
cada ponto em um vetor através do método Split(‘ ’). Aproveitando-se que os dados já
estão em um vetor, o programa obtém o tamanho deles para operar no próximo bloco.
String hora = DateTime.Now.ToString("dd-MM-yyyy-HH-mm-ss"); String filePath = @"D:\Users\marco\Documents\SalvaArquivo\" + hora + ".csv"; var PT_aux = PT.Split(' '); var VD_aux = VD.Split(' '); var AM_aux = AM.Split(' '); var tam_VD = VD_aux.Length; var tam_AM = AM_aux.Length; if (tam_AM < 24 || tam_VD < 24) { Console.WriteLine("\nDeve ser incerido pelo menos 24 cordenadas por regiao..."); Thread.Sleep(3000);
}
Para o terceiro bloco e o mais importante, adiciona-se o cabeçalho do arquivo CSV e
cada um dos seus respectivos pontos. Para que cada coluna receba seu respectivo
ponto foi feito um for que preenche o dado em determinada coluna de acordo com seu
tamanho de vetor. Para acessar o código inteiro, verificar o apêndice do documento.
33
string header = ("Ponto; Verde; Amarela\n"); File.WriteAllText(filePath, header);
var maxValue = Math.Max(tam_AM, tam_VD);
for (int i = 0; i < maxValue; i = i + 3) {
if (i < 3) {
File.AppendAllText(filePath, PT_aux[i] + "," + PT_aux[i + 1] + ","
+ PT_aux[i + 2] + ";"); }
else File.AppendAllText(filePath, ";"); if (i < tam_VD) {
File.AppendAllText(filePath, VD_aux[i] + "," + VD_aux[i + 1] + ","
+ VD_aux[i + 2] + ";"); }
else File.AppendAllText(filePath, ";"); if (i < tam_AM) {
File.AppendAllText(filePath, AM_aux[i] + "," + AM_aux[i + 1] + ","
+ AM_aux[i + 2] + "\n"); }
else File.AppendAllText(filePath, "\n"); }
3.3.5 CONSTRUÇÂO DO PROGRAMA DE COMUNICAÇÂO SOCKET
Para que o HoloLens receba os dados do arquivo CSV localizado dentro do
computador, é necessário desenvolver um programa de comunicação entre os dois
dispositivos. Como a velocidade de comunicação não pode se tornar um gargalo de
informações no projeto, visto que é uma aplicação em tempo real, optou-se por
comunicação via sockets, por ser um tipo de conexão mais veloz e segura as
limitações do projeto. Nesse tópico do documento será abordado uma explicação dos
principais blocos do programa desenvolvido. Para obter o código completo, ele se
encontra no Apêndice do documento.
Para comunicação desenvolveu-se duas partes de código, uma para o cliente
(Computador) e outra para o servidor (HoloLens).
3.3.5.1 CÓDIGO CLIENTE
Para o primeiro bloco do projeto configurou-se a porta de conexão e o Ip em
que o cliente utiliza para se conectar ao servidor. Através da função
FileSystemWatcher(), o programa obtém recursos para analisar qualquer tipo de
operação realizada sobre os arquivos localizados dentro de uma pasta específica,
34
para essa aplicação utilizou-se apenas o Watcher para criação de novos arquivos.
Para isso é fornecido o diretório do arquivo que é gerado pelo programa de geração
de arquivo CSV.
public static string serverIp = "localhost"; public static int port = 8080;
static void Main(string[] args) { // Instanciamento do objeto var fileSystemWatcher = new FileSystemWatcher();
// Associação do operador de eventos com os eventos fileSystemWatcher.Created += FileSystemWatcher_Created;
// diretorio do arquivo para vigilancia do Watcher fileSystemWatcher.Path =
@"D:\Users\marco\Documents\SalvaArquivo";
// You must add this line - this allows events to fire. fileSystemWatcher.EnableRaisingEvents = true;
WriteLine("Listening..."); WriteLine("(Press any key to exit.)");
ReadLine(); }
O programa se mantem ativo ouvindo na pasta por qualquer tipo de criação de
arquivos, assim que um arquivo é criado ele invoca a função
FileSystemWatcher_Created(), que além de chamar a função que envia os dados do
arquivo CSV, também realiza um Log da operação no console.
// Funcao ativa com a criação de um arquivo novo na pasta
private static void FileSystemWatcher_Created(object sender,
FileSystemEventArgs e)
{
ForegroundColor = Blue;
WriteLine($"A new file has been created - {e.Name}");
EnviaArquivo(sender, e);
}
Para o último bloco do código, o programa tenta abrir uma conexão com o
servidor e abre o arquivo CSV, adicionando seu conteúdo em um novo vetor. Para
saber o tamanho do arquivo, é realizado o cálculo do número de bytes da informação,
assim o vetor é construído a partir desse número de bytes. Após enviar esses dados,
o programa fecha o arquivo e a conexão com o servidor. Caso o programa não consiga
abrir o arquivo ou realizar a conexão com o servidor, ele apresenta um erro para
informar o usuário que a operação não foi realizada com sucesso.
35
try {
TcpClient client = new TcpClient(serverIp, port); Thread.Sleep(1000);
StreamReader rd = new StreamReader(@"D:\Users\marco\Documents\SalvaAr-
quivo\" + e.Name);
string arquivo = rd.ReadToEnd();
int byteCount = Encoding.ASCII.GetByteCount(arquivo);
byte[] sendData = new byte[byteCount];
sendData = Encoding.ASCII.GetBytes(arquivo);
NetworkStream stream = client.GetStream();
stream.Write(sendData, 0, sendData.Length);
rd.Close();
stream.Close();
client.Close();
ForegroundColor = Green;
WriteLine($"Dados enviado ao servidor - {e.Name}"); }
catch {
ForegroundColor = Red;
WriteLine($"Erro ao enviar os dados ao servidor - {e.Name}"); }
3.3.5.2 CÓDIGO SERVIDOR
O bloco do código principal do servidor, mantem uma porta de conexão aberta
e espera que o cliente se conecte com ele através de uma conexão TCP. No momento
que recebe a conexão do cliente, ele salva os arquivos recebidos em um buffer de
1000 bytes. Com os dados recebidos, o servidor gera outro arquivo CSV em um dos
seus diretórios, mantendo assim uma cópia do arquivo que o cliente enviou.
36
try {
server.Start();
Console.WriteLine("Server Started..."); }
catch (Exception ex) {
Console.WriteLine(ex.ToString());
Console.Read();
}
while (true) {
client = server.AcceptTcpClient();
Console.Clear();
byte[] receivebuffer = new byte[1000]; NetworkStream strem = client.GetStream();
strem.Read(receivebuffer, 0, receivebuffer.Length);
StringBuilder msg = new StringBuilder();
foreach (byte b in receivebuffer) {
if (b.Equals(00)) {
break; }
else {
msg.Append(Convert.ToChar(b).ToString());
}
}
File.WriteAllText(filePath, msg.ToString());
Console.WriteLine(msg.ToString());
3.3.6 CONSTRUÇÃO DO GRÁFICO 3D NO UNITY
Para realizar a construção do gráfico 3D no Unity foi criado um projeto em branco
chamado “Organon”. Dentro do projeto foram adicionados o Mixed Reality Toolkit
(MRTK) da Microsoft, e dentro do SceneContent foi adicionado um cubo chamado de
CubeBoundingBox, que será responsável por conter a maioria dos scripts
relacionados a manipulação de hologramas no HoloLens. A figura a seguir ilustra a
hierarquia do projeto:
37
Figura 12 – Hierarquia do Projeto no Unity
Em seguida, a configuração do CubeBoundingBox foi realizada conforme a
imagem a seguir:
Figura 13 – Configuração do Cube Bounding Box
38
A figura a seguir mostra quais scripts do MRTK foram ser adicionados ao
CubeBoundingBox, assim como a configuração de cada um deles:
Figura 14 – Scripts do MRTK adicionados ao Cube Bounding Box
39
Figura 15 – Configuração do script Bounding Box
Figura 16 – Configuração do script Near Interaction Grabbable
40
Figura 17 – Configuração do script Manipulation Handler
41
Figura 18 – Configuração do script Transform Scale Handler
Por fim, foi necessário criar um script em C# ao CubeBoundingBox chamado
UniversalSampleTutorial contendo o código a seguir para realizar a parte de
comunicação TCP utilizando sockets:
using System; using System.Collections; using System.Collections.Generic; using UnityEngine; using UnityEngine.UI; #if !UNITY_EDITOR using Windows.Networking; using Windows.Networking.Sockets; using Windows.Storage.Streams; #endif //Able to act as a reciever public class UniversalSampleTutorial : MonoBehaviour { public GameObject[] Prefabs; private int activePrefabIndex = 0; Vector3 position, devicePosition; Quaternion rotation; public String _input = "Waiting"; #if !UNITY_EDITOR StreamSocket socket; StreamSocketListener listener; String port; String message; #endif // Use this for initialization void Start() { #if !UNITY_EDITOR listener = new StreamSocketListener(); port = "9090"; listener.ConnectionReceived += Listener_ConnectionReceived; listener.Control.KeepAlive = false; Listener_Start(); #endif }
42
#if !UNITY_EDITOR private async void Listener_Start() { Debug.Log("Listener started"); try { await listener.BindServiceNameAsync(port); } catch (Exception e) { Debug.Log("Error: " + e.Message); } Debug.Log("Listening"); } private async void Listener_ConnectionReceived(StreamSocketListener sender, StreamSocketListenerConnectionReceivedEventArgs args) { Debug.Log("Connection received"); try { while (true) { using (var dw = new DataWriter(args.Socket.OutputStream)) { dw.WriteString("Hello There"); await dw.StoreAsync(); dw.DetachStream(); } using (var dr = new DataReader(args.Socket.InputStream)) { dr.InputStreamOptions = InputStreamOptions.Partial; await dr.LoadAsync(12); var input = dr.ReadString(12); Debug.Log("received: " + input); _input = input; } } } catch (Exception e) { Debug.Log("disconnected!!!!!!!! " + e); } } #endif
43
void Update() { UpdateActiveGraph(_input); } private void UpdateActiveGraph(string data) { position = transform.position; rotation = transform.rotation; Prefabs[activePrefabIndex].SetActive(false); activePrefabIndex = int.Parse(data); if (activePrefabIndex > Prefabs.Length) { activePrefabIndex = Prefabs.Length; } transform.position = position; transform.rotation = rotation; Prefabs[activePrefabIndex].SetActive(true); } }
Com o CubeBoundingBox configurado, com todos os scripts necessários para
realizar comunicação TCP e manipulação de hologramas. Foi adicionado uma série
de gráficos 3D diferentes dentro da configuração do script UniversalSampleTutorial.
3.4 PLANO DE TESTES
Durante o desenvolvimento do projeto, serão realizados diversos testes para
validar o funcionamento de cada parte do sistema individualmente, totalizando o
escopo do projeto e garantindo confiança e segurança ne entrega do produto. Essa
rotina de testes facilita para o encontro de possíveis erros e correções, tornando o
produto muito mais confiável. Os testes que tiverem sucesso serão identificados por
“V” na coluna status. Os testes que não tiverem sucesso serão indicados pela letra “F”
na mesma coluna.
3.4.1 AMBIENTE DE DESENVOLVIMENTO, DADOS E HOLOGRAMA
A seção a seguir trata dos testes referentes ao ambiente de desenvolvimento e
os dados de base que serão utilizados no projeto, assim como os testes relacionados
ao holograma que será desenvolvido.
44
3.4.1.1 T01 - Teste do Ambiente de Desenvolvimento
Objetivo: Verificar se o ambiente de desenvolvimento foi instalado e
configurado corretamente.
Pré-condição: Instalar e configurar o Visual Studio 2017, Unity 2018.3.14f1 e o
HoloLens Emulator em um computador com Windows 10.
Maiores detalhes na Tabela 1.
DESCRIÇÃO DOS PROCEDIMENTOS STATUS
PASSO AÇÃO RESULTADO ESPERADO
1 O usuário inicia o Visual Studio 2017 A janela do Visual Studio 2017 aparece no monitor.
V
2 O usuário inicia o Unity A janela do Unity aparece no monitor. V
3
O usuário cria um projeto na opção
New dentro do Unity, com o nome do projeto e o local de armazenamento
Uma pasta do projeto é criada com o
nome e local especificado na criação
V
4 O usuário exporta um projeto do Unity
para o Visual Studio 2017
O projeto é carregado com sucesso no
Visual Studio 2017.
V
5
O usuário seleciona a opção Debug
com arquitetura x86, seleciona a
ferramenta HoloLens Emulator e inicia
a depuração
A janela do HoloLens Emulator abre e
inicia a execução do projeto.
V
6
O usuário exporta um kit de
ferramentas de realidade misturada para
o Unity
Uma coleção de opções de customização das formas é disponibilizada no Unity.
V
Tabela 1 – Teste 1
45
3.4.1.2 T02 - Teste de Configuração do Unity para HoloLens
Objetivo: Configurar o Unity para que funcione no HoloLens com qualquer tipo
de forma criada.
Pré-condição: Instalar o Visual Studio 2017, Unity 2018.3.14f1 e o HoloLens
Emulator em um computador com Windows 10.
Maiores detalhes na Tabela 2.
DESCRIÇÃO DOS PROCEDIMENTOS STATUS
PASSO AÇÃO RESULTADO ESPERADO
1 O usuário criar um projeto no Unity A janela do Unity é aberta com as configurações padrões de projeto
V
2 O usuário altera a posição da Main
Câmera para (0, 0, 0) A Câmera é centralizada na tela
V
2 O usuário muda o valor da opção Clear Flags para Solid Colors e altera o valor
RGB de Background para (0, 0, 0)
A cor do fundo do projeto é alterada
para preto sólido
V
3 O usuário altera o valor da opção Clipping Planes para 0.85
A escala de visão da Main Câmera é deslocada para 0.85
V
4
O usuário altera a qualidade gráfica da
plataforma universal do Windows para
Fastest ou Very Low
O processamento e simulação do projeto é aumentado
V
5
O usuário altera as configurações de
compilação alterando a plataforma
padrão para Universal Windows
Platform, adiciona o Scene do projeto, altera o Targer Device para HoloLens
com uma arquitetura x86, altera o tipo
de construção para D3D e seleciona as versões do SDK, mínimo da plataforma
e Visual Studio.
O Build do projeto para o HoloLens já
pode ser gerado
V
6
O usuário altera o Script Backending
para .NET em PlayerSettings/Other Settings
A opção de desenvolvimento em Unity
C# é liberada ao projeto
V
7
O usuário marca InternetClient,
Microphone e SpatialPerception em PublishingSettings/Capabilities
Os recursos de microfone, internet e
percepção de espaço do HoloLens são liberados para uso
V
8 O usuário marca a opção Virtual Reality
Supported em XR Settings
O projeto agora suporta realidade
virtual
V
9 O usuário constrói o projeto clicando em Build Project
O projeto é criado dentro da pasta especificada
V
Tabela 2 – Teste 2
46
3.4.1.3 T03 - Teste criação de um Holograma simples no HoloLens Emulator
Objetivo: Fazer a implementação de um holograma simples no Unity e testar
com o uso do HoloLens Emulator.
Pré-condição: Instalar o Visual Studio 2017, Unity 2018.3.14f1 aberto e
configurado para HoloLens e o HoloLens Emulator em um computador com Windows
10.
Maiores detalhes na Tabela 3.
DESCRIÇÃO DOS PROCEDIMENTOS STATUS
PASSO AÇÃO RESULTADO ESPERADO
1 O usuário inclui duas esferas ao Scene
e renomeia uma como World
Duas esferas devem aparecer na tela do
projeto
V
2 O usuário altera a posição da esfera
World para (0, 0, 2) e a outra para
(0.3, 0, 2)
A posição das esferas é alterada, ficando em frente a “Main Câmera”, lado a lado
V
3 O usuário altera a escala de ambas as esferas para (0.1, 0.1, 0.1)
O tamanho das esferas é reduzido V
4 O usuário cria um cubo no Scene e
renomeia o cubo para “Cursor”
Um cubo deve aparecer na tela do
projeto
V
5 O usuário altera a posição do cubo para (0, 0, 0)
O cubo estará na mesma posição da câmera principal
V
6 O usuário altera a dimensão do cubo
para (0.01, 0.01, 0.01)
O cubo ficará com uma dimensão bem
pequena
V
7 O usuário salva e executa a construção
do projeto em uma nova pasta
O projeto é gerado nessa nova pasta
com todos os arquivos dentro
V
8
O usuário abre o projeto clicando no
executável do Visual Studio gerado pela construção do projeto
O Visual Studio é aberto com o projeto
carregado
V
9
O usuário altera a opção de compilador
para Debug, a arquitetura de ARM para
x86 e a ferramenta de compilação de Computador Local para HoloLens
Emulator e então inicia a depuração
O projeto é depurado e aberto no HoloLens Emulator. As formas geradas
no projeto aparecem na visão do
emulador
V
Tabela 3 – Teste 3
47
3.4.1.4 T04 - Adição de funções ao projeto básico
Objetivo: Fazer com que o projeto básico possua movimentação de um
holograma e responda a um comando de voz.
Pré-condição: Instalar e configurar o Visual Studio 2017, Unity 2018.3.14f1 e o
HoloLens Emulator em um computador com Windows 10. Projeto Unity já criado e
configurado para HoloLens.
Maiores detalhes na Tabela 4.
DESCRIÇÃO DOS PROCEDIMENTOS STATUS
PASSO AÇÃO RESULTADO ESPERADO
1 O usuário adiciona o script Gaze
Cursor de movimentação do cursor ao cubo
O cubo deve obter a capacidade de atuar
como cursor do projeto quando em execução
V
2 O usuário adiciona o script World a esfera
A esfera deve obter a capacidade de se
movimentar horizontalmente na direção ou contra a outra esfera durante a
execução do projeto
V
3
O usuário adiciona os scripts Voice
Manager e Gesture Manager a Main Camera
Comandos de voz e gestos agora devem
estar disponíveis durante a execução do projeto por emulação ou pelo HoloLens
V
4 O usuário salva o Scene e constrói o
projeto em uma nova pasta
O projeto deve ser criado junto com a
nova pasta
V
5 O usuário abre o projeto gerado com o Visual Studio
A janela do Visual Studio aparece no monitor com o projeto carregado
V
6
O usuário altera a opção de compilador
para Debug, a arquitetura de ARM para
x86 e a ferramenta de compilação de Computador Local para HoloLens
Emulator e então inicia a depuração
A janela do HoloLens Emulator é aberta
e o projeto é carregado com as formas criadas
V
7 O usuário abre o projeto selecionando-o com a tecla “espaço”
O projeto é aberto e os objetos construídos aparecem na tela
V
8
O usuário posiciona o cubo em cima da
esfera, pressiona a tecla “espaço” e
move o mouse simultaneamente
O World é deslocado para esquerda ou
para direita, podendo colidir com as
duas esferas do projeto
V
9 O usuário testa o gesto Bloom
apertando a tecla “Windows”
O menu do HoloLens é aberto, ou
fechado caso já estivesse aberto
V
9 O usuário fala “Reset”
O comando de voz é reconhecido e
tanto a esfera quanto o cursor retornam para a posição inicial do projeto
V
Tabela 4 – Teste 4
48
3.4.1.5 T05 - Teste de Holograma com HoloLens Emulator no Microsoft HoloLens
Objetivo: Testar a conexão entre as plataformas de desenvolvimento e o
HoloLens Emulator , verificar as funções de reconhecimento no Microsoft HoloLens.
Pré-condição: Instalar e configurar o Visual Studio 2017, Unity 2018.3.14f1 e o
HoloLens Emulator em um computador com Windows 10. HoloLens Emulator
configurado corretamente.
Maiores detalhes na Tabela 5.
DESCRIÇÃO DOS PROCEDIMENTOS STATUS
PASSO AÇÃO RESULTADO ESPERADO
1 O usuário conecta o HoloLens por meio
de um cabo USB
O dispositivo realiza a conexão com o
computador
V
2 O usuário abre o Visual Studio e troca o
destino de implantação para
“Dispositivo”
As configurações do HoloLens devem ficar registradas como o dispositivo
V
3 O usuário mantem a configuração de “Máquina Local”
Dispositivos obstruídos são direcionados para o computador
V
4 O usuário inicia a depuração do projeto O projeto deve ser aberto no HoloLens e
entrar em execução
V
5 O usuário testa o gesto de Bloom O menu do HoloLens deve ser aberto ou fechado se já estiver aberto
V
6 O usuário testa o gesto de Click e
arrasto com um objeto
O objeto deve ser selecionado e movido
como indicado pelo usuário
V
7 O usuário testa comandos de voz O HoloLens executa os comandos de
voz ordenados
V
Tabela 5 – Teste 5
49
3.4.1.6 T06 - Teste de Comportamento do Holograma
Objetivo: Plotar um gráfico em 3D com o HoloLens Emulator e verificar se os
comportamentos básicos de um holograma estão presentes.
Pré-condição: Instalar e configurar o Visual Studio 2017, Unity 2018.3.14f1 e o
HoloLens Emulator em um computador com Windows 10.
Maiores detalhes na Tabela 6.
DESCRIÇÃO DOS PROCEDIMENTOS STATUS
PASSO AÇÃO RESULTADO ESPERADO
2 O usuário posiciona o foco sobre o
gráfico
O gráfico é mostra um contorno azul indicando que está sendo
focado
V
3 O usuário deve selecionar e
rotacionar o gráfico O sistema rotaciona o gráfico
V
4
O usuário deve selecionar o gráfico e
diminuir seu tamanho, em seguida
aumentar novamente
O sistema diminui o tamanho do
gráfico e em seguida aumenta o
tamanho novamente
V
Tabela 6 – Teste 6
50
3.4.1.7 T07 - Teste de Atualização do Hologramas
Objetivo: Verificar se o holograma é alterado quando as informações dos limites
sofrem alterações.
Pré-condição: Instalar e configurar o Visual Studio 2017, Unity 2018.3.14f1 e o
HoloLens Emulator em um computador com Windows 10. HoloLens Emulator aberto
e configurado.
Maiores detalhes na Tabela 7.
DESCRIÇÃO DOS PROCEDIMENTOS STATUS
PASSO AÇÃO RESULTADO ESPERADO
1 É inserido um conjunto de dados sobre
as regiões de segurança e o ponto de operação para serem plotados
Um gráfico 3D deve ser gerado com as
regiões de segurança e o ponto de operação
V
2 Os dados sobre as regiões de segurança
são alterados
As regiões de segurança são atualizadas
e o ponto de operação não sofre alteração
V
3 Os dados sobre o ponto de operação são alterados
O ponto de operação é reposicionado e
as regiões de segurança não sofrem
alteração
V
Tabela 7 – Teste 7
51
3.4.1.8 T08 - Teste de Envio e Leitura de Dados
Objetivo: Verificar se o arquivo CSV contendo os dados para geração do gráfico
3D é enviado para o HoloLens corretamente.
Pré-condição: Executar o programa do cliente em uma máquina conectada a
mesma rede Wi-Fi que o HoloLens e então executar a aplicação com o programa do
servidor no HoloLens.
Maiores detalhes na Tabela 8.
DESCRIÇÃO DOS PROCEDIMENTOS STATUS
PASSO AÇÃO RESULTADO ESPERADO
1 Executar a aplicação com o programa
do servidor no HoloLens A aplicação é executada com sucesso
V
2 Executar a o programa do cliente em
uma máquina conectada na mesma rede
Wi-Fi que o HoloLens
O programa é executado com sucesso e
uma tela requisitando inputs de
coordenadas aparece.
V
3 Fechar o programa do cliente enviando
um arquivo vazio para o HoloLens
O arquivo deve chegar no HoloLens e gerar uma falha de atualização do
gráfico 3D
V
4
Executar a o programa do cliente em uma máquina conectada na mesma rede
Wi-Fi que o HoloLens
O programa é executado com sucesso e uma tela requisitando inputs de
coordenadas aparece
V
5
Inserir manualmente coordenadas no
arquivo CSV a ser enviado de modo que o gráfico 3D seja atualizado com
sucesso
O arquivo CSV deve ser salvo com os dados inseridos manualmente
V
6
Fechar o programa do cliente enviando
um arquivo contendo dados para o HoloLens
O arquivo deve chegar no HoloLens e
gerar uma atualização no gráfico 3D
V
7
Fechar a aplicação com o programa do
servidor no HoloLens e permanecer com o HoloLens ligado
A aplicação é fechada com sucesso
V
8 Repetir passos 2 a 6 O arquivo não chega ao HoloLens com
a aplicação fechada
V
Tabela 8 – Teste 8
52
3.5 ANÁLISE DE RISCOS
A análise de riscos é a etapa do projeto necessária para que não haja surpresas
durante o desenvolvimento do projeto. Todo projeto está suscetível a falhas, erros e
danos, através desse planejamento o time sempre tem uma ação de mitigação para
evitar que os riscos ocorram, uma ação de monitoramento para análise da situação
atual, e uma ação de contingência como um “plano B” caso o risco venha a acontecer.
Mais detalhes estão apresentados na Tabela 9.
N
.
Situação Data
Limite
Consequência Mitigação Monitoramento Contingência Probabilidade Impacto Efeito Nível
1 Baixa
experiência em relação as ferramentas
utilizadas.
18/06 Aumento do
custo e atraso entrega final
Estudar a
documentação das tecnologias
disponíveis na internet
Reuniões
semanais
Solicitar
auxílio ao comitê de AR da Siemens
Baixa (0,30) Alto
(0,40)
0,12 Risco
médio
2 Ambiente de
desenvolvimento não instalado ou
configurado corretamente
14/11 Atraso nas
entregas
Utilizar a
documentação disponibilizada pela Microsoft
para configurar e instalar os
softwares necessários.
Verificar se os
softwares foram configurados de maneira correta
por meio de testes
Solicitar
auxílio ao comitê de AR da Siemens
Média (0,50) Médio
(0,20)
0,10 Risco
médio
3 Má gestão do
tempo
14/11 Atraso nas
entregas das atividades
Planejar bem
o tempo das atividades
Reuniões
semanais e mensais. Elaborar um
cronograma e utilizá-lo
Não se aplica Baixa (0,30) Médio
(0,20)
0,06 Risco
médio
4 Defeito no
HoloLens
11/11 HoloLens não
poderá mais ser utilizado
Cuidar do
equipamento e usar de maneira
especificada pelo fabricante
Verificar seu
estado com frequência
Utilizar as
ferramentas de emulação existentes do
HoloLens
Baixa (0,10) Médio
(0,20)
0,06 Risco
médio
5 Baixo
conhecimento para desenvolvime
nto dos gráficos 3D
30/09 Atraso e
impedimentos no desenvolvime
nto do código e validação dos dados do
Organon
Estudar o
motor de jogo Unity
Os trabalhos
devem estar sempre em dia com o
cronograma
Solicitar
auxílio ao comitê de AR da Siemens
Média (0,50) Alto
(0,40)
0,20 Risco
Alto
6 Dados do
Organon não validados
18/11 Atrasos no
desenvolvimento do projeto, incapacitação
de realizar demonstrações e testes
Estudar a
estrutura dos dados utilizados.
Verificar se não
ocorre erros durante a aquisição dos
dados em testes e na implementação
Solicitar
auxílio ao comitê de AR da Siemens
Baixa (0,10) Alta
(0,40)
0,04 Risco
baixo
7 Comunicação online com o Organon não
funciona
11/11 Mudança de estratégia utilizada no
processamento dos dados para
hologramas
Realizar a conexão de modo offline
Não se aplica Trabalhar com os dados dentro da
estrutura do código de modo estático
Média (0,50) Médio (0,20)
0,10 Risco médio
Tabela 9 – Tabela de riscos
53
4 DESENVOLVIMENTO
4.1 CRONOGRAMA
Para melhorar o controle das atividades e entregas envolvidas no projeto, o
escopo foi dividido em 3 grandes segmentações:
A) Planejamento e Pré-projeto:
Nessa primeira etapa se encontram a elaboração da Proposta de Projeto, a
elaboração do Plano de Projeto e sua defesa.
B) Prototipação do Projeto Físico:
Nessa etapa, um protótipo que representa parcialmente o Projeto Funcional é
desenvolvido e apresentado no final da etapa. Essa é a primeira de duas partes do
desenvolvimento do Projeto Físico. É a fase em que se encontram a elaboração da
documentação do Projeto Físico, sua defesa, revisão do Projeto Físico, e defesa do
protótipo funcional.
C) Projeto Funcional:
Essa etapa é a segunda parte do desenvolvimento do Projeto Físico, onde a
implementação deverá estar pronta e sem defeitos no término da etapa. É a fase em
que deverá ser elaborado o Relatório Final do projeto.
O cronograma abaixo (Figura 19Figura 19) foi elaborado para o monitoramento
e controle das etapas do projeto definidas previamente:
54
Figura 19 - Cronograma do Projeto
55
5 SUSTENTABILIDADE E IMPACTO AMBIENTAL
Como todo equipamento eletrônico, o HoloLens também possui componentes
como plástico, vidro e metal que são poluentes, que se não descartados corretamente
podem prejudicar o meio ambiente. Para isso é necessário enfatizar sobre a maneira
correta de descartar cada parte do equipamento, assim como alertar sobre os tipos
de componentes prejudiciais que podem ser encontrados nesses tipos de eletrônicos.
Segundo o website MUNDOEDUCAÇÃO [6], as baterias do dispositivo
possuem em seu interior Mercúrio e outros químicos que podem prejudicar o meio
ambiente ficando retidos por milhares de anos. Esses metais altamente tóxicos
também afetam a saúde humana atacando o sistema nervoso central e podem atingir
o fígado, os rins e os pulmões. Para o descarte correto dessas baterias existem
espalhados por todo Brasil diversas unidades responsáveis pela recepção desse lixo,
onde estão dispostos a dar o destino correto ao lixo.
Segundo o website ELETRONICAGARAGEM [7], nas placas internas do
dispositivo também existem diversos tipos de metais e componentes químicos tóxicos.
Com destaque ao Estanho, da família dos metais pesados, e que é utilizado para a
solda dos componentes eletrônicos na placa de circuito impresso (PCI), se não
descartado corretamente, assim como o chumbo que faz parte mesma família, podem
causar anemia, danos no fígado e rins, entre outros problemas ao meio ambiente.
Segundo o website ECYCLE [9], enfatiza-se o devido descarte desses materiais nas
empresas fabricantes e importadoras que atuam no Brasil. Após o descarte os
equipamentos são encaminhados para empresas que se responsabilizam em
desmontar os equipamentos e separar cada resíduo para devida reciclagem.
Praticamente 100% do aparelho pode ser reciclado.
Já existem leis no Brasil para controlar o descarte desse tipo de lixo como a Lei
nº 12.305/10 da Política Nacional de Resíduos Sólidos (PNRS) intitulada em 2010.
Segundo o website ECYCLE [8], a lei exige dos setores públicos e privados a
transparência no gerenciamento dos seus recursos.
56
6 CONCLUSÃO
Todas as tecnologias de software e hardware escolhidas para esse projeto
foram pensadas visando obter o melhor produto mínimo viável possível, com um
processamento de informação veloz e atraente. Muitas pesquisas e testes foram
desenvolvidos pelo ONS para provar que o sistema Organon tem uma grande
eficiência em monitoramentos de segurança do sistema de energia Brasileiro,
suprindo a necessidade de obter dados em tempo real e mostrando ser uma ótima
ferramenta para prevenção e correção das ações de controle.
Analisando os riscos mapeados ao longo do projeto, fica evidente que o projeto
possui uma complexidade elevada. Para garantir que o projeto continue sendo viável,
a estratégia de desenvolvimento é manter a representação do resultado da análise do
Organon o mais simples possível, ou seja, a solução não contempla a parte
matemática por trás de como a região segura do ponto de operação da rede elétrica
é feita. Para simplificar ainda mais o desenvolvimento da ferramenta, foram utilizados
dados representativos ao invés dos dados reais obtidos do processo de análise do
Organon.
Durante o desenvolvimento foram encontrados diversos obstáculos. Algumas
das funcionalidades e o fluxo de dados que foram planejados antes do
desenvolvimento tiveram que ser repensados para que o projeto atingisse os objetivos
dentro do prazo de tempo.
O primeiro grande desafio enfrentado foi a construção do gráfico 3D com base
em dados contidos em arquivos. Para realizar a construção de um gráfico 3D dessa
maneira é necessário que várias etapas sejam realizadas. Devido ao tempo que seria
gasto para executar todas as etapas com sucesso, foi adotada uma abordagem mais
simples para a construção do gráfico: foram elaborados manualmente vários
exemplos de gráficos 3D que eram alternados na tela do usuário como forma de
simular uma atualização do gráfico. Os exemplos eram alternados conforme uma
requisição chegasse para o HoloLens através da rede Wi-Fi.
O segundo grande desafio enfrentado foi codificar uma aplicação do tipo
cliente-servidor entre um computador e o HoloLens para enviar a requisição de troca
dos exemplos. Fazer com que o computador transmitisse os dados necessários pela
rede Wi-Fi até o HoloLens não foi simples. Após algumas tentativas, notou-se que o
HoloLens não estabelecia conexão com o computador devido a um problema de
57
incompatibilidade entre as bibliotecas do Unity e do UWP. Para solucionar esse
problema foi necessário agrupar o código específico de cada plataforma, fazendo que
o compilador ignorasse as configurações especificas do Unity quando estivesse no
UWP e vice-versa.
Através da realidade aumentada, é possível fazer com que a análise de dados
sofra uma grande mudança tecnológica, ajudando os operadores do sistema a
interpretar e tomar de decisões muito mais rápido do que antes. Sendo assim, é
possível afirmar que a ferramenta proposta cumpre os objetivos de a trazer as
informações segmentadas do resultado da análise no Organon em um único gráfico
tridimensional interativo, diminuindo a carga cognitiva do operador, providenciando
uma ótima UX e, principalmente, acelerando e aprimorando a tomada de decisão dos
operadores em tempo real.
A realidade aumentada é uma tecnologia que deve ser bastante explorada pois
possibilita um novo mundo de opções no que se trata de aplicações industriais. Muitas
pesquisas e novos equipamento estão sendo desenvolvidos, melhorando cada vez
mais a ergonomia e UX dos usuários, assim como a sensação de realismo dos objetos
digitais.
58
7 TRABALHOS FUTUROS
Como trabalhos a serem desenvolvidos a partir deste, podem-se sugerir os
seguintes:
7.1 COMANDOS POR VOZ
Implementação de comandos de voz para que o usuário consiga utilizar a
ferramenta sem a necessidade de gestos, melhorando a UX e a velocidade com que
o usuário utiliza a ferramenta proposta.
7.2 CONEXÃO DIRETA COM O ORGANON
Conectar a ferramenta proposta diretamente com o sistema do Organon,
reutilizando os dados gerados pela análise do sistema para a geração do gráfico 3D
e melhorando a velocidade com que o gráfico é atualizado.
7.3 SUPORTE PARA DADOS HISTÓRICOS
Aprimoramento da ferramenta para dar suporte aos dados antigos do Organon
que estão armazenados em um banco de dados. Assim, o operador do sistema poderá
consultar quando houve a mudança do ponto de operação da rede para uma região
mais crítica a qualquer momento.
59
REFERÊNCIAS
[1] Kirner, C., Realidade Virtual e Aumentada, Acessado em abril, 2019. Disponível em:
<http://www.realidadevirtual.com.br>.
[2] AZUMA, R., (1993) - Tracking Requirements for Augmented Reality. Communications of the
ACM, 36, 7 (July 1993), p. 50-51. Acessado em abril, 2019. Disponível em:
<http://www.cs.unc.edu/~azuma/cacm.html>.
[3] AZUMA, R., (1997) - A Survey of Augmented Reality. Presence: Teleoperators and Virtual
Environments, v .6, n.4, August, p. 355-385. Acessado em abril, 2019. Disponível em:
<http://www.cs.unc.edu/~azuma/ARpresence.pdf>
[4] Microsoft, HoloLens, Acessado em abril, 2019. Disponível em:
<https://docs.microsoft.com/pt-br/hololens/hololens-setup>.
[5] ONS, O Sistema Interligado Nacional, Acessado em setembro, 2019. Disponível em:
<http://www.ons.org.br/paginas/sobre-o-sin/o-que-e-o-sin>
[6] MUNDOEDUCACAO, Pilhas e Baterias Usadas: Perigoso Lixo Toxico. Acessado em novembro,
2019. Disponível em: <https://mundoeducacao.bol.uol.com.br/quimica/pilhas-baterias-
usadas-perigoso-lixo-toxico.htm>
[7] ELETRONICAGARAGEM, Solda Estanho Riscos a Saúde, Acessado em novembro, 2019.
Disponível em: <https://eletronicagaragem.blogspot.com/2015/11/solda-estanho-riscos-
saude.html>
[8] ECYCLE, O que é Política Nacional de Resíduos Sólidos, Acessado em novembro, 2019.
Disponível em: <https://www.ecycle.com.br/3705-politica-nacional-de-residuos-solidos-
pnrs.html>
[9] ECYCLE, Reciclagem de Lixo Eletrônico, Acessado em novembro, 2019. Disponível em:
<https://www.ecycle.com.br/7076-onde-descartar-lixo-eletronico.html>
60
APENDICE A –CÓDIGO GERADOR DE ARQUIVO CSV
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
using System.Threading;
using Linq.Csv;
using System.IO;
namespace CriaArquivo
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
public void button1_Click(object sender, EventArgs e)
{
String PT = textBox3.Text;
String VD = textBox2.Text;
String AM = textBox1.Text;
arquivo(PT, VD, AM);
}
private void button2_Click(object sender, EventArgs e)
{
String PT = ("0.1 0.2 0.3");
String VD = ("0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.10 0.11 0.12 0.13 0.14 0.15 0.16 0.17 0.18 0.19
0.20 0.21 0.22 0.23 0.24");
String AM = ("0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.10 0.11 0.12 0.13 0.14 0.15 0.16 0.17 0.18 0.19
0.20 0.21 0.22 0.23 0.24");
arquivo(PT, VD, AM);
}
private void button3_Click(object sender, EventArgs e)
{
String PT = ("0.1 0.2 0.3");
String VD = ("0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.10 0.11 0.12 0.13 0.14 0.15 0.16 0.17 0.18 0.19
0.20 0.21 0.22 0.23 0.24 0.25 0.26 0.27");
String AM = ("0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.10 0.11 0.12 0.13 0.14 0.15 0.16 0.17 0.18 0.19
0.20 0.21 0.22 0.23 0.24");
arquivo(PT, VD, AM);
}
private void button4_Click(object sender, EventArgs e)
{
String PT = ("0.1 0.2 0.3");
String VD = ("0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.10 0.11 0.12 0.13 0.14 0.15 0.16 0.17 0.18 0.19
0.20 0.21 0.22 0.23 0.24");
String AM = ("0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.10 0.11 0.12 0.13 0.14 0.15 0.16 0.17 0.18 0.19
0.20 0.21 0.22 0.23 0.24 0.25 0.26 0.27");
arquivo(PT, VD, AM);
}
private void button5_Click(object sender, EventArgs e)
{
String PT = ("0.1 0.2 0.3");
String VD = ("0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.10 0.11 0.12 0.13 0.14 0.15 0.16 0.17 0.18 0.19
0.20 0.21 0.22 0.23 0.24 0.25 0.26 0.27");
String AM = ("0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.10 0.11 0.12 0.13 0.14 0.15 0.16 0.17 0.18 0.19
0.20 0.21 0.22 0.23 0.24 0.25 0.26 0.27");
61
arquivo(PT, VD, AM);
}
private void arquivo(String PT, String VD, String AM)
{
try
{
String hora = DateTime.Now.ToString("dd-MM-yyyy-HH-mm-ss");
String filePath = @"D:\Users\marco\Documents\SalvaArquivo\" + hora + ".csv";
var PT_aux = PT.Split(' ');
var VD_aux = VD.Split(' ');
var AM_aux = AM.Split(' ');
var tam_VD = VD_aux.Length;
var tam_AM = AM_aux.Length;
if (tam_AM < 24 || tam_VD < 24)
{
Console.WriteLine("\nDeve ser incerido pelo menos 24 cordenadas por regiao...");
Thread.Sleep(3000);
}
string header = ("Ponto; Verde; Amarela\n");
File.WriteAllText(filePath, header);
var maxValue = Math.Max(tam_AM, tam_VD);
for (int i = 0; i < maxValue; i = i + 3)
{
if (i < 3)
{
File.AppendAllText(filePath, PT_aux[i] + "," + PT_aux[i + 1] + "," + PT_aux[i + 2] +
";");
}
else
File.AppendAllText(filePath, ";");
if (i < tam_VD)
{
File.AppendAllText(filePath, VD_aux[i] + "," + VD_aux[i + 1] + "," + VD_aux[i + 2] +
";");
}
else
File.AppendAllText(filePath, ";");
if (i < tam_AM)
{
File.AppendAllText(filePath, AM_aux[i] + "," + AM_aux[i + 1] + "," + AM_aux[i + 2] +
"\n");
}
else
File.AppendAllText(filePath, "\n");
}
}
catch
{
Console.WriteLine($"Erro ao salvar os arquivos");
}
}
}
}
62
APENDICE B – CÓDIGO FILE WATCHER
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Net;
using System.Net.Sockets;
using System.Threading;
using System.IO;
using static System.Console;
using static System.ConsoleColor;
namespace FileSystemWatcherSample
{
class Program
{
public static string serverIp = "localhost";
public static int port = 8080;
static void Main(string[] args)
{
// Instanciamento do objeto
var fileSystemWatcher = new FileSystemWatcher();
// Associação do operador de eventos com os eventos
fileSystemWatcher.Created += FileSystemWatcher_Created;
// diretorio do arquivo para vigilancia do Watcher
fileSystemWatcher.Path = @"D:\Users\marco\Documents\SalvaArquivo";
// You must add this line - this allows events to fire.
fileSystemWatcher.EnableRaisingEvents = true;
WriteLine("Listening...");
WriteLine("(Press any key to exit.)");
ReadLine();
}
// Funcao ativa com a criação de um arquivo novo na pasta
private static void FileSystemWatcher_Created(object sender, FileSystemEventArgs e)
{
ForegroundColor = Blue;
WriteLine($"A new file has been created - {e.Name}");
EnviaArquivo(sender, e);
}
// Funcao chamada para enviar dados ao servidor via socket
private static void EnviaArquivo(object sender, FileSystemEventArgs e)
{
try
{
TcpClient client = new TcpClient(serverIp, port);
Thread.Sleep(1000);
StreamReader rd = new StreamReader(@"D:\Users\marco\Documents\SalvaArquivo\" + e.Name);
string arquivo = rd.ReadToEnd();
int byteCount = Encoding.ASCII.GetByteCount(arquivo);
byte[] sendData = new byte[byteCount];
sendData = Encoding.ASCII.GetBytes(arquivo);
NetworkStream stream = client.GetStream();
stream.Write(sendData, 0, sendData.Length);
63
rd.Close();
stream.Close();
client.Close();
ForegroundColor = Green;
WriteLine($"Dados enviado ao servidor - {e.Name}");
}
catch
{
ForegroundColor = Red;
WriteLine($"Erro ao enviar os dados ao servidor - {e.Name}");
}
}
}
}
64
APENDICE C – CÓDIGO SERVIDOR
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
//Para controle de sockets
using System.Net;
using System.Net.Sockets;
//Controle de arquivos em pasta
using System.IO;
using static System.Console;
using static System.ConsoleColor;
namespace Servidor
{
class Servidor
{
static void Main(string[] args)
{
String filePath = @"D:\Users\marco\Documents\SalvaArquivo\Arquivos do servidor\ArquivoServidor.csv";
// Inicia o Objeto
var fileSystemWatcher = new FileSystemWatcher();
IPAddress ip = Dns.GetHostEntry("localhost").AddressList[0];
TcpListener server = new TcpListener(ip, 8080);
TcpClient client = default(TcpClient);
try
{
server.Start();
Console.WriteLine("Server Started...");
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
Console.Read();
}
while (true)
{
client = server.AcceptTcpClient();
Console.Clear();
byte[] receivebuffer = new byte[1000];
NetworkStream strem = client.GetStream();
strem.Read(receivebuffer, 0, receivebuffer.Length);
StringBuilder msg = new StringBuilder();
foreach (byte b in receivebuffer)
{
if (b.Equals(00))
{
break;
}
else
{
msg.Append(Convert.ToChar(b).ToString());
}
}
File.WriteAllText(filePath, msg.ToString());
Console.WriteLine(msg.ToString());
//Console.Read();
}
}
}
}