Since working with AGI for over 10 years now, I can say with some certainty that particular questions about our modules come up fairly regularly. One in particular is whether a client should use the STK Integration Module for Real Time propagation of targets or if the RT3 module is the better option. STK Integration is definitely the ‘go to’ module to properly connect different applications to the STK application programming interface (API) in which you either want to a) tell STK to do something or b) have STK tell another application to do something. Often the ‘telling’ is really just the exporting of vehicle ephemerides that are either visualized in STK or provided by STK to an application (like Matlab) to do other calculations and analysis.
Now, for RT3, to leverage some recents comments from an AGI colleague:
“RT3 could also be used for this, but the advantages of RT3 will only be realized if you are pushing many objects into STK at the same time. If your need is only to supply realtime positions for a smaller number of objects, I think the Realtime Propagator with an Integration license is probably a bit simpler.
RT3 comes with a software development kit (SDK) that helps you create time-triggered actions, etc
If you think there may be a future need for pushing a larger number of realtime objects into STK then RT3 is something you may want to consider looking into but I should let you know of a few caveats to RT3:
RT3 is meant to be able to streamline the realtime load by only displaying position data (i.e. not attitude data) and will group all incoming realtime entities into an STK Object called a “Multi Track Object” which is much lighter-weight than a “heavy” STK object. MTO’s are essentially a collection of ID’s with time-stamped position information associated with each ID. If an entity being supplied to RT3 does have attitude data associated with it, then RT3 will “promote” that particular ID to an actual STK aircraft object type and it will essentially be the same as using the Realtime Propagator via the previous method and will be more expensive computationally than a collection of objects with only positional data (i.e. Lat/Lon/Alt).
You do gain the ability to query the incoming data stream with RT3. This can be really useful if your data has associated Metadata with it. For example, you may have an incoming data stream from commercial air traffic such as FlightAware or FlightRadar24 and that data will have many data fields available aside from just position such as callsigns, departure airport code, arrival airport code, aircraft type, engine types, etc. etc. which you could then create an RT3 Query within the STK GUI to essentially filter out the potentially thousands of aircraft down to just the ones you may be concerned with.
RT3 also supports the concept of “Actions” or “Events” which you can create custom through .NET code. This lets you fire events based on whatever you may want to calculate. An example may be to change graphics to show the track(s) as RED in color if they are within a certain distance from another object or area, or do something more programmatic like send an email with specific information about any object that breaches a defined airspace volume (Area Target in STK for example). Because you create these “events” yourself in .NET, you can make them perform whatever tasks you want, not just in STK capabilities, but any other .NET capability/library you may have included in the project.”
I really could not say this last part better, so I didn’t. Hope it helps!
You must be logged in to post a comment.