Experimental Method

Networked Pseudo Dynamic Tests by PNSE

A series of networked pseudo dynamic tests are performed upon the CFT/BRBF by employing the "Platform for Networked Structural Experiments"(PNSE) developed in National Center for Research on Earthquake Engineering (NCREE), Taiwan.
NCREE had launched a project, "Internet-based Simulations on Earthquake Engineering"(ISEE), to develop techniques to link a number of structural laboratories around the world by the Internet to conduct a single structural experiment in a collaborative manner. Two approaches under the ISEE project: the "Database Approach" and the "Application Protocol Approach", provide different solutions to the destination of the ISEE project. In 2002, a series of networked pseudo dynamic tests had been successfully conducted for a full-scale RCS frame by using the platform proposed by the Database Approach. This year, 2003, the CFT/BRBF will be tested by using the PNSE, the solution proposed by the Application Protocol Approach. This page gives a short description of PNSE. More details and information can be found at the website dedicated for the PNSE: http://pnse.ncree.gov.tw/pnse/

Goals

In recent years, structural laboratories are facing more and more challenges on testing upon larger and/or more complex specimen. Unfortunately, it is always difficult or even impossible for laboratories to increase their facility capacity fast enough to meet the demands. A solution for this situation is to link all the resources in laboratories around the world together by the Internet to collaboratively conduct a single structural experiment. This idea of cooperation between structural laboratories implies appropriate division of a huge-size specimen into a number of parts that will be constructed and tested in different laboratories. Conceptually, a real structural laboratory will become a part of the "virtual laboratory" shown in the following figure.



In addition, cooperation itself always brings benefits to all participators. One of the goals of the ISEE project is to construct a platform that promotes contributions of intelligences from researchers all over the world by viewing and discussing about the test results instantly in the course of the networked collaborative experiment or after it is finished. By drawing available testing facilities and intelligent minds from all over the world, simulations and experiments upon complex/huge-size structural model/specimen for advanced knowledge of structures will not be just a dream.

Platform for Networked Structural Experiments

Requirements

Undoubtedly, any platform promising networked collaborative structural experiments must provides components of a traditional structural laboratory:

  1. A module for command generation. This can be a numerical integration algorithm in a pseudo dynamic testing, an input module that queues predefined command profile, or simply an interface that allows user to enter command dynamically.
  2. Modules for facility control, data acquisition. These modules generally are built by different programming languages, running on different operating systems, to control different hardware controllers.
  3. Modules for real time display on test results. These modules are usually but not always a part of the facility control modules.
  4. Modules for data storage and management. Experimental data can be stored in various media such as a file on PC, CDs, MOs, or directly in databases.
  5. Staffs including test operator and investigators.
  6. Human communication.

Besides the intrinsic characteristics of structural experiments, features listed below should also be included as the platform is built based upon the Internet.

  1. Environment independent. The platform aims to link laboratories around the globe to collaboratively conduct experiments. However, all laboratory control facilities are diversely controlled by different controllers, which in turn are controlled by programs built by different programming languages, which finally, run on different operating systems. It is evident that the platform should be accessible regardless the heterogeneous environment.
  2. Event reflective. Conceptually, the platform is a "virtual laboratory," which makes each real laboratory part of itself. The feature of event reflective is naturally demanded by the characteristic of linking laboratories by Internet. That is, all significant events that can occur in any real laboratory should be promptly "seen" by all other participating entities. It is even important while the occurring event highly influences the progress of the test such as a sudden hydraulic power shut off or severe specimen damage in a specific laboratory.
  3. Efficient data transmission. Compared with traditional structural experiments, inevitably more time is consumed on the platform for networked experiments since the data are transmitted over the Internet. However, this amount of additional transmission time should be reasonably small or otherwise it will be an impractical system. Meanwhile, efficient data transmission is also required to ensure a highly responsive system.
  4. Security. In the case of networked structural experiments, all the command and structural responses are transmitted over the Internet. This intrinsic characteristic inevitably introduces risks of malicious attack. Obviously, a mechanism must exist to guard the safety of the networked experiments.
  5. Friendly individual participation. Although the participation of some participants such as registered researchers or interested individuals is not a prerequisite to a networked experiment, they should have appropriate privileges to take part in since they still can contribute by instant data reviewing and discussion while the test is in progress or after it is finished. This feature promotes the usage and share of the experimental data, as well as makes most out of the testing resources.

Brief Introduction on TCP/IP

The Transmission Control Protocol / Internet Protocol (TCP/IP) suite was designed as an open standard to meet the demand of data transmission on rigorous network conditions. TCP guarantees reliable data transmission and IP provides addressing, routing, fragmentation and reassembly for data packets. TCP/IP stack thus handles all those tedious works for data transport between hosts on heterogeneous networks. The characteristic of open standard and the fact of support from almost all currently available operating systems make TCP/IP the foundation of the today's Internet. With TCP/IP, any two hosts on line can communicate to each other without difficulty provided they have the same application protocol, which is a set of predefined rules describing the information, and sending and receiving behaviors of the application.

There are two types of connections under the TCP/IP suite: the TCP connection and the UDP connection. The UDP provides connectionless services. It sends data in the form of datagram which includes the IP address of the destination in each data packet without establishing a virtual circuit. The UDP connection reserves the packet boundary but does not guarantee data delivery and the arriving sequence.

Although it is still practical to employ the UDP connection, the PNSE is implemented by using the TCP connection for its simplicity and reliability. The TCP connection provides a connection-oriented services since a virtual circuit is established between two hosts and the connection exists until any side of a connection explicitly terminates it. The TCP connection does not reserve the data packet boundary but it provides reliable data transport by automatically acknowledging data receipt, retransmitting data if an acknowledgment is not received, preserving data sequence, and avoiding duplication of data.

Architecture of PNSE

To meet the requirements listed above, the platform PNSE is proposed and illustrated in the following figure. The PNSE concentrates on core works directly related to the progression of networked collaborative experiments and excludes functionalities of data storage, management, monitoring, and video display, which can be implemented by utilizing commercially available software such as the Microsoft SQL server and the RealPlayer. Three types of modules in the PNSE, the PNSE server, Command Generation Module (CGM), and the Facility Control Modules (FCM) are connected by employing socket operations to utilize the TCP/IP suite to ensure high interoperability between heterogeneous network and working environments.

The PNSE is a multi-client system with two kinds of clients, the CGM and the FCMs, connecting to the server with a TCP connection. For any client, all messages and data must be sent to and received from the server to simplify the network topology and hence the communication flow. Communication between the server and clients is full-duplex transmission which means that at the same time either side of a connection can actively send and passively receive information to and from the other side and thus to realize the goal of an event reflective platform. The communication follows the rules depicted in a proposed application protocol, the "Networked Structural Experiment Protocol" (NSEP).

  1. The PNSE server

    The server serves as an information and data center. It is the center of the PNSE star topology. All clients must send information to the server for dispatch. The server also manipulates information that relates to the whole project since it is the one who owns all the information. For the concern of safety, the server also manipulates a simple login process for any connection attempt.
     
  2. The CGM

    The CGM calculates or prepares the command to be imposed on the specimen. Depending on situations, the command can be generated by a numerical integration algorithm in pseudo dynamic testing, an input module that queues predefined command profile in quasi-static testing, or simply an remote control application with an user interface that allows its user to enter command dynamically. Any existing finite element analysis program can be modified to be compatible with the PNSE. All it needs to be modified is to send the calculated displacement command to the PNSE server and wait for the restoring force response from the Internet, instead of directly recover it from a mathematical model by itself. In the case of quasi-static testing or remote control, the server does not send any restoring force responses but it still notifies the CGM the completion of the command execution so that the CGM can continue to send command for the next step.
     
  3. The FCM

    The FCM receives the command from the server and controls the actuators to impose the command on the specimen. It then measures or calculates the critical response and send it back to the server. The FCM on PNSE is quite the same as the traditional facility control program in a structural laboratory. One difference is that the FCM on PNSE executes the command received from the PNSE server, instead of one generated by itself. Another difference is that it is obligated to send notification to the server when the command execution is done. It still controls the actuator motion, performs the data acquisition, alters the test running state if necessary, and displays the real time test results to its operator in exactly the same manner as in a traditional facility control program.
     
  4. Signals

    Signals on the PNSE are referred to those values that change continuously with respect to time and are divided into two categories:

    1. Critical signals. Critical signals are referred to those signals that are crucial to the generation of the command such as the restoring force responses in a pseudo dynamic testing.
    2. Open signals. Opens signals are referred to those signals that are not crucial to the generation of the command but indicate important structural behaviors and can be displayed on the Internet.

     
  5. The command cycle

    A command cycle is a conceptual cycle encompassing those actions to be executed from the generation of command of this step to (but does not include) the generation of command of next step. The PNSE proceeds the collaborative experiments by repeatedly executing tasks enclosed in a command cycle.
     
  6. Human communication

    On PNSE, human communication is still necessary but not as easily implemented as in a traditional structural experiment since all the staffs and operators of PNSE client programs are in different locations around the world. To address this issue, a feature of instant discussion is included in the PNSE. This feature provides convenient conversation channel for human communication and is a necessity since it is almost impossible to define all events possible that can occur in the course of the test in the application protocol.

Networked Structural Experiment Protocol

The TCP/IP suite provides reliable data transmission without knowing the actual content of the data. It is only responsible for delivery of a stream of bytes over the networks. In stead, the content of the transmitted data should be understood by both sides of a connection and hence applications must have an application protocol, a protocol defined at the application level based on which they can communicate.

For server and all clients to communicate on the PNSE, an application protocol, the "Networked Structural Experiment Protocol" (NSEP), is defined as the common language. Relevant information and significant events, as well as communication rules are explicitly defined in NSEP.

The PNSE server and client notify the peer on the other end of the connection that something has happened by sending appropriate NSEP data packets. The NSEP data packets are composed of parameters of some defined primitive data types. These primitive data types are defined for use in NSEP and are not necessarily the same with those primitive data types in any programming language. The following table summarizes these primitive data types used to compose the NSEP data packets.

TYPE Description
CHAR 8 bits character. It can hold values not only for ASCII characters but also small integers.
SHORT 16 bits integer.
USHORT 16 bits unsigned integer.
INT 32 bits integer.
UINT 32 bits unsigned integer.
FLOAT 32 bits floating point number.
DOUBLE 64 bits floating point number.
STRING Variant length. It is usually used to hold human readable texts. An object of type STRING is actually a stream of bytes (usually readable ASCII characters) terminating with a zero at the end of the STRING object. The length of the STRING object is the number of the bytes, including the terminating zero. For example, a STRING object with value "HELLO" is composed of 5 characters and 1 one-byte integer ('H', 'E', 'L', 'L', 'O' and 0). The length is of this STRING object is 6.

The data packet transmitted on PNSE can be expressed as follows.

LENGTH + TYPE + PARAMLIST

LENGTH is a parameter of primitive data type USHORT denoting the total length of the whole packet. The PNSE employs the TCP connection which preserves data arriving sequence but not the packet boundary. Actually what is transmitted over the network is a stream of bytes and a data packet is simply only a concept. Hence, each data packet should contain explicit information on the total length of itself so that the receiving end of a connection can correctly receive it.

TYPE is a parameter of primitive type CHAR denoting what kind of data or information this packet contains. Currently defined TYPEs are detailed in the following table.

Anonym Value Short description
SD_ERROR 0 SD_ERROR packet is used to make a reply to clients when some errors occurred in the previous communication.
SD_QUERY 1 Reserved data packet.
SD_LOGIN 2 SD_LOGIN packet contains information (client name and password) for login procedure.
SD_PRJINFO 3 SD_PRJINFO packet contains information of the project, such as the number of the clients, names of clients, total duration or number of time steps of this project.
SD_SIGNALINFO 4 SD_SIGNALINFO packet contains information (names and units) of the open signals to be publicized on the Internet.
SD_PRJSTATE 5 SD_PRJSTATE packet contains the current running state of the whole project as well as the running states of all clients.
SD_CLNSTATE 6 SD_CLNSTATE packet contains the client's current running state.
SD_CPSCMD 7 SD_CPSCMD is a packet holding composite command generated by the CGM. It is always sent to the PNSE server by the CGM and it is the server's responsibility to dispatch SD_IDVCMD parsed from SD_CPSCMD to all FCMs.
SD_IDVCMD 8 SD_IDVCMD is a packet holding individual command for each FCM. It is always sent by the PNSE server to each FCM after it receives an SD_CPSCMD from the CGM. Typically each FCM gets different SD_IDVCMD in a command cycle.
SD_CPSRSP 9 SD_CPSRSP is a packet holding composite critical responses compiled from all SD_IDVRSP received from all FCMs. It is always sent by the PNSE server to the CGM.
SD_IDVRSP 10 SD_IDVRSP is a packet holding individual critical response after a FCM finishes executing the SD_IDVCMD previously received from the PNSE server.
SD_SIGNAL 11 SD_SIGNAL packet contains an array of FLOAT values holding the open signals corresponding to this command cycle. The SD_SIGNAL is always sent by the client to the server for data publication and storage on the Internet.
SD_DISCUSS 12 SD_DISCUSS packet contains human readable texts for human conversation. It also contains the ID of the receiver.

PARAMLIST is an optional list of parameters to make this data packet complete and meaningful. The number, primitive type and actual content of those parameters depend on each NSEP TYPE.

NSEP stipulates that both the PNSE server and clients should take the responsibility of making active notification to all other participants if it owns the information relevant to the progress of the collaborative experiment. For example, if a facility control module needs to hold the experiment for any reason, it should notify the PNSE server of this holding action before or immediately right after it really does it. When the server receives this notification of change of a client's running state, it has the responsibility to notify all other clients. NSEP stipulates this active notification to simplify the communication over the Internet and to enhance the communication efficiency since otherwise an information query mechanism may be needed to make the platform event-reflective. Although it is still feasible, an information query mechanism generally decreases the overall efficiency since typically the query actions need to be performed frequently enough so that significant events can be reflected promptly enough. However, frequent query waists a lot of time and network resources, especially when the information queried has not been updated at the moment of query. That's the reason why NSEP discards the information query mechanism and stipulates the active notification mechanism.

The concept of "event-driven" is the modern philosophy of programming and is powerful when the sequence of computational works can't be determined by the programmer in the coding stage of the program. This is exactly the case of collaborative experiment and hence the NSEP is developed under the concept of event-driven. In other words, there does not exist a "processing center/module" which controls the sequence of works. The PNSE server does not mandate any client to do particular tasks to proceed the test. The progression of the test is led by continual actions responding to events triggered by all clients. That is, for PNSE clients, NSEP conceptually stipulates for:

  1. Data packets that hold information. Sending a data packet is actually triggering an event.
  2. Timing to send a particular data packet.
  3. Behaviors that need to be done before sending a data packet. (Or equivalently, behaviors that need to be performed after receiving a data packet.)

The concept of event-driven actually constructs the PNSE a true cooperating platform since the server and all the clients take part of the responsibility of the test progression.

More details and information about PNSE and NSEP can be found at the website for PNSE: http://pnse.ncree.gov.tw/pnse/