MatrigraniCF-RelPadCE235ListEx5-ProjFinal

(1)

INSTITUTO TECNOLÓGICO DE AERONÁUTICA

RELATÓRIO PADRONIZADO LISTEX5 CE-235

PROJETO FINAL

SISTEMAS EMBARCADOS DE TEMPO REAL

VERSÂO DE:

CIRO FERNANDES MATRIGRANI

DEMAIS AUTORES:

ALEXANDRE LIMA POSSEBON RIBEIRO GUSTAVO MATUCK

JOSÉ ARMANDO BARBOSA FILHO PAULO ANDRE CARVALHO DE MELO TAYNARA ARAUJO SOARES

(2)

2011

1 INTRODUÇÂO

Este projeto final ilustra a participação do autor:

1. Na Revisão do 3º Sprint Backlog (3º SBK) e na Elaboração do 3º Sprint Development (3º SDV), indicando as principais funcionalidades desenvolvidas no seu Produto do SSG, com ênfase nas funcionalidades de integração entre os Sub-Produtos do SSG ;

2. Na atualização dos Artefatos produzidos no 3º Sprint Development do seu Grupo (Visão,Glossário, Product Back log , Releas e Back log , Sprint Back log , entre outros julgados necessários);

3. Na elaboração, no RRRT, dos Diagramas necessários produzidos pelo seu Grupo (Casos de Uso, Seqüência, Classes, Estrutura, Estados; entre outros também julgados necessários); e

4. Na elaboração de uma Apresentação Atualizada para o Cliente (contendo um 3º Resultado Intermediário de Valor), envolvendo uma documentação mínima, necessária e suficiente,descrevendo códigos-fonte gerados para o seu Sub-Produto do SSG, em C++, com ênfase nas funcionalidades de integração, concentrando as suas execuções na máquina de desenvolvimento do LAB TEC da FCMF no ITA.

1.1

Motivação

A elaboração da ListEx5 ou Projeto Final da Disciplina CE235, teve como motivação uma iniciação no processo do terceiro sprint de desenvolvimento ágil do produto SM-Central. Esta lista de exercícios, ou projeto final, propiciou colocar em prática o aprendizado no desenvolvimento ágil de projetos utilizando Scrum para equipes geograficamente distribuídas, proporcionando um know-how sobre integração dos dispositivos Smart Grids.

Um dos maiores impactos observados no desenvolvimento tradicional de projetos de sistemas embarcados de tempo real é a questão de integração entre dispositivos. A maioria dos projetos desta natureza possuem problemas de integração o qual implica na insatisfação do Cliente, perda de informações, funcionalidades implementadas que não são utilizadas, etc. Devido a este fato é que o Cliente do Smart Grids estipulou que o processo de integração deverá ser prioridade no segundo sprint de desenvolvimento do produto SM-Central.

(3)

2 PRINCIPAIS PASSOS REALIZADOS NO EXERCÍCIO

Este capítulo ilustra a participação do autor na elaboradção do projeto final, em todas as suas etapas descritas nas seções posteriores. Na seção 2.1, é mostrada a participação do autor na na Revisão do 3º Sprint Backlog (3º SBK) e na Elaboração do 3º Sprint Development (3º SDV), indicando as principais funcionalidades desenvolvidas no seu Produto do SSG, com ênfase nas funcionalidades de integração entre os Sub-Produtos do SSG; na seção 2.2, a participação na atualização dos Artefatos produzidos no 3º Sprint Development do seu Grupo (Visão,Glossário, Product Backlog , Releas e Backlog , Sprint Backlog , entre outros julgados necessários); na seção 2.3, na elaboração, no RRRT, dos Diagramas necessários produzidos pelo seu Grupo (Casos de Uso, Seqüência, Classes, Estrutura, Estados; entre outros também julgados necessários); e, por fim, na seção 2.4, na elaboração de uma Apresentação Atualizada para o Cliente (contendo um 3º Resultado Intermediário de Valor), envolvendo uma documentação mínima, necessária e suficiente,descrevendo códigos-fonte gerados para o seu Sub-Produto do SSG, em C++, com ênfase nas funcionalidades de integração, concentrando as suas execuções na máquina de desenvolvimento do LAB TEC da FCMF no ITA.

2.1

Participação na Revisão do 3º Sprint Backlog (3º SBK) e na

Elaboração do 3º Sprint Development (3º SDV), indicando as

principais funcionalidades desenvolvidas no seu Produto do SSG,

com ênfase nas funcionalidades de integração entre os

Sub-Produtos do SSG;

O Sprint Backlog Três foi elaborado priorizando as funcionalidades do SM-CEN inseridas dentro do contexto do cenário pedido no item 1.2, os demais itens foram adiados para o sprint 4 visando uma maior entrega de valor no produto ao cliente final. Abaixo segue o script do projeto final direcionado ao SM-CEN:

 SM-CEN:

o Conferência entre os valores armazenados localmente e valores registrados em cada Smart Meter. Resultado esperado: valores idênticos; e

o Identificação de possível roubo de energia, através da comparação entre energia consumida pela rede e energia registrada pelos smart meters da rede. Cenário previsto: roubo de energia na rede gerenciada por SM-RED1.

Resultado esperado: identificação, por parte de SM-RED1, de possível roubo de energia.

(4)

2.1.1 REVISÃO DO 3º SPRINT BACKLOG (3º SBK);

Foram definidas 6 Users Stories principais priorizando o cenário para o projeto final descrito no item 1.2 deste documento.

São elas:

1. Solicita medição local em outro SM.

2. Compara valor armazenado localmente no Central com o valor armazenado remotamente no SM.

3. Receber pedido de energia. 4. Armazenar pedido de energia. 5. Enviar pacote de energia.

6. Comparar medição com valor de energia enviado.

2.1.2 DEMONSTRAÇÃO DOS SPRINTS DEVELOPMENTS EXECUTADOS DURANTE O PROJETO.

Os sprints 1, 2 e 3 foram priorizados segundo o que mais oferecia de valor para o cliente segundo às adaptações às necessidades emergenciais como mostra a tabela, abaixo:

1 User Stories Sprint BackLog 1 – Principal Valor: Funcionalidades Principais 2 User Stories Sprint BackLog 2 – Principal Valor: Integração

3 User Stories Sprint BackLog 3 – Principal Valor: Cenário do projeto final descrito no item 1.2 deste documento

Abaixo os possíveis sprints 4 e 5, com os itens faltantes, resultantes da priorização.

4 User Stories Sprint BackLog 4 5 User Stories Sprint BackLog 5

A seguir as User stories pertencentes a cadas sprint:

Item Responsável Estimativa

1 Desenvolvimento da Unidade de Processamento Central

(UPC) Gustavo 20

2 Recebimento Medições dos SM Alexandre 20

3 Armazenamento de Medições Armando 13

4 Atribuição de ID de SM Ciro 13

(5)

12 Atualização de tabela de tarifas Paulo 13 13 Stub de conexão com o SM-Rede (INTEGRAÇÃO) Todos 13 14 Stub de desacoplamento de conexões (INTEGRAÇÃO) Todos 13 15 Determinação da quantidade de energia a ser enviada Alexandre 13 34 Solicitar medição local em Smart Meter remoto Paulo 13 35 Comparar valor armazenado localmente no SM-CEN com o

valor armazenado no SM remoto Taynara 13

36 Receber pedido de energia Armando 13

37 Armazenar log do envio de energia Gustavo 8

31 Detecção de fraudes de energia Ciro 8

17 Bloqueio de recebimento de energia de forma remota Armando 8 18 Habilitação de recebimento de energia de forma remota Ciro 8

19 Criação de lista de conexões Gustavo 8

20 Atualização da lista de conexões Paulo 8

21 Implementação de sistema de backup Taynara 8 16 Determinação da quantidade de energia a ser recebida Alexandre 5 22 Restauração para as configurações originais Alexandre 5

24 Monitoramento da voltagem da rede Ciro 5

25 Configuração de cadastro de configurações do sistema Gustavo 5 26 Configuração de remoção de configurações do sistema Paulo 5 27 Configuração de edição de configurações do sistema Taynara 5 28 Configuração de procura de configurações do sistema Alexandre 3 29 Configuração de autenticação de configurações do sistema Armando 3

30 Emissão de relatórios Ciro 5

32 Detecção de roubo de energia Paulo 5

33 Implementação do sistema de criptografia Taynara 3 23 Monitoramento da integridade da rede Armando 3

(6)

2.1.3 REVISÃO DO 3º SPRINT DEVELOPMENT (3º SDV);

O 3º sprint de desenvolvimento teve que ser reestruturado devido à do atendimento ao cenário descrito na seção 1.2 deste documento, como cenário principal do projeto final, para avaliação da integração entre os dispositivos Smart Meters. Esta necessidade não foi totalmente esclarecida durante o processo de planejamento no 1º bimestre junto ao Cliente e, portanto, não foi detalhada como necessidade para o primeiro e segundo sprint de desenvolvimento.

O planejamento inicial da equipe de desenvolvimento para o produto SM-Central levou em consideração o processo de integração com os demais Smart Meteres de acordo com o cenário do projeto final e adaptou a prioridade das user stories cascateando-as para um quarto e quinto sprint de desenvolvimento. Diante de uma nova informação, definida pelo Cliente após o término do segundo sprint de desenvolvimento o qual o processo de integração de acordo com o cenário definido deverá ser prioridade para o terceiro sprint, diversas alterações estratégicas tiveram que ser realizadas (escopo, prioridades, prazos, funcionalidades, etc.).

2.2

Participação na atualização dos Artefatos produzidos no 3º Sprint

Development do seu Grupo (Visão,Glossário, Product Back log ,

Releas e Back log , Sprint Back log , entre outros julgados

necessários).

Os artefatos descritos abaixo foram atualizados de acordo com o status atual de desenvolvimento do dispositivo SM-Central pela equipe CES-63/CE-235:

• Documento VISÃO;

O Documento VISÃO pode ser visto em:

https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/projeto/%28ArtefatoVIS%C3%83O-SM-CENTRAL5.0%29.pdf?attredirects=0&d=1

(7)

• Documento GLOSSÁRIO;

O Documento GLOSSÁRIO pode ser visto em:

(8)

• Documento PRODUCT BACKLOG (PBK); O Documento PRODUCT BACKLOG pode ser visto em:

https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/projeto/ArtefatoPBK-SM-CENTRAL5.0.pdf?attredirects=0&d=1

(9)

• Documento RELEASE BACKLOG (RBK); O Documento RELEASE BACKLOG pode ser visto em:

https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/projeto/ArtefatoRBK-SM-CENTRAL5.0.pdf?attredirects=0&d=1

(10)

• Documento SPRINT BACKLOG (SBK). O Documento SPRINT BACKLOG 2 pode ser visto em:

https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/projeto/ArtefatoSBK3-SM-CENTRAL1.0.pdf?attredirects=0&d=1

(11)

2.2.1 Gráfico BurnDownChart;

Através de uma comunicação ágil com a equipe CE-230 buscou-se aferir qualidade e confiabilidade de software para o SM-Central para o sprint 3 de desenvolvimento, através do gráfico burndown chart (figura 8). Conforme observado na figura, todo o processo de desenvolvimento ocorreu conforme planejado. A interação com a equipe CE-230 foi crucial para que o prazo fosse cumprido e que todas as funcionalidades fossem atendidas e que agregassem valor imediato ao Cliente.

Uma vez que a equipe de desenvolvimento é formada por integrantes distribuídos geograficamente, somente foi possível realizar poucas reuniões de desenvolvimento. Observado o gráfico burndown chart é possível observar que, devido a este fato, sempre o trabalho realizado está acima do esforço planejado.

2.3

Participação na elaboração, no RRRT, dos Diagramas necessários

produzidos pelo seu Grupo (Casos de Uso, Seqüência, Classes,

Estrutura, Estados; entre outros também julgados necessários).

A reestruturação do dispositivo SM-Central definida como prioridade pela equipe de desenvolvimento não alterou a configuração interna do SM-Central conforme definido previamente. A figura 1 ilustra esta visão interna do dispositivo SM-Central.

(12)

Figura 1 – Visão interna do SM-Central

A figura 2 a seguir ilustra os módulos desenvolvidos dentro do SM-Central.

Figura 2 – Estrutura do SM Central

Já a figura 3 ilustra as portas de comunicação da Unidade de Processamento Central (UPC), que integra todos os módulos funcionais dentro do dispositivo SM-Central.

(13)

Figura 3 –Estrutura da Unidade de Processamento Central

A figura 4 ilustra a Unidade de Processamento Central que interliga todas as funcionalidades do dispositivo SM-Central e controle com eficiência e eficácia.

Figura 4 –Estados da Unidade de Processamento Central

A figura 5 ilustra o processo computacional de integração do Central com o SM-Rede. É possível observar que caso o Cliente necessite a implantação do Smart Grids em computadores diferentes, basta somente trocar as duas unidades de integração entre os Smart Meters.

(14)

A figura 6 ilustra o processo de implementação envio e recebimento de alertas do SM-Central.

Figura 6 –Envio e Recebimento de Alertas

(15)

O projeto e seus diagramas podem ser baixados em:

https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/projeto/SMCENTRAL_v3.0.rar?attredirects=0&d=1

(16)

2.3.1 Alterações no modelo para o cenário do Projeto Final.

Esta subseção descreve os passos realizados para a aferição das funcionalidades exigidas no cenário proposto para a listex 5, projeto final, descrita no item 1.2 deste documento, pertinentes ao SM-CENTRAL. Abaixo os requisitos exigidos no cenário. Esta subseção descreve os novos diagramas para o cenário final, A subseção 2.3.2 explica o que deve ser implementado para as novas funcionalidades e a subseção 2.3.3 descreve detalhadamente as alterações que devem ser feitas no modelo atual para compreenção das novas funcionalidades do cenário do Projeto Final.



SM-CEN:

o Identificação de possível roubo de energia, através da comparação entre energia consumida pela rede e energia registrada pelos smart meters da rede. Cenário previsto: roubo de energia na rede gerenciada por SM-RED1. Resultado esperado: identificação, por parte de SM-RED1, de possível roubo de energia.

A partir do contexto citado acima, o sprint development 3 deste projeto (3º SDV) priorizou as funcionalidades de mais valia ao cliente que atendessem aos requisitos exigidos na nova realidade. A metodologia de desenvolvimento ágil se provou adequada a esta realidade por seu auto grau de adaptação a alterações das necessidades do cliente.

A seguir são listados todos os 6 requisitos identificados como maior valor de negócio para o Cliente neste terceiro sprint development:

1. (15) Determinação da quantidade de energia a ser enviada;

2. (34) Solicitar medição local em Smart Meter remoto;

3. (35) Comparar valor armazenado localmente no SM-CEN com o valor armazenado no SM remoto;

4. (36) Receber pedido de energia;

5. (37) Armazenar log do envio de energia;

(17)

Figura 8 –Estrutura SM CEN cenário final

(18)

Figura 11 –Capsula controle de Energia cenário final

Figura 12 –Comportamento Capsula SM CENTRAL

2.3.2 Implementação dos itens para atendimento das funcionalidades exigidas no cenário final do projeto descrito no item 1.2.

As subseções de 2.3.2.1 à 2.3.2.5 descrevem as novas funcionalidades US 15, 35, 36, 37 e 31 respectivamente.

2.3.2.1 User Story 15 – Determinação da quantidade de energia a ser enviada

(19)

Detalhes: O cálculo da energia enviada inicial dependerá do histórico de consumo do Smart Meter e os envios seguintes dependerão do monitoramento contínuo do Smart Meter. Dessa forma, será necessário ficar acompanhando o funcionamento do Smart Meter, em todos os momentos.

Teste de Aceitação: Esta User Story tem alta prioridade. Para testar isso,

será emitido um valor inicial de teste ao Smart Meter. Em seguida, simular-se-á duas situações: um aumento e uma diminuição desse valor. Por último, desconectar-se-á e reconectar-se-á o Smart Meter.

Implementação: Esta user story será implementada seguindo o mesmo padrão do envio e recebimento de medições, será criada mais uma capsula que gerenciará a autorização de envio e recebimento de energia, o SM Remoto poderá solicitar o envio de energia por meio do envio de uma mensagem no padrão do message protocol: Type: “solicitarEnergia Text: “Quantidade de Energia Solicitada”. O sistema poderá enviar uma autorização de envio baseando-se em critérios (que podem ser definidos posteriormente) como quantidade máxima de energia autorizada, ou aguardar a solicitação de um doador com o mesmo valor, e enfim enviar uma autorização a ambos, doador e receptor.

2.3.2.2 User Story 34 – Solicitar medição local em Smart Meter remoto

O sistema deve, em uma frequência pré-determinada, enviar uma solicitação para cada Smart Meter para que este responda com as medições armazenadas localmente no mesmo.

Esforço Estimado: A User Story Solicitar medição local em Smart Meter

remoto foi estimada em 8 Story Points (SP);

Detalhes: Essa User Story visa somente manter a integridade da

informação na rede. Pois se o conjunto de todos os aparelhos e a rede fossem confiáveis, a confirmação de que a informações enviada e recebida são iguais seria redundante.

Teste de Aceitação: Esta User Story tem alta prioridade. A aceitação dela

se dará quando o usuário puder ativar o envio de mensagem de solicitação de medições armazenadas e esta mensagem chegar ao seu destino (nos casos de teste de desenvolvimento, o Stub do SM-RED).

Implementação: Esta user story será implementada exatamente como na funcionalidade de recebimento de medições, mas ao invés disso irá requerer o log de medições do SM Remoto. Por meio de uma interface do SM-CEM, o controlador do SM-CEN poderá emitir um sinal, no padrão do Message Protocol: Origem, Destino, Type, Text, com o texto “solicitarMedicao” (tal qual a funcionalidade recebimento de medições). O SM-Remoto deverá responder com os dados da medição armazenada (tal qual a resposta do recebimento de

(20)

Todos os SM remotos devem estar preparados para, assim que receber uma mensagem de solicitação de medições armazenadas, enviar como resposta uma mensagem contendo as medições armazenadas localmente. Ao receber essa mensagem. o sistema deve comparar o valor recebido com os valores armazenados localmente e, em caso de disparidade, atualizar a lista armazenada localmente e emitir uma notificação ao administrador do sistema mostrando essa diferença.

Esforço Estimado: A User Story Solicitar medição local em Smart Meter

remoto foi estimada em 13 Story Points (SP).

Detalhes: Essa User Story visa somente manter a integridade da

informação na rede. Pois se o conjunto de todos os aparelhos e a rede fossem confiáveis, a confirmação de que a informações enviada e recebida são iguais seria redundante.

Teste de Aceitação: Esta User Story tem alta prioridade. A aceitação desta

se dará quando o sistema, ao receber uma mensagem de resposta à solicitação de medições armazenadas com medições diferentes das armazenadas localmente, conseguir atualizar as medições armazenadas localmente e notificar o administrador da rede sobre a disparidade.

Implementação: Para implementação desta user story, é planejado, por meio da soma dos valores anteriormente armazenados para determinado SM remoto, verificar se a soma dos dados do smart meter em questão foram todas reportadas para o smart meter central. O armazenamento de medições já conta com uma tabela de medições armazenadas hoje. O que se faria seria alterar esta user story para que além dos dados de medição propriament ditos, este também armazenasse a origem dos dados. Por meio da user story do item 2.3.1.3, será possível resgatar as medições de um determinado smart meter, e nesta será possível comparar com as medições já existentes.

2.3.2.4 User Story 36 – Receber pedido de energia

O sistema deve estar preparado para receber uma mensagem de pedido de energia.

Detalhes: Todos os SM remotos, ao detectar uma falta de energia presente

ou futura, devem enviar uma mensagem de pedido de energia para o SM-CEN contendo a quantidade sendo solicitada e este, ao receber esta mensagem deve enviar a quantidade exata de energia requisitada para o SM que realizou a solicitação.

(21)

Implementação: Esta user story será implementada em conjunto com a US 15 “Determinação da quantidade de energia a ser enviada “ descrita no ite. 2.3.1.1. seguindo o mesmo padrão do envio e recebimento de medições, será criada mais uma capsula que gerenciará a autorização de envio e recebimento de energia que aguardará um sinal do SM Remoto no padrão do message protocol: Type: “solicitarEnergia, Text: “Quantidade de Energia Solicitada”. O sistema poderá enviar uma autorização de envio baseando-se em critérios (que podem ser definidos posteriormente) como quantidade máxima de energia autorizada, ou aguardar a solicitação de um doador com o mesmo valor, e enfim enviar uma autorização a ambos, doador e receptor.

2.3.2.5 User Story 37 – Armazenar log do envio de energia

O sistema deve, ao enviar uma quantidade qualquer de energia, ser capaz de armazenar em um arquivo de log esta ação para futura consulta de fraude.

Detalhes: A informação do envio será armazenada em um arquivo de texto

contendo os seguintes parâmetros separados por vírgula.

Timestamp – ID do SM que recebeu energia – Quantidade de energia

Teste de Aceitação: Esta User Story tem alta prioridade. A aceitação dela

se dará no momento em que toda a ação de envio de energia estiver sendo devidamente “logada” em um arquivo texto satisfazendo a especificações acima.

Implementação: Após a implementação das US 15 e 37 descritas respectivamente nos itens 2.3.1.1. e 2.3.1.4, a cada resultado de autorização ou discordância de cada pedido e envio de energia, o sistema armazenará esta informação em um log tal qual o envio e recebimento de medições.

2.3.2.6 User Story 31 – Detecção de fraudes de energia

O sistema deve identificar fluxos incorretos de energia, a partir do monitoramento das requisições, que devem registrar a quantidade de transferência de energia devidamente validada.

Esforço Estimado: A User Story Detecção de fraudes de energia foi

estimada em 13 Story Points (SP).

(22)

Implementação: Esta user story será implementada podem bater a soma dos dados das medições de um determinado SM Remoto com as autorizações de envio e recebimento de energia que serão implementadas nos itens das US 15 e 37. Quaisquer discordâncias das informações, o sistema pode enviar uma alerta de fraude.

2.3.3 Implementação dos diagramas para atendimento das funcionalidades exigidas no cenário final do projeto descrito no item 1.2.

Para o funcionamento do SM CENTRAL segundo o cenário do projeto final, serão desenvolvidos e implementados os seguintes diagramas.

 User Story 15 – Determinação da quantidade de energia a ser enviada

 User Story 36 – Receber pedido de energia

 User Story 37 – Armazenar log do envio de energia

Para as user story 15, 36 e 37 será criada uma capsula de controle e de energia que como descrito acima, controlará o recebimento, determinação da quantidade de energia a ser enviada e armazenamento dos envios.

Figura 13 –Alterações no diagrama de estrutura do SM CENTRAL para US 15, 36 e 37.

User Story 36 – Receber Pedido de Energia

User Story 15 – Determinação da quantidade de energia a ser enviada

User Story 36 – Receber Pedido de Energia

(23)

Figura 15 – Estados UPC para US 15, 36 e 37

Figura 16 – Comportamento da Capsula Energia

 User Story 31 – Detecção de fraudes de energia

 User Story 35 – Comparar valor armazenado localmente no SM-CEN com o valor armazenado no SM remoto

Para as user story 31 e 35 será criado uma comportamento diretamente na capsula SM CENTRAL, baseado no wrm-up 4, esta exibira uma interface esperando um comando (como no

User Story 15 – Determinação da quantidade de energia a ser enviada

User Story 37 – Armazenar log do envio de energia

User Story 36 – Receber Pedido de Energia

(24)

Varias outras rotinas podem ser adicionadas posteriormente, mas as primeiras seriam a de requisição de medições a um SM Remoto. a de detecção de fraudes, que basicamente comparariam os arquivos armazenados de medição e envio de autorização para aquisição de energia.

Figura 17 –Comportamento Capsula SM CENTRAL para US 31 e 35.

Figura 18 –Interface SM CENTRAL para US 31 e 35.

User Story 31 – Detecção de fraudes de energia

User Story 35 – Comparar valor armazenado localmente no SM-CEN com o valor armazenado no

(25)

Figura 19 –Interface SM CENTRAL para US 35.

Figura 20 –Interface SM CENTRAL para US 31.

2.4

Participação na elaboração de uma Apresentação Atualizada para

o Cliente (contendo um 3º Resultado Intermediário de Valor),

envolvendo uma documentação mínima, necessária e

suficiente,descrevendo códigos-fonte gerados para o seu

Sub-Produto do SSG, em C++, com ênfase nas funcionalidades de

integração, concentrando as suas execuções na máquina de

desenvolvimento do LAB TEC da FCMF no ITA.

A Apresentação foi elaborada para explicar o TODO, ou o que vai ser feito para o atendimento das funcionalidades descritas no cenário do projeto final. A interface de integração continua utilizando as práticas de stubs, e o SM Central já foi desenvolvido no Ambiente de desenvolvimento do SM Rede.

Abaixo o link para a apresentação:

A apresentação pode ser vista em:

https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/projeto/SmartMeterCentral-ProjFinal.pptx?attredirects=0&d=1

(26)

3 CONCLUSÕES, RECOMENDAÇÔES E SUGESTÔES.

Segundo às p´raticas comuns da implementação ágil , trabalha-se em cima de escopo aberto para a implementação, que se adapta segundo as prioridades voláteis dos clientes. Diante do cenário ilustrado no projeto final, a equipe de desenvolvimento focou no desenvolvimento do SM-Central na resolução das necessidades apresentadas. Mesmo assim todas as funcionalidades propostas para o primeiro e segundo sprint de desenvolvimento foram implementadas corretamente proporcionando o máximo de valor agregado ao Cliente.

A motivação para que a equipe pudesse realizar o terceiro sprint de desenvolvimento foi de absorver um know-how dos processos que norteiam a questão de integração entre os dispositivos direcionadas ao cenário do projeto final. Como resultado foi possível observar um empenho maior para que as funcionalidades fossem implementadas corretamente conforme acordado com o Cliente.

A comunicação com a equipe CE-230 foi de suma importância para aferir qualidade, confiabilidade e segurança (safety) para este dispositivo, permitindo uma maior visibilidade durante o andamento do processo de desenvolvimento (sprint). Já a comunicação com a equipe CE-237 foi importante para mostrar à equipe de desenvolvimento (CES-63/CE-235) análises de teste e métricas importantes para potenciais de melhoria no processo de implementação dentro da ferramenta do Rational Rose Real Time e pontos críticos a serem levados em consideração.

(27)

ANEXO

LISTEX 5 - 3

O

_{SPRINT DEVELOPMENT (3º SDV)}

PRÉVIA (PROVA DE CONCEITO) DO PROJETO FINAL

Baseando-se na idéia do Jogo SimCity, o Projeto Final das Disciplinas acima deverá obedecer aos seguintes Requisitos:

1. Haverá uma cidade fictícia denominada Smart Grids City;

2. O fornecimento de energia para esta cidade será realizado, inicialmente, pela Concessionária XPTO;

3. Um novo modelo de distribuição de energia foi implementado, seguindo as características das tecnologias de Smart Grids, gerenciado pela companhia Smart Grid XPTO;

4. A coleta das informações referentes ao consumo de energia passará a ser realizada usando-se medidores inteligentes (Smart Meters), com capacidade de aferir o consumo e a oferta de energia em intervalos programáveis, envolvendo Atores de uma malha energética;

5. O sistema permitirá que se avalie a oferta/utilização excedente de energia, tanto da concessionária, quanto de outras fontes de energia (de consumidores).

(Dados Fictícios -> Manchete de primeira página do Jornal Elétrico Diário de 24/10/2011):

Uma Idéia Brilhante

Foi com grande orgulho que o prefeito de Smart Grids City, Tom Edison, anunciou esta manhã, para uma platéia de centenas de pessoas, seu mais novo projeto revolucionário. O projeto, batizado de Falta de Energia Zero, prevê a implantação até o final de 2012 de uma rede de gerenciamento inteligente de energia (smart grid) em todo o perímetro urbano, visando, entre outras coisas, resolver os cada vez mais comuns problemas de abastecimento de energia elétrica que tem assolado nossa bela cidade nesses últimos anos.

A implantação ficará a cargo da famosa companhia de energia Lamp S.A. e, segundo seu representante, All Adin, o sistema a ser utilizado já se encontra num estágio avançado de

(28)

Teste Piloto

Para a verificação da eficiência do sistema desenvolvido serão instalados medidores inteligentes (smart meters), em área a ser definida, respeitando a seguinte distribuição:

 1 smart meter central, doravante referenciado como SM-CEN;

 2 smart meters de rede, doravante referenciados como SM-RED1 e SM-RED2;

 2 smart meters residenciais, doravante referenciados como RES1 e RES2. SM-RES1 estará conectado a SM-RED1 e SM-RES2 estará conectado a SM-RED2. Ambas as residências deverão possuir ampla quantidade de produtos eletrônicos compatíveis com o modelo de smart meter utilizado;

 2 smart meters industriais, doravante referenciados SM-IND1 e SM-IND2. Ambos estarão instalados na mesma indústria. SM-IND2 estará conectado a SM-IND1, que por sua vez estará conectado a SM-RED2;

 2 smart meter de ponto de venda de energia, doravante referenciados como SM-PVE1 e SM-PVE2. Ambos estarão conectados a SM-RED1; e

 2 smart meter móveis, doravante referenciados SM-MOV1 e SM-MOV2.

Os testes abaixo serão executados durante o teste piloto e representam as funcionalidades mínimas necessárias para o início da implantação.

 SM-CEN:

o Identificação de possível roubo de energia, através da comparação entre energia consumida pela rede e energia registrada pelos smart meters da rede. Cenário previsto: roubo de energia na rede gerenciada por SM-RED1.

Resultado esperado: identificação, por parte de SM-RED1, de possível roubo de energia.

 SM-RED:

o Identificação de falhas no fornecimento. Cenário previsto: desconexão individual de cada um dos Smart Meters envolvidos no test. Resultado

(29)

 SM-RES:

o Exibição de relatório de consumo mensal. Resultado esperado: correta

apresentação de todo o consumo do mês corrente com granularidade horária; e

o Operação de emergência durante falha de fornecimento de energia. Cenário previsto: corte temporário de energia em SM-RED2. Resultado esperado: registro do período de ocorrência da falha e execução de procedimentos para evitar perda e/ou corrupção de dados quando do término da bateria de emergência do smart meter.

 SM-IND:

o Envio conjunto de informações. Resultado esperado: SM-IND1 envia o consumo conjunto de SM-IND1 e SM-IND2; e

o Exibição de relatório de energia excedente gerada pelos geradores da empresa. Resultado esperado: correta apresentação da quantidade de energia

excedente gerada pelos geradores da empresa.

 SM-PVE:

o Venda de energia concorrente. Cenário previsto: abastecimento de SM-MOV1 e SM-MOV2 de forma simultânea em SM-PVE1. Resultado esperado: registro correto da quantidade de energia vendida e envio de informação a SM-CEN; e o Registro de consumo do ponto de venda de energia. Resultado esperado:

correto registro do consumo de energia dos pontos de venda onde SM-PVE1 e SM-PVE2 estão instalados e envio de informação a SM-CEN.

 SM-MOV:

o Operação solo. Resultado esperado: correta operação sem qualquer conexão com outros smart meters; e

o Abastecimento em diferentes pontos de venda de energia. Cenário previsto: abastecimento de SM-MOV1 não-simultâneo em SM-PVE1 e SM-PVE2. Resultado esperado: correto registro da energia adquirida e envio de informações para SM-CEN em ambos os abastecimentos.