<?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: SLS software over budget and behind schedule	</title>
	<atom:link href="https://behindtheblack.com/behind-the-black/points-of-information/sls-software-over-budget-and-behind-schedule/feed/" rel="self" type="application/rss+xml" />
	<link>https://behindtheblack.com/behind-the-black/points-of-information/sls-software-over-budget-and-behind-schedule/</link>
	<description></description>
	<lastBuildDate>Tue, 29 Mar 2016 10:04:18 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>
	<item>
		<title>
		By: Local Fluff		</title>
		<link>https://behindtheblack.com/behind-the-black/points-of-information/sls-software-over-budget-and-behind-schedule/#comment-870468</link>

		<dc:creator><![CDATA[Local Fluff]]></dc:creator>
		<pubDate>Tue, 29 Mar 2016 10:04:18 +0000</pubDate>
		<guid isPermaLink="false">http://behindtheblack.com/?p=38458#comment-870468</guid>

					<description><![CDATA[A shuttle derived launch vehicle sounds (must&#039;ve sounded) like a great idea. Most technology is already developed and well proven, it should happen sooner, cheaper and safer than starting from scratch. But hey, everything seems to require redevelopment for SLS! From engines to transportation and ground systems and manufacturing equipment and even buildings. And then maybe the legacy from the shuttle becomes a problem rather than a benefit. I suppose the shuttle flight control software has a legacy spanning almost 40 years. I can imagine that replacing it with contemporary software is even harder than starting from scratch. They do use many sub-systems from the shuttle, they cannot truly start from scratch.

When starting from scratch one can design stuff from the beginning for modern software architecture, modern electronics and sensors, modern materials, modern manufacturing methods like 3D-printing. Making everything that follows, during some years, easy. Upgrading the old only works up to a limit. I think that the space shuttle is too old to build directly upon.]]></description>
			<content:encoded><![CDATA[<p>A shuttle derived launch vehicle sounds (must&#8217;ve sounded) like a great idea. Most technology is already developed and well proven, it should happen sooner, cheaper and safer than starting from scratch. But hey, everything seems to require redevelopment for SLS! From engines to transportation and ground systems and manufacturing equipment and even buildings. And then maybe the legacy from the shuttle becomes a problem rather than a benefit. I suppose the shuttle flight control software has a legacy spanning almost 40 years. I can imagine that replacing it with contemporary software is even harder than starting from scratch. They do use many sub-systems from the shuttle, they cannot truly start from scratch.</p>
<p>When starting from scratch one can design stuff from the beginning for modern software architecture, modern electronics and sensors, modern materials, modern manufacturing methods like 3D-printing. Making everything that follows, during some years, easy. Upgrading the old only works up to a limit. I think that the space shuttle is too old to build directly upon.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Dick Eagleson		</title>
		<link>https://behindtheblack.com/behind-the-black/points-of-information/sls-software-over-budget-and-behind-schedule/#comment-870453</link>

		<dc:creator><![CDATA[Dick Eagleson]]></dc:creator>
		<pubDate>Tue, 29 Mar 2016 09:11:33 +0000</pubDate>
		<guid isPermaLink="false">http://behindtheblack.com/?p=38458#comment-870453</guid>

					<description><![CDATA[Speculation on my part, but I suspect that SpaceX, Orbital-ATK, Blue Origin and other launch providers probably use a customized code skeleton for their ground support software that is then fleshed out with &quot;canned&quot; software modules that are available from the manufacturers of the electromechanical components used in constructing the ground support hardware.

Things like electrically operated valves typically incorporate on-board microcontrollers to handle the low-level control functions with some kind of higher-level command language defined that allows the developers of customized systems to use those components by issuing commands like &quot;Linear open to 30% of maximum flow over an interval of 1.5 seconds&quot; or some such.

This would all be somewhat analogous to the G-code language used to program CNC machine tools.  CNC programs tell machines what path the cutter should follow based on straight lines and circular sections, and at what speed, but allows the machine&#039;s control software to translate these &quot;do what&quot; commands into &quot;do how&quot; commands that actually drive the motors.

Automated valve control, to cite just the example used here, is, as a generic function, needed in innumerable places in the chemical, food, beverage, cosmetics, pharmaceutical and many other industries.  The infrastructure of a launch facility is just another industrial plant as far as basic functionalities are concerned.

I suspect SpaceX and most everyone else in the launch business uses existing code libraries whererever possible to both minimize development costs and to benefit from the considerable free debugging already done on canned code as the result of the experiences of prior users.

If NASA is developing their ground support software by also using canned code wherever possible as appendages to a custom-coded backbone system, then their overruns and schedule slippages simply reflect a lamentable lack of competence in the software development process.  The U.S. government, regrettably, has a long and noisome history of bungling big software development projects (healthcare.gov anyone?).  This would just be one more such sad, but typical, story.

If, on the other hand, NASA is really attempting to write &lt;i&gt;all&lt;/i&gt; the code in their ground support system from scratch - even down to the microcontroller level - that&#039;s just nuts.  It could probably be demonstrated in court to be a matter of actual malfeasance even if it isn&#039;t, technically, corrupt.]]></description>
			<content:encoded><![CDATA[<p>Speculation on my part, but I suspect that SpaceX, Orbital-ATK, Blue Origin and other launch providers probably use a customized code skeleton for their ground support software that is then fleshed out with &#8220;canned&#8221; software modules that are available from the manufacturers of the electromechanical components used in constructing the ground support hardware.</p>
<p>Things like electrically operated valves typically incorporate on-board microcontrollers to handle the low-level control functions with some kind of higher-level command language defined that allows the developers of customized systems to use those components by issuing commands like &#8220;Linear open to 30% of maximum flow over an interval of 1.5 seconds&#8221; or some such.</p>
<p>This would all be somewhat analogous to the G-code language used to program CNC machine tools.  CNC programs tell machines what path the cutter should follow based on straight lines and circular sections, and at what speed, but allows the machine&#8217;s control software to translate these &#8220;do what&#8221; commands into &#8220;do how&#8221; commands that actually drive the motors.</p>
<p>Automated valve control, to cite just the example used here, is, as a generic function, needed in innumerable places in the chemical, food, beverage, cosmetics, pharmaceutical and many other industries.  The infrastructure of a launch facility is just another industrial plant as far as basic functionalities are concerned.</p>
<p>I suspect SpaceX and most everyone else in the launch business uses existing code libraries whererever possible to both minimize development costs and to benefit from the considerable free debugging already done on canned code as the result of the experiences of prior users.</p>
<p>If NASA is developing their ground support software by also using canned code wherever possible as appendages to a custom-coded backbone system, then their overruns and schedule slippages simply reflect a lamentable lack of competence in the software development process.  The U.S. government, regrettably, has a long and noisome history of bungling big software development projects (healthcare.gov anyone?).  This would just be one more such sad, but typical, story.</p>
<p>If, on the other hand, NASA is really attempting to write <i>all</i> the code in their ground support system from scratch &#8211; even down to the microcontroller level &#8211; that&#8217;s just nuts.  It could probably be demonstrated in court to be a matter of actual malfeasance even if it isn&#8217;t, technically, corrupt.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: mpthompson		</title>
		<link>https://behindtheblack.com/behind-the-black/points-of-information/sls-software-over-budget-and-behind-schedule/#comment-870307</link>

		<dc:creator><![CDATA[mpthompson]]></dc:creator>
		<pubDate>Tue, 29 Mar 2016 01:56:46 +0000</pubDate>
		<guid isPermaLink="false">http://behindtheblack.com/?p=38458#comment-870307</guid>

					<description><![CDATA[There must be two major software systems -- the software that controls the rocket itself (presumably running on the rocket itself) and the software that monitors the rocket remotely.  Given the size of the market is so small, is off-the-shelf commercial software even available that would fulfill either role?  Or, can software designed for other aerospace uses be readily adapted to providing control and monitoring of a system as the SLS?  Perhaps someone with knowledge of this aspect of space system design can provide some background on what parts readily available and what parts are usually hand rolled for a specific launch system.  The article is very vague about this.]]></description>
			<content:encoded><![CDATA[<p>There must be two major software systems &#8212; the software that controls the rocket itself (presumably running on the rocket itself) and the software that monitors the rocket remotely.  Given the size of the market is so small, is off-the-shelf commercial software even available that would fulfill either role?  Or, can software designed for other aerospace uses be readily adapted to providing control and monitoring of a system as the SLS?  Perhaps someone with knowledge of this aspect of space system design can provide some background on what parts readily available and what parts are usually hand rolled for a specific launch system.  The article is very vague about this.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
