Difference between revisions of "WCPS: Wireless Cyber-Physical Simulator"

From Cyber-Physical Systems Laboratory
Jump to navigationJump to search
Line 5: Line 5:
 
* '''[Software Update]''' WCPS v2.0 is released [http://research.engineering.wustl.edu/~boli/downloads/WCPS%202.0.zip here].
 
* '''[Software Update]''' WCPS v2.0 is released [http://research.engineering.wustl.edu/~boli/downloads/WCPS%202.0.zip here].
  
−
* '''[News]''' [https://nees.org/resources/12787 - Benchmark Wireless Structural Control Problem Released], July 29, 2014.
+
* '''[News]''' [https://nees.org/resources/12787 Benchmark Wireless Structural Control Problem Released], July 29, 2014.
  
 
* '''[News]''' [http://spectrum.ieee.org/podcast/at-work/test-and-measurement/smart-bridges Smart Bridges - Interview and Podcast on Cyber-Physical Systems for Resilient Bridges], August 07, 2013.
 
* '''[News]''' [http://spectrum.ieee.org/podcast/at-work/test-and-measurement/smart-bridges Smart Bridges - Interview and Podcast on Cyber-Physical Systems for Resilient Bridges], August 07, 2013.

Revision as of 20:26, 26 May 2015

Wireless Cyber-Physical Simulator (WCPS) is an open-source simulation environment for wireless control systems. By integrating Simulink and the TOSSIM wireless sensor simulator in a holistic simulation environment, WCPS accurately captures the dynamics of both the physical systems and the wireless sensor-actuator networks used for control. WCPS has been used for realistic case studies of wireless structural control systems for civil infrastructure. The broad application of WCPS is to support cyber-physical systems research on large-scale wireless control systems through high-fidelity joint cyber and physical simulations. This site includes the code release, tutorial, and simulation examples for wireless structural control systems. WCPS is developed as part of the cyber-physical systems project on wireless structural health monitoring and control systems, a collaborative effort by Washington University, Purdue and UIUC.

What's New

  • [Software Update] WCPS v2.0 is released here.

WCPS Architecture

Figure 1. WCPS Architecture

As shown in the right figure, WCPS simulates the feedback control loop of the control system as follows. Sensor data is generated from structural models. Through a cross-platform function call from Simulink, sensor data is injected to the corresponding wireless sensors in TOSSIM. Following the routes and transmission schedule calculated by the network manager module, TOSSIM simulates the end-to-end wireless communication of the sensor data packets from the sensors to the base station, and then return the packet delay and loss to the Interfacing Block in Simulink through the Python interface. The Packet Collector module then extracts packet delivery information(the delay and loss)from the message pool. Sensor data and their loss and delay are then provided to the Data Block, which then feed the sensor data to the controller at the right time based on the packet delay (if the packet is not lost). WCPS utilizes basic API (e.g., the dos, UNIX command) of MATLAB to do cross-platform function calls. In TOSSIM, we re-implement a printf method in TinyOS to send simulation results to the Interfacing Block.

User inputs to WCPS includes excitation signals to the structure (e.g., acceleration caused by earthquakes) and wireless traces used as input to TOSSIM. Excitation signal of the structure is provided to the structure models in the format of MAT files. The scheduler module calculates transmission schedules. Networking schedule is then deployed into the MAC layer code of wireless nodes and becomes effective after a TinyOS compilation. The TDMA MAC layer in WCPS is developed based on the MAC Layer Architecture (MLA) library and further adapted for TOSSIM under TinyOS 2.1.1. Received Signal Strength Indication( RSSI) and wireless noises traces are collected from real-world environments and provided to the wireless model used by TOSSIM for realistic wireless network simulations. The interfaces between the Simulink model and TOSSIM are encapsulated as two MATLAB embedded functions in Simulink: the Interfacing Block and the Data Block. The Interfacing Block extracts delay and loss information from TOSSIM messages, and the Data Block decides what data will be used for discrete control during each sampling period. The federated architecture of WCPS provides great flexibilities to incorporate different structural models and implement alternative scheduling-control approaches.

WCPS Capabilities

This section briefly reviews application of WCPS in extensive Wireless Structural Control studies, which shows capability of WCPS enabling in-depth tradeoff among sensing synchronization, wireless network delays, as well as reliability of the wireless network. Specifically for the wireless network presented in this section, wireless traces in TOSSIM were collected from a 5-sensor testbed located at Bryan Hall of Washington University, as in Fig. 2. All results presented here uses the TDMA MAC layer.

Figure. 2. Wireless Network in A Building
Figure. 3. Network Statistics

Fig. 3 shows end-to-end network ratio changes with different re-transmission mechanisms in WCPS. Sensor 1 has the lowest delivery ratio because it has a 2-hop route to the base station. Since OTDC-1 does not perform any retransmission, while OTDC-2 and OTDC-3 performs retransmit each packet once and twice, respectively. Under OTDC-1 Sensors 1 and 4 have delivery ratios of 70% and over 95%, respectively. As expected more retransmissions improve the deliver ratios of all sensors at the cost of longer delays as described earlier.

Figure 4. Tradeoff Among Data Synchronization, Network Reliability and Network Delay.

Fig. 4 shows changes of required resource for building control. Underlying tradeoffs are: better sensing synchronization vs. larger delays (e.g., OTDC-1 vs. SC), and larger network delays trading for better reliability (e.g., OTDC-3, OTDC-2 vs. OTDC-1). In Fig.4(a), OTDC-k approaches consistently require less control power than SC. As k increases, OTDC-k requires slightly less control power. Similarly, as shown in Fig. 2(b), OTDC-1 reduces control force by 80% when compared to SC. The differences in control force among different OTDC-k approaches are negligible. The results that OTDC-1 outperforms SC in both metrics indicate resource requirements are more sensitive to data synchronization than to sensing delays in this building control system. OTDC-k with larger k results in negligible reduction of control power and force, indicating resource requirements are not sensitive to network reliability in this case study.

Fig. 5 shows control performance regarding structural response. In term of peak inter-story drift in Fig. 5(a), OTDC- k achieves more reduction in inter-story drift than SC. Interestingly, higher k in OTDC-k increases peak inter-story drift. Recall a higher k leads to higher communication reliability but longer sensing delay. Inter-story drift is thus more sensitive to sensing delays than to data loss in this case study. Similarly, as shown in Fig. 5(b), OTDC-3 causes worse peak acceleration than all the other approaches. Hence, building structural responses are more sensitive to sensing delays than to data loss. In addition, OTDC-1 only slightly outperforms SC, which indicates limited impact of data synchronization on structural response.

Figure 5. Tradeoff Among Data Synchronization, Network Reliability and Network Delay.

WCPS has efficiently integrated TOSSIM and Simulink. Fig. 2-4 shows that there exist complex tradeoffs among data synchronization, sensing delay, and network reliability under realistic wireless structural control settings. A realistic, integrated wireless control simulator like WCPS is critical in exploring these design tradeoffs in wireless control design. Our cyber-physical simulation methodology and scheduling-control co-design approaches presented here not only represent a promising step toward smart civil infrastructure, but also provide useful insights and tools that can be generalized to other cyber-physical systems employing wireless control.

Environment Installation

  • Install TinyOS
 WCPS is implemented and tested on MacOS X (snowleopard), Windows XP, and Windows 7. Current release of WCPS is under  TinyOS 2.1.1, which can be installed following the two methods.
  • Install Mac Layer Architecture(MLA)
The MAC Layer Architecture (MLA) provides a component-based architecture for MAC protocols in wireless sensor networks. MLA extends the Unified Power 
Management Architecture to provide the hardware-independent interfaces required by timing sensitive MAC protocols, and defines platform-independent 
reusable components that implement MAC layer logic on top of them. The MLA architecture can be used to develop a large number of platform-independent 
MAC implementations, with little or no further effort required to adapt these implementations to new hardware platforms. Our current implementation of MLA
is built on top of TinyOS 2.1.1. It currently supports platforms which use the CC2420 radio stack and has been tested on TelosB motes. In addition to providing
interfaces and components for building new MAC layer implementations, MLA includes implementations of five representative MAC layers. Specifically for WCPS, we 
adopt and further change the pure-TDMA MAC protocol for centralized data communication.
  • Install MATLAB and Simulink
  • If you already have MATLAB MATLAB 7.11.0.584 (2010b) or later version, skip this step. Otherwise, follow the tutorial here: install MATLAB
  • Install Python

If you already have Python 2.7.2 or later version installed, skip this step. Otherwise, follow the manual here: install Python

Download WCPS

Use WCPS

Wireless network plays a critical role in close-loop wireless control system. Sitting on top of WCPS, simulating a wireless TDMA network is as easy as collecting these NesC files below:

  • "Makefile" takes advantage of the fact that it's not necessary to recompile all the files not changed while specifying all necessary libraries.
  • "TestNetwork.h" defines necessary message structures for the wireless communication.
  • "TestNetworkAppC.nc" connects claimed application interfaces to interfaces that are defined in the hardware library.
  • "TestNetworkC.nc" implements send/receive functionality of a wireless node.
  • "tossim-call.py" configures TOSSIM network and does packet injection into the Tossim network.All above necessary files..
  • Re-implemented TOSSIM libraries for TDMA simulation.TDMA components for TOSSIM..
  • Wireless traces: Traces for 5-sensor wireless network in a building.

Put all the above files into the same folder, prompt a terminal (or a Cygwin window), and in the terminal run 

 Make micaz sim

If TinyOS and python is configured correctly, go ahead and run in the terminal: 

./tossim-call.py

Having collected aforementioned TinyOS files, a simplified example that uses key networking Interfacing Block and Data Block of WCPS is shown in Fig. 6.

Figure 6. A Simple Example that uses Interfacing and Data Block of WCPS.

This examples shows:

  • How input data in Simulink is injected to TOSSIM network;
  • How TOSSIM Interfacing Block runs as a Matlab Embedded function;
  • What type of data is output from the Interfacing Block;
  • How data usage strategies are applied to the data in the Data Block.
  • What type of data is eventually output from the Data Block and provided for future control use.

Source code for the example can be found here. To run this integrated example, simply download, unzip the source code, and run Run_delay_data_func.m in Matlab.

Talks

Publication

Get Support

  • TinyOS and TOSSIM: Bo Li: boli@seas.wustl.edu
  • Simulink Models: Zhuoxiong Sun: SUN152@purdue.edu
Retrieved from "http://wsn.cse.wustl.edu/index.php?title=WCPS:_Wireless_Cyber-Physical_Simulator&oldid=3448"