Post Test Data Server vs. Local Mode Client
Eileen Suszek
Server and running a Local Mode Client? Also, when would I use one
feature over another?
James Bretz
> Server and running a Local Mode Client? Also, when would I use one
> feature over another?
First let me define the two methods. Both are techniques for replaying or
accessing data that's already been saved to archive files while using the
Iads client... so this is really a "what's the best way to play back and
analyze Iads data in post test" question.
Now, let me give you the answer in a "nutshell" -> For 99% of the FTEs
analyzing post test data on their own at their desk, use the Local Mode
Client. It's the quickest most direct way to access the data.
Ok, now let me back up to the larger picture.
Basically, the Post Test Data Server (PTDS) is a completely separate
application that you run in order to "simulate" a data server (i.e. simulate
the CDS). Once you load up an archive, you can then run the client and
"connect" to that server to get your data. On the other hand, "Local Mode
Client" is simply the display software (Iads.exe) accessing the files
directly, without a PTDS. At first glance, you might wonder why there are
multiple methods for playing back post test data. I understand it's a little
confusing, so let me try to explain.
Up until around version 3.4 (2002), the Post Test Data (PTDS) server was the
only way to replay data in a client for PostTest. Although "Local Mode" was
available, not very many engineers knew of it.... or they were reluctant to
change their methods....understandable. Well, for those engineers and for
the "newbie" out there, let me try to break down the differences:
*PTDS*
Advantages:
1) As well as serving data, it also performs a number of functions that
you'd want in a data server as in config file creation, importing data,
creating compressed archives, etc. This is probably it's number one
advantage, but that will eventually go away as more functions are moved to
the client (Iads.exe).
2) Allows you to orchestrate the interaction of multiple users. If a number
of people are connected to the same PTDS server, you could in essence
simulate a mission (for training purposes) by playing back the data in an
orchestrated manner. This technique has been used in many locations,
including test pilot schools, etc. Connecting multiple people also muxes
config changes into a single config file (good for next day mission prep).
3) Allows you to serve a large number of users from the same data set in a
more "network efficient" and possibly secure manner than simply accessing
the files across Network Neighborhood (depending on network speed and
security issues of course). Sometimes network neighborhood access is
restricted, but connection to a server is not.
4) Allows you to acquire (yes, I did say acquire) live data from a number of
data sources. These sources include MGC from HBM, select cards from
LabViews, Acra's KAM-500, and other misc "custom" built plugin applications.
Yes, the PTDS can be a mini-CDS, but of course it's scope and capabilities
are highly limited.
Disadvantages:
1) It's another application that you must run first *before* the client in
order to play back data. This is confusing.
2) It's possible to launch the PTDS many times on the same data set. During
client startup and log in, it's very difficult to ascertain which PTDS to
choose. This has caused headaches in the past (and probably still is now).
3) Every time a user launches a PTDS, the other clients on the network can
see this PTDS in their client log-on list. If everyone on the network used
this technique, you could imagine the list of available servers would get
painfully long... confusing.
4) For the everyday user, the whole process to view data is now slower.
First they have to start the PTDS, choose the archive, then wait for it the
config file to load and validate. At this point, they have to run the
client, wait for the list of available servers (this takes time) and then
choose the server. After the server is chosen, it has to "connect" and the
whole entire config file is then "transferred" to the user's temp directory
(takes time). Finally, the client can load the config file (takes time) and
start. For the config file sizes that exceeding 100MB, this is even more of
a pain.
*Local Mode*
Advantages:
1) Simple. When the client starts, it asks you for the config file location.
After the config file is chosen, it loads and starts the desktop. The lower
amount of steps, the less probabilty that something will go wrong. This is
truely the "method of choice" for everyday use.
2) Quick. The config file is only handled once, thus the loading time is
reduced. If the data is on the local machine, this is truely the fastest
method of access.
Disadvantages:
1) Missing features such as "data import", compressed archive creation, etc
as mentioned above.
2) Can't perform "collaboration" with multiple users.
I'm sure there's more points to either side of the argument, but I'll just
cut it short there (need to get back to work). IMHO, use the "Local Mode"
client unless you need something it doesn't have ;)
Jim
Pat
discussion, but perhaps not clear.
5) Allows LAN access without a shared drive being available. If the
two machines can make a socket connect, basically an IT issues, then
the Client can connect to PTDS and receive data. For the Local mode
Client to run in this environment, a shared drive would need to be
available, a "Z" drive if you will. If this is not desirable then
the PTDS is the way to go..
Adam Chant
Surprisingly enough we have built our testing group around this feature of the
PTDS. Everything from production checkout to ground testing uses this technique
of recording and display. If your test only requires a single MGCplus or KAM-500
then this is an efficient way to go about it.
Compared to the software offered by HBM, IADS is much easier to set-up and get
running out of the box. Once up and running, you can still play around with the
displays and not worry about lagging the recording process.(Not the case with
Catman) Beyond the basics IADS offers much more than even the latest version of
HBM's Catman software.
It goes without saying that IADS is the best software solution for the KAM-500
being that it's now the software offered by ACRA.
I would say that if you can deal with millisecond delay of the data being
displayed then this technique is an excellent way to do testing or even vehicle
check-out testing before going to a telemetered solution.
Having one software solution producing 1 data storage file type for all of our
acquisition hardware types saves us a lot of time and money.
-Adam Chant
James Bretz
> Jim! I thought that was our little secret! LOL
Ya, sorry. I had to put that on the list ;)
> It goes without saying that IADS is the best software solution for the
> KAM-500
> being that it's now the software offered by ACRA.
I hope so.... and soon we'll be the "OEM" display software for ACRA. Let's
hope we can live up to expectations.
I though of another "disadvantage" for Local Mode:
3) Saving sometimes takes a little longer. When the config file is very
large you can really notice the difference. This is because the client is
"blocked" until the entire config file is written to the disk. We'll address
this issue soon, though.
Jim
James Bretz
>two machines can make a socket connect, basically an IT issues, then
>the Client can connect to PTDS and receive data. For the Local mode
>Client to run in this environment, a shared drive would need to be
>available, a "Z" drive if you will. If this is not desirable then
>the PTDS is the way to go..
Yep, another good point. It gives the IT people a little bit more
flexibility.
Jim