Pagina scratch

Horários no IFSC 2013/2

Segunda-feira => 13:30 ás 17:30

Quarta-Feira => 7:30 ás 9:30

Quinta-Feira => 07:30 ás 9:30 e 13:30 ás 15:30

Documentação do projeto (26/08)

Especificação do Projeto

Cenário 1

Pré condição:

1º - Somente deverão ser usados algarismos "0" e "1" como mensagens;

2º - O sistema está desligado (flag vermelho do scratch clicado). Usuário implemente sprites com PCs que irão se conectar as placas de rede (sprite chave). Para que a chave possa compreender quem é o PC que estará conectado a ela, o mesmo deve informar através da variável global "quadro" a mensagem que deseja transmitir. O formado da mensagem que o pc deve adicionar na variável quadro é o seguinte:

• Primeiros 3 digitos devem ser o identificador do pc que deverá ser idêntico ao ID da chave que ele deseja estar conectado;
• Do dígito 4 ao 6 deve constar o destino que se deseja enviar a mensagem, que pode ser informado pelo usuário através de linha de comando;
• Por último vem a mensagem que se deseja transmitir, que poderá ter qualquer tamanho.

3º - Todos PCs, ao final da transmissão, receberão uma mensagem "dizer_mensagem". Quando o mesmo receber esta mensagem, haverá uma lista "mensagem-XXX", onde XXX é o ID do PC e nesta lista estará a mensagem coletada pela chave associada ao PC. Deve ser feito um teste nesta lista:

• Se os bits das posições 4 a 6 forem identicos ao ID do PC, então o PC deverá apresentar em tela o conteúdo dessa lista. Isto significa que caso o PC em questão seja o destino informado pelo usuário para o envio da mensagem, então este deverá apresentá-la em tela, caso contrário não.

O usuário liga o sistema clicando na FLAG VERDE. Dois botões aparecerão no canto inferior direito, um azul (Criar meio) e outro cinza (Criar chave). Quando o usuário arrasta a seta do mouse até um destes botões aumentará o tamanho do botão.

Clique do mouse em "Criar meio": é mandado um sinal "criar meio" para todos. Quando o sprite meio escutar este sinal, o mesmo irá gerar um clone de si e jogá-lo na posição (0,0) do palco.

Clique do mouse em "Criar chave": é mandado um sinal "criar chave" para todos. Quando o srpite chave escutar este sinal, o mesmo irá gerar um clone de si e jogá-lo na posição (0,0) do palco, além de informar o seu ID que será necessário para os PCs se comunicarem com as chaves.

• É possível arrastar os sprites para qualquer parte do cenário e montar a topologia da maneira que o usuário desejar.
• Segurando a tecla "d" e clicando em algum sprite chave ou meio aparecerá uma janela perguntando se o usuário deseja excluir o sprite clicado. Basta responder com um "s" e teclar enter para confirmar a exclusão.

Funcionalidades

Chave

1) O sprite chave escuta mensagens enviadas por PCs. Os PCs devem mudar a variável global "identifica_pc" quando o mesmo desejar se comunicar com alguem. Nesta variável ele deve informar seu ID que deve ser o mesmo da chave que ele estiver "conectado". Com isso, a chave consegue distinguir quando ela deve atuar e assim montar o quadro a ser transmitido. Então, a chave mudará de cor em intervalos de 1 segundo de acordo com o valor do bit a ser transmitido. 2) Haverá um script nas chaves que detecta mudanças de cores. Quando houver transmissão de mensagens pelo meio, este o fara por mudança de cores. Portanto, se o meio mudar de cor, a chave irá inserir em um buffer um conteúdo que mudará de acordo com a cor que o meio estiver. 3) Com a informação completa, a chave informa ao PC conectado a ela a mensagem que está armazenada em seu buffer.

Meio

Este sprite apenas detecta as mudanças de cor de objetos encostados nele (chave) e muda sua cor para a mesma da chave. Dessa forma, as outras chaves que estiverem conectadas ao meio conseguirão detectar as mensagens informadas pelo meio.

Primeiro Laboratório Scratch

O objetivo deste primeiro laboratório no Scratch é desenvolver um ambiente que simule uma rede local com topologia em estrela (utilizando um switch),em anel (utilizando uma rede local Token-Ring) ou topologia em barramento e em seguida mostre a forma com que ocorre a troca de mensagens em cada protocolo. Será possível visualizar a troca de mensagens entre os computadores da rede através de simulações em broadcast, multicast e unicast, dependendo da escolha do usuário.

Nas simulações também será possível visualizar colisões de pacotes quando o meio estiver ocupado por outros dispositivos e aguardar um certo tempo para tentar transmitir novamente seus pacotes até o destino desejado. Com isso será possível compreender melhor o funcionamento do método de transmissão CSMA-CD, amplamente utilizado em redes locais Ethernet, onde o dispositivo "escuta" o meio antes de transmitir e, se ninguém estiver transmitindo no momento, a troca de mensagens ocorrerá entre A e B.

Em seguida será possível clicar em um botão para mudar este método para CSMA-CA, onde o dispositivo avisa que irá transmitir momentos antes de efetivamente transmitir, dessa forma todos os dispositivos sabem que alguém deseja usar o meio em determinado momento e então não ocupam-no. dessa forma será possível verificar as diferenças entre ambos métodos de transmissão, CSMA-CD e CSMA-CA. Também haverá simulações que demonstre o funcionamento e a forma como ocorre a negociação em modos simplex, half-duplex e full-duplex.

Também será possível inserir novos computadores e novas interfaces de rede aos computadores já existentes no cenário e em seguida realizar novas simulações. O cenário apresentará os endereços físicos (MAC) e endereço lógico (IP) de cada interface.

Casos de Uso Previstos

Caso 2 - O usuário clica sobre um PC para enviar uma mensagem para outro PC

Para a simulação iniciar, basta clicar em um dos 5 computadores da rede e inserir na caixa de texto que se abrirá o ID do computador de destino que se deseja enviar o pacote. Então, o pacote será enviado ao meio. Este fará a entrega do pacote até o destino desejado, porém, todas as demais estações receberão o pacote, no entanto, somente a que obtiver o ID designado lê a mensagem. Será possível enviar mais de uma mensagem ao mesmo tempo simplesmente clicando em outro computador e inserindo o endereço de destino desejado como da primeira vez. No entanto, quando uma mensagem é enviada ao meio, este fica ocupado e se houver a tentativa de ocupação do meio por outra mensagem, ocorrerá uma colisão. Por este motivo, a interface de rede "escuta" o meio e aguarda até que este esteja desocupado para enviar a mensagem. Desta forma, evita-se que a colisão ocorra.

=Caso 3 - Ocorrência de colisão

Haverá um botão chamado "Forçar colisão". Quando clicado neste botão, duas mensagens serão enviadas ao mesmo tempo e será possível observar o comportamento do sistema quando ocorrer uma colisão. Será sorteado um valor aleatório de tempo para os dois computadores tentarem retransmitir suas mensagens. Ao final deste tempo ocorrerá a transmissão. Aquele que obtiver o menor tempo sorteado transmitirá primeiro, o outro escutará o meio e aguardará que o mesmo fique desocupado após o estouro do tempo sorteado e enviará a mensagem ao destino desejado.

Caso 4 - O usuário constrói o cenário desejado

Haverá um botão chamado "Criar cenário". Quando clicado, aparecerá na tela o barramento em que os computadores da rede estarão conectados. Haverá também os cabos de rede que deverão ser conectados ao barramento. Para isso, basta clicar nele e arrastar até próximo a uma das extremidades no barramento. Haverá também a figura de um computador, basta clicar e arrastá-lo até a outra extremidade do cabo de rede que foi conectado ao barramento. Será possível conectar até 5 computadores e realizar os mesmos testes e as mesmas simulações citadas anteriormente.

Reunião 06/05

Foi apresentado uma prévia daquilo que deverá ser implementado no Scratch para a topologia em barramento. Esta prévia foi disponibilizado acima nesta mesma página. Em seguida foi apresentado as alterações da versão anterior do primeiro projeto no Scratch com uma topologia em barramento, sendo verificado algumas melhorias em relação a versão anterior, entre elas a entrega do pacote ao meio para o mesmo distribuir a todos dispositivos da rede, porém somente o destinatário "lê" a mensagem. Também foi implementado uma "ocupação do meio" enquanto há pacotes trafegando na rede, onde o mesmo também avisa quando está desocupado.

Foi discutido a possibilidade de implementação de, quando clicado em um PC enquanto já estaria sendo utilizado o meio, mostrar uma mensagem ao usuário dizendo que o meio estaria ocupado, sendo que, para 1 dos PCs, esta lógica já está funcionando. Ficou acordado que esta mensagem não deveria aparecer, apenas o pacote seria gerado e não seria despachado ao meio enquanto este não estiver livre. Sendo assim, seria possível dispensar a simulação que gera colisões.

Também foi discutido sobre a possibilidade de implementação de apresentação de um cabeçalho, contendo os endereços de origem e destino junto de uma mensagem que seria transportada pelo meio dentro dos pacotes já existentes e apresentada quando esta atinja o seu destino.

Por último, com relação a possibilidade de criação de cenários, foi levantada a hipótese de ser implementado um cenário que o usuário possa definir quantos PCs teria a rede dele e que ele simplesmente clicasse em um PC e automaticamente o sistema alocaria um ID, um endereço MAC para todas as interfaces de rede e os cabinhos para conectar os PCs ao meio físico.

Versão atual do projeto: [[Media:Arquivo:Barramento2.sb]]

Reunião 13/05

Neste dia foi apresentado as evoluções no desenvolvimento das simulações da topologia em barramento, onde um mini cabeçalho é gerado e apresentado em tela antes e após a entrega das mensagens entre os computadores. Também foi verificado que o sistema já dispunha de um algoritmo que evite colisões de mensagens na rede, isto é, se algum PC verifica que o meio está ocupado, ele prepara a mensagem para ser enviada mas não a envia até que o meio avise que está livre. Após o meio enviar o sinal que está livre, a mensagem é transmitida normalmente.

Com relação a criação de cenários por parte do usuário, foi levantada a hipótese de usarmos o "MIT SCRATCH ONLINE", que dispõe de uma facilidade para criação de clones de objetos, facilidade esta que poderia ajudar nas implementções. No entanto, houveram algumas dificuldades na adaptação com o novo sistema e no estudo de suas novas funcionalidades e por isso o desenvolvimento do laboratório de criação de cenários ainda está nos primórdios.

Para a próxima semana, ficamos acordados que seria interessante se o cenário de criação de topologias implementasse uma funcionalidade especial: que o meio propagasse a mensagem não mais através de pacotinhos, mas que fosse "preenchesse o meio" com as informações e elas prosseguissem até o destino como se fosse água dentro de um cano, tudo isso utilizando o MIT-SCRATCH. Antes de tudo, o cenário para criação de topologias deveria estar implementado, já que ele é extremamente necessário para a realização dos testes, portanto, este deve ser o próximo passo a ser concluído.

Reunião 20/05

Na reunuão deste dia foi levantada uma certa dificuldade em manipular clones gerados pelo Scratch 2.0, pois a princípio não haveria como reutilizar um clone gerado anteriormente e efetuar novas manipulações a partir deste clone. Então, foi levantada a hipótese de colocarmos um contador que vá incrementando seu número sempre que um novo clone é gerado. Esse contador seria o ID do clone. Então bastaria realizar um teste com este contador, se este fosse o ID do clone clicado, então fariamos a ação necessária. Vimos que dessa forma será possível manipular clones antigos quando clicado sobre os mesmos.

Também foi discutido a respeito da forma como a informação deveria "fluir" no meio. E uma forma interessante levantada foi a de utilizar clones que representariam a informação atravessando o meio após a criação do cenário pelo usuário. Ficou acertado que, a princípio, haverão posições nas coordenadas do palco que serão específicas para que haja a presença de um PC, isto é, haverá um limite (entre -10 e 10 por exemplo de X), e se o PC for colocado entre este limite, ele deverá ir automaticamente para a posição 0 de X, para que seja possível criar uma forma matemática para os fluxos de informação da origem até o destino.

Reunião 27/05

Neste dia foi apresentado alguns avanços no desenvolvimento do cenário de criação de topologias, entre elas o fato de, quando clicado no cabo de rede, um clone do mesmo aparece no ponteiro do mouse e nele fica até ocorrer um novo clique. Além disso, tanto para o cabo de rede como para o PC, quando ambos atingem um raio de 10 unidades das coordenadas do palco, o objeto vai automaticamente para onde ele deve ser posto, e além disso, para o PC, essa lógica só funcionará caso haja um cabo espetado no meio. Também foi apresentado uma pequena ideia de como pode ser o fluxo de informação no meio com clones.

Em seguida, foi sugerido que seja implementado um mini sistema que trafegue informações pelo meio e que fosse utilizado clones para representar cada bit (zero e um), além de haver um terceiro estado com um clone de cor diferente que represente algum dado que tenha sofrido colisão.

Reunião 03/06

Na reunião deste dia foi apresentados as novas implementações do sistema que mostre como é feita a troca de bits em um meio de comunicação, conforme descrição da reunião anterior. Nesse sistema, o usuário clica em uma das extremidades (emissor) e digita uma mensagem (binária) para que esta trafegue pelo meio até a outra extremidade (receptor). Então, a mensagem é transformada em "bolinhas" vermelhas (bit 0) ou verdes (bit 1) e viajam com sincronismo até seu destino que reconhece a chegada das "bolinhas" e as interpreta para que seja possível compreender a mensagem original.

A única coisa que a princípio não estaria funcionando é a colisão. Então, conforme discutido em reunião neste dia, deveria ser feita algumas correções no código, entre elas a substituição de 2 sprites referentes aos 2 tipos de bits por apenas 1 sprite e este realizasse clonagens e mudanças de trajes para representar o bit que se necessite. As chaves que são 2 sprites que geram e recebem os bits também devem ser clones a partir de 1 único sprite. Além também da correção de bugs que estão ocorrendo em virtude de uma lógica discutida para a utilização de uma lógica de representação de bits com colisão que foi feito uma tentativa de implementação no cenário.

Reunião 10/06

Neste dia foi apresentada algumas evoluções no projeto de comunicação através do meio entre dois dispositivos. A maior evolução em relação a semana anterior é que agora existe apenas um sprite para todos os tipos de bits e apenas um strite para a chave que representa uma interface de rede do dispositivo de comunicação. Isso foi possível graças a utilização de clones em posições desejadas para as chaves e múltiplos clones para os bits combinados com mudanças de traje que nada mais é que um único sprite podendo variar em 3 cores de acordo com aquilo que se deseje representar (bit 0, bit 1 ou bit com colisão). Também foi visto que o projeto possui uma lista que indica a mensagem que cada dispositivo deve receber.

Entretanto, foi verificado e discutido algumas funcionalidades que não estariam de acordo com um cenário real e sendo proposta a alteração da forma como estaria implementado. A mais importante mudança diz respeito ao fato de o próprio bit identificar a chave de destino quando este a encontrar, quando na verdade é a chave quem deve identificar a chegada de um bit e armazenar o valor em um buffer próprio, para cada chave, e não com um único buffer para todo o cenário como está implementado. Foi verificado também uma anormalidade em bits com colisão, onde apenas um dos bits colididos muda o traje para a cor Roxa, quando os dois deveriam mudar de cor. Além disso, a própria chave deve escutar a chegada de bits para identificar colisões e parar de transmitir por um tempo para em seguida retransmitir a sua mensagem em um tempo aleatório.

Para a próxima reunião, a meta é resolver as anomalias e os bugs ainda presentes no projeto e em seguida fazer um estudo da implicação de um novo dispositivo final no cenário e onde a entrada de um Hub ou Switch poderia facilitar as implementações de uma rede em crescimento.

Reunião 17/06

Neste dia foi apresentado algumas correções que eram necessárias para a conclusão do cenário de comunicação através do meio físico entre 2 dispositivos finais, entre elas, a correção da anormalidade de bits com colisão (cor roxa), também foi implementado um buffer de recepção para cada chave, e esta agora fica "escutando o meio" e caso verifique a chegada de um bit, preenche o buffer de recepção com o valor do bit de acordo com a cor do mesmo.

Entretanto, foi verificado outras pequenas anormalidades que facilmente podem ser corrigidas. Uma delas é que o buffer de recepção é uma lista global, e seria interessante se ela fosse uma variável local. Outro comportamento esperado é que quando há um delay oriundo do próprio Scratch, um bit da mesma origem toca em outro, originando uma "colisão" que na verdade não ocorre, isso devido ao bit estar programado para quando tocar em outro, modificar sua cor e dar origem ao bit de colisão. Ficou acertado que esse comportamento não pode ocorrer.

Foi também discutido a possibilidade de implementação de um cenário semelhante ao último, porém, com um Hub intermediando as comunicações entre até 3 dispositivos, utilizando os conceitos já discutidos e implementados no cenário anterior.

Reunião 24/06

Nessa reunião foi apresentado um esboço e algumas funcionalidades do programa de simulação de troca de bits entre dispositivos finais (PCs) utilizando um Hub para interligar cada um deles. Foi apresentado também um modelo de programação para esta topologia sem variáveis globais no Scratch, onde a comunicação entre sprites se dá por sinais. Foi verificado que o desempenho do Scratch diante de tantos sinais fica comprometida, então foi proposta uma mudança para atribuir algumas variáveis globais que somente poderiam ser utilizadas sem ferir o real funcionamento de uma rede local.

O programa ainda não consegue fazer com que o Hub replique uma mensagem a todas as demais estações, então, foi proposto que para esta semana seja concluido esta parte. O objetivo é que os 4 computadores da rede interligados por um Hub troquem bits entre si através do mesmo, e além disso, deve ser implementado um sistema que identifique origem e destino da mensagem, isso será feito através de bits que serão inseridos na mensagem.

Reunião 01/07

Não houve reunião nesta semana.

Reunião 08/07

Na reunião deste dia foi apresentado as evoluções e as dificuldades na implementação das funcionalidades da topologia de rede interligando 4 PCs através de 1 hub. Foram reduzidos alguns sinais que poderiam ser substituídos por variáveis globais que não violassem os princípios de funcionamento de uma rede como a que foi projetada. O funcionamento do cenário está correto até a hora que a mensagem (origem, destino e informação) chega ao hub e o mesmo replica a mensagem a 3 listas que representam as demais portas conectadas a ele. No entanto, há considerável dificuldade no tratamento dos clones dos bits após sua saída do hub, pois terá-se que necessariamente processar esses bits em paralelo.

Após uma análise do código foi proposto que seja utilizado de contadores temporizados para em seguida, quando o clone fosse criado, pudesse ser atribuído um ID ao clone e em seguida efetuar os comandos que se desejasse ao bit. Após finalizar esta funcionalidade, deve ser estudado uma forma diferente de se movimentar bits pelo meio, não mais com passos, mas possivelmente através das cores do meio. Além disso, deve-se, para próxima reunião, estudar uma forma de manipular o palco, para que seja possível trabalhar com palcos diferentes apenas com 1 clique de botão na tela.

Reunião 15/07

Na reunião deste dia foi apresentado a primeira versão final do software de simulação de uma topologia de rede que interliga 4 PCs através de um hub. Percebe-se que, diferente da última semana, os bits trafegam pelo meio da origem da informação até o hub, no entanto, após o hub, toda a mensagem é replicada para todas as demais estações conectadas ao hub. Quando a mensagem chega por completo ao destino, o mesmo interpreta-a e se ele for o destino (verificado através sequência de bits recebidos), o Sprite emite um alerta informando que recebeu uma mensagem. Para que houvesse sucesso nesta etapa foi utilizada a ideia proposta na semana anterior, onde foi discutido que a criação dos clones deveria ser temporizada para em seguida receber um identificador local e em seguida ser processado.

A segunda etapa da reunião foi marcada pela discussão de uma proposta diferente de representação na rede, onde os bits deixariam de existir e quem faria seu papel seria o meio, onde o mesmo deverá mudar de cor por um determinado período para representar fluxos de bits e então as chaves perceberiam estas mudanças de cor e as interpretaria como sendo os bits propriamente ditos. O principal objetivo dessa mudança seria visando a simplificação da programação do projeto para que seja possível que alunos de disciplinas de Projeto Integrador I possam reutilizá-lo.

Reunião 22/07

Neste dia foi apresentado um esboço de como deverá funcionar a simulação proposta na semana anterior, substituindo os "bits", onde o próprio meio deveria ser o encarregado de repassar a informação de uma placa de rede (chave) para a outra. Na implementação desta semana já é possível verificar este comportamento pelo menos entre 2 PCs. A mensagem é coletada, formando um "quadro" e em seguida, a chave do dispositivo que deseja repassar a informação avisa o meio que deseja transmitir e este, de acordo com o conteúdo da mensagem, varia sua cor em vermelho (bit 0) ou verde (bit 1) por 1s para cada bit.

Entretanto, como um dos objetivos desta mudança seria a simplificação do código fonte, foi levantado um problema referente a isso, pois da forma como está implementado, o simulador se utiliza de pelo menos uma variável para cada placa de rede (totalizando 8 placas) e vários testes referentes ao estado destas variáveis são realizados para que a informação seja transmitida corretamente. Então, foram levantadas a princípio duas soluções para simplificar o código, uma delas seria a utilização de um "Sprite" para cada segmento do meio de transmissão que possuir o cenário, sento assim possível o envio de sinais a cada um desses "Sprites". A segunda proposta e a com maior aceitação é a de se utilizar duas listas nas placas de rede, uma para mensagens a serem transmitidas (TX) e outra para mensagens recebidas (RX), assim, bastaria ao meio ficar esperando a ordem para o que o mesmo realize a "mudança de cores" e a propria chave quem interpretaria esta mudança.

Também foi discutido sobre a possibilidade de realizar um estudo de uma forma de utilizar dois cenários diferentes na mesma simulação, realizando apenas a mudança do palco através de um botão presente no cenário.

Reunião 19/08

Na reunião deste dia foi discutido sobre uma utilização de bibliotecas (Sprites) "meio de transmissão" que sejam genéricos para qualquer cenário, independente de posição na tela, onde a única restrição para o funcionamento seria possuir um Sprite "chave" encostado que represente que há conexão neste ponto. A mecânica de funcionamento do "meio de transmissão" deverá ser diferente de como está implementado no último cenário, devendo funcionar da seguinte maneira: a "chave" de transmissão recebe alguma informação através de alguma variável e em seguida ela mesma modifica sua cor dependendo do bit que se deseje transmitir. O "meio" deve perceber esta mudança de cor e consequentemente também mudar sua cor para a mesma da chave. A "chave" receptora perceberá a mudança de cor e automaticamente saberá que aquela é uma informação de recepção e não de transmissão. Com isso será desnecessário a utilização das variáveis "TX-A, TX-A1, TX-B, TX-B1, ...", o que tornará o Sprite "meio" mais simples. Também será necessário que exista uma interface de gerenciamento que permita a criação de um clone "meio", além de informar quando o mesmo estiver tocando na "chave", isso representa que há conexão entre ambos e permite que o resto dos testes funcionem.

Para a sequência de desenvolvimento foi discutido sobre a possibilidade de criação de uma rotina que faça a conversão de uma string em bits através da tabela ASCII e vice-versa. Isso seria feito através da definição de variáveis contendo sua representação em ASCII, sendo necessário apenas a comparação dos caracteres e em seguida a conversão.

Também foi discutido um cenário futuro que se utilize de um sistema de comunicação através de modulação por amplitude (AM) ou modulação por frequencia (FM), onde um Sprite mudaria seu tamanho ciclicamente de acordo com a informação a ser transmitida e outro Sprite perceberia esta mudança e detectaria a informação que se deseja transmitir. No entanto este cenário seria um planejamento para mais tarde, sendo prioridade a criação dos Sprites "meio" e um segundo plano o desenvolvimento do sistema de conversão em ASCII.

Reunião 04/09

Esta reunião foi marcada pela apresentação das bibliotecas "meio" e "chave". Elas foram desenvolvidas de forma genérica e simples, sendo que as instruções para o uso destas bibliotecas estão no Capítulo 2 desta página. A primeira vista o cenário funciona da maneira como foi proposta sem erros e de maneira simples.

Na segunda etapa da reunião foi debatida uma nova proposta de projeto, o de um multiplexador TDM. Para a construção do multiplexador, quatro circuitos devem ser multiplexados em um meio comum a todos e em seguida, cada circuito deve ser demultiplexado de forma que seja possível a comunicação dos 4 circuitos com outros 4 destinos distintos. Para isso, pode-se utilizar de cenários já criados, como o meio e as chaves anteriormente citados, faltaria apenas os multiplexadores.

Outra ideia de projeto foi a de um sistema de de comunicação por amplitude modulada (AM) e frequencia modulada (FM), utilizando-se para isso Sprites que mudam de cor consantemente ou aumentam seu tamanho.

--Roicenir.r 10h17min de 24 de abril de 2013 (BRT)Roicenir Girardi Rostirolla