7.2.1 PSBD Overview

PSBD views simulation as the driving force for designing and testing engineering systems. It provides a design process that explicitly focuses on systematic transitions from simulation models to system realization. As shown in Figure 7.1, the design process consists of three stages, each of which is characterized by the types of entities (virtual or physical) that are involved. The first stage is conventional simulation (in fast simulation mode), where simulation is carried out using all models. A major task of this stage is to develop the system model based on available knowledge and assumptions about the hardware and operating environment of the physical system. Often discrepancies between simulation models and physical system components exist. These discrepancies cause the models to comprise behavior different from the system behavior. To reveal such design discrepancies, the next stage of the design process is virtual environment simulation (in real-time simulation mode), where simulation-based study is carried out in a virtual testing environment using combined models and physical system components. This stage brings simulation-based study one step closer to a realization by including physical system components into the simulation. The goal is to use physical system components to reveal overlooked design details, and thus help designers improve the control models/algorithms under development. The final stage is physical system experiment, where the physical system is tested in the target operating environment.

Along this design process, the PSBD methodology emphasizes two parallel activities in a progressive manner: replace models with physical system components and update models. As the design moves forward, physical system components are incrementally brought into the simulation to replace models. Simulations with these physical system components allow designers to validate their design assumptions and to reveal new design details. Such information is fed back to the previous stages to update the models if necessary. The updated model will then be used for follow-on design and test. This activity of model update allows designers to maintain a coherent model of the system under development. Thus, at the end of the design, not only the system is realized and tested, but also a system model that faithfully represents the system is developed. This system model can support final system measurement and evaluation (shown by the dashed line in Figure 7.1) and serve other purposes such as system maintenance and future development. It is important to note that each design stage is a dynamically evolving process by itself. For example, during the conventional simulation stage, it is common for designers to start from high level models and then refine them to more detailed models. Similarly, the virtual environment simulation stage that involves combined models and physical system components typically includes multiple phases too, for example, to start with replacing one physical system component first and then gradually add more.

Two important features of the PSBD methodology are model continuity and virtual environment simulation that supports simulation-based test with combined virtual and physical system components. Model continuity refers to the ability to transition as much as possible of a model specification through the stages of a development process [17]. For real-time embedded systems, we restrict model continuity to the models (software components) that implement the real-time control of the system. This means the control models of a real-time embedded system are designed, analyzed, and tested by simulation methods and then smoothly transitioned from simulation to hardware execution in the physical environment (see Hu et al. [4] and Azarnasab [6] for more details). To support model continuity, it is necessary to develop system models and run simulation-based tests in a systematic way. A modular design and well-defined interfaces are necessary to ensure the control models work with physical and simulated hardware in the same way at different stages of the design process [4,6]. The virtual environment simulation provides a virtual testing environment by using combined physical and virtual system components. It bridges the gap between conventional simulations that use all models and physical system experiments that use all physical system components. To support the virtual environment, simulation techniques must be developed that synchronize the physical and virtual system components. This includes allowing the physical and virtual components to “sense” each others’ existence (see Hu and Zeigler [18] for an example of how physical and virtual robots are synchronized with each other). Meanwhile, time synchronization is also important. Since hardware components are included in the simulation-based study, real-time simulations are necessary to support the virtual testing environment.

7.2.2 Bifurcated Design Process for Networked Real-Time Embedded Systems

Networked real-time embedded systems are characterized by a network of embedded devices interacting with each other and the tight couplings between software and hardware of those devices. Each of these devices is referred to as a node in this chapter. When commercial-off-the-shelf (COTS) nodes are not used, design of networked real-time embedded systems must design both the individual nodes and the networked system as a whole. Within this context, the PSBD methodology described above is elaborated to include a bifurcated design process as shown in Figure 7.2. The bifurcated design process explicitly differentiates the design of a single node (the bottom route in Figure 7.2) and the design of the networked system (the top route in Figure 7.2). The former mainly concerns designing the different functional modules, such as sensing, modulation/demodulation, and channel coding, of the embedded device. The latter focuses on how the multiple nodes work together as a whole, including designing and improving the communication protocols and the cooperative strategies among the nodes. Despite the different design focuses, both designs follow the PSBD process that starts from models and gradually adds more physical system components.

In Figure 7.2, the models are shown as white boxes; the physical system components are shown as grey boxes. The design starts and bifurcates into two routes: the design of a single node and the design of the networked system. For designing a single node, the first step is to model the functional modules of the embedded device and simulate how they work together to fulfill the functionality of the device. Then hardware components are brought into the design and HIL simulations are conducted to test how well the designed modules and algorithmic code work with the hardware. This proceeds in a stepwise fashion as more and more hardware components are included. Consider the CR (described later) as an example, first the channel sensing mechanism is implemented on the FPGA and DSP hardware, then the data transmission and data reception components are included, and finally the reporting mechanism is implemented. We use a signal generator and signal analyzer to help to test the developed components before a working node is complete. Eventually, all the code modules are implemented in the hardware and the embedded node is tested with all hardware components.

When designing the networked system, the first step is to develop individual node models and a model of the communicating network. The individual node model can reuse the model from designing the single node (as indicated by the dotted arrow in Figure 7.2). Alternatively, a different node model at a higher abstraction level (e.g., without including all the details of the devices’ functional modules) can be used. Simulations with these models allow designers to test the networked system in the model world. The next step is to gradually include physical device nodes into the simulation-based study to conduct virtual environment simulations. The physical device nodes are either the ones from the single node design or COTS nodes. This continues until the entire system is realized and all designed nodes are tested in a physical network. It is important to note that the bifurcated design process provides a systematic view for designing general networked embedded systems. For a specific application, the design process can be tailored (e.g., some design stages are elaborated while others are omitted) to fit the specific design needs of the application. In Section 7.4, we provide an example of designing a CR system by starting from the design of a single radio modem and then proceeding to the design of a CR network. The single radio modem is also designed in progressive manner, where different functional modules are gradually implemented/tested in the hardware while other modules are provided by simulation models.

PSBD brings several advantages when designing complex networked engineering systems. Some of them are shared by the traditional HIL simulation. For example, it brings simulation-based study one step closer to the reality to provide useful information for designers. It also increases confidence by the designer about how the final system will operate. However, PSBD goes beyond that by emphasizing a systematic design process that gradually adds more physical system components to replace simulation models. The virtual environment simulation provides the flexibility for experimenting with a design in a virtual testing environment. It allows designers to use several, instead of all, physical nodes to carry out a system-wide test of a networked system. This is especially useful for large-scale networked real-time embedded systems whose complexity and scale severely limit experimentations in a physical environment using all physical nodes. As the scale of these systems increases, so does their design and test complexity. It is the intent of PSBD to systematically handle such design complexity in a progressive manner.

7.4.1 Design Procedure and Implementation Environment

The design started from a single cognitive modem and then proceeded to the CR network. As part of the simulation-based testing environment, simulated PUs generated data traffic based on a model of the application layer for realistic PUs on particular frequency channels. Depending on the channel, the traffic model can be a constant bit rate (CBR), a burst data, or a Poisson process. For example, Internet traffic is often modeled as bursts of data transfer, CBR is a good model for TDMA networks such as voice traffic, and Poisson process is a generic model of data arrival. Simulated SUs not only generate data traffic, but also are responsible for handling signaling packets over a control channel of the network.

In the first stage of PSBD, we implemented a single transceiver (transmitter and receiver radio). First, MATLAB^® was used for conventional modeling and simulation of a generic transceiver modem and a generic channel. The goal was to find out the parameters to achieve the required bit error rate (BER) of the radio system. Second, one SDR board and simulation models formed a co-simulation carried out in DEVSJAVA [11]. In this stage, the signal processing and data acquisition components of the transceiver were substituted by physical hardware components (such as DSP and FPGA components) on the board. The remaining components were DEVSJAVA models. To support reuse, the DEVSJAVA models reused the corresponding MATLAB functions in the first stage. The MATLAB Builder^™ for Java can build Java libraries from MATLAB functions and have them ready to use in DEVSJAVA. In our project, the MATLAB m-files developed for MATLAB simulation of the channel, some MATLAB visualization methods, and also the MEX files (that interfaced the SDR board) were compiled to Java methods and used inside the DEVSJAVA simulation. The embedded MATLAB code inside DEVSJAVA helped in generating precise communication-specific models such as traffic and random fading of multipath channel. In this way, we were able to avoid reimplementing and testing mathematical methods and could focus on higher level network modeling in DEVSJAVA. The integration of DEVS and MATLAB models decoupled the design of CR network model from the underlying complicated mathematical functions.

While MATLAB is good at mathematical modeling, it is not straightforward to model the event-driven nature of interconnected components. On the other hand, DEVSJAVA can naturally support network modeling and, thus, was used to model the network of CR nodes. After an initial cognitive modem was implemented (as one SU), the next step was to design the CR network. At first, a complete simulation of a CR network with SUs and PUs was developed in DEVSJAVA. The conventional simulation simulated the activities of channel assignments for SUs and PUs. An SU acting as a Secondary Base (SB) station model received the sensing information from all SUs and compiled channel state information. In our system, we had distributed sensing to avoid the hidden node problem as much as possible. A vector signal generator emulated the traffic of simulated PUs and simulated SUs on the physical channel. In modeling the network, CR nodes were modeled by DEVS atomic models and the network was modeled as a DEVS coupled model. The scheduled messages passing between the DEVS atomic models carried packets with different lengths. Based on the propagation rules, the channel model rescheduled the messages to the receiver. Note that DEVS modeling is homomorphic. This means the CR node could be modeled as a coupled model itself including its functional component models. The hierarchical model construction of DEVS helped in modeling the internal interactions of subsystems of a single cognitive modem and the interactions of multiple cognitive modems in a network. During the course of PSBD, we replaced two of the simulated SUs with physical CRs to carry out a virtual environment test. In the setup of the virtual environment simulation, the physical nodes used filterbanks to detect the presence of the PUs and sent the sensing information to the SB, which was simulated on a PC. In this way, we were able to develop the network and to carry out system-wide test without having to wait for all hardware to become available. Below we describe the two design routes in detail.

7.4.2 Design of a Single Cognitive Modem

Based on the PSBD methodology, a model of a modem was first developed at an abstraction level according to the design goal. This model included all the functional modules of the cognitive modem. First, we started from a conventional simulation of the cognitive modem in a simulated environment. In this example, the environment was defined by the frequencies in use and a channel model. It dynamically changed as a result of PU or SU transmission or channel fading. The model was simulated in Simulink^® to test for the required BER [24].

Figure 7.3 shows the model of the cognitive modem, which includes physical layer and MAC layer modules. The MAC layer module is the core of this model. The cognition algorithm inside the MAC layer module is responsible for compiling the spectral information sensed by the filterbank sensing module to provide a utility function. This utility function is used to determine the channels that should be assigned and the duration for which those channels are valid. The filterbank sensing [7,23] module is applied directly on the channel to detect the power spectral density (PSD) and thus the active PUs. The synchronization module detects the incoming packets while correcting the residual carrier offset before passing data to an equalizer to compensate for the effect of channel on data. The communication channel in the simulation is considered as an additive white Gaussian (AWGN) model. Conventional simulations based on this model allow us to test the cognitive algorithm inside the MAC layer and the functionality of the physical layer.

The conventional simulation, however, is insufficient to design and test the features that are influenced by the implementing hardware. For example, tuning algorithm/ protocol parameters to achieve optimal synchronization results depends on the real-time properties of the hardware that cannot be predetermined without employing the actual hardware. In our design, the MAC layer protocol is decentralized and consisted of three phases. In the sensing phase, all the nodes sense the channel. In the reporting phase, all the nodes communicate their cognition results over a control channel. The cognition algorithm uses these reports to assign channels. In the channel usage phase, all the nodes start using the assigned channels. The purpose of the reporting period is to maximize cognition accuracy by sharing the cognition knowledge of individual SUs. Note that only the transmission time contributes to the effective bandwidth, and therefore, the time spent in reporting and sensing should be minimized. Since sensing takes a constant duration, an important task in designing the cognitive modem is to optimize the MAC layer so that reporting time is minimized [27]. Also we should note that the transmission time cannot last for a very long time, because a PU may return and thus SUs must release the occupied channels to the PUs. The time that SUs are permitted to transmit continuously without sensing is thus determined by a statistical model of PU arrivals in the bands of interest. To better design these features, the next stage is to include physical hardware components into the simulation for virtual environment simulation.

It is challenging to decide to what extent simulation-assisted design should be involved and to what level the system should be decomposed. A single cognitive modem comprises many individual radio modules, each of which is a candidate for virtual environment simulation along with other simulated objects and the environment. Figure 7.4 shows how virtual environment simulation is carried out in designing a single modem. In this figure, one SDR board is used. The simulation runs on a single PC, while the SDR board (running implemented components) is connected to that PC via an Ethernet cable. Since sensing the channel is the most critical part of the CR, we implement this component in the earliest stage as shown in the rightmost section of Figure 7.4. We implement filterbanks sensing in DSP of the board. To test the sensing module, we emulate PU traffic on different frequency bands using a wide-band vector signal generator. The transmitted traffic of PU by the signal generator is a multiband waveform generated using a MATLAB script. In this stage, we adjust some design parameters such as analog-to-digital converter gains, frequency axis margins, and power threshold of PU detection. After sensing is implemented, other components such as modulation/demodulation and channel coding are implemented in the order depicted in the figure.

7.4.3 Design of a CR Network

After the cognitive modem is implemented, we design the CR network using the developed cognitive modem. Similar to the design of a single modem, we start from conventional simulation of the cognitive network using the model of cognitive modem developed in the previous stage. In our design, first we consider a centralized network where some SUs were assigned to act as SB stations. This approach leads to a global common plane architecture for signaling and control to avoid the hidden node problem for PUs. This is essential in any CR network to avoid interfering with existing PUs. SB is in charge of synchronization and channel assignment. It compiles the channel state information based on sensing results of SUs and uses this knowledge to rank different parts of the spectrum and blacklist some active channels. After the role of each CR node is assigned, we model the cognitive network, which includes multiple PU and SU models, a SB model, and a Channel model that simulates the features of the wireless channel. Conventional simulations using this network model allows us to test if the SUs can successfully detect nonused bands and to dynamically use them without interfering with the PUs. A sample simulation result is provided in Section 7.4.4

The next stage is to introduce physical cognitive modems (SUs) in the simulation. The virtual environment simulation includes physical SUs, physical PUs, simulated SUs, simulated PUs, and simulated channels (used only between simulated SUs). Figure 7.5 shows the setup of a virtual environment simulation and the interconnections among simulated, emulated, and physical components. In Figure 7.5, two physical SUs (Lyrtech SFF SDR boards, denoted as Real SU1 and Real SU2) and one physical PU (two-way radio, denoted as Real PU1) are used. The simulated SUs and PUs are emulated using a vector signal generator to generate spectral energy on the bands of the simulated agents. Therefore, the physical SUs would see the channel as if the simulated users exist. To test the cognitive modem against the generic PU channel usage pattern, the traffic of the PU (being simulated) is known and programmed in the PU model. The emulation of the PUs and SUs is necessary to test the sensing mechanism of physical SUs. The simulated SUs use the simulated channel and simulated traffic directly from the simulated PUs. The simulated channel is also used between two simulated SUs when transmitting a packet. A fading channel and different exponential PU traffic (with various mean for each channel) is implemented in MATLAB and compiled to be invoked by DEVSJAVA. Note that the emulator is considered as part of the testing environment and is not included in the system model.

To carry out virtual environment simulation, it is important to set up the environment so the physical and simulated nodes can “sense” each other’s existence. For example, when a physical SU uses a band of the channel, the simulated SUs must know the band has been occupied (by the physical SU). The reverse is true too. Thus, a two-way communication is necessary between the physical SUs and the PC that hosts the simulated SUs. In our system, as shown in Figure 7.5, the emulator conveys the simulated environment and broadcasts the information sensed by the physical SUs. To support the communication from a physical SU to the PC, an Ethernet cable (not shown in Figure 7.5) is used to connect the physical SU with the PC. During the “report” stage of the MAC protocol, a physical SU sends its information to the PC through the Ethernet cable. Note that the Ethernet cable is not necessary in testing the physical system, in which case wireless communication is used. To synchronize the physical and simulated SUs (meaning to allow the physical and simulated SUs to know each other’s existence) in a systematic way, each physical SU has a “shadow model” on the PC. This is similar to the robot-in-the-loop simulation [4–6], where each physical robot has a counterpart robot model in the simulation environment on the PC. The shadow model is responsible for receiving report information from the real SU and then passes that information to the Channel model similar as how other simulated SUs do.

Figure 7.6 shows a DEVS model of a CR network including two PUs, two SUs, and one SB in the virtual environment simulation. One of the SUs (SU2), the two PUs (PU1 and PU2), and also the SB station are simulated on the host PC. The other SU (SU1) has a hardware implementation and thus is executed using the co-simulation engine. The SU1 shown in Figure 7.6 is the shadow model of the real SU1. Using the message passing mechanism of DEVS between the models, in which messages are external events, and also exploiting the time-triggered message generation inside the modeled nodes, which are internal events, the simulation of the network is implemented. We use immediate messages for passing parameters between the models, while time scheduled messages are used to pass the data-carrying binary signals. For the simulated nodes, after a transmitter sends a packet of data, the Channel model passes the binary signal, along with the carrier frequency and other required parameters to MATLAB code that simulates a complete transmitter, channel, and receiver. The MATLAB code for the transmitter includes source coding, baseband modulation, upsampling and RF modulation, downsampling, etc. For the receiver, the necessary functions are also developed in MATLAB and the data (that may include error) are passed to the node in DEVS. The physical cognitive modem SU1 relies on its embedded software for data transmission, and the virtual environment simulation engine handles the interface between the shadow model SU1 and the physical SU1.

7.4.4 Experiment Results

Based on the PSBD methodology, we designed and implemented three cognitive SUs as follows. After initial simulation of one SU in MATLAB, we agreed on certain technical parameters. Then inside DEVSJAVA along with a generic simulation of one PU, we improved our SDR implementation of one SU along with its model. In the next step, we added one more SDR-based physical SU and more PU nodes along with one simulated SB to our network [24,28]. The simulated SB was in charge of transmitting channel assignment over the reporting channel. It combined the individual sensing result of the SU and assigned channels to them upon their request.

Figure 7.7 shows the result of a conventional simulation with all-simulated SUs and PUs. In this simulation, 2 SUs and 16 PUs were used. A flat fading wireless channel was used for simulation with white noise, and filterbanks were used for sensing. The simulation demonstrates how a SU can dynamically detect and change its band to avoid interfering with a PU. As shown in the top part of Figure 7.7, initially PU6 was not present (its power was below the noise temperature) and SU1 was using its band. Then as shown in the bottom part of Figure 7.7, as soon as PU6 returned, SU1 dynamically found another unused band that was less likely to have a PU any time soon as described in Amini et al. [24] and changed to the new band. In this simulation, SU2 used a band that no other PU was using. Thus, SU2 did not have to change its band.

Figure 7.8 shows the result of a virtual environment simulation that included one physical SU and 12 simulated PUs. In this experiment, we implemented three sensing methods, including filterbank, Fast Fourier Transform (FFT), and FFT with Hanning, and compared them. The collected data was the PSD sensed from a densely populated spectrum for 256 subcarriers in an experiment. This figure shows that SB reassigned a new frequency band to the only SU when PU3 was detected in the adjacent frequency of the previous carrier (the dotted vertical line in the top figure). As a result, the SU changed to a new band (shown by the vertical dotted line in the bottom figure). The top and bottom figures show before and after the PU3 detection, respectively. The continuous transmission of voice during this action also proved the success of the frequency hopping. This experiment shows that the cognition modem was capable of locating a less active band in the spectrum where more than 10 active PUs were transmitting. In addition, as shown in this figure, the FFT sensing could not detect two PUs on the right-hand side of the frequency spectrum, while the developed filterbank sensing could easily find them.