Avaliação de Artefato do SBRC 2026
Em 2026, o SBRC 2026 contará com um Comitê Técnico de Artefatos (CTA) para avaliar os artefatos dos artigos aceitos. Tais artefatos incluem software, dados, documentação complementar, resultados brutos, provas de conceito, modelos, avaliações detalhadas, benchmarks, etc. O artefato é um recurso essencial para os trabalhos de pesquisa e a qualidade dele é tão importante quanto a do próprio artigo científico.
O artefato será avaliado por um comitê específico, que poderá atribuir até quatro selos:
- Artefatos Disponíveis (SeloD),
- Artefatos Funcionais (SeloF),
- Artefatos Sustentáveis (SeloS), e
- Experimentos Reprodutíveis (SeloR).
O processo de avaliação de artefatos terá como base o processo de avaliação realizado por conferências renomadas como SIGCOMM, USENIX, CoNEXT e EuroSys. É fundamental que os autores leiam as descrições dos selos disponíveis para artefatos, bem como a descrição do que é esperado de um artefato.
Chamada para Artefatos
Autores com artigos aceitos no SBRC 2026 são incentivados a enviar artefatos para serem avaliados pelo comitê técnico de artefatos (CTA). Um artefatos pode ser um software, dados, documentação, resultados brutos, provas, modelos, benchmarks, etc.
Quatro selos de qualidade podem ser considerados para um artefato. Estes sendo:
- Artefatos Disponíveis (SeloD);
- Artefatos Funcionais (SeloF);
- Artefatos Sustentáveis (SeloS); e
- Experimentos Reprodutíveis (SeloR).
Antes de enviar seu artefato, verifique os requisitos para a aquisição de cada selo. Caso você tenha alguma dúvida ou preocupação, você pode entrar em contato.
Instruções de submissão
Quatro selos de qualidade podem ser considerados para um artefato. Após a notificação de aceite do artigo, os autores podem opcionalmente submeter o(s) artefato(s) relacionado(s) (os autores do Salão de Ferramentas são obrigados a fazer a submissão do artefato).
Os autores devem fazer o registro do artefato na plataforma hotcrp. Este registro requer algumas informações como contato dos autores, um link para o artefato e opcionalmente um apêndice. Vale lembrar que o processo de revisão do CTA é independente da revisão do artigo no JEMS e as submissões são single-blind.
Importante ressaltar que para um artefato o comitê de revisão espera que:
- Os requisitos mínimos do README estejam presentes no repositório;
- Informações sobre recursos específicos estejam presentes no apêndice.
- O artefato atenda os critérios dos selos solicitados;
- Os autores respondam as perguntas postadas pelos revisores na plataforma, como enviem a carta de rebuttal dentro do prazo.
Todo o processo de revisão do artefato será realizado pela plataforma hotcrp. Os autores com artefatos registrados para o processo de revisão serão notificados sobre o acesso à plataforma e devem observar por emails enviados pela plataforma com dúvidas do comitê de revisão. Todo o processo de comunicação dos revisores de artefatos com os autores é realizado pelo hotcrp.
Requisitos mínimo README.md (Obrigatório)
Para facilitar o processo de avaliação dos artefatos, foi criado um modelo de README.md (Obrigatório) com todos os campos mínimos esperados para um artefato. Veja exemplos de README.md de Artefatos com 4 Selos.
# Título projeto
Resumo descrevendo o objetivo do artefato, com o respectivo título e resumo do artigo.
# Estrutura do readme.md
Apresenta a estrutura do readme.md, descrevendo como o repositório está organizado.
# Selos Considerados
Os autores devem descrever quais selos devem ser considerados no processo de avaliação. Como por exemplo: ``Os selos considerados são: Disponíveis e Funcionais.''
# Informações básicas
Esta seção deve apresentar informações básicas de todos os componentes necessários para a execução e replicação dos experimentos.
Descrevendo todo o ambiente de execução, com requisitos de hardware e software.
# Dependências
Informações relacionadas a benchmarks utilizados e dependências para a execução devem ser descritas nesta seção.
Busque deixar o mais claro possível, apresentando informações como versões de dependências e processos para acessar recursos de terceiros caso necessário.
# Preocupações com segurança
Caso a execução do artefato ofereça algum tipo de risco para os avaliadores. Este risco deve ser descrito e o processo adequado para garantir a segurança dos revisores deve ser apresentado.
# Instalação
O processo de baixar e instalar a aplicação deve ser descrito nesta seção. Ao final deste processo já é esperado que a aplicação/benchmark/ferramenta consiga ser executada.
# Teste mínimo
Esta seção deve apresentar um passo a passo para a execução de um teste mínimo.
Um teste mínimo de execução permite que os revisores consigam observar algumas funcionalidades do artefato.
Este teste é útil para a identificação de problemas durante o processo de instalação.
# Experimentos
Esta seção deve descrever um passo a passo para a execução e obtenção dos resultados do artigo. Permitindo que os revisores consigam alcançar as reivindicações apresentadas no artigo.
Cada reivindicações deve ser apresentada em uma subseção, com detalhes de arquivos de configurações a serem alterados, comandos a serem executados, flags a serem utilizadas, tempo esperado de execução, expectativa de recursos a serem utilizados como 1GB RAM/Disk e resultado esperado.
Caso o processo para a reprodução de todos os experimentos não seja possível em tempo viável. Os autores devem escolher as principais reivindicações apresentadas no artigo e apresentar o respectivo processo para reprodução.
## Reivindicações #X
## Reivindicações #Y
# LICENSE
Apresente a licença.
É obrigatório que TODAS as Seções apresentadas no requisito mínimo README.md estejam presentes. Se você tiver qualquer dúvida, por favor, entre em contato conosco.
Note Antes de submeter o seu artefato, é interessante que os autores realizem a instalação e execução do seu artefato em um ambiente novo (máquina virtual) seguindo somente as instruções presente no README.md.
Recursos específicos ou restrições
Caso recursos adicionais sejam necessários (infraestrutura de nuvem, chaves SSH, etc.) para a avaliação do artefato, estas informações devem ser submetidas através de um apêndice. Neste os autores incluem informações adicionais (privadas, como chaves SSH para acessar o Google Cloud) para auxiliar os revisores do Comitê Técnico de Artefatos. O modelo LaTeX de apêndice está disponível em Exemplo-Apendice. Todos os campos devem ser apresentados no apêndice, além dos requisitos mínimos para o README.md que são obrigatórios.
O apêndice é um critério adicional no momento que recursos específicos acabam sendo necessários para a avaliação do artefato ou restrições de acesso existam.
Requisitos por selo
Para que o trabalho/artefato seja apto a receber o selo, os respectivos requisitos devem ser alcançados:
Artefatos Disponíveis (SeloD)
É esperado que o código e/ou dados estejam disponíveis em um repositório estável (como GitHub e GitLab). Neste repositório é esperado encontrar um README.md com os requisitos mínimos. O arquivo README.md do repositório pode ser o mesmo arquivo submetido para apreciação do CTA.
Artefatos Funcionais (SeloF)
É esperado que o código e/ou artefato possa ser executado e o revisor consiga observar algumas de suas funcionalidades. Para adquirir este artefato, é importante que informações adicionais estejam presentes no README.md do repositório, como
- lista de dependências;
- lista de versões das dependências/linguagens/ambiente;
- descrição do ambiente de execução;
- instruções de instalação e execução;
- um exemplo de execução mínima.
Artefatos Sustentáveis (SeloS)
É esperado que o código e/ou artefato esteja modularizado, organizado, inteligível e de fácil compreensão. Para obter o selo é interessante que:
- exista uma documentação mínima do código (descrevendo arquivos, funções,..);
- legibilidade mínima de código;
- permita que os avaliadores consigam identificar as principais reivindicações do artigo no artefato.
Experimentos Reprodutíveis (SeloR)
É esperado que o revisor consiga reproduzir as principais reivindicações apresentadas no artigo. Sugere-se a utilização de máquinas virtuais, containers ou scripts que facilitem e reduzam o tempo de criação do ambiente. Para obter este selo é esperado:
- instrução para executar as principais reivindicações (e.g., resultados dos principais gráficos/tabelas);
- descrição de um processo de como foram executados os experimentos para chegar até o resultado do artigo. Para atender esses requisitos sugere-se a inclusão de script(s) que automatizem ao máximo todo o processo de reprodução;
Processo de revisão
O processo de revisão de artefatos está dividido em duas etapas de revisão, como autor você deve ficar atento às perguntas levantadas pelos revisores na plataforma. Após o término da primeira etapa de revisão (r1), os autores devem submeter uma carta de rebuttal que visa esclarecer problemas encontrados pelos revisores e auxiliar no processo de revisão. Por fim, os revisores vão considerar as revisões da primeira fase e a carta de rebuttal para tomar uma decisão na segunda fase de avaliação (r2-decision).
Calendário de revisão para o ciclo de revisão:
- Prazo para Submissão de Artefatos
- Rodada 1 de Revisão (r1)
- Fase de Rebuttal
- Decisão do Revisor (r2-decision)
*As datas estão disponíveis no hotcrp.
Instruções para revisão
Seu objetivo como um revisor de artefato consiste em garantir que a qualidade do artefato corresponda com o conteúdo do artigo e os requisitos mínimos esperados para a obtenção de cada selo.
Note: Observe que o período de revisão é relativamente curto. Recomendamos iniciar suas revisões assim que receber sua tarefa, já que dois selos requerem a execução do artefato.
Passos para a Avaliação de um Artefato
O processo de revisão pode ser realizado em um ambiente de sua preferência, desde que satisfaça os requisitos mínimos do ambiente de execução esperado para o artefato. Recomendamos a execução do artefato (quando aplicável) em um ambiente virtual, por trazer praticidade para os revisores e garantir que componentes presentes na sua máquina local não prejudiquem o processo de avaliação (uma instalação limpa em um ambiente novo pode reduzir imprevistos).
Todos os recursos adicionais necessários para execução do artefato (infraestrutura de nuvem, chaves SSH etc.) devem estar presentes no apêndice que descreve o artefato.
O artefato em avaliação está relacionado a um artigo em avaliação pelos comitês técnicos da conferência. O foco de um revisor do CTA está voltado para o artefato e não para a revisão do artigo. No entanto, caso seja encontrado algum problema, ele deve ser relatado aos coordenadores de avaliação de artefatos.
Note: Lembre-se de que todos os artefatos, análises e discussões são confidenciais.
Processo de Revisão
No momento que um artefato é alocado para revisão, você já pode começar o trabalho de revisão. Quanto antes você começar melhor, pois permite que problemas sejam encontrados e discutidos com os autores. Neste ano teremos a revisão em 2 etapas:
-
Na primeira etapa (r1) os revisores fazem a revisão do artefato considerando os critérios de avaliação. Durante este processo mensagens podem ser postadas na plataforma hotcrp, estas podem ser discussões entre membros do comitê de revisão, como perguntas para os autores, como por exemplo perguntas em relação a problemas encontrados no artefato. No final do processo de revisão você deve submeter um parecer que será apresentado para os autores. Este deve destacar as etapas que foram realizadas para a avaliação de cada selo, o processo de execução observado e resultado alcançado (problemas no processo de execução deve estar claramente explicados na revisão). Os autores vão responder aos pontos levantados nesta etapa na fase de rebuttal.
-
A segunda etapa (r2-decision) ocorrerá após a fase de rebuttal dos autores. No qual, os autores com base na revisão realizada na primeira fase devem esclarecer dúvidas, solucionar problemas encontrados, informar eventuais equívocos e/ou explicar algo que passou despercebido aos revisores. Seu papel como revisor na segunda etapa consiste em considerar os pontos levantados na primeira fase e na fase de rebuttal para tomar uma decisão em quais selos devem ser atribuídos ou não.
Calendário de revisão para o ciclo de revisão:
- Prazo para Submissão de Artefatos
- Rodada 1 de Revisão (r1)
- Fase de Rebuttal
- Decisão do Revisor (r2-decision)
*As datas estão disponíveis no hotcrp.
Note Procure escrever sua revisão de forma precisa, impessoal e polida, considerando que a mesma estará disponível para os autores em uma fase posterior do processo.
Critérios de avaliação
Para realizar esta atividade com excelência, você deve considerar os quatro Selos e seus respectivos requisitos mínimos que devem ser alcançados para a alocação de um selo:
Artefatos Disponíveis (SeloD)
É esperado que o código e/ou dados estejam disponíveis em um repositório estável (como GitHub e GitLab). Neste repositório é esperado encontrar um README.md com os requisitos mínimos do README.md. Os requisitos mínimos do README.md sendo:
# Título projeto
Resumo descrevendo o objetivo do artefato, com o respectivo título e resumo do artigo.
# Estrutura do readme.md
Apresenta a estrutura do readme.md, descrevendo como o repositório está organizado.
# Selos Considerados
Os autores devem descrever quais selos devem ser considerados no processo de avaliação. Como por exemplo: ``Os selos considerados são: Disponíveis e Funcionais.''
# Informações básicas
Esta seção deve apresentar informações básicas de todos os componentes necessários para a execução e replicação dos experimentos.
Descrevendo todo o ambiente de execução, com requisitos de hardware e software.
# Dependências
Informações relacionadas a benchmarks utilizados e dependências para a execução devem ser descritas nesta seção.
Busque deixar o mais claro possível, apresentando informações como versões de dependências e processos para acessar recursos de terceiros caso necessário.
# Preocupações com segurança
Caso a execução do artefato ofereça algum tipo de risco para os avaliadores. Este risco deve ser descrito e o processo adequado para garantir a segurança dos revisores deve ser apresentado.
# Instalação
O processo de baixar e instalar a aplicação deve ser descrito nesta seção. Ao final deste processo já é esperado que a aplicação/benchmark/ferramenta consiga ser executada.
# Teste mínimo
Esta seção deve apresentar um passo a passo para a execução de um teste mínimo.
Um teste mínimo de execução permite que os revisores consigam observar algumas funcionalidades do artefato.
Este teste é útil para a identificação de problemas durante o processo de instalação.
# Experimentos
Esta seção deve descrever um passo a passo para a execução e obtenção dos resultados do artigo. Permitindo que os revisores consigam alcançar as reivindicações apresentadas no artigo.
Cada reivindicações deve ser apresentada em uma subseção, com detalhes de arquivos de configurações a serem alterados, comandos a serem executados, flags a serem utilizadas, tempo esperado de execução, expectativa de recursos a serem utilizados como 1GB RAM/Disk e resultado esperado.
Caso o processo para a reprodução de todos os experimentos não seja possível em tempo viável. Os autores devem escolher as principais reivindicações apresentadas no artigo e apresentar o respectivo processo para reprodução.
## Reivindicações #X
## Reivindicações #Y
# LICENSE
Apresente a licença.
Artefatos Funcionais (SeloF)
É esperado que o código e/ou artefato possa ser executado e o revisor consiga observar algumas de suas funcionalidades. Para adquirir este artefato, é importante que informações adicionais estejam presentes no README.md do repositório, como
- lista de dependências;
- lista de versões das dependências/linguagens/ambiente;
- descrição do ambiente de execução;
- instruções de instalação e execução;
- um exemplo de execução mínima.
Note: Como revisor além de verificar que o artefato possua os respectivos critérios é necessário a execução do artefato. Na sua revisão será esperado uma prova de execução, com alguns dos outputs apresentados pela ferramenta.
Artefatos Sustentáveis (SeloS)
É esperado que o código e/ou artefato esteja modularizado, organizado, inteligível e de fácil compreensão. Para obter o selo é interessante que:
- exista uma documentação mínima do código (descrevendo arquivos, funções,..);
- legibilidade mínima de código;
- permita que os avaliadores consigam identificar as principais reivindicações do artigo no artefato.
Experimentos Reprodutíveis (SeloR)
É esperado que o revisor consiga reproduzir as principais reivindicações apresentadas no artigo. Para obter este selo é esperado:
- instrução para executar as principais reivindicações (e.g., resultados dos principais gráficos/tabelas);
- descrição de um processo de como foram executados os experimentos para chegar até o resultado do artigo;
Note: Para a atribuição do selo você deve reproduzir (executar) os experimentos apresentados no artigo através do conteúdo encontrado no artefato. Alcançando as reinvidicações encontradas no artigo, reproduzindo tabelas e figuras. Na sua revisão é esperado um resumo com estes resultados.
Entrega das Revisões
Para cada artefato, você deve produzir uma breve revisão justificando a razão por atribuir ou negar um selo ao artefato. Esta avaliação só deve ser completada após o processo de avaliação ter sido realizado.
Para facilitar o processo de avaliação, um exemplo está disponível junto ao formulário de submissão.
Melhores trabalhos
Para atribuir os prêmios de melhores trabalhos, utilizaremos como um dos critérios a classificação atribuída pelos revisores na categoria “Candidato ao Prêmio Artefato Distinto”. Dessa forma, espera-se que os revisores atribuam notas mais elevadas (3 e 4) para trabalhos com pelo menos 3 selos e que se destaquem pela qualidade em relação aos demais. Ainda, se espera que trabalhos que não obtiveram mais de dois selos não possuam nota superior a nota mínima (1).
Exemplos de Artefatos com 4 Selos do SF/SBRC 2025
A seguir, apresentam-se alguns dos principais artefatos contemplados com os quatro selos no Salão de Ferramentas do SBRC 2025. Os respectivos arquivos README.md servem como exemplos de boas práticas de documentação e organização.
- Cloud AutoDroid: Um Sistema Distribuído Escalável para Execução de Ferramentas de IA Generativa
- HackInSDN Dashboard
- Mininet-GUI: Uma Abordagem Visual e Interativa para Experimentação em Redes SDN
- THEXCAD - Sistema de Tesselação Hexagonal para cobertura de área com drones
- UNetyEmu: Unity-based simulator for aerial and non-aerial vehicles with integrated network emulation
- VulnSyncAI: PLN e LLMs para Construção e Atualização Contínua de Datasets de Vulnerabilidades
Resultados
Trabalhos com Selos Atribuídos
Trilha Principal (TP)
| Disp. | Func. | Sus. | Repr. | Título do Trabalho |
|---|---|---|---|---|
 |  |  |  | Agente K-alibra: Estratégia para Seleção de K-Clientes em Aprendizado Federado autônoma |
| | | | Unsupervised DDoS Detection in High-Speed Networks: An Evaluation Using Real Transit Provider Data |
| | | | Flex-Cubic: A Runtime-Adaptive Loss-Tolerant TCP Cubic |
| | | | GlobalAmBC-DRL: Reproducible Artifact for "A New Centralized DRL-Based Control Module for Dense Batteryless IoT Networks with Ambient Backscatter" |
| | | | ORION: Escalonamento de Tarefas baseado em Otimização Multiobjetivo para Nuvens Veiculares |
| | | | PRINCE: A Proactive Client Selection in Federated Learning for Connected and Autonomous Vehicles |
| | | | CAIROS: Controle Adaptativo do aprendIzado fedeRadO em redes Sem fio |
| | | | Tronco: Um Operador Genético para Remapeamento de Serviços de Rede Sensível ao Histórico |
| | | | Aprendizado Federado com Geração de Embeddings para Controle da Heterogeneidade Estatística |
| | | | Ataques de Envenenamento de Rótulos contra a Detecção de Zero-Day em Sistemas de Detecção de Intrusão Colaborativos |
| | | | Seleção de Clientes Federados usando Aprendizado por Reforço Multiagente |
| | | | Modelagem e Otimização do Aprendizado Federado para Justiça do Nível de Energia em Redes Sem Fio |
| | | | Avaliação de Inferência em Edge AI sob Restrições Embarcadas em um Sistema Robótico Simulado Baseado na Internet das Coisas Robóticas |
| | | | Uma Análise Comparativa de Algoritmos de Machine Learning e Explicabilidade para Detecção de Intrusão de Redes |
| | | | Recomendação de rotas consciente de QoE com Atenção e Comunicação |
| | | | Uma Extensão Pós-Quântica Híbrida para o Protocolo Matrix: Avaliação Experimental e Impacto Sistêmico |
| | | | IMPA: Novo algoritmo para atribuição de potência de forma adaptativa em SDM-EONs |
| | | | Uma Abordagem Declarativa e Modular para Adaptação Dinâmica da Camada de Enlace de Redes Heterogêneas |
| | | Agente VAMOS! Planejamento de Rotas Veiculares Cientes de Contexto Semântico com Agentes de LLM | |
| | | NOAH: Protocolo Hibrido e Adaptativo de Codificação de Rede para Comunicação por Luz Visível | |
| | | ASTRA: Adaptive Student-Teacher Method for Robust Aggregation and Client Drift Reduction in Federated Learning | |
| | | Mascaramento por Agrupamento e Rotulagem com LLMs para Compartilhamento de Datasets de Incidentes em Redes | |
| | | Detecção de Oportunidades de Sanduíche MEV via Grafo de Fluxo de Controle de Contratos Inteligentes | |
| | | C2N: Bridging CAMARA Service APIs and 3GPP Core Network Exposure Function | |
| | | Ember: Asynchronous Dynamic Data Serving for PyTorch Distributed Training | |
| | An Experimental Framework for Studying Non-IID Data in Federated Learning for Network Telemetry | ||
| | Comparative Performance Analysis of IaC Tools for Deploying Containerized SDN Topologies in Cloud Environments | ||
| | On the Scale Transition of Event-Driven IoT Architectures: An Experimental Evaluation | ||
| Evasão em Modelos de Detecção de Ameaças de Rede Usando Propriedades do Espaço de Decisão | |||
| Orquestração de dispositivos IoT em cenários complexos com interação humana baseada em LLMs | |||
| Degradação de Desempenho de Contramedidas Estáticas a Ataques de Negação de Serviço de Baixo Volume | |||
| Do Aprendizado Centralizado ao Federado: O Que Acontece com a Explicabilidade dos Modelos? | |||
| Escalonamento de Recursos de Rádio para Suporte ao Aprendizado Federado em Redes 5G | |||
| Cybersecurity in the CAN Protocol: A Systematic Mapping of Attacks and Vulnerabilities in Practical Scenarios | |||
| Latency-Aware Routing and Multidimensional Optical Resource Allocation for CF-RAN over SDM-EON | |||
| Framework para Verificação e Validação Experimental de Configurações de Rede Geradas por LLMs | |||
| Enforcing Service Stability for WebAssembly Extended Reality Workloads at the Edge A Quality of Service Aware Orchestration Framework | |||
| Representação Baseada em Grafos de Infraestrutura como Código: Possibilitando o Raciocínio Semântico para Sistemas Conteinerizados |
Salão de Ferramentas (SF)
| Disp. | Func. | Sus. | Repr. | Título do Trabalho |
|---|---|---|---|---|
| | | | QuantumNet: Um Simulador de Redes Quânticas baseado em uma Arquitetura em Camadas com Interface Gráfica |
| | | | AnonShield: Scalable On-Premise Pseudonymization for CSIRT Network Vulnerability Data |
| | | | UNetyEmuROS: A Unity-Based Multi-Vehicle Simulator with Physically-Grounded Dynamics and ROS2 Sensor Integration |
| | | | IoT-Zoo: A Container-Based Framework for Heterogeneous IoT Device Profiles and Reproducible Traffic Capture |
| | | | From Red Flags to Detection Rules: An LLM-driven Pipeline for Real-Time GOOSE Intrusion Detection and Prevention |
| | | | GhostView: Enabling Deep Visibility in Programmable Data Planes with Minimal Server Overhead |
| | | | Yes, CARLA CAN: Extending the CARLA Simulator for In-Vehicle Network Cybersecurity Experimentation |
| | | | GridGooseSV: um Módulo do NS-3 para Simular Protocolos de Comunicação de Smart Grids definidos na IEC 61850 |
| | | | FirewallTester: desenvolvimento de ferramenta para automação de testes e validação de regras de firewalls |
| | | | SAARIS: Um Simulador Aberto de Antenas e Superfícies Inteligentes Reconfiguráveis |
| | | | IoT-ID: Deterministic Device Identity from Hybrid Network Fingerprinting |
| | | | dsm2cli: A Verifiable and Observable Pipeline for Translating Network Intents into Multivendor CLI |
| | | | FL-H.IAAC: Um Testbed Heterogêneo para Aprendizado Federado em Borda |
| | | The Last WAVE: Integrating with Mininet for More Flexible and Reproducible Network Experiments | |
| | | MedTracker: A BLE-Based Indoor Localization System for Tracking Portable Medical Devices in Hospital Environments | |
| | FLeer2FLeer: Uma Ferramenta Web Baseada em Arquitetura Par-a-Par para Orquestração do Aprendizado Federado | ||
| | P4R: Scaling Stateful Network Testing and Trace Replay with Nanosecond-level Accuracy | ||
| Metadata privacy and obliviousness in distributed learning via a bulletin board: a proof-of-concept | |||
| WASP: Workload Agent-Based Simulation Platform for Migration Recommendations in Federated Kubernetes Environments | |||
| SimpleSim: An Open-Source Python Simulator for SDM-EON Resource Allocation |
Trabalhos Destaque na Categoria Artefatos
TBA
Revisores Destaque
TBA
Organizadores
Coordenadores do CTA
Tiago Heinrich (UFPR/MPI)
Diego Kreutz (UNIPAMPA)
Leandro Bertholdo (UFRGS)
Antonio João Azambuja (UFRGS)
Comitê Técnico de Artefatos (CTA)
Alex Sandre Pinheiro Severo (UNIPAMPA)
Alexandre Sztajnberg (UERJ)
Aline de Lurdes Zuliani Lunkes (PUCPR)
Amanda Viescinski (UFPR)
Anderson Frasão (UFPR)
Anderson Bergamini de Neira (UFPR)
Arthur Vinícius Cunha Camargo (UFRGS)
Beatriz Roland Machado (UNIPAMPA)
Cristhian Eduardo Kapelinski de Avilla (UNIPAMPA)
David Arantes Pereira (UFU)
Diego Kreutz (UNIPAMPA)
Diego Medeiros de Abreu (UFPA)
Douglas Lautert (UNIPAMPA)
Douglas Rodrigues Fideles (UNIPAMPA)
Edvar Afonso Luciano Filho (PETROBRAS)
Emanuel Carricio Ferreira (UNIPAMPA)
Fabricio Eduardo Rodriguez Cesen (Telefónica Research)
Fêlipe Rosário de Araújo (UFBA)
Fernando Silva (UFRJ)
Fiterlinge Martins de Sousa (RNP)
Gefte Alcantara de Almeida (UNIPAMPA)
Gustavo Zambonin (UFSC)
Jeronimo Soares de Castro Menezes (UNIPAMPA)
Joner Assolin (UFAM)
Laerte Peotta de Melo (UnB)
Laura Negreiros Naves (UNICAMP)
Leandro C. de Almeida (IFPB)
Leonardo de Jesus Bitzki (UNIPAMPA)
Lucas Mayr (UFSC)
Matheus Cabral (UNIPAMPA)
Matheus Martins Ciocca (UNIPAMPA)
Nicolas Kolling Ribas (UFRGS)
Paulo Ditarso Maciel Jr. (IFPB)
Rafael Santa Rosa Alves (UNICAMP)
Ramon Fontes (UFRN)
Rodrigo Mansilha (UNIPAMPA)
Vitor Reiel Moura de Lima (UFC)
Weslei Ferreira Santos (UFBA)
William Akihiro Alves Aisawa (ICMC-USP)
Melhores Revisores do CTA
TBD
Contato
Comite Tecnico comite.tecnico.de.artefatos@gmail.com