From: "Gloster" <[log in to unmask]>
> BTW today was my last day working as leader of the On-Board Software
> 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
Practitioners. So it's not all bad.
OK, yes, I'm missing the project dreadfully. But to some degree "Our work
done, Tonto. Hi-Ho, Silver!"
Still miss it though.
> "That's the trouble with Ada - the software works reliably first time, and
> are out of a job till the next project comes along : there's almost no
> 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
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
Control system Operational Command Console (OCC) using command "build
automatically generates a build number and places the binary under config
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
m) When all is well, send a Telecommand to transfer data from LDU #1 to
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
To change the code on other payloads involves uploading to different LDUs,
different Telecommands to transfer data from LDU to payload, and restart the
but is otherwise the same.
It's as simple and turnkey as we can make it. We've cycled through this
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
(open source) with gnat 13.10p (the public, free version) on top. Cost
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