Requisitos do Sistema

Botão visível na tela principal; ao clicar, envia comando STOP e exibe feedback visual de parada confirmada.

A interface de monitoramento deve exibir em tempo real o status de cada processo.

A interface deve oferecer filtros dinâmicos e busca rápida por falhas, logs e eventos.

Campo de busca funcional sem recarregar página; resultados retornam em ≤ 2 s.

O sistema deve implementar pipeline de SCA para analisar dependências antes do deploy.

Execução automática a cada build; falha de CVE crítico bloqueia deploy.

100% dos eventos críticos logados com timestamp e ID; perda máxima tolerada = 1 evento.

Formulário registra dados corretamente; taxa de falha ≤ 1%; sem travamentos.

O sistema deve restringir o envio de perguntas por robôs de rede interna.

Bloqueio ativo de acessos não autenticados; logs de tentativas mantidos.

Disponível do início ao fim; bloqueado após término; tempo de resposta ≤ 1 s.

Merge apenas via Pull Request aprovado por 2 revisores; push direto bloqueado.

Deploy ocorre apenas após build aprovado; rollback automático disponível.

A interface deve ter feature de parada de emergência em caso de falhas ou danos.

A interface deve ter tempo de resposta < 1 s em operações críticas.

A arquitetura de DevOps deve seguir GitFlow com controles de acesso rígidos.

O repositório deve possuir varredura automática de chaves e segredos.

Nenhum commit com segredos permitido; scanner executado a cada build.

Ícones e labels compatíveis com leitores de tela; contraste > 7:1.

Logs de auditoria gerados; acesso restrito a operadores autorizados.

O robô deve parar imediatamente (tempo máximo de resposta ≤ 1 s) após o botão de emergência ser pressionado, interrompendo todos os processos ativos.

O backend deve receber o comando STOP e enviar confirmação ao robô em ≤ 1 s; log de parada deve registrar timestamp e origem do comando.

O backend deve enviar o comando de parada para o robô de forma prioritária, com confirmação de execução e redundância no canal de envio.

Sistema deve registrar ACK de parada em até 1 s; falhas de transmissão ≤ 1%.

Os endpoints de comunicação entre backend e robô devem permitir troca de comandos e status em tempo real, incluindo dados de sensores, movimento e estado.

Latência média de comunicação ≤ 200 ms; 100% das mensagens críticas entregues e confirmadas.

As falas geradas via LLM devem ser processadas e transmitidas ao robô com tempo máximo de resposta de 1,5 s.

Testes de desempenho confirmam tempo médio ≤ 1,5 s em 95% das requisições.

Todos os endpoints REST ou WebSocket devem exigir autenticação JWT válida antes de permitir qualquer operação de controle sobre o robô.

Nenhuma requisição não autenticada aceita; logs registram ID de sessão e timestamp.

O backend deve implementar rate limiting em todos os endpoints críticos, prevenindo abuso ou sobrecarga indevida.

Limite configurado de 100 req/min por IP; logs registram violações; bloqueios aplicados automaticamente.

O sistema deve registrar logs detalhados de todas as requisições, incluindo status, endpoint, payload e tempo de resposta.

Logs armazenados com precisão de timestamp ≤ 10 ms; nenhuma requisição crítica sem registro.

O backend deve manter latência máxima de 200 ms para comunicação com o robô e ≤ 500 ms para geração de resposta das falas LLM.

Monitoramento contínuo confirma médias dentro do limite em 95% dos testes sob carga nominal.

A infraestrutura de rede deve garantir baixa perda de pacotes (≤ 1%) e tempo de reconexão inferior a 2 segundos após falha.

Testes de estresse validam reconexão ≤ 2 s; perda de pacotes ≤ 1% em 1.000 iterações.

O backend deve seguir padrões OWASP API Security Top 10, prevenindo vulnerabilidades como injeções, autenticação fraca e exposição indevida de dados.

Auditoria de segurança trimestral comprova 0 vulnerabilidades críticas.

O rate limiter deve ser configurável e adaptativo, permitindo ajustes dinâmicos de limite conforme tipo de endpoint e contexto operacional.

Painel administrativo permite alteração de limites sem downtime; alterações registradas em log.

O backend deve possuir monitoramento contínuo de desempenho e disponibilidade, com alertas em caso de falha.

Todos os logs e métricas do backend devem ser armazenados de forma segura e criptografada, com retenção mínima de 90 dias.

O sistema deve operar com dois modelos de linguagem distintos: Modelo A (Detector) — responsável por identificar perguntas capciosas, enganosas, maliciosas ou de natureza antiética; e Modelo B (Respondente) — responsável por gerar respostas somente quando autorizado pelo Modelo A.

Os testes devem comprovar que o Modelo B apenas gera respostas após autorização explícita do Modelo A, com taxa de falsos positivos inferior a 2%.

O Modelo B deve recusar a geração de respostas quando o Modelo A classificar a entrada como capciosa ou potencialmente maliciosa.

Durante testes de validação, o Modelo B deve bloquear 100% das tentativas de resposta em entradas classificadas como capciosas pelo Modelo A.

Logs de auditoria devem comprovar que toda comunicação entre os modelos ocorre via canal interno autenticado e criptografado.

O sistema deve registrar as decisões do Modelo A (Detector) para auditoria, incluindo entradas classificadas, tempo de inferência e motivo da classificação.

Logs de auditoria devem registrar 100% das inferências, contendo data/hora, entrada, saída e justificativa.

O Modelo B deve produzir respostas verificáveis, parciais em relação ao Inteli, evitando menções vagas, meias verdades, difamações ou menções negativas a pessoas, grupos ou instituições.

As respostas devem passar por teste de conformidade ética e semântica com precisão ≥ 95% segundo checklist de validação.

O sistema deve possuir um módulo de auditoria de geração de conteúdo, capaz de revisar periodicamente respostas e detectar possíveis desvios éticos ou factuais.

Auditorias mensais devem detectar e corrigir 100% dos desvios classificados como críticos.

O sistema de dois modelos deve utilizar estratégias de inferência assíncrona, evitando bloqueios ou gargalos entre o Detector e o Respondente.

O sistema deve processar entradas simultâneas mantendo latência total ≤ 1,5s em 95% das requisições.

A base de dados utilizada no RAG deve ser tratada e padronizada para eficiência e relevância.

Índices otimizados e consistência de dados ≥ 99%; consultas retornam em ≤ 1 s.

O sistema de LLMs deve operar com latência total ≤ 1,5 s, incluindo filtragem pelo Modelo A.

Testes de desempenho validam tempo médio ≤ 1,5 s em 95% das requisições.

Deve haver isolamento lógico e físico entre ambientes de inferência.

Nenhum compartilhamento de dados entre ambientes detectado; verificações semanais de segurança.

Modelos devem ser reprodutíveis, gerando resultados consistentes sob mesmas condições.

Métricas de desempenho e detecção de falhas devem ser monitoradas continuamente.

Sistema de alertas ativa notificação em < 60 s após detecção de falha.

O pipeline de AIOps deve registrar logs e métricas de inferência, falhas e auditorias.

Logs armazenados com retenção mínima de 90 dias; perda máxima de eventos = 0%.

O robô deve detectar e evitar obstáculos, pessoas e objetos em tempo real.

O robô não deve colidir com nenhum objeto ou pessoa, evitando qualquer tipo de dano físico.

O robô deve interromper o movimento imediatamente ao detectar risco iminente de colisão, perda de controle ou falha de sensor.

O robô deve parar em até 1 segundo após a detecção de risco ou falha.

O robô deve utilizar sensores de proximidade, LiDAR e visão computacional para mapear o ambiente e ajustar sua trajetória dinamicamente.

O robô deve demonstrar capacidade de desviar de obstáculos móveis e fixos em testes controlados.

O robô deve seguir comandos do backend via WebRTC apenas após validação de integridade e origem da mensagem.

O robô só deve executar comandos validados com origem conhecida e integridade confirmada.

Em caso de perda de conexão com o backend, o robô deve entrar automaticamente em modo seguro (failsafe).

O robô deve parar o movimento e aguardar reconexão ao detectar perda de sinal.

O robô deve implementar protocolos de comunicação seguros entre hardware e backend, utilizando criptografia DTLS (Data transfer layer security) para prevenir ataques Man-in-the-Middle (MITM).

Todas as mensagens entre o robô e o backend devem ser criptografadas e autenticadas.

A latência máxima de comunicação entre o robô e o backend não deve ultrapassar 200 ms.

Testes de comunicação devem confirmar latência ≤ 200 ms em 95% do tempo de operação.

O robô deve manter taxa mínima de disponibilidade de conexão de 99%, reconectando-se automaticamente em menos de 3 segundos após uma falha de rede.

O robô deve conseguir se reconectar sozinho após falha, dentro do tempo especificado, em 95% dos testes.

A arquitetura do robô deve ser modular e redundante, permitindo que falhas em um subsistema (ex: sensor ultrassônico) não comprometam o funcionamento global.

Durante testes com falha induzida em subsistemas, o robô deve continuar operando com funções críticas.

O robô deve ser fisicamente seguro, com motores limitados por torque e velocidade para evitar impacto danoso em humanos ou objetos.

Em testes de segurança, os limites de força e velocidade não devem ser ultrapassados.

A pilha ROS 2 (se for utilizado ROS 2) deve ser configurada com QoS adequada aos canais críticos conforme prioridade de mensagem.

A configuração deve garantir que mensagens críticas (ex: parada de emergência) tenham prioridade e baixa latência.

O sistema deve ser testado em ambiente controlado para verificar tolerância a falhas de sensores, perda de rede e falhas de hardware.

O sistema deve manter operação segura e controlada mesmo com falhas simuladas em testes.

Completude funcional, Correção funcional, Apropriabilidade funcional

Adequação da reconhecibilidade, Apreensibilidade, Operacionalidade, Proteção contra erro do usuário, Estética da interface, Acessibilidade

Maturidade, Disponibilidade, Tolerância a falhas, Recuperabilidade

Confidencialidade, Integridade, Não repúdio, Responsabilidade, Autenticidade

Modularidade, Reusabilidade, Analisabilidade, Modificabilidade, Testabilidade

Adaptabilidade, Capacidade para ser instalado, Capacidade para substituir