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.