TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Alan and Carmel Brain <[log in to unmask]>
Reply To:
Alan and Carmel Brain <[log in to unmask]>
Date:
Thu, 7 Feb 2002 23:30:36 +1100
Content-Type:
text/plain
Parts/Attachments:
text/plain (105 lines)
From: "Gloster" <[log in to unmask]>

> BTW today was my last day working as leader of the On-Board Software
Development on
> FedSat (Australia's First R&D Satellite in 25 years)."
>
> What an atrocious treatment of valuable human resources.

With a bit of luck in a few weeks I should be doing an AI system to advise
General
Practitioners. So it's not all bad.

OK, yes, I'm missing the project dreadfully. But to some degree "Our work
here is
done, Tonto. Hi-Ho, Silver!"

Still miss it though.

> "That's the trouble with Ada - the software works reliably first time, and
the developers
> are out of a job till the next project comes along : there's almost no
maintenance effort
> compared with the initial development."
>
> Having come from an onboard software maintenance department, I can say
that though Ada is
> excellent the user perception of developers wanting to hop onto a brand
new project would
> be changed if they provided a reliable; elegant; and safe way of modifying
the software in
> flight without having to resort to assembly and manual task rescheduling.

The Large Data Transfer Service and codepatch service - for updating the
code on various
payloads *and also* the compiled Ada-95 code that's the "Operating System"
was the last
bit I had to get working before leaving.

The development process (assuming you've gone through requirements, analysis
and design) involves:
a) Make change to code using Nedit.
b) Compile and build using command "build" (described in User manual).
Syntax is "build", no
arguments needed.
c) iterate a) and b) till it compiles with zero warnings and zero errors.
Then check it in.
d) Make an executable version for the software simulator using "build test"
e) Test on simulator, iterate previous steps till it works.
f) Make and install a version on the EM (Engineering model, ie a copy on the
ground) Ground
 Control system Operational Command Console (OCC) using command "build
install" which
automatically generates a build number and places the binary under config
management, and
transfers it to the OCC.
g) Check to make sure it's there. Get permission from Director to continue.
h) Packetise, using OCC system's "convert file to LDTS packets" button,
addressed to LDU 1.
i) Run Verifinator on command stack using OCC "Check" facility.
j) Set Engineering Model to "Simulated Ground Pass" state, and repeat until
it's got everything.
Command Stack will be automatically sent.
k) Send a Telecommand to Warm Restart, booting directly from LDU 1 . Any
problem will cause
a re-start, re-booting from Flash (ie previous version of code).
l) Do vast quantities of regression testing. Repeat previous steps till it
works.
m) When all is well, send a Telecommand to transfer data from LDU #1 to
Flash.
n) Do a warm start, booting from Flash
o) Do vast quantities of regression testing.
p) Now transfer the file to the "live" OCC and repeat steps h) to o) on the
FM (Flight Model -
the bird in orbit). OCC will automatically re-send missed packets, and
inform that upload
to LDU was successful or otherwise.

OK, so it requires a Warm start when you make a change to the code. Or a
Cold Start if your
change has invalidated some hardcoded data store boundaries, or definition
of metadata of
Warm Start Variables. No Dynamic Binding as such. But the above process
could be performed
by a new graduate or good undergraduate - all regression tests are
automated.

To change the code on other payloads involves uploading to different LDUs,
and using
different Telecommands to transfer data from LDU to payload, and restart the
payload,
but is otherwise the same.

It's as simple and turnkey as we can make it. We've cycled through this
literally
hundreds of times now - though the FM's still in pieces in the cleanroom.

There's no assembler, no "tweaking" of the scheduling required. It's pure
RTEMS 4.5
(open source) with gnat 13.10p (the public, free version) on top. Cost
zilch. This
satellite is being built on a shoestring budget, as a "learning exercise"
for us to
find out and solve the problems in making a 5-payload satellite in under 60
kg.

ATOM RSS1 RSS2