InTech110

Número 110 3

GERENCIAMENTO DE ATIVOS artigo

GERENCIAMENTO DE ATIVOS APLICADO À GESTÃO DE SOFTWAREAlessandro Barbosa Shirahige ([email protected]), Engenheiro de Aplicações; Carlos Eduardo Gurgel Paiola ([email protected]); Gerente de Contas; e Márcia Campos ([email protected]), Gerente Comercial, todos da Aquarius Software.

Quando falamos em gerenciamento de

ativos na área de automação indus-

trial, fica evidente a intenção de cui-

dar e manter bens materiais da empre-

sa, como equipamentos ou instrumentos

(sensores / atuadores). No entanto, den-

tro desse contexto, é importante tam-

bém ressaltar como ativo o software, que

ganha importância como um bem à me-

dida que é cada vez mais utilizado para

controlar, supervisionar e gerenciar ope-

rações e produção.

O termo “ativo” tem origem na ciência

contábil, onde se atribui ao ativo o con-

trole dos recursos e a capacidade de

proporcionar benefícios futuros para a

organização.

Antes do final do século passado, a con-

tabilidade só dava importância aos ati-

vos materiais, tangíveis; no entanto, re-

centemente, a discussão sobre ativos in-

tangíveis evoluiu de maneira significati-

va. Em 2007, com a finalidade de atua-

lizar conceitos e adequar-se aos modos

atuais de produção, foi decretada a Lei

11.638/07 [Ref. 1] sobre elaboração e di-

vulgação de demonstrações financeiras.

4 InTech | www.isadistrito4.org

artigo GERENCIAMENTO DE ATIVOS

Nessa lei, os ativos são separados em

ativos circulantes e ativos não-circulan-

tes. Os ativos não-circulantes englobam

ativo realizável em longo prazo, investi-

mentos, imobilizado e intangível. Den-

tro desta última classificação, define-se

como ativo intangível os direitos que te-

nham por objeto bens incorpóreos desti-

nados à manutenção da companhia ou

exercidos com essa finalidade.

Esse conceito também é discutido por

autores como Johnson e Kaplan [Ref. 2],

que afirmam que o valor da entidade não

se restringe à soma dos valores de seus

ativos tangíveis, mas inclui também os

valores de ativos intangíveis: o surgi-

mento de produtos inovadores, o conhe-

cimento de processos de produção fle-

xíveis e de alta qualidade, o talento e a

moral dos empregados, a fidelidade dos

clientes, a imagem dos produtos, rede de

distribuição eficiente, etc.

Nessa mesma tendência, o International

Accounting Standard Board (IASB) [Ref.

3], organismo internacional de emissão

de padrões contábeis, estabelece que

ativos intangíveis são aqueles que não

tem substância física, ou tem um valor

que não é convertido para aquelas subs-

tâncias físicas que estes possuem, a

exemplo de um software, o qual não é ra-

zoavelmente mensurado em relação ao

custo dos disquetes que o contém (EPS-

TEIN e MIRZA, 2004 [Ref. 4]).

As empresas têm preocupação perma-

nente em conservar seus ativos, incluin-

do máquinas e equipamentos, de modo

a manter sua produtividade. Porém, os

equipamentos de produção, como con-

troladores industriais, robôs e instru-

mentações inteligentes, utilizam cada

vez mais software em sua programação

e configuração. Sistemas fundamentais

para a operação, como IHMs (Interfaces

Homem-Máquina) e supervisórios, são

ferramentas de software. Assim sendo,

torna-se natural estender o conceito de

gerenciamento de ativos também para

o ativo intangível software, pois se sua

perda ou falha acarreta prejuízos diretos

e indiretos, é imprescindível garantir sua

preservação, integridade e atualização.

CARACTERÍSTICAS ESPECÍFICAS DO ATIVO INTANGÍVEL SOFTWARE

Além do aspecto da continuidade opera-

cional, é importante observar que custos

de desenvolvimento da aplicação, de im-

plementação, de ajustes e de manuten-

ção incidem sobre software e aplicati-

vos, além do tempo, da experiência e da

inteligência aplicados a estes. Ou seja,

os programas de CLPs (Controladores

Lógicos Programáveis), os aplicativos de

supervisão e a documentação relativa a

esses softwares reúnem conhecimento,

procedimentos e otimizações do proces-

so produtivo.

Assim, quando se observa o universo de

software utilizado numa indústria, per-

cebe-se a importância desse conheci-

mento, que posto em execução e ajusta-

do por experiência, deve ser reconhecido

como bem crítico da empresa e não pode

simplesmente ser perdido. Pelo contrá-

rio, o software deve ser cuidado e con-

servado como qualquer outro ativo.

SISTEMAS PARA BACKUP E GERENCIAMENTO DE VERSÃO DE SOFTWARE INDUSTRIAL SÃO UMA TENDÊNCIA

Na área de informática, sistemas para

backup (cópia de segurança) e gerencia-

mento de versão de software são rotinei-

ros e parte do dia a dia dos programado-

res. Sua utilização segue a normas como

a ISO/IEC 27002 [Ref. 5], recente atuali-

zação da ISO/IEC 17799 [Ref. 6], de ges-

tão de segurança da informação, basea-

da em três pilares básicos: confidenciali-

dade, integridade e disponibilidade das

informações. Esta norma fornece um

conjunto de recomendações que visam

conscientizar e orientar os funcionários,

clientes, parceiros e fornecedores de tec-

nologia de informação para o uso segu-

ro do ambiente, tanto físico quanto o in-

formatizado, com informações sobre ge-

renciamento, distribuição e proteção da

informação.

No entanto, o mesmo ainda não ocor-

re de forma sistemática no ambiente in-

dustrial. O gerenciamento de versão de

software é um tema mais comum na in-

dústria alimentícia e farmacêutica, de-

vido a requisitos da norma FDA 21 CFR

Part 11 [Ref. 7], que exige controle dos

programas e aplicativos de forma rígida.

Em outros setores da indústria, a bus-

ca por soluções para backup e gerencia-

mento de versões de software, em geral,

visa evitar a repetição de problemas an-

teriores (paradas de produção, dificul-

dades por uso de versões antigas, etc.)

ou é devida à percepção de que há fa-

lhas nos mecanismos empregados. Mas,

seja para aplicar as normas exigidas pelo

mercado, ou por necessidade do dia a

dia da empresa, a tendência que se ob-

serva de controlar de maneira segura os

softwares industriais é inexorável.

Com a intenção de orientar as ações de

segurança na área de tecnologia da au-

tomação, a ISA (International Society of

Automation) criou uma série de normas,

cada qual cobrindo um aspecto especí-

fico do tema “segurança de sistemas de

manufatura e controle” [Ref. 8]. São elas:

•ISA 99.00.01 – Escopo, conceitos, mo-

delos e terminologia;

•ISA 99.00.02 – Estabelecendo a segu-

rança de sistemas de manufatura e

controle;

Número 110 5


•ISA 99.00.03 – Operando um progra-

ma de segurança de sistemas de ma-

nufatura e controle;

•ISA 99.00.04 – Requisitos específicos

de segurança para sistemas de manu-

fatura e controle.

Adicionalmente, o comitê responsável

desenvolveu dois relatórios técnicos que

auxiliam na compreensão e execução

das normas, identificando e avaliando

as tecnologias atualmente disponíveis e

como elas podem ser utilizadas nos sis-

temas de controle:

•ISA TR 99.00.01 – Tecnologias para a

proteção dos sistemas de manufatura

e controle;

•ISA TR 99.00.02 – Integrando seguran-

ça eletrônica ao ambiente dos siste-

mas de manufatura e controle.

Com necessidades mais amplas do que

os usuários de TI, os usuários da tecno-

logia de automação industrial já dis-

põem de ferramentas para auxiliá-lo no

backup e gerenciamento de ativos de

software: os Sistemas de Backup e Ge-

renciamento de Versão de Softwares

Industriais. Esses sistemas também

são conhecidos como CMS (do inglês,

Change Management System, ou seja,

Sistema Gerenciador de Mudanças).

Os CMSs funcionam como uma apólice

de seguro, onde se faz um investimento

para reduzir custos em caso de aciden-

te. E o retorno sobre o investimento (em

inglês, ROI – Return On Investiment) em

um sistema desse tipo é extremamente

rápido, pois, ao garantir disponibilidade

de backup e identificar mudanças inde-

vidas, reduz tempos de parada, com im-

pacto direto na produtividade da empre-

sa e na segurança operacional.

QUANDO O GERENCIAMENTO DO ATIVO SOFTWARE É NECESSÁRIO

Quando uma das situações abaixo ocor-

re, há indicação de que o gerenciamento

do ativo software é necessário:

•Não havia backup atualizado dos pro-

gramas quando ocorreu uma falha;

•A empresa já teve problemas para en-

contrar um programa ou uma configu-

ração quando precisava colocar um

equipamento em funcionamento;

•A empresa percebeu um problema no

programa de configuração do equipa-

mento e, quando procurou o backup,

encontrou-o com o mesmo problema;

•O programa do controlador industrial

foi modificado sem que a mudança te-



nha sido devidamente documentada;

•Alguém esqueceu um ponto “for-

çado” no CLP e causou problemas

posteriores;

•Uma pessoa não autorizada ou não

identificada fez uma modificação em

um programa de configuração;

•Perderam algumas alterações no pro-

grama de configuração porque outra

pessoa sobrescreveu o trabalho;

•A versão errada do programa de confi-

guração foi editada.

Qualquer dessas situações em uma

empresa indica que não existe pro-

cedimento de criação e controle de

backups ou que tais criações e contro-

les são feitos de forma ineficaz. Para

estes casos, é fortemente indicado

um sistema para backup e gerencia-

mento dos programas e aplicativos de

software.

Esse gerenciamento evita conseqüên-

cias trabalhosas e até mesmo caras,

como uma parada de produção prolon-

gada, e ainda horas adicionais de tra-

balho, refazendo ou revendo progra-

mas, devido a dificuldades na compa-

ração destes. Com o uso dessa tecnolo-

gia, situações ainda mais graves tam-

bém podem ser evitadas, como aciden-

tes operacionais causados por uso de

versões antigas do software do CLP,

por exemplo.

ASPECTOS ESPECÍFICOS DO GERENCIAMENTO DO ATIVO SOFTWARE

O gerenciamento do software requer

cuidados distintos de outros ativos:

•Backup – para garantir que possa ser

recuperado fácil e rapidamente em

casos de falha de hardware ou outra

ocorrência que leve à perda da ver-

são em uso;

•Proteção, para evitar “furtos” e mu-

danças indevidas – o que se traduz

no controle de acesso;

•Gerenciamento de mudanças – para

permitir rastrear a autoria das altera-

ções e quais foram essas alterações.

A seguir, os três aspectos principais do

sistema de backup e gerenciamento de

versões de software são detalhados.

BACKUP

O primeiro aspecto tratado por um bom

CMS é a cópia de segurança.

É indiscutível que a falta de backup

tem custo direto (ex. nas paradas de

produção) ou indireto (ex. com aumen-

to de horas trabalhadas para recuperar

a perda). No entanto, o aspecto mais

importante na perda de programas e

aplicativos é que equivale (ou até mes-

mo supera) a perda de um equipamen-

to de campo, com custos e prazos asso-

ciados à sua reposição, além do tempo

de parada da produção.

O que se pretende com um sistema

que permite backup automático para

softwares industriais é garantir que a ver-

são que é executada no controlador in-

dustrial ou no sistema supervisório este-

ja disponível em um repositório comum,

com fácil acesso e sem criar a dúvida de

qual seria a última versão validada.

Para atingir este objetivo, os tradicio-

nais agendadores de tarefa dos siste-

mas operacionais podem até atender

a necessidade de realizar os backups

de sistemas supervisórios, mas estes

não são suficientes para realizar os

backups dos programas de configura-

ções dos controladores industriais. Isso

se deve ao fato de que é necessário ob-

ter o programa de configuração direta-

mente da CPU do controlador, ou seja,

é necessário fazer um upload (descar-

ga ou leitura) do controlador industrial.

Mesmo que os tradicionais agenda-

dores realizassem o upload e, por con-

seqüência, obtivessem o backup do

aplicativo, isso ainda não seria o bas-

tante para obter-se uma cópia con-

fiável, pois nada indicaria ao usuá-

rio se este backup é diferente ou igual

à versão anterior. Um CMS permi-

te que, caso a versão seja igual à an-

terior, não seja arquivado este novo

backup, evitando assim o armazena-

mento de informação desnecessária;

além disso, se o novo backup do pro-

grama obtido for diferente, o sistema

pode armazená-lo momentaneamente

e notificar um responsável de que uma

nova versão foi obtida. O responsá-

vel validará a mudança para manter o

backup, afinal, a nova versão tanto

pode estar correta, quanto pode ser

indevida, por exemplo, trazendo um

ponto que não deveria permanecer

forçado.

Embora o backup se relacione ao con-

trole de acesso e ao gerenciamento de

mudanças, que será explanado adian-

te, já se percebe que não se trata aqui

apenas de agendamento e upload, mas

sim, da necessidade de uma inteligên-

cia adicional para resultar em confiabi-

lidade e robustez de informação.

CONTROLE DE ACESSO

Quando se fala em controle de aces-

so, pensa-se imediatamente em usu-

ários, senhas e privilégios (Figura 1).

Estes são fundamentais e indispen-

sáveis, porém, para gerenciar progra-

mas e aplicativos eficientemente, de-

ve-se possuir recursos adicionais que

permitam restringir o acesso de usuá-

rios considerando a função específica

a cada um. Por exemplo, um técnico de

manutenção pode recuperar o progra-

Número 110 7

ma arquivado da sua área, mas não pode alterá-lo, enquanto

o administrador possui acesso para todas as operações pos-

síveis sobre este programa. Pode-se ter também a necessi-

dade de aprovar ou validar mudanças. Tal procedimento é

exigido na norma FDA 21 CFR Part 11.

FIGURA 1 - Controle de Acesso.

Uma vez que o controle de acesso é realizado, pode-se obter

algumas funcionalidades adicionais. Um ganho ao gerenciar

acessos é evitar que duas pessoas alterem simultaneamen-

te o mesmo programa, evitando que uma delas tenha seu tra-

balho sobrescrito. Para isso, quando alguém precisa modifi-

car um software, o sistema reserva o respectivo projeto para

o usuário solicitante e o bloqueia para os demais. Durante a

modificação do projeto, os outros usuários poderão lê-lo, mas

não editá-lo (Figura 2).

FIGURA 2 - Acesso bloqueado por outro usuário.

Outro aspecto importante em qualquer controle de versão é a

documentação. Devem existir mecanismos que incentivem a

inclusão de comentários, informando o que e por que foi modi-

ficado. Logicamente, obrigar um usuário a incluir um comen-

tário não garante que este seja claro e completo, mas quando

é possível identificar quem deixa de comentar adequadamen-

te suas mudanças, pode-se também criar formas de motivá-lo

a adotar o procedimento correto.

GERENCIAMENTO DE MUDANÇAS

O gerenciamento de mudanças visa manter todas as versões

e alterações realizadas na empresa, com o registro histórico

de quem fez cada modificação (Figuras 3 e 4). O histórico ga-

rante informações para diversos tipos de análise: gerenciais,

auditorias, freqüência de alterações em programas, etc.

FIGURA 3 - Exemplo de histórico de versões.

FIGURA 4 - Exemplo de histórico de versões via web.

A manutenção de versões intermediárias tem diversas apli-

cações. Durante o desenvolvimento de um programa, compa-

rar versões auxilia a identificar em que ponto um problema re-



artigo MEDIÇÃO DE NÍVEL

cém-diagnosticado não ocorria, podendo reduzir drasticamente

o tempo gasto nesse diagnóstico e no restabelecimento da ope-

ração desejada.

Na prática, em qualquer trabalho mais demorado, é interessante

que o usuário possa salvar versões intermediárias do programa.

Mas é importante diferenciar a última versão (aquela que está

sendo modificada) da versão corrente, que é a versão que está ro-

dando efetivamente em campo. Por exemplo, o engenheiro pre-

para a inclusão de um novo equipamento no processo, o progra-

ma que está rodando no CLP somente será trocado após as mu-

danças no programa, testes e adaptações. Durante essa fase de

desenvolvimento, o engenheiro quer manter seus backups, mas

o programa validado para a produção é a versão corrente, ante-

rior à expansão. Nesse caso, a versão original e a modificada de-

vem ser mantidas e, ao fazer o upload, a versão do CLP deverá

ser comparada à versão corrente, que não é a última versão.

CARACTERÍSTICAS IMPORTANTES PARA O SISTEMA DE BACKUP E CONTROLE DE VERSÃO DE SOFTWARE

Conceitualmente simples, o sistema de backup e controle de

versão requer características que garantam abrangência e fle-

xibilidade para que possa ser implementado com sucesso. Algu-

mas dessas características são detalhadas a seguir.

SUPORTE A DIFERENTES CLPS E SUPERVISÓRIOS

Os CMS encontram uma restrição relevante. Tipicamente as

plantas industriais possuem uma grande diversidade de contro-

ladores industriais e supervisórios. E cada um destes possui um

formato proprietário e níveis diferentes de recursos de acesso e

de comparação de versão (Figura 5).

FIGURA 5 - Árvore de projetos.

Desta forma, o CMS não deve se limitar a um fabricante es-

pecífico, mas sim abranger um número grande de fabrican-

tes e tipos de equipamentos.

Para garantir algum nível de controle para todos os

softwares industriais, criou-se a possibilidade de personalizar

o controle para os programas e aplicativos que não são supor-

tados em modo nativo. Neste caso, o controle é mais eficiente,

ou menos, dependendo do grau de abertura para personaliza-

ção oferecido pelo próprio CMS e dos padrões de abertura que

programadores de cada equipamento oferecem.

Nesse aspecto, ao escolher um CMS, é importante obser-

var o conjunto de programas e aplicativos existentes na em-

presa, bem como considerar a possibilidade de inclusão de

novos softwares e definir qual o nível mínimo de controle

aceitável.

ARQUITETURA

Uma arquitetura do tipo cliente/servidor é desejável nesta

aplicação, pois garante que a informação mais recente fi-

que disponível para todos. Na Figura 6 está um exemplo de

arquitetura cliente/servidor para um software gerenciador

de mudanças. Pode-se notar a comunicação direta com os

diversos programas atendidos pelo servidor, incluindo a co-

municação com os dispositivos de campo, como CLPs, IHMs

etc. Esta comunicação pode ser feita de forma manual ou

automática.

FIGURA 6 - Arquitetura cliente/servidor.

Quando existe conexão on-line com as aplicações geren-

ciadas, a partir do servidor ou de algum cliente da rede, po-

de-se realizar backup e comparação automáticos das apli-

cações, em períodos determinados pelo usuário, através

de um agendador de tarefas (Figura 7), também conhecido

como scheduler.


Número 110 9

FIGURA 7 - Agendador de tarefas.

METODOLOGIA DE CONTROLE DE ACESSO

Não basta ter um CMS, é necessário implementar uma metodo-

logia de controle de acesso e treinar os usuários para que enten-

dam a necessidade e os benefícios desse controle.

O melhor método a ser implementado em uma empresa depen-

de da realidade e dos costumes empresariais da mesma, sendo

muito específico para cada caso. Em alguns ambientes, o aces-

so direto ao controlador industrial é considerado uma operação

emergencial válida e essa premissa tem que ser respeitada. Em

outros casos, o controlador industrial não possui recursos que

impeçam um acesso direto, como pela porta serial e, mesmo que

tal procedimento não seja permitido, na prática será necessário

verificar se isso ocorreu (através dos uploads programados).

Quando o gerenciador de mudanças tem acesso on-line aos

controladores industriais e supervisórios da rede, o controle de

acesso é mais simples e eficiente (Figura 8).

FIGURA 8 - Arquitetura do gerenciador de mudanças on-line.

Mas existem situações em que o equipamento fica isolado, sem

acesso via rede. Neste caso, a solução típica é trabalhar off-line

(Figura 6), onde o usuário faz acesso primeiramente ao servidor


do sistema de gerenciamento e recupera a última versão exis-

tente para edição. Então, este se desconecta do servidor que,

por sua vez, reserva a edição desse projeto para este usuário

por um tempo pré-determinado, evitando assim que algum tra-

balho seja sobrescrito. O usuário do aplicativo terá esse tem-

po específico para carregar as devidas alterações no dispositivo

remoto e, então, devolver a última versão do programa, liberan-

do o acesso para a próxima necessidade de edição.

Caso o programa não seja devolvido no tempo pré-determina-

do, o responsável poderá prorrogar o prazo, caso contrário, a re-

serva do programa será cancelada, exigindo que o usuário faça

nova reserva, verificando se houve alteração por outro usuário

nesse intervalo.

OUTRAS FUNÇÕES IMPORTANTES

A possibilidade de criar telas com interface gráfica e com o tipo

de árvore de projeto mais intuitivo pode ser um fator facilitador

da aceitação do sistema, uma vez que não basta instalar um

bom produto para gerenciar mudanças, pois o verdadeiro con-

trole vem da utilização ampla e adequada do sistema.

Uma vez implementado, o sistema deve fazer parte do cotidia-

no de cada usuário, sendo, portanto, extremamente desejável

que possua uma interface de uso amigável, intuitiva. A inter-

face deve proporcionar agilidade e diminuir a possibilidade de

erros na operação do sistema. Na Figura 9 há um exemplo de

tela baseada em HTML, que permite a fácil navegação dentro

de cada área gerenciada, indicando os respectivos projetos ge-

renciados: CLP, IHM, supervisório e documentação.

FIGURA 9 – Exemplo de tela personalizada.

RELATÓRIOS

Um aspecto a ser considerado no CMS é a oferta de relató-

rios prontos e parametrizáveis, pois quanto mais comple-

tos forem, menor será a engenharia necessária e maior a


FIGURA 10 - Relatório para auditoria.

agilidade para implantação do gerenciamento de ver-

são. A lista de programas bloqueados, o histórico para

auditorias (Figura 10) e relação de acessos são al-

guns exemplos de relatórios básicos. É importante que

haja flexibilidade para determinar filtros, períodos, etc.

A comparação entre versões do mesmo programa, abordada

aqui anteriormente, também gera relatórios com diferentes

níveis de detalhamento. Na Figura 11, temos um exemplo de

FIGURA 11 – Relatório de comparação entre versões de um programa de CLP.

relatório de comparação entre versões de um programa de CLP,

com um índice de diferenças entre as duas versões compara-

das, dividido em: lógica de ladder, configuração do controla-

dor, registros de entrada/saída e tabela de forces. As Figuras

12 e 13 mostram o detalhamento de ladder e tabela de forces,

respectivamente.

FIGURA 12 – Relatório de comparação da lógica de ladder entre versões de um programa de CLP.


Número 110 11

FIGURA 13 - Comparação da tabela de forces entre versões de um CLP.

Em muitos casos, é possível até mesmo o detalhamento das

linhas de uma lógica de ladder, permitindo analisar a inclu-

são, exclusão ou modificação na lógica entre duas versões

quaisquer, sejam do mesmo projeto ou de projetos distintos.

Quando o CMS permite acionar comparações entre diferen-

tes projetos, este tipo de relatório também tem grande utili-

dade para comparar programas similares, rodando em CLPs

distintos, como os de máquinas iguais ou linhas de produção

semelhantes.

CONCLUSÃO

A implementação de um CMS traz retornos significativos para

as indústrias e variam de acordo com o perfil da empresa. Os

ganhos mais comuns estão descritos a seguir.

•Centralizando o backup e garantindo a freqüência e robus-

tez da sua realização, em caso de falha em um equipamen-

to ou sistema e existindo a necessidade de restauração de

backup, o processo se torna mais rápido e seguro, com re-

dução real do tempo de parada da planta ou área – o que

geralmente afeta diretamente a produtividade;

•A identificação de mudanças, sejam elas indevidas ou não,

permite detectar situações que requerem interferência. É o

caso de pontos que são sistematicamente forçados. A maior

visibilidade obtida através do gerenciamento de versão per-

mitirá que a empresa identifique a situação e aplique a so-

lução correta. Neste caso, é possível que seja feita uma re-

visão do programa do CLP para adequá-lo às práticas ope-

racionais com maior controle e segurança.

•Há uma tendência de diminuição na taxa de mudanças em

programas. A redução do volume de mudanças significa

redução direta de horas de trabalho com alterações, além

da redução dos riscos inerentes a essas alterações. Essa

tendência é decorrente de vários fatores:

a) maior controle de acesso no que tange as permissões de

usuário; isto leva o administrador do sistema a um melhor

planejamento das permissões e privilégios, de acordo com

a função de cada usuário;

b) possibilidade de exigir que a mudança requeira aprovação

de um supervisor;

c) a identificação do autor das mudanças e necessidade de co-

mentar cada alteração, com possibilidade de auditoria pos-

terior, inibem mudanças isoladas e conduzem a uma prá-

tica adequada de concentrar alterações, implementá-las e

testá-las de forma mais planejada.

A utilização de um CMS resulta no controle sistemático e ro-

busto das práticas de manutenção e implantação de sistema

de automação industrial. Tal sistema confere ao cotidiano dos

usuários e responsáveis pela manutenção uma metodologia

segura de uso de cada tecnologia existente em uma planta in-

dustrial. Mais do que uma tendência de mercado, essa tecno-

logia é uma necessidade real!

REFERÊNCIAS

1. Lei nº 11.638 de 28.12.2007. Publicada no D.O.U.: 28.12.2007 - Edição Extra

2. JOHNSON, H. T.; KAPLAN, R. S. (1993) - Contabilidade Gerencial - a restauração da relevância da contabilidade nas empresas. Rio de Janeiro, ed. Campus.

3. International Accounting Standard Board (IASB) - FINANCIAL ACCOUNTING STANDARDS BOARD. Statement of Financial Standards nº 142: Goodwill and Other Intangible Assets. June, 2001.

4. EPSTEIN, Barry J.; MIRZA, Abbas Ali. WILEY IAS 2004: Interpretation and Application of International Accounting and Financial Reporting Standards. New York: John Wiley & Sons, 2004.

5. ISO/IEC 27002:2005. Código de Práticas para Gestão da Segurança da Informação.

6. ABNT NBR ISO/IEC 17799. Código de Práticas para Gestão da Segurança da Informação.

7. Federal Register - Rules and Regulations. Vol. 62, No. 54. March, 1997. “Department of Health and Human Services - Food and Drug Administration - 21 CFR Part 11”.

8. Guide to the ISA-99 Standards – Manufacturing and Control Systems Security - Rev.4 – November, 2005.


InTech110

Documents

Transcript of InTech110