Energy consumption and execution time estimation of embedded system applications

Texto

(1)Post-Graduation in Computer Science. “Energy Consumption and Execution Time Estimation of Embedded System Applications” by. Gustavo Rau de Almeida Callou MSc Dissertation. Federal University of Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao. Recife, March/2009.

(2) FEDERAL UNIVERSITY OF PERNAMBUCO CENTER FOR INFORMATICS POST‐GRADUATION IN COMPUTER SCIENCE . . Gustavo Rau de Almeida Callou . “Energy Consumption and Execution Time Estimation of Embedded System Applications” A dissertation submitted to the Post-Graduation in Computer Science of the Center for of Federal University of Pernambuco Informatics in partial fulfillment of requirements for the degree in Master of Computer Science.. Adviser: Prof. Dr. Paulo Romero Martins Maciel. Recife, March/2009.

(3) Callou, Gustavo Rau de Almeida Energy consumption and execution time estimation of embedded system applications / Gustavo Rau de Almeida Callou - Recife : O Autor, 2009. xv, 111 folhas : il., fig., tab. Dissertação (mestrado) – Federal de Pernambuco. CIn. Computação, 2009.. Universidade Ciência da. Inclui bibliografia, anexo e apêndice. 1. Avaliação de desempenho. 2. Redes de Petri – Modelagem de sistemas. 3. Consumo de energia. 4. Simulação. I. Título. 004.029. CDD (22.ed.). MEI2009-031.

(4) This dissertation is dedicated to my parents..

(5) ACKNOWLEDGEMENTS. First of all, I would like to thank God for all conquests that I have been achieving. Also, I am very grateful to my parents, people that have always been supporting and encouraging me to do what I dreamed. Many thanks to my sisters that always contributed me to keep going at all difficult moments. A special thanks for Karina, who has never stopped to give her support and encouragement whether in good or difficult moments. Thanks to my friend and professor Sérgio Galdino who gave me the opportunity to start my academic life as a researcher and who introduce me to professor Paulo Maciel. Many thanks to my advisor and friend professor Paulo Maciel. He gave me the chance to be part of his research group, and has helped me at all moments. A thanks to professor Meuse Oliveira Jr. who helped me at the initial stages of this research and who provided the hardware implementation for validating the experiments; to Eduardo Tavares, who helped with valuable article reviews; to Bruno Nogueira for implementing the CPN Simulator and for all supporting and help; and to all members of our research group (MODCS - Modeling of Distributed and Concurrent Systems); and to professors Nelson Rosa and Ricardo Salgueiro for their valuable contributions as committee members. Thanks to several colleagues I made at CIn/UFPE. Among them: Adriana Ribeiro, Antônio Ricardo, Danuza Neiva, Erica Sousa, Ermeson Andrade, Giselia Magalhães, Julian Menezes, Kalil Bispo, Rafael Antonello and Patricia Takako. My special thanks to Ermeson, Erica and Julian for the motivating moments and for all support and help. Thanks to all professors and staff in the center for informatics of UFPE. Thanks to Clinic Hospital of Pernambuco (HCPE), specially to all the informatics team members. Thanks to my English teacher, Cremilda Matos, for all my English improvements.. iv.

(6) All models are wrong, but some are useful. —GEORGE BOX.

(7) RESUMO. Nos u ´ ltimos anos, a redu¸cão do consumo de energia das aplica¸cões dos sistemas embarcados tem recebido uma grande aten¸cão da comunidade cient´ıfica, visto que, como o tempo de resposta e o baixo consumo de energia são requisitos conflitantes, esses estudos tornam-se altamente necessários. Nesse contexto, é proposta uma metodologia aplicada nas fases iniciais de projeto para dar suporte a`s decisões relativas ao consumo de energia e ao desempenho das aplica¸cões desses dispositivos embarcados. Além disso, esse trabalho propõe modelos temporizados de eventos discretos que são avaliados através de uma metodologia de simula¸cão estocástica com o objetivo de representar diferentes cenários dos sistemas com facilidade. Dessa forma, para cada cenário é preciso decidir o n´ umero máximo de simula¸cões e o tamanho de cada rodada da simula¸cão, onde ambos os fatores podem impactar no desempenho para se obter tais estimativas. Essa metodologia considera também, um modelo intermediário que representa a descri¸cão do comportamento do sistema e, é através desse modelo que cenários são analisados. Esse modelo intermediário é baseado em redes de Petri coloridas temporizadas que permitem não somente a análise do software, mas também fornece suporte a um conjunto de métodos bem estabelecidos para verifica¸cões de propriedades. ´ nesse contexto que o software, ALUPAS, responsável por estimar o consumo de E energia e o tempo de execu¸cão dos sistemas embarcados é apresentado. Por fim, um caso de estudo real, assim como também, exemplos customizados são apresentados com a finalidade de mostrar a aplicabilidade desse trabalho, onde usuários não especializados não precisam interagir diretamente com o formalismo de redes de Petri. Palavras-chave: Redes de Petri Coloridas, Simula¸cão Estocástica, Sistemas Embarcados, Consumo de Energia e Desempenho.. vi.

(8) ABSTRACT. Over the last years, the issue of reducing energy consumption in embedded system applications has received considerable attention from the scientific community, since responsiveness and low energy consumption are often conflicting requirements. In this context, this dissertation proposes a methodology applied in early design phases for supporting design decisions on energy consumption and performance of embedded applications. In addition, this work proposes temporized discrete event models that have been evaluated through a stochastic simulation approach to represent different system scenarios in an easier way. For each scenario, it is important to decide the maximum number of simulations and the duration of each simulation, where both may impact the performance estimates. Such approach also considers an intermediate model which represents the system behavioral description and, through these models, the scenarios are analyzed. The intermediate model is based on timed Colored Petri Net, a formal behavioral model that not only allows the software execution analysis, but it is also supported by a set of well established methods for property verifications. In this context, a software, named ALUPAS, for estimating energy consumption and execution time of embedded systems is presented. Lastly, a real-world case study as well as customized examples are presented, showing the applicability of this work in which non-specialized users do not need to interact directly with the Petri net formalism. Keywords: Coloured Petri Net, Stochastic Simulation, Embedded System, Energy Consumption and Performance.. vii.

(9) CONTENTS. List of Figures. xii. List of Tables. xv. Chapter 1—Introduction. 1. 1.1. Objectives and Contributions . . . . . . . . . . . . . . . . . . . . . . . .. 4. 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5. Chapter 2—Background 2.1. 6. Energy Consumption and Performance Evaluation . . . . . . . . . . . . .. 6. 2.1.1. Evaluation models . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 2.1.2. Measurement Strategies . . . . . . . . . . . . . . . . . . . . . . .. 9. 2.2. Simulation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 11. 2.3. System Classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12. 2.4. Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 14. 2.4.1. Place-Transition Nets . . . . . . . . . . . . . . . . . . . . . . . . .. 15. 2.4.2. Marked Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . .. 17. 2.4.3. Transition Enabling and Firing . . . . . . . . . . . . . . . . . . .. 17. 2.4.4. Petri Net Analysis Methods . . . . . . . . . . . . . . . . . . . . .. 18. 2.5. Time Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 22. 2.6. Coloured Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 23. 2.6.1. CPN ML Language . . . . . . . . . . . . . . . . . . . . . . . . . .. 29. 2.6.2. Timed Coloured Petri net . . . . . . . . . . . . . . . . . . . . . .. 33. 2.6.3. Hierarchical CPN . . . . . . . . . . . . . . . . . . . . . . . . . . .. 35. Embedded Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 38. 2.7. viii.

(10) CONTENTS. ix. 2.8. 40. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Chapter 3—Related Works. 41. 3.1. General Overview of Energy Consumption and Performance Evaluation .. 41. 3.2. Hardware simulation-related-works . . . . . . . . . . . . . . . . . . . . .. 42. 3.3. Software simulation-related-works . . . . . . . . . . . . . . . . . . . . . .. 44. 3.4. Hybrid Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 45. 3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 46. Chapter 4—Methodology. 47. 4.1. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 47. 4.2. Energy Consumption and Performance Evaluation Framework . . . . . .. 49. 4.2.1. Characterization Process . . . . . . . . . . . . . . . . . . . . . . .. 50. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 53. 4.3. Chapter 5—Formal Model 5.1. 54. Embedded Software Modeling . . . . . . . . . . . . . . . . . . . . . . . .. 54. 5.1.1. CPN model for ordinary instructions . . . . . . . . . . . . . . . .. 55. 5.1.2. CPN model for conditional instructions . . . . . . . . . . . . . . .. 57. 5.1.3. Procedure calls model . . . . . . . . . . . . . . . . . . . . . . . .. 57. 5.1.4. CPN model for conditional branch instructions . . . . . . . . . . .. 58. 5.1.5. CPN model for branching exchange instructions . . . . . . . . . .. 60. 5.1.6. CPN model for Store multiple instruction. . . . . . . . . . . . . .. 62. 5.1.7. CPN model for Load multiple instruction . . . . . . . . . . . . . .. 62. 5.1.8. CPN model for the stop criteria process . . . . . . . . . . . . . .. 62. 5.2. Reduction Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 64. 5.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 65. Chapter 6—The Simulation Environment. 66. 6.1. ALUPAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 66. 6.2. Assembler and C Compiler . . . . . . . . . . . . . . . . . . . . . . . . . .. 66.

(11) x. CONTENTS. 6.3. Binary CPN Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 67. 6.4. CPN Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 68. 6.4.1. Sim file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 69. 6.4.2. Simulation Process . . . . . . . . . . . . . . . . . . . . . . . . . .. 71. 6.4.3. Simulation Algorithm Variables . . . . . . . . . . . . . . . . . . .. 72. 6.4.4. Stop Criteria Evaluation . . . . . . . . . . . . . . . . . . . . . . .. 74. 6.4.5. Enabling and Firing rules . . . . . . . . . . . . . . . . . . . . . .. 75. Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . .. 78. 6.5.1. Component Integration . . . . . . . . . . . . . . . . . . . . . . . .. 79. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 80. 6.5. 6.6. Chapter 7—Case Studies 7.1. 81. Example One . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 81. 7.1.1. Simulation Results. . . . . . . . . . . . . . . . . . . . . . . . . . .. 82. 7.2. Example Two . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 83. 7.3. Binary Search Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . .. 84. 7.3.1. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 87. 7.4. BCNT Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 88. 7.5. Pulse-oximeter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 89. 7.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 94. Chapter 8—Conclusions. 96. 8.1. Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 97. 8.2. Future Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 98. Bibliography. 99. Appendix A—A Validation Process A.1 Noncorresponding measurements Appendix B—The Simulation Algorithm. 106 . . . . . . . . . . . . . . . . . . . . . .. 106 108.

(12) CONTENTS. xi. Appendix C—Binary-CPN Compiler Class Diagram. 110. Appendix D—CPN Simulator Class Diagram. 111.

(13) LIST OF FIGURES. 1.1. Levels of Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3. 1.2. Cost of correcting a requirements defect according to the stage at which it is discovered. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. 2.1. Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8. 2.2. Histogram showing accuracy and precision. . . . . . . . . . . . . . . . . .. 11. 2.3. Simulation process diagram. . . . . . . . . . . . . . . . . . . . . . . . . .. 12. 2.4. System classifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 14. 2.5. Petri net basic elements. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 15. 2.6. Compact representation of a PN . . . . . . . . . . . . . . . . . . . . . . .. 16. 2.7. (a) Mathematical formalism; (b) Graphical representation before firing of t0 ; (c) Graphical representation after firing of t0 . . . . . . . . . . . . . . .. 18. 2.8. Simple reduction rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 20. 2.9. Reduction of a PN with a redundant place . . . . . . . . . . . . . . . . .. 20. 2.10 Six transformations preserving properties. . . . . . . . . . . . . . . . . .. 21. 2.11 Reduction Rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 29. 2.12 Place inscriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 32. 2.13 Arc inscription. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 32. 2.14 Transition inscriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34. 2.15 Moore’s law. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 39. 3.1. The System with its Environment, Requirements and Constraints. . . . .. 41. 3.2. Performance Evaluation Methodology.. . . . . . . . . . . . . . . . . . . .. 42. 4.1. Methodology activity diagram. . . . . . . . . . . . . . . . . . . . . . . . .. 48. 4.2. The proposed Framework. . . . . . . . . . . . . . . . . . . . . . . . . . .. 50. 4.3. A code example for measuring.. 51. . . . . . . . . . . . . . . . . . . . . . . .. xii.

(14) LIST OF FIGURES. xiii. 4.4. The measurement performed on oscilloscope. . . . . . . . . . . . . . . . .. 52. 4.5. Hardware Platform with LPC2106 microprocessor. . . . . . . . . . . . . .. 52. 4.6. The measurement process. . . . . . . . . . . . . . . . . . . . . . . . . . .. 53. 4.7. The AMALGHMA engine. . . . . . . . . . . . . . . . . . . . . . . . . . .. 53. 5.1. Methodology task-flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 55. 5.2. Ordinary model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 56. 5.3. An example of ordinary model. . . . . . . . . . . . . . . . . . . . . . . .. 56. 5.4. Conditional model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 57. 5.5. Branch and link model . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 58. 5.6. Conditional branch model. . . . . . . . . . . . . . . . . . . . . . . . . . .. 58. 5.7. Conditional branch model example . . . . . . . . . . . . . . . . . . . . .. 59. 5.8. Branching exchange instruction model. . . . . . . . . . . . . . . . . . . .. 61. 5.9. Bx instruction example . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 61. 5.10 Store multiple model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 62. 5.11 Load multiple model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 63. 5.12 CPN model for the stop criteria process . . . . . . . . . . . . . . . . . . .. 63. 5.13 (a)CPN model, (b)CPN model after reduction process. . . . . . . . . . .. 64. 6.1. Assembler structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 67. 6.2. Basic Binary CPN Compiler structure. . . . . . . . . . . . . . . . . . . .. 68. 6.3. Detailed Binary-CPN Compiler structure. . . . . . . . . . . . . . . . . .. 68. 6.4. Basic CPN Simulator structure. . . . . . . . . . . . . . . . . . . . . . . .. 69. 6.5. CPN Simulator structure. . . . . . . . . . . . . . . . . . . . . . . . . . .. 69. 6.6. Simulation diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 71. 6.7. Stop criteria diagram.. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 75. 6.8. Concurrent example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 77. 6.9. ALUPAS’ input interface. . . . . . . . . . . . . . . . . . . . . . . . . . .. 78. 6.10 ALUPAS’ output interface. . . . . . . . . . . . . . . . . . . . . . . . . . .. 79. 6.11 Component Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 80. 7.1. Annoted Assembly Code . . . . . . . . . . . . . . . . . . . . . . . . . . .. 82. 7.2. CPN Tools versus CPN Simulator runtime. . . . . . . . . . . . . . . . . .. 84.

(15) LIST OF FIGURES. xiv. 7.3. Binary Search Code in Assembly. . . . . . . . . . . . . . . . . . . . . . .. 85. 7.4. Binary Search Code in C. . . . . . . . . . . . . . . . . . . . . . . . . . .. 86. 7.5. Binary search results of execution time. . . . . . . . . . . . . . . . . . . .. 87. 7.6. Binary search results of energy consumption. . . . . . . . . . . . . . . . .. 87. 7.7. Binary search results of execution time. . . . . . . . . . . . . . . . . . . .. 88. 7.8. Binary search results of energy consumption. . . . . . . . . . . . . . . . .. 88. 7.9. The CPN model for BCNT Algorithm. . . . . . . . . . . . . . . . . . . .. 89. 7.10 Pulse-Oximeter Architecture. . . . . . . . . . . . . . . . . . . . . . . . .. 90. 7.11 Pulse-oximeter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 91. 7.12 Runtime Comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 92. B.1 Simulation Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 108. C.1 Binary-CPN Compiler class diagram. . . . . . . . . . . . . . . . . . . . .. 110. D.1 CPN Simulator class diagram. . . . . . . . . . . . . . . . . . . . . . . . .. 111.

(16) LIST OF TABLES. 2.1. Some Pioneers in Performance Evaluation. . . . . . . . . . . . . . . . . .. 7. 2.2. Interpretation for places and transitions. . . . . . . . . . . . . . . . . . .. 16. 6.1. The simulation results. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 76. 6.2. Comparison: 10 replications versus 653 replications . . . . . . . . . . . .. 76. 6.3. Firing rule results of Figure 6.8. . . . . . . . . . . . . . . . . . . . . . . .. 78. 7.1. Simulation Results of the code on Figure 7.1. . . . . . . . . . . . . . . . .. 82. 7.2. Comparison between simulation results. . . . . . . . . . . . . . . . . . . .. 83. 7.3. Comparison of the runtime simulation. . . . . . . . . . . . . . . . . . . .. 83. 7.4. Binary Search results summary . . . . . . . . . . . . . . . . . . . . . . .. 88. 7.5. BCNT results summary. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 90. 7.6. Pulse-oximeter result summary . . . . . . . . . . . . . . . . . . . . . . .. 91. 7.7. CPN Tools runtime x CPN Simulator runtime. . . . . . . . . . . . . . . .. 92. 7.8. Excitation - comparison of execution time. . . . . . . . . . . . . . . . . .. 93. 7.9. Excitation - comparison of energy consumption. . . . . . . . . . . . . . .. 93. 7.10 Acquisition - comparison of execution time.. . . . . . . . . . . . . . . . .. 94. 7.11 Acquisition - comparison of energy consumption. . . . . . . . . . . . . . .. 94. 7.12 Control - comparison of execution time. . . . . . . . . . . . . . . . . . . .. 95. 7.13 Control - comparison of energy consumption. . . . . . . . . . . . . . . . .. 95. xv.

(17) CHAPTER 1. INTRODUCTION. Embedded system is the one whose principal function is not computational, but it is controlled by a computer embedded (e.g.: microprocessor or microcontroller) within it [Wil01]. The word embedded means that the computer lies inside the overall system, hidden from view, forming an integral part of a greater whole and, as a result, the user may be unaware of the computers existence [Tav06]. Nowadays, embedded systems are present in practically all areas of human lives. Mobile phones, clocks, refrigerators, microwaves, oscilloscopes and routers are a few examples of those devices that have a digital processor responsible for performing specific tasks. Within such devices embedded applications that have always been running the same tasks are present and, thus, the software updates after being in production are unusual. Besides, embedded systems do not terminate, unless it fails [Lee02]. Depending on the purpose of the application, the design of embedded systems may have to take into account several constraints, for instance, time, size, weight, cost, reliability and energy consumption. Furthermore, advances in microelectronics have allowed for the development of embedded systems with several complex features, thereby upholding the development of powerful mobile mechanism such as military gadgets (e.g.: spy satellites and guide missiles) and medical devices (e.g.: thermometers and pulseoximeters). These devices generally rely on constrained energy sources (e.g.: battery), in such a way that if the energy source is depleted, the system stops functioning. The power consumption control is also becoming an important design goal in designs that are not battery-operated, because the excessive heat generated from high power consumption can seriously degrade chip performance and cause physical damage to the chip [HZDS95]. Hence estimating energy consumption in early design phases can provide important insights to the designer about the battery lifetime as well as parts of the application that need optimization. Embedded applications that deal with time constraints are classified as Embedded Real-Time Systems (ERTS). In these systems, not only the logical results of computations are important, but also the time instant in which they are obtained. Some constraints are considered “hard”, while others are “soft”, meaning the timing deadlines may or may not be violated. In other words, soft ERTS accepts a soft delay to obtain the results (e.g.: web servers, mobile phones, Voice over Internet Protocol (VoIP) Calls, digital TV, web video conferences, and others). On the other hand, in the hard ERTS if the time constraints are not satisfied, a catastrophe may occur (e.g.: car races, health care devices, military 1.

(18) INTRODUCTION. 2. applications, aircraft and nuclear control centers)[TMSO08]. Hence, time predictability is an essential issue on the development life cycle of those systems [BL04, TMS+ 07]. The context of this work is related to embedded systems with timing and energy constraints. More specifically, this work is concerned about the adoption of formal models for modeling hard real-time systems with energy constraints as well as the utilization of techniques for estimating their energy consumption and execution time. A formal approach, based on Coloured Petri Nets (CPN), for estimating execution time as well as energy consumption of embedded system applications through a stochastic simulation method is presented. The formal mechanism, such as CPN, has being adopted in order to trade off and system’s representation based on abstraction levels that might focus on processor instructions or high-level programming languages, in which applications may be modeled instruction-by-instruction or by blocks of instructions. Originally, most part of embedded systems was hardware-based, using for instance ASICs (Application Specific Integrated Circuit). However, with the constant microelectronic advances, the technology evolved in a such way that the computational capability of processors has been increased and, correspondingly, their cost and size have been decreased. Consequently, the software has been responsible for 80% of an embedded system development so far [SVM01]. This process has been moving functionalities from hardware to software, and some advantages such as flexibility, lower cost, and accessibility are improved. On the other hand, functionalities implemented in hardware still have better performance and consume less energy. It is important to state that many works deal with energy consumption of embedded systems at different abstraction levels. The differences of each abstraction level [Oel00] [Bea01] resulted i the following classification: Application/System level: the energy consumption related to the execution of a particular program can be considered in such level. Behavioral/Algorithm level: different algorithms for the same purpose gives different amount of power consumption, and at this level such behavior is analyzed. Architectural level: in this level, the power consumption analysis of caches, core and processor buses are performed. Logic (gate) level: at this level both the function and the style of any circuit are decided. There are various design styles and each one has its power-performance trade-offs. Transistor (circuit) level: this is the lowest level of abstraction; studies of changing the input voltage and reordering of transistors, for example, are analyzed in such level. Figure 1.1 summarizes the relation of those levels considering capacity, accuracy, speed, resources and energy saving analysis on each level. The reader should have in.

(19) 3. INTRODUCTION. Figure 1.1: Levels of Abstraction. mind that it does not have a level better than the others. On the other hand, a level may be more applicable in a specific case, but all of them are important in order to have a low power energy consumption in embedded systems. Furthermore, this work focuses the application and behavior levels. Without loss of generality, there are two basic approaches based on simulation for estimating embedded software energy consumption: (i) instruction based simulation and (ii) hardware based simulation [NN02]. In hardware simulation, despite the very high computation effort, more accurate results might be obtained in comparison with instruction simulation due to the laborious system specification. However, instruction simulation has been adopted by many works in order to provide energy consumption estimation in a satisfactory period of time. Although there are some works about these methods, to the best of our knowledge, only a small number may represent the embedded applications at a different abstraction level with good accuracy for estimating energy consumption and execution time in a short period of runtime. In addition, performance has been a central issue in the design, development and configuration of systems [Wel02]. The performance as well as power will get more importance if we consider embedded systems with energy and time constraints. In this context, it is not enough to know that systems work properly, they must also work effectively in order to respect their constraints. Studies about performance analysis of systems have been conducted to evaluate existing and/or planned softwares, to compare alternative configurations and to find an optimal system configuration. Thus, being able to estimate the performance and power consumption of a system is important because if such requirements are not satisfied, the system designers can make changes in a very early stage of the design, thereby saving both time and money. The redesign of both software and hardware is costly and may cause late system delivery. Figure 1.2 shows the error detection costs in a different stages of the development life cycle. Thus, in such illustration is demonstrated that earlier detected errors cost less.

(20) 1.1 OBJECTIVES AND CONTRIBUTIONS. 4. money for the companies. Moreover, as the system are getting more and more complex, the adoption of formal evaluation models can provide a significant help in order to reduce the global development cost of embedded systems.. Font: [Hal07, p. 2]. Figure 1.2: Cost of correcting a requirements defect according to the stage at which it is discovered.. 1.1. OBJECTIVES AND CONTRIBUTIONS. In order to assure that the embedded system constraints (e.g.: energy consumption and execution time) are preserved, this dissertation focuses on providing a methodology that aims at evaluating energy consumption as well as execution time of embedded real-time systems in early design phases. From an Assembly code or C program, models have been built in order to represent the system behavior and compute both energy consumption and execution time of each code instruction. More specifically, the objectives are: to propose a temporized discrete event model supported by a precise semantic in order to be able to represent Assembly language and a representative subset of the C ANSI language; to propose a simulator for evaluating the proposed model in order to estimate the energy consumption and execution time of embedded systems applications; to propose a characterization mechanism of the microcontroller instruction set considering its energy consumption and performance..

(21) 1.2 OUTLINE. 5. This dissertation presents a methodology for estimating energy consumption and execution time of embedded systems. This work extends the approach proposed by Oliveira [OJ06] by simplifying such methodology considering other microcontroller (ARM7-based instead of 8051) and dealing with C programs. Furthermore, a simulation tool is proposed in order to improve the runtime evaluation. Specific contributions are depicted as follows: Framework. A mechanism for supporting design decisions on energy consumption and performance of embedded applications in early design phases is proposed; Modeling. The proposed methodology automatically translates the embedded code into a Coloured Petri net, a formal behavioral model that allows the software execution analysis. The modeling phase is based on composition of basic blocks that represents each relevant behavior of the ARM7-based instruction set microcontroller. Simulating. A stochastic evaluation approach through discreet event simulation is proposed for output data analysis. A new simulating tool is proposed to simulate the specific CPN models in a much faster simulation runtime than the other generic engines available for CPN simulation. 1.2. OUTLINE. This work is organized as follows: Chapter 2 overviews the main concepts of concern in this dissertation, such as embedded systems, real-time systems, and Petri nets. Chapter 3 reviews the related works, and Chapter 4 depicts the proposed methodology for embedded system evaluation. Afterwards, Chapter 5 describes the proposed models for embedded hard real-time systems. Next, Chapter 6 explains the simulation environment. Chapter 7 shows experiments conducted using the proposed methodology. Finally, Chapter 8 concludes this dissertation and presents future works..

(22) CHAPTER 2. BACKGROUND This chapter shows a summary of the background information needed for a better understanding about this work. First of all, it is performed an overview of energy consumption and performance evaluation, including measurement techniques and evaluation models. After that, it is presented the system classification. Next, it is shown an overview about Petri nets and Coloured Petri nets (CPN). Afterwards, some definitions such as binding, marking, enable transitions, fire rules and reduction process are introduced. 2.1. ENERGY CONSUMPTION AND PERFORMANCE EVALUATION. Energy is one of the most important non-functional requirements for embedded system design. It is important to stress that the energy consumption of embedded system depends on the hardware platform and software. The energy design problems can be classified into two groups: (i) analysis and (ii) optimization [Yea98]. Analysis problems are concerned with the accurate estimation of the energy consumption in order to assure that the energy consumption constraints are not violated. The analysis techniques differ in their accuracy and efficiency, in which the accuracy depends on the available design information. In early design phases, the focus should be to obtain energy consumption estimates quickly through little design information. Thus, in such phases, less accuracy results are expected. As the design proceeds, more details are available and more accurate results can be obtained through longer analysis time. Optimization has been considered as the process that improves the design without violating any design specification. An automatic design optimization requires a fast analysis engine to evaluate different design scenarios. On the other hand, manual optimization demands a tool in order to provide energy consumption estimation of different design choices. It is important to highlight that a design decision involves trade-offs from different sources such as the impact to the circuit delay, which affects the performance and throughput of the chip, and the chip area, which may increase the manufacturing costs. Furthermore, the design decisions to achieve a low energy consumption may affect other factors such as cycle time, quality and reliability. Nowadays, it is not always enough to know that systems work properly, they must also work effectively. Thus, Performance Evaluation (PE) is often a central issue in the design, development, and configuration of systems. The goals of the PE may be to maximize the throughput of the system, process a given workload for a minimum cost (e.g.: to reduce the energy consumption), or any number of other objective functions [Luc71]. These goals provide the overall environment for evaluation and determine what level of effort 6.

(23) 7. 2.1 ENERGY CONSUMPTION AND PERFORMANCE EVALUATION. can be devoted to the models or measurement techniques that should be applied in order to obtain the performance metric of a system. In order to have a history overview of the firsts approaches that deal with PE, Table 2.1 shows the pioneers in PE. However, such list showed by [Her02] is incomplete and should contain a hundred or more names. In such table, it is possible to observe that in the sixties, researchers have been adopting PE techniques in the world of computers and computer communication systems. Furthermore, since 80s performance simulation approaches have been taken over in the Internet. Table 2.1: Some Pioneers in Performance Evaluation.. Pioneers. Year. in. Erlang. 1908-18 Telephone traffic. Palm. 1943. Telephone traffic. approaches fundamental delay and loss formulas long-term variations. Jacobaeus 1950. switching networks. congestion in link systems. Clos. switching networks. nonblocking systems. 1953. Wilkinson 1955. toll traffic engineering. Cobham. 1954. operation research. priority assignment. Jackson. 1957. operation research. queuing in networks. Conway. 1958-67 operation research. scheduling. Scherr. 1965. time-sharing systems. Kleinrock 1964-74 ARPA. alternate routing systems. measurement and modeling performance and reliability. Buzen. 1971. computers. central server model. Bux. 1981. token ring network. performance simulation. Bellcore. 80th. Internet traffic. long-range dependency. In addition, performance analysis studies are conducted to evaluate existing or planned systems, to compare alternative configurations, or to find an optimal configuration of a system [Wel02]. The following sections presents an overview of the evaluation models and measurements techniques that have been conducted in order to measure and estimate the energy consumption and execution time of embedded system applications.. 2.1.1. Evaluation models. The performance evaluation can be classified into performance modeling and performance measurement [Joh06]. There are advantages and drawbacks to each of these techniques..

(24) 2.1 ENERGY CONSUMPTION AND PERFORMANCE EVALUATION. 8. Figure 2.1: Performance Evaluation. The most direct method for performance as well as power evaluation are based on actual measurement of the system under study. Although measurement techniques can provide exact answers regarding the performance and power, during the design phase, the system (hardware prototype) is not always available for such experiments, and yet performance of a given design needs to be predicted to verify that it meets design requirements and to carry out necessary trade-offs [Bol06]. Another drawback of the measurement approach is that performance (energy consumption also) of only the existing configuration can be measured or, in the best cases, it might allow limited reconfiguration through code changing. Furthermore, the measurement results may or may not be accurate depending on the current states of the system, in which such technique has been performed. It is also important to state that a possible solution for such issue could be the adoption of statistical approaches that may guarantee the measurement results. Instead, the computational effort (human also) may turn this solution inadequate. Modeling methods are typically adopted in early stages of the design process, when entire systems or prototypes are not yet available for measurements. Performance modeling may further be divided into simulation-based modeling and analytical modeling. Figure 2.1 shows the classification of performance evaluation, in which the analytical models deal with probabilistic methods, queuing theory, Markov models, or Petri nets [Joh06]. The basic principle of the analytic approaches is to represent the formal system description either as a single equation from which the interesting measures can be obtained as closed-form solutions, or as a set of system equations from which exact or approximate metrics can be calculated through numerical methods [Bol06]. However, in order to be able to have tractable solutions, simplified assumptions are often made regarding the structure of the model and, hence, a compromise between tractability and accuracy is often a challenge. In fact, Jain [Jai91] has observed that “analytical modeling requires so many simplifications and assumptions that if the results turn out to be accurate, even the analysts are surprised”. An alternative to analytical models is the adoption of simulation-based models, where the most popular of them are based on discrete-event simulation (DES) [Bol06]. The results obtained through simulation approaches have not been so accurate as the ones.

(25) 2.1 ENERGY CONSUMPTION AND PERFORMANCE EVALUATION. 9. provided by measurements techniques, but it is possible to calculate the estimates precision. The principal drawback of simulation models, however, is the time taken to run such models for large, realistic systems, particularly when results with high accuracy (i.e.: narrow confidence intervals) are desired. Simulation approaches deal with a statistical investigation of output data of both performance and energy analysis, and the verification and validation of simulation experiments. It is important to state that each technique can be adopted in different situation. Thus, the decision of which approach should be adopted depends on each situation. Another characteristic that the reader should be in mind is to create appropriate models containing only needed details to simplify the models. The next section describes some measurement strategies and their issues.. 2.1.2. Measurement Strategies. It is possible to adopt many different types of performance metrics in order to perform a measurement. Different strategies are adopted for measuring the values of these metrics considering the system state changes (events). These events are classified as: Event-count metrics. Metrics that just counts the number of times a specific event occurs. An Example of event-count metrics is the number of disk input/output requests performed by a software. Secondary-event metrics. These types of metrics record the values of secondary parameters after an event happens. For instance, in the performance evaluation of a software, its energy consumption value may be computed. Profiles. A profile is an aggregate metric used to characterize the overall behavior of an application program or of an entire system. Typically, it is used to identify where the program or system is spending its execution time. The above event-type classification is useful for helping the performance analyst to decide which measurement technique will be adopted, since different types of measurement tools are appropriate for measuring different types of events. There are basically three measurement strategies: (i) Event-driven. This strategy records only the information necessary to compute the performance metric. The simplest type of an event-driven measurement tool adopts the Event-count metrics in order to produce the results. This measurement technique is usually considered for low-frequency event systems. (ii) Sampling. Samples of the executing program are taken at fixed points in time. As a consequence, statistical approach has to be adopted to obtain precise results..

(26) 2.1 ENERGY CONSUMPTION AND PERFORMANCE EVALUATION. 10. (iii) Indirect. This strategy is considered when the desired performance metric is difficult (or impossible) to measure directly. In this case, another metric is measured from which the results are obtained. There are advantages and drawbacks to each of these techniques. An event-driven measurement tool provides only a higher-level summary of the system behavior, such as overall counts or average durations. In contrast, sampling strategy adopts statistical approaches in order to provide the information. Thus, its results vary slightly each time the experiment is performed. The indirect strategy is just performed when the direct metric is not available. Several of the fundamental techniques that have been used for implementing the various measurement strategies are described in the following sections. Interval timers An interval timer is adopted to measure the execution time of a software or any code blocks within an application. It can also provide the time basis for a sampling measurement tool. The interval timer basic idea is to count the number of clock pulses that happens among the events. For that, calls to a routine that record the current timer count values are inserted before and after the predefined events. There are two common implementations of interval timers, one considering software interrupt and one adopting hardware counter. Hardware timers compute the number of pulses they receive at their clock input from a clock source. The counter starts from “0” when the system is powered up and, so, the value read from the counter corresponds to the number of clock ticks that have occurred. On the other hand, the software interrupt adopts the hardware clock to generate a processor interruption. The interrupt-service routine is responsible to increment the counter variable that is read by an application. Measurement perturbations The measurement techniques implementation can perturb the computer systems performance measurement results. In order to obtain higher resolution measurements, for instance, more instrumentation points in a program are adopted. However, this causes more perturbations in the program than in its usual execution behavior. As a result, only the important data to infer the behavior of the system should be considered. Measurement noise Time is a fundamental quantity that needs to be measured to determine almost any aspect of a computer system’s performance [Mea00]. There are three important characteristics that determine the quality of the measurement results: (i) accuracy, the absolute difference between a measured value and the corresponding reference value; (ii) precision, the repeatability of the measurements performed; and (iii) resolution, the smallest incremental change that can be detected and displayed by a measuring tool..

(27) 2.2 SIMULATION PROCESS. 11. Figure 2.2 depicts a histogram that shows the number of times each specific measurement occurred. Moreover, the histogram distribution indicates the measurement precision by the spread of the measurements around the mean value. On the other hand, accuracy is the difference between the mean of the measured values and the true value (see Figure 2.2).. Figure 2.2: Histogram showing accuracy and precision.. Measuring accuracy, precision and resolution individual errors are difficult to be quantified by the results. Instead, a confidence interval for the mean value is adopted to quantify the precision of measurement results. On the other hand, quantifying the accuracy of measurements is more difficult because it involves, for example, the calibration of the clock source with a standard measurement of time.. 2.2. SIMULATION PROCESS. Simulation is the execution of a model that reproduces the system behavior that it represents. In this context, there are two types of systems: terminal and non terminal. The terminal systems, also called transient systems, are those ones in which there are initial and final states well determined. The non terminal, also named stationary systems, consists of systems that the simulation is finished through a statistical stop criteria evaluation instead of an event that could happen. A stationary simulation approach has been adopted in this work. Figure 2.3 depicts a general simulation process [LK99]. The simulation starts on the main program which invokes the initialization routine. The initialization routine sets the.

(28) 2.3 SYSTEM CLASSIFICATIONS. 12. simulation clock to “0” (variable indicating the current value of simulated time), initializes counters (variables used for storing statistical information about system performance and energy consumption), and starts the event list (list that contains the transition times for each transition able to fire). Afterwards, the main program invokes the timing routine which determines the next event type (the transition that is fired) and advances the simulation clock. Next, the main program invokes the event routine, in which the system state and statistical counters are updated, future events are generated and added to the event list. Then, it is determined whether the simulation should be finished or not, according to the stop criteria evaluation. After finishing the simulation, the estimates results are showed.. Figure 2.3: Simulation process diagram.. 2.3. SYSTEM CLASSIFICATIONS. This dissertation adopts a temporized discrete event system through stochastic simulation. Before getting into the details of this particular class of systems, it is reasonable to start out by simply describing what the word “system” means, and by presenting the system classifications. Systems does not have an exact definition. Three representative system definitions are presented as follows: (i) An aggregation or assemblage of things so combined by nature or man as to form an integral or complex whole (Encyclopedia Americana). (ii) A regularly interacting or interdependent group of items forming a unified whole (Webster’s Dictionary). (iii) A combination of components that act together to perform a function not possible with any of the individual parts (IEEE Standard Dictionary of Electrical and Electronic Terms). The system classifications have been adopted to describe the scope of different aspects of system and control theory. Such classification is really important in order to understand.

(29) 2.3 SYSTEM CLASSIFICATIONS. 13. the adopted models and simulation mechanism (temporized discrete event models through stochastic simulation) by this work. Figure 2.4 depicts these classifications in which systems are divided into two main groups, Static, system that does not depend on the past, and Dynamic, which are systems whose output depends on the input. The Dynamic systems can be dived into time-varying and time-invariant. The time-invariant systems, also called stationary systems, are divided into linear and non-linear systems. The non-linear, a system whose performance cannot be described by equations, is divided into discrete-state and continuous-state systems. The discrete-state system is divided into event-drive and time-driven systems. The event-drive system, in which the state is changed by the occurrence of an event, is divided into stochastic and deterministic systems. The stochastic system is divided into discrete-time and continuous-time. The following items describe each system in more details. Static and Dynamic Systems. Systems whose output is always independent of past values of the input are classified as static. On the other hand, dynamic systems are those systems whose output depend on past values of the input. In order to describe the behavior of dynamic systems, differential equations are generally required. Time-varying and Time-invariant Systems. The behavior of time-invariant systems does not change with time. This property, also called stationarity, implies that such systems always respond in the same way. Linear and Nonlinear Systems. A linear system satisfies the condition g(a1 u1 + a2 u2) = a1 g(u1) + a2 g(u2 ), where u1 , u2 are two input vectors, a1 , a2 are two real numbers, and g() is the resulting output. Thus, linear systems correspond to system where all the interrelationships among the quantities involved cannot be expressed by linear equations (e.g.: algebraic, differential or integral) Continuous-State and Discrete-State Systems. The state variables can generally take on any real (or complex) value in continuous-state systems. In discrete-state systems, the state variables are elements of a discrete set (e.g.: the non-negative integers). Time-driven and Event-driven Systems. The state continuously changes as time changes in time-driven systems. In event-driven systems, it is only the occurrence of asynchronously generated discrete events that forces instantaneous state transitions. Deterministic and Stochastic Systems. A system becomes stochastic whenever one or more of its output variables is a random variable. In this case, the state of the system is described by a stochastic process, and a probabilistic framework is required to characterize the system behavior. Discrete-time and Continuous-time Systems. In continuous-time systems, all input, state, and output variables are defined for all possible values of time. On the other side, discrete-time systems have one or more of these variables defined at discrete points in time only, usually as the result of some sampling process..

(30) 14. 2.4 PETRI NETS. Figure 2.4: System classifications.. 2.4. PETRI NETS. Formal methods consist of writing formal descriptions, analyzing those descriptions and, in some cases, producing new descriptions from them in order to obtain refinements [Hal07]. Among the formal methods, Petri nets have been adopted in this work. Petri nets (PN) were introduced in 1962 by the PhD dissertation of Carl Adams Petri [Pet62], at Technical University of Darmstandt, Germany. The original theory was developed as an approach to model and analyze communication systems. Petri Nets (PNs)[Mur89] are a graphic and mathematical modeling tool that can be applied in several types of systems and allow the modeling of parallel, concurrent, asynchronous and non-deterministic systems. Since its seminal work, many representations and extensions have been proposed for allowing more concise descriptions and for representing systems feature not observed on the early models. Thus, the simple Petri net has subsequently been adapted and extended in several directions, in which timed, stochastic, high-level, object-oriented and coloured nets are a few examples of the proposed extensions..

(31) 15. 2.4 PETRI NETS. 2.4.1. Place-Transition Nets. Place/Transition Petri nets are one of the most prominent and best studied class of Petri nets, and it is sometimes called just by Petri net (PN). A marked Place/Transition Petri net is a bipartite directed graph, usually defined as follows: Definition 2.4.1. (Petri Net) A Petri net [Mur89] is a 5-tuple: P N = (P, T, F, W, M0 ) where: (i) P = {p1 , p2 , ..., pm } is a finite set of places; (ii) T = {t1 , t2 , ..., tn } is a finite set of transitions; (iii) F ⊆ (P × T ) ∪ (T × P ) is a set of arcs (flow relation); (iv) W : F →{1, 2, 3, ...} is a weight function; (v) M0 : P → {0, 1, 2, 3, ...} is the initial marking; This class of Petri net has two kinds of nodes, called places (P ) represented by circles and transitions (T ) represented by bars, such that P ∩ T = Ø and P ∪ T = Ø. Figure 2.5 depicts the basic elements of a simple PN. The set of arcs F is used to denote the places connected to a transition (and vice-versa). W is a weight function for the set of arcs. In this case, each arc is said to have multiplicity k, where k represents the respective weight of the arc. Figure 2.6 shows multiple arcs connecting places and transitions in a compact way by a single arc labeling it with its weight or multiplicity k.. Figure 2.5: Petri net basic elements.. Places and transitions may have several interpretations. Using the concept of conditions and events, places represent conditions, and transitions represent events, such that, an event may have several pre-conditions and post-conditions. For more interpretations, Table 2.2 shows other meanings for places and transitions [Mur89]..

(32) 16. 2.4 PETRI NETS. Figure 2.6: Compact representation of a PN Table 2.2: Interpretation for places and transitions.. Input Places. Transitions. pre-conditions. events. input data. computation step. input signals. signal processor. resource needed tasks conditions. logical clauses. buffers. processor. Output Places post-conditions output data output signals resource releasing conclusions buffers. It is important to show that there are another way to represent PN’s elements. As an example, the set of input and output places of transitions is shown in Definition 2.4.2. Similarly, the set of input and output transitions of determinate place is shown in Definition 2.4.3. Definition 2.4.2. (Input and Output Transitions of a place) The set of input transitions (also called pre-set) of a place pi ∈ P is: •pi = {tj ∈ T |(tj , pi ) ∈ F }. and the set of output transitions (also called post-set) is: pi • = {tj ∈ T |(pi , tj ) ∈ F }. Definition 2.4.3. (Input and Output Places of a transition) The set of input places of a transition tj ∈ T is:.

(33) 17. 2.4 PETRI NETS. •tj = {pi ∈ P |(pi , tj ) ∈ F }. and the set of output places of a transition tj ∈ T is: tj • = {pi ∈ P |(tj , pi ) ∈ F }. 2.4.2. Marked Petri Nets. A marking (also named token) has a primitive concept in PNs such as place and transitions. Markings are information attributed to places; the number and mark distributions consist of the net state in determined moment. The formal definitions are presented as follows. Definition 2.4.4. (Marking) Considering the set of places P in a net N, the formal definition of marking is represented by a function that maps the set of places P into non negative integers M : P → N. Definition 2.4.5. (Marking vector) Considering the set of places P in a net N, the marking can be defined as a vector M = (M(p1 ), ..., M(pn )), where n = #(P ), ∀pi ∈ P / M(pi ) ∈ N. Thus, such vector gives the number of tokens in each place for the marking Mi . Definition 2.4.6. (Marked net) A marked Petri net is defined by a tupla NM = (N; M0 ), where N is the net structure and M0 is the initial marking. A marked Petri net contains tokens, which reside in places, travel along arcs, and their flow through the net is regulated by transitions. A peculiar distribution (M) of the tokens in the places, represents a specific state of the system. These tokens are denoted by black dots inside the places as shown in Figure 2.5 (d).. 2.4.3. Transition Enabling and Firing. The behavior of many systems can be described in terms of system states and their changes. In order to simulate the dynamic behavior of a system, a state (or marking) in a Petri net is changed according to the following firing rule:.

(34) 2.4 PETRI NETS. 18. (i) A transition t is said to be enabled, if each input place p of t is marked with at least the number of tokens equal to the multiplicity of its arc connecting p with t. Adopting a mathematical notation, an enabled transition t for given marking mi is denoted by mi [t >, if mi (pj ) ≥ W (pj , t), ∀pj ∈ P . (ii) An enabled transition may or may not fire (depending on whether or not the respective event takes place). (iii) The firing of an enabled transition t removes tokens (equal to the multiplicity of the input arc) from each input place p, and adds tokens (equal to the multiplicity of the output arc) to each output place p . Using a mathematical notation, the firing of a transition is represented by the equation mj (p) = mi (p)−W (p, t)+W (t, p), ∀p ∈ P . If a marking mj is reachable from mi by firing a transition t, it is denoted by mi [t > mj . Figure 2.7 (a) shows a Petri net model example with three places and one transition. Figure 2.7 (b) outlines its respective graphical representation, and Figure 2.7 (c) provides the same graphical representation after the firing of t0 . For this example, the set of reachable markings is m = {m0 = (3, 1, 0), m1 = (1, 0, 2)}. The marking m1 was obtained by firing t0 , such that, m1 (p0 ) = 3 - 2 + 0, m1 (p1 ) = 1 - 1 + 0, and m1 (p2 ) = 0 - 0 + 2.. Figure 2.7: (a) Mathematical formalism; (b) Graphical representation before firing of t0 ; (c) Graphical representation after firing of t0 .. 2.4.4. Petri Net Analysis Methods. In order to verify that a given PN satisfies certain properties (e.g.: deadlock freedom, liveness [Mur89]), it is necessary to adopt some analysis methods. The Petri net analysis methods may be divided into three groups: the reachability tree method, analysis based on the matrix-equations and reduction techniques. In this work, the analysis based on reachability tree and reduction techniques are presented..

(35) 2.4 PETRI NETS. 19. Reachability Based Methods The analysis method namely Reachability Tree is based on the building of a tree that makes possible to represent all reachable markings of a net [MLC96]. From the initial marking of a PN, it is possible to obtain some markings through the fireable transitions. Such possibilities can be represented as a tree, where the nodes correspond the markings and the arcs represent the fired transitions. The reachability tree has been generated through initial marking of the net and adding directly reachable markings as leaves. Next, the process proceeds by these new markings in order to determine their directly reachable markings. These markings now become the new leaves of the already generated part of the reachability tree. If the desired marking is reached, it is not necessary to continue building the tree any further at that node. Such Reachability trees can be transformed directly into graphs by removing multiple nodes and connecting the nodes appropriately. This graph is called a reachability graph. Definition 2.4.7. (Reachability Tree) Considering a Marked Petri net MN = (N; M0 ), a reachability tree is defined by RT = (S, A), where S represents the markings and A the labeled arcs by tj ∈ T . Some PN’s properties such as boundedness, safetness, deadlock freedom and reachability can be analyzed through these reachability tree T by adopting the following rules [Mur89]:. (i) A Marked Petri net (N; M0 ) is bounded and thus R(M0 ) is finite if and only if (iff) W (from the weight function - Definition 2.4.1) does not appear in any node labels in T ; (ii) A Marked Petri net (N; M0 ) is safe iff only 0’s and 1’s appear in code labels in T ; (iii) A transition t is dead iff it does not appear as an arc label in T ; (iv) If M is reachable from M0 , then there will be a node labeled M such that M ≤ M . A major problem of this approach arises with the analysis of systems in which the number of reachable markings is infinite (unbounded systems). Due to the infinite number of markings, such systems are not easily represented by enumeration. Reduction techniques Reduction analysis deals with the reduction of the Place-Transition net by replacing subnets of the net by less complex subnets such that several properties remain invariant. A reduction technique that reduces sequential states (places) has been considered in the.

(36) 20. 2.4 PETRI NETS. Font: [BK02, p. 113]. Figure 2.8: Simple reduction rule.. Petri net model showed in Figure 2.8. This figure shows that the places p1 and p2 were replaced by the place p . Figure 2.9 (a) depicts a petri net model in which it is possible to observe that the place p3 represents a redundant path. In order to reduce the redundant path, a transformation starts by removing arcs from transitions to the place. If all arcs are removed, then the place can be removed from the PN. A place is redundant “when its marking is always sufficient for allowing firings of transitions connected to it” [Ber86]. Figure 2.9 (b) shows the petri net model after performing the reduction technique for removing the redundant path.. Font: [BK02, p. 114]. Figure 2.9: Reduction of a PN with a redundant place.

(37) 21. 2.4 PETRI NETS. Murata [Mur89] presented other simple reduction rules, in which the nets have been reduced by applying fusion of places and transitions, and by the elimination of loops. Figure 2.10 depicts six reduction operations. (i) Fusion of Series Places, Figure 2.10 (a). (ii) Fusion of Series Transitions, Figure 2.10 (b). (iii) Fusion of Parallel Places, Figure 2.10 (c). (iv) Fusion of Parallel Transitions, Figure 2.10 (d). (v) Elimination of Self-Loop Places, Figure 2.10 (e). (vi) Elimination of Self-Loop Transition, Figure 2.10 (f).. Font: [Mur89, p. 553]. Figure 2.10: Six transformations preserving properties..

(38) 2.5 TIME EXTENSIONS. 2.5. 22. TIME EXTENSIONS. The original definition of Petri nets does not include any notion of time and their aims are to model the logical behavior of systems by describing the causal relations between their events. Many researches have been proposing different ways for incorporating timing in Petri Nets, and the first ones related to them were presented by P.M Merlin et al. [MF76] and J.D Noe et al. [NN73]. In Timed Petri nets (TPN), time may be associated to places, transitions or tokens [vdAvHR00] such that: P laces : The time can be associated to places, in which the markings in the output places only will be available to fire after a determinate amount of time. T oken : The time can be added to the token, in which it have an information indicating when the token will be available to fire a transition. T ransitions : The time can be associated to transitions. In this case, the fire of a transitions only happens after some delay correspondent to the time associated to the transition. In TPN, the time can be deterministic, stochastic or between intervals. Deterministic : In this case, a deterministic time is adopted to represent the events. Interval Computations: In this case, intervals are adopted in order to describe the higher and shorter limits related to the time of each activity. Stochastic : This model adopts a probabilistic approach. Since transitions represent activities that change the state (marking) of the net, it seems natural to associate time to transitions. For this, there are two different firing policies in TPN: Three-phase firing: a first instantaneous phase in which an enabled transition removes tokens from its input places, then a timed phase in which the transitions are working, and a final instantaneous phase in which tokens are deposited into the output places. Such time information is called duration; Atomic firing: Tokens remain in input places during the whole transition delay; after that period such tokens are consumed from input places and generated in output places when the transition fires. The firing itself does not consume any time. In atomic firing, when a transition is able to fire, a timer associated to the transition is started. Such timer decreases in a constant way, and the transition is fired when the timer value goes to zero. There is an issue related to the other transitions timers and, in order to solve such issue, the following approaches have been adopted to represent the memory policies whenever a transition fires [vdAvHR00]:.

(39) 2.6 COLOURED PETRI NETS. 23. Resampling : the timers of all transitions are discarded (restart mechanism). New values of timers are reset for all enabled transitions at a new marking; Enabling memory: transitions that are still enabled in the new marking keeps the value of the timer; transitions that are not enabled have their timers reset. The enabling time of a transition is measured since the last instant of time it became enabled; Age memory: the timer value is kept, even if the transition is not enabled in the new marking. Whenever this transition becomes enabled, the counting is resumed from the kept value.. 2.6. COLOURED PETRI NETS. Among the Petri net extensions that have been proposed, it is important to stress Jensen’s high-level model, the so called Coloured Petri net (CPN)[Jen95] [JKW07]. In this model, a token may have complex data type as in programming languages; each place has the correspondent data type, hence restricting the kind of tokens that it may receive; the transitions process the token values and create new ones with different values; hierarchy structure can be modeled with different abstraction levels, where each transition may describe another net (called subnet), and so on. Indeed, CPN is a high-level model that considers abstract data-types and hierarchy. Likewise in PN, places are graphically represented by ellipses, transition by rectangles, and arcs by direct arrows. Moreover, a Timed CPN has been adopted in this research. The main difference between timed and non timed CPN models is that the tokens in a timed CPN model, in addition to the token colour, can carry a second value called a time stamp [JKW07]. CPN has some properties which turns such formalism a valuable language for the design, specification and analysis of many different types of systems. Among these properties, it is possible to stress: (i) well-defined semantics: CPNs have a well-defined semantics that turns them able to represent complex systems; (ii) hierarchical descriptions: it is possible to build a large and complex CPN by relating smaller CPNs to each other, in a well-defined way. This hierarchical property is similar to subroutines, procedures and modules of programming languages; (iii) time concept: CPNs can be extended to cover the time concept; (iv) interactive simulations. In CPN simulations, it is possible to fire a determinate number of transitions and to see their result values instantaneously; (v) inscriptions: CPNs allow one to associate inscriptions to CPN components such as places, arcs, and transitions in order to improve their functionalities;.

(40) 24. 2.6 COLOURED PETRI NETS. (vi) reduction process: due to their precise semantics, it is possible to apply a reduction process where a new simplified CPN model can be obtained preserving determinate properties. The formal definition of Coloured Petri nets is based on the following entity definitions. Definition 2.6.1. (Multi-set) Multi-set is a function that describes the set of element collections with identical colour (data type). Let N be the set of all non-negative integers. The multi-set MS, defined over a non-empty set S, is a function m : S → N, where: MS =. . m(s) s. s∈S. SM S denotes the set of all multi-sets over S. The non-negative integers {m(s)|s ∈ S} are the coefficients of the multi-set. Considering a collection of tokens that represents the pets in a house, this token type is “PET”. A state of the house related to the number of pets can be defined by: 2 tokens representing “dog” value and 4 tokens representing “cat” value. This multi-set is: MS =. . m(s) s = 2 dog + 4 cat.. s∈S. Multi-sets consider a number of standard operations. Definition 2.6.2. (Multi-set Operations) Let a set of multi-set {m, m1 , m2 }⊆ SMS and n a non-negative integer. The following basic operations are defined among multisets: (i) m1 + m2 =. . (m1 (s) + m2 (s))’s (addition). s∈S. (ii) n ∗ m =. . (n * m(s))’s (scalar multiplication). s∈S. (iii) m1 = m2 ⇒ ∃s ∈ S|m1(s) = m2(s) (comparison =) (iv) m1 ≤ m2 ⇒ ∃s ∈ S|m1(s) ≤ m2(s) (comparison ≤) (v) m1 ≥ m2 ⇒ ∃s ∈ S|m1(s) ≥ m2(s) (comparison ≥).

(41) 2.6 COLOURED PETRI NETS. (vi) |m| =. . 25. m(s) (size). s∈S. (vii) m2 - m1 =. . (m2 (s) - m1 (s))’s, iff(if and only if) m2 ≥ m1 (subtraction). s∈S. For a better comprehension of the formal concepts related to CPN, it is also important to define some primitive operators. Definition 2.6.3. (Type operator) Let V , the set of variables; EXP , expressions and T , model types. The function T ype : V ∪ EXP → T denotes type operator, where T ype(exp) maps the variable or expression exp into a valid type.. Definition 2.6.4. (Operator of set of variables) Let V be the set of variables and EXP expressions. The function V ar : EXP → V denotes the operator of set of variables, where V ar(exp) represents the set of variables in an exp expression.. The Formal definition of Coloured Petri nets is presented as follows. Definition 2.6.5. (Coloured Petri Net) The non-hierarchical definition of Coloured Petri Net [Jen94] is a nine-tuple: CP N = ( , P, T, A, N, C, G, E, I) satisfying the following requirements: (i). . is a finite set of non-empty types, called colour sets;. (ii) P is a finite set of elements (Places) that represents local states; (iii) T is a finite set of elements (Transitions) that depicts events and actions; (iv) A is a finite set of arcs such that P ∩ T = P ∩ A = T ∩ A = Ø; (v) N is a node function defined from A into P × T ∪ T × P ;.

(42) 26. 2.6 COLOURED PETRI NETS. (vi) C is a colour function defined from P into. ;. (vii) G is a guard function defined from T into expressions such that: ∀t ∈ T : [T ype(G(t)) = Bool ∧ T ype(V ar(G(t))) ⊆ ], where Bool ∈{true, f alse}; (viii) E is an arc function defined from A into expressions such that: ∀a ∈ A : [T ype(E(a)) = C(p(s))M S ∧ T ype(V ar(E(a))) ⊆ ], where p(a) is the place of N(a) and CM S denotes the set of all multi-sets over C; (ix) I is an initialization function defined from P into closed expressions such that ∀p ∈ P : [T ype(I(p)) = C(p(s))M S ]. where: T ype(expr) denotes the type of an expression; V ar(expr) denotes the set of variables in an expression; C(p)M S denotes a multi-set over C(p).. After analyzing the formal definition of CPN, the reader should conclude that: The set of types - item(i) - determines the data values, operations and functions that can be adopted in the net expressions (i.e.: arc expressions, guards and initialization expressions). Places, transitions and arcs - item (ii), (iii), (iv) - are described by three sets P , T and A which are finite and pairwise disjoint (P ∩ T = P ∩ A = T ∩ A = Ø). The node function - item (v) - maps each arc into a pair where the first element is the source node and the second the destination node. It is important to stress that both elements must be of different kind (i.e.: place and transition). The colour function C - item (vi) - maps each place, p, to a type C(p)∈ . This means that each token on p must have a data value that belongs to C(p). The guard function G - item (vii) - maps each transition, t, into a boolean expression, where all variables have types that belong to S. The arc expression function E - item (viii) - maps each arc, a, into an expression of type C(p)M S . This means that each arc expression must evaluate to multi-sets over the type of the adjacent place, p. The initialization function I - item (ix) - maps each place, p, into a closed expression which must be of type C(p)M S . A Closed expression is an expression without variables.

(43) 2.6 COLOURED PETRI NETS. 27. which can be evaluated in all bindings, and all evaluations give the same value. The behavior of CPN models For a better comprehension of concepts related to the behavior of CPN models, it is important to introduce the following notation for all t ∈ T and for all pairs of nodes (x1 , x2 )∈(P × T ∪ T × P ): A(t) = {a ∈ A|N(a) ∈ (P × T ∪ T × P )} V ar(t) = {v|v ∈ V ar(G(t)) ∨ ∃a|a ∈ A(t): v ∈ V ar(E(a))} A(x1 , x2 ) = {a ∈ A|N(a) = (x1 , x2 )} E(a) E(x1 , x2 ) = (a∈A(x1 ,x2 )). In CPNs, sometimes token values refer to token colours, in the same way data types are referred as colour sets. The formal definition of token is depicted as follows. Definition 2.6.6. (Token) Token represents a value (literal) that can be either primitive or composite data types. A token element is a pair (p, c) where p ∈ P and c ∈ C(p). T E denotes the set of all token elements.. Data values are assigned (bound) to variables present in the arc expressions on the surrounding arcs of transitions in order to evaluate whether a transition may or may not occur. The formal definition of binding element is presented as follows. Definition 2.6.7. Binding. A binding element is a pair (t, b) where t ∈ T and b ∈ B(t), where B(t) denotes the set of all bindings for t. A binding of a transition t is a function b defined on V ar(t), such that: (i) ∀v ∈ V ar(t): b(v) ∈ T ype(v). (ii) G(t) denotes the evaluation of the guard expression G(t) in the binding b.. A state of a CPN is called a marking [KCJ98], and its definition is given as follows..

(44) 28. 2.6 COLOURED PETRI NETS. Definition 2.6.8. Marking. It consists of a number of tokens positioned (distributed) on the individual places. Each token carries a value (colour), which belongs to the type of the place on which the token resides. The tokens present on a particular place are called the marking of that place. A marking is a multi-set over T E (the set of all token elements) while a step is a non-empty and finite multi-set over BE (the set of all binding elements). The initial marking M0 is the marking which is obtained by evaluating the initialization expressions. It is possible to attach a boolean expression (with variables), called guard, to each transition. A transition is enabled if each of its input places contains the multi-set specified by the input arc inscription and the guard evaluates to true. The formal definition of enabling a transition is defined as follows. Definition 2.6.9. Enabled Transitions. A step Y is enabled in a marking M if and only if the following property is satisfied: (i) ∀p ∈ P :. . E(p, t) ≤ M(p).. (t,b)∈Y. When a transition is enabled it may occur (fire). An occurrence of a transition removes tokens from places connected to incoming arcs (input places), and adds tokens to places connected to outgoing arcs (output places), thereby changing the marking (state) of the CPN [KCJ98]. The number and colour of the tokens are determined by the arc expressions, evaluated for the occurring bindings. The formal definition is presented as follows. Definition 2.6.10. Firing of an Enabled Transition. When a step Y is enabled in a marking M1 it may occur, changing the marking M1 to another marking M2 , defined by: (i) ∀p ∈ P : M2 (p) = (M1 (p) −. . E(p, t) ) +. (t,b)∈Y. . E(t, p) .. (t,b)∈Y. M2 is directly reachable from M1 (M1 [Y M2 ). where: The expression evaluation E(p, t) computes the tokens which are removed from p when t occurs with the binding b..