1

page 1 (1 pages)

CERC Technical Report Series

Technical Memoranda

CERC-TR-TM-92--10

PROMOTING CONCURRENT ENGINEERING THROUGH

INFORMATION SHARING*

Raghu Karinthi

V. Jagannathan

Vasile Montan

James Petro

Ravi Raman

George Trapp

November 1992

ACKNOWLEDGEMENT: This effort has been sponsored by Defense Advance Research Projects Agency (DARPA), under contract No. MDA972-88-C-0047 for DARPA Initiative in Concurrent Engineering (DICE).

Concurrent Engineering Research Center

West Virginia Univeraisity

Drawer 2000, Morgantown WV 26505

* Appeared in Engineering Database Program, ASME Winter Annual Meeting, November 1992.

Promoting Concurrent Engineering through

Information Sharing

Raghu Karinthi

V. Jagannathan

Vasile Montan

James Petro

Ravi Raman

George Trapp

The address of all the above authors is:

Concurrent Engineering Research Center

Drawer 2000, West Virginia University

Morgantown, WV 26506

The Email addresses of the authors (in order) are: [email protected], [email protected], [email protected], [email protected], [email protected], and [email protected]

All the authors are affiliated with the Concurrent Engineering Research Center. Raghu Karinthi and George Trapp are also computer science faculty in the Department of Statistics and Computer Science at West Virginia University. All the authors can be reached at 304-293-7226.

Primary contact person: V. ?Juggy? Jagannathan

Acknowledgment: This work has been sponsored by the Defense Advanced Research Projects Agency (DARPA), under Contract No. MDA972-88-C-0047 for the DARPA Initiative in Concurrent Engineering (DICE).

ABSTRACT

At the Concurrent Engineering Research Center (CERC), we have identified information sharing, as one of the crucial enabling technologies for concurrent engineering. Information in a large enterprise is distributed in various information repositories which range from relational databases to multimedia file systems that contain text, graphics, images, and CAD data. One of the goals in concurrent engineering is to enable a team member to transparently access the information all across the enterprise. To this end, we are focusing on two areas: enterprise modeling, and integration of engineering databases and other enterprise information repositories. The modeling of the enterprise is done in the data definition language called EXPRESS developed by the STEP consortium as an international standard. Theclass definitions in the enterprise model are stored in a commercial object oriented database. The model is intended to provide an integrated view of the enterprise. The detailed information of various products, processes and organization (PPO) is stored in the various information repositories and the model only holds the pointers to such data. We are developing a system (called the Information Sharing System) that implements our ideas, and enables information access over a wide-area network. This is based on our prior experience in a prototype system called the Knowledge Server. We believe that our system will be useful in integrating engineering databases, and will aid in the concurrent engineering of products by a geographically distributed team. This project is being carried out as part of the DARPA Initiative in Concurrent Engineering (DICE) and the software will be transitioned to pilot sites of participating industrial organizations in the fourth quarter of 1992.

I INTRODUCTION

Product development is an inherently cooperative activity in which a group of engineers, other experts, and managers work on different facets of the product under the direction of a project leader. The need for developing products that support a team arises in the context of concurrent engineering. There are several elaborate definitions of concurrent engineering currently in use. Briefly, the goal of concurrent engineering is to improve the cycle-time in the development of products and decrease the cost of production and maintenance, while considering customer expectations and life-cycle issues. One method of concurrent engineering is the concept of a tiger team. A tiger team is composed of members from multiple disciplines, each of whom provide unique perspectives in a product development environment. Unconstrained by arbitrary barriers, the members of a tiger team communicate their insights, make recommendations, and negotiate conflicts. In so doing, they bring problems to light early. This results in better quality products developed in a shorter time with reduced cost. However, in a number of organizations, physically collocating a team of relevant experts is very difficult or even impossible. For a variety of reasons, the relevant people, their tools and computer equipment are located in geographically dispersed locations, and the cost involved in collocating the people and the appropriate tools may be too high.

The concept of a virtual team was developed at the Concurrent Engineering Research Center (CERC) and in the DARPA Initiative in Concurrent Engineering (DICE). A virtual team is much like a traditional tiger team except that the team members can be geographi-

cally dispersed. In order for them to function effectively, they are connected via a computer network. A computer model of the enterprise, or at least the product being developed, is provided so that each individual can get a global picture of the organization (or product) and how he/she fits in as a part of the whole. Such a model will enable cooperative work among the team members by enabling information sharing and monitoring the progress of product development. This activity, sometimes called enterprise integration, is of growing importance. This kind of integration provides a number of facilities for a team member:

1. the team members can exchange ideas as well as archive them;

2. the team members can access information in the information repositories of others subject to security considerations; and

3. the team members can examine the model of the whole organization (or the specific product) in order to relate to the work of other team members.

II Methodology

With the above introduction, we examine specifically the problem at hand, viz., enterprise integration through a facility for sharing of information among the team members. Such a facility provides a model-directed view of an enterprise. The approach we are using is to develop an enterprise model and to integrate specific repositories with the model. This is described in greater detail in subsequent sections. There are several kinds of models that are commonly used: a Product-oriented model, which describes all the products developed in the enterprise; a Process model, which describes all the processes; and an Organization model, that describes the organization of the enterprise. In order to characterize an enterprise, one needs to model the Products, Processes, and the Organizational behaviors. Such a model is referred here as the PPO.

In the context of integrating multiple databases of an enterprise, several other approaches have been suggested. The federated (see Heimbigner and McLeod (1985), Navathe et al (1989), and Seth and Larson (1990)) or multidatabase (see Litwin, Mark and Roussopoulos (1990)) approaches avoid constructing a global schema and merely present the user with a collection of local schemas along with tools for information sharing among the databases. In this case, the user integrates only the necessary portions of the databases. There are several advantages to this approach such as increased security, easier maintenance, and the ability to deal with inconsistent databases. We believe that such an approach is suitable when the different databases in the federation contain similar data, but not when a wide variety of information repositories (not all of which are databases) need to be integrated. In such cases, the user (a virtual team member in our case) needs to be guided through the information available via an enterprise model. Certain segments of the overall information in the enterprise could be implemented as federated database systems.

The Carnot project (Collet, Huhns and Shen (1991)) at MCC uses an approach that is different from ours as well as the federated scheme. Carnot has a large body of knowledge or ontology that is available from the Cyc knowledge base (see Lenat and Guha (1990), and Guha and Lenat (1990)). Cyc, being a knowledge-based system, has a rich representational structure. The bulk of the knowledge in Cyc is common sense facts about the world (such as how tall humans are) and does not include enterprise-specific information.

Such information is added to Cyc, thus expanding Cyc?s ontology. The Carnot project is also aimed at integrating multiple databases.

In order to build an enterprise model we felt that the object oriented paradigm was best-suited to capture both the hierarchical nature of enterprises as well as their behaviors. For the purpose of modeling, we chose the data modeling language EXPRESS (1991), designed as part of the STEP international standard. EXPRESS was chosen primarily

because it is a modeling language and it is an upcoming international standard. It may be noted here that the EXPRESS language currently does not provide methods, and hence we are not planning to incorporate methods into our current model. This is discussed further in Section 5.

III SYSTEM OVERVIEW

Figure 1 shows the schematic of a system called the Information Sharing System (ISS) that we currently are building. The goal of the Information Sharing System is to provide the means for a team member to transparently access information over the entire enter-

MIND

DBA

ISS

API

Client UI
Application

RDB

GATEWAYS

MMR

ISS: Information Sharing System

API:Application Programmers Interface

MIND:Model-based INformation Directory

DBA:Database Administrator

RDB:Relational Database

MMR:Multi-Media Repository

Figure 1: Overview of the Information Sharing System

prise. Because corporate information already exists in a variety of computer information repositories such as databases, documents, drawings, and data files, it is imperative that the ISS be integrated with these existing repositories. For this reason, there cannot be one shrink-wrapped solution that can be deployed in a variety of enterprises with little or no customization. Keeping this in mind, we designed the ISS to provide the user with a system that is integrated with representative information repositories along with methodologies that enable the implementation in a phased manner. Earlier prototypes to this include the Knowledge Server (1991) and the PPO Server efforts carried out in earlier phases of the DICE project.

The use of the ISS by a team member is as follows:

A team member uses the client user interface to view, browse, and navigate the enterprise model. A team member can also pose queries based on the model, and the ISS will retrieve the appropriate information from the various repositories in the enterprise. The user is shielded from the locations, organizations, and access methods of the various information repositories.

Central to the ISS is a module called the Model-based Information Directory (MIND). The MIND contains a model of the information which is distributed throughout the various repositories in the enterprise. The ISS provides access to the model to enable a user to view how the information is organized. The MIND also maintains a mapping from the model to the actual information in each of the repositories. Using the mapping, the ISS can assist a user in accessing the information which has been modeled. When the project is complete, the ISS will be integrated with commercial Relational Database Management Systems (RDBMS), Object-Oriented Database Management Systems (OODBMS), Configuration Management Systems, Multimedia document repositories, and CD-ROM archives. We currently are working on the following goals:

1) to develop the Model-based Information Directory software and methodology;

2) to integrate with a commercial relational database management system (Oracle), and a multi-media document repository;

3) to develop an application programming interface for the Information Sharing System; and

4) to deploy over a wide area network.

IV Users

There are three main types of users of the ISS, as shown below:

1. database administrators (DBA), who manage the organization?s databases and information systems. They interact with the ISS via a DBA interface. They can create, modify, and delete the models and mappings in the ISS.

2. end-users, who are the team members that use the system. These include engineers, sales and marketing representatives, designers, and production specialists, etc. They use the user interface and the browsing facilities of the ISS in order to navigate the model and access the information in the repositories.

3. application programmers, who are computer software specialists that develop and update the client applications which access information using the facilities of the ISS.

V System Architecture

With the above overview of the system, we now examine the detailed architecture of the ISS depicted in Figure 2. In the figure, the arrows indicate the flow of data. The data flow is in response to a request for information in the other direction.

DBA Data

Access
Manager
Map

Manager

Query Processor

Relational

Gateway
Database
Multi-media

Gateway
Repository

Client

Data Flow

Editor

Communications Module

DBA

Modeler
EXPRESS
Importer

Model-based
Information

MIND

Model

Manager

ORACLE
RDBMS
Document
Multi-media

Repository

Repository
Manager
Application

Directory
database

Figure2: Architecture of the Information Sharing System

Database Administrator Tools

DBA Modeler

The DBA Modeler is a stand-alone tool which can be invoked by the database administrator for the purpose of interactively creating, modifying, deleting, and viewing the classes that comprise the information model in the Model-based Information Directory. Each class defined in the model represents an enterprise model entity specification, which in turn represents information stored in one or more data repositories. This definition manifests itself as a C++ language class definition that is stored in persistent form via the VER- SANT object-oriented database management system.

DBA Data Editor

The DBA Data Editor is another stand-alone tool which can be invoked by the Database Administrator for the purpose of interactively creating, modifying, deleting, and viewing the instances of the user access information and the mapping information in the Modelbased Information Directory. The DBA editor allows one to create information identifying individual users and their access privileges. It also allows one to create the mapping information which correlates model components with the repositories wherein the actual data resides. Repository-specific information, such as name, type, and communications parameters, is also created using the DBA editor. All of these instances are stored in persistent form via the VERSANT object-oriented database management system.

EXPRESS Importer

The EXPRESS Importer is another stand-alone tool which can be invoked by the Database Administrator for the purpose of incorporating a file containing EXPRESS language definitions of one or more classes into the Model-based Information Directory. The class definitions are converted from EXPRESS into C++ by means of a VERSANT-supplied translation utility, and then stored in the MIND database. As before, each class defined in the model signifies an enterprise model entity specification which represents information stored in one or more data repositories.

MIND

The Model-based Information Directory (MIND) process is the VERSANT objectoriented database management system server that provides access to the database containing the model information. It provides a communications interface via which client applications, such as the ISS Server process, may access the database.

Access Manager

The Access Manager contains the methods for authenticating a user?s requests. Transactions contain the user?s authorization information, such as an account and a password. Each transaction is validated by verifying the authorization information against the access information stored in the MIND.

Model Manager

The Model Manager is a module that performs a set of services related to the model. These services include identifying the existence of a class in the model; identifying the attributes, unique attributes, and relationships of a given class, as well as their data type; and retrieving the definition of a specific class. The class definitions are created by the DBA

Modeler or EXPRESS Importer tools and are stored in the MIND database.

Map Manager

The Map Manager is a module that performs a set of services related to the information in persistent storage that pertains to enterprise model-to-repository mappings. The mappings themselves are created by the DBA Data Editor tool and are stored in the VER- SANT database.

Client Application

The Client Application/User Interface assists a user in examining the enterprise model using a simple to use graphical interface built with Motif. It also assists the user in browsing the data in the enterprise, retrieving the data, and searching for data.

Repository Manager

The Repository Manager module processes incoming requests made by a client application. It controls the operations of the ISS, ensuring transaction validation and routing of the request to the model manager or the query processor as appropriate.

Query Processor

The Query Processor is responsible for interpreting an enterprise query, which is based on the enterprise model, and for forming the individual queries for each of the repositories. The query presented to the Query Processor through the Communications Module will be couched in terms of the enterprise model. For this purpose, we have developed a simple query language similar to SQL. This language has the functionality of a subset of SQL. In this language, we try to select instances or attribute value pairs in which certain conditions hold. The query will be a request for information which may reside in either of two types of repositories: an external relational database, or an external Multi-media repository. The Map Manager enables the Query Processor to determine where each piece of the requested information is located and how it may be extracted. The Query Processor then formulates the necessary queries and submits them via the Communications Module to the appropriate repository gateways. The Query Processor then consolidates the results from the repository gateways to form the result of the original query.

Communications Module

The Communications module provides inter-process communications and supports the transfer of requests and results between the client application programs and the ISS Server process, and also between the ISS Server process and the RDB and MMR Gateway processes. It contains methods for packing and unpacking the various requests and results into the format for transfer over the communications media.

RDB Gateway

The Relational Database (RDB) Gateway is a separate process which accepts queries from the ISS Server process, converts them to the format specific to the relational database management system with which it is associated, and submits the transformed queries to the DBMS employing ORACLE?s Application Programming Interface (API). The results

of the queries are obtained from the DBMS, packaged, and then transferred back to the ISS Server.

Multi-media Gateway

The Multi-media Repository (MMR) Gateway is a separate process which accepts queries from the ISS Server process, converts them to the format specific to the multi-media repository system with which it is associated, and submits the transformed queries to the MMR, utilizing its API. The results of the queries obtained from the MMR, which are either document files or information about documents, are packaged and then transferred back to the ISS Server.

VI Issues and Implementation Decisions

Our vision of the ISS is a generic system which may have multiple instances. Therefore, in a large enterprise, one would have a number of IS servers and the user can avail of the services of any server on the network. Each server will also be capable of serving multiple users and will allow both read and write access to the enterprise information which is being modeled, subject to security constraints. However, in our current implementation, we have deferred some of the goals to future years (we are currently five months into a three year project). Some of the issues and decisions we have made for the current system are:

1. Security: The objective of the Information Sharing System is to provide easy access to enterprise information. It is essential, however, that access be provided only to those who have the appropriate authorization. Organizations ensure the security of corporate information and reserve the right to specify the data access rights of its employees. At present, the data stored in any organization?s data repositories is controlled by security mechanisms. The Information Sharing System will respect and abide by these procedures. In the immediate future, however, we will not provide any additional security beyond what is provided by external data repositories and the data management system which is used to manage the model. The ISS will make all requests to the external data repositories as a special user.

2. Transaction versus session oriented: In building a system such as ISS, which needs to support multiple, concurrent users, there has to be a notion of processing transactions. However, from the context of individual users, it is useful to maintain a session orientation. To balance these requirements, we have decided to make the ISS server transaction oriented and to provide support to ISS client builders to develop session oriented clients.

3. Performance: In order to improve the performance, we should allow the system to have as much concurrency as possible. The ISS will have concurrency in extracting from multiple databases.

4. Static Schema: One of the characteristics of engineering data is that the schema does not change frequently. Therefore, we have assumed that the schema will remain static during the time that users will be accessing information from the Information Sharing System. Trying to access the data while the schema or the map is being modified could result in inconsistent results. Therefore, we decided that the user interface cannot access the data or the model while the model or the map is being updated.

5. Information Access: Since we are trying to address the problems of large organizations that are geographically dispersed, the ISS must operate over a wide area network. For this purpose, we are adapting information protocols (see Kahle (1989) WAIS Concepts, and ftp) that enable data transmission over a wide area network.

6. DBA maintenance role: A system such as the ISS will never be deployed if the DBA is expected to be a C++ programmer. In our current strategy, we expect the DBA to model in EXPRESS the information to be served by the ISS, with the help of an information modeler. We also expect the DBA to provide mappings from the model to external repositories. The map representation has been simplified to make the maintenance task easier. We have also decided that we will maintain no information within ISS other than model classes and maps.

For the sake of brevity we are omitting some of the other issues pertaining to the design of the ISS, such as the details of the protocol for exchanging files and objects over a wide area, and the translators from EXPRESS to C++ schemas.

Hot Cup

Name CupID HeaterIDHotCupID

Cup

HeaterPad
HotCupDoc

Salesman

UnitPrice FeatureList

Assembler

Material

Designer DesignerName

BottomX2

BottomThickness
SideColor SideGeometry

BottomMaterial

SideMaterial

HandleGeometry PricePerVolume

Picture

Description Supplier

Name Price

HeatRate

Cup Database

Heater Pad Database

Hot Cup Database

Hot Cup Document

CupPicture

HandleMaterial

BottomY2

BottomY1

BottomX1

Database 1

Database 2

Database 3

Database 4

Figure 3: Entity-Relationship model of Hot Cup scenario

VII The Coffee Cup Scenario

We will illustrate ISS with a toy scenario of a (hot) coffee cup manufacturing company. Even though the scenario is fictitious, several of the databases that are used are elaborate systems built in other projects. Figure 3 depicts the four databases involved in the hotcup scenario. The first database resides on VERSANT and contains the auxiliary data, whichcontains the ?glue? information that supports the model and integrates the remaining databases. It is explicitly built as part of enterprise integration, whereas the others are legacy systems. The first database, called Hot Cup, has only one table called HotCup, and the second database, called Cup, has three tables called Cup, Material, and Designer. The third database, called Heater Pad, has one table called Heater Pad, and the fourth is a document repository called HotCupDoc. Below, we show the descriptions of the first two databases.

Database 1: Hot Cup

Table 1: HotCup - table with each record describing a hot cup

HotCupID - unique identifier of hot cup

Name - descriptive name of hot cup

CupID - unique identifier of cup used with this hot cup

HeaterID - unique identifier of heater used in this hot cup

Database 2: Cup

Table 1: Cup - table with each record describing a cup

CupID - unique identifier of cup

DesignerName - name of designer of this cup

BottomX1, BottomY1 - Points describing the base of the cup

BottomX2, BottomY2 - Points describing the base of the cup

BottomThickness - thickness of bottom of cup

BottomMaterial - unique id of material of bottom of cup

SideColor - color of the side of cup (white, blue, etc.)

SideGeometry - file name of EXPRESS geometry file

HandleMaterial - unique id of material of handle of cup

HandleGeometry - file name of IGES geometry file

Table 2: Material - table with each record describing a material

MaterialID - unique identifier of the cup material

MaxHeatTolerance - maximum heat the material can tolerate

PricePerVolume - price per unit volume of material

Table 3: Designer - table with each record describing a designer

DesignerName - name of designer

Picture - picture of designer

Relationships [code: Table.Column]

Cup.DesignerName - Designer.DesignerName

Cup.BottomMaterial - Material.MaterialID

Cup.HandleMaterial - Material.MaterialID

Cup.SideMaterial - Material.MaterialID

Part of the enterprise schema is shown below.

SCHEMA TYPE MAPPINGS

HotCup

[HotCupID] ID 1:HotCup.HotCupID,

4:HotCupDoc.HotCupID

Name string 1:HotCup.Name

Cup

[CupID] ID 1:HotCup.CupID,

2:Cup.CupID

Designer

Name string 2:Cup.DesignerName,

2:Designer.DesignerName

Picture file 2:Designer.Picture

Salesman string 4:HotCupDoc.Salesman

UnitPrice real 4:HotCupDoc.UnitPrice

FeatureList str list 4:HotCupDoc.FeatureList

Assembler string 4:HotCupDoc.Assembler

CupPicture file 4:HotCupDoc.Picture

As one can see from the above, the global schema has pointers to the data in the individual repositories. These are provided via the mappings. For example, Salesman is an attribute of the entity HotCup of the global schema, and the mapping for it reads ?4:HotCupDoc.Salesman,? which refers to the attribute Salesman of the HotCupDoc entity of the fourth database. The attribute Designer of HotCup.Cup is itself an entity and has attributes

Name and Picture. The attribute HotCupId has two mappings, ?1:HotCup.HotCupId,? which is the column HotCupId of the table HotCup of the first database, and, ?4:HotCupDoc.HotCupId,? which is the attribute HotCupId of the entity HotCupDoc of the fourth repository. The mapping of a single attribute into multiple repositories establishes a relationship among the repositories. At present, we are planning to use all the mappings. The issue of how to retrieve information when we have multiple mappings opens several research issues and we are currently studying these.

VIII Future of the System

The ISS is part of a set of projects in concurrent engineering being developed as part of the DARPA Initiative in Concurrent Engineering (DICE) program. A prototype system integrating the Oracle relational database and a multimedia repository will be completed over the next six months and will be delivered to industrial pilot sites. Some of the pilotsites in the DICE program are specific projects in General Electric Aircraft Engines, Westinghouse, MCC, and Lockheed. The ISS will be integrated into a single environment available to a team member to enable him to work effectively in a concurrent engineering environment by allowing him to communicate with others over a wide area network, coordinate his/her activities with that of other team members and the project as a whole, and share information using the enterprise model. We hope the lessons learned during the use at the pilot-sites will help in designing a better system in the future years.

In future versions of the system, we plan to provide better security, version and configuration management of the model, and integration with several different kinds of database mangement systems and other information repositories. Information models will be enriched from the experience at the pilot sites. We plan to develop product, process and organizational models for at least a few industrial settings. We envision this development to lead to a situation in which we have several cooperating ISS agents, so that if the information a user wants is not with one ISS agent, it will be passed to another in order to obtain the solution.

IX Summary

In this paper, we have described our ongoing efforts in the development of a system to promote cooperative work within a team, especially in a concurrent engineering setting. A model-based methodology for accessing information that is scattered across an enterprise has been developed. The architecture of a system called the Information Sharing System (ISS) that is currently being developed has been described. The progress on the ISS and the future in terms of its use at pilot sites has been described.

The use of the model in searching and retrieving information eliminates the need for a user to know where and how the data is physically stored. This relieves the user from having to know multiple retrieval protocols and the different naming conventions of the different repositories. It also provides the user with a unified view of the entire collection of information regardless of where each piece of information is located. This allows the user to get an overall picture of the information as well as locate information which is related to information that is already known.

We believe this system and its successors will significantly promote cooperative work among team members and increase their productivity in product-development endeavors.

X References

Christine Collet, Michael Huhns and Wei-Min Shen, ?Resource Integration Using a Large Knowledge Base in Carnot,? IEEE Computer, 24(12):55-62, December 1991.

International Standards Organization, CADDETC 171 Woodhouse Lane Leeds LS2 3AR UK. EXPRESS Language Reference Manual. 1991.

R.V. Guha and Douglas Lenat, ?Cyc:A Midterm report,? AI Magazine, 11(3):32-59, Fall 1990.

D. Heimbigner and D.A. McLeod, ?Federated Architecture for Information Management,? ACM Transactions on Office Information Systems, 3(3):253-278, July 1985.

Brewster Kahle, ?Wide Area Information Server Concepts,? Technical Report, Thinking Machines Corporation, November 1989.

Bell Atlantic Software Systems, Morgantown WV. Knowledge Server Guide. May 1991

Douglas Lenat and R.V. Guha. Building Large Knowledge-Based Systems: Representation and Inference in the Cyc Project. Addison-Wesley, Reading, Mass. 1990.

Stanley B. Lippmann. C++ Primer. Addison-Wesley Publishing Company, 1991.

W. Litwin, L. Mark, and N. Roussopoulos, ?Interoperability of Multiple Autonomous Databases,? ACM Computing Surveys, 22(3):267-293, September 1990.

S. B. Navathe et al., ?Federated Architecture for Heterogeneous Information Systems,? in Proceedings of the National Science Foundation Workshop on Heterogeneous Databases. 1989.

A.P. Seth, and J.A. Larson, ?Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases,? ACM Computing Survey, 22(3):183-236, September 1990.

Darrell Woelk and Won Kim, ?Multimedia information management in an object-oriented database system,? Technical Report DB-046-87, MCC, Austin Texas, 1987.