EARTHQUAKE ENGINEERING AND STRUCTURAL DYNAMICS Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 Published online 27 June 2007 in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/eqe.729

ISEE: Internet-based Simulation for Earthquake Engineering—Part II: The application protocol approach Kung-Juin Wang1, † , Keh-Chyuan Tsai1, ∗ , Shiang-Jung Wang1 , Wei-Choung Cheng2 and Yuan-Sen Yang2 1 Department

of Civil Engineering, National Taiwan University, and National Center for Research on Earthquake Engineering, Taipei, Taiwan 2 National Center for Research on Earthquake Engineering, Taipei, Taiwan

SUMMARY This paper develops new techniques for integrating a number of different structural laboratories together through the Internet in order to jointly conduct a single structural experiment. A computer-networking platform, called Platform for Networked Structural Experiments (PNSE), was developed to achieve this goal. PNSE runs directly on top of the Transmission Control Protocol/Internet Protocol (TCP/IP). It is a multi-client system consisting of a number of client programs, which include one command generation program and a number of facility control programs, connected to a server program via TCP point-topoint connections across the Internet. An associated application protocol, called Networked Structural Experiment Protocol (NSEP), was developed to work with the PNSE. In addition to communication rules, the NSEP defines general experimental information, significant laboratory events, commands and signals, as well as obligated behaviours of all PNSE programs. Both domestic and transnational pseudo-dynamic (PSD) tests were performed to verify the validity and efficiency of the PNSE. Test results showed that on the PNSE: signals were correctly transmitted; significant laboratory events were promptly reflected; and data transmission was remarkably efficient, with the round-trip time (RTT) between Taiwan and the United States less than 0.1701 s. The characteristic of environment independency was also demonstrated through the successful collaboration of different facility control programs running on different operating systems. Copyright q 2007 John Wiley & Sons, Ltd. Received 15 June 2006; Revised 16 May 2007; Accepted 17 May 2007 KEY WORDS:

internet; hybrid testing; ISEE; pseudo-dynamic; TCP/IP; application protocol

∗ Correspondence

to: Keh-Chyuan Tsai, Department of Civil Engineering, National Taiwan University, and National Center for Research on Earthquake Engineering, Taipei, Taiwan. † E-mail: [email protected] Contract/grant sponsor: National Science Council; contract/grant number: NSC91-2711-3-319-200

Copyright q

2007 John Wiley & Sons, Ltd.

2308

K.-J. WANG ET AL.

INTRODUCTION Structural laboratories today are facing increasing demand for the testing of large and realistic specimens. Rather than endlessly increasing the capacity of each laboratory, a more practical approach would be to link a number of geographically separated laboratories via the Internet and conduct a single collaborative experiment. Besides investment savings, additional benefits that can be drawn from such integration include the opportunity for the exchange of experiences and technologies between laboratories, as well as the promotion of further collaboration on research works though the shared use of experimental data. Details of several similar research efforts can be found in References [1–7]. At the National Center for Research on Earthquake Engineering (NCREE) in Taiwan, a project named Internet-Based Simulation for Earthquake Engineering (ISEE) [8] was initiated to achieve the goal of conducting collaborative structural experiments through the Internet. ISEE uses two different approaches: the Database (DB) approach and the Application Protocol (AP) approach. Detailed descriptions of the DB approach can be found in Reference [9]. This paper presents the architecture and implementation of the AP approach. The Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite was designed as an open standard to meet the demand of data transmission on rigorous network conditions [10, 11]. TCP/IP guarantees reliable data transfer [10–12] between processes running on different hosts. This de facto standard is currently supported by most operating systems and programming languages. The TCP/IP protocol suite allows applications running on different hosts to communicate across heterogeneous networks as if they were directly connected, provided a well-defined AP exists. An AP defines the types of messages to be exchanged, the syntax of the various message types, the semantics of the fields within each message type, and the rules for determining when and how a process sends and responds to messages. A computer networking platform, named Platform for Networked Structural Experiments (PNSE), and its associated AP, named Networked Structural Experiment Protocol (NSEP), were developed to demonstrate the AP approach.

PLATFORM FOR NETWORKED STRUCTURAL EXPERIMENTS (PNSE) The PNSE provides a reliable platform for robust progression of networked testing. It is a multiclient computer networking system with each client connected to the server via a point-to-point TCP connection channel. Figure 1 illustrates the architecture of PNSE. Communication between a client and the server is achieved by sending and receiving data packets that are well defined by an associated AP on the established TCP connection. Only one port is used by the server to accept connection requests from each client. This port number can be arbitrarily selected before notifying clients prior to the start of the collaborative test. Some well-known ports, such as 80 (HTTP) and 443 (HTTPS), can be used although port numbers larger than 1023 are recommended. The PNSE server maintains an individual TCP connection with each of the clients. Once the connection is established, the socket [12] remains open for the duration of the test. A detailed description of TCP connections can be found in Reference [12]. Two kinds of clients, the Command Generation Module (CGM) and the Facility Control Module (FCM) were defined on the PNSE. The CGM generates the commands to be imposed on specimens by all participating FCMs. Depending on the scenario, a CGM could be a numerical integration algorithm for pseudo-dynamic (PSD) testing, a module that sends out predefined consecutive commands for quasi-static or cyclic tests, or simply an application with an appropriate user interface to allow remote manual command input. In each Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

INTERNET-BASED SIMULATION FOR EARTHQUAKE ENGINEERING

PNSE

2309

Server data repository

web server

viewer1

video server

viewer2

command responses CGM

FCM1

FCM2

camera

Figure 1. The architecture of PNSE.

execution loop, designated as a ‘command cycle’ in this study, the commands are generated by the CGM and sent to the server, which then dispatches the commands to all participating FCMs. After executing the command and measuring and/or calculating the specimen responses, the FCMs will send the response data back to the server, which then forwards this data to the CGM to complete one command cycle. Command cycles are then repeated until the test ends. Signals on the PNSE refer to values that change continuously with respect to time. Typically, they include the structural responses measured and/or calculated by the FCMs and the commands generated by the CGM. Signals are characterized as ‘critical signals’ or ‘open signals’. Critical signals refer to those that are prerequisite for the progression of testing. For example, the computed target displacement and the measured restoring forces in a PSD test scenario are critical signals. They are critical in the sense that if any fail to reach their destination, the whole experiment would be suspended. Open signals, on the other hand, refer to data values that have been designated for near real-time broadcast on the Internet, for example, strain gauge values. Even without transmitting them in each command cycle, the networked test can still advance to the next step. Nevertheless, typically open signals are carefully chosen and broadcast in each command cycle since they facilitate monitoring of the test and understanding of the specimen behaviour. In networked testing, human communication is still necessary because it is difficult, if not impossible, to comprehensively define in the AP all possible events that may occur in a structural experiment; for example, the detailed damage condition of the specimen or the corresponding actions taken to fix it. The PNSE addresses this issue by defining a data packet type in the associated AP that contains readable text to allow direct human communication. In the course of an experiment, the test may be suspended or even stopped prematurely for a variety of reasons. Due to the importance of laboratory safety, all participating FCMs have authority to autonomously change their individual running state, although they are required to report the change to the system. Firewalls have been widely used by organizations to protect their internal networks due to the threat of malicious attacks via the Internet. In some highly protected network environments, existing firewalls may prohibit networked communication due to the security policies specified by the network administrators. In fact, firewalls today are sufficiently advanced that in addition to prohibiting entry of data packets originating from certain IP addresses and port numbers, they can also be configured to examine the packet content and filter accordingly; even if the transmitted content is encapsulated by widely used protocols like HTTP or FTP. In such cases, the PNSE may not be able to be established unless a relevant change to the firewall configuration is granted by the network administrators. However, given that the PNSE is a legitimate application developed to promote sharing of resources and information, there should not be an issue with obtaining the appropriate network communication resources. Therefore, the recommended approach to overcome Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

2310

K.-J. WANG ET AL.

such prohibition on data transmission is to apply for firewall exemption from the corresponding network administrators.

NETWORKED STRUCTURAL EXPERIMENT PROTOCOL (NSEP) In this study, an AP named NSEP was developed to work with the PNSE. The NSEP defines the following in detail: (1) the syntax of a data packet; (2) general information about the structural experiments; (3) significant laboratory events; and (4) signals, including commands and responses. The NSEP also stipulates the behaviour of the server and the client on receiving a specific data packet. The general syntax of NSEP data packets can be expressed as: LENGTH+TYPE+PARAMLIST, where the plus sign only denotes concatenation, and is not a part of the data packet. The LENGTH parameter specifies the total length of a data packet. The receiving end needs this explicit information to correctly retrieve a data packet from the transmitted data stream. The TYPE parameter specifies the kind of data a packet holds. It is used in interpreting the parameters contained in the PARAMLIST. The PARAMLIST is an optional list of parameters that makes a data packet comprehensive. The number, primitive type, and actual content of those parameters depend on the parameter TYPE. Detailed definitions of data packets can be found in Reference [8]. NSEP data packets are listed in Table I. The length of the NSEP application-layer [12] message is determined by its PARAMLIST and varies from test to test; for example, the number of experimental degree of freedom (DOF) involved. The typical length is less than 100 bytes, which is very small compared to those encountered in other Internet applications; for example, web browsing, file transferring, and e-mail delivery. Therefore, NSEP packets typically need little transmission time [12]. The PNSE server sits in the central position of a star topology connection configuration. However, apart from maintaining a login procedure for each connection attempt, it does not

Table I. Short description of NSEP data packets. TYPE

Short description

ERROR LOGIN EXPINFO EXPSTATE CLNSTATE CSIG CGM CSIG FCM OSIG SC OSIG CS DISCUSS Copyright q

Used to make a notification when an error occurs Contains the client name and password for the login procedure Contains meta data, such as the test name, the number and names of the clients, duration or number of steps of the experiment, of the test Contains the current running states of the test and of all clients. Defined values include: ES NOTREADY, ES RUNNING, ES HOLDING, ES INTERRUTPED TEMP, ES INTERRUPTED, and ES FINISHED Contains the client’s current running state. Defined values include: CS DISCONNECTED, CS NOTREADY, CS RUNNING, CS HOLDING, CS INTERRUPTED, and CS FINISHED Contains current critical signal values sent between the CGM and the server Contains current critical signal values sent between the FCM and the server Contains current open signal values sent from the server to all clients Contains current open signal values sent from a client to the server Contains the receiver’s ID and human readable texts for instant discussion

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

INTERNET-BASED SIMULATION FOR EARTHQUAKE ENGINEERING

2311

Table II. Communication/actions in the implementation example. No.

Packet

From

To

Packet/Action description

1 2 3 4

— — LOGIN ERROR

— — C Server

— — Server C

5

EXPINFO

Server

C

6

EXPSTATE

Server

C

7 8 9

— CLNSTATE EXPSTATE

— C Server

— Server C, L1, L2

10

—

—

—

11 12

EXPSTATE CSIG CGM

Server C

C, L1, L2 Server

13 14

CSIG FCM —

Server —

L1, L2 —

15

CSIG FCM

L1, L2

Server

16

CSIG CGM

Server

C

17

OSIG CS

C, L1, L2

Server

18

OSIG SC

Server

C, L1, L2

19 20

— CLNSTATE

— L2

— Server

23 24

EXPSTATE CLNSTATE

Server L2

C, L1, L2 Server

25

EXPSTATE

Server

C, L1, L2

26

CLNSTATE

C

Server

27

EXPSTATE

Server

C, L1, L2

28

CLNSTATE

L1, L2

Server

The server program is launched C connects to the server C submits user name and password to login Server sends an error-free packet to C to indicate a successful login procedure General experimental information including the experiment name, information of all the clients, the duration of this experiment, and information about the open signals are sent The state of the project and that of all the clients, although L1 and L2 are still not connected Steps 2–6 repeat for L1 and L2 C changes its state to CS RUNNING Server notifies all clients of the change to the state of the experiment and of client C. The state of the experiment is still ES NOTREADY Steps 8–9 repeat for L1 and L2. The test state changes to ES RUNNING once all clients are in the state of CS RUNNING The test state changes to ES RUNNING The first command for both L1 and L2 (usually the initial conditions) The individual command for L1 and L2 L1 and L2 execute the commands and prepare the corresponding critical response The restoring force contained in the individual critical response packet is sent to the server The server integrates the two CSIG FCM packets into one CSIG CGM packet and sends it to C to indicate the end of command execution C, L1, and L2 collect their open signal values and send them to the server The server integrates the above three OSIG CS into one OSIG SC and sends it to all the clients Steps 12–18 repeat if everything goes fine L2 changes its state to CS HOLDING for some reason. An example would be for closer inspection on the specimen The experiment state changes to ES HOLDING L2 finishes inspection and changes its state back to CS RUNNING The experiment state changes back to ES RUNNING again and the test continues (Steps 12–18 repeat) The analysis duration is finished. C changes its state to CS FINISHED The experiment state changes to ES FINISHED and this change is sent to all clients L1 and L2 also change their states to CS FINISHED. Test finishes

Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

2312

K.-J. WANG ET AL.

serve as an administrator of the system. It only facilitates the data exchange function for all clients, and does not have specific control over any client. For example, it does not actively query for commands nor query the running state of any client. Instead, it is the responsibility of the CGM and all the clients to actively send the relevant information. In other words, both the server and clients are stipulated to make active notifications (AN), meaning that the one who owns the relevant information should actively inform the other side of the connection when appropriate.

An illustrative example To illustrate the communication between the PNSE server and clients, detailed packet transmission of a networked sub-structural PSD (SubPSD) test on a two-storey braced frame is shown in Table II. Two laboratories named L1 and L2 and a finite element analysis (FEA) program named C were connected to the Server through three TCP connections to perform the collaborative test. The numerical model shown in Figure 2 has 14 elements, where elements 5 and 12 were tested in L1 and L2, respectively. All other elements were analysed by C. The information that was determined before the test started included the following: the IP address of the server, the port number to be used, the client information (name, password, ID), general project information such as the structural model, the testing DOFs, the earthquake excitation, the project name, the test duration, and the contents to be contained in the critical signal data packets CSIG CGM and CSIG FCM. After the basic settings have been determined, the collaborative test was conducted. The step-by-step test procedures are listed in Table II. It should be noted that the step sequence and the contents of each data packet listed in Table II are for illustrative purposes only. In a real implementation, transmission of certain data packets such as LOGIN, ERROR, and EXPINFO always occurs at expectable times. However, transmission of other data packets, such as EXPSTATE, CLNSTATE, CSIG CGM, CSIG FCM, OSIG CS, OSIG SC, and DISCUSS, depends on the client states, the design and implementation of all participating programs, or the actions taken by the operators of the client programs.

13

14

8

5

7 12 6

8

10

9 6

4

11

7

1

3

5 2 1

2

3

4

Figure 2. The two-storey frame model. Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

INTERNET-BASED SIMULATION FOR EARTHQUAKE ENGINEERING

2313

CHARACTERISTICS OF PNSE Environment independent The PNSE is an environment-independent platform since it is constructed based on the widely supported TCP/IP protocol suite. High interoperability can be assured regardless of heterogeneous environments due to diverse types of computer hardware, operating systems, programming languages, and facility controllers. This suggests that minimum programming effort will be required to incorporate existing programs running in these diverse environments. Event-reflective As mentioned earlier, in addition to the prerequisite commands and responses, significant laboratory events such as changes to the running state of FCMs are also adequately defined in NSEP. Combining this with the stipulation of AN, PNSE becomes an event-reflective platform, meaning a platform with a formal mechanism that supports reflection to all other participating entities of the events that occur in any participating laboratory during a collaborative test. Thus, all participants can be kept aware of the overall running condition of the test. Truly cooperative and event-driven For any PNSE client, any information coming from the server has actually originated from other clients. This suggests that the PNSE is a truly cooperative platform, because every client plays an indispensable role and needs to behave as stipulated in order to collaboratively make the experiment in progress. From a software programming viewpoint, this also means that the PNSE is an event-driven system. In contrast to a traditional batch programmed system, where the flow of the program is determined by the programmer, an event-driven system is programmed in such a way that the program flow is determined by messages from other programs, or user actions, for example, mouse kicks or key presses. PNSE is an event-driven system since test progression is actually a succession of serial responsive behaviours to all events defined in the NSEP. An advantage of being an event-driven system is that the PNSE has enhanced scalability. This is because as possible events and client interactions within a test become more and more complex, all that is required to scale up the PNSE correspondingly is to add more message handling functions in the programs without the need to drastically modify the program architecture. Efficient data transmission The requirement for AN not only makes the PNSE event-reflective, truly cooperative and eventdriven, it also increases the overall data transmission efficiency. A contrary but commonly used approach to transfer messages between processes is the polling mechanism (PM). This approach works by having the program that requires the relevant information actively querying for the information repeatedly until it is acquired. Techniques utilizing the PM to exchange data over networks have been widely adopted in other research works due to their simplicity. Examples include accessing shared used disk files [1–4], and depositing and retrieving data from a DB repository [9]. However, PM generally decreases the overall efficiency of the system because the polling has to be performed sufficiently frequently such that the desired information is acquired sufficiently promptly. This technique wastes a lot of time and network resources as the information queried is usually not available at the time of the query. On the other hand, using AN increases the Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

2314

K.-J. WANG ET AL.

system’s efficiency greatly since all information is transmitted automatically to the relevant party without needing to spend any time and network resources for continuous polling. Simplified communication and maximized extensibility All PNSE clients connect only to the server, rather than to the other clients. As such, all data packets are transmitted through the server to their final destinations. Having this detour consumes more time in data transmission but the advantage is that it tremendously simplifies the network communication flow since each client program only has to handle information that comes from the server. This also translates to maximized extensibility of the platform as the design saves a large amount of programming effort, especially when events and interactions are complex. Maximum flexibility to support versatile test configurations Although the NSEP differentiates signals into two categories according to their nature, critical and open, it does not concretely define the content for critical signals since content can change from case to case. For example, in some testing arrangements, there could be complex geometric relationships between the structural DOFs and the actuator orientation, while in other cases they could be equivalent. NSEP does not define the contents of the CSIG CGM or the CSIG FCM packets. Instead, the contents should be determined and agreed upon by the researchers participating in the collaborative test during the planning stage. This provides users the maximum flexibility when using the PNSE to achieve their individual specific testing goals. In addition, signals are categorized in order to allow different operations to be carried out upon them. This is especially useful when the integration time step has to be set to a small value due to stability or accuracy issues, while equally dense measurements of structural behaviour is not necessary or unaffordable. Resuming ability after accidental disruptions In the course of an experiment, there could be instances of accidental disruptions that either temporarily or permanently interrupt the test. Examples include network connection failure, program run-time errors, or damage that occurs to unexpected parts of the specimen. If all the specimens remain within their elastic ranges when an accidental disruption occurs, all that needs to be done is to re-conduct the test again from the beginning after the problem is solved. However, if some specimens have entered their inelastic zone, conducting the test from the beginning again would not be ideal as this would cause all the specimens, including those that have no problems, to undergo erroneous plastic deformation. To address this issue, PNSE clients are designed to have two different disconnecting mechanisms: explicit disconnection (ED) and quiet leave (QL). ED refers to situations where the client explicitly sends out a CLNSTATE packet, with its running state set to CS DISCONNECTED, before it actually disconnects from the server. QL refers to situations where the client directly disconnects from the server, whether intentionally or accidentally, without sending any notification. Once a client disconnects, the server will change the current experiment running state to ES INTERRUPTED, if the client disconnects by ED, or ES INTERRUPTED TEMP, if the client disconnects by QL. An ES INTERRUPTED state indicates that the test is permanently interrupted and is unable to be resumed from the interrupted point, even if only one client has problems. On the other hand, an ES INTERRUPTED TEMP state indicates that the test is only temporarily interrupted, and test resumption is possible after the problems that caused the disconnection are fixed and the disconnected clients are reconnected Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

INTERNET-BASED SIMULATION FOR EARTHQUAKE ENGINEERING

2315

back to the platform. Therefore, clients with no problems will not be forced to disconnect from the system when other participating entities fail. Instead, they simply wait for the test to be resumed as if the experiment’s state were ES HOLDING. When each disconnected client reconnects to the PNSE server, the server will change the experiment state to reflect the reconnection. The new state could be ES RUNNING, ES HOLDING, or perhaps remain as ES INTERRUPTED TEMP, depending on the combination of all clients’ running states at that point of time. The test will then continue when all clients are reconnected. Through this design, if some specimens have already entered the plastic zone, and the CGM QLs for any reason, all the specimens will remain stationary and wait for the CGM to reconnect. The test can then be resumed directly from the previously interrupted point without any specimen undergoing erroneous plastic deformation. However, if any FCM QLs when some specimens have entered the plastic zone, the specimen tested at the failed laboratory may undergo erroneous plastic deformation as it depends on the failure condition and the manner in which the FCM responds to it. However, erroneous plastic deformation will not be experienced by other specimens located in those laboratories that work smoothly. This contrasts with the DB approach [9], where if any one client has problems during the test, all clients will be forced to disconnect. The test can only be resumed by creating a new test and reconnecting all clients to the DB server. As such, the PNSE has a superior mechanism for handling accidental disruptions to the collaborative test.

EXPERIMENTAL VALIDATION Two-site experiment on a double-skinned concrete-filled-tubular (DSCFT) bridge To investigate the feasibility and data transmission efficiency of the PNSE, a series of transnational PSD tests were conducted on a two-pier bridge system subjected to two-direction excitation using data from the 1999 Chi–Chi earthquake. The peak ground acceleration was adjusted to keep the specimens within their elastic range since the structural behaviour of the specimens is not the main interest of this study. Figures 3 and 4 show the numerical model and photographs of the specimens. Details of the specimen design and testing parameters can be found in Reference [13]. The two piers were fabricated and tested in the NCREE laboratory (NCREELab) and the National Taiwan University laboratory (NTULab), respectively. The hydraulic control systems employed in NCREELab and NTULab were MTS FlexTest IIm and MTS 407 controllers, which are, respectively, controlled by FCMs coded using the C + + and LabVIEW programming languages. Pure numerical simulations were also performed for comparison purposes. Three PSD tests, Test A, Test B, and Test C, were conducted on the specimens. All testing parameters were exactly the same, except for the locations of the PNSE server and the CGM program. In Test A, both the server and the CGM ran on the same computer at NCREE. In Test B, the server program ran at NCREE and the CGM ran at Stanford University. In Test C, the server resided at Stanford University and the CGM at NCREE. It was obvious that Test C, where all packets had to be transmitted to the United States and then back to Taiwan, would be the most challenging. The application programming interface (API) used to implement the network communication is the Windows Sockets API (WinSock), which is a standard system library. Figure 5 compares the displacement commands sent and received by the CGM and the FCM. It also compares the results between those obtained from the numerical analysis and those from the experiment. It can be seen that the signals were correctly transmitted, and that the test results matched those obtained with the simulation. Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

2316

K.-J. WANG ET AL.

DOF2

DOF4 DOF3 2.37 m

DOF1 C1 Y X

C2

6.0 m

Figure 3. The bridge model for verification test.

NTULab

NCREELab

Figure 4. The DSCFT pier specimens.

The data transmission efficiency was explored by investigating the timestamps recorded in each command cycle. The lengths of the NSEP application-layer messages in this test were 42 and 36 bytes for CSIG CGM and CSIG FCM packets, respectively. Table III lists the average time consumed on PNSE, and the time needed for the Microsoft Ping program. The Ping program was executed under similar network conditions for comparison purposes. It can be seen that Test C was the worst case, as the data were transmitted between Taiwan and the United States. The round-trip time (RTT), that is, the time for a packet to travel from client to server and then back to the client, was 0.1701 s. Comparing this to the result of 0.1608 s obtained by the Ping program suggests that data transmission on PNSE was efficient as it was almost as fast as what the operating system could provide. Compared with conventional PSD tests, the additional time required to transmit data across the Internet for each integration step is only 0.3394 s, which is quite acceptable. This is calculated using the formula: RTTCGM + max(RTTNTULab , RTTNCREELab ) = 0.1693 + max(0.1651, 0.1701). Results of Test B were also compared with Experiment 153 in the DB approach, where both the CGM and the Analysis Engine ran at Stanford University [9]. The PNSE exhibited much better working efficiency as the average time for data transmission and data processing by the AP and DB Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

2317

INTERNET-BASED SIMULATION FOR EARTHQUAKE ENGINEERING

5 Disp. (mm)

NTULab Command 0 sent -5

received

0

20 Time (sec)

Disp. (mm)

5

NTU-X, TCU082, PGA=0.00377g, M=507.2t, ξ=2%

0 Analysis -5

Test

0

20 Time (sec)

Figure 5. Comparison of the displacement time histories (sent/received and simulation/ experiment) for test C in the x-direction.

Table III. Time statistics on PNSE. Activity WTCGM RTTCGM

Test A

0.0060 0.1661 0.1628 0.0096

0.0153 0.1693 0.1653 0.0459

PNSE Ping

0.0037 <0.001 0.5512

0.0056 <0.001 0.5486

0.1651 0.1625 0.6071

PNSE Ping

0.0046 <0.001 0.6356

0.0039 0.0070 0.6106

0.1701 0.1608 0.6540

0.6634

0.7963

1.0545

WTNTULab RTTNCREELab

Test C

0.0180 0.0080 <0.001 0.0437

PNSE Ping

WTServer RTTNTULab

Test B

WTNCREELab Ttotal

Notation: WTx , working time of module x; RTTx , round-trip time between module x and the server. Note: 1. Time is recorded in units of s/step. 2. Internet time indicates the time needed for a round trip.

approaches were about 0.1813 and 1.944 s, respectively [9]. The time history of the time consumed for data transmission in Test C, shown in Figure 6, indicates that the transmission was acceptably stable since only a few spikes were observed. Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

2318

K.-J. WANG ET AL.

Time (s)

1.2 Internet time (Test C)

CGM NTULab NCREELab

0.6

0

0

1000 Step No.

Figure 6. History of time consumed in data transmission over the Internet.

Single-site experiment on a concrete-filled-tubular/buckling-restrained-braced (CFT/BRB) composite frame Another series of networked PSD tests were performed on a full-scale three-storey three-bay CFT/BRB composite frame using the PNSE [14, 15]. It was a single-site experiment, but the PNSE was still employed to display the experimental data on the Internet in near real time, and to verify that the PNSE was environment independent and had the capability of event reflection. In these tests, a FreeBSD [16]-based CGM was used in the PSD testing procedure. The network communication was implemented using Berkeley Software Distribution (BSD), which is a standard system library on Unix-like operating systems. Figure 7 shows the typical windows displayed on the Internet [17] during and after the course of the experiment. It proves that applications running on different operating systems can be successfully incorporated into the PNSE. The states of the whole experiment and of all the clients were also found to be reflected correctly and promptly on the PNSE. Single-site SubPSD test on a two-storey buckling-restrained-braced frame (BRBF) Traditionally, to conduct a SubPSD test, one had to modify a FEA program so that in addition to performing dynamic structural analysis, the program also had the ability to drive the actuators and read force responses from the control and measurement facilities. However, this kind of modification typically introduces maintenance and/or extensibility problems because it increases the complexity of the program architecture by merging the functions of structural analysis and facility control into one program. Ideally, the FEA program should not have any knowledge of the testing facilities, the control program should not know any structural characteristics, and the two programs should have appropriate interfaces that allow definition of the relationships between structural characteristics and facility control through user-supplied information. The PNSE’s separation of the command generation and facility control functions make it an extremely suitable platform for the development of SubPSD procedures, provided that the FEA program has the capability of Internet access. To enable Internet access without affecting the structural analysis function of FEA programs, an incorporating method was proposed (shown in Figure 8). The FEA–CGM program was divided into two parts: the CGM-shell and the FEALIB. The FEALIB is a library version (*.lib) of the original FEA program. Only limited modification of the original FEA code is made so that it can be compiled into a library object for the CGM-shell program to call. Main modifications on general finite element methods (FEMs) are listed in Table IV. All works relating to network communication are handled by the CGM-shell and the structural analysis is done exclusively by Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

INTERNET-BASED SIMULATION FOR EARTHQUAKE ENGINEERING

2319

Figure 7. Typical windows shown on the Internet.

NSEP communication

PNSE Server

FEA-CGM CGMshell

restoring force

FEALIB displ.

Figure 8. The architecture of the FEA-incorporated CGM.

the FEALIB. Maximum extensibility can be achieved since the functions of structural analysis and networked communication are completely separated, and can therefore evolve independently. In this study an FEA program, named Platform for Inelastic Structural Analysis for 3D Systems (PISA3D) [18], was adopted for incorporation into the PNSE using the method described above. The integration schemes supported by PISA3D are the Newmark average acceleration method and Operator-splitting (OS) method [19]. The details of the implementation of the implicit average acceleration method in PSD testing where the iteration is not accepted can be found in [20]. Both the CGM-shell and the PISA3D are coded in object-oriented C + + languages. Figure 9 shows the strategy pattern [21], illustrated in Unified Modeling Language (UML) [22], which is used to implement the interfaces between the CGM-shell and PISA3D. Through polymorphism, PISA3D or any other ‘AnaEngine’-inherited FEA programs can be utilized smoothly. For those FEA programs that are coded in traditional procedure-oriented style, incorporation can still be achieved through a number of function calls encapsulated in newly inherited classes. Separating the functions of network communication and structural analysis makes it possible to incorporate any legacy FEA programs with the PNSE. Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

2320

K.-J. WANG ET AL.

Table IV. Main modifications on the FEM to be incorporated in the PNSE. Item Original

1

2

main{ }

Read input from file Do analysis

Calculate next step command Update all element responses

Modified

performAnalysis{ Read input from file Do analysis }

Calculate next step command Notify CGM-shell to get next command Wait and get experimental nodal force Update all element responses

Remarks

Rename the function name such that it can be compiled into a library file. The function ‘performAnalysis’ will be called by the CGM-shell

Two new functions need to be added: 1. Notify the CGM-shell to get the newly calculated displacement after the calculation is done 2. Wait and get the restoring force received from the CGM-shell

CGMShell

AnaEngine +getDisp() +setForce()

FullAnaEngine

PISA3D

+getDisp()

+getDisp()

+setForce()

+setForce()

Figure 9. The strategy pattern used to incorporate legacy FEA programs.

To verify the capability of the PNSE to incorporate PISA3D, a series of networked SubPSD tests were performed on a full-scale two-storey BRBF specimen subjected to bi-directional earthquake excitation using the PNSE [23]. The analytical model of PISA3D is composed of a perimeter moment resisting frame and two identical BRBFs. Only one BRBF specimen was actually built and tested while all the other elements in the model were analysed by a PISA3D-based CGM. All the network communication in this series of tests was implemented using WinSock. Figure 10 shows the model and a photograph of the specimen. Typical test results as shown in Figure 11 prove that PISA3D can be successfully incorporated into the PNSE. All test results can be seen on the website [24].

COMPARISONS WITH THE DB APPROACH The goal of networked collaborative structural testing can also be conveniently achieved through the DB approach, as detailed in a companion paper [9]. Comparisons between the current platforms Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

INTERNET-BASED SIMULATION FOR EARTHQUAKE ENGINEERING

2321

Lateral Disp.(mm)

Figure 10. The analytical model of PISA3D and the appearance of the specimen.

120

Y-dir. 2F

EXP. PISA3D

60 0 -60 -120

CHY024EW(2/50) 0.67g

SPDT No.3 0

10

20

30

40

50

Time(sec)

Figure 11. The second storey in-plane (y-direction) displacement time history.

developed by the DB and AP approaches are given in Table V. Before further research results become available, the authors suggest using the DB approach if the relatively higher cost of initial development for the AP approach is not affordable and if the somewhat limited functionalities and poorer working efficiency for the DB approach is acceptable. Otherwise, the AP approach is recommended since it provides features that are more comprehensive, better functionalities, as well as a satisfactory working efficiency, which is needed in modern networked collaborative structural experiments.

CONCLUSIONS The PNSE was developed to facilitate the AP approach under the ISEE project. The PNSE utilizes the TCP/IP protocol suite to establish a multi-client system that links a CGM and a number of FCMs that are geographically scattered via the Internet to achieve the goal of networked collaborative structural testing. Communication between the PNSE server and clients are performed by transmitting TCP data packets defined in the proposed AP, NSEP. General experimental information, significant laboratory events, signals, and the obligated behaviours of all PNSE participants, are defined in the NSEP. The AN behaviour stipulated by the NSEP makes the PNSE a truly cooperative, event-driven, and event-reflective platform. Transnational test results of a series of two-site networked PSD tests on two DSCFT piers confirmed that data can be accurately transmitted over heterogeneous computer systems/environments. The overall data transmission efficiency is remarkable, as less than 0.1701 s was needed for two data packets to travel back and forth Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

2322

K.-J. WANG ET AL.

Table V. Comparisons between the current platforms developed by the DB and AP approaches.

Initial development/subsequent maintenance Supported OS Supported FEM Transmitted content

Information transmitted during tests Method to acquire information Event-reflective Truly cooperative Event-driven Data transmission efficiency Communication between the server and the clients Resuming ability Flexibility to support versatile test configurations Extensibility to support new laboratory events Programs that need creation or modification to support new clients

DB approach

AP approach

Easier Microsoft PISA3D, OpenSees [25] Freely defined by the users provided that the contents are able to be represented by floating point numbers Signals∗

More difficult Microsoft, FreeBSD PISA3D Clearly defined in NSEP with different contents represented by different primitive data types [8] Signals∗ , running state, human conversation Active notification Yes Yes Yes High More complex High High High The new client and the server

Polling mechanism No Yes No Acceptable Simpler Low High Low The new client

∗ Signals in DB approach are all ‘critical’ ones, while in AP approach they are classified as ‘critical’ or ‘open’

ones.

between NCREE in Taiwan, and Stanford University in the United States. Another series of networked PSD tests were conducted on a full-scale CFT/BRB composite frame using the PNSE to verify that the PNSE was environment independent and had the capability of event reflection. The PNSE also proved to have the ability to easily incorporate PISA3D, as verified by the SubPSD tests conducted upon the BRBF specimen. It can be concluded that the proposed PNSE can successfully and efficiently achieve the goal of networked collaborative structural experiments.

ACKNOWLEDGEMENTS

Financial support by National Science Council (NSC91-2711-3-319-200) is acknowledged. The authors would also like to express their gratefulness towards the laboratory support provided by NCREE and NTU. Special thanks are also due to Mr Bo-Zhou Lin and Miss Kate Chang for their great efforts on PISA3D support and in reviewing this paper.

REFERENCES 1. Sugiura K, Nagata N, Suzuka Y, Watanabe E. Internet related structural testing. Proceedings of the Eighth KKNN Seminar on Civil Engineering, Singapore, 1998; 219–224. 2. Yun CB, Lee IW, Part DU, Watanabe E. Remote parallel pseudo-dynamic testing on base-isolated bridge using Internet. Proceedings of the 13th KKNN Symposium on Civil Engineering, Taipei, Taiwan, 2000; 87–89. 3. Watanabe E, Yun CB, Sugiura K, Park DU, Nagata K. On-line interactive testing between KAIST and Kyoto University. Proceedings of the 14th KKNN Symposium on Civil Engineering, Kyoto, Japan, 2001; 369–374. Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe

INTERNET-BASED SIMULATION FOR EARTHQUAKE ENGINEERING

2323

4. Pan P, Tada M, Nakashima M. Online hybrid test by Internet linkage of distributed test-analysis domains. Earthquake Engineering and Structural Dynamics 2005; 34:1407–1425. DOI: 10.1002/eqe.494 5. Spencer BF, Elnashai A, Nakata N, Saliem H, Yang G, Futrelle J, Glick W, Marcusiu D, Ricker K, Finholt T, Horn D, Hubbard P, Keahey K, Liming L, Zaluzec, Pearlman L, Stauffer E. The MOST experiment: earthquake engineering on the grid. Technical Report NEESgrid-2004-41, NEES Program, National Science Foundation, U.S.A., 2004. 6. Takahashi Y, Fenves G. Software framework for distributed experimental–computational simulation of structural systems. Earthquake Engineering and Structural Dynamics 2006; 35:267–291. DOI: 10.1002/eqe.518 7. Pan P, Tomofuji H, Wang T, Nakashima M, Ohsaki M, Mosalam KM. Development of peer-to-peer (P2P) internet online hybrid test system. Earthquake Engineering and Structural Dynamics 2006; 35:867–890. DOI: 10.1002/eqe.561 8. Tsai KC, Hsieh SH, Yang YS, Wang KJ, Wang SJ, Yeh CC, Cheng WC, Hsu CW, Huang SK. Network platform for structural experiment and analysis (I). Report NCREE-03-21, National Center for Research on Earthquake Engineering, 2003. 9. Yang YS, Hsieh SH, Tsai KC, Wang SJ, Wang KJ, Cheng WC, Hsu CW. ISEE: Internet-based simulation for earthquake engineering, Part I: database approach. Earthquake Engineering and Structural Dynamics, in this issue. 10. Postel J. Transmission Control Protocol DARPA Internet Program Protocol Specification. RFC-793, DARPA, Information Sciences Institute, University of Southern California, 1981. 11. Postel J. Internet Protocol DARPA Internet Program Protocol Specification. RFC-791, DARPA, Information Sciences Institute, University of Southern California, 1981. 12. Kurose James F, Ross Keith W. Computer Networking A Top-Down Approach Featuring the Internet (3rd edn). Addison Wesley: Reading, MA, 2005; 239–246. 13. Tsai KC, Yeh CC. Networked substructure pseudo-dynamic tests of double-skinned CFT bridge piers under bi-directional earthquakes (1). Technical Report NCREE-03-021, National Center for Research on Earthquake Engineering, Taipei, Taiwan, 2003 (in Chinese). 14. Lin ML, Weng YT, Tsai KC, Hsiao PC, Chen CH, Lai JW. Pseudo-Dynamic test of a full-scale CFT/BRB frame: Part 3—analysis and performance evaluation. Thirteenth World Conference on Earthquake Engineering, Vancouver, BC, Cananda, 2004. 15. Tsai KC, Wang KJ, Chen CH, Weng YT, Lin ML, Lai JW, Hsiao PC, Tsai CY. Seismic experiments on large scale frame structures. First International Conference on Advances in Experimental Structural Engineering (AESE 2005), Nagoya, Japan, 2005. 16. The official FreeBSD website. http://www.freebsd.org/ (11 June 2007). 17. Pseudo Dynamic Test of a 2D Full-Scale 3-Story 3-Bay CFT Buckling Restrained Braced Frame web page. http://cft-brbf.ncree.org.tw/fs.html (8 January 2007). 18. Lin BZ, Hsu FW, Chuang MC, Wang KJ, Tsai KC. Development of an object-oriented platform and graphical user interface for nonlinear structural analysis. Eighth U.S. National Conference on Earthquake Engineering (8NCEE), San Francisco, CA, U.S.A., 2006. 19. Nakashima M, Kaminosono T, Ishida M, Ando K. Integration techniques for substructure pseudo dynamic test. 4th US National Conference on Earthquake Engineering, Palm Springs, CA, 1990; 515–524. 20. Prakash V, Powell GH. Filippou FC. DRAIN-2DX: base program guide. Report No. UCB/SEMM-92/29, University of California, Berkeley, CA, 1992. 21. Gamma E, Helm R, Johnson R, Vissides J. Design Patterns: Elements of Reusable Object-Oriented Software (1st edn). Addison-Wesley: Reading, MA, 1995; 315–324. 22. Booch G, Rumbaugh J, Jacobson I. The Unified Modeling Language User Guide. Addison-Wesley: Reading, MA, 1999. 23. Tsai KC, Weng YT, Wang KJ, Tsai CY, Lai JW, Lin JL. Bi-directional sub-structural pseudo-dynamic testing of a full-scale 2-story BRBF, Part 1: seismic design, analytical, and experimental performance assessments. Eighth U.S. National Conference on Earthquake Engineering (8NCEE), San Francisco, CA, U.S.A., 2006. 24. Substructural Pseudo Dynamic Tests of a 2-story Buckling Restrained Braced Frame Subjected to Bi-directional Earthquake Loads web page. http://substructure-brbf.ncree.org/ (8 January 2007). 25. McKenna F. Object oriented finite element analysis: frameworks for analysis algorithms and parallel computing. Ph.D. Thesis, University of California, Berkeley, 1996.

Copyright q

2007 John Wiley & Sons, Ltd.

Earthquake Engng Struct. Dyn. 2007; 36:2307–2323 DOI: 10.1002/eqe