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:
Besides the intrinsic characteristics of structural experiments, features listed below should also be included as the platform is built based upon the Internet.
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).
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:
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/