A terminologia e os conceitos normativos da tecnologia da inteligência artificial (IA)

A visão computacional é a capacidade de uma unidade funcional para adquirir, processar e interpretar dados que representem imagens ou vídeos e  está intimamente relacionada ao reconhecimento de imagens, por exemplo, o processamento de imagens digitais. Os dados visuais normalmente se originam de um sensor de imagem digital, uma imagem analógica digitalizada ou algum outro dispositivo de entrada gráfica. Para os efeitos normativos, as imagens digitais incluem variantes fixas e móveis.

As imagens digitais existem como uma matriz de números que representam escalas de cinza ou cores na imagem capturada ou, em outros casos, uma coleção de vetores. As imagens digitais podem incluir metadados que descrevem as características e atributos associados à imagem. As imagens digitais podem ser compactadas para economizar espaço de armazenamento e melhorar seu desempenho de transmissão em redes digitais.

Alguns exemplos de aplicações de IA baseadas em visão computacional e reconhecimento de imagem: a identificação de imagens específicas em um conjunto de imagens (por exemplo, imagens de cães em um conjunto de imagens de animais); nos veículos autônomos: detecção e identificação de sinalização de trânsito e objetos em veículos automatizados; no diagnóstico médico: detecção de doenças e anomalias em imagens médicas; no controle de qualidade (por exemplo, localizar peças defeituosas em uma linha de montagem); e no reconhecimento facial.

As tarefas fundamentais para a visão computacional incluem a aquisição de imagens, reamostragem, escala, redução de ruído, aprimoramento de contraste, extração de características, segmentação, detecção e classificação de objetos. Vários métodos estão disponíveis para realizar tarefas de visão computacional em sistemas de IA. O uso de rede neural convolucional profunda ganhou popularidade nos últimos anos devido à sua alta precisão em tarefas de classificação de imagens e seu desempenho em treinamento e predição.

O processamento de linguagem natural processa as informações com base na compreensão da linguagem natural e na geração de linguagem natural. Engloba análise e geração de linguagem natural, com texto ou fala. Usando recursos de processamento de linguagem natural (natural language processing – NLP), os computadores podem analisar textos escritos em linguagem humana e identificar conceitos, entidades, palavras-chave, relações, emoções, sentimentos e outras características, permitindo aos usuários extrair compreensão desse conteúdo.

Com esses recursos, os computadores também podem gerar texto ou fala para se comunicar com os usuários. Qualquer sistema que use linguagem natural como entrada ou saída, na forma de texto ou fala, e seja capaz de processá-la, está usando componentes naturais de processamento de linguagem. Um exemplo desse tipo de sistema é um sistema de reserva automatizado utilizado por uma empresa aérea, capaz de atender chamadas de clientes e reservar voos. Esse sistema necessita de um componente de compreensão de linguagem natural e um componente de geração de linguagem natural.

São exemplos de aplicações de IA baseadas no processamento de linguagem natural: o reconhecimento de caligrafia (por exemplo, conversão de notas manuscritas em formato digital); reconhecimento de fala (por exemplo, compreensão do significado de declarações humanas); detecção de spam (por exemplo, usando o significado das palavras em uma mensagem de e-mail para determinar se essa mensagem é classificada como indesejada); os assistentes pessoais digitais e chatbots online que podem usar compreensão de linguagem natural e geração de linguagem natural (incluindo reconhecimento de fala e geração de fala) para oferecer interfaces de usuário conversacionais; resumo; geração de texto; e pesquisa de conteúdo. NLP também é usado em muitos sistemas de aplicativos, como chatbots, sistemas de anúncios baseados em conteúdo, sistemas de tradução de fala e sistemas de e-learning.

Os componentes de NLP abordam diferentes tarefas. As tarefas mais comuns incluem: o natural language understanding (NLU) que é um componente que converte texto ou fala em uma descrição interna que supostamente carrega a semântica da entrada. A dificuldade vem da ambiguidade inerente às línguas naturais: palavras e frases são polissêmicas por natureza, portanto, um resultado NLU é propenso a erros.

O componente natural language generation (NLG) converte uma descrição interna em texto ou fala compreensível por um

ser humano. Essa tarefa pode envolver o ajuste da frase para que pareça mais natural para o usuário. O part-of-speech (POS) é usado para categorizar cada palavra na entrada como um objeto gramatical: se é um substantivo, um adjetivo, um verbo e assim por diante. O POS-tagging também é afetado pela polissemia.

Um componente named entity recognition (NER) busca reconhecer e rotular os nomes denotacionais de uma pessoa, localização, organização ou outra entidade para sequências de palavras em um fluxo de texto ou fala. Dependendo da entidade, mais informações podem ser extraídas. Por exemplo, para pessoas, seu título ou função é útil.

Um componente de respostas a perguntas tenta dar a resposta mais adequada a uma pergunta humana. O usuário pergunta algo usando linguagem natural, e o sistema fornece uma resposta em linguagem natural. Um componente machine translation (MT) traduz automaticamente um conteúdo de linguagem natural de um idioma para outro. Isso pode acontecer de text-to-text, speech-to-text, speech-to-speech ou text-to-speech. A dificuldade vem da polissemia, na qual uma palavra tem múltiplos significados, bem como de outras

fontes, como referências entre ou dentro de frases ou intenções não ditas. Em muitos casos, várias traduções são possíveis.

Um componente optical character recognition (OCR) busca converter documentos escritos na forma de imagens (possivelmente digitalizadas) em uma descrição codificada digital de seu conteúdo: texto, tabelas, figuras, títulos e suas relações. Um componente de extração de relacionamento aborda a tarefa de extrair relações entre entidades nomeadas ou mesmo entre quaisquer entidades na entrada. Por exemplo, o componente pode identificar em um texto de entrada sobre filmes que Al Pacino estrelou o filme Serpico.

Um information retrieval (IR) ou componente de pesquisa busca atender às necessidades de informações do usuário pesquisando uma coleção de conteúdo não estruturado. A consulta do usuário expressando sua necessidade de informação é comparada algoritmicamente com cada elemento da coleção, para predizer sua relevância para a necessidade de informações do usuário.

A saída deste componente é tipicamente apresentada ao usuário como uma lista de elementos selecionados classificados em ordem decrescente de sua relevância. Os componentes de recuperação de informações podem ser desenvolvidos para uma ampla gama de diferentes tipos de elementos de informação, incluindo texto livre, documentos semiestruturados, documentos estruturados, áudio, imagem e vídeo, e em diferentes linguagens naturais.

Um componente de análise de sentimento busca identificar e categorizar computacionalmente opiniões expressas em um texto, fala ou imagem. Também é conhecida como mineração de opinião. Exemplos de aspectos subjetivos podem incluir sentimentos positivos ou negativos. Um componente de sumarização automática transmite de forma mais concisa as informações importantes de um elemento de conteúdo por uma de duas abordagens (ou a combinação delas). Sumarização extrativa que seleciona conteúdo-chave relevante do conteúdo de origem para produzir uma versão resumida reduzida. Sumarização abstrativa que busca sintetizar um novo texto mais curto que transmita as informações relevantes. A sumarização abstrativa está relacionada à geração de linguagem natural.

Um componente de gerenciamento de diálogo ajuda a gerenciar uma série de interações entre um usuário e um sistema com o objetivo de melhorar a experiência do usuário, assemelhando-se a uma conversa em linguagem natural. O gerenciamento de diálogo emprega uma série de abordagens, incluindo regras declarativas que especificam respostas para gatilhos de entrada específicos e abordagens baseadas em aprendizado de máquina. O gerenciamento de diálogo pode conduzir interações baseadas em texto, por exemplo, para fornecer uma experiência mais conversacional com componentes de resposta a perguntas ou integrados com componentes de reconhecimento e síntese de fala para oferecer suporte a aplicativos em assistentes pessoais, agentes de atendimento ao cliente on-line ou robótica de cuidados pessoais.

A tradução por máquina é uma tarefa NLP, na qual um sistema de computador é usado para traduzir automaticamente texto ou fala de uma língua natural para outra. Em geral, o processo de tradução por um humano acontece em duas etapas. O primeiro passo é decodificar o significado da linguagem de origem. O segundo passo é recodificar o significado na língua-alvo.

O processo requer profundo conhecimento de gramática, semântica, sintaxe, expressões idiomáticas, contexto cultural e outros domínios. Os desafios técnicos na tradução por máquina incluem múltiplos sentidos de palavras, considerações contextuais, diferenças gramaticais e idiomas que usam sistemas de escrita baseados em logogramas. Existem muitas abordagens para a tradução por máquina, como baseada em regras, baseada em exemplos, estatística, neural ou a combinação delas.

Nos últimos anos, as redes neurais têm sido usadas para realizar tradução por máquina, o que levou a melhorias notáveis na fluência e precisão da tradução. Por meio do aprendizado profundo, o modelo pode ser treinado e personalizado para expressões específicas de domínio para atingir altos níveis de precisão. A síntese de fala converte texto de linguagem natural em fala e é chamado de sistema text-to-speech (TTS).

Em geral, o processo TTS possui três etapas: análise, modelagem e síntese. Naturalidade inteligibilidade são características importantes de um sistema TTS. A naturalidade descreve o quanto a saída soa como a fala humana, enquanto a inteligibilidade é sobre a facilidade com que a saída é entendida pelos humanos. Os sistemas de síntese de fala geralmente tentam maximizar ambas as características.

Várias abordagens são usadas na síntese de fala, incluindo síntese de concatenação, síntese formante, síntese articulatória, síntese baseada em HMM, síntese de onda senoidal e deep neural network (DNN). Cada abordagem tem suas próprias forças e fraquezas. Alguns sintetizadores de fala baseados em DNN estão se aproximando da qualidade da voz humana.

O reconhecimento de fala pode ser definido como o reconhecimento de fala como conversão, por uma unidade funcional, de um sinal de fala para uma representação do conteúdo da fala. A fala digitalizada é uma forma de dados sequenciais, de modo que técnicas que podem lidar com dados associados a um intervalo de tempo podem ser usadas para processar fonemas a partir da fala. Várias abordagens usando redes neurais têm sido usadas para reconhecimento de fala.

Uma abordagem envolve o uso de long short-term memory (LSTM). Esse método permite que uma rede neural seja treinada e implantada como uma solução de reconhecimento de fala sem ser combinada com outros processos, como hidden Markov model (HMM), e resulta em desempenho de reconhecimento razoável.

A seguir, exemplos de aplicações de IA com base no reconhecimento de fala: os sistemas de comando de voz; o ditado digital; e os assistentes pessoais. Os sistemas de respostas a perguntas podem absorver um grande número de páginas de texto e aplicar a tecnologia de resposta a perguntas para responder a perguntas feitas por humanos em linguagem natural. Essa abordagem permite que pessoas perguntem e obtenham respostas quase instantâneas para perguntas complexas.

Combinada com outras aplication programmimg interface (API) e análises avançadas, a tecnologia de resposta a perguntas distingue-se da pesquisa convencional (que é desencadeada por palavras-chave) fornecendo uma experiência de usuário mais interativa. A mineração de dados refere-se à aplicação de algoritmos para a descoberta de informações válidas, novas e úteis a partir de dados. A mineração de dados ganhou destaque no final da década de 1990 e foi reconhecida como distinta dos métodos estatísticos anteriores.

A estatística tradicional focava na coleta de dados necessários e suficientes para responder definitivamente a uma pergunta específica. A mineração de dados era tipicamente aplicada a dados redefinidos para encontrar respostas aproximadas ou ajustes probabilísticos para padrões. A mineração de dados é considerada a etapa de modelagem algorítmica no processo completo de knowledge discovery in data (KDD). Saindo dos primeiros esforços de mineração de dados, um consórcio foi capaz de detalhar todas as etapas da mineração de dados no padrão da indústria cross-industry process model for data mining (CRISP-DM) publicado em 2000.

A mineração de dados abrange uma série de técnicas, incluindo árvores de decisão, clustering e classificação. À medida que as tecnologias de big data surgiram em meados dos anos 2000, a aplicação de algoritmos não podia mais ser separada do armazenamento de dados, e a amostragem cuidadosa deu lugar a um processamento mais rápido e intensivo de dados. Essas mudanças levaram à nova descrição da versão big data do processo de ciclo de vida KDD como atividades de ciência de dados. Embora KDD e descoberta de conhecimento sejam termos comuns em IA, o que um computador produz não é conhecimento, é informação. A figura abaixo demonstra como o ciclo de vida do sistema de IA pode ser mapeado.

O planejamento é uma subdisciplina da IA. É fundamental para aplicações industriais e importante em muitas áreas de negócio, como gestão de riscos, saúde, robôs colaborativos industriais, segurança cibernética, assistentes cognitivos e defesa. O planejamento permite que a máquina encontre automaticamente uma sequência procedimental de ações, para atingir determinados objetivos enquanto otimiza determinadas medidas de desempenho.

Do ponto de vista do planejamento, um sistema ocupa um determinado estado. A execução de uma ação pode alterar o estado do sistema, e a sequência de ações propostas pelo planejamento pode mover o sistema do estado inicial para mais próximo do estado objetivo.

A NBR ISO/IEC 22989 de 10/2023 – Tecnologia da informação — Inteligência artificial — Conceitos de inteligência artificial e terminologia estabelece terminologia para IA e descreve conceitos no campo da IA. Este documento pode ser utilizado no desenvolvimento de outras normas e no apoio às comunicações entre as diversas partes interessadas. Este documento é aplicável a todos os tipos de organizações (por exemplo, empresas comerciais, agências governamentais, organizações sem fins lucrativos).

Os avanços na capacidade de computação, redução dos seus custos, disponibilidade de grandes volumes de dados de muitas fontes, currículos acessíveis de aprendizado online e algoritmos capazes de atender ou exceder o desempenho humano para tarefas específicas em velocidade e precisão permitiram as aplicações práticas de IA, a tornando um ramo cada vez mais importante da tecnologia da informação. A IA é um campo altamente interdisciplinar amplamente baseado em ciência da computação, ciência de dados, ciências naturais, humanidades, matemática, ciências sociais e outros.

São utilizados termos como “inteligente”, “inteligência”, “compreensão”, “conhecimento”, “aprendizado”, “decisões”, “habilidades” etc. No entanto, a intenção não é a de antropomorfizar sistemas de IA, mas descrever o fato de que alguns sistemas de IA podem simular rudimentarmente essas características.

Existem muitas áreas da tecnologia de IA. Essas áreas estão intrincadamente ligadas e se desenvolvendo rapidamente, por isso é difícil encaixar a relevância de todos os campos técnicos em um único mapa. A pesquisa da IA inclui aspectos como “aprendizado, reconhecimento e predição”, “inferência, conhecimento e linguagem” e “descoberta, busca e criação”. A pesquisa também aborda interdependências entre esses aspectos.

O conceito de IA como fluxo de processos de entrada e saída é compartilhado por muitos pesquisadores de IA, e a pesquisa sobre cada etapa desse processo está em andamento. Os conceitos e a terminologia padronizados são necessários às partes interessadas da tecnologia para serem melhor compreendidos e adotados por um público mais amplo.

Além disso, os conceitos e as categorias de IA permitem a comparação e classificação de diferentes soluções em relação às propriedades como fidedignidade, robustez, resiliência, confiabilidade, precisão, segurança e privacidade. Isso permite que as partes interessadas selecionem soluções apropriadas para suas aplicações e comparem a qualidade das soluções disponíveis no mercado.

Como este documento fornece uma definição para o termo IA apenas no sentido de uma disciplina, o contexto para seu uso pode ser descrito da seguinte forma: A IA é um campo técnico e científico dedicado aos sistemas desenvolvidos que geram saídas como conteúdo, previsões, recomendações ou decisões para um determinado conjunto de objetivos definidos pelo ser humano.

Este documento fornece conceitos padronizados e terminologia para ajudar a tecnologia de IA a ser melhor compreendida e usada por um conjunto mais amplo de partes interessadas. Destina-se a um grande público, incluindo especialistas e não praticantes. A leitura de algumas seções específicas pode, no entanto, ser mais fácil com uma formação em ciência da computação.

A inteligência artificial (IA) é a 〈disciplina〉 pesquisa e desenvolvimento de mecanismos e aplicações de sistemas de IA. A pesquisa e o desenvolvimento podem ocorrer em diversos campos, como ciência da computação, ciência de dados, humanidades, matemática e ciências naturais. O sistema de inteligência artificial pode ser desenvolvido para gerar saídas como conteúdo, previsões, recomendações ou decisões para um determinado conjunto de objetivos definidos pelo homem. O sistema desenvolvido pode utilizar diversas técnicas e abordagens relacionadas à inteligência artificial para desenvolver um modelo para representar dados, conhecimento, processos etc. que podem ser usados para realizar tarefas. Os sistemas de IA são projetados para operar com diferentes níveis de automação.

O estudo interdisciplinar e o desenvolvimento de sistemas de IA visam a construção de sistemas de computadores capazes de executar tarefas que normalmente requerem inteligência. As máquinas habilitadas para IA têm o objetivo de perceber certos ambientes e tomar ações que atendam suas demandas.

A IA utiliza técnicas de diversas áreas, como ciência da computação, matemática, filosofia, linguística, economia, psicologia e ciência cognitiva. Em comparação com a maioria dos sistemas não IA convencionais, há uma série de recursos interessantes que são compartilhados por alguns ou por todos os sistemas de IA. O interativo compreende as entradas para sistemas de IA são geradas por sensores ou por meio de interações com humanos, com saídas que podem resultar em estimular um atuador ou fornecer respostas a humanos ou máquinas. Um exemplo pode ser o reconhecimento de objetos como resultado de um sistema de IA sendo apresentado à imagem de um objeto.

O contextual envolve alguns sistemas de IA que podem se basear em múltiplas fontes de informação, incluindo informações digitais estruturadas e não estruturadas, bem como entradas sensoriais. Os sistemas de supervisão envolvem os que podem operar com vários graus de supervisão e controle humano, dependendo da aplicação. Um exemplo é um veículo autônomo com diferentes níveis de automação.

O sistema adaptável envolve alguns sistemas de IA que são desenvolvidos para utilizar dados dinâmicos em tempo real e retreinar para atualizar sua operação com base em novos dados. Da IA forte e fraca à IA generalista e restrita, do ponto de vista filosófico, a viabilidade das máquinas que possuem inteligência tem sido debatida. Esse debate levou à introdução de dois tipos diferentes de IA: a denominada IA fraca e a IA forte.

Na IA fraca, o sistema só pode processar símbolos (letras, números etc.) sem nunca entender o que faz. Na IA forte, o sistema também processa símbolos, mas entende verdadeiramente o que faz. As denominações “IA fraca” e “IA forte” são principalmente importantes para os filósofos, mas irrelevantes para pesquisadores e profissionais de IA. Após esse debate, apareceram as qualificações de “IA restrita” versus “IA generalista”, que são mais adequadas ao campo da IA.

Um sistema de “IA restrita” é capaz de resolver tarefas definidas para resolver um problema específico (possivelmente muito melhor do que os humanos fariam). Um sistema de “IA generalista” aborda uma ampla gama de tarefas com um nível satisfatório de desempenho. Os sistemas atuais de IA são considerados “restritos”. Ainda não se sabe se os sistemas de IA “generalistas” serão tecnicamente viáveis no futuro.

É possível olhar para os sistemas de IA do ponto de vista do paradigma do agente, uma vez que algumas aplicações de IA visam simular inteligência humana e comportamento humano. Definida como uma disciplina da engenharia, a IA pode ser vista como o domínio que tenta construir agentes artificiais apresentando comportamento racional. O paradigma do agente estabelece uma linha clara separando o agente e o ambiente no qual evolui.

Um agente de IA interage com seu ambiente por meio de sensores e atuadores, tomando ações que maximizam sua chance de alcançar com sucesso seus objetivos. Os ambientes têm características diferentes dependendo da tarefa que está sendo realizada, e essas características impactam o nível de dificuldade de resolução de problemas.

Nesse paradigma, vários tipos de agentes de IA podem ser definidos, dependendo de sua arquitetura: agentes reflexos, que dependem apenas da situação atual para escolher uma ação; agentes baseados em modelos, que dependem de um modelo de ambiente que os permita considerar os resultados de suas ações disponíveis; agentes de objetivo ou de utilidade, que dependem de uma função de utilidade interna que os permita escolher ações que atinjam objetivos e, entre objetivos, procurar os mais desejáveis; agentes de aprendizado, que podem coletar informações sobre seu ambiente e aprender a melhorar seu desempenho. Várias arquiteturas sofisticadas e de alto nível baseadas em diferentes teorias foram desenvolvidas para implementar agentes.

O significado específico de “conhecimento” em IA merece uma discussão mais detalhada, devido à prevalência desse conceito no documento e em campo. Enquanto em outros domínios o termo pode estar associado às capacidades cognitivas, no contexto da IA é um termo puramente técnico, que se refere a conteúdos, não a capacidades. O conceito de conhecimento faz parte da hierarquia dados-informações-conhecimento, conforme a qual os dados podem ser usados para produzir informações, e as informações podem ser usadas para produzir conhecimento.

No contexto de IA, são processos puramente técnicos, não cognitivos. O conhecimento difere da informação porque a informação é observada pelo sistema, enquanto o conhecimento é o que o sistema retém dessas observações. O conhecimento é estruturado e organizado, se abstrai das especificidades das observações individuais. Dependendo do objetivo, a mesma informação pode levar a diferentes conhecimentos.

O conhecimento difere de sua representação na medida em que o mesmo conhecimento pode ter representações diferentes: pode aparecer sob diferentes formas concretas, cada uma com seus prós e contras, mas todas têm o mesmo significado. Essas distinções têm um impacto técnico, pois algumas abordagens, métodos e outros tópicos de estudo de IA dependem inteiramente da capacidade de produzir conhecimento diferente para a mesma informação ou representações diferentes para o mesmo conhecimento.

A cognição compreende a aquisição e o processamento do conhecimento por meio do raciocínio, da experiência exclusiva ou compartilhada, do aprendizado e da percepção. Engloba conceitos como atenção, formação de conhecimento, memória, julgamento e avaliação, raciocínio e cálculo, resolução de problemas e tomada de decisão, compreensão e produção de linguagem.

O retreinamento consiste em atualizar um modelo treinado, treinando-o com diferentes dados de treinamento. Isso pode ser necessário devido a muitos fatores, incluindo falta de grandes datasets de treinamento, desvio de dados e desvio de conceito. No desvio de dados, a precisão das predições do modelo decai ao longo do tempo devido às alterações nas características estatísticas dos dados de produção (por exemplo, a resolução de imagem mudou ou uma classe se tornou mais frequente nos dados do que outra).

Nesse caso, o modelo precisa ser retreinado com novos dados de treinamento que representem melhor os dados de produção atuais. No desvio de conceito, a fronteira de decisão se move (por exemplo, o que é legal e o que não é, tende a mudar quando novas leis são publicadas), o que também degrada a precisão das predições, mesmo que os dados não tenham mudado.

No caso de desvio de conceito, as variáveis de destino nos dados de treinamento precisam ser novamente rotuladas e o modelo retreinado. Ao retreinar um modelo existente, uma consideração específica é superar ou minimizar os desafios do chamado esquecimento catastrófico. Muitos algoritmos de aprendizado de máquina são bons em tarefas de aprendizado apenas se os dados forem apresentados todos de uma vez.

Quando um modelo é treinado em uma determinada tarefa, seus parâmetros são adaptados para resolver aquela tarefa. Quando novos dados de treinamento são introduzidos, adaptações baseadas nessas novas observações substituem conhecimentos que o modelo havia adquirido anteriormente. Para redes neurais, esse fenômeno é conhecido como “esquecimento catastrófico” e é considerado uma de suas limitações fundamentais.

O aprendizado continuado, também conhecido como aprendizado contínuo ou aprendizado ao longo da vida, é o treinamento incremental de um modelo que ocorre continuamente enquanto o sistema está sendo executado em produção. É um caso especial de retreinamento, no qual as atualizações do modelo são repetidas, ocorrem com alta frequência e não envolvem qualquer interrupção na operação.

Em muitos sistemas de IA, o sistema é treinado durante o processo de desenvolvimento, antes que seja colocado em produção. Isso é, por natureza, semelhante ao desenvolvimento-padrão de software, em que o sistema é construído e testado totalmente antes de ser colocado em produção.

O comportamento desses sistemas é avaliado durante o processo de verificação e espera-se que permaneça inalterado durante a fase de operação. Os sistemas de IA que incorporam aprendizado continuado implicam na atualização incremental do modelo no sistema à medida que opera durante a produção. A entrada de dados no sistema durante a operação não é apenas analisada para produzir uma saída do sistema, mas também usada simultaneamente para ajustar o modelo no sistema, com o objetivo de melhorar o modelo com base nos dados de produção.

Dependendo do desenho do sistema de IA de aprendizado continuado, pode haver ações humanas necessárias no processo, como, por exemplo, rotulagem de dados, validação da aplicação de uma atualização incremental específica ou monitoramento do desempenho do sistema de IA. O aprendizado continuado pode ajudar a lidar com as limitações dos dados de treinamento originais e também pode ajudar a lidar com o desvio de dados e o desvio de conceito.

No entanto, o aprendizado continuado traz desafios significativos para assegurar que o sistema de IA continue funcionando corretamente à medida que aprende. A verificação do sistema em produção é necessária, assim como a necessidade de capturar os dados de produção para que se tornem parte do dataset de treinamento, caso o sistema de IA seja atualizado em algum momento futuro.

A gestão do sistema de infraestrutura de telecomunicações, redes e TI

O sistema automated infrastructure management (AIM) envolve o hardware e o software integrados para a gestão da infraestrutura e intercâmbio de dados com outros sistemas e o software AIM é um programa computacional capaz de detectar informações de conectividade do cabeamento e gerenciar suas relações com os ativos de rede do sistema AIM. O gerenciamento de ativos pode melhorar a utilização efetiva e a disponibilidade da rede, e seus componentes, auxiliando na redução do custo operacional.

Os ativos em sistemas AIM incluem todos os elementos de software e hardware presentes na infraestrutura da rede. O gerenciamento de ativos é uma ação importante para a construção e manutenção do inventário da rede, de modo que os sistemas AIM devem oferecer formas de documentar ativos manualmente para componentes passivos e devem ter a capacidade de descobrir a presença, bem como manter as informações sobre o status de conectividade e a localização dos equipamentos de distribuição da rede, como roteadores, switches, pontos de acesso sem fio etc.; e dos dispositivos terminais, servidores, computadores pessoais, telefones IP, câmeras IP, dispositivos de controle de acesso, etc.

Os sistemas AIM devem registrar a capacidade e a utilização da infraestrutura de telecomunicações e rede dos equipamentos de distribuição ou dispositivos terminais mantidos no sistema. Isso melhora a velocidade e a precisão do planejamento para mudanças, adições de ativos e outras alterações, como, por exemplo, identificação de portas ociosas, entre outras capacidades.

Os sistemas AIM devem registrar e manter as mudanças na infraestrutura de cabeamento, equipamentos de distribuição e dispositivos terminais, etc. em tempo real, para as seguintes informações: as atividades autorizadas e não autorizadas de manobras de patch cords; a geração de ordens de serviço para mudanças, adições e alterações; o rastreamento automático de conclusão de ordens de serviço; o histórico de ordens de serviço agendadas e executadas; e o monitoramento de mudanças na conectividade, definição de alarmes, etc. Os sistemas AIM devem ter a capacidade de registrar eventos e gerar notificações, alertas e alarmes em resposta a eventos registrados.

Essa capacidade aumenta a segurança da rede pela notificação de conexões não autorizadas, desconexões ou acessos aos sistemas AIM que devem oferecer suporte à alimentação elétrica em corrente contínua remota e rastrear automaticamente o uso dessa capacidade por dispositivos habilitados. Esses sistemas são conhecidos na linguagem técnica como dispositivos ou equipamentos power over ethernet (PoE).

Devido à natureza dinâmica da alimentação dos dispositivos PoE, o estado dos cabos em um feixe de cabos, como, por exemplo, conexões e desconexões de portas do equipamento que contém a fonte de alimentação PoE (PSE) e as conexões e desconexões do dispositivo PoE alimentado (PD), pode ser obtido pela combinação da capacidade do hardware AIM para a detecção automática de mudanças nas conexões; habilidade do software AIM para extrair informações dos dispositivos terminais e alimentação elétrica remota do PSE, que utiliza protocolos de rede padronizados; e a documentação das características elétricas dos cabos no sistema AIM.

O intercâmbio de dados entre sistemas AIM e outros sistemas da rede aumenta a funcionalidade de ambos os sistemas. Os sistemas AIM devem ter capacidades de intercâmbio de dados entre os seguintes sistemas e aplicações, porém não limitado a eles: gerenciamento de sistemas de TI: rede; incidentes e helpdesk; segurança da informação; gerenciamento de sistemas de automação predial: energia; controle de iluminação; gerenciamento da infraestrutura de data centers: sistemas DCIM; configuração e gerenciamento de banco de dados.

Os sistemas AIM devem ter capacidade de integração com sistemas de telefonia IP, de forma a permitir o rastreamento da localização física de dispositivos terminais conectados à infraestrutura de cabeamento da rede. Devem ter capacidade de interoperabilidade com elementos da rede para gerenciamento de falhas, configuração, desempenho, etc.

Essas capacidades podem incluir: a consolidação de alertas relacionados aos elementos da rede, incluindo a infraestrutura de cabeamento, em um único console de gerenciamento para dotar os sistemas AIM de capacidades de gerar eventos sobre o status de mudanças na infraestrutura de cabeamento e fazer o intercâmbio desses eventos com aplicações de protocolo de gerenciamento de rede simples (SNMP); uma expansão da habilidade existente de descoberta de inventário da rede com base em um mapeamento lógico com a capacidade de apresentar graficamente a conectividade física entre os elementos da rede; a capacidade de mostrar graficamente a localização de cada elemento de rede descoberto pelo sistema AIM, entre outras capacidades.

Os sistemas AIM devem ter capacidade de integração com aplicações helpdesk, como gerenciamento de incidentes e comunicações com os clientes. A interoperabilidade entre os sistemas AIM e as aplicações helpdesk, quando implementada, deve incluir: as notificações sobre mudanças na conectividade em tempo real; as informações relacionadas à rede física, incluindo equipamentos de distribuição, dispositivos terminais e infraestrutura de cabeamento; a automação de processos de criação de ordens de serviço relacionadas às atividades de mudanças, às adições e às alterações na rede; a capacidade de realizar análises remotas de problemas relacionados à conectividade no cabeamento; e a capacidade de atualizar automaticamente o status das ordens de serviço concluídas relacionadas às atividades de mudanças, às adições e às alterações na rede.

Assim, os sistemas AIM devem ter capacidade de integração com sistemas de gerenciamento de segurança da informação da organização para assegurar que os dados sensíveis não estejam disponíveis aos usuários não autorizados. Isso pode ser feito com base em métodos seguros de autenticação para impedir o acesso não autorizado.

Eles devem ter capacidade de integração com sistemas de segurança física da organização. Uma vez que as mudanças não autorizadas na infraestrutura da rede podem ser rastreadas, uma conexão do sistema AIM com o sistema de segurança da organização pode permitir a captura de evidências fotográficas do responsável pela mudança não autorizada. A resposta a eventos não autorizados pode envolver os mecanismos do protocolo SNMP.

Os sistemas AIM devem ter capacidade de integração com sistemas de automação predial BMS para contemplar informações sobre a localização física dos equipamentos e dispositivos do sistema BMS no software do sistema AIM. Entre as funcionalidades do sistema BMS que podem ser integradas ao sistema AIM estão: o gerenciamento de consumo de energia do edifício; o gerenciamento do sistema de iluminação do edifício; segurança; e o controle de acesso.

Os sistemas AIM devem oferecer capacidades de integração com sistemas DCIM de modo a incluir: o gerenciamento da operação para identificar mudanças não planejadas ou não autorizadas na conectividade e gerar alarmes para o software DCIM sobre esses eventos; o gerenciamento da conectividade e dos ativos de rede de forma a oferecer visibilidade de conexões de redundância entre os ativos da rede; a manutenção da documentação completa da conectividade juntamente com informações sobre a presença de equipamentos de distribuição de rede interconectados e dispositivos terminais; o gerenciamento de mudanças por meio do rastreamento automatizado das mudanças na conectividade e nos ativos de rede; o gerenciamento de disponibilidade de forma a oferecer informações sobre a conectividade e oferecer suporte às atividades relacionadas a ela, como, por exemplo, diagnósticos e soluções de problemas na rede; e o planejamento da capacidade dos ativos de rede por meio de informações precisas sobre as conexões das portas de patch panels para melhorar o planejamento das capacidades dos ativos de rede no software DCIM.

Os sistemas AIM devem ter capacidade de integração com os sistemas de banco de dados de gerenciamento de configuração (CMDB), de modo a incluir a atualização automática da localização física dos ativos de rede. Por exemplo, um sistema AIM pode atualizar o status de itens configurados em um sistema CMDB com uma informação de localização sempre que essa informação estiver disponível, tanto por mudanças agendadas como por mudanças não agendadas da conectividade da rede.

A NBR 16869-4 de 08/2023 – Cabeamento estruturado – Parte 4: Sistema automatizado de gerenciamento da infraestrutura de telecomunicações, redes e TI especifica os requisitos e as recomendações que se aplicam à infraestrutura de cabeamento e gerenciamento de dispositivos conectados; aos sistemas e processos de gerenciamento da infraestrutura de TI; a outros sistemas e processos de gerenciamento de rede, como sistemas de automação de edifícios; e ao rastreamento de ativos e gerenciamento em conjunto com notificações de eventos e alertas que suportam a segurança da rede física. Para sistemas automatizados de gerenciamento da infraestrutura de telecomunicações, redes e TI (automated infrastructure management – AIM) que oferecem suporte à alimentação elétrica remota em corrente contínua como uma opção, esta parte apresenta os requisitos e as recomendações de gerenciamento adicionais. Especifica uma estrutura de requisitos e recomendações para o intercâmbio de dados com outros sistemas.

Para que um sistema AIM esteja em conformidade com esta parte da NBR 16869, ele deve: compreender componentes de hardware e software que atendam aos requisitos da Seção 5; atender aos requisitos da Seção 7; ser implementado de acordo com os requisitos do Anexo C. Os sistemas AIM que oferecem suporte a sistemas com alimentação elétrica remota em conformidade com esta parte devem estar em conformidade com os requisitos do Anexo E, além dos requisitos de conformidade descritos nesta parte.

Um sistema AIM deve possuir os seguintes elementos funcionais: hardware para detecção automática de inserção e remoção de patch cords; software com capacidade para: coletar e detectar as informações das conexões; relacionar as informações das conexões e da conectividade do cabeamento; tornar as informações das conexões acessíveis ao usuário autorizado ou a outros sistemas. Conforme especificado na NBR 14565, as interfaces de equipamento para cabeamento estruturado estão localizadas nas extremidades de cada subsistema, e essa topologia é válida também para a infraestrutura de cabeamento para sistemas AIM.

Embora vários hardwares AIM possam ser instalados ao longo de um edifício, campus ou até mesmo em redes WAN, o monitoramento propriamente dito é sempre local, ou seja, nos subsistemas de cabeamento de backbone e horizontal, que são encontrados os equipamentos de distribuição de rede e os dispositivos terminais. Uma conexão de backbone, por sua vez, conecta equipamentos de distribuição de rede e não contempla os dispositivos terminais.

Os equipamentos de distribuição de rede devem ser instalados nos espaços de telecomunicações que contêm distribuidores, em conformidade com a NBR 16415. Os dispositivos terminais devem ser instalados nas tomadas de telecomunicações das áreas de trabalho ou das áreas de cobertura, em conformidade com a NBR 14565, nas tomadas de equipamentos, em conformidade com a NBR 16665, ou nas tomadas de telecomunicações da área de automação, em conformidade com a NBR 16521.

As conexões entre os dispositivos e o hardware de conexão nos distribuidores do cabeamento podem ser feitas por meio de modelos de interconexão ou conexão cruzada. Esses modelos de conexão podem ser usados para as conexões em sistemas AIM. A figura abaixo mostra um exemplo de conexão entre o hardware AIM com portas habilitadas para os sistemas AIM e os patch panels com portas habilitadas para sistemas AIM, usando o modelo de interconexão no subsistema de cabeamento horizontal.

No modelo de interconexão apresentado na figura, o equipamento de distribuição de rede com portas habilitadas para sistemas AIM é conectado diretamente ao hardware de conexão, com portas habilitadas para os sistemas AIM. O hardware AIM monitora as conexões entre as portas do distribuidor de rede e dos patchs cords, e detecta inserções e remoções de patch cords.

Embora os sistemas AIM com um grande número de conexões possam necessitar de servidores dedicados, eles são opcionais e, em uma topologia de rede WAN, podem estar em qualquer localidade da rede, inclusive com gerenciamento em nuvem. O software utilizado em sistemas AIM deve incluir as interfaces de programação da aplicação (API) e os formatos para intercâmbio de dados descritos na Seção 7, de forma a permitir que dados do sistema AIM sejam compartilhados com outros sistemas utilizados na organização.

Este é um aspecto importante para melhorar e automatizar o gerenciamento e as funções operacionais no edifício e em data centers. Um sistema AIM deve ter as seguintes capacidades: detectar automaticamente a conectividade entre as portas de patch panels habilitadas para os sistemas AIM; detectar automaticamente a conectividade entre as portas de patch panels habilitadas para os sistemas AIM e outros equipamentos com portas habilitadas para os sistemas AIM, ou documentar a conectividade entre as portas habilitadas para os sistemas AIM e patch panels ou outros equipamentos não habilitados para os sistemas AIM; monitorar as conexões e desconexões em sistemas AIM.

Uma vez configurado, um sistema AIM deve ter as seguintes capacidades: associar o esquema de identificação estabelecido para os itens a serem documentados pelo software AIM, conforme a NBR 16869-1; registrar as conexões entre os elementos da infraestrutura de cabeamento; detectar, documentar e monitorar automaticamente a presença de equipamentos detectáveis conectados à rede; atualizar automaticamente os registros, quando quaisquer conexões monitoradas forem modificadas; documentar manualmente as informações para ativos de rede não detectáveis; documentar a localização física do equipamento de distribuição conectado à rede; documentar a presença e a localização física do hardware de sistemas AIM; manter um histórico dos eventos listados acima; e permitir a exibição de itens mapeados documentados no software AIM, para uma localização física em plantas e leiaute do edifício.

Um sistema AIM deve ter as seguintes capacidades: permitir que o usuário determine as condições em que um evento deve gerar um alarme; permitir que o usuário determine as condições sob as quais um alarme deve gerar uma notificação; permitir que o usuário veja graficamente a representação de conectividade e outras informações relacionadas aos itens documentados no software AIM; prover recomendações sobre as tarefas de conectividade do cabeamento, necessárias para a provisão das ordens de serviço; permitir que o usuário gerencie ordens de serviço e itens documentados no software AIM, como a criação, atribuição, agendamento, execução, rastreamento de conexões e fechamento de ordens de serviço; manter um histórico de ordens de serviço; oferecer acesso a ordens de serviço eletrônicas e outras informações mantidas no sistema AIM nos espaços em que o hardware AIM estiver localizado; oferecer um meio para detectar automaticamente a precisão da implementação de tarefas de conexão e desconexão entre portas habilitadas para AIM, conforme as ordens de serviço; oferecer meios para alertar execuções incorretas; atualizar automaticamente o status das tarefas executadas corretamente; e gerar relatórios, de forma automática ou sob demanda, relacionados aos itens documentados no software AIM.

Após a recuperação da interrupção de um sistema AIM ou seus componentes, o sistema deve ter as seguintes capacidades: manter a integridade das informações do software AIM; e mostrar o estado atual da conectividade monitorada. Uma vez configurado, um sistema AIM pode ter as seguintes capacidades adicionais: gerar dados formatados para a produção de etiquetas; detectar, documentar e monitorar a configuração básica de conectividade de equipamentos gerenciáveis; documentar e inferir a conectividade entre portas de sistemas não habilitados para AIM e outros equipamentos; identificar e rastrear a localização física dos dispositivos terminais conectados à rede.

Deve-se conhecer as informações sobre as características e as capacidades dos sistemas AIM. Para melhorar a disponibilidade, os sistemas AIM devem oferecer capacidades de atualização automatizada da documentação da infraestrutura da rede.

A marcação digital dos produtos para a automação de processos industriais

A marcação digital de um produto pode ser lida eletronicamente, codificada em um meio de leitura óptico, um dispositivo do tipo transponder (transmitter-responder) de radiofrequência ou um firmware de produto. De forma diferente de uma marcação convencional, uma marcação digital não é diretamente lida por humanos, como os símbolos 2D, como o QR Code e Data Matrix, são exemplos de meios de marcação lidos opticamente. Os dispositivos de identificação por meio de transponders de radiofrequência (RFID – radio frequency identification) são exemplos de meios de marcação lidos eletronicamente.

Para citar um exemplo, nos casos de marcação digital de produtos Ex, devem ser adicionalmente atendidos os requisitos indicados na NBR IEC 60079-14, quando da utilização de transponders em áreas classificadas contendo atmosferas explosivas formadas por gases inflamáveis ou poeiras combustíveis. Os transponders passivos podem ser considerados equipamentos simples, de acordo com a NBR IEC 60079-14, sem a necessidade de certificação para atmosferas explosivas. As cargas eletrostáticas que possam ser acumuladas no transponder devem ser evitadas por medidas apropriadas de projeto, de acordo com a NBR IEC 60079-14.

Já a marcação digital em produtos modulares que, frequentemente, podem consistir em diversos componentes, que podem ser considerados separadamente. Isto significa que cada componente individual pode ter a sua própria marcação.

Nestes casos, somente um transponder, que contenha a marcação para o produto completo, pode ser afixado, como é tradicionalmente efetuado nos casos das marcações convencionais, no lado externo dos invólucros. Se um produto tivesse diversos transponders, uma única marcação não poderia ser assegurada. Se necessário, o transponder deve ser atualizado após os serviços de reparo, recuperação ou substituição de componentes.

O firmware é outra possibilidade de armazenamento de dados em uma marcação digital, no respectivo produto final, na forma de informações regulamentares, requeridas para serem acessíveis. Independentemente da tecnologia de exibição e de integração utilizada, os dados integrais devem ser armazenados permanentemente no firmware do produto.

Deve ser assegurado que as informações da marcação digital não possam ser alteradas pelo usuário e que a manipulação não seja possível (por meio de alterações indevidas). A marcação digital pode ser atualizada pelo fabricante, se necessário. Os dados somente podem ser lidos quando o produto estiver ligado, por exemplo, por meio de uma estrutura de menu interna e display integrado, ou por meio de uma interface de comunicação (por exemplo, interface WEB, interface de serviço, bluetooth ou I/O Link).

A NBR IEC 63365 de 05/2023 – Medição, controle e automação de processos industriais — Marcação digital é aplicável aos produtos utilizados na medição, controle e automação de processos industriais e estabelece o conceito e os requisitos para a marcação digital e apresenta soluções de leitura eletrônica (por exemplo, por meio de Códigos 2D, como os QR Codes, RFID ou firmware), alternativas às marcações convencionais, com textos simples sobre os produtos ou embalagens ou seus documentos. As informações das marcações digitais são contidas em meios lidos eletronicamente, afixados aos produtos, às embalagens dos produtos ou aos documentos que acompanham os produtos.

As informações das marcações digitais são disponíveis de forma offline, sem uma conexão com a internet. Após a leitura eletrônica, todas as informações das marcações digitais são mostradas na forma de texto, em uma tela ou display a ser lida por humanos. As marcações digitais também incluem um link de identificação, de acordo com a IEC 61406-1 (identification link), que proporciona informações adicionais dos produtos na forma online. Esta norma não especifica o conteúdo de marcações convencionais, que são sujeitas a regulamentos ou normas regionais ou nacionais.

O objetivo primário de uma marcação é identificar, de forma clara, os equipamentos, componentes, dispositivos e seus fabricantes. Requisitos legais de marcação ou símbolos de aprovação indicam a conformidade com os regulamentos para a colocação dos produtos no mercado, bem como para as suas utilizações de forma segura.

O projeto marcação digital foi iniciado em resposta às necessidades dos fabricantes de equipamentos com tipos de proteção “Ex” para instalação em atmosferas explosivas e pelos operadores ou proprietários de instalações de instrumentação, automação, telecomunicações, elétricas e mecânicas, em áreas classificadas. Um dos objetivos da marcação digital é assegurar que todas as informações necessárias possam ser marcadas nos equipamentos, particularmente considerando a grande quantidade de informações requeridas na área de equipamentos para atmosferas explosivas.

Os requisitos para a marcação de produtos “Ex” para os mercados globais têm se tornado tão extensivos que frequentemente não é mais possível incluir todas as informações requeridas sobre uma marcação convencional, especialmente para os produtos de menores dimensões, como, por exemplo, os sensores. Como exemplo, na Europa, diferentes Diretivas para os países da Comunidade Europeia e normas harmonizadas podem ser aplicáveis a um mesmo produto, como regulamentos sobre a segurança elétrica, proteção de equipamentos “Ex” para atmosferas explosivas, segurança para máquinas, segurança de equipamentos sobre pressão ou segurança de alimentos.

Se os produtos forem destinados à comercialização em diferentes países do mundo, marcações adicionais e símbolos de aprovação são requeridos, como, por exemplo, marcação internacional IECEx, marcação “Ex” para o mercado norte americano, marcação para o Reino Unido (UK CA), marcação EAC para a área econômica da Eurásia, marcação RCM para a Austrália ou marcação CCC para a China. Neste contexto, para a fabricação inteligente, é também requerido, no momento, que os produtos sejam identificados eletronicamente.

Os fabricantes dos equipamentos podem utilizar marcações com leitura por máquinas, no processo de produção, para controlar automaticamente o fluxo de material, utilizando, por exemplo, um código de barras. Os operadores ou proprietários podem facilmente identificar os produtos nas etapas de inspeções iniciais de recebimento.

Os engenheiros envolvidos com serviços de engenharia ou as autoridades responsáveis podem verificar, eletronicamente, todos os dados requeridos e as informações para uma adequada aplicação em particular e para utilização segura dos produtos. Um dos objetivos da marcação digital offline é a redução do espaço requerido pelas marcações convencionais.

Em longo prazo, é previsto que a marcação digital possa substituir os textos da marcação convencional, economizando um espaço significativo, especialmente em produtos de pequenas dimensões. Este documento descreve soluções para leituras eletrônicas, alternativas com as marcações convencionais, com texto e símbolos, na marcação de produtos, embalagens ou documentos.

Esta norma descreve as tecnologias de marcação que utilizam Códigos 2D (como o QR Code), transponders (como o RFID) ou o firmware dos produtos. No caso dos Códigos 2D ou transponders, os dados armazenados na marcação digital podem ser lidos por dispositivos comumente disponíveis no mercado, como, por exemplo, os smartphones.

Se os dados da marcação forem armazenados em um firmware do produto, a marcação pode ser mostrada, por exemplo, na tela ou no display do leitor ou escâner, ou os dados podem ser lidos remotamente, por meio de uma interface eletrônica. Além disto, a IEC 61406-1 (Identification link) apresenta os requisitos para uma identificação única de produtos, por meio de um link de identificação.

Aquela norma permite que os fabricantes apresentem todas as informações e dados, bem como os documentos relacionados a um produto, por meio de um endereço na internet, em um formato eletrônico. A documentação dos produtos, como informações técnicas, manuais de instalação, operação, manutenção, inspeção e recuperação, bem como os certificados de conformidade, pode ser obtida por meio de download da internet.

A IEC 61406-1 estabelece um código 2D ou RFID, o qual contém somente a identificação de um link, com caracteres limitados. Nesta norma a identificação do link é incluída como a primeira propriedade da marcação digital para o website do fabricante, seguida de propriedades detalhadas de marcação. Se uma conexão de internet for disponível para o website do fabricante, dados adicionais do produto e sua documentação podem ser acessados (gêmeo digital/digital twin).

Este documento é também destinado à elevação da aceitação das marcações digitais por parte dos organismos e entidades regulamentadoras. Um objetivo em médio e longo prazos é a substituição da marcação convencional por uma marcação digital, tanto quanto possível. Os organismos e entidades regulamentadoras requerem que a marcação seja aplicada aos produtos, componentes e dispositivos de forma permanente, clara e legível.

Estes requisitos podem ser atendidos também pelas marcações digitais que são permanentemente afixadas aos produtos e que permitem que os dados requeridos sejam acessados sem a necessidade de uma conexão com a internet são muito parecidas com a marcação convencional com textos simples. Para assegurar uma maior aceitação da marcação digital, a marcação apresenta a quantidade mínima de marcação em texto simples.

Durante o período de transição, ambas as informações, por meio de texto simples e de marcação digital, podem ser aplicadas de forma simultânea aos produtos. No momento, as marcações digitais estão sendo implementadas e aceitas nos mercados internacionais, de forma crescente e contínua.

A ISO/IEC 22603-1, publicada em 2022, especifica uma etiqueta digital que representa o produto marcação. No entanto aquela norma proporciona a marcação do produto por meio de um link para um servidor Web, que contém as informações relevantes, mas não contém a marcação digital diretamente no código digital. As informações, de acordo com o Anexo A, podem ser incluídas em um código digital para a marcação.

O código digital: pode armazenar todas as informações requeridas por regulamentos regionais ou nacionais e pode conter informações apresentadas pelos fabricantes. As marcas e os símbolos não estão aptos a serem convertidos em um código digital na marcação digital, mas podem ser incluídos no firmware.

Todas as informações proporcionadas no código digital, que não sejam requeridas especificamente em um texto simples por regulamentos regionais ou nacionais, podem ser removidas do texto da marcação digital a ser lido por humanos. Por questões de segurança cibernética, é recomendado que os leitores de marcações digitais no formato 2D solicitem uma autorização do usuário antes de ativar um link para uma URL (uniform resource locator).

Em geral, se o link não for ativado, o texto incluído na marcação digital é mostrado. As informações apresentadas no Anexo A podem ser convertidas para o formato digital. Os dados devem ser estruturados de acordo com as seguintes três categorias: informações básicas; especificações técnicas; certificados de conformidade.

A primeira informação de uma marcação digital deve ser um link de identificação, de acordo com a IEC 61406-1. Isto permite que os leitores e escâneres comuns interpretem a primeira linha como uma URL e, caso uma conexão com a internet esteja disponível, acessem um banco de dados do produto.

Um exemplo de uma marcação convencional é mostrado na parte superior da figura abaixo. Esta marcação representa um medidor de nível industrial que possui diversos certificados de conformidade internacionais, regionais e nacionais, como um equipamento certificado para instalação em atmosferas explosivas.

Devido à grande quantidade de informações, esta marcação convencional ocupa uma grande área, de 80 cm². Na parte de baixo da figura, é mostrada a correspondente marcação digital, com as informações básicas e os símbolos de conformidade também mostrados juntamente com os textos simples. A marcação completa é convertida em código digital.

A marcação digital, incluindo o QR Code, ocupa uma área de 42,5 cm², que é aproximadamente a metade da área de marcação convencional mostrada na parte de acima da Figura. A leitura do QR Code utilizando um smartphone, com um software comum de leitura, é também mostrada na figura. O texto completo da marcação digital, incluindo as informações básicas, é visível na tela do dispositivo de leitura e pode ser armazenado ou transferido como um arquivo de texto.

Pode ser útil tornar estes dados capazes de serem lidos por máquinas e alocar os dados em um banco de dados específico. Com o link de identificação na marcação digital, uma conexão via internet pode ser estabelecida com um banco de dados do produto, o qual pode conter uma descrição semântica dos dados da marcação, com identificadores internacionais de dados (por exemplo, IEC CDD – common data dictionary).

Os identificadores internacionais de dados permitem que os dados sejam trocados de forma simples entre as diferentes indústrias, países e idiomas (ver Anexo B). Os códigos de barras bidimensionais que podem ser opticamente lidos (Códigos 2D) podem ser utilizados para a marcação digital de produtos. Diversos Códigos 2D podem ser aplicados a um produto ao mesmo tempo. Os Códigos 2D podem ser: parte da marcação (rótulo, impressão ou gravação a laser no produto) ou — afixados no produto por uma placa separada.

Devem ser utilizados como Códigos 2D os QR Codes, de acordo com a ISO/IEC 18004, ou Data Matrix, de acordo com a ISO/IEC 16022. Os QR Code têm atualmente a forma de um quadrado. Uma versão retangular de QR Code está em desenvolvimento (Micro QR Model R). O formato Data Matrix é disponível na forma quadrada ou retangular (extended rectangular data matrix (DMRE), de acordo com a ISO/IEC 21471. Os Códigos 2D devem ser legíveis por leitores eletrônicos comercialmente disponíveis no mercado (por exemplo, smartphones). Os requisitos de qualidade dos Códigos 2D, por exemplo, tamanho do módulo, correção do erro, qualidade da impressão e durabilidade, são similares aos indicados na IEC 61406-1.

Os parâmetros normativos de medição predial remota do consumo de água e gás

O sistema de medição remota (SMR) se constitui por medidores providos de geradores de pulsos ou outra tecnologia substituta, dispositivos auxiliares de medição, dispositivos adicionais de medição e prescrições documentadas, que permitem a medição e outras funcionalidades, como acionamento de válvulas de bloqueio digital à distância. Basicamente, podem ser um sistema de medição remota constituído por linhas variáveis discretas; um sistema de medição remota constituído por linhas de comunicação digital; e um sistema de medição remota misto.

O comissionamento do SMR envolve um conjunto de ensaios e inspeções para assegurar a sua conformidade com a norma e minimizar a ocorrência de anomalias. O comissionamento do SMR deve ser realizado em duas etapas, tendo em vista as exigências preconizadas para a realização de ensaio de verificação da integralização de pulsos dos medidores pelo SMR.

Os seguintes documentos devem ser entregues ao proprietário e/ou operador do SMR pelo seu fornecedor na ocasião do comissionamento: manual de operação e manutenção do SMR; declaração de inspeção de componentes de SMR adquiridos de terceiros; certificados dos ensaios e simulações e inspeções feitas no SMR instalado no local; cópia das anotações de responsabilidade técnica (ART) de projeto, equipamentos e sistemas, e execução da instalação do SMR; projeto final (desenho esquemático) das instalações do SMR, para o edifício em questão, detalhando a localização dos componentes situados em área comum, assim como o tipo de material utilizado, seguindo as prescrições da ISA 5.1; e as prescrições documentadas. A discriminação dos ensaios e os respectivos planos de amostragem encontram-se na tabela abaixo.

Igualmente, deve-se entender uma metodologia de dimensionamento da infraestrutura predial civil necessária (eletrodutos, eletrocalhas, caixas de passagem, etc.) que possibilite a futura instalação de quaisquer das três modalidades de sistema de medição remota prediais, as quais estão comumente disponíveis no mercado brasileiro. Isso se preferencialmente à elaboração do projeto da edificação, para o qual existe a necessidade de se prever a infraestrutura civil para a futura instalação de SMR após a conclusão das obras e cuja modalidade e fornecedor ainda não foram definidos. Para edificações já construídas ou para o caso de já se ter definido por ocasião da elaboração do projeto da edificação o fornecedor do SMR, recomenda-se consultá-lo para efeito de dimensionamento da infraestrutura civil necessária.

A NBR 15806 de 02/2010 – Sistemas de medição predial remota e centralizada de consumo de água e gás estabelece os requisitos mínimos necessários para implementação de sistemas de medição prediais remotos e centralizados de consumo de água e gás, tipicamente utilizados em edificações residenciais e comerciais. Esta norma se aplica aos sistemas com medidores de água e gás regularmente utilizados em medições residenciais e análogas (hidrômetros e medidores de paredes deformáveis) conforme descritos nas normas NBR NM 212 e NBR 12127.

O sistema de medição remota (SMR) é usado para a medição e é constituído por medidores providos de geradores de pulsos ou outra tecnologia substituta, dispositivos auxiliares de medição, dispositivos adicionais de medição e prescrições documentadas, que permitem a medição e outras funcionalidades, como acionamento de válvulas de bloqueio digital à distância (figura abaixo). Os componentes do SMR, particularmente os dispositivos auxiliares de medição, podem constituir-se em elementos únicos situados em locais determinados ou em vários elementos localizados ao longo de uma rede digital de comunicações em função da solução tecnológica adotada.

Para exemplificar os dispositivos de memórias (dispositivo auxiliar de medição) tanto podem estar localizados de forma distribuída nos andares dos edifícios, como também podem se constituir em um elemento único localizado nas centrais de controle instaladas em área comum. Os sistemas de medição remota prediais para água e gás são classificados em três modalidades, de acordo com a tipologia das redes de comunicação de dados.

O Anexo A apresenta uma metodologia de dimensionamento da infraestrutura predial civil (eletrodutos, eletrocalhas, caixas de passagem, etc.) que possibilita no âmbito do projeto da edificação a previsão dos meios necessários para a instalação de quaisquer das três modalidades de sistema de medição remota prediais, após a sua construção. O sistema de medição remota constituído por linhas variáveis discretas – SMR 01 usa predominantemente linhas variáveis discretas (pulsos) para a transmissão de dados, sem o uso de protocolos de comunicação. A integração de pulsos digitais dos medidores, bem como o envio de pulsos de comando para acionamento das válvulas de bloqueio são realizados no dispositivo calculador do SMR (concentrador), o qual é normalmente localizado na central de operações e coleta de dados do SMR.

Eventualmente, em função das necessidades do edifício, dois ou mais calculadores podem ser interligados. O SMR é considerado um sistema de medição eletrônico, tendo em vista a sua concepção. O SMR deve ser protegido contra campos magnéticos externos, descargas eletrostáticas e interferências eletromagnéticas de acordo com as resoluções Anatel nº 442 e 238.

Recomenda-se que o SMR seja concebido de forma a não ocasionar qualquer tipo de interferência em sistemas e/ou aparelhos típicos de uso urbano normalmente existentes nos edifícios. O SMR deve ser concebido de tal maneira que o restabelecimento do fornecimento de gás não possa ser realizado remotamente.

Os componentes elétricos/eletrônicos devem ser protegidos contra a ignição no caso de contato direto com gases combustíveis. O SMR deve ser concebido de tal maneira que não gere temperaturas superiores a 85 °C e choques elétricos por contato. Deve assegurar a integridade dos dados nele coletados e armazenados.

O SMR deve ser integralmente protegido contra surtos de tensão e corrente elétrica, através de dispositivos apropriados (DPS – dispositivo de proteção contra surtos). A especificação da classe do DPS deve estar de acordo com a NBR 5410, referente à especificidade de cada sistema. Deve ser protegido contra descargas atmosféricas, levando em conta as características locais da instalação e as interfaces com outros sistemas existentes.

A especificação da classe contra descargas atmosféricas deve estar de acordo com a NBR 5410 e com a especificidade de cada sistema. Os componentes do SMR instalados em área aberta devem ser protegidos contra ação dos agentes atmosféricos e da corrosão. Os invólucros que venham a ser utilizados devem possuir classificação mínima de proteção IP 65 em conformidade com a NBR IEC 60529.

O SMR deve garantir a continuidade da aquisição de dados de medição em casos de falta de alimentação principal por um período mínimo de 24 h. O SMR deve possibilitar a medição dos consumos individuais referente às economias e ao medidor coletivo (se houver). Deve possuir dispositivo indicador local, de livre acesso, que permita a visualização dos dados de leitura e alarmes disponíveis.

O SMR deve ter a capacidade de atualização manual das leituras remotas de acordo com as leituras indicadas nos totalizadores dos medidores, sempre que essa se fizer necessária. O SMR deve ter a capacidade de disponibilizar pelo menos uma leitura por dia. O SMR deve ter a capacidade de realizar testes periódicos de funcionamento da VBRP de água ou de gás.

Os protocolos para comunicação externa do SMR devem ser abertos de forma a garantir a sua total intercambiabilidade e interoperabilidade. Recomenda-se adotar as diretrizes preconizadas no Anexo B para a sua especificação. O SMR deve emitir alarmes em casos de falta de alimentação principal por um período superior a 3 h.

O SMR deve ter a capacidade de geração, registro e visualização de alarmes relativos a rompimento da selagem eletrônica. Para se obter acesso aos componentes do SMR, no caso de uso de selos mecânicos, cada selo deve ser removido, danificado ou quebrado. O SMR deve ser capaz de emitir alarmes de consumo ininterrupto de água ou gás por no mínimo 24 h.

O SMR deve emitir alarme quando ocorrer falta de integridade da comunicação desde os medidores e a válvula de bloqueio remoto acionada por pulso (VBRP) até o concentrador, de acordo com o ensaio descrito nessa norma. Se na rede interna da economia existir um VBRP operando em conjunto com SMR, este deve enviar um alarme se o transdutor de medição enviar dados ao SMR enquanto a VBRT estiver na posição fechada, o que representaria um vazamento de gás.

O SMR, quando submetido ao ensaio de verificação da integralização de pulsos dos medidores pelo SMR, não deve apresentar nenhuma variação entre as leituras coletadas no totalizador do medidor e no dispositivo indicador remoto. Os medidores devem atender às Portarias nº 31 (medidores de gás) e nº 246 (medidores de água) do Inmetro.

Os medidores devem ser dimensionados e instalados de acordo com as normas vigentes e os requisitos específicos dos fabricantes. Recomenda-se que os medidores a serem instalados na entrada da edificação e/ou nas áreas comuns sejam pré-equipados para interligação ao SMR. O transdutor de medição deve garantir a integridade da transmissão do sinal do medidor ao SMR. Deve atender rigorosamente às normas vigentes e aos requisitos específicos dos fabricantes.

Deve possuir características de funcionamento prolongado no mínimo iguais às do medidor no qual ele será instalado. O SMR, no que tange à sua operação associada com o transdutor de medição para medidores de gás, deve estar em conformidade com a NBR15526. O SMR, no que tange à a sua operação associada com o transdutor de medição, não deve ser afetado por violações magnéticas ou eletromagnéticas. Caso seja violado deve gerar um alarme para esta ocorrência.

Para o caso do uso de transdutores de medição tipo ampola de contato (reed switch), este requisito deve ser comprovado, por ocasião do comissionamento do SMR, através da execução de ensaio de influência de campo magnético externo. O transdutor de medição deve ser solidariamente fixado ao medidor e respeitar os requisitos mínimos de proteção IP65, de acordo com a NBR IEC 60529.

O subconjunto constituído por medidores, transdutores de medição, conexões dos transdutores dos medidores aos meios físicos e VBRP deve estar devidamente selado através de lacres apropriados. O subconjunto constituído por medidores, transdutores de medição, conexões dos transdutores dos medidores aos meios físicos e VBRP deve estar devidamente protegido contra choques mecânicos ou avarias de qualquer natureza.

Os dispositivos auxiliares não podem afetar as funções metrológicas do medidor e tão pouco a correta operação do SMR. O SMR deve possuir interface para comunicação com equipamentos de coleta de dados conforme protocolo delineado no Anexo B. O concentrador deve ser instalado permanentemente em área comum de livre acesso, protegida de intempéries, de forma a permitir sua conexão com sistemas de coleta de dados e auditagem.

O invólucro do concentrador deve possuir classificação mínima IP65 segundo a NBR IEC 60529. O concentrador deve armazenar de forma não volátil os dados de medição, permitindo sua conferência com o totalizador do medidor. A altura dos dígitos do indicador deve ser igual ou superior a 5 mm. Deve ser possível a leitura de maneira clara e sem ambiguidades a um ângulo de 55° tomando como referência um eixo perpendicular ao visor. O dispositivo indicador remoto deve possuir interfaces homem-máquina amigáveis e de simples operação. O dispositivo indicador remoto deve ser alojado em local protegido de intempéries.

A segurança para a construção dos elevadores unifamiliares

O elevador unifamiliar ou de uso por pessoas com mobilidade reduzida é projetado para atender a pessoas em edificações residenciais unifamiliares, melhorando o conforto na habitação e proporcionando uma previsão para eventual necessidade futura; tem uma função social ao prover acesso a pessoas com mobilidade reduzida, pessoas idosas, doentes ou com dificuldade de locomoção, permanente ou temporária, eliminando a limitação de acesso aos espaços físicos e provendo integração com a comunidade. Diferentemente de um elevador de passageiros para transporte de pessoas em geral, o elevador unifamiliar ou de uso por pessoas com mobilidade reduzida é projetado com características peculiares

que se destinam a ocupar menor espaço horizontal e vertical; viabilizar a instalação em edificações existentes; reduzir o custo total envolvido na sua implantação e manutenção; requerer pouca potência instalada e ser energeticamente econômico.

A estrutura da edificação deve ser construída de modo a suportar às cargas e forças exercidas pelo equipamento do elevador. Salvo especificado em contrário na norma, para aplicações particulares, estas cargas e forças são os valores resultantes das massas estáticas; e os valores resultantes de massas móveis e suas operações de emergência. O efeito dinâmico é representado por um fator 2. É importante que as guias do elevador sejam suportadas de modo que os efeitos da movimentação da estrutura da edificação à qual estão ligados sejam minimizados.

Ao considerar as edificações construídas de concreto, blocos pré-moldados ou tijolos, pode-se presumir que os suportes de guia não serão submetidos ao deslocamento causado pela movimentação das paredes da caixa, com exceção da compressão. No entanto, quando os suportes de guia estiverem fixados à estrutura da edificação por vigas de aço, ou por fixação a estruturas de madeira, pode haver deformação desta estrutura, devido à carga imposta pelo carro por meio das guias e suportes de guias.

Além disso, pode haver movimento da estrutura de apoio do elevador devido às forças externas, como carga de vento, carga de neve, etc. Devem ser consideradas qualquer deflexão dessas vigas ou estruturas durante os cálculos requeridos e a deflexão total admissível das guias para a operação segura do freio de segurança, etc. deve incluir qualquer deslocamento da guia devido à deflexão da estrutura da edificação e a deflexão da própria guia devido à carga imposta pelo carro. Portanto, é importante que as pessoas responsáveis pelo projeto e fabricação das estruturas se comuniquem com o fornecedor do elevador, a fim de assegurar que as estruturas atendam a todas as condições de carga.

O requisito para ventilar adequadamente a caixa e a casa de máquinas está, muitas vezes, inserido nos regulamentos locais sobre edificações que se aplicam, especificamente, como requisito geral que seria dado para qualquer espaço da edificação onde maquinaria seja instalada ou pessoas sejam acomodadas (para o lazer, trabalho etc.). A norma não pode prover orientação específica para os requisitos de ventilação para estas áreas, tendo em vista que a caixa e a casa de máquinas são frequentemente partes de um ambiente maior e mais complexo da edificação. Caso isto seja feito, pode trazer conflito com estes requisitos nacionais. No entanto, algumas orientações gerais podem ser providas.

A segurança e o conforto das pessoas que viajam no elevador, trabalham na caixa ou aqueles que podem ficar presos na cabina ou na caixa quando o carro para entre os andares depende de muitos fatores: a temperatura ambiente da caixa, como parte da edificação, ou independente dela; a exposição à luz solar direta; o componente orgânico volátil, CO2, qualidade do ar; o acesso de ar fresco na caixa; o tamanho da caixa, tanto na área da seção transversal quanto na altura; o número, tamanho e folgas das aberturas em torno das portas de pavimento; a produção de calor dos equipamentos instalados; as estratégias de evacuação no combate a incêndios e fumaça, relacionadas ao sistema de gerenciamento da edificação; a umidade, poeira e vapores; o fluxo de ar (calor/frio) e tecnologia aplicada de economia de energia na edificação; e a estanqueidade do ar na caixa e em toda edificação.

É recomendado que o carro seja provido com aberturas de ventilação suficientes para assegurar um fluxo adequado de ar para o número máximo de ocupantes permitidos. Durante a operação normal e a manutenção do elevador, geralmente as aberturas em torno das portas de pavimento, a abertura/fechamento destas portas e o efeito pistão, devido ao deslocamento do elevador dentro da caixa, podem ser suficientes para prover as necessidades humanas de troca de ar, entre as escadas, saguões e a caixa.

No entanto, para as necessidades técnicas e, em alguns casos, para as necessidades humanas, o estancamento do ar na caixa e em toda edificação, as condições ambientais, particularmente superior à temperatura ambiente, radiação, umidade, qualidade do ar, irá resultar em necessidade permanente ou demanda de abertura (s) de ventilação e/ou (combinado com) ventilação forçada e/ou a entrada de ar fresco. Isso somente pode ser decidido caso a caso.

Além disso, no caso de parada prolongada do carro (considerando as condições normais e acidentais), é recomendado que seja fornecida ventilação suficiente. Em particular, deve ser dada atenção para aquelas edificações (novas e no caso de renovação) nas quais o projeto tecnológico de eficiência energética esteja presente. As caixas não se destinam a serem utilizadas como meios para ventilar outras áreas da edificação.

Em alguns casos, isso pode ser uma prática extremamente perigosa, como ambientes industriais ou estacionamentos subterrâneos, onde a extração de gases perigosos através da caixa pode causar risco adicional para as pessoas que viajam na cabina. De acordo com estas considerações, não é recomendado utilizar o ar viciado a partir de outras áreas da edificação para ventilar a caixa.

Quando a caixa fizer parte da segurança contra incêndio, cuidados especiais devem ser tomados. Nestes casos, as orientações devem ser obtidas por aqueles que se especializam nesse tipo de equipamento ou em regulamentos locais de construção e combate a incêndio.

A fim de permitir que a pessoa responsável pelo projeto e construção da edificação determine se/qual ventilação precisa ser fornecida relacionando todas as instalações de elevadores como parte da edificação, é recomendado que o instalador do elevador forneça as informações necessárias para permitir o cálculo adequado do projeto de construção a ser realizado. Em outras palavras, recomenda-se que eles se mantenham mutuamente informados dos fatos necessários e por outro lado, tomem as medidas adequadas para garantir o bom funcionamento e utilização segura e manutenção do elevador dentro da edificação.

A ventilação da casa de máquinas é normalmente realizada para fornecer um ambiente de trabalho apropriado ao técnico e ao equipamento instalado em tais espaços. Por esta razão, é recomendado que a temperatura ambiente da casa de máquinas seja mantida conforme provido nas premissas. Recomenda-se cuidados adicionais em relação à umidade e qualidade do ar para evitar problemas técnicos, por exemplo, condensação.

A falha em manter estas temperaturas pode resultar na retirada do elevador de serviço automaticamente até que a temperatura volte a ter seus níveis pretendidos. A fim de permitir que a pessoa responsável pelo projeto e construção da edificação determine se/qual ventilação precisa ser fornecida relacionando todas as instalações de elevadores como parte da edificação, é recomendado que o instalador do elevador forneça as informações necessárias para permitir o cálculo adequado do projeto de construção a ser realizado. Em outras palavras, recomenda-se que eles se mantenham mutuamente informados dos fatos necessários e por outro lado, tomem as medidas adequadas para garantir o bom funcionamento e utilização segura e manutenção do elevador dentro da edificação.

A NBR 12892 de 10/2022 – Elevadores unifamiliares ou de uso por pessoas com mobilidade reduzida – Requisitos de segurança para construção e instalação especifica os requisitos de segurança para instalação permanente de novos elevadores unifamiliares ou de uso por pessoas com mobilidade reduzida com limitação de capacidade, velocidade e percurso, com acionamento por tração ou acionamento hidráulico, servindo níveis de pavimento definidos, sendo o carro projetado para o transporte de pessoas e objetos, suspenso por cabos, cintas ou pistões e movimentando-se entre guias inclinadas não mais que 15° em relação à vertical. Em casos especiais, em complementação aos requisitos desta norma, devem ser considerados os requisitos suplementares (condições climáticas extremas, umidade, salinidade, etc.).

Esta norma não é aplicável: a elevadores com outros sistemas de acionamento diferentes dos mencionados na NBR 12892; a segurança durante as operações de transporte, montagem, reparação e desmontagem de elevadores; a ruídos e vibrações; ao uso de elevadores em caso de incêndio; e aos elevadores de passageiros instalados antes da data de sua publicação.

Com o propósito de preservar a segurança, foram impostos requisitos de desempenho no sentido de eliminar ou minimizar riscos para o uso peculiar a que se destina. Percurso, velocidade, capacidade, área da cabina, entre outras, são grandezas objeto de restrição para atender ao disposto nessa norma.

Quanto à instalação, são estabelecidas somente as seguintes aplicações: instalação em edificações unifamiliares; o elevador, conforme esta norma, não pode ser considerado para o cálculo de tráfego da NBR 5665, mas pode ser utilizado como meio de transporte de pessoas e como meio de acesso das pessoas com mobilidade reduzida à edificação; quando o elevador, conforme esta norma, for projetado para uso por pessoas com mobilidade reduzida, esta condição de uso deve ser sinalizada; capacidade de até oito passageiros; velocidade nominal até 0,35 m/s; percurso até 12 m; portas de pavimentos do tipo eixo vertical são aplicáveis somente em elevador residencial unifamiliar; e porta de cabina do tipo dobrável é aplicável somente em elevador residencial unifamiliar.

Devem ser feitas negociações para cada contrato entre o cliente e o fornecedor/instalador sobre: a finalidade do uso do elevador; condições ambientais; problemas de engenharia civil; outros aspectos relacionados à edificação e ao local da instalação; a resistência ao fogo para as portas de pavimento nas aplicações unifamiliares. Não é intenção de esta norma limitar o desenvolvimento tecnológico do produto. Entretanto, um projeto novo deve atender, pelo menos de maneira equivalente, aos requisitos de segurança desta norma.

Foram considerados possíveis riscos atribuíveis a cada componente que podem ser incorporados em uma instalação completa de elevador. Regras adequadas foram estabelecidas, considerando-se o descrito a seguir. Os componentes são: projetados de acordo com a prática usual de engenharia e os códigos de cálculos, incluindo todos os critérios de falha; de construção adequada tanto mecânica como eletricamente; fabricados com materiais de resistência e qualidade adequadas; e livres de defeitos. Materiais nocivos, como amianto, não podem ser utilizados.

Os componentes são mantidos em bom estado de conservação e funcionamento, de modo que as dimensões se mantenham, apesar do desgaste. Considera-se que todos os componentes do elevador requerem inspeção para garantir a operação segura e contínua durante a sua utilização. As folgas operacionais especificadas na norma devem ser mantidas não somente durante a inspeção e ensaios antes de o elevador ser colocado em serviço, porém também ao longo da vida útil do elevador.

Os componentes que não requerem manutenção (por exemplo, livre de manutenção, lacrado por toda vida útil) ainda são obrigados a estar disponíveis para inspeção. Os componentes são selecionados e instalados de modo que as influências ambientais previsíveis e as condições especiais de trabalho não afetem a operação segura do elevador. Por projeto dos elementos que suportam carga, uma operação segura do elevador é considerada para cargas variando de 0% até 100% da carga nominal, acrescida da sobrecarga mínima de 10% e deve atender aos ensaios desta norma.

Os requisitos desta norma sobre os dispositivos elétricos de segurança são tais que a possibilidade de falha de um dispositivo elétrico de segurança, que atenda a todos os requisitos dessa norma, não precisa ser considerada. Os usuários devem ser protegidos contra a sua negligência e descuido inconscientes ao utilizar o elevador do modo estabelecido. Considerou-se que um usuário pode, em certos casos, cometer um ato imprudente.

A possibilidade de cometer dois atos imprudentes simultâneos e/ou a má utilização de instruções de uso não foi considerada. Se durante o desenvolvimento do trabalho de manutenção um dispositivo de segurança, normalmente não acessível aos usuários for deliberadamente neutralizado, a operação segura do elevador não é mais assegurada, porém medidas compensatórias devem ser tomadas para garantir a segurança dos usuários de acordo com as instruções de manutenção.

Foi considerado que o pessoal de manutenção está instruído e trabalha de acordo com as instruções. Para reproduzir forças horizontais que uma pessoa pode exercer, foram utilizados os seguintes valores de forças estáticas: 300 N; 1.000 N, onde um impacto pode ocorrer. Com exceção dos itens listados, um dispositivo mecânico construído de acordo com as boas práticas e com os requisitos desta norma não irá deteriorar-se a ponto de criar perigo sem que a falha seja detectada.

As seguintes falhas mecânicas foram consideradas nesta norma: quebra da suspensão; deslizamento sem controle dos cabos na polia motriz; quebra e afrouxamento de toda a ligação dos seguintes elementos auxiliares: cabos; correntes; e correias. Inclui a falha de um dos componentes mecânicos do freio eletromecânico que toma parte na ação de frenagem no tambor ou disco; a falha de um componente associado com os elementos de acionamento principais e a polia motriz; a ruptura no sistema hidráulico (cilindro excluído); e pequenos vazamentos no sistema hidráulico (cilindro incluso).

Ocorrendo a queda livre do carro a partir do pavimento extremo inferior, a possibilidade de o freio de segurança não atuar, antes que o para-choque seja atingido, é considerada aceitável. Em caso de elevadores com acionamento hidráulico, providos de dispositivos contra queda livre ou a descida com velocidade excessiva, que parem o carro completamente (por exemplo, freio de segurança, válvula de queda), a possibilidade de o carro bater no para-choque com velocidade excedendo 115% da velocidade nominal de descida não pode ser considerada.

Quando a velocidade do carro está vinculada com a frequência elétrica da rede até o momento da aplicação do freio mecânico, é considerado que a velocidade não exceda 115% da velocidade nominal. Desde que nenhuma das falhas mencionadas ocorra, supõe-se que a velocidade do carro no sentido de descida com qualquer carga (até a carga nominal) não excede a velocidade nominal de descida em mais de 8%.

A caixa está devidamente ventilada, conforme regulamento da construção nacional, considerando a dissipação do calor conforme especificado pelo fabricante. Os acessos às áreas de trabalho devem ser adequadamente iluminados. O sistema de fixação das proteções utilizadas especificamente para proteção das pessoas contra riscos mecânicos, elétricos ou qualquer outro, por meio de uma barreira física, que tenha que ser removida durante a manutenção e inspeção regular, permanece solidário à proteção ou ao equipamento quando a proteção for removida.

O elevador unifamiliar ou de uso por pessoas com mobilidade reduzida deve atender aos requisitos de segurança e medidas de proteção desta norma. Além disso, o elevador unifamiliar ou de uso por pessoas com mobilidade reduzida deve ser projetado de acordo com os princípios da NBR ISO 12100, para perigos relevantes, porém não significativos, que não são tratados por esta norma (por exemplo, arestas vivas).

Esta norma foi desenvolvida tendo por base as formas construtivas usuais. Não é intenção desta norma limitar o ingresso de novas tecnologias, como por exemplo, manutenção de equipamento a partir do interior da cabina, desde que comprovadas sua eficiência, segurança e aplicação por órgão certificador reconhecido. Todos os rótulos, avisos, marcações e instruções de operação devem ser afixados permanentemente, indeléveis, legíveis e facilmente compreensíveis (se necessário, auxiliados por sinais ou símbolos). Eles devem ser de material durável, colocados em uma posição visível e redigidos no idioma do país onde o elevador está instalado (ou, se necessário, em vários idiomas).

Quando o peso, as dimensões e/ou a forma dos componentes impedirem que estes sejam movimentados manualmente, eles devem ser: equipados com fixadores para mecanismo de levantamento; ou projetados de modo que possam ser montados tais fixadores (por exemplo, por meio de furos roscados); ou projetados de modo que um mecanismo de levantamento padronizado possa facilmente ser acoplado. As forças horizontais e/ou energias a serem consideradas estão indicadas nas seções aplicáveis desta norma.

Normalmente, quando não especificada nesta norma, a energia exercida por uma pessoa resulta em uma força estática equivalente a: 300 N; 1.000 N onde o impacto pode ocorrer.

Deve-se atentar para os requisitos referentes à caixa que se destina a proteger o carro do elevador e todas as suas partes móveis, bem como servir de estrutura para fixação de componentes e partes do elevador, como guias, suportes, dispositivos de segurança, portas de pavimento e portas de emergência. É desejável que a caixa ocupe pouco espaço e se constitua em elemento arquitetônico de integração do elevador ao ambiente.

O contrapeso (se provido) do elevador deve estar na mesma caixa do carro. Em todos os casos em que houver, embaixo do poço, recinto utilizado por pessoas, o fundo do poço deve ser calculado conforme descrito a seguir. Se os espaços abaixo do carro ou do contrapeso (se provido) forem acessíveis, a base do poço deve ser projetada para resistir a uma carga de no mínimo 5.000 N/m² e o contrapeso (se provido) deve ser equipado com freio de segurança. O pistão do elevador com acionamento hidráulico deve estar na mesma caixa do carro. Ele pode prolongar-se sob o poço ou outros espaços.

A caixa deve ser totalmente fechada por paredes, piso e teto sem perfurações. As únicas aberturas permitidas são as aberturas para portas de pavimento; as aberturas para portas de inspeção e emergência da caixa; as aberturas para saída de gases e fumaça em caso de incêndio; as aberturas de ventilação; as aberturas necessárias para o funcionamento do elevador entre a caixa e as casas de máquina ou de polias.

Quando não for requerido que a caixa contribua na proteção da edificação contra a propagação do fogo, pode-se admitir proteção de vidro. As folhas de vidro, plano ou conformado, devem ser laminadas. As folhas de vidro e os seus meios de fixação devem resistir a uma força estática horizontal de 1.000 N em uma área de 0,30 m x 0,30 m, em qualquer ponto, tanto de dentro como de fora da caixa, sem deformação permanente.

A caixa deve ser convenientemente ventilada e não pode ser utilizada para ventilação de locais alheios ao serviço do elevador. Se não houver meios de fuga para pessoa (s) presa (s) na caixa para conseguir auxílio externo, um sistema de alarme deve ser instalado quando existir o risco de aprisionamento, operado a partir do (s) espaço (s) de refúgio, garantindo comunicação por voz de duas vias. Este sistema deve permitir contato com o serviço de resgate de forma: direta, via sistema remoto, conforme NBR 16756, ou indireta, via intercomunicação com a portaria.

Quando for aplicado o bloqueio mecânico eliminando o risco de aprisionamento na área de trabalho no topo da cabina ou no poço, não há necessidade de instalação do sistema de alarme. Se houver riscos de enclausuramento em áreas fora da caixa, esses riscos devem ser discutidos com o proprietário da edificação.

A Qualidade normativa dos cilindros hidráulicos

Em sistemas de energia de fluido hidráulico, a energia é transmitida e controlada através de um líquido sob pressão que circula dentro de um circuito fechado. Um componente de tal sistema é o cilindro de potência do fluido hidráulico. É um dispositivo que converte energia fluida em força mecânica linear e movimento. Consiste em um elemento móvel, ou seja, um pistão e haste do pistão, operando dentro de um furo cilíndrico.

Eles podem ser encontrados em quase todas as máquinas hidráulicas que requerem uma forte força de empurrão ou tração e são usados ​​em uma infinidade de indústrias, incluindo manufatura, construção, mineração e offshore. Um cilindro hidráulico é um atuador mecânico usado para converter energia hidráulica em movimento linear para realizar a ação desejada da máquina, como levantar, pressionar ou mover.

A carcaça de um cilindro hidráulico consiste em um barril com portas separadas para entrada e saída de fluido e um pistão dentro do qual separa o tubo em duas câmaras. O pistão está conectado a uma haste que se move para frente e para trás dentro do cilindro quando exposta à pressão.

A câmara é parcialmente preenchida com fluido hidráulico, deixando espaço suficiente para o pistão operar. O fluido alimenta o cilindro, transmitindo uma força que retrai ou estende o pistão. À medida que a primeira câmara é preenchida com fluido hidráulico, ela atua no pistão forçando-o a se estender e expelindo fluido da segunda câmara. Se a segunda câmara for então preenchida, o pistão se retrai e o fluido é expelido da primeira câmara.

Esse processo gera movimentos de empurrar e puxar, fornecendo a grande força linear necessária para que uma máquina execute a operação necessária. Tal como acontece com todos os outros componentes e aplicações hidráulicas, os cilindros hidráulicos funcionam com base na lei de Pascal. A teoria por trás disso é que, como os fluidos hidráulicos são incompressíveis, a força gerada no pistão transmite uma pressão igual por todo o cilindro. Portanto, a força aplicada internamente será igual à força de saída especificada.

Para a preparação para o ensaio, o cilindro sob análise deve ser montado horizontalmente sem nenhuma carga móvel adicional. A proporção de pressão entre as duas câmaras deve ser inversamente proporcional às áreas do embolo de modo a balancear as forças em ambas as câmaras.

O ensaio pode ser montado verticalmente, caso requerido pela aplicação ou acordado. Neste caso, o peso deve ser considerado nos cálculos de força de atrito. A velocidade máxima de ensaio vk deve ser de 0,05 m/s e deve ser atingida dentro dos primeiros 5 % da amplitude.

No caso de a potência disponível ser insuficiente para atingir a velocidade máxima de ensaio, vk, a velocidade máxima de ensaio será resultado da vazão de óleo disponível. É recomendado que os fabricantes utilizem uma das seguintes declarações, conforme aplicável, em relatórios de ensaios, catálogos e literatura de vendas quando decidirem estar de acordo com este documento.

– Cilindros hidráulicos ensaiados de acordo com a NBR ISO 10100:2022, Sistemas hidráulicos – Cilindros – Ensaios de aceitação para cilindros ensaiados com o Módulo L.

– Cilindros hidráulicos ensaiados de acordo com a NBR ISO 10100:2022, Sistemas hidráulicos – Cilindros – Ensaios de aceitação para cilindros ensaiados com o Módulo L e P.

– Cilindros hidráulicos ensaiados de acordo com a NBR ISO 10100:2022, Sistemas hidráulicos – Cilindros – Ensaios de aceitação para cilindros ensaiados com o Módulo L e F.

– Cilindros hidráulicos ensaiados de acordo com a NBR ISO 10100:2022, Sistemas hidráulicos – Cilindros – Ensaios de aceitação” para cilindros ensaiados com o Módulo L, P e F.

Enfim, a maioria dos tipos de cilindros se enquadram em duas categorias. Os cilindros de simples ação, em um cilindro de simples ação, o fluido só pode atuar em um lado da haste do pistão. Para operar o cilindro da extremidade oposta, outra força, como a pressão da mola ou o peso da carga, deve ser aplicada.

Os cilindros de dupla ação podem exercer força em duas direções, permitindo que a haste atinja movimentos de ida e volta sob a força do líquido de ambos os lados da câmara. Nestas categorias, existem muitas variações na construção para criar diferentes tipos de cilindros. A diferença entre eles depende principalmente de como as duas tampas são presas ao cano, juntamente com os materiais e a espessura da parede.

A NBR ISO 10100 de 09/2022 – Sistemas hidráulicos – Cilindros – Ensaios de aceitação especifica a aceitação e os ensaios funcionais para cilindros hidráulicos. Em sistemas hidráulicos, a energia é transmitida e controlada por meio da circulação de um líquido sob pressão dentro de um circuito fechado. Um componente desse sistema é o cilindro hidráulico. Esse é o dispositivo que converte a energia hidráulica em uma força linear mecânica e em movimento.

Ele consiste em um elemento móvel, por exemplo, um pistão e haste, operando dentro de um cilindro. As seguintes informações sobre o cilindro a ser ensaiado devem ser registradas: tipo; tamanho, tipo e orientação do pórtico; se o cilindro possuir amortecimento, verificação da localização e orientação adequada dos parafusos de regulagem; curso do cilindro; etiqueta do modelo; diâmetro interno do cilindro; diâmetro da haste; extensão e configuração da haste do pistão; e o tipo ou estilo de fixação e, onde aplicável, posição da superfície variável de fixação. Na figura abaixo pode-se conferir a identificação de um cilindro de haste dupla (passante) e a identificação de cilindros de haste simples.

Inserir cilindro2

O óleo hidráulico (ou outro líquido cujo fabricante do cilindro e usuário concorde), que esteja em conformidade com as ISO 6743-4, ISO 7745 ou ISO 15380 e seja compatível com os materiais de vedação usados no cilindro ensaiado, deve ser o meio de ensaio. O fluido usado no circuito de ensaio deve estar de acordo com o descrito a seguir. O nível de contaminação do fluido deve ser 19/16 ou 19/16/13, expresso de acordo com a ISO 4406:2017, ou inferior.

Para aquelas aplicações que requerem um elevado nível de limpeza do fluido, por exemplo, para cilindros com servoválvulas ou elementos de vedação sensíveis a contaminação, o nível de contaminação do fluido deve ser 16/13 ou 16/13/10 de acordo com o especificado na ISO 4406:2017. A temperatura do fluido durante o ensaio deve ser mantida entre 35 °C e 55 °C. Outras faixas de temperatura devem ser acordadas entre o fabricante e o usuário.

Os inibidores de oxidação que previnem a corrosão dentro do cilindro podem ser adicionados ao fluido, desde que sejam compatíveis com os materiais de vedação usados no cilindro sob ensaio. Para o ensaio de estanqueidade em baixa pressão, deve-se realizar o ciclo do cilindro com no mínimo 500 kPa (5 bar) para cilindros com diâmetro interno maior do que 32 mm e com até 1.000 kPa (10 bar) para cilindros com diâmetro interno menor ou igual a 32 mm, três ou mais vezes até a posição final.

Parar em uma das posições finais por no mínimo 10 s. É recomendado que a pressão seja aplicada por mais tempo durante as pausas em cilindros de diâmetros maiores. Para o ensaio visual, verificar a ausência de vibração ou irregularidades durante o movimento. Quando o pistão chegar ao curso final, o curso total deve ser medido. Observar o vazamento do fluido na vedação da haste.

Quando o ensaio terminar, qualquer camada de óleo presente na haste deve ser insuficiente para formar uma gota ou um anel de óleo na haste. Verificar a ausência de vazamento de fluido em todas as vedações estáticas e verificar a ausência de vazamento de fluido nos parafusos de regulagem ou nas válvulas de retenção ou nos amortecedores de fim de curso.

Se quaisquer componentes do cilindro forem vedados por uma solda, verificar a ausência de vazamento de fluido no cordão de solda. Se o cilindro incorporar um amortecimento ou amortecimentos de fim de curso e possuir parafusos de regulagem, os parafusos devem ser ajustados fixados a uma posição ligeiramente aberta. Verificar se a montagem do pistão com a haste mostra um efeito de desaceleração antes do seu contato com o (s) cabeçotes (s) do cilindro.

Um ensaio de pressão de 1,5 vez a pressão nominal do cilindro ou pressão de operação recomendada deve ser aplicado alternadamente em ambas as extremidades do cilindro e mantido por pelo menos 10 s.

É recomendado que a pressão seja aplicada por mais tempo em ambas extremidades em cilindros de diâmetros maiores. No ensaio visual, deve ser verificada a integridade estrutural do cilindro e a ausência de vazamento de fluido em todas as vedações estáticas. Deve ser verificada a ausência de vazamento de fluido no parafuso de regulagem ou na válvula de retenção de amortecimento de fim de curso, quando aplicável.

Se quaisquer componentes do cilindro forem vedados por uma solda, deve ser verificada a ausência de vazamento de fluido no cordão de solda (s). O módulo P, ensaio de estanqueidade da vedação do êmbolo (opcional) é um ensaio é requerido somente se especificado pelo usuário. Uma pressão de ensaio igual à pressão nominal do cilindro ou uma pressão de ensaio especificada pelo usuário deve ser aplicada ao cilindro. No ensaio visual, deve ser verificada a ausência de vazamento do fluido na vedação do pistão.

O módulo F, ensaio de força de atrito (opcional) é requerido se especificado pelo usuário. As forças de atrito em cilindros hidráulicos devem ser determinadas pela medição de pressão diferencial em um circuito eletro-hidráulico. Para este propósito, as hastes dos cilindros hidráulicos devem ser movimentadas com controle de posição em malha fechada com válvulas de controles e transdutores de posição apropriados.

Os transdutores de pressão adequados devem ser integrados as duas câmaras do cilindro. Ambas as pressões das câmaras e a posição da haste devem ser continuamente medidas em cada estágio de pressão pa = 5 MPa,10 MPa, 15 MPa, 20 MPa e 25 Mpa2) durante dois ciclos de avanço e recuo completos. Se a pressão de trabalho permitida for menor do que a pressão de ensaio mencionada neste documento, nenhuma medição deve ser efetuada com estas altas pressões.

Apenas 26% das empresas de óleo e gás utilizam as tecnologias digitais

Uma pesquisa da KPMG apontou que apenas 26% das companhias de petróleo e gás, que participaram do levantamento, aplicam tecnologias disponíveis. Alguns desses recursos são drones, visualização 3D, análise de dados e inteligência artificial utilizados para melhorar a forma como é feita a gestão de ativos, reduzindo o tempo de parada das unidades de processamento e a exposição a riscos. Essas são as principais conclusões do relatório denominado Nos trilhos da jornada digital que tem como objetivo mostrar de forma inédita como essa a indústria está lidando, na era pós-pandemia, com temas como a digitalização, uso de novas tecnologias e de dados.

Segundo o estudo, 29% dos entrevistados possuem uma equipe bem preparada para implantação de um processo de automação na indústria contra 48% que consideram não estarem aptos para aplicar esse método. Quase metade dos entrevistados (42%) afirma que as organizações estão prontas para uma mudança na matriz energética, sendo capazes de repor o portfólio de ativos pelos originados de fontes alternativas de energia.

“O relatório mostrou que um percentual pequeno de empresas de petróleo e gás utiliza as tecnologias disponíveis. Por isso, a indústria ainda tem muito a fazer com relação ao processo de transformação digital que pode aprimorar a gestão do negócio”, afirma o sócio do setor de energia e recursos naturais da KPMG, Anderson Dutra.

Na verdade, as empresas de petróleo e gás estão repensando as suas estratégias, buscando a oportunidade perfeita para reavaliar sua infraestrutura e fazer investimentos inteligentes em tecnologia para trazer seus sistemas para a era moderna. Por exemplo, os investimentos certos em tecnologia da informação e comunicação (TIC) e outras soluções digitais podem contribuir muito para aumentar a lucratividade e impulsionar a eficiência da organização para criar uma operação mais robusta.

De acordo com a McKinsey, investir em tecnologias digitais pode economizar às empresas de gás até 20% em despesas de capital e 5% em custos operacionais upstream. Com isso em mente, pode-se descrever algumas tecnologias nas quais as empresas de petróleo e gás estão cada vez mais investindo.

– Big data e análises – As empresas de petróleo e gás não podem se dar ao luxo de tomar decisões com base em seus instintos. Os projetos de perfuração são empreendimentos que exigem muito capital e maquinário pesado, e as organizações não podem se dar ao luxo de nenhuma margem de erro. É por isso que um número crescente de organizações está coletando mais e mais dados e executando análises para determinar o caminho mais inteligente a seguir. Com big data, pode ser mais fácil tomar as decisões certas.

– IIoT e computação de ponta – A internet das coisas industrial (IIoT) promete otimizar grande parte do setor de petróleo e gás, com dispositivos conectados coletando dados na origem e executando cargas de trabalho de computação de ponta para fornecer às organizações as informações de que precisam para garantir operações eficientes.

– Computação na nuvem – As empresas de petróleo e gás continuam a alavancar o poder da nuvem, aumentando a acessibilidade e disponibilidade de dados e, ao mesmo tempo, criando redundâncias em suas redes.

Inteligência artificial (IA) e aprendizado de máquina – A IA e o aprendizado de máquina estão mudando todos os setores, incluindo petróleo e gás. A IA, por exemplo, permite que as organizações transformem uma realidade prática acessível para qualquer pessoa.

– Robótica e drones – Devido às eficiências operacionais que fornecem, cada vez mais empresas de petróleo e gás estão investindo em robótica e drones. Esta categoria é projetada para ser a área de crescimento mais rápido para a indústria nos próximos três a cinco anos.

– Redes 5G – Na era digital, a velocidade é o que mais importa. É por isso que mais e mais organizações de petróleo e gás estão investindo em redes 5G que fornecem velocidade e conectividade incomparáveis.

– Ferramentas colaborativas – As empresas globais de petróleo e gás têm operações espalhadas por todo o mundo. Ao investir em ferramentas de colaboração, eles são capazes de garantir que todos os funcionários possam permanecer na mesma página – não importa onde estejam.

Para o setor, segundo alguns especialistas, fazer uso de conectividade digital avançada poderá otimizar o rendimento da perfuração e da produção, e melhorar a manutenção e as operações de campo. Esse processo pode agregar até US$ 250 bilhões de valor às operações upstream da indústria até 2030.

Desse valor, entre US$ 160 e US$ 180 bilhões poderiam ser realizados com a infraestrutura existente, enquanto US$ 70 bilhões adicionais poderiam ser desbloqueados com satélites em órbita terrestre baixa e tecnologias 5G de próxima geração. Além disso, as empresas poderiam reduzir custos, incluindo despesas operacionais e de capital, em 20% a 25% cento por barril, contando com conectividade para implantar as ferramentas digitais.

Para ajudar no processo de gestão das indústrias de petróleo e gás, a ABNT ISO/TS 29001 de 10/2010 – Indústrias do petróleo, gás natural e petroquímica – Sistemas de gestão da qualidade específicos do setor – Requisitos para organizações de fornecimento de produtos e serviços especifica requisitos para um sistema de gestão da qualidade, quando uma organização necessita demonstrar sua capacidade para fornecer produtos que atendam de forma consistente aos requisitos do cliente e requisitos estatutários e regulamentares aplicáveis. Esta Especificação Técnica tem como objetivo desenvolver um sistema de gestão da qualidade que promova a melhoria contínua, enfatizando a prevenção de defeitos e a redução da variabilidade e de perdas na cadeia de suprimento e na prestação de serviços.

Em conjunto com os requisitos específicos de clientes, define os requisitos fundamentais do sistema de gestão da qualidade para aqueles que adotarem esta especificação técnica que é baseada na NBR ISO 9001. Assim, pode-se evitar múltiplas auditorias de certificação e fornecer uma abordagem comum para um sistema de gestão da qualidade para as indústrias do petróleo, gás natural e petroquímica. O procedimento documentado deve identificar as funções responsáveis pela coleta e manutenção dos registros.

A NBR ISO 14224 de 10/2011 – Indústrias de petróleo e gás natural – Coleta e intercâmbio de dados de confiabilidade e manutenção para equipamentos fornece uma ampla base para a coleta de dados de confiabilidade e manutenção (RM) num formato-padrão para equipamentos em todas as instalações e operações nas indústrias de petróleo, gás natural e petroquímica durante o ciclo de vida operacional dos equipamentos. Ela descreve os princípios da coleta de dados e os termos e definições associados que constituem uma linguagem de confiabilidade que pode ser útil para a comunicação da experiência operacional.

API STD 1164: a segurança cibernética de sistemas de controle de dutos

A API STD 1164:2021 – Pipeline Control Systems Cybersecurity fornece os requisitos e a orientação para o gerenciamento de risco cibernético associado a ambientes de automação e controle industrial (industrial automation and control – IAC) para atingir os objetivos de segurança, integridade e resiliência. Dentro dessa norma, isso é realizado por meio do isolamento adequado de ambientes IAC para ajudar na sua continuidade operacional.

Mesmo com o isolamento adequado dos ambientes IAC dos ambientes de TI, ambos desempenham um papel na continuidade geral dos negócios. A continuidade operacional do IAC e a continuidade do sistema de TI são frequentemente desenvolvidas e implementadas em conjunto como parte do plano geral de continuidade de negócios.

O escopo desta norma é limitado apenas aos aspectos de segurança cibernética da IAC que podem influenciar a continuidade geral dos negócios. Ela foi feita sob medida para a indústria de dutos de petróleo e gás natural (oil and natural gas – ONG), que inclui, mas não está limitado a sistemas de dutos de transmissão de gás natural e líquidos perigosos, sistemas de dutos de distribuição de gás natural, instalações de gás natural liquefeito (GNL), instalações de ar propano e outros envolvidos nessas indústrias.

Essa norma foi desenvolvida para fornecer uma abordagem acionável para proteger as funções essenciais do IAC, gerenciando o risco de segurança cibernética para os ambientes IAC. Isso pode incluir, mas não estão limitados a soluções de controle de supervisão e aquisição de dados (Scada), controle local e internet das coisas industriais (IIoT).

A norma deve ser usada no contexto de desenvolvimento, implementação, manutenção e melhoria de um programa de segurança cibernética do IAC, que inclui as políticas, processos, e controles de procedimentos e técnicos para ambientes cibernéticos IAC. Trata-se de um conjunto de requisitos que deve ser customizado antes da implementação usando os processos de gerenciamento de riscos da empresa.

O resultado é um conjunto de requisitos personalizados e específicos da empresa para um programa de segurança cibernética IAC a fim de ajudar a gerenciar a postura de segurança cibernética e qualquer risco residual resultante para seus ambientes IAC em alinhamento com a missão, objetivos e estratégia de risco da empresa, e de acordo com as suas políticas e procedimentos. Embora a identificação de ameaças e impactos seja crítica para o desenvolvimento do programa de segurança cibernética do IAC, uma avaliação baseada no risco de cada um garantirá que o programa seja implementado, executado e sustentado de forma adequada, de acordo com a postura de risco desejada pela organização.

Essa norma se concentra nos resultados de segurança cibernética desejados, definindo requisitos para níveis de proteção de impacto de objetivos de negócios específicos. Embora os princípios definidos nesta norma possam ser aplicados a sistemas instrumentados de segurança (safety instrumented systems – SIS), eles estão fora do escopo deste documento.

Os requisitos de segurança especificados nesta norma não tentam abordar os impactos potenciais para a seleção ou determinação do nível de integridade de segurança (safety integrity level – SIL) do SIS. Qualquer uso desta norma em ambientes SIS fica por conta e risco do implementador. Para as empresas que já têm um programa de segurança cibernética IAC, incluindo uma ou mais políticas de programa aprovadas e um plano ou planos de segurança cibernética IAC documentados implementados ou em implementação, esta norma deve ser considerada um acréscimo aos elementos existentes do programa de segurança cibernética.

Nessas situações, um processo de mapeamento desta norma para os elementos atuais do programa de segurança cibernética da IAC determinará quaisquer requisitos da API 1164 que não estejam atualmente no programa existente. A implementação de quaisquer elementos ausentes deve ser adaptada e priorizada usando os processos de gerenciamento de risco da empresa. O processo de adaptação para os requisitos de segurança cibernética API 1164 é descrito em 5.5.

Conteúdo da norma

1 Escopo. . . . . .. . . . . . . . . . . 1

1.1 Objetivo. . . .. . . . . . . . . . . 1

1.2 Público-alvo. . . . . . . . . . . . 2

1.3 Como ler esta norma . . . . . . . 2

2 Referências normativas. . . . . . . 4

3 Termos, definições, acrônimos e abreviações. .  . . . 4

3.1 Termos e definições. . .. . . . . . . . . . . . . . . . 4

3.2 Siglas. . . . . . . . . . . . . . . . . . . . . . 9

4 Perfis de cibersegurança de dutos IAC de ONG. .  . . 10

4.1 Introdução ao perfil de cibersegurança IAC. …. . 10

4.2 Perfil de segurança cibernética da IAC – restrições comuns………..10

4.3 Perfil de segurança cibernética da IAC – objetivos da proteção contra ameaças. . . . . . . . . . . . . 11

4.4 Perfil de segurança cibernética da IAC – objetivos de missão e negócios. . . . . . . . . . . . . 12

4.5 IAC: perfil de segurança cibernética – objetivos e impacto no mapeamento de proteção contra ameaças. . .  . 13

5 Política, plano e programa de segurança cibernética da ONG e IAC. . . . . . . . . . . . . . . 13

5.1 Plano de desenvolvimento de segurança cibernética da IAC. . . . . . . . . . . . . . . . . . . . . 15

5.2 IAC: plano de segurança cibernética – gerenciamento de risco. . . . .. . . . . . . . 15

5.3 Plano de segurança cibernética da IAC – operacionalizando um programa de segurança cibernética . . . . . . 17

5.4 Perfis de segurança cibernética de seleção de planos de segurança cibernética da IAC. . . . . . . . . . . 18

5.5 Requisitos de perfil selecionado de personalização do plano de segurança cibernética da IAC. . . . . 27

6 ONG IAC: requisitos do perfil de cibersegurança – requirements identify (ID). . . . . . . . 28

6.1 Governança (ID.GV). .. . . . . . . . . 28

6.2 Estratégia de gerenciamento de risco (ID.RM). . 32

6.3 Ambiente de negócios (ID.BE). . . . . . . . . . . . 35

6.4 Gestão de riscos da cadeia de suprimentos (ID.SC)… . 39

6.5 Avaliação de Risco IAC (ID.RA). . . . . . . . . 42

6.6 Gerenciamento de ativos (ID.AM). . . . . . . 49

7 ONG IAC: perfil de cibersegurança – profiles protect (PR)….55

7.1 Controle de acesso (PR.AC). . .  . . . . . 56

7.2 IAC Conscientização e treinamento em segurança cibernética (PR.AT). . . . . . . . . . . . 63

7.3 Segurança de dados (PR.DS).. . . . . . . . 67

7.4 Processos e procedimentos de proteção da informação (PR.IP). . . . . . . . . . . . . . . . 75

7.5 Manutenção (PR.MA). .. . . . . . . . . . . . . 89

7.6 Tecnologia de proteção (PR.PT). . .. . . . . . . . . 92

8 ONG IAC: requisitos do perfil de cibersegurança (detecção – DE). . . .  . . . . . . . . . . . . . 97

8.1 Anomalias e eventos (DE.AE). . .. . . . . . 97

8.2 Monitoramento contínuo de segurança (DE.CM). . .. 100

8.3 Processos de detecção (DE.DP). .. . . . . . . . . . . 106

9 ONG IAC: perfil de cibersegurança dos requisitos de respostas (RS). .  . . . . . . . . . . . . . . 110

9.1 Planejamento de Resposta (RS.RP). . . . . . . . 110

9.2 Comunicações (RS.CO). . .. . . . . . . . . 111

9.3 Análise (RS.AN).. . . . . . . . . . . . . . 114

9.4 Mitigação (RS.MI). . . . . . . . . . . . . . . . 118

9.5 Melhorias (RS.IM). . . . . . . . . . . . . . . . 120

10 ONG IAC: perfil de cibersegurança dos requisitos de recuperação (RC). . . . . . . . . . . . 122

10.1 Planejamento de Recuperação (RC.RP). . . 122

10.2 Melhorias (RC.IM). . . . . . . . . . . . . . . . 122

10.3 Comunicações (RC.CO). .  . . . . . . . . . 124

Anexo A (informativo) Construção e mapeamento da norma API 1164. . . . . .  . . . . . . . 126

Anexo B (informativo) Modelo Plan-Do-Check-Act.  . 129

Anexo C (informativo) Ações recorrentes. . . . . . . . . 131

Bibliografia. . .. . . . . . . . . . . . . . . . . . . . . . . . . . 132

Em resumo, a infraestrutura de dutos – composta por milhares de empresas e mais de 2,7 milhões de quilômetros de dutos responsáveis pelo transporte de petróleo, gás natural e outras commodities – é um facilitador fundamental da segurança econômica mundial. Como os proprietários e os operadores de dutos estão cada vez mais confiando na integração de tecnologias de informação e comunicação (TIC) em tecnologia da informação (TI) e tecnologia operacional (TO) para conduzir a automação, eles também devem implementar medidas de segurança para proteger os dutos de riscos cibernéticos em evolução e emergentes. A integração de dispositivos de TIC em sistemas de dutos críticos cria uma vulnerabilidade que os hackers cibernéticos podem explorar.

IEC 60839-11-33: a interface de serviços da Web para o controle de acesso eletrônico

A IEC 60839-11-33:2021 – Alarm and electronic security systems – Part 11-33: Electronic access control systems – Access control configuration based on Web services define a interface de serviços da Web para sistemas de controle de acesso eletrônico. Isso inclui listar os componentes do sistema de controle de acesso eletrônico, sua composição lógica, monitorar seus estados e controlá-los. Também inclui um mapeamento dos requisitos obrigatórios e opcionais de acordo com a IEC 60839-11-1: 2013, conforme coberto pelo Anexo.

Este documento se aplica apenas à segurança física para evitar que pessoas não autorizadas, ladrões ou invasores acidentais acessem fisicamente um prédio, sala, etc. O uso de serviços da Web e a funcionalidade de gestão de dispositivos estão fora do escopo deste documento.

O documento especifica apenas os dados e o fluxo de controle entre um cliente e os serviços sem referência a qualquer dispositivo físico, pois os serviços necessários para implementar um sistema de controle de acesso eletrônico compatível (electronic access control system – EACS) não são necessariamente implementados em um único dispositivo, ou seja, todos os serviços podem ser executados em um painel de controle, software agregador de eventos no PC, etc.

Conteúdo da norma

PREFÁCIO …….. …………………… 8

INTRODUÇÃO ……….. ……………. 10

1 Escopo …… …………………….. 11

2 Referências normativas …………… … 11

3 Termos e definições ……………… …. 12

4 Visão geral ……… ………………… 15

4.1 Geral ……………… …………… 15

4.2 Namespaces …………… ……. 16

4.3 Tratamento de erros ………. …… 17

5 Serviço de credencial ……. ……… 17

5.1 Geral …………. …………… 17

5.2 Capacidades de serviço ………………….. 18

5.2.1 Geral ……………………………. ……… 18

5.2.2 Estrutura de dados ServiceCapabilities ………………….. 18

5.2.3 Comando GetServiceCapabilities …. ………………… 19

5.3 Informações de credencial ……………………………… 20

5.3.1 Geral …………………………… ……… 20

5.3.2 Estruturas de dados …………………….. 20

5.3.3 Comando GetCredentialInfoList …………… 23

5.3.4 Comando GetCredentials ……………………….. 24

5.3.5 Comando GetCredentialList ………………………. 25

5.3.6 Comando CreateCredential ……………………. 26

5.3.7 Comando SetCredential ………………………. 28

5.3.8 Comando ModifyCredential ………………………. 30

5.3.9 Comando DeleteCredential ……………………… 31

5.3.10 Comando GetCredentialState ……………….. 32

5.3.11 Comando EnableCredential ……………………… 32

5.3.12 Comando DisableCredential ………………………….. 33

5.3.13 Comando ResetAntipassbackViolation ……. ………….. 33

5.3.14 Comando GetSupportedFormatTypes ……………. 34

5.3.15 Comando GetCredentialIdentifiers ………………. 34

5.3.16 Comando SetCredentialIdentifier …………………….. 35

5.3.17 Comando DeleteCredentialIdentifier …. …………….. 36

5.3.18 Comando GetCredentialAccessProfiles …… ………… 36

5.3.19 Comando SetCredentialAccessProfiles …………….. 37

5.3.20 Comando DeleteCredentialAccessProfiles ……… …….. 37

5.4 Tópicos de notificação …………………………… 38

5.4.1 Geral ………………………………. ……… 38

5.4.2 Visão geral do evento (informativo) …………………… 38

5.4.3 Mudanças de status ……………….. 38

5.4.4 Mudanças de configuração …………………………….. 39

6 Serviço de regras de acesso ………………………. …… 40

6.1 Geral ………………………………….. …………… 40

6.2 Capacidades de serviço …………………………… 41

6.2.1 Geral …………………………………. ……… 41

6.2.2 Estrutura de dados ServiceCapabilities ………………….. 41

6.2.3 Comando GetServiceCapabilities …………………. 41

6.3 Acessar informações de perfil …………………………… 41

6.3.1 Geral …………………………………. ……… 41

6.3.2 Estruturas de dados ……………………………….. 42

6.3.3 Comando GetAccessProfileInfo …………………… 42

6.3.4 Comando GetAccessProfileInfoList …………………. 43

6.3.5 Comando GetAccessProfiles ………………………. 44

6.3.6 Comando GetAccessProfileList ………………….. 45

6.3.7 Comando CreateAccessProfile ………………….. 46

6.3.8 Comando SetAccessProfile ………………………… 47

6.3.9 Comando ModifyAccessProfile …………………….. 48

6.3.10 Comando DeleteAccessProfile …………………. 49

6.4 Tópicos de notificação ………………………. 50

6.4.1 Geral ………………………………. ……… 50

6.4.2 Visão geral do evento (informativo) ………………… 50

6.4.3 Alterações de configuração ……………………… 50

7 Serviço de comportamento de autenticação ………………… 51

7.1 Geral ……………………………. …………… 51

7.2 Exemplo ………………………….. ………….. 51

7.3 Capacidades de serviço ………………………. 52

7.3.1 Geral ………………………………….. ……… 52

7.3.2 Estrutura de dados ServiceCapabilities …………………. 52

7.3.3 Comando GetServiceCapabilities …………………….. 53

7.4 Informações de perfil de autenticação …………………… 53

7.4.1 Geral ………………………………… ……… 53

7.4.2 Estruturas de dados ………………………………….. 54

7.4.3 Comando GetAuthenticationProfileInfo ……. …………. 55

7.4.4 Comando GetAuthenticationProfileInfoList…….. …….. 56

7.4.5 Comando GetAuthenticationProfiles …… …………….. 57

7.4.6 Comando GetAuthenticationProfileList …………….. 58

7.4.7 Comando CreateAuthenticationProfile ……………… 59

7.4.8 Comando SetAuthenticationProfile …………………. 60

7.4.9 Comando ModifyAuthenticationProfile ………………. 61

7.4.10 Comando DeleteAuthenticationProfile ………………. 62

7.5 Informações de nível de segurança ……………………… 63

7.5.1 Geral ………………………………………… ……… 63

7.5.2 Estruturas de dados ……………………………… 64

7.5.3 Comando GetSecurityLevelInfo ……………………. 66

7.5.4 Comando GetSecurityLevelInfoList …………………. 66

7.5.5 Comando GetSecurityLevels ……………………………. 67

7.5.6 Comando GetSecurityLevelList ………………………….. 68

7.5.7 Comando CreateSecurityLevel ……………………….. 69

7.5.8 Comando SetSecurityLevel ……………………………. 70

7.5.9 Comando ModifySecurityLevel ……………………….. 71

7.6 Tópicos de notificação …………………………. 73

7.6.1 Geral …………………………………… ……… 73

7.6.2 Visão geral do evento (informativo) ………….. 73

7.6.3 Mudanças de configuração …………………….. 73

8 Agendar serviço ……………………….. ………. 74

8.1 Geral …………………………….. …………… 74

8.2 Recorrência ……………………….. ……… 76

8.2.1 Geral ………………………………. ……… 76

8.2.2 Recorrência semanal ……………………. 76

8.2.3 Recorrência estendida …………………. 77

8.2.4 Recorrência de programação padrão ……… 77

8.2.5 Recorrência de dia especial ………………….. 77

8.3 Capacidades de serviço ……………………….. 78

8.3.1 Geral …………………………….. ……… 78

8.3.2 Estrutura de dados ServiceCapabilities ………………. 78

8.3.3 Comando GetServiceCapabilities …………………. 79

8.4 Informações de programação ………………… 79

8.4.1 Geral ……………………………… ……… 79

8.4.2 Estruturas de dados ……………………….. 79

8.4.3 Comando GetScheduleInfo ………………………….. 82

8.4.4 Comando GetScheduleInfoList …………………… 83

8.4.5 Comando GetSchedules ………………………………. 84

8.4.6 Comando GetScheduleList …………………………… 85

8.4.7 Comando CreateSchedule ……………………………. 86

8.4.8 Comando SetSchedule ………………………………… 87

8.4.9 Comando ModifySchedule ………………………….. 88

8.4.10 Comando DeleteSchedule …………………………. 89

8.5 Informações do grupo de dias especiais …………………… 90

8.5.1 Geral ……………………………….. ……… 90

8.5.2 Estruturas de dados ……………………….. 90

8.5.3 Comando GetSpecialDayGroupInfo ……………….. 90

8.5.4 Comando GetSpecialDayGroupInfoList ………………. 91

8.5.5 Comando GetSpecialDayGroups …………………….. 92

8.5.6 Comando GetSpecialDayGroupList …………………. 93

8.5.7 Comando CreateSpecialDayGroup …………………… 94

8.5.8 Comando SetSpecialDayGroup …………………… 95

8.5.9 Comando ModifySpecialDayGroup ………………….. 96

8.5.10 Comando DeleteSpecialDayGroup ………………….. 97

8.6 Status da programação ………………………….. … 97

8.6.1 Estrutura de dados ScheduleState ………………. 97

8.6.2 Comando GetScheduleState ……………………… 98

8.7 Tópicos de notificação …………………………… 99

8.7.1 Geral ………………………………. ……… 99

8.7.2 Visão geral do evento (informativo) ……….. 99

8.7.3 Mudanças de status ………………………. 99

8.7.4 Mudanças de configuração …………………. 100

8.8 Exemplos …………………………. ………. 101

8.8.1 Geral ……………………………… ……. 101

8.8.2 Acesso 24 × 7 para equipe administrativa ………… 101

8.8.3 Acesso às segundas e quartas das 06:00 às 20:00 para o pessoal de limpeza………………. 101

8.8.4 Acesso de sexta-feira 18:00 às 07:00 para equipe de manutenção……………. 101

8.8.5 Acesso em dias de semana das 8h00 às 17h00 para funcionários…………….. 102

8.8.6 Acesso de 15 de janeiro de 2014 a 14 de janeiro de 2015, das 09:00 às 18:00 …………………………. ………. 103

8.8.7 Dias especiais, exemplo 1 ……………… 103

8.8.8 Dias especiais, exemplo 2 …………… 104

8.8.9 Dias especiais, exemplo 3 ……………….. 106

Anexo A (normativo) Esquemas XML da interface de controle de acesso………… …. 107

A.1 Serviço de credencial WSDL ……………………… 107

A.2 Serviço de regras de acesso WSDL ………………….. 127

A.3 Serviço de comportamento de autenticação WSDL……….. 137

A.4 Programar WSDL de serviço …………………………. 155

Anexo B (informativo) Mapeamento de funções obrigatórias na IEC 60839-11-1…………….174

Bibliografia …………………….. 182

Este documento torna possível construir um sistema de alarme e segurança eletrônica com clientes, normalmente um console de monitoramento, e dispositivos, normalmente uma unidade de controle de acesso, de diferentes fabricantes usando interfaces comuns e bem definidas. O documento especifica apenas os dados e o fluxo de controle entre um cliente e os serviços sem referência a qualquer dispositivo físico, pois os serviços necessários para implementar um sistema de controle de acesso eletrônico compatível (electronic access control system – EACS) não são necessariamente implementados em um único dispositivo, ou seja, todos os serviços podem ser executados em um painel de controle, software agregador de eventos no PC, etc.

Este documento não define a comunicação interna entre uma unidade de controle de acesso e seus componentes se eles forem implementados em um único dispositivo. Este documento é baseado no trabalho realizado pelo fórum aberto da indústria, o open network video interface forum (ONVIF). A especificação de credencial ONVIF, a especificação de regras de acesso ONVIF, o comportamento de autenticação ONVIF e a especificação ONVIF Schedule são compatíveis com este documento.

Este documento é acompanhado por um conjunto de definições de interface legíveis por computador (ver Anexo A): WSDL de serviço de credencial, consulte a Cláusula A.1; WSDL do serviço de regras de acesso, consulte a Cláusula A.2; WSDL do serviço de comportamento de autenticação, consulte a Cláusula A.3; agendar WSDL de serviço, consulte a Cláusula A.4. Devido às diferenças na terminologia usada na IEC 60839-11-1:2013 e IEC 60839-11-2:2014 e na especificação ONVIF na qual esta parte da IEC 60839 se baseia, um leitor deve prestar atenção especial aos termos e definições cláusula. Os serviços adicionais necessários para o monitoramento de portas e pontos de acesso (lados do portal) estão fora do escopo deste documento. Esses serviços são cobertos pela IEC 60839-11-32.

Os processos de ciclo de vida de software

A NBR ISO/IEC-IEEE 12207 de 08/2021 – Engenharia de sistemas e software – Processos de ciclo de vida de software estabelece uma estrutura comum para processos de ciclo de vida de software, com terminologia bem definida, que pode ser referenciada pela indústria de software. Ele contém processos, atividades e tarefas que são aplicáveis durante a aquisição, fornecimento, desenvolvimento, operação, manutenção ou desativação de sistemas, produtos e serviços de software.

Estes processos de ciclo de vida são executados com sucesso por meio do envolvimento de stakeholders, com o objetivo final de alcançar a satisfação do cliente. Este documento é aplicável à aquisição, fornecimento, desenvolvimento, operação, manutenção e desativação de sistemas de software, produtos e serviços, e a parte de software de qualquer sistema (executados tanto interna como externamente a uma organização).

O software inclui a parte de software do firmware. Os aspectos de definição de sistema necessários para prover o contexto para produtos e serviços de software estão incluídos. Este documento também fornece os processos que podem ser empregados na definição, controle e melhoria dos processos de ciclo de vida de software dentro de uma organização ou projeto.

Os processos, atividades e tarefas deste documento também podem ser aplicados durante a aquisição de um sistema que contenha software, seja individualmente ou em conjunto com a ISO/IEC 15288:2015 – Systems and software engineering – System life cycle processes. No contexto deste documento e da ISO/IEC/IEEE 15288, há um continuum de sistemas desenvolvidos por humanos desde os que usam pouco ou nenhum software, até aqueles nos quais o software é o principal componente.

É raro encontrar um sistema complexo sem software e todos os sistemas de software exigem que os componentes do sistema físico (hardware) funcionem, ou seja, como parte do sistema de software de interesse. Assim, a escolha de quando aplicar este documento para os processos de ciclo de vida de software, ou a ISO/IEC/IEEE 15288: 2015 – Systems and software engineering–System life cycle processes, depende do sistema de interesse.

Os processos em ambos os documentos têm os mesmos propósitos e resultados de processo, mas diferem em atividades e tarefas para executar a engenharia de software ou a engenharia de sistemas, respectivamente. Assim, o propósito deste documento é fornecer um conjunto definido de processos para facilitar a comunicação entre adquirentes, fornecedores e outros stakeholders no ciclo de vida de um sistema de software.

Este documento foi escrito para adquirentes, fornecedores, desenvolvedores, integradores, operadores, mantenedores, gestores, gerentes de garantia de qualidade e usuários de sistemas, produtos e serviços de software. Ele pode ser usado por uma única organização de forma autoimposta ou em uma situação que envolva várias organizações. As partes podem ser da mesma organização ou de diferentes organizações, podendo variar para a realização de um acordo informal a um acordo formal.

Os processos neste documento podem ser usados como base para estabelecer ambientes de negócios, por exemplo, métodos, procedimentos, técnicas, ferramentas e pessoal treinado. O Anexo A fornece orientação normativa para a adaptação destes processos de ciclo de vida de software. Este documento é aplicável a todo o ciclo de vida de sistemas, produtos e serviços de software, incluindo concepção, desenvolvimento, produção, utilização, suporte e desativação, e à sua aquisição e fornecimento, sejam estes processos executados interna ou externamente a uma organização.

Os processos do ciclo de vida deste documento podem ser aplicados de forma concorrente, iterativa e recursiva a um sistema de software e de forma incremental aos seus elementos. Há uma grande variedade de sistemas de software em termos de propósito, domínio de aplicação, complexidade, tamanho, novidade, adaptabilidade, quantidade, localizações, vida útil e evolução.

Este documento descreve os processos que compõem o ciclo de vida de sistemas de software criados pelo homem. Portanto, aplica-se aos sistemas de software únicos, sistemas de software para ampla distribuição comercial ou pública e sistemas de software adaptáveis e customizados. Também se aplica a um sistema de software independente completo e aos sistemas de software que são incorporados e integrados a sistemas maiores, mais complexos e completos.

Este documento fornece um modelo de referência de processo caracterizado em termos de propósito e resultados de processo, que são consequência da execução bem-sucedida das tarefas da atividade. O Anexo B lista exemplos de artefatos e itens de informação que podem estar associados a vários processos. Este documento pode, portanto, ser usado como um modelo de referência para apoiar a avaliação de processo, conforme especificado na ISO/IEC 33002:2015.

O Anexo C fornece informações sobre o uso dos processos de ciclo de vida do software como um modelo de referência de processo. O Anexo D descreve os construtos do processo para uso no modelo de referência de processo. O Anexo I fornece a correspondência entre este documento e a ISO/IEC/IEEE 12207:2009 no nível de nome e resultado de processo.

Este documento não prescreve um modelo específico de ciclo de vida de software, metodologia de desenvolvimento, método, abordagem de modelagem ou técnica. Os usuários deste documento são responsáveis por selecionar um modelo de ciclo de vida para o projeto e por mapear os processos, atividades e tarefas deste documento naquele modelo. As partes também são responsáveis pela seleção e aplicação de metodologias, métodos, modelos e técnicas apropriados para o projeto.

Este documento não estabelece um sistema de gestão ou requer o uso de qualquer norma de sistema de gestão. No entanto, destina-se a ser compatível com o sistema de gestão da qualidade especificado pela NBR ISO 9001, com o sistema de gestão de serviços especificado pela NBR ISO/IEC 20000-1 (IEEE Std 20000-1) e com o sistema de gestão de segurança da informação especificado pela ISO/IEC 27000. Este documento não detalha itens de informação em termos de nome, formato, conteúdo explícito e mídia de registro. A ISO/IEC/IEEE 15289 aborda o conteúdo dos itens de informação de processo de ciclo de vida (documentação).

Acesse algumas questões relacionadas a essa norma GRATUITAMENTE no Target Genius Respostas Diretas:

O que representam os sistemas habilitadores?

Quais são os processos do ciclo de vida para o sistema de software?

Por que fazer a adoção em nível de projeto e organização?

Qual é o modelo de ciclo de vida para o sistema de software?

A complexidade dos sistemas de software aumentou a um nível sem precedentes. Isto levou a novas oportunidades, mas também aumentou os desafios para as organizações que criam e utilizam os sistemas. Estes desafios existem ao longo do ciclo de vida de um sistema e em todos os níveis de detalhes arquiteturais.

Este documento fornece uma estrutura de processo comum para descrever o ciclo de vida de sistemas criados por seres humanos, adotando uma abordagem de engenharia de software que é uma abordagem interdisciplinar e propicia a produção bem-sucedida de sistemas de software.

Ela foca a definição das necessidades dos stakeholders e a funcionalidade requerida no início do ciclo de desenvolvimento, a documentação dos requisitos, a execução da síntese do design e a validação do sistema, considerando o problema completo. Ela integra todas as disciplinas e grupos de especialidade em um esforço de equipe, formando um processo de desenvolvimento estruturado que passa do conceito à produção, operação e manutenção.

Ela considera tanto as necessidades de negócio quanto técnicas de todos os stakeholders, com o objetivo de fornecer um produto de qualidade que atenda às necessidades dos usuários e outros stakeholders aplicáveis. Este ciclo de vida abrange da concepção de ideias até a desativação de um sistema. Ela provê os processos para aquisição e fornecimento de sistemas.

Ela ajuda a melhorar a comunicação e a cooperação entre as partes que criam, utilizam e gerenciam sistemas de software modernos para que possam trabalhar de forma integrada e coerente. Além disso, a estrutura proposta contribui para a avaliação e melhoria dos processos do ciclo de vida.

Os processos neste documento formam um conjunto abrangente a partir do qual uma organização pode construir modelos de ciclo de vida de software apropriados para seus produtos e serviços. Uma organização, dependendo da sua finalidade, pode selecionar e aplicar um subconjunto apropriado para alcançar este propósito.

Este documento pode ser usado de uma ou mais das seguintes formas: por uma organização – para ajudar a estabelecer um ambiente de processos desejados. Estes processos podem ser sustentados por uma infraestrutura de métodos, procedimentos, técnicas, ferramentas e pessoal treinado. A organização pode então empregar este ambiente para executar e gerenciar seus projetos e evoluir sistemas de software ao longo as fases do ciclo de vida.

Dessa forma, este documento é usado para avaliar a conformidade de um ambiente declarado e estabelecido em relação ao que ele provê. Também pode ser usado por um projeto – para ajudar a selecionar, estruturar e utilizar os elementos de um ambiente estabelecido para fornecer produtos e serviços. Dessa forma, este documento é usado na avaliação da conformidade do projeto em relação ao ambiente estabelecido e declarado.

Pode ser utilizado por um adquirente e um fornecedor – para ajudar a desenvolver um acordo relativo a processos e atividades. Por meio desse acordo, os processos e atividades deste documento são selecionados, negociados, acordados e executados. Dessa forma, este documento é usado para orientar o desenvolvimento do acordo.

Pode ser usado por avaliadores de processo – para servir como um modelo de referência de processo utilizado na execução de avaliações de processo, que podem ser usadas para apoiar a melhoria do processo organizacional. Este documento fornece os requisitos para uma variedade processos adequados para uso durante o ciclo de vida de um sistema ou produto de software.

É reconhecido que projetos ou organizações específicos podem não precisar usar todos os processos fornecidos por este documento. Portanto, a implementação deste documento geralmente envolve a seleção e a declaração de um conjunto de processos adequados à organização ou projeto. Existem duas formas de reivindicar a conformidade com as disposições deste documento ‒ conformidade total e conformidade personalizada.

Existem dois critérios para reivindicar a conformidade total. Atingir qualquer destes critérios é suficiente para conformidade, embora o critério (ou critérios) escolhido (s) deva (m) ser declarado (s) na reivindicação. Reivindicar conformidade total com as tarefas afirma que todos os requisitos das atividades e tarefas do conjunto declarado de processos são alcançados.

Alternativamente, reivindicar conformidade total com os resultados afirma que todos os resultados requeridos do conjunto declarado de processos são alcançados. A conformidade total com resultados permite maior liberdade na implementação de processos e pode ser útil para implementar processos a serem usados no contexto de um modelo inovador de ciclo de vida.

Opções para conformidade são fornecidas para a flexibilidade necessária na aplicação deste documento. Cada processo tem um conjunto de objetivos (expressos como resultados) e um conjunto de atividades e tarefas que representam uma maneira de alcançar os objetivos. Os usuários que implementam as atividades e tarefas do conjunto declarado de processos podem afirmar conformidade total com as tarefas dos processos selecionados.

Alguns usuários, no entanto, podem ter variantes inovadoras de processos que atinjam os objetivos (ou seja, os resultados) do conjunto declarado de processos sem implementar todas as atividades e tarefas. Estes usuários podem afirmar conformidade total com os resultados do conjunto declarado de processos.

Os dois critérios – conformidade com tarefa e conformidade com resultado – não são necessariamente equivalentes, pois a execução específica de atividades e tarefas pode requerer, em alguns casos, um nível mais alto de capacidade do que apenas o alcance de resultados. Quando este documento é usado para auxiliar o desenvolvimento de um acordo entre um adquirente e um fornecedor, seções deste documento podem ser selecionadas para incorporação ao acordo, com ou sem modificação.

Neste caso, é mais apropriado que o adquirente e o fornecedor reivindiquem a conformidade com o acordo do que com este documento. Uma organização (por exemplo, pública, associação industrial, corporação) que impõe este documento, como condição comercial, pode especificar e tornar público o conjunto mínimo de processos, resultados, atividades e tarefas exigidos, que constituem a conformidade dos fornecedores com as condições do negócio.

Os requisitos deste documento são assinalados pelo uso do verbo deve. As recomendações são assinaladas pelo uso da expressão convém que. As permissões são assinaladas pelo uso do verbo pode. No entanto, apesar do termo usado, os requisitos de conformidade são selecionados conforme descrito anteriormente.

Uma reivindicação de conformidade total declara o conjunto de processos com os quais a conformidade é requerida. A conformidade total com resultados é alcançada pela demonstração que todos os resultados do conjunto declarado de processos foram alcançados. Nesta situação, as disposições para atividades e tarefas do conjunto declarado de processos são orientações e não requisitos, independentemente da expressão ou forma verbal usada na disposição.

Um uso pretendido deste documento é facilitar a avaliação e a melhoria do processo. Para este fim, os objetivos de cada processo são escritos na forma de resultados compatíveis com as disposições da ISO/IEC 33002 que fornece a avaliação dos processos deste documento, fornecendo uma base para melhorias. Os usuários que pretendem avaliar e melhorar processos podem usar os resultados de processo escritos no presente documento como o modelo de referência de processo requerido pela ISO/IEC 33002.

Uma reivindicação de conformidade total declara o conjunto de processos para os quais a conformidade é reivindicada. A conformidade total com tarefas é alcançada pela demonstração que todos os requisitos das atividades e tarefas do conjunto declarado de processos foram satisfeitos. Nesta situação, as disposições para os resultados do conjunto declarado de processos são orientações e não requisitos, independentemente da expressão ou forma verbal usada na disposição.

Uma reivindicação de conformidade total com tarefas pode ser apropriada em situações contratuais em que um adquirente ou um regulador requer um entendimento detalhado dos processos dos fornecedores. Quando este documento é utilizado como base para estabelecer um conjunto de processos que não se qualificam para conformidade total, as seções deste documento são selecionadas ou modificadas de acordo com o processo de adaptação prescrito no Anexo A.

O texto adaptado, para o qual a conformidade personalizada é reivindicada, é declarado. A conformidade personalizada é obtida pela demonstração de que foram alcançados os resultados, atividades e tarefas, conforme adaptados. As elaborações adicionais destes conceitos relativos à aplicação do gerenciamento do ciclo de vida podem ser encontradas nas ISO/IEC TS 24748-1, ISO/IEC TR 24748-2 e ISO/IEC TR 24748-3.

Os sistemas de software considerados neste documento são feitos, criados e utilizados por pessoas para fornecer produtos ou serviços em ambientes definidos para o benefício dos usuários e de outros stakeholders. Estes sistemas de software podem incluir os seguintes elementos de sistema: hardware, software, dados, pessoas, processos (por exemplo, processos para fornecer serviços aos usuários), procedimentos (por exemplo, instruções do operador), instalações, serviços, materiais e entidades.

Conforme vistos pelo usuário, eles são considerados produtos ou serviços. Este documento se aplica a sistemas para os quais o software é de primordial importância para os stakeholders. Este documento é baseado nos princípios gerais da engenharia de sistemas e engenharia de software.

É uma premissa fundamental deste documento que o software sempre exista no contexto de um sistema. Como o software não opera sem hardware, o processador no qual o software é executado pode ser considerado como parte do sistema. Como alternativa, o hardware ou serviços que hospedam o sistema de software e lidam com as comunicações com outros sistemas também podem ser vistos como sistemas habilitadores ou sistemas externos no ambiente operacional.

A percepção e a definição de um sistema de software específico, sua arquitetura e seus elementos dependem dos interesses e responsabilidades de um stakeholder. O sistema de interesse de um stakeholder pode ser visto como um elemento do sistema de interesse de outro stakeholder. Além disso, pode ser visto também como parte do ambiente de um sistema de interesse de outro stakeholder.

A seguir, são apresentados os principais pontos sobre as características de sistemas de interesse. Os limites definidos encapsulam necessidades significativas e soluções práticas; existem hierarquias ou outros relacionamentos entre os elementos do sistema. Uma entidade em qualquer nível no sistema de interesse pode ser vista como um sistema.

Um sistema compreende um conjunto integrado e definido de elementos de sistema subordinados e as pessoas podem ser vistas como usuários externos a um sistema e como elementos internos ao sistema (isto é, operadores); e um sistema pode ser visto isoladamente como uma entidade, isto é, um produto; ou como um conjunto de funções capazes de interagir com o ambiente ao seu redor, isto é, um conjunto de serviços. Quaisquer que sejam os limites escolhidos para definir o sistema, os conceitos neste documento são genéricos e permitem correlacionar ou adaptar instâncias individuais dos ciclos de vida aos princípios de sistema de um profissional.

Os processos do ciclo de vida neste documento são descritos em relação a um sistema de software que é composto por um conjunto de elementos que interagem (incluindo elementos de software), cada um dos quais pode ser implementado para satisfazer os respectivos requisitos especificados (figura abaixo). A responsabilidade pela implementação de qualquer elemento do sistema pode, portanto, ser delegada a outra parte por meio de um acordo.

O relacionamento entre o sistema de software e o conjunto completo de seus elementos geralmente pode ser representado mostrando os relacionamentos entre os elementos ‒ frequentemente descritos como uma hierarquia para o mais simples dos sistemas de interesse. A decomposição é uma abordagem para algumas atividades de software.

Outras abordagens incluem a orientação a objetos, na qual os elementos do sistema são dispostos em um mesmo plano (não hierárquica), como em um diagrama de rede. Para sistemas de interesse de software mais complexos, pode ser necessário considerar um futuro elemento como um sistema (que por sua vez é composto por outros elementos) antes que um conjunto completo possa ser definido de forma confiável.

Dessa forma, os processos apropriados de ciclo de vida de sistema são aplicados recursivamente a um sistema de interesse para resolver sua estrutura, até que elementos compreensíveis e gerenciáveis do sistema de software possam ser implementados (criados, adaptados, adquiridos ou reutilizados). Pode-se dizer que todo sistema de software tem um ciclo de vida. Um ciclo de vida pode ser descrito usando um modelo funcional abstrato que representa a conceituação de uma necessidade do sistema, sua realização, utilização, evolução e desativação.

Um sistema de software evolui no seu ciclo de vida como resultado de ações das atividades dos processos. Estas ações são executadas e gerenciadas por pessoas nas organizações. Os detalhes no modelo de ciclo de vida são expressos em termos destes processos, seus resultados, relacionamentos e sequência.