AbstractEmbedded systems are comprised of hardware and software and usually run dedicated applications in environments with highly restricted resources, such as memory constrained devices, microcontrollers with low processing power, and wireless sensors running on batteries. These systems must exactly match applications' requirements, with minimum support. The growth in application complexity and even more strong constraints demand new approaches, methodologies, and tools to assist embedded systems development. Usually, in this domain, reuse of components, architectural transparency, low overhead, and reconfigurability are essential features. The Application-Oriented System Design (AOSD) method was created to deal with these issues, and aims at guiding the development of embedded systems that exactly match application requirements. To deliver each application a tailored run-time support system calls for a good combination of object oriented techniques, the separation of functional and non-functional aspects, some implementation techniques, and a sophisticated tool that helps the developer in managing component configurations and automating the generation of embedded systems. This paper describes a configuration and system generation tool that is being successfully used with EPOS (Embedded and Parallel Operating System), an OS developed using AOSD. This tool receives the application source-code (using EPOS API) as input and, after a few mouse clicks, builds the entire computational support, comprised by software and, if hardware is reconfigurable, the FPGA configuration file. This paper also shows that the design of these tools allows them to be used for configuring and building several other systems, not only EPOS. The development of this tool enabled the configuration and generation of several embedded systems instances for several di erent architectures in an automatic way. To illustrate this process and the tool's usage, this paper describes a case study of the generation of an embedded system that supports a simple audio decoder application. 1 INTRODUCTIONEmbedded systems are being extensively used in several industrial sectors as an e ective alternative to control machines, automobiles, domestic appliances, personal gadgets, and virtually every device that includes electronic components. Recent statistics reveal that over 99% of the microprocessors produced nowadays are used in embedded systems and that in 2005 the number of embedded systems in the planet rose above the number of humans [9]. Besides growing in number, these embedded systems are also becoming more and more complex as they benefit from microchip advances. In this context, the System-on-a-Chip (SoC) approach emerges as a compromise between complexity and cost. Programmable Logic Devices (PLD) enable developers to evaluate complex designs in short periods of time by applying techniques that are closer to software development than to traditional hardware development. Getting a SoC out o a Field-Programmable Gate Array (FPGA), however, is not a trivial task and requires an intricate engineering process. From the hardware perspective, much e ort has been put in tools that assist designers in selecting and configuring hardware components, or Intellectual Property (IP) blocks, and also in generating the necessary glue logic. Indeed, some embedded systems can be completely implemented in hardware with this approach. Nonetheless, the more complex the application is, greater is the probability it will need some sort of run-time system to adequately support its execution on top of a (soft-core) processor. From the software perspective, this research group has been exploring methodologies and tools to sustain the development of embedded systems as aggregates of reusable components. One of the main challenges surmounted along this long-term research concerns architectural transparency for the run-time support system. In the realm of embedded systems, run-time support must often be provided under distinct architectures. For instance, an application running on a simple 8-bit microcontroller will probably be supported by a run-time library, while a multitask application running on a 32-bit microprocessor will probably require a microkernel. In order to enable application portability, a component-based embedded system must present the same interface in both cases. Indeed, the component should be the same, since its interface and behavior remains the same; only the software architecture is different. Our approach has so far enabled the development of run-time support systems whose architecture can be defined according to particular application needs. Embedded applications usually don't find adequate run-time support on allpurpose operating systems and hardware. Application-Oriented System Design (AOSD) is an useful solution for this kind of applications, as demonstrated in previous works [3] [4] [8] [2]. Application-Oriented Operating Systems (AOOS) are targeted towards the applications, which means they are composed only from selected software components that are adapted to finely fulfill application requirements. Additionally, an AOOS may be supported by a hardware platform created by the composition and synthesis of proper hardware components. Delivering each application a tailored run-time support system, besides requiring a comprehensive set of well-designed software and hardware components, also calls for a sophisticated tool that will help the developer in creating component configurations, a task that includes the identification, selection, configuration, adaptation, and composition of those components. In this work we present an approach to the configuration management of componentbased embedded systems which enables partial automation of the development process of mobile and embedded applications, contributing to an increase in productivity. Also, the ability to easily generate optimized versions of an operating system and a hardware platform for each of the applications that are going to use is of great value in the domain of high performance embedded computing, since it results in performance gains and resource usage optimization. This paper is organized as follows: Section 2 briefly describes AOSD, our approach to the design of component-based embedded systems. Section 3 presents the main concepts and structure of a tool that is able to configure and generate embedded systems. Section 4 describes the details of a prototype implementation. Section 5 presents a case study that demonstrates the use of this tool and the last section presents some conclusions and a road map for future work. 2 AOSDThe Application-Oriented Systems Design method (AOSD) proposes strategies to define components that represent significant entities in di erent domains. By applying variability analysis, as defined in the Family-Based Design (FBD) [7], AOSD allows the modeling of independent abstractions and organizes them as family members. Even independent and separated, these abstractions may have dependencies from the environment to which they are applied. But abstractions that have environment dependencies will be reused with difficulty in di erent scenarios. To reduce environment dependencies and to increase re-usability of abstractions, AOSD adds to the decomposition process the main concern of Aspect-Oriented Programming (AOP): aspects separation. With this, it is possible to identify scenario variations and to model them not as family members, but as scenario aspects. The integrated utilization of these and other advanced software engineering techniques allows the development of efficient methodologies for Embedded Systems Design, both in basic software and in hardware domains. One of the first strategies is the one proposed by [3], the EPOS (Embedded Parallel Operating System). EPOS is a framework conceived through AOSD that combines concerns of FBD, OAP, Object Oriented Design (OOD) and Static Meta Programming (SMP) to guide the development of scenario independent component families that, by applying scenario adapters, can be used in di erent environments and provide architecture transparency [4]. Besides operating system components, it has been extended to deal with hardware [8], allowing the design of hybrid components whose software/hardware implementations are suitable. This approach has so far enabled the development of run-time support systems with architectures that are defined according to the particular needs of applications. Indeed, with all these features, it seems a promising approach to help solving the problems that currently limit efficiency in SoC development. The main ideas behind AOSD are described below: Families of scenario independent abstractions: during domain decomposition, abstractions are identified from domain entities and grouped in families according to their commonalities. Yet, during this phase, aspect separation is used to shape scenario-independent abstractions, thus enabling them to be reused in a variety of scenarios. These abstractions are subsequently implemented to give rise to the actual software components. Scenario adapters: as explained earlier in this article, Application-Oriented Inflated interfaces: summarize the features of all members of a family, creating an unique view of the family as a super component. It allows application programmers to write their applications based on well-known, comprehensive interfaces, postponing the decision about which member of the family shall be used until enough configuration knowledge is acquired. The binding of an inflated interface to one of the members of a family can thus be made by automatic configuration tools that identify which features of the family were used in order to choose the simplest realization that implements the requested interface subset at compile-time. 3 A CONCEPTUAL TOOLOperating systems and hardware support designed according to the premises of Application-Oriented System Design, besides all the benefits claimed by software component engineering, have the additional advantage of being suitable for automatic configuration and generation. The concept of inflated interface enables an application-oriented operating system and its hardware support to be automatically generated of out of a set of software and hardware components, since inflated interfaces serve as a kind of requirement specification for the system that must be generated. Our approach relies on a static configuration mechanism that allows the generation of optimized versions of the operating system for each of the applications that are going to use it. The following is a detailed list of functionalities we have identified as requirements for a tool that addresses the problem: (i) Requirements analysis (automatic): applications must be inspected and their requirements regarding the support system should be extracted. (ii) Component suggestions (automatic): components that satisfy application needs should be identified. (iii) Component selection (semi-automatic): from a set of satisfactory components for an application, the most adequate ones should be automatically selected, and the developer must be allowed to select additional ones. (iv) Component configuration and composition (semi-automatic): default and critical components should be automatically selected, traits and features of components should be configured by the tool with default values and be modifiable. Also, the compliance to composition rules, such as exclusivity of some component members, should be maintained. (v) Generation of systems and hardware (automatic): based on configurations created by developers and components retrieved from a repository, system instances should be generated and hardware should be synthesized. (vi) Cost estimation (automatic): estimations of component costs, such as energy and silicon area, should be provided to the developer to assist him in choosing between components or between component members that achieve the same task. (vii) Configuration validation (semi-automatic): application and component dependencies should be tracked and presented to the developers, as well as other configuration problems and restrictions, such as restrictions regarding the chosen target hardware platform. The dependencies that can be automatically solved should be, while the others should be left to the developer to deal with. And three main non-functional requirements to be considered: (i) Specific Graphical User Interface (GUI): one that has good usability and leads to efficiency. (ii) Feedback to the developer: the developers should know what is happening and, therefore, the actions that the tool automatically takes should be notified to them. (iii) Automation: some steps should be done automatically or by default. We have organized these functionalities in three conceptual modules: Analyzer, Configurator, and Generator. Figure 1 illustrates how these modules could be used to assist an automatic or semi-automatic generation procedure of a system instance to support the runtime of a specific application. An application's source code, previously written based on the interfaces of components from a repository (the OS API), can be submitted to the Analyzer module. This module searches for references to the interfaces, identifying what features are necessary from each component, and elaborates a requirement specification that includes methods, types, and constants used by the application. If a requirement may be satisfied only by one component from the repository, the Analyzer can automatically choose it. If there are more than one, the components that meet the requirements, along with cost estimations, are presented to the developer so that he can choose the most adequate one. The primary output of the Analyzer is a set of application dependencies, since the application depends on some components in order to work properly. These dependencies feed the Configurator.
Figure 1: An overview of the tool The Configurator module is logically divided in a Validator and a Configuration. The components chosen with the help of the Analyzer are added to the Configuration and used by the Validator to build a dependency tree. By doing this, the Validator is able to keep track of (1) aplication dependencies, (2) component dependencies, and (3) component composition rules. (1) refers to the dependencies that exist between application requirements and system components. (2) refers to the dependencies that may exist between components and their traits and features. (3) refers to the rules that should be followed when creating the Configuration, since some component members may be exclusive, and critical components cannot be touched. Some components are critical to any configuration, while others are critical to specific target platforms. Although the Validator leads the developer to choose only the components that are necessary and adequate, he can interact with the Configurator to add and remove components from the Configuration and modify their features and traits. The last step in the system development process is accomplished by the Generator module. Internally, it works by generating a set of keys that represent the current valid Configuration, binding the interface used by the application to specific component members existent in the repository, and activating the scenario aspects eventually identified as necessary to satisfy the constraints dictated by the application or by the configured execution scenario. On the hardware side, the Generator produces a list of mediators that were included in the Configuration, specifying which ones are associated to IP blocks. These blocks are reusable hardware components, specified in a Hardware Description Language (HDL) or in an intermediate format, such as netlists. The last step in the system development process is accomplished by the Generator module. Internally, it works by generating a set of keys that represent the current valid Configuration, binding the interface used by the application to specific component members existent in the repository, and activating the scenario aspects eventually identified as necessary to satisfy the constraints dictated by the application or by the configured execution scenario. On the hardware side, the Generator produces a list of mediators that were included in the Configuration, specifying which ones are associated to IP blocks, which are simple reusable hardware components, specified in a Hardware Description Language (HDL) or in an intermediate format, such as netlists. The Generator module translates the keys into parameters for a statically metaprogrammed component framework and executes the compilation of a tailored system instance. In addition, whenever a SoC needs to be tailored, the Generator produces a synthesis configuration file that holds the parameters for configuring IP blocks and the information necessary to glue the IPs in a SoC. Written in a hardware description language, this configuration file and the selected IP blocks are handed over to a third-party tool, which performs the translation of the SoC specification into netlists. Finally, by considering the target PLD technology, these netlists are translated into a configuration bitstream. 4 PROTOTYPE IMPLEMENTATIONA proof-of-concept Java implementation of the tool described in the previous section has been developed and some details of its operation at the current development stage are given here. AnalyzerThe Analyzer applies a technique that involves the compilation of the application's source code, a look at the resulting object files, and the identification of unresolved symbols that refer to methods and/or constants from the 'System' namespace. By doing this, it is able to identify the usage of the operating system API. The references to the API are extracted by an external Perl script and output in the form of a XML file. The file is used by the tool to generate application dependencies, and the subsequent suggestions of satisfactory components. Figure 2 depicts the Analyzer GUI. This interface allows a developer to specify application implementation files and include directories containing header files, to visualize the code (right side), and to ask for requirements extraction. The requirements are exhibited in a tree structure (left side), which shows component families and members that satisfy the requirements. From the tree, the user may indicate the families and members to be included in the configuration. We can observe a message console at the bottom of the figure. This console also accompanies the Configurator and Generator interfaces and shows all the relevant notifications, warnings, and error messages that must be delivered to the developer, relieving him from having to deal with dialog box windows.
Figure 2: The Analyzer interface ConfiguratorThe strategy used to describe components in a repository and their dependencies plays a key role in making the configuration process possible. The description must be complete enough so that the Configurator will be able to automatically identify which abstractions better satisfy the requirements of the application without generating conflicts or invalid configurations and compositions. The component description language we adopted is based on XML and is focused on describing each component individually. As shown below, a component is defined by a family and its set of member. A family description also includes an interface declaration, an optional set of dependency, an optional set of trait, and a common package that holds type and constant declarations that are common to all family members. A family's interface summarizes the features of the whole family, including constants, constructors, and methods. Each member of a family is also described by an interface, which designates a total or partial realization of the family's interface. Additionally, a member is described by an optional super declaration, an optional set of trait, dependency, and feature declarations, and a required cost declaration. The super element determines the inheritance from other members in the family, while a trait designates a configurable information that can be set by the developers, via the Configurator, in order to influence the instantiation of a component. A trait can also be used to specify configuration parameters that cannot be automatically fi gured out, such as the number of processors in a target machine or the amount of memory available. The description of the interfaces in a family and its members is the main source of information for the Configurator, but correctly assembling a component-based system goes far beyond the verification of syntactic interface conformance: nonfunctional and behavioral properties must also be conveyed. For this purpose, the component description language includes two special elements: feature and dependency. These elements can be applied to virtually any other element in the language to specify features provided by components and dependencies among components that cannot be directly deduced from their interfaces. Enriching the description of components with features and dependencies can significantly improve the correctness of the assembly process, helping to avoid inconsistent component arrangements. If the family is hardware mediator type or hardware IP type, the member descriptions must also declare arch and mach, which specify the architecture and machine the member is compatible with. More details and examples of the description language can be found in [10] [11]. The Configurator GUI is depicted in Figure 3. It allows the developer to see the list of components included in the configuration (left side). Through the configuration desktop pane (right side), all the components, as well as the configuration's target platform, can be viewed and modified with the help of their respective configuration frames, although the default values for their features and traits are often adequate. The Configurator automatically includes the minimum necessary components and allows the developer to include other ones. However, currently it does not identify unnecessary or redundant components. Despite not being implemented, this could be achieved simply by analyzing the dependencies. The Validator also has a graphical interface that opens up in the Configurator window. It shows the current collection of dependency problems and other miscellaneous ones, such as incorrect information describing component, target, or general configuration characteristics. GeneratorThe Generator allows a developer to launch processes that invoke the operating system's makefiles, causing the system instance generation, and processes that invoke synthesis tools that build the hardware platform. Before these generation processes can be executed, a set of directive files are created, including traits files and a 'keys file' that guide the generation. Also, the application may be compiled by the Generator with parameters that consider the system that was just built for it. Our approach aims at generating real systems, not only simulated ones. A limitation of this Generator is its inability to estimate properties (memory and silicon area, latency, power consumption, etc.) of the final system before really building it.
Figure 3: The Configurator interface The Generator interface, as depicted in Figure 4, is very straightforward. It shows informative output from the processes launched by their respective buttons. Some logic is applied to allow the actions a developer can take. For instance, it is not permitted to build the system or hardware before the 'Config' action is taken, since that action causes the generation of the directives needed by the building processes. This tool was designed to assist developers in executing the procedure depicted in Figure 1 in a simple, direct, and semi-automatic manner. The GUI and its usability have an important role, since it must greatly reduce the work a developer is required to do in comparison to what would be performed manually without tool assistance. Several conveniences, such as action keys, pop-up menus, icons, and intuitive responses are provided by it, and all the elements are organized in a way to make a clear separation of the activities related to analysis, configuration, and generation steps, although the developer is able to go back and forth through the steps.
Figure 4: The Generator interface 5 CASE STUDY AND RESULTSIn order to evaluate the prototype implementation described in Section 4 and its support for the requirements listed in Section 3, we performed some case studies involving the automatic or semi-automatic generation of di erent kinds of embedded applications, such as multimedia, automotive control, wireless sensor networks, energy aware mobile systems [1] [5] for different platforms/architectures, such as AVR, MIPS, SparcV8, PPC405, and IA32. In this paper we present a simple audio player application. The case study we will describe here was performed with the help of the EPOS component-based operating system and a Xilinx prototyping board as the target hardware platform. In order to avoid similar figures, all screenshots previously shown in this paper depict this case study. The Xilinx board used as target contains a Virtex-II FPGA. Besides two built-in PowerPC 405 CPUs in that board (not used), a LEON2 soft-core processor was synthesized along with other IP blocks to create a system-on-a-chip. This board is targeted towards multimedia application prototyping and some of its available devices are: Memory Management Unit (MMU), Floating Point Unit (FPU), Time Stamp Counter (TSC), Interrupt Controller (IC), Data Service Unit (DSU), Watchdog, Universal Asynchronous Receiver/Transmitter (UART), Timer, Network Interface Card (NIC), Audio Decoder, Video Decoder, and Display Controller [6]. The application's source code is written in C++ and is listed below (the same that appears in Figure 2). As we can see, only one method from the EPOS API is called, the play(Log Addr sound, Seconds length, Sample Rate sample rate, Bit Depth bit depth, Sound Mode mode) method from the PCM Audio Player abstraction. The parameters indicate that a 16-bit stereo sound stream sampled at 44.1 khz and stored at the 0x40080000 address should be played for 3 seconds. The PCM Audio Player abstraction provides functionalities related to controlling the reproduction of uncompressed digital audio streams represented with Pulse Code Modulation (PCM). PCM is a standard for digital audio in computers and compact disks (CD) and is the usual output of audio decompressors, such as MPEG-1 Layer 3 (MP3) decoders. The following is a description of the actions and interactions between a developer and the tool when the audio player application is submitted to begin the procedure:
Figure 5 depicts the components included in this case study's configuration and the dependencies existent between them. We found that this tool is adequate for the use case described here, since it satisfies the requirements elicited in Section 3: application analysis; component suggestions, component selection, configuration, and composition; generation of system software and hardware; configuration validation; specific graphical interface; feedback to the developer; and partial automation. Cost estimations, though, is a requirement that currently is not fully supported, since no meaningful estimations for each of the components are calculated. Several other applications, components, and target platforms were tested with the tool. Its strong points are its fast and simple operation and its internal design that features good maintainability and extensibility. Another aspect to consider is the possibility of using it to configure and generate other component-based operating systems. This would be possible if such systems provide some of the facilities EPOS does: a component repository properly described in a language the tool knows how to interpret and a set of makefiles that provide building rules.
Figure 5: Component diagram of the audio player system configuration 6 CONCLUSIONSIn this paper we dealt with the problem of developing embedded systems. Even with component-based design, current solutions do not address efficiently architectural transparency, performance, configuration and generation of application oriented embedded systems. We have shown the basic concepts of Application-Oriented System Design methodology that was developed to solve these problems and we focused here on the final phase of development. We have presented a tool that assists developers in configuring and generating software and hardware support for embedded systems taking as base a collection of reusable components developed according with the Application-Oriented System Design methodology, their dependencies and composition rules. The prototype implements the requirements listed in Section 3, and effectively identifies, selects, configures, adapts, and composes those components, generating real and functional embedded systems. Steps are performed automatically whenever possible by the current prototype and some hints are given when design decisions are required. The developer can focus on his application, not on the underlying support system, which leads to a faster development process and, incidentally, shorter time-to-market for commercial products. As a case study, an example of a configuration process for a simple but real application was presented, as well as the current limitations of the model due to the need of manual selection when more than one di erent component satisfy the required interface. We believe that it represents an important step in the direction of a fully automated generation since we have promoted the generation of software and hardware support and SoC instances in the same generation flow according to a well defined methodology. The strategy currently realized does not represent a complete solution to automate the process of generating SoC-based embedded systems (whereas the programmer still takes some decisions regarding the selection of more than one di erent realization for a component). We believe a more detailed costs model for components and the inclusion of a smarter algorithm to perform design exploration could automatically solve most of the situations. However, some decisions will seldom be fully automatic, such as choosing the best real-time scheduler component that garantees deadlines will be meet based only on application source code and on component interfaces. The components existent in our repository were identified and defined with the AOSD approach, which starts with domain analysis, identification of families, identification of members and aspects. Since great attention is required when performing these steps, the actual specification of components and their features does not require much e ort. A developer needs only to implement their code and add some lines of description in configuration rules files. The maintainance of these components is also not a hard task, since abstraction components will seldom be modified, and hardware mediator ones have different implementations for each platform they refer to. Our road map for future work includes simple improvements, such as the implementation of a convenient GUI that shows numbers and charts that better represent the system, to make the Configurator responsible for finding out if there are any unnecessary, redundant, or not very adequate components, to include convenient repository manipulation functionalities to help developer in managing component implementations, and to provide a simple source code editor for the Analyzer. Finally, the results obtained with Application-Oriented System Design, the EPOS framework, and the tool described in this paper are so far encouraging. Research in progress is looking forward to improve the costs model for components and allow intelligent design space exploration for automatic and adaptive component selection and partitioning. With this, our approach would not only automatically generate systems that match applications requirements, but also design requirements, such as as maximum silicon area or power consumption. REFERENCES[1] Lucas Francisco Wanner Arliones Stevert Hoeller Junior and Antônio Augusto Fröhlich. A hierarchical approach for power management on mobile embedded systems. In Proceedings of the 5th IFIP Working Conference on Distributed and Parallel Embedded Systems, pages 265-274, Braga, Portugal, 2006. [2] Roberto de Matos Danillo Santos, Rafael Cancian and Antônio Augusto Fröhlich. Advantages and disadvantages of application-oriented system design in embedded systems design. In Proceedings of 4th International IEEE Conference on Industrial Informatics, pages 904 - 909, Cingapura, 2006. [3] Antônio Augusto Fröhlich. Application-Oriented Operating Systems. PhD thesis,
GMD - Forschungszentrum Informationstechnik, Sankt Augustin, Germany, [4] Antônio Augusto Fröhlich and Wolfgang Schröder-Preikschat. Scenario adapters: Efficiently adapting components. In Proceedings of the 4th World Multiconference on Systemics, Cybernetics and Informatics, Orlando, USA, 2000. [5] Augusto Born de Oliveira Lucas FranciscoWanner, Arliones Stevert Hoeller Junior and Antônio Augusto Fröhlich. Operating system support for data acquisition in wireless sensor networks. In Proceedings of the 11th IEEE International Conference on Emerging Technologies and Factory Automation, pages 582-585, Prague, Czech Republic, 2006. [6] T. Tierens P. Pelgrims and D. Driessens. Overview: Excalibur, leon, microblaze, nios, openrisc, virtexii pro. Technical report, DE NAYER Instituut, 2003. [7] David Lorge Parnas. On the design and development of pro- gram families. In IEEE Transactions on Software Engineering, pages 1-9, 1976. [8] F. V. Polpeta and A. A. Fröhlich. Hardware mediators: a portability artifact for component-based systems. In Proceedings of the International Conference on Embedded and Ubiquitous Computing, volume 3207 of LNCS, Aizu, Japan, Aug. 2004. [9] P. Pop. Embedded systems design: Optimization challenges. CP-AI-OR 2005 Invited Talk, May, 31 2005. Embeded Systems Lab (ESLAB), Linköping University, Sweden. [10] Gustavo Fortes Tondello and Antônio Augusto Fröhlich. Configuration management of embedded operating systems using application-oriented system design. In Proceedings of the 5th Argentine Symposium on Computing Technology (part of the 33rd Argentine Conference on Computer Science and Operational Research), Córdoba, Argentine, 2004. [11] Gustavo Fortes Tondello and Antônio Augusto Fröhlich. On the automatic con- fi guration of application-oriented operating systems. In Proceedings of the 3rd ACS/IEEE International Conference on Computer Systems and Applications, pages 120 - 123, Cairo, Egypt, 2005. About the authors
Cite this document as follows: Alexandre Schulter, Rafael L. Cancian, Marcelo R. Stemmer, Antônio A. M. Fröhlich: "A Tool for Supporting and Automating the Development of Component-based Embedded Systems", in Journal of Object Technology, vol. 6, no. 9, Special Issue: TOOLS EUROPE 2007, October 2007, pages 399-416, http://www.jot.fm/issues/issue_2007_10/paper20/ |
|||||||||||||||||||
