ArtefatoPBK-SM-CENTRAL5.0

(1)

CE 235 - Sistemas Embarcados de Tempo Real Página 1

Smart Meter Central

Product Backlog

Versão <5.0>

Outubro de 2011 ITA/CTA - São José dos Campos

(2)

HISTÓRICO DA REVISÃO

Data Versão Descrição Autores

10/08/2011 a 22/08/2011 1.0 Preenchimento do Documento Visão de maneira compartilhada

Equipe SM-CENTRAL via Google Docs

22/08/2011 1.0

Conclusão desta versão deste Documento Visão de maneira

compartilhada.

Alexandre Possebon

22/08/2011 1.0

compartilhada

Gustavo Matuck

22/08/2011 1.0

compartilhada

Ciro Matrigrani

22/08/2011 1.0

compartilhada

José Armando Barbosa Filho

22/08/2011 1.0

compartilhada

Taynara Araujo Soares

22/08/2011 1.0

compartilhada

Paulo Andre Carvalho de Melo 27/09/2011 2.0 Atualização desta versão deste Documento de maneira compartilhada

Equipe SM-CENTRAL via Google Docs 13/10/2011 – 16/10/2011 3.0 Atualização desta versão deste Documento de maneira compartilhada

Equipe SM-CENTRAL via Google Docs 17/10/2011 – 31/10/2011 4.0 Atualização desta versão deste Documento de maneira compartilhada

Equipe SM-CENTRAL via Google Docs

(3)

SUMÁRIO

1 INTRODUÇÃO ... 5

2 USER STORIES ... 5

2.1 User Story 1 – Desenvolvimento da Unidade de Processamento Central (UPC) ... 6

2.2 User Story 2 – Recebimento de medições de Smart Meters ... 7

2.3 User Story 3 – Armazenamento de medições ... 7

2.4 User Story 4 – Atribuição de ID ao Smart Meter ... 8

2.5 User Story 5 – Recebimento de Alertas ... 9

2.6 User Story 6 – Envio de Alertas ... 9

2.7 User Story 7 – Envia programação/dados ao Smart Meter ... 10

2.8 User Story 8 – Armazenamento de Alertas ... 11

2.9 User Story 9 – Recebimento de coordenadas de localização do Smart Meter ... 11

2.10 User Story 10 – Implementação do Sistema de Recuperação ... 12

2.11 User Story 11 – Recebimento de tabela de tarifas ... 13

2.12 User Story 12 – Atualização de tabela de tarifas ... 13

2.13 User Story 13 – Stub de Conexão com o SM-Rede (Integração) ... 14

2.14 User Story 14 – Stub de Desacoplamento de Conexões (Integração) ... 15

2.15 User Story 15 – Determina quantidade de energia a ser enviada ... 16

2.16 User Story 16 – Determina quantidade de energia a ser recebida ... 16

2.17 User Story 17 – Bloqueio de recebimento de energia de forma remota ... 17

2.18 User Story 18 – Habilitação de recebimento de energia de forma remota ... 18

2.19 User Story 19 – Criação da lista de conexões ... 19

2.20 User Story 20 – Atualização da lista de conexões ... 19

2.21 User Story 21 – Implementação do Sistema de Backup ... 20

2.22 User Story 22 – Restauração para as configurações originais ... 21

2.23 User Story 23 – Monitoramento da integridade da rede ... 21

2.24 User Story 24 – Monitoramento da voltagem da rede ... 22

2.25 User Story 25 – Configuração de cadastro de configuração do sistema (funcionalidade do administrador) ... 23

2.26 User Story 26 – Configuração de remoção de configuração do sistema (funcionalidade do administrador) ... 23

(4)

CE 235 - Sistemas Embarcados de Tempo Real Página 4 2.27 User Story 27 – Configuração de edição de configuração do sistema (funcionalidade do

administrador) ... 24

2.28 User Story 28 – Configuração de procura de configuração do sistema (funcionalidade do administrador) ... 25

2.29 User Story 29 – Configuração de autenticação de configuração do sistema (funcionalidade do administrador) ... 25

2.30 User Story 30 – Emissão de relatórios... 26

2.31 User Story 31 – Detecção de fraudes de energia ... 27

2.32 User Story 32 – Detecção de roubo de energia ... 27

2.33 User Story 33 – Implementação do sistema de criptografia ... 28

2.34 User Story 34 – Solicitar medição local em Smart Meter remoto ... 29

2.35 User Story 35 – Comparar valor armazenado localmente no SM-CEN com o valor armazenado no SM remoto ... 30

2.36 User Story 36 – Receber pedido de energia ... 30

2.37 User Story 37 – Armazenar log do envio de energia ... 31

(5)

1 INTRODUÇÃO

Esse documento tem, por objetivo, documentar a seção Product Backlog do Smart Meter Central. Para isso, serão analisados dois tópicos principais: User Stories e Priorização. O tópico User Stories terá vários subtópicos.

2 USER STORIES

A seguir são listados todos os 33 requisitos identificados como maior valor de negócio para o Cliente.

1. Desenvolvimento da Unidade de Processamento Central (UPC) 2. Recebimento Medições dos SM

3. Armazenamento de Medições 4. Atribuição de ID de SM 5. Recebimento de Alertas 6. Envio de Alertas 7. Envio de Programação/Dados 8. Armazenamento de Alertas

9. Recebimento de coordenadas de localização do Smart Meter

10. Implementação do sistema de recuperação da rede inteligente (Smart Grid) 11. Recebimento de tabela de tarifas

12. Atualização de tabela de tarifas

13. Stub de conexão com o SM-Rede (Integração) 14. Stub de desacoplamento de conexões (Integração) 15. Determinação da quantidade de energia a ser enviada 16. Determinação da quantidade de energia a ser recebida 17. Bloqueio de recebimento de energia de forma remota 18. Habilitação de recebimento de energia de forma remota 19. Criação de lista de conexões

20. Atualização da lista de conexões 21. Implementação de sistema de backup 22. Restauração para as configurações originais 23. Monitoramento da integridade da rede 24. Monitoramento da voltagem da rede

25. Configuração de cadastro de configurações do sistema 26. Configuração de remoção de configurações do sistema 27. Configuração de edição de configurações do sistema 28. Configuração de procura de configurações do sistema

(6)

CE 235 - Sistemas Embarcados de Tempo Real Página 6 29. Configuração de autenticação de configurações do sistema

30. Emissão de relatórios

31. Detecção de fraudes de energia 32. Detecção de roubo de energia

33. Implementação do sistema de criptografia 34. Solicitar medição local em Smart Meter remoto

35. Comparar valor armazenado localmente no Smart Meter Central com o valor armazenado no Smart Meter remoto

36. Receber pedido de energia

37. Armazenar log do envio de energia

Para cada um dos requisitos segue uma pequena explicação do requisito em forma de texto, seguida de uma estimativa do esforço a ser despendida na realização da tarefa, uma especificação dos detalhes de implementação da tarefa e, finalmente, um teste de aceitação para a mesma.

Para a estimativa de esforço despendido, utilizou-se como base de comparação o requisito “Recebe e Envia Alertas do Smart Meter”, considerado pelo grupo como o mais simples. Este requisito recebeu então a atribuição de esforço como sendo 1 SP (Story Point).

2.1 User Story 1 – Desenvolvimento da Unidade de Processamento Central

(UPC)

O sistema deve gerenciar de forma correta toda a comunicação recebida do SM-Rede e enviada ao dispositivo SM-Central.Também deverá controlar os fluxos de comunicação entre os componentes internos do SM-Central.

2.1.1 Esforço Estimado

A User Story Recebimento de medições de Smart Meters é estimada em 13 Story Points (SP). .

2.1.2 Detalhes

O sistema deve receber as informações do SM-Rede e gerenciar corretamente o fluxo de comunicação dentro do SM-Central, processando de forma correta.

(7)

2.1.3 Teste de Aceitação

Verificar o gerenciamento correto do SM-Central conforme os requisitos do Cliente.

2.2 User Story 2 – Recebimento de medições de Smart Meters

O sistema deve receber as informações de medições enviadas pelos demais Smart Meters. As mensagens devem estar estruturadas de modo compatível com os outros Smart Meters.

A User Story Recebimento de medições de Smart Meters é estimada em 5 Story Points (SP). .

2.2.2 Detalhes

O sistema deve receber as informações de medições com os demais Smart Meters, sendo capaz de interpretar de forma adequada.

Verificar o recebimento correto dessas medições possibilitando inferir de forma adequada.

2.3 User Story 3 – Armazenamento de medições

Com o armazenamento das medições do Smart Meter é possível gerar relatórios e analisar o histórico deste dispositivo para melhor controlar o Smart Grid.

(8)

2.3.2 Detalhes

O Smart Meter deve gravar LOGS das medições, que devem conter informações como, por exemplo: identificação do usuário, quantidade consumida, horário e tarifa de consumo.

Após o estabelecimento de uma conexão com fluxo de energia, os LOGS devem ser verificados com a validação das informações especificadas.

2.4 User Story 4 – Atribuição de ID ao Smart Meter

A identificação do Smart Meter permite saber qual dispositivo está solicitando comunicação com o SM-Central para melhor controlar o sistema como um todo.

A User Story Identificação do Smart Meter é estimada em 20 Story Points (SP).

2.4.2 Detalhes

O sistema deve verificar e armazenar a identificação do Smart Meter que está se conectando. Essa identificação será feita por meio de um número de identificação (ID).

Um Smart Meter deve solicitar conexão e o Smart Meter central deve responder validando o número de ID e mantendo-o associado à nova conexão.

(9)

2.5 User Story 5 – Recebimento de Alertas

Um alerta, para o escopo deste projeto, será tido como uma mensagem de acknowledgement, ou seja, uma mensagem trocada com o simples intuito de reconhecer a conexão entre os Smart Meters. Em particular, o Smart Meter Central deverá ser capaz de reconhecer quais dispositivos estão conectados em qualquer momento.

A User Story Comunicação com Smart Meters é estimada em 5 Story Point (SP).

2.5.2 Detalhes

A implementação deste requisito se baseia em um acordo entre todos os Smart Meters sobre o protocolo sobre o qual será implantado o código. Este requisito também necessita que esteja criada a tabela de conexões, para que nesta possam ser acrescentadas as atualizações.

Recebimento de alertas de um Smart Meter qualquer identificando o tipo da mensagem de forma adequada.

2.6 User Story 6 – Envio de Alertas

De forma semelhante ao User Story 5, o alerta deverá ser enviado de forma adequada para o Smart Meter o qual está conectado ao SM-Central.

(10)

CE 235 - Sistemas Embarcados de Tempo Real Página 10 A User Story Comunicação com Smart Meters é estimada em 8 Story Point (SP).

2.6.2 Detalhes

A implementação deste requisito se baseia em um acordo entre todos os Smart Meters sobre o protocolo sobre o qual será implantado o código. Este requisito também necessita que esteja criada a tabela de conexões, para que nesta possam ser acrescentadas as atualizações.

Envio de alertas do SM-Central para qualquer Smart Meter de forma adequada.

2.7 User Story 7 – Envia programação/dados ao Smart Meter

Com o envio da programação/dados ao Smart Meter requerente é possível transmitir informações específicas para este dispositivo.

A User Story Identificação do Smart Meter é estimada em 13 Story Points (SP).

2.7.2 Detalhes

O sistema deve enviar periodicamente mensagens contendo informações gerais sobre o consumo para o período do dia e data atual, bem como previsões para o período seguinte. As mensagens devem conter: as tarifas atuais, quantidade consumida no último período do dia, quantidade de energia total consumida desde o último pagamento, valor atual a ser pago e informações sobre alterações nas tarifas.

(11)

Monitorar um Smart Meter de teste que deve consumir emergia de modo programado e em período que contenha mudança tarifária. Assim, devem-se verificar as respostas obtidas no Smart Meter comparando-as com as previamente conhecidas a partir da programação de consumo.

2.8 User Story 8 – Armazenamento de Alertas

De forma semelhante ao User Story 5, o alerta deverá ser armazenado de forma adequada, garantindo assim a rastreabilidade das informações que circulam pelo SM-Central.

A User Story Comunicação com Smart Meters é estimada em 13 Story Point (SP).

2.8.2 Detalhes

A implementação deste requisito se baseia no armazenamento correto dos alertas recebidos e enviados pelo SM-Central. Este armazenamento deverá se comunicar adequadamente com uma base de dados o qual estas informações servirá de repositório.

Armazenamento de alertas enviados e recebidos pelo SM-Central de forma adequada.

2.9 User Story 9 – Recebimento de coordenadas de localização do Smart

Meter

Com o recebimento das coordenadas de localização do Smart Meter é possível identificar tarifas de consumo de energia para melhorar a eficiência no gerenciamento de energia.

(12)

A User Story Recebimento de coordenadas de localização do Smart Meter é estimada em 5 Story Points (SP).

2.9.2 Detalhes

O Sistema deve receber periodicamente uma mensagem contendo Latitude e Longitude de modo compatível com os demais Smart Meters (GPS – Global Position System).

Uma mensagem do tipo Localização deve ser enviada de um Smart Meter Remoto para o Smart Meter Central. Essa mensagem deve chegar de modo integro ao sistema.

2.10 User Story 10 – Implementação do Sistema de Recuperação

Para o caso de um Smart Meter importante para a distribuição de energia se desconectar, o sistema deve ser capaz de recalcular a maneira de distribuir de energia, de forma a continuar fornecendo energia a todos os Smart Meters.

2.10.1Esforço Estimado

A User Story Implementação do Sistema de Recuperação é estimada em 20 Story Points (SP).

2.10.2Detalhes

Na implementação desse requisito será necessário o desenvolvimento de um algoritmo de detecção sub-grafo fortemente conexo, que é uma tarefa complexa o suficiente para adicionar uma incerteza relativamente grande na estimação do esforço.

(13)

2.10.3Teste de Aceitação

A implementação deste requisito estará terminada mesmo com a queda de um ponto importante de distribuição de energia, o qual o sistema deverá continuar provendo energia a todos os Smart Meters.

2.11 User Story 11 – Recebimento de tabela de tarifas

O sistema deve receber uma tabela contendo os valores das tarifas relativas a cada horário, tipo de Smart Meter e região. Esta tabela poderá ser requisitada pelos clientes, a todo e qualquer momento. Por isso, deverá existir uma interface para o administrador possa modificar estas tarifas.

A User Story Recebe e atualiza tabela de tarifas foi estimada em 8 Story Points (SP). .

2.11.2Detalhes

A tabela de tarifas pode mudar conforme a hora do dia, dia do mês, a localização do SM e etc.

Esta User Story tem alta prioridade. Para realizar o teste, o SM-Central deverá receber os valores tarifados de forma correta.

2.12 User Story 12 – Atualização de tabela de tarifas

O sistema deve atualizar uma tabela contendo os valores das tarifas relativas a cada horário, tipo de Smart Meter e região. Esta tabela poderá ser requisitada pelos clientes, a todo e qualquer momento. Por isso, deverá existir uma interface para o administrador possa modificar estas tarifas.

(14)

A User Story Recebe e atualiza tabela de tarifas foi estimada em 5 Story Points (SP). .

2.12.2Detalhes

A tabela de tarifas pode mudar conforme a hora do dia, dia do mês, a localização do SM e etc.

Esta User Story tem alta prioridade. Para realizar o teste, o SM-Central deverá atualizar os valores tarifados de forma correta.

2.13 User Story 13 – Stub de Conexão com o SM-Rede (Integração)

O sistema deve realizar a conexão adequada com o SM-Rede para envio das informações necessárias oriundas do SM-Central. Para isto, esta user story prevê a criação de um stub que fará uma simulação do comportamento do SM-Rede em ambiente de produção. Este stub deverá representar com fidelidade a realidade dos acessos do SM-Rede para o SM-Central durante o funcionamento do Smart Grid integrado.

A User Story desenvolvida foi estimada em 8 Story Points (SP).

2.13.2Detalhes

Esta stub deve representar várias instancias em paralelo do SM-Rede, pois haverá comunicação de vários deles ao mesmo tempo no ambiente de produção, também deve conter um heartBeat para verificação do acesso de tempos em tempos, simulando o heartBeat do SM-Rede que verifica se os SMs estão conectados.

(15)

Esta User Story tem alta prioridade. Para testar isso, deve conferir o timer enviando periodicamente um sinal de teste um sinal para o SM-CENTRAL, e verificar se o sistema está criando diferentes instâncias desse stub, também de forma periódica, para simular o paralelismo.

2.14 User Story 14 – Stub de Desacoplamento de Conexões (Integração)

O sistema deve realizar o desacoplamento da comunicação entre SM-Rede e o SM-Central facilitando uma possível substituição da comunicação entre os SMs por sockets, sem a necessidade de alterar nada do que já está pronto dentro de qualquer um deles.

A User Story facilita uma atualização da comunicação pelo protocolo de rede criando stubs de comunicação em rede foi estimada em 3 Story Points (SP).

2.14.2Detalhes

Para que a funcionalidade seja atendida, um módulo oco de comunicação deve ser acoplado antes da saída de sinal dos dois sistemas. Assim, caso haja alteração na forma de comunicação, apenas estes stubs devem ser substituídos e não será necessário alterar ou re-compilar os sistemas que já estão funcionais.

Para testar esta User Story, basta verificar se a comunicação entre os Smart Meters não está acontecendo de forma direta. Qualquer comunicação entre eles deve passar por uma cápsula oca que abstrai a forma de comunicação.

(16)

2.15 User Story 15 – Determina 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.

A User Story Determina quantidade de energia a ser enviada foi estimada em 8 Story Points (SP).

2.15.2Detalhes

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.

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.

2.16 User Story 16 – Determina quantidade de energia a ser recebida

O sistema deve calcular a quantidade de energia que deve ser recebida a partir da primeira requisição de um Smart Meter. Além disso, o sistema deve fazer verificações periódicas para saber se a energia foi recebida de forma adequada.

(17)

A User Story Determina quantidade de energia a ser recebida foi estimada em 8 Story Points (SP).

2.16.2Detalhes

O cálculo da energia recebida inicial dependerá do histórico de consumo do Smart Meter e os recebimentos 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.

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.

2.17 User Story 17 – Bloqueio de recebimento de energia de forma remota

O sistema deve bloquear o recebimento de energia de forma remota adequadamente. Toda a integridade do sistema deverá ser mantido.

A User Story Bloqueio de recebimento de energia de forma remota foi estimada em 8 Story Points (SP).

(18)

2.17.2Detalhes

O bloqueio de recebimento de energia de forma remota poderá ser realizado de qualquer lugar através de um acesso seguro e autenticado. Dessa forma, deverá ser registrado todas as ações de bloqueio de energia recebida adequadamente.

Para realizar o teste será necessário realizar o bloqueio do recebimento de energia de forma remota, registrando esta ação adequadamente.

2.18 User Story 18 – Habilitação de recebimento de energia de forma remota

O sistema deve habilitar o recebimento de energia de forma remota adequadamente. Toda a integridade do sistema deverá ser mantida.

A User Story Habilitação de recebimento de energia de forma remota foi estimada em 8 Story Points (SP).

2.18.2Detalhes

A habilitação de recebimento de energia de forma remota poderá ser realizada de qualquer lugar através de um acesso seguro e autenticado. Dessa forma, deverão ser registradas todas as ações de habilitação de energia recebida adequadamente.

Para realizar o teste será necessário realizar a habilitação do recebimento de energia de forma remota, registrando esta ação adequadamente.

(19)

2.19 User Story 19 – Criação da lista de conexões

O sistema precisa criar uma lista de usuários (Smart Meters) que estão conectados em todos os momentos, inclusive os dados históricos de conexões.

A User Story Criação da lista de conexões foi estimada em 8 Story Points (SP).

2.19.2Detalhes

Ainda não foi decidido uma estrutura de dados adequada para a implementação deste requisito, esta escolha será feita num momento posterior do projeto.

Este requisito será considerado satisfeito quando existir uma estrutura de dados no projeto capaz de criar os dados de conexão. Esta estrutura deve suportar a adição de novos Smart Meters e o armazenamento do histórico de conexões criadas.

2.20 User Story 20 – Atualização da lista de conexões

O sistema precisa atualizar uma lista de usuários (Smart Meters) que estão conectados em todos os momentos, inclusive os dados históricos de conexões.

(20)

2.20.2Detalhes

Ainda não foi decidido uma estrutura de dados adequada para a implementação deste requisito, esta escolha será feita num momento posterior do projeto.

Este requisito será considerado satisfeito quando existir uma estrutura de dados no projeto capaz de atualizar os dados de conexão. Esta estrutura deve suportar a adição de novos Smart Meters, e o armazenamento do histórico de conexões.

2.21 User Story 21 – Implementação do Sistema de Backup

O sistema deve armazenar fisicamente todas as informações relacionadas a ele como, por exemplo, a conta atual de cada Smart Meter, em, no mínimo, dois lugares físicos distantes entre si, para evitar possíveis perdas de informações importantes.

A User Story Implementação de Sistema de Backup foi estimada em 8 Story Points (SP).

2.21.2Detalhes

Um exemplo que demonstra a importância dessa implementação é o caso de acidentes físicos como, por exemplo, incêndios que podem ocorrer e, com isso, um número imenso de informações podem ser perdidas, caso não exista um sistema de backup.

Esta User Story tem baixa prioridade. Por isso, não será especificado teste de aceitação para ela nesta fase do projeto.

(21)

2.22 User Story 22 – Restauração para as configurações originais

O sistema precisa de uma função para reiniciar suas configurações, para o caso de ocorrer alguma pane do sistema, ou ainda para o caso de o administrador desejar recomeçar a definir as configurações.

A User Story Restauração para as configurações originais foi estimada em 3 Story Points (SP).

2.22.2Detalhes

O sistema deve armazenar os dados de configuração para que, se necessário, consiga estabelecer as conexões novamente. Além disso, deve ser possível a edição desses dados, caso necessário.

2.23 User Story 23 – Monitoramento da integridade da rede

Garante a inexistência (ou a existência pouco provável) de falhas de segurança na rede atual, utilizando-se dos dados medidos.

(22)

2.23.2Detalhes

A integridade será medida levando em consideração boas práticas na criação de uma rede de computadores, como a utilização de criptografia dos dados e o reconhecimento de mensagem corrompida.

2.23.3 Teste de Aceitação

2.24 User Story 24 – Monitoramento da voltagem da rede

O sistema deve monitorar a voltagem da rede para que a transmissão ocorra, conforme as regras de funcionamento da concessionária.

A User Story Monitoramento da voltagem da rede foi estimada em 8 Story Point (SP).

2.24.2Detalhes

A voltagem de energia transmitida segue algumas normas. É indispensável para o bom funcionamento dos Smart Meters que todas as transmissões sigam essas normas, afinal toda a estrutura física é preparada para funcionar de acordo com elas. Portanto, é interessante que o sistema verifique se a voltagem da rede está obedecendo tais normas e, caso isso não esteja ocorrendo, que ele tome as medidas cabíveis para que isso aconteça.

(23)

2.25 User Story 25 – Configuração de cadastro de configuração do sistema

(funcionalidade do administrador)

O sistema deve prover uma interface para que o administrador do sistema (pessoa responsável por manter o funcionamento do sistema) possa cadastrar as configurações do sistema.

A User Story Configuração de cadastro de configuração do sistema foi estimada em 3 Story Points (SP).

2.25.2Detalhes

As configurações do sistema serão definidas com o decorrer do projeto. Conseqüentemente, essas configurações surgirão conforme necessidade e serão especificadas em futuros relatórios.

2.26 User Story 26 – Configuração de remoção de configuração do sistema

(funcionalidade do administrador)

O sistema deve prover uma interface para que o administrador do sistema (pessoa responsável por manter o funcionamento do sistema) possa remover as configurações do sistema.

(24)

A User Story Configuração de remoção de configuração do sistema foi estimada em 3 Story Points (SP).

2.26.2Detalhes

2.27 User Story 27 – Configuração de edição de configuração do sistema

(funcionalidade do administrador)

O sistema deve prover uma interface para que o administrador do sistema (pessoa responsável por manter o funcionamento do sistema) possa editar as configurações do sistema.

A User Story Configuração de edição de configuração do sistema foi estimada em 5 Story Points (SP).

2.27.2Detalhes

(25)

2.28 User Story 28 – Configuração de procura de configuração do sistema

(funcionalidade do administrador)

O sistema deve prover uma interface para que o administrador do sistema (pessoa responsável por manter o funcionamento do sistema) possa procurar as configurações do sistema.

A User Story Configuração de procura de configuração do sistema foi estimada em 5 Story Points (SP).

2.28.2Detalhes

2.29 User Story 29 – Configuração de autenticação de configuração do sistema

(funcionalidade do administrador)

O sistema deve prover uma interface para que o administrador do sistema (pessoa responsável por manter o funcionamento do sistema) possa autenticar os usuários que acessam as configurações do sistema.

(26)

A User Story Configuração de autenticação de configuração do sistema foi estimada em 5 Story Points (SP).

2.29.2Detalhes

2.30 User Story 30 – Emissão de relatórios

O sistema deve emitir um relatório para os Smart Meters, contendo alguns dados importantes, tais como consumo de energia e tarifa atual.

A User Story Emissão de relatórios foi estimada em 5 Story Points (SP).

2.30.2Detalhes

A opção de receber relatórios do Smart Meter Central transmite uma idéia de confiabilidade e transparência ao sistema.

(27)

2.31 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.

A User Story Detecção de fraudes de energia foi estimada em 13 Story Points (SP).

2.31.2Detalhes

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.

2.32 User Story 32 – Detecção de roubo 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.

(28)

A User Story Detecção de roubo de energia foi estimada em 13 Story Points (SP).

2.32.2Detalhes

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.

2.33 User Story 33 – Implementação do sistema de criptografia

O sistema deve trocar todas as informações através de um processo de criptografia adequado, garantindo a integridade e segurança nestas informações.

A User Story Implementação do sistema de criptografia foi estimada em 8 Story Points (SP).

2.33.2Detalhes

Toda a informação transmitida ou recebida deverá passar por um processo de criptografia de forma adequada.

(29)

2.34 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.

A User Story Solicitar medição local em Smart Meter remoto foi estimada em 8 Story Points (SP).

2.34.2Detalhes

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.

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).

(30)

2.35 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.

2.35.2Detalhes

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.

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.

2.36 User Story 36 – Receber pedido de energia

(31)

2.36.2Detalhes

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.

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.

2.37 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.

(32)

CE 235 - Sistemas Embarcados de Tempo Real Página 32 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

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.

(33)

3 PRIORIZAÇÃO

A seguir, é apresentada a tabela de prioridades, onde são elencadas todas as User Stories, em ordem decrescente de prioridade, suas respectivas justificativas e estimativas de esforço despendido para a realização de cada uma das tarefas.

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 Recebimento de Alertas Paulo 20

6 Envio de Alertas Taynara 13

7 Envio de Programação/Dados Gustavo 13

8 Armazenamento de Alertas Alexandre 13

9 Recebimento de coordenadas de localização do Smart Meter Armando 13 10 Implementação do sistema de recuperação da rede inteligente (Smart

Grid)

Ciro 13

11 Recebimento de tabela de tarifas Gustavo 13

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

(34)

23 Monitoramento da integridade da rede Armando 3

Tabela 1 – Priorização dos requisitos do SM-Central.

Vale ressaltar que os valores atribuídos às prioridades foram reavaliados para entrarem em acordo com os novos requisitos do cliente dados pelo teste-piloto, especificado no documento em anexo de nome Especificação do teste-piloto. Também foram acrescentadas quatro User Stories para satisfazer estes novos requisitos.