ERP para drones: o plano de emergência do piloto remoto

O ERP - Emergency Response Plan, plano de resposta a emergências - é o documento que diz o que fazer depois de perdido o controlo de uma operação com drone: quem alertar, por que ordem e como limitar as consequências de uma queda, de uma colisão ou de uma fuga do aparelho.

⚠️ Fora da aviação, ERP significa normalmente enterprise resource planning, o planeamento de recursos empresariais. Na regulamentação de drones, ERP designa sempre o plano de emergência: é o termo usado pela EASA, pelo JARUS e pelas autoridades nacionais.

O que não é: um procedimento de emergência

É a confusão mais frequente, e a metodologia SORA esclarece-a de forma clara. Distingue três níveis de resposta:

• os procedimentos de contingência voltam a pôr sob controlo uma situação anormal, como uma bateria que enfraquece ou uma perda temporária de ligação;
• os procedimentos de emergência tratam da própria aeronave quando já está fora de controlo: terminação do voo, paraquedas, aterragem forçada;
• o ERP começa onde a aeronave já não importa. Trata os efeitos secundários de uma perda de controlo - uma pessoa ferida, um incêndio, uma aeronave atingida - e coordena a resposta com os serviços de emergência.

Dito de forma simples, um procedimento de emergência joga-se no radiocomando. O ERP joga-se ao telefone. O corpo principal da SORA 2.5 di-lo sem rodeios: o ERP não trata do controlo da UA.

O que deve conter

A SORA 2.5 coloca-o no objetivo de segurança operacional OSO #08 (os procedimentos operacionais estão definidos, validados e são cumpridos). O seu anexo E fixa um conteúdo mínimo:

1. a lista das situações de emergência previstas que podem ter efeitos secundários;
2. um procedimento para cada uma, incluindo os critérios que permitem reconhecer a situação;
3. a lista dos contactos relevantes: controlo de tráfego aéreo, polícia, bombeiros, primeiros socorros.

Acrescenta quatro qualidades esperadas. O ERP deve ser adequado à situação, mitigar eficazmente os efeitos secundários previstos, atribuir claramente as funções entre a tripulação e ser praticável e treinado, para poder ser executado sob stress.

O último ponto é o que se esquece. Um ERP que ninguém alguma vez percorreu só é plano no nome.

Proporcional ao risco, não à papelada

O anexo E precisa que o ERP deve ser proporcional aos possíveis efeitos secundários de um impacto no solo, como um incêndio ou uma libertação de gás tóxico. Um drone de 900 gramas sobre um campo e um multirrotor de 25 quilos sobre um local industrial não exigem o mesmo plano.

O nível de prova segue a mesma lógica. Nos níveis de garantia baixos, o operador declara que o seu ERP é adequado. No nível de garantia elevado espera-se um exercício de simulação em sala, e um terceiro competente valida que é representativo. O exercício pode envolver os terceiros indicados no plano, como os bombeiros ou o responsável do local.

O que mudou com a SORA 2.5

Nas versões anteriores da metodologia, o ERP contava como mitigação do risco no solo: dispor de um podia baixar a classe de risco. A SORA 2.5 retirou-o das mitigações e ligou-o, em vez disso, aos procedimentos operacionais.

A consequência prática: um ERP já não baixa o seu nível de exigência. Faz parte do que tem de demonstrar, seja qual for esse nível.

Um plano geral e uma ficha por local

Um ERP útil tem dois níveis.

O primeiro é geral. Vive no MANEX, o manual de operações: situações previstas, procedimentos, funções, cadeia de alerta. Muda pouco.

O segundo é próprio de cada trabalho. É ele que serve no terreno:

• as coordenadas exatas do local, para ditar aos serviços de emergência;
• o hospital e o quartel de bombeiros mais próximos, com os respetivos acessos;
• os contactos locais: cliente, responsável do local, órgão de controlo de tráfego aéreo;
• o ponto de encontro e o acesso para os veículos de emergência;
• os riscos próprios do lugar: produtos armazenados, linhas elétricas, público presente.

Um ERP genérico, copiado de um trabalho para o outro, falha precisamente aqui. No dia em que é preciso, ninguém tem tempo para procurar a morada do hospital.

Quando é exigido

Na categoria aberta não é exigido um ERP formal. Ter à mão os números úteis e a morada do local continua a ser uma boa prática.

Na categoria específica faz parte do processo: é esperado ao abrigo do OSO #08 numa avaliação SORA, e o manual de operações contém-no. É um dos documentos que a autoridade examina, porque mostra se o operador pensou no que vem depois.

O que reter

1. O ERP não é um procedimento de voo. Começa quando a aeronave já não importa.
2. Contém no mínimo as situações previstas, um procedimento para cada uma e os contactos a quem ligar.
3. É proporcional aos possíveis efeitos secundários, não à dimensão do processo.
4. Treina-se. Um plano nunca ensaiado não aguenta sob stress.
5. Declina-se por local. É a ficha de terreno que poupa tempo.

Para ir mais longe

• SORA para drones - a metodologia de avaliação de risco que exige o ERP na categoria específica.
• MANEX - o manual de operações que contém o ERP geral.
• JARUS - o agrupamento de autoridades que publica a SORA.