An RTOS API Translator for Model-driven Embedded Software Development *

Transcription

1 An RTOS API Translator for Model-driven Embedded Software Development * Ji Chan Maeng, Jong-Hyuk Kim, and Minsoo Ryu College of Information and Communications, Hanyang University {jcmaeng, jhkim, msryu}@rtcc.hanyang.ac.kr Abstract In this paper, we present a model-driven approach to RTOS-based embedded software development and an automated tool that can produce RTOS-specific code. Our contributions are two fold. First, we defined generic RTOS APIs (Application Programming Interfaces) that can capture most of typical RTOS services but are not bound to any specific RTOS. The generic RTOS APIs can be used as a means for describing application s RTOSrelated behavior at an early design stage. We then developed an automated transformation tool that can generate functional code by transforming generic RTOS APIs into RTOS-specific APIs. Our tool, called TransPI, is able to produce C code aimed at POSIX-compliant RTOSs, and is also configurable to target other RTOSs that do not conform to the POSIX standard. 1. Introduction Increasing software complexity has given rise to model-driven software development. With a model-driven approach, a developer can work at a high level of abstraction since he just needs to focus on building an abstract application model without being concerned about specifics of hardware and software platforms [4, 12]. Automated tools can then be used to produce a final implementation through model-to-code transformation [3, 13]. Thus, the model-driven approach can provide a significant productivity gain, and even alleviate the maintenance problem since software changes can be made by modifying the original model and regenerating the code. Model-Driven Architecture (MDA) of the Object Management Group (OMG) is one of the most noticeable results [1]. An important goal of MDA is to separate the specification of abstract system behavior and functionality from the specification of concrete implementation details. To do so, MDA depends on two important types of models, Platform Independent Model (PIM) and Platform Specific Model (PSM). A PIM is a model that does not rely on any implementation technologies, and can be built using UML (Unified Modeling Language). A PSM is a model that contains enough implementation details so that code can be generated from it. It can be viewed as an intermediate form of the code that combines the specification of PIM with the details that specify how the application uses and interact with a particular type of platform. Therefore, to generate executable code through an MDA approach, we need two stages of model mapping, as shown in Figure 1(A). Unfortunately, MDA provides little support for the development of RTOS-based embedded software. As described in the MDA Guide Version [5], MDA focuses primarily on middleware target platforms such as EJB, Web Services,.NET, and CORBA [16]. These middleware platforms allow applications to run independent of programming language and underlying operating system, thus providing better productivity and portability by hiding implementation-specific details. However, a typical embedded system has crucial requirements such as real-time performance and limited resources. These requirements are commonly supported by a real-time operating system, whereas the use of middleware is much likely to fail to meet these requirements [2]. As a result, many embedded applications are designed and implemented to run directly on top of RTOS (Real-Time Operating System). In this paper, we present a model-driven approach and an automated transformation tool, called TransPI, for the development of RTOS-based embedded software. The proposed approach can be viewed as a variation of MDA with an emphasis on RTOS platforms. As shown in Figure 1(B), a major difference from MDA is that ours can capture application s RTOS-related behavior at an early design stage and produce a concrete RTOS-specific implementation at the final stage. To do so, we first defined generic RTOS APIs (Application Programming Interfaces) that can represent most of typical RTOS services but are not bound to any specific RTOS. In our approach, the generic RTOS APIs are used as a means for * This work was supported in part by the Korea Research Foundation Grant funded by the Korean Government (MOEHRD) KRF D00625 and by IT Leading R&D Support Project funded the Ministry of Information and Communication

2 incorporating abstract RTOS-related behavior into an application design model. We then developed an automated transformation tool that can generate code by transforming generic RTOS APIs into RTOS-specific APIs. Our tool, called TransPI, is able to produce C code aimed at POSIX-compliant RTOSs, and is also configurable to target other RTOSs that do not conform to the POSIX standard [6]. (A) (B) Figure 1. (A) the MDA and (B) our approach. The work reported in this paper is a result of a collaborative project that began early in 2005 between the Seoul National University and Hanyang University. The goal of the project was to develop an integrated modelbased tool set, called HOPES, aimed at embedded software development [7, 8]. As shown in Figure 1(B), our approach consists of three stages. At the first stage, a developer creates an Application Behavior Model (ABM) through specifying application s functionality using a data flow model [14, 17] and generic RTOS APIs. At the second stage, a code synthesizer produces an intermediate form of code, called RTOS Independent Code (RIC). At the final stage, a target RTOS is chosen and the RIC is transformed into RTOS Specific Code (RSC) through TransPI. In the HOPES project, our role was to support the mapping of RIC to RSC, and the work reported here contains our major contributions made for the HOPES project. Specifically, they include generic RTOS APIs to capture application s RTOS-related behavior and an automated tool for RIC-to-RSC transformation. Commercial CASE tools have been available for model-driven software development [9, 10, 11]. Rhapsody by I-Logix [10] is one of them, which has been widely used in industry long before the release of MDA by OMG. Within Rhapsody, a developer can create a PIM using standard UML [15, 18]. Rhapsody can then produce final code directly from the PIM without having an explicit PIM-to-PSM transformation stage. Rhapsody can support the development of RTOS-based software by providing a virtual machine layer, called OS-dependent adapter, which handles interaction with the underlying RTOS. To the best of our knowledge, a common technique to achieve platform independence in existing CASE tools is to target application software for a platform-neutral virtual machine such as Rhapsody s OS-dependent layer. We believe that our transformation-based approach is superior to the virtual machine approach in many ways. First, the transformation-based approach can avoid runtime overheads that would be incurred by the use of a virtual machine layer. Note that a virtual machine should have wrapper functions that invoke real RTOS calls, and this incurs extra overheads both in time and space for every function call. This may be a serious problem for many performance- and resource-critical embedded systems. Second, the transformation-based approach can provide another important benefit for maintaining legacy software that was not developed through a model-driven approach. For example, it is possible to extend transformation tools to support reverse transformation, i.e., code-to-model transformation. Reverse transformation would allow a developer to derive a model from legacy code and then generate another code for a different target RTOS, or to change the legacy software by modifying the derived model and regenerating code. We will show that our TransPI is able to generate RIC (RTOS Independent Code) from RSC (RTOS Specific Code), i.e., reverse transformation. The rest of this paper is organized as follows. Section 2 describes how to develop generic RTOS APIs and how to use them for RTOS behavior modeling. Section 3 describes the design of TransPI. Section 4 presents its implementation and experimental results. Section 5 concludes this paper. 2. A Model-Driven Approach Using Generic RTOS APIs A typical RTOS provides a range of services including task management, memory management, file system management, and I/O management. An important observation is that such RTOS services are available for applications in the form of APIs (Application Programming Interfaces), i.e., networking through socket APIs and inter-process communications through message queue APIs. For this reason, and to permit easy incorporation of RTOS behavior into an application design model, we chose to abstract RTOS APIs for the specification of RTOS-related behavior. Note that a usual RTOS provides more than hundreds of APIs whose semantics and syntax are different across RTOSs. This motivated us to take POSIX standard as a starting point, and also considered POSIX [20] real-time profiles and power management APIs. 2.1 Definition of Generic RTOS APIs POSIX is a set of standards specified by the IEEE to define the application programming interfaces (APIs) for

3 UNIX-based software, and it is now maintained by a joint working group called the Austin Group. The latest version is POSIX Standard which consists of four major components; Base Definitions volume, System Interfaces volume, Shell and Utilities volume, and Rationale (Informative) volume. Here, the System Interfaces volume the actual OS APIs that are defined in eight categories including signal, standard I/O streams, STREAMS, XSI interprocess communication, real-time, threads, sockets, tracing, and others. Note that the POSIX standard is not restricted to OSrelated services. The POSIX standard has been designed to cover all the aspects of application programming. Examples include mathematical functions such as sin() and cos() functions. In fact, the POSIX set is a superset of the standard C library functions (ISO/IEC 9899:1999) and the mathematical functions are supported by the standard C library (math.h). The definition of generic RTOS APIs was rather straightforward. Our approach was to first group related POSIX APIs and organize them into coherent clusters, and then remove redundant or RTOS-irrelevant APIs from them. Note that the POSIX API set contains a number of APIs that have similar functionalities. For example, printf(), fprintf(), and sprintf() have an identical function of printing formatted data except they print to different display targets. Table 1. Generic RTOS APIs (85 APIs in total). Category Task Real-Time Power Memory File Network Device Others Generic RTOS APIs THREAD_CREATE, (21 APIs) MQ_SEND, (15APIs) PM_POWER_OFF,... (8 APIs) MEMALLOC, MMAP, (4 APIs) CHDIR, CLOSE, (17 APIs) SOCK_ACCEPT, (9 APIs) IOCTL, POLL, SELECT (3 APIs) CTIME, GETITIMER, (8 APIs) Our taxonomy of APIs is based on typical RTOS services such as task, memory, file, network, and device management. We reclassified POSIX APIs into eight categories based on these services in mind while separately considering real-time and power management issues. 2.2 RTOS-related Behavior Specification Using Generic RTOS APIs Based on generic RTOS APIs, the application s RTOSrelated behavior can be easily incorporated into a toplevel ABM (application behavior model). This can be best explained through the following example. Figure 2 shows a top-level data flow diagram of H.263 decoder example, which was also used in our experiments. The H.263 decoder consists of five major components: main controller, AVI Reader, Divx decoder, MPEG audio decoder, and frame buffer manager. The main controller is responsible for the execution and coordination of the other four elements by using appropriate RTOS services. Specifically, it creates four threads for pipelined concurrent execution of AVI Reader, Divx decoder, MPEG audio decoder, and frame buffer manager. This requires the main controller to invoke three generic RTOS APIs, THREAD_CREATE, THREAD_JOIN, and THREAD_EXIT. Similarly, the other four components rely on generic RTOS APIs to perform their required functions such as access to multimedia data residing on secondary storage, dynamic allocation of required memory, and destruction of threads. Figure 2. RTOS-related behavior specification with generic RTOS APIs. Note that the above example has been constructed through the entire HOPES tool set. Our approach to the application s behavioral modeling uses a data flow model for describing overall functionality and an extended finite state machine model [8] for specifying detailed behavior of each component. Each component in Figure 2 has been modeled as a finite state machine, whose precise behavior can be specified by a set of states, events, guard conditions, and actions. Here, we do not delve into how the extended finite state machine can specify detailed behavior. Interested readers are referred to [8]. 3. Design of TransPI An important goal of our API translator development is configurability, which is crucial for handling a diversity of target RTOSs ranging from POSIX-compliant RTOSs to those that do not support POSIX APIs. This gave rise to the development of a rule-based API translator, called TransPI. TransPI relies on a set of rules that govern transformation of generic RTOS APIs into RTOS-specific APIs. TransPI allows a developer to modify these transformation rules and/or add new rules. Therefore, TransPI can be configured to target any particular RTOS by specifying transformation rules specific to the chosen RTOS.

4 3.1 API Usage Patterns and Scoping Through a preliminary investigation, we found that many generic RTOS APIs have some patterns in their usage. For example, a SEM_WAIT() that attempts to acquire a lock must be followed by a SEM_POST() that releases the lock. Furthermore, when these APIs are transformed into RSC, some extra routines such as sem_init() and sem_destroy() should also be added at proper locations in the code. 3.2 Transformation Rules TransPI provides a dedicated transformation language that can be used to specify transformation rules. The key elements of the transformation language include 7 major directives: INCLUDE AT, DECLARE AT, INITIALIZE AT, INSERT AT, REPLACE BY, FINALIZE AT, and DELETE. INCLUDE AT: include a required header file at a specified location. DECLARE AT: declare variables at a specified location. INITIALIZE AT: insert an initialization routine at a specified location. INSERT AT: insert a code fragment at a specified location. REPLACE WITH: replace a code fragment with at a specified code. FINALIZE AT: insert a finalization routine at a specified location. DELETE: delete a specified code fragment. Using the above directives, we can specify a family of transformation rules for each API pattern. Generally, each pattern can have at most five transformation rules: initialize, open, transform, close, and finalize rules. Figure 4 illustrates the transformation rules for SEMAPHORE pattern, which is subject to four transformation rules. (A) Before transformation (B) After transformation Figure 3. Transformation of SEMAPHORE pattern into POSIX compliant C code. To handle such patterns in our transformation, we introduced a notion of API pattern into the design of TransPI. We defined an API pattern as a group of one or more APIs that must be used in a synchronous manner to meet their predefined semantics. Figure 3 illustrates an example of RIC and its transformation into POSIX compliant RSC. It shows that SEM_WAIT and SEM_POST constitute a SEMAPHORE pattern and that the transformation replaces SEM_WAIT and SEM_POST with sem_wait() and sem_post(), respectively. The transformation also inserts additional code including: the declaration of a semaphore variable, sem_init(), and sem_destroy(). Our TransPI specially handles some APIs that access shared resources such as semaphores. Such shared resources are often accessed by several concurrent threads and/or processes, and this raises a question of which thread or process should initialize and destroy the shared resources. To address this problem, we chose to create two additional files, init.c and wrapup.c, to insert code required for initialization and finalization at a global scope, respectively. Figure 4. Transformation rules for SEM pattern. 4. Implementation and Experiments TransPI has been implemented in C, and consists of the following three major stages. Stage 1 (initialization): It reads in two configuration files, one for a list of API patterns and the other for a set of transformation rules. Stage 2 (model analysis): It accepts RIC as input and identifies generic APIs and patterns. Stage 3 (code generation): It performs a two-pass transformation based on given transformation. In the first pass, it transforms individual generic RTOS APIs into

5 RTOS-specific APIs. In the second pass, it inserts extra code segment per API pattern. Note that TransPI allows for reverse transformation, i.e., generation of RIC from RSC. This can be done by providing TransPI with a set of rules for reverse transformation. It is straightforward to derive reverse transformation rules from forward transformation rules. Here, due to space limitation, we do not include how to create a reverse transformation rule with a forward transformation rule. Two cases of experiments were performed to validate TransPI. In the first experiment case, we performed intensive tests on TransPI using Open POSIX Test Suite [19]. Open POSIX Test Suite is freely available on the Web and provides a lot of C code that had been written with POSIX APIs. To check if our tool produces operational code for POSIX compliant RTOSs, we manually converted the POSIX APIs in the original Test Suite C code into generic RTOS APIs and then transformed them back into POSIX-compliant C. In the second experiment case, we applied our TransPI for the development of H.263 decoder. Through preliminary work, we had constructed a RIC that consists of five RIC files, MainController.ric, AviReader.ric, DivxDecoder.ric, MpegAudioDecoder.ric, and FrameBufferManager.ric. TransPI was then used to transform each RIC file into POSIX-compliant C code. We compiled the resulting files and executed the resulting H.263 decoder on top of Linux. Figure 5 shows a snapshot of the produced H.263 decoder running a multimedia application. Figure 5. Snapshot of H.263 decoder. 5. Conclusion In this paper we presented a model-driven approach and a support tool for the development of RTOS-based embedded software. Our major contributions are: (1) generic RTOS APIs that can be used to specify RTOSrelated behavior at modeling level, and (2) an automated tool that can produce RTOS-specific code from RTOSindependent code. There are several future research directions. First, we may extend TransPI to support automatic reverse transformation and this would provide substantial benefits for legacy software management. Note that even with current implementation of TransPI, it is possible to perform reverse transformation by manually specifying the rules for reverse transformation. However, we found that this is time-consuming and error-prone, and we are working on a supplementary tool that can automatically generate reverse transformation rules from forward transformation rules. Second, we will explore the problem of how to incorporate our approach and tool into the existing MDA framework. This problem seems very challenging since we have to find how to combine UML and the notion of generic RTOS API for building a PIM and how to transform the combined model into a PSM. References [1] Thomas O. Meservy and Kurt D. Fenstermacher, Transforming Software Development: An MDA Road Map, IEEE Computer, 38(9): 52 58, September [2] Pieter Van Gorp, Dirk Janssens, and Tracy Gardner, Write Once, Deploy N: a Performance Oriented MDA Case Study, Proceedings of the 8 th IEEE International Enterprise Distributed Object Computing Conference, pp , [3] Jana Koehler, Rainer Hauser, Shubir Kapoor, Fred Y. Wu, and Santhosh Kumaran, A Model-Driven Transformation Method, Proceedings of the 7 th IEEE International Enterprise Distributed Object Computing Conference, pp , [4] Joao Paulo Almeida, Remco Dijkman, Marten van Sinderen, and Luis Ferreira Pires, On the Notion of Abstract Platform in MDA Development, Proceedings of the 8 th IEEE International Enterprise Distributed Object Computing Conference, pp , [5] Object Management Group Inc., "MDA Guide v1.0.1," June [6] The Open Group, "The Open Group Base Specification Issue 6, IEEE Std , 2004 Edition," [7] HOPES, [8] Soonhoi Ha, Hardware/Software Co-design of Multimedia Embedded Systems: PeaCE Approach, white paper, [9] International Business Machines Corporation, "Rational Rose-RT," [10] I-Logix, "Rhapsody," [11] Telelogic AB, "TAU," [12] Stephen J. Mellor, Kendall Scott, Axel Uhl and Dirk Weise MDA Distilled: Principles of Model-Driven Architecture, Addison Wesley, [13] Anneke Kleppe, Jos Warmer and Wim Bast, "MDA Explained: The Model Driven Architecture: Practice and Promise," Addison Wesley, [14] David Harel. "Statecharts: A visual formalism for complex systems," Science of Computer Programming, 8(3): , June [15] Grady Booch, James Rumbaugh, and Ivar Jacobson. "The Unified Modeling Language User Guide," Addison Wesley, 1999 [16] Object Management Group Inc., "CORBA/IIOP Specification," [17] Dohyung Kim and Soonhoi Ha, "Static Analysis and Automatic Code Synthesis of flexible FSM Model," ASP-DAC 2005, January [18] Stephen J. Mellor and Marc J. Balcer, "Executable UML: A Foundation for Model-Driven Architecture," Addison Wesley, [19] Open POSIX Test Suite from A GPL Open Source Project, [20] The Open Group, "IEEE Standard for Information Technology Standardized Application Environment Profile (AEP)-POSIX Realtime and Embedded Application Support, IEEE Std ,"