Tabela 6.2 Tabela de transição de modo para a classe de modo mcPressure.
Old mode Event New mode
TooLow @T(mWaterPres ≥ Low) Permitted
Permitted @T(mWaterPres ≥ Permit) High
Permitted @T(mWaterPres < Low) TooLow
High @T(mWaterPres < Permit) Permitted
Tabela 6.3 Tabela condicional para a variável controlada cSafety Injection.
Mode Conditions
High, Permitted True False
TooLow tOverridden NOT tOverridden
cSafety Injection Off On
Um operador para cada tabela da especificação e um operador principal chamado de Safety Injection Systemque representa toda a especificação e coordena a comunicação entre os outros nós.
Seguindo a estratégia de verificação, a ferramentaVGSgerou ao todo 48 vetores de teste. Desses, 8 correspondem a vetores da tabela cSafety Injection, 12 da tOverridden e 28 da mcPressure. A Tabela6.4resume os resultados da aplicação da estratégia de verificação no primeiro estudo de caso. Todos os testes gerados foram executadas e passaram com sucesso.
6.2
Sistema de Controle de Cruzeiro
O segundo estudo de caso do presente trabalho é uma versão simplificada de um sistema real de controle de cruzeiro para automóvel adaptado de Heitmeyer et al.(2005). O sistema monitora diversas variáveis do ambiente e usa esta informação para controlar a aceleração do automóvel.
Basicamente, se a ignição estiver ativa, o motor em funcionamento e os freios não acionados, o automóvel entra no modo de controle de cruzeiro movendo a alavanca (mLever) para a posição const . Enquanto estiver no modo de controle de cruzeiro, a velocidade do automóvel determina se o controle de aceleração deve desacelerar, acelerar ou manter a velocidade atual. O motorista anula o controle de cruzeiro se pressionar os freios, reassume o controle se mover a alavanca para a posição resume ou sai do modo se mover a alavanca para off. A Figura6.2, adaptada deHeitmeyer et al.(2005), ilustra como os elementos deSCRforam usados para especificar o sistema. Existem seis variáveis monitoradas e uma controlada, além de uma variável de modo e dois termos. A variável monitorada time representa a passagem de tempo e é útil para o operador DUR presente
6.2. SISTEMA DE CONTROLE DE CRUZEIRO
Tabela 6.4 Resultados do Sistema de Injeção de Segurança.
Safety Injection System
Tabela Testes gerados Testes com Sucesso Porcentagem de Sucesso
cSafety Injection 8 8 100%
tOverridden 12 12 100%
mcPressure 28 28 100%
Total 48 48 100%
Figura 6.2 Especificação do Sistema de Controle de Cruzeiro.
no exemplo. Este exemplo também possui instruções Assertion deSCR, diferentemente do primeiro estudo de caso, que possui apenas uma Assumption.
A especificação é composta ao todo pelas Tabelas6.5,6.6,6.7e6.8. A Tabela de transição de modo 6.5 define como a classe de modo mcCruise muda de estado. A primeira coluna define o estado anterior da classe de modo. A coluna do meio define o evento específico que, caso ocorra, irá fazer com que a classe de modo mude de estado para o estado definido na terceira coluna. As Tabelas6.6e6.7são tabelas de evento e definem o comportamento dos termos dur tDesiredSpeed true time 1 e tDesiredSpeed respectivamente. A Tabela 6.7, diferentemente da 6.6, está condicionada à classe de modo mcCruise, cujos valores são visíveis na sua primeira coluna. Por fim, a Tabela condicional6.8define o comportamento da variável cThrottle. Cada linha da tabela está condicionada ao estado da classe de modo mcCruise, cujos valores são visíveis na sua primeira coluna. O valor que a variável cThrottle receberá está definido na terceira coluna da tabela.
Para a correta geração de vetores de teste pelo T-VEC, foi necessário fazer algumas adaptações na especificação inicial detalhadas abaixo. O Código6.1mostra a especifica- çãoSCRem formato textual referente a tabela da classe de modo mcCruise quando esta está no estado Override.
Relembrando a Seção2.2, na qual é explicado que o One-Input Assumption deSCR define que apenas uma entrada sofrerá alteração entre um ciclo e outro. Como tanto o
6.2. SISTEMA DE CONTROLE DE CRUZEIRO
Tabela 6.5 Tabela de transição de modo para a classe de modo mcCruise.
Old mode Event New mode
Off @T(mIgnOn) Inactive
Inactive @T(mLever=const ) WHILE mIgnOn AND
mEngRunning AND NOT mBrake)
Cruise
Inactive @F(mIgnOn) Off
Cruise @F(mIgnOn) Off
Cruise @F(mEngRunning) Inactive
Cruise @T(mBrake) OR @T(mLever = off) Override
Override @F(mIgnOn) Off
Override @F(mEngRunning) Inactive
Override (@T(mLever = resume) WHILE(mIgnOn
AND mEngRunning AND NOT mBrake)) OR (@T(mLever = const ) WHILE(mIgnOn AND mEngRunning AND NOT mBrake))
Cruise
Tabela 6.6 Tabela de evento para o termo dur tDesiredSpeed true time 1.
Variable Events
@T(mLever = const ) @F(mLever = const )
dur tDesiredSpeed true time 1’ time’ -1.0
TTMquanto oSCADEnão implementam esta premissa deSCR, existe a possibilidade de a variável mIgnOn mudar seu valor para false e a variável mLever mudar seu valor para resume no mesmo ciclo. Se esta situação ocorrer, a especificação entrará em um estado de ambiguidade. Isto é exatamente o caso que ocorre no Código6.1onde não há uma forma determinística de escolher entre os fluxos definidos pelas linhas 3 e 5. Esta situação de ambiguidade ocorre na aplicação de três dos vetores de teste gerados pelo VGSpara a variável mcCruise, fazendo com que os testes falhem. Este problema foi corrigido através da substituição do operador WHEN deSCR, nas seções de código que
1 [ ] t y p e _ m c C r u i s e _ O v e r r i d e 2 ev 3 [ ] @F( mIgnOn ) −> t y p e _ m c C r u i s e _ O f f 4 [ ] @F( mEngRunning ) −> t y p e _ m c C r u i s e _ I n a c t i v e 5 [ ] (@T( mLever = y L e v e r _ r e s u m e ) 6 WHERE( mIgnOn 7 AND mEngRunning
8 AND NOT mBrake ) )
9 OR (@T( mLever = y L e v e r _ c o n s t _ )
10 WHERE( mIgnOn
11 AND mEngRunning
12 AND NOT mBrake ) ) −> t y p e _ m c C r u i s e _ C r u i s e
Código 6.1 Parte do código SCR do Sistema de Controle de Cruzeiro que contém problemas de ambiguidade.
6.2. SISTEMA DE CONTROLE DE CRUZEIRO
Tabela 6.7 Tabela de evento para o termo tDesiredSpeed.
Mode Conditions
Cruise @F(((time - dur tDesiredSpeed true time 1) >
kStartIncr) AND (dur tDesiredSpeed true time 1 != -1.0))
Inactive @T(mLever = const ) WHEN mIgnOn AND
mEngRunning AND NOT mBrake
Off, Override never
tDesiredSpeed’ mSpeed’
Tabela 6.8 Tabela condicional para a variável controlada cThrottle.
Mode Conditions cThrottle’
Cruise (tDesiredSpeed - kTolerance
> mSpeed) OR (((time -
dur tDesiredSpeed true time 1) > kStartIncr) AND
(dur tDesiredSpeed true time 1 != -1.0))
accel
Cruise tDesiredSpeed - kTolerance
<= mSpeed AND tDesiredSpeed + kTolerance >= mSpeed AND (((time - dur tDesiredSpeed true time 1)
<= kStartIncr) AND
(dur tDesiredSpeed true time 1 != -1.0))
maintain
Cruise tDesiredSpeed + kTolerance
< mSpeed AND (((time -
dur tDesiredSpeed true time 1) <= kStartIncr) AND
(dur tDesiredSpeed true time 1 != -1.0)) decel Inactive, Off, Override True off
apresentaram o erro, pelo operador WHILE da ferramentaTTM. A diferença entre os operadores é simples. Em uma expressão da forma
• T(c) WHILE d 6.1
a expressão d deve ser avaliada como verdadeira no ciclo anterior e no atual. No caso de uma expressão similar que usa o operador WHEN, a expressão d deve ser avaliada como verdade apenas no ciclo anterior.
Após a execução do tradutor, foram gerados cinco nós operadores de SCADE. Um operador para cada tabela da especificação e um operador principal chamado de Cruise Control Systemque representa toda a especificação e coordena a comunicação
6.2. SISTEMA DE CONTROLE DE CRUZEIRO
Tabela 6.9 Resultados do Sistema de Controle de Cruzeiro.
Cruise Control System
Tabela Testes gerados Testes com Sucesso Porcentagem de Sucesso
cThrottle 26 26 100%
dur tDesiredSpeed true time 1 8 8 100%
mcCruise 33 33 100%
tDesiredSpeed 10 10 100%
Total 77 77 100%
Tabela 6.10 Elementos deSCRcobertos pelos estudos de caso.
Elementos de SCR Sistema de Injeção de Segurança Sistema de Controle de Cruzeiro
Type X X Constant X X Monitored Variable X X Controlled Variable X X Term Variable X X Mode Class X X Assumption X X Assertion - X Event @T(c) X X Event @F(c) - X Event @C(c) - X DUR - X When X X Condition table X X Event table X X
Mode transition table X X
entre os outros nós.
Seguindo a estratégia de verificação, a ferramentaVGSgerou ao todo 77 vetores de teste. Desses, 26 correspondem a vetores da tabela cThrottle, 33 da mcCruise, 10 da tDesiredSpeede 8 da dur tDesiredSpeed true time 1. A Tabela6.9resume os resultados da aplicação da estratégia de verificação no segundo estudo de caso. Todos os testes gerados foram executadas e passaram com sucesso.
A aplicação da estratégia de verificação nesses dois estudos de caso é apenas uma abordagem preliminar na tentativa de investigar que a tradução gera modelosSCADE em conformidade com a especificação. Portanto, não é a intenção desta abordagem ser uma verificação formal e completa da robustez da tradução. Entretanto, os estudos de caso foram escolhidos de tal forma que pudessem exercitar um número significativo de caminhos do tradutor. A Tabela6.10mostra a cobertura de elementos deSCRque os estudos de caso forneceram. É importante lembrar que, de acordo com as Tabelas6.4e6.9, todos os testes gerados para os dois estudos de caso passaram com sucesso. Isto demonstra que, para estes estudos de caso, as regras são completas e robustas.
7
Conclusão
O presente trabalho propõe uma estratégia de tradução automática que transforma especi- ficaçõesSCRem modelosSCADEatravés do uso de regras de tradução. O trabalho inclui a construção de uma ferramenta tradutora com a implementação das regras de tradução usando o framework Stratego/XT com o auxílio do Spoofax. Para ilustrar a proposta do trabalho, dois estudos de caso encontrados na literatura foram adaptados e traduzidos usando a ferramenta construída. Como uma primeira abordagem de investigação de que a tradução gera modelosSCADEem conformidade com a especificação, propusemos uma estratégia de verificação baseada em campanhas de testes geradas automaticamente pela suíte de ferramentas T-VEC e aplicadas nos estudos de caso do presente trabalho. As campanhas de teste seguiram o critério de coberturaMCDCfocado no padrão DO-178B de desenvolvimento de sistemas críticos aeronáuticos. Os casos de teste foram aplicados no código C gerado pela ferramentaSCADEe todos tiveram êxito, confirmando que o código condiz com a especificação.
Para tornar possível a integração proposta neste trabalho, foi necessário estudar várias tecnologias que não eram conhecidas pelo autor. Tanto o método SCR quanto a suíte SCADE, assim como as tecnologias auxiliares como T-VEC, Spoofax, Stratego/XT e SDF foram estudadas iniciando pelo básico. Apesar de ser um método poderoso para descrição de especificações de sistemas de controle, SCR possui documentação escassa e relativamente poucos estudos publicados. A suíte SCADE, por sua vez, possui uma documentação farta e em nenhum momento se mostrou um obstáculo para a conclusão da pesquisa. O desenvolvimento com Spoofax e Stratego/XT foi penoso, pois as tecnologias possuem uma documentação superficial com seções incompletas. As informações levan- tadas quando ocorre um erro de implementação também são pouco intuitivas dificultando o trabalho do desenvolvedor. Por fim, a linguagem SDF sofre de problemas semelhantes à Stratego/XT: documentação escassa e mensagens de erro pouco intuitivas.
7.1. TRABALHOS RELACIONADOS
Apesar dos obstáculos, as tecnologias escolhidas são viáveis e merecem atenção. Por fim, o objetivo da pesquisa de criar uma forma de gerar modelos SCADE a partir de especificações descritas em SCR foi alcançado. Com a tradução, é possível acelerar o desenvolvimento de sistemas críticos que optem por usar SCR para descrição de especificações aumentando as vantagens de se escolher usar o conjunto SCR e SCADE. A seguir serão apresentados alguns trabalhos relacionados e uma seleção de trabalhos futuros.
7.1
Trabalhos Relacionados
A seguir serão descritos trabalhos que derivam código de modelos SCR, trabalhos que mostram o uso independente deSCReSCADEe trabalhos que também integram dois métodos formais. Não foi encontrada outra pesquisa que proponha a integração entre SCReSCADEpara produzir código certificado a partir de requisitos formais.
Muitos trabalhos propõem a integração entre métodos, como é o caso do trabalho re- portado emVenky et al.(2008), que descreve uma estratégia de tradução de STATEMATE paraSCADEe um processo de validação, auxiliando em diminuir a distância semântica entre as duas ferramentas. Semelhantemente ao trabalho desta dissertação, o trabalho reportado também propõe uma abordagem baseada em testes para investigar o indício de corretude da estratégia de tradução. Outra diferença, fora a diferença dos métodos traduzidos, é que apenas os principais elementos de STATEMATE foram abordados. Na tradução desta dissertação, praticamente toda a gramática de SCR foi abordada com algumas exceções pontuais.
EmCaspi et al.(2003), é apresentada uma abordagem fim-a-fim em camadas para o desenho e implementação de software embarcado em uma plataforma distribuída. A abordagem consiste na integração entre uma camada de alto nível para modelagem e simulação (Simulink), uma camada de nível médio para programação e validação (SCADE / Lustre) e uma camada de baixo nível para execução (TTA). Para passar de uma camada para a próxima, o trabalho fornece algorítimos e ferramentas incluindo uma tradução de Simulink para SCADE/Lustre. Além de não fazer uso de regras de tradução, o trabalho também se diferencia em relação ao desta dissertação pelo fato de não apresentar um processo de verificação ou prova de que a estratégia de tradução entre Simulink e SCADE possui indícios de corretude.
O trabalho reportado emLeonard and Heitmeyer(2003) apresenta duas estratégias de tradução diretas de requisitos formais descritos emSCRpara código C. As estratégias são
7.1. TRABALHOS RELACIONADOS
obtidas através do uso do sistema de transformação de programas APTS (Cai and Paige, 1993). A primeira estratégia usa regras de tradução para transformar a árvore sintática de uma especificação SCR na árvore sintática do código C correspondente. A segunda estratégia de tradução associa uma relação à cada nó dá arvore sintática de SCR. Cada membro desta relação atua armazenando o código C correspondente. O trabalho aplica ambas as estratégias à dois estudos de caso. A principal diferença em relação ao trabalho desta dissertação é que o código C gerado não possui indícios de ser certificado, mas indica este ponto como trabalho futuro. O trabalho também não apresenta uma estratégia de verificação ou prova de que há indícios de corretude na tradução. Outro ponto de diferença é no desempenho da tradução. É possível comparar informalmente o tempo necessário para executar a tradução do trabalho reportado e o desta dissertação, pois os trabalhos possuem um estudo de caso em comum (Safety Injection System). Assim, o trabalho reportado levou cerca de 4 minutos, usando a estratégia mais rápida, para produzir código C enquanto que o trabalho desta dissertação levou alguns segundos para gerar os modelos SCADE e o código C a partir do SCADE.
O trabalho deRothamel et al.(2006) descreve um método para gerar código eficiente a partir de SCR, além de apresentar a implementação e uma avaliação experimental. No final, o trabalho mostra experimentos com sete benchmarks, demonstrando que o método proposto produz melhorias significativas de desempenho no código gerado a partir de especificações extensas. Semelhantemente aLeonard and Heitmeyer(2003) e diferentemente do trabalho desta dissertação, o trabalho deRothamel et al.(2006) fornece uma forma de obter código C não certificado. O trabalho também não apresenta uma estratégia de verificação ou prova de que há indícios de corretude da tradução.
Outros trabalhos também focam na integração de métodos distintos, não necessaria- mente entre SCR e SCADE, fazendo uso de regras de tradução. O trabalho deCataño et al. (2012) apresenta a integração entre os métodos B e JML através da implementação de uma ferramenta tradutora modelada a partir de regras de tradução. O trabalho permite aos desenvolvedores usarem diferentes métodos e ferramentas formais em fases diferentes de um ciclo de desenvolvimento de software. Enquanto B provê forte suporte à verificação de modelos durante as fases iniciais, JML simplifica o trabalho de gerar código JAVA. O trabalho se assemelha à tradução desta dissertação por usar regras de tradução para integrar dois métodos formais distintos, porém o foco da tradução não é obter código certificado como resultado.
7.2. TRABALHOS FUTUROS
7.2
Trabalhos Futuros
Nesta seção serão apresentados alguns trabalhos futuros interessantes para dar conti- nuidade à pesquisa da tradução entreSCReSCADE. Como explicado na Seção4.3, o tradutor ainda é apenas um projeto do Spoofax no Eclipse. Um trabalho futuro interes- sante seria publicar o tradutor como um plugin do Eclipse para que possa ser instalado de forma simples e rápida.
Um segundo trabalho futuro importante seria aplicar o tradutor a estudos de casos reais, complexos e extensos. O uso deste tipo de estudo de caso poderia mostrar problemas de desempenho na tradução que não foram capturados no presente trabalho. Mais interessante ainda seria usar exemplos aeronáuticos que demonstrassem a utilidade da tradução de auxiliar na geração de código C certificado.
Uma das desvantagens consequentes do uso de geradores automáticos de código a partir de modelos, que é o caso do SCADE, é o fato de que o código resultante pode ser ineficiente. Um trabalho futuro interessante seria avaliar se a forma como a estratégia de tradução gera os modelos de SCADE pode implicar em um modelo mais ineficiente além de apresentar possíveis melhorias na tradução que implicassem em modelos mais eficientes. Poderia-se ainda fazer análises de desempenho com o código C gerado pelo SCADE a partir de um modelo traduzido de SCR e comparar os resultados com o trabalho de Rothamel et al. (2006) que propõe a tradução de SCR diretamente para código C eficiente.
Por fim, mesmo que a quantidade de estudos de caso seja significativa, nada garante que em um outro estudo de caso a tradução ocorra sem erros. Para comprovar que as regras estão corretas e que para toda especificação de SCR existirá uma contrapartida em SCADE, levando-se em consideração todas as limitações da tradução descrita no presente trabalho, é necessário que a tradução passe por uma prova formal. Um trabalho futuro importante é provar formalmente que as regras de tradução estão corretas através do uso de UTP (Hoare and Jifeng,1998) como uma semântica comum entreSCReSCADE.
Referências Bibliográficas
Ayav, T., Fradet, P., and Girault, A. (2008). Implementing fault-tolerance in real-time programs by automatic program transformations. ACM Trans. Embed. Comput. Syst., 7(4), 45:1–45:43.
Bravenboer, M., van Dam, A., Olmos, K., and Visser, E. (2005). Program transformation with scoped dynamic rewrite rules. Fundam. Inf., 69, 123–178.
Bravenboer, M., Kalleberg, K. T., Vermaas, R., and Visser, E. (2008). Stratego/xt 0.17. a language and toolset for program transformation. Sci. Comput. Program., 72, 52–70. Cai, J. and Paige, R. (1993). Towards increased productivity of algorithm implementation.
In Proceedings of the 1st ACM SIGSOFT symposium on Foundations of software engineering, SIGSOFT ’93, pages 71–78, New York, NY, USA. ACM.
Caspi, P., Curic, A., Maignan, A., Sofronis, C., Tripakis, S., and Niebert, P. (2003). From simulink to SCADE/Lustre to TTA: a layered approach for distributed embedded applications. SIGPLAN Not., 38, 153–162.
Cataño, N., Wahls, T., Rueda, C., Rivera, V., and Yu, D. (2012). Translating b machines to jml specifications. In Proceedings of the 27th Annual ACM Symposium on Applied Computing, SAC ’12, pages 1271–1277, New York, NY, USA. ACM.
Clarke, E. M. and Wing, J. M. (1996). Formal methods: state of the art and future directions. ACM Comput. Surv., 28(4), 626–643.
Davis, J. F. (2005). The affordable application of formal methods to software engineering. Ada Lett., XXV(4), 57–62.
Halbwachs, N., Caspi, P., Raymond, P., and Pilaud, D. (1991). The synchronous dataflow programming language Lustre. In Proceedings of the IEEE, volume 79, pages 1305– 1320.
Hansen, K. M. and Wells, L. (2006). Dynamic design and evaluation of software architecture in critical systems development. In Proceedings of the eleventh Australian workshop on Safety critical systems and software - Volume 69, SCS ’06, pages 35–44, Darlinghurst, Australia, Australia. Australian Computer Society, Inc.
Heering, J., Hendriks, P. R. H., Klint, P., and Rekers, J. (1989). The syntax definition formalism sdf – reference manual –. SIGPLAN Not., 24(11), 43–75.
REFERÊNCIAS BIBLIOGRÁFICAS
Heitmeyer, C. and Bharadwaj, R. (2000). Applying the SCR requirements method to the light control case study. Journal of Universal Computer Science, 6, 2000.
Heitmeyer, C., Archer, M., Bharadwaj, R., and Jeffords, R. (2005). Tools for constructing requirements specifications: The SCR toolset at the age of ten. International Journal of Computer Systems Science and Engineering.
Heitmeyer, C. L., Jeffords, R. D., and Labaw, B. G. (1996). Automated consistency checking of requirements specifications. ACM Trans. Softw. Eng. Methodol., 5(3), 231–261.
Heninger, K. and (U.S.), N. R. L. (1978). Software requirements for the A-7E aircraft. NRL memorandum report. Naval Research Laboratory.
Hoare, C. and Jifeng, H. (1998). Unified Theories of Programming (Prentice Hall series in computer science). Prentice Hall.
Jackson, D. (2002). Alloy: a lightweight object modelling notation. ACM Trans. Softw. Eng. Methodol., 11, 256–290.
Kelly J., H., Dan S., V., John J., C., and Leanna K., R. (2001). A practical tutorial on modified condition/decision coverage. Technical report.
Lakehal, A. and Parissis, I. (2005). Structural test coverage criteria for lustre programs. In Proceedings of the 10th international workshop on Formal methods for industrial critical systems, FMICS ’05, pages 35–43, New York, NY, USA. ACM.
Lakehal, A. and Parissis, I. (2007). Automated measure of structural coverage for Lustre programs: a case study. In Proceedings of the Second International Workshop on Automation of Software Test, AST ’07, page 12, Washington, DC, USA. IEEE Computer Society.
Leonard, E. I. and Heitmeyer, C. L. (2003). Program synthesis from formal requirements specifications using APTS. Higher Order Symbol. Comput., 16, 63–92.
Lublinerman, R., Szegedy, C., and Tripakis, S. (2009). Modular code generation from synchronous block diagrams: modularity vs. code size. SIGPLAN Not., 44(1), 78–89. Muchnick, S. S. (1997). Advanced compiler design and implementation. Morgan
REFERÊNCIAS BIBLIOGRÁFICAS
Papailiopoulou, V. (2008). Automatic test generation for lustre/scade programs. In Proceedings of the 2008 23rd IEEE/ACM International Conference on Automated Soft- ware Engineering, ASE ’08, pages 517–520, Washington, DC, USA. IEEE Computer Society.
Rothamel, T., Liu, Y. A., Heitmeyer, C. L., and Leonard, E. I. (2006). Generating optimized code from SCR specifications. SIGPLAN Not., 41, 135–144.