Agile Development Methodology for Embedded Systems: A PlatformBased Design Approach

1
Agile Development Methodology for Embedded
Systems A Platform-Based Design Approach
Federal University of Amazonas
14th Annual IEEE International Conference and
Workshop on the Engineering of Computer Based
Systems (ECBS). March 26th-29th, 2007 - Tucson,
AZ U.S.A
Lucas Cordeiro lcc_at_dcc.ufam.edu.br
2
Agenda

• Introduction

• Proposed Agile Development Methodology

• Applying the Proposed Methodology

• Summary and Outlook

3
Introduction
The cost/performance relation is a decisive
paramter for the market sucess of any product
Difficulties
Trends

• Microcontrollers becoming cheaper,
• smaller and more reliable.

• They may place code size, energy
• consumption and timing requirements.

• It often needs to develop in low-level
• programming languages.

• Use of embedded computers in
• a wide range of system.

• Embedded systems contain dedicated
• hardware and software.

• Functions demanded for embedded
• systems are increasing.

• Development teams usually do not
• adopt software engineering concepts.

• Development time is increasingly
• difficult to predict and control.

4
Problem
"How to adapt system development methodologies in
order to balance production cost with development
time in view of performance and functionality
constraints?"
5
Motivation
New Product Development

• Rarely possible to create up-front unchanging
  and detailed specification
• at the beginning of the project.

High degree of novelty, creativity, and change.
new technologies, process, and tools
adaptive planning driven by build-feedback cycles.

• New product development at the core
• of the agile and iterative methods.

Platform-based design and agile methods share
common themes such as uncertainty and flexibility
to changes.

• Platform-Based Design Reuse,
• flexibility and efficiency.

6
Definition
What does agile mean? Is it simply fast?
Agile?
Not Agile?

• Tigers and racing car drivers may all be agile.

• Cows and Elephants may not be agile.

The definition of agility is

• Speed To be first in the market.
• Nimble To be able to improvise and create new
  solutions (flexible).
• Adaptable Dynamic and interactive in response
  to changing requirements.
• Resourceful Thoughtful or exhibiting some
  discipline.

Levine, SEI
Which kind of application does the proposed
methodology apply?

• Medical devices

• Communication

• Process control

• Household appliances

• Scientific instruments

7
Research Goal
"Adapt the agile methods for embedded systems
domain by integrating processes, practices and
tools to balance cost/performance relation"
8
Agenda

• Introduction

• Proposed Agile Development Methodology

• Applying the Proposed Methodology

• Summary and Outlook

9
Proposed Agile Development Methodology (1)
Overview of the Proposed Methodology
The proposed methodology aims to define roles and
responsibilities and provide processes,
practices and tools to be applied in embedded
real-time system projects.
? The system platform processes group aims to
instantiate the platform for a given product.
Product management processes group
System platform processes group
Product development processes group
? The product development processes group offers
practices to develop the application's components
and integrating them into the platform.
? The product management processes group monitors
and controls the product scope, time, quality,
and costs parameters.
10
Proposed Agile Development Methodology (2)
Roles and Responsibilities
Platform Owner The person who is officially
responsible for the products that derive from a
given platform.
Product Leader Responsible for the
implementation, integration and test of the
product ensuring that quality, schedule, and cost
targets are met.
Feature Leader Responsible for managing,
controlling and coordinating subsystem projects,
pre-integration projects, external suppliers.
Development Team Consists of software and
hardware engineers
who are responsible for the product development.
11
Proposed Agile Development Methodology (3)
Processes Lifecycle

• The proposed agile methodology consists of five
  phases Exploration,
• Planning, Development, Release, and
  Maintenance.

12
Agenda

• Introduction

• Proposed Agile Development Methodology

• Applying the Proposed Methodology

• Summary and Outlook

13
Applying the Proposed Methodology (1)
Case Study Description

• The pulse oximeter measures the oxygen
  saturation in the blood system.

• The level of the oxygen saturation and cardiac
  frequency must be shown every second.

Source http//www1.vghtpe.gov.tw

• The user must be able to change the alarm
• configuration.

This project is typical of many real-time
embedded projects.

• The user interface must have a keyboard and a
  graphical display.

• The design of the system should be highly
  optimized for life-cycle cost and effectiveness.

• The amount of software defects should be as low
  as possible.

• The design required a 8-bit micro-controller and
  about 5000 lines of
• embedded code (C and Assembly).

14
Applying the Proposed Methodology (2)
Process for Implementing New Systems
Functionalities

• To implement systems functionality, we should
  write the unit test for this
• functionality and thereafter we should
  successfully compile the unit test.

• Distinguish between components that are driven
  by the environment (stub),
• and those that drive hardware (special type of
  unit test!).

• We must avoid debugging hardware and software
  simultaneously by running
• the application on a desktop PC as well as on
  the target CPU.

Unit tests can address logic but not timing
15
Applying the Proposed Methodology (3)
Process for Refactoring the Code

• Identify in further sprints opportunities to
  improve an existing code.

• The level of the oxygen saturation (SpO2) and
  cardiac frequency (BPM)
• functionalities have some tasks in common.

• This process would lead to elimination of
  duplicated code and reduction of the
• number of system's functions.

• The system designers might decide to
• move a function from software running
• on a processor to a hardware block.

• A HW/SW partitioning can achieve
• performance and energy consumption
• results superior to software-only
• solutions.

16
Applying the Proposed Methodology (4)
Process for Instantiating the System Platform

• Estimate the pulse oximeter metrics to define
  the system platform.

• Specify the system functionalities in UML.

Consider the resulting design as a sketch with
the purpose of exploring the design alternatives

• The code could be generated in the
• language selected by system designer.

• Hardware/Software estimation tool could
• be used to estimate the metrics.

• Hardware/Software partitioning tool looks
• for the best partitioning.

• Incorporate the application constraints into the
  objective function.

17
Applying the Proposed Methodology (5)
Process for Optimizing the System

• Identify system's variable that could be
  optimized in order to meet the
• system's constraint.

• Establish the metrics and ensure that the
  refactoring process has already
• been applied.

• Run a profiler tool to monitor the program and
  tell where it would be
• consuming time and energy.

Analysis of 3 Metrics
- Energy Consumption Analysis
- Power Analysis
- Execution-time Analysis
For each metric, 3 options available
- Probability Distribution
- Scenario Analysis
- Probability Sweep
18
Agenda

• Introduction

• Proposed Agile Development Methodology

• Applying the Proposed Methodology

• Summary and Outlook

19
Summary and Outlook
Summary

• Apply agile principles, practices, and patterns
  to embedded systems.

• Adopt processes and tools to optimize the
  product's design.

• Support software and hardware development.

• Instantiate the system platform based on the
  application constraints.

• Use system platform to conduct design space
  exploration.

Outlook

• Formal models to achieve better results in terms
  of functional correctness.

• Planning experimental studies where the
  methodology will be observed.

• Develop a HW/SW partitioning tool that is
  transparent to system designer.

20
QA
http//www.benq-siemens.com