UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE AUTOMAÇÃO E SISTEMAS
Henrique Amaral Misson
APPLYING FORMAL VERIFICATION TECHNIQUES TO EMBEDDED SOFTWARE IN UAV DESIGN
Florianópolis 2019
Henrique Amaral Misson
APPLYING FORMAL VERIFICATION TECHNIQUES TO EMBEDDED SOFTWARE IN UAV DESIGN
Dissertação submetida ao Programa de Pós-Graduação em Engenharia de Automação e Sistemas para a obtençăo do Grau de Mestre em Engenharia de Automação e Sistemas.
Orientador: Prof. Dr. Leandro Buss Becker - PGEAS - UFSC
Coorientador: Prof. Dr. Fernando Silvano Gonçalves - IFSC
Florianópolis 2019
Ficha de identificação da obra elaborada pelo autor,
através do Programa de Geração Automática da Biblioteca Universitária da UFSC.
Misson, Henrique Amaral
Applying Formal Verification Techniques to Embedded Software in UAV Design / Henrique Amaral Misson ; orientador, Leandro Buss Becker,
coorientador, Fernando Silvano Gonçalves, 2019. 106 p.
Dissertação (mestrado) - Universidade Federal de Santa Catarina, Centro Tecnológico, Programa de Pós Graduação em Engenharia de Automação e Sistemas, Florianópolis, 2019.
Inclui referências.
1. Engenharia de Automação e Sistemas. 2. Verificação de Sistemas. 3. Métodos Formais. 4. Veículos Aéreos Não-Tripulados. 5. Software Embarcado. I. Buss Becker, Leandro. II. Silvano Gonçalves, Fernando. III. Universidade Federal de Santa Catarina. Programa de Pós-Graduação em Engenharia de Automação e Sistemas. IV. Título.
I dedicate this work to my parents, family and my love for their support and incen-tive.
ACKNOWLEDGMENTS
First of all, I thank God for another achievement. I would like to thank my family, parents, sisters, uncles and grandmothers for their trust, dedication and patience. To my love Georgia, special thanks for your dedication, support and for believing in me.
To all ProVANT project members and the Master’s colleagues for the friendship, companionship, and great moments lived in those years.
To the graduate program in automation engineering and systems (PGEAS) of UFSC by the opportunity, to the Brazilian research agency CAPES for financial support.
I would also like to thank my advisor Leandro Becker and co-advisor Fernando Silvano for the opportunity, knowledge and support during the development of this work.
RESUMO
O desenvolvimento de sistemas considerados safety-critical, como no caso dos Veículos Aéreos Não-Tripulados (VANTs), é uma tarefa que exige altos níveis de garantia dos requisitos funcionais e não funcionais previstos em seu projeto. Devido a complexidade desses sistemas, que envolvem muitas funcionalidades e constante interação com o ambiente externo, onde uma falha em sua operação pode ocasionar consequen-cias graves, a utilização de técnicas de verificação são imprescindíveis para validação desses requisitos, visto que propriedades que descrevem o correto funcionamento do sistema alvo são confrontadas com seu mo-delo atual. Apesar da existência de técnicas eficientes na verificação, muitas vezes a necessidade de complementar essa abordagem é funda-mental para cobrir alguns gargalos deixados por limitações existentes e assegurar a corretude do sistema. Nesse sentido, muitos esforços por parte das comunidades e empresas foram realizados na integração desses métodos de verificação, porém isto ainda é um grande desafio. Com isto, um processo de verificação que envolve técnicas como model checking, runtime verification e análise do comportamento do software são previstas na proposta deste trabalho. Com intuito de aplicar essa abordagem, um projeto de Veículo Aéreo Não Tripulado (VANT) é uti-lizado como caso de estudo, na qual o foco principal é a validação do escalonamento de tarefas do software envolvido.
Palavras-chave: Verificação de Sistemas, Model Checking, Runtime Verification, VANT, Sistemas Safety-critical, Software Embarcado
RESUMO EXPANDIDO
Introdução
Nos últimos anos, a demanda por novas tecnologias tem crescido com intuito de facilitar a vida das pessoas e tornar os processos mais efi-cientes. Como exemplos dessas novas tecnologias, podemos citar os carros autônomos e VANTs, na qual o último vem se destacado de-vido à sua enorme gama de aplicações em diversos campos, como civil, comercial e militar. Esses sistemas são chamados de sistemas safety-critical, aos quais dependem fortemente de restrições temporais em seu processamento e onde uma falha em sua operação pode levar a con-seqüências graves, como perdas materiais e econômicas, destruição do meio ambiente e até a perda de vidas humanas.
Considerando a natureza crítica desses sistemas, garantias de confia-bilidade e segurança desses são um fator crucial durante seu desen-volvimento. No entanto, essas garantias são um grande desafio para as indústrias, isso devido à seus projetos envolverem diversas funcional-idades, além da iminência na utilização de novos e poderosos proces-sadores e componentes que o tornam ainda mais complexo. Outro fator que contribui para essa dificuldade é a falta de ferramentas e integração entre as etapas em sua produção.
Nesse sentido, métodos formais são amplamente utilizados e desem-penham um papel importante no ciclo de desenvolvimento, ao qual envolve provas matemáticas como na técnica de theorem proving ou model checking, que é uma técnica de natureza estática, ou seja, não depende da execução do código, e exaustiva baseada na exploração do espaço de estados do modelo. Nesta última técnica, o modelo descreve o comportamento e as características essenciais da operação do sistema e este é confrontado com propriedades formalizadas com base nos re-quisitos iniciais do projeto. Essa verificação visa garantir que sempre o sistema corresponde com aquilo que é esperado pelo cliente.
Entretanto, apesar de serem técnicas eficientes, sua utilização para sis-temas críticos pode levar a algumas limitações. Dentre essas desta-camos a dificuldade na modelagem que reflete realmente seu compor-tamento o que exige grande experiência do time de desenvolvimento, além de que em alguns casos esse modelo é tão complexo que seu es-paço de estados tende a crescer exponencialmente, dificultando assim sua análise por parte das ferramentas.
de apenas um método não garante a corretude do sistema alvo. Por isto, análises adicionais devem ser adotadas para elevar a confiabilidade do produto.
Uma dessas técnicas adicionais que vem ganhando destaque nos últi-mos anos é o Runtime Verification. Esta tem a natureza dinâmica, ou seja, requer a execução do código da aplicação e tem como base seu monitoramento e verificação em tempo de execução. Essa verificação é realizada por meio de entidades computacionais chamadas monitores que são geradas à partir de especificações e requisitos do projeto. Como resultado, os monitores emitem vereditos de satisfação ou violação de acordo com a análise da aplicação.
Com isto, o principal objetivo do processo de verificação é identificar comportamento indesejados do sistema nas fases iniciais do desenvolvi-mento, o que reduz custos e retrabalho do time, além de garantir que o produto final esteja de acordo com o que foi concebido.
Objetivo
Esta dissertação tem como objetivo prover contribuições ao processo de verificação para sistemas críticos. A metodologia proposta visa integrar diferentes técnicas e métodos de verificação existentes tanto de maneira estática, ou seja, sem execução de código, quanto de maneira dinâmica durante essa execução. Além disto, ferramentas que permitem visu-alizar o comportamento da aplicação e obter dados mais precisos sobre este foram adotados. Para demonstrar a viabilidade desse processo, a aplicação dessas técnicas foi realizada no projeto de desenvolvimento de um VANT e com foco principal em resolver o problema de escalo-nabilidade de tarefas.
Metodologia
O processo de verificação proposto nesta dissertação foi baseado na revisão e atualização do trabalho desenvolvido por (GONÇALVES, 2018) no escopo do projeto.
A metodologia proposta na tese de Gonçalves tem como objetivo in-tegrar as etapas de modelagem funcional, arquitetural e verificação de um VANT. Para isto, ferramentas de transformação de modelos foram desenvolvidas automatizando o processo e onde as principais caracterís-ticas do sistema eram mantidas em cada etapa.
A integração entre a modelagem arquitetural em AADL e o modelo ge-rado em autômatos foi suportada pela ferramenta ECPS Verifier (GONÇALVES
et al., 2017). Esse modelo em autômatos temporizados é utilizado para aplicação da técnica de verificação formal Model Checking, na qual o modelo que representa o sistema alvo é confrontado com as propriedades que se esperam que esse sistema atenda formalizadas na linguagem apropriada. Essa etapa de verificação foi realizada através da ferra-menta UPPAAL.
O processo de verificação apresentado nesta dissertação é composto por 4 etapas, sendo a primeira etapa, a verificação descrita anteriormente. O segundo passo é suportado por ferramentas de rastreamento, onde a aplicação real é executada, e seu comportamento e respectivos eventos gerados são gravados e exportados para um arquivo. Com isto, é pos-sível analisar de forma precisa os dados e informações do software que servem como entrada para a etapa seguinte.
A etapa 3 visa aplicar novamente a técnica de Model Checking uti-lizando o UPPAAL, porém com dados mais confiáveis sobre a execução da aplicação alvo obtidas na etapa anterior. Além desses dados, o mo-delo é revisado e refinado à partir do momo-delo desenvolvido na primeira etapa e do comportamento observado pela ferramenta de rastreamento. Novas propriedades são escritas para a avaliação.
Como última etapa da metodologia, a técnica de verificação dinâmica é recomendada para complementar a abordagem estática que sofre com algumas limitações, principalmente quando se trata de sistemas com-plexos. Para isto, a técnica de Runtime Verification é utilizada. Con-tudo, no presente trabalho, apenas uma parte da técnica foi implemen-tada, sendo esta a geração dos monitores que devem ser integrados ao sistema.
Resultados e Discussão
Os resultados obtidos no presente trabalho estão relacionados à apli-cação dos métodos propostos na metodologia desenvolvida e apresen-tada no capítulo 4. Para isto, o software embarcado de um VANT foi utilizado como sistema alvo.
As análises feitas nas etapas 1 e 2 mostram uma divergência entre o modelo gerado à partir da AADL e o código real da aplicação do VANT, na qual as threads de sensoriamento e atuação foram modeladas juntas e na realidade elas são independentes. Além disto, os tempos de computação utilizados na etapa 1 não são fiéis àqueles encontrados pelas ferramentas de rastreamento.
Esses novos dados foram fundamentais para o refinamento do modelo e aplicação da verificação estática na etapa 3, que mostrou que o conjunto
de threads do software é escalonável de acordo com as propriedades avaliadas. No entanto, algumas propriedades não foram satisfeitas du-rante essa abordagem, isto devido à alguns fatores, como dificuldade em expressar corretamente uma especificação em linguagem formal ou na representação do modelo inerente à sua complexidade, o que motivou na aplicação de uma técnica complementar de Runtime Verification. Para tal, monitores foram gerados com intuito de observar a execução do código e verificar a satisfação ou violação das propriedades de tempo real. A integração desses monitores na real aplicação é prevista nos tra-balhos futuros.
Considerações Finais
Nesta dissertação de mestrado, a proposta de um processo de verifi-cação de software embarcado foi apresentada e aplicada em um projeto de VANT. Esta proposta é baseada em uma revisão e complemento do método desenvolvido por Gonçalves (2018). Neste último, foi apresen-tada uma metodologia de desenvolvimento de Cyber-Physical Systems, além da integração da etapa de verificação formal através da técnica de Model Checking. Esta etapa é suportada pela transformação de modelos entre a modelagem arquitetural descrito em AADL para autô-matos temporizados, que permite a verificação estática utilizando a ferramenta UPPAAL.
Com o objetivo de cobrir algumas lacunas deixadas na primeira abor-dagem como a violação de algumas propriedades importantes e a ocor-rência da explosão de estados, uma nova metodologia composta por 4 etapas foi proposta para assegurar segurança, confiabilidade e a corre-tude do sistema, ou seja, seu correto funcionamento de acordo com o previsto no ínicio do projeto.
Para isso, uma primeira rodada de verificação realizada por Goncalves em sua tese, ferramentas de rastreamento são aplicadas com intuito de compreender o comportamento da execução real do código e coletar dados mais precisos das características de tempo real do conjunto de threads relacionados ao sensoriamento, controle e atuação do VANT. Essa foi uma das contribuições adicionadas a esse processo, que ajuda enormemente na aplicação da segunda rodada de verificação estática, na qual foram gerados novos modelos em autômatos temporizados, re-presentando mais fielmente o software a ser verificado.
Com isto, a avaliação das propriedades consideradas implícitas, ou seja, correspondem àquelas mais gerais de uma aplicação e podem ser usadas em vários contextos, como a propriedade que avalia a ausência de
dead-lock, e as especificações consideradas explícitas, que são mais específicas do sistema alvo, foi realizada . Como nosso foco principal é a análise de escalonamento, os resultados obtidos nesta etapa nos mostram que os threads cumprem seus respectivos prazos (deadlines) levando em conta as características comportamentais capturadas na análise de rastreio. No entanto, como em sistemas críticos as restrições de tempo devem ser garantidas, onde um pequeno detalhe pode levar a sérias conse-qüências, e levando em conta as limitações da verificação estática como propriedades não verificadas, uma abordagem dinâmica onde o sistema é constantemente monitorado por entidades chamadas monitores tam-bém é prevista. Esses monitores emitem veredictos de satisfação ou violação de acordo com propriedades que os deram origem.
Um ponto importante a ser considerado é que, embora o contexto atual seja o desenvolvimento de um VANT, o processo de verificação proposto pode ser usado em aplicações em vários domínios e, o sucesso da sua implementação depende em grande parte da experiência da equipe de desenvolvimento.
Palavras-chave: Verificação de Sistemas, Model Checking, Runtime Verification, VANT, Sistemas Safety-critical, Software Embarcado
ABSTRACT
The development of safety-critical systems, as in the case of Unmanned Aerial Vehicles (UAVs), is a task that requires high levels of assurance of the functional and non-functional requirements expected in its project. Due to the complexity of these systems, which involve many function-alities and constant interaction with the external environment, where a failure in its operation can cause serious consequences, the use of verification techniques are crucial to validate these requirements, since properties that describe the correct functioning of the target system are confronted with its current model. Despite the existence of efficient verification techniques, often the need to complement this approach is fundamental to cover some gaps left by existent limitations and en-sure system correctness. In this sense, many efforts by communities and companies have been made in integrating these verification meth-ods, but this is still a great challenge. With this, a verification process involving techniques like model checking, runtime verification and anal-ysis of software behavior are foreseen in the proposal of this work. In order to apply this approach, a UAV project is used as a case study, where the main focus is to validate the scheduling problem of the in-volved software.
Keywords: System verification. Model Checking. Runtime Verifica-tion. UAV. Safety-critical systems, Embedded Software
LIST OF FIGURES
Figure 1 Schematic view of model checking technique. . . 8
Figure 2 Simple Kripke Structure example. . . 10
Figure 3 Evaluation of LTL propositions. . . 12
Figure 4 Evaluation of CTL formulae.. . . 13
Figure 5 Gate template by train-gate example in UPPAAL. . . 16
Figure 6 Verifier view on UPPAAL. . . 17
Figure 7 Schematic view of RV technique. . . 20
Figure 8 Rmtld3synth and Rtmlib overview. . . 25
Figure 9 UAV Design method workflow.. . . 31
Figure 10 Goncalves’s Design Process Flow. . . 31
Figure 11 Proposed Design Process Flow. . . 34
Figure 12 ECPSVerifier design flow. . . 41
Figure 13 Provant Simulator with UAV2.0 model. . . 42
Figure 14 VTOL UAV project design. . . 46
Figure 15 Embedded System Architecture. . . 46
Figure 16 Evaluation Process on the 1st round of MC. . . 49
Figure 17 Scheduling Evaluation from ECPS Verifier. . . 50
Figure 18 Template of thread in UPPAAL. . . 51
Figure 19 Tracing step’s workflow. . . 52
Figure 20 Execution view in SystemView tool. . . 54
Figure 21 Report View of Tracealyzer. . . 55
Figure 22 Trace View in Tracealyzer . . . 56
Figure 23 CPU Load Graph in Tracealyzer. . . 57
Figure 24 Details window in Tracealyzer. . . 57
Figure 25 Thread model on UPPAAL. . . 60
Figure 26 Parameters declaration on UPPAAL. . . 60
Figure 28 Simple buffer model on UPPAAL. . . 61
Figure 27 Scheduler model on UPPAAL. . . 61
Figure 29 Mutex structure on UPPAAL. . . 62
Figure 30 Classification of verified properties. . . 65
LIST OF TABLES
Table 1 Related Works and their methods and case study em-ployed . . . 30 Table 2 Proposal Instantiation . . . 39 Table 3 UAV software set of threads . . . 48 Table 4 Real-time parameters of UPPAAL thread . . . 50 Table 5 Timing of threads execution on SystemView . . . 54 Table 6 Results of the software analysis. . . 58
LIST OF ACRONYMS
UAV Unmanned Aerial Vehicle . . . 1 CPS Cyber-Physical Systems . . . 1 UFSC Universidade Federal de Santa Catarina . . . 2 UFMG Universidade Federal de Minas Gerais . . . 2 MDE Model-Driven Engineering . . . 2 RTS Real-Time Systems . . . 6 EDF Earliest Deadline First . . . 7 RM Rate Monotonic . . . 7 DM Deadline Monotonic . . . 7 MC Model Checking . . . 7 IEC International Electrotechnical Commission . . . 7 ESA European Space Agency. . . 7 TS Transition System. . . 10 LTL Linear Temporal Logic . . . 10 CTL Computation Tree Logic . . . 10 DREAM Distributed Real-time Embedded Analysis Method . . . 14 DRE Distributed Real-time Embedded . . . 14 DSML Domain-specific Modeling Language . . . 14 DTMC Discrete-Time Markov Chain . . . 14 PTA Probabilistic Timed Automata . . . 14 PCTL Probabilistic Computation Tree Logic . . . 14 CSL Continuous Stochastic Logic . . . 14 TA Timed Automata . . . 15 TCTL Timed Computation Tree Logic . . . 16 BDD Binary Decision Diagram . . . 19 RV Runtime Verification . . . 19 API Application Programming Interface . . . 21 SUO System Under Observation . . . 21 MTL Metric Temporal Logic . . . 22 STL Signal Temporal Logic . . . 22 RTOS Real Time Operating System. . . 25 PVS Prototype Verification System . . . 27
BMC Bounded Model Checking . . . 28 USV Unmanned Surface Vehicles . . . 28 S3 Systerel Smart Solver . . . 28 HLL High Level Language . . . 29 LLL Low Level Language . . . 29 AADL Architecture Analysis Design Language . . . 29 TTS Timed Transition System . . . 29 HIL Hardware-In-The-Loop . . . 41 ROS Robotic Operating Systems . . . 42 VTOL-CPVertical Take-Off and Landing Convertible Plane . . . 45 ESC Electronic Speed Control . . . 46 BCET Best Case Execution Time . . . 59 WCET Worst Case Execution Time . . . 65
CONTENTS
1 INTRODUCTION . . . 1 1.1 PROJECT SCOPE . . . 2 1.2 OBJECTIVES . . . 3 1.3 OUTLINE . . . 3 2 RELATED CONCEPTS AND TECHNIQUES . . . 5 2.1 SYSTEM VERIFICATION . . . 5 2.2 MODEL CHECKING . . . 7 2.2.1 Specification Language . . . 9 2.2.2 Model Checkers . . . 14 2.2.3 UPPAAL Model Checker . . . 15 2.3 RUNTIME VERIFICATION . . . 19 2.3.1 Specification Languages . . . 21 2.3.2 Runtime Verification Tools . . . 23 2.3.3 Rmtld3synth Toolchain . . . 24 3 RELATED WORKS . . . 27 3.1 DISCUSSION FROM PREVIOUS WORKS . . . 29 3.2 THE PROPOSAL FROM GONCALVES . . . 30 4 PROPOSED VERIFICATION PROCESS TO
EMBED-DED SOFTWARE . . . 33 4.1 PROPOSAL DETAILS . . . 34 4.2 PROPOSAL INSTANTIATION . . . 39 5 APPLYING THE VERIFICATION PROCESS IN UAV
DESIGN . . . 45 5.1 SYSTEM UNDER EVALUATION . . . 45 5.2 STATIC VERIFICATION - 1ST ROUND . . . 48 5.3 TRACING ANALYSIS . . . 51 5.4 STATIC VERIFICATION - 2ND ROUND . . . 58 5.5 DYNAMIC VERIFICATION . . . 66 5.6 SUMMARY . . . 69 6 CONCLUSIONS . . . 71 6.1 FUTURE WORKS . . . 72 References . . . 73
1
1 INTRODUCTION
Over the last few years, the demand for new technologies has been growing very intuitively to make life easier for people and to make processes more efficient. As examples, it is highlighted autonomous cars and UAVs, that have been standing out due to enormous range of applications in diverse fields like civil, commercial and military.
Those systems are called Cyber-Physical Systems (CPS), as they involve constant interaction with the surrounding environment and in most cases execute in autonomous mode of control (LEE; SESHIA, 2015). Typically, such systems are also viewed as safety-critical systems, in which a failure in its operation can lead to terrible consequences such as material and economic loss, destruction of the environment and even loss of human life (KNIGHT, 2002).
Considering this, guarantee for high levels of reliability and safety of these systems is a crucial factor to ensure their proper functioning. In this sense, the use of verification techniques is a natural approach to guarantee expected functional and non-functional requirements on the design application (HUTH; RYAN, 2004).
Despite significant efforts in integrating processes that encom-pass several verification techniques in the life cycle of these critical systems, it is still a major challenge for industries mainly due to the in-herent complexity of its design processes regarding the various function-alities introduced and the emergence of new and powerful processors and components, and the lack of tooling support for such integration and verification (WOODCOCK; BANACH, 2007).
For the verification purpose, formal methods are widely used and play an important role in development cycle, that involves mathemati-cal proofs like theorem proving or model checking, which is a static and exhaustive technique. In the latter technique, a model that describes the behavior and essential characteristics of the system is confronted with properties aiming to ensure the evaluation and validation of the related specifications.
However, due to the complexity of these systems, or even by the limitation in the expressiveness of the language used, some of the properties are not satisfied or even partially fulfilled in the case of complex model designing, the use of just one verification technique is not enough to ensure strong evidences of the system correctness (BAIER;
KATOEN; LARSEN, 2008). Henceforth, additional analysis are required
2
Complementary techniques like runtime verification (LEUCKER;
SCHALLHART, 2009), a dynamic technique that deals directly with the
real software of the target is gaining a lot of attention in the commu-nity and are being adopted by many designers in order to ensure the correctness of the system.
It is important to point out that although the verification process has been improved and new techniques have emerged, this is not a trivial task, requiring n experienced team of developers, mainly for activities of representation of the system during modeling.
Considering all motivations related above, the main objective and relevance of the verification process is to identify unwanted be-haviors of the target earlier in the development process phases, which reduces costs and rework time, and increase system’s reliability levels.
1.1 PROJECT SCOPE
This present work is conducted in a project named ProVant1,
whose objective regards the autonomous UAV design. ProVant project was created in 2012 from Federal University of Santa Catarina (UFSC) in partnership with Federal University of Minas Gerais (UFMG).
Since its creation different studies and researches have been made, covering different UAV design phases such as complex design of control systems, long term communication, artificial intelligence, and design of complex embedded systems.
Regarding the embedded systems design, especially the UAV projects a design method was created aiming to guide the different design teams during the project construction (GONÇALVES; RAFFO;
BECKER, 2016). This method is composed by a set of phases and
activities and aims to properly cover the required UAV characteristics representation. It is based on MDE (Model-Driven Engineering) and envisage the construction of complementary representations for map-ping the characteristics of the application.
For this purpose, tools were developed in the project scope to support the integration of stages during the life cycle, such as model transformation tools that aim to automate the generation of new rep-resentations based on their input data.
Regarding the method activities, the system verification and val-idation is defined as one activity aiming to ensure the system require-ments evaluation and validation. In this way, studies have been made
3
to evaluate the recommended approach to be applied in this process. The current project, a version 4.0 of the UAV with VTOL-CP configuration is in progress and aims at the search and rescue mission. Older projects like versions 1.0, 2.0 and 3.0 have been successfully de-veloped and serve as the basis for the current.
1.2 OBJECTIVES
The objective of this Master Thesis is to present the proposal of a formal verification process for safety-critical systems, mainly applied to embedded software in UAV design.
In order to apply the process, some specific activities need to be performed as described below:
1. Research on verification processes for critical systems and revision of the method proposed by Gonçalves (2018).
2. Proposal of a verification methodology of systems that involve static and dynamic verification, in addition to behavior analysis of the target application.
3. Application and analysis of the software of a UAV through tracing tools.
4. Modeling a UAV software behavior in timed automata, formal-ization of properties in TCTL language and application of model checking.
5. Generation of monitors to apply runtime verification of an UAV.
1.3 OUTLINE
The first chapter introduces the context of application and im-portance of verification used in safety-critical systems design, its prob-lems and challenges, in addition to the project scope and objectives proposed in this present work.
• Chapter 2 discusses characteristics of real-time systems, con-cepts, methods and tools related to system verification which are divided into static and dynamic approaches;
4
• Chapter 3 presents the state of the art of the methods most used in the verification phase, besides the description and analysis of works related to our context. An integration methodology of the formal verification stage proposed in our project previously is also presented, in which the present work was inspired;
• Chapter 4 outlines the description of the verification process with the details of the proposed steps, as well as the instantiation of this process in our context that introduces its application and tools used.
• Chapter 5 presents the application of the proposed process, its integration in the methodology and discussion of obtained results in context of the UAV development.
5
2 RELATED CONCEPTS AND TECHNIQUES
Real-time applications are characterized mainly by the need to meet the temporal requirements that can be imposed by both the en-vironment and the architecture used. According to Farines, Fraga e Oliveira (2000) most real-time systems are designed and implemented with conventional verification and implementation tools.
Formal modeling and verification are important steps in an at-tempt to ensure that the system will behave in a safe and early manner
(BERGERON, 2012). With mathematical methods, there is an
exhaus-tive sweep of the behavioral possibilities of the system, obtaining a mathematical result guaranteeing that some event may or may not happen. However according to the complexity of the system and its size, the number of possible states can grow exponentially and make it impossible to verify.
In this chapter the concepts and definitions of system verifica-tion are presented. Related to system verificaverifica-tion, main techniques are covered, its languages and tools, the state of the art and related works about this subject is also portrayed.
2.1 SYSTEM VERIFICATION
System verification is one of the phases performed during the life cycle of a product. This phase aims to check whether the current target system, in different stages, meets their requirements planned in the beginning. The verification process can be applied in different ways and using several techniques.
Formal Verification (ONEM; GURDAG; CAGLAYAN, 2008) is the act of proving or disproving the correctness of a system with respect to a certain formal specification or property, where the possible behavior of the system is checked against the desired behavior. This consists in a static analysis of the set of possibles scenarios represented by an abstract mathematical model and providing a formal proof based on the predefined requirements.
Verification techniques can be used in several stages during the system design. When in earlier stages, the models to be verified are con-structed from the specifications and requirements, and in later stages, these models can be developed from the generated code. These mod-els are normally represented by transition system which it is composed
6
by a set of states that represents the system behavior or its operation mode, and transitions which are structures describing the activities or required conditions to change the system states. This network of states and transitions represent the system behavior, where for each transi-tion it is possible to define a set of rules and conditransi-tions that the system must meet to enable state changes.
This process can be applied in the development of various appli-cations and in different areas, but is mainly used for systems consid-ered safety-critical systems, where real-time system characteristics are involved.
Real-Time Systems (RTS) are systems imposed by temporal con-straints, i.e, they must execute their computation respecting the time pre-determined. According to Laplante et al. (2004), RTS is one whose logical correctness is based on both the correctness of the outputs and their timeliness.
In order to understand how these systems work, some impor-tant concepts and characteristics need to point out about real-time. Normally RTS are those that involve computational processes, such as embedded systems and reactive systems.
A task, which is a code segment that can be a function, a thread or any section of a program, has some attributes. These attributes are: a period, which is a portion of time that defines when the task is ready to execute; a computation time, which is the duration time of task execution; and a deadline, which is the most important attribute and it means the maximum instant for the task job conclusion. The task periodicity is determined by the attribute period and it can be periodic, when there is a fixed period, or aperiodic, which the jobs are released at arbitrary time intervals with no fixed period, and sporadic, which is similar to aperiodic tasks, but there is a minimum interval between two arrivals (KOPETZ, 2011).
The scheduler is a structure that deals with the task scheduling on the resources, such as the processor. Scheduling consists of deciding the order of a set of tasks with certain known characteristics (period-icity, duration) on a limited set of processing units (BALARIN et al.,
1998).
In order to perform the scheduling, it exists several policies im-plemented through algorithms that determine which task can execute first, if it is ready on the queue. Considering these algorithms, there are policies non-preemptive, i.e, the processing of any task cannot be interrupted by a request for any higher priority task, and preemptive, in which the executing task may be interrupted, if a more urgent task
7
requests. In addition, another possible classification is with respect to the scheduler’s decisions during execution or before execution. These are called static, when the scheduler makes compile-time decisions, and dynamics, when the scheduler decides which task will be executed dur-ing execution. Among the most used policies, we can highlight Earliest Deadline First (EDF), Rate Monotonic (RM) which is widely used due to its efficiency and considers the task of highest priority being the one with the shortest period, and Deadline Monotonic (DM) (KOPETZ, 2011).
As previously described, the main feature of a real-time system is its temporal requirements, that is, it should not only respond correctly to system inputs, but it must do so within a specified amount of time, otherwise it can lead to consequences that can be disastrous.
The need of conceiving reliable RTS and ensures high levels of correctness is crucial for the properly operation of the system.
For this, some formal verification approaches are adopted by the specialists mainly to check if temporal properties are hold during system execution or if the task set is schedulable.
Theorem proving (COOK, 1971), which is a deductive method
that produce formal mathematical correctness proofs using theorem provers to provide inductive arguments, and the Model Checking (MC), a exhaustively and automatic verification technique, are some of applied static methods.
2.2 MODEL CHECKING
Model Checking (CLARKE; EMERSON, 1981) is a static, auto-matic and exhaustive technique of formal verification, where the sys-tem abstract model is checked against properties written in a formal language.
According to Baier, Katoen e Larsen (2008), this formal proce-dure is one of the "highly recommended" technique for software de-velopment of safety-critical systems according to the best practices standard of the IEC1(International Electrotechnical Commission) and
standards of the ESA2 (European Space Agency).
Aiming to perform MC, a set of activities are required as shown in Fig 1. Basically, desired properties are formalized taking into account the system requirements, and generate a model representing the system
1http://www.iec.ch
8
behavior. So the verification is applied by confronting the model and the desired properties exploring exhaustively the complete state space of a system to search for flaws or bugs (TUAN; ZHENG; THO, 2010).
Figure 1 – Schematic view of model checking technique.
Requirements System
System model Property
specification
satisfied counterexample violated +
Formalizing Modeling
Simulation
location error Model Checking
Source: Baier, Katoen e Larsen (2008).
As previously highlighted, to perform MC, three main steps are required being described as: modeling; formalization of expected prop-erties; and evaluation process by using MC. This steps are summarized here.
• Modeling: Modeling behavior typically involves using mathe-matical equations or graphs. It is common the use of modeling languages like Finite State Machines, Timed Automata or Petri Nets in order to describe the system’s behavior by a set of states and transitions.
• Formalization of expected properties: This step define the representation of expected system properties in a formal way, in order to support the MC evaluation. However, translate these properties from the requirements written in natural language to a formal representation is not an simple task, and requires a large experience of the design team.
To make a verification possible, properties should be described in a precise and unambiguous manner. This is typically done
9
using a property specification language. As examples of formal language for MC that use temporal logic such as LTL (Linear Temporal Logic) (PNUELI, 1977) or CTL (Computation Three Logic) (CLARKE; EMERSON, 1981). Formal languages are
repre-sented by expressions using a set of strings of symbols together that allow to express properties in terms of the time. This is very important to understand the behavior of the system under verification during the time variation.
The difference between LTL and CTL is that the first has a linear time and express properties in a single path. On the other hand, CTL has branching time and can express properties on multiple paths.
There are several ways to express property using temporal logic, and to facilitate this work, these properties can be classified ac-cording to what is intended. It allows for the specification of a broad range of relevant system properties such as reachability, safety, liveness, real-time properties, among others.
• Verification: Once designed the abstract system model and the system properties formalized, verification should be performed. In this way, these elements will be confronted by the a tool named model checker that executes algorithms to evaluate and validate the proposed specification. This is an automatic and exhaus-tive process, where the property to be verified is submitted to all possible state combinations, providing as output the signal-ization regarding if that property is satisfied or a counterexample is generated in case it is not satisfied.
As a result, the model checker will indicate whether the model satisfies or violate the specification. In case of violation, a counterex-ample is given and then the designer can simulate the model in order to locate the error and take the best action to correct the system misbe-havior, that is, inconsistencies between the modeled behavior and the defined specification.
2.2.1 Specification Language
The specification of the desired properties is an important part which allows the model checker engine to verify automatically the tar-get model. These properties are formally defined using mathematical expressions, formal grammar, and temporal logic that can express some
10
essential behavior of the system analyzed. Normally, formal languages are used to avoid some misinterpretation of the requirements, which is very likely to happen in natural language.
In order to understand how formal languages represent system’s behavior, some notions and definitions about the representation of the system are presented.
Most part of concurrent systems can be modeled by using finite Kripke structure (KRIPKE, 2007), which is a transition system (TS) formed by states and transitions as explained previously, and a labelling function consisting in a set of properties that hold in the corresponding state (Figure 2). These properties are described by a set of atomic propositions (AP ) that can characterize some behavior of the system.
Figure 2 – Simple Kripke Structure example.
Considering AP as the set of atomic propositions, the kripke structure of a system can be defined by a quadruple (S, I, R, L), where
• S is a finite set of states. • I ⊆ S is the set of initial states. • R ⊆ SxS is the transition relation.
• L: S → 2AP is the labeling function, which it maps each state s
to a subset of AP.
In the context of MC technique, let M be a kripke structure (the system model), and considering f be a formula of temporal logic (the desired property), the problem is to find all states s of M such that M,s |= f (CLARKE, 2008).
For the purpose of formalizing the properties, there are two main specification languages widely used: Linear Temporal Logic (LTL)(PNUELI, 1977) and Computation Tree Logic (CTL)(CLARKE; EMERSON, 1981). These languages are based on temporal logic, that deals with propo-sitions in terms of time. Here, the word "temporal" relates with the order of occurrence of events in the TS, not the notion of real-time behavior (BAIER; KATOEN; LARSEN, 2008).
11
• Linear Temporal Logic: the LTL is a temporal logic formalism for specifying and verifying properties of reactive systems. It deals with an infinite sequence of states, that represents the system behavior, where each point in time has a unique successor, based on a linear-time perspective.
The time is modeled as this sequence of states, called path, that is extending infinitely into the future. The path represent the dif-ferent possibles scenarios in which the system can reach regarding the actual state (WANG, 2017).
The syntax of LTL (BAIER; KATOEN; LARSEN, 2008) is based in some elements such the atomic propositions, the boolean connec-tors ( conjunction ∧ and negation ¬), and two basic temporal operators O (denotes "next"), U (denotes "until").
Its grammar is defined over the set of atomic proposition AP, and it can be formed as:
ϕ ::= true | a | ϕ1∧ ϕ2| ¬ϕ | Oϕ | ϕ1U ϕ2
Besides the basic operators presented, there are other logical op-erators such disjunction (∨), implication (→), equivalence (↔) and the exclusive or (⊕) that can be combined to generate other important temporal logic operators to express specifications in LTL language, such as ("eventually" in the future) and ("al-ways", from now and forever).
The LTL formulae are constructed taking into account the notion of path (Figure 3), which is the sequence of states of a TS. This path contains the trace, which is the sequence of sets of atomic propositions (called "words") valid along the execution over the all infinite words possibles in the alphabet 2AP. In other words,
the trace represents the sequence of observable events of the run
12
Figure 3 – Evaluation of LTL propositions.
Source: Baier, Katoen e Larsen (2008).
Regarding the Figure 3, it is possible to see examples of linear paths, representing an individual execution of some system, in which properties written in LTL are verified using the proposed operators. With this, the model described through states, start-ing in a state s, satisfies a property ϕ when ϕ it is interpreted as truth along the infinite path of the model.
• Computation Tree Logic: the CTL is a branching temporal logic to express properties of a reactive system in form of compu-tation trees, i.e, it can deal with many executions at once. Unlike LTL where a state at a particular point of execution has only one successor, in CTL the notion of more than one successor for each given state is taken into account.
In this case, the generated tree represents all possible paths of execution, and where its branches represent single paths. With this, it is possible to highlight the main difference with respect to the writing of formulas in LTL and CTL. In this branched logic, the formulas are written using path quantifiers before the tempo-ral operators, which are the universal quantifier, represented by A and references for all execution, and the existential quantifier, represented by E, and refers to the existence of a path in that property can be satisfied. Remembering that in LTL, properties are checked for all execution (quantifier A is implicit in formula), but it is also possible to represent the existence of some state by
13
making the composition of operators.
Formulas in CTL are based on two concepts: states and paths. The first expresses states properties, through atomic propositions, and are interpreted over states, that is, between the TS states and the state formulae. For this to be satisfied, considering a state s, the state formula Φ must hold in state s (s |= Φ). Already those temporal expressions that are interjected on paths, between the possible paths and the formula. In this case, considering a path φ, the property is satisfied if the path formula ϕ satisfies in φ (φ |= ϕ) (BAIER; KATOEN; LARSEN, 2008).
The evaluation of CTL propositions over a computation tree can be seen in the figure 4.
Figure 4 – Evaluation of CTL formulae.
Source: Zampieri (2017).
Regarding the specification languages (LTL and CTL) presented, they are used to formalize the properties to apply model checking, and through the model checker tool, these properties are confronted with a model that describes important behaviors of the target system. Some examples of these tools are detailed below.
14
2.2.2 Model Checkers
Aiming to perform MC, there exist many tools called model checker that apply algorithms to confront models designed by the user with properties formalized, all created in the language supported by the correspondent verification engine, to check the correctness of the sys-tems. For this, some model checkers can be highlighted such as TINA Toolbox (BERTHOMIEU; VERNADAT, 2006), DREAM (MADL; DUTT, 2009), PRISM (KWIATKOWSKA; NORMAN; PARKER, 2011), SPIN ( HOLZ-MANN, 2003), UPPAAL (BEHRMANN; DAVID; LARSEN, 2004a), among other.
TINA (TIme petri Net Analyzer) Toolbox has been developed in research groups of LAAS/CNRS3. The toolbox is composed of a set of tools like tina, sift, selt, muse, and others, that allow the editing and analysis of Petri Nets (MURATA, 1989), Time Petri Nets (MERLIN;
FARBER, 1976), and an extension of Time Petri Nets with data handling
called Time Transition Systems.
DREAM ( Distributed Real-time Embedded Analysis Method ) is a model-based analysis method and tool for the real-time verification and performance estimation of Distributed Real-time Embedded (DRE ) systems. The tool design flow utilizes the concept of Domain-specific Modeling Languages (DSMLs) to capture simulations and model check-ing in a formal framework (MADL; DUTT, 2009).
The PRISM is a probabilistic model checker for formal modelling and analysis of systems that exhibit random or probabilistic behaviour. It is possible to build and analyze several types of models such as discrete-time Markov chains (DTMCs), probabilistic timed automata (PTAs, and the models are described using a simple and state-based own language. The property specification language supported are Prob-abilistic Computation Tree Logic (PCTL), Continuous Stochastic Logic (CSL), LTL, and PCTL* (KWIATKOWSKA; NORMAN; PARKER, 2011).
SPIN is a verification tool widely used for the formal verification of multi-threaded software applications. Its verification models are fo-cused on providing the correctness of process interactions. Regarding their formalisms, SPIN accepts design specifications written in the ver-ification language PROMELA (Process Meta language) and standard LTL (Linear Temporal Logics) (HOLZMANN, 1997).
The UPPAAL (BEHRMANN; DAVID; LARSEN, 2004b) toolbox is introduced in more details because it is applied in the present work.
15
It was developed in collaboration between the Department of Infor-mation Technology of Uppsala University in Sweden and the Depart-ment of Computer Science of the University from Aalborg in Denmark, and allows the construction of the model in timed automata, formalize properties in TCTL language and apply MC verification. It is freely available at http://www.uppaal.org/.
2.2.3 UPPAAL Model Checker
The UPPAAL is an integrated tool environment for modeling, simulation and verification of real-time systems. It is an intuitive tool to use and at the same time very efficient, allowing the validation, through graphic simulation, and verification, through automatic model checking. Its interface is implemented in Java and allows the modeling of systems in Timed Automata (TA) extended with integer variables, structured data types, and channel synchronization.
This consists of finite state machines with clock, in which the model is composed of states (locations), which represent situations or modes of operation, and transitions , structures in the form of lines that connect two or more states. This network of states and transi-tions forms the behavior of the system, where for each transition it is possible to define a set of rules and conditions that the system must meet to enable state change. The simulation stage of the model through UPPAAL allows the developer to test the most various paths the system can take during its execution, and note that it is working as planned
(BEHRMANN; DAVID; LARSEN, 2014).
In the Figure 5 the gate template of the train-gate example avail-able by the tool can be seen. In this template, some characteristics of the modeling can be highlighted and it is explained below (BEHRMANN;
DAVID; LARSEN, 2014; CARVALHO; SOUSA, 2009). The edge features
are:
• Select: this label takes a non-deterministic value in the range of their respective types and it allows to attribute this value to a temporary variable (just valid to the correspond transition). • Guard: the guard label allows to activate a transition under a
given condition. It may call a side-effect free function that returns a boolean.
• Synchronization: this label channel allows to pass the automata states in a synchronization way, where it can be set in two types:
16
Figure 5 – Gate template by train-gate example in UPPAAL.
Source: Behrmann, David e Larsen (2004a)
synch! is a sender label and the synch? is a receive label. For cor-rect operation, the transition of a template must have the sender and the corresponding a receiver label.
• Update: the update label is used to update global or local vari-ables or initialize functions.
The tool has the Simulator feature that gives the user the pos-sibility to simulate their model and achieve different scenarios and be-haviors of the system.
After the modeling stage, desired properties can be formalized in the Timed Computation Tree Logic (TCTL) formal language, which is a fragment of CTL language which it uses clock variables and clock constraints to specify timing behaviours reasoning about properties of Timed Automata.
The verification process is done through the Verifier tab on UP-PAAL. It allows the user to write the desired property on the Query window, store all queries in the Overview, analyze the verification through the Status window.
As the tool supports the TCTL specification language, it is pos-sible to construct the queries for using the quantifiers A and E, the temporal operator and, beyond the logic operators (and, or ) and imply (→).
Still considering the example of the train-gate, it is possible to see some properties and their verdict (Figure 6).
Be-17
18
sides that, may be satisfied and may not be satisfied verdicts can exists according to the approximations made by the tool considering some options of search algorithms.
Aiming to organize and facilitate verification analysis, there are some type of properties. Above it is highlighted the one of liveness, safety (in the case of deadlock freedom) and reachability.
• Reachability: it allows to evaluate if there is a path which at least one state satisfies the property specified. A possible notation using CTL (Computation Tree Logic) formal language is:
E α
where E is the quantifier that means “exist a path”, the tempo-ral operator represents “eventually” and α is the property. For instance, considering that the system has a state called Running, and this is an important state for correct operation of the ap-plication. It is possible to check the property against the model using the reachability classification as the expression:
E model.Running
• Safety: this classification says that “something bad never hap-pens“, which means the system should never reach the state in which this property is satisfied. The formulae can be expressed by TCTL language:
A α
where the quantifier A means “for all paths”, the temporal opera-tor represents “always” and α is the desired property. A typical example to demonstrate this type is the absence of deadlock on the system, i.e., it always has another state from the current one. In order to express this property as:
A not deadlock
• Liveness: it enables to check if, considering all paths, there exists states that satisfies the desired property. It uses the following grammar to express this classification in TCTL:
19
where A is the quantifier " for all paths", the operator repre-sents "eventually" and α is the desired property. For example, considering a system has a state “Ready”, it is possible, through the liveness specification, to check for all paths of the execution, if this state will be reach in one moment on the future. It can be expressed by:
A model.Ready
Although MC is a very used and efficient technique, it presents advantages and disadvantages, in which the main advantages regard its fast verification, and the counterexamples generation in case of the model does not satisfy the property. On the other hand, its disadvan-tage is related to the state space explosion, that is observed on model with high level of complexity, which generates a large number of pos-sible states combination, and the model checker is not able to evaluate the property.
To avoid this state explosion situation, there are some design techniques that can be applied. One of these techniques is reducing the state space by abstracting away details of a module’s behavior that are not relevant to the specification being checked, or the use of binary decision diagrams (BDD’s) and symbolic algorithms (CLARKE, 1990).
In addition to the techniques presented to avoid the explosion of states, other approaches can be considered to complement MC verifica-tion, as in the case of Runtime Verification (HEFFERNAN; MACNAMEE;
FOGARTY, 2014;PEDRO et al., 2017), which deals directly with the
ac-tual application to which specifications are checked at runtime in order to give more confidence to the development project.
2.3 RUNTIME VERIFICATION
Runtime Verification (RV) is a lightweight and dynamical tech-nique that checks the current execution of the system under scrutiny through structures called monitors and yields a verdict whether this ex-ecution satisfies or not a given correctness property (FALCONE; HAVELUND;
REGER, 2013).
RV has its origins in model checking, where the key problem of generating monitors is similar to generation of automata in MC. The mainly difference between both techniques, besides its static and dynamic natures, is that MC deals with infinite traces, i.e, all possible
20
Figure 7 – Schematic view of RV technique.
Source: Francalanza et al. (2017).
executions of a given system, and RV deals with finite trace, that is, the current run of a target system (LEUCKER; SCHALLHART, 2009).
In this technique, the formal specifications are confronted with the code to be monitored. It generally assumes a logic describing the correctness specifications that are expected to be satisfied by the sys-tem. From these specifications, monitors are generated and instru-mented to run with the main code (FRANCALANZA et al., 2017). The RV checks the security breach and properties violated during execu-tion. If the property is violated, the system behavior will fail (PATIL, 2016). To correct this behavior, the RV technique proposes a code that consists of monitoring the main code to be verified, in which the first one is activated when a violation happens, as shown in Fig. 7.
In order to apply RV technique, three basic steps are essential. • Properties formalization for RV: in order to generate the
monitor to check the system, the desired properties need to be formalized in a formal language. For RV purposes, there ex-ists a variety of different formalism and specification languages, depending on the objective and the system under observation (SUO).
• Monitoring: Monitor is a structure based on the specifications that will be verified, and is responsible to reads a finite trace and
21
yields a certain verdict. The monitoring step can be performed by two different ways online and offline.
In the offline approach, the monitor analyzes the log file generated by the system’s execution and yields a verdict.
On the other hand, regarding the online analysis, the monitor runs concurrently with the target application and yields the ver-dict. This type of monitor can be integrated with the source code as an external entity and runs in parallel with main application or inline, which it is part of the program such as assertions. In order to monitoring a program’s execution code instrumenta-tion is required.
• Instrumentation: Instrumentation is a technique used to ex-port information about the code execution.
This is one of the most important steps in RV, because it is through the instrumentation that the monitor will obtain the events generated from the code trace and it can confront with the specifications to give the satisfaction or violation verdict. The instrumentation can be done by manual, such as assertions and pre/post conditions in design by contract solutions, or auto-mated way. In the autoauto-mated way the code can be instrumented in different forms according to the tool used, such as directly in the source code, in the byte/object code, using APIs or program-ming using aspects.
The first step mentioned aims to define some properties that describe the correctness of the SUO, that is, some desired behaviors stipulated in the requirements for the proper functioning of the product. Considering this objective, it is important to highlight the specification languages used for RV.
2.3.1 Specification Languages
Just like in MC, the RV technique allows the use of several spec-ification languages that are used according to the nature of the target system, in addition to the properties to be verified, and play a funda-mental role in the formal verification process.
Before explaining in more details the existing languages, it is needed to understand some notions about how the system is described and its behavior.
22
Unlike the MC technique in which, for the system to be verified, it must be modeled and generally this model involves states and transi-tions that describe the possible behaviors of its execution, where states evolve through the transitions and their rules that are applied by the developer according to studies and observations of the target.
The RV deals directly with the actual system in which it is checked by monitors at runtime. The behavior of this SUO is described through events, which can be actions such as variable updates or func-tion calls, and are observable by the user. With this, the execufunc-tion is defined by a trace which is a (finite) sequence of events that have taken place. In this case, the set of observable events of interest is called the alphabet (BARTOCCI et al., 2018).
In the case of specification languages for RV, there is a wide range for describing the behavior of the system. Temporal logic is also used in this context, and LTL, MTL (Metric Temporal Logic), and STL (Signal Temporal Logic) are examples of this type of logic.
The LTL language is also used in Runtime Verification to express desired properties to be checked, as well as in MC. Its semantics is constructed with the notion of infinite traces, as presented in MC, where all possible combinations of system execution are taken into account. However, since in RV the monitored and verified behavior is finite, that is, it takes into account the current moment of the code and past events already happened, it is necessary to look at this as a finite prefix of a possible infinite execution.
Since the execution of the code has a linear behavior, LTL is a suitable language in this sense, and although it has the same syntax as MC, the semantic differs somewhat, and in RV a three-valued verdict is adopted: true, false or inconclusive.
Considering u being the execution trace (finite prefix), and ϕ the formula in LTL. The value true is produced if every continuation of u satisfies ϕ, otherwise if there is no continuation of u that satisfies ϕ is considered false. However, if observations of u can not be determined and neither true nor false can be considered, the verdict is inconclusive
(BAUER; LEUCKER; SCHALLHART, 2011).
MTL is an extension of propositional linear temporal logic (LTL) that can refer to discrete-timed properties, and it is formulas are in-terpreted over finite timed state sequences. This specification language is using to monitoring real-time systems. Its syntax involves operators as in LTL, but besides that it allows future and past time linear tem-poral operators which are bounded by discrete-time intervals (THATI; ROŞU, 2005). For instance, a possible formula [4,5]ϕ can be written
23
and means that ϕ will become true within 4 to 5 time units from now. The STL is a specification language that considers the observable events of the execution as being a collection of signals where the signal is a function of a set of points in real times. In writing the formula predicates over real values are involved and there is usually a bounded interval in which the property must be verified. This type of language is more suitable for use in hardware monitoring (BARTOCCI et al., 2018). Besides temporal logic, regular expressions, state machines, stream languages among others can be used in this context. Specification languages for RV have arisen with the need of the teams to express important properties according to the nature of the target systems. From this, various research and studies are in progress (BARTOCCI et al., 2018).
An important issue to take into account when a monitor is syn-thesized from specifications is the monitorability of properties. It con-sists in determining whether it is worth monitoring such property, that is, if, during monitoring, the monitor can still provide an evaluation (in the form of a verdict) of the current execution (BARTOCCI et al., 2018). The formal verification techniques described here are normally implemented considering the characteristics and objectives of the target system. For this purposes several tools are created to help this stage execution in the design process.
2.3.2 Runtime Verification Tools
There exist many RV tools which depend primarily on the nature of the target system to be checked, whether it is an embedded system for example, and also the programming language in which it is writ-ten. These tools and frameworks support the generation of monitors that are computational entities responsible for checking and produc-ing the satisfaction or violation verdicts of the desired properties and may or may not provide an instrumentation mechanism for communi-cation between these monitors and the applicommuni-cation. Examples of these are JavaMOP (JIN et al., 2012), Lola (D’ANGELO et al., 2005), R2U2
(ROZIER; SCHUMANN, 2017), Rmtld3synth (PEDRO et al., 2017), among
others.
JavaMOP (JIN et al., 2012) is an instance of Monitoring-Oriented Programming (MOP) to apply runtime verification for Java program-ming language, using AspectJ for instrumentation. It allows concise descriptions of parametric properties using a combination of event
spec-24
ifications using an extension of AspectJ as well as properties specified over these events. From these specifications, JavaMOP generates As-pectJ code for monitoring, which is weaved into the target program. In MOP (MEREDITH et al., 2012), monitors are automatically synthesized
from specified properties and integrated with the original system to check its dynamic behaviors during execution.
LOLA (SEBASTIAN, 2016) is a stream-based specification lan-guage for synchronous systems, and its idea is to generate a set of output streams, based on a given set of input streams. Input streams describe the values of the system under observation and output streams represent errors or diagnosis reports of the monitor.
A runtime monitoring of LTL safety specifications, R2U2 (ROZIER;
SCHUMANN, 2017) is used for NASA in an UAV to check its embedded
application code written in C. In the case, R2U2 is set up to monitor the code via information sent over the system bus (NASA’s aircraft run NASA CFS/CFE, which is a message- passing architecture). The monitor is not annotate within the code, it is running as standalone on the same bus of the actions generated by the code.
Rmtld3synth is a toolchain for generation of monitors based on the restricted Metric Temporal Logic with durations (LAKHNECHE;
HOOMAN, 1995) to perform RV of real-time embedded systems. As
it will be used to generate monitors in our context, its details is pre-sented below.
2.3.3 Rmtld3synth Toolchain
Rmtld3synth (PEDRO, 2018) is a toolchain to automatically syn-thesize monitors in a c++11 or Ocaml programming language from a fragment of MTL with durations to apply runtime verification in hard real-time embedded systems. In addition, the tool is also capable of generating specifications in SMT-LIB v2 standard language which al-lows partial resolution of a scheduling problem for periodic resources models and scheduling algorithms with fixed priority before code exe-cution. As a verdict, the three-valued semantic is used, in which true, false, and inconclusive are issued according to the verification of the execution trace with the expected property.
The generated monitors are a set of files and auxiliary functions that can be integrated into the target application through a library created to support runtime monitoring of real-time embedded systems. This library, Rtmlib, is based on lock-free ring buffer FIFO queues either
25
Figure 8 – Rmtld3synth and Rtmlib overview.
Source: Pedro et al. (2017).
for ARM and X86 platforms. It is used to implement different mon-itoring architectures and can solves the lock-free producer-consumer problem based on lock-free enqueue and dequeue primitives over trace sequences containing time stamped events, where readers are consumers and writers are producers (PEDRO, 2018).
For the synthesis of the monitors, some languages like latex are allowed as input for writing the formulas in RMTLD3 that is composed of atomic propositions and logic variables that can be syntactically connected using some temporal operators and the relation ’<’ for terms
(PEDRO et al., 2017).
Figure 8 gives an overview of the operation flow of the monitors generation tool, its inputs and outputs, and the integration with the library that allows the target monitoring at runtime.
The code instrumentation that links the monitors to the actual application through the library is done manually by the designer. In the first instance, this library was developed for real-time platforms that have NuttX support, a Real Time Operating System (RTOS) that as-sists in the application’s task set management, and is based on pthreads. Although it is a very powerful tool to run runtime verification on hard real-time systems, it is still very recent and lacks examples of how to use it. One of the case studies carried out by the author (PEDRO et al., 2018) was the monitoring of the PX4/Autopilot autopilot system for an ArduCopter on the Pixhawk platform.
The verification techniques presented in this chapter, especially MC, have been widely used in the last years during the development of systems in several areas. With this, many works have already been done in this sense, and some of these will be presented in the next chapter, mainly for safety-critical systems.
27
3 RELATED WORKS
The development of systems considered safety-critical is a com-plex task because it requires several steps and activities to assure that the application works correctly according to the one expected in its initial phase and it is free of errors.
During this life cycle, many methods and techniques are used in order to strictly inspect every detail and features of this design. Some steps as requirements definition, which involve what and how this system will behave, in addition to various modeling, verification and testing are widely applied.
The verification and validation steps are essential to obtain guar-antees of the correctness and reliability of the target system. These steps are expected to be applied to each new phase of the project, which helps in finding errors and inconsistencies as early as possible and that they be repaired. Its basic concept is to confront the current model that represents the system with its pre-defined requirements, which results in satisfaction or violation. From this analysis, it allows the team of developers to make important decisions.
Regarding the methods and techniques used in the verification process applied to critical systems, especially to mobile robots, which must be highly reliable, some related works and their characteristics will be presented in this chapter.
Verification techniques is widely explored to formally verify hy-brid and cyber-physical systems in order to check, for instance, prob-abilities to reach errors states, sanity and safety properties, timing of protocols communication and software scheduling, among others.
In Xu e Wang (2016), the authors propose a model-based inte-gration framework for modeling and verification of timing properties of UAV flight control system. This work approaches from modeling the software system using class diagram and state chart, passing to the transformation of an model that could be verified by using formal tools. The formal verification was applied by Z/EVES and PVS (Prototype Verification System), that are tools for analyzing formal specifications using theorem proving technique. In order to check the system, a PTA (Probability timed automata) model was used and mathematics model of real-time reliability was created to perform the formal proof. The outcome allowed to analyze the software model through the status type at different time periods.