By paul ~ September 17th, 2011. Filed under: Best Practices, RAMS, SDR & SCA.
We don’t usually think of software porting as an application for modeling and simulation or model-based design. However, some of our customers have not been so narrow-minded, and they are reaping real benefits!
Porting embedded software to new platforms can be a frustrating task. As I write this, I’m smiling, because I’m thinking about all of the times that product managers have nonchalantly planned a port to a new platform believing that it would be inexpensive and then had the project overrun by an order of magnitude. The estimation error is often exacerbated by a number of factors including:
- The software may have been written in a high level language, using all of the latest portability guidelines, so expectations of portability are unrealistically high
- A “skunkworks” project may have performed an initial exploratory port very quickly, giving a false sense of assurance
- Often the software is enhanced at the same time that it is ported, adding both uncertainty and risk
- The new platform behaves differently in subtle and unexpected ways
- Those doing the port are often not the original developers, and they may not have access to complete explanations for why the code “is the way that it is”
I recently ran across a 2002 article by EDN Technical Editor Robert Cravotta aptly entitled “Fear and loathing of porting embedded software.” Mr. Cravotta does an excellent job of discussing these and other embedded software porting pitfalls, as well as their remedies.
Consider these two quotes from Mr. Cravotta’s article:
“You can improve the success of a software port if you perform a requirements analysis and establish your criteria for a successful effort before you start. Defining success criteria provides a basis for your porting decisions and allows you to objectively determine when the port is complete.”
“Define the amount of system headroom you need the port to finish with to be considered successful. You are probably not performing this port just for the fun of it. Your original platform is lacking sufficient headroom to some sensitivity vector. You might need more processor capacity for your new algorithms, or you might need a system that consumes less power. You risk another premature porting effort if you have insufficient headroom after completing the port. Remember that, although you may need to optimize the ported code, the main goal of the porting effort is to transfer a function to a new platform. Balance your project time frame with the system-headroom and -performance requirements. This effort will help you complete a good enough port without expending more time and resources than necessary.”
Making the investment to reverse-engineer an application and build a simulatable model of it will save significant time and money in the long-run. This is particularly true of large, complex applications where the team doing the porting is not the original development team. On the other hand, blindly undertaking such a challenging port will always be much more costly than anticipated. JTRS waveform porting is a case in point.
One of our SDR clients, a true believer from hard experience, recently made this statement:
“The most significant business driver for the ongoing funding of the [waveform] modeling effort is the cultivation of transferable [waveform] expertise within [the company] that is being applied to [multiple] products to solve emerging network operational issues, meet operational requirements and eliminate [the company’s] dependence on [the waveform developer].”
Over the years, disciplined application of our Resource Aware Modeling and Simulation (RAMS) performance engineering process has helped numerous clients dramatically improve the results of their embedded software porting programs. This methodology tames the porting beast in a number of ways, including:
- Minimizing the risk in cost assessments when planning the port. Truly understanding the magnitude of the task can be the determining factor in whether the team gets the contract or funding for the port.
- Providing structure for understanding the application and capturing the knowledge gained by reverse engineering. This captured knowledge yields huge benefits when the port runs into problems.
- Finding and fixing performance problems BEFORE testing does.
- Determining resource requirements (processor throughput, memory, bus bandwidth, power, etc.) early.
- Allowing the team to explore enhancements to functionality and their impacts via simulation before they result in unpleasant surprises for the project team.
Porting embedded software to new platforms is just plain hard, but an approach based on RAMS methodology will manage the complexity. You’ll have a much better understanding of the challenge up front, and you’ll be much more likely to complete the port on time and on budget while meeting all of your objectives.
Trying to port a complex resource constrained embedded system to a new hardware platform without using RAMS makes about as much sense as this: