Re: [Mratc-developers] [my status]

[<aqu...@ya...>]

 --- Michael Ross <ht...@us...> wrote: 
> ----- Original Message -----
> From: "Aquila Deus" <aqu...@ya...>
> 
> > Again, I list things that we've (maybe) been sure:
> >
> >
> >    R A D A R                       F L I G H T S
> >
> >      ||                                  ||
> >      ||                                  //
> >
> >       Flight management system  (is the name proper?)
> 
> Sounds good

:)

> 
> >  +--------------------------------------
> >  |  Database to store flight info
> >  |  Flight registration interface
> >  +--------------------------------------
> >      ||
> >      ||
> >      ||   ATC
> >  +--------------------------------------
> >  | Internal structure undecided
> >  +--------------------------------------
> >
> >
> > Radar: I don't know about the interface of radar system.
> Should we get info
> > from radar (if so, how?), or wait for it to send our system
> info about flights?
> 
> Unspecified at this time.  Whichever works best.  The interface
> should be as open and widely implemented as possible, without
> sacrificing performance.

Ummm... The problem is: The real radar system is not going to be developed by
us. So we need to know what interface the manufacturer will provide. Is this
possible, now?

> We don't want to tie radar
> manufacturers down to an obscure, poorly supported protocol.

CORBA :)

> The atc and radar systems should be fairly independent as well.
> The radar system might be owned and maintained by one entity
> while the atc system is owned and maintained by another.  Having
> database logins for the other system might be too much
> interdependence.  No user IDs or passwords for the atc-radar
> interface seems appropriate at this time.  The atc system should
> be able to keep functioning even if it loses contact with a
> radar system.  Also, a radar system should be able to keep
> functioning even if it loses contact with the atc system.  We
> can try to re-establish communications if they are lost, but not
> put the whole show on hold while we wait for communications to
> be restored.
> 
> > ATC: the only thing we can be sure that it has only one source
> of input and
> > output. But that's good enough for us to start working on :)
> 
> What do you mean by "one source of input and output?"

The flight management system. The ATC retrieve and send everything via it (and
only via it). By this method we may make the development of ATC easier, because
things in the flight management system such as communicating to radar or
flights are uncertain.

> 
> > BTW, what happened to mratc.org??
> 
> It's still around.  Since DNS changes didn't propogate fast
> enough, I removed all the flight hostnames (flight1 - flight15).
> There are still atc & radar hosts.  There is no www host, but
> there is a home page for the project at
> http://mratc.sourceforge.net/

One question: If our ATC only helps flights to avoid collision and let them
decide what course they follow (and there is no pre-defined course), we may not
need to manage the course change at all. Besides, if the flights decide the
course by itself, it may hit flights or objects which are not managed by our
ATC (we can know this from radar though), and the possibility may be bigger
than hitting managed flights. Are you sure to let the flights decide the course
by themselved? Isn't this too different from current ATC?

BTW I have a good news for you: I won't touch java anymore, until I get a fast
computer... It's too terrible!


=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com