University of Southern California Dissertations and Theses

Analysis of embedded software architecture with precedent dependent aperiodic tasks

(USC Thesis Other)

Analysis of embedded software architecture with precedent dependent aperiodic tasks

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content Copyright 2017 Tatsuhiko Tomita Analysis of embedded software architecture with precedent dependent aperiodic tasks by Tatsuhiko Tomita A Thesis Presented to the FACULTY OF THE USC VITERBI SCHOOL OF ENGINEERING UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree MASTER OF SCIENCE (COMPUTER SCIENCE(SOFTWARE ENGINEERING)) May 2017 ii Acknowledgements I would especially like to thank my advisor, Professor Nenad Medvidović, who is also the chair of my thesis committee. Without his insightful comments and suggestions, I would have never completed this thesis. He has also been greatly tolerant and supportive when I make mistakes or fail to understand his suggestions. I would also like to thank each of the committee members, Professor William G.J. Halfond, and Professor Wang Chao, for the constructive comments they have given me on my research. I am grateful to Jasmine Espindola for carefully proofreading the manuscript. I would like to express my appreciation to Seiji Sasaki, General Manager at Canon Inc, who provided me with several suggestions about embedded software architectures. I would also like to express my gratitude to Canon Inc. for their financial support. Finally, I would like to thank my family for their moral support, warm encouragement, and great patience. iii Abstract Modern embedded software is more complex than before, therefore an early analysis of the software architecture is needed to reduce the development cost and risks. However, precedent aperiodic dependent tasks, which are widely used in embedded software, make the architectural analyses difficult because of their intricate interconnections. In more detail, each precedent dependent aperiodic task runs concurrently with other tasks as well as having precedent constraints with the others: in other words, it starts at different time depending on the other tasks’ end time. This makes analyzing software architectures difficult. To address the challenge, this thesis provides new tools that can analyze precedent aperiodic dependent tasks, while accepting existing architectural models so that developers do not need to prepare a new model or can reuse the model for other analyses. Specifically, this thesis focuses on the performance, scalability, and portability analyses, which are often needed in embedded systems. I have evaluated the new tools by using an evaluation platform, which I modeled by utilizing an existing architectural model, and proved that these tools could analyze software architectures with precedent dependent aperiodic tasks, which had not been able to be done by existing tools. iv Table of Contents Acknowledgements ................................................................................................................. ii Abstract .................................................................................................................................. iii Table of Contents ................................................................................................................... iv List of Tables ........................................................................................................................... vi List of Figures ......................................................................................................................... vii Chapter 1 Introduction ...................................................................................................... 1 1.1 Embedded software requirements and architectural decisions .................................... 2 1.1.1 Performance ............................................................................................................. 3 1.1.2 Scalability .................................................................................................................. 3 1.1.3 Portability ................................................................................................................. 4 1.2 Existing approaches for software analysis .................................................................... 5 1.2.1 Problems with precedent dependent aperiodic tasks ............................................. 7 1.3 Thesis statement, hypotheses, and assumptions ......................................................... 9 1.4 Approach to fix the issues and its contribution .......................................................... 10 1.5 Structure of this thesis............................................................................................... 14 Chapter 2 Background and Related Work ........................................................................ 15 2.1 Software Architecture ............................................................................................... 15 2.1.1 Software architecture verification ......................................................................... 16 2.1.2 Architecture Description Languages ...................................................................... 17 2.2 Existing approaches for software analysis .................................................................. 18 f2.2.1 Model-based software analysis approaches .......................................................... 18 2.2.2 Analysis approaches for pipelines .......................................................................... 21 Chapter 3 Evaluation platform ......................................................................................... 23 3.1 Tizen Multimedia Architecture .................................................................................. 23 3.2 Requirements ............................................................................................................ 27 3.3 Architectural decisions .............................................................................................. 29 Chapter 4 Approach ......................................................................................................... 36 4.1 AADL and analysis tools ............................................................................................. 36 4.1.1 AADL 36 v 4.1.2 Analysis tools using AADL ....................................................................................... 38 4.2 Analysis approaches .................................................................................................. 40 4.2.1 Performance analysis ............................................................................................. 40 4.2.2 Scalability analysis .................................................................................................. 47 4.2.3 Portability analysis .................................................................................................. 52 4.3 Technical approach ................................................................................................... 54 4.3.1 Performance analysis ............................................................................................. 54 4.3.2 Scalability Analysis .................................................................................................. 59 4.3.3 Portability Analysis ................................................................................................. 62 Chapter 5 Evaluation ....................................................................................................... 65 5.1 Performance analysis ................................................................................................ 67 5.2 Scalability Analysis .................................................................................................... 72 5.3 Portability analysis .................................................................................................... 74 Chapter 6 Conclusion ....................................................................................................... 79 6.1 Future Work .............................................................................................................. 80 Bibliography .......................................................................................................................... 82 Appendix ............................................................................................................................... 86 vi List of Tables Table 1 Requirements of evaluation platform ............................................................................... 28 Table 2 Architectural decisions of evaluation platform ................................................................. 29 Table 3 Correspondence between AADL and this thesis ............................................................... 66 vii List of Figures Figure 1 Precedent dependent aperiodic tasks ............................................................................... 1 Figure 2 Many sets of precedent dependent tasks (a) and the result of Cheddar (b)..................... 7 Figure 3 OSATE analyses for periodic tasks (a) and aperiodic tasks (b) ........................................... 8 Figure 4 Job Matrix Converter ....................................................................................................... 11 Figure 5 How to challenge the analysis of aperiodic tasks ............................................................ 12 Figure 6 Tizen Multimedia Framework .......................................................................................... 24 Figure 7 Tizen Gstreamer ............................................................................................................... 25 Figure 8 Tizen Player/Streaming Framework ................................................................................. 26 Figure 9 Overview of evaluation platform ..................................................................................... 27 Figure 10 Pipeline in evaluation platform ...................................................................................... 30 Figure 11 Simultaneous inputs to pipeline .................................................................................... 32 Figure 12 How the pipeline works for simultaneous inputs .......................................................... 32 Figure 13 Multiple Components .................................................................................................... 33 Figure 14 Alternatives for CPU allocating ...................................................................................... 35 Figure 15 OSATE overview ............................................................................................................. 39 Figure 16 What if you have too many plugins to analyze? ............................................................ 41 Figure 17 What if you have too many filters to analyze? .............................................................. 42 Figure 18 End-to-End Flow Declaration ......................................................................................... 42 Figure 19 The output of Cheddar (timeline) .................................................................................. 43 Figure 20 The output of Cheddar (XML) ........................................................................................ 44 Figure 21 AADL Example of precedent dependent aperiodic tasks ............................................... 45 Figure 22 A task set affecting the other’s total execution time .................................................... 46 viii Figure 23 Using a hard disk drive in the evaluation platform ........................................................ 47 Figure 24 HDD alternatives for multiple components ................................................................... 48 Figure 25 Example of scalability analysis ....................................................................................... 49 Figure 26 Precedent dependent periodic tasks analysis ............................................................... 50 Figure 27 Precedent dependent aperiodic tasks analysis .............................................................. 51 Figure 28 Alternatives for portability ............................................................................................. 53 Figure 29 Job Matrix Converter ..................................................................................................... 54 Figure 30 Toolchain of Execution Time Analyzer ........................................................................... 56 Figure 31 Execution Time Analyzer output (Time-lined view) ....................................................... 57 Figure 32 Task delay because of other jobs ................................................................................... 58 Figure 33 Execution Time Analyzer output (Matrix view) ............................................................. 59 Figure 34 OSATE plugin architecture ............................................................................................. 59 Figure 35 Algorithm of Bus Load analysis tool ............................................................................... 60 Figure 36 Example AADL for bus load analysis .............................................................................. 62 Figure 37 Algorithm of Resource Allocation analysis tool.............................................................. 63 Figure 38 Example AADL for resource allocation analysis ............................................................. 64 Figure 39 AADL for Evaluation Platform ........................................................................................ 65 Figure 40 Estimated execution time .............................................................................................. 67 Figure 41 Task precedence of the evaluation platform ................................................................. 68 Figure 42 Job Matrix in AADL ......................................................................................................... 68 Figure 43 Cheddar original output ................................................................................................. 69 Figure 44 Time-Lined View ............................................................................................................. 70 Figure 45 Matrix View .................................................................................................................... 71 Figure 46 AADL for Multiple component ....................................................................................... 72 Figure 47 Problem of the original OSATE bus load analysis .......................................................... 73 ix Figure 48 A result of the new bus load analysis tool ..................................................................... 73 Figure 49 AADL for portability analysis: Alternative 1 ................................................................... 75 Figure 50 AADL for portability analysis: Alternative 2 ................................................................... 75 Figure 51 Problem of the original OSATE resource allocation analysis ......................................... 76 Figure 52 A result of the new resource allocation analysis tool .................................................... 77 1 Chapter 1 Introduction Software architecture has a potent influence on key requirements of a product. When designing the software architecture in embedded systems, for example, developers need to take the several software non-functional requirements into account. This thesis focuses on the following three requirements: A) Performance: often considered as an important factor in embedded product competitiveness, for example, the number of papers printed per unit time on printers, continuous shooting speed on cameras, decoding/encoding speed on video servers. B) Scalability: needed in product lines so that developers can provide various types of products derived from the system architecture. C) Portability: this is important because the hardware or platform can be changed in the future product or even as the current product is still in development. Software needs to be portable across different hardware platforms. Software architectures are useful not only to decide the principal designs for the requirements as described above, but also to verify the system prior to implementation. Verifying a software architecture beforehand decreases finding architecture-related errors at the end of the development process: as a result, it will help decrease costs of revising or reconsidering the software architecture, which is generally considered to be very costly. Figure 1 Precedent dependent aperiodic tasks 2 In resource-restricted embedded systems, developers often use precedent dependent aperiodic tasks, where each task runs concurrently with other tasks as well as having precedent constraints with the others (see Figure 1). This technique is widely used in software pipeline architectures so that developers receive the benefits of flexibility and concurrency of the system. This is why it is important to be able to analyze these constraints especially for embedded software developers. However, precedent dependent aperiodic tasks are hard to analyze although a lot of techniques have been proposed to analyze software architecture at an early stage of a development process. The goal of this thesis is to make it possible to analyze embedded software architectures that have precedent dependent aperiodic tasks. In the remainder of this chapter, I will first provide examples of software architectural decisions for the following requirements of embedded systems, A) performance, B) scalability, and C) portability, and then I will discuss existing software architecture analysis methods that aim to analyze these architectural decisions and the current proposals’ limitations. Then I will provide my insights and hypotheses that will be tested by this thesis. After all, I will explain my new approach aimed at being able to analyze precedent dependent aperiodic tasks, which are currently not supported by existing software architecture analysis methods. 1.1 Embedded software requirements and architectural decisions In this section, I will first explain the following requirements of embedded systems: A) performance; B) scalability; and C) portability, and provide examples of typical architectural decisions for each of the requirements. 3 1.1.1 Performance Embedded systems often have performance related requirements and the implementation of these requirements gives them the ability to compete with other products on the market. Therefore, software architects have to consider how they accomplish these performance related requirements in their software architecture. More importantly, they also have to analyze whether the software architecture carries out the performance related requirements in complicated situations: such as, where various operations with different implications on performance are running in parallel; where the various performance qualities are needed in each product in the product lines; and where the performance requirements need to be satisfied in different hardware or platform alternatives. Architectural decisions for performance Pipeline architecture has widely been used both to obtain high throughput and to use hardware resources effectively [1]. Decomposing a function into sub-functions and allocating hardware resources to each sub-function, a pipeline architecture enables the system to be executed in parallel which results in high throughput. Since many embedded systems are in the domain of networking services, voice- or image-processing, and multimedia tasks, many of them use a streaming-based structure: that is, using limited number of hardware resources in parallel in order to obtain maximum performance and this structure therefore is suitable to pipeline architecture. 1.1.2 Scalability Many embedded systems have their product lines [2] where they use the same software architecture but the different hardware or platforms: for example, low-priced products use a 4 single processor while high-priced ones use multiple processors; or portable devices use flash memories while desktop devices use hard disk drives. A well-defined software architecture can be used for the various products in the product line so that it significantly decreases the cost of implementation for each of them. Architectural decisions for scalability To satisfy the requirement of scalability, software architects use multiplicities as the software architectural decision [3]. By using this technique, a component that seems to be the bottleneck of the system due to having heavy computation to carry out or being used by many other components, is treated as multiple components: so that it can be instantiated more than one time and those instances can be processed simultaneously. As the product needs more performance, developers instantiate more multiple components to satisfy the performance related requirements: for example, in web service application with server-client architecture, the server can generally handle multiple clients by instantiating multiple client components; or in video servers, the developers can add more processors to handle decoding/encoding processes according to the requirement of the number of jobs simultaneously executable in the system. 1.1.3 Portability Embedded software, especially in its product line, needs to be executed in different environments: for example, low-priced products that use embedded operating systems and CPUs or high-priced ones that use Linux and Intel CPUs, and as the hardware are upgraded when technology improves. The environment can even be changed during the development of a product: for example, if developers were originally going to use platform A but realize it was not 5 capable of fulfilling their requirements in the middle of development, they would be able to change to platform B. If an embedded software has these portability requirements, software architects have to design it to be able to change its environment. Architectural decisions for portability Message bus [4] [5] [6] provides a way to receive and send messages for software components so that the components can interact with each other without knowing specific details about either the other component or the environment where the system is running. By using a message bus, developers do not have to worry about the implementation of communication between components. In addition, the components using message bus are portable and can be moved to different environments as long as the environment supports the same message bus. 1.2 Existing approaches for software analysis Model-based analysis is a key technique to determine if the system would satisfy its functional- or nonfunctional-requirements. In this method, an embedded system is described by developers as higher levels of abstraction that includes both hardware and software components. By using it, developers can evaluate the model with regard to its structure, software allocation to hardware, partitioning the communication tasks, scheduling tasks, and communication synthesis with shared variable resources [7] [8] [9] [10]. However, these analysis techniques do not support software architectures that contain precedent dependent aperiodic tasks. In embedded systems, as mentioned in 1.1.1, pipeline architecture is often used to accomplish the performance requirements and often implemented by precedent dependent aperiodic tasks. This also makes it hard to analyze the other major requirements, which are scalability and portability. In the 6 remainder of this section, I will focus more on performance-related analysis, which is a major area of model-based analysis. This is because embedded systems have severe timing and performance constraints due to limited resources for size and cost, and therefore it is needed to be analyzed by using modeling techniques. [11] [12] propose UML-based performance modeling frameworks and Those are useful in terms of compatibility with existing UML models. However, they do not provide accurate analyses because of the complicated performance related constraints, such as precedent dependent aperiodic tasks. A lot of techniques related to performance analysis model a system into tasks with their execution times, periods, and deadlines. These techniques can identify the worst-case execution sequences composed of several processing steps [13]. However, these methods assume the tasks of the system are all independent. [14] provides a framework for performance modeling and analysis. Although developing original performance modeling framework like this is so attentive that it might produce accurate analyses to developers, the models are hard to reuse for the analyses of other requirements, such as scalability and portability. In summary, model-based approaches can be useful for embedded software architecture analyses. However, UML-based models are not able to describe complicated performance requirements, while original models are hard to reuse for other purposes. Through the study of the existing approaches, I found that AADL, Architecture Analysis and Design Language [9], can be used for embedded system analyses, and that the AADL models can be reused for multiple purposes. In addition, there are state-of-the-art analysis tools using AADL such as Cheddar (performance) and OSATE (scalability, portability, and any other requirements). I will discuss AADL in more detail in 4.1. For the above reasons, I have decided to use AADL and will discuss whether AADL is practical and useful throughout this thesis. However, AADL and its related tools still have 7 problems with precedent dependent aperiodic tasks. In the remainder of this section, I will introduce the technical issues of the existing AADL analysis tools. 1.2.1 Problems with precedent dependent aperiodic tasks Problem 1: Figure 2 Many sets of precedent dependent tasks (a) and the result of Cheddar (b) For the performance analysis, Cheddar [15] outputs a result of the schedulability analysis that shows each task’s behavior while considering the precedent dependence of tasks. Figure 2 (a) shows three precedent dependent tasks where each task has its own plugins and each plugin runs on the thread of the task. For example, plugin “1_A” and “1_B” share thread “Task1” thus they 8 cannot be executed at the same time. And a set of plugins “1_A”, “2_A”, and “3_A” have precedent dependence as “Set A”, so does “1_B”, “2_B”, and “3_B” as “Set B”. Cheddar outputs all the possible combinations of the tasks, and therefore it might be too hard for developers to interpret the result, especially when there are many tasks (Figure 2 (b)). Problem 2: Figure 3 OSATE analyses for periodic tasks (a) and aperiodic tasks (b) OSATE [10] cannot analyze aperiodic tasks because aperiodic tasks do not have necessary information for the analysis. Figure 3 (a) shows three periodic tasks all of that have 100 milliseconds period. When the tool analyzes the bus load, for example, it sums up each task’s data transfer rate: 10 (Hz) * 10 (Kbyte) = 100 Kbps (Kbytes per second) between Task1 and Task2; 10 (Hz) * 10 (Kbyte) = 100 Kbps between Task2 and Task3; and the total is 100 + 100 = 200 Kbps. Thus, calculating the resource parameters of periodic tasks are not hard because all the information the tool needs is described in a thread. On the other hand, if Task1 and Task3 are 9 aperiodic as Figure 3 (b), the tool cannot take the periods directly from Taks1 and Task3: as a result, OSATE outputs invalid result. 1.3 Thesis statement, hypotheses, and assumptions The objective of this research is to create an integrated technique that can analyze embedded software architectures with precedent dependent aperiodic tasks in a manner that is compatible with existing architectural models. The shortcoming of existing approaches motivates the following hypothesis, which this thesis will test. Hypothesis 1: Insight 1: For the performance analysis, analyzing all the combinations of the sets of precedent dependent tasks is hard for developers to interpret and find which combination could cause the delay of total execution time. Hypothesis 1: By analyzing precedent dependent task sets in a pairwise fashion, it is possible to isolate combinations of task sets that will create the worst-case execution time Hypothesis 2: Insight 2: For the scalability and portability analyses, the existing tool cannot analyze aperiodic tasks because they do not have the timing properties that are needed for the analyses. Hypothesis 2: It is able to analyze an aperiodic task by searching other tasks that are precedent dependent on the aperiodic task and by getting necessary properties for the analysis from the dependent tasks. 10 Also, I have made the following assumption in terms of the evaluation of my proposal. Assumption: We will be able to analyze many embedded systems with precedent dependent aperiodic tasks if we can analyze pipeline architecture regarding performance, scalability, and portability. This is due to the fact that both pipeline architecture and these non-functional requirements are widely used in most embedded systems. 1.4 Approach to fix the issues and its contribution This thesis proposes new implementations that are made based on the hypotheses stated in 1.3. In this section, I will propose each approach for the two hypotheses. I will also discuss the evaluation approach of this thesis. 11 Approach 1: Figure 4 Job Matrix Converter To tackle the issue of performance analysis, I have developed a new method to isolate combination of precedent dependent tasks so that developers can easily see which combination causes the worst-case execution time. The Job Matrix Converter, which I propose, first parses an original AADL file that contains precedent dependent tasks (see Figure 4). Then this tool creates a new AADL file that contains combination of sets of precedent dependent tasks in a pairwise fashion: that is, if there are three sets of precedent dependent tasks (Set A, B, and C), this tool newly describes three combinations of the pairwise sets (A + B, B + C, and C + A). Each combination should be executed independently with each other so that developers can see how a particular combination works: therefore, the Job Matrix Converter also modifies the tasks themselves. For example, Task 1 is in Set A and Set A is in two combinations (A+B and C+A), thus Task 1 will become 12 two different tasks (Task 1 for (A+B) and Task 1 for (C+A)) that will be executed independently. This new AADL file is analyzed by Cheddar and users can obtain the total execution time of each combination. Approach 2: Figure 5 How to challenge the analysis of aperiodic tasks To address the limitation of the existing OSATE analysis tool, I have directly improved the tool to analyze aperiodic tasks with searching other tasks that are precedent dependent on the aperiodic task and obtaining necessary properties for the analysis from the dependent tasks (see Figure 5). 13 Evaluation approach I also evaluate these new implementations using an embedded software architecture that is made for a multimedia server. First I evaluated whether approach 1 can detect the worst total response time between sets of precedent dependent tasks in the evaluation platform. The evaluation shows that the new performance analysis method is able to isolate a particular combination of task sets that creates the worst case execution time. Second, I evaluated approach 2 that can analyze aperiodic tasks in terms of scalability and portability analyses. The evaluation shows that the new approach can determine whether the number of instances of a component surpasses the limitation of the system, which currently is not being analyzed in this way with the existing tools. This is important when you make the software architecture scalable because the number of instances directly corresponds to how scalable the system is. The evaluation also shows the new approach can find whether the architecture has a capacity to allocate aperiodic tasks to CPUs. This analysis is also important to recognize the limitations of the portability of the system when you make components in the system portable. Contributions The contributions of this thesis are shown as follows:  The implementation of new performance analysis method that creates precedent dependent task sets in a pairwise fashion and enables developers to analyze a particular combination of task sets that will create the worst-case execution time  The implementation of new scalability and portability analysis methods that can analyze aperiodic tasks by searching tasks that are precedent dependent on the 14 aperiodic task and by getting necessary properties for the analysis from the dependent tasks  The evaluation that the new analysis methods are applicable to embedded software architectures. 1.5 Structure of this thesis The rest of this thesis is organized as follows: In Chapter 2, I will discuss related works including research into software architectures and software analysis methods. Chapter 3 describes an embedded software architecture that is used for an evaluation of my proposal. In Chapter 4, I will first enlarges AADL along with the analysis tools, which is discussed throughout this thesis, and also discuss the technical issues of the AADL analysis. Then I will propose new methods to fix the issues. Chapter 5 demonstrates the evaluation of analyses by using my proposal. Finally, I will conclude with Chapter 6 on contributions and future work. 15 Chapter 2 Background and Related Work In this chapter, I will describe works related to this thesis in two major areas of study: (1) software architecture and its related works including software architecture analysis and ADL, which will be mainly discussed through this thesis; (2) existing approaches for modeling-based analysis methods. 2.1 Software Architecture Software has become more important in all systems in recent years. Software plays a major role not only in complicated air traffic control but in embedded-systems such as mobile phones. It is difficult to find an organization that is not involved in software. Software that is used by all such organizations needs to realize sufficient capabilities, preserve the satisfactory qualities, be able to serve at appropriate timing, and be provided in reasonable price. Software architectures have a potent influence on all these characteristics. In other words, developing an appropriate software architecture is critical to succeed for all organizations. Designing software architecture is of benefit not only to decide principal designs for a system but also to verify or evaluate the system prior to the implementation of the system. Now the objects for developers to verify or evaluate an architecture are roughly classified into two concepts: whether the architecture (1) satisfies a client’s requirement; or (2) is realizable in terms of the implementation. This thesis discusses the verification of software architectures mainly regarding to concept (1). 16 2.1.1 Software architecture verification Software developers, especially software architects, verify a software architecture in roughly three ways [16]: (1) inspection- and review-based; (2) model-based; or (3) simulation-based. Above all, (1) inspection- and review-based approach is widely used in a software development industry. In (1) approach, a software architecture is studied by human architects, sometimes by all stakeholders. In other words, this approach is basically a manual approach although there have been several researches to make this more efficient and systematized, such as ATAM [17] and SAAM [18]. Doing all this verification manually causes the following three problems: A) Can be expensive: human-cost is the biggest part of software development cost especially at the beginning of the project. Moreover, if inspections/reviews are held by all the stakeholders including the non-technical staff, it takes more time and cost to make all of them understand the concept of the software architecture; B) Need experts: inspection/review needs a lot of domain knowledge and experiments of the participants. It is hard for beginners to make an appropriate, or at least reasonable, decision; they might not even know what concept of a system they should analyze; C) Even experts make mistakes: there is always a possibility that humans make a mistake no matter how much knowledge or experiences they have. They might, for instance, overlook an issue that they should have considered, over- or underestimate, or give up performing a complicated analysis; In this situation, (2) model-based; or (3) simulation-based approach has been proposed to tackle these problems. 17 2.1.2 Architecture Description Languages ADLs, Architecture Description Languages, is one of the techniques that can describe and analyze software architecture using (2) model-based; or (3) simulation-based approaches. ADLs describe high-level structure of the system rather than detailed implementation. A lot of ADLs have been proposed both for a particular domain and general purposes [8]. The objective of ADLs for embedded systems are roughly divided into three concepts [19]: generation of a software toolkit, such as compiler, simulator, and debugger; generation of a synthesizable Hardware Description Language (HDL); and validation of the embedded system architecture. In this section, I would like to focus on ADLs for validation of the architecture and to introduce this research. [20] proposes an automatic validation framework using ADL for pipelined processors. In this framework, a graph model of the architecture is automatically generated from ADL and the graph model is used to perform equivalence checking with the Register Transfer (RT) design of the system, or to generate a compiler and a simulator for the RT design. That graph model captures both the structure and behavior of the processor so that designers can achieve well- formed architecture and assure the quality at an early stage. EAST-ADL [21] or EAST-ADL2 [22] is proposed for automotive industry to support timing and resource consumption analysis as well as variability modeling, product line management, and requirements engineering. This method provides multi-abstraction-level models so that developers can consistently model and analyze the whole system from an abstract level to an implementation level: where the abstract level includes requirements, features, and principle interfaces, and the implementation level includes configuration of software according to the hardware and assessment of feasibility of the system realization. The timing and resource 18 consumption analysis methods of EAST-ADL and EAST-ADL2 are realized by modeling the timing aspects in automotive embedded systems and of Priced Timed Automata (PTA) respectively. HiLeS-T [23] provides a method to express the behavior of the system and to perform system verification. This method is based on Petri Nets, a formal behavioral model that performs formal verification and model checking. With timing related requirements written in a certain notation, HiLeS-T with Timed Petri Nets is analyzed and allows developers to get the worst-case execution time of the system. AADL [9] is one of the most widely used ADLs, especially for embedded systems or real- time systems. I will discuss AADL in detail in 4.1. 2.2 Existing approaches for software analysis There has been much research done proposing analytical methods for software systems other than ADLs. In this section, I will first introduce model-based analysis methods and then focus more on performance-related analysis. Because embedded systems have severe timing and performance constraints under limited resources for size and cost, performance-related analysis is a major area of model-based analysis. Second, I will discuss some research that provides analysis methods for software pipeline, which this thesis tries to analyze. 2.2.1 Model-based software analysis approaches Model-based analyses, including ADLs, is a key technique used to determine if the system would satisfy its functional- and nonfunctional-requirements. Developers sometimes describe software architecture by using diagrams in their own individual way. While this may be easy to draw, it may also lead to obscurity and be hard to use or reuse effectively. Model-based analysis methods have 19 provided standard specifications in order to analyze and detect any potential issues within the software architecture. Generally, in model-based analysis, an embedded system is described by developers at higher levels of abstraction including both hardware and software components. By using it, developers can evaluate the model with regard to its structure, software allocation to hardware, partitioning of communication tasks, scheduling tasks, and communication synthesis with shared variable resources [7]. Because a major area of model-based analysis has to deal with the severe timing and performance constraints under limited resources in embedded systems, I will focus on performance-related analysis in the remainder of this section. UML-based performance modeling frameworks build upon the existing UML (Unified Model Language). In addition to UML notations, they also provide additional performance information such as other workloads, multiple users, or delays of connections to resources. [11] proposes UML-based performance evaluation using software performance engineering (SPE). A performance-related scenario is described as a use case scenario and a sequence diagram. This scenario is processed by a software engineering tool, and the tool provides the execution graph corresponding to the scenario. Once users specify the software resource requirements and computer resource requirements for each processing step, the analysis tool produces solutions of the execution path that achieve the performance objective. Software resource requirements describe the number of calls per unit time, instructions executed in the CPU, and disk accesses while computer resource requirements specify the quantity of devices, their service times, and the amount of processing required from each device. [12] proposes a performance-annotated UML description, where the performance parameters for components, connectors, and resources are described based on UML and XML. The performance parameters are classified into two categories: workload intensity parameters, and service demand parameters. Workload intensity parameters are measured by arrival rates of request or by the number of concurrent entities, 20 while service demand parameters are measured by the amount of resources used by each request. These parameters are described in XML and mapped to a performance model that is analyzed based on queuing network. Queuing network [24] is widely used for the analysis of system performance. In order to predict the length and waiting time of a queue in queueing network, each task is associated with a queue that has performance parameters such as the time between arrival to a queue, size of jobs, and the number of servers. Those UML-based performance modeling methods are useful in terms of compatibility with existing UML models. However, they do not provide accurate analyses because of the complicated performance related constraints, such as precedent dependent aperiodic tasks. On the other hand, many performance analysis methods use the queuing network theory, including Cheddar and OSATE analysis tools, which will be introduced in 4.1.2. A lot of techniques related to the performance analysis of the system model it by dividing the system into tasks with its execution times, periods, and deadlines. These techniques can identify the worst-case execution sequences composed of several processing steps. Because many techniques assume that the system runs with single priority scheduling and are not able to handle complex priority structure, [13] proposes a technique to model a complex task comprised of many sub-tasks. [13] also insists that this analytical method be used not only for periodic tasks but also for aperiodic tasks by providing high priority execution time to service aperiodic requests. Even though [13] tackles the complex structure of priority better than the rest of the techniques, it still also assumes that the tasks of the system are all independent. [14] provides a framework for performance modeling and analysis. Structural model, platform model, and runtime model are constructed with a set of performance parameters. While the structural model and platform model are used to model the transaction and computational devices respectively, the runtime model is created as a weighted directed acyclic graph that has 21 nodes to represent tasks and also weight functions to specify the resources demanded by the tasks. [14] analyzes this runtime model based on the timing and schedulability analysis theory for real-time system and outputs the schedulability of the task set on each device, the end-to-end response times of the task chains, and the resource consumption of devices. Although developing an original performance modeling framework like this is very useful because it produces accurate analyses to developers, the models are hard to reuse for the analyses of other requirements, such as scalability and portability as mentioned in the section 1.1. Most of the schedulability analysis methods are based on priority-based analysis. [25] proposes an exact analysis method of worst-case response times with a separate analysis of each individual task. This method first calculates the LCM (Least Common Multiple) of all task periods. In order to model precedence relations between tasks, [25] analyzes a certain task by considering the release jitter and offsets of higher priority tasks. Even though this method could be time consuming because of the LCM calculations of each task, it can, however produce a more precise worst-case response time for the task. These schedulability analysis methods generally assume all tasks can be executed at the same time by taking all combinations of tasks into account and considering the worst-case scenario. However, some developers want to analyze particular combinations of precedent dependent tasks. For example, a multi-function printer has to carry out a copy function and a print function at the same time but does not have to carry out both a copy and a scan function. In this case, the analysis of defined combinations of tasks are preferred rather than time consuming analysis for all possibilities of task schedulability. 2.2.2 Analysis approaches for pipelines [26] proposes an analytical method based on queueing theory to model the pipeline in order to assess the parallelism. This model aims to estimate the execution time for the whole pipeline by 22 calculating the throughput of each internal queue. To address this calculation, it models the two things: the buffer where there are pending items to be processed; and the threads that process the items. This model gives an accurate prediction of execution time according to the experiment. Furthermore, [26] also proposes methods to handle the load imbalance issues in the pipeline system by implementing dynamic scheduling with the Threading Building Blocks (TBB) library. However, this method does not handle a pipeline system where the execution time of each stage changes dynamically. Flextream [27] is a flexible compilation framework that aims to adapt a running streaming application dynamically if a change in the target architecture occurs. This method represents streaming applications as a graph with computational nodes and dataflow edges. These computational nodes are mapped to heterogeneous cores based on the underlying system architecture. This method dynamically adapts running applications to suitable cores when a change of resource availability in the system, such as number of cores, available memory, or bandwidth, occurs. Flextream, however, is applicable to streaming applications assuming the execution time of each stage is relatively balanced. Feedback-Directed Pipelining (FDP) [28] is a method that treats each thread as a stage in a pipeline and dispatches each thread to a processor core dynamically. The goal of this method is to maximize the performance of the workload while reducing the number of active cores to save power. The challenge of this method is how to treat the dynamic change of the input dataset or of the machine that typically influences the optimal allocation of threads to cores. To address this challenge, FDP samples latencies of each stage and feeds them back to obtain an optimal core-to- stage allocation. However, training optimized mapping from the input dataset means that this method does not fit a system where the input data changes every single time. 23 Chapter 3 Evaluation platform In this chapter, I will introduce an example of embedded software architecture that will be used as an evaluation platform for my proposed analysis method. I will first describe the Tizen architecture, which I utilized to make the evaluation platform. Then I will introduce the requirements and architectural decisions of the evaluation platform. 3.1 Tizen Multimedia Architecture Tizen [29] OS is an open-source operating system based on Linux. This OS supports web applications as well as installable ones, has advanced multimedia features, uses location-based services, and offers the ability to multi-task. The original scope of this OS is smartphones, tablets, smart TVs, and in-car information systems but is also applicable to cameras, printers, and any other embedded systems in the future. Although Tizen offers various features for developers to develop Tizen applications, for example Application Management, User Interface, Notifications, Content Sharing, Messaging, Text Input and Voice, and Security, I would like to focus on its Multimedia framework and introduce how it works. This is because many embedded systems are in the domain of networking services, voice- or image-processing, and multimedia tasks, and therefore many of them use a streaming-based structure like the Tizen Multimedia framework. In addition, this framework offers a plugin architecture in order to enable the system to be changeable. The changeability is one of the key non-functional requirements of embedded systems especially for their product lines. 24 Figure 6 Tizen Multimedia Framework Figure 6 shows the Tizen’s multimedia framework [30] [31]. The core components in the upper layer of the multimedia framework provide several features:  Player/Streaming FW: Local Playback, Various kinds of Streaming playback (HTTP, HLS, Smooth)  Camera/Recorder FW: Various Shot, Full HD Recording, Audio Recording  Audio FW: Audio Playback/Capture, Sound Path Control, Audio Session Manager  WiFi Miracast FW: Screen Mirroring  Media Content FW: Multimedia Content list and Metadata management  Media Editing FW: Content Trans-code, Content Metadata Extracting and Writing In the middle and lower layer, it provides important mechanisms that are used throughout multimedia processes. One of the key mechanisms is Gstreamer. Gstreamer is a pipeline-based and plugin architecture (see Figure 7). 25 Figure 7 Tizen Gstreamer The application developers create a pipeline that performs multimedia processing by implementing their own plugins or choosing a suitable plugin from the plugin pool, depending on what they want to implement. The application and the pipeline communicate with each other through a message bus using messages, events, and queries. Now I will introduce an example of how this framework works by using one of key components, Player / Streaming FW. 26 Figure 8 Tizen Player/Streaming Framework Figure 8 shows an example of Player/Streaming Framework where this application provides functions for a multimedia application to implement playback of media content. The developer first creates a player pipeline instance and then puts the suitable plugins into it. For example, as a source plugin, they can choose the input format, such as file, http, rtsp, or the application itself. Then they generate a whole pipeline for the parsing, buffering, decoding, filtering, and synchronizing of the data by choosing suitable plugins. This example consists of three concurrent pipelines for audio, video, and text. The biggest advantage of this framework is the ease of developing applications. All developers have to do is to choose the plugin and create the pipeline. Detailed implementations both for multimedia processing, such as parsing, decoding, and synchronizing of the data, and for the communication between an application and a pipeline, are hidden into the framework. As described above, the Tizen multimedia framework was designed for stream processing which is one of the key mechanisms for embedded systems. This architecture makes many typical design decisions that are well suited for embedded software such as pipeline, plugin, and message 27 bus. In the remainder of this chapter, I will make an evaluation platform utilizing the Tizen architecture in order to evaluate my new approach of embedded software architecture analysis. 3.2 Requirements Figure 9 Overview of evaluation platform The evaluation platform is made for a multimedia server, the overview of which is shown in Figure 9. This system receives inputs of multimedia from several devices, such as internet, hard disk drives (HDDs), and DVDs, then processes the inputs with pipeline architecture, which will be described later, and finally outputs media streams to several devices, such as TVs, computers, phones, and tablets. I defined major requirements of the evaluation platform in Table 1, and these are also typical requirements of embedded systems. Here I focused on non-functional requirements that can affect the software architecture of the system rather than defined all detailed functions of the system. Those are roughly classified into three categories: performance, scalability, and portability requirements. 28  Performance: Req1, Req4, and Req6  Scalability: Req2, Req3, Req5, Req6, and Req7  Portability: Req6, Req7, and Req8 I would like to note that a requirement could be in several categories: for example, Req6 is in all three categories. As well as Req6 is clearly a performance-related requirement, it implies that the system has to have the capability of changing its performance (scalability), and of being executed on various hardware (portability). Table 1 Requirements of evaluation platform ID Requirements Req1 Input streams might come simultaneously. The system has to process all inputs in parallel in order to avoid that the response time of the processes might affect each other and result in a delay (i.e. multi-users can use this system at the same time) Req2 The system has to accept these file formats as input streams: AVI, WMV, ASF, FLV, MP4, MOV, MKV, VOB. In addition, new file formats might be added in the future. Req3 The system has to output streams to several devices via: DVI, DisplayPort, HDMI, Ethernet (Wired); Intel WiDi, Miracast, AirPlay, WiFi (Wireless). In addition, new file transfer standards might be added in the future Req4 The system has to be implemented using streaming processing. (i.e. it has to process part of the input data before the whole data is stored, and process it continuously as data is flowing through the system) 29 Req5 The maximum number of input streams that can be processed at the same time, varies according to the line of the product. (i.e. High-end products can handle more input streams) Req6 To obtain a high throughput, the system can have image processing hardware in addition to general processors. Req7 The system should currently be on a single server but it could be implemented across several servers in the future. Req8 The platform (CPU, OS, Middleware) of the system can be changed according to the line of the product. 3.3 Architectural decisions I made three architectural decisions in Table 2 and described how each decision relates to the requirements mentioned in Table 1. In this section, I will describe these architectural decisions in detail and why these decisions are suited for the requirements. Table 2 Architectural decisions of evaluation platform ID Architectural Decisions Related Requirements AD1 Pipeline Plugin Architecture Req1, Req2, Req3, and Req4 AD2 Multiple Components Req2, Req3, Req5, Req6, and Req7 AD3 Message Bus Req6, Req7, and Req8 30 AD1: Pipeline Plugin Architecture The first architectural decision of the evaluation platform is pipeline and plugin. Figure 10 Pipeline in evaluation platform This architecture is made utilizing Tizen Gstreamer mentioned in 3.1 and consists of these components:  Filters o Input: This component works as a data source. It can receive several types of data formats. o Output: This component works as a data sink. It outputs media stream to several devices. o Demux, Queue, Decoder, and Filter: These components receive data, then process the data, and send the result to the next filter. 31 o Each filter has its own thread. o Developers can implement several types of plugins and fit them into a filter. Take an Input component for example: you can develop a plugin that can handle a particular input stream format, such as file and http, and plug it in as an Input component. This makes it easy to add a new function for each process (Req2 and Req3). o All plugins in a filter share a thread due to limited resources that I described before. Take the Input component for example: you can add several plugins into the Input component, such as file and http, but only a plugin can be executed at the same time because they have only a thread. Ideally, all plugins are preferred to be executed on each thread. However, it consumes both the CPU power and memory: therefore, I fixed the number of threads statically in this architecture.  Message bus o This component works as pipes between filters. o Each filter uses this message bus component to send/receive data to the next filter/from the previous filter. o Message bus has buffers for all communications between filters. It helps each filter (thread) work concurrently without worrying about synchronization. o This also has a responsibility for portability, which will be mentioned later. 32 Figure 11 Simultaneous inputs to pipeline Here I will explain how this pipeline architecture works to obtain concurrency and, as a result, to achieve high performance. Figure 11 shows three jobs, job1, job2, and job3, occur from different devices at the same time: from DVD, HDD, and Internet respectively. Those input streams first come into filter Input and are processed by each plugin that is suitable to process each job. Filter Input divides the stream as appropriate size, which is enough to process by the latter filters, and send it to filter Demux. This procedure in filter Input will continue until the input stream is over or a user cancels the job. The remainder of the processes is straight forward: Demux, Queue, Decoder, and Filter receive a piece of data, process it, and send the result to next filter. Finally, filter Output sends each device the result stream that is created appropriately matched for each device. Figure 12 How the pipeline works for simultaneous inputs Figure 12 shows how the simultaneous inputs are processed by each filter along the time axis. First, plugin file in filter Input processes part of the data of job1 (from DVD). The result of the process is sent to filter Demux and processed by plugin mp4. Plugin H264 in filter Decoder then 33 processes data sent from previous filters. The series of processes through Input, Demux, Decoder, and the latter filters, continues for job2 (from HDD), for job3 (from the Internet), and then for the remainder of job1 again. Each job is processed partially and then the architecture performs parallel processing: in other words, all of the users for job1, job2, and job3 can see the media streams simultaneously (Req1 and Req4). AD2: Multiple Components The second architectural decision of the evaluation platform is multiple components. In order to solve the bottleneck of the system throughput, software developers often instantiate multiple instances of the bottleneck component. Figure 13 Multiple Components Take the evaluation platform for example: filter Decoder can be a bottleneck because decode processes generally take a lot of time: therefore, I have decided for Queue and Decoder filters to be multiple components (see Figure 13). The reason filter Queue should be a multiple component 34 as well as filter Decoder is that a Queue filter is supposed to be simultaneously used with a Decoder filter: in other words, the number of Queue instances is supposed to be the same as that of Decoder instances. Developers instantiate multiple components so that they can make them execute in parallel. In more detail, if the system has multiple execution environments, such as a multicore CPU, multi CPUs, CPU and GPU, or distributed servers, these multiple instances are allocated to these parallel execution platforms and executed in parallel. As a result, the bottleneck will be relieved and the throughput of the system will improve (Req5, Req6 and Req7). AD3: Message Bus The third architectural decision of the evaluation platform is a message bus. As shown in Figure 10, the evaluation platform has a message bus to provide communication methods between components. Message bus provides APIs in order to send/receive messages so that each component does not have to worry either about the location of the other is and how to communicate with each other. In more detail, different OSs/platforms generally provide different communication methods between threads/processes, such as message queue, message flag, semaphore, pipe, socket, and shared memory. A message bus obscures the implementation of the communication method to the components: as a result, the components can be independent from the platform they are executed on. 35 Figure 14 Alternatives for CPU allocating Figure 14 shows an example of two alternatives in the evaluation platform regarding how to allocate filters (threads) between two CPUs. Alternative 1 suggests that CPU2 be occupied by filter Decoder which is likely to carry out many computations, the purpose of which is to have filter Decoder use the full power of the CPU. Alternative 2 suggests that the two CPUs be allocated by the first-part and the latter part, aiming to decrease communications between two CPUs. The decision of choosing one of these alternatives could be different depending on many considerations, such as the memory capacity of each CPU, performance, or even how to organize teams that develop each component. In order to achieve portability, developers use a message bus and make these filters portable between two CPUs. Figure 14 shows only an example of the allocation of different CPUs but, in real software developments, many other platforms could be different such as the OS, middleware, and distributed servers. Message bus also supports these kinds of differences (Req6, Req7, and Req8). 36 Chapter 4 Approach In this chapter, I will first describe AADL and state-of-the-art analysis tools using AADL that will be discussed throughout this thesis. Then I will discuss how the tools are used for the performance, scalability, and portability analyses, and then the technical issues that the tools encounter in order to obtain the goal I defined in 1.3. Lastly, I will present my technical solutions to solve the issues. 4.1 AADL and analysis tools AADL [9] is one of the most widely used ADLs, especially for embedded systems or real-time systems. The analyses of embedded or real-time systems will become more important because the ratio occupied by software in embedded systems will probably expand, considering the current trends of IoT [32] [33] or CPS [34] [35]. In this section, I will discuss AADL in detail and also the state-of-the-art analysis tools using AADL. 4.1.1 AADL AADL, Architecture Analysis and Design Language [9], standardized by the Society of Automotive Engineers (SAE), has provided standard specifications for Architectural Description Languages used in embedded or real-time systems. AADL enables embedded system developers to detect any potential issues of the software architecture. In addition to architecture analysis, AADL can also be used for principle design documentation, skeleton code generation, and automated integration. 37 AADL basic features AADL provides modeling concepts of components and of their interactions. Components include not only software but hardware and their composite (system) as follows:  Software o Thread: a unit of procedures that can be executed concurrently o Process: has its own address space and can contain threads o Data: data structure  Hardware (Execution Platform) o Processor: schedules and executes threads o Memory: stores data and code o Device: external environment such as sensors o Bus: provides interconnections between other hardware  Composite o System: the integration of other components including system itself (it can be nested) Each component declared by AADL specification has interfaces such as connection ports, data accesses, and bus accesses. Detailed characteristics of each component are also described by properties such as type of data, bandwidth of connections, and execution time or deadline of a thread. AADL specification also provides runtime semantics for data or event exchange:  Message/event passing  Thread scheduling protocols  Timing requirements  Remote procedure calls 38 4.1.2 Analysis tools using AADL AADL supports analyses of critical system qualities such as performance, schedulability, and reliability. Take schedulability for example: AADL threads have an estimated execution time and execution properties such as periodic, aperiodic, background (dispatched once and executed to completion), and sporadic (paced by an upper rate bound). These thread properties are analyzed according to which process or processor these belong to. This AADL analysis concept will be discussed throughout this thesis to determine whether AADL is practical and/or useful. In the remainder of this section, I will introduce some state-of-the-art analysis tools using AADL. OSATE OSATE [10], Open Source AADL Tool Environment, has provided toolsets for processing AADL models. It provides users a textual editor and a set of analysis tools on the Eclipse platform. While developers can develop OSATE analysis tools by themselves using Eclipse plugin platform, some standard analysis tools are provided in OSATE as follows:  Architecture consistency: such as ports connection, data interchange, and safety/security in port connection flow;  Confidentiality;  Architecture dependency: such as Dependency Structure Matrix (DSM);  Fault analysis: such as fault impact and unhandled faults;  Resource analysis: such as electrical power, weight, RAM/ROM memory, processor MIPS, and network bandwidth;  Resource allocation and scheduling analysis: such as priority inversion, balanced processor load, minimized network traffic 39  Flow latency analysis: such as worst-case flow, port queue latency, and bus latency Figure 15 OSATE overview Cheddar Cheddar [15] has been proposed as a real-time schedulability analysis tool which can also handle AADL with processors, tasks, and messages. It then outputs a result of the simulation that shows how each task can be scheduled and whether it satisfies the deadline of the task. The schedulability analysis of Cheddar is based on the real-time scheduling theory and supports several types of scheduling policies such as pre- or non-preemptive, rate monotonic, least laxity first, POSIX queueing, and other time sharing policies. This tool provides not only scheduling simulations but also worst/best task response time, number of preemption, deadlock, and priority 40 inversion, thereby supporting embedded system developers widely. I will introduce the real output of Cheddar in 4.2.1. Ocarina Ocarina [36] is a command-line tool that generates C code from AADL models. Generating code makes it possible not only to save time in the implementation of the architecture, but also to obtain direct results of the performance analysis in the simulation on a particular environment. This is highly useful because the environments of embedded systems are so diverse that developers sometimes cannot simulate the architecture without the real code. However, this thesis only focuses on model-based analyses without the real environment so that developers can analyze the architecture prior to development of the hardware / platform. 4.2 Analysis approaches This section explains what developers want to analyze by using the above analysis methods. I will also discuss the technical issues with them that this research will deal with. I will go over the requirements of a system which are performance, scalability, and portability and which of these the analyses methods fail to address. 4.2.1 Performance analysis I will first explain what kind of performance should be analyzed in embedded systems. As I discussed before (in 1.1.1), a plugin pipeline architecture is suited for streaming processing. Developers can add any plugins that they want to implement as a new feature and obtain whole 41 streaming processes by combining those plugins as a pipeline. However, the combination could be too complex to analyze manually. Figure 16 What if you have too many plugins to analyze? Take the Demux, Queue, and Decoder filters in the evaluation platform for example: Figure 16 shows each filter has many plugins that interrelate with the others. Because each plugin has several estimated execution times, developers want to analyze the total execution time for each pipeline with all the possible combinations. the plugins in a filter cannot run concurrently because of the resource limitation since each filter has multiple plugins and only one thread. This fact makes it hard to analyze the worst-case execution time of each pipeline when all the combinations can occur at the same time as described in 1.2.1. Although the evaluation platform has a fixed number of filters in it, other plugin pipeline architectures might have the capability of being able to add as many filters as developers want in order to compose a pipeline as shown in Figure 17. This capability adds to the complicated interrelation of tasks which is why Developers need to do model-based performance analyses. 42 Figure 17 What if you have too many filters to analyze? AADL analysis approach for the performance Figure 18 End-to-End Flow Declaration OSATE has provided an analysis framework for flow latency [37] that calculates end-to-end latency by using the flow specification notation of AADL. Figure 18 shows an example of an end-to-end flow system: where the Sensor as a flow source runs prior to Controller 1 or Controller 2 as intermediate flows; and Controller 1 or Controller 2 runs prior to Actuator as a flow sink. 43 By describing an end-to-end flow like Figure 18 using AADL and using the flow latency analysis tool of OSATE, you can get a report that suggests whether the end-to-end flow satisfies the requirement of total execution time. List 1 AADL for precedent dependent aperiodic tasks Figure 19 The output of Cheddar (timeline) 44 Figure 20 The output of Cheddar (XML) Cheddar [15] also provides a schedulability analysis of several tasks that are written by AADL. Take precedent dependent aperiodic tasks shown in Figure 1 for example: the input of AADL should be just like List 1 where precedent dependent aperiodic tasks are described as “Cheddar_Properties::Task_Precedencies”. Cheddar outputs the result of schedulability of this AADL input both by a time line chart (see Figure 19) and by an event table XML (see Figure 20). Cheddar outputs the execution time for all the possible combinations oftasks so that developers can see the worst-case execution time of each task. 45 Technical issue of the performance analysis Figure 21 AADL Example of precedent dependent aperiodic tasks AADL has the capability to describe precedent dependent aperiodic tasks as stated in Figure 18. However, OSATE standard analysis tools are not able to analyze them because of the difficulty to analyze aperiodic tasks. Take Figure 21 for example: task1, task2, and task3 are precedent dependent, and task1 and task3 are aperiodic tasks. To analyze the execution time of the end-to- end flow, the tool must find the start time or the period of the aperiodic task, task1 and task3. Because aperiodic tasks do not have such timing properties, OSATE analysis tools cannot calculate the end-to-end flow execution time so they output an invalid result. 46 Figure 22 A task set affecting the other’s total execution time Even though Cheddar analyzes precedent dependent tasks and outputs the execution time of each task, it is still hard for developers to know how much a set of precedent dependent tasks affects the execution time of the others. Figure 22 shows three precedent dependent tasks where each task has its own plugins and each plugin runs on the thread of the task. For example, plugin “1_A” and “1_B” share the thread of “Task1” thus they cannot be executed at the same time. We also seea set of plugins “1_A”, “2_A”, and “3_A” that are part of “Set A” and precedent dependent, just like “Set B” which includes plugins “1_B”, “2_B”, and “3_B”. When “Set A” is executed alone, the total execution time is 20 + 10 + 30 = 60 milliseconds assuming there is no delay or jitter in the communication between tasks. However, if the “Set A” is executed with “Set B” and “Set B” is processed prior to “Set A”, each plugin in “Set A” waits to start until each plugin in “Set B” is finished (see Figure 22). As a result, the total execution time of “Set A” is 10 (wait) + 20 + 10 (wait) + 10 + 10 (wait) + 30 = 90 milliseconds. In this way, sets of precedent dependent tasks may affect 47 each other’s response time. Even though cheddar outputs the execution time for all the possible combinations of the sets, the result of all the combinations of tasks might be too hard for developers to interpret, especially when there are many sets of precedent dependent tasks. 4.2.2 Scalability analysis Figure 23 Using a hard disk drive in the evaluation platform As described in 3.3, multiple components are a technique to make a system scalable. The greater number of instances there are of multiple components, the more bandwidth will be necessary to transfer the input/output data to/from the instances. Figure 23 demonstrates an example of filters Queue and Decoder, which are multiple components in the evaluation platform, using HDD (Hard Disk Drive) as a data storage. In this example, once Queue receives data, it writes data into HDD in the manner of a queue structure (i.e. First-In-First-Out structure). Decoder reads the data from HDD, processes it, and writes the result back to HDD. Because HDD has a limited data 48 transfer rate, these multiple components also have a limitation on the number of instances that can be executed at the same time. Developers have to balance the HDD data transfer rate and the concurrency of multiple components. Figure 24 HDD alternatives for multiple components Figure 24 shows a more complicated analysis example. Alternative 1 uses one hard disk drive as HDD1, which is used to store the result both by the queue and decoder filters. Although it makes the system architecture simpler, HDD1 will have higher speed and therefore be more expensive. Also, it might have a lower scalability due to the capacity of HDD1’s data transfer rate. Alternative 2 uses two types of HDDs. HDD2 is used to store the result from the queue instances while HDD3 is used to store the result from the decoder instances. This could be more scalable because you add hard disk drives every time you want to scale up. On the other hand, the system architecture could be complex and likely to need more physical space to install many hard disk drives. Developers in embedded systems often perform an analysis to figure out how scalable and what cost each alternative would have. 49 AADL analysis approach for the scalability OSATE has provided an analysis framework for bus load that takes the bandwidth required by each connection between components into account. Figure 25 Example of scalability analysis Figure 25 is an example of software architecture where three components use a hard disk drive (HDD) and each component reads/writes data at several speeds. OSATE parses this architecture written by AADL and outputs a result that shows whether the total speed requirement of three components is within the HDD’s read/write speed. Although this is just a simple example, real systems have far more complexity. For example, there might be three HDD candidates and over ten components that have several read/write speeds, making it hard for developers to analyze the system without tools. OSATE supports this analysis even for software architecture with multiplicity: for example, it can help understand the number of instances that can be covered with this architecture. 50 Technical issue of the scalability analysis Because of the difficulty with the analysis of aperiodic tasks, the OSATE bus load analysis tool fails at analyzing them just like the end-to-end flow analysis does. I will describe the difficulty now. Figure 26 Precedent dependent periodic tasks analysis 51 If tasks are all periodic, the analyzer only has to focus on each task. Take Figure 26 for example: Task1, Task2, and Task3 are all periodic tasks with a period of 100 milliseconds and have different execution times: 30, 10, and 20 milliseconds respectively. When the tool analyzes the bus load, it sums up each task’s data transfer rate: 10 (Hz) * 10 (Kbyte) = 100 Kbps between Task1 and Task2; 10 (Hz) * 10 (Kbyte) = 100 Kbps between Task2 and Task3; and the total data transfer rate is 100 + 100 = 200 Kbps. When the tool analyzes the CPU budget, it calculates the total execution time per second for each task: 10 (Hz) * 30 (milliseconds) = 300 milliseconds for Task1 and CPU1; 10 (Hz) * 10 (milliseconds) = 100 milliseconds for Task2 and CPU2; and 10 (Hz) * 40 (milliseconds) = 400 milliseconds for Task3 and CPU3. Thus, calculating the resource parameters of periodic tasks are not hard because all of the information the tool needs is described in a thread. On the other hand, if Task1 and Task3 are aperiodic as in Figure 22, the tool cannot take the periods directly from Taks1 and Task3: therefore, it needs to search for a periodic task through the precedent dependence of the aperiodic tasks. This is the first part of the difficulty in analyzing precedent dependent aperiodic tasks. Figure 27 Precedent dependent aperiodic tasks analysis 52 The second difficulty is the nested structure of AADL. As shown in Figure 21, all the threads are not connected directly with each other threads but nested in the parent processes and systems. Because systems are structured in nested hierarchies of components, analysis tools may have to parse several layers to find the connection that the aperiodic task has. In embedded systems, each thread can be placed in different processes, CPUs, and systems, thus parsing is often required because of the intricate relationship between aperiodic tasks. 4.2.3 Portability analysis Even though you have developed portable software, you also have to care about where to locate it considering the resource budget of the system. Take alternative 2 in Figure 14 as an example: whether you can place all of the latter filters into CPU2 depends on how much instruction power CPU2 has and how many instructions are needed by the filters. Developers must take these resource allocation constraints into account. AADL analysis approach for the portability OSATE has provided an analysis framework for resource allocation [38] that helps to make allocation decisions of components to typical hardware resources, such as processors or memory. 53 Figure 28 Alternatives for portability In Figure 28, there are two alternative architectures: in alternative 1, Compo. 1 is executed on CPU1 while Compo. 2 and Compo. 3 are executed on CPU2; in alternative 2, Compo. 1 and Compo. 2 are executed on CPU1 while Compo. 3 is executed on CPU2. To determine which allocation is better, developers usually consider how often or how much communication happens between components, how the components use CPU power, or how much memory size they need. OSATE resource allocation analysis tool outputs a result to show whether the allocation is within the resource boundary of the system: considering component’s MIPS consumption, execution time, memory consumption; processor’s MIPS budget; and memory’s budget. Technical issue of the portability analysis The OSATE resource allocation analysis tool can be used for the portability analysis. This tool analyzes whether all the computations in tasks surpasses the capacity of CPUs. However, this tool is also not capable of analyzing precedent dependent aperiodic tasks just like the bus load analysis tool. 54 4.3 Technical approach This thesis proposes new implementations that fix the technical issues stated in the previous section. In this section, I will propose each approach for the performance, scalability, and portability analyses. 4.3.1 Performance analysis I have tackled the issue of the performance analysis in the following steps: 1. Convert original AADL to a new AADL that contains the combinations of sets of precedent dependent tasks in a pairwise fashion 2. By using the output of the analysis of the new AADL with Cheddar, develop a new analyzer to output a matrixed view result. Figure 29 Job Matrix Converter 55 Now I will explain these steps. Figure 29 shows how Job Matrix Converter, which I propose, works. In the original AADL, the process Read has two threads, RdFax and RdScan, where you can consider a process as a task and a thread as a plugin. In order to use Cheddar, you also have to describe precedent dependent tasks by using Cheddar_Properties::Task_Precedencies. In this example, plugin RdFax is part of a set of precedent dependent tasks with main_prs.test, image_prs.ImgLayout, and write_prs.WrtFax, and this set processes Job0. Plugin RdScan is part of two sets of precedent dependent tasks: with main_prs.test, image_prs.ImgRip, and write_prs.WrtPrint for Job1; and with main_prs.test, image_prs.ImgLayout, and write_prs.WrtPrint for Job2. The Job Matrix Converter parses this AADL and creates a new AADL file that contains the job matrices: Job0 and Job1; Job1 and Job2; and Job2 and Job0. Each combination should be executed independently with each other so that developers can see how a particular combination works: therefore, the Job Matrix Converter also modifies the tasks themselves. For example, only one RdFax thread is in the original AADL while RdFax_A_0 and RdFax_B_0 exist in the new AADL. This is because the RdFax is in a set of precedent dependent tasks and the set is in two combinations (A +B and C+A), thus RdFax will become two different tasks that will be executed independently. 56 Figure 30 Toolchain of Execution Time Analyzer Next step is to develop a new analyzer that outputs a matrix viewed result. I call this new analyzer Execution Time Analyzer. Figure 30 shows an overview of the toolchain that contains Cheddar, the Job Matrix Converter, and the Execution Time Analyzer, which I also propose. The Execution Time Analyzer first finds out the precedent dependences between tasks from the architectural XML. It also examines how each task can be executed with other tasks under the constraints of precedent dependences. All of the possible combinations of tasks that could be executed at the same time are calculated by the algorithm in Cheddar. Using the information of task dependences and possible combinations of task executions both analyzed by Cheddar, the Execution Time Analyzer first outputs a time-lined view result of total response times of all jobs. 57 Figure 31 Execution Time Analyzer output (Time-lined view) Figure 31 shows the detail of the time-lined view result of the Execution Time Analyzer. First this tool outputs a series of precedent dependent tasks, then analyzes how much time each job has taken to be executed by all tasks in a set of precedent dependent tasks. Here, a job represents a series of processes done by a set of precedent dependent tasks. For example, if you have precedent dependent tasks as shown in Figure 1, this tool measures when Task1 starts and Task3 ends and outputs the duration between these times as a total execution time. This process continues as long as there are jobs simulated by Cheddar. That is, if Cheddar simulates ten jobs, the Execution Time Analyzer also outputs ten total execution times so that developers can see what circumstances cause the worst execution time. I will describe this in more detail. 58 Figure 32 Task delay because of other jobs Figure 32 shows an example of precedent dependent tasks: where each task has several plugins and only a thread. Job A is processed by plugins of mp4, queue, and h264 while Job B is processed by plugins of mkv, queue2, and mp3. Each plugin has a different estimated execution time. In this example, all four jobs are processed by these tasks in the order of Job A, Job B, Job B, and Job A. The 1st Job A is processed by each plugin without any delay. Then the following 1st Job B is processed by plugins of mkv and queue2 without a delay but plugin mp3 waits for 10 milliseconds because a thread of decoder has already been running for the previous Job A when plugin mp3 is ready for Job B. On the other hand, the 2 nd Job B runs without a delay because there is no conflict between the tasks during the 2 nd Job B is executing. In the 2 nd Job A, both queue and h264 plugins wait until other previous jobs are finished. In this way, the execution times of the jobs are different depending on the other job’s situation. The two sets of Job A are executed in 130 and 180 milliseconds respectively, while the two sets of Job B are executed in 170 and 160 milliseconds respectively. The Execution Time Analyzer helps developers analyze these scenarios and find the worst-case execution time. 59 Figure 33 Execution Time Analyzer output (Matrix view) Finally, the Execution Time Analyzer outputs a matrix view result that shows the best and worst total execution times between sets of precedent dependent tasks in a pairwise fashion. In the matrix, the best and worst execution times are described as (best)|(worst) in each cell (see Figure 33). Developers can find which pair of set may cause the worst-case execution time easily from this result. 4.3.2 Scalability Analysis Figure 34 OSATE plugin architecture 60 To perform scalability analysis, I chose an approach to directly improve the OSATE bus load analysis tool. OSATE is an open source platform based on Eclipse platform and all the OSATE features are implemented as Eclipse plugins where everyone can edit the source code (see Figure 34). Figure 35 Algorithm of Bus Load analysis tool The original OSATE bus load analysis tool is lacking in its abilities to analyze aperiodic tasks. Therefore, I modified the plugin to make it possible to handle them. Figure 35 shows the algorithm of the bus load analysis tool that contains both original steps and new steps of my approach. I will explain these steps using an example of AADL shown in Figure 36. This tool first searches for a physical bus in the system and continues the process for all the buses. Then, for all the buses, this tool searches for a connection in the physical bus. Take Figure 36 for example: there are a physical bus “eth ” and a connection between “outPort ” in “proc_src ” and “inPort ” in “proc_sink ”. Then the tool gets a source port of this connection, “outPort ” in this example. Next step is to get a 61 thread where the port exists, and find “outPort ” in “taskSrc ”. In the next step, if this “taskSrc ” is not a synchronous (periodic) thread, then the original tool stops searching for other synchronous threads in the connection and quits this analysis: as a result, it outputs an invalid bus load value. On the other hand, a new algorithm searches for not only the source ports but also the destination ports of the connection. If the destination port is in a synchronous (periodic) thread, then it can get the message rate of the thread. In Figure 36 example, the “taskSink ” has a destination port and is a synchronous task, the new approach can get the message rate, data size [byte] / (10 [milliseconds] / 1000) [bps]. This example only contains two tasks and one connection: however, real systems could have tens or even hundreds of tasks and complicated related interconnections. For example, it could have a set of precedent dependent tasks that has ten aperiodic tasks and one periodic task. The new approach can detect the message rates of all the connections by recursively searching for a port in a synchronous (periodic) task. 62 Figure 36 Example AADL for bus load analysis 4.3.3 Portability Analysis The original OSATE resource allocation analysis tool was lacking in its abilities to analyze precedent dependent aperiodic tasks as with the bus load analysis tool. Therefore, I also directly improved the tool. 63 Figure 37 Algorithm of Resource Allocation analysis tool Figure 37 shows the algorithm of the resource allocation analysis tool that contains both original steps and new steps of my approach. I will explain these steps using an example of AADL shown in Figure 38. This tool first searches a CPU in the system and continues the process for all the CPUs, then gets MIPS (million instructions per second) capacity from the CPU. This MIPS capacity value will be used as the boundary of computing power and the tool will find whether the total MIPS of tasks is within the boundary. The tool next searches a process and then searches a thread in the process. Take Figure 38 for example: there is an “Intel ” CPU, the capacity of which is 10 MIPS, and which has “taskSrc ” and “taskSink ” in it. If the task is not a synchronous (periodic) thread, then the original tool stops calculating the MIPS of the task. This is why the original tool is lacking in its abilities to analyze aperiodic tasks. On the other hand, a new algorithm searches for a synchronous thread through the connection of the asynchronous (aperiodic) task. For example, 64 because the “taskSrc ” is an aperiodic task, it does not have a period itself. However, the new approach searches for the “out_port ” of “taskSrc ” and finds a synchronous task “taskSink ” that is connected to the “out_port”. The period of the aperiodic task “taskSrc” is supposed to be the same as the periodic task “taskSink”: therefore, the new approach can detect the period not only of synchronous (periodic) tasks but also of asynchronous (aperiodic) tasks. Once the tool gets the period of each task, it can calculate the estimated MIPS of the task by using the execution time of the task. The tool finally outputs a result that shows whether or not the total MIPS of all the tasks in a CPU are within the MIPS capacity of the CPU. Figure 38 Example AADL for resource allocation analysis 65 Chapter 5 Evaluation In this chapter, I will provide the evaluation of my research. In more detail, I will evaluate the hypotheses that was stated in 1.3 and demonstrate that my proposed approaches achieve the objective that was also stated in 1.3. To test the hypotheses, I first modeled the evaluation platform described in Chapter 3 by using AADL. Figure 39 shows the model produced by OSATE Instance Model Viewer [39]. I have attached the AADL script in A.1 AADL for the Evaluation Platform. Figure 39 AADL for Evaluation Platform I described the pipeline architecture as a series of processes, and the plugin architecture as a set of threads in a process. For example, in Figure 39, filter Input is described as process “P1_input” and plugins of file, http, and app are described as threads of “file”, “http”, and “app” where port input and port output of each threads are shared with the parent process. By sharing those ports between the parent process and the threads, they have the same interface so that developers can add as many threads (plugins) as they want into the process. Note that a process in AADL 66 corresponds to a task that has been stated through this thesis, and a thread in AADL corresponds to a plugin as well (see Table 3). I modeled these constraints based on the following two reasons: - In AADL, a thread is a minimum execution process and able to have an execution time, which should be different from each plugin of the evaluation platform - A process located in a CPU is able to be executed simultaneously with the other processes. This helps me analyze the concurrency of tasks, especially for the performance analysis. Each thread (plugin) in the pipeline is described as aperiodic thread: therefore, each process (task) that has those threads can be treated as an aperiodic task as well. For the testing purpose, I put process “P0_main” that has a periodic thread and is assigned a role of external devices either for input devices such as internet, HDD, and DVD, or for output devices such as TV, PC, and phones. Table 3 Correspondence between AADL and this thesis AADL components The terms of this thesis Process Task (either periodic or aperiodic) Thread Plugin Port Message bus In the pipeline of Figure 39, there is a system called “multi” that has processes of “P3_queue” and “P4_decoder”. This system is designed for multiple components so that I can use this for the scalability analysis, which will be described later. I did not clearly demonstrate a message bus (see 3.3) in this AADL because the AADL ports work as a message bus from a standpoint of the environmental and implemental independence. In the remainder of this chapter, I will evaluate my new approaches for the performance, scalability, and portability analyses respectively. 67 5.1 Performance analysis Figure 40 Estimated execution time By using the AADL of the evaluation platform, I first performed the performance analysis stated in 4.3.1. To obtain a performance analysis, I put the execution time on all the threads of the evaluation platform. Figure 40 shows each execution time of each thread and it also shows the precedent dependence between aperiodic threads (plugins): Job0 is executed by a set of aperiodic tasks (plugins) of file, mp4, queue, h264, audio, and video; Job1 is executed by http, mkv, queue2, mp3, pango, and audio; and Job2 is executed by app, his, multiqueue, aac, volume, and pixmap. The best-case total execution time of Job0, Job1, and Job2 are 47, 51, and 55 milliseconds respectively, assuming no delay or overhead within the communication between the tasks. 68 Figure 41 Task precedence of the evaluation platform Figure 42 Job Matrix in AADL First step of the performance analysis is to convert the AADL in order to make combinations of Job0, Job1, and Job2. Figure 41 is an original AADL that I made to describe the task precedence of 69 the evaluation platform. I executed the Job Matrix Converter, which I proposed, and get a new AADL shown in Figure 42. Figure 43 Cheddar original output Second step is to run Cheddar with the AADL and get a simulation result in XML format. Cheddar also outputs the worst-case response time of each thread (plugin) and the end-to-end worst-case response time of precedent tasks (see Figure 43). However, this only shows the worst-case of each task and users cannot find when and how this worst-case occurred. 70 Figure 44 Time-Lined View The Execution Time Analyzer, which I proposed, creates two results. First, it outputs a time lined view as shown in Figure 44 (note: this tool outputs a csv file so you should add colors yourself). You can see how each plugin (thread) affects the others: specifically, the first processed plugin prevents the other plugins from being executed because they share a same processor so the latter plugin waits until the processor is available. The order of the execution of each task can make each job’s total execution time different. The time-lined view of the Execution Time Analyzer helps developers understand how a set of precedent dependent aperiodic tasks affects the execution time of others. If developers find a possibility that the worst-case execution time surpasses the requirement, they reconsider the architecture, for example, dividing a bottleneck task into several tasks, replacing a CPU to more powerful one, or tuning up the algorithm to shorten the execution time of the task. These works are considered to be very costly and error prone, especially at the end of the development process, therefore reconsidering software architecture at the beginning will decrease the cost and the effort. 71 Figure 45 Matrix View Although the time-lined view is helpful to see how jobs affect each other, it is hard to find the worst-case execution time with a particular combination of two jobs. The matrix view of the Execution Time Analyzer fixes this issue. Figure 45 shows the “worst-case|best-case” execution time of each combination of jobs: Job0 takes 61 milliseconds with Job1, and 74 milliseconds with Job2 in its worst-case execution time, while 49 milliseconds with both in its best-case execution time; Job1 takes 61 and 73 milliseconds with Job0 and Job3 respectively in its worst-case; and Job2 takes 86 and 78 milliseconds with Job0 and Job2 respectively in its worst-case. As you can see, the worst-case execution time would be different depending on with which job occurs at the same time. Take Job0 for example: it could take a lot more time with Job2 than with Job1. Ultimately, there might be a possibility that developers cannot make it to implement a particular combination of jobs while satisfying the requirement of the response time of both jobs. In that case, developers have to reconsider the software architecture or make a decision to process only a job as higher priority with sacrificing to process another job within a time. The Execution Time Analyzer also helps to make developers realize these types of issue before the implementation. 72 5.2 Scalability Analysis Figure 46 AADL for Multiple component To make it simpler, I only use system “multi” for scalability analysis instead of using whole evaluation platform described in Figure 39. The detail of system “multi” is described in Figure 46. In this example, I have used an AADL process to describe “hdd” that connects to bus “hdd_high”. Bus “hdd_high” has a bandwidth capacity of 100 Mbyte/sec and this capacity can be considered as the hard disk drive’s data transfer rate. Process “P3_queue” processes data at a period of 20 milliseconds and inputs 100 Kbyte data to “hdd_high” every period. The “multi” system has multiple components, four “P4_decoder” processes in this example, and this system reads data at 100 Kbytes per 20 milliseconds and writes data at 2 Mbytes per 20 milliseconds. Here I want to analyze up to how many “P4_decoder” processes this architecture can possess and at that time how fast the architecture could process data. The original OSATE bus load analysis plugin cannot handle this architecture. Figure 47 shows the output of the original OSATE analysis tool. Because both “P3_queue” and “hdd” processes are asynchronous (aperiodic), the original tool does not 73 output the data transfer rate for the connections where these asynchronous processes have source port (see the red rectangle in Figure 47). Figure 47 Problem of the original OSATE bus load analysis Figure 48 A result of the new bus load analysis tool On the other hand, a new analysis tool, which I proposed, can search a synchronous thread through all the connections and the flows, and find a period of the connection the source port of which is in an aperiodic thread. Figure 48 is a result achieved by the new bus load analysis tool. Thread “P3_queue.queue” has port “in_port” which is connected to “src_port” in thread “test” in 74 process “P0_main”, and this thread “test” is a periodic thread and has a period of “20 milliseconds”. Then (Data Size * Sender Rate) is 100 Kbyte * 1000/20 milliseconds, and is equal to 5000.0 Kbytes / sec. Thread “hdd.thr” has port “small_write” which also is connected to “src_port” in process “P0_main” via process “P3_queue”. Then (Data Size * Sender Rate) is 100 Kbyte * 1000/20 milliseconds / 4 (the number of “P4_decoder” processes), and is equal to 1250.0 Kbytes / sec. As a result, the new tool outputs the result that warns the total budget of all the connections exceeds the capacity of “hdd_high”, 100 Mbytes / sec, while the original tool could not measure. Developers now can find the maximum number of instances of multiple components, three “P4_decoder” processes in this example, and it enables them to reconsider the software architecture beforehand if the result shows it does not satisfy scalability-related requirements. Again, redesigning software architectures at a later stage is very costly: therefore, the new tool can reduce the cost of software development. This example only had one hard disk drive and one multiple component (“P4_decoder”) but real systems might have several devices and components that affect each other. The new approach can also be used for that complicated related interconnections because it analyzes each device and outputs a result by considering all the connections between aperiodic tasks. 5.3 Portability analysis As mentioned earlier, AADL supports port components for connectors between processes. This makes the components portable between CPUs/Memory. However, it does not necessarily mean any processes can be placed on a CPU because CPUs have a capacity in terms of their computational power. If too many processes are placed on a CPU that does not have the enough computational power for all the processes, some processes are not processed as expected in a timely manner and result in the performance problem. 75 Figure 49 AADL for portability analysis: Alternative 1 Figure 50 AADL for portability analysis: Alternative 2 Figure 49 and Figure 50 show examples of the process allocation between CPUs by using the evaluation platform. In alternative 1 (Figure 49), “P1_input”, “P2_demux”, and “P3_queue” 76 processes are located on processor “Intel1” which has 50 MIPS capacity, while all the other processes are located on processor “arm” which has 5 MIPS capacity. In alternative 2 (Figure 50), on the other hand, only process “P4_decoder” is placed on processor “arm”, while all the other processes are placed on processor “Intel1”. Figure 51 Problem of the original OSATE resource allocation analysis The original OSATE resource allocation analysis plugin cannot analyze these two alternatives. Figure 51 shows the output of the original OSATE analysis tool. Because all threads (plugins) are asynchronous (aperiodic), this tool does not output the MIPS of each task (see the red rectangle in Figure 51). 77 Figure 52 A result of the new resource allocation analysis tool On the other hand, a new analysis tool, which I proposed, can search a synchronous thread through all the connections and the flows, and find a period of an aperiodic thread. Figure 52 shows a result of both the alternative 1 and alternative 2 achieved by the new resource allocation analysis tool. According to this analysis, the alternative 1 has a problem that the total MIPS of threads in processor “arm” exceed its capacity while the alternative 2 can be within the acceptable range. Relocating a component from a processor to others often happens in embedded software developments. Even if the relocation seems to be done successfully at first, it might have a problem with surpassing the CPU capacity and end up degrading the performance quality. 78 Importantly, these problems are hardly to be noticed and, as a result, cost a lot of time to fix the issue. The new approach helps developers find this issue earlier and would decrease the cost. 79 Chapter 6 Conclusion Performance, scalability, and portability are the key non-functional requirements in embedded systems and that affect the design of software architecture. Early analysis of these requirements of the system is essential to reduce the development cost and risks. There has been much research to propose model-based analysis methods. Some methods use general software modeling approaches such as UML for embedded software analyses but they are lacking in their ability to describe the complex performance properties. Other methods propose an original modeling framework to deal with the embedded software requirements but these are hard to repurpose for another purpose by using other existing tools. Meanwhile, AADL can be used for the analyses because the principle design is aiming to handle embedded systems and also there are state-of- the-art analysis tools using AADL. However, AADL and the related analysis tools have technical issues to deal with precedent aperiodic dependent tasks, which are widely used in embedded software architecture. Although Cheddar along with AADL can simulate all the combinations of precedent dependent tasks, it may be hard for developers to interpret and find which combination could cause the worst execution time in performance analyses. Even though OSATE can be used for scalability and portability analyses, OSATE analysis tools cannot analyze aperiodic tasks because they do not have timing- related properties that are needed for the analyses. To address these problems, this thesis first proposed a new approach for performance analyses that was able to isolate combinations of precedent dependent task sets by analyzing these sets in a pairwise fashion. The evaluation showed that this new performance analysis approach could create a matrix viewed result that contains the worst- and best-case execution time of a particular combination of task sets. This will help developers easily find which combination of task sets causes a serious problem and reconsider the software architecture at an 80 early stage. This thesis also proposed a new approach for scalability and portability analyses that was able to analyze aperiodic tasks. To perform the approach, I directly improved OSATE analysis tools by searching other tasks that are precedent dependent on aperiodic tasks and by getting necessary properties for the analysis from the dependent tasks. The evaluation showed that both the new scalability and the portability analysis methods can analyze embedded software architecture with aperiodic tasks, which the original OSATE analysis tools had not been able to do. 6.1 Future Work There are still remaining research challenges that can be addressed in future work. Although the performance, scalability, and portability are key non-functional requirements for embedded systems, there are many other requirements that should be analyzed prior to the implementation such as security, changeability, and usability. Fault analysis is one of the most important and difficult analyses for embedded systems because precedent dependent aperiodic tasks make it difficult to analyze the faults in a system due to the difficulties in predicting the occurrences. AADL and OSATE have already supported Error-Model Annex to tackle the fault analysis and it is therefore possible to improve this existing tool to handle precedent dependent aperiodic tasks in a manner that I have proposed in this thesis. In addition, users still have to model the system architecture itself. Pipeline and plugin architectures as stated throughout this thesis can be complicated to model manually. Due to the flexibility of the architecture, the system might end up having hundreds of filters and plugins and result in developers not being able to model or to fully understand the system. Automatic modeling methods can be a solution for this issue. Modeling precedent dependent aperiodic tasks can be complicated but at the same time they can have certain patterns that tools can model automatically with limited inputs from users. Even though it may be hard to generate all models 81 of precedent dependent aperiodic tasks, the tools will at least be able to generate skeletons that help developers model the tasks in some detail. 82 Bibliography [1] N. P. Topham, A. Omondi and R. N. Ibbett, "On the design and performance of conventional pipelined architectures," Journal of Supercomputing, vol. 1, no. 4, pp. 353-393, 1988. [2] E. Niemela and T. Ihme, "Product line software engineering of embedded systems," ACM SIGSOFT Software Engineering Notes, vol. 26, no. 3, pp. 118-125, 2001. [3] D. Dhungana et al, "Modeling multiplicity and hierarchy in product line architectures: Extending a decision-oriented approach," Proceedings of the WICSA, pp. 1-6, 2014. [4] E. Danielyan, "Taking advantage of ToolTalk," Inside Solaris, vol. 6, no. 10, pp. 6-7, 2000. [5] J. Jaben-Eilon, "Understanding CORBA," Bank Technology News, vol. 13, no. 8, pp. 52-56, 2000. [6] O. Salli, O. Nevalainen and V. Leppänen, "Event‐driven asynchronous method calls with the D‐Bus message system," Software: Practice and Experience, vol. 45, no. 1, pp. 53- 74, 2015. [7] D. D. Gajski and F. Vahid, "Specification and design of embedded hardware-software systems," IEEE Design & Test of Computers, vol. 12, no. 1, pp. 53-67, 1995. [8] N. Medvidovic, R.N. Taylor, "A classification and comparison framework for software architecture description languages," IEEE Transactions on Software Engineering, vol. 26, no. 1, pp. 70-93, 2000. [9] P. H. Feiler, D. P. Gluch and J. J. Hudak, "The architecture analysis & design language (AADL): An introduction.," Star 44(24), 2006. [10] P. Feiler, "Open Source AADL Tool Environment (OSATE)," 2005. [Online]. Available: http://www.aadl.info/aadl/documents/d1_1500_Osate.pdf. [Accessed 10 Feb. 2017]. [11] L. G. Williams and C. U. Smith, "Performance evaluation of software architecture," Proceedings of the 1st International Workshop on Software and Performance, pp. 164-177, 1998. [12] H. Gomaa and D. A. Menasce, "Design and performance modeling of component interaction patterns for distributed software architecture," Proceedings of the 2nd ACM International Workshop on Software and Performance, pp. 117-126, 2000. 83 [13] M. G. Harbour, M. H. Klein and J. P. Lehoczky, "Timing analysis for fixed-priority scheduling of hard real-time systems," IEEE Transactions on Software Engineering, vol. 20, no. 1, pp. 13-28, 1994. [14] S. Wang, "Performance modeling and analysis techniques for integrated embedded control software design," University of Michigan, Ann Arbor, 2004. [15] F. Singhoff, J. Legrand, L. Nana, and L. Marce, "Cheddar: a flexible real time scheduling framework," Proceedings of the 2004 Annual ACM SIGAda International Conference on Ada, pp. 1-8, 2004. [16] R.N. Taylor, N. Medvidovic, and E.M. Dashofy, Software Architecture: Foundations, Theory, and Practice, John Wiley & Sons, 2009. [17] R. Kazman et al, "Experience with performing architecture tradeoff analysis," Proceedings of the 21st International, pp. 54-63, 1999. [18] R. Kazman et al, "SAAM: a method for analyzing the properties of software architecture," Proceedings of the 16th, pp. 81-90, 1994. [19] P. Mishra and N. Dutt, "Architecture description languages for programmable embedded systems," IEE Proceedings - Computers and Digital Techniques, vol. 152, no. 3, p. 285, 2005. [20] P. Mishra et al, "Automatic modeling and validation of pipeline specifications driven by an architecture description language," IEEE Computer Society, p. 458, 2002. [21] R. Marinescu, E. P. Enoiu and C. Seceleanu, "Statistical Analysis of Resource Usage of Embedded Systems Modeled in EAST-ADL," IEEE Computer Society Annual Symposium on VLSI, pp. 380-385, 2015. [22] P. Cuenot et al, "The EAST-ADL Architecture Description Language for Automotive Embedded Software," Model-Based Engineering of Embedded Real-Time Systems, vol. 6100, pp. 297-307, 2011. [23] H. Hoyos, R. Casallas and F. Jiménez, "HiLeS-T: an ADL for early requirement verification of embedded systems," Proceedings of the 5th International Workshop on model based architecting and construction of embedded systems, pp. 7-12, 2012. [24] J. Lehoczky, "Real-time queueing network theory," Proceedings Real-Time Systems Symposium, pp. 58-67, 1997. [25] O. Redell and M. Torngren, "Calculating exact worst case response times for static priority scheduled tasks with offsets and jitter," Eighth IEEE Real-Time and Embedded Technology and Applications Symposium, pp. 164-172, 2002. 84 [26] A. Navarro et al, "Analytical Modeling of Pipeline Parallelism," 18th International Conference on Parallel Architectures and Compilation Techniques, pp. 281-290, 2009. [27] A. H. Hormati et al, "Flextream: Adaptive Compilation of Streaming Applications for Heterogeneous Architectures," 18th International Conference on Parallel Architectures and Compilation Techniques, pp. 214-223, 2009. [28] M. Suleman et al, "Feedback-directed pipeline parallelism," Proceedings of the 19th international conference on parallel architectures and compilation techniques, pp. 147-156, 2010. [29] S. Jeong, "Tizen, Overview and Architecture," 11-12 October 2012. [Online]. Available: https://events.linuxfoundation.org/images/stories/pdf/lceu2012_haitzler.pdf. [Accessed 18 Feburary 2017]. [30] SKKU Embedded Software Lab, "Tizen Multimedia Framework," [Online]. Available: https://wiki.tizen.org/w/images/7/75/11-Tizen_Multimedia_Framework.ppt. [Accessed 1 Feb 2017]. [31] Tizen, "Porting Guide/Multimedia - Tizen Wiki," Tizen, 7 Feburary 2017. [Online]. Available: https://wiki.tizen.org/wiki/Porting_Guide/Multimedia. [Accessed 18 Feburary 2017]. [32] R. Rudman and N. Sexton, "The internet of things," Accountancy SA, pp. 22-23, 2016. [33] M. U. Farooq et al, "A review on internet of things (IoT)," International Journal of Computer Applications, vol. 113, no. 1, 2015. [34] S. Papavassiliou et al, "Guest Editors' Introduction: Special Issue on Cyber-Physical Systems (CPS)," IEEE Transactions on Parallel and Distributed Systems, vol. 23, no. 9, pp. 1569-1571, 2012. [35] L. Zhang, "Designing big data driven cyber physical systems based on AADL," Systems, Man and Cybernetics (SMC), 2014 IEEE International Conference on, pp. 3072-3077, 2014. [36] J. Hugues, "10_02_09-AADL_User_Day-Ocarina.ppt," 2 10 2009. [Online]. Available: https://wiki.sei.cmu.edu/aadl/images/f/f1/10_02_09-AADL_User_Day- Ocarina.pdf. [Accessed 15 3 2017]. [37] P. H. Feiler, J. Hansson, "Flow latency analysis with the architecture analysis & design language (AADL)," NASA/Langley Research Center, Hampton, 2007. [38] P. Feiler, "Resource Analysis with OSATE," March 2006. [Online]. Available: http://www.aadl.info/aadl/downloads/resourceanalysis032006.pdf. [Accessed 14 2 2017]. 85 [39] SEI, "Osate 2 IMV," SEI, 25 September 2014. [Online]. Available: https://wiki.sei.cmu.edu/aadl/index.php/Osate_2_IMV. [Accessed 10 March 2017]. [40] H. H. Manh, "Software Testability Measure for SAE Architecture Analysis and Design Language (AADL)," Clemson University, Ann Arbor, 2012. [41] H. Deng and J. Huang, "System integration and data exchange solution based on message queue software bus," Journal of South China University of Technology (Natural Science Edition), vol. 36, no. 5, pp. 1-5, 2008. [42] S. Zhang, L. Wang and F. Yang, "Hierarchical message bus-based software architectural style," Science in China Series : Information Sciences, vol. 45, no. 2, pp. 111-120, 2002. 86 Appendix A.1 AADL for the Evaluation Platform List A. 1 Filters.aadl package Filters public with SEI; with Plugins; with Cheddar_Properties; with Scalable; -- -- Processes (Filters) -- process FilterSmall features in_port : in event data port Plugins::small; out_port : out event data port Plugins::small; flows f_path : flow path in_port -> out_port; end FilterSmall; process FilterMiddle features in_port : in event data port Plugins::small; out_port : out event data port Plugins::large; flows f_path : flow path in_port -> out_port; end FilterMiddle; process FilterLarge features in_port : in event data port Plugins::large; out_port : out event data port Plugins::large; flows f_path : flow path in_port -> out_port; end FilterLarge; -- -- Processes (Impl) -- process implementation FilterSmall.input subcomponents file : thread Plugins::Input.file; http : thread Plugins::Input.http; app : thread Plugins::Input.app; connections c_in1 : port in_port -> file.in_port; c_in2 : port in_port -> http.in_port; c_in3 : port in_port -> app.in_port; c_out1 : port file.out_port -> out_port; c_out2 : port http.out_port -> out_port; c_out3 : port app.out_port -> out_port; flows f_path : flow path in_port -> out_port; end FilterSmall.input; process implementation FilterSmall.demux subcomponents mp4 : thread Plugins::Demux.mp4; 87 mkv : thread Plugins::Demux.mkv; his : thread Plugins::Demux.his; connections c_in1 : port in_port -> mp4.in_port; c_in2 : port in_port -> mkv.in_port; c_in3 : port in_port -> his.in_port; c_out1 : port mp4.out_port -> out_port; c_out2 : port mkv.out_port -> out_port; c_out3 : port his.out_port -> out_port; flows f_path : flow path in_port -> out_port; end FilterSmall.demux; process implementation FilterSmall.queue subcomponents queue : thread Plugins::Queue.queue; queue2 : thread Plugins::Queue.queue2; multiqueue : thread Plugins::Queue.multiqueue; connections c_in1 : port in_port -> queue.in_port; c_in2 : port in_port -> queue2.in_port; c_in3 : port in_port -> multiqueue.in_port; c_out1 : port queue.out_port -> out_port; c_out2 : port queue2.out_port -> out_port; c_out3 : port multiqueue.out_port -> out_port; flows f_path : flow path in_port -> out_port; end FilterSmall.queue; process implementation FilterSmall.queuemulti subcomponents queue : thread Plugins::Queue.queue; connections c_in1 : port in_port -> queue.in_port; c_out1 : port queue.out_port -> out_port; flows f_path : flow path in_port -> out_port; end FilterSmall.queuemulti; process implementation FilterMiddle.decoder subcomponents h264 : thread Plugins::Decoder.h264; mp3 : thread Plugins::Decoder.mp3; aac : thread Plugins::Decoder.aac; connections c_in1 : port in_port -> h264.in_port; c_in2 : port in_port -> mp3.in_port; c_in3 : port in_port -> aac.in_port; c_out1 : port h264.out_port -> out_port; c_out2 : port mp3.out_port -> out_port; c_out3 : port aac.out_port -> out_port; flows f_path : flow path in_port -> out_port; end FilterMiddle.decoder; process implementation FilterMiddle.decodermulti subcomponents h264 : thread Scalable::Decoder; connections c_in1 : port in_port -> h264.in_port; c_out1 : port h264.out_port -> out_port; flows f_path : flow path in_port -> out_port; end FilterMiddle.decodermulti; process implementation FilterMiddle.decoderPortable subcomponents task : thread Plugins::Decoder.aac; connections c_in1 : port in_port -> task.in_port; 88 c_out1 : port task.out_port -> out_port; flows f_path : flow path in_port -> out_port; end FilterMiddle.decoderPortable; process implementation FilterLarge.filter subcomponents audio : thread Plugins::Filter.audio; pango : thread Plugins::Filter.pango; volume : thread Plugins::Filter.volume; connections c_in1 : port in_port -> audio.in_port; c_in2 : port in_port -> pango.in_port; c_in3 : port in_port -> volume.in_port; c_out1 : port audio.out_port -> out_port; c_out2 : port pango.out_port -> out_port; c_out3 : port volume.out_port -> out_port; flows f_path : flow path in_port -> out_port; end FilterLarge.filter; process implementation FilterLarge.output subcomponents video : thread Plugins::Output.video; audio : thread Plugins::Output.audio; pixmap : thread Plugins::Output.pixmap; connections c_in1 : port in_port -> video.in_port; c_in2 : port in_port -> audio.in_port; c_in3 : port in_port -> pixmap.in_port; c_out1 : port video.out_port -> out_port; c_out2 : port audio.out_port -> out_port; c_out3 : port pixmap.out_port -> out_port; flows f_path : flow path in_port -> out_port; end FilterLarge.output; -- -- Main Assembly -- system Evaluation features in_port : in event data port Plugins::small; out_port : out event data port Plugins::large; flows f_path : flow path in_port -> out_port; end Evaluation; system implementation Evaluation.i subcomponents intel1 : processor Plugins::Intel.i; arm : processor Plugins::Arm.i; eth : bus Plugins::Ethernet; P1_input : process FilterSmall.input; P2_demux : process FilterSmall.demux; scale : system Scalable.i; P5_filter : process FilterLarge.filter; P6_output : process FilterLarge.output; connections cin : port in_port -> P1_input.in_port; c12 : port P1_input.out_port -> P2_demux.in_port; c23 : port P2_demux.out_port -> scale.in_port; c45 : port scale.out_port -> P5_filter.in_port; c56 : port P5_filter.out_port -> P6_output.in_port; cout: port P6_output.out_port -> out_port; cbus34: bus access scale.eth -> eth; cbus1 : bus access intel1.eth -> eth; cbus2 : bus access intel2.eth -> eth; cbus5 : bus access intel5.eth -> eth; 89 cbus6 : bus access intel6.eth -> eth; flows f_path : flow path in_port -> cin -> P1_input.f_path -> c12 -> P2_demux.f_path -> c23 -> scale.f_path -> c45 -> P5_filter.f_path -> c56 -> P6_output.f_path -> cout -> out_port; properties Actual_Processor_Binding => reference intel1 applies to P1_input; Actual_Processor_Binding => reference intel1 applies to P2_demux; Actual_Processor_Binding => reference arm applies to P5_filter; Actual_Processor_Binding => reference arm applies to P6_output; Actual_Processor_Binding => reference intel1 applies to scale.P3_queue; Actual_Processor_Binding => reference arm applies to scale.multi.P4_decoder_1; Actual_Connection_Binding => reference eth applies to c12; Actual_Connection_Binding => reference eth applies to c23; Actual_Connection_Binding => reference eth applies to c45; Actual_Connection_Binding => reference eth applies to c56; Cheddar_Properties::Task_Precedencies => ( -- Job 1 "P0_main.test", "P1_input.file", "P1_input.file", "P2_demux.mp4", "P2_demux.mp4", "P3_queue.queue", "P3_queue.queue", "P4_decoder.h264", "P4_decoder.h264", "P5_filter.audio", "P5_filter.audio", "P6_output.video", -- Job 2 "P0_main.test", "P1_input.http", "P1_input.http", "P2_demux.mkv", "P2_demux.mkv", "P3_queue.queue2", "P3_queue.queue2", "P4_decoder.mp3", "P4_decoder.mp3", "P5_filter.pango", "P5_filter.pango", "P6_output.audio", -- Job 3 "P0_main.test", "P1_input.app", "P1_input.app", "P2_demux.his", "P2_demux.his", "P3_queue.multiqueue", "P3_queue.multiqueue", "P4_decoder.aac", "P4_decoder.aac", "P5_filter.volume", "P5_filter.volume", "P6_output.pixmap" ); end Evaluation.i; end Filters; List A. 2 Plugins.aadl package Plugins public with SEI; with Cheddar_Properties; bus Ethernet properties SEI::BandWidthCapacity => 1000.0 Mbytesps; end Ethernet; 90 processor Intel features eth : requires bus access Ethernet; properties SEI::MIPSCapacity => 50.0 MIPS; end Intel; processor implementation Intel.i properties Scheduling_Protocol => POSIX_1003_HIGHEST_PRIORITY_FIRST_PROTOCOL; Cheddar_Properties::Preemptive_Scheduler => true; Cheddar_Properties::Scheduler_Quantum => 0 ms; end Intel.i; processor ARM features eth : requires bus access Ethernet; properties SEI::MIPSCapacity => 5.0 MIPS; end ARM; processor implementation ARM.i properties Scheduling_Protocol => POSIX_1003_HIGHEST_PRIORITY_FIRST_PROTOCOL; Cheddar_Properties::Preemptive_Scheduler => true; Cheddar_Properties::Scheduler_Quantum => 0 ms; end ARM.i; -- -- data definition -- data small properties Data_Size => 100 KByte; end small; data large properties Data_Size => 2 MByte; end large; -- -- Threads (plug-ins) -- thread Input features in_port : in event data port small; out_port : out event data port small; flows f_path : flow path in_port -> out_port; properties Dispatch_Protocol => Aperiodic; reference_processor => classifier (Intel); end Input; thread implementation Input.file properties compute_execution_time => 1 ms .. 1 ms; end Input.file; thread implementation Input.http properties compute_execution_time => 2 ms .. 2 ms; end Input.http; thread implementation Input.app properties compute_execution_time => 3 ms .. 3 ms; end Input.app; thread Demux features 91 in_port : in event data port small; out_port : out event data port small; flows f_path : flow path in_port -> out_port; properties Dispatch_Protocol => Aperiodic; reference_processor => classifier (Intel); end Demux; thread implementation Demux.mp4 properties compute_execution_time => 6 ms .. 6 ms; end Demux.mp4; thread implementation Demux.mkv properties compute_execution_time => 5 ms .. 5 ms; end Demux.mkv; thread implementation Demux.his properties compute_execution_time => 4 ms .. 4 ms; end Demux.his; thread Queue features in_port : in event data port small; out_port : out event data port small; flows f_path : flow path in_port -> out_port; properties Dispatch_Protocol => Aperiodic; reference_processor => classifier (Intel); end Queue; thread implementation Queue.queue properties compute_execution_time => 7 ms .. 7 ms; end Queue.queue; thread implementation Queue.queue2 properties compute_execution_time => 8 ms .. 8 ms; end Queue.queue2; thread implementation Queue.multiqueue properties compute_execution_time => 9 ms .. 9 ms; end Queue.multiqueue; thread Decoder features in_port : in event data port small; out_port : out event data port large; flows f_path : flow path in_port -> out_port; properties Dispatch_Protocol => Aperiodic; reference_processor => classifier (Intel); end Decoder; thread implementation Decoder.h264 properties compute_execution_time => 20 ms .. 20 ms; end Decoder.h264; thread implementation Decoder.mp3 properties compute_execution_time => 11 ms .. 11 ms; end Decoder.mp3; thread implementation Decoder.aac properties compute_execution_time => 10 ms .. 10 ms; end Decoder.aac; thread Filter features in_port : in event data port large; 92 out_port : out event data port large; flows f_path : flow path in_port -> out_port; properties Dispatch_Protocol => Aperiodic; reference_processor => classifier (Intel); end Filter; thread implementation Filter.audio properties compute_execution_time => 7 ms .. 7 ms; end Filter.audio; thread implementation Filter.volume properties compute_execution_time => 20 ms .. 20 ms; end Filter.volume; thread implementation Filter.pango properties compute_execution_time => 9 ms .. 9 ms; end Filter.pango; thread Output features in_port : in event data port large; out_port : out event data port large; flows f_path : flow path in_port -> out_port; properties Dispatch_Protocol => Aperiodic; reference_processor => classifier (Intel); end Output; thread implementation Output.video properties compute_execution_time => 6 ms .. 6 ms; end Output.video; thread implementation Output.audio properties compute_execution_time => 5 ms .. 5 ms; end Output.audio; thread implementation Output.pixmap properties compute_execution_time => 20 ms .. 20 ms; end Output.pixmap; end Plugins; 93 List A. 3 Test.aadl package Test public with SEI; with Filters; with Plugins; -- -- Main Assembly -- thread Test features src_port : out event data port Plugins::small; sink_port : in event data port Plugins::large; flows f_src : flow source src_port; f_sink : flow sink sink_port; properties Dispatch_Protocol => Periodic; compute_execution_time => 1 ms .. 1 ms; Period => 120 ms; reference_processor => classifier (Plugins::Intel); end Test; process Main features src_port : out event data port Plugins::small; sink_port : in event data port Plugins::large; flows f_src : flow source src_port; f_sink : flow sink sink_port; end Main; process implementation Main.i subcomponents test : thread Test; connections c_src : port test.src_port -> src_port; c_sink : port sink_port -> test.sink_port; flows f_src : flow source src_port; f_sink : flow sink sink_port; end Main.i; system s0 end s0; system implementation s0.i subcomponents P0_main : process Main.i; eval_pf : system Filters::Evaluation.i; connections c0 : port P0_main.src_port -> eval_pf.in_port; end s0.i; end Test; 94 A.2 Job Matrix Converter List A. 4 makeMatrix.pl #!/bin/perl $inputfile=$ARGV[0]; ######################################## ## Read file and store precedence jobs ######################################## $flagPrecedence = 0; $jobCount = -1; @jobs = (); open (FILE, $inputfile) or die "$!"; while (<FILE>) { my $line = $_; if ($line =~ /Cheddar_Properties::Task_Precedencies/) { $flagPrecedene = 1; } elsif ($line =~ /\);/) { $flagPrecedene = 0; } elsif ($flagPrecedene == 1) { if ($line =~ /-- Job\s+([0-9]*)/) { $jobCount++; } elsif ($line =~ /\"(.+)\", \"(.+)\"/) { push @{$jobs[$jobCount]}, $1; push @{$jobs[$jobCount]}, $2; } } } close (FILE); # jobs[0]: [main.test, input.file] # jobs[1]: [input.file, demux.mp4] ######################################## ## Create combination characters (A, B, ..) ######################################## $charComb = 'A'; %charCombHash; ## {'A'} => [0,1], {'B'} => [0,2], .. %jobNumHash; ## {0} => [A,B], {1} => [A,C], .. for ($i = 0 ; $i <= $jobCount ; ++$i) { for ($j = $i+1 ; $j <= $jobCount ; ++$j) { push (@{$charCombHash{$charComb}}, $i); push (@{$charCombHash{$charComb}}, $j); push (@{$jobNumHash{$i}}, $charComb); push (@{$jobNumHash{$j}}, $charComb); $charComb++; } } ######################################## ## Re-read input file and convert lines ######################################## $flagPrecedence = 0; 95 open (FILE, $inputfile) or die "$!"; while (<FILE>) { my $line = $_; ## End Precedencies if ($line =~ /\);/) { $flagPrecedene = 0; } ## Duplicate thread subcomponents my @words = split(/\s+/, $line); if ($words[3] =~ /thread/) { my $thread = $words[1]; my @already; for (my $jobNum = 0 ; $jobNum < scalar(@jobs) ; ++$jobNum) { my @uniq = unique_array(@{$jobs[$jobNum]}); for ($j = 0 ; $j < scalar(@uniq) ; ++$j) { $compo = $uniq[$j]; if ($compo =~ /\.(.*)/) { if ($1 eq $thread) { my $suffix; foreach $char (@{$jobNumHash{$jobNum}}) { my $convLine = $line; my $suffix; if ($thread eq "test") { if (!grep { $_ eq $char } @already) { $suffix = "${char}"; push (@already, $char); $convLine =~ s/$thread/${thread}_${char}/g; print $convLine; } } else { # file : thread Input_file; -> only the first one would be converted $convLine =~ s/$thread /${thread}_${char}_${jobNum} /g; print $convLine; } } } } else { print "Error! compo = $compo\n"; } } } } elsif ($flagPrecedene == 1) { ## Print every combination @charKeys = sort(keys(%charCombHash)); foreach $char (@charKeys){ @jobsOfChar = @{$charCombHash{$char}}; print "\t-- $char: Jobs[", join(",", @jobsOfChar), "]\n"; ## Print every job for the combination foreach my $jobNum (@jobsOfChar) { my @uniq = unique_array(@{$jobs[$jobNum]}); for ($j = 0 ; $j < scalar(@uniq) - 1; ++$j) { if ($uniq[$j] =~ /\.test/) { print "\t\"$uniq[$j]_${char}\",\t\"$uniq[$j+1]_${char}_${jobNum}\""; } else { print "\t\"$uniq[$j]_${char}_${jobNum}\",\t\"$uniq[$j+1]_${char}_${jobNum}\""; } ## Delete last comma if ($char eq $charKeys[$#charKeys] && $jobNum == $jobsOfChar[$#jobsOfChar] && 96 $j+1 == $#uniq) { print "\n"; } else { print ",\n"; } } } } $flagPrecedene = 2; } elsif ($flagPrecedene == 2) { } else { print $line; } ## Start precedencies if ($line =~ /Cheddar_Properties::Task_Precedencies/) { $flagPrecedene = 1; } } close (FILE); sub unique_array { my @array = @_; my %hash = map {$_ => 1} @array; return sort keys %hash; } 97 A.3 Execution Time Analyzer List A. 5 Main.java package executiontimeanalyzer; import java.io.BufferedReader; import java.io.BufferedWriter; import java.io.File; import java.io.FileNotFoundException; import java.io.FileReader; import java.io.FileWriter; import java.io.IOException; import java.io.PrintWriter; import java.util.ArrayList; import java.util.Arrays; import java.util.Collections; import java.util.HashMap; import java.util.Set; import java.util.StringTokenizer; import java.util.TreeSet; import java.util.regex.Pattern; import javax.xml.parsers.ParserConfigurationException; import org.xml.sax.SAXException; import java.util.regex.Matcher; class TimeMatrix { public int _max; public int _min; } public class Test { private static void printMatrix2CSV(HashMap<String, HashMap<String, TimeMatrix>> matrix, HashMap<Set<String>, String> mapJobs2Comb) { // Prepare File File file = new File("src/executiontimeanalyzer/resultMatrix.csv"); PrintWriter pw; try { pw = new PrintWriter(new BufferedWriter(new FileWriter(file))); // Print Header Set<String> keysJob = matrix.keySet(); // [1, 2, 3] for (String keyJob: keysJob) { pw.print("," + keyJob); } pw.println(); // Print Matrix for (String keyJob1: keysJob) { pw.print(keyJob1); for (String keyJob2: keysJob) { pw.print(","); Set<String> set = new TreeSet<String>(Arrays.asList(keyJob1, keyJob2)); if (mapJobs2Comb.containsKey(set)) { String combination = mapJobs2Comb.get(set); if (matrix.get(keyJob1).containsKey(combination)) { pw.print(matrix.get(keyJob1).get(combination)._max + "|" + matrix.get(keyJob1).get(combination)._min); } } else { pw.print("-"); } 98 } pw.println(); } pw.close(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } } private static void printMatrix(HashMap<String,TimeMatrix> map) { Pattern p = Pattern.compile("_([a-z])_([0-9]*)"); HashMap<String, HashMap<String, TimeMatrix>> matrix = new HashMap<String, HashMap<String, TimeMatrix>>(); HashMap<String, Set<String>> mapComb2Jobs = new HashMap<String, Set<String>>(); // a => 1,2 HashMap<Set<String>, String> mapJobs2Comb = new HashMap<Set<String>, String>(); // 1,2 => a // Keys: [***_a_1, ***_a_2, ...] ArrayList<String> keys = new ArrayList<String>(map.keySet()); Collections.sort(keys); // Strip map and get a hash map which contains two keys (Job, Set) for (String key: keys) { // group(1):a , group(2):1 Matcher m = p.matcher(key); if (m.find()) { if (!matrix.containsKey(m.group(2))) { matrix.put(m.group(2), new HashMap<String, TimeMatrix>()); } matrix.get(m.group(2)).put(m.group(1), map.get(key)); mapComb2Jobs.putIfAbsent(m.group(1), new TreeSet<String>()); // a => 1,2 mapComb2Jobs.get(m.group(1)).add(m.group(2)); } } // Convert setMap (a=>1,2) to (1,2=>a) ArrayList<String> keysSet = new ArrayList<String>(mapComb2Jobs.keySet()); Collections.sort(keysSet); for (String keySet: keysSet) { mapJobs2Comb.putIfAbsent(mapComb2Jobs.get(keySet), keySet); } printMatrix2CSV(matrix, mapJobs2Comb); } private static void analyze() { // Analyze the execution time of each job Pattern p_each = Pattern.compile("Job[0-9]+"); // Read a file line by line String line = ""; File csv = new File("src/executiontimeanalyzer/result.csv"); try { BufferedReader br = new BufferedReader(new FileReader(csv)); while ((line = br.readLine()) != null) { Matcher m_each = p_each.matcher(line); if (m_each.find()) { // split by ',' and count the num of "*" StringTokenizer st = new StringTokenizer(line, ","); int timeCnt = 0; String token = null; while (st.hasMoreTokens()) { token = st.nextToken(); if (token.equals("*")) { 99 timeCnt++; } } System.out.println(m_each.group() + ": " + timeCnt); } } br.close(); } catch (FileNotFoundException e) { // File オブジェクト生成時の例外捕捉 e.printStackTrace(); } catch (IOException e) { // BufferedReader オブジェクトのクローズ時の例外捕捉 e.printStackTrace(); } // Analyze matrix HashMap<String,TimeMatrix> map = new HashMap<String,TimeMatrix>(); Pattern p_job = Pattern.compile("_[a-z]_[0-9]*"); String matchstr = ""; // Read a file line by line try { BufferedReader br = new BufferedReader(new FileReader(csv)); while ((line = br.readLine()) != null) { Matcher m_job = p_job.matcher(line); if (m_job.find()) { // If the line contains e.g.(id_14(printersystem.i.p1_read_prs.fax_a_1), // keep the "_a_1" for latter process matchstr = m_job.group(); // And create a map instance for "_a_1" only for the first time if (!map.containsKey(matchstr)) { TimeMatrix time = new TimeMatrix(); time._max = 0; time._min = (int) Double.POSITIVE_INFINITY; map.put(matchstr, time); } } Matcher m_each = p_each.matcher(line); if (m_each.find()) { // split by ',' and count the num of "*" StringTokenizer st = new StringTokenizer(line, ","); int timeCnt = 0; String token = null; while (st.hasMoreTokens()) { token = st.nextToken(); if (token.equals("*")) { timeCnt++; } } // Update max and min value of the Job (e.g. "_a_1") TimeMatrix time = map.get(matchstr); if (time != null && time._max < timeCnt) time._max = timeCnt; if (time != null && timeCnt != 0 && time._min > timeCnt) time._min = timeCnt; } } printMatrix(map); br.close(); } catch (FileNotFoundException e) { // File オブジェクト生成時の例外捕捉 e.printStackTrace(); } catch (IOException e) { 100 // BufferedReader オブジェクトのクローズ時の例外捕捉 e.printStackTrace(); } } private static void printDependency(Dependency dep, TimeUnits timeunits, PrintWriter pw) { for (int m = 0; m < dep._tasks.size() ; m++) { int cnt = 0; Task task = dep._tasks.get(m); pw.print( task.m_id + "(" + task.m_name + ")"); for (int i=0; i < timeunits._timeUnits.length; i++) { TimeUnit unit = timeunits.getTimeUnitFromTaskIdAndEventName(i , task.m_id, ""); if ( unit != null) { pw.print( "," + Integer.toString(cnt)); if (unit.m_eventName.equals("END_OF_TASK_CAPACITY")) { cnt++; } } else { pw.print( ", "); } } pw.println(""); } } private static void printTimeLine(Dependency dep, TimeUnits timeunits, PrintWriter pw) { class Job { int _start; int _end; } ArrayList<Job> jobs = new ArrayList<Job>(); // Source task Task sourceTask = dep._tasks.get(0); for (int i=0; i < timeunits._timeUnits.length; i++) { TimeUnit unit = timeunits.getTimeUnitFromTaskIdAndEventName(i , sourceTask.m_id, "START_OF_TASK_CAPACITY"); if ( unit != null) { Job job = new Job(); job._start = i; jobs.add(job); } } // Sink task Task sinkTask = dep._tasks.get(dep._tasks.size() - 1); int cnt = 0; for (int i=0; i < timeunits._timeUnits.length; i++) { TimeUnit unit = timeunits.getTimeUnitFromTaskIdAndEventName(i , sinkTask.m_id, "END_OF_TASK_CAPACITY"); if ( unit != null) { Job job = jobs.get(cnt++); job._end = i; } } for(int i=0;i<jobs.size();i++){ pw.print("Job" + Integer.toString(i) + ","); for (int j=0; j<jobs.get(i)._start; j++) { pw.print(","); } for (int j=jobs.get(i)._start; j<=jobs.get(i)._end; j++) { pw.print("*,"); } pw.println(); 101 } } public static void main(String[] args) throws SAXException, IOException, ParserConfigurationException { ArrayList<Dependency> dependencyList; // MyXML xml = new MyXML("default_event_table_file.xml"); // Read XML file of Chedder project to get dependency XmlReaderChedder reader = new XmlReaderChedder(); reader.domRead("src/executiontimeanalyzer/thesis.xml"); dependencyList = reader.getM_dependencyList(); // Debug System.out.println("------------------"); System.out.println("num of dependencies: " + dependencyList.size()); // Read XML file of Cheddar event table XmlReaderEvent readerEvent = new XmlReaderEvent(); readerEvent.domRead("src/executiontimeanalyzer/thesis_event.xml"); TimeUnits timeunits = readerEvent.get_timeUnits(); // Prepare File File file = new File("src/executiontimeanalyzer/result.csv"); PrintWriter pw = new PrintWriter(new BufferedWriter(new FileWriter(file))); // PrintWriter pw = new PrintWriter(System.out); // Print Header pw.print("dependency"); for (int i=0; i < timeunits._timeUnits.length; i++) { pw.print("," + Integer.toString(i)); } pw.println(); pw.println(); // Visualize timeline from dependency list and timeunits for (int l = 0 ; l < dependencyList.size() ; l++) { Dependency dep = dependencyList.get(l); printDependency(dep, timeunits, pw); printTimeLine(dep, timeunits, pw); pw.println(""); } pw.close(); // Analyze csv analyze(); } } 102 List A. 6 Task.java package executiontimeanalyzer; public class Task { String m_name; String m_id; Task(String name, String id) { this.m_name = name; this.m_id = id; } } List A. 7 TimeUnit.java package executiontimeanalyzer; // Struct class public class TimeUnit { public String m_time; public String m_eventName; public String m_taskId; public TimeUnit(String time, String eventName, String taskId) { m_time = time; m_eventName = eventName; m_taskId = taskId; } public void print() { System.out.println(m_time + m_eventName + m_taskId); } } List A. 8 TimeUnitComparator package executiontimeanalyzer; import java.util.ArrayList; import java.util.Comparator; public class TimeUnitComparator implements Comparator<ArrayList<TimeUnit>> { @Override public int compare(ArrayList<TimeUnit> o1, ArrayList<TimeUnit> o2) { int time1 = Integer.parseInt(o1.get(0).m_time.trim()); int time2 = Integer.parseInt(o2.get(0).m_time.trim()); if (time1 > time2) { return 1; } else if (time1 == time2) { return 0; } else { return -1; } } } 103 List A. 9 TimeUnits.java package executiontimeanalyzer; import java.util.ArrayList; import java.util.Collections; public class TimeUnits { public TimeUnitList[] _timeUnits; private int _numArray = 0; public TimeUnits() { _timeUnits = new TimeUnitList[_numArray]; } public void changeNumOfArray(int num) { if (_numArray < num) { _numArray = num; TimeUnitList[] timeUnitsNew = new TimeUnitList[_numArray]; System.arraycopy(_timeUnits, 0, timeUnitsNew, 0, _timeUnits.length); _timeUnits = timeUnitsNew; } } public void addUnit(TimeUnit unit) { int timeunit = Integer.parseInt(unit.m_time.trim()); if (_numArray <= timeunit) { System.out.println("Error! timeunit[" + timeunit + "] overlimit"); } if (_timeUnits[timeunit] == null) { TimeUnitList units = new TimeUnitList(); units.add(unit); _timeUnits[timeunit] = units; } else { _timeUnits[timeunit].add(unit); } } public void sort() { // Collections.sort(m_timeUnits, new TimeUnitComparator()); } public TimeUnit getTimeUnitFromTaskIdAndEventName(int index, String taskId, String eventName) { if (_timeUnits[index] == null) { } TimeUnitList ith_timeunit = _timeUnits[index]; if (ith_timeunit != null) { for (int i=0; i < ith_timeunit.size(); i++) { if (ith_timeunit.get(i).m_taskId.equals(taskId)) { if (eventName.equals("") || ith_timeunit.get(i).m_eventName.equals(eventName) ) { return ith_timeunit.get(i); } } } } return null; } public void test() { TimeUnit a = new TimeUnit("0", "hoge", "0"); TimeUnit b = new TimeUnit("0", "foo", "1"); TimeUnit c = new TimeUnit("1", "hoge", "0"); TimeUnit d = new TimeUnit("2", "hoge", "0"); this.addUnit(a); 104 this.addUnit(b); this.addUnit(c); this.addUnit(d); this.print(); } public void print() { for (int i=0; i < _numArray; i++) { TimeUnitList units = _timeUnits[i]; if (units != null) { for (int j=0; j < units.size(); j++) { TimeUnit unit = units.get(j); unit.print(); } } } } } List A. 10 XmlReaderCheddar.java package executiontimeanalyzer; import java.io.IOException; import java.util.ArrayList; import java.util.Arrays; import java.util.HashMap; import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.parsers.ParserConfigurationException; import org.w3c.dom.Document; import org.w3c.dom.Element; import org.w3c.dom.Node; import org.w3c.dom.NodeList; import org.xml.sax.SAXException; public class XmlReaderChedder { private ArrayList<Dependency> m_dependencyList; public ArrayList<Dependency> getM_dependencyList() { return m_dependencyList; } public XmlReaderChedder() { m_dependencyList = new ArrayList<Dependency>(); } // Use if parent has only one child private Element getChildFromParent(String childName, Element parent) { NodeList children = parent.getChildNodes(); for(int i=0; i < children.getLength(); i++) { Node node = children.item(i); if (node.getNodeType() == Node.ELEMENT_NODE) { Element element = (Element)node; if (element.getNodeName().equals(childName)) { return element; } } } return null; } 105 public void domRead(String file) throws SAXException, IOException, ParserConfigurationException { DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); DocumentBuilder documentBuilder = factory.newDocumentBuilder(); Document document = documentBuilder.parse(file); // root node Element root = document.getDocumentElement(); // tasks node Element tasks = getChildFromParent("tasks", root); NodeList tasksChildren = tasks.getChildNodes(); HashMap<String, String> map = new HashMap<String, String>(); for (int i=0; i < tasksChildren.getLength(); i++) { Node task = tasksChildren.item(i); if (task.getNodeType() == Node.ELEMENT_NODE) { Element taskElement = (Element)task; String id = taskElement.getAttribute("id"); // children nodes of task NodeList taskChildren = task.getChildNodes(); for (int k=0; k < taskChildren.getLength(); k++) { Node child = taskChildren.item(k); if (child.getNodeName().equals("name")) { map.put(id, child.getTextContent()); break; } } } } for (String key : map.keySet()) { System.out.println(key + " " + map.get(key)); } System.out.println("------------------"); // dependencies node Element dependencies = getChildFromParent("dependencies", root); NodeList depsChildren = dependencies.getChildNodes(); System.out.println("Num of dependencies ：" + depsChildren.getLength()); for (int j=0; j < depsChildren.getLength(); j++) { Node dependency = depsChildren.item(j); // children nodes of dependency NodeList depChildren = dependency.getChildNodes(); Task sink = null; Task src = null; for (int k=0; k < depChildren.getLength(); k++) { Node child = depChildren.item(k); if (child.getNodeType() == Node.ELEMENT_NODE) { Element depElement = (Element)child; if (depElement.getNodeName().equals("precedence_sink")) { String id = depElement.getAttribute("ref"); sink = new Task(map.get(id), id); } else if (depElement.getNodeName().equals("precedence_source")) { String id = depElement.getAttribute("ref"); src = new Task(map.get(id), id); } } } if (sink != null) { boolean flagNoSrc = true; for (int i = 0; i < m_dependencyList.size() ; i++) { Dependency dep = m_dependencyList.get(i); if (dep.hasSink(src)) { dep.addDependency(sink); flagNoSrc = false; } } // if src isn't in current list, add the src to list. 106 if (flagNoSrc) { Dependency dep = new Dependency(src, sink); m_dependencyList.add(dep); } } } } } List A. 11 XmlReaderEvent.java package executiontimeanalyzer; import java.io.IOException; import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.parsers.ParserConfigurationException; import org.w3c.dom.Document; import org.w3c.dom.Element; import org.w3c.dom.Node; import org.w3c.dom.NodeList; import org.xml.sax.SAXException; public class XmlReaderEvent { private TimeUnits _timeUnits; public TimeUnits get_timeUnits() { return _timeUnits; } public XmlReaderEvent() { _timeUnits = new TimeUnits(); } private void changeNumOfTimeUnits(NodeList units) { int maxTimeUnit = 0; for (int i=0; i < units.getLength(); i++) { Element unit = (Element)units.item(i); int tmpValue = Integer.parseInt(unit.getLastChild().getNodeValue().trim()); maxTimeUnit = (maxTimeUnit < tmpValue) ? tmpValue : maxTimeUnit; } _timeUnits.changeNumOfArray(maxTimeUnit + 1); // 0 origin } /** * <time_unit>1 </time_unit> <time_unit_event> <type_of_event>RUNNING_TASK</type_of_event> <running_core>core_unit_printersystem.i.intel_cpu0</running_core> <running_task ref="id_10"> </running_task> <current_priority>2</current_priority> </time_unit_event> * @param result */ private void createTimeUnits(Node result) { if (result.getNodeType() == Node.ELEMENT_NODE) { Element element = (Element)result; NodeList units = element.getElementsByTagName("time_unit"); changeNumOfTimeUnits(units); NodeList events = element.getElementsByTagName("time_unit_event"); // System.out.println("size ：" + units.getLength()); for (int i=0; i < units.getLength() || i < events.getLength(); i++) { 107 // <time_unit> Element unit = (Element)units.item(i); String timeUnitValue = unit.getFirstChild().getNodeValue(); // <time_unit_event> Element event = (Element)events.item(i); NodeList types = event.getElementsByTagName("type_of_event"); Element type = (Element)types.item(0); String typeValue = type.getFirstChild().getNodeValue(); if (type != null) { Element task; if (typeValue.equals("RUNNING_TASK")) { task = (Element)event.getElementsByTagName("running_task").item(0); } else if (typeValue.equals("START_OF_TASK_CAPACITY")) { task = (Element)event.getElementsByTagName("start_task").item(0); } else if (typeValue.equals("END_OF_TASK_CAPACITY")) { task = (Element)event.getElementsByTagName("end_task").item(0); } else { task = null; } if (task != null) { TimeUnit timeunit = new TimeUnit( timeUnitValue /* time unit */ , typeValue /* event name */ , task.getAttribute("ref") /* task id */); _timeUnits.addUnit(timeunit); } } } } } public void domRead(String file) throws SAXException, IOException, ParserConfigurationException { DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); DocumentBuilder documentBuilder = factory.newDocumentBuilder(); Document document = documentBuilder.parse(file); // root node Element root = document.getDocumentElement(); NodeList rootChildren = root.getElementsByTagName("scheduling_result"); for (int i=0; i < rootChildren.getLength(); i++) { Node node = rootChildren.item(i); if (node.getNodeType() == Node.ELEMENT_NODE) { Element element = (Element)node; // Result node NodeList results = element.getElementsByTagName("result"); createTimeUnits(results.item(0)); } } } public void print() { _timeUnits.print(); } } 108 A.4 OSATE analysis plugin List A. 12 package org.osate.xtext.aadl2.properties.util.GetProperties.java (new functions) private enum SearchDirection { PROCEEDING, FOLLOWING; } private static double getPeriodFromDependence(final NamedElement ne, SearchDirection mode, int searchNum) { NamedElement dep; ArrayList<NamedElement> deps; double period = 0; // Get a port adjacent to ne. If no more adjacent, return 0 deps = getDependentElements(ne, mode); if (!deps.isEmpty()){ for (int i = 0 ; i < deps.size() ; i++) { double tmp = 0; dep = deps.get(i); // Get period of the port if (dep instanceof InstanceObject) { tmp = GetProperties.getPeriodInSeconds(((InstanceObject) dep).getContainingComponentInstance(), 0); } else { tmp = GetProperties.getPeriodInSeconds(dep.getContainingClassifier(), 0); } // If the port is in asynchronous task, then go further if (tmp == 0) { // Recursive call tmp = getPeriodFromDependence(dep, mode, searchNum + 1); } // First time, period = tmp, // Later, period is divided by the number of tmps (message rate will be doubled) period = (period == 0) ? tmp : tmp / ((tmp/period) + 1) ; // If the dependent port is directly found in system, then return immediately if (period != 0 && searchNum == 0) break; // If the dependent port is found via async task (case 3 or 4), then go further } return period; } return 0; } private static ArrayList<NamedElement> getDependentElements(final NamedElement ne, SearchDirection mode) { ArrayList<NamedElement> elements = new ArrayList<NamedElement>(); /** * case 1. a following port in system's connections is in a synchronous task * (Async(this) -> ... -> Sync) * case 2. a proceeding port in system's connection is in a synchronous task * (Sync -> ... -> Async(this)) **/ // Get connections with ne in system EList<ConnectionInstance> cons = (mode == SearchDirection.FOLLOWING) ? 109 ((ConnectionInstanceEnd)ne).getSrcConnectionInstances() : ((ConnectionInstanceEnd)ne).getDstConnectionInstances() ; if (!cons.isEmpty()) { Iterator<ConnectionInstance> ite = cons.iterator(); while (ite.hasNext()) { ConnectionInstance ins = ite.next(); ConnectionInstanceEnd end = (mode == SearchDirection.FOLLOWING) ? ins.getDestination() : ins.getSource(); if (end != null) { elements.add( (NamedElement)end ); } } return elements; } else { /** * case 3. a proceeding port is in a synchronous task via a flow in async task * (Sync -> Async (flow: in -> out) -> Async(this)) * case 4. a following port is in a synchronous task via a flow in async task * (Async(this) -> Async (flow: in -> out) -> Sync) **/ // Get flows with ne in each process, if no more flows, then return nul EList<FlowSpecificationInstance> flowSpec = (mode == SearchDirection.FOLLOWING) ? ((FeatureInstance) ne).getSrcFlowSpecs() : ((FeatureInstance) ne).getDstFlowSpecs() ; if (!flowSpec.isEmpty()) { Iterator<FlowSpecificationInstance> ite = flowSpec.iterator(); while (ite.hasNext()) { FlowSpecificationInstance ins = ite.next(); FeatureInstance port = (mode == SearchDirection.FOLLOWING) ? ins.getDestination() : ins.getSource(); if (port != null) elements.add( (NamedElement)port ); } return elements; } } return null; } 110 A.5 New Bus Load analyzer List A. 13 package org.osate.xtext.aadl2.properties.util.GetProperties.java (only diff) A.6 New Resource Allocation analyzer List A. 14 package org.osate.xtext.aadl2.properties.util.GetProperties.java (only diff)

Abstract (if available)

Abstract Modern embedded software is more complex than before, therefore an early analysis of the software architecture is needed to reduce the development cost and risks. However, precedent aperiodic dependent tasks, which are widely used in embedded software, make the architectural analyses difficult because of their intricate interconnections. In more detail, each precedent dependent aperiodic task runs concurrently with other tasks as well as having precedent constraints with the others: in other words, it starts at different time depending on the other tasks’ end time. This makes analyzing software architectures difficult. ❧ To address the challenge, this thesis provides new tools that can analyze precedent aperiodic dependent tasks, while accepting existing architectural models so that developers do not need to prepare a new model or can reuse the model for other analyses. Specifically, this thesis focuses on the performance, scalability, and portability analyses, which are often needed in embedded systems. I have evaluated the new tools by using an evaluation platform, which I modeled by utilizing an existing architectural model, and proved that these tools could analyze software architectures with precedent dependent aperiodic tasks, which had not been able to be done by existing tools.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Proactive detection of higher-order software design conflicts

PDF

Architectural evolution and decay in software systems

PDF

Architecture and application of an autonomous robotic software engineering technology testbed (SETT)

PDF

A reference architecture for integrated self‐adaptive software environments

PDF

Techniques for methodically exploring software development alternatives

PDF

Constraint-based program analysis for concurrent software

PDF

Automated repair of presentation failures in Web applications using search-based techniques

PDF

Side-channel security enabled by program analysis and synthesis

PDF

Detecting SQL antipatterns in mobile applications

PDF

Detecting anomalies in event-based systems through static analysis

PDF

Automated repair of layout accessibility issues in mobile applications

PDF

Energy optimization of mobile applications

PDF

Utilizing user feedback to assist software developers to better use mobile ads in apps

PDF

A unified framework for studying architectural decay of software systems

PDF

Domain-based effort distribution model for software cost estimation

PDF

Design-time software quality modeling and analysis of distributed software-intensive systems

PDF

Calculating architectural reliability via modeling and analysis

PDF

A model for estimating schedule acceleration in agile software development projects

PDF

A user-centric approach for improving a distributed software system's deployment architecture

PDF

Hardware and software techniques for irregular parallelism

Asset Metadata

Creator Tomita, Tatsuhiko (author)

Core Title Analysis of embedded software architecture with precedent dependent aperiodic tasks

School Viterbi School of Engineering

Degree Master of Science

Degree Program Computer Science (Software Engineering)

Publication Date 04/17/2017

Defense Date 03/20/2017

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag AADL,aperiodic tasks,Cheddar,embedded software,OAI-PMH Harvest,OSATE,precedent dependent tasks,software analysis,Software Architecture

Language English

Contributor Electronically uploaded by the author (provenance)

Advisor Medvidović, Nenad (committee chair), Chao, Wang (committee member), Halfond, William G. J. (committee member)

Creator Email tomita.tatsuhiko@gmail.com,ttomita@usc.edu

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c40-354872

Unique identifier UC11255856

Identifier etd-TomitaTats-5190.pdf (filename),usctheses-c40-354872 (legacy record id)

Legacy Identifier etd-TomitaTats-5190.pdf

Dmrecord 354872

Document Type Thesis

Rights Tomita, Tatsuhiko

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA