<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: Guest Article: Static Analysis in Medical Device Software (Part 2) — Methodology</title>
	<atom:link href="http://rdn-consulting.com/blog/2009/06/04/guest-article-static-analysis-in-medical-device-software-part-2-methodology/feed/" rel="self" type="application/rss+xml" />
	<link>http://rdn-consulting.com/blog/2009/06/04/guest-article-static-analysis-in-medical-device-software-part-2-methodology/</link>
	<description>Software Development and Biomedical Engineering</description>
	<lastBuildDate>Tue, 31 Jan 2012 14:44:21 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Guest Article: Static Analysis in Medical Device Software (Part 3) — Formal specifications &#124; Bob on Medical Device Software</title>
		<link>http://rdn-consulting.com/blog/2009/06/04/guest-article-static-analysis-in-medical-device-software-part-2-methodology/comment-page-1/#comment-4475</link>
		<dc:creator>Guest Article: Static Analysis in Medical Device Software (Part 3) — Formal specifications &#124; Bob on Medical Device Software</dc:creator>
		<pubDate>Tue, 14 Dec 2010 03:41:03 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/?p=275#comment-4475</guid>
		<description>[...] Pascal Cuoq at Frama-C continues his discussion of static analysis for medical device software. Also see Part 1 and Part 2. [...]</description>
		<content:encoded><![CDATA[<p>[...] Pascal Cuoq at Frama-C continues his discussion of static analysis for medical device software. Also see Part 1 and Part 2. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Track Jacket ·</title>
		<link>http://rdn-consulting.com/blog/2009/06/04/guest-article-static-analysis-in-medical-device-software-part-2-methodology/comment-page-1/#comment-3940</link>
		<dc:creator>Track Jacket ·</dc:creator>
		<pubDate>Mon, 08 Nov 2010 10:34:33 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/?p=275#comment-3940</guid>
		<description>embedded software is quite in demand these days coz more devices use microcontrollers           _</description>
		<content:encoded><![CDATA[<p>embedded software is quite in demand these days coz more devices use microcontrollers           _</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pascal Cuoq</title>
		<link>http://rdn-consulting.com/blog/2009/06/04/guest-article-static-analysis-in-medical-device-software-part-2-methodology/comment-page-1/#comment-1893</link>
		<dc:creator>Pascal Cuoq</dc:creator>
		<pubDate>Sun, 12 Jul 2009 11:51:41 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/?p=275#comment-1893</guid>
		<description>I was not aware that this was on the internet before, and I only knew of the hardware design methodology conclusions, but Richard P. Feynman&#039;s report on the NASA Space Shuttle has a section on software methodology. If you were interested enough to read this far, it is worth taking a look:

http://tr.im/RPFeynman

When trying to explain, in the above article, that during verification, statistically all alarms turn out to be false alarms, I wish I had quoted these sentences from the report:
&quot;A discovery of an error during verification testing is considered very serious, and its origin studied very carefully to avoid such mistakes in the future. Such unexpected errors have been found only about six times in all the programming and program changing (for new or altered payloads) that has been done.&quot;

Feynman does not start a discussion of false positives in his report because the Shuttle software was verified exclusively by testing, and testing (considering one execution path at a time) does not have false positives by construction, so to say.</description>
		<content:encoded><![CDATA[<p>I was not aware that this was on the internet before, and I only knew of the hardware design methodology conclusions, but Richard P. Feynman&#8217;s report on the NASA Space Shuttle has a section on software methodology. If you were interested enough to read this far, it is worth taking a look:</p>
<p><a href="http://tr.im/RPFeynman" rel="nofollow">http://tr.im/RPFeynman</a></p>
<p>When trying to explain, in the above article, that during verification, statistically all alarms turn out to be false alarms, I wish I had quoted these sentences from the report:<br />
&#8220;A discovery of an error during verification testing is considered very serious, and its origin studied very carefully to avoid such mistakes in the future. Such unexpected errors have been found only about six times in all the programming and program changing (for new or altered payloads) that has been done.&#8221;</p>
<p>Feynman does not start a discussion of false positives in his report because the Shuttle software was verified exclusively by testing, and testing (considering one execution path at a time) does not have false positives by construction, so to say.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://rdn-consulting.com/blog/2009/06/04/guest-article-static-analysis-in-medical-device-software-part-2-methodology/comment-page-1/#comment-1669</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Sat, 06 Jun 2009 03:18:29 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/?p=275#comment-1669</guid>
		<description>Here is a (very) partial list of software failures in commercial aircraft which did *not* lead to human fatalities, courtesy of the FAA&#039;s database of Airworthiness Directives:

http://rgl.faa.gov/Regulatory_and_Guidance_Library/rgAD.nsf/WebSearchDefault?SearchView&amp;Query=software

http://en.wikipedia.org/wiki/Airworthiness_Directive</description>
		<content:encoded><![CDATA[<p>Here is a (very) partial list of software failures in commercial aircraft which did *not* lead to human fatalities, courtesy of the FAA&#8217;s database of Airworthiness Directives:</p>
<p><a href="http://rgl.faa.gov/Regulatory_and_Guidance_Library/rgAD.nsf/WebSearchDefault?SearchView&#038;Query=software" rel="nofollow">http://rgl.faa.gov/Regulatory_and_Guidance_Library/rgAD.nsf/WebSearchDefault?SearchView&#038;Query=software</a></p>
<p><a href="http://en.wikipedia.org/wiki/Airworthiness_Directive" rel="nofollow">http://en.wikipedia.org/wiki/Airworthiness_Directive</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>

