A Product Life Cycle Information Management System Infrastructure with
CAD/CAE/CAM, Task Automation, and Intelligent Support Capabilities[^1]

Harold P. Frisch

NASA/Goddard Space Flight Center, Greenbelt, MD 20771, USA

**Abstract.** NASA is not unique in its quest for a product development
cycle that is better, faster, and cheaper. Major advances in technical
information management will be required to achieve significant and
obvious process improvement goals. A vision of order for the associated
systems of unstructured and unconnected files and databases is the first
step towards organization. This is provided by examining the basic
nature of technical information, item relationships, change and
knowledge processing demands to be placed on any management system that
supports all aspects of data representation and exchange during the
product\'s full propose, design, develop and deploy life cycle. An
infrastructure that partitions product technical information relative to
the perspectives of creation time phase, type and the cause of change
provides sufficient structure. This enables maximal use of existing
CAD/CAE/CAM/... software tool systems and digital library data mining
capabilities. Introducing the concept of packaging technical information
in a machine interpretable manner, at key life cycle deliverable and
product review milestone points, provides the fastener needed for the
attachment of the relevant soft computing and intelligent support
capabilities discussed at the NATO Advanced Study Institute on Soft
Computing and reported elsewhere within this volume. It also provides
the basis upon which task automation capabilities can evolve.

# Partitioning Technical Information

Technical information evolves in 3 stages:

-   Computation with metaphors: This is the product creation process.
    Within an organization it takes place within the domain of social
    communication. In reference \[1\] evidence is presented to suggest
    that both communication and understanding in a social environment is
    carried out via metaphors. If these arguments are accepted it
    follows that the project creation process is effectively a
    metaphorical feedback process that stabilizes around a fuzzy, word,
    definition of the product.

-   Computation with words: This is rarely done, in a strict
    mathematical sense. However, it is argued within the conclusions of
    Zadeh\'s 1996 paper, reference \[9\], that "computing with words is
    likely to emerge as a major field in its own right. ...there is much
    to be gained by exploiting the tolerance for imprecision." To
    compute with words, selected design parameters are assigned
    linguistic rather than numeric measures. These fuzzy word
    descriptors form the natural connective linkage between metaphoric
    and numeric product data representations. Computing with words
    within this interface domain enables imprecision and the tolerance
    for imprecision to be exploited. The associated first order
    sensitivity and design trade-off studies accomplished with fuzzy
    words provides deep design insight and has the potential of
    providing early design value checks.

-   Computation with numbers: This spans the complete, business as
    usual, womb-to-tomb spectrum of CA*x*[^2] software tool
    capabilities.

A vision of order within the complexity of a universe of discourse is
the essential first step toward the development of an infrastructure.
The most natural approach to ordering life cycle technical information
is to partition it relative to the perspectives of time and type.

-   Reference \[5\] details the NASA spacecraft system engineering
    process. By placing this work in a more generic setting, it is
    reasonable to suggest that a product\'s life cycle can be
    partitioned into 4 time phases:

1.  Propose the product: Develop a product proposal which maximizes the
    ability to satisfy a set of broadly stated mission goals while
    minimizing life cycle system costs.

2.  Design the product: Define product\'s mission, its operational
    support system, establish and refine a baseline design,

3.  Develop the product: Establish final design, fabricate subsystems,
    integrate them into the system, test, validate, verify and establish
    mission support infrastructure.

4.  Deploy the product: Prepare and deploy the product, verify its
    operation, carry out mission objectives and dispose of product at
    mission end of life.

-   Technical information may be partitioned into 4 type categories:

1.  Unstructured collections of reports. These may be formal or
    informal. They are essentially text but contain a generous mix of
    graphics, tables, figures and equations.

2.  Drawings and schematics from many CAD software systems.

3.  Input/output data files from many CAE and CAM software system.

4.  Technical data packages: These are focused collections of structured
    technical information. For example:

-   Specifications & requirements for product and subsystems,

-   Plans & procedures for product and subsystems,

-   Baseline system & subsystem descriptions,

-   System \\& subsystem reviews,

-   Test plans, procedures and results,

-   Subsystem interface integration standards,

-   Interface control documents,

-   Subsystem function modeling reports.

    Unstructured reports are best collected within digital libraries
    which have extensive data mining capability, see reference \[4\]
    These enable complex queries to be launched with query results
    returned to the user as images of the identified pages on their
    desktop computer screen. Cut and paste tools enable timely
    information reuse, without transcription error. Query tools which
    simply do key word searches and return a list of reports that
    contain the key words are totally inadequate; this is not data
    mining.

    CA*x* drawings, schematics, and input/output data files come from
    many different software systems. These systems usually provide an
    extensive range of options for viewing and databasing. Furthermore,
    user groups usually have a full range of legacy and proprietary post
    processing, viewing, databasing and data reformating tools for
    moving detailed modeling data between major CA*x* software
    systems[^3]^,^[^4] Supporting the full range of associated data
    representation and exchange problems are several STEP[^5] standard
    projects in America, Europe and
    Asia[^6]^,^[^7]^,^[^8]^,^[^9]^,^[^10] .

The author strongly supports these efforts to enhance data communication
between software systems, at the detailed modeling level. However, it is
the author\'s opinion that managing the contents of technical data
packages, with their formally defined views of system, subsystem,
interface and function is the true door to major life cycle cost saving
potential. Task automation, software reuse, shortening and focusing
review meetings, corporate knowledge capture, infusion and reuse are all
possible with today\'s state of the art in computational science and
soft computing[^11]^,^[^12].

## Accommodating Information Relationships

Technical information accumulated over a product\'s life cycle can be
viewed as an aggregation of information items linked together through a
complex network of soft, fuzzy and crisp relationships.

The organizational group with the best knowledge of these relationships,
the ability to avoid their rediscovery, to innovatively use them for
system analysis and process automation will successfully meet the
significant and obvious process improvement goals of "better, faster,
cheaper."

It is easy to get lost within the microscopic views of subsystems and
the details of their associated theory, modeling data and computational
support systems. It is therefore important to view relationships from
the macroscopic perspective that is captured within the technical data
packages associated with reviews and summary reports.

Relationships between items of information within and across technical
data packages can be categorized as:

-   First principle relations. These are dictated by the product\'s
    configuration and the laws of nature. These cannot be violated under
    any circumstances. These range from trivial; e.g., product mass
    shall be a positive real number, to exceedingly complex dynamic
    cross coupling relations within a multidisciplinary system model.

-   Standards. These are dictated by international, national and
    corporate standards setting organizations. They are crisp and their
    violation normally requires detail support analysis and an extensive
    approval cycle.

-   Best practices, corporate knowledge and lessons learned. These
    relationships are inherently fuzzy. The machine interpretable
    representation of this knowledge and its utilization requires the
    instantiation of knowledge expressions with linguistic measures and
    evaluation via computation with words, see reference \[9\].

-   Design tradeoffs. These attempt to minimize cost while maximizing
    performance. They are a mix of crisp, fuzzy, probabilistic, random,
    etc. relationships that are difficult to define and computationally
    evaluate.

## Accommodating Information Change

Product technical information is dynamic. Fundamental to its life cycle
accumulation is "change". If knowledge is to be linked with information
then change too must be categorized. This can be done relative to the
perspective of its "cause". The following 4 causes of change are
considered:

-   Evolutionary change: This is associated with the normal course of
    events during the product\'s propose, design, develop and deploy
    life cycle process. Evolutionary changes are discontinuous and
    distributed across the system. Normally these are collected at
    irregular time intervals and released as a configuration data
    update. The update is effectively time tagged by version number.
    Versioning tracks change while allowing users to have a fixed
    baseline reference model over programmatically convenient time
    periods. To support the "version release" process, an intelligent
    support system can be used to check for relationship violations
    between design parameters.

-   Design change: This is introduced to improve product performance or
    to solve a problem uncovered during design analysis, testing or
    operation. There are lessons learned, design change rationale and
    other items of information important to manage for future reference
    and reuse.

-   Dependency change: Design parameter dependencies transition from a
    state of softness, during initial trade studies, to a state of
    crispness as the life cycle matures. If one attempts to model this
    change as a continuous process one loses the ability to associate
    dependency change with an associated life cycle time phase and
    technical data package contents.

    Dependency within and across data packages evolves as follows:

1.  Design parameters start from a single point expert\'s best estimate
    and end as the output of a complex sequence of computational,
    logical and fuzzy reasoning procedures. From this perspective,
    definitions of design parameter attributes remain fixed but their
    instantiation source changes.

2.  Attempts to minimize cost while maximizing function involve a
    complex intertwined mix of physics, mission viability and
    performance tradeoff considerations. From this perspective, design
    parameter dependencies transition from a mix of soft and crisp
    dependencies during product proposal preparation and design, to a
    set of crisp dependencies during product development and deployment.

-   Knowledge change: Design rules, best practices, corporate knowledge
    and other items of knowledge base type information are usually
    linked to phases in the life cycle process. As the process matures
    higher fidelity knowledge constructs become relevant and must be
    introduced into the intelligent support system. Once articulated in
    clear text and translated into a machine readable format
    computational intelligence can be used to initiate the actions which
    provide intelligent support. This is not an easy task, since
    knowledge is usually derived from an expert. While the expert
    instinctively provides accurate and timely evaluations via mental
    computation with metaphors; they find that the articulation of these
    metaphors into fuzzy words, relations, constraints and numerics is
    extremely difficult.

## Using STEP To Model Information

The ability to model information in a machine parsable format provides
the fastener necessary to attach intelligent support and a variety of
soft computing capabilities to a technical information management
system. The EXPRESS information modeling language provides the bridge
between the clear text representation of information and its machine
interpretable representation. The EXPRESS language is an international
standard and it is a Part of the ISO 10303 STEP standards for Product
Data Representation and Exchange[^13]

It is assumed that a clear text definition of information to be
collected within technical data packages can be developed. If this can
be obtained then the associated information can be modeled via EXPRESS
and presented as a "technical data package" in a STEP compatible
manner[^14]. The technical information component associated with change
can also be presented in a STEP compatible manner[^15].

The most difficult aspect of the technical data packaging problem is to
develop a textural definition which is clear, unambiguous, complete and
nonredundant. Unaided, this is a near impossible task. The language
EXPRESS was specifically designed to aid this task. Once information is
translated from a clear text definition into the machine readable
language EXPRESS, the EXPRESS source code is compiled. The compiler
returns an error list of ambiguities, incompleteness and redundancies.
This list is then used to both adjust the textural definition and the
EXPRESS source code. This feedback process implies that clear text
development and its EXPRESS translation is an interactive process.

# Information Modeling

The ISO 10303 STEP standards provide the enabling technology needed for
product data representation and exchange. While IGES, the Initial
Graphics Exchange Specification, was developed with the direct need for
human intervention to assure correct translations, STEP is being
developed to be machine to machine processable with no human
intervention. See references \[3\] and \[6\].

STEP provides a representation of product information along with the
necessary mechanisms and definitions to enable product data to be
exchanged among different computer systems and environments associated
with the complete product life cycle process.

STEP uses the formal information modeling language EXPRESS to specify
product information in a computer readable manner. This formal language
enables precision and consistency of representation and facilitates the
development of applications. STEP also uses application protocols (APs)
to represent generic classes of information relevant to broad
application areas.

The overall objective of STEP is to provide a mechanism that is capable
of describing product data throughout the life cycle, independent from
any particular system. The nature of this description makes it suitable
not only for neutral file exchange, but also as a basis for implementing
and sharing product data bases and archiving. The ultimate goal is an
integrated product information database that is accessible and useful to
all the resources necessary to support a product over its life cycle.

## EXPRESS -- Language for Information Modeling

The language EXPRESS (ISO 10303 Part 11) is the international standard
language for information modeling. EXPRESS is a data-specification
language as defined in ISO 10303 Part 1: Overview and Fundamental
Principles. It consists of language elements which allow an
unambiguous-object definition and specification of constraints on the
objects defined[^16]. Reference \[7\] provides an excellent introduction
to the language with illustrative examples.

Within this language the *schema* contains the information model
relative to a focused universe of discourse. The *entity* defines some
atomic level of information associated with the product within the
universe of discourse and *attributes* provide the properties of the
entity relative to all relevant product views. Context, rules,
relationships, functions and constraints between entities and their
attributes can be defined within and across schemas.

The following is an example of information modeling with EXPRESS:

> SCHEMA car_trace;
>
> ENTITY history;
>
> item : car;
>
> transfers : LIST \[0:?\] OF transfer;
>
> END_ENTITY;
>
> ENTITY transfer;
>
> item : car;
>
> prior : owner;
>
> new : owner;
>
> on : date;
>
> INVERSE
>
> must_be_in_history : history FOR transfers;
>
> END_ENTITY;
>
> ENTITY car;
>
> model_type : car_model
>
> made_by : manufacture;
>
> mnfg_no : STRING;
>
> registration_no : STRING;
>
> production_year : date;
>
> UNIQUE
>
> joint : made_by, mfg_no;
>
> single : registration_no;
>
> END_ENTITY;
>
> ENTITY car_model;
>
> name : STRING;
>
> made_by : manufacture;
>
> consumption : REAL;
>
> END_ENTITY;
>
> ENTITY date;
>
> day : INTEGER;
>
> month : INTEGER;
>
> year : INTEGER;
>
> WHERE
>
> days_ok :
>
> {1 \<= day \<= 31};
>
> months_ok :
>
> {1 \<= month \<= 12};
>
> year_ok :
>
> year \> 0;
>
> date_ok :
>
> valid_date(SELF);
>
> END_SCHEMA;

The above example illustrates the definition of entities, attributes and
associated constraints. It is part of a model for the process of
tracking automobile registration. The *entity* **history** provides the
arbitrary length transfer *list*. The *entity* **transfer** defines
exactly what information is recorded with each change of ownership. The
*entity* **car_model** defines car model information. The *entity*
**car** defines exactly what information is recorded for each car.
Within the *entity* **car** two uniqueness constraints must be
satisfied, registration numbers must be unique and manufacture number
per manufacturer must be unique. The *entity* **date** has constraints
on day, month, year integer value and also uses the function
*valid_date* (not shown) to check for proper day-month relations and
leap years.

Hopefully this short example provides sufficient inference material for
the reader to develop the suspicion that the language might have
sufficient information modeling capability to form a bridge between a
clear text definition of technical information and a machine readable
translation, that is also human readable.

## Technical Data Packages

One method for collecting information is to design technical data
collection packages that support the life cycle need to gather, review
and distribute design information in a timely manner. A process
enhancement approach is to design the packages to compliment established
documentation delivery requirements and product reviews. The packaged
data provides a particular view of product information at a particular
time point in the life cycle process. ISO 10303 AP 232 -- "Technical
Data Packaging Core Information and Exchange" provides the structure to
package and relate groups of product information so that configuration
controlled exchanges can be achieved. This Application Protocol provides
an information structure that meets the requirements for collecting,
organizing and managing the exchange of a complex set of data files and
databases associated with the technical information being packaged.

## Life Cycle Change Management

Product life cycle *information* management includes the exchange of
product data relative to the identification of a problem and its causes.
Product life cycle *change* management includes the identification of
the reason for change, its cause, the approval and performance of the
resulting changes to the product, and the authorization of corrective
actions to prevent reoccurrence of the anomaly. ISO 10303 AP 208 --
"Life Cycle Management -- Change Process" provides the structure
necessary to support the management of change with the product and its
subsystems.

# Baseline Spacecraft System Definition

Section 1 provides a list of focused information collections that could
be transformed into STEP compatible technical data packages. For any
organization with a well-established product line significantly large
segments of the focused information collections are repeated with each
new product. These repeated segments can be expressed in such a manner
that the information template will satisfy the data recording needs of
all products within the product line.

The output of the NASA spacecraft proposal development phase provides an
illustrative example. The deliverable is a definition of the baseline
system. It is a well structured collection of information developed by
expert teams representing the subsystem design and development groups
shown in Fig. 1. Relative to the needs of the systems engineer this view
of the baseline system is complete and unambiguous. To support this
proposal development process various NASA groups are developing highly
advanced software support systems[^17]^,^[^18]^,^[^19].

Fig. 1. System's engineering view of NASA spacecraft subsystems

Irrespective of proposal development approach the resultant baseline
system is effectively defined by a template of information, the items of
which are referred to as design parameters. During the proposal
development stage this template is instantiated with the best estimates
that the expert teams and intelligent support aids can provide. Once
this phase ends the best estimates are refined by detailed work carried
out within subsystem design and development groups.

Baseline subsystems can also be defined by templates of information and
technical data packages developed for them.

From a technical information management perspective it is important to
note where the information comes and came from and how it was developed.
The system must be able to both identify the initial creator team and
all appropriate links and pointers to instantiation procedures.

Relative to STEP, within the baseline system template, each system
design parameter and all associated elements of information become
EXPRESS entities. Each entity has an associated list of attributes.
These support the viewing needs of the different design and development
groups. As will be shown, additional attributes can be added to support
knowledge infusion

The language EXPRESS defines the information elements of the template
while ISO 10303 AP 232 -- "Technical Data Packaging Core Information and
Exchange" provides the additional structure needed to track the
information creation trail. Who did what, when, why, what were the
results and who approved it?

As the volume of product technical information accumulates the desire to
infuse knowledge and intelligence into the process becomes a necessity.
Database maintenance becomes a more and more difficult process. Data
redundancy, ambiguity and completeness are critical uses requiring
intelligent support aids. Furthermore, if the product is complex,
intelligent aids are desired to support cross department and cross
disciplinary design checking.

## Capturing Intelligence

Intelligence is the capacity to acquire and apply knowledge. During one
of Zadeh\'s NATO/ASI lectures it was suggested that the subject domain
of artificial intelligence is based upon hard computing. That is,
quantitative, precise and formal computation with numbers. It was also
suggested that the subject domain of computational intelligence is based
upon soft computing. That is,qualitative, imprecise and informal
computation with words. Both subjects areas are based upon the
assumption that acquired knowledge can be presented in some machine
readable format.

The author proposes to take one step further into the domain were
acquired knowledge is not machine readable. In this domain knowledge is
in the format of metaphors stored in the minds of product experts. It is
suggest that creative intelligence is based upon computation with
metaphors.

This concept aids in understanding the process and difficulties
associated with acquiring knowledge from experts. The concept implies
that an intelligent support capability must first translate the
metaphors of experts into machine readable constructs of hard
computation numbers and soft computation words. It is not difficult to
be convinced that this is very difficult. One can also be convinced
that, for the foreseeable future, *the creation process will remain in
the minds of the experts*; while*, what is mundane to the expert can be
automated*.

The latter has been proven many times over by the CA*x* software
development

community.

The key to process automation is to make provision for the machine
readable acquisition of all knowledge needed to make tasks within the
product life cycle process "mundane". If the task is mundane to the
expert and if all information needed for its automation is databased;
then, it can be entered into the "task to be automated" queue.

## Knowledge Representation

The dictionary definition of knowledge[^20] goes well beyond what
today\'s technology can hope to represent in a machine readable format.
This contribution bounds "knowledge representation" by the tools and
capabilities available for its instantiation within an information
management system.

To illustrate a method for infusing knowledge into such a system,
consider the need to provide linguistic descriptors to the entity
**car**, defined in Section 2.1, and label them *car_body_condition*,
*car_engine_condition* and *car_classification*. The attributes
*car_body_condition* and *car_engine_condition* are subjective
linguistic measures provided by an inspector. The attribute
*car_classification* is another linguistic measure. It may be provided
directly by an appraiser using the estimates of the inspector or it may
be computationally inferred from the inspector\'s estimates in
combination with other available information such as car model, age,
manufacturer, owner history, etc. Within the insurance industry this is
the claims adjustment process.

The ability to automate the instantiation of the attribute
*car_classification* requires an ability to reason in the face of
uncertain information. This capability is based upon the use of fuzzy
sets, possibility theory and approximate reasoning as outlined in
references \[2\] and \[8\]. It requires an ability to aggregate fuzzy
subsets and to use fuzzy sets to constraint variables.

The knowledge representation problem reduces to the need to supply all
information needed for the operations of fuzzy set aggregation and for
the statement of propositions. The following definitions for fuzzy sets
and propositions are used.

-   Assume X is a set serving as the universe of discourse. A **fuzzy
    subset** A of X is associated with a characteristic function $m_{A}$
    such that

$m_{A}:C \rightarrow \lbrack 0,1\rbrack$ (1)

In the framework of fuzzy set theory the characteristic function is
generally called the **membership function** associated with the fuzzy
subset A. This terminology stresses the idea that a fuzzy set is defined
by the pair of points x and $m_{A}$(x). For every value of x within the
universe of discourse X there is a different degree of belonging to the
fuzzy set A. The degree of belonging is defined by
$0\text{<=}m_{A}\text{<=}1$.

The following EXPRESS code captures this definition of fuzzy subsets and
membership functions within the context of the above example:

> ENTITY car_condition_set;
>
> SUPERTYPE OF (ONEOF(trash, poor, fair, average, good, very_good,
> mint));
>
> universe_of_discourse : car;
>
> constraint_type : constraint_types;
>
> END_ENTITY;
>
> ENTITY trash;
>
> SUBTYPE OF (car_condition_set);
>
> membership : membership_function;
>
> END_ENTITY;
>
> etc.
>
> ENTITY car_class_set;
>
> SUPERTYPE OF (ONEOF(junker, budget, economy, mid_range, family_range,
> deluxe, luxury));
>
> universe_of_discourse : car;
>
> constraint_type : constraint_types;
>
> END_ENTITY;
>
> ENTITY junker;
>
> SUBTYPE OF (car_class_set);
>
> membership : membership_function;
>
> END_ENTITY;
>
> etc.
>
> ENTITY membership_function;
>
> graph : LIST(0:?) x_mu_coordinate;
>
> END_ENTITY;
>
> ENTITY x_mu_coordinate;
>
> x_coordinate : REAL;
>
> mu_coordinate : REAL;
>
> WHERE
>
> 0.0 \<= mu_coordinate \<= 1.0;
>
> END_ENTITY;
>
> In the above code the entities *car_condition_set* and *car_class_set*
> are supertypes. Their attributes *universe_of_discourse* and
> *constraint_type* are inherited by each of their respective subtypes.
> The subtype entities trash, poor, \... and junker, budget, \... are
> the fuzzy subsets of the universe of discourse. Each will have a
> membership function. The membership function is not inherited since it
> will be different for each fuzzy subset within the universe of
> discourse.
>
> The entity **membership_function** provides an example of how the
> EXPRESS language enforces consistency. The EXPRESS specification
> requires that the function be databased as linear segments connecting
> the listed set of points. The entity **x_mu_coordinate** defines the
> point $\left\lbrack x,m(x) \right\rbrack$ as a real number pair and
> bounds $m(x)$within the interval \[0,1\]. If users wish to communicate
> to the database using other functional formats "user friendlies" must
> be provided. These are written using the programming objects that can
> be derived from the EXPRESS specification. This enables views to be
> tailored to in-house corporate preferences, while leaving the database
> untouched and readable by foreign groups having access to the EXPRESS
> specification.

-   A proposition in a natural language is viewed as a network of fuzzy
    constraints. Upon aggregation, the constraints which are embodied in
    the proposition result in an overall fuzzy constraint which can be
    represented as an expression of the form

X *is* R (2)

where R is a constraining fuzzy relation and X is the constrained
variable. The generalized constraint is represented as

X *isr* R (3)

> where "isr" is a variable which defines the way in which R constrains
> X, see reference \[9\]. The "isr" variables identify constraint
> relation type. This information is required for the operations of
> fuzzy subset aggregation. The associated keywords are identified via
> the semantic construct *constraint_types* defined by the TYPEing
> operator of EXPRESS.
>
> The following EXPRESS code captures this generalized definition of
> constraint type by providing an enumerated list of allowable
> constraint relation types:
>
> TYPE constraint_types = ENUMERATION OF
>
> (equal, possibilistic, conjunctive,
>
> probabilistic, usuality, random_set,
>
> random_fuzzy_set, fuzzy_graph,
>
> rough_set);
>
> END_TYPE;

## EXPRESS -- Not a Computing Language

The language EXPRESS is not a computing language. It effectively
provides the template for information to be stored within an object
oriented database. Within this context knowledge representation via the
statement of propositions is accomplished during database instantiation.
The following EXPRESS code provides the necessary template for car
condition and appraisal knowledge representation. It uses the above
EXPRESS definitions for fuzzy subsets and adds 3 new attributes to the
attribute list of the entity

> ENTITY car;
>
> model_type : car_model
>
> made_by : manufacture;
>
> mnfg_no : STRING;
>
> registration_no : STRING;
>
> production_year : owner;
>
> car_body_condition : car_condition_set;
>
> car_engine_condition : car_condition_set;
>
> car_classification : car_class_set;
>
> UNIQUE
>
> joint : made_by, mfg_no;
>
> single : registration_no;
>
> END_ENTITY;

The entity **car** now contains three linguistic variables that may be
instantiated with the fuzzy subsets identified in the respective
"SUPERTYPE OF" lists of the entities **car_condition_set** and
**car_class_set**. The associated database instantiation process is the
proposition statement process.

It important to note that EXPRESS provides for the modeling of
information. How it is to be used is of no concern to EXPRESS. In this
example, the attribute *car_classification* may be provided directly by
an appraiser or it may be derived via the fuzzy inference techniques
associated with the theory of approximate reasoning.

## Link to Soft Computing

The introduction of linguistic variables to an entity\'s attribute list,
with an enumerated list of associated fuzzy set names, provides the
necessary link to the realm of soft computing. Entities which must be
viewed from several perspectives (mass, temperature, size, \...) will
have several associated linguistic variable descriptors.

Attribute instantiation is the first problem. In many situations these
are simply estimated via expert experience. In other situations a body
of information exists which will allow the techniques of fuzzy cluster
analysis to be applied to the attribute instantiation process.

Knowledge representation is the next problem. This is enabled by soft
computing\'s ability to compute with words. Complex IF ... THEN ... word
rules can be set up and evaluated via the theory of approximate
reasoning. This can

-   Support the engineering review process by creating a library of the
    IF ... THEN ... design rules used by the experts during the review
    process. These can be linked with the technical information
    management system\'s object oriented database to continuously
    perform background disciplinary and cross disciplinary checks on all
    baseline system design variables as they are entered into the
    system.

-   Support the launching of data mining queries to a digital library
    for background information to be checked when certain design
    conditions are encountered. For example, when design parameters near
    a past region of anomalous or reduced performance.

-   Support the product proposal creation and design process by
    linguistic sensitivity analysis. This analysis yields the allowable
    linguistic ranges for design parameter variation. This knowledge can
    complement and add insight into the results obtained by traditional,
    numerical, sensitivity analysis.

-   Automate the checking for standards, best practices and lessons
    learned violation.

## Computing with Words for Design Insight

In a metaphoric sense, consider the rectangular matrix equation

$\lbrack A\rbrack\left\{ x \right\} \leq \left\{ b \right\}$ (4)

were {x} contains numeric measures of design parameters, and {b}
contains numeric measures for design requirements, cost and performance
objectives. The rectangular matrix \[A\] captures all design parameter
dependencies associated with the physical and natural laws associated
with modeling product requirements, cost and performance. The design
process attempts to find an optimal solution to {x} relative to the
measures contained in {b}. Of course the actual design process is more
complex and carried out differently; but, this is its metaphoric
essence.

Now let the elements of {x} and {b} contain linguistic measures. Matrix
\[A\] still captures all design parameter dependencies however the
operations of summation and multiplication must now be replaced by fuzzy
constraint aggregation and the operators used for generalized constraint
specification, as defined in reference \[9\].

At a metaphoric level, one does not need to understand exactly how
linguistic constraints are defined and aggregated to see that a
powerful, insight rich, capability is evolving in the soft computing
community.

The design equation \[A\]{x}$${b} defines performance, realizability,
manufacturability, etc. The inability to find a linguistic solution for
{x} implies a product design with either a "null" or a single point
solution in design space. This implies that, for the defined mix of
requirements, performance and cost objectives, all possible product
designs will have the fundamental property that they will not be robust
enough to satisfy the desired mix of objectives. The key here is that
the linguistic solution {x} is not a point solution; it is a fuzzy
region in design space. This has much deeper interpretive meaning since
the size of the fuzzy region can be directly associated with design
solution robustness.

Computing with words has the potential for replacing numerical
sensitivity analysis via parameter variation with a one step process
that defines the fuzzy region in which the optimal design solution
exists.

# STEP -- Subsystem Interface Integration

The STEP-SII (Subsystem Interface Integration) project argues that
subsystem interface specifications are technical information and
therefore they too can be presented in a machine readable manner via
EXPRESS. In this format the interface specifications become complete,
unambiguous and nonredundant; a goal that is exceedingly hard to achieve
via traditional textural documentation.

Figure 2 provides a big picture view of the STEP-SII project. The
process starts with a clear text definition of a subsystem\'s interface.
The text of this Interface Control Document (ICD) is then translated
into the EXPRESS language. Once in EXPRESS a variety of commercial
software tools[^21]^,^[^22] are available to provide access to object
oriented databases and objects for use with programming languages such
as C++ and JAVA. The EXPRESS model effectively defines the template for
the technical information to be stored in the database. The next step is
to instantiate the database. To support this, user friendlies are
developed with a software toolbox of graphical user interfaces (GUIs).
The availability of EXPRESS derived objects and GUIs makes this a
straightforward process. In Fig. 2 software linkages S/W 1 and S/W 2
instantiate the database with standards and project specific data. S/W 3
enables data to be requested and S/W 4 enables it to be obtained. Since
the database is object oriented it is possible for the system itself to
request missing items of data. This is done by S/W 5. Engineers use
requested data via "established in-house lines of communication" to do
whatever has to be done to satisfy the data request and deliver it to
the database via S/W 6.

Fig. 2. Subsystem Interface Integration

As this process proceeds there are many "mundane" tasks that must be
done. These are mundane, to the expert, in the sense that what has to be
done is clearly known and all the data needed to do the task is in the
database. When this situation exists the potential for task automation
is high. S/W 7 is the link which provides for task automation. Along
this link data is automatically requested, processed and results placed
into the database. The STEP-SII project intends to demonstrate that this
can be done. The demonstration will use an EXPRESS model of subsystem
characterization data to support a highly focused controls design
analysis problem and a flight software development task[^23].

# Conclusions

An infrastructure for the technical management of information has been
presented. Areas requiring the support of state of the art soft
computing and intelligent support capabilities have been identified.
*Have no illusions*; implementation of the proposed infrastructure will
require commitment, it will be slow and it will be painful. Doing the
necessary computer science should present no major problems. The EXPRESS
translation of technical data packages should become easier after the
first few have been done. The hardest part will be capturing the soft,
crisp and fuzzy dependencies and relationships between the items of
information that define the product. This must be overcome and there
appears to be no easy solution, today. Never-the-less, the author is
convinced that the road to significant and obvious process improvement
goals is the road which takes a system level view while providing
intelligent support and enabling task automation within and across
subsystems.

**References**

1.  Peter Brown, M.D., "The Hypnotic Brain, Hypnotherapy and Social
    Communication," Yale University Press, 1991

2.  Didier Dubois and Henri Prade, "Possibility Theory, An Approach to
    Computerized Processing of Uncertainty, Plenum Press, 1988

3.  Julian Fowler, "STEP for Data Management, Exchange and Sharing,"
    Technology Appraisals, UK, 1995

4.  Jonathan T. Hujsak,"Digital Libraries and Corporate Technology
    Reuse," D-Lib Magazine, January 1996,
    http://www.dlib.org/dlib/january96/01hujsak.html

5.  "NASA Systems Engineering Process for Programs and Projects,"
    NASA/JSC, JSC-49040, Oct 1994

6.  Jon Owen, "STEP: An Introduction," Information Geometers Ltd., 1993

7.  Douglas A. Schenck and Peter R. Wilson, "Information Modeling: The
    EXPRESS Way," Oxford University Press, 1994

8.  Ronald R Yager and Dimitar P. Filev, "Essentials of Fuzzy Modeling
    and Control," John Wiley & Sons, 1994

9.  Lotfi A. Zadeh, "Fuzzy Logic = Computing with Words," IEEE
    Transactions on Fuzzy Systems, Vol. 4, No. 2, May 1996, pp.
    103--111.

[^1]: From: Okyay Kaynak, Lotfi A. Zadeh, Burhan, Imre J. Rudas Edts.,
    \"Computational Intelligence: Soft Computing and Fuzzy-Neuro
    Integration with Applications\", Springer-Verlag Series F: Computer
    and Systems Sciences, Vol 162, 1998.

[^2]: CA*x* = CAD/CAE/CAM...

[^3]: http://skipper2.mar.external.lmco.com/save/index.html -- SAVE
    (Simulation Assessment Validation Environment, at Lockheed Martin)

[^4]: http://www.ccad.uiowa.edu/\~infoint/ -- Information Integration
    for Simulation-Based Design and Manufacturing at The University of
    Iowa

[^5]: Standard for the Exchange of Product Model Data

[^6]: http://arioch.gsfc.nasa.gov/nasa\\\_pdewg/nasa\\\_pdewg.html --
    NASA Product Data Exchange Working Group

[^7]: http://www.scra.org/uspro/ -- U.S. Product Data Association,
    National Product Data Exchange Resource Center

[^8]: http://www.cadlab.tu-berlin.de/\~PDTAG/whois.html -- Product Data
    Technology Advisory Group, ESPRIT 9049

[^9]: http://www.univoa.pt/CRI/GR\\\_SSNC/RESEARCH/projsip.html --
    SIP-STEP -- based Integration Platform

[^10]: http://www.hike.te.chiba-u.ac.jp/ikeda/documentation/STEP.html --
    STEP Home Page, Ikeda Lab. Japan

[^11]: http://mecha.ee.boun.edu.tr/asi.html - NATO Advanced Study
    Institute on Soft Computing and its Applications

[^12]: http://http.cs.berkeley.edu/projects/Bisc/bisc.welcome.html -
    Home page for BISC (Berkeley Initiative in Soft Computing)

[^13]: http://www.scra.org/uspro//stds/stepage.html -- "STEP on a Page"

[^14]: ISO 10303, Proposed Application Protocol AP-232: Technical Data
    Packaging Core Information and Exchange

[^15]: ISO 10303, Proposed Application Protocol AP-208: Life Cycle
    Product Change Process

[^16]: ISO 10303 Part 11: EXPRESS Reference Manual

[^17]: http://gsfccost.gsfc.nasa.gov/mio/asset/asset.htm - Advanced
    System Synthesis and Evaluation Tool (ASSET)

[^18]: http://pdc.jpl.nasa.gov/ - JPL\'s Project Design Center

[^19]: http://mijuno.larc.nasa.gov/default.html - Design for Competitive
    Advantage

[^20]: 1\) the act, fact, or state of knowing; specifically, a)
    acquaintance or familiarity (with a fact, place, etc.). b)
    awareness. c) understanding. 2) acquaintance with facts; range of
    information, awareness, or understanding. 3) all that has been
    perceived or grasped by the mind; learning; enlightenment. 4) the
    body of facts accumulated by mankind. From: Webster\'s New World
    Dictionary of the American Language, 1966.

[^21]: http://www.steptools.com -- STEP Tools Inc. STEP Software for
    World-wide Manufacturing

[^22]: http://www.iti-oh.com -- International TechneGroup Incorporated

[^23]: http://skipper2.mar.external.lmco.com/sii/index.html -- The
    NASA/GSFC supported STEP-SII (Subsystems Interface Integration)
    Project, at Lockheed Martin