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
   December 2007
   January 2008
   April 2008
   May 2008
   June 2008
   September 2008
   December 2008
   January 2009
   March 2009
   April 2009
   June 2009
   August 2009
   September 2009
   November 2009
   February 2010
   April 2010

Subscribe to Posts [Atom]

SCOMO Goes Beyond FOTA and Focuses on Managing Individual Software Components

By Elad Ganot
Director of Standards and Alliances
Red Bend Software

Last month I enthusiastically purchased an advanced home entertainment system. I paid a lot of money to enjoy its high sound and picture quality, which were enabled by the cutting-edge technology that’s available in today’s market. It took me about seven years to upgrade my system even though I am a gadget fan and have a technical background. My new system is composed of an HDTV, an advanced receiver (which includes an image enhancer), a media streamer and a DVD player. You might wonder why isn’t Blu-ray part of my system—especially if I want to enjoy high definition movies. The DVD won’t help me so much as it cannot store the capacity required for HD quality. Well, as you may know, there is still doubt on whether Blu-ray will indeed become the next mainstream format for movies, so I’ve decided to wait and see. I can always upgrade separately my existing DVD to a Blu-ray (or whatever other format wins the market). Upgrading my DVD will not force me to upgrade the whole system because it is a stand-alone part with well-defined interfaces to the rest of the system. This makes it a “component.” When the time comes, I will receive an email telling me about this cool new device and for the right price I would click the “buy it now” button, and a delivery package will be on its way to my home.

Going from the hardware world to the software world, things look even cooler. Here not only do components are upgradable, but also they even do so almost instantly and quite frequently. I change software components on my computer at least 100 times a year (not just once every few years). I install software, update existing software and uninstall software that I don’t use. Sometimes I just disable software for a while and re-enable it later. Yeah, I like tweaking the software on my computer, and recently I started playing with my mobile phone in the same way. My mobile phone has so many software components available for it that I even abandoned my stand-alone PDA, which had served me loyally for several years.

Most users are not even aware of the fact that their mobile phone could actually be used as a personal computing platform. They probably know they can customize it in terms of a fashionable look (with wallpapers, sounds and colorful covers), but will they know how to discover a useful software component? Then be able to download it? Install it? Disable it if needed and re-enable it? Remove it?

It was back in 2005 when the mobile industry saw an opportunity to improve the user experience with regard to software management and offered a service of managing the “life cycle” of software components on remote devices. To be able to realize this concept, you have to achieve a mass market, and the industry must agree on some common methods of communication—to allow for every device on every network to connect to the service, regardless of the manufacturer of the equipment (be it a managed client device or a managed server). The good news is that we NOW have a consensus with the Candidate Release of SCOMO 1.0 that was ratified by the OMA on Nov. 17.

Now let us componentize the last sentence in a reversed order:

Open Mobile Alliance (OMA) is the open organization that develops service enablers for the benefit of the mobile (and recently fixed-line) industry. If you are using Multimedia Messaging Service (MMS), then you are already using an enabler developed by the OMA.
Software Component Management Object version 1.0 (SCOMO 1.0) is the name of the service enabler that allows a service provider to remotely manage software components on connected devices.
Candidate Release is a major milestone in the development of OMA enablers. It denotes that the enabler is ready for implementation and is about to go through a phase of interoperability testing. If a concrete interoperability issue is identified during the testing phase, then a standard solution can be found and incorporated into the official specifications. Once no more issues are found and interoperability testing is sufficiently successful, the enabler is promoted to Approved status.

But a Candidate state also means a lot from a business perspective. Interoperability testing period typically happens in parallel to commercial deployments of the enabler. This means that Candidate Release of an enabler is a signal for businesses to start implementing commercial deployments, since the enabler is stable.

In mid-2006, the OMA published the Candidate Release of Firmware Update Management Object (FUMO), which allowed mobile operators to offer a service of updating the firmware of a connected device over the air, without bothering the consumer to physically bring the device to a store. This enabler—which was later Approved in early 2007—has revolutionized the way firmware is managed and had significant results in productivity of consumers as well as mobile operators and handheld manufacturers. It saved costs and, at times, was a means for rolling out new service features and services. To date, hundreds of millions of devices worldwide have been using FOTA, and it serves as evidence for the success of the FUMO enabler.

Much of the lesson and design details of SCOMO are based on FUMO, but with a major difference in mind. This time it’s all about software components over the air (SCOTA) rather than a single monolithic firmware image being managed. It is a more complicated task to manage separate components than it is to manage a single firmware, which is why FUMO is not appropriate for performing SCOTA. But SCOMO is still based on design principles learned from the successful FUMO standard. In that sense, SCOMO can be considered as an evolution of FUMO. But make no mistakes, these two are complementary to each other and they will live side-by-side. They are tools designed for similar but still different purposes. Coming back to my neat home entertainment system analogy: I would use FUMO to update the whole system in one piece, but I would use SCOMO to update just my DVD component (hopefully sooner than later).

For more information about SCOMO, please read the following:

"SCOMO: Enabling the Remote Lifecycle Management of Software Components" at http://www.redbend.com/resources/scomo.asp and
Wireless Week’s “Inventory Changes Everything” at http://www.redbend.com/news/view_article.asp?ID=605&TypeID=2.

Labels: design, device management, DM, firmware, FOTA, mobile, mobile software management, Red Bend, standards

posted by Red Bend @ Tuesday, December 2, 2008 - 11:23 AM 0 Comments

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