当前位置:首页 >> 能源/化工 >>

A grid-based collaborative system for vehicle crash safety design and its application based on LAN


Advances in Engineering Software 41 (2010) 170–179

Contents lists available at ScienceDirect

Advances in Engineering Software
journal homepage: www.elsevier.com/locate/advengsoft

A grid-based collaborative system for vehicle crash safety design and its application based on LAN
Zhijie Zhao *, Xianlong Jin, Yuan Cao, Jianwei Wang
School of Mechanical Engineering, Shanghai Jiao Tong University, Shanghai 200240, China

a r t i c l e

i n f o

a b s t r a c t
Car manufacturers and their suppliers are usually geographically dispersed, heterogeneous characters of various resources. To solve the resource sharing and data security problems in vehicle collaborative design environment, grid technology and Computer Supported Collaborative Work (CSCW) technology are integrated. This paper proposes a collaborative design system for vehicle crash safety design based on grid technology that is conformed to the OGSA framework, and explains how the grid middleware VEGA contributes to make collaboration more ef?ciently. Web services about the functions in this collaborative system are realized based on VEGA. Design principles and methods based on the FE analysis tool LS-DYNA are also presented. Finally, a test bed is built based on LAN and a case of a carmaker collaborating with a seat supplier is presented. ? 2009 Elsevier Ltd. All rights reserved.

Article history: Received 2 February 2007 Received in revised form 19 December 2008 Accepted 11 September 2009 Available online 9 October 2009 Keywords: Collaborative design Car crashworthiness Grid computing Architecture

1. Introduction During the past years, advances in the area of CAD, CAE technologies have contributed signi?cantly to the automotive industry to keep up with the growing competition. Despite some initial success, the development of these disciplines did not meet the challenges of globalization of the automotive industry well enough. However, the OEM-Supplier pattern, that the carmaker collaborates with a multitude of suppliers, can be an effective way to deal with these requirements. The crash safety design of vehicle plays an important role in the process of vehicle design. It is used to verify whether the part satis?es the strict safety requirements by way of crashworthiness analysis. We propose in this paper a collaborative system for vehicle crash safety design in which a Virtual Organization (VO) is created. The VO members, including a carmaker, suppliers and a compute partner, collaborate on a car safety design project. These members have different tasks according to the roles they play in the VO. When several organizations participate in a project, information must be exchanged among the partners involved. On the other hand, each partner strives to protect its proprietary know-how as far as possible. The analysis models usually contain a lot of con?dential data such as modeling skills, representation of a material
* Corresponding author. Address: Room 225, Advanced Manufacture Building, School of Mechanical Engineering, Shanghai Jiao Tong University, No. 800, Dongchuan Road, Shanghai 200240, PR China. Tel.: +86 021 34206099; fax: +86 021 34206338. E-mail address: zhijie@sjtu.edu.cn (Z. Zhao). 0965-9978/$ - see front matter ? 2009 Elsevier Ltd. All rights reserved. doi:10.1016/j.advengsoft.2009.09.003

behavior, and shape of the car at the early stages of the design, etc. Thus, some technologies such as the assembling technique of the models and the extracting technique of calculation results have been proposed to meet the requirements of the protection of the proprietorship. The collaborative design system for vehicle crash safety can be assisted by establishing a Computer Supported Collaborative Work (also known as CSCW, groupware) environment. CSCW provides a means for people in different places to collaborate, enabling them to share the environment and information, to engage common task, etc. [1]. Distributed technologies, such as CORBA, DCOM, J2EE, are adopted to realize the CSCW applications [2,3]. These technologies can construct various distributed application systems, but are limited to a customized static domain in which the hardware and software environment of each application system is basically changeless. If the static domain is changed, the resource sharing and application systems will be affected, and all the application systems must be reconstructed manually [4]. On the contrary, the grid technology based on Web services is capable of solving the problems concerned above, and is suitable for resources sharing, cooperative interaction of multi-party participants in dynamic environment [5]. Grid technology is one of the best choices for collaborative work owing to its characteristics and application patterns, and can be an effective application of the CSCW [6]. The grid connects various geographically distributed computers, including high-performance computers, workstations and PCs, and all kinds of other equipments through network. This will form a virtually high-performance computing environment that is transparent to the users,

Z. Zhao et al. / Advances in Engineering Software 41 (2010) 170–179

171

and will realize resources sharing and collaborative work [7]. This research proposes VEGA as the middleware in the architecture of grid environments. VEGA is one of the middleware level grid software aiming at distributed resource sharing and application integration in China. The EVP Address Space Model and agora (grid community) concept in VEGA are helpful to build this collaborative environment. In addition, we chose the explicit ?nite element program LSDYNA as the only FEA tool because of its extensive capabilities in crash, impact, dummy, and airbag analysis. Nowadays, LS-DYNA is widely recognized for vehicle crashworthiness analysis. The rest of the paper is organized as follows: Section 2 presents the overall scenario of the collaborative design for vehicle crash safety design. Section 3 introduces and describes the grid middleware and the framework architecture proposed in this research. Section 4 discusses two key technologies of this system, which are the assemble technique of FE models and the split technique of the calculation results. Section 5 discusses the trust relationship among partners. Section 6 gives a detailed description of the process for the vehicle crash safety design via an example of the collaboration between a seat part supplier and a car manufacture based on LAN. Section 7 concludes the research in this period and outlines our future direction. 2. Application scenario According to the needs analysis discussed in previous section, the chosen scenario (as shown in Fig. 1) can be regarded as a collaborative work between a carmaker and its suppliers, whose products should meet the speci?c crash criterion made by carmaker. To validate the design of the parts, the suppliers shall assemble their parts to the whole car model and then perform the crash simulation. This will yield a more realistic result as in an actual physical crash test. The suppliers need a lot of information to design the components. It is obvious that the dissemination of vehicle data among many partners means a total loss of con?dentiality if the data are not secure. The problem concerns both the carmaker and the

suppliers. Carmaker wants to keep con?dentiality of vehicle design data containing digital models of parts, architecture of the vehicle, material constitutive laws, modeling skills, etc. The suppliers want to protect their information such as material constitutive laws of their components. Also, given that a supplier may potentially work for other carmakers, it should only be allowed to have access to the data needed instead of the whole car. On the other hand, suppliers themselves can be competitors, so one supplier shall be prevented from reading others’ data. The data encryption mechanisms may meet the data security requirement mentioned above, but there is no effective way for the encryption of ?nite element models involved in our project. So we adopt another method to solve the problem. Needed models will be provided to suppliers by carmaker, and the simulation results of the whole car will also be divided into different parts according to the suppliers they relate to. The suppliers only have access to those ?les they need, such as the CAD environment of their parts, simulation results for their parts, etc. They also have access to some calculation results of the whole car if they are indispensable for the part being designed. This article mainly focuses on the data security and resource sharing problems in the collaboration design for vehicle safety design and less concerns the mass calculation and the work?ow technology. The partners in this VO are carmaker, suppliers, and compute partner who provides compute resource. According to the discussion above, the collaborative work consists of following steps: 1. The carmaker creates three sub-models of the car: car ?nite element model (FEM) excluding the parts made by suppliers (CARFEM), FEM of the part environment (ENV-FEM), and the CAD model of the part environment (ENV-CAD). The ENV-FEM includes the parts that are directly connected to or are in contact with the parts to be designed. Carmaker puts these submodels into the compute partner’s site. The supplier has access to ENV-FEM and ENV-CAD, but none to the CAR-FEM. 2. The supplier gets from the carmaker the environment models including the ENV-FEM and ENV-CAD to design the part at local site. It designs the geometry of the part based on ENV-CAD in its own CAD system. It then meshes the geometry and assembles the meshed part to ENV-FEM to create the FEM of the part (PAR-FEM) which is compatible with the car design. All data belonging to supplier’s speci?c knowledge and modeling skills are encrypted. At last, the supplier uploads PAR-FEM to the compute partner’s site. The carmaker has no access to this model. 3. CAR-FEM and PAR-FEM will be assembled automatically to become a whole FEM of the car (W-CAR-FEM) ready for simulation at the compute partner’s site. The technique about how to realize the automatically assembly will be explained later in detail. When all the parts have been assembled successfully, the carmaker triggers the crash simulation of the whole model. After that, the whole car calculation results (W-CAR-RES) will be divided automatically into two different parts, one being the result of PAR-FEM (PAR-RES) which will be put on the supplier’s site, and the other the result of CAR-FEM (CAR-RES). These results include ASCII output ?les that record the movement of the nodes and the binary output ?les that record the complete outputs states. Some data belonging to the whole car results will also be sent to the supplier for the evaluation of the whole car. If there is anything wrong in the calculation or the results of the parts does not meet the criterion of car crashworthiness, the process goes back to step 1, and the supplier will redesign the parts. 4. At the end of the steps, the supplier sends a noti?cation to the carmaker to tell him that the parts are ?nished, and the carmaker can download the parts and all the calculation results.

Fig. 1. The process of collaborative design for vehicle crash safety.

172

Z. Zhao et al. / Advances in Engineering Software 41 (2010) 170–179

ENV-FEM only includes the information of nodes and elements in the environment, and will not contain any sensitive information that the carmaker wish to keep as con?dential. With the help of ENV-FEM, we can assemble the meshed part to the car. Meanwhile, some complicated rules should also be made by the carmaker so that the PAR-FEM is compatible with the CAR-FEM. This will be scrutinized in the later chapter of this paper. To enhance the security level of data, the compute partner will have no access to all the models and result ?les. 3. Architecture of grid system The established grid system is conformed to the Open Grid Services Architecture (OGSA) framework that can dynamically integrate services coming from carmaker, suppliers, and compute partner within the VO [8,9]. 3.1. Grid middleware Grid middleware is also called ‘‘the grid operation system” which decouples application and hardware across diverse physical resources. Grid middleware is line in a common horizontal layer that de?nes and implements a consistent set of abstractions and interfaces for access to, and management of, shared resources, and simultaneously provides user programming interface and developing environment of grid application services. Many kinds of grid middleware have been proposed to support the construction of various grid applications. As for the application of collaborative design concerned in this paper, we chose VEGA GOS 2.0 (for short, VEGA). It is currently the proper grid middleware for collaborative work on which our research is based [10].

In China, CNGrid (also known as VEGA) is middleware level grid software. The goal of CNGrid software is to support ef?cient management of multiple geographical distributed grid nodes, to offer a secured and uniformed interface to the grid users, and to provide a convenient accessing approach to the grid resources from anywhere. VEGA is conformed to the OGSA framework, and the Service Oriented Architecture (SOA) concept is fully utilized and embodied in VEGA 2.0 architecture (as shown in Fig. 2). It is comprised of job broker service, resource management service, ?le service, system monitor service, and user and CA virtual interface service, etc. and it also supports the single sign on (SSO) [10]. The Effective, Virtual, and Physical (EVP) Address Space Model plays an important role in VEGA. As show in Fig. 3 [1], the model is made up of three layers, the physical service address (PAD), the virtual address space (VAD), and the effective address space (EAD). PAD consists of Web services called physical service hosted in different service containers. Physical service address is registered into the service router. Each registered physical service will get a virtual service address which will be manually put into independent agoras and will be assigned a readable name called effective service address. An effective service is described as a group of customized access control and authorization policies that can be indexed by an effective service address in a certain agora. All services in all agoras build up the EAD. Mapping between VAD and PAD is a one-to-one mapping, while mapping between EAD and VAD is an n-to-n mapping, meaning that one effective service can be mapped to multiple virtual services and vice versa [10]. Similar to the EVP Address Space Model, VEGA has a ?le storage resource space model called GriDaEn. In VEGA, every user in a VO possesses a logic, continuous and independent ?le space. So, different user actions on ?les will be mapped into different ?le spaces.

Fig. 2. Structure of VEGA 2.0.

Z. Zhao et al. / Advances in Engineering Software 41 (2010) 170–179

173

3.2. Architecture This grid system is an integrated collaborative design, analysis, and calculation platform based on grid technology and middleware. Its architecture is shown as Fig. 4, and can be divided into four layers: resource layer, middleware layer, service layer and application layer. Particularly, in this architecture, applications and services are not tightly bound to a single physical resource (or set of physical resources). Instead, they bind dynamically to resources via the grid middleware layer. The resource layer includes all kinds of compute resources, storage resources, network resources, software resources, and other resources managed by different institutions or administrative domains. The middleware layer consists a series of components and VEGA. Its function is to hide geographically distributed, heterogeneous characters of various resources in the resource layer and to provide transparent, coincident applying interface to service layer of grid application. Service layer provides various services for collaborative design and selectively exposes certain interfaces to the application layer which is set on the top of the architecture. The application layer contains several basic applications for collaborative design which span a broad spectrum: batch and interactive, compute and data intensive. The end user can use the applications in this layer by accessing the services in grid environment while remain unaware of the things occur in lower layers. Also included in the application layer is the portal design, through which the end user interacts with the applications. Distributed grid resources are integrated by grid middleware and are encapsulated by grid application services. Without authorization and authentication, the user cannot access the resources unless it is the owner of these resources. This ensures the security of resources. By the services layer, the ‘‘application” is totally decoupled from the underlying resources. In addition, the services in this grid environment are based on Axis 1.4 and Tomcat 5.0. The oriented and loosely coupled architecture of the service determines that this grid environment is scalable and adaptable. 4. Services for crash safety design of vehicle project Section 2 describes the application scenario. Now we will realize this scenario based on the grid technology mentioned in Section 3. This research opted for an SOA that allow developers to encapsulate information tools as services that clients can access without knowledge of, or control over, their internal workings [12].

Fig. 3. EVP model of VEGA.

At the same time, a shared global space in a VO also supports ?le sharing among different users. In the global space, File owners can grant or revoke the access permission of their ?les to other user in the same VO. Like the EVP model, GriDaEn is also composed of three layers: the Physical storage space, which is the collection of storage resources at grid nodes that can be distributed and heterogeneous; the Virtual storage space, which is the abstraction of physical storage resources and provides uniform accessing interface; the Effective storage space which provides a convenient interface for programmers or end users. Files in GriDaEn are divided into the following layers. Grid physical ?le: the ?les stored at local ?le system. Grid virtual ?le: global identi?er of grid ?le. Grid effective ?le: visible and operable by end user, and exclusive in users’ ?le space [10]. The EVP and GriDaEn are suitable models in VEGA for implementation of the grid community (also called agora) in resource and ?le management. We can see that agora in VEGA is one instance of the VO concept, in which different resources encapsulated by Web services can be shared by the members of a certain agora. The contents of the resources these members can get depend on the roles they play in the community. End users can specify grid services and user interface in EAD layer. So the EVP Model implemented by VEGA is helpful in building a CSCW environment, and can provide technique support for this collaborative work. More details about VEGA and its EVP Model can be found in vega.ict.ac.cn/gos/, [10,11].

Fig. 4. Architecture of grid system.

174

Z. Zhao et al. / Advances in Engineering Software 41 (2010) 170–179

4.1. Service description From the view of the SOA, this system integrates common services provided by the grid middleware VEGA and grid application services that we have developed according to the application requirement. These common services include services for resource management, security authenti?cation, ?le transfer, and so on. The application services are deployed in different institutions. Depending on the roles play in agora (such as carmaker, suppliers), the partners will have access to the services they need, and none to the others. The available application services to the carmaker:  ProjectInitiate: This service ?rst builds a VO for collaboration, and then uploads the CAR-FEM onto the compute partner. The global model will be uploaded only once for all in case of several suppliers taking part in the same project. The compute partner and the suppliers have no access to this model.  SubProjectInitiate: This service initiates a subcontracted part design project. It uploads the part’s environment models (ENVFEM, ENV-CAD) onto the compute partner’s site. At the same time, the service sends a noti?cation to the supplier to tell it that the subproject has initiated. The supplier has access to the submodels that relate to the part it designs.  PartAssemble: After the part design process, the supplier uploads the PAR-FEM onto the compute partner. Then, the carmaker invokes this service to assemble it to the whole model CARFEM to form the global model W-CAR-FEM.  CrashSimulate: This service provides compute resource for the crash simulation, the CAR-RES will be obtained when the simulation ?nishes. With the job monitoring module, the carmaker can check and control the progress of the calculation, such as stop the simulation, pause the simulation, and recalculation the simulation.  GetPartResults: Depending on the degree of con?dentiality speci?ed by the carmaker, this service will automatically extract the results (PAR-RES) that the supplier is allowed to get.  GetDeliveredPart: On noti?cation from the DeliverPart service, this service is called to get the delivered model of the designed part and the associated results of the crash analysis. The available application services to the suppliers:  GetEnvironment: On noti?cation from the SubProjectInitiate service, the supplier calls this service to get the environment models of the parts.  PartDeliver: If the calculation results of part meet the criterion, the supplier will call this service to deliver the part model to the carmaker. The work?ow of all the services is shown in Fig. 5. The Part Design shown in this ?gure is activities of the supplier designing the part at local host, and it may take more time than any other services. The red arrows indicate the noti?cation realized via email or a sign on webpage. In this system, both data storage and computing power are hosted at the compute partner’s site, and no one can access these resources directly unless these resources are related to the part they are designing. Thus, a user can only do what the service authorizes him to do. In addition, the grid middleware VEGA will take charge of the other security aspects (authentication of members of the VO, secured data transfers, etc.) and other common services such as resource management, ?le transfer, and so on. The ParAssemble service and The GetPartResults service can be technical challenges. We will discuss them in detail in the next section.

Fig. 5. The work?ow of the Services.

4.2. Key services 4.2.1. The ParAssemble service To automate the assembling of a supplier’s part model to the global part on a distant server, both parties (carmaker and supplier) should respect an agreed methodology. We will explain the conventional format of supplier deliveries in the context of a crash simulation based on LS-DYNA. This method has been applied successfully in an example involving a seat supplier and a carmaker.  PAR-FEM should comply with the numbering rules imposed by the carmaker. Numbering ranges for Nodes, Elements, Parts, Materials, Section de?nitions, Contacts de?nitions, Curve de?nitions, and Set (node, element, part) de?nitions are assigned to the suppliers.  PAR-FEM should include the Database de?nitions about which nodes, elements or parts will be output into the binary history ?les or the ASCII ?les.  PAR-FEM should include contact de?nitions indicating the contact interfaces between part and the ENV-FEM and constrained de?nitions. Furthermore, the numbering of nods, elements or parts in ENV-FEM must be reserved.  PAR-FEM should not include Control de?nitions.  The PAR-FEM is built based on the ENV-FEM, but it should not include elements in the part environment where the part is to be attached. After the supplier uploads the PAR-FEM, this service will create an FE model automatically by the INCLUDE control card which

Z. Zhao et al. / Advances in Engineering Software 41 (2010) 170–179

175

combines the PAR-FEM and the CAR-FEM to become the W-CARFEM. 4.2.2. The GetPartResults service After the SimulateCrash service, the analysis results of the whole car will be yielded. The results pertaining to the supplier’s parts are extracted from the global results, and part of them will be sent to the suppliers depending on the con?dentiality level speci?ed by the carmaker. The con?dentiality level would be as follows:  No results: The supplier can just check if the job ends in a normal termination status. Typically, in the case of a ‘‘low-cost” supplier, the carmaker would take charge of analyzing the results.  Part results: (high con?dentiality case) The supplier would be allowed to see the results related to his part only.  Full results: (trust relationship) The supplier is allowed to see the complete results of the whole car model. Some simulation tools such as PAM-CRASH can extract subsets of the whole results by using a special option of the solver that allocates the calculation of the part to a given processor while the other processors calculate the rest of the model. So each processor produces its own result ?le. While In LS-DYNA, the result is produced as a whole, and we have to extract part results from it. There are two kinds of result ?les. One is the ASCII ?les such as NODOUT, ELOUT, etc. and the other is the binary ?les such as D3PLOT. For ASCII ?le, the GetPartResults service can extract the subset of the whole results by ?le operation procedure using java language. For the binary ?les, the D3PART control card is used to specify the output of part results. 5. The trust relationship among partners Trust relationship is an important factor for cooperation networks to achieve their objectives. Trust relationship among VO members has been established by safety-based approach which focuses on avoiding possible loss of sensitive information during collaboration.

In the proposed vehicle crash safety design system, sensitive information usually refers to material constitutive laws of designed parts, modeling technique, simulation methods, etc. All these information are stored in two kinds of ?les. One is model ?les like CARFEM, PAR-FEM, and W-CAR-FEM, and the other is simulation result ?les like W-CAR-RES, CAR-RES, and PAR-RES. The ENV-FEM and ENV-CAD are the only ?les that do not contain sensitive information. All these ?les are under the management of the GriDaEn model, the ?le management system in VEGA. VO members who play different roles in the collaboration have different access to these ?les. The carmaker can get access to CAR-FEM, ENV-FEM, ENVCAD, and CAR-RES. Most of the suppliers have access to ENVFEM, ENV-CAD, PAR-FEM, and PAR-RES. The compute partner does not have access to any of these ?les. With the help of the GriDaEn model, both the carmaker and the suppliers need not worry about the loss of the sensitive information of their own. The trust relationship among carmaker, suppliers and the computer partner is effectively built not only by adopting the GriDaEn model as mentioned above but also the collaboration policy and well designed services. Modeling policy for suppliers is ?rst established by carmaker to help assemble the parts successfully. Then, the environment model is provided to the supplier to ensure that the part is compatible with the whole car. Since the part the supplier designs has relationship only with its environment, it is appropriate to provide the supplier with the environment part that does not contain any sensitive information instead of the whole car model. Furthermore, well designed services such as The ParAssemble service, CrashSimulate service and GetPartResults service are developed. Actually, at the beginning of our research, the assembling of the CAR-FEM and PAR-FEM as well as the dividing of the W-CAR-RES need to be done under the help of the compute partner, which means that the compute partner has to take part in these two processes and manipulate ?les containing sensitive information. During these processes, it is possible that the compute partner will get sensitive information from the manufacture and the suppliers. To solve this problem, we proposed the ParAssemble and GetPartResults services in the later research described in Section 4. With these two services, the models can be assembled automatically and the simulation results of the whole car can be divided according to the parts they relate to. At the same time,

Fig. 6. Grid test bed topology.

176

Z. Zhao et al. / Advances in Engineering Software 41 (2010) 170–179

sensitive information is kept unknown from the compute partner to ensure the con?dentiality security. The compute partner in the VO acts as a calculator who provides calculation services. These calculation services need ?les (CAR-FEM, PAR-FEM) from the carmaker and the suppliers that contain sensitive information. Although the compute partner provides services, he cannot get these ?les. The tasks performed by computer partner are described as follows. At the beginning of the collaboration, after the carmaker ?nishes ProjectInitiate service and a VO for vehicle crash safety design is built, the compute partner joins this VO, and registers the ParAssemble service, CrashSimulate service and GetPartResults service into the grid system. After that, the compute partner no longer takes part in these services. The services he registered will be invoked by carmaker when needed as described in Section 4. Because the compute partner cannot get any sensitive information, both the manufacturer and supplier need not place full trust on the computer partner. Although there is authorization mechanism of ?le management system in VEGA, some manufactures and suppliers may still worry about ?le security problem, and want to store their model ?les at their local hosts as far as possible. The GriDaEn model can meet this requirement. The manufacture and the suppliers can choose

their local sites as the physical storage space, and the global space of VO as the effective storage space as described in Section 3.1. From the description above, we can see that this system has different ways to protect the member’s speci?c knowledge even if the VO members do not fully trust each other. This mechanism makes the system useful in many kinds of situations. 6. Application and case study 6.1. Test bed To validate the Scenario and the architecture system, this research builds a grid-based system test bed in the LAN of Computer Aided Design Lab in Shanghai Jiao Tong University. The topology of test bed is shown in Fig. 6. The test bed is composed of three slave nodes, 1 master node and a Grid CA node. The slave nodes represent car manufacturer, supplier and the compute partner, respectively, and are all connected with the master node. The master node is divided into two parts: the portal (Front end) and the server (Back end). According to Section 4, besides the common services contained at each node, the application services are deployed at corresponding nodes. The slave node of manufacturer provides project management services such as ProjectInitiate service, SubProjectInitiate service, and data service, etc.; the slave node of supplier provides data service, design activity, etc.; the slave node of compute partner which is further divided into two parts provides CrashSimulate services, ParAssemblet services, GetPartResults service, data service, etc. The master node provides user management service, monitoring service, etc. Grid CA node provides x.509 certi?cate management. Users can log in the system through master node with accounts authorized and authenticated by the slave node, and access the granted resources of other slave node. In other words, users generally cannot access the services and applications of slave nodes directly.

Fig. 7. Full-scale side impact FEM.

Fig. 8. Fig. the seat model and its environment models.

Z. Zhao et al. / Advances in Engineering Software 41 (2010) 170–179

177

6.2. Performance of the case In this section, a case of collaborative design for crash safety between a car maker and a seat supplier will be presented to demonstrate the system capability. All partners join in the simulation of

the full-scale side impact test to evaluate vehicle crashworthiness and occupant protection according to the National Crash Standard. The models for side impact simulation include the ?nite element model of impacted vehicle, Moving Deformable Barrier (MDB), and EuroSID dummy, in which there are 391 parts,

Fig. 9. Key interfaces in the process.

178

Z. Zhao et al. / Advances in Engineering Software 41 (2010) 170–179

Fig. 10. Portal of services for the collaborative simulation system.

124,063 elements, and 136,858 nodes. The MDB impacts the car from the side of driver at the speed of 50 km/h. The models are shown as Fig. 7. The seat supplier builds the PAR-FEM based on the method proposed in Section 4.2. The designed part (seat) is different from general part provided by suppliers in simulation environment. In this model, the dummy needs to be put onto the seat, so the PAR-FEM should include the dummy model. The dummy and the seat are related by de?ning the contact interfaces between the seat pan and the dummy’s buttocks. Range numbers assigned by the carmaker was 1,000,000– 1,050,000. The carmaker decided the critical nodes that should be checked to see whether the design meet the crash criteria, such as the nodes on the dummy’s head and rib, and some key nodes on seat. The data about these nodes will be put to the NODOUT ?le. Carmaker de?ned the binary ?le about the seat with the help of the card D3PART. Besides the contacts between the seat pan and the dummy’s buttocks, the supplier also de?ned the contact interface between other parts of the dummy and the seat, between the dummy and the seat environment, and between the seat and the environment. At last, the supplier connected the seat with the environment through spot-weld constrain. The Fig. 8 shows the seat FEM and images of the seat model together with the environment model. 6.3. Portal The system provides a portal by web-browser for users. Users get proxy certi?cates from CA and register in system. The system provides different log in roles for the users, corresponding to the different roles they play in the system. Users can log off without stopping the execution of the service and log in again at a later stage to view the progress. This portal is a user-centric environment that provides a homogeneous interface (as shown in Figs. 9 and 10) to a set of heterogeneous resources and functions from standard web-browsers. The interface includes support for most activities for a regular user, such as to upload and download models, submit and delete jobs, monitor job status, etc.

7. Conclusion and expectation CSCW and grid technology both aiming to support collaboration are closely related and integrated. Grid technology could provide a general-purpose technology platform for CSCW to build and run collaboration applications. The proposed grid-based system facilitates various collaborative design and remote simulation activities. It enables geographically dispersed partners to join a VO and work together on a common design project. As this system is conformed to the OGSA, the distributed grid resources are encapsulated by grid application services, so the VO numbers including carmaker and suppliers can share these resources dynamically. The agora concept and the EVP Address Space Model coming from the VEGA middleware make establishment of the collaborative system more convenient and effective. The GriDaEn model coming from the VEGA middleware and the well designed services are used to build the safety-based trust relationship between the VO members. Carmaker, suppliers, and compute partner need not fully trust each other during the collaboration. To contribute to protecting IPR from the outsourcing of design activities, this research proposes a set of methods based on LSDYNA such as the assemble technique of FE models and the extraction technique of the calculate results. The case that a carmaker collaborates with a seat supplier based on LAN shows that this grid-based collaborative system architecture and the application services we developed can be an effective way for the carmaker and its suppliers to solve the problem of the collaborative design for vehicle crash safety design. But collaboration in a grid environment is still a young ?eld. There are many new contents that need further research. This paper represents our current status in developing collaborative design grid environment. In future, the follow aspects need to be improved: (1) Although the method concerned in Section 4.2 about the parts assemble can be used to assemble a number of FE models to become one model, and it has been applied in

Z. Zhao et al. / Advances in Engineering Software 41 (2010) 170–179

179

an example successfully, there are also limitations about it. For example, when the numbering changed in the CARFEM, the PAR-FEM should be modi?ed. In addition, when a designed part has relationship with another part, the PARFEMs of the two parts will be dif?cult to produce. We hope a more ?exible and advanced method can be found in future to overcome these limitations. (2) No model check service: Now, we check the model in the CrashSimulate service based on the LS-DYNA solver in which the solver will stop when there is incompatibility in the model and also display the error message about the incompatibility. We need a more advanced tool to realize this function in the future. (3) We hope to ?nd an effective encryption mechanism about the ?nite element model in the future, and make the model assemble more ?exibly.

Shanghai Automotive Industry Corporation (SAIC) and Shanghai Supercomputer Center (SSC) are sincerely acknowledged. References
[1] Kamel NN, Davison RM. Applying CSCW technology to overcome traditional barriers in group interactions. Inform Manage 1998;34:209–19. [2] Huang S, Hu Y, Li C. A CORBA-based computer support cooperative work for dynamic alliances. Int J Adv Manuf 2002;19:752–5. [3] Fang WD, Tang MX, Frazer John Hamilton. Supporting collaborative product design in an agent based environment. In: IEA/AIE 2003, vol. 44; 2003. p. 447– 60. [4] Li Zhi, Jin Xianlong, Cao Yuan, Zhang Xiaoyun, Li Yuanyin. Architecture of collaborative design grid and its application based on LAN. Adv Eng Softw 2007;38(2):21–132. [5] W3C, Web services architecture, <http://www.w3.org/TR/ws-arch/>; 11.02.04. [6] Foster I, Kesselman C, Tuecke S. The anatomy of the grid: enabling scalable virtual organizations. Int J High Perform Comput Appl 2001;15:200–22. [7] Foster I, Kesselman C. The grid: blueprint for a future computing infrastructure. Morgan Kaufmann Publishers; 1999. [8] Foster I, Kishimoto H, Savva A, Berry D, Djaoui A, Grimshaw A, et al. <ttp:// www.ggf.org/documents/GFD.30.pdf>. [9] Foster I, Kesselman C, Nick J, Tuecke S. The physiology of the grid: an open grid services architecture for distributed systems integration. DRAFT document, 2002, <http://www.globus.org/research/paper/ogsa.pdf>. [10] Xie X, Xiao N, Xu Z et al. CNGrid software 2: service oriented approach to grid computing. In: Proceedings of the UK e-Science all hands meeting 2005, Southampton, UK, EPSRC. p. 701–8. [11] Zhiwei Xu, Ning Yang, Huaming Liao. Vega information grid for collaborative computing. CSCWD; 2004. p. 1–10. [12] Foster I. Service-oriented science. Science 2005;308(5723):814–7.

Acknowledgement This work is supported by the National Natural Science Foundation of China (Grant No. 90612017 and 60174023), the Found of RFDP (Grant No. 20070248110). Our industrial collaborators and informants Shanghai Automotive Engineering Academy (SAEA) of


相关文章:
更多相关标签: