Prototipagem de IHM com UX/UI e ISA101: PLC Do Rascunho ao Software 37

No artigo anterior (36), exploramos os princípios de UX/UI e da norma ISA-101 aplicados à prototipagem de IHM para o Magazine de Paletes. Agora chegou o momento de dar o próximo passo: montar toda a documentação necessária para que os nossos protótipos saiam do rascunho e se tornem referência real de desenvolvimento.

Documentar antes de prototipar pode parecer contra-intuitivo para quem está acostumado a partir direto para o software de IHM. Mas assim como não começamos a escrever o código do CLP sem antes ter o fluxograma de máquina e a lista de I/O, também não devemos abrir o Figma ou o WinCC sem um conjunto mínimo de documentação que guie nossas decisões de design.

Vamos apresentar agora a documentação que compõem o “kit de entrada” para prototipagem de IHM: o que é cada um, por que existe, como preencher e onde ele se encaixa no fluxo da nossa série com o Magazine de Paletes.

1. Por Que a documentação Precede o Protótipo

Engenheiros de automação raramente têm formação formal em UX, isso é um fato e uma realidade de mercado, uma fez que a graduação na área não apresenta esse tipo de conceito. O resultado prático é que a maioria das IHMs industriais ainda é projetada de forma intuitiva, baseada na experiência pessoal do desenvolvedor, sem um processo estruturado. Funciona? Muitas vezes sim. Mas esse modelo tem um custo alto:

•       Refatorações frequentes durante o comissionamento, quando mudar é caro e demorado.

•       Interfaces inconsistentes entre telas, porque cada parte foi desenvolvida em momentos diferentes.

•       Dificuldade de validação com o cliente ou com os operadores, pois não existe uma referência formal do que foi acordado.

•       Retrabalho de programação quando o layout precisa mudar e as variáveis já estavam amarradas à posição de tela.

A documentação prévia resolve esses problemas ao criar um contrato informal entre todos os envolvidos: o que a IHM deve fazer, como deve parecer, quem vai usá-la e quais regras ela precisa seguir. Com isso em mãos, o protótipo deixa de ser um exercício criativo e passa a ser a validação de decisões já tomadas.

Regra prática : Se você não consegue explicar em um documento por que um elemento está em determinada posição da tela, provavelmente ele não deveria estar lá.

2. Os Cinco Documentos do Kit de Entrada

Com base nas práticas da ISA-101, nos princípios de UX industrial e na dinâmica prática de projetos de automação, definimos cinco documentos que formam o kit mínimo para iniciar a prototipagem com qualidade:

#	Documento	Propósito Principal	Fidelidade
1	Perfil de Usuário (Persona)	Quem vai usar a IHM	Conceitual
2	Mapa de Navegação de Telas	Como as telas se conectam	Estrutural
3	Guia de Estilo ISA-101	Como a IHM deve parecer	Visual
4	Especificação de Tela (Screen Spec)	O que cada tela contém	Detalhada
5	Lista de Variáveis de IHM	O que a IHM precisa do CLP	Técnica

Nenhum desses documentos precisa ser um relatório de 50 páginas. Para projetos de pequeno e médio porte, como o Magazine de Paletes, cada um pode ser uma página ou uma planilha simples. O que importa é que exista e que tenha sido validado antes de abrir a ferramenta de prototipagem.

3. Documento 1: Perfil de Usuário (Persona)

A Persona é uma representação semifictícia do usuário real da IHM. Não é um questionário de RH nem um currículo vitae — é um retrato funcional que guia decisões de design. A ISA-101 trata isso como “Design Centrado no Operador” e é o primeiro princípio da norma por uma razão: não é possível projetar uma boa interface sem saber para quem ela está sendo feita.

3.1 Estrutura do Documento de Persona

Informações Básicas

Campo	Conteúdo para o Magazine de Paletes
Nome (ficticio)	Carlos Mendes
Cargo	Operador de Linha — Setor de Logística Interna
Idade média	35–45 anos
Escolaridade	Técnico em Mecânica ou Eletrotécnica
Experiência com IHM	5–10 anos operando equipamentos similares
Turno	Trabalha em turnos rotativos (manha/tarde/noite)

Objetivos e Tarefas Principais

•       Monitorar o estado geral do magazine (paletes presentes, posições, movimentação).

•       Acionar movimentos manuais em caso de falha ou setup.

•       Identificar rapidamente qual sensor ou atuador causou uma parada.

•       Verificar o histórico de falhas para reportar ao supervisor.

Frustrações com IHMs Existentes

•       Telas com muita informação ao mesmo tempo, difíceis de ler.

•       Botões muito pequenos para operação por touchscreen industrial.

•       Mensagens de falha genéricas sem indicação clara de onde está o problema.

•       Navegação confusa entre telas, especialmente em situações de alarme.

Cenário de Uso Crítico

O magazine para no meio do ciclo. Carlos precisa identificar em menos de 2 minutos qual sensor disparou a parada, acionar o reset ou o movimento manual necessário, e retornar a linha ao modo automático. Cada minuto parado representa impacto direto na produção.

Este cenário crítico define os requisitos não-funcionais mais importantes da IHM: velocidade de leitura, clareza dos alarmes, acesso rápido às telas de movimentos manuais e ao reset. Tudo que não contribui para esse fluxo é ruído.

4. Documento 2: Mapa de Navegação de Telas

O Mapa de Navegação é o equivalente ao fluxograma de máquina da IHM. Ele define quais telas existem, como elas se relacionam e quais são os pontos de entrada e saída de cada uma. A ISA-101 recomenda que a navegação seja hierárquica e intuitiva — o mapa é a prova visual de que isso foi planejado.

4.1 Hierarquia de Telas do Magazine de Paletes

Com base nos requisitos definidos na série, a estrutura hierárquica de telas é:

Nível	Tela	Acesso	Descrição
Nível 1	Sinótico Geral	Tela principal / startup	Visão geral do processo. Sempre visível.
Nível 2	Movimentos Manuais	Botão no rodapé do sinótico	Acionamentos individuais dos atuadores.
Nível 2	Falhas Ativas	Botão no rodapé ou banner de alarme	Lista de alarmes ativos com prioridade.
Nível 2	Histórico de Falhas	Botão no rodapé ou da tela de Falhas	Registro de eventos passados com filtro.
Nível 3	Detalhe de Falha	Clique em item da lista de Falhas Ativas	Descrição detalhada + guia de solução.
Nível 3	Parâmetros	Acesso restrito por senha	Tempos, limites e configurações operacionais.

4.2 Regras de Navegação

•       O Sinótico Geral é sempre acessível a partir de qualquer tela (botão fixo no cabeçalho ou rodapé).

•       A tela de Falhas Ativas deve ser acessível diretamente pelo banner de alarme que aparece no cabeçalho.

•       Nenhuma tela deve exigir mais de 3 toques a partir do Sinótico para ser acessada.

•       Telas de acesso restrito (Parâmetros) devem ter indicador visual claro de nível de acesso.

Dica de prototipagem: O Mapa de Navegação pode ser feito em qualquer ferramenta de diagramas (Figma, Draw.io, PowerPoint). O importante é que ele seja validado com o operador ou supervisor antes de começar os wireframes. Uma navegação mal planejada é a causa mais comum de refatoração em projetos de IHM.

5. Documento 3: Guia de Estilo ISA-101

O Guia de Estilo é o manual visual da IHM. Ele centraliza as decisões de design que precisam ser consistentes em todas as telas: paleta de cores, tipografia, tamanhos de elementos, comportamento dos estados visuais e símbolos utilizados. Sem um guia de estilo, cada tela tende a ter decisões ligeiramente diferentes, criando inconsistência que aumenta a carga cognitiva do operador.

5.1 Paleta de Cores ISA-101 para o Magazine de Paletes

Estado	Cor	Uso Correto	Uso Incorreto
Fundo padrão	Cinza médio (C0C0C0)	Fundo de todas as telas	Nunca como cor de destaque
Normal / OK	Cinza escuro (404040)	Equipamento em operação normal	Não usar verde para normal
Atenção	Amarelo puro (FFFF00)	Warnings, alertas não críticos	Não usar para informação
Alarme crítico	Vermelho puro (FF0000)	Falhas críticas, segurança	Não usar para navegação
Informação op.	Azul (0000FF)	Dados operacionais, status	Não usar para alarmes
Segurança / ESD	Magenta (FF00FF)	Funções de segurança exclusivamente	Não usar para outros fins
Texto padrão	Preto (000000)	Todo texto sobre fundo cinza	Não usar texto colorido para legibilidade

Atenção ISA-101: Verde não é a cor para “estado normal” nessa norma. O cinza escuro representa equipamento em operação normal. Verde é aceito com moderacão, mas reservar vermelho, amarelo e magenta para estados específicos é prioritário.

5.2 Tipografia

Elemento	Fonte	Tamanho mínimo	Peso
Título de tela	Arial / sans-serif	14pt	Bold
Label de tag/equipamento	Arial / sans-serif	10pt	Regular
Valor numérico	Arial / monospace	12pt	Bold
Mensagem de alarme	Arial / sans-serif	11pt	Bold
Botão / ação	Arial / sans-serif	10pt	Bold
Legenda / rodapé	Arial / sans-serif	8pt	Regular

5.3 Tamanhos Mínimos de Elementos Táteis

Para operação em touchscreen industrial, especialmente com luvas, a ISA-101 e as diretrizes de acessibilidade recomendam áreas de toque maiores do que em aplicações consumer:

•       Botões de ação: mínimo 44px x 44px (ideal: 60px x 60px).

•       Botões de navegação: mínimo 50px x 50px.

•       Botões de confirmação de ações críticas (ex: Reset): mínimo 80px x 60px, com confirmação em dois passos.

•       Espaçamento mínimo entre elementos clícaveis: 8px.

5.4 Símbolos e Ícones

Definir um conjunto padrão de símbolos antes de prototipar evita inconsistência. Para o Magazine de Paletes, os símbolos essenciais são:

Elemento	Representação Visual	Comportamento de Estado
Cilindro pneumático	Retângulo com seta de extensão	Cinza=recolhido, Azul=extendido, Amarelo=movendo
Sensor (presencça)	Círculo sólido	Cinza=inativo, Azul=ativo/detectando
Motor	Círculo com M	Cinza=parado, Verde escuro=rodando, Vermelho=falha
Palete presente	Retângulo cheio	Amarelo claro=presente, Vazio=ausênte
Indicação de alarme	Triângulo exclamacão	Vermelho piscante=ativo, Cinza=reconhecido

6. Documento 4: Especificação de Tela (Screen Spec)

A Especificação de Tela é o documento mais detalhado do kit. Para cada tela da IHM, ele descreve textualmente (e opcionalmente com um wireframe de baixa fidelidade) todos os elementos presentes, seu comportamento, as variáveis associadas e as ações possíveis. É o equivalente ao seu Documento de Requisitos completo, sem ele, o desenvolvedor toma decisões improvisadas durante a implementação.

6.1 Template de Especificação de Tela

Identificação

Campo	Exemplo — Tela de Sinótico Geral
ID da Tela	SCR-001
Nome	Sinótico Geral do Magazine de Paletes
Nível hierárquico	Nível 1 (Tela Principal)
Resolução alvo	1024 x 768 px (IHM Siemens TP1200 Comfort)
Usuários autorizados	Todos os níveis de acesso
Data / Versão	v1.0 — [data de criação]

Layout Geral

O layout da tela SCR-001 é dividido em três áreas fixas:

•       Cabeçalho (altura: 80px): Nome da máquina, indicadores de modo (Auto/Manual), status de segurança e banner de última falha com link direto à tela SCR-003.

•       Area central (altura: 608px): Representação gráfica animada do magazine. Cilindros, sensores e posições de paletes são renderizados seguindo a paleta de cores do Guia de Estilo.

•       Rodapé (altura: 80px): Quatro botões de navegação: [Automático], [Movimentos Manuais], [Falhas Ativas], [Histórico].

Elementos e Comportamentos

Elemento	Tipo	Variável CLP	Comportamento
Indicador Segurança OK	Luz piloto	DB_Safety.Safety_OK	Verde escuro=OK, Vermelho piscante=falha
Indicador Modo Auto	Luz piloto	DB_Mode.Auto_Mode	Azul=auto ativo, Cinza=inativo
Indicador Modo Manual	Luz piloto	DB_Mode.Manual_Mode	Amarelo=manual ativo, Cinza=inativo
Banner de última falha	Display de texto	DB_Alarm.Last_Alarm_Txt	Exibe texto da última falha. Clicavel para SCR-003
Cilindro avancador A1	Gráfico animado	DB_Cyl.A1_Extended	Estado visual conforme guia de símbolos
Sensor pos. palete P1	Luz piloto circular	DB_Sen.Palet_Pos1	Azul=detectando, Cinza=livre
Botão Mov. Manuais	Botão navegação	—	Navega para SCR-002
Botão Falhas Ativas	Botão navegação	—	Navega para SCR-003

Nota de rastreabilidade: Cada variável listada na Spec de Tela deve corresponder exatamente ao mesmo nome usado na Lista de Variáveis de IHM (Documento 5) e no mapeamento de tags do CLP. Isso evita o problema clássico de a IHM ter um nome para a variável e o CLP ter outro.

7. Documento 5: Lista de Variáveis de IHM

A Lista de Variáveis de IHM é o elo entre o projeto de IHM e o projeto do CLP. Ela lista todas as variáveis que precisam ser expostas pelo CLP para que a IHM funcione, incluindo tipo de dado, endereço, acesso (leitura/escrita) e em qual tela são usadas.

No contexto da nossa série, esse documento se conecta diretamente com as estruturas de dados que construímos nos episódios anteriores. A IHM não deveria acessar variáveis internas ou temporárias do CLP diretamente — ela deve consumir apenas variáveis organizadas e intencionalmente expostas para a finalidade de conectar a IHM, por exemplo: variáveis da UDT, UDT_ModosDeOpIHM.

7.1 Estrutura da Lista de Variáveis

Abaixo um exemplo genérico de uma lista de variáveis.

Tag IHM	Endereço CLP	Tipo	Acesso	Tela(s) de Uso	Descrição
Safety_OK	DB_Safety.Safety_OK	Bool	R	SCR-001	Circuito de segurança OK
Auto_Mode	DB_Mode.Auto_Mode	Bool	R	SCR-001	Magazine em modo automático
Manual_Mode	DB_Mode.Manual_Mode	Bool	R	SCR-001	Magazine em modo manual
Last_Alarm_Txt	DB_Alarm.Last_Alarm_Txt	String[80]	R	SCR-001	Texto último alarme ativo
A1_Extended	DB_Cyl.A1_Extended	Bool	R	SCR-001, SCR-002	Cil A1 extendido
A1_Retracted	DB_Cyl.A1_Retracted	Bool	R	SCR-001, SCR-002	Cil A1 recolhido
CMD_A1_Extend	DB_Cmd.A1_Extend	Bool	R/W	SCR-002	Comando manual avançar A1
CMD_A1_Retract	DB_Cmd.A1_Retract	Bool	R/W	SCR-002	Comando manual recuar A1
Palet_Pos1	DB_Sen.Palet_Pos1	Bool	R	SCR-001	Sensor palete posição 1
CMD_Reset_Fault	DB_Cmd.Reset_Fault	Bool	R/W	SCR-001, SCR-003	Reset geral de falhas
Alarm_Active_Count	DB_Alarm.Active_Count	Int	R	SCR-003	Qty alarmes ativos

7.2 Convenções de Nomenclatura

Definir as convenções antes de começar garante consistência ao longo de todo o projeto:

•       Prefixo por categoria: DB_Alarm, DB_Mode, DB_Cyl, DB_Sen, DB_Cmd.

•       Sufixo de ação para comandos: Extend, Retract, Reset, Start, _Stop.

•       Evitar abreviaturas ambíguas: usar A1_Extended em vez de A1_Ext (que pode ser extensão ou externo).

•       Variáveis de escrita (R/W) devem ter confirmação de ação documentada na Screen Spec correspondente.

Essas mesmas convenções já podem estar definidas dentro do padrão do CLP, ou da organização do software do CLP, e podem ser seguidas pela IHM, caso não sejam aplicáveis (casos de IHM / Supervisórios), que atendem a várias CPUs de projetos diversos, onde não existe uma padronização, adicionar essas convenção ao documento é ainda mais imprecindível, para não tornar o software da IHM confuso.

Boas práticas: Variáveis de escrita (acesso R/W) representam risco operacional. Cada uma deve ter um comportamento de confirmação documentado na Screen Spec: o operador clica no botão, aparece um diálogo de confirmação (“Deseja avançar o cilindro A1?”) e só então o bit é setado. Isso é especialmente crítico em movimentos manuais.

8. Integrando os Cinco Documentos: O Fluxo de Trabalho

Os cinco documentos não são independentes — cada um alimenta o próximo. O fluxo correto de trabalho é:

1.    Passo 1 — Persona: Define quem usa e quais são os cenários críticos.

2.    Passo 2 — Mapa de Navegação: Define quantas telas existem e como se conectam.

3.    Passo 3 — Guia de Estilo: Define como as telas devem parecer (cores, tipografia, símbolos).

4.    Passo 4 — Screen Specs: Detalha o que cada tela contém, elemento por elemento.

5.    Passo 5 — Lista de Variáveis: Consolida todos os pontos de dados necessários do CLP.

6.    Passo 6 — Protótipo: Apenas agora começamos a construir a interface visual.

Essa sequência garante que quando abrirmos a ferramenta de prototipagem, cada decisão já foi tomada. O protótipo deixa de ser um exercício de improvisação e torna-se uma tarefa de implementação de um plano validado.

Para equipes pequenas ou projetos de menor escala: é possível combinar a Persona e o Guia de Estilo em um único documento de uma página, e as Screen Specs podem ser feitas como anotações em cima de um wireframe desenhado à mão. O formato não importa tanto quanto a existência e validação do conteúdo.

9. Ferramentas Sugeridas para Montar a Documentação

A documentação não precisa de ferramentas sofisticadas. O que importa é que seja acessível a todos os envolvidos e fácil de atualizar. Algumas opções práticas:

Documento	Ferramentas Sugeridas	Observação
Persona	Google Docs / Notion / Word	Texto simples. Foco no conteúdo, não no formato.
Mapa de Navegação	Draw.io / Figma / PowerPoint / papel	Qualquer ferramenta de diagramas funciona.
Guia de Estilo	Figma (ideal) / PDF / Planilha / PowerPoint	Figma permite criar amostras de cores reais.
Screen Spec	Planilha (Excel/Sheets) + wireframe	Planilha para os dados, wireframe para o layout.
Lista de Variáveis	Excel / Google Sheets	Estrutura tabular. Fácil de exportar do CLP ou para o CLP dependendo do estágio do projeto e das características do projeto.
Protótipo	Figma / Adobe XD / Software de IHM	Alta fidelidade no próprio software do projeto.

10. O que Vem a Seguir

Com os cinco documentos montados e validados, estamos prontos para a próxima etapa da série: a construção dos protótipos de baixa fidelidade (wireframes) e, em seguida, a evolução para o protótipo de alta fidelidade dentro do próprio software de IHM do projeto.

Na próxima edição, vamos usar a documentação criada aqui para montar os wireframes das três telas principais do Magazine de Paletes: Sinótico, Falhas Ativas e Histórico. Veremos como cada decisão tomada neste artigo se traduzirá diretamente em elementos visuais, sem surpresas nem improvisação.

Aqui eu deixo um desafio: Tente montar a Persona e o Mapa de Navegação para um projeto real que você está desenvolvendo ou já desenvolveu. O exercício de documentar uma IHM existente frequentemente revela inconsistências que passaram despercebidas durante o desenvolvimento.

Até o próximo artigo!

Referências

•       ANSI/ISA-101.01-2015. Human Machine Interfaces for Process Automation Systems. ISA, 2015.

•       UFOP. Desenvolvimento de uma Interface Homem-Máquina (IHM) Industrial de Alta Performance Baseada no Estudo da Norma ISA-101. Monografia, 2024.

•       Nielsen, J. 10 Usability Heuristics for User Interface Design. Nielsen Norman Group, 1994.

•       Mayhew, D. The Usability Engineering Lifecycle. Morgan Kaufmann, 1999.

•       ISA São Paulo. Introdução à Norma ISA-101: Interfaces Homem-Máquina. Simpósio ISA SP, 2016.