XCELLENCE IN AUTOMOTIVE & ISM
Sprint Backlog
Daily Scrum
Meeting
Backlog Tasks
Expanded
by Team
Incompatible Middleware
When developing embedded software,
you almost never implement every line of
code from scratch. Instead, various tools
are available to make the firmware designer
more productive. These range from
simple drivers to network stacks to operat-
24 Hours
Product Backlog
as Priortized by Product Owner
Design Tools Must be Reliable, Too
Demonstrable
New Functionality
Source: Adapted from Agile Software
Development with Scrum by
Ken Schwaber and Mike Beedle
Figure 6 – The team identifies a “sprint backlog” of work tasks for each sprint in the cycle, expands
and assigns them, and then reviews progress and removes roadblocks during a daily “scrum” meeting.
The team delivers product functionality to the customer at the end of each sprint.
ing systems and even code-generation
tools. Though these systems are generally
well tested individually, no software is
bug-free. With so many possible combinations
of tools and libraries, the likelihood
of using components together in a novel
way is relatively high.
For this reason, the FDA mandates that
for all off-the-shelf software used in medical
devices, companies must validate that the
software stack works for each of their particular
design’s specific use case. What does
that mean? If, for example, we are using a
signal-processing library that contains a
fixed-point fast Fourier transform and we
are detecting the presence of a certain frequency
component, we do not need to validate
that the FFT returns the correct answer
for all possible inputs. Rather, we need to
validate that it returns what we expect for all
valid inputs according to specifications. For
example, if we are detecting only tones audible
to humans, there is no reason to test that
the function returns correct values for
inputs over 20 kHz.
Unfortunately, software components
that seem independent are not necessarily
so. Therefore, if we are using that software
stack with an SPI driver coupled with a
real-time operating system (RTOS), we
need to validate all of these components
together to really have confidence in the
FFT. If the FFT passes a valid output to the
SPI driver, but the SPI driver crashes, then
clearly there is a problem. If we then decide
to modify the SPI driver, we need to validate
the entire software stack again. This
An important part of HEI’s design methodology is our tool set. Because the FDA regulations are so stringent for medical
devices, companies that develop medical products are wise to use tools that are mature (not buggy themselves) and
have a reputation for reliability. For example, among the many reliable tools we use in our flow is National Instruments’
LabVIEW Real-Time and LabVIEW FPGA. We use this high-level programming tool to efficiently define a solution to a
given problem. Specifically, we apply LabVIEW FPGA to our design flow process to develop IP on accelerated time lines,
with fewer development translation errors and no software rework. LabVIEW’s multicore characteristic helps in deploying
code to multiple processors.
We also leverage proven hardware building blocks such as NI’s Single-Board RIO hardware, which shares both a real-time
processor and a Xilinx FPGA. Because so many companies have used the RIO hardware and the underlying middleware drivers
in a broad range of applications, we consider them very reliable. This gives us peace of mind and allows us to focus on
moving as much software as possible out of the processor and into the FPGA. It also allows us to concentrate on designing
the custom circuitry that a particular product requires.
Other off-the-shelf tools our design team relies on include IBM Requisite Pro for requirements management, the Tigris
SubVersion configuration-management software for documents and source code tracking, the Seapine Test Track Pro for
defect tracking, SolidWorks for mechanical modeling and SolidWorks PDMWorks for mechanical-file management. For
PCB electronics design, we use the Mentor PADS Suite. – Chuck Russo
32 Xcell Journal Fourth Quarter 2009