INSTITUTO TECNOLÓGICO DE AERONÁUTICA
Divisão de Ciência da Computação
CE 235 – Sistemas Embarcados de Tempo Real
Projeto Final - Smart Meter Industrial (SM-IND)
Aluno: Luiz Rubens Lencioni P. Leite
Alunos (SM-IND): Giácomo de Lacerda
Luís Antônio de A. Rodriguez Luis Paulo Zanetti
Luiz Rubens Lencioni
Strauss Carvalho
Professores: Prof. Dr. Adilson Marques da Cunha Prof. Dr. Luiz Alberto Vieira Dias
São José dos Campos 28 - Novembro - 2011
I. Introdução
1.1 Motivação
Os dois principais pilares para a execução deste trabalho foram o uso de Métodos Ágeis para desenvolvimento de software e auxílio de uma ferramenta para modelamento e geração automática de código para sistemas embarcados de tempo real, tendo como estudo de caso o Sistema Smart Grids – Smart Meter Industrial, um medidor inteligente de energia elétrica consumida e produzida por uma indústria hipotética, conforme ilustrado pela figura 1 do anexo I.
Seguindo as boas práticas dos métodos Ágeis, o ponto de partida foi o levantamento das necessidades junto ao cliente, neste caso os professores da disciplina CE-235. Esta pesquisa deu origem a quinze User Stories, que formaram a base para elaboração do primeiro artefato denominado Product Backlog.
As User Stories foram dividas entre os alunos do grupo, conforme apresentado pela tabela 1 do anexo II. As três User Stories sob responsabilidade do autor deste relatório foram: realizar a medida de energia da área administrativa (US-9), medir a energia solar produzida pelos geradores (US-13) e calcular o fator de carga (US-11).
Para desenvolvimento do software embarcado de tempo real foi utilizada a ferramenta Rational Rose Real Time, da empresa IBM Rational.
1.2 Contexto
As User Stories sob responsabilidade deste autor estão destacadas no diagrama de casos de uso na Figura 1 do anexo III. As seguintes funcionalidades serão fornecidas com a esta implementação:
• Medida da energia consumida da rede elétrica pela área administrativa da empresa, como iluminação e tomadas de uso geral e específico dos escritórios;
• Medida da energia solar produzida pela indústria, para possibilitar a venda de energia excedente da indústria para a concessionária de energia;
• Cálculo do fator de carga, para calcular a energia elétrica útil realmente consumida pela indústria.
1.3 Objetivo do Protótipo do Smart Meter Industrial (SM-IND)
O objetivo do projeto Smart Meter Industrial (SM–IND) é fornecer capacidade de gerenciamento da energia elétrica que trafega por uma indústria, através do registro de medições de energia produzida e demandada pelos diversos setores. Ele oferece um Sistema de Apoio à decisão para os gestores de energia, visto que, com os resultados de suas ações, gera informações úteis para implementação de mudanças para expansões ou economia de meios.
1.4 Redução do Escopo
O conjunto de capacidades definidas com a implementação do software foi acertado entre o cliente e a equipe de desenvolvimento no sentido de que fosse flexível, de certa forma, aberto, mas devendo ser tomado como premissa para o desenvolvimento.
As capacidades do software limitam-se a:
• Medir todo tipo de energia que trafega pelas linhas da indústria, tais como a que é solicitada pelos equipamentos, produzida por sistemas eólicos, solares ou termais.
• Gerar relatório geral impresso em display e em arquivo em disco. • Alterar o intervalo de tempo de medições e de envio de alarmes.
• Comunicar-se com um Smart Meter Central, a fim de enviar-lhe os resultados das medições.
• Recuperar o relatório a qualquer momento.
• Manter um registro de outros equipamentos dentro da rede interna da indústria.
1.5 Especificação de Requisitos
Considerando o primeiro artefato gerado, a lista que contém o conjunto de necessidades do cliente, foi possível criar as quinze User Stories que formaram o Product Backlog. As capacidades correspondentes às US descritas para o projeto são:
User Story I – Editar configurações do sistema: “Como um usuário autorizado a
como, do intervalo de tempo de medição.”
User Story II – Medir a demanda total de carga: “Como um interpretador de todo sinal
elétrico que trafega pela rede, o hardware do sistema deve armazenar o valor de toda a energia consumida pela empresa e transmitir esse valor ao sistema de software, para que o mesmo possa calcular o valor resultante ao final dos períodos de medição.”
User Story III – Emitir relatório geral: “Como um usuário cadastrado e tendo
acessado o sistema, posso acionar uma funcionalidade que gere um relatório que contenha todos os dados processados pelo hardware do sistema, incluindo as modificações de configurações de sistema autorizadas com senha e a demanda por energia, detalhada por setor de cobertura.”
User Story IV – Manter comunicação com o dispositivo central: “Como um usuário
cadastrado e tendo acessado o sistema, posso acionar uma funcionalidade que abra um canal de comunicação com o elemento central da rede de medidores, que servirá para a troca de mensagens entre os dispositivos comuns e o dispositivo central. Desejo, também, ter confirmação do canal aberto no display do hardware.”
User Story V – Manter registro dos outros SM: “Como parte integrante de um
conjunto de Smart Meters ligados em rede, eu necessito saber informações de status de todos os outros equipamentos, incluindo seus Id’ s de rede, a fim de que, baseado nessas informações, possa ser executado o algoritmo de escolha para backup no caso de pane de algum equipamento.”
User Story VI – Ativar ou Desativar dispositivos: “Como parte integrante de um
sistema inteligente, o Smart Meter deve ser capaz de identificar imediatamente um novo dispositivo conectado à rede e solicitando ou produzindo energia que irá trafegar pelo sistema.”
User Story VII – Manter registro da posição geográfica: “Como parte integrante de
uma grande rede de equipamentos de medição, espalhados geograficamente, cada hardware deve manter o registro da posição geográfica em que está posicionado.”
User Story VIII – Enviar medições ao SM – CEN : “Como parte integrante de uma
rede de Smart Meters, o hardware do sistema deve enviar todas as medições realizadas pelo equipamento durante o intervalo de tempo estabelecido nas configurações.”
User Story IX – Medir a demanda de energia da área administrativa: “Como parte
integrante de uma rede de Smart Meters, o hardware do sistema deve ter a capacidade de medir a demanda da área administrativa, que utiliza duas fases, e, diferenciar as demandas das subseções, registrando os valores individuais.”
User Story X – Medir a demanda de energia da área operacional: “Como parte
integrante de uma rede de Smart Meters, o hardware do sistema deve ter a capacidade de medir a demanda da área operacional, que utiliza três fases, e, diferenciar as demandas dos fornos e motores, registrando os valores individuais.”
User Story XI – Calcular o Fator de Carga: “Como parte integrante de uma rede de
Smart Meters, o hardware do sistema deve ter a capacidade de registrar a energia dispersada, calculando o fator de carga do intervalo medido.”
User Story XII – Medir a quantidade de energia eólica produzida: “Como parte
integrante de uma rede de Smart Meters, o hardware do sistema deve ter a capacidade de registrar a quantidade de energia Eólica pela empresa.”
User Story XIII – Medir a quantidade de energia solar produzida: “Como parte
integrante de uma rede de Smart Meters, o hardware do sistema deve ter a capacidade de registrar a quantidade de energia produzida pelas placas de captação de energia solar.”
User Story XIV – Informar o valor resultante: “Como usuário cadastrado eu posso
acessar o sistema e verificar o valor resultante definido para o período de medição configurado.”
User Story XV – Restaurar configurações originais: “Como usuário cadastrado eu
posso acessar o sistema e acionar a funcionalidade que restaura as configurações originais do sistema.”
1.6 Ordem de Apresentação do Projeto Final da Matéria
O trabalho foi estruturado de forma que, na Seção I, Introdução, é exposta a Motivação para resolver o problema, o ponto de partida para o descobrimento da solução, o Contexto, onde o universo de características que foi implementado pelo autor é referenciado com relação ao projeto como um todo. O Objetivo do protótipo do software embarcado, caracterizando suas capacidades e uma especificação de requisitos, onde são associadas funcionalidades e capacidades às US.
A Seção II retrata o desenvolvimento em seus detalhes, mostrando todas as etapas utilizadas pela equipe para construir o software, incluindo as três iterações de desenvolvimento em seus detalhes. Pode-se observar várias referências a diagramas nesta Seção, visto que a mesma está calcada na implementação na ferramenta da Rational.
A Seção III contem conclusões, recomendações e idéias para possíveis trabalhos futuros.
II. Desenvolvimento
A idéia reservada como premissa para cada Sprint Backlog é entregar ao cliente um produto que seja utilizável, considerando este termo como algo que ele possa, de imediato, implantar e agregar valor para o funcionamento de seu negócio. O desenvolvimento do projeto foi dividido em quatro fases, a saber, a primeira foi o Sprint Backlog, onde foi feita a priorização das User Stories, considerando o que cada uma agregou de valor ao cliente, juntamente com as estimativas de tempo em horas de trabalho.
Após o planejamento descrito no Sprint Backlog, o Scrum Master dividiu o desenvolvimento em três iterações, ou, três Sprint Developments. Cada um deles gerou um artefato pronto para ser entregue ao cliente e colocado em operação, agregando valor ao funcionamento do negócio do mesmo. Os produtos gerados na segunda e na terceira iteração partiram dos anteriores, de forma incremental.
1ª Fase – Sprint Backlog (SBK)
A idéia desta etapa é definir pontos-chave do processo que sejam de entendimento comum de toda a equipe, a fim de falar a mesma língua no que diz respeito a prazos, escopo, arquitetura e priorização do desenvolvimento. A Figura 2 do Anexo III mostra o diagrama de domínio do sistema, em um nível de abstração que permite que sejam visualizadas as principais Classes de Objetos do domínio, seus relacionamentos verticais e horizontais, as ações realizadas por cada uma delas e como as mensagens são trocadas para solicitação de serviços entre elas.
A Figura 1 do Anexo III mostra um diagrama de Casos de Uso que representa o escopo do projeto. Cada caso de uso modelado representa uma User Story, listadas na Tabela 1 do Anexo II, alinhadas com o diagrama e numeradas de acordo com a definição do documento Sprint Backlog confeccionado pelo Grupo.
A Figura 3 do Anexo III mostra a arquitetura de alto nível do sistema. É possível observar que há um componente central que controla e se comunica com outros oito componentes. Cada um deles foi implementado como uma cápsula na ferramenta da IBM Rational e tem uma funcionalidade específica, a saber:
do sistema.
• Scan – Realiza todas as medições de energia.
• Ping – Abre um canal de comunicação com o SM – RED. • Echo – Recebe uma resposta do SM – RED.
• Reset – Restaura as configurações originais do sistema. • Config – Altera manualmente as configurações do sistema. • EnviaMedicoes – Envia o pacote de informações ao SM – RED.
• EnviaPosicao – Mantém o registro dos outros SM do sistema e envia sua própria posição em broadcast, para que todos saibam sua posição.
Nesta fase do projeto foi definido o uso do Burndown Chart para acompanhamento da evolução dos Sprints de acordo com as User Stories definidas, conforme ilustra a figura 2 do Anexo I.
2ª Fase – 1º Sprint Development (SDV)
O 1º. Sprint Development foi realizado implementando-se as funcionalidades descritas pelo Sprint Backlog através da ferramenta Rational Rose Real Time (RRRT). Esta fase permitiu a elaboração da plataforma base para os demais Sprint Developments que virão a seguir.
As seguintes funcionalidades foram implementadas no 1º Sprint Development: o Medir a demanda total de carga (US-2)
o Manter comunicação com dispositivo central (US-4) o Medir demanda de energia da área operacional (US-9) o Medir energia eólica produzida (US-12)
o Medir energia solar produzida (US-13)
Minha participação no 1º Sprint Development, de acordo com a divisão das User Stories pelo grupo SM-IND, foi a implementação da User Story 9 (Medir a demanda de energia consumida pela área administrativa) conforme figuras 3 e 4 do Anexo I.
Para a implementação da US-9, bem como para desenvolvimento de outras US também, foi criada a cápsula “SCAN” dentro da ferramenta RRRT. Uma transição chamada “Lendo_SM” foi criada, e dentro desta transição foi implementado o código
em C++ para leitura da energia consumida não apenas pela área administrativa bem como da área operacional da industria. Para simular quando os equipamentos e iluminações são ligados/desligados foi criado um programa em linguagem Python, denominado “Supervisório”, ilustrado na figura 5 do Anexo I.
O gráfico Burndown Chart foi atualizado para permitir o acompanhamento da evolução do projeto.
3ª Fase – 2º Sprint Development (SDV)
O objetivo do segundo Sprint Development foi entregar ao Cliente a segunda versão de do protótipo funcional do Smart Meter Industrial, com mais funcionalidades do que o primeiro Sprint Development.
As seguintes funcionalidades foram implementadas no 2º Sprint Development: o Editar configurações do sistema (US-1)
o Emitir relatório geral (US-3)
o Manter registro de outros Smart Meters Industriais (US-5) o Enviar medições ao SM-CEN (US-8)
o Medir demanda de energia da área administrativa (US-9)
Minha participação no 2º Sprint Development, de acordo com a divisão das User Stories pelo grupo SM-IND, foi a implementação da User Story 13 (Medir a energia solar produzida) conforme figuras do Anexo I.
Para esta implementação também foi utilizada a cápsula “SCAN” desenvolvida na ferramenta RRRT, e utilizado o programa supervisório para simular a produção de energia solar.
Os artefatos foram atualizados e foi realizada uma apresentação executiva, mostrando ao cliente o resultado da implementação das User Stories desta fase. Novamente o gráfico Burndown Chart foi atualizado para permitir o acompanhamento da evolução do projeto.
4ª Fase – 3º Sprint Development (SDV)
O objetivo do terceiro Sprint Development foi entregar ao Cliente a ultima versão de do protótipo funcional do Smart Meter Industrial.
As seguintes funcionalidades foram implementadas no 3º Sprint Development: o Ativar/desativar dispositivos (US-6)
o Manter registro de posição geográfica (US-7) o Calcular o Fator de Carga (US-11)
o Informar o valor resultante (US-14) o Restaurar configurações originais (US-15)
Minha participação no 2º Sprint Development, de acordo com a divisão das User Stories pelo grupo SM-IND, foi a implementação da User Story 11 (Calcular o Fator de Carga).
O gráfico Burndown Chart foi finalizado, permitindo a visualização da evolução do projeto através dos Sprint Developments, conforme figura 8 do Anexo I.
Ao fim do 3º Sprint Development pode-se verificar o funcionamento completo do Smart Meter Industrial, com todas as User Stories implementadas.
3. Conclusão
3.1 Conclusões
Conforme proposto pelo conteúdo da disciplina CE-235, verifica-se que é totalmente viável o projeto de software embarcado em tempo real combinando-se boas práticas do desenvolvimento ágil com ferramentas de modelagem e geração automática de código.
Foram constatadas na prática as vantagens do uso de métodos Ágeis para elaboração de um projeto de software profissional, incremental e com total foco nos desejos e anseios do cliente. Pode-se verificar também a vantagem no uso de ferramentas como o Rational Rose Real Time para modelagem e geração de códigos automaticamente. No caso do projeto Smart Meter Industrial, apenas 7% do código total foi gerado manualmente, um salto tanto em produtividade quanto na possibilidade de reuso de modelos em projetos futuros.
Particularmente, tornei-me entusiasta da proposta de métodos como Scrum, pois é fato, comprovado por inúmeros projetos nos quais já participei em minha vida profissional, que as técnicas de gerenciamento de projetos de software tradicionais estão ultrapassadas.
3.2 Recomendações
Algumas premissas foram assumidas no projeto Smart Meter Industrial para tornar viável a adoção do método Scrum, como por exemplo, na medida da evolução do projeto em User Stories no gráfico Burndown Chart. Normalmente esta estimativa é realizada em horas, para controle mais preciso do processo de desenvolvimento. Desta forma recomenda-se o uso da estimativa em horas no Burndown Chart.
O embarque do software realizado no RRRT em um hardware específico era altamente desejável, mas não foi realizada devido à falta de tempo. Esta fase envolve passos importantes no desenvolvimento de um software embarcado de tempo real, que é a interface com hardware específico.
O uso de tecnologias de comunicação utilizado atualmente em redes Smart Grids também era um anseio do grupo, como por exemplo, a transmissão de dados em linhas
de energia elétrica, conhecido como PLC (Power Line Communications), e seria implementado caso houvesse mais tempo durante o curso.
3.3 Sugestões para trabalhos futuros
O campo de modelagem de sistemas de software e sua aplicação prática são vastos no mundo atual. Sugere-se como trabalho futuro o estudo de caso de uma iniciativa tomada pelos principais fabricantes de automóveis e empresas de autopeças, denominado AUTOSAR (Automotive Open Systems Architecture) [3], um padrão para desenvolvimento de software recém criado para toda indústria automotiva, baseado em modelos e geração automática de software.
Uma sugestão para a evolução da disciplina CE-235 é a elaboração de aulas em salas de laboratório, onde poderiam ser mostrados na prática, por exemplo, a
implementação de um software embarcado em um hardware específico.
Nos próximos trabalhos sugere-se também um foco maior também em sistemas operacionais embarcados, como o QNX, vastamente utilizado em produtos atuais.
Referências Bibliográficas
[1] Endereço eletrônico da página da disciplina CE-235, acessado dia 28/11/2011
https://sites.google.com/site/ce235ita/
[2] Endereço eletrônico do aluno Luiz R. Lencioni, acessado dia 28/11/2011
https://sites.google.com/site/luizlencioni/
[3] AUTOSAR (Automotive Open Systems Architecture)
ANEXO I – IMAGENS
Figura 1 - Smart Meter Industrial (SM-IND)
Burndown Chart SM-IND
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 3/10/2011 10/10/2011 17/10/2011 24/10/2011 31/10/2011 7/11/2011 14/11/2011 U s e r S to ri e s
1o. Sprint Backlog 2o. Sprint Backlog 3o. Sprint Backlog
Figura 1 – Burndown Chart inicial do projeto SM-IND
Área Operacional (Fabril) Área Administrativa Sensores Tensão/Corrent Outros SM-IND SM-CEN Energia Solar Energia Eólica Comunicação (produzida) (produzida) Sensores Tensão/Corrent R ed e Tri fá sic
Figura 3 – Implementação da User Story 9
Figura 5 - Programa supervisório para simulação de consumo de equipamentos
Figura 7 – Teste da energia solar produzida pelo software Supervisório
Figura 8 – Burndown chart final do projeto Smart Grid Industrial (SM-IND)
Burndown Chart SM-IND
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 3/10/2011 10/10/2011 17/10/2011 24/10/2011 31/10/2011 7/11/2011 14/11/2011 U s e r S to ri e s
ANEXO II – TABELAS
Componente Descrição
Strauss
(Product Owner)
US 4 - Manter comunicação com o dispositivo central US 8 - Enviar medições ao SM – CEN
US 6 - Ativar / desativar dispositivos
Rodriguez
(Scrum Master)
US 2 - Medir a demanda total de carga US 3 - Emitir relatório geral de atividades US 15 – Restaurar configurações originais
Lencioni
(Development Team)
US 9 - Medir a demanda de energia da área administrativa US 13 - Medir a energia Solar produzida pelos geradores US 11 - Calcular o Fator de Carga
Giácomo
(Development Team)
US 12 - Medir a energia Eólica produzida pelos geradores US 5 - Manter registro dos outros SM-IND
US 7 - Manter registro da posição geográfica
Zanetti
(Development Team)
US 10 - Medir a demanda de energia da área operacional (fornos & motores)
US 1 - Editar configurações do sistema US 14 - Informar o Valor resultante
Tabela 1 - Divisão das Users Stories
User Stories 1o Sprint
Development
2o Sprint Development
3o Sprint Development
1 Editar configurações do sistema X 2 Medir a demanda total de carga X
3 Emitir relatório geral X
4 Manter comunicação com o dispositivo central X 5 Manter registro dos outros SM X 6 Ativar/Desativar dispositivos X 7 Manter registro da posição geográfica X 8 Enviar medições ao SM-CEN X 9 Medir a demanda de energia da área ADM X 10 Medir a demanada de energia da área operacional X 11 Calcular o Fator de Carga X 12 Medir a quantidade de energia eólica produzida X 13 Medir a quantidade de energia solar produzida X 14 Informar o valor resultante X 15 Restaurar configurações originais X
ANEXO III – DIAGRAMAS
Figura 1 - Diagrama de Casos de Uso (SM-IND)
