2009 2009 International International Conferences Conference on on Embedded Embedded Software Software and and Systems Systems
Model Driven High-level Power Estimation of Embedded Operating Systems Communication Services Saadia Dhouib, Eric Senn, Jean-Philippe Diguet, Johann Laurent and Dominique Blouin
[email protected] European University of Brittany - UBS Lab-STICC, CNRS/UMR 3192 F-56321 Lorient Cedex, France
Abstract
To describe functional properties of a system, various modeling languages can be chosen. UML [3] is a widespread modeling language standardized by the OMG, which provides concepts to model the architecture, behavior and deployment of software systems in object-oriented or component-based paradigms. Moreover, the language can be extended through profiles, accommodating domain specific modeling concepts. For example, SysML [5] is a profile to describe system engineering applications. Nonfunctional properties are harder to describe using UML. The MARTE profile initiative [18] tries to extend UML for improving the Modeling and Analysis of Real-Time and Embedded systems. Architecture Description Languages (ADLs) aim at modeling both functional and nonfunctional properties of system architectures. Making the description of these properties explicit enables analysis of the architectures. A number of ADLs have been proposed over the last decade. From these proposals, the Architecture Analysis and Design Language (AADL) [1] has received increasing interest from mission-critical applications development industries. In the context of the European project ITEA SPICES (Support for Predictable Integration of mission Critical Embedded Systems) [4], we have integrated AADL in the Model Driven Architecture (MDA) approach for system level power estimations at early design phases. Now, we propose to enrich the MDA based design flow for integrating the operating system as a system component; and to give designers high level feedback about power and energy consumption of operating system services without requiring simulation or prototyping of the hardware platform. In this paper, we present an approach to allow for early power and energy estimations for operating system services in MDA based design flow. We take as a case study, the RTOS interprocess communication and synchronization services (IPC). We present the MDA based design flow integrating AADL models in section 2, and the methodology to per-
This paper presents a System level Model Driven Architecture (MDA) approach for power estimation of real time operating system (RTOS) communication and synchronization services at early design phases. The approach integrates the Architecture Analysis and Design Language (AADL) in the design flow. We describe how to extend the language for modeling RTOS communication and synchronization services, and we explain how power consumption analysis can be performed on software components in the AADL platform independent model (PIM), once deployed into components in the AADL target hardware platform model. Operating system services are considered as components in the MDA approach in order to take them into account in the estimation methodology. This paper focuses on consumption analysis of RTOS communication and synchronization services.
1 Introduction Several industries are currently facing the issue of developing real-time embedded systems with increasing complexity, dependability and economic pressures such as cost and time to market. Reducing development times and costs of such systems should not imply any damage to their nonfunctional requirements such as timeliness, performance, safety properties and power consumption. Model-driven development/engineering (MDD/MDE) addresses those issues. Indeed, with such approaches, models become the primary artifacts in the development of systems instead of writing code. The choice of an adequate language to model embedded system is essential to build models whose (functional/non-functional) properties can be analyzed and verified. 978-0-7695-3678-1/09 $25.00 © 2009 IEEE DOI 10.1109/ICESS.2009.94
473 475
2.1 AADL related tools
form power and energy estimations throughout this flow in section 3. Then, section 4 explains how we extended the AADL language to model IPC and how power estimation can be done for this RTOS service. This paper is finally concluded within the last section.
A number of tools are available for system modeling and analysis with the AADL. Ocarina [14] is a tool suite written in Ada supporting the generation of formal models and distributed applications with scheduling analysis capabilities. Cheddar [22] is a free real time scheduling tool. It is designed for checking task temporal constraints of a real time application/system written in the AADL or with a Cheddar proprietary language. In the context of the SPICES project [4], a set of ECLIPSE based tools are under development. As shown in Figure 1, SPICES tools address the verification, analysis, simulation and implementation of AADL models. Some of SPICES tools are integrated into the TOPCASED [2] framework. OSATE [20] is a textual and graphical modeling tool. ADELE address shortcomings in OSATE graphical editor. MAST [7] performs schedulabilty analysis on AADL models. PathCrawler [8] is specialized to be used for worst-case/best-case execution time prediction. AADS [6] performs timed simulations on AADL models. This article focuses on integrating power models of operating system services in the consumption analysis toolbox (CAT) that estimates power consumption of AADL software components bound to hardware platform components such as processors, buses, memories and FPGA (Field Programmable Gate Arrays).
2 AADL Modeling of embedded systems The Society of Automotive Engineers (SAE) Architecture Analysis and Design Language (AADL), AS5506, was developed drawing on significant experimentation and research in architecture description languages (ADL) over 15 years. It provides the specification capability to capture the software and execution platform components. It supports the capture of functional and non functional properties of embedded systems. It is also extensible with analysis approaches to evaluate properties such as schedulability, performance and power and energy consumption [13]. The language was standardized in 2004 and annexes were published in 2006 for graphical notation, error modeling, standard metamodel, and programming language Guidelines [1]. To model complex embedded systems, AADL provides three distinct sets of component categories: • Application software components including data, subprogram, thread, thread group and process. • Execution platform components including processor, memory, bus and device.
Topcased OSATE
• A Composite component, system, which encapsulates hardware components, software components and lower level system components within their implementations.
faust
TINA
Interfaces to components and component interactions are completely defined. The AADL standard also includes runtime semantics for mechanisms of exchange and control of data including message and event passing, synchronized access to shared components, timing requirements and remote procedure calls. Though its precise modeling semantics, we noticed that AADL presents some lacks regarding software architecture modeling. For example, there is no software architecture abstraction concepts useful for modeling at an abstraction level higher than the one of an imperative programming language [11]. The lacks of the language has led to a new version of AADL which is now under development along with a Behavioral annex based on industries desired extensions. Version 2 of AADL will include support for modeling virtual bus and processor, abstract component and arrays of subcomponents.
BIP
Deduce initial architecture from formal requirements
ADELE
MAST
Model editors Schedulability analysis
AADL models Models verification
Update timing models
Power analysis
AADS
Pathcrawler WCET Estimate worst-case execution time
CAT Timed simulation
Implementation code (CCM, AADL-C)
Direct generative techniques
Component framework
Integration onto the target
Figure 1: Interaction of SPICES tools
2.2 Using AADL in Model Driven Architecture In 2001, the Object Management Group, OMG, adopted the MDA approach for using models in system develop-
476 474
ment. The MDA approach investigates the idea of separating the system operation specification from the details of the way that system uses the capabilities of its platform. The three primary goals of MDA are portability, interoperability and re-usability [17]. When designing an embedded system with respect to MDA, it is required to create models at several levels:
quirement. A comparative study of different approaches is exposed in table 1. In the next section we show how we have followed the MDA approach to perform power consumption analysis on AADL specifications of a PIM consisting in software tasks managed by real time operating system services and bound to a hardware platform.
• At the first level, the Platform Independent Model (PIM) is built. It describes the system regardless of the details of its platform use. A Platform Model (PM) is also built. It provides a set of technical concepts, representing the different parts that make up a platform and the services provided by that platform.
3 Consumption Analysis: the methodology In previous works, we have introduced the Functional Level Power Analysis (FLPA) methodology which we have applied to build high-level power models for different hardware components. This approach relies on the decomposition of a complex system into functional components, independent regarding the power consumption. The components architecture is firstly analyzed and relevant parameters regarding its power consumption are identified. Then physical measurements are performed to assess the evolution of the power consumption with the models input parameters (using little benchmarking programs called scenario), and finally power consumption laws are established. Power models are functions of component’s operating frequency and its architectural parameters (mainly linked to its memory configuration in the case of processors) and application parameters such as the type of instruction executed (calculation or memory accesses) in the case of processors and amount of transferred data in the case of Ethernet controllers:
• At the second level, a Platform Specific Model is obtained after model transformation. The PSM combines the specifications in the PIM with the details that specify how that system uses a particular type of platform. AADL was designed to support a full model based engineering lifecycle [15]. Both platform independent and specific models can be specified with AADL. Balp et al [9] use AADL to build a modular specification of the different views of a component based system at the platform independent level. From the description of this component based architecture (IDL, IDL3, and Component Deployment Plan files), they generate the equivalent AADL PIMs and AADL deployment plan model. The AADL PSM model is obtained after a model composition process of the AADL framework models libraries, deployment plan model and component assembly model. Other approaches have also adopted AADL in a model based architecture design process, but only at a low level of abstraction (Platform Specific level). S´ebastien et al [19] proposed a design process starting from PIMs to PSMs. Platform Independent Models are specified in xUML: the system is captured in Domains in a Domain Chart, ie., sets of classes with well-defined interactions between them. The translation of a PIM expressed in xUML to a PSM expressed in AADL requires the interpretation of xUML models, and then mapping xUML charts to AADL packages playing the same role. Delanote et al [10] adopted a different approach to integrate AADL in a MDA design process. The authors considered the AADL runtime environment as the target platform in the approach. At the highest level of abstraction, there is an UML model annotated with AADL stereotypes according to the UML profile for AADL. This AADL PIM is transformed to an AADL PSM through functional and non functional transformations. Functional transformations consist in a number of rules that enforce the PSM compliance with all SAE AADL standard legality rules. Non functional transformations add properties to the AADL PSM allowing the analysis of the model towards non functional re-
P =F (Archi P arameters,Appli P arameters)
In [21], we have shown how FLPA approach fits into the AADL design flow. Besides integrating AADL in an MDA approach, we aim at enhancing AADL for expressing non functional requirements related to power and energy consumption of applications managed by an operating system and running on different hardware components; and then the development of a runtime support for the analysis of AADL models extended with non functional properties. The challenge for the consumption analysis tool (CAT) is to provide a realistic power budget for every component in the AADL component assembly model. Basically, we have chosen a two step methodology consisting of two computation phases for the system’s power consumption analysis: 1. In the first phase, the power budget is computed for every software component independently. This phase is the power estimation. 2. In the second phase, the power budgets of software components are combined to get the power budgets for the whole set of hardware components. This second phase is the power analysis. Using timing information,
477 475
Table 1: Approaches integrating AADL in a MDA design process [9]
[19]
[10]
PIM
AADL models generated from a component based architecture description(IDL, IDL3)
xUML Domains charts
UML2 model annotated with AADL stereotypes according to the UML profile for AADL
Model Transformation (from PIMs to AADL PSMs)
Model composition process of AADL deployment plan model, AADL component assembly model and AADL framework libraries
Mapping xUML charts to AADL packages
Functional and non Functional transformations
Discussion of the approach
gives CCM community access to AADL analysis tools
gives xUML community access to AADL analysis tools
gives UML2 community access to the AADL analysis tools
the energy analysis is performed afterwards. Energy analysis can be performed using information from the timing analysis tools currently being developed in the SPICES project.
OS_kernel
Estimation
Communication & Synchronization
Analysis
Process2 Device Drivers
Bound to
Scheduler
PowerBudget => ?
Memory Management
Process1
EnergyBudget => ?
thread 1
Those two phases are presented in Figure 2 in the case of one thread bound to one processor. Plain edges represent phase 1 (estimation), dotted edges represent phase 2 (analysis). The power estimation tool gathers several information in the system’s AADL specification at different levels, here from the process and thread descriptions, and from the processor and peripheral devices specification. It also uses binding information that come from the AADL deployment plan model. The tool uses the power model of the targeted hardware component (here a processor and an Ethernet controller) to compute the power budget for the software component (e.g. a thread mapped on a processor and communicating through a Ethernet port). In fact, it determines the input parameters of the model from the set of information it has gathered. Power Models for embedded processors have been developed and are detailed in previous work [21]. Power models have also been developed for peripheral devices such as Ethernet. We have indeed shown in [12] that a large part of a system’s power consumption is due to data transfers from and to peripherals. Those transfers may come directly from the application, or may be induced by the operating system. Data transfers from the application are either embedded in the source code through direct memory accesses by threads, or they can be supported by inter-process communication services from the operating system. In the first situation, the data transfer power consumption is directly included in the power model of the processor that run the code and is based on cache miss behavior lower and upper bounds. The consumption of the external memory is easily computed from the number of external accesses and the basic power features of the memory component from its datasheet. Power consumption of inter-process communication (IPC) services is however not included in the processors’ model. In the next section we describe how we modeled operating
Power Models Library
Power Analysis plug-in
Power Estimation Tool
1 processor2 PowerBudget => ? EnergyBudget => ? PowerCapacity => 5W
processor1 PowerBudget => ? EnergyBudget => ? PowerCapacity => 5W
2
Sys_Bus2
Sys_Bus1 Ethernet_ctrl1 PowerBudget =>? EnergyBudget => ? PowerCapacity => 3W
Energy Analysis plug-in
Ethernet_Bus
Ethernet_ctrl2 PowerBudget =>? EnergyBudget => ? PowerCapacity => 3W
Timing Analysis Tools
Figure 2: Power and Energy consumption estimation in the AADL design flow system communication services in AADL, and how we applied our methodology to estimate consumption of IPC. We take as a case study Ethernet communications.
4 High level consumption analysis on RTOS communication services The increasing complexity of embedded system applications has led to the use of operating systems with hard and/or soft real time constraints. They are considered as a software layer between the system resources (processor, memory and peripheral devices) and the applicative tasks. In fact, they provide system designers with several helpful mechanisms such as preemptive multitasking, fixed/dynamic priority scheduling, support for periodic/aperiodic tasks, synchronization, interprocess communication timers, memory management, device drivers. In doing so, they require memory and processor resources. Limited power budgets of embedded systems have made it necessary to consider the RTOS influence on power and en478 476
ergy dissipation. Our purpose is to analyze and estimate the energy and power consumption of embedded applications managed by an operating system at the first design steps. The system to analyze is an AADL PSM of a software application managed by RTOS services and running on an embedded hardware architecture. Despite its precise modeling semantics, we noticed that AADL presents some lacks regarding software modeling. For example, communications between threads or processes are modeled through ports (event, data or event data ports). But this modeling facility is not sufficient to describe all the communication mechanisms supported by an operating system. Therefore, it is necessary to extend the AADL language to enable precise modeling of process communications.
compliance with the standard.
4.2 Example of IPC use in an AADL model In Figure 3, we show an example of an AADL PSM to analyze. The RTOS is modeled as an AADL software component, namely a process which represents the RTOS protected address space. RTOS services are modeled as data types and threads within the OS kernel process. The software application consists of three processes, two applicative processes and the RTOS process. Processes communicate via an mqueue. Threads within each process are bound to the general purpose processor sysCPU. Processes and data types are bound to the memory sysRAM.
Process 2
Process 1
4.1 AADL Modeling of Synchronization, Local and Remote Interprocess communications
Thread1 Mq_send
Processes/threads in concurrent programs will necessary share some resource, such as variables, but also files, buffers, and devices. The RTOS synchronizes access to shared resources by implementing mechanisms like mutex, semaphores, and signals. Interprocess communication (IPC) can be considered as another level of generalization of synchronization, since many of these mechanisms have a built-in synchronization aspects. IPC allows threads in one process to share information with threads in other processes, even processes that exist on a different hardware platform. In IPC, the RTOS explicitly copies information from a sending process’s address space into a distinct receiving process’s address space. Examples of IPC mechanisms are pipes, message passing through mailboxes or sockets (remote interprocess communication). Since AADL does not allow for precise modeling of those communication mechanisms, we have defined new AADL packages that describe IPC and that can be used to model any communications between software processes or threads. We organized the AADL specification of IPC and synchronization mechanisms as a set of five packages: Mqueue, Shared Memory, Socket, Semaphore, Mutex. Each package contains a specific data type component corresponding to a communication mechanism. Services of an IPC are modeled as server subprogram features of a thread contained in the RTOS process. Only socket services are modeled as features of the socket data component, because sockets are implemented in user address space, not in the RTOS address space. Table 2 shows the AADL socket package. To guarantee the portability and re-usability of the IPC predefined components, we have followed the POSIX standard when designing the corresponding packages. We have also defined a POSIX property set (Table 3) to ensure models
Thread2 Mq_receive
R TO S kernel
Server subprogram call binding
Mqueue_Thread Ethernet_driver
Mq_receive
Mqueue
Mq_send
SysR A M Bus_access
R am
SysC PU G PP
SysR O M
Bus_access Sys_bus Bus_access
Flash_ctrl
R om
Flash_disk_device Bus_access
Ethernet_C trl Ethernet_device Bus_access
Figure 3: AADL Mqueue communication example Next, we illustrate the use of the AADL socket package in Figure 4. The modeled system consists on hardware and software parts. The hardware distributed system contains three platforms connected with the Local Area Network. Each platform is composed of a FPGA embedding a PPC processor and on-chip device controllers. The Ethernet MAC controller is inside the FPGA, the physical controller is off-chip and is connected to the Ethernet bus that models the LAN. Each platform also contains a memory which is connected to an on-chip memory controller. The software system is a client/server system which contains three processes: a server process and two client processes. Each client process communicates with the server through sockets. The client sender thread is connected to the socket through a data access connection. Each thread is bound to its corresponding platform processor. Event data connections between processes are bound to the Ethernet bus. To estimate power and energy consumption due to Ethernet communications, the tool searches for all event data
479 477
Table 3: Posix Property set property set Posix_properties is
Table 2: Socket Package
POSIX_scheduling_policy: enumeration (SCHED_RR, SCHED_FIFO, SCHED_SPORADIC, SCHED_OTHERS) applies to (thread, system);
package ipc::socket public data socket features bind: subprogram; listen: subprogram; accept: subprogram; connect: subprogram; send: subprogram; recv: subprogram; sendto: subprogram; recvfrom: subprogram; getpeername: subprogram; close: subprogram; end socket; -- Accept a connection on a socket subprogram accept features sock: requires data access; addr: requires data access; end accept; -- Bind a name to a socket subprogram bind features sock: requires data access; my_addr: requires data access; end bind; -- Initiate a connection on a socket subprogram connect features sock: requires data access; serv_addr: requires data access; end connect; -- Listen for connections on a socket subprogram listen features sock: requires data access; backlog: in parameter behavior::integer; end listen; -- Receive a message from a socket TCP subprogram recv features sock: requires data access; -- the socket to read from msg: requires data access; -- buffer that will contain -- the received message len: requires data access; end recv; -- Receive a message from a socket UDP subprogram recvfrom features sock: requires data access; msg: requires data access; len: requires data access; addr_in: requires data access; end recvfrom; . . . . end ipc::socket
POSIX_Control_Protocol: enumeration (POSIX_MUTEX, POSIX_SEMAPHORE, POSIX_BUFFER, POSIX_MQUEUE) applies to (data); POSIX_Socket_Type: enumeration (SOCK_STREAM, SOCK_DGRAM, SOCK_SEQPACKET) applies to (data);
connection instances bound to the Ethernet bus. If threads connected through those connection instances are accessing socket data types, the tool concludes that there are Ethernet data transfers. Then it computes for power and energy consumption of MAC and physical controllers connected to processors executing corresponding threads. To compute energy and power consumption, it extracts software parameters such as IP packet data size, transmission protocol and processor frequency. It then uses the power models presented in [12].
5 Conclusion We have presented MDA based approach for power and energy estimation. The approach integrates AADL and allows for estimating consumption of software components bound to hardware platform components. We have considered the operating system effect on power and energy consumption of the whole system. We have noticed that major sources of consumption are data transfers which are partially managed by OS IPC services. Actually other remaining data transfers are estimated in our model and based on cache behavior lower and upper bounds. We extended the AADL language in order to enable modeling of IPC, then we explained how consumption analysis can be performed on a PIM containing processes and threads communicating via IPC, once deployed on the hardware platform components. We illustrate the approach with the Ethernet communications case study. This work is a part of the European project SPICES aiming a system level design framework in which our consumption analysis approach is implemented.
References [1] The SAE AADL Standard Info Site. http://www. aadl.info/. [2] TOPCASED Home. http://topcased-mm.gforge. enseeiht.fr/. [3] Object management group, unified modeling language: Superstructure, omg/2005-07-04, 2005.
480 478
[4] The SPICES ITEA Project Website. http://www. spices-itea.org/, 2006. [5] Systems modeling language open source specification project. http://www.sysml.org, 2006. [6] AADL Simulator Home. http://www.teisa. unican.es/gim/en/AADS2.php, 2008. [7] MAST Home. http://mast.unican.es/, 2008. [8] PATHCRAWLER Home. http://www-list.cea. fr/labos/fr/LSL/test/pathcrawler/index. html, 2008. [9] H. Balp, E. Borde, G. Ha¨ık, and J.-F. Tilman. Automatic composition of AADL models for the verification of critical component-based embedded systems. In Proc. of the Thirteenth IEEE Int. Conf. on Engineering of Complex Computer Systems (ICECCS), march 2008. Belfast, Ireland. [10] D. Delanote, S. V. Baelen, W. Joosen, and Y. Berbers. Using AADL in model driven development. In IEEE-SEE International Workshop on UML and AADL, ICECCS, 2007. [11] D. Delanote, S. V. Baelen, W. Joosen, and Y. Berbers. Using AADL to model a protocol stack. In IEEE-SEE International Workshop on UML and AADL, ICECCS, 2008. [12] S. Dhouib, J.-P. Diguet, E. Senn, and J. Laurent. Energy models of real time operating systems on fpga. In Euromicro International Workshop on Operating Systems Platforms for Embedded Real-Time Applications, ECRTS, 2008. [13] P. Feiler, B. Lewis, and S. Vestal. The sae architecture analysis & design language (AADL) A standard for engineering performance critical systems. In IEEE International Symposium on Computer-Aided Control Systems Design, pages 1206–1211, Munich, october 2006. [14] J. Hugues, B. Zalila, L. Pautet, and F. Kordon. Rapid prototyping of distributed real-time embedded systems using the AADL and ocarina. Rapid System Prototyping, IEEE International Workshop on, 0:106–112, 2007. [15] B. Lewis and P. Feiler. Multi-dimensional model based engineering using AADL. rsp, 0:xv–xviii, 2008. [16] N. Medvidovic. A classification and comparison framework for software architecture description languages. IEEE Transactions on Software Engineering, 26:70–93, 2000. [17] OMG. MDA Guide Version 1.0.1, June 2003. [18] OMG. The official omg marte web site. http://www. omgmarte.org, May 2007. [19] G. S´ebastien, P. Feiler, J.-F. Rolland, M. Filali, M.-O. Reiser, D. Delanote, Y. Berbers, L. Pautet, and I. Perseil. UML & AADL ’2007 grand challenges. ACM SIGBED Review, A Special Report on UML & AADL Grand Challenges, 4(4), octobre 2007. [20] SEI. OSATE: An extensible source AADL tool environment. Technical report, SEI AADL Team technical Report, December 2004. [21] E. Senn, J. Laurent, E. Juin, and J. Diguet. Refining power consumption estimations in the component based AADL design flow. In FDL’08, ECSI Forum on specification & Design Languages, pages 1206–1211, Stuttgart, Germany, september 2008. [22] F. Singhoff, J. Legrand, L. Nana, and L. Marc. Scheduling and memory requirements analysis with AADL. In Proceedings of the 2005 annual ACM SIGAda international conference on Ada, 2005. Atlanta, GA, USA.
Client Server System Input_data
Output_data Client_1 Processing
Sender
Socket
Server
Data_to_send
Receiver
IP address
Socket
Client_2 Processing
Processing
Buffer
IP address
Sender Socket
Buffer IP address
Hardware Distributed System
Platform1 FPGA CPU
Memory Controller
Platform2 FPGA
Memory
Memory Controller
CPU
MAC Controller
Memory
MAC Controller
PHY Controller
PHY Controller
Ethernet Bus
Platform3 FPGA CPU
Memory Controller
PHY Controller
MAC Controller
Memory
Figure 4: AADL socket communication example
481 479
