Issue No.

34 Page 1

NASSCOM/ MEM - 030 / 2003 - 04 19 May 2003

Market Intelligence Service

Geography Vertical : : India The Role of Embedded Software in Electronics OEM business

For more information, please contact NASSCOMTM

National Association of Software and Services Companies

research@nasscom.org

Introduction
We are pleased to release the 34th issue of NASSCOM Market Intelligence Service. This week, we focus Increasing OEM Productivity in India. We sincerely hope that the service is able to meet its objectives. In order to do so, we need your feedback. Do tell us whether it is useful, ways to improve relevance and other topics to cover in order to enable us to tailor-make this for your needs. To subscribe to this service, please send an email to research@nasscom.org Thanks and looking forward to serving you better . With warm regards

EXECUTIVE SUMMARY Increasing OEM Productivity The Role of Embedded Software in Electronics OEM business India is on the fast track to emerge as one of the worlds leading centers for IT services and IT enabled services both sizeable and global opportunities. However, a significant opportunity area still eludes India Inc. products. India has only been able to capture a meager 0.2% of this $180 billion market. This is primarily because the core skills in a product play are fundamentally different from the IT and ITES sectors, and Indian companies have not paid focused attention to the unique aspects of the product market. Indias core strengths lie in lower costs of development, a large pool of entry ad mid level talent and mature quality management processes. However success in the products business requires sizable investment in sales, marketing and branding; a sizable pool of high end architectural, design and testing skills and flexible and dynamic development environments. Additionally and most importantly, product plays require companies to be in customers markets. This however, does not mean that India should forget the product opportunity. An exploration

Sunil Mehta Vice President - Research

www.nasscom.org

NASSCOMs Market Intelligence Service

Issue No. 34 Page 2

of the pain points of global software players, an understanding of the emerging technological trends and a review of some of the creative plays adopted by the more successful Indian players throws light on what is actually a spectrum of opportunities for India Inc. to participate in the products space. One such opportunity is that of embedded software in the OEM space. This report provides an overview of the cost-based, time-based and technology risks that face electronic OEMs and how this business is looking to embedded software solutions to provide solutions to over come this. It is in filling this chasm, that there may exist an opportunity for Indian Embedded Software and Product companies. Introduction Spanning a wide number of industries, electronic OEMs provide significant diversity and functionality for electronic devices and equipment. The range of these industrial and commercial electronic products includes everyday consumer and automotive electronics, medical testing and diagnostics products, and industrial automation and telecommunications equipment etc. All along this product spectrum, embedded software combines with semiconductor microprocessors and microcomputers to create the intelligence to make these products functional and differentiated. Typically, a microprocessors capabilities are enhanced by additional semiconductor parts for memory, graphics, communications, and other special-purpose functions, which in turn create the hardware platform for the products. The embedded software platform consists of three layers that imbue the OEM product with its intelligent capabilities: Underlying operating system to manage the hardware and software operations Middleware layer to provide specialpurpose libraries and communications facilities

Application layer to implement unique and specific capabilities of the device

The OEM products that incorporate these embedded platforms are event-driven systems. These systems are usually not open to direct user contact and typically manage streams of input and output data and signals. This view of the electronics OEM business excludes the large segment of generalpurpose desktop PCs and servers. Important as the latter are, they focus on enterprise and individual administrative computing needs; and are usually driven by time and the calendar, not events; and are multipurpose and not designed, developed, or optimized as specific equipment and devices to focus on delivering particular industry and application solutions. The electronics OEM market characterized this way is a large sector of the world economy made up of many industries. The manufacturing shipment revenue for subassemblies, products, and equipment that are constructed using embedded hardware and software platforms has become a major contributor to worldwide GDP. Based on research data and observations of industry trends and directions, it is believed that factory shipments for the embedded electronics OEM industry exceeded the $1 trillion mark in the benchmark year 2000 (excluding PC and server shipments), while the total worldwide GDP exceeded $40 trillion. RISKS CONFRONTING ELECTRONICS OEMS The turbulent marketplaces that electronics OEMs encounter require careful identification and management of critical factors for success. Cost-based problems, time-based problems, and technology-based risks are the most common obstacles. Cost-Based Risks and Outsourcing OEMs encounter cost-based concerns at each point of their product life cycle at the project and at the enterprise level. The need to provide customer value, satisfaction,

NASSCOMs Market Intelligence Service

www.nasscom.org

Issue No. 34 Page 3

and competitive advantage has engineering and business management continually assessing core product values. The product costs and headcount for the full product life cycle from engineering design and development through manufacturing and then service and product maintenance and related areas are all critical to overall projectlevel expenses and represent areas for savings relief. OEM enterprise-level costs include the training and learning curve time of deploying engineering staffs to projects that utilize multiple hardware and software platforms and of maintaining these platforms. Also, in the OEM customer enterprise there are further usage costs and related management of the capital expenditure budget. There is the potential to lower the cost factor by improving quality and reliability. In attaining these goals, there are associated cost savings, including fewer returns and lower warranty expenses and reduced service and maintenance requirements for individual products. Savings are more practicable to achieve within engineering if productivity tools and productivity methods are used to accelerate performance and attain quality. The partitioning of OEM products into hardware and software architectures enables the incremental management and control of costs. The hardware platform and its cost structures are better understood than the embedded software cost structure. The capabilities in hardware cost management have permitted the engineering and manufacturing costs for hardware solution platforms to be analyzed more carefully and earlier and then appropriately reduced. The nature of hardware solutions allows OEMs to pose fundamental questions surrounding buy versus build and the nature of what manufacturers need to own and what can be outsourced. Hardware cost may also be impacted by trade-offs made on the software platform side, forcing the use of higher-performance

or higher-capability hardware to achieve the desired product specifications. Even while electronics OEMs have made a commitment to hardware outsourcing, the nature of the business has been changing. Once driven by hardware platform, it is now being driven by a mix of hardware and software, with the emphasis on application software. The change that clearly demonstrates this shift is in the basic mix of project skills. Software engineers have rapidly replaced hardware engineers to form the largest skill base for project teams. It has been estimated that the percentage of software engineers on a typical project team has increased from 55% in the early to mid-1990s to 75% in 2002. This growth has created a software engineering focus on product architecture and product development. This focus reflects the increasing software content for programmable semiconductor-based products. Software outsourcing has been following a different path than hardware outsourcing. For the product platform, software outsourcing has focused more on the individual embedded software component, which involves areas such as operating systems, protocol stacks, and other middleware, and externally acquiring multiple software tools such as compilers and debuggers used in building the products embedded software. The supermarket style of purchasing has high transaction costs for acquiring and managing individual software and suppliers to ensure conformance with the project plan and product development requirements. According to OEMs, this approach to software outsourcing has inherent technical problems and costs surrounding the integration of multiple supplier products across the embedded platform and development tools. The OEM community estimates that integration costs have recently been rising most significantly.

www.nasscom.org

NASSCOMs Market Intelligence Service

Issue No. 34 Page 4

The time delays surrounding tool chain integration lead to another area of OEM concern: time-based issues. Time-Based Risks The criticality of time-based risks includes both meeting project schedules and not losing the business opportunity that often accompanies being early to market. Many problems surround product design and development times. Figure 1 presents typical time and schedule pressures facing the engineering development organization for the benchmark year 2000 based on research data. Figure 1 demonstrates that 85% of OEM products have engineering development schedules of less than two years. Within this mix, 50% are less than one year. Only 15% have schedules greater than two years. There is enormous pressure to minimize rework and create the best-fit product design as early as possible. Exacerbating the product development schedule is the need for OEMs to be responsive to the time-to-market impact of their products in what are often very competitive markets.

Time to market consolidates internal and external time-based requirements. Internal time-based concerns include development time for prototypes and the specifications and designs to release to manufacturing. Hardware platform development has usually been able to stay closer to schedule. The software platform has proven to be more difficult to control, debug, and fix. The result has been significantly more time spent on testing and integration for the software portion of the product to meet market requirements. There are also external time issues affecting the enterprise once the product ships and reaches its market. Foremost among these is the time-to-revenue generation for the OEM product line. Successful product families are not often successful revenue producers with the first product release; rather, they require further product enhancements and modifications. It is often the early-to-market products that capture market share and establish their positioning for market growth. Then the follow-on models of these products need to be architected to accommodate rapid i t e r a t i o n s , modifications, and changes. Much of this product evolution is determined by the software releases and involves the software platform and development tools. As a result the product architecture and value have become more software oriented. TechnologyBased Risks

Figure 1 : OEM Product Development Schedule

> 2 years (15%) 1-2 years (34%) < 6 months (14%)

6-12 months (37%)

> 2 years (15%) 6-12 months (37%) < 6 months (14%) 1-2 years (34%)
Source : IDC a nd First Technology, 2002

NASSCOMs Market Intelligence Service

www.nasscom.org

Issue No. 34 Page 5

OEM technology choices determine the product form and function for current versions and future models of the product family. Not only are there costs for selection and evaluation, but the largest costs and risks are to establish the technology as a business unit standard and to train engineers in its usage. The choice of software and hardware technology by OEMs is always associated with the following questions:
!

As leading OEM technical directors for business units review their choices and the importance of hardware and software platform technologies, they are drawing some interesting conclusions. Figure 2 compares their views of the importance of fundamental classes of hardware and software platform technologies currently and in the middle of this decade. Currently, the most important platform technologies for OEMs are operating system software and hardware bus and processor technologies. While hardware retains a high rating in the future, it is being surpassed in importance by the software platform. The operating system has emerged as the foundation for the OEM product platform. During the next two years, there will be an increasing interest and growing importance in both the operating system and middleware software.

Will the technology be available for the life of the product? Is the technology robust enough to meet evolving industry, market, and application needs? Can the technology be extended so that it scales for future products? Are there enough adopters, partners, and special interest groups (SIGs) so that the technology will have a longer life and remain superior to competitive choices?

Figure 2 : Technology Rating

90 80 70 60 % 50 40 30 20 10 0
Bus Architecture Microprocessor Architecture DSP Architecture Operating System Software Middleware Software

Current Rating

Rating in two years

Source : IDC and First technology, 2002

www.nasscom.org

NASSCOMs Market Intelligence Service

Issue No. 34 Page 6

Better articulated software services and facilities for implementing product functions are emerging from different sources. These services and facilities include the potential for innovative reengineering of software solutions. The software impact may become as significant as outsourcing has become for the hardware platform. Programmable Semiconductor Evolution New programmable silicon presents OEMs with new product opportunities. The two trends of SOC and multicore implementations in the form of ASICs or ASSPs add the requirement for not only multicore operating systems but also mixed cores with mixed types of operating systems. Cellular handsets are the most prevalent example of multicores because microprocessor and digital signal processor (DSP) cores together meet the handset functionality. DSPs come in fixed and floating point varieties and require different types of software tools and algorithm construction middleware from other microprocessor silicon tools. Another newer class of programmable processor, the network processing unit (NPU), has been designed to provide efficient processing for networking packets with very high sustained data throughput in the multigigabit range. Special tools and middleware that are designed to make the NPU more effective are demonstrating early acceptance in this market segment by combining software standards with industry functional expertise. Still another emerging processor alternative for embedded solutions is the Field Programmable Gate Array (FPGA), which is reconfigurable and instills the ability to have reusable parts in the embedded hardware platform. The configurability of the FPGAs allows OEM product development and deployment to progress more rapidly. With the requirements of multicore and SOC uses, additional types of synthesizable cores,

and other intellectual property, there is a wider range of hardware solutions. This means that the software platform as well as software development tools need greater capabilities to support and manage these choices. Even with the potential of leveraging new programmable silicon, OEMs are finding the design and development of their embedded software platform to be their greatest vulnerability. For this reason, the discussion focuses even more sharply on the embedded software platform and its requisite construction tools. Leading factors that affect the architecture of the OEM products are also examined. Increasing Complexity of Products Accelerating customer requirements have led to more complex products across all industries. The complexity leads to concerns for managing the effectiveness of the embedded software platform resulting from:
!

Larger software footprints with many more lines of code Greater need for software integration along with testing and quality control More software repairs for field-deployed products in the post-release phase for Value and

Requirements Differentiation

OEMs need to both manage their value to their customers and differentiate themselves for their customers. This is a business problem that, at its heart, is a value problem. And the product differentiation has become more of a software concern. To achieve differentiation, the OEM product software platform and the software development tools need better synchronization to create correct application solutions and manage them through their life cycles. OEM changes to maintain the value and uniqueness of products frequently have their strongest impact on middleware and application software.

NASSCOMs Market Intelligence Service

www.nasscom.org

Issue No. 34 Page 7

Rapid Response to Competitive Decisions Individual OEMs understand they must be within the top 3 positions in their industry market segment. Staying in one of these primary competitive slots allows a company to harvest more price margin points and extend its product and service life cycles to better manage company resources. There is the need to adjust product and business unit resources to remain competitive for price, performance, and service because these are the areas OEM customers use as critical purchasing factors. The most difficult of the mix is to respond to competitive product performance decisions. To do this, OEMs require flexible architectures and tools. This is often a software decision. With much of the current software technology, this is challenging to perform. Rapid response requires tuning of software tools, operating systems, and middleware to the personality for each industry segment. But the response may also require a quick change to newly available, higherperformance hardware being exploited by the competition. Thus, the software platform must provide a level of hardware independence. EVOLUTION OF PRODUCT CAPABILITIES As the capabilities of products have evolved, the underlying software platforms have also evolved to provide products with greater capabilities. The following sections provide an overview of some significant directions. Distributed and Networked Solutions There are multiple views of networked and distributed solutions. LANs and WANs are critical organizing elements, as are virtual private networks (VPNs) and even dial-up networks, although the latter is on a severe decline for embedded solutions. Wireless and Internet solutions have seen the most rapid growth of networked devices. Internet-driven solutions have quickly become fundamental for managing distributed and remote devices.

Connectivity, managing network elements, and managing the network overall continue the advance of the OEM into the communications side of the embedded software business. Many OEMs have neither the organizational setup nor the technical core competency to manage distributed and networked solutions. This situation leads to unexpected problems. Robust and Easier-to-Administer Security Many embedded solutions are taking advantage of Internet connectivity, which increases the potential for transactions and software platforms to be vulnerable to security breaches. The security capabilities need to provide data access, data authentication, and data integrity to maintain a confidential solution environment. In Internet security and embedded software these capabilities mean supporting Internet Protocol security (IPsec) and also managing and distributing the cryptographic algorithms and keys, often by enabling distributed software with Internet Key Exchange (IKE). Further support is required for encryption algorithms and suppliers. Security is increasingly important over time, and managing it is primarily a software issue. High Levels of Reliability and Quality Product quality and product reliability are among the most important characteristics for both OEMs and their end customers. A useful operational metric for these qualities is the targeted maximum system uptime per year. The percentage of uptime is expressed as a string of 9s representing uptimes of 99%, 99.9%, 99.99%, and higher. Often product targets are to achieve four 9s and five 9s, which correspond to annual downtime of 54 minutes and 5 minutes, respectively. Traditionally, OEMs and their end customers have taken a hardware approach to achieve higher-availability 9s conformance. The hardware approach has been based on redundant chassis hardware such as CPU boards, I/O boards, power supplies, and disk drives. At the same time, the problems

www.nasscom.org

NASSCOMs Market Intelligence Service

Issue No. 34 Page 8

surrounding reliability have become more software oriented as the level of system complexity increases. In-Service Upgradeability Maintainability and

IMPACT OF STANDARDS AND OPEN SOURCE Individual industry standards and crossindustry standards affect OEM technology risks. Special interest groups (SIGs) and standards organizations have become worldwide in scope and participation to innovate and educate. OEM membership is critical for an enterprise to evolve successful products. Standards organizations have the charter to bring a wider industry community together with more participation to improve the success of products. Standards There is always a mix of de facto and de jure standards. The former are established by individual company strategies and the latter by chartered standards bodies. Since competition is a significant variable for success, many companies would rather meet on more neutral grounds of standards bodies and SIGs to advance their particular industry agendas. Many of the linchpin standards directly impact the embedded software platform and the tools required to create the platform. Open Source Open source is a special category of standards-based software that impacts the embedded software platform. Historically, open source GNU software tools for developing embedded application code and the open source Unix operating systems have played a critical role in developing and evolving embedded software solutions. These are called open source because they are managed and enhanced by volunteer professional software engineers and have a range of licensing programs that maintain free software availability. Linux is rapidly emerging from its GNU background through Linus Torvalds stewardship to also impact embedded solutions. The embedded software community is interested in and planning for the use of Linux in certain types of applications.

There has been a traditional hierarchy for product service, maintenance, and upgradeability that, at its most basic level, deploys local and onsite field service engineers. The engineers at this level typically use dial-up lines and portable PC capabilities to maintain and upgrade products. The next level of sophistication is the OEM technical analysis center or, if a managed telecom network is involved, the network operations center. Both are fully staffed, global response centers that manage products in the field and operate on a 24 x 7 basis. These solutions are evolving into another mode to manage products remotely: remote device management (RDM). In this mode, products remain in service or, at worst, are upgraded or have preventative maintenance on a scheduled basis. RDM solutions are designed to manage product health and wellbeing from initial configuration and setup through status, diagnosis, and repair of faults through ongoing monitoring. It is a more costeffective alternative to the physical upgrading and replacing of products. The RDM approach is also consistent with enterprise software trends for upgrading desktops and servers. There are also choices for in-service upgradeability and maintainability targeting levels at less than full RDM deployment. These solutions combine the Internet with Web services and deployment through Java and .NET to establish connected embedded software platforms. These communications and software management facilities require a significant amount of expertise. Even something as straightforward as the TCP/IP protocol stack has many layers and many choices for tuning and effectiveness.

NASSCOMs Market Intelligence Service

www.nasscom.org

Issue No. 34 Page 9

Because embedded software adoption is generally a function of product cycles and design wins, adoptions and changes in practices and products occur carefully and take longer to implement for these product life cycles. There are pros and cons surrounding open source software. The benefits of open source Linux address important areas for embedded software developers. There is the acquisition and manufacturing cost benefit and availability issue based on no runtime license fees and source code available at no charge. Also there is a wide range of operating system services that includes effective support for networking. There are associated GNU tools that are available for a wide variety of semiconductor cores. There are also drawbacks. A potential risk is the use of open source intellectual property. It is sometimes difficult to verify that available open source intellectual property code is free from patent infringement. Also the business terms and conditions for some open source lack clarity. In particular, the GNU Public License (GPL) usage sometimes leads to contradictory conclusions. In addition, the actual total cost of ownership needs to be considered in determining whether the acquisition and manufacturing cost benefits of open source outweigh the costs associated with new levels of integration and testing required in utilizing open source IP. OEMs need to ask if open source is the primary characteristic most likely to deliver success for OEM products and whether it is the most appropriate technology foundation. Analysts believe that the success of embedded solutions is definitely assisted by the open source characteristics but, more important, needs different types of solutions that more directly impact the critical success variables discussed earlier for cost-based, time-based, and technology-based special industry needs. Successful OEM products require a deep understanding of industry requirements and a specific industry focus for the platform and www.nasscom.org

associated tools. Traditionally, open source software developers are motivated to solve more broad-based problems that are independent of specific industries. It is not clear that the community for open source solutions will be able to provide the specific requirements of individual industry segments. Specifically, a richer and more robust software basis needs to be provided for the OEM product. The software requires its own specific industry focus and industry framework. This better developed approach recognizes that development tool requirements may be different by industry and better matched with an industry-targeted embedded software platform. AN EVOLVING SOFTWARE PARADIGM FOR OEM SUCCESS The OEM communities in each industry market segment are under constant pressure to exploit business opportunities, enhance their product lines, and release more competitive products sooner. Yet these same OEMs are finding that as embedded software increases in complexity and code base size, their business successes are held hostage by their inability to manage, develop, deploy, and maintain embedded software solutions. In its earlier years the software supplier industry was not concentrated enough to supply sufficiently robust solutions for its OEM partners. Lately, these software suppliers have targeted their business and technology to architect more highly focused solutions to remedy the OEM embedded software quagmire. According to analysts, the model that may provide the greatest chance for success needs to provide OEMs with tools, platforms, and services that address specific industry application needs. This type of solution requires more than just arming OEMs with workbench tools; more than being an open source solution; and more than being a supplier to OEMs of specialized semiconductors that have been preloaded with critical industry embedded software solutions.

NASSCOMs Market Intelligence Service

Issue No. 34 Page 10

The potential of the model is in the management and control that it provides individual industries, companies, and OEMs for specialized tool chains and for developing robust software solutions. The model has the potential to contribute immediately to improve the value that OEMs deliver to their customer base. Embedded software solution providers have evolved through a variety of stages to get to this point. Stage 1: Early Value Creation for Embedded Software The early stage for creating software value by embedded software suppliers extended from the mid-1980s to the mid-1990s. Software products matured separately along individual product lines that included the following:
!

Stage 2: Connected Tools and Operating Systems in a Flourishing Partnering Market The time frame for stage 2 is from the mid1990s to the end of the 1990s. The beginnings of stage 2 started with the release of integrated development environments (IDEs) by multiple suppliers. The IDE established a major milestone for tool connectivity and a tighter connection to operating systems. During this period, there was a more rapid consolidation of companies that previously supplied individual embedded pieces of software, and the larger embedded software companies were able to become the primary supplier to their OEM accounts for IDEs and related critical software value. There was also an expansion of process management tools within individual accounts in areas such as requirements specification, testing, and full application cycle management. Embedded software attracted more unified modeling tools and there was the beginning of increased interest for the Unified Modeling Language (UML). Also at this time, middleware started to be identified and noticed. Libraries, communication protocol stacks, graphics packages, and related special-purpose embedded software began to fill out the middleware area. Finally, RDM began to take root. OEMs reached the milestone of recognizing that their products require more significant lifecycle management. The technical analysis center, although not yet automated for networked support and still relying on local field service engineering support, became the prevalent location for centrally organizing the management of remote devices. This precursor to the beginning of Internet RDM was a milestone within stage 2.

Tools companies focused more on compilers and debuggers sometimes working with open source products and sometimes having their own proprietary products. Operating systems companies generally moved from a kernel with fewer services to a more broadly defined operating system with more facilities and services. Hardware semiconductor and boards companies that may have been supplying their own tools and operating systems recognized the value of software companies and decided to exit from the mainstream of the software business. Software companies started partnerships with semiconductor companies.

Toward the end of this period, tools and operating systems companies increased their compatibility through acquisitions and closer partnerships. There were business couplings and initial connections to form tighter relationships with the OEM supplier community between hardware and software companies.

NASSCOMs Market Intelligence Service

www.nasscom.org

Issue No. 34 Page 11

Stage 3: Creating a Robust Framework for Embedded Software Solutions This stage brings software evolution into the present. Multiple strands of events have come together to establish a business and technology framework for a more direct OEM focus for embedded software solutions. The solution incorporates embedded software tools, the embedded software platform for the products, and services. The especially difficult current economy is forcing OEMs to continue their ongoing struggle to assess the value they contribute to their product technology and determine which portions of bill of materials and processes they are willing to outsource. There is a greater recognition by OEMs to continue to own the specific application solution and the customer and be creative in using suppliers for the structure and framework of underlying infrastructure. The economy continues to highlight the importance of business expense reduction and cost containment, which are drivers of cost and schedules at the engineering level and which roll up to operating expenditure (OpEx) and capital expenditure (CapEx) at the business unit level. The focus on OpEx and CapEx is an important consolidation point for the concerns of cost, time, and technology risks. CapEx has even more significance for OEM customers cost-containment efforts. Standards-setting bodies have established varieties of necessary standards over the years. They have gained sufficient credibility and trust in articulating workable solutions with which OEMs can actively participate. The emerging presence of lower-cost Internet services and solutions for RDM has increased the impetus for broader business solutions to also address CapEx. This continues to enable the OEMs and their suppliers to come together around a shared view for the desired elements of the preferred embedded software platform and development tools. This common view has expanded over

time to combine tools, operating systems, middleware, communications, applications, and services. The importance and credibility of these shared views across multiple industries are stimulating the growth for an emerging engineering environment. These environments are focusing on more integrated development and product deployment systems and services for the application software that characterizes the uniqueness of each industry. The structure has already started to evolve in particular industries that include telecom/ datacom switches, smart cellular handhelds, printers, and automotive driver information systems. These application areas involve OEMs, semiconductor companies, and embedded software companies. CONCLUSION OEM producers of electronic products using programmable semiconductors are innovating to build and deploy new products that meet more user needs and to differentiate themselves from and their competitors. The character of the products being developed demonstrates increasing complexity, connectivity, and reliability. With increased remote management, these products can be maintained and upgraded while still in use and service. This increased value for OEM products and their users is being constructed primarily from improved embedded software. The results are that the OEMs are becoming more reliant on software with the need to become more effective at the tasks of software management. The software is necessary. But, it is only the application portion of the software that reflects the value of the OEM product. The embedded software platform and the software support tools that OEMs often manage have the potential to distract OEMs from their primary value of delivering embedded application software in a differentiated manner.
NASSCOMs Market Intelligence Service

www.nasscom.org

Issue No. 34 Page 12

Outsourcing the hardware platform has been a very effective way to manage the hardware-based variables. Software outsourcing has been more fragmented and has required OEMs to allocate more time for integration and testing; it has yet to be effective. Embedded software management requires a different approach that integrates OEMspecific industry and standards knowledge

with software expertise surrounding embedded platforms, support tools, and services. However, this type of outsourcing has begun to emerge with solutions in different industry applications. Thus, as software is becoming pervasive in all devices and OEMs and suppliers are struggling to build software competencies, there is a very real opportunity for Indian companies to step in and fill the void.

Disclaimer : This report is published by NASSCOM for the exclusive use of its members. This report has been prepared using sources believed to be reliable and accurate. NASSCOM does not accept any liability for any direct or consequential use of this report or its contents. The information and opinions contained in this report are subject to change without notice. The contents of this report may be reproduced only after prior permission from NASSCOM.

NASSCOMs Market Intelligence Service

www.nasscom.org