IADS Configuration Control

[Dan]

How are other people handling configuration control of IADS?  Ultimately, what I would like to accomplish is to be able to prevent users from making changes to a set of derived parameters in the ParameterDefaults table.  Say, we have a set of N paramters that have been signed off by the group as "official" and I don't want anyone to intentionally or unintentionally make changes to them.  I've searched the group and learned about the /private and /noSaveSilent options but they only prevent saving of the changes back to the server.  It doesn't prevent a user from making changes to the configuration and using those changes during a flight (for their local workstation).  Based on what I know right now, I think the answer is to implement a system to check the "controlled" parameters in the IADS configuration file against an "official" copy prior to launching the CDS and also advertise to users not to change the parameters.  Now that I think about it, I suppose that the "controlled" parameters could be added to the telemetry frontend as derived parameters so they couldn't be tampered with in IADS.  Are there features in IADS that might help with this that I'm not aware of?  Has anyone else attempted something like this and how did you accomplish it?

Thanks for the help,

Dan

[Watzlavick, Robert L]

We use groups to distinguish the “official” deriveds from the user deriveds.  Whenever we rebuild the project (every day or two), we delete and reimport the official set.  I’m not sure you would want to prevent someone from doing it during a mission as there might be a valid reason to perform an on-the-spot fix.  I suppose during the mission you could always create a new derived with the fix but then everybody would have to re-drop the control onto their screens. 

 

Some of the test sites don’t roll the ending config forward for the start of the next mission.  In that case, you always start the mission with a known configuration which would include replacing the official derived set with the master copy.

 

Moving them into the front end is an option but that is less portable and there are probably dependencies on other derived parameters that would cause to have to put the whole set there.

 

-Bob

--
You received this message because you are subscribed to the Google Groups "IADS" group.
To view this discussion on the web visit https://groups.google.com/d/msg/iads/-/NyPTGWXv3MQJ.
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.

[James Bretz]

If I remember correctly, the ability to prevent someone from changing a
given parameter in the PD is a requirement for an upcoming release.... but
I'm with Bob. Preventing a user from editing an equation is a slippery
slope, especially if they have a valid reason to do so.

The control room is a pretty dynamic environment, and you need flexibility
to react to changes or correct previously missed mistakes.... but on the
other hand, you could be introducing problems into an otherwise correct
configuration. We believe this flexibility as well as responsibility should
rest squarely on the FTEs shoulders.

In the end, it all boils down to training and coordination amongst the FTEs
with the discipline leads and test conductor.... but if that can't be
accomplished then there is help on the way ;)

Jim

--------------------------------------------------
From: "Watzlavick, Robert L" <robert.l....@lmco.com>
Sent: Tuesday, February 07, 2012 11:03 AM
To: <ia...@googlegroups.com>
Subject: RE: EXTERNAL: [IADS] IADS Configuration Control

> ia...@googlegroups.com<mailto:ia...@googlegroups.com>.

> To unsubscribe from this group, send email to

> iads+uns...@googlegroups.com<mailto:iads+uns...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/iads?hl=en.
>

> --
> You received this message because you are subscribed to the Google Groups
> "IADS" group.

[Dan]

Thank you for the replies.  I agree that that the responsibility should fall on the FTE to maintain the configuration.  We should be able to accomplish what we want with training and a process to check the config for changes.  I think what Bob suggested about using specific groups for the "official" parameters to find those parameters quickly sounds like a good idea.  Thanks again!

Dan

[Eileen Suszek]

Individual or program circumstances can determine the control of the
configuration file.  These are some real life examples of different
configuration management styles:

The program has determined that the test engineer is responsible for
development/changes of the configuration file.  In this case the
configuration file will have two version, the pre and post (the post
version is included with the post test data, the pre is the last
configuration file used for this program).  Each engineer is
responsible for their own changes and those changes make the config
file a living file, going from test to test to test.

The program has multiple test vehicles under test simultaneously.
 Each test vehicle can have its own set of configuration files (two
for each mission, pre/post).

The program is responsible for all changes.  Program managers (not the
engineer) approve changes to the configuration file.  Either a base
line configuration file can be used each time for a test and any
changes are approved at the program level (not the engineer level).
 This way no matter what changes are made in the control room during a
test, tomorrow we start fresh with our baseline config file. We have
seen circumstances where the engineers are not allowed to make changes
in real-time.

Changes have been deemed unacceptable by a Senior Engineer or the
Program Manger.  A backup (the previous version) can be immediately
accessed for the mission.

The Engineer has several custom configurations they would like to use
to run the data.  In this scenario the real-time log information is
not important (such as events and thresholds), but more the display
setup.

[Dan]

Thanks for the input, Eileen.  One question: when you say "We have seen circumstances where the engineers are not allowed to make changes in real-time.", how is this enforced?  With a policy and/or rule?  Even if I start all the clients with the /private or /noSaveSilent option, they can still make changes to equations, limits, etc and monitor a flight with those changes.  All I can do is prevent them from saving those back to the configuration on the server.  Correct?

Dan