INSTITUTO TECNOLÓGICO DE AERONÁUTICA
TODO SM CENTRAL
RELATÓRIO DE DEFINIÇÃO DA ARQUITETURA DO SM CENTRAL PARA O 3º SPRINT DEVELOPMENT
PROJETO FINAL SM CENTRAL
SISTEMAS EMBARCADOS DE TEMPO REAL
CIRO FERNANDES MATRIGRANI
DEMAIS AUTORES:ALEXANDRE LIMA POSSEBON RIBEIRO GUSTAVO MATUCK
JOSÉ ARMANDO BARBOSA FILHO PAULO ANDRE CARVALHO DE MELO TAYNARA ARAUJO SOARES
PROFESSORES: ADILSON CUNHA E VIEIRA DIAS
SÃO JOSÉ DOS CAMPOS 2011
1
INTRODUÇÂO
Este documento ilustra o que deve ser feito no projeto SM CENTRAL para compreensão das funcionalidades mínimas necessárias e suficientes para alcançar os objetivos descritos no cenário proposto para o projeto final da disciplina CE235 descrito na seção a seguir. O Capítulo dois mostra a arquitetura proposta no 3º sprint development para ser implementada.
1.1
Cenário
2
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.1 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 seção 2.1 explica o que deve ser implementado para as novas funcionalidades e a seção 2.2 descreve detalhadamente as alterações que devem ser feitas no modelo atual para compreensão das novas funcionalidades do cenário do Projeto Final.
•
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.
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;
6. (31) Detecção de fraudes de energia.
A seguir são listados o resultante das alterações efetuadas nos diagramas da versão atual do SM CENTRAL para compreensão de todos os 6 requisitos identificados como maior valor de negócio para o Cliente neste terceiro sprint development. As Figuras 8 e 12 mostram as alterações na capsula SM CENTRAL para implementação das USs 35 e 31, as Figuras 9 e 10 mostram as alterações na Unidade de Processamento Central decorrentes das novas funcionalidades e a Figura 11 mostra o comportamento a ser inserido na nova capsula Energia que será inserida para a compreensão das US 15, 36 e 37 (descrita posteriormente).
Figura 1 –Estrutura SM CEN cenário final
Figura 2 –Estrutura UPC cenário final
Figura 4 –Capsula controle de Energia cenário final
Figura 5 –Comportamento Capsula SM CENTRAL
2.1
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.1.1 à 2.1.5 descrevem as novas funcionalidades US 15, 35, 36, 37 e 31 respectivamente.
2.1.1 User Story 15 – Determinação da quantidade de energia a ser enviada
O sistema deve calcular a quantidade de energia que deve ser enviada a partir da primeira requisição de um Smart Meter. Além disso, o sistema deve fazer verificações periódicas para saber se deve enviar um valor diferente do anterior.
Esforço Estimado: A User Story Determina quantidade de energia a ser enviada foi estimada em 8 Story Points (SP).
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.1.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 medições).
2.1.3 User Story 35 – Comparar valor armazenado localmente no SM-CEN com o valor armazenado no SM remoto
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.1.4 User Story 36 – Receber pedido de energia
O sistema deve estar preparado para receber uma mensagem de pedido de energia.
Esforço Estimado: A User Story Solicitar medição local em Smart Meter remoto foi estimada em 13 Story Points (SP).
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.
Teste de Aceitação: Esta User Story tem alta prioridade. A aceitação desta se dará quando o sistema conseguir, ao receber uma mensagem de pedido de energia, enviar a quantidade de energia correta e para o smart meter que realizou a solicitação. A entidade energia será representada para fins de teste por um stub em forma de mensagem de text contendo a quantidade de energia enviada.
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.1.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.
Esforço Estimado: A User Story Solicitar medição local em Smart Meter remoto foi estimada em 8 Story Points (SP).
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.1.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).
Detalhes: Um exemplo de como seria esse monitoramento de requisições seria o seguinte: Um Smart Meter está vendendo certa quantidade de energia a outro Smart Meter. Nesse caso, a quantidade de energia vendida pelo primeiro Smart Meter tem que ser igual à quantidade de energia comprada pelo outro Smart Meter.
Teste de Aceitação: Esta User Story tem baixa prioridade. Por isso, não será especificado teste de aceitação para ela nesta fase do projeto.
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.2
Implementação dos diagramas para atendimento das
funcionalidades exigidas no cenário final do projeto descrito no
item 1.1.
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 7 –Alterações no diagrama de Estrutura UPC para US 15, 36 e 37
Figura 8 – Estados UPC para US 15, 36 e 37
• 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 eletronic Lock). Este comando poderá direcionar a uma determinada rotina.
Este comportamento entraria em um estado “esperandoComando” qua aguardaria a entrada de um comando, assim como no warm-up 4, uma transição question mostraria as opções de comando da interface do SM CENTRAL. A inserção de um comando dispara uma outra transição que executa um determinado código e retorna para o estado inicial aguardando o próximo comando.
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 10 –Comportamento Capsula SM CENTRAL para US 31 e 35.
Figura 11 –Interface SM CENTRAL para US 31 e 35.
ANEXO
LISTEX 5 - 3
OSPRINT 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 desenvolvimento.
O jornal Elétrico Diário também recebeu, com exclusividade, o planejamento completo do teste piloto a ser realizado no final do mês de Novembro. Os detalhes encontram-se especificados abaixo e demonstram diversas das funcionalidades que podem ser esperadas desse inovador sistema.
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 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.
•
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
esperado: geração de alerta cada vez que algum smart meter, com exceção de SM-MOV, for desconectado da rede em um prazo de, no máximo, 10 minutos; e
o Operação de emergência durante falha de comunicação com SM-CEN. Cenário previsto: corte temporário de comunicação entre SM-RED2 e SM-CEN.
Resultado esperado: envio de todos os registros do período quando a comunicação for restabelecida.
•
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.
