Developing Reusable Software Components for Embedded Systems

Transcription

1 Developing Reusable Software Components for Embedded Systems ECE750-T11 Component-Based Software Systems Spring 2009 Babak Omidi Tony Zhao Group 6 - Project Presentation 1 Date:

2 Agenda Definitions Background Motivation Literature Survey Problem Formulation Platform Independent Abstraction Architectural Style Components for Embedded Systems 2

3 Definitions Embedded System A computer system that is part of a larger system and performs some of the requirements of that system; for example, a computer system used in an aircraft or rapid transit system (IEEE,1992) [1]. 98% of all computers systems are embedded systems [1]. Components for Embedded Systems 3

4 Definitions Architecture and Architectural Style Architectural styles are recurring organizational patterns and idioms [2]. An architecture is a conceptual model of how a system s components are defined and developed, and how they interoperate [3]. An infrastructure is the implementation of the conceptual model [3]. Components for Embedded Systems 4

5 Definitions Software Component Software Component as defined by Szyperski: A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties [4]. Components for Embedded Systems 5

6 Background Software Component Elements To be able to describe a component completely and to ensure its correct integration and updating, the component should consist of the following elements [5]: A set of interfaces provided to, or required from, the environment. These interfaces are particularly for interaction with other components. An executable code, which can be coupled to the code of other components via interfaces. Components for Embedded Systems 6

7 Background Liberal View of Software Component Elements Some researchers believe that the strict view of Software Component Elements does not work well with the special requirements of embedded systems (e.g. reliability, safety and timing) [1]. Liberal View: To be able to describe a component completely and to ensure its correct integration and updating, the component should consist of the following elements [1]: A set of interfaces provided to, or required from, the environment. These interfaces are particularly for interaction with other components. A source code, which can be coupled to the code of other components via interfaces. Components for Embedded Systems 7

8 Background Liberal View of Software Component Elements Source code does not necessarily need to be modified to adapt the component. However, source code is needed to be compiled on the target platform. Some have chosen to keep a repository of component variants which are optimized on multiple target platforms [6]. Components for Embedded Systems 8

9 Motivation Software reuse is good Recent analysis of more than problem reports collected by the mobile phone company Ericsson in Grimstad, Norway, has shown that software reuse does result in significantly fewer problems and better stability [7]. reused components have significantly lower defect-density than non-reused ones [7]. Component Based Software Engineering (CBSE) enables software reuse [1,8,9] Components for Embedded Systems 9

10 Motivation Cont d The growing complexity of embedded systems requires methods that improve reusability [10]. Software for embedded systems is typically monolithic and strongly platform-dependent [11]. Components for Embedded Systems 10

11 Motivation Cont d Other advantages of using CBSE for embedded systems [11] are: Shorter development time Better maintainability Components for Embedded Systems 11

12 Motivation Cont d Most existing and well known component architectures are not suitable for embedded systems in their current form [12] (e.g. Pipe and Filters, N-Tiered, Layered, Blackboard and MVC). Component models such as.net, J2EE and CORBA Component Model (CCM) cannot be used for embedded systems [12]. Components for Embedded Systems 12

13 Literature Survey [6] proposes a repository of components that contains variants and versions of the software optimized for each target platform. Waste of storage space The component developer needs to predict all future uses of the component. This is not feasible. Components for Embedded Systems 13

14 Literature Survey Open Implementation defines principles for system decomposition and interface design [13]. Requires the programmer to tune the underlying implementation at composition time. Forces the programmer to learn the specifics of the component. The component cannot be treated as a blackbox Components for Embedded Systems 14

15 Literature Survey Component models developed are often targeted to specific application domains [12]: PECOS [11] Koala [15] They do not address the issue of platform specific code. Components for Embedded Systems 15

16 Literature Survey FIRSL (Flight Instruments Reuse & Standardization Library) provides a modified system architecture for Flight Software (FSW) [14] FIRSL publishes standardized API s for reusable device functions Components are open source code units A step in the right direction which needs to be formalized and generalized! Components for Embedded Systems 16

17 Problem Formulation Need to separate hardware independent functionality from hardware specific functionality This needs to be done at the highest level of abstraction A new Architectural Style needs to be developed. Components for Embedded Systems 17

18 Problem Formulation Cont d *From class notes Components for Embedded Systems 18

19 Proposed Architectural Style Platform Independent Abstraction... Hardware Independent Layer... Interface Mapping Layer... Operating System Layer... Hardware/Simulation Layer Components for Embedded Systems 19

20 Platform Independent Abstraction - Example Play MP3 Play Video... Send Fax Make Call Hardware Independent Layer Audio Control Mapper... Dialing Interface Mapper Interface Mapping Layer Hardware Specific Audio Control... Hardware Dialing Control Operating System Layer Physical Audio Control... Physical Dialing Control Hardware/Simulation Layer Components for Embedded Systems 20

21 Platform Independent Abstraction Example Cont d Detailed architectural model to be provided in the next presentation. Essentially a layered architecture Each layer communicates only with the layer below it. Layers below have no knowledge of the layers above. Increasing abstraction towards the top layer Maintainability, Reuse, Portability (replacing layers to work within a different context) Difference is that each layer exports multiple interfaces Components for Embedded Systems 21

22 Platform Independent Abstraction Example Cont d Disadvantages of Layered Architecture are not applicable Universally applicable components by definition cannot spread around different layers Performance is not affected since the levels of indirection get resolved at compile time Determining the correct abstraction level is achieved by definition Layer bridging is not allowed Components for Embedded Systems 22

23 Proposed Architectural Style - Details Hardware Independent Layer Contains all components not dependent on the underlying hardware. All hardware specific details are abstracted away. Components could be composite components. Interface Mapping Layer These are simple components. Translate hardware functionality into hardware independent calls. Operating System Layer Pipes calls to the Hardware/Simulation Layer. Hardware/Simulation Layer Performs/simulates operations requested. Components for Embedded Systems 23

24 Advantages of Platform Independent Abstraction The majority of the software belongs to the Hardware Independent Layer. This includes the logical flow control which is most susceptible to errors. Development of the system is done on a desktop computer and the Hardware Independent and Interface Mapping Layer components are then transferred to the hardware platform. This approach has two advantages: Since desktop computers are much faster than embedded systems, development and testing times are reduced significantly; ultimately improving time-to-market. Development of such a system can be done by software engineers that are not necessarily familiar with the target hardware. This enables the utilization of stronger software developers as supposed to hardware engineers who might not be as proficient in developing software applications. Components for Embedded Systems 24

25 Proof of Concept In order to demonstrate the effectiveness of the Platform Independent Abstraction architectural style, we will be implementing a simple application that will be run on 2 embedded systems in addition to the hardware simulator. In order to do this, we will: Develop and test the Hardware Independent and Interface Mapping components on a windows machine with the help of a hardware simulator. Transfer the components to the target platforms without any modifications and demonstrate 100% component reuse The two targeted platforms will be an ARM4I and an x86 processor. Components for Embedded Systems 25

26 References [1] I. Crnkovic. Component-based approach for embedded systems. Ninth International Workshop on Component-Oriented Programming, Oslo, [2] David Garlan and Mary Shaw. An Introduction to Sofware Architecture: Advances in Sofware Engineering and Knowledge Engineering, volume 1. World Scientific Publishing, [3] Israel Ben-Shaul, James W. Gish, and William Robinson. "An Integrated Netwrok Component Architecture", IEEE Software, Volume 15, Issue 5, pp , September [4] C. Szyperski. Component Software: Beyond Object-Oriented Programming. ACM, Press and Addison-Wesley, New York, N.Y., [5] He Jifeng, Liu Zhiming and Li Xiaoshan. Component Calculus. The United Nations University, International Institute for Software Technology, Report No. 285, Components for Embedded Systems 26

27 References Cont d [6] Mikael Åkerholm, Joakim Fröberg, Kristian Sandström, Ivica Crnkovic. "A Model for Reuse and Optimization of Embedded Software Components", 29th International Conference on Information Technology Interfaces, 2007, pp [7] P. Mohagheghi, R. Conradi, O.M. Killi, H. Schwarz. An Empirical Study of Software Reuse vs. Defect-Density and Stability. 26th International Conference on Software Engineering (ICSE 04), 2004, Edinburgh, Scotland, pp [8] Patrick Tessier, Sébastien Gérard, Chokri Mraidha and Jean-Marc Geib. A Component-Based Methodology for Embedded System Prototyping, Proceedings of the 14th IEEE International Workshop on Rapid System Prototyping (RSP'03), 2003, p.9. [9] I. Crnkovic and M. Larsson. Building Reliable Component-Based Software Systems. Artech House publisher, Components for Embedded Systems 27

28 References Cont d [10] Severine Sentilles, Anders Pettersson, Dag Nystrom, Thomas Nolte, Paul Pettersson and Ivica Crnkovic. Save-IDE - A tool for design, analysis and implementation of component-based embedded systems, 31st International Conference on Software Engineering, [11] Michael Winter, Christian Zeidler and Christian Stich. "The PECOS Software Process", Workshop on Components-based Software Development Processes, ICSR 7, [12] Ihor Kuz, Yan Liu, Ian Gorton and Gernot Heiser. CAmkES: A component model for secure microkernel-based embedded systems Journal of Systems and Software, volume 80, issue 5, May 2007, p [13] G. Kiczales. Beyond the Black Box: Open Implementation. IEEE Software, Volume 13, Issue 1, January 1996, pp. 8, Components for Embedded Systems 28

29 References Cont d [14] D. Mathur, B.W. Edwards, J. Goldstein, H. Nguyen, J. Pine, B.A. Plante, J.C. ThackerAn Approach for Designing Reusable, Embedded Software Components for Spacecraft Flight Instruments, 11th IEEE Real Time on Embedded Technology and Applications Symposium, Pages: , [15] Rob van Ommering, Frank van der Linden, Jeff Kramer, Jeff Magee, The Koala Component Model for Consumer Electronics Software, Computer, v.33 n.3, p.78-85, March Components for Embedded Systems 29