Desenvolvimento de Drivers de Comunicação

Transcrição

1 Nota de Aplicação NAP033 Desenvolvimento de Drivers de Comunicação Sumário 1. Introdução Tipos de Operandos dos CPs Conceitos Básicos Transação Serviços Pendentes Time-out de Serviço Aquisição de Dados de CPs pelo Driver de um Supervisório Protocolo ALNET I/v Princípios de Funcionamento Características do Canal de Comunicação ALNET I Endereçamento do CP Formato Geral dos Comandos do Protocolo ALNET I Serviços do Protocolo ALNET I Comando Lê Status do Equipamento Comando Monitora Operandos Simples Comando Monitora Operando Tabela Comando Escreve Operandos Simples Comando Força Operandos Tabela Restrições no Uso do Protocolo ALNET I Protocolo ALNET II Princípios de Funcionamento Endereçamento do CP Formato Geral dos Comandos do Protocolo ALNET II Serviços do Protocolo ALNET II Comando Lê Status do Equipamento Comando Lê Operandos Comando Escreve Operandos Validação Revisões Altus S.A. Página: 1

2 1. Introdução Este documento tem como objetivo orientar desenvolvedores de drivers que se comuniquem com CPs Altus e que: sejam conectados diretamente na rede de comunicação ALNET I/v2.0 ou, via gateway, à rede de comunicação ALNET II interpretem diretamente o protocolo ALNET II, como no caso de drivers para Ethernet Antes de serem apresentadas as características peculiares de cada um dos protocolos, são relacionados os tipos de operandos dos controladores que devem ser reconhecidos, e alguns conceitos básicos relacionados. 1.1 Tipos de Operandos dos CPs Os operandos listados a seguir são definidos para os CPs Altus. Cada operando possui limites específicos de endereçamento, sendo que os operandos do tipo tabela também apresentam um endereço de posição dentro da tabela, conforme o tipo de UCP utilizada. Operando Memória M <end> Tabela de Memória TM <end>:<pos> Decimal D<end> Tabela de Decimais TD<end> <pos> Decimal F<end> Tabela de Reais TF<end> <pos> Auxiliar A<end> Entrada E<end> Saída S<end> Maiores detalhes sobre os tipos, formatos e endereçamentos dos operandos do CP podem ser encontrados nos Manual de Utilização e Programação do MasterTool, bem como nos manuais específicos de cada CP. 1.2 Conceitos Básicos Transação Uma transação de comunicação normalmente é composta por uma seqüência de duas mensagens: comando (ou requisição) e resposta. Estas mensagens são trocadas, normalmente, entre dois nós. O objetivo de uma transação é a execução de um serviço de rede. Existe um nó que requisita o serviço (mestre), e outro que fornece o serviço (escravo ou servidor). Inicialmente, o mestre envia uma mensagem (comando) para o escravo. A seguir o escravo envia uma mensagem para o mestre (resposta). No comando, o mestre pode informar para o escravo: o tipo de serviço que deve ser executado Altus S.A. Página: 2

3 pacotes de dados que devem ser recebidos pelo escravo (exemplo: o mestre deseja escrever variáveis no escravo) Na resposta, o escravo pode informar para o mestre: que o serviço solicitado foi reconhecido e executado que o serviço solicitado não foi reconhecido, ou que não foi executado por algum motivo pacote de dados requisitado pelo mestre (exemplo: o mestre deseja ler variáveis do escravo) Uma transação é finalizada quando o nó requisitor recebe: (a) pacote de confirmação de serviço, para o caso de serviços sem resposta; (b) pacote de dados para serviços com resposta de um pacote; (c) o último pacote de dados de serviços com resposta em mais de um pacote; e (d) por time-out Serviços Pendentes Há serviços na rede considerados de execução longa. Para evitar que o processamento pare até o final da execução destes serviços, definem-se serviços pendentes. Um serviço pendente é aquele cuja execução é realizada em várias varreduras, ou seja, a cada varredura completa do executivo realizase uma parcela do serviço Time-out de Serviço Nos serviços em que o CP espera uma resposta, existe um time-out relacionado ao serviço requisitado. Este controle existe para as instruções de escrita/leitura e no serviço de recebimento de módulo. Este time-out é declarado no módulo de configuração (módulo C) em unidades de 100 ms. O valor é necessariamente maior que o time-out de pacote, controlado pelo nível de enlace. Esta condição é garantida pelo CP, colocando um time-out de, no mínimo, 100ms a mais que o time-out de pacote no caso do usuário declarar um valor muito baixo. No caso de ocorrer time-out em uma das instruções, a instrução é terminada com erro, e a requisição solicitada é perdida. Os erros de time-out só ocorrem se o pacote de requisição foi corretamente transmitido e recebido pela estação destino, porém por algum motivo não executado. No caso dos níveis inferiores não realizarem a transmissão, erros específicos são sinalizados para as instruções, por exemplo, time-out de pacote, colisão fora do preâmbulo, etc. 1.3 Aquisição de Dados de CPs pelo Driver de um Supervisório O driver de comunicação de um supervisório deve emular bases de dados similares as dos CPs com os quais se comunica (operandos + áreas de memória para serviços especiais). A aquisição de dados feita pelo driver de comunicação de um software de supervisão deve ser feita por um dos diferentes tipos: execução de "polling": o supervisório busca a informação em um CP, e a escreve na base de dados associada a este CP recepção de mensagens não-solicitadas: os CPs escrevem em uma base de dados especial (nãosolicitada) do driver do supervisório enviando comandos para o endereço do gateway (conectado ao supervisório) na rede. No primeiro tem-se o driver operando como dispositivo mestre da rede, enquanto que no segundo, como escravo. Altus S.A. Página: 3

4 2. Protocolo ALNET I/v2.0 Entende-se por ALNET I/v2.0, os comandos do protocolo ALNET I que estabelecem a comunicação com todos os controladores programáveis Altus, exceto os integrantes da série de controladores AL-1000, doravante aqui denominada apenas como ALNET I.. A ALNET I é uma rede de comunicação que se comunica com a rede ALNET II através de um gateway AL-2400/S. O AL-2400/S é um equipamento gerenciador da troca de informações entre as redes, permitindo que um supervisório conectado ponto a ponto a rede ALNET I opere como mestre ou escravo, este último necessário para que existam mensagens não solicitadas na rede. A comunicação serial na rede ALNET I, entre terminais de programação ou supervisão e controle e os controladores programáveis, é realizada de forma ponto-a-ponto, isto é, somente entre os dois equipamentos. 2.1 Princípios de Funcionamento Usualmente, uma configuração de rede padrão, utilizando as redes ALNET I e ALNET II, apresenta a configuração mostrada a seguir: micro compu GATEWAY CP1 CP2 CP3 CP4 CP5 CPN... Configuração Típica de uma Estação de supervisão e Controle O supervisório da rede normalmente possui a iniciativa do envio de comandos para os controladores. Estes os recebem, analisam, interpretam e executam, enviando comandos de resposta de volta ao supervisório. Quando implementado no driver de comunicação a característica de tratamento de mensagens não solicitadas, qualquer CP ligado a rede ALNET II poder enviar comandos ao supervisório. Para isto, envia requisições para o endereço do supervisório na rede ALNET I. Este endereço é o mesmo endereço de sub-rede do gateway na ALNET I, sendo o endereço de nó destino qualquer valor diferente do valor configurado como nó do gateway. Após a transmissão de um comando, o equipamento que enviou deve esperar a resposta do equipamento destino, antes de transmitir outro comando pela rede, a fim de evitar conflitos entre transmissões simultâneas na linha. Esta espera ocorre enquanto o tempo de time-out configurado não foi excedido. Após este tempo, o equipamento mestre assume uma falha na comunicação ou o mau funcionamento do equipamento escravo. O tratamento do protocolo pelo equipamento escravo pode ser dividido em dois níveis: análise dos bytes recebidos e interpretação de um comando. O escravo analisa os bytes que transitam na linha à medida que os mesmos vão sendo recebidos. São detectados erros do canal de comunicação, tais como erro de paridade, "overrun" ou "framming". Altus S.A. Página: 4

5 Também são verificados erros de protocolo, no que diz respeito à consistência de seu formato (byte inicial, checksum do cabeçalho e bloco de dados, número de bytes que compõem o cabeçalho e o bloco de dados) e também à interrupção do protocolo antes do seu término (p. ex.é o cabeçalho chega incompleto por falha do mestre). Quando um equipamento escravo recebe da linha um comando não endereçado a si próprio, não executa nem responde o mesmo, mas permanece "escutando" a linha e contando os bytes restantes do comando, a fim de permanecer sincronizado com a transmissão, aguardando o próximo comando. Não é permitida a presença simultânea na rede de dois equipamentos com o mesmo endereço de identificação. No segundo nível de tratamento, realizada a consistência do comando recebido, desde que o endereço seja o do próprio equipamento escravo. É verificada a correção do número do comando, dos seus parâmetros e seu bloco de dados. Se o comando estiver correto, este é executado e o caracter ACK é devolvido na resposta. Se ocorrer algum erro, é enviada como resposta um comando contendo o caracter NACK e um código de erro, indicador da natureza do erro. 2.2 Características do Canal de Comunicação ALNET I Velocidade de comunicação: 9600 bps Paridade: par Número de bits por caracter: 8 Número de start bits: 1 Número de stop bits: Endereçamento do CP Com o objetivo de unificar os espaços de endereçamento para os protocolos ALNET I e ALNET II, utiliza-se parte do primeiro byte do frame de comando da ALNET I como endereço, totalizando 11 bits de endereço na ALNET I: END_SUB_H STX END_SUB_L END_NO Este formato permite com que o nó mestre da ALNET I consiga endereçar: até 63 sub-redes (1 a 63) até 31 estações (1 a 31) por sub-rede IMPORTANTE: Para equipamentos ESCRAVOS na ALNET I, como os controladores programáveis, o frame ALNET I deve iniciar com um byte STX (=02h) (e não apenas um nibble). PORTANTO, qualquer frame contendo uma identificação de sub-rede maior do que 7 NÃO SERÁ RECONHECIDO por estes equipamentos. Esta informação será decodificada como endereço de nó, uma vez que para redes ALNET I o endereço de subrede é sempre igual a zero. Altus S.A. Página: 5

6 A extensão do endereçamento ALNET I somente é interpretada por equipamentos com capacidade de serem MESTRES na rede ALNET I (supervisórios ou gateways) e que necessitam comunicar-se com nós conectados em sub-redes ALNET II. 2.4 Formato Geral dos Comandos do Protocolo ALNET I Um comando é composto por um cabeçalho e, opcionalmente, um bloco de dados. BYTE CONTEÚDO VALOR Cabeçalho Bloco de Dados END STX 2 END COMAND CKS D A D O S... CKS O cabeçalho contém 8 bytes e especifica o comando enviado pelo mestre ou a resposta retornada pelo escravo. O bloco de dados opcional tem tamanho variável. O último byte do cabeçalho ou do bloco de dados é o byte de checksum. A soma - truncada em 1 byte e desprezando o bit de carry - de todos os bytes de um cabeçalho ou de um bloco de dados, incluindo o próprio byte de checksum, deve resultar em Serviços do Protocolo ALNET I Para o desenvolvimento de drivers de comunicação para supervisórios, deve ser implementado o seguinte subconjunto de comandos do protocolo ALNET I: Comando (dec/hex) Descrição do Comando h Lê status do equipamento Eh Resposta sem bloco de dados h Monitora operando simples h Monitora operando tabela h Resposta sem bloco de dados - até 256 bytes de dados h Força operandos Tabela h Escreve operando simples 192 0C0h Resposta com blocos de dados - até 64 Kbytes Altus S.A. Página: 6

7 A descrição completa dos comandos ALNET I encontra-se na Norma Técnica Altus NTP031. Anexo a esta norma é fornecida uma implementação parcial exemplo do protocolo ALNET I, em linguagem C. O arquivo de header contém a documentação dos métodos para o usuário. Na sequência são apresentados exemplos de frames de controle que representam as requisições ALNET I para o comando a que se referem. Para os exemplos foram considerados endereço destino como sendo nó 1 da subrede 0 (rede puramente ALNET I) Comando Lê Status do Equipamento Frame de Requisição ALNET I: D8 Frame de Resposta ALNET I: [DADOS + CKS] Comando Monitora Operandos Simples Operandos: M0010 à M0012 Frame de Requisição ALNET I: A 03 C8 Frame de Resposta ALNET I: C [DADOS + CKS] Comando Monitora Operando Tabela Operando: TM0010 posições 5 à 7 Frame de Requisição ALNET I: A A2 Frame de Resposta ALNET I: C0 06 0A [DADOS + CKS] Comando Escreve Operandos Simples Operandos: M0010 à M0012 Valor Forçamentos: M0010 = 10 ; M0011 = 11; M0012 = 12 Frame de Requisição ALNET I: A A 00 0B 00 0C DC Frame de Resposta ALNET I: E D9 Altus S.A. Página: 7

8 2.5.5 Comando Força Operandos Tabela Operando: TM0010 posições 5 à 7 Valor Forçamentos: TM0010:5 = 5 ; TM0010:6 = 6; TM0010:7 = 7 Frame de Requisição ALNET I: A EB Frame de Resposta ALNET I: E D9 2.6 Restrições no Uso do Protocolo ALNET I A seguir estão listados alguns itens que devem ser observados no desenvolvimento de drivers de comunicação. O supervisório deve evitar comunicações utilizando o endereço de nó igual a zero, sendo este endereço reservado para uso do software programador de CPs Comandos de monitoração e forçamento de tabelas de memória (TM) não devem ser maiores do que 64 posições a cada transação, devido a restrições da ALNET I Comandos de monitoração e forçamento de tabelas de decimais (TD) e tabelas de reais (TF) não devem ser maiores do que 55 posições por vez, devido a restrições da rede ALNET I 3. Protocolo ALNET II 3.1 Princípios de Funcionamento O nível de aplicação do protocolo ALNET II é utilizado como nível de aplicação para supervisórios que interpretam TCP/IP através de uma rede Ethernet, e que desejam se comunicar com CPs AL-2002, conectados à Ethernet por alguma interface de rede Altus, tal como AL-3405 ou WebGate. O nível de aplicação nos supervisórios, neste caso, é implementado através de serviços (comandos) ALNET II. A conexões entre as redes ALNET I, ALNET II e Ethernet, são mostradas a seguir. No exemplo são consideradas UCP AL-2002 e interface de rede AL-3405: Altus S.A. Página: 8

9 ALNET I (RS-232) ALNET II (RS-485) ETHERNET CPU AL2002 AL3405 B A R R A M E N T O D O C P Aplicação 7 ALNET II AL-2002 Apresentação 6 Sessão 5 Transporte 4 TCP Rede 3 IP Al3405 Enlace 2 ETHERNET Físico 1 & IEE Conexões entre as Redes O nó requisitor de serviço é quem inicia uma transação. É possível definir no máximo 16 transações para cada nó da rede, isto é, um requisitor pode solicitar até 16 serviços (máximo) a uma mesma estação da rede antes que uma destas venha a ser executada. A razão de haver um controle de transação é função da necessidade de identificar a resposta com a requisição realizada. Para iniciar uma transação o requisitor deve, segundo sua estrutura de dados, alocar um número de transação para a estação solicitada. Cada entrada nesta estrutura de dados corresponde a requisição de um serviço a espera de resposta (transação). Uma transação é identificada pelo seu número (0-15) e pelo endereço da estação destino (executora). Após a obtenção do número da transação segue a montagem do pacote de requisição obedecendo o formato do frame definido para a ALNET II. Na estrutura de dados da transação deve haver uma previsão para campos de time-out, já que esta pode ser finalizada por esta condição. Caso a resposta a transação ocorra após sua finalização por time-out, esta deve ser desconsiderada. Finalizar uma transação significa, na prática, retirá-la da estrutura de dados de requisições a espera de resposta. 3.2 Endereçamento do CP No módulo de configuração das UCPs Altus aparece o endereço ALNET II do CP, constituído de um endereço de nó (variando de 1 a 31), e de um endereço de sub-rede (variando de 1 a 63). A subrede 64 é reservada para Ethernet. O endereço de nó IP (valor menos significativo) de um CP pode assumir valores de 1 a 255. Na rede Ethernet, pode-se colocar apenas "nós ALNET II" na sub-rede 64. Entenda-se por "nós ALNET II" da rede Ethernet os CPs e os demais nós (como supervisórios) que precisam dialogar diretamente com estes CPs, através da rede Ethernet. Portanto, só podem existir 255 "nós ALNET II" na rede Ethernet. Na rede ALNET II, podem existir até 63 sub-redes, cada uma com até 31 nós. Altus S.A. Página: 9

10 3.3 Formato Geral dos Comandos do Protocolo ALNET II Uma transação na rede ALNET II compreende uma requisição gerada por uma estação solicitante de um serviço e uma resposta emitida pela estação executora do serviço solicitado. O frame de informação empregado pelo nível de aplicação da ALNET II possui no máximo 256 bytes, apresentando o seguinte formato básico: Byte Requisição Resposta 00 DA low DA high DA low DA high 02 SA low SA High SA low SA High 04 TAM high TAM low TAM high TAM low 06 DSAP DSAP 07 SSAP SSAP 08 CONTROLE CONTROLE 09 TIPO TIPO 10 PAC high PAC low PAC high PAC low 12 REQUISIÇÃO REQUISIÇÃO 13 - ERRO 14 SR fonte SR fonte 15 NÖ fonte NÖ fonte 16 SR destino SR destino 17 NÖ destino NÖ destino 18 TAM +6-1 Área de cabeçalho Área de dados DA e SA (2 bytes cada) endereços destino e fonte, respectivamente, de uma comunicação. Ao endereçar um nó, o byte menos significativo do endereço aparece primeiro. O bit menos significativo deste byte (low) deve sempre ser zero para endereçamentos diretos (não multi/broadcast), fazendo com que os endereços de nó apareçam deslocados de um bit para a esquerda (ou multiplicados por 2). TAM (2 bytes) tamanho do frame de informações em número de bytes, excluindo os primeiros 6 bytes DSAP e SSAP sempre zero CONTROLE sempre igual a hexa C0 ou 192 TIPO serve para uma série de ações de controle do nível de aplicação como: interpretação do tipo de pacote, identificando-o como requisição ou resposta se a requisição fornece um ou mais pacotes de resposta durante sua execução Altus S.A. Página: 10

11 identificação da recepção do último pacote de resposta se é um pacote proveniente de um nó local ou de outra sub-rede (este é o caso para drivers de supervisórios) O número de transação é gerado por todo mestre de uma comunicação (incluindo o driver de um supervisório) e é utilizado para consistência entre requisições e respostas; varia de 0 a 15. PAC (2 bytes) número do pacote; possibilita controle de seqüenciamento na execução de um serviço com múltiplos pacotes REQUISIÇÃO identificação do serviço a ser executado ERRO tem significado apenas para pacotes de resposta, servindo para confirmar a execução de um serviço. Seu valor é zero no término de um serviço com sucesso. Em caso de erro, um valor indicativo (código de erro) é enviado junto à resposta, informando a causa da não execução do serviço SR fonte e destino sempre 64 NÓ fonte e destino equivalente a DA e SA ÁREA DE DADOS possui tamanho de zero a 220 bytes. Pode aparecer nos pacotes de requisições que necessitam enviar parâmetros, e nos pacotes de resposta, dependendo do tipo de serviço requisitado O último byte de um pacote tem o índice TAM+6-1, já que TAM é igual ao número total de bytes do pacote, menos os 6 primeiros bytes. 3.4 Serviços do Protocolo ALNET II Para o desenvolvimento de drivers de comunicação para supervisórios, o seguinte subconjunto de comandos do protocolo ALNET II precisa ser implementado: Requisição (Dec/Hex) Descrição do Comando h Lê Status do Equipamento h Escreve operandos h Lê operandos. A Área de dados dos serviços de escrita e leitura de operandos apresenta os seguintes formatos: Escreve Operandos Requisição Descrição do Operando Área de Valores Lê Operandos Requisição Resposta Descrição Área de do valores operando Altus S.A. Página: 11

12 Os códigos de erro possíveis nas respostas lógicas para estes dois tipos de requisições são os seguintes: Código (Dec/Hex) Erro Ch Tipo de operando inválido h CP protegido Dh Operando não definido Eh Índice de tabela inválido h Bloco de operandos inválido Conclui-se que: apenas um operando ou bloco de operandos pode ser transferido a cada transação nível de aplicação do supervisório deve se encarregar de subdividir a transferência de um operando ou bloco, que ocupar mais de 220 bytes em múltiplas requisições. A descrição completa do protocolo de comunicação para redes ALNET II aparece na Norma Técnica Altus NTP032. Anexo a esta norma é fornecida uma implementação parcial exemplo do protocolo ALNET II, em linguagem C. O arquivo de header contém a documentação dos métodos para o usuário. Na sequência são apresentados exemplos de frames que representam as requisições ALNET II / Ethernet para o comando a que se referem. Para os exemplos foram considerados os endereços abaixo relacionados, bem como os valores apresentados na base numérica hexadecimal: IP origem = nó = 34H e sr eth = 40H nó x 2 = 68H IP destino = nó = 29H e sr eth = 40H nó x 2 = 52H Comando Lê Status do Equipamento Frame de Requisição ALNET II: C C Frame de Resposta ALNET II: C C0 C [DADOS] Comando Lê Operandos Operandos: M0010 à M0012 Frame de Requisição ALNET II: C A 00 0C Frame de Resposta ALNET II: C0 C [DADOS] Altus S.A. Página: 12

13 Operando: TM0010 posições 5 à 7 Frame de Requisição ALNET II: C0 6F A0 00 0A Frame de Resposta ALNET II: C0 CF [DADOS] Comando Escreve Operandos Operandos: M0010 à M0012 Valor Forçamentos: M0010 = 10 ; M0011 = 11; M0012 = 12 Frame de Requisição ALNET II: C A A 00 0B 00 0C Frame de Resposta ALNET II: C C0 C Operando: TM0010 posições 5 à 7 Valor Forçamentos: TM0010:5 = 5 ; TM0010:6 = 6; TM0010:7 = 7 Frame de Requisição ALNET II: C A0 0A Frame de Resposta ALNET II: C C0 C Validação Entende-se por validação do produto os testes sobre as implementações do(s) protocolo(s) ALNET I e ALNET II, os quais visam verificar se as implementações realizadas permitem a utilização para o qual foram concebidos. Os drivers devem ser testados a fim de verificar o funcionamento correto de todos os comandos implementados, bem como a verificação da performance obtida. Na sequência são listados alguns testes aos quais as implementações devem ser submetidas, sendo algumas específicas da implementação ALNET I, outras ALNET II. Todos os testes devem ser feitos com programas bem pequenos ( 01 lógica ) e grandes (200 ms ou mais ) para que se avalie a influência do tempo de ciclo do CP na performance da comunicação. Altus S.A. Página: 13

14 Todas as etapas que seguem devem ser executadas ao mesmo tempo pelo micro-computador rodando o MasterTool. Os resultados obtidos nas operações de monitoração de operandos devem ser os mesmos. Operações de escrita realizadas pelo driver devem ser confirmadas através de leituras no programador. Descrição do Teste 1 Verificação da monitoração e forçamento de operandos simples e tabelas 2 Verificação do forçamento de bits de auxiliares 3 Monitoração de bits de operando simples e tabelas de memória 4 Verificação de recepção de mensagens não solicitadas de operandos simples e tabelas 5 Verificação do comando status do CP 6 Monitoração de CPs utilizando os limites de endereçamento 7 Verificação do estado do CP em relação à comunicação 8 Verificação da performance do sw 9 Testes simultâneos de polling e mensagens não solicitadas 10 Verificação das mensagens de erro geradas pelo software em caso de falha de algum dispositivo 11 Testar subdivisões de operandos, para os tags definidos 12 Monitoração de mais de um CP simultaneamente pelo driver com monitoração dos CPs por duas estações também simultaneamente, todos ligados a mesma rede ethernet 13 Verificação da comunicação com diferentes ajustes de time out de comunicação 14 Verificação de diferentes taxas de geração de requisições pelos equipamentos e teste da sincronização de blocos de comunicação baseado no intervalo de silêncio entre blocos. Devem ser avaliados os tempos de silêncio após blocos válidos ou inválidos 15 Comportamento com comandos inválidos e não implementados emitidos tanto pelos mestres quanto pelos escravos das comunicações 16 Verificação do restabelecimento da comunicação após desligamento alternado de mestre e escravos das comunicações. Verificar a influência do desligamento de um escravo na comunicação do mestre com o outro escravo 17 Verificação do diagnóstico de falhas de comunicação induzidas artificialmente por um gerador de blocos mal formados ou pela interrupção física da conexão. 18 Verificação do restabelecimento da comunicação após cessar a inserção artificial de blocos mal formados ou interrupção física da conexão sem necessidade de reinicialização dos equipamentos mestres ou escravos Altus S.A. Página: 14

15 5. Revisões A revisão deste documento é mostrada na margem superior, indicando alterações no conteúdo ou melhorias no formato. O histórico a seguir apresenta observações correspondentes a cada revisão: Revisão: A Data: 02/05/94 Autor: Rosana Casais & Maria Helena Jaeger Aprovador: Júlio Siczkowski Observações: Esta é a primeira versão liberada. Revisão: B Data: 16/04/01 Autor: Éder J. F. Garcia Aprovador: Luiz Gerbase Observações: Conversão de Word 5.0 para Word 97. Revisão: C Data: 10/04/03 Autor: Rosana Casais Aprovador: Luiz Gerbase Observações: Revisão geral do documento. Corrigido endereço de subrede Ethernet de 63 para 64. Incluídos exemplos de frames ALNET I e ALNET II dos comandos (sniffer). Anexados módulos exemplo em C de implementações dos protocolos ALNET I e ALNET II. Incluída seção referente à validação de drivers. Altus S.A. Página: 15