* is Ada used in James Webb Space Telescope software?
@ 2021-12-26 13:18 Nasser M. Abbasi
2021-12-26 14:23 ` Dmitry A. Kazakov
2021-12-30 13:30 ` Peter Chapin
0 siblings, 2 replies; 13+ messages in thread
From: Nasser M. Abbasi @ 2021-12-26 13:18 UTC (permalink / raw)
Any one knows if Ada is used in James Webb Space Telescope software.
Either in the control systems or in the embeded software for the Telescope.
https://www.jwst.nasa.gov/
I sure hope they did not use javascript or Python or C for the software.
There is some talk in the following link about its software, but could
not find what language they used.
https://www.nasa.gov/feature/goddard/2020/nasa-s-james-webb-space-telescope-completes-comprehensive-systems-test
--Nasser
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: is Ada used in James Webb Space Telescope software?
2021-12-26 13:18 is Ada used in James Webb Space Telescope software? Nasser M. Abbasi
@ 2021-12-26 14:23 ` Dmitry A. Kazakov
2021-12-26 19:22 ` Paul Rubin
2021-12-30 13:30 ` Peter Chapin
1 sibling, 1 reply; 13+ messages in thread
From: Dmitry A. Kazakov @ 2021-12-26 14:23 UTC (permalink / raw)
On 2021-12-26 14:18, Nasser M. Abbasi wrote:
> Any one knows if Ada is used in James Webb Space Telescope software.
>
> Either in the control systems or in the embeded software for the Telescope.
>
> https://www.jwst.nasa.gov/
>
> I sure hope they did not use javascript or Python or C for the software.
Since it was 30 years in developing, I would not dismiss QBasic...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: is Ada used in James Webb Space Telescope software?
2021-12-26 14:23 ` Dmitry A. Kazakov
@ 2021-12-26 19:22 ` Paul Rubin
2021-12-26 23:57 ` John McCabe
0 siblings, 1 reply; 13+ messages in thread
From: Paul Rubin @ 2021-12-26 19:22 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> Since it was 30 years in developing, I would not dismiss QBasic...
Don't forget Forth! It was used on many space projects.
https://web.archive.org/web/19990125085748/http://forth.gsfc.nasa.gov/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: is Ada used in James Webb Space Telescope software?
2021-12-26 19:22 ` Paul Rubin
@ 2021-12-26 23:57 ` John McCabe
2021-12-27 0:37 ` Paul Rubin
0 siblings, 1 reply; 13+ messages in thread
From: John McCabe @ 2021-12-26 23:57 UTC (permalink / raw)
On Sunday, 26 December 2021 at 19:22:58 UTC, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:
> > Since it was 30 years in developing, I would not dismiss QBasic...
> Don't forget Forth! It was used on many space projects.
>
> https://web.archive.org/web/19990125085748/http://forth.gsfc.nasa.gov/
Interesting. I didn't realise there had been so many projects in Forth. I started to learn /use Forth at one point, as it looked like we (Matra Marconi Space) might be forced to use the RTX2010 as it was one of very few space qualified processors with hardware floating point support. In the end we used the MA31750, with Ada, instead.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: is Ada used in James Webb Space Telescope software?
2021-12-26 23:57 ` John McCabe
@ 2021-12-27 0:37 ` Paul Rubin
2021-12-27 7:44 ` Niklas Holsti
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Paul Rubin @ 2021-12-27 0:37 UTC (permalink / raw)
John McCabe <john@mccabe.org.uk> writes:
> I didn't realise there had been so many projects in Forth.
Much of Forth's early development was at the Kitt Peak observatory where
I think Charles Moore worked for a while, so it was popular with the
astronomy community and maybe indirectly with the spaceflight community
through there and JPL. As a more general matter, hardware designers
(electrical engineers who sometimes have to muck with embedded software
but aren't really into programming as a topic) tend to like it because
of its simplicity and directness.
> as it looked like we (Matra Marconi Space) might be forced to use the
> RTX2010 as it was one of very few space qualified processors with
> hardware floating point support. In the end we used the MA31750, with
> Ada, instead.
Interesting. I hadn't heard of the MA31750 but it appears to be a 16
bit processor that implements the MIL-STD-1750A instruction set(!),
which I didn't know about either. Apparently it was made in the 1980s
but has since been superseded by SPARC architecture cpu's.
I wonder if targeting GCC to the RTX2010 might have been feasible.
Can I ask what Ada compiler you used for the MA31750? It looks like GCC
supported the MA31750 until version 3.1, but I don't know whether GNAT
existed then.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: is Ada used in James Webb Space Telescope software?
2021-12-27 0:37 ` Paul Rubin
@ 2021-12-27 7:44 ` Niklas Holsti
2021-12-28 10:24 ` John McCabe
2022-04-23 9:17 ` is Ada used in James Webb Space Telescope software? 姚飞
2 siblings, 0 replies; 13+ messages in thread
From: Niklas Holsti @ 2021-12-27 7:44 UTC (permalink / raw)
On 2021-12-27 2:37, Paul Rubin wrote:
> John McCabe <john@mccabe.org.uk> writes:
>> I didn't realise there had been so many projects in Forth.
>
> Much of Forth's early development was at the Kitt Peak observatory where
> I think Charles Moore worked for a while, so it was popular with the
> astronomy community and maybe indirectly with the spaceflight community
> through there and JPL. As a more general matter, hardware designers
> (electrical engineers who sometimes have to muck with embedded software
> but aren't really into programming as a topic) tend to like it because
> of its simplicity and directness.
Forth is of course one of the few ways to get a self-hosted but fairly
fast interactive compiler/editor system on small processors.
In the 1980's I was working in radio astronomy and we were planning to
use Forth to replace HP BASIC on an HP2100 16-bit mini for telescope
control and data acquisition. I had a little crush on Forth at the time,
but fell out of love with it when I found that some astronomy SW had
defined the word 2000.0 as a procedure to convert stellar coordinates to
the year 2000 ephemeris... very clear :-(
Fortunately IMO we chose to use HP-Algol instead, and much later changed
to Ada on a MicroVAX.
>> as it looked like we (Matra Marconi Space) might be forced to use the
>> RTX2010 as it was one of very few space qualified processors with
>> hardware floating point support. In the end we used the MA31750, with
>> Ada, instead.
>
> Interesting. I hadn't heard of the MA31750 but it appears to be a 16
> bit processor that implements the MIL-STD-1750A instruction set(!),
> which I didn't know about either. Apparently it was made in the 1980s
> but has since been superseded by SPARC architecture cpu's.
>
> I wonder if targeting GCC to the RTX2010 might have been feasible.
> Can I ask what Ada compiler you used for the MA31750? It looks like GCC
> supported the MA31750 until version 3.1, but I don't know whether GNAT
> existed then.
Like John, I used Ada on an MA31750. We used the TLD Ada compiler, where
(IIRC) TLD stands for the main author, Terry L. Dunbar. GNAT was around,
but I don't remember if it had support for the MA31750 -- I doubt it. We
used gnatp 3.<something> for testing the MA31750 SW on workstations (Sun
Solaris on SPARC, IIRC), but the customer (Matra Marconi Space)
specified TLD Ada for the target, so there was never a question of using
GNAT instead.
That project developed the on-board SW for the ozone-monitoring
instrument GOMOS on the ESA ENVISAT satellite. I believe ENVISAT used
MA31750 and TLD Ada for all its systems.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: is Ada used in James Webb Space Telescope software?
2021-12-27 0:37 ` Paul Rubin
2021-12-27 7:44 ` Niklas Holsti
@ 2021-12-28 10:24 ` John McCabe
2021-12-28 10:59 ` Niklas Holsti
2022-04-23 9:17 ` is Ada used in James Webb Space Telescope software? 姚飞
2 siblings, 1 reply; 13+ messages in thread
From: John McCabe @ 2021-12-28 10:24 UTC (permalink / raw)
On Monday, 27 December 2021 at 00:37:03 UTC, Paul Rubin wrote:
> John McCabe <jo...@mccabe.org.uk> writes:
> > as it looked like we (Matra Marconi Space) might be forced to use the
> > RTX2010 as it was one of very few space qualified processors with
> > hardware floating point support. In the end we used the MA31750, with
> > Ada, instead.
> Interesting. I hadn't heard of the MA31750 but it appears to be a 16
> bit processor that implements the MIL-STD-1750A instruction set(!),
> which I didn't know about either. Apparently it was made in the 1980s
> but has since been superseded by SPARC architecture cpu's.
There were 3 or 4 different implementations of the MIL-STD-1750A instruction set architecture around the time. It was an interesting one; it was fairly small, but had some relatively complex instructions that were really useful. The MA31750 was GEC-Plessey Semiconductors' 2nd version, I believe, although if I remember correctly, this was the one that had the FPU, or maybe it was the MMU, integrated into a single device, using silicon-on-sapphire for rad-hardness. There were two other implementations I particularly remember that were rad-hard, one by IBM, which had better claimed performance but was really expensive and special order only (I think we paid £7500 or so for each MA31750, so you may be able to imagine what I mean by "really expensive"), and one by another US company that went into Chapter 11 protection around the time we were talking to them!
> I wonder if targeting GCC to the RTX2010 might have been feasible.
> Can I ask what Ada compiler you used for the MA31750? It looks like GCC
> supported the MA31750 until version 3.1, but I don't know whether GNAT
> existed then.
I'm almost 100% sure GNAT wasn't available for the MIL-STD-1750A; it was a very niche market and we weren't aware of any C compilers we could've used at the time, even if we'd wanted to.
The Ada compiler we used was the same as Nikolas; TLD. I was also working on part of ENVISAT (the Tile Control and Interface Unit - TCIU, although some of my colleagues were also using it on the main ASAR control system). Although Nikolas mentions Matra Marconi Space mandating TLD, that would've come down from Dornier who'd apparently done a deal with TLD. I don't know what happened with TLD after that, but some geezer from the Irvine Compiler Corporation contacted me once when they were following up on some unpaid license fees related to part of the TLD compiler.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: is Ada used in James Webb Space Telescope software?
2021-12-28 10:24 ` John McCabe
@ 2021-12-28 10:59 ` Niklas Holsti
2021-12-31 10:26 ` John McCabe
0 siblings, 1 reply; 13+ messages in thread
From: Niklas Holsti @ 2021-12-28 10:59 UTC (permalink / raw)
On 2021-12-28 12:24, John McCabe wrote:
> On Monday, 27 December 2021 at 00:37:03 UTC, Paul Rubin wrote:
>> John McCabe <jo...@mccabe.org.uk> writes:
>
>>> as it looked like we (Matra Marconi Space) might be forced to use
>>> the RTX2010 as it was one of very few space qualified processors
>>> with hardware floating point support. In the end we used the
>>> MA31750, with Ada, instead.
[snip]
> The Ada compiler we used was the same as Nikolas; TLD.
[snip]
> Although Nikolas mentions Matra Marconi Space mandating TLD, that
> would've come down from Dornier who'd apparently done a deal with
> TLD.
Yes, a considerable part of our requirements came from Dornier via Matra
Marconi Space (France). We sometimes had fun trying to understand how
the French had interpreted requirements written in English by the
Germans. The two other languages had left their imprints on the
"English" wording :-)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: is Ada used in James Webb Space Telescope software?
2021-12-26 13:18 is Ada used in James Webb Space Telescope software? Nasser M. Abbasi
2021-12-26 14:23 ` Dmitry A. Kazakov
@ 2021-12-30 13:30 ` Peter Chapin
1 sibling, 0 replies; 13+ messages in thread
From: Peter Chapin @ 2021-12-30 13:30 UTC (permalink / raw)
On 12/26/21 8:18 AM, Nasser M. Abbasi wrote:
> Any one knows if Ada is used in James Webb Space Telescope software.
It is likely they used C. Specifically, C99. I say this because in my
dealings with NASA (related to my work with CubeSats), the people I've
talked with made it clear that NASA is now a C shop. Both my colleague
and I have extolled the virtues of Ada and SPARK to NASA engineers, but
we get the usual reaction: to much investment in C to take any other
option seriously... except maybe C++ (JPL, at least, does some work with
C++ so that might also be on the JWST).
Peter
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: is Ada used in James Webb Space Telescope software?
2021-12-28 10:59 ` Niklas Holsti
@ 2021-12-31 10:26 ` John McCabe
2021-12-31 21:18 ` [OT] ESA project memories (was Re: is Ada used in James Webb Space Telescope software?) Niklas Holsti
0 siblings, 1 reply; 13+ messages in thread
From: John McCabe @ 2021-12-31 10:26 UTC (permalink / raw)
On Tuesday, 28 December 2021 at 10:59:36 UTC, Niklas Holsti wrote:
> On 2021-12-28 12:24, John McCabe wrote:
> [snip]
> > Although Nikolas mentions Matra Marconi Space mandating TLD, that
> > would've come down from Dornier who'd apparently done a deal with
> > TLD.
> Yes, a considerable part of our requirements came from Dornier via Matra
> Marconi Space (France). We sometimes had fun trying to understand how
> the French had interpreted requirements written in English by the
> Germans. The two other languages had left their imprints on the
> "English" wording :-)
We didn't really have that problem. On TCIU most of our requirements came from Dornier - > MMS-UK (ASAR instrument prime) - > Alcatel - > MMS-UK (TCIU team). Both MMS-UK teams were in Portsmouth. Alcatel were only there because of 'juste retour'* and they didn't even seem to bother trying to interpret the MMS-UK ASAR requirements, they just changed the front page to have "Alcatel" on it. We basically had a shed-load of requirements placed on us that had nothing to do with what the TCIU needed to do, and Alcatel never did get round to formally specifying the bit we really did need from them (the TCIU - > T/R Module - an Alcatel device - interface) as far as I can remember!
It was good in a way, but Alcatel certainly, and possibly also Alenia, played politics all the way through. We were required to go through Alcatel to get them to clarify some of the requirements that were relevant and had come from MMS-UK. As they had no idea what they meant, Alcatel had to go to MMS-UK to get the clarification. Fortunately Alcatel appeared to want to do as little work as possible for their money so they'd just forward the clarification from MMS-UK without bothering to try to understand it.
I'm sure lots of people have been in similar situations, but the inefficiency could've been disastrous, especially as we (the MMS-UK teams) had been working directly with each other on ASAR for years before Alcatel were put in to split us up, and we used the same canteen!
Ah well, those were the days. Apologies for going so far off-topic, but it was nice to reminisce :-)
* Similarly, the ASAR CESA (Central Electronics SubAssembly) requirements came Dornier - > MMS-UK - > Alenia - > MMS-UK.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [OT] ESA project memories (was Re: is Ada used in James Webb Space Telescope software?)
2021-12-31 10:26 ` John McCabe
@ 2021-12-31 21:18 ` Niklas Holsti
2022-01-05 16:43 ` John McCabe
0 siblings, 1 reply; 13+ messages in thread
From: Niklas Holsti @ 2021-12-31 21:18 UTC (permalink / raw)
On 2021-12-31 12:26, John McCabe wrote:
> On Tuesday, 28 December 2021 at 10:59:36 UTC, Niklas Holsti wrote:
>> On 2021-12-28 12:24, John McCabe wrote: [snip]
>>> Although Nikolas mentions Matra Marconi Space mandating TLD,
>>> that would've come down from Dornier who'd apparently done a deal
>>> with TLD.
>> Yes, a considerable part of our requirements came from Dornier via
>> Matra Marconi Space (France). We sometimes had fun trying to
>> understand how the French had interpreted requirements written in
>> English by the Germans. The two other languages had left their
>> imprints on the "English" wording :-)
>
> We didn't really have that problem. On TCIU most of our requirements
> came from Dornier - > MMS-UK (ASAR instrument prime) - > Alcatel - >
> MMS-UK (TCIU team). Both MMS-UK teams were in Portsmouth.
Interesting :-). I had a similar, but inverse, experience in a later
project (SW for the Flexible Combined Imager instruments on the MTG
satellites) where Thales Alenia Space (France) was both our customer for
the whole SW and our subcontractor for a part of the SW. It led to a
number of "direct" communications and decisions between the two TAS-F
teams that bypassed our team (in Finland) and of which we learned later.
But not much harm done, overall a good project.
> Alcatel were only there because of 'juste retour'*
I can't complain about "juste retour" as without it much less ESA work
would be given to Finnish companies, especially earlier when Finland was
a new ESA member with no experience in ESA work.
(For those not in the know: "juste retour" is the ESA policy by which
ESA tries to give enough project work to each of its member countries to
correspond to the country's share of ESA membership fees.)
> and they didn't even seem to bother trying to interpret the MMS-UK
> ASAR requirements, they just changed the front page to have
> "Alcatel" on it. We basically had a shed-load of requirements placed
> on us that had nothing to do with what the TCIU needed to do, and
> Alcatel never did get round to formally specifying the bit we really
> did need from them (the TCIU -> T/R Module - an Alcatel device -
> interface) as far as I can remember!
Sounds like blatant work-avoidance indeed.
> It was good in a way, but Alcatel certainly, and possibly also
> Alenia, played politics all the way through. We were required to go
> through Alcatel to get them to clarify some of the requirements that
> were relevant and had come from MMS-UK. As they had no idea what they
> meant, Alcatel had to go to MMS-UK to get the clarification.
> Fortunately Alcatel appeared to want to do as little work as possible
> for their money so they'd just forward the clarification from MMS-UK
> without bothering to try to understand it.
>
> I'm sure lots of people have been in similar situations, but the
> inefficiency could've been disastrous, especially as we (the MMS-UK
> teams) had been working directly with each other on ASAR for years
> before Alcatel were put in to split us up, and we used the same
> canteen!
Although splitting work up into several companies does easily make for
inefficiency, in can also have the benefit of documenting stuff that
otherwise might be lost in internal e-mails or face-to-face discussions.
That is, if the companies involved do their work properly, and don't act
as you describe for Alcatel. But perhaps the Alcatel technical people
did as well as they could to mitigate a poor higher-level decision, by
being basically a transparent conduit, as you describe.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [OT] ESA project memories (was Re: is Ada used in James Webb Space Telescope software?)
2021-12-31 21:18 ` [OT] ESA project memories (was Re: is Ada used in James Webb Space Telescope software?) Niklas Holsti
@ 2022-01-05 16:43 ` John McCabe
0 siblings, 0 replies; 13+ messages in thread
From: John McCabe @ 2022-01-05 16:43 UTC (permalink / raw)
On Fri, 31 Dec 2021 23:18:49 +0200, Niklas Holsti wrote:
> On 2021-12-31 12:26, John McCabe wrote:
<snip>
>> We didn't really have that problem. On TCIU most of our requirements
>> came from Dornier - > MMS-UK (ASAR instrument prime) - > Alcatel - >
>> MMS-UK (TCIU team). Both MMS-UK teams were in Portsmouth.
> Interesting :-). I had a similar, but inverse, experience in a later
> project (SW for the Flexible Combined Imager instruments on the MTG
> satellites) where Thales Alenia Space (France) was both our customer for
> the whole SW and our subcontractor for a part of the SW. It led to a
> number of "direct" communications and decisions between the two TAS-F
> teams that bypassed our team (in Finland) and of which we learned later.
> But not much harm done, overall a good project.
It would be inappropriate of me to say whether or not that sort of
behaviour occurred on ASAR, although I seem to remember occasions where
Alcatel waived their right to be piggy-in-the-middle as some of the
discussion about SAR pulse timing and the effect of shifting things
around a bit, to deal with the fact that we would've needed a mid-90s
supercomputer (and a substantial re-design of the TCIU -> T/R Module
interface) to achieve what was originally specified, would've fried the
brains of the people who were actually involved :-)
<snip>
> Although splitting work up into several companies does easily make for
> inefficiency, in can also have the benefit of documenting stuff that
> otherwise might be lost in internal e-mails or face-to-face discussions.
> That is, if the companies involved do their work properly, and don't act
> as you describe for Alcatel. But perhaps the Alcatel technical people
> did as well as they could to mitigate a poor higher-level decision, by
> being basically a transparent conduit, as you describe.
To be fair (to MMS!), the actual documentation that was produced at the
instrument level was pretty good. To be fair to Alcatel, as I mentioned,
we'd been working without them on this for a long time before ESA decided
to mandate that they should "manage" the TCIU development as a
subcontract, so they were forced to pick up on stuff they pretty much
hadn't cared about before.
Ironically none of this helped with the documentation from Alcatel; the
TCIU -> T/R Module interface I mentioned, for example. We went through 3
rounds of TCIU Software Requirements reviews (i.e. SRR, then re-visited
at ADR and DDR or something like that), where our assumptions on how that
interface worked (based on rough sketch ideas we'd been given rather than
formal specification) were described, before someone at Alcatel bothered
to read it and say "nah, doesn't work like that" (presumably in French) :-
)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: is Ada used in James Webb Space Telescope software?
2021-12-27 0:37 ` Paul Rubin
2021-12-27 7:44 ` Niklas Holsti
2021-12-28 10:24 ` John McCabe
@ 2022-04-23 9:17 ` 姚飞
2 siblings, 0 replies; 13+ messages in thread
From: 姚飞 @ 2022-04-23 9:17 UTC (permalink / raw)
在 2021年12月27日星期一 UTC+8 08:37:03,<Paul Rubin> 写道:
> John McCabe <jo...@mccabe.org.uk> writes:
> > I didn't realise there had been so many projects in Forth.
> Interesting. I hadn't heard of the MA31750 but it appears to be a 16
> bit processor that implements the MIL-STD-1750A instruction set(!),
> which I didn't know about either. Apparently it was made in the 1980s
> but has since been superseded by SPARC architecture cpu's.
MAS31750 + XGC M1750-Ada is a very wonderful combine, we use them for several large satellite, and they are working on orbit now.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-04-23 9:17 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-26 13:18 is Ada used in James Webb Space Telescope software? Nasser M. Abbasi
2021-12-26 14:23 ` Dmitry A. Kazakov
2021-12-26 19:22 ` Paul Rubin
2021-12-26 23:57 ` John McCabe
2021-12-27 0:37 ` Paul Rubin
2021-12-27 7:44 ` Niklas Holsti
2021-12-28 10:24 ` John McCabe
2021-12-28 10:59 ` Niklas Holsti
2021-12-31 10:26 ` John McCabe
2021-12-31 21:18 ` [OT] ESA project memories (was Re: is Ada used in James Webb Space Telescope software?) Niklas Holsti
2022-01-05 16:43 ` John McCabe
2022-04-23 9:17 ` is Ada used in James Webb Space Telescope software? 姚飞
2021-12-30 13:30 ` Peter Chapin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox