Netcentric View:

Time to Change OEM channels?

By Bernard Cole
iApplianceWeb
(01/16/03, 10:54:18 AM GMT)

What are embedded hardware/software tool companies, or for that matter, the system developers who depend on them, to do when the marketplace starts changing OEM channels in mid-broadcast?

With nearly ubiquitous Internet connectivity, every aspect of how embedded computing and control devices are designed, tested, built, and used has to be rethought in the context of the fundamental change in the underlying computing model. Previous tools, methodologies, operating systems, and processor architectures must be reevaluated. In addition, it will be necessary to find or develop new tools and building blocks appropriate to this environment.

But some embedded developers tell me that the changes are much more fundamental than that: the traditional OEM channels they previously depended on may or may not have the tools, the additional application software, or the operating system specific to the new requirement or to the hardware. Throw into this mix the shift to system-on-chip levels of integration, and the traditional ways to get the technical help and tools and products goes right out the window.

If this just happened once, developers say that they would go with the flow, adjust their design methodologies, tools, the companies and the OEM channel sources they previously relied on, and then get on with the job. But it keeps happening again and again: a change in the communications protocol, a further improvement in the underlying standards, or a change in the bandwidth constraints and the effect this has on the ability of the control devices to respond properly. And on and on.

Nor has it been easy for the companies supplying the hardware and software. The hardware manufacturers face a plethora of technical and business-related issues that are increasing in magnitude as the current unsettled market shows no signs of stabilizing. At the same time, the hundreds of companies that supply embedded software to these manufacturers face major hurdles in getting their products to market in an effective and cost-efficient manner. Taken as a whole, these issues have led to a highly fragmented and unprofitable embedded software industry.

The Internet-centric computing environment is not just a "convergence"; it's a collision, and it hits suppliers where it hurts -- in the pocketbook. Adjusting to every change requires effort and resources. In any environment, whether physical, biological or social, when two systems in steady state with well-defined connections between constituent elements collide the result is not another steady state. Rather is another chaotic one in which are previous causal connections disappear and new ones must be established.

What is confusing is the sheer number of new elements that have been introduced into the mix, says Curt Schacker, former marketing VP at Wind River Systems in Alameda, Ca., who's spent a lot of time trying to figure out the dynamics of this new environment. He cites new fabrication methodologies, such as SOC and high-density programmable devices; new architectures such as the data flow designs used in network processors. Because of connectivity, all of the elements to accomplish a task may now no longer reside on the device; they may be distributed throughout the network.

Shacker says the assumptions the engineer once made may not be true in the future, given the accelerating pace of integration and the changing nature of the Internet-centric computing environment. In addition, the underlying embedded networking infrastructure is still stuck between architectural paradigms -- one which uses many instantiations of the familiar RISC architecture, executed in parallel to achieve the necessary gigabit-per-second throughputs and the alternative, in which new dataflow architectures are used. In the former, familiar programming methodologies can be used, and in the latter, much more parallelized methods must be used.

"In the last ten years, we've seen embedded devices go from relatively simple, standalone products with well understood software requirements to highly complex, networked devices with huge demands placed on the embedded software," says Schacker. "In the early 90s, a simple scheduler with some facility for I/O was typically a sufficient starting point for most applications. Now these devices require sophisticated software features, such as full-featured operating systems, complex communications protocols, distributed data management, advanced security, and network management."

For help, embedded developers have turned to the traditional OEM channels they once depended on, and they discover that:

• The company they used to rely on is still there but doesn't have the expertise they need nor the resources to get it;

• The company has gone out of business or shifted for economic reasons to another more lucrative and stable market; and

• the company has been acquired by a larger company that has other plans for the tools, OSes and building blocks engineers depended on and has no interest in developing the ones needed.

Schacker , who is now a managing partner with Embedded Solution Partners, thinks what is needed are companies with a new kind of business model. They cannot be wedded to any particular market segment, and would serve as brokers and middlemen with expertise not just about specific application domains but the connectivity elements and middleware needed to make a system work in the new environment. Most important, he says, "the companies based on the new model will have to be fast on their feet, keeping track of changes in markets, standards and technologies and adjusting their mix of tools and building blocks and their expertise as needed. "

Such companies, because they would have to act as middleman to several constituencies -- the hardware vendor, the software suppliers and the developer -- would have to be platform independent, and would be required to supply technical advice that isn't biased by a particular product agenda. This advice would involve everything from recommendations on technical features to make vs. buy decisions for certain software functionality. In addition, this middleman company would have to have comprehensive insight into the hundreds of software suppliers, understand what products are offered.

I know that a number of companies in the market are trying to rebuild themselves into such middleman/broker entities. Some such as Wind River have acquired a number of companies to gather all of the building blocks for the many varieties of devices used in the embedded market and in markets outside embedded that find embedded tools useful. Accelerated Technology allowed itself to be acquired by Mentor Graphics in hopes that Mentor's deeper pockets would give it the financial muscle to build the pieces it needs. The same is true of Metrowerks, which has allied itself with Motorola. Other still independent software vendors such as Green Hills, OSE, Lynuxworks and QNX saw the shift coming years ago and have had the time to slowly add capabilities.

Will this approach work? Or will such a new kind of business model require a startup that is not wedded to the past and with the right mix of expertise from the embedded market and the half a dozen or so new segments that have emerged since the collision? What do you think? Are the traditional embedded tool vendors doing the job? What will it take to transform them into the new type of company that is needed?

Bernard Cole is site leader and editor of iApplianceweb and an independent high technology editorial services consultant. He welcomes your feedback. Call him at or send an email to .

For more information about topics, issues and technologies mentioned in this story go to the flashing icon in the upper left corner on this page or go to the iAppliance Web Views page and call up the associatively-linked Java/XML-based Web map of the iApplianceWeb site.

Enter the appropriate key word, product or company name to list instantly every news and product story, product review and product database entry relating to the topic since the beginning of the 2002.