Gestão de projetos de automação: conduzir projetos de PLC, SCADA e sistemas de controlo da URS ao comissionamento

O que é a gestão de projetos de automação

A gestão de projetos de automação é a disciplina de planear, executar, coordenar e entregar projetos de automação industrial que instalam, configuram e integram sistemas de controlo (PLC, SCADA, DCS, sistemas de segurança) numa fábrica de produção ou numa instalação de processo. Situa-se no cruzamento entre a gestão de projetos de engenharia, a gestão de projetos de IT e a gestão de projetos de operações, bebe das três sem se reduzir a nenhuma, porque os projetos de automação têm traços próprios que as abordagens genéricas de gestão de projetos não cobrem por completo.

A definição e o lugar dos projetos de automação

Um projeto de automação começa quando uma organização de produção decide instalar nova tecnologia de controlo ou modernizar os sistemas de controlo existentes, e termina quando o sistema instalado funciona de forma segura e fiável em produção e satisfaz os requisitos operacionais definidos no início. O âmbito inclui em geral a seleção e o aprovisionamento do hardware, a configuração e a programação do software, a integração com os sistemas de fábrica existentes, os testes em várias etapas, a validação da segurança e da cibersegurança, a formação dos operadores e a entrega formal às operações. Os tipos de projeto frequentes são as instalações greenfield (fábrica nova, sem heranças), as modernizações brownfield (substituição de sistemas de controlo obsoletos numa fábrica em funcionamento), as ampliações de capacidade (novas linhas de produção dentro de uma arquitetura de automação existente) e as atualizações de sistemas de segurança (levar instalações existentes às normas em vigor como a IEC 61511 Edição 2).

Em que se distinguem dos projetos de produção habituais

Um projeto de automação não é um projeto de produção habitual, ainda que decorra dentro de uma empresa de produção. Quatro diferenças são decisivas. Primeira, o resultado é um sistema e não um produto: obtém-se uma arquitetura de automação em funcionamento, e não um único produto pronto a vender, de modo que os critérios de sucesso incidem sobre o desempenho operacional e não sobre as características de um produto. Segunda, o trabalho é multidisciplinar por natureza de um modo que os projetos de produção correntes não são: mecânica, elétrica, software de controlo, infraestrutura de IT e engenharia de processo têm de convergir para a mesma data de instalação, muitas vezes com empreiteiros diferentes responsáveis por disciplinas diferentes. Terceira, a ordem de validação é obrigatória e irreversível: FAT antes do SAT antes do comissionamento, sem atalhos possíveis, porque as dependências físicas impõem a sequência. Quarta, os requisitos de segurança e conformidade carregam muitas vezes um peso regulatório que os projetos de produção genéricos não enfrentam com a mesma intensidade, das normas de segurança funcional aos requisitos de cibersegurança e às regulamentações setoriais.

Em que se distinguem dos projetos de IT

Por vezes os projetos de automação são geridos por engano como projetos de IT, porque ambos incluem software. As diferenças são consideráveis. Os projetos de IT permitem em geral a entrega iterativa, o lançamento faseado a subconjuntos de utilizadores e as correções rápidas após o lançamento. Os projetos de automação são implementados numa instalação física onde o software comanda processos físicos com consequências reais: aplicar um patch a quente a um PLC num reator químico não é o mesmo tipo de alteração que aplicar um patch a uma aplicação web. Os projetos de IT podem ser colocados em pausa; as fábricas em funcionamento muitas vezes não. O fracasso de um projeto de IT provoca em geral perda de dados ou incómodo para o utilizador; o fracasso de um projeto de automação pode provocar incidentes de segurança, descargas ambientais ou incumprimentos regulatórios. É por isso que existe a disciplina FAT-SAT-comissionamento e é por isso que encurtá-la gera consequências dispendiosas que os gestores de projetos de IT podem não reconhecer no início.

As seis fases de um projeto de automação: da URS ao comissionamento

Os projetos de automação seguem uma estrutura consolidada de seis fases que se tornou padrão em todos os setores: química, farmacêutica, alimentar e bebidas, energia e produção geral. As fases são: especificação de requisitos do utilizador (URS), especificação de projeto funcional e detalhado (FDS, DDS), engenharia e construção, teste de aceitação em fábrica (FAT), instalação e teste de aceitação no local (SAT), e comissionamento. Cada fase tem entradas, saídas e critérios de gate definidos, e a disciplina de fazer cumprir os critérios de gate entre as fases separa os projetos de automação entregues a tempo daqueles que esgotam o orçamento em retrabalho tardio.

Fase 1: especificação de requisitos do utilizador (URS)

A URS define o que o sistema de automação deve alcançar do ponto de vista operacional: débito de produção pretendido, especificações de produto, filosofia de controlo, requisitos de segurança, restrições regulatórias, expectativas da interface de operador e pontos de integração com os sistemas de fábrica existentes e com o IT empresarial. Uma URS bem redigida, à semelhança de um termo de abertura do projeto, é funcional e não técnica: descreve o resultado desejado sem prescrever a solução técnica. A qualidade da URS é o melhor preditor isolado dos resultados de um projeto de automação, porque cada fase seguinte herda a ambiguidade ou a completude desse documento. Os projetos que saltam a URS ou a tratam como uma formalidade descobrem repetidamente, no SAT ou no comissionamento, que diferentes partes interessadas tinham pressupostos diferentes sobre funções básicas, e nessa altura o custo do alinhamento é ordens de grandeza superior ao que teria sido na fase de URS.

Fase 2: especificação de projeto funcional e detalhado (FDS, DDS)

A FDS traduz a URS num projeto funcional: que PLC, que SCADA, que topologia de rede, que malhas de regulação, que funções de segurança, que alarmes e como se ligam entre si e à infraestrutura de fábrica. A DDS desce depois ao nível de detalhe técnico necessário à engenharia e ao aprovisionamento: modelos de hardware precisos, contagens de E/S, esquemas de cablagem, disposição dos quadros, arquitetura de software, maquetas de ecrãs HMI. As fases FDS e DDS incluem revisões de projeto com o cliente, e a aprovação no final da DDS é o equivalente ao congelamento de projeto do projeto de automação. As alterações posteriores a este ponto exigem gestão formal de alterações e alongam em geral o cronograma.

Fase 3: engenharia e construção

A engenharia e a construção abrangem o aprovisionamento do hardware, a montagem dos quadros, o desenvolvimento de software (código de PLC, ecrãs SCADA, lógica de segurança, configuração do historian), a instalação da infraestrutura de rede e a montagem mecânica e elétrica no local. Esta fase decorre em paralelo entre várias disciplinas e fornecedores, e é aqui que a coordenação interdisciplinar consome a maior parte da atenção do gestor de projeto. Os componentes de longo prazo de entrega identificados durante a FDS (instrumentos especiais, controladores certificados de segurança, equipamentos de rede especializados) devem ter sido encomendados com antecedência suficiente para que a engenharia avance sem esperar pelo hardware. O desenvolvimento de software para PLC e SCADA faz-se em geral após a DDS, em paralelo com o aprovisionamento do hardware, para que ambos estejam prontos em conjunto para o FAT.

Fase 4: teste de aceitação em fábrica (FAT)

O FAT decorre nas instalações do fornecedor ou do integrador, antes do envio para o local. O sistema de controlo completo (hardware de PLC, software SCADA, sistemas de segurança) é montado e testado num ambiente controlado com entradas e saídas simuladas. O FAT valida que o hardware está conforme com a DDS, que o software implementa corretamente a lógica funcional, que os alarmes e os encravamentos se comportam como projetado, que os ecrãs HMI mostram a informação especificada e que a integração entre subsistemas funciona. O FAT é a última oportunidade rentável de detetar defeitos: as correções no FAT custam cerca de dez vezes menos do que as mesmas correções no SAT e cem vezes menos do que os defeitos detetados no comissionamento. Saltar ou encurtar o FAT é a causa isolada mais frequente de derrapagens dispendiosas na automação.

Fase 5: instalação e teste de aceitação no local (SAT)

Após a aprovação do FAT, o sistema é enviado para o local, instalado por empreiteiros mecânicos e elétricos, e passa o SAT. O SAT verifica que a instalação está conforme com os desenhos, que as E/S físicas estão corretamente ligadas a instrumentos e atuadores, que a integração com os sistemas de fábrica existentes funciona como projetado e que os testes funcionais de ponta a ponta passam nas condições reais de instalação. Para os projetos SCADA e de processo contínuo, o SAT inclui muitas vezes um ensaio prolongado de uma a duas semanas para demonstrar um funcionamento estável sem incidentes maiores. Quando vários subsistemas de fornecedores diferentes têm de ser testados em conjunto, após os SAT individuais realiza-se um teste de integração no local (SIT), introduzido formalmente na IEC 62381:2024, para demonstrar o funcionamento integrado.

Fase 6: comissionamento

No comissionamento, o sistema validado é transferido para a produção em funcionamento. O comissionamento a frio testa os sistemas sem material de processo ou com fluidos inócuos. O comissionamento a quente introduz gradualmente material de processo real, com afinação das malhas de regulação e das sequências e otimização para o desempenho pretendido. O comissionamento termina com a entrega formal às operações, que exige a formação completa dos operadores, a entrega da documentação (desenhos as-built, manuais de operação, instruções de manutenção), a disponibilidade de peças de reserva e o cumprimento dos critérios de aceitação acordados. Os períodos de apoio após o comissionamento (em geral de 30 a 90 dias) permitem ao integrador resolver os problemas que só surgem nas condições reais de produção.

A espinha dorsal da validação: FAT, SAT, SIT e comissionamento

As etapas de validação entre o fim da engenharia e o início da produção estável constituem a disciplina que define a gestão de projetos de automação. A sua ordem é obrigatória e não pode ser encurtada: o hardware e o software devem primeiro ser validados num ambiente controlado (FAT), depois verificados no ambiente instalado (SAT), depois integrados com os subsistemas vizinhos (SIT) e por fim demonstrados nas condições reais de processo (comissionamento). Cada etapa tem objetivos distintos, critérios de aceitação distintos e uma economia radicalmente diferente na deteção e correção de defeitos.

FAT: detetar os defeitos no ponto menos dispendioso

O teste de aceitação em fábrica decorre nas instalações do fornecedor, na presença do cliente ou de um inspetor independente. O sistema de controlo completo, ou um subconjunto funcionalmente completo, é montado na bancada de ensaio do fornecedor e testado contra um ambiente de fábrica simulado com simuladores de E/S, estimulação do HMI e guiões de teste funcional derivados da FDS. O âmbito típico do FAT cobre a verificação das E/S e a verificação de malhas (cada canal de entrada e saída funciona e está corretamente atribuído), os testes da lógica de controlo e das funções (encravamentos, permissivos, alarmes, sequências validados contra os P&ID e a especificação funcional), a inspeção do hardware e da cablagem (dimensões dos quadros, marcação dos condutores, ligação à terra, montagem dos componentes), as verificações de calibração e instrumentos e a validação de cibersegurança para os sistemas ligados em rede. Um FAT corretamente conduzido dura em geral de um a cinco dias nas instalações do fornecedor, consoante a complexidade do sistema. A razão económica de um FAT rigoroso é clara: corrigir um defeito em fábrica custa em geral ordens de grandeza menos do que no terreno, porque a correção em fábrica não afeta o cronograma da fábrica, não gera custos logísticos de local, não interrompe as operações nem exige remobilizar as equipas.

SAT: verificar a instalação real e a integração

O teste de aceitação no local decorre após a instalação nas instalações do cliente. Confirma que a instalação está conforme com os desenhos, que as E/S físicas estão corretamente ligadas a instrumentos e atuadores na fábrica real, que a integração com os sistemas de fábrica existentes (processos a montante e a jusante, interfaces MES, ERP) funciona como projetado e que os testes funcionais de ponta a ponta passam nas condições reais de instalação. O SAT revela muitas vezes problemas que o FAT não conseguiu captar: instrumentos mal cablados, configurações erradas dos dispositivos de campo, discrepâncias de integração com os sistemas legados, interferências eletromagnéticas de instalações vizinhas. Para as instalações SCADA e de processo contínuo, o SAT inclui em geral um ensaio de estabilidade prolongado de uma a duas semanas para demonstrar que o sistema funciona em contínuo sem incidentes maiores. A aprovação do SAT é o gate para o comissionamento.

SIT: integrar vários subsistemas

As instalações industriais modernas raramente assentam numa única plataforma de automação. Uma instalação de processo típica integra vários PLC, controladores DCS, sistemas de segurança, sistemas de deteção de incêndio e gás, unidades package, centros de comando de motores, variadores de frequência, analisadores, sistemas de proteção elétrica, historians, sistemas de gestão de ativos e postos de operador, muitas vezes de fornecedores diferentes. Cada subsistema pode passar o FAT e o SAT em separado, mas assim que os sistemas começam a trocar dados de processo reais surgem muitas vezes problemas de integração. O teste de integração no local (SIT), introduzido formalmente como etapa padrão na IEC 62381:2024, testa todos os subsistemas de automação a atuar em conjunto como uma única solução de controlo de processo. O SIT é a resposta adequada à complexidade multifornecedor que os FAT e SAT individuais não conseguem tratar.

Comissionamento: demonstrar a aptidão para produção

O comissionamento transfere o sistema validado para a produção em funcionamento. O comissionamento a frio verifica o sistema sem material de processo ou com simulantes inócuos: as bombas trabalham, as válvulas manobram, as sequências executam-se, os alarmes assinalam, mas nenhum produto está em risco. O comissionamento a quente introduz gradualmente material de processo real, afina as malhas de regulação (parâmetros PID, configurações em cascata, antecipação) e otimiza as sequências (receitas de lote, procedimentos de arranque e paragem) para o desempenho pretendido. O comissionamento é o momento em que se torna visível a qualidade acumulada da URS, da FDS, da engenharia, do FAT e do SAT: um projeto que fez bem as fases anteriores é comissionado em dias ou semanas, ao passo que um projeto que saltou ou encurtou fases anteriores pode passar meses no comissionamento a resolver problemas que deveriam ter sido detetados mais cedo.

Coordenação multidisciplinar nos projetos de automação

Os projetos de automação são multidisciplinares por natureza de um modo que os projetos de produção correntes não são, um domínio em que ajudam os princípios do lean management aplicado à gestão de projetos. Um projeto de automação de média dimensão típico envolve pelo menos cinco disciplinas de engenharia distintas a trabalhar em paralelo, muitas vezes de empresas diferentes, que têm todas de convergir para as mesmas datas de instalação e comissionamento. Coordenar as transferências entre estas disciplinas absorve a maior parte da atenção do gestor de projeto de automação, e reduzir o atrito nas transferências é a maior alavanca sobre a duração total do projeto.

Engenharia mecânica e construção

Os empreiteiros mecânicos instalam a infraestrutura física de que a automação depende: tubagens, válvulas, atuadores, suportes de motores, suportes de instrumentos, esteiras de cabos. O seu trabalho precede a instalação elétrica e de controlo, e os atrasos da construção mecânica propagam-se a cada disciplina a jusante. O âmbito mecânico inclui também o fornecimento do ar e da hidráulica de que os instrumentos e atuadores precisam, o que tem de ser coordenado com a seleção e instalação dos instrumentos para evitar discrepâncias no comissionamento.

Engenharia elétrica e instalação

Os empreiteiros elétricos instalam a distribuição de energia, os centros de comando de motores, o encaminhamento de cabos, a cablagem dos quadros e as ligações dos dispositivos de campo. A sua sequência segue a construção mecânica e precede o comissionamento do sistema de controlo. Os empreiteiros elétricos são em geral também responsáveis pelo esquema de ligação à terra e equipotencialização, decisivo tanto para a segurança (proteção elétrica) como para a fiabilidade do sistema de controlo (supressão de ruído nos cabos de sinal). A coordenação entre empreiteiros elétricos e integradores de sistemas de controlo em torno de listas de cabos, disposição dos quadros e listas de bornes é uma fonte de atrito permanente no projeto, em torno da qual os gestores de projeto de automação experientes planeiam.

Engenharia e integração do sistema de controlo

O integrador do sistema de controlo é responsável pela seleção e programação do hardware de PLC, pela configuração SCADA e pelo desenvolvimento dos ecrãs, pelo projeto e validação do sistema de segurança, pela arquitetura de rede e pela configuração do historian e dos relatórios. É a disciplina que entrega de forma mais direta a funcionalidade de automação que as operações irão usar. Os integradores de sistemas de controlo subcontratam muitas vezes elementos específicos (programação do sistema de segurança, avaliação de cibersegurança, projeto de rede) a empresas especializadas, o que acrescenta mais uma camada de coordenação que o gestor de projeto tem de gerir.

Engenharia de redes IT e OT

Os sistemas de automação modernos estão integrados em rede e exigem a sua própria infraestrutura de rede, separada do IT empresarial, com interfaces definidas onde se sobrepõem. A engenharia de redes IT/OT abrange a arquitetura da rede de controlo (em geral variantes de Ethernet industrial), a segmentação entre a zona de controlo e a empresarial, as medidas de cibersegurança conformes à IEC 62443, as políticas de acesso remoto e a integração com o historian de fábrica e os sistemas MES. Os engenheiros de IT/OT ficavam historicamente fora dos projetos de automação e eram envolvidos tarde, mas os projetos modernos beneficiam de os associar desde a URS, porque as decisões de rede influenciam o projeto físico dos quadros e o encaminhamento dos cabos.

Engenharia de processo e operações

Os engenheiros de processo fornecem a filosofia de controlo que o PLC e o SCADA implementam: que malhas precisam de que estratégia de regulação, que encravamentos protegem contra que modos de falha, que alarmes os operadores têm de ver. As operações contribuem com o conhecimento operacional que se torna o conteúdo da URS: como a fábrica funciona realmente, o que os operadores precisam nos seus ecrãs, que sequências exigem que opções, que informação ajuda no diagnóstico de avarias às três da manhã. Os projetos de automação que mantêm a engenharia de processo e as operações envolvidas desde a URS até ao comissionamento superam sistematicamente os projetos que as tratam como partes interessadas consultadas e não como participantes ativos do projeto.

Armadilhas frequentes nos projetos de automação

Cinco padrões de falha repetem-se de projeto de automação para projeto, seja qual for o setor, e cada um pode ser prevenido com contramedidas concretas. Dar nome aos padrões permite reconhecê-los mais cedo em projetos futuros, quando ainda podem ser intercetados por uma fração do custo de os resolver no comissionamento.

URS insuficientemente especificada levada para engenharia

O primeiro padrão é tratar a URS como uma formalidade inicial em vez de a base sobre a qual assenta todo o projeto. A URS é redigida à pressa para libertar a engenharia, as ambiguidades permanecem no documento com o pressuposto de que serão esclarecidas mais tarde, e a engenharia avança contra um conjunto de requisitos mal definido. As consequências surgem no SAT e no comissionamento: as operações descobrem que o sistema não faz algo que davam como garantido, ou faz algo que nunca quiseram, e a correção exige um reprojeto que uma URS sólida teria evitado. A contramedida é investir o tempo de calendário numa URS rigorosa com aprovação explícita das partes interessadas e critérios de aceitação definidos antes do início da engenharia, mesmo que pareça atrasar o projeto.

FAT encurtado ou saltado

O segundo padrão é tratar o FAT como um passo opcional que se pode encurtar quando o cronograma está sob pressão. O fornecedor concluiu o software e o hardware está montado, mas o cliente decide que o FAT é desnecessário porque o fornecedor testa bem internamente, ou que o FAT pode reduzir-se a uma demonstração em vez de um teste funcional completo. As consequências surgem no SAT e no comissionamento, onde cada defeito que o FAT teria intercetado custa agora dez a cem vezes mais a corrigir. A contramedida é tratar o FAT como inegociável independentemente da pressão de prazos e estruturar o âmbito do FAT de forma tão concreta que uma demonstração não possa passar por um teste.

Lacunas na coordenação multifornecedor sem SIT

O terceiro padrão é presumir que os FAT e SAT individuais dos fornecedores bastam quando vários subsistemas têm de trabalhar em conjunto. O sistema de cada fornecedor passa os seus próprios testes, mas as interfaces entre sistemas não foram validadas em conjunto, e os problemas de integração surgem durante o comissionamento, quando resolvê-los é mais dispendioso. A contramedida é planear um teste de integração no local explícito quando o projeto inclui vários subsistemas de fornecedores diferentes, e definir o âmbito do SIT já durante a URS, para que os fornecedores saibam que estão contratualmente obrigados a participar em testes integrados e não apenas a validar o próprio subsistema.

Atrasos das disciplinas vizinhas que transbordam para a automação

O quarto padrão é tratar a duração do projeto de automação como se fosse independente das outras disciplinas do local. A construção mecânica atrasa-se, a instalação elétrica atrasa-se, e a equipa de automação chega para começar o SAT apenas para descobrir que a fábrica não está pronta para a acolher. Os cronogramas da equipa de automação em geral não podem deslizar na mesma direção, porque as janelas de comissionamento estão ligadas a paragens de fábrica ou a janelas de arranque fixadas com muita antecedência. A contramedida é integrar explicitamente os cronogramas do projeto de automação com os cronogramas mecânico e elétrico, com marcos de prontidão de cada disciplina para as atividades de automação e com gatilhos de escalonamento quando uma disciplina desliza para além da margem.

Validação de segurança e cibersegurança adiada

O quinto padrão é tratar os testes de segurança funcional e a validação de cibersegurança como atividades cerimoniais do fim em vez de fluxos de trabalho contínuos ao longo de todo o projeto. As funções de segurança exigem validação contra a especificação de requisitos de segurança ao longo de todo o ciclo de vida, do projeto ao FAT e ao SAT até ao comissionamento, e a cibersegurança conforme à IEC 62443 exige do mesmo modo medidas em tempo de projeto em vez de uma auditoria no fim do projeto. A contramedida é definir fluxos de trabalho de segurança e cibersegurança com entregáveis explícitos por fase, dotá-los de recursos separados dos testes funcionais e tratar a aceitação de segurança e cibersegurança como gates próprios em vez de pontos de uma lista de aceitação geral.

Segurança e conformidade nos projetos de automação

Os projetos de automação operam dentro de quadros regulatórios e de normas que os projetos de produção genéricos raramente enfrentam com a mesma intensidade. A segurança funcional, a cibersegurança, as regulamentações setoriais e as normas industriais colocam todas requisitos que devem ser integrados na estrutura do projeto desde a URS, não acrescentados no comissionamento. Um incumprimento da conformidade na entrega é na melhor das hipóteses dispendioso e na pior bloqueia as operações, e a disciplina de integrar a conformidade no fluxo do projeto separa os gestores de projeto de automação que entregam a tempo daqueles que passam o último mês à procura de evidências para a auditoria.

Segurança funcional segundo a IEC 61511 e a IEC 61508

Os sistemas de segurança na indústria de processo seguem a IEC 61511 (com a IEC 61508 como norma de base). Os requisitos do ciclo de vida incluem a análise de perigos e riscos, a atribuição de funções de segurança a funções instrumentadas de segurança (SIF) com níveis de integridade de segurança (SIL), a especificação de requisitos de segurança, o projeto e a engenharia com verificação do SIL, a validação na instalação e no comissionamento e os procedimentos de operação e manutenção. A segurança não pode ser acrescentada no comissionamento; tem de estar presente em cada fase. Os projetos de automação que tratam a segurança como um fluxo de trabalho próprio desde a URS produzem evidências prontas para auditoria como resultado natural do projeto, ao passo que os projetos que tratam a segurança como uma atividade de aceitação final descobrem em geral tarde que lacunas de documentação ou problemas de projeto exigem retrabalho.

Cibersegurança segundo a IEC 62443

Os sistemas de automação e controlo industrial enfrentam ameaças de cibersegurança que os quadros de segurança de IT não cobrem por completo. A IEC 62443 define os requisitos de cibersegurança para a automação industrial, incluindo a segmentação de rede entre as zonas de IT e OT, o acesso remoto seguro, a gestão de patches dos sistemas de controlo, o registo de eventos de segurança e a gestão de vulnerabilidades. Os requisitos de cibersegurança devem ser definidos durante a URS e desdobrados na FDS, na DDS e na engenharia. Acrescentar a cibersegurança no comissionamento é dispendioso e raramente dá resultados satisfatórios, porque as decisões fundamentais de arquitetura já foram tomadas.

Regulamentações setoriais

Diferentes setores industriais acrescentam aos projetos de automação requisitos de conformidade específicos. Os projetos farmacêuticos e das ciências da vida seguem o Anexo 15 das GMP da UE, que reconhece expressamente o papel do FAT e do SAT na qualificação e exige evidência documentada da instrumentação crítica, da calibração e da verificação do processo. A FDA 21 CFR Part 11 aplica-se aos registos e assinaturas eletrónicos nas ciências da vida. Os projetos alimentares e de bebidas seguem os princípios HACCP com normas setoriais de projeto higiénico e rastreabilidade. Os projetos de energia e utilities seguem a NERC CIP para a cibersegurança da rede. Os projetos da indústria geral exigem a evidência da marcação CE e as normas ISO pertinentes de segurança, desempenho e especificações técnicas. Os requisitos do setor devem ser identificados durante a URS, e o cronograma do projeto deve contemplar as atividades de auditoria e documentação que impõem.

Gerir vários projetos de automação ao nível do portefólio

Uma empresa de engenharia que entrega projetos de automação, ou um fabricante com várias iniciativas de automação simultâneas, raramente tem um só projeto em curso. Mais tipicamente, o portefólio inclui vários projetos em fases diferentes que competem pelo mesmo talento de engenharia, pelos mesmos meios de ensaio, pela mesma capacidade de integração e pelas mesmas janelas de comissionamento. A vista de portefólio é o ponto em que a gestão de projetos de automação passa de disciplina de projeto a capacidade organizacional, e onde estão disponíveis os maiores ganhos de débito global.

O painel de portefólio dos projetos de automação

Um painel de portefólio de projetos de automação mostra todos os projetos ativos classificados por fase (URS, FDS, engenharia, FAT, SAT, comissionamento), com visibilidade sobre que projetos se aproximam das revisões de gate, quais estão bloqueados e quantos há em cada fase. O painel revela padrões que as vistas de projeto isolado escondem: estrangulamentos sistemáticos no planeamento do FAT com o mesmo integrador, janelas de comissionamento que se aglomeram em faixas estreitas do calendário, competição por recursos em competências especializadas como a programação de sistemas de segurança. O reconhecimento de padrões ao nível do portefólio alimenta a melhoria sistémica em vez do combate reativo a incêndios projeto a projeto.

Competição por recursos em competências especializadas

Os projetos de automação dependem de competências especializadas muitas vezes escassas: programadores de sistemas de segurança, especialistas de cibersegurança, arquitetos de rede, peritos em determinadas plataformas de PLC, engenheiros de comissionamento com experiência de setor. Os recursos partilhados tornam-se a maior fonte de atrasos não planeados num portefólio de vários projetos. A competição por recursos, invisível ao nível do projeto, torna-se visível ao nível do portefólio, onde o mesmo especialista a surgir em simultâneo em vários cronogramas de projeto expõe a dupla reserva que os gestores de projeto individuais não conseguem ver. Uma gestão de portefólio eficaz deteta cedo estes estrangulamentos e ou acrescenta capacidade, ou sequencia os projetos para reduzir a competição, ou aceita os atrasos como decisões de portefólio visíveis.

Padronização entre projetos

Os portefólios maduros de projetos de automação padronizam os elementos recorrentes: modelos de URS por tipo de projeto, estruturas de FDS, formatos de guiões de teste FAT, critérios de aceitação SAT, listas de verificação de comissionamento, modelos de documentação de segurança, procedimentos de avaliação de cibersegurança. A padronização evita reinventar os elementos de rotina em cada projeto e liberta a atenção de engenharia para as partes que verdadeiramente diferem. A padronização também possibilita a aprendizagem entre projetos: um padrão de defeito revelado no FAT de um projeto atualiza os modelos, para que os projetos seguintes intercetem mais cedo a mesma classe de defeitos. As empresas de engenharia com uma padronização madura entregam projetos mais depressa e com menor variabilidade do que as empresas em que cada projeto reinventa a sua própria abordagem.

Planeamento de capacidade e decisões de proposta ao nível do portefólio

A visibilidade ao nível do portefólio sobre a carga atual dos projetos e sobre a disponibilidade prevista de recursos apoia as decisões comerciais que as empresas de engenharia tomam continuamente: a que concursos concorrer, que datas de entrega se comprometer a cumprir, quando contratar, quando dizer não a certas oportunidades. As empresas sem dados de capacidade ao nível do portefólio em geral sobrecarregam-se nas fases otimistas e contêm-se nas prudentes, e a variabilidade de entrega resultante deteriora as relações com os clientes e a retenção do pessoal. As empresas com dados de portefólio podem tomar decisões de proposta a partir da capacidade de entrega real em vez do otimismo sobre quanto a equipa consegue absorver.

Caso de estudo A: Smart Automation, execução disciplinada do portefólio

A Smart Automation é uma empresa de engenharia de Olsztyn, na Polónia, ativa na automação industrial desde 2009. A empresa projeta e entrega sistemas de automação completos, de conceitos de máquina e análises de viabilidade à programação de sistemas de controlo e aos sistemas de visão artificial, passando pela automação robotizada de processos e pela construção de máquinas especializadas. A experiência da equipa soma mais de 300 anos em automação, robótica e mecatrónica. A empresa concluiu mais de 1000 projetos para clientes como IKEA, Michelin, Siemens Energy, Unilever e Danone, o que na prática significa várias dezenas de projetos simultâneos a qualquer momento, diferentes em âmbito, complexidade e localização.

O ponto de partida antes da adoção do FlexiProject era familiar às empresas de engenharia: os orçamentos eram geridos em soluções em torno do sistema ERP, porque é aí que residem as faturas, os pagamentos e os custos, mas cada gestor de projeto tinha desenvolvido uma abordagem pessoal ao controlo financeiro. As ferramentas de planeamento de cronograma, monitorização de riscos e planeamento de recursos faltavam no essencial. Não havia uma visão completa de um único projeto, muito menos de todo o portefólio. A empresa decidiu procurar um sistema de gestão de projetos dedicado que reunisse cronogramas, orçamentos, riscos e recursos num único lugar e se tornasse a fonte única de informação sobre os projetos.

A adoção abrangeu toda a organização. Em três meses, os 51 projetos ativos de complexidade variada foram transferidos para o FlexiProject. Hoje todos os colaboradores e os subcontratados-chave usam o sistema, 37 pessoas no total, o que se tornou praticável graças a um pool de licenças flexível. Mais importante ainda: a empresa entendeu a adoção como uma oportunidade para construir um padrão comum de gestão de projetos, e não apenas para substituir uma ferramenta. Agora cada projeto começa da mesma forma: com um termo de abertura que define objetivos, âmbito e responsabilidades, e com um modelo de fases que ordena o trabalho do conceito à entrega. Os cronogramas são criados a partir de um modelo comum com dependências de Gantt e marcos, e cada plano é guardado como linha de base: um ponto de referência aprovado face ao qual se medem os desvios de prazo e custo.

Os dados de orçamento tinham de manter-se coerentes com o sistema ERP, por isso o FlexiProject foi integrado com o ERP de modo que a informação de custo flui entre os sistemas sem duplo registo. Para além dos projetos, a estrutura flexível permitiu refletir o processo de proposta e o serviço de garantia e pós-garantia. Dois fatores impulsionaram a adoção. Primeiro, o diretor-geral atuou como patrocinador ativo do projeto, exigindo de forma constante que toda a informação de projeto vivesse num único sistema e esperando atualizações regulares de cada gestor de projeto. Segundo, a barreira de entrada era baixa: construir cronogramas e orçamentos era suficientemente intuitivo para que qualquer gestor de projeto, seja qual for a experiência, pudesse começar a formação inserindo um projeto real próprio em vez de praticar com exemplos artificiais. Os resultados veem-se nas decisões: desvios de orçamento com previsão até à conclusão, utilização de recursos como entrada para as decisões de proposta e os planos de contratação, revisões de projeto de duas em duas semanas para os projetos ativos e mensais para os projetos em fase de planeamento, tudo a partir dos dados do sistema em vez de apresentações elaboradas à mão.

Caso de estudo B: a crise de automação do Model 3 da Tesla, 2017-2018

O aumento de produção do Model 3 da Tesla entre 2017 e 2018 é um dos fracassos de projeto de automação mais bem documentados publicamente da história industrial, invulgar pela disposição de Elon Musk para o admitir com as suas próprias palavras. O Model 3 foi anunciado em 2016 como o primeiro veículo de mercado de massa da Tesla, a um preço-alvo de 35 000 USD, e nas 24 horas seguintes ao lançamento 115 000 pessoas tinham feito reservas. A Tesla fixou o objetivo ambicioso de produzir 5000 Model 3 por semana até ao fim de 2017 e seguiu uma abordagem que Musk viria a descrever como «automatizar tudo», apostando que uma automação extensa permitiria o volume necessário para escoar a acumulação de pré-encomendas.

O resultado foi aquilo a que o próprio Musk chamou «o inferno da produção». A Tesla falhou por larga margem o objetivo do fim de 2017 e produziu 2425 Model 3 em todo o quarto trimestre de 2017 (face a um objetivo de 5000 por semana). O objetivo revisto para o fim do primeiro trimestre de 2018, de 2500 por semana, também foi falhado, com a Tesla a atingir 2020 na última semana do primeiro trimestre. Tanto a montagem dos módulos de bateria na Gigafactory como a linha de montagem final em Fremont tinham projetos de automação que se revelaram pouco fiáveis ao volume de produção. Os analistas da Bernstein defenderam publicamente que a sobreautomação gravou os erros da Tesla na linha de produção e custou mais do que rendeu. A 13 de abril de 2018, Musk admitiu publicamente no Twitter: «Sim, o excesso de automação na Tesla foi um erro. Para ser preciso, um erro meu. Os humanos estão subvalorizados.» Numa entrevista à CBS descreveu o desmantelamento de uma «rede louca e complexa de tapetes transportadores» que não funcionava, e a Tesla acabou por devolver partes da linha de montagem à operação manual, incluindo a conhecida linha de montagem provisória em «tenda» em Fremont, que acrescentou capacidade com trabalho manual em vez de mais automação.

Três lições transferem-se diretamente para qualquer projeto de automação. Primeira, a ambição de automatizar sem validação-piloto multiplica o risco em vez de o reduzir: a decisão da Tesla de implementar nova automação à escala de produção antes de a validar a volume-piloto multiplicou a dificuldade de cada ciclo posterior de resolução de problemas, ao passo que um aumento gradual teria revelado os problemas de automação a menor custo. Segunda, sobreautomatizar passos de submontagem que exigem adaptabilidade produz piores resultados do que as alternativas semiautomatizadas em que as pessoas assumem a variação e as máquinas o trabalho repetível: é um princípio conhecido da prática de produção japonesa que a Tesla, na prática, redescobriu sob a pressão da produção. Terceira, os compromissos de cronograma de projeto que dão como garantido que a tecnologia funcionará como previsto, sem margem suficiente para revelar os problemas de automação, geram uma pressão que torna a resolução disciplinada de problemas mais difícil em vez de mais fácil. A Tesla acabou por atingir o objetivo de 5000 por semana até ao fim de junho de 2018 e mais do que duplicou a produção total de 2017, mas o preço de o ter conseguido através de uma crise em vez de um aumento gradual disciplinado foi considerável.

Como o FlexiProject apoia os projetos de automação

O FlexiProject apoia o nível de execução da gestão de projetos de automação com a visibilidade de portefólio, a gestão de cronograma, a monitorização de riscos, as revisões estruturadas e os modelos padronizados. A coordenação multidisciplinar dos projetos de automação, em particular o trabalho de harmonizar as funções de mecânica, elétrica, controlo, IT/OT e engenharia de processo, continua a ser responsabilidade da organização. O FlexiProject fornece a infraestrutura operacional que torna gerível a execução disciplinada de projetos de automação em grande escala, não um substituto da colaboração de engenharia de que depende o sucesso de um projeto de automação.

Vista de portefólio para projetos de automação simultâneos

O FlexiProject oferece um painel de portefólio que mostra todos os projetos de automação ativos numa única vista, classificados por fase (URS, FDS, engenharia, FAT, SAT, comissionamento) e por cliente ou unidade de negócio, com visibilidade sobre que projetos se aproximam das revisões de gate e quais estão bloqueados. A vista de portefólio traz à luz padrões que as vistas de projeto isolado escondem, como janelas de comissionamento que se aglomeram em faixas estreitas do calendário, competição por recursos em competências especializadas e atrasos sistemáticos no planeamento do FAT com determinados integradores. Os comités de direção que tomam decisões ao nível do portefólio trabalham a partir da mesma vista de portefólio, em vez de reconciliar relatórios de projeto distintos.

Cronograma com diagrama de Gantt, lista de tarefas e kanban

O cronograma no FlexiProject combina uma vista de diagrama de Gantt para o acompanhamento dos marcos e a visualização das dependências, uma vista de lista de tarefas para o trabalho de execução detalhado e uma vista kanban para a disciplina de fluxo dentro das fases. Os projetos de automação beneficiam da combinação: o diagrama de Gantt gere a estrutura ao nível das fases com as dependências da URS ao comissionamento e os marcos de revisão de gate, as listas de tarefas gerem o trabalho detalhado de engenharia e teste dentro das fases, e o kanban acompanha o fluxo dos entregáveis concretos pela revisão e aprovação. Os ícones de aviso nas tarefas do cronograma assinalam problemas de orçamento ou de risco sem exigir relatórios separados.

Registo de riscos, ligado às fases do projeto

O registo de riscos no FlexiProject acompanha os riscos próprios da automação com responsáveis, planos de mitigação e ritmo de revisão. Os riscos próprios de cada fase (disponibilidade de componentes de longo prazo de entrega durante a engenharia, prontidão do fornecedor para o FAT, prontidão do local para o SAT, disponibilidade da fábrica para o comissionamento, validação do sistema de segurança, avaliação de cibersegurança) estão ligados aos marcos de fase pertinentes e revistos no gate correspondente. A ligação entre riscos, tarefas e cronograma faz com que um risco que se materializa se repercuta visivelmente no prazo associado, em vez de ficar num registo à parte que ninguém consulta no momento das decisões de prazo.

Revisões de projeto como revisões de gate

As revisões de projeto no FlexiProject podem ser estruturadas como revisões de gate formais dos projetos de automação, com critérios definidos, apresentação estruturada de evidências e decisões formais de prosseguir ou não prosseguir registadas na ata do projeto. O ritmo de revisão é planeado (em geral no fim de cada fase de projeto e em cada transição FAT/SAT/comissionamento), e os resultados das revisões alimentam os modelos padronizados dos projetos seguintes. Os critérios de gate configurados nos modelos aplicam-se de forma coerente entre projetos do mesmo tipo, para que o gate de aprovação do FAT de um projeto use a mesma estrutura de critérios do gate de aprovação do FAT de outro.

Modelos padronizados para os projetos de automação

O FlexiProject oferece modelos padronizados para a estrutura recorrente dos projetos de automação, com o modelo de seis fases, a espinha dorsal de validação FAT-SAT-comissionamento, os entregáveis padrão por fase e critérios de gate padrão adequados à automação. As empresas de engenharia podem estender os modelos consoante as particularidades do tipo de projeto (greenfield, modernização brownfield, ampliação de capacidade, atualização de segurança) sem abdicar da estrutura de base. A gestão de projetos de automação baseada em modelos atua como o equivalente digital da prática de engenharia padronizada: evita reinventar os elementos de rotina do projeto e liberta a atenção de engenharia para as partes de cada projeto que verdadeiramente diferem.

O que o FlexiProject não faz

O FlexiProject não executa a engenharia (é o trabalho do integrador do sistema de controlo), não executa nem o FAT nem o SAT (exigem bancadas de ensaio e instrumentação), não qualifica fornecedores (exige processos de compras e qualidade) e não substitui a disciplina de fazer cumprir os critérios de gate (exige o empenho da direção). Fornece a visibilidade, a estrutura e a rastreabilidade que tornam gerível a execução disciplinada de projetos de automação num portefólio, mas a disciplina em si é organizacional.

Perguntas frequentes

Em que difere a gestão de projetos de automação da gestão de projetos geral?

Os princípios gerais de gestão de projetos aplicam-se aos projetos de automação, mas estes têm traços próprios que as abordagens gerais não cobrem por completo: uma espinha dorsal de validação sequencial e obrigatória (FAT antes do SAT antes do comissionamento), uma complexidade multidisciplinar inerente que abrange mecânica, elétrica, software de controlo, IT/OT e engenharia de processo, requisitos de segurança e conformidade com peso regulatório, e dependência de vários fornecedores externos cujos atrasos se propagam de forma imprevisível. Os gestores de projeto de automação têm em geral formação de engenharia e experiência específica de setor, porque o conteúdo técnico das decisões influencia os resultados do projeto a um nível que a gestão de projetos geral não consegue substituir.

Quanto dura um projeto de automação típico?

Depende do âmbito, da complexidade e do setor. Uma instalação greenfield simples com integração limitada pode concluir-se em seis a nove meses. Uma modernização brownfield típica com integração nos sistemas de fábrica existentes dura em geral de doze a dezoito meses. Os grandes projetos de investimento com tecnologia inédita ou elementos críticos de segurança podem durar de dois a três anos. O maior fator isolado de cronograma muitas vezes não é a complexidade de engenharia mas a complexidade de coordenação: os projetos com muitos fornecedores e disciplinas duram mais do que os projetos com menos participantes, mesmo que o trabalho técnico seja semelhante.

De quem é o projeto de automação?

Um gestor de projeto de automação é responsável pelo cronograma, pela coordenação, pelas revisões de gate e pelo alinhamento entre disciplinas, mas o trabalho é multidisciplinar por natureza e nenhuma função o controla sozinha. Os empreiteiros mecânicos são responsáveis pela infraestrutura física, os elétricos pela alimentação e cablagem, o integrador do sistema de controlo pela entrega do PLC e do SCADA, os engenheiros de IT/OT pela infraestrutura de rede, os engenheiros de processo pela filosofia de controlo, e as operações pelos requisitos que o sistema deve satisfazer. O gestor de projeto de automação é o coordenador e integrador entre estas funções. O apoio da direção de topo é indispensável, porque as decisões de gate têm implicações comerciais e de segurança que excedem a autoridade do gestor de projeto.

Qual é a diferença entre FAT e SAT?

O FAT (teste de aceitação em fábrica) decorre nas instalações do fornecedor ou do integrador antes do envio para o local, com entradas e saídas simuladas, para validar o hardware e o software num ambiente controlado. O SAT (teste de aceitação no local) decorre após a instalação nas instalações do cliente e verifica que a instalação está conforme com os desenhos, que as E/S físicas estão corretamente ligadas a instrumentos e atuadores reais e que a integração com os sistemas de fábrica existentes funciona. O FAT interceta os defeitos no ponto menos dispendioso do ciclo de vida; o SAT interceta os problemas que só surgem no ambiente real de instalação. Nenhum pode substituir o outro, e em geral ambos são necessários.

O FAT e o SAT são obrigatórios por lei?

Depende do setor. Os projetos farmacêuticos e das ciências da vida exigem o FAT e o SAT na prática segundo o Anexo 15 das GMP da UE, que reconhece expressamente o seu papel na qualificação. Para as instalações da indústria geral, a marcação CE e as normas ISO pertinentes exigem a evidência de que a instalação satisfaz as especificações de segurança, desempenho e técnicas, e o FAT e o SAT são os mecanismos padrão para fornecer essa evidência. Mesmo onde não são estritamente obrigatórios por lei, o FAT e o SAT são prática corrente na maioria dos setores industriais, porque a razão económica de intercetar os defeitos no ponto mais precoce possível está bem documentada.

Os projetos de automação podem seguir métodos ágeis?

Os projetos de automação têm dependências físicas que limitam a aplicabilidade dos métodos puramente ágeis: o hardware precisa de prazo de aprovisionamento, o comissionamento exige janelas de disponibilidade da fábrica, a validação de segurança segue sequências regulatórias que não podem ser iteradas. Elementos do pensamento ágil ajustam-se bem, em especial o refinamento iterativo da URS com as partes interessadas antes do congelamento de projeto e a depuração iterativa durante o FAT e o comissionamento. Mas a estrutura de fases da URS ao comissionamento é uma espinha dorsal em cascata, porque as restrições físicas e regulatórias a impõem, e as tentativas de aplicar métodos puramente ágeis aos projetos de automação dão em geral piores resultados do que a abordagem disciplinada de fases e gates.

A gestão de projetos de automação é a disciplina de entregar projetos de automação industrial desde a especificação de requisitos do utilizador, passando por engenharia, FAT, SAT e comissionamento, até à produção estável, distinta da gestão de projetos de produção genérica pela sua espinha dorsal de validação sequencial e obrigatória, pela sua complexidade multidisciplinar inerente, pela intensidade da segurança e da conformidade e pela dependência da coordenação de vários fornecedores. A estrutura de seis fases da URS ao comissionamento fornece o quadro, e a espinha dorsal de validação FAT-SAT-SIT-comissionamento fornece a disciplina que a define, com os defeitos detetados no FAT a custar uma ordem de grandeza menos do que no SAT e duas ordens de grandeza menos do que durante o comissionamento. A coordenação multidisciplinar entre as funções de mecânica, elétrica, controlo, IT/OT e engenharia de processo absorve a maior parte da atenção do gestor de projeto, e reduzir o atrito nas transferências é a maior alavanca isolada sobre a duração total do projeto. Cinco padrões de falha (URS insuficientemente especificada, FAT encurtado, lacunas na coordenação multifornecedor sem SIT, atrasos das disciplinas vizinhas que transbordam, e segurança e cibersegurança adiadas) podem ser prevenidos com contramedidas nomeadas. Os requisitos de segurança e conformidade, incluindo a IEC 61511, a IEC 62443 e as regulamentações setoriais, devem ser integrados no fluxo do projeto desde a URS. A visibilidade ao nível do portefólio sobre os projetos de automação simultâneos possibilita as decisões de recursos, padronização e capacidade que as empresas de engenharia tomam continuamente. O caso Smart Automation mostra que uma empresa de engenharia de média dimensão pode construir em meses um padrão de projeto disciplinado em torno de um sistema comum, ao passo que o caso do Model 3 da Tesla mostra que a ambição de automatizar sem validação-piloto nem execução disciplinada de fases e gates gera «o inferno da produção» à maior escala possível. O FlexiProject apoia o nível de execução da gestão de projetos de automação com a visibilidade de portefólio, a gestão de cronograma que combina as vistas de diagrama de Gantt, lista de tarefas e kanban, um registo de riscos ligado às fases, revisões estruturadas como revisões de gate e modelos de projeto padronizados. A coordenação multidisciplinar de engenharia e o cumprimento disciplinado dos critérios de gate continuam a ser responsabilidades organizacionais. Quando o portefólio de projetos de automação de uma empresa de engenharia ultrapassou as folhas de cálculo e precisa de um sistema que sustente a disciplina entre vários projetos simultâneos e equipas multidisciplinares, trinta dias de acesso completo sem cartão de crédito são uma forma prática de verificar se é adequado.