A SERVICE BASED ARCHITECTURE FOR INFORMATION AND ASSET UTILIZATION IN DISTRIBUTED PRODUCT REALIZATION Jitesh H. Panchal*, Matthew K. Chamberlain§, David W. Rosen¶, Janet K. Allen# and Farrokh Mistree** Systems Realization Laboratory The George W. Woodruff School of Mechanical Engineering Georgia Institute of Technology Atlanta, GA 30332-0405
ABSTRACT The rise of the internet and the increasingly symbiotic relationship between designers and computers have both made information increasingly easy to acquire and have changed the way design is carried out. At the same time, the ease with which information can be gathered has created demand for faster, more flexible design processes. Today, geographically distributed designers can take part in a design by breaking the design process down into smaller, independent tasks. In this situation, both computers and fellow designers become the assets that are necessary to carry out the process of product realization. Each asset provides the lead designer with a service that could be based solely on the experience of other designers or on the software tools available for use over the Internet. The heterogeneous nature of these available assets brings into light a need for a systematic means of exchanging design information and knowledge. The question that arises is: “How can these assets be integrated and used in the design process?” In this paper, we present a framework for integrating various activities along the design time line. The framework is based on XML based standards for communication between various software services and achieving interoperability between them. Simple Object Access Protocol (SOAP) is used as an underlying mechanism for transferring messages between different assets. We also discuss the model used to deploy, search for, and manage the available services on the Internet. Lastly, we discuss the management of the information that is generated as a natural byproduct of the process of product realization. We present an example in which the use of the web-based framework and information management model is
demonstrated by using them to integrate the distributed services that make up the Technology Identification, Evaluation, and Selection (TIES) method, a conceptual design exploration method that has already been demonstrated in the literature. We close the paper with discussion of what has been shown and look towards the future of this ongoing work, paying particular attention to its use in a future strategic design framework. 1.
FRAME OF REFERENCE
Today, industrial enterprises are found spread out all over the world. Companies are expanding their base of operations in a search for cheaper labor, materials, or land, or as a way of bringing manufacturing closer to the targeted market. As this trend continues into the foreseeable future, engineers may increasingly find themselves working on the realization of products that could be designed in one location, built in another, marketed to consumers in a third region, and supported or serviced by a group elsewhere. Given this vision of the future, it is not too much of a stretch to also imagine that the design teams in such enterprises might themselves be split up, with members of the teams distributed amongst the company’s many worldwide locations. While some newer technologies such as broadband internet and cellular phones have eased the barrier that distance creates to verbal and written communication between individual co-workers, there is still a great deal of work to be done in facilitating the meaningful sharing of engineering information and in facilitating or approximating the same sort of collaborative environment that exists when designers are working in the same location.
*
Graduate Research Assistant, AIAA Student Member Graduate Research Assistant, AIAA Student Member ¶ Associate Professor # Senior Research Scientist, AIAA Senior Member ** Professor and Corresponding Author, AIAA Associate Fellow. Email:
[email protected]. Phone: (404) 894-8412 Fax: (404) 894-9342 §
1 American Institute of Aeronautics and Astronautics
Using a simple example, we demonstrate how the engineering environment of tomorrow calls us to develop new design tools. A major international aerospace company has decided to explore the feasibility of a line of small, supersonic business jets for a worldwide market. The company has established design practices and individuals or teams with expertise in the design of small aircraft, supersonic aircraft, and aircraft designed for a business clientele. They also have a proven track record of creating products that fit well into the existing niches in market demand. The company’s expertise in these areas is spread amongst its numerous international branches. The company’s problem is twofold: it needs a design process that can be tailored to the task at hand and it needs a way of bringing all of its design assets together from points all over the world. The latter problem could be addressed in several ways. One option available to the company is to move individuals from their respective locations to a common facility to perform an initial study of the feasibility of the business jet, but this would involve considerable and perhaps prohibitive relocation and setup costs. The other problem could be addressed through the use of strategic design methods, which forecast changes in markets, customer demands, and technical capabilities to help support the design of products that can quickly accommodate these changes. Strategic design could allow the company to create a related family of jets that would react to changes easily and take as much advantage of new or emerging technologies as possible1. Still, the problem of bringing internationally distributed assets together must be addressed. What if a mechanism were available whereby the individual experts in each field were able to collaborate in the strategic design of the aircraft, communicating and sharing their data freely while never leaving their home offices? In this paper, we describe one such mechanism, a computerized framework called X-DPR, focusing mainly on explaining the important aspects of information management in the creation of a web-based strategic design method. The story of the development of this framework begins with a description of the technical background for distributed product realization environments and an overview of the software technologies and standards that it uses. We then describe some of the previous efforts towards distributed collaborative engineering and highlight the drawbacks in each as a way of developing the requirements for an enhanced product distributed realization environment. The
work is based on the Web-DPR (Distributed Product Realization) framework developed in the Systems Realization Laboratory at Georgia Tech2 but since the new framework is based on the XML-based standards, it is termed as X-DPR. We go on to discuss the main elements of the X-DPR in Section 3 and show how it can be used for distributed design activities by examining the case of the Technology Identification, Evaluation and Selection (TIES) methodology3 in Section 4. The TIES process is made up of various computational tasks that can be carried out using different software resources. In the case study, we show how these software resources were published as services over the Internet and used by through the X-DPR framework. 2. TECHNICAL BACKGROUND FOR DISTRIBUTED PRODUCT REALIZATION Having discussed in Section 1 our vision what the design environment of the future may entail and how this work on X-DPR framework may help fulfill the needs of future engineers, we now continue on to describe the technical background upon which our work is based. 2.1. Overview of Relevant Software Technologies Currently, distributed software systems are typically developed using the Web Services philosophy. Web Services are defined as some piece of useful functionality that is made accessible over the Internet. These services are broken down into two categories: those that are automated and those that involve a human being. For example, there are numerous existing automated services like FedEx package tracking service, car rental reservation service, local weather forecast service and so on. An example of the latter category is a design consultant who provides technical help based on his/her experience in design in the form of answers to customers’ problems. All of these web services are published over the network to be used by other programs or by other users. A web service can also be a combination of a number of other services. The standard base of Web Services today is XML (eXtensible Markup Language)4. XML is designed to improve the functionality of the web by providing more flexible and adaptable information identification. It provides an application independent way of sharing data and serves as a common structure for information that is readable by both humans and computers. For these reasons, XML is
2 American Institute of Aeronautics and Astronautics
used for information transfer between various applications in the X-DPR framework presented in this paper. A number of independent efforts aimed at achieving a distributed computing environment have been carried out in the past. Some of the more successful ones are: CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model), and EJB (Enterprise Java Beans). CORBA is developed by OMG – a group of middleware vendors. More information about OMG can be obtained at their web site: www.omg.org. CORBA uses a protocol called IIOP (Internet InterORB Protocol). CORBA supports application development on different platforms and in different languages. Another successful venture, DCOM (Distributed Component Object Model) is developed at Microsoft5. DCOM is an extension of a specification called COM, which defines the interfaces between objects. A third example is EJB technology6, which is developed by Sun Microsystems. EJB is a platform independent specification but can be used only for Java. EJB uses Java based Remote Method Invocation for communication between objects on different systems.
SOAP Request POST/StockPrice HTTP/1.1 Host:www.stockpriceserver.com Content-Type: text/xml Content-Length: MSFT
SOAP Response HTTP/1.1 200 OK Content-Type:text/xml Content-Length: nnnn
105
Figure 1 - An example of a SOAP request and response for a stock price web service7 All of these protocols share the common problem that they are not compatible with each other and that the applications deployed with these protocols cannot be accessed through a firewall. To address these drawbacks, a standard protocol - Simple Object Access Protocol (SOAP) is developed. SOAP uses simple HTTP request-response based communication, allowing it to pass through corporate firewalls7. XML is used to transfer data between applications. Since XML is a platform and language independent standard, SOAP is also platform and language independent. A SOAP message typically
contains an XML message along with an HTTP header. An example of SOAP request and response is shown in Figure 1 for a web service that takes the stock symbol as input and sends back the stock price corresponding to that symbol as output. The web service receives the request as a stock symbol and returns a number for stock price as a response. Another standard that is developed for the Web Services based framework for distributed applications is WSDL (Web Service Description Language). WSDL is an XML-based language used for describing web services and their location so that the users can know how to access the service. A WSDL file describes the format of input and output data for each function call in the service. In this work, we use XML to define interfaces between different design activities, SOAP for message transfer between distributed applications over different platforms and WSDL to describe different web services. 2.2. Earlier Software Frameworks Recently, a significant amount of attention is paid to efforts meant to enable globally distributed designers to work as a team and carry out their design activities over the web. In this section, we discuss some of the activities that have been going on in research institutions both within academia and in industry. SANDIA P2: One of the initial efforts to achieving distributed computing environment is the SANDIA P2 framework that used a central communication agent that delivered client requests to corresponding services8, 9. All the services and clients were directly connected to the communication agent. The communication agent managed the interaction between different services and passed asynchronous messages over the Internet, allowing concurrent processing. The major drawback of SANDIA P2 framework is that for each design process, the communication agent needed to be reconfigured and recoded10. PRE-RMI framework: The Systems Realization Laboratory at Georgia Institute of Technology improved the information handling in SANDIA P2 framework in the course of developing PRE-RMI framework. In PRE-RMI, the underlying messaging mechanism is through events that are exchanged between agents. The event is a Java object that is transferred between agents through Java Remote Method Invocation (RMI). Event channels are used to control the flow of these events among agents. The
3 American Institute of Aeronautics and Astronautics
agents are divided into a number of logical groups; all agents in a group are registered to an event channel. The event channels receive all events and broadcast the event to all registered agents. The agent that is directly responsible to that agent will respond to it2. Web DPR framework: Using the basic communication framework of PRE-RMI, Web DPR is developed (see Figure 2.) The aim in developing Web DPR framework is to make the system accessible using a simple Java enabled web browser. A Java Web Server is introduced in the framework in order to accept HTTP requests from the browser and return HTTP responses back to the browser. A process database stores the information about available agents, the event channels they are registered to, and other information about the design process. The client sends a request to the web server, which is then transferred to event channels. The event channels then forward the request to agents. Information is transferred between various agents either as messages concerning events and other supporting info like starting point or destination point or as engineering data. Engineering data may include data files, CAD models, etc. This engineering data is archived in a central data vault. A Java based application, Agent Template is used to create and deploy agents easily into the framework. With the Agent Template, the users need not have much knowledge about the internal implementation details about the framework.
Upload & download Data
Se P ro rvice R ce s s D e qu e s at a t Upd & a te
Up
Framework Database
e dat
WWW Server
U Re pdat qu e es t
WWW Client
Request & Response
Coordinator (EventChannel)
Upload & Download Data
Call h od e Met Updat a D at
Data Vault
Agent Template
Message Data Coordinator Agent
Figure 2 - Web DPR framework architecture Some of the main features of Web DPR are: • It is platform independent since the framework is Java based. • The framework could be used not only in an intranet, but also over the Internet.
•
The framework is easy to use and maintain.
• The framework can readily adapt to changes in the agents and is robust enough to overcome failure of some agents in the network11. As is seen from these frameworks, there has been a continuous improvement in the ability of systems to reconfigure themselves, without much effort in recoding. To take this effort further, the new framework (X-DPR) is developed at Systems Realization Laboratory, Georgia Tech. We now discuss two commercially available frameworks for application integration – iSIGHT and Phoenix Integration. iSIGHT: iSIGHT is a software application developed by Engineous Software Inc. for the purpose of integrating various simulation codes that are generally used in a design process. ISIGHT also provides built-in functionality to carry out design of experiments, approximations and optimization. ISIGHT is mainly developed to integrate multiple design tools, coordinate the design process by customers and automate them. It enables engineering designers to explore more design alternatives and reach optimal designs faster, leading to significantly lower product costs and increased overall product performance12. iSIGHT embodies a variety of optimization methods including quality engineering, approximations and design of experiment methods; however, iSIGHT provides limited functionality of process integration of the distributed process using CORBA. The function of iSIGHT database is not the same as the utility of the original (relational or object-oriented) database, but just data storage where iSIGHT saves the generated data during the operation13. It is not necessary to construct well-structured relationships or design process efficient management for engineering data generated in optimization process.
The limitation of iSIGHT is that it is only capable of integrating applications that can accept inputs in the form of simple text files and can provide outputs in the form of simple text files. iSIGHT uses its inbuilt text parser to parse these text-based input and output files to extract and write parameter values. This kind of text parsing is generally inefficient and time consuming. Further, it is difficult to use this kind of interface to achieve high interoperability between various software applications, and it tends to make the system less robust. In addition, it is not possible to pass complex objects between applications. The
4 American Institute of Aeronautics and Astronautics
text-based mechanism will work only for simple parameter passing. Phoenix Integration: Phoenix Integration provides two modules, ModelCenter and Analysis Server. ModelCenter operates on client-server based architecture, meaning that all the applications are installed on Analysis Server, allowing the user to use ModelCenter to define a design process. ModelCenter automates the process of running a number of design programs incorporated in designers’ activity. Data for a design is automatically passed from one program to another using ModelCenter, enabling the engineer to concentrate not on the tedious job of running individual/heterogeneous programs, but on the results of the design. Together, the two modules are meant to provide a lightweight, protable, and configurable integration strategy for engineering organizations14. ModelCenter enables users to link input data parameters to individual output data parameters with drag and drop operation. ModelCenter and Analysis Server together give more flexibility of data interoperability with third party software than iSIGHT does. While iSIGHT provides only file format of interface, Analysis Server offers four different data interfaces, which are File wrapper to Macro/Script APIs, Java-based command line interaction, COM/OLE integration through Visual Basic Scripting, and C/C++ API interface. The main limitation of ModelCenter is that it does not have capability to perform parallel processing of tasks. This means that, in a given design process, only one process can be active at a time even though two tasks can be independent to each other. 2.3. Comparison of the Frameworks Discussed Some of the earlier efforts on distributed product realization frameworks are presented in Section 2.2. These frameworks are compared in Table 1 under the headings – Web DPR, Phoenix Integration and iSIGHT. The comparison is based on various factors like flow of information, ability to integrate heterogeneous software applications, robustness to changes in agent implementation and support for collaboration, etc. As discussed earlier, most of the frameworks are developed based on the ClientServer philosophy where the server owns an agent and all the information exchange between the agents is through some central computers. This impedes direct communication between agents and creates a bottleneck at the web server if there are a huge number of agents linked to that server. To overcome
this drawback, a peer-to-peer based framework called X-DPR is presented in this paper. It allows for direct communication between the agents. Table 1 - Comparison between Web-DPR, Phoenix Integration, iSIGHT, and X-DPR Web-DPR
Architecture
Client-Server
Phoenix Integration
iSIGHT
Client -Server
Low distributed computing functionality
Peer-to-Peer
Files
SOAP
CORBA, DCOM Etc.
X-DPR
Messaging Mechanism
Java RMI
Changes in the agents propagate to the framework easily?
Yes
Yes
The file parsing has to be changed
Yes
Direct Agent-toAgent communication?
No
No
No
Yes
Central governing authority?
Yes
No
No
No
Compatibility with other frameworks?
No
No
No
Yes
Message structures
Standardized XML template
Simple text
Objects
Flexible XML structure
Platform independence?
Yes
Depends on the Model Center
Available for Windows and Unix
Completely platform independent
Support for multiple programming languages?
No
Yes to some extent
The program just deals with text files
Yes – completely language independent
Support for collaboration?
No
No
No
Yes
The message transfer between agents is accomplished by the Simple Object Access Protocol. This renders the framework to be language and platform independent as compared to Web DPR, which is language dependent because of the use of Java RMI. The new framework is designed such that it allows collaboration between different designers working on the same design process. From Table 1, it is observed that the main advantages of X-DPR are that it facilitates direct communication between agents, is compatible with other distributed frameworks, has support for multiple programming languages and has support for collaboration. The details of X-DPR framework are discussed in Section 3. 3.
THE X-DPR FRAMEWORK
In Section 2.2, we presented some of the earlier efforts towards integrating various design activities through an integrated computer framework. In this section, we further evaluate the existing frameworks, discuss their drawbacks, and show how the demands of future distributed design environments create a need for new work to be done.
5 American Institute of Aeronautics and Astronautics
3.1. The Case for the Development of X-DPR The Web-DPR framework is based on the client server type of architecture. Each agent is linked directly to a server that forwards the client requests to various agents. In other words, all the requests from the client have to go through the web server. This means the server controls all the agents. However in an open system, where there can be a number of engineering service providers available, all the agents cannot be controlled by a single server. In the case where there are thousands of agents available for the clients to access, the server will experience excessive load and in fact need to split the load with other servers. The agents are also required to communicate with one another. Web-DPR does not allow such Agent-to-Agent communication. All the message transfer between the agents has to go through the web server. Many commercial applications like iSIGHT have the drawback that they are only capable of integrating simulation codes that accept simple text inputs and can only produce simple text files as outputs. Usually, the interfaces between various applications are text files and a parser is used to read and write data from these text files. A small change in the input and output file format will render the coupling between codes useless, meaning that the mapping has to be redone. This kind of loose coupling between various codes is not suitable for an open distributed system. The Web-DPR framework is based on Java RMI messaging between the web server and the agents. Java RMI is used to achieve platform independence in the framework. This allows the agents to be deployed on any platform i.e., Windows and Unix. However, this also places a restriction on the framework that the software agents must be coded in Java if an object level interaction is required between the agents. A higher-level communication is made possible by an agent template, as seen in Figure 313.
Figure 3 - Communication between agents through agent templates Each agent is tied to an agent template. By using agent templates, the agents send and receive files and perform some basic operations like activation of the agent. Hence, finer level interaction between agents written in different languages is not possible13. Web DPR is also not compatible with commercial web based frameworks like .Net because the messaging standard used for these frameworks is XML based SOAP (Simple Object Access Protocol) protocol. To overcome the drawbacks of Web-DPR as outlined in this section, we have developed the next generation framework that embodies a Peer-to-Peer arrangement of agents. This framework is called XDPR (eXtensible Distributed Product Realization environment) because in this architecture, we use XML extensively for defining interfaces between agents and all the communication is based on XML based protocol – SOAP. This Peer-to-Peer topology facilitates direct communication between agents, without a central authority. This architecture removes the bottleneck at the web server. X-DPR is based on the international standards like XML, SOAP, and WSDL etc. that are widely accepted for web service development. This makes X-DPR compatible with other frameworks based on these standards. In Section 3.2, we present an overview of X-DPR and its main elements. 3.2. Overview of X-DPR In Figure 4, we show the topology of X-DPR.
6 American Institute of Aeronautics and Astronautics
Search toolbar
XML SOAP
Process Diagram construction toolbar
XML XML SOAP
Internet XML
SOAP
Client
Decision making toolbar File transfer toolbar
XML
SOAP
XML
SOAP
}
Process diagram
Figure 4 - Topology and information flow in XDPR
According to Ulrich15, modular product architectures Connection are divided into three types: a) Slot architecture Process diagram Task assigned between two to an Agent where each interface between components – or whiteboard agents agents in our case – are of different type from others, so that various components can not be interchanged; Figure 5 – Client application b) Bus architecture, where there is a common bus to which other physical components connect via the same type of interface; c) Sectional architecture, X-DPR is an open system in which different modules where all the interfaces are of same type and there is can be easily integrated to the system for enhancing no single element to which other components the functionality of the overall system. Engineers can connect. Web-DPR is based on the bus architecture integrate their own applications residing on their where all the agents can connect to the web server to machines with X-DPR, the idea being that this would provide services to the client. X-DPR is based on the help in creating a global library of engineering tools sectional architecture where each agent can connect over the Internet. This library can then be integrated to another agent because the interfaces between with tools from other areas like marketing, sales and agents are of same type – i.e. described in XML. The other business services to realize a global enterprise. flow of information between these agents takes place The system is designed such that a designer can through XML-encoded SOAP messages. easily model his/her design process using visual tools, as shown in Figure 5. Engineers can then connect their process models with services available in the global library over the Internet and execute their complete design process online. The framework has a capability of allowing engineers to collaboratively develop and execute their process models. This means that multiple designers distributed around the globe can work together as a team on a product realization project. This type of collaboration is demonstrated when we discuss the usage scenario of TIES process. In Section 3.3, we discuss the main components of the X-DPR framework and how engineers can use it for their needs.
7 American Institute of Aeronautics and Astronautics
3.3. Elements of the Framework
document for COM objects and WASP toolkit can be used for creating WSDL for java classes.
The most important element of the X-DPR framework is the Client application that provides access to all the available web services and is used to model and execute design processes. In the next few sections, we describe the Client application in further detail and show how agents are published on the internet and connected to the framework. Based on this information, the Client can dynamically generate a user interface into which the user can provide inputs to that agent. The process of dynamic generation of a user interface is also discussed in section 3.3.3. Finally, we describe an agent search service and a tool for mapping interfaces between different agents with different XML structures in order to achieve a seamless data flow between remote applications. 3.3.1.
Dynamic UI generation
A graphical user interface is necessary for dealing with the case where the input to the agent comes directly from the user. The interaction between the user and the agent through this interface may vary from case to case and agent-to-agent, suggesting a need for unique graphical user interfaces for each agent. Since it is not possible to create a separate user interface and code it into the client, a dynamic graphical user interface is created based on the number and type of inputs required by the agent. The mechanism of dynamic user interface generation is shown in Figure 6.
Client application
3.
The Client application, which is used to execute the available assets in the framework, is coded in Java and is platform independent. The main parts of this Client application are shown in Figure 5. The client application contains a white board on which the process diagram can be created by simple drag and drop utilities. The process diagram construction toolbar aids in this process of creating flow diagrams with blocks and connecting lines. These blocks are essentially various tasks in the design process. The connecting lines in Figure 5 indicate the flow of information between these tasks. The tasks are assigned to any of the web services available over the network. The search toolbar is used to search for available services. A Decision Support Problem Technique (DSPT)16 toolbar contains decision support tools for the design process. The DSPT toolbar contains a compromise Decision Support Problem solver and a selection Decision Support Problem solver. Lastly, the file transfer tool is used for sending and receiving files like CAD files to the agents. 3.3.2.
3.3.3.
Publishing a service
The agents are published in the X-DPR framework simply by creating the description file based on WSDL standard. The client retrieves the information from this WSDL description and creates a user interface for the agent. The WSDL documents can either be created manually or can be created automatically using commercially available toolkits. Microsoft SOAP toolkit can be used to create WSDL
Dynamically generated user interface
Client
1.
2.
4.
WSDL
Agent Figure 6 - Generation of dynamic user interface by the client The process of customized user interface generation follows the following steps: 1. The client searches for the WSDL document published by the service. 2. From the WSDL document, the client extracts the inputs and the corresponding data types. 3. The client generates the graphical interface for the user inputs. 4. Based on the data entered by the user, the agent is executed. 3.3.4.
Asset search service
The task of searching for agents appropriate for a particular task is implemented as a web service in
8 American Institute of Aeronautics and Astronautics
itself. This web service is called the search service. The search service basically maintains a database of links to WSDL files along with some description about the service. Currently, the database is populated manually and is created in Microsoft Access. However, the aim of search service is to maintain a running search on the Web for WSDL description files. Keeping the search service as a separate module is helpful because it can be developed independently of the framework and thus replaced with a different service at a later date. This also leaves open the possibility that if commercial web service search engines are developed at some point in the future, they might be integrated into the framework. 3.3.5.
Interface mapping tool
In a generic framework where different applications may provide vastly different functionality, it is very likely that the outputs of one service are not exactly the same as the inputs of another agent. In other words, it is reasonable to assume that the interfaces between agents are not standardized. Here, the interface refers to the structure of information being inputted and outputted by agents. For example, a variable may be referred to as “mass” by one agent and “weight” by another, when both really refer to the same information. XML
Information Information Information
XML
Information Information
Information
Figure 7 - Mapping of interfaces between various agents In this situation, there is a need to map these variables and define relationship between them. To achieve such a mapping of interfaces, the Interface mapping tool is created. This tool has the capability of mapping XML structure from output of one agent to XML input of another agent, as shown in Figure 7. The Interface mapping tool facilitates seamless flow of information between agents. This tool is implemented using X-Path, which is a language similar to the directory-naming scheme in Windows
that is meant to specify the path of an element in an XML document. Having discussed the main components of X-DPR, we now move on to a case study involving the Technology Identification, Evaluation and Selection (TIES) process. Through this usage scenario, we present how X-DPR can be used for integrating distributed activities. 4. A USAGE SCENARIO: THE TECHNOLOGY IDENTIFICATION, EVALUATION, AND SELECTION METHOD In carrying out design, engineers hope to create artifacts that address the shifting demands of the market for such factors as performance, affordability, and safety. When the demands of the market have shifted to a point where existing products no longer suffice in meeting market demands, designers are left with several options: • New products can be designed from the ground up. • Existing products can be redesigned or reconfigured to create a family of products. • New technologies can be investigated and developed as means of expanding the market coverage of existing or slightly-redesign products. The Aerospace Systems Design Laboratory at Georgia Tech has developed the Technology Identification, Evaluation, and Selection (TIES) as a generic method whereby the third option may be explored while keeping the focus of the design problem on system affordability –as opposed to the old paradigm of design with only system performance in mind17. TIES is a demonstrated preliminary design tool, having been used for numerous applications including missiles18, tiltrotor aircraft19, commercial transport aircraft20, aircraft engines21, and a high-speed civil transport22. It is chosen as a case study for this work due both to its proven utility and to the fact that it is made up of a series of discrete activities that might reasonably be split up between individual members of a distributed product realization team. 4.1. An Introduction to TIES TIES is an eight step iterative method, as illustrated in Figure 8. The goal in carrying out TIES is to generate a feasible design that meets, maximizes, or minimizes system metric goals –whichever is desired- while determining the optimal combination
9 American Institute of Aeronautics and Astronautics
of new technologies to help achieve these goals. The method begins with the definition of the problem and the customer requirements in the first step. Next, feasible design alternatives are identified and described. In the third and fourth steps, the alternatives are modeled mathematically in order to determine the values of key system metrics for each. These metrics are compared to goals and constraints in the next step to determine which, if any of the feasible alternatives measures up to the customer criteria set forth in the first step. If feasible alternatives are found that match these criteria, the process can stop. If no feasible and affordable alternatives exist, the next step is to identify a group of new or emerging technologies that might have a positive effect on the system and quantify these effects probabilistically. The seventh step involves a process similar to that of the third and fourth steps, the difference being that combinations of new technologies are used as variables to determine the
optimal set to improve system metrics. In the final step of the process, a suite of tools is used to help the decision maker determine which combination of technologies should be used to enhance system effectiveness. For further details on this process, readers should consult Kirby, 20013. 2. Baseline and alternative concepts definition
1. Problem Definition
3. Modeling and Simulation
4. Design space definition
Iterative 8. Selection of Technology Combinations
7. Technology Evaluation
6. Technology Identification
5. Examination of system feasibility
Figure 8 - Summary of Technology Identification, Evaluation and Selection method
S creening E xp erim ents D efinitio n o f P ro b lem
DOE
S im ulatio n
R esp o nse S urface M o d eling
S creening E xp erim ents
A ctual E xp erim ents M o nte C arlo S im ulatio n
R esp o nse S urface M o d eling
S im ulatio n
Techno lo g y E valuatio n Techno lo g y Id entificatio n
DOE
S im ulatio n
R esp o nse S urface M o d eling (k- facto rs)
DOE
Techno lo g y S electio n (TO P S IS /U tility B ased )
Figure 9 - Flow diagram of the web-based TIES process 4.2. Benefits of a Web-Based TIES System There are several drawbacks to current implementations of TIES. First, they typically require that the designer executing the process have direct access to a variety of different software programs. Specifically, unique programs may be needed for various different aspects of the TIES method, including modeling and simulation, design of experiments, analysis of variance, Monte Carlo simulation, and response surface generation. Some of these programs may have to be run on different computing platforms. Because many of these different programs do not interface directly with one
another, files and/or individual pieces of data must often be moved or manipulated by hand. All of this means that in order to carry out TIES, a designer must be an expert in the inner-workings of the software applications and must have direct access to a computer with all of the necessary software installed on it. Both of these requirements place restrictions on who can use TIES. The latter requirement also limits the usefulness of current implementations of TIES in a distributed environment to those who have all the needed software on-hand. A distributed team of designers trying to utilize TIES for preliminary design decides how best to distribute
10 American Institute of Aeronautics and Astronautics
and utilize the necessary software assets. One conventional option is to make each software asset available to every team member by installing and running it locally. Another option entails installing only those software assets needed for the certain modules of TIES for which the team member is considered an expert. Both of these options have drawbacks, the former in the time and storage cost of installing every piece of software in every location from which a team member might work, the latter in the inability of team members to inspect or collaborate on modules that fall outside their realm of expertise. Two basic premises of our vision of the future of design and engineering are the idea of teams working collaboratively and from distributed locations. The drawbacks of the existing conventional TIES implementations seem to make them ill suited to use in the future design environment that we envision. For these reasons, it is be worthwhile to explore how TIES might be specially tailored to use on a distributed framework like X-DPR.
Table 2 - Implementation of various tasks in TIES process using software agents Tasks
Inputs
Agents / Impleme ntation software
Outputs
1. Definition of design space
User input
Developed in-house
XML file containing information about system variables
XML file containing information about system variables
iSIGHT
XML representation of various experiments
2. DOE
XML representation of various experiments
Application specific
Values of response variables for various experiments
4. Response Surface Modeling
XML file containing values of inputs and response values
iSIGHT
Coefficients of response surface equations relating inputs and responses
5. Screening
Response Surface equations
iSIGHT/JMP (Pareto plots, Prediction profiler) + Manual
Reduced number of design variables
6. Monte Carlo simulation
Response Surface equations
Crystal Ball / Excel
Information about feasibility of technologies
7. Technology Identification
Morphologic al matrix about available technologies
Manual
Technology Impact matrix
8. Selection of technologies
Manual input about preferences by designer, information about available technologies
Utility based selection
Possible technologies to proceed with
3. Simulation
4.3. Mapping Agents to the TIES Method The modules in the web-based TIES process are shown in the flow diagram in Figure 9. The process is divided into three major steps: screening experiments, actual experiments and technology evaluation. In Table 2, we show how the agents or software applications assigned to each of the individual tasks in a TIES process as well as the input and output information for each task. Before the screening experiments, the problem is defined. The system level metrics in terms of design and noise variables are identified. This task of identifying the system variables based on the customers’ requirements is generally carried out manually. These variables are assigned ranges to limit the design exploration space. The information is inputted in the system through an agent called Design Space Definition agent. The agent has the capability of taking the information about design variables from the user and storing this information in an XML file (Table 2). The agent takes information about both the input variables and the output variables. The information required for defining input variables is different from those required for outputs. Hence, the agent provides two functions: “defineVariable” and “defineResponse”.
(Design of Experiments module)
(Approximati ons module)
Through the screening experiments, a designer gets an idea about design factors that have a large effect on the responses and the factors that do not have large influence on responses. The screening experiments are performed to reduce the number of design variables and reduce the design space. The screening experiments (see Figure 9) involve
11 American Institute of Aeronautics and Astronautics
selecting various points in the design space and carrying out simulation on those points. These points are selected from the continuous design space by using a design of experiments technique.
service for design of experiments module of TIES (Table 2). An XML based wrapper for iSIGHT is created as a part of this work that provides an XML interface to iSIGHT. This wrapper converts the XML representation of iSIGHT input file into iSIGHT’s native file format – MDOL (Multi-Disciplinary Optimization Language). The wrapper also converts the output of iSIGHT, an application specific “.db” file, to an XML file. The mechanism of information transfer in iSIGHT wrapper is shown in Figure 10.
Approximate algebraic relations between design factors and responses are developed. These relations are used to predict the response on points where simulation is not performed. Based on the factorresponse relationship, the factors that have most impact on the responses are determined by using Pareto analysis.
The Simulation agent is dependent on the particular problem on which TIES is being employed (Table 2). For instance, in the High-Speed Civil Transport design case study described by Kirby 3, existing physics-based modeling and synthesis codes for aircraft including FLOPS (Flight Optimization System) and ALCCA (Aircraft Life Cycle Cost Analysis) were used. Where they do not already exist, these codes must be generated on a case-bycase basis. The Response Surface Modeling agent is developed using the approximations module of iSIGHT. This agent takes an XML file containing the system variables and responses as input (Table 2).
The agents that are required in screening experiments are: Design of Experiments, Simulation, Response Surface Modeling and Pareto Plotting. All of these agents depend on information about the input variables that is gathered in the Design Space Definition agent. From the variables and ranges, a set of combinations of input variables is generated. Design of experiments is carried out in this case study by a commercial package iSIGHT developed by Engineous Software Inc. The design of experiments module of iSIGHT is deployed as a web
XML representation of MDOL
iSIGHT specific input (MDOL)
iSIGHT
iSIGHT specific output (.db file)
XML file
re s p o n s e s u rfa c e c o e ffic ie n ts
re s p o n s e s u rfa c e e q u a tio n s
Figure 10 - Flow of information in the iSIGHT wrapper
X M L file c o n ta in in g in p u to u tp u t d a ta
iS IG H T s p e c ific ".d b " file
iS IG H T
Figure 11 - Response Surface Modeling agent using iSIGHT The output is a file containing all the response surface coefficients for the system metrics. For ease of use with the Compromise DSP solver, the response surface coefficients are converted into an algebraic equation that can directly be sent to the Compromise DSP solver’s input XML file. The mechanism of information transfer in response surface modeling agent is shown in Figure 11. From the response surface models, the Pareto Plotting agent generates plots and the designer identifies the design factors that have more influence on the responses. The outcome of screening experiments is a new set of reduced number of
variables that can be used for the generation of response surfaces. The procedure whereby the response surfaces are generated is similar to that used in the screening experiments, except that instead of carrying out Pareto analysis, a response surface is generated and tested using Monte Carlo simulation. The Monte Carlo simulation is carried out in Excel with a Crystal Ball add-in installed (Table 2). From the Monte Carlo simulation, the system’s feasibility and viability is assessed based on the probability of that system achieving a target.
12 American Institute of Aeronautics and Astronautics
If the system is infeasible, i.e., the constraints are not met, then the option is to infuse new technologies. First, a set of technologies that may hold promise for improving the system are identified and checked for compatibility with one another. For each of these technologies, a “k-factor” array is created to express the improvement or detriment that it would have on a group of system variables. The information from the k-factors and from forecasts of the readiness levels of the technologies is fed into a design of experiments agent as shown previously, goal being to generate a response surface model of effects of the technologies on the system metrics. Simulation and response surface modeling follows the design of experiments. From the relation between k-values for technology combinations and response, we select the technologies by utility-based selection technique (Table 2). 4.4. Deploying and Using Assets as Services The TIES process and various computational assets (or tools) required for carrying out the TIES process are discussed in Section 4.3. These assets include tools that support design space definition, design of experiments, simulation, response surface modeling, the Monte Carlo simulation, and Pareto plotting. All of these tools are published as services in the Webbased X-DPR framework for TIES and can thus be accessed from a client application like that shown in Figure 5. In Table 2, we present the list of software tools that correspond to the design process activities shown in Figure 8, along with the input and output information for each activity. To achieve interoperability and seamless flow of data between different services, all of the services in the framework take input in XML format and provide output in XML format. The capabilities of these services are published in the form of WSDL documents (as discussed in Section 3.3.2). The WSDL file contains the information about inputs that the service can take and the outputs that this service can provide. The description of inputs and outputs in the WSDL files can then be used by the mapping tool shown in Figure 7 to create a mapping of the information flow between all of the services. After these software tools are published over the Internet as web-services, a designer can utilize them from a remote location using the client application. In the client application, the designer creates a process diagram that represents each task (the tasks are listed in Table 2) with a node and the information flowing between the tasks as links between the nodes (Figure 8). Each node in the process diagram is
assigned to a web-service and executed over the Internet. 4.5. A Brief Design Scenario Coming back to the scenario described previously in Section 1, let us imagine that the company engaged in the design of the supersonic business jet has decided not to move all of its design and marketing experts to one facility to explore the feasibility of the project. Instead, they will employ TIES on the XDPR framework. To do this, the distributed team would first have to meet using video or teleconferencing to establish the problem, define the system level metrics, and define the design space. From this point on, each step of the TIES process would be carried out using distributed services. First a group of services would be utilized to perform a screening test and narrow down the design space. At this point, some members of the team would have to be involved in deciding which concepts should be carried to the next phase. Those concepts would be passed on to the distributed assets that would generate response surfaces and calculate the likelihood that the best concepts will meet the goals for the system-level metrics. If the team found that the best concept or concepts do not have an acceptable likelihood of success, they would then meet again in a virtual environment to discuss options for new technologies. Experts in the field of emerging technologies might also be called upon at this point to quantify the future impacts of the technology, creating data that could be passed onto the remote services that would evaluate the effects of the new technologies on the best concepts. The team members would then each input his or her preferences into the technology selection service to generate a personal list of best concepts to bring to the next virtual meeting of the design group, at which overall feasibility of the system would be discussed and “best” concepts identified. The scenario explained above is brief, oversimplified, and skips many of the key details of the design procedure for the sake of brevity. It is meant only to express how a framework like X-DPR could be used to allow a distributed team of designers to use existing design methods like TIES without requiring all of them to be in the same physical location. The example is also not limited to TIES. Given time to develop the web-based services, almost any other offline tool or method can be converted into a web-based tool as with the case of TIES in this project.
13 American Institute of Aeronautics and Astronautics
5.
CLOSURE
6.
In this paper, we outline the development of a nextgeneration distributed computing framework for supporting design processes. In discussing the basic structure of the framework, we placed emphasis on describing the work that is done using XML to create a peer-to-peer architecture for X-DPR. The utility of X-DPR is described in the case of the Technology Identification, Evaluation, and Selection (TIES) method. In the exercise, TIES is transformed from a primarily off-line systematic design tool that required local access to a suite of software applications and numerous steps to a streamlined, platform independent utility accessible from any web-ready computing platform anywhere on earth. Not all modules of TIES are realized using the X-DPR framework. Most notably the modeling and simulation environment, which is likely to change from example to example, is not implemented due to time constraints. In addition, numeric examples of the functionality of the web-based TIES method are provided here for the sake of brevity, but can be discussed in future publications. We believe that the X-DPR framework provides a robust, flexible, discipline-independent foundation on which future distributed design can take place. Opportunities for future work do exist in the complete implementation of TIES for a case study that would include the modeling and simulation environment. Implementation of another non-webbased method like TIES might also provide useful information. X-DPR is shown in Section 4.3 as an infrastructure that can be used in managing and utilizing available software assets remotely for realizing a distributed design environment. Future work can be carried out in the direction of developing standards for capturing and converting engineering information into knowledge. One avenue of future work that we are particularly interested in would involve the use of XDPR as the framework for a proposed web-based strategic design platform1 that the Systems Realization Laboratory at Georgia Tech continues to investigate as a potential tool for the combined forecasting of changes in markets, requirements, and technological capabilities and design of artifacts that swiftly and easily accommodate these changes. XDPR would serve as the computing backbone that allowed such a platform to be useful to tomorrow’s distributed engineering design teams.
ACKNOWLEDGEMENTS
We gratefully acknowledge the support of National Science Foundation grants DMI-0100123, DMI0085136, and DMI-9618039. Matt Chamberlain is a NSF Graduate Research Fellow, a Georgia Tech Presidential Fellow, and has been supported by both Rohm and Haas, Inc and ONR grant #N000140110267. 7.
REFERENCES
1.
Seepersad, C.C., F.S. Cowan, M.K. Chamberlain, and F. Mistree. 2002,"Strategic Design: Leveraging and Innovation for a Changing Marketplace". Proceedings of the Engineering Design Conference 2002, King's College London, UK.
2.
Xiao, A., H. Choi, R. Kulkarni, J.K. Allen, D. Rosen, and F. Mistree. 2001,"A Web-Based Distributed Product Realization Environment". ASME Computers in Engineering Conference, Pittsburgh, PA, Vol DETC2001/CIE-21766.
3.
Kirby, M.R., 2001, "A Methodology for Technology Identification, Evaluation, and Selection in Conceptual and Preliminary Aircraft Design: PhD Dissertation, School of Aerospace Engineering, Georgia Institute of Technology, Atlanta, GA.
4.
Williams, S. and M. Jones, 2001, "Protocol Abstract Model," World Wide Web Consortium, http://www.w3c.org/TR/xmlp-am.
5.
1998, "DCOM Technical Overview," Microsoft Corporation, http://www.microsoft.com/com/tech/DCOM.asp.
6.
2002, "Javabeans Component Architecture Documentation," Sun Microsystems, Inc., http://java.sun.com/products/javabeans/docs/inde x.html.
7.
Marcato, D., 2000, "Distributed Computing with SOAP," http://www.devx.com/upload/free/features/vcdj/2 000/04apr00/dm0400/dm0400.asp.
8.
Gerhard, J.F., D. Rosen, J.K. Allen, and F. Mistree. 2000,"A Distributed Product Realization Environment for Design and Manufacturing". Computers and Information in Engineering Conference, Baltimore, MD, Vol DETC00/CIE14624.
9.
Pancerella, C.M. and R.A. Whiteside, 1998, "The Integration of Manufacturing Enterprises Using CORBA." International Journal of Agile Manufacturing,vol. 1(2): pp. 155-172.
10.
Xiao, A., J.K. Allen, D. Rosen, and F. Mistree. 2000,"A Method to Design Product Architecture
14 American Institute of Aeronautics and Astronautics
in a Distributed Product Realization Environment". 9th International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, Gaithersburg, MD. 11.
Kulkarni, R., 2001, "A Web-Based System for Distributed Product Realization: MS Thesis, G.W. Woodruff School of Mechanical Engineering, Georgia Institute of Technology, Atlanta, GA.
12.
2002, "iSight Overview," Engineous Software Inc., http://www.engineous.com/products.htm.
13.
Choi, H., 2001, "A Framework for Distributed Product Realization Environment: MS Thesis, G.W. Woodruff School of Mechanical Engineering, Georgia Institute of Technology, Atlanta, GA.
14.
2001, "Phoenix Integration: Products," Phoenix Integration Inc., http://www.phoenixint.com/products/index.html.
15.
Ulrich, K., 1995, "The Role of Product Architecture in the Manufacturing Firm." Research Policy,vol. 24(3): 419-440.
16.
Bras, B.A. and F. Mistree, 1991, "Designing Design Processes in Decision-Based Concurrent Engineering." SAE Transactions, Journal of Materials and Manufacturing,vol.: 451-458.
17.
Kirby, M.R. and D.N. Mavris. 2000,"A Method for Technology Selection Based on Benefit, Available Schedule and Budget Resources". 5th World Aviation Congress and Exposition, San Diego, CA, Vol SAE Paper 2000-01-5563.
18.
Roth, B. and D.N. Mavris. 2000,"Evaluation and Selection of Technology Concepts for a Hypersonic High Speed Standoff Missile". AIAA 2000 Missile Sciences Conference, Monterey, CA.
19.
Mavris, D.N., A.P. Baker, and D.P. Schrage. 2000,"Technology Infusion and Resource Allocation for a Civil Tiltrotor". AHS Vertical Lift Aircraft Design Conference, San Diego, CA.
20.
Mavris, D.N. and M.R. Kirby. 1999,"Technology Identification, Evaluation, and Selection for Commercial Transport Aircraft". 58th Annual Conference of Socity of Allied Weight Engineers, San Jose, CA.
21.
Roth, B., B.J. German, D.N. Mavris, and N. Macsotai. 2001,"Adaptive Selection of Engine Technology Solution Sets from a Large Combinatorial Space". 37th Joint Propulsion Conference and Exhibition, Salt Lake City, UT.
22.
Mavris, D.N., M.R. Kirby, and S. Qiu. 1998,"Technology Impact Forecasting for a High Speed Civil Transport". 3rd World Aviation Congress and Exposition, Anaheim, CA.
15 American Institute of Aeronautics and Astronautics
