multi-user architectures for computer-aided engineering collaboration

Proceedings of the 2011 17th International Conference on Concurrent Enterprising (ICE 2011)

Klaus-Dieter Thoben, Volker Stich and Ali Imtiaz (Eds.)

ISBN: 978–3–943024–05–0

Copyright © 2011 FIR e.V. an der RWTH Aachen www.ice-conference.org of 10

Multi-User Architectures for Computer-Aided

Engineering Collaboration

Edward Red1, Gregory Jensen

2, David French

3, Prasad Weerakoon

4

1Mechanical Engineering, Brigham Young Univ., Provo, UTAH 84602, USA, [email protected] 2Mechanical Engineering, Brigham Young Univ., Provo, UTAH 84602, USA, [email protected]

3Mechanical Engineering, Brigham Young Univ., Provo, UTAH 84602, USA, [email protected] 4Mechanical Engineering, Brigham Young Univ., Provo, UTAH 84602, USA, [email protected]

Abstract

Concurrent engineering, defined as product development by teams working in parallel, is severely limited by the

serial functionality of modern computer-aided applications (CAx) like CAD/CAE/CAM. Ultimately, any develop-

ment project is decomposed into assemblies and components which are then sub-divided into single models. Each

model is then assigned to one technical person: designer, analyst, or process planner. The function of this paper is to

consider CAx architectural changes that will allow product teams to concurrently and simultaneously collaborate on

product models. Several prototypes will demonstrate multi-user effectiveness, and expose collaborative and

architectural deficiencies in modern CAx tools.

Keywords

Multi-user collaboration, collaborative architectures

1 Introduction

Concurrent engineering is limited by the serial design of modern CAx tools like

CAD/CAE/CAM; these tools limit model and assembly creation and editing to one active

user/engineer. Collaborators are restricted to an observer’s role or to sharing a mouse through a

sharing application. Each assigned user independently edits the design, analysis, or manufactur-

ing model as the product floats down the design stream. Any modelling error or manufacturing

resource deficiency will necessitate model changes and divert the model modifications upstream

in a convoluted feedback system that lengthens the product development cycle. These present

methods are the antithesis of concurrent engineering and the very reason of three decades of

under achieved/realized concurrent engineering research.

What is the root problem? Simply stated - our modern computer operating systems and

engineering applications are based on architectures designed for single users: one active

application and one active cursor. This paper proposes CAx architectural changes that will allow

product teams to concurrently/simultaneously collaborate on product models. We acknowledge

the excellent research conducted in multi-user CAD over the last decade, and note the emergence

of a few multi-user tools like Google Docs - see the extensive literature review by [Red, et al.

2010].

Several prototypes will demonstrate multi-user effectiveness, and expose collaborative and

architectural deficiencies in modern CAx tools. The prototypes presented in the paper consist of

multi-user versions of Siemens NX (NX Connect), Siemens NX with an integrated Skype

interface (NX Skype) and CATIA (CATIA Connect), and the first multi-user finite-element

analysis (FEA) pre-processor based on the Cubit FEA software supported by Sandia Labs (Cubit

Proceedings of the 2011 17th International Conference on Concurrent Enterprising ICE 2011


Connect). In addition the paper considers important issues for multi-user interfaces, under the

acronym MUG which stands for Multi-User Graphical user interfaces.

2 NX Connect

NX Connect, as an add-on to the existing CAD package Siemens NX, allows multiple users to

access and make changes simultaneously to a single part file, Figure 1. This prototype software

was designed in C# to investigate the limitations of collaborative modelling using a primary

commercial CAx application, rather than develop a new application from the ground up. NX

Connect allows multiple users to open and actively make changes to a part file simultaneously.

Each user can view the part independently and zoom and rotate without affecting the view of the

remaining users.

NX Connect utilizes Client-Server (CS) with a thin server and strong client. The server stores

the data for the part file and broadcasts changes to each client workstation. Each client maintains

a local copy of the part file which is constantly updated. NX Connect uses four custom modules

as shown in Figure 1b.

The Information Storage Module (ISM) in the server stores the part features and related data,

including all information relating to part location and multi-user access. We applied Microsoft’s

SQL Server as the RDMS which is easily accessible by calls made in C#. A series of tables are

created and linked together to organize the various data types. A hierarchical structure was

implemented where each part stored in the Parts table is assigned a Part ID which is then used in

the child table that contains all of the features, Figure 1c.

Two modules were developed to monitor and store model changes that were continually

broadcast to all clients: 1) Data Capture Module (DCM) and 2) Data Sync Module (DSM).

Data Capture Module - The DCM monitors the NX session to determine when changes have

been made to the part file. When a change is detected the DCM determines the feature that has

been created, modified, or deleted and then alerts the NX Controller of the change, then passing

the change information for the modified feature.

Data Sync Module - The DSM monitors the ISM to determine if any changes have been

uploaded by another user. Upon finding a change to the database, the NX Controller is alerted to

the changes.

NX Controller - This module converts all part information into their primitive values for storage

in the database, as well as converting these parameters back into useful data to construct the

corresponding features in the NX session on each users machine. When the DCM reports a

a) CS architecture b) NX Connect modules c) Server feature attributes

Server

Client

Figure 1: NX Connect architecture



change in the local NX part file, the controller gathers all pertinent information about the

modified feature by utilizing the NX API. Using API commands the controller determines the

feature type and then deconstructs the feature into the basic parameters such as extrude start and

stop distance, draft angle, and Boolean type. If a sketch is used for the specific feature the

controller stores the sketch name for later name reference. All such information is sent to the

corresponding table in the database for distribution to each user.

After a user modifies the existing CAD document, and changes are uploaded to the database, the

DSM alerts the Controller of a change ready to be distributed to each user. The NX Controller

will then read the feature data and place each parameter in the appropriate API function to

recreate locally the feature or modification on all user workstations.

Figure 2 shows three client multi-users simultaneously building a jet engine front frame in

various stages of coordination. The final model is shown in Figure 4d. The design time required

for three users was about 1/3rd

the time for a single user, although some preliminary coordination

planning was required.

3 NX Skype

The NX Skype prototype was designed for two purposes: 1) to show that a popular collaborative

tool like Skype could be integrated inside Siemens NX, and thus provide a means of on-line

communication between distributed collaborators; and 2) to demonstrate a method that allows

design rationale communicated between distributed users to be captured, stored and retrieved

[Mix, et al. 2010].

Key to this method is a tight integration between current industry CAx tools and computer-based

VoIP software. The method focuses on minimizing user interaction with the system to increase

adoption and long-term future use of the system. Figure 3 shows several intermediate interac-

Figure 2: NX Connect front frame multi-user session

a) Client 1 b) Client 2

c) Client 3 d) Design done



tions between two users as one user queries another user for a part dimension. This early

prototype implemented IM and audio to multiple modelling collaborators, but did not provide a

video interface.

Figure 3: NX Skype session

4 CATIA Connect

The CATIA Connect prototype uses a CS architecture similar to NX Connect, but the Visual

Basic version for CATIA (VBA) could not make calls to the SQL database directly. Thus, we

used Microsoft SQL Server 2008, but resorted to intermediate text files and a C# program to

communicate with the server.

VBA detects new features, then writes the data to a text file in JSON format (JavaScript Object

Notation - a lightweight data-interchange format). VBA calls an executable program created

from C# which reads the output text file and sends those changes to the database. The executa-

ble then calls the database to fetch new features from other users and creates a second text file (in

JSON-format) that VBA then reads in to create new parts from other users.

The first multi-user session tutorial re-created the previous jet engine front frame while

demonstrating the ability to create pads, shafts, pockets, grooves, and circular patterns with

complete crown. The interfaces were developed using the CATIA Visual Basic API, since the

CATIA C++ API is quite difficult to use.

Several of the user instructional steps that follow show a few of the coordinated actions. We also

note that the user activity periods were sometimes staggered to demonstrate that users could

enter or depart a multi-user session at any time. It is also important to note that in this implemen-

tation that entities created by one modeller could easily be taken and patterned by another

modeller. The final CATIA design looked very similar to that shown in Figure 2d.

4.1 User 1

Step 1 - To create the front frame’s inner case, make the sketch of Figure 3 in CATIA V5 on the

XY plane and use it to create a 360 degree shaft (CATIA solid of revolution) around the Z axis.

Dimensioning the part Bringing up a buddy

Skype integrated into Siemens

After user help on proper dimension, user exits

and saves interaction history



Step 2 - Update CATIA Connect after completing the shaft. Figure 4 shows the inner case along

with the bypass case and a vane (created by users 2 and 3).

Figure 3: Sketch plane cross-section of inner

case

Figure 4: Revolved inner case and other client

additions

4.2 User 2

Step 1 - Create the middle rim by making the sketch of Figure 5 on the XY plane and revolving it

for a 360 deg shaft. The thickness is 0.1 inches with the front constrained along the V axis.

Figure 5: Sketching and revolving the middle rim

Step 2 - Create the sketch for the fin attachments on the surface of the bypass case, Figure 6.

Create a circular pattern with 10 instances of the feature using the complete crown method and

any of the cases as the reference axis, Figure 7.

Figure 6: Sketching vane boss

Figure 7: Apply 10 instances of extruded pad



4.3 User 3

Step 1 - Build the vane by making the sketch shown in Figure 8 on the new plane and pad it 1

inch to -2 inches. Update part. Edge of fin is constrained to edge of case and arc is tangent to

both lines.

Step 2 - Pattern the vane in a complete crown circular pattern with 10 instances using any case as

a reference; see Figure 9.

Figure 8: Sketch a vane

Figure 9: Pattern the vane

5 Cubit Connect

Cubit is a mesh generation tool developed primarily by Sandia National Laboratories. Cubit

comprises two distinct portions: 1) Cubit Core (executes the FEA method); and 2) Claro

(Graphical User Interface). The Core and the GUI communicate with each other using a C++

method called Cubit Interface as shown in Figure 10. Since we had access to the Cubit source

code we were able to program in C++ to develop our prototype within Cubit Interface.

Figure 10: Cubit Connect Interface

Whenever the user creates geometry, mesh, etc. a command string is automatically generated and

passed through to the Cubit Core through the Cubit Interface. That command is then executed

and the results are passed back to the GUI for displaying through the same interface.

In the multi-user mode each user is able to:1) skew elements; 2) apply loads; 3) apply constraints

around their locality; and 4) use their cursor independent of other user cursors. A P2P network-

ing client was built with Qt Creator and modified for this purpose as shown in Figure 11.

Under investigation is how to filter update commands from other clients/users. A propagated

client command may stop the current user from editing the model for minutes or hours while the

FEA algorithms are executed. Figure 12 shows three users simultaneously editing the elements

on a race car, each assigned a different region.



Figure 12: Cubit Connect multi-user session

6 MUG (Multi-User Graphical Interface) Prototype

Yue Xu investigated contextual preferences for a MUG [Xu, 2010]. Product collaboration

involves technical personnel from different backgrounds and cultures. New multi-user interfaces

must be able to set context preferences for each multi-user. Contextual changes in a user’s MUG

must not affect the application data communicated among multi-users and be general enough to

integrate into any multi-user CAx application regardless of distribution network type with these

User 2

Intercept

Commands

CUBIT CORE

Filter

Output file

Network Client

Pass commands to

the entire network

(to peers)

Read output file

Read incoming

command strings

from network

(from peers)

Write incoming

commands to

input file

Input file

Read file & pass the

commands to Core.

To Cubit GUI

Write commands to file

To peer users

Figure 11: Cubit Connect communication

User 1

User 3



contexts: 1) display control contexts - each user will set a display mode context, which identifies

whether user remote sessions and their screen displays are to be observed locally; 2) communica-

tion contexts – allow multi-users to communicate by video, audio/voice, text, and emotive icon;

3) supervisory control contexts - provide both a teaching context and a management context; 4)

security contexts – allow supervisors to set the collaborative access rights to CAx application

model data or extend participation rights to supply chain personnel who can identify current

problems in obtaining material resources, or supply chain limitations in globally distributed

design and manufacturing facilities; 5) recording context –recognize the importance of and

record multi-user CAx sessions as these sessions generate product development histories, and

include critical design and manufacturing intent and decisions.

As an interface layer on top of the CAx application the proposed MUG will separate the model

from the view. Contextual changes in a user’s MUG will not affect the application data inherent

to any multi-user application.

In Xu’s early prototype three users logged in as John, Lu and April and the group collaborated to

design a turbine engine front frame that required multiple features. Table 1 displays some of the

interaction contexts and sequence.

April wanted to watch John’s screen to make sure there was no intersection of their respective parts.

John accepted her request and gave April full screen access.

Later April sent John a text requesting that she be able to view his workspace.

John changed his view setting based on April’s request. Then, April sent a request to watch Lu’s

screen.



Lu received the message and translated it into Chinese, Lu’s native language, using Google Translator

accessed through the MUG.

Shortly thereafter, April sent several text messages to Lu and Lu used the Google Translator. He

figured that it might be easier to understand April’s intent using the remote view.

Later, April sent an alert to Lu and John and notified them that the model had appeared to be finished.

Table 1: NX MUG Demo

7 Architectural Considerations

The paper has reviewed several network architectures to measure collaborative effectiveness, but

our observations are still very preliminary. In the near future the prototypes will be transitioned

to a cloud serving architecture where effectiveness will depend on network latencies, and may be

ineffective across widely distributed global networks, unless the cloud servers are also distribut-

ed and updated accordingly using update timers and buffers. Cloud serving collaboration should

prove very effective in local infrastructure networks, and provide for enhanced security.


Copyright © 2011 FIR e.V. an der RWTH Aachen www.ice-conference.org of

10

The paper has considered several prototypes and research to draw conclusions as to single user

architectural limitations in modern OS’s and commercial CAx applications. For example, the

architectural access to CAx applications is limited by their API interfaces. The exception is Cubit

Connect where we had source code access. In general we get no direct access to the event

handler; we thus use undo marker files to access model parameter changes in a multi-user

environment.

API’s provide handles to geometric objects (memory addresses) that cannot be passed to other

multi-users over a network since memory locations on each computer vary. Our prototypes

required extensive programming to extract the parameters from the data structures. Multi-user

CAx will need API’s that provide the parameters directly, like copying the object, rather than just

memory addresses to the object.

CAx applications have a concept of a single display screen, a single viewpoint, and a single

cursor. Modern CAx GUI’s are built for single users and are not intended to be shared by multi-

users. Users cannot simultaneously view the model from different viewpoints or simultaneously

edit the model parameters in the same GUI.

Event interrupts are not available in API calls that signal parameter changes inside the CAx

application. Interrupts would keep the computer from busy-wait polling, and switch a context to

an interrupt handler. Interrupts make it easy to add new functions such as a sound alert when the

server receives a new update and sends it to each client.

Undo sequences do not recognize multi-user input and user undo histories are vulnerable to undo

actions by multi-users. This major architectural deficiency must be addressed by CAx developers

before multi-user collaboration can be practical.

8 Summary

It seems evident to the authors that multi-user collaboration is both feasible and desirable, given

that a few architectural modifications are made to CAx software functionality. Product timelines

can be reduced in proportion to the number of collaborators, and design rationale better

managed. The important point is that these changes are not major and can be implemented in

some future software release of popular CAx applications.

It was easier to convert Cubit to multi-user because we had access to the source code and only

had to filter the commands sent to peers. In the case of CATIA or NX the API functionality was

limited and had to be implemented bit-by-bit. Effectively, we had to write distinct code for each

implemented function.

What may be more difficult is the configuring of an optimal interaction environment for people

of different cultures and backgrounds. How can new tools of collaboration protect the intellectual

property of companies that interact to develop new products? Security and collaboration contexts

will be important future research topics.

References

Red, E., et al, (2010) “-CAx: A Research Agenda for Collaborative Computer-Aided Applications” Computer-

Aided Design and Applications, vol. 7, no. 3, pp. 387-404.

Xu, Y. (2010)A Flexible Context Architecture for a Multi-User GUI. Master’s Thesis, Brigham Young University,

December.

Mix, K. J., Jensen, C. G., and Ryskamp, J., (2010) “Automated Design Rationale Capture within the CAx

Environment” Computer-Aided Design and Applications, vol. 7, no. 3, pp. 361-375.

multi-user architectures for computer-aided engineering collaboration

Documents