Segurança em Robótica

Visão geral

Segurança em robótica (robotics safety) é a disciplina de garantir que robôs do mundo real — robôs móveis, braços industriais, drones, dispositivos médicos e humanoides — operem sem causar danos inaceitáveis a pessoas, patrimônio ou ao meio ambiente. Segurança não é um recurso isolado; é uma propriedade do sistema que emerge da mecânica, eletrônica, software, controle e interação humana.

Robôs modernos frequentemente combinam controle clássico com componentes baseados em aprendizado (learning-based components) (por exemplo, percepção profunda (deep perception), políticas aprendidas (learned policies)). Isso aumenta a capacidade, mas também introduz novos modos de falha, como mudança de distribuição (distribution shift) e casos extremos difíceis de prever (hard-to-predict corner cases). Uma estratégia prática de segurança, portanto, combina:

  • Restrições de segurança (safety constraints) (o que nunca pode ser violado, ou só pode ser violado dentro de limites controlados)
  • Verificação e validação (verification and validation) (evidências de que o sistema atende aos requisitos de segurança)
  • Tratamento de falhas (failure handling) (detectar falhas e transicionar para estados seguros)

Este artigo conecta ferramentas teóricas (métodos formais (formal methods), controle com restrições (constrained control)) a padrões práticos de engenharia (paradas de emergência (E-stops), watchdogs (watchdogs), redundância (redundancy)) e mostra como a segurança se encaixa na pilha padrão de robótica Percepção → Planejamento → Controle.

O que “seguro” significa em robótica

Segurança é frequentemente confundida com objetivos relacionados:

  • Confiabilidade (reliability): o robô funciona como esperado na maior parte do tempo.
  • Robustez (robustness): o robô tolera perturbações e erros de modelagem.
  • Segurança cibernética (security): o robô resiste a ataques maliciosos.
  • Segurança funcional (functional safety): o sistema evita risco injustificável devido a falhas (hardware/software), normalmente guiado por normas.

Um robô pode ser confiável, mas inseguro (por exemplo, mover-se rapidamente de forma confiável perto de humanos), ou robusto, mas inseguro (por exemplo, alcançar um alvo de forma robusta ignorando zonas de exclusão (keep-out zones)). Segurança trata de risco, geralmente formulado como:

Risco = severidade × probabilidade (às vezes também × exposição)

A engenharia de segurança busca reduzir risco tanto por prevenção (evitar perigos) quanto por mitigação (limitar consequências quando algo dá errado).

Fontes comuns de perigos

Robôs são críticos para segurança porque podem exercer força e se mover em ambientes humanos. Categorias frequentes de perigos incluem:

  • Perigos cinemáticos (kinematic hazards): colisões, esmagamento, pontos de pinçamento, enrosco.
  • Perigos dinâmicos (dynamic hazards): impactos em alta velocidade, cargas instáveis, detritos projetados.
  • Perigos de percepção (perception hazards): falha em detectar pessoas/obstáculos, falsos positivos causando comportamento errático.
  • Perigos de planejamento/controle (planning/control hazards): controle instável, oscilações, trajetórias inseguras.
  • Fatores humanos (human factors): sinalização pouco clara, confiança excessiva, UI confusa, procedimentos de manutenção inseguros.
  • Perigos específicos de ML (ML-specific hazards): mudança de distribuição, previsões excessivamente confiantes, manipulação de recompensa (reward hacking), generalização insegura.

Restrições de segurança: de requisitos à aplicação

Restrições de segurança especificam invariantes ou limites que devem valer durante a operação. Em robótica, restrições aparecem em múltiplas camadas:

  • Mecânica: bordas arredondadas, materiais complacentes, limites de torque, freios.
  • Elétrica: limitação de corrente, fusíveis, trilhos de alimentação seguros.
  • Software/controle: limites de velocidade/aceleração, zonas de exclusão, margens de estabilidade.
  • Operacional: áreas de trabalho restritas, limites de velocidade quando há humanos presentes, procedimentos.

Restrições rígidas vs. flexíveis

  • Restrições rígidas (hard constraints) não podem ser violadas (por exemplo, “nunca entrar na zona perto de humano”, “nunca exceder o limite de torque”).
  • Restrições flexíveis (soft constraints) são objetivos negociados com desempenho (por exemplo, “preferir manter 1,5 m de distância, mas pode chegar mais perto para evitar uma queda”).

Na prática, robôs frequentemente implementam uma hierarquia:

  1. Restrições rígidas impostas por mecanismos de segurança de baixo nível (intertravamentos de hardware (hardware interlocks), paradas de proteção).
  2. Restrições rígidas/flexíveis impostas por controle e planejamento (Controle, Planejamento de Movimento).
  3. Objetivos de desempenho otimizados sujeitos a restrições.

Tipos de restrições que você vê em sistemas reais

  • Restrições de estado (state constraints): limites de posição, limites de junta, regiões de exclusão.
  • Restrições de entrada (input constraints): velocidade máxima, aceleração, jerk, limites de torque/corrente.
  • Restrições de taxa (rate constraints): suavidade para estabilidade e conforto.
  • Restrições de contato (contact constraints): força máxima no efetuador final; comportamento complacente em tarefas ricas em contato (Manipulação).
  • Restrições de visibilidade (visibility constraints): por exemplo, “não se mover se a covariância de localização exceder um limiar” (relacionado a SLAM).

Exemplo: limitação de velocidade perto de humanos

Um padrão comum em robôs colaborativos é monitoramento de velocidade e separação (speed and separation monitoring): conforme uma pessoa se aproxima, o robô deve reduzir a velocidade e possivelmente parar. Isso requer:

  • Uma estimativa de distância até o humano (a partir de lidar/câmera)
  • Uma política de segurança que mapeie distância → velocidade máxima permitida
  • Um limitador de baixo nível difícil de burlar

Pseudo-lógica:

def max_speed_allowed(distance_m):
    if distance_m < 0.3:
        return 0.0          # protective stop
    elif distance_m < 1.0:
        return 0.2          # slow
    else:
        return 1.0          # normal

v_cmd = planner_velocity()
v_safe = clip_norm(v_cmd, max_speed_allowed(human_distance()))
send_to_controller(v_safe)

Mesmo que o planejador seja aprendido ou tenha bugs, o limitador impõe um limite inegociável.

Controle com restrições para segurança

Na camada de controle, a segurança frequentemente é imposta usando otimização com restrições ou invariância comprovável. Duas ideias amplamente usadas são Controle Preditivo por Modelo (Model Predictive Control, MPC) e Funções de Barreira de Controle (Control Barrier Functions, CBFs).

Controle Preditivo por Modelo (MPC) com restrições

MPC resolve um problema de otimização online: escolher controles futuros para minimizar um custo respeitando restrições (aproximações de desvio de obstáculos, limites de entrada etc.). Isso é atraente porque as restrições são explícitas, mas:

  • Depende da qualidade do modelo.
  • A resolubilidade em tempo real importa.
  • Restrições não convexas (obstáculos complexos) podem ser difíceis.

MPC é comum para drones, veículos autônomos e manipuladores quando as restrições são bem modeladas e há capacidade de computação disponível.

Funções de Barreira de Controle (CBFs): impondo invariantes

CBFs fornecem uma forma de garantir que o sistema permaneça dentro de um conjunto seguro (safe set) ( \mathcal{S} = {x : h(x) \ge 0} ). Intuitivamente, se você consegue escolher ações que impeçam (h(x)) de diminuir “rápido demais”, você permanece seguro.

Um padrão comum é um filtro de segurança minimamente invasivo:

  • Calcular um controle nominal (u_{\text{nom}}) (de um controlador ou de uma política aprendida).
  • Resolver um pequeno programa quadrático (QP) para encontrar o controle mais próximo (u) que satisfaça a restrição de barreira.

QP conceitual:

minimize    ||u - u_nom||^2
subject to  h_dot(x, u) + alpha * h(x) >= 0
            u in U  (actuator limits)

Exemplo prático: manter um robô móvel a pelo menos d_min de um obstáculo na posição p_obs. Defina:

  • h(x) = ||p - p_obs||^2 - d_min^2 (seguro se ≥ 0)

Então o QP garante que você não reduza a distância de forma agressiva demais, mesmo que a política nominal tente passar perto demais.

CBFs são amplamente usadas como camadas de segurança em tempo de execução (runtime safety layers) porque são rápidas e modulares: elas podem “envolver” um controlador existente ou uma política aprendida.

Verificação: construindo confiança com evidências

Robótica crítica para segurança (safety-critical robotics) tipicamente exige mais do que “funciona em demos”. Você precisa de evidências de que as restrições se mantêm sob suposições definidas. A verificação abrange um espectro:

  • Testes e simulação (empírico)
  • Verificação formal (formal verification) (matemático)
  • Monitoramento em tempo de execução (runtime monitoring) (detectar e mitigar quando suposições falham)

Requisitos e análise de perigos

Um fluxo de trabalho padrão começa com análise estruturada de perigos:

  • Análise de Modos de Falha e Efeitos (Failure Modes and Effects Analysis, FMEA): enumerar falhas de componentes e seus efeitos.
  • Análise de Árvore de Falhas (Fault Tree Analysis, FTA): analisar como combinações de eventos levam a perigos.
  • Análise de Processos Teórico-Sistêmica (System-Theoretic Process Analysis, STPA): foca em ações de controle inseguras e interações.

A partir disso, você deriva requisitos como:

  • “O robô deve entrar em parada de proteção em até 100 ms após a ativação do E-stop.”
  • “O robô não deve exceder 250 N de força de contato em modo colaborativo.”
  • “Se a incerteza de localização exceder um limiar, o robô deve reduzir a velocidade e solicitar intervenção do operador.”

Métodos formais: o que pode ser provado?

Verificação formal é mais forte quando os modelos do sistema são bem definidos:

  • Verificação de modelos (model checking) (frequentemente para máquinas de estados discretas): verificar propriedades temporais como “se ocorrer falha, eventualmente atingir parada segura.”
  • Análise de alcançabilidade (reachability analysis): computar conjuntos de estados que o sistema pode alcançar; usada para provar desvio de colisão sob perturbações limitadas.
  • Prova de teoremas (theorem proving): provar propriedades de controladores/algoritmos; poderosa, mas trabalhosa.
  • Verificação probabilística (probabilistic verification): raciocinar sobre restrições de chance (chance constraints) e modelos estocásticos.

Em robótica, provas formais completas de ponta a ponta são raras porque componentes de percepção e aprendizado são difíceis de modelar. Em vez disso, equipes frequentemente verificam envelopes críticos de segurança (limites de velocidade, comportamento de parada, intertravamentos) e usam garantia em tempo de execução para o restante.

Validação: cobertura de cenários e simulação

Mesmo sem provas completas, você pode aumentar a confiança com validação sistemática:

  • Testes de cenários baseados em simulação (incluindo geração de cenários adversariais (adversarial scenario generation))
  • Reexecução de logs (log replay) contra novas versões de software
  • Testes baseados em propriedades (property-based testing) para planejadores (por exemplo, “nunca produzir uma trajetória que viole limites de junta”)
  • Testes com hardware no laço (hardware-in-the-loop, HIL) para temporização, sensores e controladores

Simulação é essencial, mas deve ser tratada com cuidado devido à lacuna Sim2Real (Sim2Real)—especialmente para dinâmica de contato, percepção e casos extremos raros.

Garantia em tempo de execução: “confie, mas verifique” durante a operação

Garantia em tempo de execução (runtime assurance, RTA) é uma arquitetura prática para robôs que usam componentes complexos ou aprendidos:

  • Um módulo de alto desempenho propõe ações (planejador, política aprendida).
  • Um monitor de segurança verifica restrições.
  • Um controlador de contingência (fallback controller) assume se houver risco de violar restrições.

Isso é comum em robôs móveis e drones, onde percepção ou planejamento aprendidos são úteis, mas a segurança deve ser imposta por mecanismos mais simples e verificados.

Monitores de segurança e “escudos”

Um monitor pode verificar:

  • Limites de entrada (velocidade/torque)
  • Colisões previstas dentro de um horizonte de tempo
  • Saúde de sensores (timeouts, valores implausíveis)
  • Qualidade de localização (limiares de covariância)
  • Sobrecarga de CPU / perdas de temporização no laço de controle

Um “escudo (shield)” modifica ou rejeita ações inseguras. Por exemplo, uma política aprendida de navegação pode produzir um comando de direção; o escudo o limita (clip) ou o sobrepõe com uma manobra de frenagem se uma colisão for iminente.

Tratamento de falhas: detectando falhas e alcançando um estado seguro

Robôs reais falham de formas confusas: sensores desconectados, escorregamento de rodas, obstáculos inesperados, deadlocks de software. Segurança requer um modelo de falhas e um plano de detecção, isolamento e recuperação de falhas (fault detection, isolation, and recovery, FDIR).

Estados seguros e degradação graciosa

Um robô deve ter estados seguros definidos, como:

  • Parada de proteção (protective stop): energia removida dos atuadores ou freios acionados.
  • Parada controlada (controlled stop): desacelerar ativamente até parar (mais seguro para cargas).
  • Posição segura (safe pose): braço recolhido para evitar pontos de pinçamento.
  • Modo degradado (degraded mode): velocidade reduzida, espaço de trabalho restrito, autonomia limitada.

Projetar estados seguros exige entender o ambiente. Por exemplo, a “parada” de um drone não é pairar para sempre se a bateria estiver baixa — o comportamento seguro pode ser “pousar no local seguro mais próximo”.

Padrões práticos de detecção de falhas

  • Watchdogs (watchdogs): se o laço de controle perder prazos, acionar parada/degradação.
  • Verificações de plausibilidade de sensores: comparar sensores redundantes ou checar consistência física (por exemplo, IMU vs odometria de rodas).
  • Timeouts: ausência de atualizações de percepção → reduzir velocidade ou parar.
  • Verificações de realimentação de atuadores: discrepância entre velocidade/torque comandados e medidos indica escorregamento, saturação ou falha.
  • Monitoramento térmico/de corrente: prevenir incêndios e danos ao motor.

Exemplo: um watchdog simples de heartbeat entre um planejador e um controlador:

last_msg_time = now()

def on_planner_command(cmd):
    global last_msg_time
    last_msg_time = now()
    apply(cmd)

def control_loop():
    if now() - last_msg_time > 0.2:   # 200 ms without updates
        enter_degraded_mode()         # e.g., slow/stop and hold position

Recuperação e humano no laço

Algumas falhas devem solicitar imediatamente intervenção humana:

  • Localização inconsistente em espaços lotados
  • Eventos repetidos de quase-acidente (near-miss)
  • Sensores degradados (por exemplo, lidar parcialmente ocluído)
  • Contatos não modelados em tarefas de manipulação

Segurança efetiva também envolve comunicação clara ao operador: alarmes, luzes de status e logs de eventos que expliquem por que o robô parou.

Segurança com componentes baseados em aprendizado

Aprendizado agora é comum em robótica: percepção profunda, preensão aprendida, políticas aprendidas de navegação (Aprendizado por Imitação, Aprendizado por Reforço). Desafios de segurança surgem porque modelos de ML podem:

  • Ser excessivamente confiantes em entradas fora da distribuição (Detecção Fora da Distribuição)
  • Falhar sob mudança de distribuição (iluminação, clima, deriva de sensor) (Mudança de Distribuição)
  • Explorar brechas da recompensa (em RL)
  • Produzir saídas de controle instáveis ao extrapolar

Mitigações práticas incluem:

  • Tomada de decisão ciente de incerteza (uncertainty-aware decision making): usar confiança/incerteza calibradas para acionar redução de velocidade ou contingência (Estimativa de Incerteza).
  • Políticas conservadoras e camadas de segurança: “filtros” CBF/MPC em torno de ações aprendidas.
  • Curadoria de dados para segurança (data curation for safety): incluir dados de quase-acidente e casos extremos; enfatizar exemplos negativos.
  • Domínio de projeto operacional (operational design domain, ODD): definir explicitamente onde o sistema de ML foi projetado para funcionar (por exemplo, indoor, piso plano, limite de velocidade, conjunto de sensores).
  • Monitoramento de deriva do modelo (model drift): detectar degradação de desempenho e acionar revalidação.

Exemplo: percepção aprendida + segurança baseada em regras

Um robô de armazém pode usar uma rede neural (neural network) para detectar paletes e pessoas. Se a confiança do detector cair (por exemplo, câmera embaçada), o robô pode:

  • Reduzir a velocidade
  • Aumentar o raio de inflação de obstáculos no planejamento
  • Preferir navegação apenas por lidar
  • Parar e solicitar limpeza/inspeção se a confiança permanecer baixa

Este é um projeto típico de defesa em profundidade (defense-in-depth): ML melhora a capacidade, mas a segurança não depende exclusivamente de ML estar correta.

Segurança na pilha de robótica

Segurança deve ser projetada ao longo de todo o pipeline:

  • Percepção: redundância de sensores, verificações de plausibilidade, estimativa de incerteza
  • Localização/Mapeamento: comportamento fail-safe quando SLAM se degrada
  • Planejamento: planejamento ciente de restrições, margens conservadoras, checagem de colisão verificada (Planejamento de Movimento)
  • Controle: estabilidade, entradas limitadas, filtros de segurança (CBFs/MPC) (Controle)
  • Sistema: intertravamentos, E-stops, watchdogs, logs, UX do operador

Um antipadrão comum é “adicionar segurança” apenas no final (por exemplo, apenas um E-stop). Um padrão mais seguro é múltiplas camadas independentes de modo que, se uma falhar, outras ainda previnam dano.

Normas e conformidade (visão de alto nível)

Muitas implantações de robôs são guiadas por normas de segurança e regimes de certificação. Qual norma se aplica depende do domínio:

  • Robôs industriais / robôs colaborativos: ISO 10218, ISO/TS 15066 (diretrizes de colaboração)
  • Segurança funcional (geral): IEC 61508 (norma guarda-chuva de segurança funcional)
  • Autonomia automotiva: ISO 26262 (segurança funcional), ISO/PAS 21448 (SOTIF—segurança da funcionalidade pretendida), UL 4600 (diretrizes de safety case para autonomia)
  • Robótica médica: estruturas regulatórias variam (por exemplo, processos da FDA nos EUA)

Essas normas tipicamente enfatizam processo: análise de perigos, requisitos rastreáveis, evidências de verificação e controle de mudanças — não apenas algoritmos.

Juntando tudo: um fluxo de trabalho prático de engenharia de segurança

Uma abordagem pragmática de ponta a ponta para equipes de robôs reais:

  1. Definir o domínio de projeto operacional (ODD) e perigos inaceitáveis.
  2. Realizar análise de perigos (FMEA/FTA/STPA) e derivar requisitos de segurança.
  3. Projetar restrições de defesa em profundidade, incluindo intertravamentos de hardware e software.
  4. Implementar garantia em tempo de execução:
    • monitores (entradas, temporização, saúde de sensores)
    • filtros de segurança (CBF/MPC ou planejadores conservadores)
    • controladores de contingência e estados seguros
  5. Plano de verificação e validação:
    • testes unitários e de integração para código crítico para segurança
    • cenários de simulação e testes de regressão
    • hardware no laço para temporização e comportamento de atuadores
  6. Procedimentos operacionais:
    • treinamento de E-stop, etapas de manutenção, sinalização de segurança
    • reporte de incidentes e coleta de logs
  7. Monitoramento contínuo após implantação:
    • métricas de quase-acidente
    • detecção de deriva para componentes de ML
    • revalidação periódica após atualizações

Desafios em aberto e direções de pesquisa

Segurança em robótica continua sendo uma área ativa de pesquisa, especialmente com o aumento da autonomia:

  • Verificação escalável (scalable verification) para sistemas com percepção neural e políticas aprendidas (Redes Neurais)
  • Segurança composicional (compositional safety): provar que módulos seguros permanecem seguros quando integrados
  • Segurança na interação humano-robô (human-robot interaction safety): prever movimento e intenção humanos sob incerteza
  • Segurança sob mudança de distribuição: detectar quando você está fora do ODD e responder apropriadamente
  • Benchmarking e métricas (benchmarking and metrics): medir segurança além de “número de colisões”, incluindo quase-acidentes e violações de restrições

Principais conclusões

  • Segurança em robótica é uma propriedade em nível de sistema: combine projeto mecânico, controle com restrições, verificação e procedimentos operacionais.
  • Restrições de segurança devem ser impostas em camadas, com restrições rígidas o mais próximo possível de hardware/controle.
  • Verificação é mais forte para componentes bem modelados; garantia em tempo de execução e monitoramento cobrem as lacunas — especialmente para ML.
  • Tratamento de falhas não é opcional: robôs devem detectar falhas, transicionar para estados seguros e degradar de forma graciosa quando necessário.
  • Aprendizado pode melhorar a capacidade, mas a segurança tipicamente depende de monitores, filtros e comportamentos de contingência independentes.

Se você está construindo ou implantando robôs reais, trate recursos de segurança como arquitetura central — não como um complemento — especialmente ao integrar percepção aprendida ou políticas aprendidas na pilha Percepção → Planejamento → Controle.