Jean Caetano Perufo Damke; Anderson Canale Garcia

DOI: 10.22167/2675-6528-202600944

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

A Engenharia Assistida por Computador (CAE) é uma área estratégica para o desenvolvimento industrial, mas a migração das simulações para a nuvem introduziu desafios significativos na visualização dos resultados. O trabalho teve como objetivo desenvolver e analisar arquiteturas de software capazes de suportar a visualização tridimensional de resultados de simulações CAE na nuvem, com foco em desempenho e escalabilidade. A metodologia empregada caracterizou-se como pesquisa aplicada de abordagem mista, que envolveu revisão bibliográfica, desenvolvimento de protótipos, medição de performance e análise comparativa. Foram implementadas duas arquiteturas distintas, uma baseada em WebSockets e outra em APIs REST, avaliadas a partir de modelos CAD com diferentes níveis de refinamento de malha. Os parâmetros medidos incluíram tempo de carregamento inicial, tempo de alteração de variáveis e uso de memória. Os resultados indicaram que ambas as arquiteturas apresentaram vantagens e limitações; a arquitetura baseada em APIs REST mostrou tempos de carregamento inicial promissores, mas não conseguiu processar modelos de alta complexidade e exibiu maior consumo de memória e lentidão na alteração de variáveis em comparação com a arquitetura WebSockets, que demonstrou otimizações robustas para mudanças pós-renderização. Concluiu-se que a escolha da arquitetura é um fator crítico para o desempenho de sistemas de visualização de simulações CAE na nuvem, e as observações realizadas permitiram uma melhor compreensão dos desafios e limitações inerentes a esses sistemas, destacando a necessidade de otimizações para a viabilidade da abordagem REST em ambientes de produção.

Palavras-chave: APIs REST; Desempenho de Software; Modelos CAD; Renderização; WebSockets.

1. Introdução

A Engenharia Assistida por Computador (CAE) representa um pilar estratégico no desenvolvimento e otimização de produtos industriais modernos, integrando ferramentas computacionais para análise, simulação e otimização de sistemas de engenharia (Walker et al., 1984). Este campo multidisciplinar abrange diversas subáreas, como o Design Assistido por Computador (CAD), a Dinâmica de Fluidos Computacional (CFD) e a Manufatura Assistida por Computador (CAM) (Haworth et al., 1998). As simulações CAE, em particular, permitem que engenheiros e pesquisadores investiguem o comportamento físico de modelos complexos por meio de cálculos computacionais, o que resulta em uma significativa redução de custos e tempo associados a testes experimentais físicos (Kolbasin e Husu, 2018). O processo de simulação CAE é tipicamente dividido em três etapas: pré-processamento, no qual o modelo e as condições de contorno são definidos; processamento, que envolve a discretização do modelo em malhas e a aplicação de algoritmos para resolver equações diferenciais parciais, frequentemente utilizando métodos como o Elementos Finitos (Petrillo, 1990) ou Lattice-Boltzmann (Sheikholeslami e Abohamzeh, 2022); e pós-processamento, focado na visualização e interpretação dos resultados (Johansson, 2014). A visualização tridimensional dos resultados é crucial nesta última etapa, pois permite a compreensão intuitiva de fenômenos complexos e a tomada de decisões de projeto informadas.

Tradicionalmente, a execução de simulações CAE e o subsequente pós-processamento exigiam infraestruturas de hardware robustas e localizadas, muitas vezes associadas a altos custos de aquisição e manutenção. Contudo, o avanço da computação em nuvem e dos conceitos de Computação de Alta Performance (HPC) transformou este cenário, oferecendo uma alternativa viável e escalável para empresas que necessitam de recursos computacionais sob demanda (Lange et al., 2021). A migração para a nuvem permite que organizações acessem clusters de alto desempenho por meio de aplicações web, eliminando a necessidade de investimentos em equipamentos caros que poderiam permanecer ociosos por longos períodos (Hochstein et al., 2011). Embora a nuvem democratize o acesso a capacidades de simulação avançadas, ela introduz novos desafios, especialmente no que tange à visualização tridimensional de resultados. Modelos complexos, com malhas de alta resolução e grandes volumes de dados, podem resultar em renderização 3D lenta e na necessidade de transmissão volumosa de dados entre o servidor e o cliente, impactando diretamente a experiência do usuário e a eficiência operacional. A complexidade inerente a esses dados e a demanda por interatividade em tempo real impõem requisitos rigorosos às arquiteturas de software subjacentes.

Diante dos desafios impostos pela visualização de simulações CAE na nuvem, a escolha da arquitetura de software torna-se um fator determinante para o desempenho e a escalabilidade do sistema. Diferentes abordagens de comunicação e processamento de dados são empregadas em aplicações web para lidar com a complexidade da renderização 3D. Entre as mais proeminentes, destacam-se as arquiteturas baseadas em WebSockets e em APIs REST (Representational State Transfer). WebSockets estabelecem uma conexão persistente e bidirecional entre cliente e servidor, permitindo a troca de dados em tempo real de forma eficiente, o que é particularmente vantajoso para cenários que exigem atualizações contínuas e baixa latência, como a manipulação interativa de modelos 3D. Por outro lado, APIs REST operam sobre o paradigma de requisição-resposta, sendo amplamente utilizadas pela sua simplicidade, escalabilidade e natureza *stateless*, embora possam introduzir maior latência em interações que demandam múltiplas trocas de dados. A eficácia de cada uma dessas arquiteturas para a visualização de resultados de simulações CAE na nuvem depende de fatores como o volume e a natureza dos dados, a frequência das atualizações e os requisitos de interatividade. A compreensão das vantagens e limitações de cada paradigma é crucial para otimizar a experiência do usuário e garantir a viabilidade técnica em ambientes de produção.

A complexidade e o volume de dados gerados pelas simulações CAE, aliadas à demanda por visualização tridimensional eficiente em ambientes de nuvem, evidenciam a necessidade de uma análise aprofundada das arquiteturas de software que podem suportar tais requisitos. A decisão arquitetural, conforme Richards e Ford (2020) apontam, é sempre uma troca, e a escolha ideal depende de um balanço cuidadoso entre desempenho, escalabilidade e facilidade de implementação. Este trabalho, portanto, justifica-se pela relevância de investigar e comparar o desempenho e as características de escalabilidade de arquiteturas baseadas em WebSockets e APIs REST para a visualização tridimensional de resultados de simulações CAE na nuvem, com o objetivo de apoiar a seleção da abordagem mais adequada em cenários industriais reais.

2. Material e Métodos

Este trabalho enquadrou-se na classificação metodológica de pesquisa aplicada, utilizando uma abordagem de métodos mistos, conforme descrito por Creswell e Creswell (2018). A pesquisa combinou elementos de um estudo de caso com uma abordagem experimental quantitativa, complementada por uma análise comparativa. Para tal, foram desenvolvidos protótipos pelo próprio autor, permitindo a avaliação prática das arquiteturas de software propostas para a visualização de resultados de simulações CAE.

O estudo foi conduzido na cidade de Munique, na Alemanha, em uma empresa de médio porte, que emprega aproximadamente cento e vinte funcionários e é especializada em simulações CAE na nuvem. A pesquisa foi realizada durante o período de desenvolvimento do trabalho, focando na criação e avaliação de soluções para desafios específicos da visualização tridimensional em ambientes de computação em nuvem. A unidade de análise principal consistiu nos dois protótipos de aplicações desenvolvidos, bem como nos dados de simulação CAE utilizados para testá-los.

As etapas de desenvolvimento do trabalho foram estruturadas para garantir uma investigação abrangente. Inicialmente, realizou-se uma revisão da literatura pertinente sobre visualizações 3D em simulações CAE. Em seguida, procedeu-se ao planejamento detalhado das diferentes arquiteturas a serem implementadas. Posteriormente, os protótipos foram desenvolvidos, seguidos pela realização de medições de performance rigorosas e, por fim, uma análise comparativa aprofundada dos resultados obtidos.

Para a avaliação, foram selecionados dois modelos CAD com distintos níveis de complexidade, servindo como base para as simulações. O primeiro modelo representou uma válvula hidráulica, enquanto o segundo modelo consistiu em uma turbina hidráulica. A complexidade de cada modelo foi caracterizada pelo número de nós, faces e arestas, fornecendo uma métrica objetiva para a comparação dos resultados de desempenho entre as arquiteturas.

O Modelo 1, a válvula hidráulica, apresentou uma estrutura com oitenta e três nós, quarenta e três faces e cento e vinte e seis arestas. O Modelo 2, a turbina hidráulica, demonstrou uma complexidade significativamente maior, com trezentos e vinte e oito nós, duzentos e vinte e quatro faces e quinhentos e quarenta e seis arestas. Essa variação permitiu testar as arquiteturas sob diferentes cargas de processamento e visualização.

A geração de malhas constituiu uma etapa crucial para a realização das simulações CAE. Para este processo, foram empregados programas desenvolvidos previamente pela empresa, fundamentados no Método de Volumes Finitos (Versteeg e Malalasekera, 2007). Os níveis de refinamento das malhas foram definidos para determinar o tamanho das células utilizadas nos cálculos, influenciando diretamente a precisão e a complexidade dos resultados da simulação.

Para o Modelo 1, foram geradas três malhas com diferentes níveis de refinamento. A Malha 1 (nível 1) continha cento e vinte e sete mil e oitocentos nós e quatrocentas e trinta mil células. A Malha 2 (nível 5) possuía cento e sessenta e seis mil e duzentos nós e quinhentas e vinte e um mil e oitocentas células. A Malha 3 (nível 10) era a mais complexa, com dezessete milhões e seiscentas mil nós e vinte e seis milhões e trezentas mil células.

Similarmente, para o Modelo 2, foram geradas três malhas com níveis de refinamento distintos. A Malha 1 (nível 1) apresentava quatrocentas e quarenta mil e trezentos nós e um milhão e quinhentas mil células. A Malha 2 (nível 5) contava com oitocentas e noventa e nove mil nós e três milhões de células. A Malha 3 (nível 10) era a mais densa, com vinte e três milhões e duzentos mil nós e trinta e cinco milhões de células.

Após a geração das malhas, as simulações CAE foram realizadas utilizando algoritmos proprietários da empresa, baseados no software OpenFoam. Os resultados foram obtidos simulando o comportamento da água tanto na válvula hidráulica quanto na turbina hidráulica. Para assegurar a relevância dos resultados, foram estipulados parâmetros de simulação específicos, como a velocidade ou pressão em uma das faces de entrada e o material do fluido.

Os resultados das simulações foram gerados em arquivos no formato `.foam`, acompanhados de arquivos auxiliares que representavam os dados de cada parâmetro e instante simulado. Para o Modelo 1, os tamanhos dos arquivos de simulação foram: 39,2 MB para a Malha 1, 47,1 MB para a Malha 2 e 2,52 GB para a Malha 3. Esses arquivos foram posteriormente utilizados nos protótipos desenvolvidos.

Para o Modelo 2, os arquivos de simulação gerados apresentaram os seguintes tamanhos: 226,4 MB para a Malha 1, 463,2 MB para a Malha 2 e 5,7 GB para a Malha 3. A variação nos tamanhos dos arquivos, diretamente relacionada à complexidade das malhas, permitiu avaliar o desempenho das arquiteturas sob diferentes volumes de dados.

Para a visualização dos resultados de simulações CAE, foram desenvolvidos dois protótipos de aplicações na nuvem, cada um implementando uma arquitetura de software distinta. O objetivo foi comparar o desempenho e a escalabilidade dessas arquiteturas, uma baseada em WebSockets e outra em APIs REST, para identificar a abordagem mais adequada em cenários industriais.

A primeira arquitetura consistiu em uma aplicação web desenvolvida em React e JavaScript, utilizando WebSockets para a transferência de dados do modelo tridimensional entre o frontend e o backend. Nesta arquitetura, a biblioteca HOOPS Envision Web foi empregada tanto no backend quanto no frontend. Os arquivos `.foam` foram carregados pelo backend e transmitidos ao frontend via WebSockets, com um objeto JSON no frontend controlando a visualização e gerando mensagens para o backend, que processava os dados e retornava a visualização para renderização progressiva em um canvas HTML.

A segunda arquitetura, por sua vez, utilizou uma biblioteca construída com base na biblioteca de código aberto ThreeJS para a renderização tridimensional no navegador. A comunicação com o servidor foi realizada por meio de chamadas de API REST para um backend que executava a biblioteca HOOPS Envision Desktop. Este backend era responsável por converter os arquivos `.foam` em arquivos `.obj`, que eram então retornados ao frontend. Uma limitação observada foi a necessidade de arquivos CAD para a renderização dos pontos e arestas do modelo 3D, utilizando os dados do arquivo `.obj` apenas para texturas.

Após a obtenção dos resultados das simulações, procedeu-se à medição de parâmetros específicos relacionados à visualização 3D. Os parâmetros avaliados incluíram o tempo de carregamento inicial do resultado, o tempo de alteração da variável visualizada (como temperatura ou pressão) e o uso de memória do navegador. Essas medições foram fundamentais para a análise comparativa do desempenho das arquiteturas.

Todos os parâmetros foram medidos utilizando a Performance API do JavaScript, incorporada em funções ou “callbacks” específicos para cada modelo. Cada valor foi medido dez vezes, e a média desses valores foi calculada para a análise. O uso de memória foi verificado através da propriedade “memory” da Performance API, que permitiu inspecionar o tamanho da memória “heap” do JavaScript utilizada pela aplicação, embora a documentação da API aponte que sua confiabilidade não é absoluta.

A análise dos dados coletados envolveu a comparação do desempenho das duas arquiteturas em relação aos parâmetros medidos, bem como a avaliação de aspectos qualitativos. Foram identificados padrões de comportamento em relação ao tempo de carregamento, tempo de alteração de variáveis e consumo de memória, permitindo uma compreensão aprofundada das vantagens e desvantagens de cada abordagem arquitetural.

Uma limitação metodológica identificada durante as medições foi a incapacidade da segunda arquitetura, baseada em APIs REST, de carregar os modelos com o maior nível de refinamento. Além disso, a primeira arquitetura, que emprega uma biblioteca proprietária, apresentou funcionalidades adicionais que não estavam presentes na segunda, o que implicaria em um custo de implementação mais elevado para a arquitetura REST caso essas funcionalidades fossem replicadas.

Outras limitações incluíram melhorias identificadas durante a fase de desenvolvimento que não puderam ser implementadas na segunda arquitetura, as quais poderiam ter simplificado o carregamento de dados. A análise do consumo de memória, embora útil para identificar padrões, foi realizada com a Performance API do JavaScript, cuja documentação indica que os valores podem ser subestimados ou superestimados, afetando a precisão absoluta das medições.

3. Resultados e Discussão

Os resultados obtidos neste estudo fornecem uma base empírica robusta para a compreensão do desempenho de diferentes arquiteturas de software na visualização de simulações CAE em ambientes de nuvem. A análise comparativa entre a arquitetura baseada em WebSockets (A1) e a arquitetura baseada em APIs REST (A2) revelou padrões distintos de comportamento em relação ao tempo de carregamento inicial, tempo de alteração de variáveis e consumo de memória. É fundamental ressaltar que a arquitetura A2 demonstrou uma limitação crítica ao não conseguir carregar modelos com o maior nível de refinamento (nível 10), o que impactou diretamente o escopo da comparação para os cenários de maior complexidade. Consequentemente, a discussão para os modelos de refinamento 10 se concentrará exclusivamente nos dados da arquitetura A1, enquanto os níveis de refinamento 1 e 5 permitirão uma comparação direta entre ambas as abordagens. As medições foram realizadas utilizando a Performance API do JavaScript, com cada valor sendo a média de dez repetições, garantindo uma representatividade estatística dos dados coletados.

O tempo de carregamento inicial do resultado é um dos parâmetros mais críticos para a experiência do usuário em aplicações web, especialmente em contextos de engenharia que envolvem grandes volumes de dados. Este parâmetro mede o intervalo em milissegundos necessário para que o modelo de simulação seja completamente carregado e visualizado na aplicação. Conforme apresentado na Figura 1, a arquitetura A2 (APIs REST) demonstrou um desempenho superior no carregamento inicial para os modelos com níveis de refinamento 1 e 5, tanto para o Modelo 1 (válvula hidráulica) quanto para o Modelo 2 (turbina hidráulica). Por exemplo, para o Modelo 1 com refinamento 1, a A2 registrou um tempo médio de 2.642 ms, enquanto a A1 levou 4.909 ms. Essa diferença se manteve consistente para os demais cenários de baixa e média complexidade, indicando uma vantagem inicial significativa para a abordagem REST.

Figura 1. Tempo de carregamento inicial em milissegundos.

Fonte: Resultados originais da pesquisa.

A superioridade da arquitetura A2 no carregamento inicial pode ser atribuída à sua abordagem de conversão de arquivos `.foam` para `.obj` no backend e posterior transmissão desses arquivos `.obj` para o frontend. Embora o processo de conversão adicione uma etapa, a transmissão de um arquivo `.obj` pode ser mais otimizada para o carregamento inicial em alguns navegadores e bibliotecas de renderização como ThreeJS, que é a base da A2. Em contraste, a arquitetura A1, que utiliza WebSockets e a biblioteca HOOPS Envision Web para streaming progressivo, pode incorrer em uma sobrecarga inicial maior devido ao estabelecimento da conexão persistente e ao processamento inicial dos dados para renderização progressiva. A literatura sobre usabilidade web, como destacado por Nielsen e Loranger (2006), enfatiza que tempos de carregamento rápidos são cruciais para a satisfação do usuário e para evitar o abandono da aplicação. Nesse sentido, a A2 apresenta uma vantagem perceptível que poderia ser explorada em cenários onde o carregamento inicial é a principal métrica de desempenho e a interação subsequente é menos frequente ou menos intensiva em dados.

No entanto, é imperativo considerar o cenário de maior complexidade. Para os modelos com nível de refinamento 10, que representam volumes de dados significativamente maiores (2,52 GB para o Modelo 1 e 5,7 GB para o Modelo 2), a arquitetura A2 não foi capaz de carregar os resultados. Isso levanta sérias questões sobre a escalabilidade da A2 para aplicações industriais reais, onde a visualização de modelos altamente detalhados é uma exigência comum. A arquitetura A1, por outro lado, conseguiu carregar esses modelos, embora com tempos de carregamento substancialmente maiores. Para o Modelo 1 com refinamento 10, a A1 registrou um tempo de carregamento inicial de 418.984 ms (aproximadamente 7 minutos), e para o Modelo 2 com refinamento 10, 525.357 ms (aproximadamente 8,7 minutos). Embora esses tempos sejam longos, a capacidade de processar e visualizar esses dados complexos é um diferencial crucial. A incapacidade da A2 de lidar com esses volumes de dados sugere que, apesar de sua eficiência em cenários mais simples, ela não atende aos requisitos de robustez para simulações CAE de alta fidelidade, um ponto crítico para a adoção em ambientes de produção (Lange et al., 2021). A otimização da transmissão e do processamento de dados para a A2 seria um passo fundamental para mitigar essa limitação, talvez explorando técnicas de compressão mais avançadas ou abordagens de carregamento assíncrono que minimizem o impacto no navegador.

O tempo de alteração na variável de resultado visualizada é outro indicador vital para a interatividade e a capacidade analítica da aplicação. Este parâmetro mede o tempo necessário para que a visualização seja atualizada após a mudança de uma variável, como temperatura ou pressão. Conforme ilustrado na Figura 2, a arquitetura A1 (WebSockets) demonstrou uma performance notavelmente superior em comparação com a A2 (APIs REST) para os modelos com níveis de refinamento 1 e 5. Por exemplo, para o Modelo 1 com refinamento 1, a A1 levou apenas 565 ms para alterar a variável, enquanto a A2 necessitou de 2.812 ms. Essa disparidade se acentua com o aumento da complexidade do modelo, evidenciando uma vantagem clara para a A1 em termos de responsividade interativa.

Figura 2. Tempo de alteração da variável do resultado em milissegundos.

Fonte: Resultados originais da pesquisa.

A eficiência da arquitetura A1 na alteração de variáveis pode ser atribuída à sua utilização de WebSockets e à biblioteca HOOPS Envision Web, que provavelmente incorpora otimizações para renderização progressiva e atualizações incrementais de dados. O uso de um objeto JSON no frontend para controlar a visualização e gerar mensagens para o backend, que processa e retorna a visualização para renderização progressiva, sugere um mecanismo de atualização mais ágil. Em contraste, a arquitetura A2, que depende de chamadas de API REST e da conversão de `.foam` para `.obj` para cada nova visualização de variável, incorre em um overhead de processamento e transmissão de dados que se assemelha ao carregamento inicial. Isso resulta em tempos de resposta mais lentos, o que pode prejudicar significativamente a experiência do usuário durante a análise interativa dos resultados da simulação. A capacidade de alternar rapidamente entre diferentes variáveis de resultado é crucial para engenheiros que precisam explorar múltiplos cenários e identificar padrões complexos em tempo real (Johansson, 2014). A lentidão da A2 nesse aspecto a torna menos adequada para tarefas que exigem alta interatividade.

Para os modelos de maior complexidade (refinamento 10), onde apenas a arquitetura A1 pôde ser avaliada, os tempos de alteração de variável foram, como esperado, significativamente maiores, mas ainda gerenciáveis dentro da mesma arquitetura. Para o Modelo 1 com refinamento 10, a A1 registrou 34.055,3 ms (aproximadamente 34 segundos), e para o Modelo 2 com refinamento 10, 71.926,6 ms (aproximadamente 72 segundos). Embora esses tempos sejam consideráveis, a arquitetura A1 mantém a funcionalidade de alteração de variável para os modelos mais complexos, o que a A2 não conseguiu fazer. Isso reforça a robustez da A1 para lidar com cenários de alta demanda computacional e visualização de dados massivos, um requisito fundamental para a Engenharia Assistida por Computador moderna (Hochstein et al., 2011). A implementação de otimizações de cache no lado do cliente ou de técnicas de pré-processamento de dados no servidor para a A2 poderia potencialmente reduzir esses tempos, mas exigiria um esforço de desenvolvimento significativo para equiparar a performance da A1.

O uso de memória do navegador é um fator crítico para a estabilidade e o desempenho de aplicações web, especialmente aquelas que lidam com visualizações 3D complexas. As medições foram realizadas em dois momentos: durante o carregamento do resultado e após o carregamento. É importante notar que a documentação da Performance API do JavaScript, utilizada para essas medições, indica que seus valores podem ser subestimados ou superestimados, o que exige uma interpretação cautelosa dos resultados absolutos, mas permite a identificação de padrões. Conforme a Figura 3, que apresenta o consumo de memória durante o carregamento para os modelos de refinamento 1 e 5, a arquitetura A1 (WebSockets) geralmente consumiu menos memória do que a A2 (APIs REST) em cenários de menor complexidade. Por exemplo, para o Modelo 1 com refinamento 1, a A1 utilizou 72,32 MB, enquanto a A2 consumiu 99,26 MB. Essa tendência se manteve para a maioria dos casos de baixa e média complexidade, sugerindo uma gestão de memória mais eficiente por parte da A1 durante o processo inicial.

Figura 3. Consumo de memória em MB durante o carregamento do resultado.

Fonte: Resultados originais da pesquisa.

A análise do consumo de memória após o carregamento do resultado, conforme a Figura 4, reforça essa observação e revela um padrão ainda mais acentuado. Para os modelos de refinamento 1 e 5, a arquitetura A1 manteve um consumo de memória significativamente menor do que a A2. Por exemplo, para o Modelo 1 com refinamento 5, a A1 consumiu 170,25 MB, enquanto a A2 utilizou 393,76 MB. Essa diferença, que se torna mais pronunciada com o aumento da complexidade do modelo, indica que a biblioteca HOOPS Envision Web, empregada na A1, possui otimizações robustas para o gerenciamento de memória no navegador, possivelmente através de técnicas de descarte de dados não essenciais ou de representações mais compactas dos modelos 3D após a renderização inicial. A capacidade de manter um baixo consumo de memória é vital para a estabilidade da aplicação em sessões de uso prolongadas e para evitar travamentos do navegador, especialmente em máquinas com recursos limitados.

Figura 4. Consumo de memória em MB após o carregamento do resultado.

Fonte: Resultados originais da pesquisa.

A questão do consumo de memória torna-se ainda mais crítica ao considerar a incapacidade da arquitetura A2 de carregar os modelos com nível de refinamento 10. Comparando o tamanho dos arquivos de simulação gerados (2,52 GB para o Modelo 1 e 5,7 GB para o Modelo 2, ambos com refinamento 10) com o consumo de memória observado na A2 para modelos de menor complexidade, é plausível inferir que o consumo de memória para os modelos mais complexos excederia os limites práticos ou impostos pelos navegadores. A A2, ao converter os arquivos `.foam` em `.obj` e transmiti-los para o frontend, pode estar mantendo uma representação mais pesada dos dados na memória do navegador. Essa limitação é um obstáculo intransponível para a aplicação da A2 em cenários de simulação CAE que exigem alta fidelidade e detalhe, onde o volume de dados é inerentemente grande. A literatura sobre computação em nuvem e visualização 3D frequentemente discute a necessidade de estratégias eficientes de gerenciamento de recursos para lidar com grandes conjuntos de dados (Hochstein et al., 2011), e a A2 parece falhar nesse aspecto para os casos mais exigentes.

Para a arquitetura A1, que conseguiu carregar os modelos de refinamento 10, o consumo de memória durante o carregamento foi de 244,59 MB para o Modelo 1 e 335,29 MB para o Modelo 2. Após o carregamento, esses valores caíram para 237,23 MB e 122,12 MB, respectivamente. Embora esses valores sejam maiores do que para os modelos de menor complexidade, eles são significativamente menores do que os tamanhos dos arquivos de simulação originais (2,52 GB e 5,7 GB), o que demonstra a eficácia das otimizações da biblioteca HOOPS Envision Web na gestão de memória. A capacidade da A1 de processar e manter na memória do navegador uma representação eficiente de modelos que, em sua forma original, excedem em muito a capacidade de memória típica de um navegador, é uma vantagem técnica substancial. Isso sugere que a A1 realiza um processamento inteligente dos dados, talvez utilizando técnicas de LOD (Level of Detail) ou de carregamento sob demanda para manter apenas as informações essenciais na memória ativa, um aspecto crucial para a viabilidade de visualizações 3D complexas em ambientes web.

Além dos aspectos quantitativos de desempenho, a análise qualitativa das arquiteturas revela importantes trade-offs. A arquitetura A2, baseada em APIs REST e na biblioteca ThreeJS de código aberto, oferece uma flexibilidade significativamente maior para a implementação de novas funcionalidades e melhorias. A dependência reduzida de bibliotecas proprietárias confere aos desenvolvedores maior controle sobre o código-fonte e a lógica de renderização, facilitando a customização e a adaptação a requisitos específicos. Essa autonomia pode resultar em um custo de desenvolvimento inicial mais baixo e em uma manutenção mais simplificada a longo prazo, pois a equipe não está atrelada às decisões de design e aos ciclos de atualização de um fornecedor externo. A simplicidade na implementação, conforme mencionado, é uma vantagem para equipes que buscam agilidade e controle total sobre a pilha tecnológica.

Por outro lado, a arquitetura A1, que emprega a biblioteca proprietária HOOPS Envision Web, oferece funcionalidades adicionais e otimizações de desempenho que não estão presentes na A2. Essas funcionalidades, como a renderização progressiva e a gestão eficiente de memória para modelos complexos, seriam difíceis e custosas de replicar na A2. A decisão de utilizar uma biblioteca proprietária implica em uma dependência tecnológica, o que pode aumentar os custos de licenciamento e limitar a flexibilidade de customização. No entanto, a performance e a robustez que a A1 demonstrou em lidar com os modelos mais complexos, especialmente no que tange ao tempo de alteração de variáveis e ao consumo de memória, são vantagens inegáveis para cenários de produção que exigem alta performance e escalabilidade. Richards e Ford (2020) argumentam que cada decisão arquitetural na engenharia de software envolve uma troca, e é fundamental compreender quais aspectos são mais importantes para o contexto específico da aplicação.

No contexto deste trabalho, a incapacidade da arquitetura A2 de visualizar os resultados mais complexos (refinamento 10) e suas limitações no tempo de alteração de variáveis e no consumo de memória a tornam menos adequada para ambientes de produção de simulações CAE, onde a manipulação de grandes volumes de dados é a norma. Embora a A2 tenha demonstrado um tempo de carregamento inicial promissor para modelos mais simples e ofereça maior flexibilidade de desenvolvimento, essas vantagens são ofuscadas pela sua falta de escalabilidade e desempenho em cenários de alta demanda. Para que a arquitetura A2 se torne viável em um ambiente industrial, seriam necessárias melhorias significativas no uso da memória e na otimização da transmissão de arquivos, possivelmente através da implementação de técnicas de compressão de dados mais eficientes, estratégias de carregamento de dados sob demanda ou aprimoramentos na biblioteca ThreeJS para lidar com modelos de maior complexidade de forma mais otimizada.

Em suma, a escolha da arquitetura de software para visualização de resultados de simulações CAE na nuvem é um fator crítico que impacta diretamente o desempenho e a usabilidade do sistema. Os resultados deste estudo demonstram que, embora ambas as arquiteturas apresentem vantagens e desvantagens, a arquitetura A1 (WebSockets com HOOPS Envision Web) se mostra mais robusta e escalável para lidar com a complexidade inerente aos dados de simulações CAE em ambientes de produção. A capacidade da A1 de carregar e interagir com modelos de alto refinamento, juntamente com sua gestão eficiente de memória e tempos de alteração de variáveis mais rápidos, a posiciona como a opção mais adequada para aplicações que exigem alta fidelidade e interatividade. As observações e medições realizadas neste trabalho contribuem para uma compreensão mais aprofundada dos desafios e limitações associados à visualização 3D em nuvem, fornecendo insights valiosos para futuras decisões arquiteturais e desenvolvimentos tecnológicos na área.

4. Conclusão

Conclui-se que o objetivo foi atingido, ao avaliar e comparar o desempenho de arquiteturas baseadas em WebSockets (A1) e APIs REST (A2) para a visualização tridimensional de resultados de simulações CAE na nuvem. Os resultados demonstraram que a arquitetura A1, utilizando WebSockets e a biblioteca HOOPS Envision Web, mostrou-se mais robusta e escalável, sendo capaz de carregar e interagir com modelos de alta complexidade (refinamento 10), além de apresentar tempos de alteração de variáveis significativamente menores e gestão de memória mais eficiente. Em contrapartida, a arquitetura A2, baseada em APIs REST e ThreeJS, embora tenha exibido um tempo de carregamento inicial superior para modelos de baixa e média complexidade, falhou em processar os modelos mais complexos, evidenciando limitações críticas de escalabilidade e desempenho para cenários de alta demanda.

As principais limitações deste estudo residem na sua concentração em aspectos de desempenho quantitativos, deixando de aprofundar em certas características qualitativas, como a flexibilidade de desenvolvimento e a dependência de bibliotecas proprietárias. A A1, por exemplo, oferece funcionalidades otimizadas, mas com custo de implementação e manutenção potencialmente mais elevados devido à sua natureza proprietária. Para estudos futuros, sugere-se a implementação de otimizações na arquitetura A2, focando na gestão de memória e na eficiência da transmissão de dados, possivelmente através de técnicas de compressão avançadas ou carregamento assíncrono, para que possa se tornar viável em ambientes de produção. Adicionalmente, recomenda-se investigar a fundo os limites de memória dos navegadores para a A2 e explorar a viabilidade de outras abordagens arquiteturais ou bibliotecas de visualização 3D.

Referências Bibliográficas

Creswell, J.W.; Creswell, J.D. 2018. Research Design: Qualitative, Quantitative, and Mixed Methods Approaches. 3. ed. Sage Publications. Los Angeles, Califórnia, Estados Unidos.

Haworth, D.; O’Rourke, P.; Ranganathan, R. 1998. Three-Dimensional Computational Fluid Dynamics. Disponível em: https://www.osti.gov/biblio/1186. Acesso em: 02 abr. 2025.

Hochstein, L.; Schott, B.; Graybill, R. 2011. Computational Engineering in the Cloud: Benefits and Challenges. Journal of Organizational and End User Computing 23 (4): 31-50.

Johansson, T. (2014). Trends in pre- and post-processing. International Journal of Computer Applications in Technology 7 (6): 131-139.

Kolbasin, A.; Husu, O. 2018. Computer-aided design and Computer-aided engineering. MATEC Web Conf., 170 (2018) 01115.

Lange, C.; Barthelmäs, P.; Rosnitschek, T.; Tremmel, S.; Rieg, F. 2021. Impact of HPC and Automated CFD Simulation Processes on Virtual Product Development—A Case Study. Applied Sciences 11 (14): 6552.

Nielsen, J; Loranger, H. 2006. Prioritizing Web Usability. New Riders Press. Berkeley, Califórnia, Estados Unidos.

Petrillo, C. 1990. Numerical solution of partial differential equations by the finite element method. Acta Applicandae Mathematica (18) 184-186.

Richards, M; Ford, N. 2020. Fundamentals of Software Architecture. O’Reilly Media, Inc. Sebastopol, Califórnia, Estados Unidos.

Sheikholeslami, M.; Abohamzeh, E. 2022. Lattice Boltzmann Method. p. 123-144. In: Gangawane, K.; Dwivedi, M. Advanced Computational Techniques for Heat and Mass Transfer in Food Processing. CRC Press. Boca Raton, Flórida, Estados Unidos.

Versteeg, H; Malalasekera, W. 2007. Introduction to Computational Fluid Dynamics: The Finite Volume Method. Pearson, Harlow, Inglaterra.

Walker, R.A.; Shah, S.C.; Gupta, N.K. 1984. Computer-aided engineering (CAE) for system analysis. Proceedings of the IEEE 72 (12): 1732-1745.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy