quarta-feira, 25 de abril de 2012

System Administration Certification exam 918 for IBM Informix Dynamic Server 11 prep, Part 1– Instalação e Configuração do Informix

Configurando a Conectividade

Existem três metodos disponiveis para a configuração da conectividade entre client-server e o sistema on-line:

  1. Através de uma conexão de memória compartilhada. Quando a aplicação cliente o e servidor de banco de dados estão no mesmo computador, este é o método preferido de comunicação. Aplicação e o servidor de banco de dados trabalha no mesmo segmento de memória compartilhada.
  2. Através de uma conexão TCP/IP, usando SOCKETS ou uma interface de programação TLI. TCP/IP pode ser usado em ambas comunicações,locais e remoto.
  3. Através  de uma conexão “stram pipe”. Isso é uma conexão local, metodo de comunicacao que o UNIX utiliza.
arquivo sqlhosts

Quando um aplicativo tenta uma conexão com um servidor de banco de dados, há algumas informações basicas que necessitam ser configuradas para fazer a conexão. Essas informações  estão armazenadas em $INFORMIXDIR/etc/sqlhosts, um arquivo que deve ficar no diretorio $INFORMIXDIR/etc. Para alterar o local do arquivo slqhosts, utilize a variavel de ambiente INFORMIXSQLHOSTS. Cada servidor que hospeda um banco de dados ou um cliente deve ter um arquivo sqlhosts.

Cada entrada (cada linha) do arquivo sqlhosts contem as informações para um banco de dados. Utilize espaços em brancos (espaços, tabulação ou ambos) para separar os campos. Não inclua espaços em branco ou tabulação dentro de um campo. Para colocar comentarios no arquivo sqlhosts, inicie a linha com um caracter (#). Você também pode deixar linhas totalmente me branco para facilitar a leitura.  Regras de sintaxe adicionais para cada um dos campos serão fornecidos nas postagens seguintes, que descrevem as entradas no arquivo sqlhosts. Use um editor de texto padrão para inserir as informações no arquivo sqlhots.

Exemplo de um arquivo sqlhosts
dbservername nettype hostname servicename
tst onipcshm isis tst
tstsoc onsoctcp isis tstsrv
prdsoc onsoctcp vishnu prdsrv

dbserver corresponde à variavel de ambiente INFORMIXSERVER e DBSERVERNAME ou DBSERVERALIASES no arquivo ONCONFIG.

A coluna nettype contém informações cruciais sobre tipo de servidor de banco de dados e como as conexões vão ser feitas. O nettype consiste em oito letras dividas em três categorias.

As duas primeiras letras representam o produto do banco de dados. As proximas três letras referem-se a interface de programação usado para a conexão. As três ultimas letras referem-se ao protocolo especifico ou mecanismo IPC.

onde:

d = produto,
i = interface,
p = protocolo

ddiiippp

on – Dynamic Server
se – Standard Engine

ipc – Conexão IPC
tli – Conexão TLI
soc – Conexão socket

shm – Shared memory
str – Stream pipes
tcp – Protocolo TCP/IP
spx – Protocolo IPX/SPX

Hostname  é o nome do servidor que esta armazenado o banco de dados.

Todos os nomes de serviços é necessario estar no /etc/services.

Exemplo de um arquivo /etc/services

tstsrv 1550/tcp
prdsrv 1540/tcp

terça-feira, 24 de abril de 2012

Planejamento para um cluster de alta disponibilidade em Informix

Antes de você iniciar  a configuração dos servidores e banco de dados para usar com um cluster de alta disponibilidade, você pode querer fazer um planejamento inicial. A lista a seguir contem as tarefas a realizar:

  • Escolher e adquirir hardware apropriados;
  • Se você estiver usando mais de um servidor de banco de dados para armazenar dados que você deseja replicar, migrar dados e redistribuir, veja se existe a possibilidade de ser gerenciado por um unico servidor de dados.
  • Assegurar que todos os banco de dados que você deseja replicar esteja em modo “transaction loggin”.
  • Desenvolver aplicativos para fazer uso de ambos os servidores de banco de dados de replicação.
  • Criar uma programação para iniciar o HDR pela primeira vez.
  • Projetar um espaço de armazenamento e programação dos backups de logical logs para o servidor de banco de dados primario.
  • Produzir um plano de como lidar com falhas de um servidor de banco de dados e como reiniciar o HDR após uma falha.

Configurando Clusters

Para configurar seu sistema como um cluster de alta disponibilidade, você deve tomar as seguintes ações:

  • Conheça os requisitos de hardware e sistema operacional;
  • Atender aos requisitos dos dados de banco de dados;
  • Atender aos requisitos de configuração do banco de dados;
  • Configurar a conectividade.

Vamos explanar cada item acima.

Você pode configurar seu sistema para usar o Secure Sockets Layer (SSL), um protocolo de comunicação que garante a privacidade e integridade dos dados transmitidos através da rede, para a comunicação do HDR. Você pode usar o protocolo SSL para conexões entre os servidor primario e secundario e para conexões com servidores secundarios Remote Standalone(RS) e Shared Disk(SD) em uma configuração de alta disponibilidade.

Requisitos de Hardware e Sistema Operacional

Para um cluster de alta disponibilidade funcionar, o hardware deve atender a certos requisitos.

O hardware deve atender aos seguintes requisitos:

  • Os servidores primario e secundario deve ser capaz de executar  a mesma imagem do IBM Informix, mesmo que eles  não tenham Hardware e Sistemas Operacionais identicos. Por exemplo, você pode usar servidores com diferentes Sistemas Operacionais Linux 32-bit porque nesses Sistemas Operacionais a imagem do Informix poderá ser executada. Nesta situação, você não pode  adicionar um Servidor com Sistema Operacional Linux 64-bit porque nesse Sistema Operacional é exigida uma outra imagem do Informix, (Informix 64-bit). Verifique o arquivo “machine notes”: você poderá utilizar alguma combinação de hardware e Sistemas Operacionais suportados no mesmo arquivo “machine notes”.
  • Os Hardwares que executa os servidores primario e secundario devem suportar conectividade com redes.
  • A quantidade de espaço em disco alocado para os dbspaces secundario devem ser identicos ao servidor primario. O tipo de espaço em disco  é irrelevante; você pode usar uma mistura de raw devices com cooked files nos dois servidores.
  • Os chunks nos dois servidores devem estar no mesmo caminho. Os links simbólicos são permitidos em plataformas UNIXs, mas não na plataforma Windows.

Requisitos dos dados e banco de dados

Os dados e banco de dados deve atender aos seguintes requisitos:

  • Todos os dados devem ser “logged”.

    Todos os banco de dados que você quer replicar deve estar em modo “transaction logging”.

    Este requisito é importante porque o servidor de banco de dados secundario utiliza os registros de logical logs do servidor primario para se auto atualizar. Se o banco de dados primario não utiliza o logical logs, não será capaz de gerar os logical logs para atualizar os outros servidores. Os registros podem ser “buffered” ou “unbuffered”.
  • Os dados deve estar localizado no mesmo dbspace ou sbspaces

    Se o servidor primario tem “simple large objects” armazenados em blobspaces, modificações nos dados dentro dessa blobspace não são replicados como parte do processamento normal do HDR. No entanto,  dados “simple large objects” são replicados.

    ”Smart large objects”, que são armazenados em sbspaces, são replicados. O sbspace deve estar em “logged”. “User-defined types” (UDTs) são replicados, a menos que eles estejam armazenados no Sistma Operacional.
  • Os servidores secundarios não deve usar compressão de disco.

    Se você utilizar o recurso de compressão de disco do Informix, dados que é comprimido na tabela de origem é comprimido na tabela de destino. Você não pode executar operações de compactação em um servidor HDR secundario., RS secundario ou SD secundario, porque o servidor HDR de destino deve ter os mesmos dados e layout físico com o servidor de origem.

Requisitos de configuração do servidor de banco de dados

Para os servidores de alta disponibilidade do cluster funcionar, você deve configurar completamente cada um dos servidores de banco de dados.

Estes tópicos descrevem as considerações de configuração para os pares de cluster de servidor de banco de dados:

  • Versão do servidor de banco de dados
  • Configuração do dbspace e chunk
  • Tamanhos de paginas em ambientes HDR
  • Espelhamento
  • Configuração do Physical-log
  • Dbspace e dispositivos de backup para  logical-log
  • Configuração dos Logical-logs
  • Configuração dos parametros do HDR
Versão do servidor de banco de dados

A versão do servidor de banco de dados no servidor primario e secundario deve ser identicas.

Configuração do dbspace e chunk

O numero de dbspaces, o numero de chunks, os seus tamanhos, os nomes de caminhos, e seus offsets devem ser identicos nos servidores,  primario e secundarios. Além disso, a configuração deve conter pelo menos um dbspace temporário se o HDR secundario for usado para gerar atividades de relatorios.

somente UNIX:

Você deve usar links simbolicos para os chunks criados em raw devices.

Importante: Se você não usar links simbolicos para os nomes do caminho dos chunks, você não poderá mudar o nome do caminho de um chunk facilmente.

Os seguintes parâmetros do ONCONFIG devem ter o mesmo valor em cada um dos servidores HDR:

  • ROOTNAME
  • ROOTOFFSET
  • ROOTPATH
  • ROOTSIZE
Tamanhos de paginas em ambientes HDR

O tamanho de paginas de um dbspace, e e as especificações do buffer pool são propagadas automaticamente do servidor primario para o servidor secundario. Embora o servidor primario e os secundarios devem ter os mesmos buffer pools, os números de buffers em buffer bool não são obrigatórios.

Espelhamento

Você não é obrigado a definir o parametro MIRROR para o mesmo valor nos dois servidores de banco de dados; você pode habilitar o espelhamento em um servidor de banco de dados e desabilitar no outro servidor. Entretanto, se você especificar um chunk espelhado para o rootdbs do servidor primario, você tera que especificar um chunk espelhado também para o servidor secundario. Portanto, os seguintes parametros do ONCONFIG deve ser definido para o mesmo valor em ambos os servidores de banco de dados:

  • MIRROROFFSET
  • MIRRORPATH
Configuração do Physical-log

O physical log deve ser identico em ambos os servidores. A seguir os parametros do ONCONFIG que devem ser os mesmos valores em cada servidor:

  • PHYSBUFF
  • PHYSFILE
Dbspace e dispositivos de backup para logical-log

Você pode especificar diferentes  dispositivos de fitas para os servidores primario e secundario.

Se você usa o ON-Bar, configure os parametros de configuração do ON-Bar com os mesmos valores em ambos os servidores.

Se você utiliza o ontape, o tamanho do dispositivo e o bloco do dispositivo para o dispositivo de armazenamento e logical-log devem ser identicos.   A seguir os parametros do ONCONFIG que devem ter os mesmos valores em ambos os servidores:

  • LTAPEBLK
  • LTAPESIZE
  • TAPEBLK
  • TAPESIZE
Configuração dos Logical-logs

Todos os registros de logical-logs são replicados para o servidor secundario. Você deve configurar os numeros de arquivos de logical-log e o tamanho dos logical-log com valores iguais em ambos os servidores. Abaixo segue parametros do ONCONFIG que devem ter os mesmos valores:

  • LOGBUFF
  • LOGFILES
  • LOGSIZE
  • DYNAMIC_LOGS
Configuração dos parametros do HDR

A seguir os parametros de configuração do HDR que devem conter o mesmo valor em ambos os servidores:

  • DRAUTO
  • DRINTERVAL
  • DRTIMEOUT

segunda-feira, 23 de abril de 2012

System Administration Certification exam 918 for IBM Informix Dynamic Server 11 prep, Part 1– Instalação e Configuração do Informix

Gerenciando espaço em disco

O servidor de banco de dados utiliza as seguintes físicas para gerenciar disco:

  • Chunk
  • Page
  • Extent
  • Blobpage
  • Sbpage

Chunk

Chunk é uma unidade de disco ou um espaço físico atribuído para o servidor. Um chunk pode ser um raw device (device de character especial) ou arquivo UNIX (cooked file). Quando atribuir chunk para o server, você precisa especificar os três valores seguintes:

  1. Pathname: o caminho do arquivo ou o nome do raw device a ser utilizado para o chunk.
  2. Offset: a distância física, especificado em KB a partir do início do dispositivo onde a leitura e escrita do dispositivo começa. Se você criar chunks usando cooked files, use o offset como zero; o offset maior que zero é somente usado com raw devices.
  3. Size: é o tamanho do espaço criado em KB, atribuido para ser utilizado com raw device a partir do offset ou o tamanho do arquivo UNIX usado para o chunk.

O server tem um limite lógico de 32.767 chunks. No entando, o Kernel do UNIX pode ter limitações para o numero de arquivos de um processo.

Page

É a unidade basica que o server utiliza para I/O é paginas. Começando pela versão 10 do IDS, o tamanho da pagina não é mais corrigido com base na plataforma do produto. Qualquer chunk/dbspaces criado após o root dbspace pode ter tamanhos de paginas entre 2K à 16K. Usando multiplos de tamanho de paginas como padrão. Um conjunto de buffers  é criado se não existir paginas do tamanho especificado.

Extent

Coleção de paginas fisicas continuas em um disco. Tamanhos das extents da tabela são especificados no momento da criação da tabela.

Blobpage

Blobpage é a unidade básica de armazenamento para os dados tipos blobs armazenados em blobspaces. O tamanho da blobpage pode ser configurado para ser múltipo do tamanho de paginas do sistema.

Sbpage

Um sbpage é um tipo de pagina que o server usa para armazenar objetos grandes (smart large objects) dentro de um sbspace. Ao contrario dos blobpages, sbpages não são configuraveis. Sbpage é do mesmo tamanho das paginas do servidor de banco de dados.

Unidades Lógicas

O servidor de banco de dados armazena as dados nas seguintes unidades lógicas:

  • Dbspace
  • Blobspace
  • Sbspace
  • Tblspace

Dbspace

Dbspace é uma coleção lógica de um ou mais chunks usados para armazenar bando de dados e tabelas. Cada dbspace deve ter pelo menos um chunk atribuido a ele.

Blobspace

Um blobspace é uma unidade lógica de armazenamento composto de um ou mais chunks que armazena somente dados TEXT e BYTE. O servidor de banco de dados gravados em blobspaces diretamente em discos. Estes dados não passam pela shared memory residente.

Sbspace

Um sbspace é um unidade lógica de armazenamento composto de um ou mais chunks que armazena os “smart large objects”, isso incluem BLOB, CLOB e UDTs (user-defined data type).

Tblspace

Tblspace é uma coleção de todos os extents alocados para armazenar informações  para uma detrminada tabela ou índice em um único dbspace. Espaço representado por uma tblspace não são continuas necessáriamente, mas o espaço representado por qualquer uma das extents são continuos.

Criando dbspace com onspaces

onspaces
-c
-d <dbspace>
-k <pagesize>
-m <mpathname moffset>
-o <offset>
-p <pathname>
-s <size>
-t <tempspace>


onde

spacename é o nome da dbspace a ser criada.
pagesize é o tamanho das paginas a ser criada para o novo dbspace.
mpathname é o pathname do mirror
moffset é o offset do mirror
offset é offset dentro do dispositivo em KB.
pathname é o caminho para inicializar o chunk.
-t indica que o dbspace criado é temporario.

Exemplo: Para criar um dbspace espelhado de 1 milhão de KB chamado de dbspace1 com offset de 200.000 KB para inicializar um chunk primario e um offset de 450.000 para o chunk espelhado.

onspaces –c –d dbspace1 –p /dev/rdsk/device1 –o 200000 –s 1000000 –m /dev/rdsk/device2 450000

Criando blobspace

onspaces
-c
-b <spacename>
-g <blobpagesize>
-m <mpathname moffset>
-o <offset>
-p <pathname>
-s <size>

Exemplo: Para criar um blobspace espelhado de 1 milhão de KB chamado de blobsp1 com offset de 200.000 KB para inicializar ambos chunks (primario) e um chunk espelhado e um blobpage de 100 KB (2K tamanho da pagina do sistema).

onspaces –c –b blobsp1 –g 50 –p /dev/rdsk/device8 –o 200000 –s 1000000 –m /dev/rsdk/device9 200000

Criando um sbspace

-c
-S <spacename>
-m <mpathname moffset>
-o <offset>
-p <pathname>
-s <size>
-t
-Ms <metasize>
-Mo <metaoffset>
-Df <options>

onde

spacename é o nome do blobspace a ser criado.
blobpagesize é o tamanho do blobpage em número de páginas em disco.
mpathname é o pathname do espelhamento
moffset é o offset do mirror
pathname é o caminho do chunk.
size é o tamanho do chunk em KB.
-t indica se o dbspace criado é temporario
metasize é o tamanho da área do sbspace em KB
metaoffset é o tamanho da área do offset do sbspace em KB.

Exemplo: Para criar um sbspace espelhado de 1 milhão de KB chamado de sbspace1 com um offset de 200.000 KB para inizializar ambos chunks (primario) e um chunk espelhado , com um metadado no tamanho de 7500 KB com 10000 KB de offset e uma expectativa média  de smart blobsize de 32KB.

onspaces –c –S sbspace1 –p /dev/rdsk/device5 –o 200000 –s 1000000 –m /dev/rdsk/device6 200000 –Ms 7500 –Mo 10000 –Df “AVG_LO_SIZE=32”

Eliminando Espaços

O utilitario onspaces pode ser usado para eliminar um dbspace, blobspace ou sbspace via linha de comando do sistema. Antes de um dbspace ser eliminado, todos os bancos e tabelas criados nesse dbspace deve ser eliminado.

Antes de um blobspace ser eliminado, todas as tabelas que possuem coluna TEXT/BYTE do blobspace tem que ser eliminado.

Exemplo:

onspaces –d dbspace1

Adicionando um chunk para um dbspace ou blobspace

O utilitario onspaces pode ser usado para adicionar um chunk num dbspaces ou blobspaces.

onspaces
-a <spacename>
-m <mpathname moffset>
-o <offset>
-p <pathname>
-s <size>

Exemplo: Para adicionar um chunk espelhado de 500.000 KB para o dbspace dbspace2 com 100.000 KB de offset.

onspaces –a dbspace2 –p /dev/rdsk/device4 –o 100000 –s 500000

Adicionando um chunk para um sbspace

o utilitario onspace pode ser usado para adicionar chunk para um sbspace.

Exemplo: Para adicionar um chunk espelhado de 100.000KB a um sbspace (sbspace1) com um offset de 20.000 KB para inicializar ambos chunks e metadado de 750 KB e 1000 KB de offset.

onspaces –a sbspace1 –p /dev/rdsk/chunk6 –o 20000 –s 100000 –m /dev/rdsk/chunk7 –Ms 750 –Mo 1000

SQL admin API

Você pode usar  as nova função SQL de administração para funções API para realizar  tarefas administrativas remotamente através do EXECUTE FUNCTION de SQL. Eles são as funções ADMIN e TASK. Estes fornecem uma interface SQL para administração como uma linha de comandos.  Só podem ser chamado pelo usuário informix e são definidos no banco de dados sysadmin.

As funções ADMIN  e TASK executa uma tarefa especifica o que equivale a um utilitário administrativo, insere uma nova linha dos historicos de comandos na tabela command_history do banco de dados sysadmin.

Criando um dbspace usando a função TASK()

EXECUTE FUNCTION TASK (‘create dbspace’, ‘dbs1’, ‘/dev/rdsk/device1’,’200000’,’1000000’);
Output: (expression) Space ‘dbs1’ added.

Eliminando um dbspace usando a função TASK()

EXECUTE FUNCTION TASK (‘drop dbspace’,’dbs1’);
Output (expression) Space ‘dbs1’ dropped.
** WARNING ** A level 0 archive will need to be done before any chunks from
DBspace dbs1 can be reused (see Dynamic Server Administrator’s manual).

Adicionando espelhamento para o dbspace acima usando a função TASK()

EXECUTE FUNCTION TASK (‘add mirror’, ‘dbs1’,’/dev/rdsk/device1’,’200000’,’/dev/rdsk/device2’,’450000’);
Output: (expression) Mirror chunk ‘/dev/rdsk/device2’ added to space ‘dbs1’

Criando um blobspace usando a função TASK()

EXECUTE FUNCTION TASK (‘create blobspace’, ‘blobsp1’, ‘/dev/rdsk/device8’, ‘50’,’200000’,’1000000’);
Output: (expression) Space ‘blobsp1’ added.

quarta-feira, 18 de abril de 2012

Guia do Iniciante para HDR no IDS 11.50

Conceitos e Beneficios do HDR

  • HDR permite  que todos os dados em uma instancia IDS seja copiada em um outro servidor em uma rede;
  • É uma “instace level”, tecnologia de replicação para fornecer copias de seus dados para outros servidores Informix.
  • Não tem restrições, como exigir chaves primarias em suas tabelas, etc. Exige que seus bancos de dados sejam “logged”,  no entento, sua tecnologia é baseada nos registros de logs. Isso não replica dados BLOBspaces.
  • Sistemas Operacionais subjacentes e versão do IDS deve ser identica nos servidores envolvidos o HDR.
  • Beneficios em caso de desastres: Servidores e Dados são redundantes minimizando o downtime
  • Pode-se criar um Servidor de relatorios com o servidor secundario, tendo o beneficio da performance: descarregamentos de algumas atividades, queries no servidor secundario. Melhor performance.
  • Dados locais para usuarios remotos, melhor performance.

HDR antes da versão 11

  • Primario: Este é o servidor que os usuários normalmente se conectam. Permite atualizações de dados, como de costume.  Este é a fonte de dados copiado para o secundario.
  • Secundario: Um servidor de backup somente leitura que recebe atualizações do primario.

HDR (IDS 11.50)

  • Primario: Este é o servidor que os usuários normalmente se concectam. Permite atualizações de dados  como de costume. Este é a fonte de dados copiado para o secundario.
    Uma das melhorias mais importantes em HDR a partir da versão 11.10 é que agora você pode ter multiplos servidores secundarios, ates você estava limitado a somente um servidor secundario. Alem disso, existem diferentes tipos de servidores secundarios que lhe permite uma configuração adequada para suas necessidades empresarias.
  • Secundario: Servidor de backup que recebe os dados do servidor primario. Ele também permite UPDATEs usando o “redirect writes” (ex, as atualizações  são realmente enviadas para o servidor primario e, em seguida recebidos através de replicação.
  • Checkpoints entre o servidor Primario e o HDR secundario são sempre sincronizados.
  • Commits entre o servidor Primario e o servidor secundario pode ou não ser sincronizados (depende da sua configuração).
  • Servidor secundario Standalone remoto (RSS): Um novo tipo  de servidor secundario foi introduzido na versão 11.10 o que é atualizado em modo assincrono e tem mais conectividade mais flexivel com o servidor primário.
  • Adequado para usar como um servidor de relatorios e tambem locais distantes geograficamente e em redes de baixa velocidade, para fazer balanceamento de CPU, memoria, e tambem como um rápido  e facil failover se o servidor primario falhar.
  • Requer indexação em paginas de logging.
  • Shared Disk Secondary (SDS): Um novo tipo de servidor secundario introduzido na versão 11.10. Tal como o nome implica, ele não tem sua própria  copia separada do espaços de disco. Discos compartilhados com o servidor primario.
  • Normalmente usado com arrays de discos ou SAN shared

HDR no IDS 11.50

  • Os servidores que participam do HDR são servidores IDS regulares, colocado em um papel especifico ( primario, HDR, secundario, RSS, SDS) usando o comando onmode.
  • Pode haver um servidor primario, zero ou um HDR secundario, e zero, um multiplos servidores RSS e SDS em um clauster MACH 11 ( MACH = Multi node Active Cluster for High availability)
  • Servidores RSS/SDS pode ser seus unicos servidores secundarios, ou eles podem ser utilizados com um HDR secundario.
  • HDR é inicialmente configurado com um backup nivel zero e um physical restore (execto para servidores SDS).
  • Após a configuração inicial, os dados entre os servidores são mantidos em sincronia usando os logical logs.

hdr

  • DRINTERVAL – parametro onconfig que controla se a replicação ocorre de maneira assincrona ou sincrona.
  • DRINTERVAL –1 – (sincrono, ex. servidor primario aguarda por notificação vindo do servidor secundario antes de descarregar o logical-log buffer, como um commit)
  • DRINTERVAL outro valor exeto –1 ( assincrono – exemplo 30 segundos)
  • HDR Threads
    • drprsend: (primario) envia buffers
    • drsecrecv: (secundario) recebe buffers
    • drprping: (primario) checa a conectividade
    • drsecping: (secundario) checa a conectividade
    • drsecapply: (secundario) recepção da copia do buffer para o recuperação do buffer
    • logrecvr: (secundario) recuperação logica – atualização dos dbspaces
    • RSS_send: usa uma comunicação full duplex ( ex. sem aguardar o recebimento de uma notificação), esse thread envia paginas de logs para um servidor RSS. (roda no servidor primario)
    • RSS_recv: recebe paginas de logs vinda do servidor primario. (roda no servidor RSS)
    • RSS_apply: copia o conteudo do buffer de recepção para o buffer de recuperação. (roda no RSS server)
  • Atualizando o servidor secundario através do Redirected Writes
    • uma das melhorias mais significantes na versão HDR 11.50
    • Servidores secundarios (todos os tipos) agora permitem atualizações de dados.
    • As atualizações são transferidas para o servidor primario e então propagadas de volta para o servidor secundario
    • Inserts, updates e deletes para a maioria dos tipos de dados são suportados.
    • Usando as novas caracteristicas de controle de versões do IDS faz escritas redirecionadas  trabalhando com maior eficiencia.
  • Gerencimaneto de conectividade
    • Novo componente de software que gerencia os pedidos de conexões a partir das aplicações clientes.
    • Permite você definir niveis de serviços (SLAs) e configuração automatica failover.
    • Monitora todos os servidores dentro do clauster.
    • Pode decidir sobre o servidor mais adequado para a conexão da aplicação cliente.
  • Planejar um servidor HDR é obrigação
  • Requisitos de negocios ( ex. planejamento de recuperação de desastre, capacidade adicional de comunicação, dados locais) conduz a configuração técnica.
  • Com base nos requisitos de negocios, hardware/software disponiveis e redes disponiveis, você decidira sobre o tipo  e o numero de secundários.
  • Sistema Operacional e versão do Informix tem que ser identica.
  • Layouts dos chunks deve ser identico ( mas espelhamentos de chunks não há necessidade)
  • Banco de dados devem ser logged.

Planejamento e configuração do HDR

DRAUTO

0 (OFF) – significa não mudar automaticamente o tipo de servidor.
1 (RETAIN_TYPE) – significa mudar automaticamente do secundario para o padrao se a replicação falhar, volta para o secundario  quando o HDR reinicializar.
2 (REVERSE_TYPE) – significa mudar automaticamente do secundario para o padrao numa falha, para o primario quando o HDR reinicializar.

DRIDXAUTO

0 (off) significa que não há replicação automatica de indices para o secundario caso esteja corrompido.
1 (on) significa replicação automatica dos indices  para o servidor secundario se os indices estiverem corrompidos.  A configuração habilitada é requerida para servidores RSS.

DRINTERVAL

Interalo maximo, em segundos, entre a descarga do buffer de replição.
Valores aceitos –1, 0 e valores positivos inteiros
Valor padrão é de 30 segundos o que significa que se pode levar até 30 segundos para que as alterações do servidores primarios seja replicado para o servidor secundario.
-1 – significa configuração sincrona.

DRLOSTFOUND

Caminho para os arquivos lost&found da replicação.
Quando a replicação assincrona é utilizada e em caso de falha, isso possibilita que algumas transações sejam comitadas no servidor primario mas não no servidor secundario. Essas transações são armazenadas em um arquivo em lost&found.

DRTIMEOUT

Periodo de tempo, em segundos, que o servidor primario aguarda para receber uma notificação vinda do servidor secundario.
Após este periodo de tempo decorrido e sem notificação de recebimento, o Informix reconhece que houve uma falha.
Default é 30 segundos.

Passo a passo:

Requisitos e planejamento são completos e seguindo um cenário tipico é selecionado:

passo

Primeiro passo:

Assegurar que todos os servidores tem o TCP/IP necessário configurados como por exemplo /etc/hosts.

vishnu server

vishnu:~ # cat /etc/hosts
#
# hosts         This file describes a number of hostname-to-address
#               mappings for the TCP/IP subsystem.  It is mostly
#               used at boot time, when no name servers are running.
#               On small systems, this file can be used instead of a
#               "named" name server.
# Syntax:
#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#

127.0.0.1       localhost


10.0.1.5        vishnu.ajmsolutions vishnu
10.0.1.9        isis.ajmsolutions isis
vishnu:~ #

isis server

isis:~ # cat /etc/hosts
#
# hosts         This file describes a number of hostname-to-address
#               mappings for the TCP/IP subsystem.  It is mostly
#               used at boot time, when no name servers are running.
#               On small systems, this file can be used instead of a
#               "named" name server.
# Syntax:
#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#

127.0.0.1       localhost

10.0.1.9        isis.ajmsolutions isis
10.0.1.5        vishnu.ajmsolutions vishnu
127.0.0.2      isis.ajmsolutions isis
isis:~ #

Segundo passo:

Assegurar que todos os servidores estão em modo de confiança entre si (“trust mode”) -  /etc/hosts.equiv

vishnu server

vishnu:~ # cat /etc/hosts.equiv
#
# hosts.equiv   This file describes the names of the hosts which are
#               to be considered "equivalent", i.e. which are to be
#               trusted enough for allowing rsh(1) commands.
#
# hostname
isis
vishnu:~ #

isis server

isis:~ # cat /etc/hosts.equiv
#
# hosts.equiv   This file describes the names of the hosts which are
#               to be considered "equivalent", i.e. which are to be
#               trusted enough for allowing rsh(1) commands.
#
# hostname

vishnu
isis:~ #

Terceiro Passo:

Verifique se o serviço do informix (ports) de cada servidor não esta bloqueado e esta sendo reconhecido em cada servidor (/etc/services)

vishnu server

vishnu:~ # cat /etc/services |egrep "prdsrv|tstsrv"
prdsrv          1540/tcp
tstsrv           1550/tcp
vishnu:~ #

isis server

isis:~ # cat /etc/services |egrep "prdsrv|tstsrv"
prdsrv          1540/tcp
tstsrv          1550/tcp
isis:~ #

Quarto Passo:

Garantir que cada servidor tem entradas dos outros servidores em seus arquivos sqlhosts do Informix. Você deve usar uma conexão TCP/IP e não conexões de memorias compartilhadas  para configuração do HDR.

vishnu server

informix@vishnu:/> cat $INFORMIXDIR/etc/sqlhosts
#**************************************************************************
#
#  Licensed Material - Property Of IBM
#
#  "Restricted Materials of IBM"
#
#  IBM Informix Dynamic Server
#  (c) Copyright IBM Corporation 1996, 2004 All rights reserved.
#
#   Title:      sqlhosts.demo
#   Description:
#               Default sqlhosts file for running demos.
#
#**************************************************************************
# IANA (www.iana.org) assigned port number/service names for Informix:
# sqlexec 9088/tcp
# sqlexec-ssl 9089/tcp

prd        onipcshm     vishnu    prd
prdsoc  onsoctcp       vishnu   prdsrv
tstsoc   onsoctcp       isis         tstsrv

informix@vishnu:/>

isis server

informix@isis:~> cat $INFORMIXDIR/etc/sqlhosts
#**************************************************************************
#
#  Licensed Material - Property Of IBM
#
#  "Restricted Materials of IBM"
#
#  IBM Informix Dynamic Server
#  Copyright IBM Corporation 1996, 2009
#
#   Title:           sqlhosts.demo
#   Description:     Default sqlhosts file for running demos.
#
#**************************************************************************
# The connectivity information for each database server includes four fields
# of required information and one optional field. You can also configure
# database server groups.
#
# The format for the five fields of connectivity information for a database
# server is one line in the UNIX  sqlhosts file, as follows:
#
# <dbservename> <nettype> <hostname> <servicename> <options>
#
# dbservername is the name of a database server on the network.
#
# nettype is an 8-character string specifying the protocol in this format:
#
# ddiiippp
#
# where
#   dd  =  Database product [|ol|on|dr]
#   iii =  Interface type [ipc|soc|tli|sql]
#   ppp =  Protocol [imc|nmp|shm|spx|str|tcp|ssl|mux]
#
# hostname is the name of the computer where the database server resides.
#
# servicename is a service name entry from the services file.
#
# options in the fifth field:

#
#   b=<connection buffer size>
#   c=<connection redirection>
#   g=<group name>
#   i=<group identifier>
#   e=<end of group>
#   m=<multiplexed connection>
#   k=<keep alive setting>
#   r=<client security setting>
#   s=<server security setting>
#   csm=<communication support module>
#
# To create an entry for a group, put a group name in the dbservername field,
# the word group in the nettype field, a hyphen in both the hostname and the
# servicename fileds, and i=<group identifier> in the options field.
#
# For additional information on the parameters, see the IBM Informix
# Administrator's Guide.
#**************************************************************************
# IANA (www.iana.org) assigned port number/service names for Informix:
# sqlexec 9088/tcp
# sqlexec-ssl 9089/tcp


tst         onipcshm        isis               tst
tstsoc   onsoctcp          isis               tstsrv
prdsoc  onsoctcp          vishnu          prdsrv
informix@isis:~>

Quinto Passo:

Assegure-se que os seguintes valores do ONCONFIG estejam identicos entre os servidores.

ROOTNAME, ROOTPATH, ROOTOFFSET, ROOTSIZE
PHYSDBS, PHYSFILE
TAPEBLK, TAPESIZE, LTAPEBLK, LTAPESIZE
LOGFILES, LOGSIZE
DRAUTO, DRINTERVAL, DRTIMEOUT

Sexto Passo:

Pegue um archive nivel 0 do servidor primario (vamos utilizar mais adiante)

Setima Passo:

Configurar o servidor primario para iniciar como um primario ligando ao servidor secundario

informix@vishnu:~/etc> onmode -d primary tstsoc

Oitavo Passo

Restaurar o archive nivel 0 como uma restauração fisica no HDR secundario.

informix@isis:~> ontape -p
Restore will use level 0 archive file /ontapeDir/archiveDir/isis_0_L0. Press Return to continue ...


Archive Tape Information

Tape type:      Archive Backup Tape
Online version: IBM Informix Dynamic Server Version 11.50.FC8GE
Archive date:   Wed Apr 18 11:58:18 2012
User id:        informix
Terminal id:    /dev/pts/0
Archive level:  0
Tape device:    /ontapeDir/archiveDir/
Tape blocksize (in k): 32
Tape size (in k): system defined for directory
Tape number in series: 1

Spaces to restore:1 [rootdbs                                                                                                                         ]
2 [dbsphyslog                                                                                                                      ]
3 [dbslog                                                                                                                          ]
4 [dbsnfe                                                                                                                          ]
5 [prd                                                                                                                             ]
6 [dbscrm                                                                                                                          ]

Archive Information

IBM Informix Dynamic Server Copyright 2001, 2010  IBM Corporation.
Initialization Time       07/17/2011 00:47:09
System Page Size          2048
Version                   18
Index Page Logging        OFF
Archive CheckPoint Time   04/18/2012 11:58:17

Dbspaces
number   flags    fchunk   nchunks  flags    owner                            name
1        40001    1        1        N  B     informix                         rootdbs                                                        
2        40001    2        1        N  B     informix                         dbsphyslog                                                     
3        40001    3        1        N  B     informix                         dbslog                                                         
4        42001    4        1        N TB     informix                         dbstmp1                                                        
5        42001    5        1        N TB     informix                         dbstmp2                                                        
6        42001    6        1        N TB     informix                         dbstmp3                                                        
7        40001    7        1        N  B     informix                         dbsnfe                                                         
8        40001    8        8        N  B     informix                         prd                                                            
9        40001    16       1        N  B     informix                         dbscrm         

Chunks
chk/dbs offset   size     free     bpages   flags pathname
1   1   0        150000   114833            PO-B  /dbroot/rootdbs
2   2   0        500053   0                 PO-B  /dblogs/physlog/dbsphyslog
3   3   0        1750053  0                 PO-B  /dblogs/logs/dbslog
4   4   0        200053   199527            PO-B  /dbtmp/dbstmp.1
5   5   0        200053   199750            PO-B  /dbtmp/dbstmp.2
6   6   0        200053   199644            PO-B  /dbtmp/dbstmp.3
7   7   0        1500053  1145313           PO-B  /dbnfe/dbsnfe
8   8   0        1500053  63                PO-B  /dblogix/prd.1
9   8   0        1500003  16                PO-B  /dblogix/prd.2
10  8   0        1500003  18                PO-B  /dblogix/prd.3
11  8   0        1500003  175               PO-B  /dblogix/prd.4
12  8   0        1500003  284               PO-B  /dblogix/prd.5
13  8   0        1500003  86187             PO-B  /dblogix/prd.6
14  8   0        1500003  1500000           PO-B  /dblogix/prd.7
15  8   0        1500003  1500000           PO-B  /dblogix/prd.8
16  9   0        1000053  697460            PO-B  /dblogix/crm.1

Continue restore? (y/n)y
Do you want to back up the logs? (y/n)y
File created: /ontapeDir/logicalLogs/isis_0_Log0000000007
File created: /ontapeDir/logicalLogs/isis_0_Log0000000008
Log salvage is complete, continuing restore of archive.
Restore a level 1 archive (y/n) n

Nono Passo:

Configure o servidor HDR secundario para inicializar como secundario ligando ao servidor primario

informix@isis:~/etc> onmode –d secondary prdsoc

Décimo Passo:

Verifique se agora você tem um HDR pariado

vishnu server

informix@vishnu:~> onstat -g dri

IBM Informix Dynamic Server Version 11.50.FC8GE -- On-Line (Prim) -- Up 03:04:24 -- 2857436 Kbytes

Data Replication at 0xd4caf028:
  Type           State        Paired server        Last DR CKPT (id/pg)    Supports Proxy Writes
  primary        on          tstsoc                       -1 / -1         NA

  DRINTERVAL   30
  DRTIMEOUT    30
  DRAUTO       0
  DRLOSTFOUND  /usr/informix/etc/dr.lostfound
  DRIDXAUTO    0
  ENCRYPT_HDR  0
  Backlog      0

informix@vishnu:~>

isis server

informix@isis:~> onstat -g dri

IBM Informix Dynamic Server Version 11.50.FC8GE -- Fast Recovery (Sec) -- Up 01:03:41 -- 2889780 Kbytes

Data Replication at 0xf320f028:
  Type           State        Paired server        Last DR CKPT (id/pg)    Supports Proxy Writes
  HDR Secondary  on          prdsoc                       -1 / -1         N

  DRINTERVAL   30
  DRTIMEOUT    30
  DRAUTO       0
  DRLOSTFOUND  /usr/informix/etc/dr.lostfound
  DRIDXAUTO    0
  ENCRYPT_HDR  0
  Backlog      0

informix@isis:~>

terça-feira, 17 de abril de 2012

A Fábrica do Futuro

A fábrica do futuro caracteriza-se por outros aspectos, além de uma instalação repleta de robôs e um elevado grau de automação, e está devidamente organizada em torno da tecnologia, do computador, que integra, por softwares especialmente desenvolvidos, praticamente todas as atividades. Nela, há o uso generalizado de ferramentas como CAD, MRP II, ERP, EDI, e acima de tudo, destaca-se a presença do trabalhador do conhecimento ( o knowledge worker,  o colaborador que usa a cabeça, o saber, mais do que as mãos). Podemos dizer que a fábrica do futuro apresenta as seguintes características:

  • Organização da produção: focada na alta produtividade. As atividades que não agregam valor são eliminadas. A filosofia de fazer certo desde a primeira vez é levada a extremos. Os refugos e retrabalhos não são admitidos. Os métodos de trabalho têm mecanismos para a prevenção de problemas. Os níveis de estoques são baixíssimos, poís o just-in-time esta em toda parte, e os componentes são entregues diretamente nas linhas de fabricação e/ou montagem. As fabricas são extremamente limpas e organizadas, em decorrência da aplicação sistemática do housekeeping. Os colaboradores são treinados em várias funções, desde a operação, preparação e manutenção até projetos de novos produtos e/ou processos produtivos, são todos controlados por computadores por meio de software integrados.
    Hoje já existem muitas fábricas do futuro em plena operação, a exemplo dos sistemas denominados produção enxuta, que surgiram no Japão e estão se espalhando por todo o mundo.
    A autoridade do colaborador, no que se refere à qualidade do produto, é praticamente ilimitada. Ele pode, a qualquer instante, parar a linha de produção, uma vez constatada uma não-conformidade já ocorrida ou latente. O espirito de grupo e de compromisso mútuo está presente. Todos os outros colaboradores procuram ajudar na solução do problema para que a linha volte à normalidade o mais rápido possível. Metodologias de identificação e solução de problemas são amplamente difundidas e incorporadas à cultura de todos os colaboradores. A gestão dos processos é feita pela utilização de indicadores de desempenho amplamente discutidos e aceitos por todos os colaboradores que estiverem intimamente ligados aos objetivos estratégicos e táticos da empresa;
  • Projeto dos produtos e dos processos: os projetos dos produtos  são desenvolvidos juntamente com os processos onde serão fabricados. A engenharia simultânea é aplicada em larga escala, passando a ser lugar-comum em todas as empresas. A atenção aos objetivos dos clientes guia o projeto, e a utilização de técnicas como o desdobramento da função qualidade (QFD) e  a análise de falhas (FMEA) assegura maior qualidade e confiabilidade aos produtos. Os produtos têm um menor número de componentes, o que diminui os riscos de falhas e os custos, sem que se perca a flexibilidade, pois os produtos são modulados.
  • Layout: é o elemento determinante da fábrica do futuro. As fábricas grandes até então tidas como padrão são divididas em várias pequenas unidades dentro da fábrica original, devidamente focalizadas, organizadas em células de produção, com elevado grau de automação. Os novos projetos contemplam áreas reduzidas para estoques de matérias-primas e produtos acabados, e não há previsão de áreas para retrabalho. Até mesmo as áreas  reservadas para os produtos em processos são reduzidas, pois as linhas são balanceadas de forma a permitir um fluxo contínuo e sem acúmulo em determinados pontos de processo. Esse processo de mudança permite que possa se dobrar a produção utilizando-se a metade da área até então usada.
  • Comunicação visual: as informações sobre produção, produtividade, objetivos atingidos e a atingir, porcentagem de refugos, etc., estão dispostas em quadros espalhados por todas as instalações, para serem lidos, analisados e criticados por todos os colaboradores. A era dos gerentes que guardam informações para deter o poder esta chegando ao fim.  Na fábrica do futuro as informações são disponibilizadas em tempo real, como a utilização de painéis eletrônicos conectados a vários terminais de entrada de dados. A utilização de cores é explorada ao máximo, com cartões kanban, contêineres, bancadas, etc., coloridos de forma a transmitir uma ou mais informações sobre o andamento dos processos.
  • posto de trabalho:  o posto de trabalho é projetado tendo em vista  os conceitos de ergonomia, procurando o conforto, bem-estar e segurança dos colaboradores. Além disso, a fábrica do futuro é ecologicamente correta. isto é, não é poluidora. São certificadas nos termos da ISO 14000 ou normas correspondentes. A preocupação em trabalhar com materiais recicláveis está presente em todas elas.

Fonte: Martins, P. G.; Laugeni, F. P. (2006). Administração da Produção. São Paulo. Saraiva.

Soluções de disponibilidade em IDS

HDR

  • Implementado pela primeira vez com a versão 6 do Informix; ps
  • Fornece Hot Backup secundário;
  • Pode ser usado para compensar o processamento de leitura;
  • Fácil configuração;
    • Faça um backup dos dados primários e restaure;
  • Trabalha com atualização automatica dos logs no servidor secundario
    • Servidor Secundario esta em modo de recuperação;
  • Suporta commits sincronizada;

 

Soluções avançadas de Alta Disponibilidade em Informix

  • Implementado com a versão 7.22 do Informix;
  • Uso
    • Particionamento de carga de trabalho;
    • Capacidade de substituição;
  • Suporta atualizações em qualquer lugar
    • Latencia muito baixa;
    • Sincronização locais com dados globais;
  • Integrado
    • Compatível com todas as soluções de disponibilidade de outros Informix;
    • Segurança das comunicações de dados;

er

Algumas características ER

  • Templates
    • Permite um grande conjunto de tabelas para ser implementado ao longo de um grande número de nós com apenas um par de comandos;
  • Check/Sync
    • Permite  verificação/reparo/sincronização online de um ambiente;
  • Suporta mudanças de esquema;
  • Configurações de replicações
    • Permite a administração de um grande número de replicações com um único comando;

Outras características ER

  • Resolução de conflitos
    • Usado para determinar se a versão atual ou apenas recebeu versão da linha ‘ganhador’;
    • Ignorar – Linha deve ser aplicada como é;
    • Timestamp – Atualizações mais recentes vence;
    • Store Procedure;
  • Direcionamento
    • Root, non-root e leaf nodes;
  • Integração com HDR
  • Permite um nó ER para ser um nó HDR

Remote Standalone Secondary (RSS)

  • Próximo passo para a evolução do HDR – nós RSSrss
    • Novo tipo de secundario – nós RSS
    • Pode ter 0 para N nós RSS
    • Pode coexistir com HDR Secundario
  • Uso:
    • Relatório
    • Aplicações WEB
    • Backup adicional no caso do primeiro falhar
  • Semelhança com nó HDR secundario:
    • Recebe logs do primario
    • Tem seu proprio conjunto de disco para gerir
    • RSS tem um impacto minimo no desempenho do primario
  • Diferenças  com nó HDR secundario
    • Só pode ser promovido a HDR secundario, nunca como primario
    • Modo SYNC não suportado

Compartilhamento de disco secundario (SDS – Shared Disk Secondary)

  • Proximo passo evolutivo
    • Nós SDS compartilha discos com o primario
    • Pode ter 0 para N nós SDShdr
  • Uso
    • Ajuste online da capacidade  como mudanças na demana
    • Não duplicar o espaço em disco
  • Caracteristica
    • Não requer nenhum hardware especifico
    • Simples para configurar
    • Pode coexistir com ER
    • Pode coexistir com nós HDR e RSS
  • Semelhanças com nó HDR secundário:
    • O primario pode ser trocado por qualquer nó SDS

Uso do disco compartilhado

  • Maior disponibilidade
  • Misturando atividades de relatorios e atualizações
    • Processamento de relatorios frequentes afeta o sistema de produção OLTP
  • Tendo nós DSS e OLTP trabalhando no mesmo dados
    • O primario pode ser configurado como um sistema OLTP enquanto uma  ou mais nós SDS são configurados como DSS/PDQ
  • Capacidade dinamica
    • O nó SDS é rapidamente instanciado, é facil de adicionar ou aumentar a capacidade como a mudança na demanda de trabalhos

Atualizando o secundário

O que é isto

  • Suporte adicionado no IDS 11.50
  • Suporta uma operação DML (INSERT, UPDATE e DELETE) no nó secundario
  • Usam concorrência otimizada para evitar a atualização de uma copia obsoleta da linha
  • Suporta commit de leitura em nós secundarios
  • Trabalha com os tipos de dados básicos, UDTs (aqueles que armazenam os dados no servidor) registros SMART BLOBs, e partições BLOBs.
  • Suporta tabelas temporarias – explícitos e implícitos.
  • Trabalha com ER.

Otimizando concorrencias  e escritas no secundario

  • Adicionado IDS 11.50
  • Adicionado suporte para versões de linha
    • CREATE TABLE……. WITH VERCOLS
      ALTER TABLE…… [ADD] / [DROP] VERCOLS
      • Cria uma coluna sombra que consiste em uma soma de verificação de inserção (ifx_insert_checksum) e atualiza a versão da coluna (ifx_row_version).
  • Se for determinado que a imagem anterior (before image) no secundário é diferente da imagem atual do primário, em seguida a gravação da operação não é permitida e uma EVERCONFLICT erro (-7350) é retornado.
  • Se a tabela não utiliza VERCOLS, então a before image da linha é usado para verificar se a atualização não esta tentando gravar numa linha obsoleta.

Gerenciamento de conexões

  • Mantem o conhecimento de todos nós dentro do clusterpolice
  • Registro de adição e remoção dos nós
  • Monitora os tipos de nós
  • Monitora carga de trabalho dos nós
  • Rotas aplicações  para nós do destino
  • Trabalha sobre o conceito de “Service Level Agreement (SLA)
    • Conecta-se ao primario
    • Conecta-se o melhor possivel com o secundario
  • Pode existir multiplas conexões de modo que não há nenhum ponto de falha

 

Arbitro

  • O proposito é detectar rapidamente a falha do server primario
  • Parte do gerenciador de conexões
  • Obtém a confirmação através de caminhos alternativos antes de realizar um failover
  • Executa um failover usando uma API de interface administrativa
  • Há failover para o arbitro assim como há failover para o gerenciamento de conexão.

Soluções básicas de restauração de logs continuos

lapis

log

Opções  de restauração dos continuos logs com ontape/onbar

Com as opções de restauração dos continus logs, o servidor irá suspender a restauração de log:

ontape –l –C
roll forward deve começar com o numero de log 7
a restauração de log será suspenso no numero de log 7

a restauração de log pode ser reiniciada novamente com o comando ontape

ontape –l –C
roll forward deve começar com o numero de log 8
a restauração de log será suspenso no numero de log 10

Modo de recuperação é terminado pelo comando ontape –l

Alterações dos dados externos

  • Observação do log exposto
  • Fornece uma base para o IDS nao replicado
  • Trabalha totalmente em protocolo SQL
    (UDRs e pseudo smart blob)

Algumas API basicas

  • CDC_OPENSESS()
    Estabelece um ambiente de CDC e retorna um ‘sessionID’, que é realmente um fd para um pseudo smartblob
  • CDC_SET_FULLROWLOGGING()
    Faz com que a linha inteira seja registrada. Um requisito para CDC
  • CDC_STARTCAPTURE()
    Define quais as tabelas devem ser capturado
  • CDC_ACTIVATESESS()
    Dados de alteração para ser devolvido ao cliente através do pseudo smartblob

Recuperação de dados CDC

  • Os dados são recuperados através de uma interface smartblob
  • Isso permite que aplicativos do CDC para ser escrito em qualquer ferramenta de cliente que suporta grandes objetos.
  • Implementado dentro de um banco de dados ‘CDC’ composto por UDRs e pseudo objetos, assim como o sysmater.
  • Para ler os dados do CDC e pseudos LOB
    • mi_lo_read() – UDRs
    • ifx_lo_read() – ODBC/C(++)
    • ifxLoRead() - Java

sexta-feira, 13 de abril de 2012

Manufatura Virtual: Conceitos e Desafios

Saudações a todos, hoje vou estar postando um artigo muito interessante sobre a Manufatura Virtual, o artigo é bem interessante. Boa Leitura.

Créditos:gestao

Arthur José Vieira Porto
Mariella Consoni Florenzano Souza
Departamento de Engenharia Mecânica – SEM,
Escola de Engenharia de São Carlos – USP,
Av. Trabalhador Sancarlense, 400,
CEP 13566-590, São Carlos, SP,
e-mails: ajvporto@sc.usp.br e mariella@sc.usp.br

Carlos Alberto Ravelli
Caterpillar do Brasil Ltda.,
Rod. Luiz de Queiroz, km 157, Unileste,
CEP 13420-900, Piracicaba, SP,
e-mail: ravelli_carlos_a@cat.com

Antonio Batocchio
Faculdade de Engenharia Mecânica,
Unicamp, R. Mendeleiev, s/n,
Cidade Universitária “Zeferino Vaz”,
CEP 13083-970, Campinas, SP,
e-mail: batocchi@fem.unicamp.br

Resumo


A Manufatura Virtual é uma nova proposta que está sendo utilizada por algumas empresas para revolucionar seus processos, visando introduzir no mercado produtos superiores, mais rapidamente e a um menor  custo. A estratégia é criar  um abiente integrado, composto de diversos sistemas e ferramentas de software, com a finalidade de gerar um novo método de desenvolvimento de produto. Este artigo tem por objetivo apresentar o conceito de Mantufatura Virtual, bem como os paradigmas envolvidos em sua definição, as aplicações potenciais e os beneficios esperados. Apresenta também os sistemas de suporte às atividades de Manufatura Virtual e uma análise dos desafios técnicos e socioculturais para sua implementação.

Palavras chave: Manufatura Virtual, desenvolvimento de produto, simulação.

1. Introdução

O mercado atualmente é caracterizado por acirrada competição internacional, por produtos cada vez mais complexos e por grande dinâmica inovadora. Juntamente com os ciclos de inovação cada vez mais reduzidos, os ciclos de vida dos produtos e o tempo para lança-los no mercado são cada vez menores.

Considerando esse contexto, juntamente com o grande avanço tecnólogio, cada vez mais as empresas estão buscando vantagem competitiva e introduzir novos produtos no mercado mais rapidamente e a um custo menor, como utilizado, por exemplo, o ambiente de Manufatura Virtual. A idéia é que esse novo ambiente porposto aborde todo o processo de desenvolvimento, simulação e fabricação do produto, possibilitando a execução dessas atividades no computador, ou seja, virtualmente, antes de realizá-las no mundo real, independentemente do grau de complexidade da forma e da estrutura de um produto.

A utilização dessas técnicas avançadas, mais especificamente da manufatura Virtual, esta sendo observada em algumas empresas, principalmente dos setores automotivo e aeroespacial, e o seu conceito tem-se desenvolvido em escopo, ganhado maior importância e aceitação internacional. Exemplos de empresas vêm utilizando a Manufatura Virtual são: a Boing, que desenvolveu o modelo 777 totalmente digital antes de fazê-lo fisicamente; a DaimlerChrysler, que produziu três veículo recentemente usando a Manufatura Virtual; a John Deere, que também tem usado esse novo ambiente no desenvolvimento de seus produtos (WAVE, 2002).

Um maior interesse, por parte do mercado mundial, por essa nova proposta pode ser verificado, principalmente, devido a dois fatores: às melhorias no desempenho das tecnologias hardware e software requeridas, cujos respectivos custos estão se tornando mais acessiveis, e aos avanços das tecnologias de modelagem e simulação de sistemas de alta complexidade topológica e funcional. E, quanto ao Brasil, pode-se afirmar que os conceitos da Manufatura Virtual se encontram em estágios inicial de utilização ou testes. Algumas empresas já estão reconhecendo o seu potencial, porém ainda não estão utilizando o ambiente integrado e completo proposto; o que se tem, na maioria dos caos, é a utilização de tecnologias e ferramentas individuais, específicas para cada área, e de forma isolada.

Portanto, o artigo tem por objetivo principal aprasentar e divulgar os conceitos de Manufatura Virtual, visando desperar a iniciativa de pesquisas, principalmente no que se refere aos desafios para a sua implementação. Mais especificamente, o artigo apresenta a definição de Manufatura Virtual dentro dos paradgmas “projeto, produção e controle”, abordando o relacionamento entre eles. Discute também como essa nova proposta pode ser aplicada e os benefícios esperados, como, por exemplo, a redução do tempo de ciclo e do custo de desenvolvimento de produto. Além disso, o artigo aborda os sistemas de suporte às atividades dentro do contexto da Manufatura Virtual, especialmente nas áreas de planejamento do processo, gerenciamento de recursos, programação de controle numérico (CN) e validações (simulações e realidade virtual). Outro objetivo não menos importante é apresentar uma analise dos principais desafios técnicos e socioculturais existentes para a implementação efetiva da Manufatura Virtual.

2. Conceituação e paradigmas da Manufatura Virtual

De acordo com Banerjee & Zetu (2001), o termo Manufatura Virtual passou a ser utilizado em meado dos anos 90, em parte como resultado da iniciativa do Departamento de Desefa dos EUA, pois a evolução do ambiente de desefa eas estratégias de aquisição propiciaram o desenvolvimento da capacidade de confirmar a manufaturabilidade e a possibilidade de novos sistemas de armas antes de comprometer recursos de produção. Até metade dessa década, os primeiros trabalhos nesse campo foram realizados por algumas organizações, principalmente as indústrias aeroespacial e automobilística, além de ser abordado como tema em alguns grupos de pesquisa acadêmica.

Para os autores, a Manufatura Virtual pode ser usada em uma grande variedade de contextos de sistemas de manufatura, e pode ser definida como a modelagem desses sistemas e de componentes como o uso efetivo de computadores, de dispositivos audiovisuais e sensores para simular ou projetar alternativas para um ambiente de manufatura visando, principalmente, prever problemas potenciais e ineficiência na funcionalidade e manufaturabilidade do produto antes que a manufatura ocorra.

A Manufatura Virtual também pode ser definida, conforme Lawrence Associates Inc. (1994), como “um ambiente integrado e sintético da manufatura exercido para melhorar todos os níveis de controle e decisão”, em que:

Ambiente: é o suporte para a construção e uso da simulação da manufatura distribuída pela sinergia provinda de uma coleção de ferramentas de análise, de simulação de implementação, de controle, modelos (produto, processo, recurso), equipamentos, metodologias e principio organizacionais.

Sintético: mistura do real com objetos, atividades e processo simulados.

Exercido: executar a simulação da manufatura utilizando o ambiente.

Melhorar: aumentar o valor, a precisão e a validade.

Níveis: do conceito do produto à sua disponibilização, do chão de fabrica à comitiva executiva, do equipamento de fábrica ao empreendimento, além da transformação de material à transformação de conhecimento.

Controle: predizer os efeitos reais.

Decisão: entender o impacto da mudança (visualizar, organizar, identificar alternativas).

Desta forma, um projeto de Manufatura Virtual propõe: prover uma estratégia para a integração de varios processos de manufatura  que produzem o Método Planejado e fornecer capacidade para “Manufaturar no Computador”, por intermédio de um ambiente tão poderoso de modelagem e simulação que a fabricação e a montagem de um produto, incluindo os processos de manufatura associados, podem ser simuladas em um computador. Essa capacidade consdiera todasd as variáveis do ambiente de produção, dos processos de chão de fábrica às transações empresariais, ou seja, consiera as interações dos processos de produção, planejamento de processo e da montagem, programação, logistica das linhas da empresa e os processos associados, como contabilidade, compras e gerenciamento.

O escopo do projeto da Manufatura Virtual engloba três diferentes paradigmas, dentro dos quais ela é definida. São eles:

  • Manufatura Virtual orientada para o projeto: fornece informações sobre a manufatura ao processo de desenvolvimento, permitindo a simulação de diversas alternativas de manufatura e a criação de protótipos “soft” pela manufatura no computador. Consiste no uso de simulações baseadas na manufatura para otimizar o projeto do produto e dos processos em uma meta específica da manufatura, como, por exemplo, DFA (Desing for Assembly), qualidade ou flexibilidade.
  • Manufatura Virtual orientada para a produção: fornece capacidade de simulação aos modelos dos processos de manufatura com o proposito de permitir avaliações mais rápidas e econômicas de diversas alternativas de processamento.  Consiste na conversão do processo de desenvolvimento nos planos de produção, otimizando os processos de manufatura.
  • Manufatura Virtual orientada para o controle: consiste na simulação dos modelos de controle e processos reais, permitindo a otimização durante o ciclo de produção existente.

A figura 1 apresenta o ambiente da Manufatura Virtual proposto e a inter-relação entre seus paradigmas.

Em resumo, o paradigma orientado para o projeto fornece um ambiente para que os projetistas projetem os produtos e avaliem sua manufaturabilidade e viabilidade. Os resultados deste paradigma incluem basicamente: informações sobre a manufatura, modelo do produto e protótipos “softs”. Visando manter a competência da manufatura sem construir produtos reais, o paradigma orientado para a produção fornece ambiente para a geração de planos de processo e de produção, para o planejamento de recursos necessários e para a avaliação desses planos. Fornecendo capacidade para simular os sistemas produtivos existentes, o paradigma orientado para o controle oferece ambiente para a avaliação de projetos de produtos novos ou revisados em relação às atividades de chão de fábrica.

 

figura1

figura 1 – Ambiente da Manufatura Virtual. Fonte: Porto & Palma (2000).

3. Aplicação potencial da Manufatura Virtual e seus beneficios

Existem diversas áreas nas quais a Manufatura Virtual pode ser aplicada. De acordo com Lee et al. (2001), as suas aplicações incluem principalmente a análise da manufaturabilidade de uma pela ou de um produto; a avaliação e validação as possibilidades dos planos de processos e de produção; e a otimização dos processos de produção e do desempenho do sistema de manufatura. Desde que a Manufatura Virtual utilize modelos baseados nas intalações reais da manufatura e dos processos, ela fornecerá não apneas informações reais sobre o produto e seus processos de manufatura como também permitirá a avaliação e validação destes. Além disso, ela pode ser usada para prever os riscos do negócio, fornecedno suporte à administração na tomada de decisões e no gerenciamento da estratégia de uma empresa.

Dentre suas aplicações destacam-se:

  • Avaliação da viabilidade de um projeto do produto, validação de um plano de produção e otimização do projeto do produto e dos processos, resultando na redução do custo no ciclo de vida do produto.
  • Teste e validação da precisão dos projetos do produto e dos processos, envolvendo atividades como, por exemplo, analisar a possibilidade do projeto do produto, realizar análise dinâmica das caratecristicas, verificar a trajetória da ferramenta durante o processo de usanagem, validar programas de controle numérico, checar problemas de colisão na usinagem e na montagem, etc.
  • Realização de treinamento por intermédio de um ambiente virtual e distribuido para os operadores, técnicos e gerência no uso das instalações de manufatura. Os custos de treinametno e produção podem, assim, ser reduzidos.

Diversos beneficios derivados da utilização da Manufatura Virtual podem ser citados. Segundo Lee et al.(2001), o principal beneficio esperado é a redução do tempo de ciclo e do custo de desenvolvimento de produto. Quanto novos sistemas ou produtos são desenvolvidos, os custos do ciclo de vida são determinados por diversas decisões tomadas nas primeiras etapas do ciclo de desenvolvimetno (fase de definição do conceito). Corrigir erros encontrados nas etapas finais do processo de desenvolvimento, causados por decisões tomadas nas etapas iniciais, envolve mudanças no projeto que consomem tempo e custo. Mesmo que as mudanças necessárias sejam pequenas, o efeito de rede pode ser substancial (Committee, 1999).

Uma forma de reduzir o tempo e o custo de desenvolvimetno é desenvolver ambientes de Manufatura Virtual ue permitam aos projetistas determinar rápida e percisamente como os projetos propostos afetarão o desempenho dos novos sistemas e produtos e como as mudanças afetarão as perspectivas de sucesso da missão. Este ambiente permitirá o desenvolvimento e a prototipagem de mais modelos baseados em computador nas etapas iniciais do processo de desenvolvimento do produto, reduzindo a necessidade de construir um grande número de protótipos físiciso nas etapas posteriores do processo de desenvolvimento de produto, como, por exemplo, a Embraer que, utilizando prototipos virtuais no desenvolvimento do ERJ 170, passa a completar seu processo de desenvolvimento em 38 meses, enquanto foram necessários 60 meses para desenvolver o modelo ERJ 145 (Embraer, 2002).

Além disso, a Manufatura Virtual complementa o processo de desenvolvimento integrado do produto e do processo, pois proporciona uma maneira de as informações da manufatura serem passadas às fases iniciais do desenvolvimetno (Lin et al., 1995). Em outras palavras, ela proporciona a introdução de um nível muito mais preciso e verificavel de as informações da manufatura estarem disponiveis nas fases iniciais do processo de desenvolvimetno, permitindo a expansão do “espaço de soluções” disponiveis na fase de projeto, pois tornará possível a verificação rapida de projetos. O objetivo é explandir o espaço de decisões, capacitando o projetista para a avaliação mais efetiva dos custos de diversos projetos via simulação de diversas alternativas de manufatura e crianção de protótipos “soft” pela manufatura no computador. Segundo estimativas da montadora Ford, que ja vem aplicando técnicas de manufatura Virtual, os resultados esperados compreendem redução de 20% nas ocorrencias de mudanças na manufatura durante o lançamento de novos produtos e redução nos custos de mais de U$200 milhões anualmente (TMR, 1998).

A Manufatura Virtual pode proporcionar também a inclusão do cliente e de seus requisitos no processo de desenvolvimento e gerar, assim, melhor resposta às perguntas “e se” dos clientes sobre a mudança nos prazos de entrega e orçamentos. Alem disso, facilita a integração funcional dentro das empresas, promovendo o compartilhamento de informações e melhorando o relacionamento do trabalho interfuncinal dentro do processo de desenvolvimento (Lawrence Associates Inc. 1994).

Outra contribuição importante é na formação da Empresa Virtual. Segundo Lin et al. (1995), a Empresa Virtual é uma rede multidisciplinar de pequenas empresas formada para alcançar oportunidades de desenvolver e produzir um produto especifico. Os membros dessa empresa, para satisfazer uma necessidade de mercado, podem compartilhar suas competencias, ferramentas de software, dados e informações do produto com outros membros em um ambiente de Manufatura Virtual.

Com uso desse ambiente virtual e colaborativo, os clientes podem participar do processo de desenvolvimento de produto e os engenheiros de projeto podem responder mais rapidamente às necessidades dos clientes e lhes fornecer uma solução otima, reduzindo, dessa forma, o tempo de ciclo e os custos de desenvolvimento. E, consequentemente, a vantagem competitiva de uma empresa no mercado pode ser melhorada.

Com ilustração, pode-se citar o caso da Boeing, que também utilizou a Manufatura Virtual para o desenvolvimento do modelo 737. Nesse processo, a empresa desenvolveu o protótipo virtual, incorporando as leis fisicas e da ciência dos materiais, e avaliou esse modelo por meio da simulação no túnel do vento virtual. Como resultado, os engenheiros puderam testar uma quantidade muito maior de protótipos, a um custo menor e com maior velocidade. Além disso, na medida em que a empresa moveu suas atividades de desenvolvimento do mundo real para o virtual, ela passou a envolver os clientes no desenvolvimento da aeronave , compartilhando informações por intermédio da simulação via computador (Balceiro & Cavalcanti, 1999).

Porém, para que os desenvolvimento desse ambiente seja possivel, algumas caracteristicas e funcionalidades são requeridas dos sistemas a serem utilizados. A seguir, são apresentados os principais sistemas de suporte às atividades, dentro do contexto da Manufatura Virtual.

4. Sistemas de suporte às principais atividades na Manufatura Virtual

O ambiente de Manufatura Virtual compreende: a utilização de sistemas para elaboração de planos de processos macro e detalhado, tanto de processos de fabricação como de montagem, todas as atividades de identificação de recursos de maquinas, ferrametnas e dispositivos, a programação de controle numerico de máquinas de usinagem, robôs, máquinas de medição, simulação e realidade virtual.

Busca-se, segundo Porto & Palma(2000), a integração de dados e sistemas e a padronização de ferramentas e programas. Não há um único produto que domine o mercado da família de softwares que compõem este novo ambiente, e como os pacotes variam consieravelmente em muitos aspectos – custo, funcionalidade, flexibilidade, facilidade de uso e plataforma, a seleção das ferramentas deverá ser direcionada para aquelas que permitam:

  • melhorar a tecnologia para obter recursos;
  • associatividade gerenciavel;
  • reduzir a recriação de geometria, em que os projetos de produtos, máquinas, ferramentas e outas entidades são baseados em modelagem sólida;
  • eliminar desenho em papel;
  • trabalho em paralelo, ou seja, simultâneo;
  • integrar ferramentas de software de ERP (Enterprise Resouces Planning);
  • acesso de fornecedores usando o Portal Web;
  • usar modelos em fase de desenvolvimento (trabalho em processo);
  • fluxo de trabalho integrado com sistemas de gerenciamento de projeto.

Pode-se afirmar que existem soluções isoladas ou parciais para cada uma das tarefas relacionadas ou parciais para cada uma das tarefas relacionadas ao ambiente de Manufatura Virtual. A seguir, são apresentadas caracteristicas funcionais básicas desejadas desses sistemas para cada  um dos principais grupos de tarefas listados na figura 2.

fig2

Figura 2 – Principais atividades a serem cobertas pelos sistemas no ambiente de Manufatura Virtual.

4.1 – Planejamento do processo

O sistema de Planejamento do Processo é a aplicação central que permite aos engenheiros de manufatura elaborarem o processo completo de manufatura e idenrificarem os elementos que definem os produtos. Um modelo genérico de dados do processo de manufatura é um componente essencial de tal aplicação. O modelo de dados deve dar suporte ao planejamento macro e detalhado dos processos. Um ambiente integrado de manufatura engloba dados do processo que descrevem como os produtos são fabricados usando os recursos disponiveis. Isto impõe que o modelo de dados proposto habilite a colaboração de dados do produto, dados do processo e dados dos recursos. A figura 3  mostra as atividades basicas envolvidas no desenvolvimento do Planejamento do Processo.

O sistema para o desenvolvimento do Plano de Processo, integrado a outras aplicações específicas, deve permitir ao usuário elaborar as instruções detalhadas de trabalho para um processo de operação específico, como por exemplo, tratamento térmico, solda por robô e usinagem.

AS principais funcionalidades que os softwares devem proporcionar são:

  • Definir necessidades geométricas – habilidade de definir requisitos baseados no projeto do produto (arquivo CAD) – e necessidades não geométricas – habilidade de definir o consumo do material que não é detalhado no projeto do produto.
  • Criar listagem de material de manufatura (MBOM) e informações associadas, como listagem das estações de consumo e datas de efetivação.

fig3

Figura 3 – Atividades básicas do Planejamento do Processo, Fonte: Halevi & Weill (1995).

  • Planejar o ponto de uso (como componentes comprados devem ser entregues ou armazenados).
  • Definir roteiro primário (sequencia primária de operações a serem realizadas).
  • Definir máquinas e estações para fabricação/montagem e suas configurações (setups).
  • Definir listagem de material processado (componentes consumidos em uma operação).
  • Determinar submontagens para melhorar o processo de manufatura.
  • Definir sequencia relativa de operações, tempo e ciclo de cada operação e instruções textuais e gráficas.
  • Emitir o Método Planejado.
  • Elaborar instruções detalhadas de primeiras operações (corte e dobra de chapas), soldagem, pintura, tratamento térmico.
  • Aplicar tempos-padrão.

Um exemplo de aplicação é mostrado na Figura 4, em que as principais funcionalidades anteriormente apresentadas, incluindo imagens em diferentes formatos, descrição detalhada da operação a ser executada, dados do local de execução da operação, tempos-padrão e de setup, pode ser observadas. Diversas ferramentas para o planejamento do processo podem ser encontadas no mercado, como, por exemplo, o eM-Planner da Tenomatix e o E-Factory Process Planner da UGS/EDS.

4.2 Gerenciamento de Recursos

Neste contexto, recursos incluem máquinas de controle numérico, máquinas de manuseio manual, espaço no chão de fabrica, células de fabricação e montagem, equipamentos especiais, dispositivos de suporte e requisitos de mão-de-obra (especialização do trabalho e carga de trabalho).

As principais funcionalidades requeridas desses sistemas são:

  • Avaliar recursos de chão de fábrica para determinar se são suficientes para atender às necessidades do Método Planejado.
  • Elaborar o layout da fábrica.
  • Gerenciar ferramentas e calibradores.
  • Selecionar ferramentas e calibradores similares e existentes: verificar a existência de ferramentas e calibradores; pesquisar a disponibilidade nos almoxarifados; usar referencias de modelo geométrico e requisitos de manufatura.

fig4

Figura 4 – Exemplo de um sistema de Planejamento do Processo. Fonte: HMS (2000).

  • Projetar ferramentas e calibradores.
  • Solicitar serviços de projetos de ferramentas e calibradores.
  • Escrever ordens de serviços para execução de atividade no chão de fabrica não especificadas no Método Planejado.
  • Definir localização de ferramentas e calibradores no chão de fábrica.
  • Realizar a comunicação com o sistema de controle de chão de fábrica (MES – Manufacturing Execution System).

Um exemplo de software nessa área é o E-Factory Resource Manager da UGS/EDS, que povê um mecanismo integrado para classificar e armazenar informações de recursos de manufatura, incluindo ferramental, dispositivos, calibradores, máquinas e equipamentos.

4.3 Programação de controle numérico

De maneira geral, os programas de controle numérico devem ser criados e simulados em um ambiente virtual 3D, usando modelos visuais para eliminar colisões da ferramenta ou ponta de prova, assim como problemas de programação que podem estar presentes, antes de executá-los fisicamente no equipamento. As funcionalidades de programação de controle numérico relatadas neste item englobam aplicativos nas seguintes áreas:

  • Programação de centros de usinagem.
  • Programação de robôs (solda, pintura, montagem, corte).
  • Programação de máquinas de medição por coordenadas (MMC).

Como operações de manufatura demandam maior eficiência, os softwares CAM empregados para usinar ou medir devem apresentar ferramentas mais precisas para o corte ou medição de peças complexas. As novas tendências em software CAM são:

  • Associatividade completa entre a geometria do modelo e os caminhos das ferramentas (programação CN) e ponta de prova.
  • Usinagem ou medição baseada no conhecimento (captura técnicas de usinagem de um operador experiente ou de um programador de controle numérico).
  • Conhecimento de feature, que permite ao sistema automaticamente reconhecer “features” da peça e configurar padrões de operação.
  • Usinagem de alta velocidade, com realização de cortes pequenos e leves em ez de grandes e pesados.
  • Capacidade de usinagem e medição de modelos solidos.

Essas novas tendencias requerem o uso de modelos sólidos ou superfícies de precisão. O uso dessas novas tendências em CAM, em conjunto com a simulação de processos, pode reduzir drasticamente o tempo de programação e a correção de erros.

4.4 Validações

Validações de processos e sistemas de manufatura, de programação CN, de ergonomia e de eventos discretos podem ser realizadas com a aplicação de softwares de simulação e realidade virtual.

4.4.1 Simulação

As empresas do setor automobilistico tem usado cada vez mais a simulação como uma proeminente ferramenta de suporte à decisão. A maioria faz uso da simulação de eventos discretos para modelar sistemas de manufatura e em questões relativas ao layout de fabrica, fluxo de processo, sistemas de manuseio de material, planejamento de capacidade, utilização de mão-de-obra, investimento em novos equipamentos, programação da produção e logística.

De acordo com Jain (1999), a simulação se tornará  a forma de fazer negócios no futuro, na qual todas as decisões serão avaliadas usando essa tecnologia  em todos os aspectos das operações. O uso da simulação não tem se limitado às aplicações tradicionais na manufatura e logistica e cada vez mais engloba processos de negocios, aplicações interativas de simulação de treinamento e vendas. No futuro, modelos de simulação se desenvolverão como o conceito de um sistema se desenvolve, crescerão como cresce o projeto em detalhes, suportarão a tomada de decisões durante o estágio de operação do sistema real. À medida que o sistema real é modificado, modelos de simulação correspondetes são atualizados.

Os sistemas de simulação para suporte às atividades de Manufatura Virtual podem ser distribuídos em quatro grandes grupos:

  • Simulação de sistemas de manufatura.
  • Simulação de processos de manufatura.
  • Simulação de sistemas mecânicos.
  • Simulação de elementos finitos.

Os softwares de simulação de sistemas de manufatura incluem:

  • Processo de fabricação e de montagem, os quais fornecem métodos sistemáticos para o projeto de fábrica (criação, análise e apresentação visual do modelo), habilitando a engenharia simultânea de toda a fábrica. Pode-se citar, como exemplos, o VisFactory da UGS/EDS e o DELMIA Process Enginer.
  • Análise de fluxo de material e layout de fábrica, integrando desenhos de fábrica e caminhos do fluxo de material com dados de produção e manuseio de material, possibilitando prever o desempenho do sistema e entender o impacto de possíveis mudanças. Exemplos de software nessa área são o eM-Plant da Tecnomatix, o FactoryFlow e o FactoryCAD da UGS/EDS e o Factor/AIM da Pristsker.
  • Eventos discretos, que permitem modelar questões complexas de manuseio de material e manufatura, provendo animações em escala real 3D enquanto o modelo está sendo executado. Como exemplo de softwares pode-se citar o AutoMod da Autosimulations, o Quest da Delmia, o Witness da Lanner Group Ltda. e o Arena da Rockwell.

A simulação de processos de manufatura e de sistemas mecânicos engloba:

  • Programação de controle numérico, que simula interativamente o processo de remoção de material e o caminho da ferra-menta e detecta automaticamente colisões de ferramentas, interferências entre peças e condições de corte inadequadas. Alguns softwares disponíveis nessa área são o Vericut da CGTech, o Virtual NC da Delmia e o NC Simul da Spring.
  • Programação de robôs, para o desenvolvimento, programação e otimização de aplicações em pintura, MMC, solda e células de manufatura, como, por exemplo, o UltraArc e o UltraPaint da Delmia, o CimStation Robotics e o CimStation Inspec-tion da Silma.

A simulação de elementos mecânicos utiliza principalmente o método de elementos finitos para verificar se as alterações nas condições de usinagem não resultarão em esforços que comprometerão a qualidade de forma e de acabamento da peça.

Uma limitação dos softwares de simulação da Manufatura Virtual é que, para a grande maioria dos casos, diferentes tipos de ferramentas de simulação – simulação de eventos discretos, simulação de fluxo de material, simulação de células de trabalho – operam independentemente umas das outras.

4.4.2 Realidade Virtual

A Realidade Virtual, por sua vez, também é uma tecnologia-chave no desenvolvimento do produto e no processo. A Realidade Virtual pode ser definida como “a habilidade em criar e interagir no espaço cibernético, isto é, um espaço que representa um ambiente muito similar ao ambiente em torno de nós” (Banerjee & Zetu, 2001).

De fato, a realidade virtual e a simulação podem ser utilizadas em diferentes áreas, incluindo a Manufatura Virtual, mas há diferenças entre elas. Ambas, simulação e realidade virtual, são ferramentas que podem ser usadas para análise e teste de materiais, treinamento de pessoas e projeto e implementação de novas idéias e conceitos (NASA, 2001).

Uma distinção importante entre elas está na forma de operação da tecnologia. A realidade virtual freqüentemente requer mais interação física da parte do usuário, enquanto a simulação é tipicamente mais passiva. A Realidade Virtual é um processo tátil, incorporando luvas, controle joysticks, telas em capacetes, óculos estéreo 3D e paredes e telas para projeção de vídeo. A simulação envolve software de visualização com gráficos de alta resolução, usando modelos CAD 3D que operam em estações gráficas de alto desempenho. Ambas podem ser usadas em conjunto por projetistas e engenheiros para criar praticamente qualquer tipo de mundo artificial. Nesses ambientes digitais, diversas situações do mundo real, variáveis e reações podem ser duplicadas.

A principal vantagem dessa tecnologia é o desenvolvimento e análise do projeto colaborativo, habilitando grupos de engenheiros a visualizar e manipular, em tempo real, um objeto virtual tão facilmente como seria com um objeto físico. Para dar suporte à criação de ambientes virtuais, diversas ferramentas de software estão disponíveis no mercado, como dVise, Supers-cape e World Toolkit.

A Realidade Virtual tem sido usada por empresas como a General Motors e a Caterpillar para a construção de protótipos digitais de veículos, em vez de protótipos físicos, reduzindo significativamente o tempo de desenvolvimento de produto. A BMW usa a Realidade Virtual para explorar a visualização de novos layouts de veículos com o objetivo de melhorar a comu-nicação e a simulação dos processos. A Rolls Royce Aeroengines and Associates usa essa tecnologia para verificar antecipadamente os procedimentos de manutenção, treinar os engenheiros de manutenção em novos procedimentos e visualizar ambientes complexos (Peng et al., 2000). A Embraer utiliza o Centro de Realidade Virtual no desenvolvimento de uma aeronave, o qual permite aos engenheiros visualizar, em três dimensões, por meio de modelos eletrônicos, toda a estrutura da aeronave em fase de projeto. A empresa usa o WorkWall da Fakespace Systems, que é uma solução de visualização ideal para apresentações em grupo e projeto colaborativo. Quando usado com um software de modelagem 3D como o CATIA da Dassault Systems, e visualizado usando o DMU Navigator da Dassault Systems e Division Reality da PTC, o WorkWall torna mais fácil para as equipes multidisciplinares avaliarem mock-ups digitais e protótipos virtuais nas etapas iniciais do ciclo de projeto. Para os clientes, fornece fácil entendimento do layout do modelo e das opções de configuração, facilitando decisões de compra (Fakespace, 2002). Com o Centro de Realidade Virtual e o CATIA, pode-se detectar, corrigir e eliminar falhas eventuais e montagens incorretas antes que qualquer peça ou conjunto seja encaminhado para a produção. A prototipagem virtual e a visualização reduzem significativamente o tempo de lançamento de uma nova aeronave no mercado e o retrabalho durante o projeto, juntamente com a expansão das linhas de produto e da capacidade de produção.

5. Principais desafios na implementação da Manufatura Virtual

Embora o desenvolvimento da Manufatura Virtual possa ser considerado uma evolução de diversas tecnologias e do ambiente de negócios, existem diversos desafios técnicos e socioculturais que dificultam sua implementação, como:

  • integração das ferramentas, sistemas e dados;
  • gerenciamento das informações;
  • gerenciamento da configuração;
  • velocidade operacional do sistema;
  • know-how em manufatura, modelagem e representação;
  • capacidade de aprendizado e aquisição de conhecimentos;
  • questões culturais, de gerenciamento, econômicas e de treinamento.

Um dos principais desafios técnicos para alcançar um ambiente ideal de Manufatura Virtual refere-se à necessidade de alcançar um elevado nível de integração das ferramentas, sistemas e dados presentes nesse ambiente, conforme apresentado na Seção 4.

Um processo de desenvolvimento de produto efetivo deve balancear diferentes fatores, como requisitos dos clientes, desempenho, custo, segurança, integração do sistema, manufaturabilidade, confiabilidade e manutenibilidade. Softwares relevantes para a Manufatura Virtual têm sido desenvolvidos como uma coleção de ferramentas individuais com pouca ou nenhuma ligação entre elas. A integração entre ferramentas de software é uma área de ativa pesquisa acadêmica, industrial e governamental, porém, soluções aplicáveis não estão totalmente disponíveis para uso operacional (Committee, 1999).

Os problemas de integração são causados por diversos fatores. Um deles diz respeito à incompatibilidade das ferramentas de software. A menos que a interoperabilidade tenha sido um objetivo específico do processo de desenvolvimento de software usado para criá-lo, para a maioria das empresas desenvolvedoras a interoperabilidade tem obtido pouca prioridade. Vendedores de softwares comerciais tendem a operar em segredo para proteger as informações, especialmente quando um novo produto está sendo desenvolvido. A incompatibilidade também ocorre, pois, na maioria das empresas, engenheiros e gerentes buscam no mercado a melhor solução para cada aplicação específica, ou, então, quando essas soluções não estão disponíveis comercialmente, são desenvolvidas in house pelo próprio usuário. Como resultado, as organizações não podem ter suas ferramentas trabalhando de forma integrada. O objetivo de melhorar o desempenho e a eficiência de produtos e processos individuais encoraja a proliferação de novas ferramentas e, conseqüentemente, resulta na falta de interoperabilidade entre elas.

Essa falta de interoperabilidade inibe o uso de ferramentas tradicionais em ambientes de Manufatura Virtual, os quais, por natureza, requerem alto grau de integração. Melhorar a interoperabilidade das ferramentas de software é uma atividade complexa, principalmente devido à geração de um custo, às incertezas sobre o retorno no investimento e às dinâmicas psicológica e social das organizações. Porém, a melhoria é essencial, pois a falta de interoperabilidade resulta em elevados custos para a empresa. Um estudo realizado recentemente por uma das principais montadoras do setor automotivo revelou que a falta de interoperabilidade tem custado para as empresas desse setor entre U$ 200 milhões e U$ 400 milhões por veículo desenvolvido. A falta de eficiência na troca de dados do produto com empresas da cadeia de fornecimento tem gerado custos de U$ 1 bilhão por ano para a indústria (NIST, 1999).

O mesmo problema de integração se aplica aos sistemas hardware. Sistemas fornecidos por diferentes vendedores às vezes são incompatíveis, e softwares escritos para sistemas hardware de um vendedor podem ser incompatíveis com sistemas de outros vendedores.

Padrões têm sido usados em muitos campos para prevenir ou corrigir problemas de interoperabilidade associados com, por exemplo, interfaces de ferramentas, arquivos e terminologia e definições de dados. Alguns padrões são formalmente aprovados por aplicações industriais. Porém, para assegurar eficiência operacional de um ambiente de Manufatura Virtual, é necessário estabelecer um padrão de dados único ou, ainda, um software para a conversão de dados, facilitando, dessa forma, a troca de dados entre sistemas desse ambiente. De acordo com Lee et al. (2001), embora muitos padrões sejam desenvolvidos pela organização ISO, as empresas continuam usando padrões de dados e software diferentes, gerando problemas para utilização da Manufatura Virtual pela Internet.

Uma forma de criar um ambiente altamente integrado é pelo uso de arquiteturas abertas que permitam a inserção de novos elementos, usando interfaces projetadas de acordo com padrões predefinidos. Essa alternativa reduz o custo de implementação e treinamento, pois possibilita que sejam realizadas mudanças nas capacidades dos sistemas com mínimo impacto e por meio de interfaces com usuário.

Além disso, mesmo que novas ferramentas e sistemas sejam altamente interoperáveis, a Manufatura Virtual somente se tornará realidade quando for efetivamente integrada com ferramentas e sistemas legados, principalmente no caso de utilizar essa proposta em um ambiente de desenvolvimento de produto já existente.

Outro fator que dificulta a integração de ferramentas, sistemas e dados é que, além de integrar seus processos internos, as empresas devem considerar toda a cadeia de fornecimento, bem como o envolvimento de fornecedores no processo de desenvolvimento do produto e processo. Assim, interfaces externas estão se tornando tão críticas quanto interfaces internas, e sistemas de engenharia e projeto devem ser integrados além dos limites organizacionais. Por exemplo, a DaimlerChrysler recomenda que os fornecedores de primeiro nível usem o mesmo software CAD/CAM (Committee, 1999).

Outro desafio é o gerenciamento das informações. Primeiramente, porque, com a Manufatura Virtual, novos projetos e processos são construídos, analisados e testados em um ambiente simulado. Conseqüentemente, há a geração de grande quantidade de informações, pois a coleta de dados de teste não é limitada a um produto ou processo físico. Segundo, porque a integração não só deve ocorrer entre diferentes e independentes bancos de dados para informação e conhecimento dentro da empresa como também entre bancos de dados de fornecedores, clientes e outras empresas. É necessário estabelecer uma base de dados completa para dar suporte à operação da Manufatura Virtual.

As tecnologias para gerenciamento de banco de dados têm alcançado sucesso substancial e as bases de conhecimento para tecnologias de manufatura estão se expandindo bastante. Porém, uma pequena porção desses recursos está sendo convertida para bases de dados de computador. A conversão bem-sucedida do know-how em manufatura para base de dados computacional demanda investimento e grande esforço humano. Além disso, trabalho adicional ainda é requerido para atualizar as tecnologias de base de dados a fim de atender a demandas futuras.

Outro desafio associado ao desenvolvimento e uso de ambientes virtuais e distribuídos é o gerenciamento da configuração, ou seja, a tarefa de assegurar que todas as ordens de engenharia e mudanças de projeto sejam refletidas nas simulações e modelos usados para criar e avaliar novos projetos. O gerenciamento da configuração tem sido tradicionalmente usado para produtos, mas está se expandindo para incluir processos e recursos.

Segundo Lee et al. (2001), a velocidade operacional do sistema também pode constituir uma barreira à implantação da Manufatura Virtual. A utilização desse ambiente envolve grande quantidade de trabalho em computação matemática, processamento gráfico de imagens, troca de dados e comunicações remotas. Isso inclui a construção de modelos sólidos 3D, animação 3D, realidade virtual, planejamento de recursos de manufatura, processamento das características do produto, aquisição de know-how em manufatura, etc. Apesar do rápido avanço do poder computacional e das tecnologias de informação, ainda assim não são suficientes para satisfazer as necessidades de um ambiente de Manufatura Virtual.

Outro desafio refere-se ao know-how em manufatura, modelagem e representação. O rápido desenvolvimento da comunicação digital via rede e das ciências da computação forneceu ferramentas indispensáveis à aplicação da Manufatura Virtual. De qualquer forma, ela é desenvolvida com base em know-how humano e no entendimento dos processos de manufatura. Seu desenvolvimento depende muito do conhecimento presente e da capacidade de aplicar ferramentas matemáticas modernas para descrever e apresentar o conhecimento de maneira sistemática. Embora algumas pesquisas se concentrem em estudar teorias dos processos de manufatura, um grande número de problemas ainda não foi resolvido e continua dependendo do julgamento pela experiência.

Como já mencionado, um sistema de Manufatura Virtual absorve grande quantidade de informações. Isso demanda maior capacidade de aprendizado e aquisição de conhecimentos das instalações reais da manufatura, facilitando monitorar o desempenho operacional das instalações, bem como prever e tomar decisões mais precisas. Há muitos estudos na aplicação de ferramentas de Inteligência Artificial, como redes neurais e algoritmos genéricos no controle do processo. Recomenda-se que aplicações de Inteligência Artificial sejam consideradas pela Manufatura Virtual.

Além dos desafios técnicos, algumas dificuldades socioculturais para a implementação do ambiente da Manufatura Virtual podem ser destacadas. Diversas questões culturais, de gerenciamento, econômicas e de treinamento, que surgem quando tecnologias e métodos inovadores são usados, devem ser superadas. O desenvolvimento de um sistema de Manufatura Virtual demanda alto investimento de capital e esforço administrativo. Implementar novas tecnologias requer investimento em treinamento de pessoal, tradução dos dados existentes, aquisição de novas ferramentas de software, sistemas e pessoal de suporte. Depois de implantado, é difícil comprovar que um sistema de Manufatura Virtual é responsável pela redução dos custos ou pela melhoria da qualidade. Um investimento em uma nova infra-estrutura com retorno incerto não é visto como favorável pelos gerentes que decidem se aceitam ou não o risco. Tais decisões devem ser guiadas por métricas que prevêem o desempenho futuro da Manufatura Virtual em aplicações específicas, e, uma vez implementada, deve-se medir o sucesso dessa ferramenta no alcance das metas. Mas essas métricas não estão disponíveis e precisam ser definidas.

Além disso, segundo Lee et al. (2001), a Manufatura Virtual, apesar de oferecer solução atrativa para a empresa melhorar sua eficiência e produtividade, ela não pode ser vista como uma solução para melhorar o estado atual da empresa de forma imediata; é uma solução que traz benefícios futuros.

O suporte da alta administração torna-se muito importante para que ambientes desse tipo sejam implementados.  Recursos adicionais são necessários no início do desenvolvimento de produto para tratar das sofisticadas análises e simulações presentes nesse novo ambiente. Suporte ativo de organizações de pesquisa, de empresas e do governo também se torna importante, pois para a implantação da Manufatura Virtual diversas empresas, setores de negócio e eras tecnológicas estão envolvidos. Além disso, dentro do mesmo setor de negócios, ainda há diferenças e, dessa forma, desenvolver um regulamento e um padrão unificado também é um problema social que precisa ser desenvolvido.

6. Considerações finais

Cada vez mais a vantagem competitiva das empresas depende da utilização de novas metodologias e de novos ambientes de desenvolvimento de produto, apoiados principalmente pela utilização de ferramentas e tecnologias computacionais.

O ambiente proposto pela Manufatura Virtual envolve grande quantidade de sistemas e ferramentas computacionais que devem agir de forma integrada, sendo necessário para tanto um conjunto de características e requisitos, tanto em nível tecnológico quanto funcional, ainda não totalmente encontrado nas soluções comercialmente disponíveis. Um dos principais desafios é desenvolver tecnologias novas e melhoradas e integrá-las efetivamente com tecnologias atualmente disponíveis para criar ambientes de Manufatura Virtual abrangentes e interoperáveis.

Além disso, a aplicação bem-sucedida de um ambiente de Manufatura Virtual requer um know-how multidisciplinar que envolve ampla gama de disciplinas das ciências da computação e engenharia, e abrange mais do que a simulação tradicional de um processo ou operação particular. O entendimento dos processos e operações, que já ganhou grande importância nos métodos convencionais, torna-se essencial para permitir que sejam simulados na Manufatura Virtual. Já a inclusão da Realidade Virtual nesse ambiente proporciona ao desenvolvimento de produto uma nova tecnologia de interface com o usuário, permitindo ao homem maior interação com o objeto simulado e possibilitando sua imersão no ambiente virtual. Essa tecnologia proporciona uma interface melhorada para o projeto e modelagem do produto, simulação dos processos, planejamento das operações e controles de chão de fábrica em tempo real.

Os diversos exemplos de aplicação da Manufatura Virtual mostram que ela vem sendo empregada principalmente por grandes empresas internacionais, pois requer grande esforço para superar os desafios de integração e as mudanças culturais, bem como o alto investimento.

Apesar do crescente interesse por esse novo ambiente, por parte das empresas mundiais, no Brasil, a Manufatura Virtual ainda é pouco conhecida. O que se tem, na maioria dos casos, é a utilização de algumas tecnologias e ferramentas individuais e específicas para certas aplicações; dificilmente verifica-se o uso do ambiente integrado e completo proposto.

Mesmo sabendo dos desafios existentes para a implantação da Manufatura Virtual, espera-se um futuro promissor, pois a contínua demanda por produtos de alta qualidade, com custos reduzidos e menores tempos de lançamento no mercado, levam as empresas a mudarem suas estratégias, processos e práticas de desenvolvimento de produto. E a Manufatura Virtual proporciona, dentro de um ambiente integrado e virtual, as mais poderosas ferramentas para as empresas lidarem com essas mudanças.

Agradecimentos à Fapesp.

Referências Bibliográficas

BALCEIRO, R. B.; CAVALCANTI, M. C. B. O
desenvolvimento de produto no mundo virtual: o caso Boeing 737. 1999. Disponível em: http://www.jsmnet.com/clippings/art028.htm>. Acesso em: 6 jun. 2002.

BANERJEE, P.; ZETU, D. Virtual manufacturing.
New York: John Wiley & Sons, 2001. 320p.

COMMITTEE on Advanced Engineering Environ-ments. Advanced Engineering Environments:
Achieving the vision, Phase 1. Washington, D. C.:
National Academy Press, 1999. 58p.

EMBRAER. Centro de Realidade Virtual. 2002.
Disponível em: <http://www.embraer.com.br/portugues/content/empresa/tecnologia/default.asp>. Acesso em: 10 jul. 2002.

FAKESPACE Systems. Manufacturing Case Study.
2002. Disponível em: <http://www. fakespacesystems.com/pdfs/EmbraerCStudy. pdf>. Acesso em: 25 out. 2002.

HALEVI, G.; WEILL, R. D. Principles of process planning: a logical approach. London: Chapman & Hall, 1995. 349p.

HMS Software Inc. HMS-CAPP second generation.
Manufacturing management information systems, 2000. Disponível em:
<http://www. hmssoftware.com>. Acesso em: 10 jun. 2000.

JAIN, S. Simulation in the next millennium. In: Winter
Simulation Conference. Proceedings... 1999.

LAWRENCE ASSOCIATES INC. Virtual manu-facturing user workshop. Technical report, Ohio, Jul. 1994. 27p. Disponível em: http://www.isr.edu?Labs/CIM/vm/lai1/final6.html. Acesso em: 17 jul. 2000.

LEE, W. B.; CHEUNG, C. F.; LI, J. G. Applications of virtual manufacturing in materials processing. Journal of Materials Processing Technology, v. 113, p. 416-423, 2001.

LIN, E.; MINIS, I.; NAU, D. S.; REGLI, W. C. Contribution to virtual manufacturing background research. University of Maryland, Institute of Systems Research, 1995. p. 44. Disponível em: <http://www.isr.umd.edu/Labs/CIM/vm/ report.html>. Acesso em: 12 jun. 2000.

NASA – National Aeronautics and Space Administration. Alternative Engineering: How virtual reality and simulation are changing design and analysis. NASA Tech Briefs Engineering Solutions for Design & Manufacturing Maga-zine, v. 25, n. 6, p. 16-24, Jun. 2001.

NIST – National Institute of Standards and Technology. 99-1 Planning report: interope-rability cost analysis of the U.S. Automotive Supply Chain, 1999. Disponível em: <http:// www.mel.nist.gov/msid/sima/daratech/sld007.htm>. Acesso em: 21 out. 2001.

PENG, Q.; HALL, T. R.; LISTER, P. M. Application and evaluation of VR-based CAPP systems. Journal of Materials Processing Technology, v. 107, p. 153-159, 2000.

PORTO, A. J.; PALMA, J. G. Manufatura Virtual. In: Fábrica do futuro: entenda hoje como sua indústria vai ser amanhã. Ed. Banas, 2000. cap. 10, p. 89-97.

TMR Show Report. AUTOFACT97: Virtual manu-facturing has become a reality. Atlanta: Lionheart Publishing, 1998. Disponível em: <http://www.lionhrtpub.com/tmr/showreviews98/122697autofact.html>. Acesso em: 20 jul. 2000.

WAVE Report. 3D – Points to Ponder. 2002. Disponível em: http://www.wave-report.com.

VIRTUAL MANUFACTURING: CONCEPTS AND CHALLENGES

Abstract


Virtual Manufacturing has been used by some companies to improve their processes, introducing  more quickly new products in the market. The strategy is to create an integrated environment, composed  by several software tools and systems, aiming at generating a new method to develop products. The  purpose of this paper is to present the Virtual Manufacturing concept and the paradigms involved in its  definition. Then the paper describes the potential application areas and the resulting benefits. In addition, the technical and social challenges in development of a Virtual Manufacturing system are discussed at the end of the text.

Key words: Virtual Manufacturing, product development, simulation.