ENGLISH 日本語中文 한국어		CUSTOMER SUPPORT SITE MAP

RESOURCES

White Papers

Product Literature

Research Reports

Standards Leadership

Red Bend Blog

   June 2007
   July 2007
   August 2007
   September 2007
   October 2007
   November 2007

Subscribe to Posts [Atom]

Improving the Management of Mobile Software

By John Purcell
Director of Terminals and Platforms
Red Bend Software

There’s a lot of discussion these days about how to improve the management of mobile software. Handset manufacturers are rethinking their architectures, analyzing modularized platforms and examining techniques such as storing programs in a User File System. Their goal is to gain greater access and control over individual software components after the phone has shipped, so that new core applications can be changed, services can be added and features can be customized.

But as we all know, it’s not that easy to create a silo of software inside a mobile phone. As software is developed, there are dependencies and hooks that reach into all layers, including in embedded software residing in ROM.

Take a web browser, for instance. A web browser may require dozens of other software components in order to fully function, such as embedded media players, video streaming components and UI resources. “Containing” the web browser is difficult, because other programs also clearly depend on some of those components.

We can no longer rely on layered but physically distinct frameworks to comprehensively manage the growing amount of software in increasingly sophisticated mobile devices. Manufacturers need management flexibility both for devices that store embedded statically-linked software and devices that employ a more modular and dynamic architecture, including open source platforms.

There are many current and emerging approaches to mobile software management. When evaluating each approach, manufacturers and platform providers should ask:

Can it work across multiple device architectures and platforms?
What existing and emerging standards does it support, to ensure interoperability?
What type of software can it manage, including software embedded in ROM?
Is it scaleable for managing individual software configurations at the mass market level?
Is it reliable, fault-tolerant and secure?
Is it consumer-friendly?

Most importantly, a powerful mobile software management solution should adapt to how software is designed, without imposing restrictions to architecture in order to achieve so-called management.

To learn more, read my article published in Wireless Design & Development called, “Beyond Platformization: Using Mobile Software Management to Achieve Feature Customization of Mobile Phones.”

Labels: design, mobile software management

posted by Red Bend @ Tuesday, September 18, 2007 - 1:11 PM 0 Comments

The “Short Blanket” Effect – Engineering Challenges in Implementing FOTA

By Sharon Peleg
Founder and CTO
Red Bend Software

Updating mobile firmware is not a simple task. Some have compared it to updating software on a PC, but there are in fact many engineering challenges that make updating mobile firmware much more difficult. While the generator running on a PC in the office can practically enjoy no resource limitations, the design of the update process on mobile devices must take into account the lack of any auxiliary data, lack of extra storage to be used as temporary buffers, lack of RAM in some cases and a much weaker CPU. Ineffective approaches could easily lead to conflicts between the various resources, and result in the “short blanket” effect – if you pull it from one side, the other side is left uncovered.

When evaluating, testing and integrating FOTA on mobile devices, manufacturers and operators should consider the following:
· Speed, accuracy and predictability of update generation
· No spare flash memory on the device
· Fault tolerance
· Size of the delta file and update package
· Positive user experience
· Updating compressed firmware
· Type of flash memory

In this blog entry, I will address the first three.

Speed, Accuracy and Predictability of Update Generation
The update algorithm must be fast enough to generate updates at a reasonable speed and should provide sufficient feedback to allow proper understanding of the behavior of the update process on the device. Another equally important requirement is the need for the update generation to be predictable. It is not only sufficient that the generator will produce a small update when few changes are introduced to the source, it must do so consistently.

No Spare Flash Memory on the Device
The fact that there is no spare flash memory for building two side-by-side alternating versions when updating the new version (as some embedded devices can afford to have) leaves no option but to perform an update in-place. In-place delta-updating is challenged by limited spare flash and RAM resources to hold the new version.

Fault Tolerance
When updating firmware on mobile devices, it is crucial to assume that the process could be interrupted at any point in time due to a power failure. Power failure during flash re-programming not only can corrupt the written flash sector but also leave the device in a useless state. In addition to having to be both in-place and fault-tolerant, the process must run at maximum speed to minimize downtime. Fault tolerance requires writing additional data when updating in order to maintain the integrity of the persistent data at any point in time. The challenge here is to minimize writing data in order to minimize the number of re-flash operations.

Learn more about implementing FOTA in our new white paper, “Principles of Updating Mobile Firmware Over-the-Air”.

Labels: FOTA, mobile, software

posted by Red Bend @ Monday, September 10, 2007 - 12:31 PM 0 Comments