Early Embedded Software Design Space Exploration Using UML-based Estimation

Transcription

1 Early Embedded Software Design Space Exploration Using UML-based Estimation Marcio F. da S. Oliveira 1 Lisane B. de Brisolara 1 Luigi Carro 1,2 Flávio R. Wagner 1 1 Computer Science Institute Federal University of Rio Grande do Sul PO Box 15064, Porto Alegre, Brazil {mfsoliveira, lisane, flavio}@inf.ufrgs.br 2 Electrical Engineering Department Federal University of Rio Grande do Sul Av. Osvaldo Aranha, 103, Porto Alegre - Brazil carro@ece.ufrgs.br Abstract In order to quickly implement an embedded system that is mainly based on software, two orthogonal approaches have been proposed: Platform-based Design, which maximizes the reuse of components; and Model Driven Development, which rises the abstraction level by using object-oriented concepts and UML. However, with this increasing of the abstraction level, software engineers do not have an exact idea of the impact of their modeling decisions on important issues such as performance, energy, and memory footprint for a given platform. In our approach, analytical estimation of data and program memory, performance, and energy are obtained directly from UML models. Experimental results show a very small estimation error when software components are reused and their costs on the target platform are already known. Real-life applications are modeled in different ways and demonstrate the effectiveness of the estimates in an early design space exploration, allowing the designer to quickly compare different modeling solutions, with estimation errors as low as 5%. 1 Introduction Embedded everywhere is an expression that is getting materialized with the new generation of computer systems. This is a reality in sectors such as automotive, airplanes, telecommunication, consumer electronics, and medical devices. Such systems are increasingly required to operate in real-time and rely on embedded hardware and software. This situation makes the design of embedded systems an ever-growing challenge. Therefore, several design methodologies have been proposed to address the problem of modeling and designing complex real-time embedded systems, satisfying tight performance and cost constraints. Platform-Based Design (PBD) [1] is a successful strategy that implements a meet-in-the-middle strategy to maximize the reuse of pre-designed components and provides a variety of abstraction levels, integrating the development effort of different design teams and achieving the best customisation of the design according to the system requirements. PBD environments must provide a rich and pre-characterized library of software and hardware components, allowing a designer to rapidly assemble a system. Furthermore, this pre-characterized library reduces dramatically the verification phase and the uncertainty about the system properties, thus improving the design productivity. Simultaneously to PBD, the use of higher abstraction levels has been adopted in order to handle the increasing complexity. In this context, UML [2] has emerged as a language to document and specify embedded systems, and the Model Driven Architecture (MDA) [3] is promoted as a new approach to develop embedded system in a modelcentric way. The MDA approach provides mechanisms to improve the portability, interoperability, maintainability, and reusability of models. MDA relies on guided model transformations starting from high-level models until detailed and platform specific models are obtained. Moving the development focus from code to model suggests the support to a fast design space exploration in the early design steps, where the design effort is now concentrated and modeling decisions can lead to substantially superior improvements. However, at this level software engineers do not have an exact idea of the impact of their decisions on essential issues such as performance, energy, and memory footprint for a given embedded platform. It would be desirable that the designer could evaluate the candidate solutions as early as possible, using the same abstraction level as in the system specification. This work proposes early software design space exploration using an UML-based estimation methodology, where estimates for performance, energy consumption, and memory footprint can be used as a guide to select the most adequate modeling solution. An estimation tool called SPEU (System Properties Estimation with UML) has been developed to implement this methodology. Since estimates are

2 obtained by an analytical method and do not rely on simulation, design space exploration can be quickly performed. Experimental results show that, by using those estimates, the designer can effectively analyze the impact of alternative UML modeling decisions, with a very reasonable accuracy regarding the final system implementation, thus allowing true UML-based design space exploration. Furthermore, results show that, in a platform-based approach, the reuse of information on the costs of pre-defined components leads to substantially better estimates from the UML models. The remaining of this paper is organized as follows. Section 2 discusses related work. The proposed estimation methodology and tool are presented in Section 3. Section 4 illustrates a design space exploration scenario, where four alternative modeling solutions for the same application are compared and estimates are used to select the most adequate solution. Section 5 draws main conclusions and introduces future work. 2 Related work Due to the increasing importance of software development in embedded systems design, several works have discussed various aspects of automatic embedded software modeling, development, and estimation. Li and Malik [4] propose a method to obtain the number of executions for basic blocks of the application code using linear equations. A linear programming method can be used to maximize these equations and obtain the worst-case execution time. However, if only static information is available, relatively large errors in the performance analysis might be expected. Nevertheless, the relative errors allow effective design space exploration. The SPADE methodology for design space exploration of heterogeneous signal processing architectures [5] distinguishes between application and architecture models and uses trace-driven simulation techniques for co-simulation. SPADE yields performance for architecture blocks out of a library of generic building blocks, e.g. in form of processor utilization or the number of read/write stalls on the I/O ports. SPADE raises the abstraction level as our proposal, but the designer must use C++ and an API to specify the system and perform simulations to obtain the estimates. In [6], Smith et al. propose a UML-based quantitative approach to evaluate software systems. This approach focuses on the system s use cases and associated critical scenarios. To build the execution model, a sequence diagram representing a key scenario is translated into an execution graph. Software and computer resource requirements are added to this graph, and the model is solved. A similar approach for performance analysis is presented in [7], which uses the UML-SPT [8] profile. In this approach, desired values for performance measures, such as response time, are manually added to the model. A performance model is then derived, from which the performance analyses are computed by simulation or by analytical techniques. However, performance-related information has to be explicitly specified in UML diagrams. Chen et al. [9] propose a design methodology that uses a UML Platform profile to model both application and platform. In this methodology, the analysis and synthesis tools available in the Metropolis framework are used to support design space exploration. This work, however, is based on a very intrusive methodology, enforcing the designer to use a very particular modeling approach. It also relies on simulation to obtain performance estimations. These previous approaches rely on simulation and lowlevel information to perform design space exploration. They lack an efficient estimation method to obtain performance information such as number of instructions or execution time. In previous UML-based approaches, this information must be manually specified in the models. Moreover, these approaches do not consider important requirements for embedded systems, like memory size and energy consumption. In this context, we propose a multi-variable estimation methodology, allowing a designer to check different system requirements to perform design space exploration. Besides performance, also energy and memory footprint can be estimated. Moreover, our approach is not based on simulation, thus requiring less time to obtain estimates and less information about the system implementation, when compared to other approaches. 3 UML-based estimation methodology We propose a design space exploration methodology for embedded software design, which is based on an analytical UML-based estimation approach that allows the estimation of system properties by mapping the application model into a given pre-characterized platform. The estimation support at UML level requires the definition of three aspects: i) the UML modeling rules; ii) the platform repository model that stores information about reused components; iii) the estimation method that allows the evaluation of high-level models. An estimation tool called SPEU (System Properties Estimation with UML) has been developed to support this methodology. 3.1 Modeling rules UML 2.0 is used to specify the application under development, following the designer s favorite UML modeling

3 methodology. However, some extensions are needed to add design information in order to allow the automatic estimation without compromising the abstraction level. The most important UML diagrams used in our approach are Use Cases, Sequence, Class, and Deployment Diagrams. These diagrams must be decorated with stereotypes and tagged values to increase the information about the model. The application structural model is specified in the Class Diagram. In this diagram, besides the definition of the application classes, the designer must also identify multiplicity for vectors, matrix attributes, and expected multiplicity for class instances. Access methods, such as getter and setter ones, are usually employed in the object-oriented programming approach. To identify these methods the get or set prefix must precede the class field name that has its method invoked. The suffix Content must be used, indicating that the method is accessing the structure contents, like vector or matrix positions. A distinction between these types of methods is important because they have different costs. The application behavioral model is based on Sequence Diagrams and must specify iteration and conditional execution, interaction between objects, and dependences between execution scenarios. Additionally, the number of loop iterations can be specified to improve the estimation. The services required by the application from the platform resource model must be specified in the Sequence Diagram. Figure 1 illustrates how a designer can specify the required services, using a Sequence Diagram for the wheelchair movement actuating scenario. The designer can use UML-SPT stereotypes and platform specific objects, such as a scheduler, as emphasized by the dotted rectangle in Figure 1. Another way to specify required services is an explicit call of a service for a reserved object called platforms, such as the math library services idiv, atan, and sqrt. The invoked method must have the same signature as the service contained in the platform resource model, from which the estimation tool will get the service costs. This form of specification is emphasized by the continuous rectangles in Figure 1. These techniques provide a good way of hiding the platform details from the designer and identifying the reused platform components. Using the Deployment Diagram, the designer must map the software components to available processing units. This mapping is used to identify the processor, its available services, and the costs associated with these services, including the instruction set. Figure 1: Joystick interface reading sequence diagram for movement actuating scenario. 3.2 Platform repository concepts In a PBD context a large number of hardware and software components are provided to be reused during the system development. To evaluate different solutions at a high abstraction level, the reused components must be precharacterized in terms of performance, energy, memory footprint, and others. In our methodology, this information is stored in a platform repository, whose data model is based on the General Resource Model from UML-SPT. Currently, the platform repository contains information on processing units (different versions of a Java microcontroller [10]), scheduling and timer services, a real-time API [11] implemented on top of the Java microcontroller, and a math library. As additional architectural aspects, information is stored about the supported data types and the instruction set, such as size, number of execution cycles, and energy consumption for each instruction. Program and data memory allocation aspects are also considered, including dynamic frame allocation, reserved memory, data type, and method allocation rules. In order to add new IP resources to the platform repository, the IP component provider must attach this architectural information to his/her IPs. After the repository is populated with adequate information on the platform components, the designer just needs to map the application into the platform model. This mapping allows one to evaluate a general application model (Platform Independent Model - PIM), when mapped to a specific system platform that corresponds to the Platform Specific Model (PSM), according to the MDA approach.

4 3.3 Estimation process Our approach allows the estimation of performance, energy consumption, and data and program memory size. These system properties are the basis for other requirement analyses, such as quality of service (QoS) assessment on issues like communication, schedulability, and resource usage. After these estimates, other deeper analyses can be performed, as suggested in [7]. Using a similar approach to [6], the estimation focuses on use cases and scenarios that describe them, since they provide the basics for the object-oriented methodology. The estimation methodology flow is illustrated in Figure 2 and described in the sequence. Fig. 2: Estimation methodology flow. 1. Select use cases and scenarios: Use cases and scenarios that are critical to meet the application requirements are identified. Therefore, only a subset of Sequence Diagrams will be used in the estimation process. This step is based on the designer s experience and must be a risk-driven process. 2. Increase model information: If needed, the designer can add more information about the system, such as the number of executions for a scenario, the best and worst-case scenarios, or loop bounds. 3. Application Analysis: After the two previous manual steps, the application model is automatically analyzed in terms of structure and behavior. Structural analysis is performed using class diagrams, such that information about classes, objects, number of methods, and other are extracted. The behavioural analysis is based on the sequence diagrams and captures information about interaction between objects, dependences between scenarios, loop and conditional executions, and references to reused components and its services. By the end of this analysis, a platform-independent signature is generated, containing information on structure and a pseudo-trace. The reused platform services are also included in the pseudo-trace as symbolic instructions (high-level, platform-independent instructions), and their costs are extracted from the platform repository after the application-mapping step. The pseudo-trace, expressed in an XML format, corresponds to the model behavior and is described as an oriented graph, where each node is a symbolic instruction and edges indicate the next symbolic instructions. Before the estimation process, the symbolic instruction set provided by the SPEU tool must be mapped to the real instruction set of processors that are available in the platform repository. This mapping is stored in another repository, to keep the platform repository independent from the SPEU tool. For processors available in our platform repository, the SPEU tool already contains this mapping. Other symbolic-real instruction mappings can be provided by the SPEU developers, by a platform provider, or by the designer, with help from the SPEU tool. 4. Application Mapping: The application signature must be mapped to platform components in order that cost estimates may be obtained. This mapping uses Deployment Diagrams and references to reused components indicated in the Sequence Diagrams. After the mapping, a new signature is generated. It contains the costs of symbolic instructions, extracted from their mapping into a processor instruction set. 5. Estimation: The estimates of memory, performance, and energy are computed for each scenario. The SPEU tool can operate in two modes, depending whether the designer knows the best and worst-case (BC and WC) execution paths or not. In the first case, the scenarios are explicitly modeled following the BC and WC, so the SPEU estimates just add symbolic instruction costs for memory, performance, and energy. In the second mode, the SPEU tool can estimate the BC and WC scenarios by handling the estimation as an optimization problem. The tool uses an ILP (Integer Linear Programming) formulation to analyze the pseudo-trace (instruction flow graph), as proposed in [7]. This estimation is static, and simulation is not required. Using ILP, SPEU estimates performance and energy. The data memory is estimated after the results of ILP, when BC and WC execution paths are already known. To estimate the data memory, all preallocated filed and static objects are analyzed in the application s Class Diagram and in the reused services. After that, the maximum dynamic allocation cost for stacking of Java frames is extracted from the pseudo-trace and added to the pre-allocated data memory values. In both SPEU modes, the program memory is estimated by listing the instructions for each method and service (but avoiding the inclusion of repeated methods). After that, the program memory costs for all instructions and services are added. 6. Feedback: The estimation results can be annotated back into the model and used to explore other candidate solutions.

5 4 Case study: Early SW Design Exploration This section presents a design space exploration scenario, where four alternative modeling solutions for the same application are proposed. After that, the estimation results extracted from the UML models are used to compare and select the most adequate solution. Moreover, every candidate solution was implemented on the target platform, and the values estimated by SPEU were compared to the results obtained through cycle-accurate simulation using a power simulator [12]. For each solution, a synthesis tool [10] was used to obtain the hardware description and the Java byte codes for the application. The case study consists of a real-time embedded system dedicated to the automation and control of an intelligent wheelchair that helps people with special needs. This wheelchair has several functions, such as movement control, collision avoidance, navigation, target pursuit, battery control, system supervision, task scheduling, and automatic movement. This experiment will focus only on the wheelchair movement control use case, which is essential to the system and incorporates critical hard real-time constraints. To implement the movement control, several components provided by the platform can be reused, such as a mathematical library to solve the control equations, a realtime Java API, and RTOS components [11]. Consequently, the platform aspects considered in the estimation methodology also take into account costs related to the real-time scheduler. Furthermore, the application was mapped to only one processing unit, a multi-cycle-rtc FemtoJava [11], in order to concentrate the experiments on the design space that can be explored when a designer develops different UML modeling solutions. The movement controller use case has two responsibilities: sensing the movement, thus getting information about the speed and angle, and actuating in the wheelchair motors. To obtain the values for speed and angle, two sensors are used, one for each wheel. The sensoring function reads the values from the sensors and converts them into speed and angle, which are required for other components such as the display output interface and the navigation system. To actuate, the system receives values from a joystick or a vocal command interface and writes the values to the actuator interface. Values read from the joystick can be directly written to the actuator; or they may be converted into a standardized representation in order to use the movement controller component together with a standard input interface. These two alternatives will be explored in different modeling solutions. Another point to be explored is the model flexibility in terms of number of threads, object encapsulation, and interaction between objects. The first modeling solution converts the joystick values into the standard representation. This solution uses finegrain capsules, i.e., the system responsibilities are distributed among a larger number of threads and objects. This modeling approach is flexible and allows high software reuse. In this way, it is easy to extend and insert new components into the system. This solution uses four threads, and each one was modeled as a sequence diagram. Two threads implement the movement actuating function, while the other ones implement the movement sensoring function. The values obtained by SPEU for the movement control use case, according to the first modeling solution, are presented in Table 1. The table also shows exact values obtained after synthesis and cycle-accurate simulation, as well as the relative error of the estimated values against the exact ones. In this table, memory values are represented in bytes and performance ones in cycles. Energy consumption is evaluated in gate switching activity, as in [12,13]. Both performance and energy were estimated in terms of BC and WC executions. First Solution Property SPEU Exact Error (%) Program memory 5,460 6, BC Data memory WC Data memory BC Performance 27,383 28,588-04,21 WC Performance 40,106 41, BC Energy 38,723,290 40,569, WC Energy 56,477,333 58,863, Table 1: Estimation results for the first solution. An error of 12.37% in the estimated data memory size was found, because the dynamic memory allocation for operations in the stack memory is not estimated for all instructions. The BC and WC estimates for data memory were the same, since the maximum value of dynamic allocation was found in the scheduler that must be considered in both cases. This happened also for the other modeling solutions. Besides, there is an error of 12.61% in the estimated value for program memory, because in some cases an algorithm can be hidden in the method body. This occurs when the designer does not express the contents of a method body, which can be a complex algorithm that cannot be easily expressed in UML Sequence Diagrams. This also occurs for some instructions that implement a method but cannot be extracted from the UML diagrams, such assignments and arithmetic instructions. However, it is important to highlight that the behavior that is more relevant for the performance estimation, such as method invocations, memory accesses, conditional executions, interaction executions, and reused services, are all captured. As a consequence of the errors on the number of executed instructions, there are errors also in the estimated values for performance and energy.

6 These results demonstrate that at a very high abstraction level it is already possible to estimate the system properties with an error less than 15%. The estimates are highly correlated to the results obtained in the final implementation. Improvements in the estimates can be achieved when more pre-characterized components are reused in the application, since the costs of their functions are already known. Since estimates do not depend on simulation, they support a very fast design space exploration at a very high abstraction level, with an acceptable accuracy. The additional modeling solutions demonstrate that there is a very large design space to be explored, when the designer considers different alternatives for encapsulating functions into threads and deciding on the number of threads and on the way they interact. The estimation methodology supports a very fast and reasonably accurate exploration of the impact of these alternatives on the final system implementation. The second modeling solution was developed as a lightweight one. It uses only static objects and does not use threads to implement the movement control. Instead, it directly uses the interrupt control system. The movementactuating scenario in the second solution has a lower encapsulation of functions than the first solution. The class Navigator has been removed, and its responsibilities were incorporated into the main class MovementController. The SensorDriver class is now responsible for reading both wheel sensors, while in the first solution we had two objects of the same class, one for each wheel, so that the number of objects has been reduced. Moreover, the second solution also converts the joystick values into a standard representation. Table 2 shows the estimated (using SPEU) and exact values (after synthesis and cycle-accurate simulation) obtained for the second solution, measured as a percentage of the values from the first solution. The second solution is better in all six cost metrics, by large differences. Although the second solution is faster, saves more energy, and presents lower memory footprint, it is very limited in terms of flexibility, due to its static design and its low degree of encapsulation. As the first solution has higher costs and the second one is static and inflexible, we designed a third solution to obtain intermediate results in terms of performance and flexibility. This third solution uses the same number of classes and objects as the first one. However, it uses only one thread for executing both the actuating and sensoring functions. A reduced encapsulation allows some objects to directly interact with other ones, as in the second solution. We also kept the conversion of the joystick values into a standard representation. Second x First Solution Property Estimated Exact Program memory % % BC Data memory % % WC Data memory % % BC Performance % % WC Performance % % BC Energy % % WC Energy % % Table 2: Results for the second solution. We obtained better performance results than in the first solution, due to the smaller number of threads and objects, thus reducing the platform scheduling overhead and the interaction between objects. But the second solution is still much better than the third one, due to the scheduling overhead and dynamic memory allocation, as shown in Table 3. However, in the third solution new components can be deployed more easily than in the second one, because it uses dynamic allocation of objects and a scheduler, making it easier to expand the system or to change the components configuration. Third x First Third x Second Property Estimated Exact Estimated Exact Program memory % % % % BC Data memory % % 22.53% 15.86% WC Data memory % % 22.53% 15.86% BC Performance % % % % WC Performance % % 47.60% 50.27% BC Energy % % % % WC Energy % % 49.81% 50.40% Table 3: Results for the third solution. In this context, the fourth solution was designed using an architecture that is similar to the third one. However, differently of the three previous alternatives, joystick values are not converted into a standard representation in the actuating scenario. The fourth solution presents similar encapsulation as the third solution, with only one thread, and the same extended SensorDrive class as in the second solution. Moreover, in the movement sensoring scenario a more efficient algorithm was used, avoiding the computation of the angle and speed values when this is not required. With these changes, some of the flexibility presented by the first and third solutions was lost, in order to reach a performance closer to the second solution. Table 4 presents results for the fourth solution, when compared to the second and third ones. The fourth solution presents improvements around 11% in the best-case execution and 33% in the worst-case execution, when compared to the third solution. However, the second solution still

7 presents best performance in the best-case execution, because it does not have the scheduling overhead. Fourth x Second Fourth x Third Property Estimated Exact Estimated Exact Program memory % % -3.48% -2.19% BC Data memory 24.07% 13.17% -1.95% -2.32% WC Data memory 24.07% 13.17% -1.95% -2.32% BC Performance % % % % WC Performance -1.87% 0.60% % % BC Energy % % % % WC Energy -0.14% 1.03% % % Table 4: Results for the fourth solution. The SPEU tool provides quantitative information about physical metrics that can be used by the designer in the development process already in its initial stages. Observing the estimates provided by SPEU and the system requirements, the designer can explore the design space using the estimates as a guide to select the most adequate modeling solution. 5 Conclusions and future work In this paper, we have presented an approach for early and fast embedded software design space exploration using a UML-based estimation tool called SPEU. This tool provides analytical estimates about physical system properties (memory footprint, energy consumption, and performance) directly obtained from the UML model, with reasonable accuracy, thus allowing a designer to select the most adequate modeling solution for further detailed implementation and analysis, without depending on costly synthesis-andsimulation evaluation cycles. Selecting the best modeling solution already at a very high abstraction level, for instance using UML for modeling, might result in significant gains in terms of physical characteristics. Moreover, the high-level exploration of candidate solutions may avoid software architectural problems, since the application analysis already at UML level can indicate problems when the cost to fix them is much smaller. These facts reinforce the need for an early design space exploration environment. Future work will address the further integration of SPEU with the MDA concepts and the development of a tool that fully supports an MDA approach. Moreover, a complete approach for better representing the platform and its services is being defined in order to facilitate the system modeling. More experiments including different embedded system application domains must be performed. References [1] Sangiovanni-Vinventelli A. et al.: Benefits and Challenges for Platform Based Design. Design Automation Conference, San Diego, June Proceedings, ACM, [2] Object Management Group (OMG). Unified Modeling language version 2.0 UML, OMG document n. formal/ [3] Mraidha C.; Robert S.; Gérard S.; Servat D.: MDA Platform for Complex Embedded System Development. In Proceedings of Design Methods and Application for Distributed Embedded Systems, IFIP TC-10 Work Conference on DIPES, [4] Li, Yau-Tsun Steven; Malik, Sharad: Performance Analysis of Embedded Software Using Implicit Path Enumeration. In Design Automation Conference (DAC). p ACM Press, [5] Lieverse, P.; Wolf, P.V.; Vissers, K.; Deprettere, Ed. A Methodology for Architecture Exploration of Heterogeneous Signal Processing Systems. Journal of VLSI Signal Processing Systems, v.29 n.3, p , November [6] Smith, C. U.; Williams, L. G.: Software Performance Engineering. In: UML for Real: Design of Embedded Real- Time Systems. Kluwer Academic Publishers, [7] Petriu, D.C.; Woodside, C. M.: Performance analysis with UML: layered queueing models from the performance profile. In: UML for Real: Design of Embedded Real-Time Systems. Kluwer Academic Publishers, [8] Object Management Group (OMG). UML Profile for Schedulability, Performance, and Time, OMG document n. ptc/ [9] Chen, R.; Sgroi, M.; Martin, G.; Lavagno, L.; Sangiovanni- Vicentelli, A.; Rabaey, J.: Embedded System Design Using UML and Platforms. In Proceedings of Forum on Specification and Design Languages (FDL 2002), September, [10] Ito, S.; Carro, L.; Jacobi, R.: Making Java Work for Microcontroller Applications. In: IEEE Design & Test of Computers. vol. 18, n. 5, Sept-Oct 2001 [11] Wehrmeister, M. A.; Becker, L. B.; Wagner, F. R.; Pereira, C. E: On Object-Oriented Platform-based Design Process for Embedded Real-Time Systems. Proceedings of IEEE International Symposium on Object-oriented Real-time distributed Computing, [12] Beck, A. C.; Mattos, J. C. B.; Wagner, F. R.; Carro, L. "CACO-PS: A General Purpose Cycle-Accurate Configurable Power Simulator". In: SBCCI'03 16th Symposium on Integrated Circuits and Systems Design. São Paulo, Brazil, September 2003 [13] Talarico, C.; Rozenblit, J. W.; Malhotra, V.; Stritter, A.: A New Framework for Power Estimation of Embedded Systems. IEEE Computer. v. 38, n. 2. p , 2005.