<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Micrium</title>
	<atom:link href="http://micrium.com/feed/" rel="self" type="application/rss+xml" />
	<link>http://micrium.com</link>
	<description>RTOS &#38; Tools</description>
	<lastBuildDate>Mon, 20 May 2013 20:53:49 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.4.2</generator>
		<item>
		<title>Renesas Electronics America, Micrium and IAR Systems Bring Expanded RTOS and Middleware Bundle to Embedded Developers on IAR Systems Tools Platform</title>
		<link>http://micrium.com/renesas-electronics-america-micrium-and-iar-systems-bring-expanded-rtos-and-middleware-bundle-to-embedded-developers-on-iar-systems-tools-platform/</link>
		<comments>http://micrium.com/renesas-electronics-america-micrium-and-iar-systems-bring-expanded-rtos-and-middleware-bundle-to-embedded-developers-on-iar-systems-tools-platform/#comments</comments>
		<pubDate>Tue, 14 May 2013 21:00:47 +0000</pubDate>
		<dc:creator>Jim Royal</dc:creator>
				<category><![CDATA[Press Release]]></category>

		<guid isPermaLink="false">http://micrium.com/?p=3448</guid>
		<description><![CDATA[Expanded “Power of Two” Offering adds Free IAR Embedded Workbench License and Support Santa Clara, Calif., Foster City, Calif., May 13, 2013 – The leading microcontroller (MCU) supplier in the Americas, the leading embedded software solution provider and the world’s &#8230; <a href="http://micrium.com/renesas-electronics-america-micrium-and-iar-systems-bring-expanded-rtos-and-middleware-bundle-to-embedded-developers-on-iar-systems-tools-platform/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p><em>Expanded “Power of Two” Offering adds Free IAR Embedded Workbench License and Support</em></p>
<p>Santa Clara, Calif., Foster City, Calif., May 13, 2013 – The leading microcontroller (MCU) supplier in the Americas, the leading embedded software solution provider and the world’s leading supplier of development tools for embedded systems are expanding the Power of Two  offer with IAR Embedded Workbench for RX and RL78, providing a bundle of high-quality MCUs, software and tools for embedded developers working with the Renesas MCUs. </p>
<p>Renesas Electronics America has selected IAR Systems to join the Power of Two program. Bundling Renesas’ high-quality MCUs with a real-time operating system (RTOS) and middleware components from Micrium provides several benefits for customers who need flexibility, reliability and ease of use to accommodate constantly changing design needs. Adding IAR Systems’ best-in-class development tools enhances the program, offering more portable, scalable and affordable MCU designs for connected and emerging applications within the Smart Society that offer increased intelligence, energy savings, safety and enhanced user experience. </p>
<p>The program offers embedded developers working with any Renesas RX or RL78 devices free production licenses of Micrium’s RTOS µCOS-II or µC/OS-III and middleware (connectivity stacks and storage software), along with one year of maintenance and support. Developers who qualify for the program can now also get a free license of IAR Embedded Workbench for RX or RL78, including one year of technical support and software upgrades as well as up to two hours of web-based training provided by IAR Academy. </p>
<p>“We are excited to strengthen the popular Power of Two program with the powerful development tools from IAR Systems,” said Peter Carbone, Vice President of Marketing, Renesas Electronics America. “For RX and RL78 MCUs, the optimization technology of IAR Embedded Workbench produces a small code footprint and fast performance on the EEMBC CoreMark benchmarks. Developers using IAR Systems’ tools, in combination with Micrium’s RTOS and middleware can select smaller RX or RL78 devices requiring less memory and processing power, while fully leveraging their rich set of peripherals and low-power features.”</p>
<p>“Renesas has raised the bar by providing complete and high-quality software solutions together with selected partners, and the addition of IAR Systems underscores the value of the Power of Two program,” said Stefan Skarin, CEO, IAR Systems. “We are happy to join the program with the assurance that customers can rely on IAR Embedded Workbench to meet their most demanding design requirements.”</p>
<p>“Having been a long time partner with IAR Systems, we at Micrium are delighted with the expansion of this program,” said Jean Labrosse President and CEO of Micrium Inc. “Micrium supports a comprehensive set of ports for the Renesas RL and RX MCU families developed on IAR Systems’ tools. This combined offering provides the embedded design engineer with the best-in-class hardware, software, and now development tools.”</p>
<p>IAR Systems is a Renesas Platinum Partner and Micrium Technology Alliance Partner, making IAR Embedded Workbench a solid choice as the perfect link between the RX and RL78 MCUs and Micrium’s RTOS and middleware. Adding IAR Systems’ tools to the Power of Two program provides a complete platform upon which customers can design and implement products faster and more reliably, while at the same time lower the production costs. </p>
<p>The Power of Two promotion is valid in the Americas only (North America, South America and Central America). The customer project must use a Renesas RX or RL78 MCU product and it must be used in a commercial application. Qualified customers can request any number of single-product licenses by registering each project individually with Renesas. </p>
<p>For more information or to apply for the promotion, visit http://am.renesas.com/PowerOfTwo.</p>
<p>For more information on Renesas Electronics’ MCU and ecosystem lineup, visit http://am.renesas.com/products/mpumcu/index.jsp. For more information on Renesas news, follow Renesas Electronics America on Twitter: www.twitter.com/RenesasAmerica.</p>
<p><strong>About Renesas Electronics America Inc.<br />
</strong><br />
Renesas Electronics America Inc., headquartered in Santa Clara, California, is a wholly owned subsidiary of Renesas Electronics Corporation (TSE: 6723), the world&#8217;s number one supplier of microcontrollers and a premier supplier of advanced semiconductor solutions including microcontrollers, SoC solutions, and a broad range of analog and power devices. In the Americas, Renesas Electronics America markets and sells industrial-type active-matrix LCD modules from NLT Technologies, Ltd., a global leader in innovative display technologies. More information about the products offered by Renesas Electronics America can be found at http://am.renesas.com/.</p>
<p><strong>About IAR Systems</strong></p>
<p>IAR Systems is the world’s leading supplier of software tools for developing embedded systems applications. The software enables over 19,000 large and small companies to develop premium products based on 8-, 16-, and 32-bit microcontrollers, mainly in the areas of industrial automation, medical devices, consumer electronics, telecommunication, and automotive products. IAR Systems has an extensive network of partners and cooperates with the world’s leading semiconductor vendors. IAR Systems Group AB is listed on NASDAQ OMX Stockholm. For more information, please visit www.iar.com.</p>
<p><strong>About Micrium, Inc</strong></p>
<p>Micrium is the world’s most respected and trusted RTOS and tools provider serving embedded systems developers. The products in Micrium&#8217;s portfolio are accompanied by intuitive documentation and are backed by second-to-none technical support. For more information, visit www.micrium.com.</p>
<p><strong>Remarks</strong></p>
<p>All other product and service names that appear in this newsflash are trademarks or registered trademarks of their respective owners. </p>
<p><strong>Renesas Electronics America Contact</strong><br />
Amelie LeMoullac<br />
Voce Communications, a Porter Novelli Company<br />
(415) 975-2212<br />
alemoullac@vocecomm.com</p>
<p><strong>IAR Systems Contact</strong><br />
Fredrik Medin, Marketing Director, IAR Systems<br />
+46 18 16 78 00<br />
fredrik.medin@iar.com</p>
<p><strong>Micrium Contact</strong><br />
Michael Phipps, Director of Sales &#038; Marketing<br />
650-776-2975<br />
michael.phipps@micrium.com</p>
]]></content:encoded>
			<wfw:commentRss>http://micrium.com/renesas-electronics-america-micrium-and-iar-systems-bring-expanded-rtos-and-middleware-bundle-to-embedded-developers-on-iar-systems-tools-platform/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>2013 Embedded Market Forecasters Survey of Embedded Developers: Bluetooth Respondents</title>
		<link>http://micrium.com/2013-embedded-market-forecasters-survey-of-embedded-developers-bluetooth-respondents/</link>
		<comments>http://micrium.com/2013-embedded-market-forecasters-survey-of-embedded-developers-bluetooth-respondents/#comments</comments>
		<pubDate>Wed, 27 Mar 2013 20:16:26 +0000</pubDate>
		<dc:creator>Jim Royal</dc:creator>
				<category><![CDATA[Article]]></category>

		<guid isPermaLink="false">http://micrium.com/?p=3205</guid>
		<description><![CDATA[Jerry Krasner, Ph.D., Chief Analyst Dolores A. Krasner, Senior Editor American Technology International, Inc. About EMF EMF is the premier market intelligence and advisory firm in the embedded technology industry. Embedded technology refers to the ubiquitous class of products which &#8230; <a href="http://micrium.com/2013-embedded-market-forecasters-survey-of-embedded-developers-bluetooth-respondents/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p><strong>Jerry Krasner, Ph.D., Chief Analyst</strong><br />
<strong>Dolores A. Krasner, Senior Editor</strong><br />
American Technology International, Inc.</p>
<h3>About EMF</h3>
<p>EMF is the premier market intelligence and advisory firm in the embedded technology industry. Embedded technology refers to the ubiquitous class of products which use some type of processor as a controller. These products include guided missiles, radars, and avionics as well as robots, automobiles, telecom gear, and medical electronics.</p>
<p>EMF has been conducting research into the embedded market for more than a decade. EMF survey work is recognized as the most comprehensive and statistically accurate set of measures in the embedded market space by LSA, IBM, Microsoft and a number of other firms. Using research discipline from medical inquiry, EMF has developed a series of survey questions for developers which provide insight into the following areas:</p>
<ul>
<li>Trends in Integrated Development Environments (IDEs) and Real Time Operating Systems (RTOS)</li>
<li>Trends in host processors (both standard microprocessors and Digital Signal Processors (DSPs)</li>
<li>Trends in Interfaces and Trends in Bus and Board Standards</li>
<li>Trends in Systems Engineering and Systems Architecture</li>
<li>Trends in Software Languages</li>
<li>Trends in simulation</li>
<li>Trends in testing</li>
<li>Trends in product life cycle management</li>
<li>Trends in product development performance, practices and management</li>
</ul>
<p>Embedded Market Forecasters (EMF) is the market research division of American Technology International, Inc. EMF clients range from startups to Global 100 companies worldwide. Founded by Dr. Jerry Krasner, a recognized authority on electronics markets, product development and channel distribution; EMF is headquartered in Ashland, Massachusetts.</p>
<p><a href="http://www.embeddedforecast.com/">www.embeddedforecast.com</a></p>
<h3>About the Author</h3>
<p>Jerry Krasner, Ph.D., MBA is Vice President of Embedded Market Forecasters and its parent company, American Technology International. A recognized authority with over 30 years of embedded industry experience, Dr. Krasner was formerly Chairman of Biomedical Engineering at Boston University, and Chairman of Electrical and Computer Engineering at Wentworth Institute of Technology and Bunker Hill Community College. In addition to his academic appointments, Dr. Krasner served as President of Biocybernetics, Inc. and CLINCO, Inc., Executive Vice President of Plasmedics, Inc. and Clinical Development Corporation, and Director of Medical Sciences for the Carnegie-Mellon Institute of Research. Earlier, he was Senior Engineer at the MIT Instrumentation Laboratory. Dr. Krasner earned BSEE and MSEE degrees from Washington University, a Ph.D. in Medical Physiology / Biophysics from Boston University and an MBA from Nichols College. He is a visiting professor at the Universidad de Las Palmas (Spain) where he was recognized for his work in neurosciences and computer technology.</p>
<p>Dolores A. Krasner, Senior Editor and Researcher for Embedded Market Forecasters received BS and MEd degrees from Fitchburg State College and Framingham State College with specializations in special education, literacy and educational research. While a full time teacher, she continued her studies with 60 credits beyond her MEd degree in educational research and best practices. Ms. Krasner retired from her full-time educational roles in 2007.</p>
<h3>Regarding the Data in this Report</h3>
<p>The data that is referred to in this report is statistically accurate and authentic and is based on:</p>
<ul>
<li>A statistically generated comprehensive and detailed survey of embedded developers and managers who reported on their design results (number of developers per project, vertical market of their design, time to market, percent of designs completed behind schedule or cancelled, closeness of final design outcomes to pre-design expectations, testing outcomes, etc.), the tools they used (development, modeling, Java, Eclipse, and other development tools), their choice of OS, IDE, communication middleware, processors used as well as where they go to learn about new products, tools and concepts.</li>
<li>An EMF Dashboard – a unique tool that allows the user to simultaneously compare similar products (vendors can do competitive comparative analysis); that marketing executives can use for sales promo and strategic planning; that allows developers beginning a project to compare the experiences of hundreds of fellow developers that undertook similar projects to gain insights before making a commitment; and that allows CFOs and senior managers to look at what tools and processes resulted in the greatest cost savings.</li>
</ul>
<p>For the interested reader, the following link demonstrates the power of the Dashboard and how we used it in developing the data that is presented herein:</p>
<p><a href="http://www.embeddedforecast.com/EMF_DashboardIntro/EMF_DashboardIntro.html">http://www.embeddedforecast.com/EMF_DashboardIntro/EMF_DashboardIntro.html</a></p>
<h3>Introduction</h3>
<p>The EMF Market Intelligence Program presents Bluetooth vendors and embedded Bluetooth users a comprehensive way to understand the competitive marketplace and to be able to understand what developers using Bluetooth and other available wireless protocols are experiencing and complaining about. In addition, the Embedded Dashboard enabled EMF to determine what processors, operating systems and tools Bluetooth and other wireless protocols developers are using.</p>
<p>This is information can be crucial to vendors and users as well. Users will get a feel for what their fellow developers have used and what – based on their personal experience &#8211; values and preferences have emerged. For wireless vendors these results should be of value and, perhaps, of concern. Understanding trends among users can allow vendors to address market opportunities ahead of their competitors.</p>
<p>A demo of how the Dashboard allows the reader to comprehensively examine the competitive marketplace can be viewed at www.embeddedforecast.com. Some sample determinations (from actual EMF Survey data from embedded developers and managers) are presented.</p>
<p>In the following examples of actual 2013 data, the Dashboard was used to filter separately on Bluetooth users as well as users of 802.11g and Zigbee. Of course, any wireless protocol could have been selected. The Dashboard users then could go to any question in the survey and determine how the users of these protocols responded.</p>
<p>The EMF Survey of Embedded Developers is conducted once per year (in January through March).</p>
<h3>2013 Embedded Developer Survey</h3>
<p><strong>Developer Profile</strong></p>
<p>Five hundred and ninety-five developers responded to the online survey, of which 51 were hardware engineers, 124 were software engineers, 73 were systems developers, 43 were systems architects, 90 were firmware engineers and 126 were engineering managers. In addition 75 developers gave titles other than these listed. This provided an excellent distribution of experiences and viewpoints from which to draw inferences and conclusions. Statistically, the response is at a 95% confidence level, plus or minus 4.0%.</p>
<p>49.5% of respondents came from North America, while 18.4% were from Asia and 32.1% were from Europe.</p>
<p><strong>Primary Application for Current Embedded Design</strong></p>
<p>The following vertical market categories apply to respondents’ primary designs – most respondents indicated that they work on several vertical applications. The responses were exceptionally well balanced and not biased towards any particular market. The large number of “other” responses shows that the health of the embedded marketplace is improving as new application segments are emerging.</p>
<table>
<tbody>
<tr>
<td>Industrial automation/controls</td>
<td>17.8%</td>
</tr>
<tr>
<td>Aerospace/avionics</td>
<td>12.2%</td>
</tr>
<tr>
<td>Automotive/transportation</td>
<td>9.1%</td>
</tr>
<tr>
<td>Medical</td>
<td>8.9%</td>
</tr>
<tr>
<td>Military/defense (including Homeland Defense)</td>
<td>7.0%</td>
</tr>
<tr>
<td>Electronic instrumentation/devices</td>
<td>6.8%</td>
</tr>
<tr>
<td>Consumer electronics, handheld devices, etc.</td>
<td>5.8%</td>
</tr>
<tr>
<td>Energy</td>
<td>5.6%</td>
</tr>
<tr>
<td>Consumer electronics, home entertainment, etc.</td>
<td>4.4%</td>
</tr>
<tr>
<td>Datacom/networking</td>
<td>2.6%</td>
</tr>
<tr>
<td>Telecommunications &#8211; Mobile devices</td>
<td>2.1%</td>
</tr>
<tr>
<td>Office automation</td>
<td>1.7%</td>
</tr>
<tr>
<td>Rail transport</td>
<td>1.7%</td>
</tr>
<tr>
<td>Robotics</td>
<td>1.2%</td>
</tr>
<tr>
<td>Telecommunications &#8211; Access networks</td>
<td>1.2%</td>
</tr>
<tr>
<td>Telecommunications &#8211; Enterprise networks</td>
<td>1.0%</td>
</tr>
<tr>
<td>Gaming devices</td>
<td>0.7%</td>
</tr>
<tr>
<td>Telecommunications Wireless Infrastructure</td>
<td>0.7%</td>
</tr>
<tr>
<td>Telecommunications &#8211; Core/Edge networks</td>
<td>0.5%</td>
</tr>
<tr>
<td>Other (please specify)</td>
<td>8.9%</td>
</tr>
</tbody>
</table>
<h3>Wireless Use by Embedded Developers in Their Applications</h3>
<table>
<caption>Which wireless technologies have you designed into your embedded applications</caption>
<tbody>
<tr>
<th></th>
<th>Industry</th>
<th>Bluetooth</th>
<th>Zigbee</th>
<th>WiFi</th>
</tr>
<tr>
<td>802.11g</td>
<td>22.7%</td>
<td>40.9%</td>
<td>38.9%</td>
<td>68.0%</td>
</tr>
<tr>
<td>Zigbee</td>
<td>21.6%</td>
<td>43.2%</td>
<td>100.0%</td>
<td>29.3%</td>
</tr>
<tr>
<td>3G</td>
<td>18.0%</td>
<td>42.0%</td>
<td>22.1%</td>
<td>29.3%</td>
</tr>
<tr>
<td>802.11b</td>
<td>17.3%</td>
<td>37.5%</td>
<td>26.3%</td>
<td>51.7%</td>
</tr>
<tr>
<td>Bluetooth Classic V2.1</td>
<td>16.4%</td>
<td>81.8%</td>
<td>33.7%</td>
<td>25.2%</td>
</tr>
<tr>
<td>HTTP</td>
<td>16.4%</td>
<td>38.6%</td>
<td>30.5%</td>
<td>28.6%</td>
</tr>
<tr>
<td>802.11a</td>
<td>15.0%</td>
<td>27.3%</td>
<td>21.1%</td>
<td>44.9%</td>
</tr>
<tr>
<td>802.11n</td>
<td>13.6%</td>
<td>25.0%</td>
<td>21.1%</td>
<td>40.8%</td>
</tr>
<tr>
<td>GSM</td>
<td>13.6%</td>
<td>31.8%</td>
<td>27.4%</td>
<td>21.1%</td>
</tr>
<tr>
<td>RFID</td>
<td>13.2%</td>
<td>37.5%</td>
<td>31.6%</td>
<td>19.7%</td>
</tr>
<tr>
<td>Proprietary</td>
<td>11.8%</td>
<td>17.0%</td>
<td>17.9%</td>
<td>9.5%</td>
</tr>
<tr>
<td>XML</td>
<td>10.0%</td>
<td>18.2%</td>
<td>14.7%</td>
<td>17.0%</td>
</tr>
<tr>
<td>WPA2</td>
<td>9.3%</td>
<td>23.9%</td>
<td>16.8%</td>
<td>23.8%</td>
</tr>
<tr>
<td>CDMA</td>
<td>9.1%</td>
<td>20.5%</td>
<td>16.8%</td>
<td>17.0%</td>
</tr>
<tr>
<td>IrDA</td>
<td>8.6%</td>
<td>25.0%</td>
<td>23.2%</td>
<td>13.6%</td>
</tr>
<tr>
<td>WPA</td>
<td>7.5%</td>
<td>20.5%</td>
<td>14.7%</td>
<td>21.8%</td>
</tr>
<tr>
<td>Bluetooth High Speed V3.0</td>
<td>6.8%</td>
<td>34.1%</td>
<td>12.6%</td>
<td>15.6%</td>
</tr>
<tr>
<td>WEP</td>
<td>6.8%</td>
<td>20.5%</td>
<td>12.6%</td>
<td>19.7%</td>
</tr>
<tr>
<td>4G</td>
<td>6.6%</td>
<td>14.8%</td>
<td>10.5%</td>
<td>13.6%</td>
</tr>
<tr>
<td>EDGE</td>
<td>6.4%</td>
<td>14.8%</td>
<td>7.4%</td>
<td>8.8%</td>
</tr>
<tr>
<td>NFC</td>
<td>5.9%</td>
<td>17.0%</td>
<td>11.6%</td>
<td>8.8%</td>
</tr>
<tr>
<td>802.11i</td>
<td>5.7%</td>
<td>11.4%</td>
<td>7.4%</td>
<td>17.0%</td>
</tr>
<tr>
<td>Bluetooth Low Energy V4.0</td>
<td>5.7%</td>
<td>28.4%</td>
<td>13.7%</td>
<td>7.5%</td>
</tr>
<tr>
<td>LTE</td>
<td>3.9%</td>
<td>9.1%</td>
<td>9.5%</td>
<td>8.2%</td>
</tr>
<tr>
<td>HSDPA</td>
<td>3.6%</td>
<td>9.1%</td>
<td>4.2%</td>
<td>6.8%</td>
</tr>
<tr>
<td>TDMA</td>
<td>3.6%</td>
<td>10.2%</td>
<td>7.4%</td>
<td>6.1%</td>
</tr>
<tr>
<td>802.16 WiMAX</td>
<td>3.4%</td>
<td>5.7%</td>
<td>6.3%</td>
<td>8.2%</td>
</tr>
<tr>
<td>Home RF</td>
<td>3.4%</td>
<td>10.2%</td>
<td>9.5%</td>
<td>6.8%</td>
</tr>
<tr>
<td>WCDMA (UMTS)</td>
<td>3.4%</td>
<td>11.4%</td>
<td>8.4%</td>
<td>6.1%</td>
</tr>
<tr>
<td>Other (please specify)</td>
<td>3.4%</td>
<td>1.1%</td>
<td>4.2%</td>
<td>2.7%</td>
</tr>
<tr>
<td>UWB</td>
<td>3.0%</td>
<td>6.8%</td>
<td>11.6%</td>
<td>6.8%</td>
</tr>
<tr>
<td>CDPD</td>
<td>0.9%</td>
<td>3.4%</td>
<td>1.1%</td>
<td>1.4%</td>
</tr>
<tr>
<td>WML</td>
<td>0.9%</td>
<td>3.4%</td>
<td>4.2%</td>
<td>2.7%</td>
</tr>
<tr>
<td>WSE</td>
<td>0.7%</td>
<td>2.3%</td>
<td>1.1%</td>
<td>2.0%</td>
</tr>
<tr>
<td>SWAP</td>
<td>0.2%</td>
<td>1.1%</td>
<td>1.1%</td>
<td>0.7%</td>
</tr>
<tr>
<td>WDECT</td>
<td>0.2%</td>
<td>1.1%</td>
<td>1.1%</td>
<td>0.7%</td>
</tr>
<tr>
<td>WiGIG</td>
<td>0.2%</td>
<td>1.1%</td>
<td>1.1%</td>
<td>0.7%</td>
</tr>
</tbody>
</table>
<p>From this Table it is clear that wireless developers design to a number of protocols. From the Bluetooth column it is clear that Bluetooth developers use many of the Bluetooth protocols as well as designing to WiFi as well. Hence, embedded developers would be wise to use a vendor that can provide all of the major protocols.</p>
<h3>Total Cost of Development: Industry, Bluetooth, and 802.11x</h3>
<p>With the many and confusing claims and counter claims made by vendors in every segment of the embedded marketplace, EMF has created a unique methodology to use survey data to calculate actual costs of development so that competitive products can be simultaneously compared.</p>
<p>The following parameters are used to calculate the TCD:</p>
<p style="padding-left: 30px;">a. Number of software and hardware developers per project<br />
b. Number of months from design start to product shipment<br />
c. Percent of designs completed behind schedule<br />
d. Number of months behind schedule<br />
e. Percent of designs cancelled<br />
f. Number of months before cancellation</p>
<p>Multiplying a) and b) provides the total average number of man-months expended on a project. Multiplying a) c) and d) provides the average number of man-months lost to schedule. Multiplying a) e) and f) provides the average number of man-months lost to cancellation. Adding these calculations provides the total number of project man-months. In order to calculate the average total cost of development, EMF estimates a man-month cost of $10,000 (including overhead). Table III presents the comparative cost between projects that include formal test processes and those that do not. Let’s look first at the world-wide data reflecting comparative design outcomes between similar projects that use Bluetooth and WiFi in their embedded designs. This data is presented in Table I.</p>
<table>
<caption>Table I: Comparative Cost of Development</caption>
<tbody>
<tr>
<th></th>
<th>Industry</th>
<th>Bluetooth</th>
<th>802.11x</th>
</tr>
<tr>
<td>Devel time Months</td>
<td>13.9</td>
<td>12.6</td>
<td>12.6</td>
</tr>
<tr>
<td>% behind schedule</td>
<td>40.8%</td>
<td>37.0%</td>
<td>39.5%</td>
</tr>
<tr>
<td>Months behind</td>
<td>3.5</td>
<td>3.8</td>
<td>3.8</td>
</tr>
<tr>
<td>% cancelled</td>
<td>9.9%</td>
<td>11.6%</td>
<td>13.2%</td>
</tr>
<tr>
<td>Months lost to cancellation</td>
<td>4</td>
<td>4.1</td>
<td>4.7</td>
</tr>
<tr>
<td>SW Developers/proj</td>
<td>11.1</td>
<td>6.8</td>
<td>9.4</td>
</tr>
<tr>
<td>HW Developers/proj</td>
<td>9.6</td>
<td>3.1</td>
<td>4.5</td>
</tr>
<tr>
<td>Total project developers</td>
<td>20.7</td>
<td>9.9</td>
<td>13.9</td>
</tr>
<tr>
<td>Average Developer months/project</td>
<td>287.7</td>
<td>124.7</td>
<td>175.1</td>
</tr>
<tr>
<td>Developer months lost to schedule</td>
<td>29.6</td>
<td>13.9</td>
<td>20.9</td>
</tr>
<tr>
<td>Developer&nbsp;months&nbsp;lost&nbsp;to&nbsp;cancellation</td>
<td>8.2</td>
<td>4.7</td>
<td>8.6</td>
</tr>
<tr>
<td>Total developer months/ project</td>
<td>325.5</td>
<td>143.4</td>
<td>204.6</td>
</tr>
<tr>
<td><strong>At $10,000/developer month</strong></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Average developer cost/project</td>
<td>$2,877,300</td>
<td>$1,247,400</td>
<td>$1,751,400</td>
</tr>
<tr>
<td>Average cost to delay</td>
<td>$377,568</td>
<td>$186,278</td>
<td>$294,875</td>
</tr>
<tr>
<td><strong>Total developer cost/project</strong></td>
<td>$3,254,868</td>
<td>$1,433,678</td>
<td>$2,046,275</td>
</tr>
</tbody>
</table>
<p>It is not clear why wireless developers enjoy a much lower cost of development per project than the industry at large but year-over –year analysis shows this to be the case.</p>
<p>Lets look a wireless protocols used across four different vertical markets (Table II).</p>
<table>
<caption>Table II: Wireless use across four Markets</caption>
<tbody>
<tr>
<th></th>
<th>Industry</th>
<th>Auto</th>
<th>Medical</th>
<th>Mobile Telecom</th>
<th>Handheld Devices</th>
</tr>
<tr>
<td>Bluetooth</td>
<td>24.2%</td>
<td>32.4%</td>
<td>22.4%</td>
<td>40.6%</td>
<td>46.9%</td>
</tr>
<tr>
<td>802.11g</td>
<td>21.8%</td>
<td>35.1%</td>
<td>26.5%</td>
<td>28.1%</td>
<td>30.6%</td>
</tr>
<tr>
<td>802.11b</td>
<td>16.6%</td>
<td>24.3%</td>
<td>14.3%</td>
<td>40.6%</td>
<td>28.6%</td>
</tr>
<tr>
<td>802.11n</td>
<td>16.6%</td>
<td>16.2%</td>
<td>16.3%</td>
<td>28.1%</td>
<td>26.5%</td>
</tr>
<tr>
<td>Zigbee</td>
<td>14.1%</td>
<td>10.8%</td>
<td>14.3%</td>
<td>15.6%</td>
<td>26.5%</td>
</tr>
<tr>
<td>3G</td>
<td>12.3%</td>
<td>18.9%</td>
<td>12.2%</td>
<td>15.6%</td>
<td>20.4%</td>
</tr>
<tr>
<td>GSM</td>
<td>11.0%</td>
<td>13.5%</td>
<td>6.1%</td>
<td>28.1%</td>
<td>22.4%</td>
</tr>
<tr>
<td>HTTP</td>
<td>8.9%</td>
<td>13.5%</td>
<td>8.2%</td>
<td>28.1%</td>
<td>18.4%</td>
</tr>
<tr>
<td>RFID</td>
<td>8.9%</td>
<td>13.5%</td>
<td>10.2%</td>
<td>9.4%</td>
<td>12.2%</td>
</tr>
<tr>
<td>802.11a</td>
<td>8.6%</td>
<td>16.2%</td>
<td>8.2%</td>
<td>15.6%</td>
<td>16.3%</td>
</tr>
<tr>
<td>Proprietary</td>
<td>8.0%</td>
<td>10.8%</td>
<td>4.1%</td>
<td>15.6%</td>
<td>12.2%</td>
</tr>
<tr>
<td>WPA2</td>
<td>8.0%</td>
<td>5.4%</td>
<td>6.1%</td>
<td>15.6%</td>
<td>14.3%</td>
</tr>
<tr>
<td>4G</td>
<td>7.1%</td>
<td>10.8%</td>
<td>4.1%</td>
<td>18.8%</td>
<td>12.2%</td>
</tr>
<tr>
<td>WEP</td>
<td>5.8%</td>
<td>5.4%</td>
<td>2.0%</td>
<td>12.5%</td>
<td>10.2%</td>
</tr>
<tr>
<td>XML</td>
<td>5.8%</td>
<td>5.4%</td>
<td>2.0%</td>
<td>21.9%</td>
<td>10.2%</td>
</tr>
<tr>
<td>WPA</td>
<td>4.9%</td>
<td>5.4%</td>
<td>2.0%</td>
<td>6.3%</td>
<td>8.2%</td>
</tr>
<tr>
<td>CDMA</td>
<td>4.6%</td>
<td>0.0%</td>
<td>0.0%</td>
<td>12.5%</td>
<td>8.2%</td>
</tr>
<tr>
<td>WCDMA (UMTS)</td>
<td>4.3%</td>
<td>0.0%</td>
<td>6.1%</td>
<td>15.6%</td>
<td>8.2%</td>
</tr>
<tr>
<td>802.11i</td>
<td>3.4%</td>
<td>5.4%</td>
<td>4.1%</td>
<td>9.4%</td>
<td>6.1%</td>
</tr>
<tr>
<td>IrDA</td>
<td>3.4%</td>
<td>8.1%</td>
<td>2.0%</td>
<td>3.1%</td>
<td>6.1%</td>
</tr>
</tbody>
</table>
<p>It can be argued that the total use of WiFi – if added up for all WiFi variants – would rank ahead of Bluetooth. But this is missing the point. If a developer is using 802.11n, they aren’t using 802.11a/b/g. So Table II presents “usage” rather than “family”.</p>
<p>The following Tables reflect how wireless developers respond to questions regarding their preferences, opinions and concerns. They are self explanatory and the reader is encouraged to interpret the findings within their own values system. EMF believes that it is instructive for all developer to see what their colleagues are expressing. We use 802.11x to reflect ALL of the WiFi variants.</p>
<table>
<caption>What are the top four significant issues impacting your embedded software development?</caption>
<tbody>
<tr>
<th></th>
<th>Industry</th>
<th>Bluetooth</th>
<th>802.11x</th>
<th>Zigbee</th>
<th>3G</th>
</tr>
<tr>
<td>Incomplete or vague requirements</td>
<td>63.0%</td>
<td>67.1%</td>
<td>65.0%</td>
<td>76.1%</td>
<td>71.8%</td>
</tr>
<tr>
<td>Insufficient time</td>
<td>45.8%</td>
<td>50.6%</td>
<td>51.5%</td>
<td>43.5%</td>
<td>48.7%</td>
</tr>
<tr>
<td>Insufficient resources</td>
<td>41.8%</td>
<td>34.2%</td>
<td>40.8%</td>
<td>28.3%</td>
<td>48.7%</td>
</tr>
<tr>
<td>Design complexity</td>
<td>41.5%</td>
<td>40.5%</td>
<td>38.8%</td>
<td>45.7%</td>
<td>46.2%</td>
</tr>
<tr>
<td>Creating documentation for the design</td>
<td>23.0%</td>
<td>24.1%</td>
<td>26.2%</td>
<td>28.3%</td>
<td>10.3%</td>
</tr>
<tr>
<td>Insufficient expertise</td>
<td>20.1%</td>
<td>21.5%</td>
<td>19.4%</td>
<td>26.1%</td>
<td>25.6%</td>
</tr>
<tr>
<td>Discovering&nbsp;defects&nbsp;late-development&nbsp;cycle</td>
<td>19.8%</td>
<td>17.7%</td>
<td>14.6%</td>
<td>23.9%</td>
<td>10.3%</td>
</tr>
<tr>
<td>Training new team members</td>
<td>16.9%</td>
<td>20.3%</td>
<td>22.3%</td>
<td>15.2%</td>
<td>25.6%</td>
</tr>
<tr>
<td>Lack of existing software for reuse</td>
<td>13.0%</td>
<td>10.1%</td>
<td>15.5%</td>
<td>10.9%</td>
<td>7.7%</td>
</tr>
<tr>
<td>Developers leaving company or project</td>
<td>10.3%</td>
<td>8.9%</td>
<td>14.6%</td>
<td>10.9%</td>
<td>10.3%</td>
</tr>
<tr>
<td>Poorly integrated development tool chain</td>
<td>9.5%</td>
<td>21.5%</td>
<td>10.7%</td>
<td>19.6%</td>
<td>12.8%</td>
</tr>
<tr>
<td>Standards Compliance</td>
<td>9.0%</td>
<td>10.1%</td>
<td>8.7%</td>
<td>4.3%</td>
<td>5.1%</td>
</tr>
<tr>
<td>Lack of enabling tools</td>
<td>8.7%</td>
<td>5.1%</td>
<td>7.8%</td>
<td>13.0%</td>
<td>7.7%</td>
</tr>
<tr>
<td>Other</td>
<td>2.4%</td>
<td>2.5%</td>
<td>2.9%</td>
<td>0.0%</td>
<td>0.0%</td>
</tr>
</tbody>
</table>
<p>It is useful to compare the responses for each wireless category to that of the broader industry in order to determine how each group responds to each item..</p>
<table>
<caption>In reviewing the purchases you made in the last year, please check the vendor characteristics below that you found to be the most DISAPPOINTING?</caption>
<tbody>
<tr>
<th></th>
<th>Industry</th>
<th>Bluetooth</th>
<th>802.11x</th>
<th>Zigbee</th>
<th>3G</th>
</tr>
<tr>
<td>Lack&nbsp;of&nbsp;quality&nbsp;of&nbsp;products,&nbsp;bugs,&nbsp;difficult&nbsp;to&nbsp;use</td>
<td>50.3%</td>
<td>63.0%</td>
<td>48.9%</td>
<td>58.5%</td>
<td>70.3%</td>
</tr>
<tr>
<td>Product not performing as advertised</td>
<td>44.0%</td>
<td>47.9%</td>
<td>48.9%</td>
<td>61.0%</td>
<td>67.6%</td>
</tr>
<tr>
<td>Non responsive technical support</td>
<td>43.4%</td>
<td>56.2%</td>
<td>53.2%</td>
<td>53.7%</td>
<td>43.2%</td>
</tr>
<tr>
<td>Lack of application support</td>
<td>32.5%</td>
<td>41.1%</td>
<td>41.5%</td>
<td>39.0%</td>
<td>37.8%</td>
</tr>
<tr>
<td>Lack of attention to service problems</td>
<td>27.4%</td>
<td>27.4%</td>
<td>34.0%</td>
<td>36.6%</td>
<td>35.1%</td>
</tr>
<tr>
<td>Delivery time delays</td>
<td>20.5%</td>
<td>21.9%</td>
<td>26.6%</td>
<td>31.7%</td>
<td>24.3%</td>
</tr>
<tr>
<td>Vendor not performing as advertised</td>
<td>18.4%</td>
<td>20.5%</td>
<td>23.4%</td>
<td>19.5%</td>
<td>21.6%</td>
</tr>
<tr>
<td>Other</td>
<td>5.1%</td>
<td>4.1%</td>
<td>5.3%</td>
<td>7.3%</td>
<td>2.7%</td>
</tr>
</tbody>
</table>
<table>
<caption>In general, what FOUR characteristics are the most important to you in buying embedded products and tools?</caption>
<tbody>
<tr>
<th></th>
<th>Industry</th>
<th>Bluetooth</th>
<th>802.11x</th>
<th>Zigbee</th>
<th>3G</th>
</tr>
<tr>
<td>Price/cost/value of product</td>
<td>67.0%</td>
<td>66.7%</td>
<td>66.7%</td>
<td>84.4%</td>
<td>57.5%</td>
</tr>
<tr>
<td>Ease of use of product</td>
<td>59.2%</td>
<td>65.4%</td>
<td>58.8%</td>
<td>66.7%</td>
<td>62.5%</td>
</tr>
<tr>
<td>Quality and reliability of products</td>
<td>54.5%</td>
<td>52.6%</td>
<td>52.0%</td>
<td>40.0%</td>
<td>52.5%</td>
</tr>
<tr>
<td>Compatibility of products</td>
<td>45.0%</td>
<td>44.9%</td>
<td>43.1%</td>
<td>48.9%</td>
<td>55.0%</td>
</tr>
<tr>
<td>Technical support</td>
<td>34.9%</td>
<td>41.0%</td>
<td>39.2%</td>
<td>40.0%</td>
<td>37.5%</td>
</tr>
<tr>
<td>Speed/performance of products</td>
<td>28.2%</td>
<td>28.2%</td>
<td>29.4%</td>
<td>26.7%</td>
<td>17.5%</td>
</tr>
<tr>
<td>Reputation of supplier/vendor</td>
<td>17.6%</td>
<td>16.7%</td>
<td>18.6%</td>
<td>26.7%</td>
<td>17.5%</td>
</tr>
<tr>
<td>Leading edge technology</td>
<td>14.8%</td>
<td>15.4%</td>
<td>19.6%</td>
<td>11.1%</td>
<td>17.5%</td>
</tr>
<tr>
<td>Personal trusted relationship</td>
<td>8.1%</td>
<td>11.5%</td>
<td>8.8%</td>
<td>13.3%</td>
<td>10.0%</td>
</tr>
<tr>
<td>Ease&nbsp;of&nbsp;dealing&nbsp;with&nbsp;vendors&#8217;&nbsp;processes</td>
<td>7.5%</td>
<td>6.4%</td>
<td>8.8%</td>
<td>2.2%</td>
<td>0.0%</td>
</tr>
<tr>
<td>Sales service and support</td>
<td>7.3%</td>
<td>5.1%</td>
<td>4.9%</td>
<td>11.1%</td>
<td>5.0%</td>
</tr>
<tr>
<td>Other</td>
<td>2.0%</td>
<td>2.6%</td>
<td>2.9%</td>
<td>2.2%</td>
<td>0.0%</td>
</tr>
</tbody>
</table>
<table>
<tbody>
<tr>
<th></th>
<th>Industry</th>
<th>Bluetooth</th>
<th>WiFi</th>
<th>Zigbee</th>
</tr>
<tr>
<td>Embedded Linux</td>
<td>32.3%</td>
<td>37.9%</td>
<td>34.8%</td>
<td>44.9%</td>
</tr>
<tr>
<td>Android (OS)</td>
<td>23.8%</td>
<td>42.4%</td>
<td>34.8%</td>
<td>39.1%</td>
</tr>
<tr>
<td>In-House</td>
<td>19.7%</td>
<td>25.8%</td>
<td>15.7%</td>
<td>20.3%</td>
</tr>
<tr>
<td>Free RTOS</td>
<td>18.7%</td>
<td>25.8%</td>
<td>21.7%</td>
<td>31.9%</td>
</tr>
<tr>
<td>Micrium uC/OS-II</td>
<td>15.3%</td>
<td>21.2%</td>
<td>24.3%</td>
<td>24.6%</td>
</tr>
<tr>
<td>Microsoft Windows CE</td>
<td>12.1%</td>
<td>19.7%</td>
<td>16.5%</td>
<td>11.6%</td>
</tr>
<tr>
<td>Microsoft&nbsp;XP&nbsp;Embedded</td>
<td>10.0%</td>
<td>18.2%</td>
<td>13.0%</td>
<td>11.6%</td>
</tr>
<tr>
<td>Apple iOS</td>
<td>9.8%</td>
<td>28.8%</td>
<td>13.9%</td>
<td>18.8%</td>
</tr>
<tr>
<td>Red Hat</td>
<td>8.7%</td>
<td>10.6%</td>
<td>6.1%</td>
<td>7.2%</td>
</tr>
<tr>
<td>Microsoft DOS</td>
<td>7.2%</td>
<td>7.6%</td>
<td>7.8%</td>
<td>7.2%</td>
</tr>
<tr>
<td>Wind River VxWorks 5</td>
<td>7.2%</td>
<td>3.0%</td>
<td>5.2%</td>
<td>1.4%</td>
</tr>
<tr>
<td>TI &#8211; DSP/BIOS</td>
<td>6.6%</td>
<td>10.6%</td>
<td>10.4%</td>
<td>10.1%</td>
</tr>
<tr>
<td>Wind River VxWorks 6</td>
<td>6.6%</td>
<td>1.5%</td>
<td>4.3%</td>
<td>4.3%</td>
</tr>
<tr>
<td>Keil RL-ARM</td>
<td>6.2%</td>
<td>12.1%</td>
<td>5.2%</td>
<td>11.6%</td>
</tr>
<tr>
<td>Green Hills INTEGRITY</td>
<td>5.5%</td>
<td>3.0%</td>
<td>3.5%</td>
<td>4.3%</td>
</tr>
<tr>
<td>QNX</td>
<td>5.5%</td>
<td>13.6%</td>
<td>6.1%</td>
<td>8.7%</td>
</tr>
<tr>
<td>DOS (other than MS)</td>
<td>5.3%</td>
<td>7.6%</td>
<td>6.1%</td>
<td>10.1%</td>
</tr>
<tr>
<td>Microsoft &#8211; Other</td>
<td>5.1%</td>
<td>7.6%</td>
<td>6.1%</td>
<td>2.9%</td>
</tr>
<tr>
<td>Quadros RTXC</td>
<td>4.7%</td>
<td>4.5%</td>
<td>2.6%</td>
<td>4.3%</td>
</tr>
<tr>
<td>Other embedded Linux</td>
<td>4.2%</td>
<td>4.5%</td>
<td>6.1%</td>
<td>5.8%</td>
</tr>
<tr>
<td>Keil RTX</td>
<td>4.0%</td>
<td>3.0%</td>
<td>4.3%</td>
<td>7.2%</td>
</tr>
<tr>
<td>Express Logic ThreadX</td>
<td>3.9%</td>
<td>4.5%</td>
<td>0.9%</td>
<td>4.3%</td>
</tr>
<tr>
<td>LynuxWorks LynxOS</td>
<td>3.4%</td>
<td>3.0%</td>
<td>0.9%</td>
<td>1.4%</td>
</tr>
<tr>
<td>Wind River Linux</td>
<td>3.4%</td>
<td>0.0%</td>
<td>0.9%</td>
<td>2.9%</td>
</tr>
<tr>
<td>OSEK</td>
<td>3.2%</td>
<td>3.0%</td>
<td>0.9%</td>
<td>1.4%</td>
</tr>
</tbody>
</table>
<table>
<caption>In which of the following form factors will you most likely be designing in 2013?</caption>
<tbody>
<tr>
<th></th>
<th>Industry</th>
<th>Bluetooth</th>
<th>802.11x</th>
<th>Zigbee</th>
</tr>
<tr>
<td>STDbus</td>
<td>38.2%</td>
<td>41.5%</td>
<td>40.3%</td>
<td>36.1%</td>
</tr>
<tr>
<td>EPIC</td>
<td>27.0%</td>
<td>36.9%</td>
<td>27.8%</td>
<td>29.5%</td>
</tr>
<tr>
<td>PCI/104 (PCI bus only)</td>
<td>19.3%</td>
<td>16.9%</td>
<td>19.4%</td>
<td>25.4%</td>
</tr>
<tr>
<td>PCIe NGFF</td>
<td>10.3%</td>
<td>7.7%</td>
<td>8.3%</td>
<td>14.8%</td>
</tr>
<tr>
<td>PCI Express</td>
<td>8.6%</td>
<td>7.7%</td>
<td>6.9%</td>
<td>12.3%</td>
</tr>
<tr>
<td>AdvancedTCA</td>
<td>7.7%</td>
<td>12.3%</td>
<td>8.3%</td>
<td>9.8%</td>
</tr>
<tr>
<td>Mini-ITX</td>
<td>6.3%</td>
<td>7.7%</td>
<td>8.3%</td>
<td>9.8%</td>
</tr>
<tr>
<td>PC/104-Plus (ISA &amp; PCI buses)</td>
<td>6.3%</td>
<td>4.6%</td>
<td>6.9%</td>
<td>9.8%</td>
</tr>
<tr>
<td>PC/104 (ISA bus only)</td>
<td>6.1%</td>
<td>6.2%</td>
<td>8.3%</td>
<td>9.8%</td>
</tr>
<tr>
<td>CompactPCI</td>
<td>5.4%</td>
<td>6.2%</td>
<td>4.2%</td>
<td>7.4%</td>
</tr>
<tr>
<td>Custom designs</td>
<td>4.0%</td>
<td>6.2%</td>
<td>6.9%</td>
<td>4.9%</td>
</tr>
<tr>
<td>EBX</td>
<td>3.7%</td>
<td>7.7%</td>
<td>5.6%</td>
<td>7.4%</td>
</tr>
<tr>
<td>COM Express</td>
<td>3.5%</td>
<td>6.2%</td>
<td>1.4%</td>
<td>4.9%</td>
</tr>
<tr>
<td>Proprietary</td>
<td>3.5%</td>
<td>7.7%</td>
<td>4.2%</td>
<td>5.7%</td>
</tr>
<tr>
<td>ATX</td>
<td>3.0%</td>
<td>6.2%</td>
<td>4.2%</td>
<td>3.3%</td>
</tr>
<tr>
<td>Qseven</td>
<td>3.0%</td>
<td>4.6%</td>
<td>1.4%</td>
<td>4.1%</td>
</tr>
<tr>
<td>SUMIT-104&nbsp;(SUMIT&nbsp;&amp;&nbsp;ISA&nbsp;Expansion)</td>
<td>3.0%</td>
<td>1.5%</td>
<td>2.8%</td>
<td>3.3%</td>
</tr>
<tr>
<td>PCI</td>
<td>2.8%</td>
<td>3.1%</td>
<td>4.2%</td>
<td>4.1%</td>
</tr>
<tr>
<td>COM</td>
<td>2.3%</td>
<td>4.6%</td>
<td>4.2%</td>
<td>3.3%</td>
</tr>
<tr>
<td>MicroTCA</td>
<td>2.3%</td>
<td>4.6%</td>
<td>5.6%</td>
<td>6.6%</td>
</tr>
<tr>
<td>PC/104</td>
<td>2.3%</td>
<td>7.7%</td>
<td>4.2%</td>
<td>3.3%</td>
</tr>
<tr>
<td>PCI/104-Express</td>
<td>2.1%</td>
<td>1.5%</td>
<td>0.0%</td>
<td>2.5%</td>
</tr>
<tr>
<td>MicroATX</td>
<td>1.4%</td>
<td>3.1%</td>
<td>0.0%</td>
<td>2.5%</td>
</tr>
<tr>
<td>ETX</td>
<td>1.2%</td>
<td>3.1%</td>
<td>1.4%</td>
<td>2.5%</td>
</tr>
<tr>
<td>SUMIT-EBX (SUMIT &amp; ISA Expansion)</td>
<td>0.9%</td>
<td>3.1%</td>
<td>0.0%</td>
<td>2.5%</td>
</tr>
<tr>
<td>SUMIT-EPIC (SUMIT &amp; ISA Expansion)</td>
<td>0.5%</td>
<td>0.0%</td>
<td>1.4%</td>
<td>0.8%</td>
</tr>
<tr>
<td>SUMIT-ISM&nbsp;(SUMIT&nbsp;&amp;&nbsp;PCI&nbsp;or&nbsp;ISA&nbsp;expansion)</td>
<td>0.2%</td>
<td>0.0%</td>
<td>0.0%</td>
<td>0.8%</td>
</tr>
<tr>
<td>VMEbus</td>
<td>0.2%</td>
<td>0.0%</td>
<td>0.0%</td>
<td>0.8%</td>
</tr>
<tr>
<td>VPX</td>
<td>0.0%</td>
<td>0.0%</td>
<td>0.0%</td>
<td>0.0%</td>
</tr>
<tr>
<td>Other</td>
<td>7.7%</td>
<td>6.2%</td>
<td>2.8%</td>
<td>8.2%</td>
</tr>
</tbody>
</table>
]]></content:encoded>
			<wfw:commentRss>http://micrium.com/2013-embedded-market-forecasters-survey-of-embedded-developers-bluetooth-respondents/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>DO 178B &#8211; Redux: Looking at Developer Preferences, Issues and Vendor Cost</title>
		<link>http://micrium.com/do-178b-redux-looking-at-developer-preferences-issues-and-vendor-cost/</link>
		<comments>http://micrium.com/do-178b-redux-looking-at-developer-preferences-issues-and-vendor-cost/#comments</comments>
		<pubDate>Wed, 13 Mar 2013 20:51:47 +0000</pubDate>
		<dc:creator>Jim Royal</dc:creator>
				<category><![CDATA[Article]]></category>

		<guid isPermaLink="false">http://micrium.com/?p=3182</guid>
		<description><![CDATA[DO 178B &#8211; Redux: Looking at Developer Preferences, Issues and Vendor Cost Jerry Krasner, Ph.D., MBA April 2013 About EMF EMF is the premier market intelligence and advisory firm in the embedded technology industry. Embedded technology refers to the ubiquitous &#8230; <a href="http://micrium.com/do-178b-redux-looking-at-developer-preferences-issues-and-vendor-cost/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>DO 178B &#8211; Redux: Looking at Developer Preferences, Issues and Vendor Cost</p>
<p>Jerry Krasner, Ph.D., MBA<br />
April 2013</p>
<h3>About EMF</h3>
<p>EMF is the premier market intelligence and advisory firm in the embedded technology industry. Embedded technology refers to the ubiquitous class of products which use some type of processor as a controller. These products include guided missiles, radars, and avionics as well as robots, automobiles, telecom gear, and medical electronics.</p>
<p>Embedded Market Forecasters (EMF) is the market research division of American Technology International, Inc. EMF clients range from startups to Global 100 companies worldwide. Founded by Dr. Jerry Krasner, a recognized authority on electronics markets, product development and channel distribution, EMF is headquartered in Framingham, Mass.</p>
<p><a href="http://www.embeddedforecast.com/">www.embeddedforecast.com</a></p>
<h3>About the Author</h3>
<p>Jerry Krasner, Ph.D., MBA is Vice President of Embedded Market Forecasters and its parent company, American Technology International. A recognized authority with over 30 years of embedded industry experience, Dr. Krasner was formerly Chairman of Biomedical Engineering at Boston University, and Chairman of Electrical and Computer Engineering at Wentworth Institute of Technology and Bunker Hill Community College. In addition to his academic appointments, Dr. Krasner served as President of Biocybernetics, Inc. and CLINCO, Inc., Executive Vice President of Plasmedics, Inc. and Clinical Development Corporation, and Director of Medical Sciences for the Carnegie-Mellon Institute of Research. Earlier, he was Senior Engineer at the MIT Instrumentation Laboratory. Dr. Krasner earned BSEE and MSEE degrees from Washington University, a Ph.D. in Medical Physiology / Biophysics from Boston University and an MBA from Nichols College.</p>
<h3>Regarding the Data in this Report</h3>
<p>The data that is referred to in this report is <em>statistically accurate</em> and <em>authentic</em> and is based on:</p>
<ul>
<li>A statistically generated comprehensive and detailed survey of embedded developers and managers who reported on their design results (number of developers per project, vertical market of their design, time to market, percent of designs completed behind schedule or cancelled, closeness of final design outcomes to pre-design expectations, testing outcomes, etc.), the tools they used (development, modeling, Java, Eclipse, and other development tools), their choice of OS, IDE, communication middleware, processors used as well as where they go to learn about new products, tools and concepts.</li>
<li>An EMF Dashboard – a unique tool that allows the user to simultaneously compare similar products (vendors can do competitive comparative analysis); that marketing executives can use for sales promo and strategic planning; that allows developers beginning a project to compare the experiences of hundreds of fellow developers that undertook similar projects to gain insights before making a commitment; and that allows CFOs and senior managers to look at what tools and processes resulted in the greatest cost savings.</li>
</ul>
<p>For the interested reader, the following link demonstrates the power of the Dashboard and how we used it in developing the data that is presented herein:</p>
<p><a href="http://www.embeddedforecast.com/EMF_DashboardIntro/EMF_DashboardIntro.html">http://www.embeddedforecast.com/EMF_DashboardIntro/EMF_DashboardIntro.html</a></p>
<h3>Executive Summary</h3>
<p>Embedded Market Forecasters (EMF) used its 2011 survey of embedded developers (642 respondents) to look at the habits and concerns of DO178B developers and how their activities and designs compared with the broad embedded industry. Using its unique to the industry Embedded Dashboard, comparisons and correlations were undertaken and published in 2012.</p>
<p>In this report, EMF reports on the results of the EMF 2013 Survey of Embedded Developers to compare the current data with that of the 2012 publication.</p>
<p>Among the reported findings in this paper are:</p>
<ul>
<li>The total developer cost per project was about 10% higher for DO178B projects in both the 2012 and 2013 data</li>
<li>Modeling-simulation and CMMI use ranked higher among DO178B developers in 2012 then in 2013. In 2013, CMMI and Common Criteria requirements dropped off the list of the top 5 items considered a Best Practice by DO 178B developers</li>
<li>Incomplete/vague requirements and insufficient resources continue to be of greater concern to DO 178B developers in 2013 as the most significant issues confronting embedded developers. Design complexity as a significant issue rose from 31% of DO 178 respondents to 51.9% in 2013</li>
<li>In 2013, when asked about the most important criteria for their OS selection, “safety certifiable”, “realtime performance”, “prior experience with OS”, and “Linux compatibility” fell out of favor as criteria for OS selection whereas “acquisition cost”, “microprocessor support” and “availability of source code” became the criteria of greatest importance.</li>
<li>EMF made Total Project Cost calculations for three of the most recognized OSes (VxWorks Secure, Integrity Secure and LynxOS Secure). Micrium uC/OS-II was selected as a representative of lesser known OSes for purposes of comparison. Micrium has been available for more than a decade and is deployed in 10’s of millions of applications. Interestingly, Micrium again in 2013 had the least cost per project</li>
</ul>
<h3>Background</h3>
<p>Eighteen months ago EMF published its findings illustrating the activities of DO178B developers compared with the activities of embedded developers whose designs don’t require certified operating systems. We had read and listened to the many advocates and users of DO 178B based developments. What we didn’t find was data that reflected the concerns, design choices, and experiences of DO178B developers. So in January 2012 we made our findings public.</p>
<p>The information was welcomed by the industry and some of the findings were not expected. EMF was encouraged to revisit the DO178B topic to see if the 2012 findings (based on the extensive 2011 EMF Survey of Embedded Developers) were a one-time look into the industry or if they were repeatable.</p>
<p>Revisiting a topic such as this is always a good idea. The findings from the 2013 EMF Survey of Embedded Developers are presented here. It is interesting to observe what, if anything, has changed during the two year interval.</p>
<h3>Introduction</h3>
<p>The RTOS marketplace is highly competitive, if not zero sum close to it, and is filled with claims, counter claims and FUD. Vendors will have you believe that a certified OS is superior to one that has not undergone a certification process. Linux, for example, is not certifiable under DO 178B. However billions of devices run with commercial Linux OSes. Certainly, mission critical applications are expected to run at a higher level of certainty – we can’t have airplanes falling out of the sky. The idea that DO 178B certification is necessary for medical patient monitoring, for example, is ridiculous (the highest frequency response required for patient monitoring is 100 Hz) and the attempted use of FUD to scare medical developers into using such has backfired.</p>
<p>The decision to absorb the expense of DO 178B certification is most often a strategic marketing decision. If one doesn’t sell to the military or avionics marketplace there is little need to incur such expense.</p>
<p>EMF conducts annual detailed and comprehensive surveys of embedded developers in a manner so as to maintain statistical accuracy. Between March 2009 and April 2011, EMF gathered data from 1975 developers to look at design outcomes (time-to-market, design completions ahead of or behind schedule, closeness of final design results to pre-design expectations, etc.) and to look at the relative levels of lines-of-code for different application verticals. For the purpose of the 2012 report we relied on the results of the 2011 EMF Embedded Developer Survey (642 respondents). The 2013 survey contained the responses of 595 developers (95% +/- 4.0% accuracy).</p>
<p>For many military and aerospace/avionics applications, application software requires adherence to such standards as DO 178B/Level A, ARINC 653, Common Criteria and MILS, among others. Developers are exposed to a myriad of claims and counter claims.</p>
<p>In this report, EMF data is used to determine project costs for several RTOSes certified to DO 178B Level A. This should certainly be of interest to OEMs and systems integrators who make OS and processor choices for their specific applications. We also<br />
report which issues these developers identify as having the greatest impact on their design efforts.</p>
<p>Recently, smaller companies have had their OSes certified under DO 178 B Level A – and it raises the question whether they offer, in addition to their intrinsic capabilities, a comparable return on investment (ROI). In this report we compare project costs for well known certified RTOSes (Integrity, VxWorks and LynxOS) as well as with Micrium uC/OS II, a lesser known but certified DO 178B RTOS.</p>
<h3>Methodology</h3>
<p>The data that is referred to in this report is statistically accurate and authentic and is based on:</p>
<ul>
<li>A statistically generated comprehensive and detailed survey of embedded developers and managers who reported on their design results (number of developers per project, vertical market of their design, time to market, percent of designs completed behind schedule or cancelled, closeness of final design outcomes to pre-design expectations, testing outcomes, etc.), the tools they used (development, modeling, Java, Eclipse, and other development tools), their choice of OS, IDE, communication middleware, processors used as well as where they go to learn about new products, tools and concepts.</li>
<li>An EMF Dashboard – a unique tool that allows the user to simultaneously compare similar products (vendors can do competitive comparative analysis); that marketing executives can use for sales promo and strategic planning; that allows developers beginning a project to compare the experiences of hundreds of fellow developers that undertook similar projects to gain insights before making a commitment; and that allows CFOs and senior managers to look at what tools and processes resulted in the greatest cost savings. The interested reader can view a Dashboard demo at http://www.embeddedforecast.com/EMF_DashboardIntro/EMF_DashboardIntr o.html</li>
<li>Five hundred and ninety-five developers responded to the online survey, of which 51 were hardware engineers, 124 were software engineers, 73 were systems developers, 43 were systems architects, 90 were firmware engineers and 126 were engineering managers. In addition 75 developers gave titles other than these listed. This provided an excellent distribution of experiences and viewpoints from which to draw inferences and conclusions. Statistically, the response is at a 95% confidence level, plus or minus 4.0%.</li>
<li>49.5% of respondents came from North America, while 18.4% were from Asia and 32.1% were from Europe.</li>
</ul>
<h3>Comparing DO 178B Development Activities with Worldwide Embedded Development Activities</h3>
<p><strong>Average Cost of Development:</strong></p>
<p>Table I presents the comparative costs of development between DO 178B and other embedded developments.</p>
<p>The EMF Dashboard was filtered to create two cadres that were simultaneously compared, side-by-side. The Dashboard was used to determine (from questions within the survey) the comparative costs using:</p>
<p>a) Number of software developers per project<br />
b) Number of months from design start to product shipment<br />
c) Percent of designs completed behind schedule<br />
d) Number of months behind schedule<br />
e) Percent of designs cancelled<br />
f) Number of months between project start and cancellation</p>
<p>Multiplying a) and b) provides the total average number of man-months expended in a project. Multiplying a), c) and d) provide the average number of man-months lost to schedule. Multiplying a), e), and f) provide the number of man months lost to cancellation. Adding these results provides the total number of project man-months.</p>
<table>
<caption>Table I: Comparative Costs for Certified (DO 178B) and non-certified RTOSes</caption>
<tr>
<th></th>
<th>2012 Ind ave<br />All RTOSes</th>
<th>2012 DO 178B<br />Users</th>
<th>2013 Ind ave<br />All RTOSes </th>
<th>2013 DO 178B<br />Users</th>
</tr>
<tr>
<td>Devel time Months</td>
<td>13.9 </td>
<td>17.9 </td>
<td>13.8 </td>
<td>17.4 </td>
</tr>
<tr>
<td>% behind schedule</td>
<td>47.0% </td>
<td>50.0% </td>
<td>38.5% </td>
<td>38.4% </td>
</tr>
<tr>
<td>Months behind</td>
<td>3.8 </td>
<td>5.7 </td>
<td>6.3 </td>
<td>3.8 </td>
</tr>
<tr>
<td>% Cancelled</td>
<td>11.0% </td>
<td>8.9% </td>
<td>9.0% </td>
<td>9.2% </td>
</tr>
<tr>
<td>Months&nbsp;before&nbsp;cancellation</td>
<td>4.7 </td>
<td>6.3 </td>
<td>4.4 </td>
<td>5.5 </td>
</tr>
<tr>
<td>SW Developers/project</td>
<td>14.7 </td>
<td>12 </td>
<td>12.3 </td>
<td>13.3 </td>
</tr>
<tr>
<td>Average Developer months/project </td>
<td>204.33 </td>
<td>214.8 </td>
<td>169.7 </td>
<td>231.4 </td>
</tr>
<tr>
<td>Developer months lost to schedule </td>
<td>26.3</td>
<td>34.2</td>
<td>29.8</td>
<td>19.4</td>
</tr>
<tr>
<td>Developer months lost to Cancellation</td>
<td>7.6 </td>
<td>6.7 </td>
<td>4.9</td>
<td>6.7 </td>
</tr>
<tr>
<td>Total developer months/ project </td>
<td>238.2</td>
<td>255.7</td>
<td>204.4</td>
<td>257.6</td>
</tr>
<tr>
<td>At $10,000/developer month </td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Average developer cost/project </td>
<td>$2,381,841 </td>
<td>$2,557,284 </td>
<td>$2,044,445 </td>
<td>$2,314,200 </td>
</tr>
<tr>
<td>Average cost to delay</td>
<td>$338,541</td>
<td>$409,284</td>
<td>$347,045</td>
<td>$261,372</td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Total developer cost/project</td>
<td>$2,720,382</td>
<td>$2,966,568</td>
<td>$2,391,489</td>
<td>$2,575,572</td>
</tr>
</table>
<p>Interestingly, the average project cost between DO 178B developments and non-DO 178B development remained remarkably consistent between the 2011 and 2013 surveys. This adds to the confidence level of the findings. The longer development times for DO 178B projects is not surprising given the nature of mission critical applications for which certified OSes are required (this might be explained for mil/aero developments).</p>
<p>Table II presents Best Practices as perceived by developers for the years 2012-2013. Since the 2012 report was based on 2011 survey data, the time span is actually two years. It is interesting to observe that only 68.4% of DO 178B developers consider it a Best Practice (compared with 14.1% of the industry).</p>
<table>
<caption>Table II: Processes Considered being a Best Practice</caption>
<tr>
<th>2013</th>
<th>Do 178B</th>
<th>Industry</th>
</tr>
<tr>
<td>DO-178B/C</td>
<td>68.4% </td>
<td>14.1% </td>
</tr>
<tr>
<td>Peer reviews</td>
<td>26.3% </td>
<td>26.8% </td>
</tr>
<tr>
<td>V-Model</td>
<td>25.0% </td>
<td>13.7% </td>
</tr>
<tr>
<td>Agile Methodologies </td>
<td>23.7% </td>
<td>33.6% </td>
</tr>
<tr>
<td>Modeling/simulation</td>
<td>19.7%</td>
<td>16.0%</td>
</tr>
</table>
<table>
<tr>
<th>2012</th>
<th>Do 178B</th>
<th>Industry</th>
</tr>
<tr>
<td>DO 178B </td>
<td>60.3% </td>
<td>12.9% </td>
</tr>
<tr>
<td>Modeling-Simulation</td>
<td>34.5% </td>
<td>22.7% </td>
</tr>
<tr>
<td>Peer reviews</td>
<td>34.5% </td>
<td>35.9% </td>
</tr>
<tr>
<td>Process Management (CMMI) </td>
<td>22.4% </td>
<td>10.1% </td>
</tr>
<tr>
<td>Agile Methodologies</td>
<td>19.0%</td>
<td>26.3%</td>
</tr>
</table>
<p>Given the strict oversight of software development, it is surprising to see that Common Criteria is not ranked high by DO 178B developers as a Best Practice. It makes sense that modeling-simulation would be a benefit to these developers – particularly with the need for code reuse. We’d like to believe that CMMI is a hold over as a bad habit from prior years – it means that you have to employ a consistent process; not necessarily a good process.</p>
<p>Developers were asked to identify the most significant issues impacting their software development. They were given a list of 15 possible responses (they could do a write in as well) and they were limited to a maximum of four choices. In this manner we were able to develop a hierarchy of issues illustrated by the percentage of respondents that chose that option. These comparative responses are presented in Table III.</p>
<table>
<caption>Table III: Most Significant Issues Confronting Embedded Developers</caption>
<tr>
<th>2013</th>
<th>Do 178B</th>
<th>Industry</th>
</tr>
<tr>
<td>Incomplete or vague requirements</td>
<td>57.0%</td>
<td>51.4% </td>
</tr>
<tr>
<td>Design complexity</td>
<td>51.9%</td>
<td>41.7% </td>
</tr>
<tr>
<td>Insufficient resources</td>
<td>35.4%</td>
<td>39.5% </td>
</tr>
<tr>
<td>Insufficient time</td>
<td>27.8%</td>
<td>38.4% </td>
</tr>
<tr>
<td>Prolonged development cycle</td>
<td>26.6%</td>
<td>24.2%</td>
</tr>
</table>
<table>
<tr>
<th>2012</th>
<th>Do 178B</th>
<th>Industry</th>
</tr>
<tr>
<td>Incomplete/vague requirements </td>
<td>62.1%</td>
<td>53.4% </td>
</tr>
<tr>
<td>Insufficient resources </td>
<td>46.6%</td>
<td>40.9% </td>
</tr>
<tr>
<td>Insufficient time</td>
<td>34.5%</td>
<td>44.7% </td>
</tr>
<tr>
<td>Design complexity</td>
<td>31.0%</td>
<td>38.5% </td>
</tr>
<tr>
<td>Standards compliance</td>
<td>24.1%</td>
<td>13.5%</td>
</tr>
</table>
<p>Clearly DO 178B developers are not as concerned about enabling tools or time constraints. Design complexity was reported in 2013 as a major concern for DO 178B developers and this is consistent with their use of modeling-simulation tools (Table II). Concluding our look at comparative developer characteristics and preferences, Table IV presents the reported criteria that are most important to developers in selecting an operating system.</p>
<table>
<caption>Table IV: Criteria Most Important in Selecting their Next OS</caption>
<tr>
<th>2013</th>
<th>Do 178B</th>
<th>Industry</th>
</tr>
<tr>
<td>Acquisition cost</td>
<td>43.9% </td>
<td>44.9% </td>
</tr>
<tr>
<td>Microprocessor support</td>
<td>42.5% </td>
<td>35.9% </td>
</tr>
<tr>
<td>Availability of source code</td>
<td>40.7% </td>
<td>25.6% </td>
</tr>
<tr>
<td>Real time performance</td>
<td>37.1% </td>
<td>44.9% </td>
</tr>
<tr>
<td>Compatibility with our development tools</td>
<td>32.9% </td>
<td>21.8% </td>
</tr>
<tr>
<td>Reliability</td>
<td>27.3% </td>
<td>26.9% </td>
</tr>
<tr>
<td>Safety certifiable</td>
<td>13.8%</td>
<td>44.9%</td>
</tr>
</table>
<table>
<tr>
<th>2012</th>
<th>Do 178B</th>
<th>Industry</th>
</tr>
<tr>
<td>Safety certifiable </td>
<td>67.9% </td>
<td>15.0% </td>
</tr>
<tr>
<td>Realtime performance </td>
<td>51.8% </td>
<td>37.3% </td>
</tr>
<tr>
<td>Acquisition cost </td>
<td>35.7% </td>
<td>37.3% </td>
</tr>
<tr>
<td>Microprocessor support </td>
<td>23.2% </td>
<td>30.5% </td>
</tr>
<tr>
<td>Prior experience with OS </td>
<td>21.4% </td>
<td>14.8% </td>
</tr>
<tr>
<td>Availability of source code </td>
<td>16.1% </td>
<td>27.8% </td>
</tr>
<tr>
<td>Compatible with Linux</td>
<td>7.1%</td>
<td>20.8%</td>
</tr>
</table>
<p>EMF has no idea why safety certifiable dropped by 50% in importance between 2012 and 2013. Interestingly, cost and microprocessor became more of an issue with DO 178B developers during this time period. Not surprisingly, Linux support appears to be a non-issue with DO 178B developers. We will need to wait for the 2014 survey to see if there is a trend.</p>
<h3>Comparing Associated Costs for Comparable DO 178B Operating Systems</h3>
<p>For more than a decade, the mission critical and standards-based market has been dominated by Wind River (VxWorks), Green Hills Software (Integrity), and LynuxWorks (LynxOS). Recently there has been competition from such vendors as Micrium, Express Logic and commercial Linux vendors. Of particular interest are the costs associated with projects using alternative OSes for DO 178B required developments and how they compare with VxWorks, Integrity or LynuxWorks OS. We chose to include Micrium as an example of an alternative choice. All four OSes presented are certified to DO 178B/C Level A. The results are presented in Table V and the calculations were made the same as for Table I. This Table was derived from data that was based on the following number of lines of code:</p>
<ul>
<li>Green Hills: 1008 thousand lines of code</li>
<li>LynxOS – 717 thousand lines of code</li>
<li>Micrium – 579 thousand lines of code</li>
<li>VxWorks – 542 thousand lines of code</li>
<li>Industry average – 569 thousand lines of code</li>
</ul>
<table>
<caption>Table V: Comparative Project Costs for DO 178B/C Operating Systems</caption>
<tr>
<th></th>
<th>Micrium uC/OS </th>
<th>GHS Secure </th>
<th>LynxOS Secure</th>
<th>VxWorks Secure </th>
</tr>
<tr>
<td>Devel time Months</td>
<td>12.1 </td>
<td>18.9 </td>
<td>15.2</td>
<td>16.8 </td>
</tr>
<tr>
<td>% behind schedule</td>
<td>38.5% </td>
<td>44.5% </td>
<td>41.7%</td>
<td>43.8% </td>
</tr>
<tr>
<td>Months behind</td>
<td>2.8 </td>
<td>4 </td>
<td>4.2</td>
<td>4.4 </td>
</tr>
<tr>
<td>% Cancelled</td>
<td>12.4% </td>
<td>6.9% </td>
<td>8.0%</td>
<td>5.6% </td>
</tr>
<tr>
<td>Months&nbsp;before&nbsp;cancellation</td>
<td>3.7</td>
<td>5.7 </td>
<td>7.3</td>
<td>5.1 </td>
</tr>
<tr>
<td>SW Developers/project</td>
<td>5 </td>
<td>16</td>
<td>12.9</td>
<td>14.7</td>
</tr>
<tr>
<td>HW Developers/project</td>
<td>3.4 </td>
<td>10.7</td>
<td>5.6</td>
<td>4.8 </td>
</tr>
<tr>
<td>Total Developers/Project</td>
<td>8.4 </td>
<td>26.7</td>
<td>18.5</td>
<td>19.5</td>
</tr>
<tr>
<td>Average Developer months/project </td>
<td>101.6 </td>
<td>504.6 </td>
<td>281.2 </td>
<td>327.6 </td>
</tr>
<tr>
<td>Developer months lost to schedule </td>
<td>9.1 </td>
<td>47.5 </td>
<td>32.4 </td>
<td>37.6 </td>
</tr>
<tr>
<td>Developer months lost to cancellation </td>
<td>3.9</td>
<td>10.5</td>
<td>10.8</td>
<td>5.6</td>
</tr>
<tr>
<td>Total Developer months lost cancel/delay</td>
<td>12.9</td>
<td>58.0</td>
<td>43.2 </td>
<td>43.1 </td>
</tr>
<tr>
<td>Total developer months/ project </td>
<td>114.5</td>
<td>562.7</td>
<td>324.4</td>
<td>370.7</td>
</tr>
<tr>
<td>At $10,000/developer month </td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Average developer cost/project </td>
<td>$1,145,491 </td>
<td>$5,626,571 </td>
<td>$3,244,049 </td>
<td>$3,707,496 </td>
</tr>
<tr>
<td>Average cost to delay</td>
<td>$129,091</td>
<td>$580,271</td>
<td>$432,049</td>
<td>$431,496</td>
</tr>
<tr>
<td>Total developer cost/project</td>
<td>$1,274,582</td>
<td>$6,206,842</td>
<td>$3,676,098</td>
<td>$4,138,992</td>
</tr>
</table>
<p>Note that Table V includes the project cost of hardware developers.</p>
<h3>Summary</h3>
<p>It is interesting to note that a lesser known OS compared very favorably compared to the more established DO 178B OSes. This repeats the findings reported in 2012.</p>
<p>It is clear from the presented analysis that embedded developers looking for a certified RTOS take into account the design particulars of their applications and the compute power required. EMF hopes that this analysis will help developers to look at certified software from a different perspective.</p>
<p>First, choose the RTOS that best meets your application. Such considerations as the following should be first considered:</p>
<ul>
<li>Power requirements</li>
<li>Worst case interrupt latency</li>
<li>Worst case context-switch times </li>
<li>Time-to-market considerations</li>
<li>Ease-of-use</li>
<li>Footprint</li>
<li>Budget</li>
</ul>
<p>The latency and context-switch times are usually processor specific and can be gotten from the chip vendors. For a better discussion of this topic see Michael Barr’s view at:</p>
<p><a href="http://www.netrino.com/Embedded-Systems/How-To/RTOS-Selection">http://www.netrino.com/Embedded-Systems/How-To/RTOS-Selection</a></p>
<p>It is not immediately clear as to why the project cost of the lesser known OSes is significantly less that those of the “big three”. It might have to do with them having been selected specifically for the application at hand, ease of learning a new OS, or other considerations.</p>
<p>What is clear from this year-over-year data is that DO178B developers have a broader range of choices and that switching OSes might be less troublesome than previously thought.</p>
]]></content:encoded>
			<wfw:commentRss>http://micrium.com/do-178b-redux-looking-at-developer-preferences-issues-and-vendor-cost/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Multicore’s Place in the Real-Time World</title>
		<link>http://micrium.com/multicores-in-the-real-time-world/</link>
		<comments>http://micrium.com/multicores-in-the-real-time-world/#comments</comments>
		<pubDate>Mon, 04 Feb 2013 16:16:06 +0000</pubDate>
		<dc:creator>Jim Royal</dc:creator>
				<category><![CDATA[Article]]></category>

		<guid isPermaLink="false">http://micrium.com/?p=2971</guid>
		<description><![CDATA[By Matt Gordon Senior Applications Engineer at Micrium Multicore CPU architectures are a little like hybrid vehicles: Once seen as anomalies, both are now encountered on a regular basis and are widely accepted as possible solutions to challenging problems. Also, &#8230; <a href="http://micrium.com/multicores-in-the-real-time-world/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>By Matt Gordon<br />
Senior Applications Engineer at Micrium</p>
<p>Multicore CPU architectures are a little like hybrid vehicles: Once seen as anomalies, both are now encountered on a regular basis and are widely accepted as possible solutions to challenging problems. Also, much as hybrid designs are not expected to fully supplant the traditional, internal combustion engine in the foreseeable future, multicore architectures likely won’t force the extinction of single-core MCUs anytime soon.</p>
<p>Within the embedded community, a few applications now seem to be almost exclusively multicore, but in many others multicore remains rare. The reasons for not migrating to multicore include concerns over the complexity of multicore platforms and uncertainty about the benefits that multicore offers.</p>
<p>Uncertainty about the benefits may be the primary reason for the lack of multicore adoption amongst one particular subset of developers—those who deal with real-time systems. Multicore devices seem to have acquired a reputation as not suitable for the rigors of real-time design. Although there is certainly some truth to this characterization, it is also true that today’s multicore landscape encompasses a number of hardware platforms and design techniques that hold potential for developers of real-time systems. </p>
<p>Read the entire article at the <a href="http://www2.electronicproducts.com/Multicore_s_place_in_the_real_time_world-article-FAJH_Micrium_Jan2013-html.aspx">Electronic Products site.</a></p>
]]></content:encoded>
			<wfw:commentRss>http://micrium.com/multicores-in-the-real-time-world/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Free Three-Day µC/OS-III and µC/TCP-IP Workshop</title>
		<link>http://micrium.com/free-three-day-%c2%b5cos-iii-and-%c2%b5ctcp-ip-workshop/</link>
		<comments>http://micrium.com/free-three-day-%c2%b5cos-iii-and-%c2%b5ctcp-ip-workshop/#comments</comments>
		<pubDate>Fri, 25 Jan 2013 22:53:09 +0000</pubDate>
		<dc:creator>Jim Royal</dc:creator>
				<category><![CDATA[Event]]></category>

		<guid isPermaLink="false">http://micrium.com/?p=2911</guid>
		<description><![CDATA[Join us for free, hands-on training at our facility in Weston, Florida. With the purchase of any uC/OS-II or uC/OS-III software license, you can benefit from three full-day sessions with Micrium’s Matt Gordon. More information about Micrium training.]]></description>
			<content:encoded><![CDATA[<p>Join us for free, <a href="http://micrium.com/training/livetraining/" title="Live Training">hands-on training at our facility in Weston, Florida</a>. With the purchase of any uC/OS-II or uC/OS-III software license, you can benefit from three full-day sessions with Micrium’s Matt Gordon.</p>
<p><a href="http://micrium.com/training/livetraining/" title="Live Training">More information about Micrium training.</a></p>
]]></content:encoded>
			<wfw:commentRss>http://micrium.com/free-three-day-%c2%b5cos-iii-and-%c2%b5ctcp-ip-workshop/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Developers Report on their Use of Wireless Protocols for Embedded Applications</title>
		<link>http://micrium.com/developers-report-on-their-use-of-wireless-protocols-for-embedded-applications/</link>
		<comments>http://micrium.com/developers-report-on-their-use-of-wireless-protocols-for-embedded-applications/#comments</comments>
		<pubDate>Thu, 24 Jan 2013 22:57:32 +0000</pubDate>
		<dc:creator>Jim Royal</dc:creator>
				<category><![CDATA[Article]]></category>

		<guid isPermaLink="false">http://micrium.com/?p=2880</guid>
		<description><![CDATA[Developers Report on their Use of Wireless Protocols for Embedded Applications Jerry Krasner, PhD. Copyright 2013 by American Technology International, Inc, 638 Main St., Ashland, MA 01721. All rights reserved. No part of this book covered by copyright hereon may &#8230; <a href="http://micrium.com/developers-report-on-their-use-of-wireless-protocols-for-embedded-applications/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>Developers Report on their Use of Wireless Protocols for Embedded Applications<br />
Jerry Krasner, PhD. </p>
<p><em>Copyright 2013 by American Technology International, Inc, 638 Main St., Ashland, MA 01721. All rights reserved. No part of this book covered by copyright hereon may be reproduced or copied in any manner whatsoever. Every effort has been made to provide accurate data. To the best of the editor’s knowledge, data is reliable and complete, but no warranty is made for this.</em></p>
<h3>About EMF</h3>
<p>EMF is the premier market intelligence and advisory firm in the embedded technology industry. Embedded technology refers to the ubiquitous class of products which use some type of processor as a controller. These products include guided missiles, radars, and avionics as well as robots, automobiles, telecom gear, and medical electronics.</p>
<p>EMF has been conducting research into the embedded market for more than a decade. EMF survey work is recognized as the most comprehensive and statistically accurate set of measures in the embedded market space by LSA, IBM, Microsoft and a number of other firms. Using research discipline from medical inquiry, EMF has developed a series of survey questions for developers which provide insight into the following areas:</p>
<ul>
<li>Trends in Integrated Development Environments (IDEs) and Real Time Operating Systems (RTOS)</li>
<li>Trends in host processors (both standard microprocessors and Digital Signal Processors (DSPs)</li>
<li>Trends in Interfaces and Trends in Bus and Board Standards </li>
<li>Trends in Systems Engineering and Systems Architecture</li>
<li>Trends in Software Languages</li>
<li>Trends in simulation</li>
<li>Trends in testing</li>
<li>Trends in product life cycle management</li>
<li>Trends in product development performance, practices and management</li>
</ul>
<p>Embedded Market Forecasters (EMF) is the market research division of American Technology International, Inc. EMF clients range from startups to Global 100 companies worldwide. Founded by Dr. Jerry Krasner, a recognized authority on electronics markets, product development and channel distribution; EMF is headquartered in Ashland, Massachusetts.</p>
<p><a href="http://www.embeddedforecast.com/">www.embeddedforecast.com</a><br />
508-881-1850</p>
<h3>About the author</h3>
<p>Jerry Krasner, Ph.D., MBA is Vice President of Embedded Market Forecasters and its parent company, American Technology International. A recognized authority with over 30 years of embedded industry experience, Dr. Krasner was formerly Chairman of Biomedical Engineering at Boston University, and Chairman of Electrical and Computer Engineering at Wentworth Institute of Technology and Bunker Hill Community College. In addition to his academic appointments, Dr. Krasner served as President of Biocybernetics, Inc. and CLINCO, Inc., Executive Vice President of Plasmedics, Inc. and Clinical Development Corporation, and Director of Medical Sciences for the Carnegie-Mellon Institute of Research. Earlier, he was Senior Engineer at the MIT Instrumentation Laboratory. Dr. Krasner earned BSEE and MSEE degrees from Washington University, a Ph.D. in Medical Physiology / Biophysics from Boston University and an MBA from Nichols College. He is a visiting professor at the Universidad de Las Palmas (Spain) where he was recognized for his work in neurosciences and computer technology.</p>
<hr />
<h3>Regarding the Data in this Report</h3>
<p>The data that is referred to in this report is statistically accurate and authentic and is based on:</p>
<ul>
<li>A statistically generated comprehensive and detailed survey of embedded developers and managers who reported on their design results (number of developers per project, vertical market of their design, time to market, percent of designs completed behind schedule or cancelled, closeness of final design outcomes to pre-design expectations, testing outcomes, etc.), the tools they used (development, modeling, Java, Eclipse, and other development tools), their choice of OS, IDE, communication middleware, processors used as well as where they go to learn about new products, tools and concepts.</li>
<li>An EMF Dashboard – a unique tool that allows the user to simultaneously compare similar products (vendors can do competitive comparative analysis); that marketing executives can use for sales promo and strategic planning; that allows developers beginning a project to compare the experiences of hundreds of fellow developers that undertook similar projects to gain insights before making a commitment; and that allows CFOs and senior managers to look at what tools and processes resulted in the greatest cost savings.</li>
</ul>
<p>For the interested reader, the following link demonstrates the power of the Dashboard and how we used it in developing the data that is presented herein: <a href="http://www.embeddedforecast.com/EMF_DashboardIntro/EMF_DashboardIntro.html">http://www.embeddedforecast.com/EMF_DashboardIntro/EMF_DashboardIntro.html</a><br />
</p>
<h3>Overview: 2012 Embedded Developer Survey</h3>
<p><strong>Developer Profile</strong><br />
Embedded development engineers were interviewed via a comprehensive survey designed to elicit information regarding current and anticipated tool usage, design starts, completions and cancellations, development (host) and target platforms, microprocessors used, desirable and undesirable product features, vendor evaluation criteria and purchasing decision processes, among other important information. This survey also inquired about the use of wireless protocols by responding developers.</p>
<p>Six hundred and forty two developers responded to the online survey, of which 60 were hardware engineers, 204 were software engineers, 61 were systems developers, 61 were systems architects, 55 were firmware engineers and 138 were engineering managers. In addition 63 developers gave titles other than these listed. This provided an excellent distribution of experiences and viewpoints from which to draw inferences and conclusions. Statistically, the response is at a 95% confidence level, plus or minus 4.1%.</p>
<p>72.0% of respondents came from North America, while 8.3% were from Asia and 19.8% were from Europe.</p>
<p>Responses from these six hundred and forty two embedded developers comprised the comprehensive survey, which explored the attitudes, preferences and values of embedded developers to the current and projected use of embedded technologies usages and best practices. The survey was constructed such that the responses could be evaluated from many perspectives, including total response, specific job title of the respondent, architecture employed in embedded design, processor family, and each of ten embedded vertical market applications (e.g., telecom, industrial controls, etc.).</p>
<h3>The Emergence of Wireless Protocols for Embedded Applications</h3>
<p>Wireless protocols are deployed across a large number of markets</p>
<p>More than a decade ago, the telecommunications marketplace was undergoing a significant restructuring. Landline communications were more prevalent than wireless applications and the Regional Bell Operating Companies (RBOCS) were using their financial clout to drive the Competitive Local Exchange Companies (CLECS) out of business. They did this by dropping the cost charged to customers significantly (the cost of transmitted bit was falling precipitously due to enhanced communications technologies) which the CLECS couldn’t match. For a brief time the RBOCS were able to run at a loss to drive their competition away.</p>
<p>With the CLECS failing, their equipment was quickly bought up by the RBOCS and absorbed into their infrastructure. Of course the market for new telecom equipment took a significant hit.</p>
<p>At that time the wireless spectrum was limited and governed by Time Division Multiplexing (TDM) which increased the number of devices using the spectrum by sampling each device sequentially in thousands of seconds. Yet the spectrum didn’t<br />
allow for the expansion of wireless applications and landline telecom dominated the industry.</p>
<p>Today, wireless devices have overtaken landline usage and many folks have dropped their landline subscriptions and now use only handheld wireless devices as their primary communication modality. Given the extraordinary computational capabilities of “smart phones”, it is no surprise that wireless technologies have created new worlds for today’s casual, business and scientific usages (which are embedded applications).</p>
<p>For the automotive industry the uptake of multiple and complex wireless protocols in still underway. Traditionally AM/FM radio was installed, but then remote access was added; Bluetooth came later, and the future promises increased use of Bluetooth, WiFi and DSRC.</p>
<p>Within the medical industry, barriers to technology uptake have slowed the introduction of wireless protocols. However, this seems to be an industry on the cusp of widespread development utilizing both long range technologies for telehealth applications and low power short range technologies for sensor network, continuous monitoring and home based care scenarios. Among these short range technologies, Bluetooth classic, Bluetooth Low Energy, WiFi, ZigBee, and ANT are just some of the technologies being deployed.</p>
<p>So let’s take a look at what wireless protocols developers are using for the varieties of embedded applications and how they are using them. We also include in this paper what they report as their preferences and what they report as complaints and concerns.</p>
<p>The data presented shows that Bluetooth is the most frequently used wireless protocol followed by WiFi (802.11) and Zigbee. As a guide to developers and to embedded RTOS and modeling vendors, we present competitive offerings from Bluetooth providers to indicate which provide more than one wireless solution.</p>
<h3>Embedded Developers Report on their use of Wireless Protocols for Embedded Applications</h3>
<p>Embedded developers were asked to report on which protocols they used for wireless embedded applications. The top 20 responses are presented in Table 1.</p>
<table>
<caption>Table 1: Top 20 Wireless Protocols used in Embedded Applications</caption>
<tr>
<td>Bluetooth </td>
<td>24.2% </td>
</tr>
<tr>
<td>802.11g </td>
<td>21.8% </td>
</tr>
<tr>
<td>802.11b </td>
<td>16.6% </td>
</tr>
<tr>
<td>802.11n </td>
<td>16.6% </td>
</tr>
<tr>
<td>Zigbee </td>
<td>14.1% </td>
</tr>
<tr>
<td>3G</td>
<td>12.3% </td>
</tr>
<tr>
<td>GSM</td>
<td>11.0%</td>
</tr>
<tr>
<td>HTTP</td>
<td>8.9%</td>
</tr>
<tr>
<td>RFID</td>
<td>8.9%</td>
</tr>
<tr>
<td>802.11a</td>
<td>8.6%</td>
</tr>
<tr>
<td>Proprietary</td>
<td>8.0% </td>
</tr>
<tr>
<td>WPA2 </td>
<td>8.0% </td>
</tr>
<tr>
<td>4G </td>
<td>7.1% </td>
</tr>
<tr>
<td>WEP </td>
<td>5.8% </td>
</tr>
<tr>
<td>XML </td>
<td>5.8% </td>
</tr>
<tr>
<td>WPA </td>
<td>4.9% </td>
</tr>
<tr>
<td>CDMA </td>
<td>4.6% </td>
</tr>
<tr>
<td>WCDMA&nbsp;(UMTS) </td>
<td>4.3% </td>
</tr>
<tr>
<td>802.11i </td>
<td>3.4% </td>
</tr>
<tr>
<td>IrDA </td>
<td>3.4% </td>
</tr>
<tr>
<td>LTE </td>
<td>3.1%</td>
</tr>
</table>
<p>From the 2012 EMF Survey of Embedded Developers, the reported wireless preferences by vertical market are presented in Table 2. Year-over-year developers continue to report that they use Bluetooth more than other protocols. One might argue that there are more 802.11 users in total than Bluetooth – which is true – but we are reporting on the most used of available wireless protocols.</p>
<table>
<caption>Table 2: Wireless Protocol Preferences by Vertical Markets</caption>
<thead>
<tr>
<th>&nbsp;</th>
<th>TOTAL</th>
<th>Auto</th>
<th>Medical</th>
<th>Mobile Telecom</th>
<th>Consumer Handheld</th>
</tr>
</thead>
<tbody>
<tr>
<td>Bluetooth</td>
<td>24.2%</td>
<td>32.4%</td>
<td>22.4%</td>
<td>40.6%</td>
<td>46.9%</td>
</tr>
<tr>
<td>802.11g</td>
<td>21.8%</td>
<td>35.1%</td>
<td>26.5%</td>
<td>28.1%</td>
<td>30.6%</td>
</tr>
<tr>
<td>802.11b</td>
<td>16.6%</td>
<td>24.3%</td>
<td>14.3%</td>
<td>40.6%</td>
<td>28.6%</td>
</tr>
<tr>
<td>802.11n</td>
<td>16.6%</td>
<td>16.2%</td>
<td>16.3%</td>
<td>28.1%</td>
<td>26.5%</td>
</tr>
<tr>
<td>Zigbee</td>
<td>14.1%</td>
<td>10.8%</td>
<td>14.3%</td>
<td>15.6%</td>
<td>26.5%</td>
</tr>
<tr>
<td>3G</td>
<td>12.3%</td>
<td>18.9%</td>
<td>12.2%</td>
<td>15.6%</td>
<td>20.4%</td>
</tr>
<tr>
<td>GSM</td>
<td>11.0%</td>
<td>13.5%</td>
<td>6.1%</td>
<td>28.1%</td>
<td>22.4%</td>
</tr>
<tr>
<td>HTTP</td>
<td>8.9%</td>
<td>13.5%</td>
<td>8.2%</td>
<td>28.1%</td>
<td>18.4%</td>
</tr>
<tr>
<td>RFID</td>
<td>8.9%</td>
<td>13.5%</td>
<td>10.2%</td>
<td>9.4%</td>
<td>12.2%</td>
</tr>
<tr>
<td>802.11a</td>
<td>8.6%</td>
<td>16.2%</td>
<td>8.2%</td>
<td>15.6%</td>
<td>16.3%</td>
</tr>
<tr>
<td>Proprietary</td>
<td>8.0%</td>
<td>10.8%</td>
<td>4.1%</td>
<td>15.6%</td>
<td>12.2%</td>
</tr>
<tr>
<td>WPA2</td>
<td>8.0%</td>
<td>5.4%</td>
<td>6.1%</td>
<td>15.6%</td>
<td>14.3%</td>
</tr>
<tr>
<td>4G</td>
<td>7.1%</td>
<td>10.8%</td>
<td>4.1%</td>
<td>18.8%</td>
<td>12.2%</td>
</tr>
<tr>
<td>WEP</td>
<td>5.8%</td>
<td>5.4%</td>
<td>2.0%</td>
<td>12.5%</td>
<td>10.2%</td>
</tr>
<tr>
<td>XML</td>
<td>5.8%</td>
<td>5.4%</td>
<td>2.0%</td>
<td>21.9%</td>
<td>10.2%</td>
</tr>
<tr>
<td>WPA</td>
<td>4.9%</td>
<td>5.4%</td>
<td>2.0%</td>
<td>6.3%</td>
<td>8.2%</td>
</tr>
<tr>
<td>CDMA</td>
<td>4.6%</td>
<td>0.0%</td>
<td>0.0%</td>
<td>12.5%</td>
<td>8.2%</td>
</tr>
<tr>
<td>WCDMA (UMTS)</td>
<td>4.3%</td>
<td>0.0%</td>
<td>6.1%</td>
<td>15.6%</td>
<td>8.2%</td>
</tr>
<tr>
<td>802.11i</td>
<td>3.4%</td>
<td>5.4%</td>
<td>4.1%</td>
<td>9.4%</td>
<td>6.1%</td>
</tr>
<tr>
<td>IrDA</td>
<td>3.4%</td>
<td>8.1%</td>
<td>2.0%</td>
<td>3.1%</td>
<td>6.1%</td>
</tr>
</tbody>
</table>
<p>In Table 2 we see that Bluetooth ranks first or second across the reported verticals.</p>
<p>Developers were asked to report on the issues that most impact their embedded designs. For purposes of clarity, WiFi respondents were compiled together irrespective of which 802.11 protocols were used. Developers were asked to choose no more than four responses from a list of concerns (in addition to “other”). In this way, the ranking of the most urgent concerns is presented in Table 3.</p>
<table>
<caption>Table 3: Issues that Most Impact Embedded Designs by Protocol</caption>
<thead>
<tr>
<th>&nbsp;</th>
<th>TOTAL</th>
<th>Bluetooth</th>
<th>802.11x</th>
<th>Zigbee</th>
<th>3G</th>
</tr>
</thead>
<tbody>
<tr>
<td>Incomplete or vague requirements</td>
<td>63.0%</td>
<td>67.1%</td>
<td>65.0%</td>
<td>76.1%</td>
<td>71.8%</td>
</tr>
<tr>
<td>Insufficient time</td>
<td>45.8%</td>
<td>50.6%</td>
<td>51.5%</td>
<td>43.5%</td>
<td>48.7%</td>
</tr>
<tr>
<td>Insufficient resources</td>
<td>41.8%</td>
<td>34.2%</td>
<td>40.8%</td>
<td>28.3%</td>
<td>48.7%</td>
</tr>
<tr>
<td>Design complexity</td>
<td>41.5%</td>
<td>40.5%</td>
<td>38.8%</td>
<td>45.7%</td>
<td>46.2%</td>
</tr>
<tr>
<td>Creating documentation for the design </td>
<td>23.0%</td>
<td>24.1%</td>
<td>26.2%</td>
<td>28.3%</td>
<td>10.3%</td>
</tr>
<tr>
<td>Insufficient expertise</td>
<td>20.1%</td>
<td>21.5%</td>
<td>19.4%</td>
<td>26.1%</td>
<td>25.6%</td>
</tr>
<tr>
<td>Discovering&nbsp;defects&nbsp;late&nbsp;in&nbsp;development&nbsp;cycle</td>
<td>19.8%</td>
<td>17.7%</td>
<td>14.6%</td>
<td>23.9%</td>
<td>10.3%</td>
</tr>
<tr>
<td>Training new team members</td>
<td>16.9%</td>
<td>20.3%</td>
<td>22.3%</td>
<td>15.2%</td>
<td>25.6%</td>
</tr>
<tr>
<td>Lack of understanding of software for reuse </td>
<td>13.0%</td>
<td>10.1%</td>
<td>15.5%</td>
<td>10.9%</td>
<td>7.7%</td>
</tr>
<tr>
<td>Developers leaving company or project </td>
<td>10.3%</td>
<td>8.9%</td>
<td>14.6%</td>
<td>10.9%</td>
<td>10.3%</td>
</tr>
<tr>
<td>Poorly integrated development tool chain </td>
<td>9.5%</td>
<td>21.5%</td>
<td>10.7%</td>
<td>19.6%</td>
<td>12.8%</td>
</tr>
<tr>
<td>Standards Compliance</td>
<td>9.0%</td>
<td>10.1%</td>
<td>8.7%</td>
<td>4.3%</td>
<td>5.1%</td>
</tr>
<tr>
<td>Lack of enabling tools </td>
<td>8.7%</td>
<td>5.1%</td>
<td>7.8%</td>
<td>13.0%</td>
<td>7.7%</td>
</tr>
<tr>
<td>Other</td>
<td>2.4%</td>
<td>2.5%</td>
<td>2.9%</td>
<td>0.0%</td>
<td>0.0%</td>
</tr>
</tbody>
</table>
<p>We asked developers that in reviewing the purchases they made in the last year which vendor characteristics they found to be the most “disappointing”? These results are presented in Table 4.</p>
<table>
<caption>Table 4: Most disappointing vendor characteristics post-purchase</caption>
<thead>
<tr>
<th>&nbsp;</th>
<th>TOTAL</th>
<th>Bluetooth</th>
<th>802.11x</th>
<th>Zigbee</th>
<th>3G</th>
</tr>
</thead>
<tbody>
<tr>
<td>Lack&nbsp;of&nbsp;quality&nbsp;of&nbsp;products,&nbsp;bugs,&nbsp;difficult&nbsp;to&nbsp;use</td>
<td>50.3%</td>
<td>63.0%</td>
<td>48.9%</td>
<td>58.5%</td>
<td>70.3%</td>
</tr>
<tr>
<td>Product not performing as advertised</td>
<td>44.0%</td>
<td>47.9%</td>
<td>48.9%</td>
<td>61.0%</td>
<td>67.6%</td>
</tr>
<tr>
<td>Non responsive technical support</td>
<td>43.4%</td>
<td>56.2%</td>
<td>53.2%</td>
<td>53.7%</td>
<td>43.2%</td>
</tr>
<tr>
<td>Lack of application support</td>
<td>32.5%</td>
<td>41.1%</td>
<td>41.5%</td>
<td>39.0%</td>
<td>37.8%</td>
</tr>
<tr>
<td>Lack of attention to service problems </td>
<td>27.4%</td>
<td>27.4%</td>
<td>34.0%</td>
<td>36.6%</td>
<td>35.1%</td>
</tr>
<tr>
<td>Delivery time delays</td>
<td>20.5%</td>
<td>21.9%</td>
<td>26.6%</td>
<td>31.7%</td>
<td>24.3%</td>
</tr>
<tr>
<td>Vendor not performing as advertised </td>
<td>18.4%</td>
<td>20.5%</td>
<td>23.4%</td>
<td>19.5%</td>
<td>21.6%</td>
</tr>
<tr>
<td>Other</td>
<td>5.1%</td>
<td>4.1%</td>
<td>5.3%</td>
<td>7.3%</td>
<td>2.7%</td>
</tr>
</tbody>
</table>
<p>The analysis is straight forward and the comparison to the broader industry (TOTAL) is interesting and informative as to determining the issues that most confront developers who include wireless technologies into their designs</p>
<p>Developers were asked, “In general, which characteristics are the most important to you in buying embedded products and tools?” They were asked to select no more that four responses out of a large list. Results are presented in Table 5.</p>
<table>
<caption>Table 5: Characteristics most importance to making purchasing decision</caption>
<thead>
<tr>
<th>&nbsp;</th>
<th>TOTAL</th>
<th>Bluetooth</th>
<th>802.11x</th>
<th>Zigbee</th>
<th>3G</th>
</tr>
</thead>
<tbody>
<tr>
<td>Price/cost/value of product</td>
<td>67.0%</td>
<td>66.7%</td>
<td>66.7%</td>
<td>84.4%</td>
<td>57.5%</td>
</tr>
<tr>
<td>Ease of use of product</td>
<td>59.2%</td>
<td>65.4%</td>
<td>58.8%</td>
<td>66.7%</td>
<td>62.5%</td>
</tr>
<tr>
<td>Quality and reliability of products </td>
<td>54.5%</td>
<td>52.6%</td>
<td>52.0%</td>
<td>40.0%</td>
<td>52.5%</td>
</tr>
<tr>
<td>Compatibility of products</td>
<td>45.0%</td>
<td>44.9%</td>
<td>43.1%</td>
<td>48.9%</td>
<td>55.0%</td>
</tr>
<tr>
<td>Technical support</td>
<td>34.9%</td>
<td>41.0%</td>
<td>39.2%</td>
<td>40.0%</td>
<td>37.5%</td>
</tr>
<tr>
<td>Speed/performance of products</td>
<td>28.2%</td>
<td>28.2%</td>
<td>29.4%</td>
<td>26.7%</td>
<td>17.5%</td>
</tr>
<tr>
<td>Reputation of supplier/vendor</td>
<td>17.6%</td>
<td>16.7%</td>
<td>18.6%</td>
<td>26.7%</td>
<td>17.5%</td>
</tr>
<tr>
<td>Leading edge technology</td>
<td>14.8%</td>
<td>15.4%</td>
<td>19.6%</td>
<td>11.1%</td>
<td>17.5%</td>
</tr>
<tr>
<td>Trusted&nbsp;relationship&nbsp;to&nbsp;rep&nbsp;or&nbsp;support&nbsp;people </td>
<td>8.1%</td>
<td>11.5%</td>
<td>8.8%</td>
<td>13.3%</td>
<td>10.0%</td>
</tr>
<tr>
<td>Ease of dealing with vendors&#8217; processes </td>
<td>7.5%</td>
<td>6.4%</td>
<td>8.8%</td>
<td>2.2%</td>
<td>0.0%</td>
</tr>
<tr>
<td>Sales service and support</td>
<td>7.3%</td>
<td>5.1%</td>
<td>4.9%</td>
<td>11.1%</td>
<td>5.0%</td>
</tr>
<tr>
<td>Other</td>
<td>2.0%</td>
<td>2.6%</td>
<td>2.9%</td>
<td>2.2%</td>
<td>0.0%</td>
</tr>
</tbody>
</table>
<p>Price and ease of use appear to be of distinct importance followed by “quality” of product. This follows the broader industry responses.</p>
<p>Developers were asked whether brand awareness (prior knowledge of the reputation and quality of the brand or company) was important in their selection of an embedded product or tool. Results are presented in Table 6.</p>
<table>
<caption>Table 6: Importance of Brand Awareness in making purchasing decision</caption>
<thead>
<tr>
<th colspan="6">How important is the brand awareness (prior knowledge of the reputation and quality of the brand or company) in your selection of an embedded product or tool?</th>
</tr>
<tr>
<th></th>
<th>TOTAL</th>
<th>Bluetooth</th>
<th>802.11x</th>
<th>Zigbee</th>
<th>3G</th>
</tr>
</thead>
<tbody>
<tr>
<td>Critical</td>
<td>4.4%</td>
<td>1.3%</td>
<td>4.9%</td>
<td>0.0%</td>
<td>7.5%</td>
</tr>
<tr>
<td>Very important </td>
<td>27.4%</td>
<td>29.1%</td>
<td>34.0%</td>
<td>33.3%</td>
<td>27.5%</td>
</tr>
<tr>
<td>Somewhat&nbsp;important </td>
<td>43.8%</td>
<td>45.6%</td>
<td>45.6%</td>
<td>51.1%</td>
<td>45.0%</td>
</tr>
<tr>
<td>Not very important </td>
<td>16.7%</td>
<td>19.0%</td>
<td>10.7%</td>
<td>13.3%</td>
<td>15.0%</td>
</tr>
<tr>
<td>Not at all important</td>
<td>7.7%</td>
<td>5.1%</td>
<td>4.9%</td>
<td>2.2%</td>
<td>5.0%</td>
</tr>
</tbody>
</table>
<p>Table 6 shows that brand awareness (including vendor reputation and product quality) is not a critical issue. This is a major surprise to us – but the data is accurate and readers should consider the result.</p>
<h3>Looking at Bluetooth and WiFi (802.11x)</h3>
<p>It is clear from Table 1 that the most used wireless protocol families are Bluetooth and one of the several 802.11 protocols.</p>
<p>Using the unique EMF Executive Dashboard, we are able to filter the database for Bluetooth users and for 802.11 users and to simultaneously compare their users for number of developers per project, time to market (multiplying these computes the total number of developer months per project), percent cancelled, the number of months consumed before cancellation, the percent of designs completed behind schedule and the number of months the project is delayed (from these we can calculate the number of man months lost to cancellation and to behind schedule completions).</p>
<p>Table 7 presents the comparative total cost of development (TCD) between industry developers, developers that incorporate Bluetooth into their designs and those that use WiFi.</p>
<p>This is an important calculation and consideration for managers and CFOs who might choose between which protocols are being considered and their comparative projected development costs.</p>
<table>
<caption>Table 7: Comparative Total Cost of Development</caption>
<thead>
<tr>
<th>&nbsp;</th>
<th>Industry</th>
<th>Bluetooth</th>
<th>802.11x</th>
</tr>
</thead>
<tbody>
<tr>
<td>Devel time Months</td>
<td>13.9</td>
<td>12.6</td>
<td>12.6</td>
</tr>
<tr>
<td>% behind schedule </td>
<td>40.8%</td>
<td>37.0%</td>
<td>39.5%</td>
</tr>
<tr>
<td>Months behind</td>
<td>3.5</td>
<td>3.8</td>
<td>3.8</td>
</tr>
<tr>
<td>% cancelled</td>
<td>9.9%</td>
<td>11.6%</td>
<td>13.2%</td>
</tr>
<tr>
<td>Months lost to cancellation </td>
<td>4</td>
<td>4.1</td>
<td>4.7</td>
</tr>
<tr>
<td>SW Developers/proj</td>
<td>11.1</td>
<td>6.8</td>
<td>9.4</td>
</tr>
<tr>
<td>HW Developers/proj</td>
<td>9.6</td>
<td>3.1</td>
<td>4.5</td>
</tr>
<tr>
<td>Total project developers</td>
<td>20.7</td>
<td>9.9</td>
<td>13.9</td>
</tr>
<tr>
<td>Average Developer months/project </td>
<td>287.7</td>
<td>124.7</td>
<td>175.1</td>
</tr>
<tr>
<td>Developer months lost to schedule </td>
<td>29.6</td>
<td>13.9</td>
<td>20.9</td>
</tr>
<tr>
<td>Developer&nbsp;months&nbsp;lost&nbsp;to&nbsp;cancellation </td>
<td>8.2</td>
<td>4.7</td>
<td>8.6</td>
</tr>
<tr>
<td>Total developer months/project</td>
<td>325.5</td>
<td>143.4</td>
<td>204.6</td>
</tr>
<tr>
<td>&nbsp;</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td><strong>At $10,000/developer month</strong> </td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Average developer cost/project </td>
<td>$2,877,300</td>
<td>$1,247,400</td>
<td>$1,751,400</td>
</tr>
<tr>
<td>Average cost to delay</td>
<td>$377,568</td>
<td>$186,278</td>
<td>$294,875</td>
</tr>
<tr>
<td><strong>Total developer cost/project</strong></td>
<td><strong>$3,254,868</strong></td>
<td><strong>$1,433,678</strong></td>
<td><strong>$2,046,275</strong></td>
</tr>
<tr>
<td></td>
<td></td>
<td><strong>Advantage</strong></td>
<td><strong>42.70%</strong></td>
</tr>
</tbody>
</table>
<p>In looking at the data contained in Table 7 it is interesting to note that not only has Bluetooth been the most used of he wireless protocols for embedded applications, but it is substantially more cost effective.</p>
<p>Finally, it is interesting to report on where the Bluetooth stacks are purchased by wireless embedded developers. We address this in Table 8.</p>
<table>
<caption>Table 8: Source of Bluetooth Stack</caption>
<tr>
<th colspan="2">From what source did you obtain the Bluetooth protocol stack?</th>
</tr>
<tr>
<th>Provided&nbsp;with&nbsp;chip&nbsp;(from&nbsp;CSR/Broadcom,&nbsp;TI,&nbsp;other)</th>
<th>33.8%</th>
</tr>
<tr>
<td>Provided by Bluetooth module vendor (BlueGiga, muRata)</td>
<td>29.2%</td>
</tr>
<tr>
<td>Bundled with RTOS vendor</td>
<td>21.5%</td>
</tr>
<tr>
<td>Jungo</td>
<td>4.6% </td>
</tr>
<tr>
<td>StonestreetOne </td>
<td>4.6% </td>
</tr>
<tr>
<td>Clarinox Technologies </td>
<td>1.5%</td>
</tr>
<tr>
<td>Stollmann E+V GmbH </td>
<td>1.5%</td>
</tr>
</table>
<p>Given the large number of Bluetooth designs, it is interesting to see that over 21% of Bluetooth stacks are obtained from RTOS vendors. This makes a lot of sense when you think about it.</p>
<p>RTOS vendors want solutions that can rapidly be implemented. If a customer wants a Bluetooth stack, it’s better to already have one that is integrated into and supported by the OS. In such, RTOS vendors can leverage existing solutions for their users while Bluetooth suppliers get a lower cost access to larger markets. This is a win-win go-to- market strategy.</p>
<p>That being said, it is interesting to note that EMF will follow Bluetooth suppliers over the next few years to see if vendor integrated multiple offerings will change the wireless market dynamics. Clarinox has a Bluetooth stack that permits multiple Bluetooth connections, a WiFi stack as well as a Zigbee stack. EMF wonders if RTOS and chip vendor would enjoy a one-stop relationship with a single vendor, given that from Table 1 that Bluetooth, WiFi and Zigbee are the leading protocol choices by wireless embedded developers.</p>
<h3>Purchasing Guide for Embedded Developers</h3>
<p>Table 9 presents a comparison between the offerings (multiple) of Bluetooth vendors. It is presented to illustrate to RTOS and modeling vendors, as well as OEM developers how they can leverage their development efforts by using a single vendor that offers multiple support packages.</p>
<table>
<caption>Table 9: Comparative Offerings</caption>
<thead>
<tr>
<th>Solution&nbsp;Provided&nbsp;by Embedded&nbsp;Product/Service&nbsp;Providers</th>
<th>Bluetooth AND WiFi Stacks (together)</th>
<th>Multiple RTOS support</th>
<th>Linux/window support</th>
<th>OS Debug Tools</th>
<th>Wireless Protocol Analyzer</th>
</tr>
</thead>
<tbody>
<tr>
<td>Clarinox</td>
<td>YES</td>
<td>YES</td>
<td>YES</td>
<td>YES</td>
<td>YES</td>
</tr>
<tr>
<td>Jungo</td>
<td>YES</td>
<td>YES</td>
<td>YES</td>
<td>NO</td>
<td>NO</td>
</tr>
<tr>
<td>Stone Street One </td>
<td>NO</td>
<td>YES</td>
<td>YES</td>
<td>NO</td>
<td>NO</td>
</tr>
<tr>
<td>Stollmann</td>
<td>NO</td>
<td>uncertain</td>
<td>YES</td>
<td>NO</td>
<td>NO</td>
</tr>
<tr>
<td>Bundled with RTOS vendor </td>
<td>NO</td>
<td>NO</td>
<td>NO</td>
<td>YES</td>
<td>NO</td>
</tr>
<tr>
<td>Provided with Chip Vendor </td>
<td>NO</td>
<td>NO</td>
<td>YES</td>
<td>NO</td>
<td>NO</td>
</tr>
<tr>
<td>Provided with Bluetooth Vendor </td>
<td>Partial</td>
<td>NO</td>
<td>Partial</td>
<td>NO</td>
<td>NO</td>
</tr>
<tr>
<td>Provided with WiFi Vendor</td>
<td>Partial</td>
<td>YES</td>
<td>NO</td>
<td>Uncertain</td>
<td>Uncertain</td>
</tr>
</tbody>
</table>
]]></content:encoded>
			<wfw:commentRss>http://micrium.com/developers-report-on-their-use-of-wireless-protocols-for-embedded-applications/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>DO 178B: Looking at Developer Preferences, Issues and Vendor Cost of Development</title>
		<link>http://micrium.com/do-178b-looking-at-developer-preferences-issues-and-vendor-cost-of-development/</link>
		<comments>http://micrium.com/do-178b-looking-at-developer-preferences-issues-and-vendor-cost-of-development/#comments</comments>
		<pubDate>Tue, 22 Jan 2013 19:15:25 +0000</pubDate>
		<dc:creator>Jim Royal</dc:creator>
				<category><![CDATA[Article]]></category>

		<guid isPermaLink="false">http://micrium.com/?p=2805</guid>
		<description><![CDATA[Jerry Krasner, Ph.D., MBA Dolores A. Krasner January 2012 Copyright 2012 by American Technology International, Inc, 638 Main St., Ashland, MA 01721. All rights reserved. No part of this book covered by copyright hereon may be reproduced or copied in &#8230; <a href="http://micrium.com/do-178b-looking-at-developer-preferences-issues-and-vendor-cost-of-development/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p><strong>Jerry Krasner, Ph.D., MBA</strong><br />
<strong>Dolores A. Krasner</strong><br />
January 2012</p>
<p><em>Copyright 2012 by American Technology International, Inc, 638 Main St., Ashland, MA 01721. All rights reserved. No part of this book covered by copyright hereon may be reproduced or copied in any manner whatsoever. Every effort has been made to provide accurate data. To the best of the editor’s knowledge, data is reliable and complete, but no warranty is made for this.</em></p>
<h3>About EMF</h3>
<p>EMF is the premier market intelligence and advisory firm in the embedded technology industry. Embedded technology refers to the ubiquitous class of products which use some type of processor as a controller. These products include guided missiles, radars, and avionics as well as robots, automobiles, telecom gear, and medical electronics. </p>
<p>Embedded Market Forecasters (EMF) is the market research division of American Technology International, Inc. EMF clients range from startups to Global 100 companies worldwide. Founded by Dr. Jerry Krasner, a recognized authority on electronics markets, product development and channel distribution, EMF is headquartered in Framingham, Mass. </p>
<p><a href="http://www.embeddedforecast.com/">www.embeddedforecast.com</a></p>
<h3>About the Authors</h3>
<p>Jerry Krasner, Ph.D., MBA is Vice President of Embedded Market Forecasters and its parent company, American Technology International. A recognized authority with over 30 years of embedded industry experience, Dr. Krasner was formerly Chairman of Biomedical Engineering at Boston University, and Chairman of Electrical and Computer Engineering at Wentworth Institute of Technology and Bunker Hill Community College.  In addition to his academic appointments, Dr. Krasner served as President of Biocybernetics, Inc. and CLINCO, Inc., Executive Vice President of Plasmedics, Inc. and Clinical Development Corporation, and Director of Medical Sciences for the Carnegie-Mellon Institute of Research. Earlier, he was Senior Engineer at the MIT Instrumentation Laboratory. Dr. Krasner earned BSEE and MSEE degrees from Washington University, a Ph.D. in Medical Physiology / Biophysics from Boston University and an MBA from Nichols College.</p>
<p>Dolores A. Krasner received BS and MEd degrees from Fitchburg State College and Framingham State College with specializations in special education, literacy and educational research. While a full time teacher, she continued her studies with 60 credits beyond her MEd degree in educational research and best practices. Ms. Krasner retired from her full-time educational roles in 2007. Ms. Krasner is currently Senior Editor and Researcher for Embedded Market Forecasters.</p>
<hr />
<h3>Executive Summary</h3>
<p>Embedded Market Forecasters (EMF) used its 2011 survey of embedded developers (642 respondents) to look at the habits and concerns of DO178B developers and how their activities and designs compared with the broad embedded industry. Using its unique to the industry Embedded Dashboard, comparisons and correlations were undertaken.</p>
<p>Among the reported findings in this paper are:</p>
<ul>
<li>The total developer cost per project was about 10% higher for DO 178B projects</li>
<li>When looking at comparative project and management practices, there was a huge difference in requirements tracking tool use (82.5% for DO 178B developers versus 54.4%)</li>
<li>DO 178B developers had a voice in selection of development processes (42.1% versus 28.2%) and the use of cost &#038; time linked management systems to development processes (49.1% versus 38.8%). Developer participation is clearly more a part of the DO 178B management process than that found in industry projects </li>
<li>Modeling-simulation and CMMI use are much more prevalent for DO 178B projects whereas Agile methodologies and Common Criteria requirements are less considered a Best Practice by DO 178B developers</li>
<li>Incomplete/vague requirements and insufficient resources are of greater concern to DO 178B developers whereas insufficient time and design complexity are of less concern to them</li>
<li>When asked about the most important criteria for their OS selection, “safety certifiable” and realtime performance were overwhelming selections for DO 178B developers. Microprocessor support, compatibility with Linux nd availability of source code were of far less concern</li>
<li>EMF made Total Project Cost calculations for three of the most recognized OSes (VxWorks Secure, Integrity Secure and LynxOS Secure). Micrium uC/OS-II was selected as a representative of lesser known OSes for purposes of comparison. Micrium has been available for more than a decade and is deployed in 10’s of millions of applications. These cost calculations were also compared to the DO 178B user community at large as well as to the industry average for all RTOSes. Interestingly, Micrium has the least cost per project – in all but one case it had a 50% cost advantage</li>
</ul>
<h3>Background</h3>
<p>The RTOS marketplace is highly competitive, if not zero sum close to it, and is filled with claims, counter claims and FUD. Vendors will have you believe that a certified OS is superior to one that has not undergone a certification process. Linux, for example, is not certifiable under DO 178B. However billions of devices run with commercial Linux OSes. Certainly, mission critical applications are expected to run at a higher level of certainty – we can’t have airplanes falling out of the sky. The idea that DO 178B certification is necessary for medical patient monitoring is ridiculous (the highest frequency response is 100 Hz) and the use of FUD to scare medical developers into using such has backfired.</p>
<p>The decision to absorb the expense of DO 178B certification is most often a strategic marketing decision. If one doesn’t sell to the military or avionics marketplace there is no need to incur such expense. </p>
<p>We have read and listened to the many advocates and users of DO 178B based developments. What we haven’t found is data that reflects the concerns, design choices, and experiences of DO178B developers. </p>
<p>EMF conducts annual detailed and comprehensive surveys of embedded developers in a manner so as to maintain statistical accuracy. Between March 2009 and April 2011, EMF gathered data from 1975 developers to look at design outcomes (time-to-market, design completions ahead of or behind schedule, closeness of final design results to pre-design expectations, etc.) and to look at the relative levels of lines-of-code for different application verticals. For the purpose of this report we rely on the results of the 2011 EMF Embedded Developer Survey (642 respondents)</p>
<p>This data has also been used to look at project costs and design outcomes measured by comparing final design results to pre-design expectations for the software, tools, merchant boards and processors used by embedded DO 178B Level A developers.</p>
<p>For many military and aerospace/avionics applications, application software requires adherence to such standards as DO 178B/Level A, ARINC 653, Common Criteria and MILS, among others. Developers are exposed to a myriad of claims and counter claims. </p>
<p>In this report, EMF data is used to determine project costs and design outcomes for several RTOSes certified to DO 178B Level A. This should certainly be of interest to OEMs and systems integrators who make OS and processor choices for their specific applications. We also report which issues these developers identify as having  the greatest impact on their design efforts.</p>
<p>Recently, smaller companies have had their OSes certified under DO 178 B Level A – and it raises the question whether they offer, in addition to their intrinsic capabilities, a comparable return on investment (ROI). In this report we compare project costs for well known certified RTOSes (Integrity, VxWorks and LynxOS) as well as with Micrium uC/OS II, a lesser known but certified DO 178B RTOS. </p>
<h3>Methodology</h3>
<p>The data that is referred to in this report is statistically accurate and authentic and is based on:</p>
<ul>
<li>A statistically generated comprehensive and detailed survey of embedded developers and managers who reported on their design results (number of developers per project, vertical market of their design, time to market, percent of designs completed behind schedule or cancelled, closeness of final design outcomes to pre-design expectations, testing outcomes, etc.), the tools they used (development, modeling, Java, Eclipse, and other development tools), their choice of OS, IDE, communication middleware, processors used as well as where they go to learn about new products, tools and concepts.</li>
<li>An EMF Dashboard – a unique tool that allows the user to simultaneously compare similar products (vendors can do competitive comparative analysis); that marketing executives can use for sales promo and strategic planning; that allows developers beginning a project to compare the experiences of hundreds of fellow developers that undertook similar projects to gain insights before making a commitment; and that allows CFOs and senior managers to look at what tools and processes resulted in the greatest cost savings. The interested reader can view a Dashboard demo at http://www.embeddedforecast.com/EMF_DashboardIntro/EMF_DashboardIntro.html</li>
<li>Six hundred and forty two developers responded to the online survey, of which 60 were hardware engineers, 204 were software engineers, 61 were systems developers, 61 were systems architects, 55 were firmware engineers and 138 were engineering managers. In addition 63 developers gave titles other than these listed. This provided an excellent distribution of experiences and viewpoints from which to draw inferences and conclusions. Statistically, the response is at a 95% confidence level, plus or minus 4.1%.</li>
<li>72.0% of respondents came from North America, while 8.3% were from Asia and 19.8% were from Europe.</li>
</ul>
<h3>Comparing DO 178B Development Activities with Worldwide Embedded Development Activities</h3>
<p><strong>Average Cost of Development</strong></p>
<p>Table I presents the comparative costs of development between DO 178B  and embedded developments.</p>
<p>The EMF Dashboard was filtered to create two cross tabs that were simultaneously compared, side-by-side. The Dashboard was interrogated to determine (from questions within the survey) the comparative costs using:</p>
<p>a)	Number of software developers per project<br />
b)	Number of months from design start to product shipment<br />
c)	Percent of designs completed behind schedule<br />
d)	Number of months behind schedule<br />
e)	Percent of designs cancelled<br />
f)	Number of months between project start and cancellation</p>
<p>Multiplying a) and b) provides the total average number of man-months expended in a project. Multiplying a), c) and d) provide the average number of man-months lost to schedule. Multiplying a), e), and f) provide the number of man months lost to cancellation. Adding these calculations provides the total number of project man-months.</p>
<table>
<caption>Table I: Comparative Costs for Certified (DO 178B) and non-certified RTOSes</caption>
<thead>
<tr>
<th></th>
<th>Ind ave</th>
<th>DO 178B</th>
</tr>
<tr>
<th></th>
<th>All RTOSes</th>
<th>Users</th>
</tr>
</thead>
<tbody>
<tr>
<td>Devel time Months</td>
<td>13.9</td>
<td>17.9</td>
</tr>
<tr>
<td>%&nbsp;behind&nbsp;schedule</td>
<td>47.0%</td>
<td>50.0%</td>
</tr>
<tr>
<td>Months behind</td>
<td>3.8</td>
<td>5.7</td>
</tr>
<tr>
<td>% Cancelled</td>
<td>11.0%</td>
<td>8.9%</td>
</tr>
<tr>
<td>Months before cancellation</td>
<td>4.7</td>
<td>6.3</td>
</tr>
<tr>
<td>SW&nbsp;Developers/project</td>
<td>14.7</td>
<td>12.0</td>
</tr>
<tr>
<td>Average&nbsp;Developer months/project</td>
<td>204.3</td>
<td>214.8</td>
</tr>
<tr>
<td>Developer months lost to schedule</td>
<td>26.3</td>
<td>34.2</td>
</tr>
<tr>
<td>Developer months lost to Cancellation</td>
<td>7.6</td>
<td>6.7</td>
</tr>
<tr>
<td>Total developer months/project</td>
<td>238.2</td>
<td>255.7</td>
</tr>
<tr>
<td>&nbsp;</td>
<td></td>
<td></td>
</tr>
<tr>
<td>At&nbsp;$10K/developer&nbsp;month</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Average developer cost/project</td>
<td>$2,043,300</td>
<td>$2,148,000</td>
</tr>
<tr>
<td>Average cost to delay</td>
<td>$338,541</td>
<td>$409,284</td>
</tr>
<tr>
<td>&nbsp;</td>
<td></td>
<td></td>
</tr>
<tr>
<td><strong>Total developer cost/project</strong></td>
<td><strong>$2,381,841</strong></td>
<td><strong>$2,557,284</strong></td>
</tr>
</tbody>
</table>
<p>Interestingly, DO 178B developments had fewer cancellations (this might be explained for mil/aero developments), and longer project times. Surprisingly DO 178B developments used fewer developers per project.</p>
<p>Table II presents project management practices that are most used by DO 178B developers and how these practices are reflected in industry responses (percent of respondents choosing the practice).</p>
<table>
<caption>Table II: Comparative Project &#038; Management Practices</caption>
<tr>
<th>&nbsp;</th>
<th>Do 178B</th>
<th>Industry</th>
</tr>
<tr>
<td>Requirements tracking tools</td>
<td>82.5%</td>
<td>54.4%</td>
</tr>
<tr>
<td>Budgets based on both management and engineering input</td>
<td>56.1%</td>
<td>50.9%</td>
</tr>
<tr>
<td>Cost&nbsp;&amp;&nbsp;Time&nbsp;linked&nbsp;management&nbsp;systems&nbsp;to&nbsp;development&nbsp;progress</td>
<td>49.1%</td>
<td>38.8%</td>
</tr>
<tr>
<td>Developers have a voice in selection of development processes</td>
<td>42.1%</td>
<td>28.2%</td>
</tr>
<tr>
<td>Management practices assigned to the right technical talent</td>
<td>38.6%</td>
<td>34.2%</td>
</tr>
</table>
<p>Table III presents Best Practices as perceived by developers. It is interesting to observe that only 60.3% of DO 178B developers consider it a Best Practice (compared with 12.0% of the industry). Peer reviews and Modeling-Simulation based development were the 2nd/3rd considered Best Practice.</p>
<table>
<caption>Table III: Processes Considered being a Best Practice</caption>
<thead>
<tr>
<th></th>
<th>Do 178B</th>
<th>Industry</th>
</tr>
</thead>
<tbody>
<tr>
<td>DO 178B</td>
<td>60.3%</td>
<td>12.9%</td>
</tr>
<tr>
<td>Modeling-Simulation</td>
<td>34.5%</td>
<td>22.7%</td>
</tr>
<tr>
<td>Peer reviews</td>
<td>34.5%</td>
<td>35.9%</td>
</tr>
<tr>
<td>Process Management (CMMI)</td>
<td>22.4%</td>
<td>10.1%</td>
</tr>
<tr>
<td>Agile Methodologies</td>
<td>19.0%</td>
<td>26.3%</td>
</tr>
<tr>
<td>Common Criteria</td>
<td>1.7%</td>
<td>5.2%</td>
</tr>
</tbody>
</table>
<p>Given the strict oversight of software development it is surprising to see that Common Criteria is dismissed by DO 178B developers as a Best Practice. It makes sense that modeling-simulation would be a benefit to these developers – particularly with the need for code reuse. We’d like to believe that CMMI is a hold over as a bad habit from prior years – it means that you have to employ a consistent process; not necessarily a good process.</p>
<p>Developers were asked to identify the most significant issues impacting their software development. They were given a list of 15 possible responses (they could do a write in as well) and they were limited to a maximum of four choices. In this manner we were able to develop a hierarchy of issues illustrated by the percentage of respondents that chose that option. The comparative responses are presented in Table IV.</p>
<table>
<caption>Table IV: Most Significant Issues Confronting Embedded Developers</caption>
<thead>
<tr>
<th></th>
<th>Do 178B</th>
<th>Industry</th>
</tr>
</thead>
<tbody>
<tr>
<td>Incomplete/vague&nbsp;requirements</td>
<td>62.1%</td>
<td>53.4%</td>
</tr>
<tr>
<td>Insufficient resources</td>
<td>46.6%</td>
<td>40.9%</td>
</tr>
<tr>
<td>Insufficient time</td>
<td>34.5%</td>
<td>44.7%</td>
</tr>
<tr>
<td>Design complexity</td>
<td>31.0%</td>
<td>38.5%</td>
</tr>
<tr>
<td>Standards compliance</td>
<td>24.1%</td>
<td>13.5%</td>
</tr>
<tr>
<td>Lack of enabling tools</td>
<td>3.4%</td>
<td>11.5%</td>
</tr>
</tbody>
</table>
<p>Clearly DO 178B developers are not concerned about enabling tools or time constraints. Design complexity is not as great a concern for DO 178B developers and this is consistent with their use of modeling-simulation tools (Table III).</p>
<p>Concluding our look at comparative developer characteristics and preferences, Table V presents the reported criteria that is most important to developers in selecting an operating system.</p>
<table>
<caption>Table V: Criteria Most Important in Selecting their Next OS</caption>
<thead>
<tr>
<th>&nbsp;</th>
<th>Do 178B</th>
<th>Industry</th>
</tr>
</thead>
<tbody>
<tr>
<td>Safety certifiable</td>
<td>67.9%</td>
<td>15.0%</td>
</tr>
<tr>
<td>Realtime performance</td>
<td>51.8%</td>
<td>37.3%</td>
</tr>
<tr>
<td>Acquisition cost</td>
<td>35.7%</td>
<td>37.3%</td>
</tr>
<tr>
<td>Prior experience with OS</td>
<td>21.4%</td>
<td>14.8%</td>
</tr>
<tr>
<td>Microprocessor support</td>
<td>23.2%</td>
<td>30.5%</td>
</tr>
<tr>
<td>Compatible with Linux</td>
<td>7.1%</td>
<td>20.8%</td>
</tr>
<tr>
<td>Availability of source code</td>
<td>16.1%</td>
<td>27.8%</td>
</tr>
</tbody>
</table>
<p>Interestingly, cost is not a differentiating factor whereas microprocessor support is less of an issue with DO 178B developers. Not surprisingly, Linux support is a non-issue with DO 178B developers.</p>
<h3>Comparing Associated Costs for Comparable DO 178B Operating Systems </h3>
<p>For more than a decade, the mission critical and standards-based market has been dominated by Wind River (VxWorks), Green Hills Software (Integrity), and LynuxWorks (LynxOS). Recently there has been competition from such vendors as Micrium, Express Logic and commercial Linux vendors.</p>
<p>The question that hasn’t been answered is costs associated with projects using alternative OSes for DO 178B required developments compare with VxWorks, Integrity or LynuxWorks OS. We chose to include Micrium as an example of an alternative choice. All four OSes presented are certified to DO 178B Level A</p>
<p>The results are presented in Table VI and the calculations were made the same as for Table I. This Table was derived from data that was based on the following number of lines of code:</p>
<ul>
<li>Green Hills: 1054 thousand lines of code</li>
<li>LynxOS – 840 thousand lines of code</li>
<li>Micrium – 829 thousand lines of code</li>
<li>VxWorks – 577 thousand lines of code</li>
<li>Industry average – 787 thousand lines of code</li>
</ul>
<table>
<caption>Table VI: Comparative Project Costs for DO 178B Operating Systems</caption>
<thead>
<tr>
<th>&nbsp;</th>
<th>Ind ave</th>
<th>DO 178B</th>
<th>Integrity</th>
<th>VxWorks</th>
<th>LynxOS</th>
<th>Micrium</th>
</tr>
<tr>
<th>&nbsp;</th>
<th>All&nbsp;RTOSes</th>
<th>Users</th>
<th>Secure</th>
<th>Secure</th>
<th>Secure</th>
<th>uC/OS-II</th>
</tr>
</thead>
<tbody>
<tr>
<td>Devel time Months</td>
<td>13.9</td>
<td>17.9</td>
<td>12.4</td>
<td>12.2</td>
<td>16.9</td>
<td>11.3</td>
</tr>
<tr>
<td>% behind schedule</td>
<td>47.0%</td>
<td>50.0%</td>
<td>35.7%</td>
<td>45.9%</td>
<td>31.0%</td>
<td>41.2%</td>
</tr>
<tr>
<td>Months behind</td>
<td>3.8</td>
<td>5.7</td>
<td>6.1</td>
<td>5.2</td>
<td>5.0</td>
<td>3.5</td>
</tr>
<tr>
<td>% Cancelled</td>
<td>11.0%</td>
<td>8.9%</td>
<td>12.8%</td>
<td>11.4%</td>
<td>12.0%</td>
<td>10.6%</td>
</tr>
<tr>
<td>Months before cancellation</td>
<td>4.7</td>
<td>6.3</td>
<td>7.1</td>
<td>4.6</td>
<td>4.5</td>
<td>3.4</td>
</tr>
<tr>
<td>SW Developers/project</td>
<td>14.7</td>
<td>12.0</td>
<td>14.8</td>
<td>12.2</td>
<td>12.4</td>
<td>8.5</td>
</tr>
<tr>
<td>Average Developer months/project</td>
<td>204.3</td>
<td>214.8</td>
<td>183.5</td>
<td>148.8</td>
<td>209.6</td>
<td>96.1</td>
</tr>
<tr>
<td>Developer months lost to schedule</td>
<td>26.3</td>
<td>34.2</td>
<td>32.2</td>
<td>29.1</td>
<td>19.2</td>
<td>12.3</td>
</tr>
<tr>
<td>Developer months lost to Cancellation</td>
<td>7.6</td>
<td>6.7</td>
<td>13.5</td>
<td>6.4</td>
<td>6.7</td>
<td>3.1</td>
</tr>
<tr>
<td>Total developer months/ project</td>
<td>238.2</td>
<td>255.7</td>
<td>229.2</td>
<td>184.4</td>
<td>235.5</td>
<td>111.4</td>
</tr>
<tr>
<td>&nbsp;</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>At&nbsp;$10K/developer&nbsp;month</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Average developer cost/project</td>
<td>$2,043,300</td>
<td>$2,148,000</td>
<td>$1,835,200</td>
<td>$1,488,400</td>
<td>$2,095,600</td>
<td>$960,500</td>
</tr>
<tr>
<td>Average cost to delay</td>
<td>$338,541</td>
<td>$409,284</td>
<td>$456,802</td>
<td>$355,166</td>
<td>$259,160</td>
<td>$153,204</td>
</tr>
<tr>
<td>&nbsp;</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td><strong>Total&nbsp;developer&nbsp;cost/project</strong></td>
<td><strong>$2,381,841</strong></td>
<td><strong>$2,557,284</strong></td>
<td><strong>$2,292,002</strong></td>
<td><strong>$1,843,566</strong></td>
<td><strong>$2,354,760</strong></td>
<td><strong>$1,113,704</strong></td>
</tr>
</tbody>
</table>
<p>Note that all of the certified RTOSes presented in Figure VI outperformed the industry average.</p>
<h3>Summary</h3>
<p>It is interesting to note that a lesser known OS compared very favorably compared to the more established DO 178B OSes. </p>
<p>It is clear from the presented analysis that embedded developers looking for a certified RTOS take into account the design particulars of their applications and the compute power required. EMF hopes that this analysis will help developers to look at certified software from a different perspective.</p>
<p>First, choose the RTOS that best meets your application. Such considerations as the following should be first considered:</p>
<ul>
<li>Power requirements</li>
<li>Worst case interrupt latency</li>
<li>Worst case context-switch times</li>
<li>Time-to-market considerations</li>
<li>Ease-of-use</li>
<li>Footprint</li>
<li>Budget</li>
</ul>
<p>The latency and context-switch times are usually processor specific and can be gotten from the chip vendors. For a better discussion of this topic see Michael Barr’s view at:</p>
<p><a href="http://www.netrino.com/Embedded-Systems/How-To/RTOS-Selection">http://www.netrino.com/Embedded-Systems/How-To/RTOS-Selection</a></p>
<p>It is not immediately clear as to why the project cost of the lesser known OSes is significantly less that those of the “big three”. It might have to do with them having been selected specifically for the application at hand, ease of learning a new OS, or other considerations.</p>
<p>What is clear is that DO178B developers have a broader range of choices and that switching OSes might be less troublesome than previously thought.</p>
]]></content:encoded>
			<wfw:commentRss>http://micrium.com/do-178b-looking-at-developer-preferences-issues-and-vendor-cost-of-development/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Estimating the Value of Ceritifed RTOSes in Embedded Development</title>
		<link>http://micrium.com/estimating-the-value-of-ceritifed-rtoses-in-embedded-development/</link>
		<comments>http://micrium.com/estimating-the-value-of-ceritifed-rtoses-in-embedded-development/#comments</comments>
		<pubDate>Tue, 22 Jan 2013 18:37:45 +0000</pubDate>
		<dc:creator>Jim Royal</dc:creator>
				<category><![CDATA[Article]]></category>

		<guid isPermaLink="false">http://micrium.com/?p=2798</guid>
		<description><![CDATA[Jerry Krasner, Ph.D., MBA American Technology International, Inc. www.embeddedforecast.com About EMF EMF is the premier market intelligence and advisory firm in the embedded technology industry. Embedded technology refers to the ubiquitous class of products which use some type of processor &#8230; <a href="http://micrium.com/estimating-the-value-of-ceritifed-rtoses-in-embedded-development/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p><strong>Jerry Krasner, Ph.D., MBA</strong><br />
American Technology International, Inc.<br />
<a href="http://www.embeddedforecast.com/">www.embeddedforecast.com</a></p>
<h3>About EMF</h3>
<p>EMF is the premier market intelligence and advisory firm in the embedded technology industry. Embedded technology refers to the ubiquitous class of products which use some type of processor as a controller. These products include guided missiles, radars, and avionics as well as robots, automobiles, telecom gear, and medical electronics. </p>
<p>Embedded Market Forecasters (EMF) is the market research division of American Technology International, Inc. EMF clients range from startups to Global 100 companies worldwide. Founded by Dr. Jerry Krasner, a recognized authority on electronics markets, product development and channel distribution, EMF is headquartered in Framingham, Mass. </p>
<h3>About the Author</h3>
<p>Jerry Krasner, Ph.D., MBA is Vice President of Embedded Market Forecasters and its parent company, American Technology International. A recognized authority with over 30 years of embedded industry experience, Dr. Krasner was formerly Chairman of Biomedical Engineering at Boston University, and Chairman of Electrical and Computer Engineering at Wentworth Institute of Technology and Bunker Hill Community College.  In addition to his academic appointments, Dr. Krasner served as President of Biocybernetics, Inc. and CLINCO, Inc., Executive Vice President of Plasmedics, Inc. and Clinical Development Corporation, and Director of Medical Sciences for the Carnegie-Mellon Institute of Research. Earlier, he was Senior Engineer at the MIT Instrumentation Laboratory. Dr. Krasner earned BSEE and MSEE degrees from Washington University, a Ph.D. in Medical Physiology / Biophysics from Boston University and an MBA from Nichols College.</p>
<p><em>Copyright 2010 by American Technology International, Inc, 638 Main St, Ashland, MA 01721 All rights reserved. No part of this book covered by copyright hereon may be reproduced or copied in any manner whatsoever. Every effort has been made to provide accurate data. To the best of the editor’s knowledge, data is reliable and complete, but no warranty is made for this.</em> </p>
<hr />
<h3>Background</h3>
<p>EMF conducts annual detailed and comprehensive surveys of embedded developers in a manner so as to maintain statistical accuracy. Between March 2009 and April 2010, EMF gathered data from 1325 developers to look at design outcomes (time-to-market, design completions ahead of or behind schedule, closeness of final design results to pre-design expectations, etc.) and to look at the relative levels of lines-of-code for different application verticals. </p>
<p>This data has also been used to look at project costs and design outcomes measured by comparing final design results to pre-design expectations for the software, tools, merchant boards and processors used by embedded developers.</p>
<p>For many military and aerospace/avionics applications, application software requires adherence to such standards as DO 178B/Level A, ARINC 653, Common Criteria and MILS, among others. Developers are exposed to a myriad of claims and counter claims. Green Hills Software, for example, touts their EAL 6+ certification as an example of their product superiority – but a reading of their certification shows a very limited coverage. </p>
<p>In this report, EMF data is used to determine project costs and design outcomes for several RTOSes certified to DO 178B Level A. This should certainly be of interest to OEMs and systems integrators who make OS and processor choices for their specific applications.</p>
<p>Recently, smaller companies have had their OSes certified under DO 178 B Level A – and it raises the question whether they offer, in addition to their intrinsic capabilities, a comparable return on investment (ROI). In this report we compare project costs and design outcomes for well known certified RTOSes (Integrity, VxWorks and LynxOS) as well as with Micrium uC/OS II, a lesser known RTOS. </p>
<p>EMF’s comprehensive embedded developer surveys and our unique Dashboard tool enable detailed comparisons to be made between competing DO 178B OSes.</p>
<h3>Calculating the ROI</h3>
<p>The following parameters are used to calculate the ROI:</p>
<p>a)	Number of software developers per project<br />
b)	Number of months from design start to product shipment<br />
c)	Percent of designs completed behind schedule<br />
d)	Number of months behind schedule</p>
<p>Multiplying a) and b) provides the total average number of man-months expended in a project. Multiplying a), c) and d) provide the average number of man-months lost to schedule. Adding these calculations provides the total number of project man-months.</p>
<p>Table I presents a side-by-side comparison between the secure OSes from Wind River, Green Hills, LynuxWorks and Micrium. The Industrial Average is for all OSes.</p>
<table>
<caption>Table I: Comparative ROIs for Certified RTOSes</caption>
<thead>
<tr>
<th></th>
<th>Ind ave</th>
<th>Micrium</th>
<th>Integrity</th>
<th>VxWorks</th>
<th>LynxOS</th>
</tr>
</thead>
<tbody>
<tr>
<td>Devel time Months</td>
<td>13.9</td>
<td>12.5</td>
<td>17.9</td>
<td>16.3</td>
<td>13.7</td>
</tr>
<tr>
<td>% behind schedule</td>
<td>47.0%</td>
<td>43.1%</td>
<td>43.0%</td>
<td>51.1%</td>
<td>36.4%</td>
</tr>
<tr>
<td>Months behind</td>
<td>3.8</td>
<td>2.8</td>
<td>3.6</td>
<td>3.3</td>
<td>2.5</td>
</tr>
<tr>
<td>Ave Delay Months</td>
<td>1.79</td>
<td>1.21</td>
<td>1.55</td>
<td>1.69</td>
<td>0.91</td>
</tr>
<tr>
<td>&nbsp;</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Delay/proj time</td>
<td>12.8%</td>
<td>9.7%</td>
<td>8.6%</td>
<td>10.3%</td>
<td>6.6%</td>
</tr>
<tr>
<td>&nbsp;</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>SW Developers/project</td>
<td>14.7</td>
<td>6.1</td>
<td>15.2</td>
<td>14.2</td>
<td>12.3</td>
</tr>
<tr>
<td>Average&nbsp;Developer&nbsp;months/project</td>
<td>204.3</td>
<td>76.3</td>
<td>272.1</td>
<td>231.5</td>
<td>168.5</td>
</tr>
<tr>
<td>Developer months lost to schedule</td>
<td>26.3</td>
<td>7.4</td>
<td>23.5</td>
<td>23.9</td>
<td>11.2</td>
</tr>
<tr>
<td>&nbsp;</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Total developer months/project</td>
<td>230.6</td>
<td>83.6</td>
<td>295.6</td>
<td>255.4</td>
<td>179.7</td>
</tr>
<tr>
<td>&nbsp;</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>At&nbsp;$10K/developer&nbsp;month</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Average developer cost/project</td>
<td>$2,043,300</td>
<td>$762,500</td>
<td>$2,720,800</td>
<td>$2,314,600</td>
<td>$1,685,100</td>
</tr>
<tr>
<td>Average cost to delay</td>
<td>$262,542</td>
<td>$73,615</td>
<td>$235,296</td>
<td>$239,455</td>
<td>$111,930</td>
</tr>
<tr>
<td>&nbsp;</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td><strong>Total developer cost/project</strong></td>
<td>$2,305,842</td>
<td>$836,115</td>
<td>$2,956,096</td>
<td>$2,554,055</td>
<td>$1,797,030</td>
</tr>
</tbody>
</table>
<p>This Table was derived from data that was based on the following number of lines of code:</p>
<ul>
<li>Green Hills: 1054 thousand lines of code</li>
<li>LynxOS – 840 thousand lines of code</li>
<li>Micrium – 829 thousand lines of code</li>
<li>VxWorks – 577 thousand lines of code</li>
<li>Industry average – 787 thousand lines of code</li>
</ul>
<p>Design outcomes are another contributor to the total cost of ownership. The EMF survey asks developers to report on how close to their pre-design expectation their final design outcome was for Performance, Systems Functionality and Features &#038; Schedule. EMF believes that acceptable design outcomes are those that are within 30% of pre-design expectation.</p>
<p>Table II presents the survey results for these certified RTOSes:</p>
<table>
<caption>Table II: Comparative Design Outcomes within 30% of Pre-Design Expectation</caption>
<thead>
<tr>
<th></th>
<th>Ind Ave</th>
<th>Micrium</th>
<th>Integrity</th>
<th>VxWorks</th>
<th>LynxOS</th>
</tr>
</thead>
<tbody>
<tr>
<td>Performance</td>
<td>73.8%</td>
<td>88.8%</td>
<td>72.3%</td>
<td>80.4%</td>
<td>77.8%</td>
</tr>
<tr>
<td>Systems Functionality</td>
<td>76.0%</td>
<td>84.6%</td>
<td>83.4%</td>
<td>80.4%</td>
<td>81.5%</td>
</tr>
<tr>
<td>Features &#038; Schedule</td>
<td>79.3%</td>
<td>78.8%</td>
<td>70.2%</td>
<td>73.2%</td>
<td>81.4%</td>
</tr>
</tbody>
</table>
<p>Note that all of the certified RTOSes outperformed the industry average.</p>
<h3>Summary</h3>
<p>It is interesting to note that a lesser known OS compared very favorably compared to the more established DO 178B OSes. In a previous report such non-certified (but frequently used) OSes as ThreadX and Nucleus also produced more favorable results than the better known OSes.</p>
<p>It is clear from the presented analysis that embedded developers looking for a certified RTOS take into account the design particulars of their applications and the compute power required. EMF hopes that this analysis will help developers to look at certified software from a different perspective.</p>
]]></content:encoded>
			<wfw:commentRss>http://micrium.com/estimating-the-value-of-ceritifed-rtoses-in-embedded-development/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ARM Techcon — Santa Clara, California</title>
		<link>http://micrium.com/arm-techcon-santa-clara-california-october-29-november-1-2013/</link>
		<comments>http://micrium.com/arm-techcon-santa-clara-california-october-29-november-1-2013/#comments</comments>
		<pubDate>Fri, 04 Jan 2013 13:28:28 +0000</pubDate>
		<dc:creator>Jim Royal</dc:creator>
				<category><![CDATA[Event]]></category>

		<guid isPermaLink="false">http://micrium.com/?p=2254</guid>
		<description><![CDATA[The ARM Technology Conference is the premier event to connect, instruct, advise and enable the world of electronic and computer design. This year, the technical conference will be divided into two distinct elements: Chip Design and Software &#38; Systems Design. &#8230; <a href="http://micrium.com/arm-techcon-santa-clara-california-october-29-november-1-2013/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>The ARM Technology Conference is the premier event to connect, instruct, advise and enable the world of electronic and computer design. This year, the technical conference will be divided into two distinct elements: Chip Design and Software &amp; Systems Design.</p>
<p>More information to come.</p>
]]></content:encoded>
			<wfw:commentRss>http://micrium.com/arm-techcon-santa-clara-california-october-29-november-1-2013/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Design East — Boston, Massachusetts</title>
		<link>http://micrium.com/design-east-boston-massachusetts-september-30-october-3-2013/</link>
		<comments>http://micrium.com/design-east-boston-massachusetts-september-30-october-3-2013/#comments</comments>
		<pubDate>Fri, 04 Jan 2013 13:21:32 +0000</pubDate>
		<dc:creator>Jim Royal</dc:creator>
				<category><![CDATA[Event]]></category>

		<guid isPermaLink="false">http://micrium.com/?p=2250</guid>
		<description><![CDATA[The East Coast&#8217;s Most Comprehensive Event for Electronics Engineers and Designers. More information to come. http://east.ubmdesign.com/]]></description>
			<content:encoded><![CDATA[<p>The East Coast&#8217;s Most Comprehensive Event for Electronics Engineers and Designers. More information to come.</p>
<p><a href="http://east.ubmdesign.com/">http://east.ubmdesign.com/</a></p>
]]></content:encoded>
			<wfw:commentRss>http://micrium.com/design-east-boston-massachusetts-september-30-october-3-2013/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
