This article was downloaded by: [UQ Library]On: 06 November 2014, At: 19:48Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House,37-41 Mortimer Street, London W1T 3JH, UK

International Journal of Computer IntegratedManufacturingPublication details, including instructions for authors and subscription information:http://www.tandfonline.com/loi/tcim20

A hierarchical federated integration architecture forcollaborative product developmentHongbo Sun a b , Wenhui Fan a , Weiming Shen b , Tianyuan Xiao a & Qi Hao ba National CIMS Engineering Research Centre, Tsinghua University , 100084 , Beijing , Chinab Centre for Computer-assisted Construction Technologies, National Research Council ,London , Ontario , Canada , N6G 4X8Published online: 14 Sep 2011.

To cite this article: Hongbo Sun , Wenhui Fan , Weiming Shen , Tianyuan Xiao & Qi Hao (2012) A hierarchical federatedintegration architecture for collaborative product development, International Journal of Computer Integrated Manufacturing,25:10, 901-913, DOI: 10.1080/0951192X.2011.608722

To link to this article: http://dx.doi.org/10.1080/0951192X.2011.608722

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) containedin the publications on our platform. However, Taylor & Francis, our agents, and our licensors make norepresentations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of theContent. Any opinions and views expressed in this publication are the opinions and views of the authors, andare not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon andshould be independently verified with primary sources of information. Taylor and Francis shall not be liable forany losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoeveror howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use ofthe Content.

This article may be used for research, teaching, and private study purposes. Any substantial or systematicreproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in anyform to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

A hierarchical federated integration architecture for collaborative product development

Hongbo Suna,b*, Wenhui Fana, Weiming Shenb, Tianyuan Xiaoa and Qi Haob

aNational CIMS Engineering Research Centre, Tsinghua University, 100084 Beijing, China; bCentre for Computer-assistedConstruction Technologies, National Research Council, London, Ontario, Canada N6G 4X8

(Received 25 December 2010; final version received 16 July 2011)

Collaborative product development (CPD) is concerned with various experience, knowledge, teams, tools andprocesses. Since simulation is an important stage of CPD, high level architecture (HLA) has been successfullyadopted as basic architecture of CPD systems. At the same time, HLA-based (federated) CPD systems also havesome difficulties. Among these, effective communication and cooperation among these disparate parties are keychallenges. In this article, a hierarchical federated integration architecture for heterogeneous information systems isproposed. Different from the tightly coupled collaborative systems for fixed-scenario collaborative jobs, theproposed architecture is more suitable for dynamic, loosely coupled and multi-objective collaborations. Under thisarchitecture, cooperation individuals are the projections (ambassadors) of real subsystems on given applicationdomains. The control scope of subsystems and the management scope of collaboration can be different in order toavoid exploring too many details about the subsystems and to maintain their independency. The owners ofsubsystems can fully control their own subsystems and share their resources as they wish. The failure of onesubsystem does not affect collaboration among other subsystems, and each subsystem can work independently whenthe integration system fails. Moreover, hierarchical collaborations are achieved by introducing the concepts ofsystem federation and application federation, which address the collaboration issues at the physical level and thelogical level separately. A real industrial application system has been designed and implemented using the proposedarchitecture.

Keywords: collaborative product development; HLA – high level architecture; federated integration

1. Introduction

With the rapid advancement of information andcommunication technologies, globalised businessesface extremely complicated operations and requirethe gear of competencies to handle the complexity.Adopting collaborative product development (CPD)makes full use of several independent developmentsystems, and enhances their abilities at the same time(Xiao et al. 2007, Shen et al. 2008). CPD systems ofteninclude functions as collaborative design, collaborativesimulation and collaborative optimisation. They re-quire data and information such as CAD digitalmodels, CAE analysis and optimisation results (Fanand Xiao 2007, Sun et al. 2009) to be cooperated.

On one hand, these requirements not only accel-erate the needs for dynamic and harmonious coopera-tion of existing computing resources but also bringmore complexity to contemporary computing technol-ogies and operational problems. The cooperativecomputing ability is absolutely necessary in solvingproblems of almost every industry and businesspractitioners, from scientific research, business solu-tion to academic efforts (Joseph and Fellenstein 2005,

Cheung et al. 2006). On the other hand, most ofcommon existing information systems cannot satisfythe cooperation requirements. These systems alwayshave a low level of adaptability to the evolvingbusiness environment because of the difficulty toreorganise the embedded workflows (Li et al. 2005).Although iterative developing processes often takeeffect to fit in new requirements, the subsystems in thesame collaboration group usually tend to producingand consuming their own data in a closed loop (Xuet al. 2006). These systems usually pay too muchattention on the consistency and integrity of data thanthe ability of sharing data with other systems (Lu et al.2008, Cheng 2009). Since no one can take a piece ofdata from these systems easily, collaboration informa-tion is also not able to share and circulate easily(Zhang et al. 2009). In a typical CPD environment, thesystems in one collaboration group often belong todifferent organisations. The conflict between sharingresources for collaboration and exposing private datato different organisations raises a lot of new challenges.This problem cannot be solved by existing technolo-gies, such as electronic data interchange (EDI), content

*Corresponding author. Email: Sunhongbo02@tsinghua.org.cn

International Journal of Computer Integrated Manufacturing

Vol. 25, No. 10, October 2012, 901–913

ISSN 0951-192X print/ISSN 1362-3052 online

� 2012 Taylor & Francis

http://dx.doi.org/10.1080/0951192X.2011.608722

http://www.tandfonline.com

Dow

nloa

ded

by [

UQ

Lib

rary

] at

19:

48 0

6 N

ovem

ber

2014

server, application server and enterprise applicationintegration (EAI) (Gu et al. 2006).

The CPD requires integration and collaboration ofheterogeneous systems which are supported by dis-tributed computing technologies. New challengescaused by distributed computing are also introducedinto this quandary, such as the following:

. Communication method. The integration mustdistinguish the differences between local andremote communication.

. Concurrency. In distributive computing, eventsdo not occur sequentially so the dynamic logicalerrors cannot be avoided.

. Non-existence of a global state. This leads to thefact that a distributed computing environmentcannot be precisely controlled.

. Partial failure. Failure of one participant isindependent from those of other participants.

. Non-existence of a global timer. This makes itvery hard for all participants to achieve punctualsynchronisation.

. Heterogeneity. The participants can be hetero-geneous in hardware, operating system, commu-nication protocol, software, programminglanguage and so on.

The integration software has the following char-acteristics, which is needed for these physicallydistributed and technology varied application systemsto collaborate in harmony.

. Autonomy. Within a given integration environ-ment, there often exists more than one indepen-dent managing domain or controlling domain.

. Integration. An integration system usually spansover several autonomous independent subsys-tems. To achieve common objectives, differentmanaging domains and professional fields needto collaborate with each other.

. Scalability. The number of computational nodesis uncertain due to different businessrequirements.

. Mobility. The actual computation loads mayshift among the computational nodes in order tofine-tune the overall performance.

In summary, CPD has greater demands on integra-tion technologies which are featured with indepen-dency, loose coupling, flexibility and heterogeneity.

In this article, a hierarchical federated integrationarchitecture is proposed. Section 2 gives detailedcomparison of several existing integration modes forheterogeneous systems. Section 3 introduces the pro-posed hierarchical federated integration architecture

which is different from the traditional monotheticfederated integration. Section 4 describes the physicaldeployment of the whole system and an industrialapplication case for optimising design parameters ofprimary springs of a 200 km/h electronic multiple unit(EMU). Compared with dedicated systems, enterpriseresource planning (ERP) extensions and some widelyused innovative development tools, the major advan-tages of the proposed architecture are discussed inSection 5.

From the view of subsystem owners, the proposedarchitecture assists the attainment of complementarycapabilities and services. It can realise inter-connection,inter-communication and inter-operation among multi-ple independent subsystems. Enabled by this architec-ture, participating companies can significantly upgradetheir resources sharing level and business competitive-ness, and furthermore escalate the competitiveness of thebusiness alliance or corporation alliance as a wholespontaneously. The integration system provides moreeloquent and convenient interfaces to the end users andavoids over investment on redundant projects.

2. Related work

Heterogeneous systems integration is not a newresearch area. A few integration modes have beenstudied in depth (Shen et al. 2001, Molina et al. 2005,Curl and Fertalj 2009, Hu et al. 2010); adopting whichmodes is strongly dependent on application scenarios.When different systems in one organisation are goingto integrate together, tightly coupled modes are moreeffective such as platform reorganisation, agent inte-gration and grid.

Platform reorganisation has the advantage offinding the global optimal. But at the same time, itrequires a unique control and authentication mechan-ism. In other words, after reorganisation, there is oneunionised system and all the ever existed subsystems donot exist anymore. However, platform reorganisation isnot widely adopted for heterogeneous system integra-tion due to the workload and some unsolved technologychallenges in the realm of system engineering.

Agent integration implies some kind of autono-mous process in which agents can communicate witheach other to perform some collective tasks on behalfof one or more humans (Huang et al. 2000). Agenttechnology needs much effort on building intelligentfunctions, such as load balancing and task migration.These functions are built on efficient communicationsand well-defined protocols. However, flexible andefficient negotiating using mutual understanding se-mantics lacks in this approach.

Grid provides a mechanism to share and usedistributed resources harmoniously by establishing

902 H. Sun et al.

Dow

nloa

ded

by [

UQ

Lib

rary

] at

19:

48 0

6 N

ovem

ber

2014

virtual enterprises. One of the objectives for a virtualorganisation is transparency – a party does not need toknow the internal mechanisms/processes of anotherparty. The persistence of a global structure anda global state is of great importance for decidingcontrol policies and fine-tuning of system performance.But a conflict is raised between the necessity ofknowing contemporary global state and the difficultyto acquire it.

On the other hand, when heterogeneous systemsfrom different organisations are planning to integratewith each other, they usually prefer loosely coupledintegration modes, such as portal, service-orientedintegration and federated integration.

Portal integration, frankly speaking, though widelyused, is not true integration in essence. Becausesubsystems do not interact with each other at all, andthe interactions between the portal and subsystems areunidirectional.

Service-oriented integration can transparently en-hance capabilities of subsystems and improve theirquality of services by utilising web services providedby other subsystems. But, since direct interaction isadopted for interoperation, flexibility is very hard to beaddressed by service-oriented integration. Moreover,web services employ a unique interface to all theirclients. That means this integration mode has a lowlevel of adaptability.

Federated integration was first mentioned in highlevel architecture (HLA) of DoD (Department ofDefense). HLA is a general technical architecture forcomputer simulation systems. From 2000, it began tobe adopted by IEEE as international standardIEEE1516 (SISC 2000). In definition, federation is anamed set of federate applications and a commonfederation object model (FOM) that are used as awhole to achieve some specific objectives.

Since federates exist within federation in the formof data abstraction, federated integration keeps wellthe independency of its participants. The owner of eachparticipant need not worry about exposing too muchprivate information. The federation only defines theinteresting domains for given objectives and the rulesof inter operations. It is a real loosely coupledintegration solution. Within a federation, subsystemscollaborate in an indirect way so that the context ofinteroperation can be taken into consideration. Sofederated integration is more suitable for and is widelyused in distributed and loosely coupled simulationintegration.

Nowadays more and more simulation functions areadded into CPD (Xu et al. 2008, Yuan et al. 2009,Zhen et al. 2010). The design of product can be deemedas a multiple steps process in which a set of designgoals and requirements are transformed into a

functional system. Simulation functions help thesesystems to fulfil their design goals and contribute totheir potential values. The key merits of simulation inthe context of product development can be describedas that it is able to:

. explore and focus on the solution space corre-sponding to a given design or optimisationproblem at a reasonable cost;

. reduce uncertainty about the system and thefrequency of changes at early design stages;

. predict and analyse system behaviour in a wellestablished environment;

. test and guide the development of differentmodules or subsystems so that they can runharmoniously to achieve certain design goals.

When simulation is added into a CPD environ-ment, there always exist several subsystems in the sameenvironment with independent design goals. Thesesubsystems may follow different design or managementrules according to their dedicated fields. Under thiscircumstance, distributed and federated systems areoften much useful, but using HLA in a CPDenvironment is far from just applying HLA as anoverall architecture on top of these systems.

In fact, there is a lot of research work that hasapplied HLA into the whole CPD systems (Tayloret al. 2005, Tang et al. 2010). However, HLAfederation also possesses several shortcomings limitingits usage.

. When being adopted to the product developmentresearch areas other than simulation, the HLAfederation faced a lot of new challenges; forexample charging method, resources utilisation,task scheduling, task immigration and faulttolerance.

. It does not accommodate latest technologies suchas service science, dynamically self-adaptive appli-cation programming interface (API), ontology andsemantics technologies (Morse et al. 2006).

. The objective of a given HLA federation usuallyis a predefined simulation process so all theconfiguration and preparations are made forone-time simulation, which disobeys the princi-ple of reusability.

. The description of management functions isrelatively simple. Some important functionswere not included, such as fault tolerance,intelligent update and consistency sustainment.

. Most collaboration agreements are not guaran-teed by any workflow or software, whichconstrains the applicability and robustness offederated applications.

International Journal of Computer Integrated Manufacturing 903

Dow

nloa

ded

by [

UQ

Lib

rary

] at

19:

48 0

6 N

ovem

ber

2014

In order to address the problems mentioned above,this article proposes a hierarchical federated integra-tion architecture. In the context of CPD, thisarchitecture makes it possible for every domain expertsto establish collaborative jobs without having detailedknowledge of other domains. The proposed architec-ture is particularly tailored for dynamic, looselycoupled, and multi-objective integration and colla-borations of heterogeneous information systems.

3. Hierarchical federated integration architecture

With the objective of enabling dynamic collaborationfor product development in a generic HLA-basedarchitecture which has been mentioned above, somenecessary characteristics are identified below:

. Every participant belongs to a different organi-sation and is independent to each other. Each ofthe participants is seeking for maximising profitand expanding capabilities via collaborations.

. The collaboration type is categorised as looselycoupling and the major problem is data coupling.

. In these collaborations, interoperation is re-strained by federation and federate rules.

. The scope of control for every participant isindependent and the scope of management forthe whole federation covers all the namedfederates.

. Subsystem owners only need to expose the datathat is required for supporting desiredcollaborations.

Unfortunately, these requirements on flexiblecoupling are beyond the ability of monothetic HLAfederations. CPD requires an open and flexiblearchitecture that can facilitate high quality collabora-tions in terms of interconnection, intercommunicationand interoperation.

3.1. Conceptual model for hierarchical federatedintegration architecture

The hierarchical federated integration architecture forCPD is working at two levels: physical level and logicallevel, as shown in Figure 1. The physical level (systemfederation) focuses on the integration issues related tothe physical environments and resources. At this level,resources can be divided into two parts: sharableresources (static resources) and candidate application

Figure 1. Hierarchical federated integration conceptual model.

904 H. Sun et al.

Dow

nloa

ded

by [

UQ

Lib

rary

] at

19:

48 0

6 N

ovem

ber

2014

federates (reactive resources). Sharable resources arepart of the collaboration environment, such assimulation models, simulation tools and mechanicalpart libraries. When a candidate application federatesponsors or joins in an application federation, it willbecome an application federate in the logical environ-ment; on the other hand, when an applicationfederation is destroyed, all application federatesembedded in it will return to the candidate federatepool again. The logical level (application federation) isunaware of physical differences of resources; it onlyneeds to pay attention to logical concerns.

System federation defines the environment ofphysical aspects, while application federations definethe logical environment. The cooperation individualsof system federation are projected from real systemsinto separate system federates. The content and basicschema (collaboration knowledge template of applica-tion federate) of these cooperative individuals needsto be defined in order for them to participate in theapplication federation. The collaboration in systemfederation is relatively simple and monotonous, onlypublishing sharable resources and candidate applica-tion federates. After the application context is defined,these candidate application federates can sponsor orjoin in an application federation in the form of a realapplication federate.

In this conceptual model, the entire story is startedfrom several existing product development systemscalled physical nodes. Within a physical node, theremay be more than one legacy system deployed. Thesesystems share the same physical information, such asdata representation and IP address. And within onelegacy system, there could be more than one or morecollaborative functions.

Presenting as either a function or a system, and nomatter where they are from, the entities that willparticipate in collaboration are all called cooperativeindividuals. These cooperative individuals will performthe inter-operative activities during the process ofcollaboration.

Before collaboration, an interesting domain whichis related to resources sharing must be establishedfirst. When cooperative individuals are projected tothis interesting domain, the projections from thesame physical node form a system federate. That is tosay, a system federate can contain more than oneprojection of cooperative individuals. When systemfederates publish their resources, the static resourcesare added into the sharable resource pool and thereactive resources become candidate applicationsfederates.

The candidate application federate pool need to belooked up first when establishing a collaborative task.After selection of appropriate candidate application

federates, an invitation message will be sent to theprojection owner of the involved candidate applicationfederates. If the involved owners agree on theresponsibilities they will perform during this collabora-tion, these federates will join the established applica-tion federation one by one, and then the collaborativetask can be carried out smoothly.

This conceptual model is more suitable to thedynamic multi-objective collaboration of heteroge-neous information systems, at the same time keepingthe independency of the participants. Since theintegration architecture is segregated into two levelswhere the system federation only focuses on physicalfeatures and physical heterogeneity, and the applica-tion federation only pays attention to the logicalaspects, the architecture is highly flexible, reusable andexpandable.

3.2. Implementation architecture

Design, simulation and optimisation resources arethree types of major resources which are frequentlyused in CPD processes. In the past, these developmentresources are often assigned to different packages sothat there is no unique collaboration mechanism forthem. To improve the efficiency of the productdevelopment process and to verify the validity of theconceptual model, a unique collaboration integratedsystem of design, simulation and optimisation forcomplex products was developed. It aims at integratingproduct design, simulation and optimisation resourcesfrom different product development packages andproviding a collaborative development environmentfor all of them. The implementation architecture isillustrated in Figure 2, which includes three CPDpackages (design, simulation and optimisation).

The whole system integrates three subsystems:collaborative design subsystem, collaborative simula-tion subsystem and collaborative optimisation sub-system. The main software of collaborative designsubsystem is Smarteam, which assembles two categorygeometry parts, ProE and CATIA parts, to formgeometry models of given product. The integrationmodule on collaborative design subsystem is redeve-loped on Smarteam by Visual Basic (VB). Collabora-tive simulation subsystem includes Adams, Matlab andcollaboration simulation software (TH_RTI); Adamsperforms kinetics simulation functions, Matlab simu-lates control functions and TH_RTI is developed inVCþþ to harmonise these simulation models, toolsand communicates with other subsystems by webser-vices. Collaborative optimisation subsystem is devel-oped by Java, integrated with iSight and invokescollaboration simulation by webservices. Each sub-system has its own data storage to save user-defined

International Journal of Computer Integrated Manufacturing 905

Dow

nloa

ded

by [

UQ

Lib

rary

] at

19:

48 0

6 N

ovem

ber

2014

data, task related data, models and application-specified data. From the logical view, they all possessaccess control, task management and applicationmanagement. In order to collaborate, they also reflectand update the collaborative data that they own.

A daemon is running on every physical node atwhich these packages reside as a deputy of the systemfederation. They work harmoniously to perform all thecollaborative jobs.

The daemon program includes three main parts:interface, logical management and data storage. Theinterface connecting the legacy systems handles theinterconnection settings, intercommunication messagesand interoperation commands. The data storagepersistently saves the user-related data and interopera-tion models. The functions of logical management

include user management, system configuration, objectmanagement, declaration management, object modeltemplate management, collaborative application man-agement and a distributed searching engine.

All the daemon programs are connected by acommon network. The protocol utilised is TCP/IP.

Hierarchical federated integration architecture isadopted as the integration model for the collaborativedesign–simulation–optimisation product developmenttasks. Maximum resources utilisation of subsystemsis facilitated by the system federation and thepragmatic environments, which are established bythe application federation. The operation patterns ofsubsystems and their development resources is com-patible with the formal style, the independency is wellpreserved.

Figure 2. Implementation architecture.

906 H. Sun et al.

Dow

nloa

ded

by [

UQ

Lib

rary

] at

19:

48 0

6 N

ovem

ber

2014

Figure 3. Physical deployment.

4. Application case demonstration

The above implementation architecture is demon-strated through the virtual manufacturing process ofthe Chinese High Speed Train project as described inthis section.

Figure 3 shows the physical deployment of thesystem, which includes eight computers, five projectorsand two workstations: computer 1 is the observer ofthe hierarchical federated integration system; computer2 hosts the collaborative design subsystem, and theworkstation connected to computer 2 (GeometryServer) provides services of all involved geometrymodels to the collaborative design, simulation andoptimisation subsystems; workstation 4 contains thecollaborative optimisation subsystem, and all the othercomputers belong to collaborative simulation subsys-tem. Computer 5 performs the simulation of the headcar, the second car and one soft gear. The computerbetween 5 and 6 simulates two soft gears. Computers 6and 7 perform the simulation of two middle cars andone soft gear separately. Computer 3 runs one moresoft gear and acts as the portal of collaborationsimulation platform and computer 8 performs thesimulation of two rear cars and one soft gear. Only the

observer and the computers simulating the train bodiesare connected to the projectors (five projectors asshown in Figure 3) in order to show the result of thiscollaborative work.

The application case demonstrates a hierarchicalfederation based collaborative design–simulation–optimisation process of Chinese high speed train. Thetarget is to optimise 200 km/h EMU design parametersof primary springs by changing the stiffness of carbody suspension system springs, shifting value ofdampers and so on.

Step 1: 3D modelling for the 200 km/h EMUdesign. This digital model includes the head car andthe car body. The car body can be divided into eightdivisions: main structure, roof, ends, bottom, interior,electrics, bogie and overall division. They are con-structed by different 3D modelling packages, ProEand CATIA, and these parts are assembled bySMARTEAM.

Step 2: Specifying the design problem. This case is adesign-optimisation problem of 200km/h EMU. Thetarget is to optimise 200 km/h EMU design parametersof primary springs (Figure 4). The material is 50CrVASpring Steel with high hardenability and yield ratio.

International Journal of Computer Integrated Manufacturing 907

Dow

nloa

ded

by [

UQ

Lib

rary

] at

19:

48 0

6 N

ovem

ber

2014

Step 3: Creating the system federation. Everysubsystem (collaborative design, simulation and opti-misation) first creates their corresponding systemfederates separately. One of them creates the systemfederation and the others join in this federation; thusthe created system federation consists of one sharedFOM file and three independent SOM files (Figure 5).

Step 4: Publishing resources and creating applica-tion federation. Every system federate publishes itsown resources as candidate application federates(Figure 6). In this case, the federate which representscollaborative design subsystem sponsors the applica-tion federation, then invites other necessary federatesto join in.

Step 5: Initialing a design task and declaring data.The collaborative design federate describes taskattributes and declares the data involved and theoptimisation federate will be informed due to itssubscription to the design task.

Step 6: Establishing optimisation model. Theoptimisation federate establishes the optimisationmodels according to the specifications of the 200km/h EMU. Later it is found that the optimisationprocess is a simulation–optimisation process. Optimi-sation federate declares relative data to the simulationfederate.

Step 7: Establishing simulation models. Accordingto the simulation task, the simulation federatecreates proper kinetic models of the 200 km/h EMU,as Figure 7 shows.

Step 8: Publishing and subscribing applicationdata. The workflow of application federation isautomatically established according to the data pub-lishing–subscribing pairs.

Step 9: Starting application federation. The colla-borative design federate starts the application federa-tion and publishes design data. The optimisationfederate receives the data from the design federateand starts the simulation–optimisation process.

Step 10: collaborative simulating. The collaborativesimulation federate starts the collaborative simulationprocesses (Figure 8). The scenario of this simulation isa curving railway with 1000 m length, 300 m radius,0.150 m ultra height and non-excitation.

Step 11: Collecting results. After the collaborativesimulation federate gets the simulation results (Figure9), it publishes data in the application federation.Because the optimisation federate subscribes this kindof data, it can receive proper data in time and make thedecision for repeating or terminating the simulationaccording to the optimisation models. When it reachesthe optima, the optimisation federate will publish theoptima in the application federation. The designfederate then gets this optimum according to thesubscription in advance. All the data processed in thishierarchical federation system are recorded to keeptracking of the whole system states.

At the end, an optimised design of the suspensionsystem was reached with critical velocity and comfortindex as the optimisation objective, safety index as theconstraint function, and the 200 km/h EMU bogiespring stiffness and damping coefficient of dampers asdesign parameters.

5. Discussion

The proposed hierarchical federated integration archi-tecture is specially tailored for complex product

Figure 4. Digital bogie of 200 km/h EMU.

908 H. Sun et al.

Dow

nloa

ded

by [

UQ

Lib

rary

] at

19:

48 0

6 N

ovem

ber

2014

development. In this research area, existing softwaretools can be classified into three main categories:dedicated platforms, ERP extensions and popularCPD tools. The dedicated platforms only focus onsome specific development phases or aspects, and theyare restricted in terms of professional domains, such asiSight, Adams and Matlab. ERP extensions extend thetraditional enterprise scope to CPD, such as SAPPLM, QAD Lean Manufacturing and Oracle JDEdwards EnterpriseOne. They pay more attention onresource utilisation than collaborations. CPD tools aredeveloped to resolve collaboration problems duringthe process of product development. The key objectiveof this kind of software is to integrate differentsoftware systems and harmonising them. This categoryincludes Fiper, Winchill, Enovia, TeamCenter, Mod-elica, ModelCenter and ANSYS. They usually empha-sise on one phase or one aspect of CPD, such as design,simulation or optimisation.

The proposed dynamic, loosely coupled and multi-objective architecture can integrate different

combination of subsystems so that it can supportdifferent kinds of CPD tasks. All the subsystems aretreated equally at the logic level, so the owners cansponsor or response to an application federation nomatter which subsystem they belong to. Because usersare able to use subsystems almost in the same manner,the domain experts can focus on their own professionalresearch area, which significantly eliminates thedemand for training. The whole architecture is alsovery flexible and suitable for dynamic applicationsbecause of the fully separation of physical and logicallayers.

Compared with dedicated platforms, the proposedapproach is more comprehensive and flexible. Fromthe technology view, it is more comprehensive in that itsupports the whole life cycle of product developmentprocess based on a unique collaboration data model.The whole architecture provides a flexible and generalframework that is easy to expand. From the processview, it is more flexible. Other than the dedicatedplatforms that are segmented along the product

Figure 5. System federates.

International Journal of Computer Integrated Manufacturing 909

Dow

nloa

ded

by [

UQ

Lib

rary

] at

19:

48 0

6 N

ovem

ber

2014

Figure 6. Candidate application federates.

Figure 7. Simulation models of 200 km/h EMU.

910 H. Sun et al.

Dow

nloa

ded

by [

UQ

Lib

rary

] at

19:

48 0

6 N

ovem

ber

2014

Figure 8. Collaborative simulation.

Figure 9. Simulation result demonstration.

International Journal of Computer Integrated Manufacturing 911

Dow

nloa

ded

by [

UQ

Lib

rary

] at

19:

48 0

6 N

ovem

ber

2014

development processes, the proposed approach canprovide a fully support to the whole life cycle. Itsupports dynamic processes and can be easily verified.From the usability view, it is more suitable to dynamicsituations, has less demand on training and can beadopted quickly and easily.

Compared with ERP extensions, it is more flexibleand acceptable. From the technology view, other thanpaying attention to specific phases, it covers the wholelife cycle of product development and can be easilyexpanded. From the process view, it supports dynamicprocesses, easy verification and innovative develop-ment better. From the usability view, it has predictableimplementation scale and a lower demand on training.

Compared with popular CPD tools mentionedabove, it is more acceptable and predictable. Otherthan emphases on some phases, the proposed approachprovides an equal support for every phases of productdevelopment. And because of the loosely coupledarchitecture, the system can be easily expanded orre-configured. From the process view, it gives bettersupport for dynamic processes. From the usabilityview, it is more predictable in dynamic situations andputs lower demand on training.

In conclusion, the proposed architecture reducesthe total cost, mitigates implementation risk, verifiesfaster return of investment and provides continuousgrowth opportunities.

6. Conclusion

Effective collaboration is crucial to the success ofintegration architectures. Aimed at tackling the chal-lenges associated with dynamic and multi-objectivecollaborations of heterogeneous information systems,a hierarchical federated integration architecture ispresented and analysed in this article. Comparingwith existing integration methods, our approachachieves several major improvements. Firstly, thecollaborative individuals are projections (ambassador)of real application systems, so the independency ofeach participant is well preserved. Secondly, byseparating physical collaboration and logical colla-borations at two levels, the coupling between applica-tions is released. Thirdly, configuration of thecollaborative environment is very flexible in that newcollaboration tasks can be accommodated withoutrecompiling all the components. Finally, an industrialcase of complex product digital prototyping representsa valid demonstration of our approach in complexvirtual product development.

This article is part of virtual and networkedmanufacturing and focuses on multi-disciplinary sys-tems integration. As the basis of whole research, thisarchitecture develops HLA into product development.

Although has been successfully applied in the researchand development of Chinese 200 km/h EMU, thereare still a lot of work to further improve the efficiencyand to reduce the work load for collaborations.For example, automatic generation of collaborationknowledge, knowledge discovery, integration andevolution, fault tolerance mechanism and distributedsystem states monitoring. Some of these issues havebeen addressed by concept of collaboration ontologies;the content about collaboration ontology modelling,fusion and maintenance have been reported in separatepapers. Performance analysis is being studied usingcontrol theory, and will be reported soon.

Acknowledgements

This work is partially supported by Chinese National High-tech Research and Development Program (863 Program,Grant No. 2009AA110302) and Chinese Nature ScienceFoundation (Grant No. 60874066).

References

Cheng, H., 2009. An integration framework of ERM, SCM,CRM. In: International conference on management andservice science. Wuhan, China: IEEE, 1–4.

Cheung, W.M., et al., 2006. Organizational knowledgeencapsulation and re-use in collaborative product devel-opment. International Journal of Computer IntegratedManufacturing. 19 (7), 736–750.

Curl, A. and Fertalj, K., 2009. A review of enterprise ITintegration methods. In: Proceedings of the ITI 200931st international conference on information technologyinterfaces. Cavtat/Dubrovnik, Croatia: IEEE, 107–112.

Fan, W. and Xiao, T., 2007. Collaboration integratedplatform of design, simulation and optimization forcomplex products (in Chinese). Science & TechnologyReview, 226 (4), 15–24.

Gu, N., Liu, J., and Chai, X., 2006. Principles and R&Dpractice of web services. Beijing, China: China MachinePress.

Hu, Y., Zhou, X., and Li, C., 2010. Internet-based intelligentservice-oriented system architecture for collaborativeproduct development. International Journal of ComputerIntegrated Manufacturing, 23 (2), 113–125.

Huang, G.Q., Huang, J., and Mak, K.L., 2000. Agent-basedworkflow management in collaborative product develop-ment on the Internet. International Journal of ComputerAided Design, 32 (2), 133–144.

Joseph, J. and Fellenstein, C., 2005. Grid computing. Beijing,China: Tsinghua University Press.

Li, H., et al., 2005. Integration of business processes in Web-based collaborative product development. InternationalJournal of Computer Integrated Manufacturing, 18 (6),452–462.

Lu, X., Zhou, M., and Yang, S., 2008.An uniformapplication supporting platform based on SOA. In:International conference on apperceiving computing andintelligence analysis. Chengdu, China: IEEE, 34–39.

Molina, A., Aca, J., and Wright, P., 2005. Global collabora-tive engineering environment for integrated productdevelopment. International Journal of Computer Inte-grated Manufacturing, 18 (8), 635–651.

912 H. Sun et al.

Dow

nloa

ded

by [

UQ

Lib

rary

] at

19:

48 0

6 N

ovem

ber

2014

Morse, K.L., et al., 2006. Enabling simulation interoper-ability. IEEE Computer, 39 (1), 115–117.

Shen, W., Hao, Q., and Li, W., 2008. Computer supportedcollaborative design: retrospective and perspective. Com-puters in Industry, 59, 855–862.

Shen, W., Norrie, D.H., and Barthes, J.P., 2001. Multi-agentsystems for concurrent intelligent design and manufactur-ing. Abingdon, Oxford, UK: Taylor & Francis.

Simulation Interoperability Standards Committee (SISC) ofthe IEEE Computer Society, 2000. IEEE standard formodeling and simulation (M&S) high level architecture(HLA)-framework and rules. New York, USA: TheInstitute of Electrical and Electronics Engineers, Inc.

Sun, H., Xiao, T., and Tang, S., 2009. Research onfederation-based pragmatic integration framework. In:Proceedings of 2009 World Congress on Computer Scienceand Information Engineering (CSIE 2009), Los Angeles/Anaheim, USA. 535–539.

Tang, S., Xiao, T., and Fan, W., 2010. A collaborativeplatform for complex product design with an extendedHLA integration architecture. Simulation ModellingPractice and Theory, 18 (8), 1048–1068.

Taylor, S.J.E., et al., 2005. Investigating distributed simula-tion at the Ford Motor Company. In: Proceedings of theninth IEEE international symposium on distributed simu-lation and real-time applications. Montreal, Canada:IEEE, 139–147.

Xiao, T., Zhang, L., and Zhao, Y., 2007. Acceleratingindependent innovation of the products with VMtechnique (in Chinese). Science & Technology Review,226 (4), 5–14.

Xu, Y., et al., 2008. Federated integration of networkedmanufacturing service platforms. Advanced EngineeringInformatics, 22, 317–327.

Xu, Y., Xiao, T., and Liang, C., 2006. Integration ofnetworked manufacturing platforms and manufacturinggrid (in Chinese). Computer Integrated ManufacturingSystems, 12 (11), 1838–1846.

Yuan, Q., Luo, S., and Tang, W., 2009. A collaborativedesign frame based on virtual prototypes and virtualmanufacturing. In: 11th IEEE international conference oncomputer-aided design and computer graphics. YellowMountain City, China: IEEE Press, 568–571.

Zhang, S., Wu, J., and Zhu, Y., 2009. Construction ofdistributed and heterogeneous data sharing platform. In:International conference on web information systems andmining. Shanghai, China: IEEE, 696–700.

Zhen, X.-J., et al., 2010. A real-time simulation grid forcollaborative virtual assembly of complex products.International Journal of Computer Integrated Manufac-turing, 23 (6), 500–514.

International Journal of Computer Integrated Manufacturing 913

Dow

nloa

ded

by [

UQ

Lib

rary

] at

19:

48 0

6 N

ovem

ber

2014