<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Cross, Joseph wrote:
<blockquote
cite="mid7FC402934595684AB4B49D416EF3D578021A212C@sde2k3-mb2.darpa.mil"
type="cite">
<pre wrap="">Patrick -
Okay, very cool. We're down to touching up the face powder on our Miss
America contestant.
</pre>
<blockquote type="cite">
<pre wrap="">We are talking about how to deploy a configuration that have
never been tested in the lab.
</pre>
</blockquote>
<pre wrap=""><!---->
Right. And looked at another way, we're talking about how to certify a
configuration that has never been tested.
</pre>
<blockquote type="cite">
<pre wrap="">I conjecture that there is no way to do that with anything other than
</pre>
</blockquote>
<pre wrap=""><!---->a
</pre>
<blockquote type="cite">
<pre wrap="">statistical assurance. The goal is to first give them a 1000 tested
configurations and use the novel generation method as a back up when
none of them fit.
</pre>
</blockquote>
<pre wrap=""><!---->
If we're being Bayesian, where probability is used to express strength
of belief, then you're saying that we'll never achieve 100% certainty
that our system will work. Sure.
But yea verily we never had 100% certainty and we never will. (Drat!
There goes another one of those pesky alpha particles!)
If we say to the Navy "Our process will deploy configurations for which
we have only statistical assurance of correctness," they'll hear "...
configurations that aren't as reliable as your old-school certified
configurations." And that's not true.
Old-school certification provides only statistical assurance of
correctness. And it would be boorish of us to rub our customers' noses
in that fact.
We're talking public relations here, not technology.
Obviously we must not oversell our product. But I believe that we can
honestly say that we're going to provide mechanisms that will enable the
certification of untested configurations. (Then the means by which we
chose one of these certified configurations at run-time is an
engineering detail.) If somebody asks whether the cert board will have
to loosen its standards to accept our configurations, we say no.
In this way we avoid emphasizing the
statistical/not-mathematically-certain nature of the entire
certification process, with or without CADynCE.
- Joe
_______________________________________________
Cadynce mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cadynce@list.isis.vanderbilt.edu">Cadynce@list.isis.vanderbilt.edu</a>
<a class="moz-txt-link-freetext" href="http://list.isis.vanderbilt.edu/mailman/listinfo/cadynce">http://list.isis.vanderbilt.edu/mailman/listinfo/cadynce</a>
</pre>
</blockquote>
Dear Joe, Patrick and Gautam:<br>
<br>
(I apologize for missing the telecon yesterday; had a visitor.)<br>
<br>
I agree 100% with the above comments. And wanted to add a couple more
thoughts:<br>
<br>
In bin-packing, we pack objects and declare victory if all objects fit
within available bins and no bin constraints (single-dimensional or
multi-dimensional) are violated. In the embedded real-time systems
domain, there are other aspects that are not necessarily captured in
the simple bin-packing model. These include the notion of execution
patterns (periodic, sporadic or aperiodic), local and end-to-end
deadlines, schedulability requirements, OS overheads, interrupt
latencies, interactions among resources (e.g. processing latency when
a network packet arrives at a network interface and then has to go up
the protocol processing stack but the network and CPU resources are
scheduled as two different policies using two different schedulers),
and potential non-negligible sources of non-determinism (caching
interactions among multiple concurrent processes). We can (and
should) take care of requirements such as schedulability in the
bin-packing phase. I also believe that an appropriate run-time
infrastructure is needed to (a) schedule the various processes/threads
to meet their deadlines when run concurrently (b) enforce/isolate the
run-time behaviors of each process/thread, and (c) the
policies/mechanisms of the run-time infrastructure should match the
assumptions of the bin-packing phase. Together, the certification of
the feasible (but potentially untested) configurations becomes
possible. <br>
<br>
Thanks,<br>
<br>
---<br>
Raj<br>
<br>
</body>
</html>