UMA METODOLOGIA PARA DESENVOLVIMENTO DE SISTEMAS EMBARCADOSCRITICOS COM VISTAS A CERTIFICACAO

Onofre Trindade Junior∗, Rosana T. Vaccare Braga∗, Luciano de Oliveira Neris†,Kalinka R L J Castelo Branco∗

∗Departamento de Sistemas de Computacao - Instituto de Ciencias Matematicas e de ComputacaoUniversidade de Sao Paulo

Av. do Trabalhador Saocarlense, 400 – Sao Carlos – SP – CEP 13560-970†AGX Tecnologia Ltda – Sao Carlos – SP

Emails: otjunior@icmc.usp.br, rtvb@icmc.usp.br, luciano.neris@agx.com.br,kalinka@icmc.usp.br

Abstract— The development of embedded systems presents some peculiarities, such as low-level communi-cation with hardware devices, uninterrupted functioning for many days, hostile environment and limitations ofresources like memory, processing and, especially, energy consumption. These systems require specific develop-ment methodologies, targeting mainly the development of products with certified quality. This paper presentsthe methodology used in the development of an embedded system, used for guidance and control of an unmannedaircraft. The methodology was adapted from existing methodologies, aiming at including activities that help toimprove the quality of the process and of the final products. The presented case study is quite complex, and rep-resents a real multidisciplinary application, which contributes to a real evaluation of the proposed methodology.The steps regarding modeling and automatic code generation of the methodology were already implemented,and preliminary results indicate the adequacy of the methodology according to the goals established, notablyregarding the quality of the software to its certification standards in each case.

Keywords— UAV, embedded systems, development methodologies, safe-critical systems, certification stan-dards.

Resumo— O desenvolvimento de sistemas embarcados possui caracterısticas peculiares, tais como comunicacaoem baixo nıvel com dispositivos de hardware, funcionamento ininterrupto por muitos dias, ambientes hostis elimitacoes de recursos, como memoria, processamento e, principalmente, consumo de energia. Esses sistemasrequerem metodologias de desenvolvimento especıficas, visando principalmente o desenvolvimento de produtoscom qualidade certificada. Neste artigo, apresenta-se a metodologia utilizada no desenvolvimento de um sistemaembarcado utilizado para guiamento e controle de uma aeronave nao tripulada. A metodologia foi adaptada apartir de metodologias existentes, visando incluir atividades que auxiliem na qualidade do processo e do produtofinal. O estudo de caso apresentado e bastante complexo, representando uma aplicacao real e multidisciplinar,o que contribui para uma avaliacao da metodologia proposta. As fases de modelagem e geracao automatica decodigo ja foram implementadas e os resultados preliminares indicam ate aqui a adequabilidade da metodologiaquanto aos aspectos pretendidos, notadamente quanto a qualidade do software produzido visando sua certificacaosegundos normas aplicaveis.

Keywords— VANT, sistemas embarcados, metodologias de desenvolvimento, sistemas crıticos, normas decertificacao.

1 Introducao

Sistemas embarcados (Douglass, 2004; Lavagnoet al., 2003; OMG, 2009) sao modulos computa-cionais integrados a equipamentos e dispositivosfısicos, que realizam um conjunto de tarefas pre-definidas, normalmente com requisitos especıficos.Em geral atuam em monitoracao e controle emtempo real, como e o caso de sistemas complexoscomo robos, veıculos autonomos e equipamentosmedicos. Esses sistemas sao dedicados a tare-fas especıficas e por meio de tecnicas de engen-haria pode-se otimizar o seu projeto reduzindotamanho, recursos computacionais e custo do pro-duto. Sistemas embarcados sao considerados crıti-cos (ou voltados para aplicacoes crıticas), quandoeles podem colocar vidas humanas ou instalacoesde alto valor em risco, no caso de falha. Em algu-mas aplicacoes, como por exemplo, na aviacao, sis-temas embarcados crıticos devem apresentar taxasde falhas tao baixas como uma falha grave a cada

105 ate 109 horas de operacao.

A construcao de software para sistemas em-barcados e normalmente mais complexa do quepara outros sistemas computacionais. Em taissistemas, o software tem que se comunicar embaixo nıvel com dispositivos de hardware, devefuncionar por dias e ate anos sem parar mesmoem ambientes hostis (alta temperatura, umidade,vibracao) (Douglass, 2004). Alem disso, ha aslimitacoes de recursos, como memoria e proces-samento, sendo necessarias solucoes para otimiza-cao dos programas, o que nao ocorre em outrossistemas computacionais que dispoem de recursosmais abundantes e nao tem que atender requisitosde tempo real.

Sistemas embarcados crıticos devem seguirnormas elaboradas por associacoes de empre-sas, orgaos governamentais, como por exemplo aRTCA (Radio Techical Commission for Aeronau-tics). Essas normas sao importantes para garantir

a confiabilidade e adequabilidade desse tipo de sis-tema, e mais que isso, equipamentos crıticos naopodem ser comercializados e aplicados sem a suahomologacao por essas normas. Nao basta, por-tanto, projetar e construir um sistema para apli-cacao crıtica que funcione. E preciso que todoo projeto e desenvolvimento sejam baseados emnormas e metodologias que tornem esse equipa-mento comercializavel, e, muitas vezes, esse as-pecto e mais difıcil de ser cumprido do que a tec-nica envolvida na especificacao e implementacaodo sistema.

O desenvolvimento de sistemas embarcadosdemanda, dessa forma, uma metodologia de en-genharia de software diferenciada da adotada parasistemas de informacao (Hugues et al., 2008).Com a criacao do INCT-SEC, (Instituto Nacionalde Tecnologia em Sistemas Embarcados Crıticos),iniciou-se a investigacao de metodologias de de-senvolvimento que possam atender nao somenteas necessidades particulares dessa classe de sis-temas como tambem as necessidades especıficasdas normas e processos de certificacao dos pro-dutos gerados. Neste artigo, apresenta-se comoestudo de caso o desenvolvimento do Tiriba, umaaeronave de baixo custo e propulsao eletrica, to-talmente autonoma, que esta servindo para a val-idacao da metodologia proposta.

Inicialmente estao sendo implantadas as fasesde analise de requisitos, modelagem, simulacao,geracao automatica de codigo e testes de inte-gracao em bancada. Pretende-se gerar codigo quepossa ser certificado, provando-se a sua correcao apartir dos testes efetuados em modelos e a utiliza-cao de ferramentas e codigo basico previamentecertificados. A proxima etapa da metodologia aser abordada e a geracao de casos de teste. Essestestes serao empregados durante duas fases dodesenvolvimento: na simulacao do modelo e nostestes em bancada baseados em um sistema dotipo hardware in the loop.

O restante do artigo esta organizado daseguinte forma: a Secao 2 apresenta alguns traba-lhos relacionados, a Secao 3 apresenta a metodolo-gia proposta, a Secao 4 o estudo de caso e a Secao5 alguns resultados preliminares obtidos na apli-cacao da metodologia. Finalmente, na Secao 6 saoapresentadas as conclusoes e trabalhos futuros.

2 Trabalhos Relacionados

Ha varios processos de desenvolvimento de soft-ware ja estabelecidos, como por exemplo o Pro-cesso Unificado (Kruchten, 2003) e a Progra-macao Extrema (Beck, 2000), que sao predomi-nantemente apoiados pela notacao UML (Uni-fied Modeling Language). Eles fornecem diretrizespara o desenvolvimento disciplinado de software eja estao bem aceitos pela comunidade, havendodisponibilidade de diversas ferramentas e ambi-

entes para dar suporte a sua utilizacao, bem comoliteratura amadurecida e bem conhecida.

No entanto, o desenvolvimento de sistemasembarcados, que anteriormente era visto comopredominantemente voltado ao hardware, temcrescido de forma visıvel, principalmente no to-cante ao desenvolvimento do software envolvido.Ja os processos que apoiam o desenvolvimento desoftware nao tem acompanhado a demanda poressa classe de sistemas, obrigando os desenvolve-dores a realizarem adaptacoes nos processos tradi-cionais, o que nem sempre e apropriado. Existemalguns trabalhos nesse sentido, como por exemplo,o uso de UML voltado a aplicacoes embarcadas(Douglass, 2004; Lavagno et al., 2003; OMG, 2009;Wehrmeister et al., 2005) e ferramentas para pro-jeto de sistemas embarcados baseadas em model-driven engineering (Nascimento et al., 2007).

A geracao automatica de codigo e outro re-curso que tem sido utilizado no desenvolvimentode sistemas embarcados (Stahl and Volter, 2006),porem esse uso tem ocorrido principalmente nageracao da logica da aplicacao a partir de mo-delos (por exemplo statecharts ou diagramas defluxos de sinais). Alem disso, tem sido usadosframeworks especıficos para implementar a infra-estrutura tecnica de sistemas embarcados, comopor exemplo (SCADE, 2009; Microsoft, 2009;Mathworks, 2009). Todos esses recursos tambemtem sido utilizados neste trabalho, mas investiga-se o uso de geradores em outras partes do sistema.Uma das vantagens do uso de geradores, especial-mente se uma arquitetura de linha de produtosfor adotada, e que o software contera apenas aspartes realmente necessarias para o produto es-pecıfico, ao contrario de frameworks, que levamconsigo a implementacao toda, causando proble-mas de espaco, notadamente um problema crıticoem sistemas embarcados.

Como exemplo de trabalho relacionado, aFigura 1 mostra o ciclo de vida da metodologiaSEEP para o desenvolvimento de sistemas embar-cados (Wehrmeister et al., 2005), em que oito eta-pas sao consideradas: modelagem de alto nıvel,exploracao do sistema, exploracao arquitetural,estimativas, compilacao do software e geracao dosistema operacional de tempo real, sıntese da co-municacao, sıntese da micro-arquitetura e plane-jamento dos testes. Em algumas das etapas saorealizadas atividades de validacao, para garantiade qualidade antes de prosseguir o ciclo. Assimcomo na metodologia SEEP, a metodologia pro-posta neste trabalho preocupa-se com a modela-gem de alto nıvel o mais independente possıvel dedecisoes que comprometam a arquitetura do sis-tema, como por exemplo que modulos serao imple-mentados em hardware ou software. No entanto, ametodologia proposta coloca em destaque a qual-idade dos artefatos obtidos, com vistas a certifi-cacao do software.

Figura 1: Metodologia SEEP para sistemas em-barcados (Wehrmeister et al, 2005)

3 Metodologia Proposta

Na definicao da metodologia propostaconsideraram-se as seguintes premissas:

• O ciclo de vida da metodologia deve serbaseado em uma sequencia de fases separadaspor fases de validacao rıgidas, evitando-seao maximo a revisao de uma fase anterior,como e o caso do desenvolvimento iterativoou em espiral, bastante utilizados no desen-volvimento de sistemas convencionais;

• Maximizar o uso de ferramentas para mo-delagem, simulacao e geracao automatica decodigo, visando diminuir o tempo de desen-volvimento e a possibilidade de erros, fa-cilitando a documentacao e os processos decertificacao do codigo gerado, principalmentecom o uso de ferramentas previamente certi-ficadas;

• Maximizar a reutilizacao de codigo com o usode modulos previamente testados e certifica-dos, visando nao somente a diminuicao dotempo de desenvolvimento como tambem odesenvolvimento de famılias de produtos obti-das pela reorganizacao dos blocos basicos eseu mapeamento em novas arquiteturas dehardware;

• Ponderar o uso de programacao e/ou de-senvolvimento orientados a objetos. Apesardas vantagens da orientacao a objetos, suaaceitacao no domınio do software embarcadonem sempre e recomendada, principalmentepelo custo extra em termos de ciclos e area dememoria de programa e dados, como apon-tado por diversas pesquisas (Chatzigeorgiouand Stephanides, 2002; Bhakthavatsalam andEdwards, 2002)

Deve-se ter em mente que os processos de cer-tificacao, como aqueles descritos na norma DO-

178B (RTCA, 2001), sao fortemente calcados nadocumentacao dos processos de desenvolvimentode software e na quantidade e qualidade dos testesutilizados na sua validacao. Tambem deve ser no-tado que para cada produto na classe de sistemasembarcados crıticos deve-se atender um conjuntoespecıfico de normas, que depende nao somenteda area de aplicacao do produto como tambem docliente final e o paıs onde o produto sera utilizado.

As fases da metodologia proposta podem servisualizadas na Figura 2 e sao descritas nas etapasque seguem:

1. Analise de requisitos funcionais e nao fun-cionais: descricao textual em formulario es-pecıfico dos requisitos. Essa etapa deve serconduzida pelo cliente final, com assessoriada equipe de desenvolvimento.

2. Validacao dos requisitos: montam-se matrizesde requisitos que devem ser validadas pordesenvolvedores e engenheiros dos sistemasonde serao utilizados os modulos embarca-dos em desenvolvimento. Deve-se notar queessas matrizes devem servir de base para aelaboracao das rotinas de teste, cujo principalproposito e a validacao funcional desses requi-sitos. Comportamentos observados na fase deteste e nao previstos ou descritos na analisede requisitos sao considerados nao conformi-dades do sistema.

3. Modelagem do sistema utilizando-se umahierarquia de blocos funcionais com espe-cificacao/projeto baseados em algoritmos,maquinas de estado e diagramas de fluxo dedados. A utilizacao mista desses meios deespecificacao em um mesmo modelo visa fa-cilitar a especificacao de cada componente dosistema, utilizando-se a ferramenta mais con-veniente em cada caso.

4. Simulacao e testes funcionais. Constitui avalidacao do modelo resultante da fase ante-rior. Os testes devem ser baseados nos requi-sitos funcionais definidos na etapa 1. Nestaetapa, e importante que tenha sido utilizadauma ferramenta CASE na etapa 3.

5. Geracao automatica de codigo para o hard-ware destino. Nesta fase e definida a arquite-tura de hardware alvo do sistema e efetuadaa particao e alocacao do sistema entre os di-versos processadores da arquitetura destino.Utilizam-se Sistemas Operacionais em TempoReal multitarefas, RTOS (Real Time Operat-ing System). Nesta etapa e necessaria a uti-lizacao de Blocos Basicos de Entrada e Saıda(previamente validados/certificados) para osprocessadores da arquitetura de hardwaredestino, alem dos RTOS mencionados. E im-portante que a geracao de codigo seja feita

Figura 2: Metodologia proposta para o desenvolvi-mento de sistemas embarcados crıticos

de forma completamente automatica visandofacilitar os processos de certificacao segundoas normas aplicaveis (existem normas difer-entes segundo os requisitos de qualidade decada processo/produto). Um exemplo podeser visto na Figura 3.

6. Validacao do codigo gerado utilizando-se, porexemplo, a tecnica hardware in the loop, am-plamente empregada em sistemas embarca-dos. Nesta etapa, e importante utilizar osmesmos testes da etapa 4 (eventualmenteacrescidos de outros que nao poderiam tersido aplicados naquela etapa) e comparar osresultados. Quaisquer discrepancias, mesmoque irrelevantes em relacao a analise de re-quisitos feita na etapa 1, devem ser comple-tamente investigadas, corrigidas e/ou justifi-cadas, podendo induzir a definicao de novasbaterias de teste.

7. Integracao com o sistema final e realizacaodos testes finais de aceitacao, que devem serdefinidos sob coordenacao do cliente final.

4 Estudo de Caso

A metodologia proposta na Secao 3 esta sendoaplicada no desenvolvimento do Tiriba (Figura 4),

Figura 3: Bloco logico e o codigo correspondentegerado de forma automatica

uma aeronave nao tripulada de pequenas dimen-soes, cujas especificacoes principais sao apresen-tadas na Tabela 1.

Tabela 1: Especificacoes basicas da aeronaveTiriba

Propulsion Electric, 1.2KW

Max Takeoff weight 3 Kg

Payload 0.7 Kg

Endurance 40min/1h30min

Cruisier speed 100Km/h/60Km/h

Takeoff hand launch/catapult

Landing Automatic, parachute

Missions Autonomous

Ground Station Smartphone based

Assembly time 10 min

Figura 4: Tiriba - aeronave nao tripulada de pe-quena dimensao

Nesta primeira utilizacao da nova metodolo-gia, espera-se nao somente valida-la quanto a suaaplicabilidade e versatilidade no desenvolvimentode sistemas embarcados crıticos, como tambemverificar a qualidade dos produtos gerados e oimpacto no tempo de desenvolvimento provocadopela sua utilizacao. Espera-se um ciclo de desen-volvimento total de 6 meses para o projeto, in-cluindo o hardware, o software e a aeronave. Umesforco combinado de 2100hs de trabalho foi pre-visto fazendo uso de uma equipe multi-disciplinarincluindo engenheiros e bachareis de computacao,

engenheiros eletronicos, engenheiros aeronauticos,tecnicos em eletronica, materiais compostos e ope-racao de aeronaves nao tripuladas.

Entre diversas opcoes de ferramentas paramodelagem e simulacao de sistemas, optou-sepelo uso neste trabalho do Matlab Simulink(Mathworks, 2009). Esta ferramenta tem semostrado ate o momento perfeitamente adequadapara a metodologia e o tipo de desenvolvimentoproposto, particularmente pela disponibilidade demodulos especıficos para a aplicacao em foco.Para a geracao automatica de codigo tambem estasendo empregado o Simulink. Outras ferramen-tas, entretanto, estao sendo avaliadas, como porexemplo, a SCADE (SCADE, 2009), cuja moti-vacao para utilizacao se da pela geracao de codigocertificado. Nesta direcao foi selecionado o RTOSuCOS (Shi et al., 2008), que esta sendo integradona metodologia permitindo o mapeamento de blo-cos ou conjunto de blocos funcionais, de formaautomatica, em processos do sistema operacional.Um bloco basico de E/S esta em desenvolvimentopara a integracao do Simulink com a famılia deprocessadores utilizados no projeto. A arquite-tura de hardware utiliza 4 processadores em umaplaca unica, conforme pode ser observado no di-agrama de blocos apresentado na Figura 5. Oprimeiro processador, o de missao, e responsavelpelo cumprimento de missoes previamente plane-jadas para execucao pela aeronave. Esse proces-sador tambem e responsavel por toda a comuni-cacao da aeronave com a rede de estacoes de solo,rede esta que esta sendo desenvolvida em um pro-jeto em paralelo. O segundo processador, o decontrole, e responsavel pelo controle de voo daaeronave, aceitando comandos basicos oriundosdo processador de missao e da rede de estacoesde solo. Em uma primeira versao, a rede de es-tacoes em solo e implementada por um transmis-sor de controle por radio. Os dois ultimos pro-cessadores implementam os dois conjuntos prin-cipais de sensores de voo: a unidade inercial in-tegrada a um receptor GPS e um modulo de me-dida do campo magnetico terrestre, responsavelpelo calculo da atitude da aeronave, e a unidadebarometrica, responsavel pela medicao da veloci-dade aerodinamica, altitude barometrica e taxa desubida da aeronave.

A adocao de quatro processadores em um pro-jeto deste tipo teve como motivacao inicial fa-cilitar, em uma primeira etapa, a divisao dastarefas da equipe de desenvolvimento. Maisimportante que isso, entretanto, ela permitede forma imediata o aproveitamento de partesdo sistema como subprodutos, notadamente asunidades barometrica e inercial. Uma segundaversao da arquitetura, consistindo de apenas umprocessador, esta prevista como teste. Esse testevisa averiguar a facilidade proposta na metodolo-gia no que tange a novos mapeamentos de con-

Figura 5: Diagrama de Blocos Simplificado da Ae-ronave

juntos de blocos logicos em novas arquiteturas dehardware.

5 Resultados Preliminares

O estagio de desenvolvimento do projeto, no mo-mento da escrita deste artigo, pode ser sumarizadocomo segue:

• Aeronave projetada, prototipo em fase finalde construcao, voos de teste previstos em 3semanas;

• Hardware do sistema projetado. Montagem etestes em 2 semanas;

• Fase de requisitos completada, modelagemem estagio final e prevista para ser concluıdaem 2 semanas. Alguns blocos ja foram to-tal ou parcialmente testados de acordo com afase 4 da metodologia proposta;

• Geracao de codigo automatica testada,tendo-se feito uma inspecao e avaliacao daqualidade do software produzido em relacaoa construcoes basicas de programa, utiliza-cao de memoria e desempenho esperado. Aconclusao inicial foi bastante favoravel a fer-ramenta utilizada;

• Bloco basico de E/S em desenvolvimento,com prioridade para as funcoes que serao efe-tivamente utilizadas no projeto.

6 Conclusoes

Apresentou-se neste trabalho uma metodologiapara desenvolvimento de sistemas embarcados

aplicada a um sistema para controle de umaaeronave nao tripulada. Pretende-se tambemaveriguar futuramente a adequacao da metodolo-gia na geracao de famılias de produtos, com difer-entes nıveis de complexidade e desempenho. Nocaso do estudo apresentado, o produto consider-ado e um sistema de guiamento e controle au-tomatico. Outros produtos similares poderiamser criados com esforco relativamente pequenofazendo-se uma reorganizacao e novo mapeamentoem hardware dos blocos funcionais desenvolvidos.

Os resultados preliminares indicam que a uti-lizacao da metodologia proposta, alem de propor-cionar maior confiabilidade ao sistema proposto,tambem possibilita uma maior facilidade na ge-racao da documentacao necessaria nos processosde certificacao, por exemplo, aqueles baseadosna norma DO-178B. Como resultado secundario,porem nao menos importante, espera-se uma con-sideravel reducao e flexibilidade no tempo de de-senvolvimento do produto, proporcionada tantopelos ensaios de validacao nos modelos quantopelo processo de geracao automatica de codigo.O desempenho da equipe de desenvolvimento temsido medido, o que permitira uma comparacaodos resultados obtidos em ganho de produtividadecom o desenvolvimento de projetos similares semo uso da metodologia proposta.

Agradecimentos

Os autores agradecem ao CNPq e FAPESPpelo financiamento ao INCT-SEC, processos573963/2008-8 e 08/57870-9.

Referencias

Beck, K. (2000). Extreme Programming Ex-plained: Embrace Change, Addison-WesleyProfessional.

Bhakthavatsalam, S. and Edwards, S. (2002). Ap-plying object-oriented techniques in embed-ded software design, CPES 2002 Power Elec-tronics Seminar and NSF/Industry AnnualReview.

Chatzigeorgiou, A. and Stephanides, G. (2002).Evaluating Performance and Power ofObject-Oriented Vs. Procedural Program-ming in Embedded Processors, ReliableSoftware Technologies-ADA-Europe 2002:7th Ada-Europe International Conferenceon Reliable Software Technologies, Vienna,Austria, June 17-21, 2002: Proceedings,Springer, p. 65.

Douglass, B. P. (2004). Real Time UML: Advancesin The UML for Real-Time Systems, 3 edn,Boston: Addison Wesley.

Hugues, J., Paris, G., Perrotin, M. and Tsio-dras, T. (2008). Using MDE for theRapid Prototyping of Space Critical Sys-tems, 19th IEEE/IFIP International Sympo-sium on Rapid System PrototypingI pp. 10–16.

Kruchten, P. (2003). The Rational Unified Process– An Introduction, 2 edn, Addison-Wesley-Longman, Reading, MA.

Lavagno, L., Martin, G. and Selic, B. (2003). UMLfor Real: Design of Embedded Real-Time Sys-tems, 1 edn, Kluwer Academic Publishers.

Mathworks (2009). Simulink - sim-ulation and model-based design.Available on 2009, May 2 athttp://www.mathworks.com/products/simulink/.

Microsoft (2009). .Net Micro Frame-work. Available on 2009, June 2 athttp://www.microsoft.com/netmf/default.mspx.

Nascimento, F. A. M., Oliveira, M. F. S. andWagner, F. R. (2007). Modes: Embeddedsystems design methodology and tools basedon mde, Model-Based Methodologies for Per-vasive and Embedded Software, InternationalWorkshop on 0: 67–76.

OMG (2009). Uml profile for marte: Mod-eling and analysis of real-time embed-ded systemss. Available on 2009, March27 at http://www.omg.org/docs/ptc/08-06-08.pdf.

RTCA, I. (2001). Final Report for Clarification ofDO-178B – Software Considerations in Air-borne Systems and Equipment Certification.,Technical report, RTCA/DO-248B, 12 Octo-ber 2001.

SCADE (2009). Scade - safety critical appli-cation development environment. Avail-able on 2009, May 2 at http://www.esterel-tecnologies.com.

Shi, L., Cai, G., Huang, J. and Yao, L. (2008). Im-plementation of RTOS 8 mC/OS-II based onSamsung S 3 C 2410 A, Jisuanji Gongchengyu Sheji(Computer Engineering and Design)29(10): 2523–2525.

Stahl, T. and Volter, M. (2006). Model-DrivenSoftware Developmen, 1 edn, Wiley.

Wehrmeister, M. A., Becker, L. B., Wagner,F. R. and Pereira, C. E. (2005). Model-ing with UML Component-Based and AspectOriented Programming Systems, ISORC´05- 8th IEEE Symposium on Object-OrientedReal-Time Distributed Computing, IEEEComputer Society Press pp. 125–128.