Costin Radulescu
USC
CSCI 589
Fall 2015

• Introduction
• Definition
• About Reuse (General):
• Why
• Where it happens
• Reuse on embedded platforms:
• Where we reuse & What
• How is it accomplished
• Pros and Cons
• Conclusion

• Some definitions:
• “The ability to use software routines over again in new applications” (PC Magazine) – Wow!
• “Use of existing assets in some form within the software product development process. Assets are products and byproducts of the software development life cycle and include code, software components, test suites, designs and documentation.” (Wikipedia) – Interesting - more Wow!
• “The process of creating software systems from predefined software components.” (Industry: “Select Business Solutions, http://www.selectbs.com/software-assetmanagement/software-reuse “) –Today!
• …OK, lets take a closer look.

• Reduce bugs (Quality code)
• If it’s proven to work before, don’t rewrite it.
• Reduce Cost
• Reuse, thus write less software (but remember that there was an initial development cost at some point).
• Constructive Cost Model (Barry Boehm’s COCOMO)
• Get the job done faster (faster time-to-market)
• This topic is still under debate. Some research suggests that is not necessarily the case.
• Recognition
• Branding.

• Classic case:
• Compiler: ForTran, C, C++, Java
• Function level
• Function to calculate mean solar time
• Object level
• Inheritance
• Components
• Drivers, OS, Web Service (the browser!)
• Non-functional requirements and Quality Attributes
• Performance, security, extendibility, etc.
• Very important in the Critical Embedded Systems (CES) world!

• Embedded software runs close to “the metal”
• Does not run on tis own (e.g.: require extra setup steps).
• Kinds of reuse :
• System software reuse
• Assembly language translator (compilers)
• Interpreters to map to the hardware platform
• Application software reuse
• Real-time operating system
• Software libraries
• Non-Functional reuse
• Critical and non-critical Quality Attributes (QAs)

• Typically a compiler is used to generate code for various chips:
• C is usually the language of choice:
• Reusable: write the code in C once, and generate it for all chips
(with the proper compiler, of course)
• BUT a common barrier to reuse:
• Purists still write assembly for maximum performance
• Caveat is that you have to (re)write code for every chip out there.
• The good: Microprocessors are getting faster and faster, that hopefully this will not be a debate anymore.

• Provides:
• “Glue” between the chip and any peripherals.
• Control & Information exchange between the chip and peripherals.
• A refactoring layer is common way to abstract platform specific services (i.e.: registry, interrupts, etc.)
• BUT a common barrier to reuse
• Program “close to the metal” to meet QAs such as performance, security.
• Embedded software is filled with such code!

• The Real-time Operating System (RTOS)
• It is what the embedded application uses to run on.
• Provides API-like calls to wrap low level calls to the bare-metal.
• High dependency to this API implies more lock in to the
RTOS.
• Reuse of an abstraction RTOS level is nice, BUT:
• Cost of performance, footprint, even speed!

• Non-functional attributes are essential in embedded systems:
• Separated in:
• Critical:
• Security
• Performance
• Non-critical:
• Extendibility
• Reusability
• Understandability
Source: [2]
• In Critical Embedded System (CES) [2]:
• Non-critical QAs are compromised in favor of critical ones.
• Quality trade-offs are more frequent among critical attributes

• Two approaches to reuse in embedded software:
• By Layers [3]:
• Provide abstraction layer for Hardware and RTOS
• By Component Factory [3]:
• An expert system generates code for specific hardware and software layer based on a user-defined set of parameters.
• This is the current status quo in the industry and more vendors are providing support for these expert systems.
• In the non-functional attributes critical attributes may pose hard constraints, which may tip the scale of reuse [2]:
• I.e.: Performance negatively affects reusability!

1 2
Source: [3]
The Hardware Abstraction layer
(HAL) acts as a buffer that insulates from any hardware specific details.
The tope level application will never talk directly to the h/w [3].
Source: [3]
The RTOS porting layer severs as an abstraction layer for the RTOS.
Causes the highes layer application to stay unchanged while swapping out various RTOS’ and/or h/w [3].

• Pros:
• Obvious advantages: free from lock-in.
• Cons:
• As mentioned earlier: indirection will introduce inefficiency, thus performance could be affected.
• Different RTOS’ might handle things differently
• More testing might be required
• Cost might increase

• Component factory:
• Expert system able to generate required code for specific platform based on an initial set of input parameters [3].
Nice!
• The Factory is:
• Collection of things needed build a driver.
• Interface to configure certain function in a driver.
• Knowledge base for how things relate to each other.
• A button to generate the required code.

• Pros:
• Instead of rewriting software, just reconfigure the factory and re-generate the code.
• Cons:
• Expert system must know about any other/new platform that it needs to generate code
• Depends the vendor’s adoption of the expert system
(High Risk item)

• Because of its capacity to generate code, the
Component Factory does not do indirections, but rather direct substitutions for the actual RTOS specific code:
• This is known as RTOS agnosticism.
• True RTOS independence design.
• The software you build is only as good as the collection of components out of which you are able to build [2].
• This is known as arbitrary extensibility.

• Instead of applying reuse at the code level, let’s apply it to the software behavioral requirements level [1]:
• This will allow engineering teams to tailor reused components and design them to fit their needs rather than requiring them to fit their needs to a particular piece of code [1].
• I.e.: if A and B are received by C, then D has to determine the number of times E’s LED has to blink.
• This is an early stage model based system engineering (MBSE)

Source: [1]
• This requires a strict adherence to the architectural principles
• In practice it’s challenging to keep code and architecture lined up, unless, of course, the code is generated automatically from the architecture/model.

• Component factory represents a major paradigm shift.
• Each solution for re-use comes with some compromises:
• Proprietary dependencies
• Non-functional attributes compromises
• The ever evolving hardware forces a tie to a specific manufacturer for obvious reason of reusing software to initialize and control the hardware.
• Model based reuse requires huge discipline and overhead.

• [1] Levenson N.G., Weiss K. A. 2004. Making Embedded
Software Reuse Practical and Safe.
• [2] Feitosa D., Ampatzoglou A., Avgeriou P., Nakagawa E.
Y. 2015. Investigating Quality Tradeoffs in Open Source
Critical Embedded Systems
• [3] Oshana and Kraeling. Software Engineering for
Embedded Systems: Methods, Practical Techniques, and
Applications - Chapter 9: Software Reuse by Design in
Embedded Systems