Question about Real Time Kernels for small satellite

Question about Real Time Kernels for small satellite

Post by Paul E. Bennet » Wed, 14 May 1997 04:00:00




> Hi there... I am on an undergraduate software team working to design an
> avionics system for a very small satellite due for launch in January
> 98.  We are using the Hitachi SH7032 32-bit RISC processor for our CPU,
> and I had some questions regarding Real Time Operating Systems /
> kernels.

> What would the mininum system requirements be for real time kernels?
> The cpu can run up to 20mhz, but for power consumption purposes we may
> run as low as 4Mhz.  There is 8k of on board Ram, and 2 megabytes of
> flash memory.

> Our current missions will not require a very robust OS ... but future
> missions may... so we are looking for some system that would be
> expandable.  Any help would be appreciated.

> Sameer Samat


Look at Forth for this. NASA use Forth for a large number of Satelite
projects because it provides the ability to up-date the software even
when the satelite is in orbit (expensive to fix problems otherwise).
Forth is also used on the Shuttle and we use it for some Very High
Integrity Systems. My company have procedures and processes that will
help produce certified Forth code for the higher integrity situations.

--

Transport Control Technology Ltd.
+44 (0)117-9499861
Going Forth Safely

 
 
 

Question about Real Time Kernels for small satellite

Post by Sameer Sama » Fri, 16 May 1997 04:00:00


Hi there... I am on an undergraduate software team working to design an
avionics system for a very small satellite due for launch in January
98.  We are using the Hitachi SH7032 32-bit RISC processor for our CPU,
and I had some questions regarding Real Time Operating Systems /
kernels.

What would the mininum system requirements be for real time kernels?
The cpu can run up to 20mhz, but for power consumption purposes we may
run as low as 4Mhz.  There is 8k of on board Ram, and 2 megabytes of
flash memory.

Our current missions will not require a very robust OS ... but future
missions may... so we are looking for some system that would be
expandable.  Any help would be appreciated.

Sameer Samat


 
 
 

Question about Real Time Kernels for small satellite

Post by Walter Mallo » Fri, 16 May 1997 04:00:00




>> Hi there... I am on an undergraduate software team working to design an
>> avionics system for a very small satellite due for launch in January
>> 98.  We are using the Hitachi SH7032 32-bit RISC processor for our CPU,
>> and I had some questions regarding Real Time Operating Systems /
>> kernels.

>> What would the mininum system requirements be for real time kernels?
>> The cpu can run up to 20mhz, but for power consumption purposes we may
>> run as low as 4Mhz.  There is 8k of on board Ram, and 2 megabytes of
>> flash memory.

It all depends on what you want to do.  What are your worst case system
level timing requirements?  The requirements you should place on the
performance of the realtime kernal are dependent on what you need it
to do to help implement your system.

>> Our current missions will not require a very robust OS ... but future
>> missions may... so we are looking for some system that would be
>> expandable.  Any help would be appreciated.

>> Sameer Samat

>Look at Forth for this. NASA use Forth for a large number of Satelite
>projects because it provides the ability to up-date the software even
>when the satelite is in orbit (expensive to fix problems otherwise).

It has been my experience that NASA does not use Forth very much any
more for satellite work.  C and Ada appear to be much more common for
new work .  This may vary from center to center.  I'm basing my
statement on my past interactions with Goddard and Langley Space Flight
Centers (someone from NASA can certainly correct me) as well as
knowledge of other prime contractor's work for NASA.  I'm not
critisizing Forth here and your suggetion to use Forth may still be
quite valid for the original poster's application.  Just wanted to point
out that your statement probably isn't real accurate.

Updating the software from the ground to an orbiting sattelite should
be possible with any language.  I've personally done it for code written
in C as well as in assembler.  It's certainly also possible using Ada or
Jovial.

Quote:>Forth is also used on the Shuttle

Probably a true statement but there are *many* computer systems on the
Shuttle and I'm almost positive the main safety critical Shuttle control
computer is not programmed Forth.  Do you know which system(s) is(are)?  
I'm actually curious here, not just trying to give you a hard time.

<snip>

--

All opinions expressed are my own and not my employer's.

To email me, please remove the word REMOVE from my email address.
Sorry, the spam has just been getting too thick lately
--

 
 
 

Question about Real Time Kernels for small satellite

Post by JUKK » Fri, 16 May 1997 04:00:00


I think that you basicly need some simple system that can run
multiple routines at the same time. I would write a simple
thread / task switch my self and use programmed thread switching.
This needs only few lines of code for the switch and a list of threads
waiting the CPU. And a routine to allocate some own stack for each
thread.

But with that kind of a simple system you can implement almost
anything needed in a system where thinks should happen parallel.
And the threads can run independently doing only their own tasks.
And make also wait loops without locking the CPU.

I can send you some code examples how to implement it your self.
Or refer to some articles in "The Computer Applications Journal" or
"Circuit Cellar Ink" magazine some years ago.

JOJ

 
 
 

Question about Real Time Kernels for small satellite

Post by Kurt Bilinsk » Fri, 16 May 1997 04:00:00


If I were going to put (small) software into something (with little memory) that was
absolutely critical, I think I would go back to assembly language.

I never quite trust a compiler.  I think of it like an onion, going from assembly
language to C backs out a level and you loose sight of what is really happening.  
How do you _really_ know what a compiler is doing.

Sure, you can disassemble the entire program, but unless all the upper-level library
files are disassembled too, you still have to say to the compiler "I trust you'll do
it the 'right' way."

Part of this is I've never been real impressed with the compilers and simulators
available for the smaller processors.

I guess I'm destined to lose this one, but it's only when I use assembly language do
I feel "I'm really in control."

Kurt

 
 
 

Question about Real Time Kernels for small satellite

Post by Robert Kais » Sat, 17 May 1997 04:00:00




Quote:>The cpu can run up to 20mhz, but for power consumption purposes we may
>run as low as 4Mhz.  There is 8k of on board Ram, and 2 megabytes of
>flash memory.

With this little RAM, you might want to check out Nucleus. I don't
have any personal experience with it, but from what I heard, it might
be just the thing you need. Their URL, AFAIK, is http://www.atinucleus.com.

Rob

 
 
 

Question about Real Time Kernels for small satellite

Post by William A. Gatlif » Sat, 17 May 1997 04:00:00


JUKKA wrote:
> > No offense, but I would be extremely nervous placing a system into
> orbit
> > based on hand-coded examples taken from a magazine.

> Basicly yes. But you are only nervous because you cannot make good
> programs your self! And if one is programming satellites he has to
> trust
> also his own programming skills!

If I'm hiring someone to develop software for me, I'm certainly not
going to trust their programming skills.  Only the test results will
prove whether or not they can produce a system that works.

In my opinion, the converse is also true: trusting a person's
programming skills without proving them is a fools paradise.

> > In my opinion, your time would be better spent understanding,
> designing,
> > developing, and testing your application software.  Buy the parts
> that
> > aren't directly relevant to your application (operating systems,
> > debugging tools, networking protocols, etc.) from reputable
> vendors with
> > measurable market shares.

> This sounds like this person is self making some commercial systems.
> I
> would say that all the parts are very relevants to a system because
> bug
> in any part will usually hang the whole system! I am only refering
> to the
> many satellites that don't work after sending them! The problem is
> mostly
> not being able to make good fail safe systems!

Read my signature: I'm not a commercial RTOS vendor.  But I HAVE gotten
paid for the last five years or so to fix problems by people who said
"trust me, I know what I'm doing" but then failed to deliver.

One of these assignments was explicitly to fix problems in a
hand-written RTOS; several other assignments involved systems that
either needed an operating system and didn't have one, or had one and
didn't use it very well.

By the way, the systems I work on don't have the luxury of allowing
themselves to be crippled by a single point of failure.

> And when the code what one need to implement parallel threads is 30
> lines .. one cannot make so many bugs. One can use a full blown
> system with lot of code if one you wants. But I am sure that there
> are
> also many more problems when learning and testing it.

Lots of the bugs I fix involve only one or two lines of code.  I'd guess
that's pretty typical.

> > That's not to say that commercial operating systems are perfect.
> > However, they've got lots of people testing them (the users), so
> they're
> > more likely to be closer to perfect than something written by
> somebody
> > whose career doesn't depend upon having a decent product, or has
> no
> > prior experience with that type of application.
> Yes. Sure testing. But the bug reports that you send are just put
> away.

I find such a general statement completely ridiculous.

> The people making new and bigger systems are too busy to make more
> that they don't any more bother with that old system you are sending
> bug
> reports from. They don't have the time. And the new system will
> anyway
> do everything in a different manner. Spending time in the old system
> is
> only lost money. Because they will never get any more money from
> that.
> Better to make a completly new system and sell it to the user!!!!
> And that
> is only done by introducing some new properties (and bugs)!

This sounds a lot like "not invented here" syndrome.  I don't know about
the kind of companies you deal with, but the ones I work with tend to be
more responsive than you describe, at least the ones that want to stay
in business.

- Show quoted text -

> > At the end of the day, I've consistently found that I can buy
> software
> > components and their related development and testing tools much
> more
> > cheaply than I can develop, debug, and test them myself, despite
> their
> > apparently high price tags.

> Nobody is asking here to get something cheap!

> > First: someday your satellite will head for orbit (I bet the date
> is
> > already set), which leaves you a fixed amount of time to develop
> your
> > application.  Doesn't it make the most sense to spend the most
> time
> > possible developing, refining, and testing the software directly
> related
> > to your experiments?  Buy the rest, because if you decide to build
> them
> > yourself and get mired down to the point you miss your launch date
> (or
> > deliver a satellite that fails in orbit), you might as well not
> have
> > started the project in the first place.

> It is no wonder if the satellite would stop working after sent .. if
> you
> would
> not spend any time developing, refining and testing it!!!! Testing
> is the
> most important part of the whole system! Make the system more simply

> if no time. But never stop testing it! What the use to send there
> something
> that does not work (it is same as send a stone there). Better to
> change the
> launch date and send it later when sure that it works!

I don't do space work, but my impression is that it's not so easy to
change a launch date, especially when you're not the only payload.

Testing is NOT the most important part of the system.  Rather, each
phase in the development cycle is equally important.  Neglect one, and
it's possible that no amount of effort will help you recover in a later
phase.

Furthermore, just because a system passes its tests doesn't mean it
works, unless your tests are a complete simulation of the working
environment.  I find that even in uncomplicated systems, this is
extremely difficult to achieve.

> > Second: if you do experience a failure in orbit, do you want to
> say it's
> > because you "copied some code [buggy] from a magazine" (or from
> USENET)?
> Who is this person to tell what is buggy when he don't even know
> what
> the system or code is about! Or do one have to say at a failure
> "made as
> some idiot wrote in a news group!"

My point is: "don't trust skills you don't have".

> I have seen so many buggy systems that I trust only my self in
> critical
> sections! The only problem is that commercial products tend to
> invest
> more on selling than making them debugged. When you once have the
> system and the people have your money. They care less about the bugs

> in that system. They try to make more code and properties in order
> to
> sell it more. Nobody makes less in order to make it more ROBUST!
> Every new more line will introduce a new possibility to a bug.

There's that "not invented here" syndrome again.  See my point.

- Show quoted text -

> It is well known that programs that are good and programs that sell
> well
> (bif market shares) are not in the same category. Making a program
> to
> sell means that it needs to be more than the competitors program.
> And
> that is when it gets bigger and bigger. And this is done so fast as
> possible
> to stay one step ahead all other programs. And when you make
> something
> in a hurry you make bugs. And if the bugs don't show very soon ..
> who cares
> .. as long you have the money! Get the picture?

> I was only telling what I WOULD DO. This is because: What you have
> self
> done and tested is much better than something somebody sometimes
> did.
> If you don't know very well who that one was/is and how it was done!

I disagree.  Someone who's written several operating systems, maintained
a few commercial versions, and experimented with future versions is much
more qualified to develop and sell an operating system than someone who
hasn't.  These qualifications will help assure that the product works.

Furthermore, if something works well, and people need it, then they'll
buy it.  If it doesn't work, people won't buy it.  So, market share is a
(partial) figure of merit for the quality of a software product.

If a vendor wants to keep that market share, they'll make sure the
product delivers what it promises.  This doesn't always mean the
software gets bigger; it usually means it gets better.

- Show quoted text -

> Something which has a big market share and plenty of kilo bytes is
> not
> so often something which is robust and fail safe! Having tested
> programs
> some 20 years have seen this too often!
> "Sorry .. but that is the sad story with most commercial
> programs .. money, money, money!"

> JOJ

> P.S. Why not use several methods and some kind of a switch to change

> to an other implementation in case of problems? Or make a system
> that
> can be downloaded when in orbit. In case of problems just send a new

> program. The basic code to implement the download mechanism should
> be very small and very well tested to avoid bugs in it. Some kind of
> a boot
> loader.

> And there are plenty of material around about how to make failure
> safe
> systems. I would read some of these too.

Your P.S. fit in nicely with a thread that's been here recently, about
how deceptively difficult it is to make a truly fault-tolerant system.
It's definitely NOT easy (witness how few of them are around), and is
definitely not something somebody can just hack out.

b.g.

--
William A. Gatliff
Software Engineer
Cummins Engine Company, Inc.
PO Box 3005 MC 7003
Columbus, IN 47202
bill.gatl...@cummins.com

 
 
 

Question about Real Time Kernels for small satellite

Post by William A. Gatlif » Sat, 17 May 1997 04:00:00



> >What would the mininum system requirements be for real time
> kernels?

> A microprocessor, with a timer which can generate a regular
> interrupt.

Well put.  How come you're consistenly better at saying what I'm
thinking than I am? :^)

b.g.

--
William A. Gatliff
Software Engineer
Cummins Engine Company, Inc.
PO Box 3005 MC 7003
Columbus, IN 47202

 
 
 

Question about Real Time Kernels for small satellite

Post by D.F.S » Sat, 17 May 1997 04:00:00



Quote:> If I were going to put (small) software into something (with little memory) that was
> absolutely critical, I think I would go back to assembly language.
> I never quite trust a compiler.  I think of it like an onion, going from assembly
> language to C backs out a level and you loose sight of what is really happening.  
> How do you _really_ know what a compiler is doing.
> Sure, you can disassemble the entire program, but unless all the upper-level library
> files are disassembled too, you still have to say to the compiler "I trust you'll do
> it the 'right' way."
> Part of this is I've never been real impressed with the compilers and simulators
> available for the smaller processors.
> I guess I'm destined to lose this one, but it's only when I use assembly language do
> I feel "I'm really in control."

ahh....yeah, "compilers" suck, "assemblers" are cool....

Better go straight to machine code, skip the whole mess, your assembler could
*up your code.

Where do most software errors come from?
I currently test code for a living, almost all of the things that I see
end up being due to programmer error, somebody screwed up or did not understand

If a higher level language cuts those errors in half for a normal programmer,
you bug rate is cut nearly in half.

Of course the rules don't apply to some ingineers that don't make any mistakes
and any errors that show up later must be due to a compiler error.

Marc

 
 
 

Question about Real Time Kernels for small satellite

Post by Allis » Sat, 17 May 1997 04:00:00



>avionics system for a very small satellite due for launch in January
>98.  We are using the Hitachi SH7032 32-bit RISC processor for our CPU,
>and I had some questions regarding Real Time Operating Systems /
>kernels.

You supplied far to small a portion of a specification to get anything
more than personal opinion.

First off I'd want to know my power budget, how fast a reaction
(latentcy?) time was expected or required from the CPU.  Are the
components radiation hard?  How errors are expected to be handled.

A tasking kernal is likely only one of the smaller parts of the
project.

Allison
the



  This was done to discourage some of the junkmailers.

 
 
 

Question about Real Time Kernels for small satellite

Post by John Lydi » Sat, 17 May 1997 04:00:00



> >What would the mininum system requirements be for real time kernels?

> A microprocessor, with a timer which can generate a regular interrupt.

  I would add at least a simple watchdog to the hardware.  It should
  be fed from one of the tasks.  Hopefully, if the task switching fails
  the watchdog could at least restart things.

  The kernel should provide standard resource management.  Task
management,
  memory management, events/semaphores/mutex's and interrupts would be
  the minimum.  Depending on the satellite function, threads may be very
  useful.

  John

--


 ***

 The Contents of this Message are mine solely and
 do not necessarily reflect the Views of the Eaton
 Corporation.  The Eaton Corporation has not reviewed
 nor approved of this Message.  I speak for myself.
 I am NOT authorized to speak for the Eaton Corporation."

 ***

 
 
 

Question about Real Time Kernels for small satellite

Post by William A. Gatlif » Sat, 17 May 1997 04:00:00



> ahh....yeah, "compilers" suck, "assemblers" are cool....

> Better go straight to machine code, skip the whole mess, your
> assembler could
>*up your code.

> Marc

Better yet, take the microcontroller out the picture completely, and
implement the whole system with discrete hardware components!

b.g.

--
William A. Gatliff
Software Engineer
Cummins Engine Company, Inc.
PO Box 3005 MC 7003
Columbus, IN 47202

 
 
 

Question about Real Time Kernels for small satellite

Post by Frank Bemelm » Sat, 17 May 1997 04:00:00



>Part of this is I've never been real impressed with the compilers and simulators
>available for the smaller processors.
>I guess I'm destined to lose this one, but it's only when I use assembly language do
>I feel "I'm really in control."

I have had my moments where I was 100% sure that the compiler screwed
up. Looking at the code that the compiler produced, every time the
compiler was *y right.

I have to admit that with assembler there's less doubt about the
produced code. Sometimes I even do not trust the hardware - the memory
where my pointers are stored. It's silly to put a range-check on a
pointer, if you know that the particular pointer is correctly
initialized and maintained. Somtimes I am silly, and put those extra
checks in anyway, a little paranoia I guess.

Best regards, Frank.

 
 
 

Question about Real Time Kernels for small satellite

Post by Iain Tebbut » Sun, 18 May 1997 04:00:00




Quote:>> >What would the mininum system requirements be for real time kernels?

>> A microprocessor, with a timer which can generate a regular interrupt.

>  I would add at least a simple watchdog to the hardware.  It should
>  be fed from one of the tasks.  Hopefully, if the task switching fails
>  the watchdog could at least restart things.

>  The kernel should provide standard resource management.  Task
>management,
>  memory management, events/semaphores/mutex's and interrupts would be
>  the minimum.  Depending on the satellite function, threads may be very
>  useful.

We have implemented a simple real-time OS for the SH7032 intended for
use with our single board computers. This OS provides all the
task/memory management functions and provides semaphores, mutexs,
mailboxes, interrupt management.

I think you need to consider your timing requirements (and also your
memory requirements) quite carefully. Bear in mind that you will need
enough RAM for the stack for each task that you are running together
with any global variables.

If you want to have a look at typical timings for operating system
functions then they will be available on our web site from 18th May. All
our timings are for a SH7032 at 20MHZ.

Good Luck

   Iain

--
       Iain Teb*
       Claritech Ltd
Tel:   01530 412488
Fax:   01530 412488

www:   http://www.veryComputer.com/

 
 
 

Question about Real Time Kernels for small satellite

Post by JUKK » Sun, 18 May 1997 04:00:00


Quote:> > ahh....yeah, "compilers" suck, "assemblers" are cool....

> > Better go straight to machine code, skip the whole mess, your
> > assembler could
> >*up your code.

> Better yet, take the microcontroller out the picture completely, and
> implement the whole system with discrete hardware components!

Some things are best done in assembly if you compare it to C. And some
things are best done using C. But if the system is very small. I would jump
totally to assembly! Some hardware related stuff get only more complicated
when using C compiler. As an example bit manipulation. And as a last word:
assembly is more efficient in SMALL systems too. And everybody hates
those huge libraries you have to link with only to get two lines from
there!
And nobody knows what actually happens there! That makes assembly
cool!

"I think that the people who try to make assembly unwanted here are
mostly people that cannot self write any assembly code!"

JOJ

 
 
 

1. Senior Real-Time C++ designers sought for Communications Satellite SW development

We are looking for several very senior software designers to assist with
developing the spaceborne and ground-based software required to control a
constellation of communications satellites.

Candidates must be thoroughly familiar with the principles and techniques
of object-oriented analysis and design as well as being fluent in C++.  
Ideally, candidates will have 10+ years experience designing software
with a minimum of five years experience designing object-oriented,
real-time software.

We offer rates beginning at $10K/month with a potential for $140K or more
annually. Work assignments, performed on-site in Arizona, range from 9 to
18 months.

TekSci, a small, privately-held company based in Seattle, assists clients
nation-wide with projects in such diverse fields as acoustics, avionics
and automated instrumentation.

Please join with our Phoenix office and enjoy what may be the most
interesting and rewarding work you'll ever experience. Send your resume
TODAY!

2. Final CFP: 2nd International NASA Workshop on Planning and Scheduling for Space

3. Embedded real-time Micro Kernel with source

4. Can i learn digital?

5. Using Real Time kernels on R3000 hardware

6. Is it possible ?

7. Real-time kernel for PIC18

8. NT server 4.0

9. Tiny Real-Time Kernel for PIC17CXXX?

10. Announce: free compact real-time kernel. C source

11. Simple, low cost real-time kernel for 8051

12. Simple real-time kernel for 8051 software.

13. RTXC Real time kernel