<?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>Embedded Insights Channels &#187; Patch-It Principle</title>
	<atom:link href="http://www.embeddedinsights.com/channels/topics/patch-it-principle/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.embeddedinsights.com/channels</link>
	<description>Shedding Light on the Hidden World of Embedded Systems</description>
	<lastBuildDate>Fri, 14 Jun 2013 17:33:02 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>Robust Design: Patch-It Principle – Teaching and Learning</title>
		<link>http://www.embeddedinsights.com/channels/2010/05/03/robust-design-patch-it-principle-%e2%80%93-teaching-and-learning/</link>
		<comments>http://www.embeddedinsights.com/channels/2010/05/03/robust-design-patch-it-principle-%e2%80%93-teaching-and-learning/#comments</comments>
		<pubDate>Tue, 04 May 2010 02:07:57 +0000</pubDate>
		<dc:creator>Robert Cravotta</dc:creator>
				<category><![CDATA[Robust Design]]></category>
		<category><![CDATA[Patch-It Principle]]></category>

		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/05/03/robust-design-patch-it-principle-%e2%80%93-teaching-and-learning/</guid>
		<description><![CDATA[[Editor's Note: This was originally posted on the Embedded Master]  In the first post introducing the patch-it principle, I made the claim that developers use software patches to add new behaviors to their systems in response to new information and changes in the operating environment. In this way, patching systems allow developers to offload the [...]]]></description>
		<wfw:commentRss>http://www.embeddedinsights.com/channels/2010/05/03/robust-design-patch-it-principle-%e2%80%93-teaching-and-learning/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>How do you support software patches in your embedded designs?</title>
		<link>http://www.embeddedinsights.com/channels/2010/04/28/question-of-the-week-how-do-you-support-software-patches-in-your-embedded-designs/</link>
		<comments>http://www.embeddedinsights.com/channels/2010/04/28/question-of-the-week-how-do-you-support-software-patches-in-your-embedded-designs/#comments</comments>
		<pubDate>Wed, 28 Apr 2010 23:14:50 +0000</pubDate>
		<dc:creator>Robert Cravotta</dc:creator>
				<category><![CDATA[Question of the Week]]></category>
		<category><![CDATA[Patch-It Principle]]></category>

		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/04/28/question-of-the-week-how-do-you-support-software-patches-in-your-embedded-designs/</guid>
		<description><![CDATA[[Editor's Note: This was originally posted on the Embedded Master]  Earlier, I posted about design-for-patching. While some patches involve fixing something that never worked, I believe most patches actually add new information to the system than was there before the patch was applied. This means there has to be some resource headroom to 1) incorporate [...]]]></description>
		<wfw:commentRss>http://www.embeddedinsights.com/channels/2010/04/28/question-of-the-week-how-do-you-support-software-patches-in-your-embedded-designs/feed/</wfw:commentRss>
		<slash:comments>12</slash:comments>
		</item>
		<item>
		<title>Robust Design: Patch-It Principle – Design-for-Patching</title>
		<link>http://www.embeddedinsights.com/channels/2010/04/26/robust-design-patch-it-principle-%e2%80%93-design-for-patching/</link>
		<comments>http://www.embeddedinsights.com/channels/2010/04/26/robust-design-patch-it-principle-%e2%80%93-design-for-patching/#comments</comments>
		<pubDate>Mon, 26 Apr 2010 23:58:06 +0000</pubDate>
		<dc:creator>Robert Cravotta</dc:creator>
				<category><![CDATA[Robust Design]]></category>
		<category><![CDATA[Patch-It Principle]]></category>

		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/04/26/robust-design-patch-it-principle-%e2%80%93-design-for-patching/</guid>
		<description><![CDATA[[Editor's Note: This was originally posted on the Embedded Master]  Patching a tire is necessary when the tire has had a part of itself forcibly torn or removed so that it is damaged and can no longer perform its primary function properly. This is also true when you are patching clothing. Patching software in embedded systems [...]]]></description>
		<wfw:commentRss>http://www.embeddedinsights.com/channels/2010/04/26/robust-design-patch-it-principle-%e2%80%93-design-for-patching/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Robust Design: Patch-It Principle</title>
		<link>http://www.embeddedinsights.com/channels/2010/04/19/robust-design-patch-it-principle/</link>
		<comments>http://www.embeddedinsights.com/channels/2010/04/19/robust-design-patch-it-principle/#comments</comments>
		<pubDate>Mon, 19 Apr 2010 17:00:42 +0000</pubDate>
		<dc:creator>Robert Cravotta</dc:creator>
				<category><![CDATA[Robust Design]]></category>
		<category><![CDATA[Patch-It Principle]]></category>

		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/04/19/robust-design-patch-it-principle/</guid>
		<description><![CDATA[[Editor's Note: This was originally posted on the Embedded Master]  The software patch is a much maligned technique for keeping systems robust because many users perceive that the majority of these patches as merely fixes of feature bugs that the developers should have taken care of before shipping the software. While there are many examples [...]]]></description>
		<wfw:commentRss>http://www.embeddedinsights.com/channels/2010/04/19/robust-design-patch-it-principle/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Robust Design: Ambiguity and Uncertainty</title>
		<link>http://www.embeddedinsights.com/channels/2010/03/22/robust-design-ambiguity-and-uncertainty/</link>
		<comments>http://www.embeddedinsights.com/channels/2010/03/22/robust-design-ambiguity-and-uncertainty/#comments</comments>
		<pubDate>Mon, 22 Mar 2010 17:00:19 +0000</pubDate>
		<dc:creator>Robert Cravotta</dc:creator>
				<category><![CDATA[Robust Design]]></category>
		<category><![CDATA[Disposable Principle]]></category>
		<category><![CDATA[Fault Tolerance Principle]]></category>
		<category><![CDATA[Patch-It Principle]]></category>
		<category><![CDATA[Sandbox Principle]]></category>

		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/03/22/robust-design-ambiguity-and-uncertainty/</guid>
		<description><![CDATA[[Editor's Note: This was originally posted on the Embedded Master]  Undetected ambiguity is the bane of designers. Unfortunately, the opportunities for ambiguity to manifest in our specifications and designs are numerous, and they are easy to miss. Worse, when an ambiguity is discovered because two or more groups on a design team interpreted some information [...]]]></description>
		<wfw:commentRss>http://www.embeddedinsights.com/channels/2010/03/22/robust-design-ambiguity-and-uncertainty/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Robust Design: Best Guesses</title>
		<link>http://www.embeddedinsights.com/channels/2010/03/15/robust-design-best-guesses/</link>
		<comments>http://www.embeddedinsights.com/channels/2010/03/15/robust-design-best-guesses/#comments</comments>
		<pubDate>Mon, 15 Mar 2010 17:00:02 +0000</pubDate>
		<dc:creator>Robert Cravotta</dc:creator>
				<category><![CDATA[Robust Design]]></category>
		<category><![CDATA[Disposable Principle]]></category>
		<category><![CDATA[Fault Tolerance Principle]]></category>
		<category><![CDATA[Patch-It Principle]]></category>
		<category><![CDATA[Sandbox Principle]]></category>

		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/03/15/robust-design-best-guesses/</guid>
		<description><![CDATA[[Editor's Note: This was originally posted on the Embedded Master]  An important realization about building robust systems is that the design decisions and trade-offs we make are based on our best guesses. As designers, we must rely on best guesses because it is impossible to describe a “perfect and complete” specification for all but the [...]]]></description>
		<wfw:commentRss>http://www.embeddedinsights.com/channels/2010/03/15/robust-design-best-guesses/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Robust Design : Good, Fast, Cheap – pick two</title>
		<link>http://www.embeddedinsights.com/channels/2010/02/10/robust-design-good-fast-cheap-%e2%80%93-pick-two/</link>
		<comments>http://www.embeddedinsights.com/channels/2010/02/10/robust-design-good-fast-cheap-%e2%80%93-pick-two/#comments</comments>
		<pubDate>Wed, 10 Feb 2010 17:00:07 +0000</pubDate>
		<dc:creator>Robert Cravotta</dc:creator>
				<category><![CDATA[Robust Design]]></category>
		<category><![CDATA[Disposable Principle]]></category>
		<category><![CDATA[Fault Tolerance Principle]]></category>
		<category><![CDATA[Patch-It Principle]]></category>
		<category><![CDATA[Sandbox Principle]]></category>

		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/02/10/robust-design-good-fast-cheap-%e2%80%93-pick-two/</guid>
		<description><![CDATA[[Editor's Note: This was originally posted on EDN]  Reading Battar’s response to the introduction post for this series has suggested to me that it is worth exploring the relationship of the popular expression “good, fast, and cheap – pick two” in the context of robust design principles. The basis for this expression is that it [...]]]></description>
		<wfw:commentRss>http://www.embeddedinsights.com/channels/2010/02/10/robust-design-good-fast-cheap-%e2%80%93-pick-two/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Robust Design</title>
		<link>http://www.embeddedinsights.com/channels/2010/02/04/robust-design/</link>
		<comments>http://www.embeddedinsights.com/channels/2010/02/04/robust-design/#comments</comments>
		<pubDate>Thu, 04 Feb 2010 17:00:24 +0000</pubDate>
		<dc:creator>Robert Cravotta</dc:creator>
				<category><![CDATA[Robust Design]]></category>
		<category><![CDATA[Disposable Principle]]></category>
		<category><![CDATA[Fault Tolerance Principle]]></category>
		<category><![CDATA[Patch-It Principle]]></category>
		<category><![CDATA[Sandbox Principle]]></category>

		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/02/04/robust-design/</guid>
		<description><![CDATA[I am accelerating my plans to start a series on robust design principles because of the timely interest in the safety recall by Toyota for a sticking accelerator pedal. Many people are weighing in on the issue, but Charles J. Murray’s article “Toyota&#8217;s Problem Was Unforeseeable” and Michael Barr’s posting “Is Toyota&#8217;s Accelerator Problem Caused [...]]]></description>
		<wfw:commentRss>http://www.embeddedinsights.com/channels/2010/02/04/robust-design/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
