Multiple aircraft in IADS

[Watzlavick, Robert L]

We need to figure out how to handle multiple aircraft at the same time in IADS.  One way to handle this would be the brute force method of duplicating all the parameters, displays, etc. with a prefix of the tail number.  The Global Parameter Replace seems to be the logical choice but it doesn’t handle everything such as constants, datagroup names, envelopes, or text-based tables for ICAW and Event Monitors.  Merging the text-based ICAW and Event Monitors into the config file would help.   All the desktops and analysis windows would need to be renamed too especially if they are tail-number specific.  Most of our external IAP/COM functions use datagroups for parameters but there a few that directly reference constants so those DLLs would need to be updated on our end.  I was thinking o f using a combination of the config interface to retrieve all the things that need to be changed, then a script of some sort to go through the config and rename everything.  I haven’t used the config interface in a few years – can it be used to extract out all the names of parameters, displays, constants, etc.?  Can you think of anything else that we are missing or a better way to do this?

 

If it weren’t for a requirement to create derived equations that are function of more than one aircraft (distance or bearing between them for example), we could just run multiple CDS instances and have the users launch separate copies of the client.  Well, that assumes we can connect multiple CDSs to the same front end which I’m not sure will work.

 

Thanks,

-Bob

[James Bretz]

Hi Bob,

 

Ya that is a tough one. I have been scratching my head thinking how to answer this one properly.

 

Using the config interface is *tough* to extract out all the parameter names, etc to say the least. The interface should help somewhat because it give you a handle on an "SQL" (not standard SQL but close) interface so you can knock out the most obvious changes with a simple query or two. The problem comes when you want to start modifying the ActiveX embedded parameters. This is tough because they are embedded into a non-human-happy string in the PropertyBag field. It's in this case where you'll be doing to complex custom parsing. Not fun.

 

I honestly don't think you can connect two simultaneous CDSs to the same front end, but Mike Burt would have to verify. Actually, if you had two separate data gather cards available, it might work. This seems pretty drastic though and might be iffy depending on the processing load.

 

I'm thinking about some way to tweak the parameter alias table in order to solve this issue. That way you don't need to actually physically change the parameter names, you just need to alias them. It's probably a no go, but it would be the nicest solution.

 

So, question: are both aircraft's parameter coming down through the same 550? If so is it like and independent stream? And if that's true, do you need to rename the parameters on the front end to get around this collision as well?

 

The bottom line is that we can probably fix the shortcomings in the parameter replace mechanism and then do the conversion for you here. I guess we need to balance the pain factor and how much time we have etc.

 

Any comments?

Jim

--
You received this message because you are subscribed to the Google Groups "IADS" group.
To post to this group, send email to ia...@googlegroups.com.
To unsubscribe from this group, send email to iads+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/iads?hl=en.

[Watzlavick, Robert L]

Thanks Jim.  The request is actually coming from EDW so it would be with their custom front end.  We were going to try and prototype it here to see what all the problems are.  I thought in the config file that the parameter names dropped onto a control would still show up as text in the file.  Or are there other cases where it won’t be so readable?  In the example below, I dropped Parameter1 and Parameter2 onto the text control:

 

Table IadsActiveXControls

   {

      TableDefinition Name|X|Y|Z|Width|Height|ProgId|ParentName|PropertyBag

      TableType String|Int|Int|Int|Int|Int|String|String|String

      TableContents

      {

         14-ThuDec0216:53:412010@AER1WU8353WL6 Text1|487|295|0|150|50|IadsPrimitives.IadsText.1|Window1|\FC=7,19\Text=-9.297765,8\AP=Text,Parameter1,0,FillColor,Parameter2,0,8\Layer=1,3\_DI=22722_22182_6992_3754,8

      }

   }

 

I was figuring we’d have to just search and replace in the overall config file with a Perl script and a giant CSV replacement table.  Then we would just merge them all in together.  An IADS native solution would be a lot better as long as it addressed every unique parameter, desktop name, etc.

 

-Bob

[James Bretz]

Bob,

 

No, you are correct. All the attached parameter show up in the config file. As long as you don't have parameter names with subsets that match each other you should be able to sed/awk/perl/vb/whatever your way through the replacement.

 

Ok, so a "secondary" custom front end huh? So basically a secondary data source to the CDS. Yes, this might work, but depending on how much data, etc. it might be a factor. It should handle a reasonable amount of parameters in addition to your base load. You'll have to test it though, you're right. Best to try a load test etc.

 

For version 6.X (I think you're still on 6.5) there might be some slight timing issues in the way data is aligned for the secondary data source. In 6.X the secondary data sources were being aligned to the primary's time input. This caused some misalignment of data in certain circumstances in the secondary source. It's probably nothing to be alarmed about, but it's something to note. Versions 7.X addressed this issue and solved the potential misalignment.

 

Let me know how things turn out. If you have problems we can crank on it over here,

[Watzlavick, Robert L]

“As long as you don't have parameter names with subsets that match each other”

 

Hmmm… good point – trying to select a set of delimiters for the replace operation may be problematic.  I suspect there are at least a few deriveds named such as “some_parameter” and “some_parameter_version2” which might make it tough.  Even worse would be “some_parameter” and “some_parameter version2”.  Is there a known/safe set of delimiters to use?  This a good example of why parsing the config file directly is a bad idea J

[James Bretz]

Bob,

 

LOL. There is always ways to cheat. Sort the parameter replacement list in order of string length (longest to shortest). Replace the longest parameter names first then the shortest last.

 

Kludgeworthy? Well, I just hope the new parameter names don’t match a subset of the older. I assume you'll prepend something to the beginning. This might nail it.

[bkelly]

You guys are way ahead of me, but we must deal with this in our system
that uses a Wyle G2 to decommutate the telemetry and send it to IADS.

In the G2 we assign a double prefix to each parameter. For example
S01_AR1_ABCD
The S01 is the stream number or channel number in the Wyle G2, the AR1
is the type of source, and the ABCD is the parameter name. In the G2
I clone streams by just exporting and changing the S01_ to S02_. This
also works in the IADS analysis window. Export the window, change its
name, do a global replace, and re-import it. Technically the AR1
section is not needed, but if you have multiple source types I think
it really helps to have it there. If you have short names, they will
be fine because you will know which window you have open.

If the prefix is sufficiently unique, then a quick replace on all your
files will suffice.