Question for all: How are you building up your final config file?

[Jim Bretz]

Hello everyone,

During a meeting at EAFB, the question that's been the subject of many
previous topics came up: "The users are bringing us all of their
Desktop import files. How do we build up the final config for a flight
and make sure everything is current?"

This of course again led into the discussion of: "Since the import
file never overwrites parameters in the PD table, how do we get
updated equations/parameter definitions into the config?"

We want to try to tackle this problem for the next release (or at
least a good initial solution), so I wondered if everyone from the
different sites would chime in and tell us how they're handling this
currently.... Also, if you want to suggest solutions to the problem,
be my guest ;)

Things that were brought up during in past discussions:

1) When there's a conflict, notify the user that's importing the
desktop... Let them know what the changes/diffs are so they can make a
determination of which version should "win". Allow them to "rollback"
the import if they're not sure what to do (and have to inquire).

2) If we can establish a sense of "ownership" within the parameters,
we could apply this rule: "If I own the parameter, my version wins
(perhaps without question)". One way of establishing ownership is: "If
that parameter only exists on my desktop, then I own it". That might
be too simplistic, we might have to tag the ownership on creation
(i.e. permissions, etc)

3) There seems to be a set of parameters that are "cast in stone" or
controlled through the data preparation process. After import of all
the user's desktop, these parameters are overwritten with the
"approved" versions.

4) What about other "global" definitions like the Envelopes table,
Predefined comments, etc.

Thanx everyone for any input you can supply ;)
Jim

[Watzlavick, Robert L]

Here's how we we're doing it here in Fort Worth:

We always require the IPTs to tell us what they changed when they send
us an .iadsDt or .iadsAw file. If the email doesn't include that
information, we have to track them down which can be a real pain at the
last minute. The IPTs that have lots of deriveds and change them
frequently will usually send us a complete replacement set so after we
import, we go into the PD table, sort by ParamSubGroup, whack their
existing ones, then import the CSV with the new set.

Other times, we won't have as good of information on what changed or
there are a bunch of individual parameters that have changed, too many
to handle one at a time. We wrote a short Perl script that will go into
an .iadsDt or .iadsAw file and change the "updat3" to "update" for all
user deriveds that match a certain ParamSubGroup. That way, there's no
risk of messing up somebody else's deriveds they may be using. Of
course, this method is potentially brittle since it involves
manipulating the import files and that isn't necessarily a published
format. Note that this method also changes all of the deriveds for a
particular IPT so it's up to them to make sure the set is current. We
haven't had any problems so far.

In the case where the user has added derived parameters, the import
brings them in correctly so there's no issue there.

Some have suggested to us that we need to maintain config control over
each individual derived parameter but I don't believe that's practical.
We currently have about 2200 user deriveds that the IPTs maintain and
when we get 15 different screen updates the day before the test, I'm not
real interested in handling 100-200 individual deriveds that may have
changed at the last minute.

So, I'm reasonably comfortable with our existing process but I'd really
like to see Iads handle the case of conflicting deriveds. I could
envision it popping up a dialog/table that lists all the conflicts and
allow the user to select which ones to update. For it to be useful, you
would need the ability to sort by various columns - sort of like the PD
table but not editable.

As far as the set of official parameters maintained by Test Data
Processing, after we're done with all the screen imports, we will whack
all those and reimport them from the official set. Technically we
shouldn't have to do this but we've found it makes it easier to figure
out when the IPTs have old parameters in their screens because they show
up as Recovered instead of real parameters.

For things like DataGroups and Envelopes, we have a mix of stuff from
the IPTs and Test Data Processing. The IPTs that have entries in those
tables will just send us replacement CSV files containing the set they
want to replace.

For support files like images, ICAW files, etc., we store those in a
shared folder in the control room with subdirectories for each IPT.
Someday, we'll bite the bullet and go with the ZBall but for now, we're
maintaining those paths by hand. It's easy to tell when an ICAW file is
missing but we can't always tell when an image is missing. However, we
tell the IPTs they need to check the paths for images and ICAW files
next time they're in the control room.

So that's pretty much it - a fair amount of hand steps but it's been
very reliable. For the "next" test, we have an "Updates" folder where
all the inputs go for each group (.iadsAw, .iadsDt, images/bitmaps, ICAW
files, etc.) and when we get ready to build the final config, we just go
in order. We also create a readme.txt file that lists the steps we do
for each IPT so we can repeat the process if something goes wrong.

-Bob

[Scott B.]

Another good practice is to have each group use a unique prefix (such
as "fq_" or "ad_") for derived parameters. This facilitates the
'complete replacement' of the derived parameter list by group that Bob
mentions above without each group stepping on each other.

[Jim Bretz]

> Here's how we we're doing it here in Fort Worth:

Wow.. Thanx Bob... That's a hell of a response ;)

Jim

[Jim Bretz]

Scott,

Ya... Good idea... There's the "ownership" theme again ;)

Bob/Scott, what happens within the group? How do you prevent stepping
on each other within your own group?
Jim

[Watzlavick, Robert L]

We don't really police that. We assume that the engineers within an IPT
are talking to each other. Usually, only one or two people are editing
deriveds on a regular basis so it's not a problem.

-Bob

-----Original Message-----
From: ia...@googlegroups.com [mailto:ia...@googlegroups.com] On Behalf Of
Jim Bretz
Sent: Wednesday, November 14, 2007 5:12 PM
To: IADS
Subject: [IADS] Re: Question for all: How are you building up your final
config file?