\section{Integrated CAD/NAST environment}\vspace{1ex}%\noindent
Before  now,  acronym ``NAST''  was understood as ``numerical
analysis and simulation tools''. From now on, we prefer to
interpret this general term in another (a more specific) sense:
``navigation aids simulation tools''. Thanks to this unified
acronym, we emphasize that we deal with a specific application but
continue to keep in mind that navigation aids simulation tools are
strongly based on the numerical analysis and methods described in
the above cited literature.

Having  analyzed many organizational/functional architecture
solutions  existing in different CE environments, we fixed upon
one of them (mentioned in Section~1) -- instead of inviting one
more schema. In so doing, we advocate the invented form and put
focus on filling this form with a new functionality content. Such
approach is equivalent to shortening the lead time and cost of
developing a new intelligent integrated CAD/NAST environment for
navigation aids CE.

The  integrated CAD/NAST system  architecture is shown in
Figure~1, which is largely self-explaining. The system is intended
to operate in a ``developer-oriented mode,'' that is, the user is
assumed to be a design developer of a Combined Navigational System
(CNS) described in Section~2.  The system supports the Concept
Design phase (Table~1) and consists of a Concept Modeler,
Numerical Analysis and Simulation packages  (in this application,
a collection of domain-specific numerical methods and algorithms
pertaining to estimation theory), and necessary system shell along
with intelligent interface modules and knowledge-base units. The
decision-making mechanism of the system is based on the concept of
concurrent consulting with several expert teams or -- as an
advanced solution, with the in-built algorithm expert systems for
any design modification in assisting the designer.

As  indicated in the picture, the user first interacts with a
conceptual design unit (CDU) in order to specify the initial
design requirements. The CDU contains the domain-specific overall
design data base and a design instance library (previous design
models). This information is concurrently controlled by the key
experts: assembly expert, cost and analysis expert, and
manufacturing expert. By this interaction, the designer forms a
pool of reference truth models to be tested (see Item~1 of Step~3,
Section~2), into a certain shape. The CDU helps capture the design
intent in the form of necessary mathematical description of
reference models. As is customary, the object-oriented programming
(OOP) is used in this system as a means to represent models and
specify all their attribute information in the form of so called
``objects.''

The pool  of ``truth'' models created by the CDU and User needs to
be analyzed and refined as per the desired design specifications.
The main tool for this is a ``design simulation unit'' (DSU) aided
by several knowledge-base units. To start the process, the DSU
selects the initial ``truth'' model from the pool and makes it the
current model for analysis. For this model, a set of simplified
design models is created as described in Item~\textsl{3},
Section~2, and a simulation program is generated. Once the program
generation is complete for the current ``truth'' model, the
simulation conditions are specified with attention of the User,
and the simulation program runs.

The next  important stage involves the visualization and
interpretation of the  simulation results. It needs an expert
system for analyzing the results and assisting the designer
through an intelligent interface. Such interface is needed because
the results from any simulation program run consist of a huge
amount of information which is difficult to unravel. The
information so ``filtered'' is accepted and diagnosed by the
``evaluation and modification'' module aided by an algorithm
knowledge. This module makes decisions regarding the necessity of
any modification of simulation conditions, or of simulation
program refinement, or of the current model adjustment, or even of
considering another ``truth'' model from the selected pool and
repeating the whole cycle of simulated design. In this way, the
presented structure embodies the recursive dynamics and iterated
mappings of the combined navigation system design process.
