1 Introduction

Buildings and infrastructure are frequently subjected to hazards such as earthquakes, typhoons, floods, and fires. These hazards may lead to other more serious disasters including nuclear crises. On March 11, 2011, a mega-earthquake occurred on the east coast of Japan and resulted in a destructive tsunami, which in turn caused releases of radioactive materials at the Fukushima Daiichi nuclear power plant (NPP) (Wang et al. 2013). The Fukushima accident developed into a full-blown disaster due to many factors, including losses of power and cooling functions, and the lack of sufficient preparation for an incident of such severity (Headquarters 2011). To limit the radiation exposure of the population of Fukushima Prefecture, the Japanese authorities created 20-km evacuation and 20–30-km sheltering (stay-in) zones (Priest 2012). However, the public faced enormous challenges including deciding when to evacuate, what area to head toward when evacuating, and how to maintain contact with family members from whom they had become separated due to disaster conditions. Lack of information on the timeline, emergency treatment, and influences of the nuclear disaster led to unnecessary public panic. Therefore, it would seem worthwhile to develop a single platform that has the ability to perform radiation monitoring, information delivery, and information announcement.

Typically, sensors are an important means of radiation monitoring, and recent developments in smart-sensor technology support new applications in this area. In addition to sensing capability, the main features of a typical smart sensor are its on-board microprocessor, data storage, wireless communication, battery power, and low cost. The long-term recording of data for monitoring purposes is expensive (Celebi 2002; Farrar 2001; Nagayama et al. 2007); smart sensors can process data before outputs are recorded, reducing the amounts of data transmitted and computing power required. Wired sensor systems can only deploy a limited number of sensors because of cost and complexity constraints. When numerous sensors are needed, wireless sensors—which are more easily installed—are preferable. Smart-sensor-based wireless sensor networks (WSNs) are an attractive option for monitoring radiation because of their low manufacturing costs, low power requirements, small size, and simplicity of deployment (lack of cables) (Ding et al. 2009; Korostynska et al. 2008; Lynch and Loh 2006; Spencer et al. 2004).

The internet of things (IOT) is a novel concept, expressing the fact that a variety of objects already present around us such as radio frequency identification (RFID) tags, wireless sensors, actuators, and mobile devices are able to interact with each other and cooperate with their neighboring objects in pursuit of particular goals (Atzori et al. 2010). This concept will be fully achieved via the embedding of electronics into an even wider range of physical objects, rendering them “smart” and seamlessly integrated within the global infrastructure (Miorandi et al. 2012). Today, traditional infrastructures are subjected to disasters that carry the risk of major loss of human life if not responded to properly. Damage and injury can and should be minimized through the provision of adequate situational awareness and decision-making support, and for this reason, the IOT is potentially very useful for managing crisis situations via providing sound disaster management and emergency-response information (Du and Zhu 2012).

This study developed an IOT-based intelligent disaster information-integrated platform (IDIIP) for disaster monitoring, disaster information management, and emergency-response coordination. To prove the concept of the IDIIP, a radiation-monitoring scenario was selected. The proposed platform combines WSNs, an information exchange web service (IEWS), and a smart mobile device-based disaster announcement app, as described in detail in the following sections, as well as a novel IOT-based data storage and exchange framework. Based on this framework, IOT devices can be upgraded effortlessly even if site conditions or users’ requirements change. Moreover, when sensors are upgraded or replaced using traditional methods, a great deal of effort is expended in rewriting the sensor drivers. Our framework makes it possible to upgrade sensors without rewriting their drivers.

2 Architecture of the intelligent disaster information-integrated platform

Figure 1 presents the three-layered architecture of the IDIIP. The top layer is a WSN client that is deployed in civil infrastructure to perform specific tasks such as sensing, data processing, and acknowledgment. The middle layer is an IEWS through which all information such as sensor data, structural health, and location are exchanged. The third layer consists of disaster information announcement for data representation and event notification.

Fig. 1
figure 1

Architecture of IDIIP

Full size image

The WSN client is an integrated WSN system based on hybrid wireless communication; disaster conditions will be assessed remotely. The proposed architecture consists of radiation-sensing nodes and an IOT platform. Each sensing node comprises a microprocessor, sensor module, and communication device. All sensing data will be sent to an IOT center node in the sensor’s own community using one-hop transmission. The IOT center node is the highest-level end device that, as compared to the other members of the WSN, has the largest memory, most powerful processor, and highest communication capability. Specifically, this capability entails uploading the data to a remote monitoring and control server via Wi-Fi, GPRS/3G or Ethernet.

IEWS is an interface between the WSN client and the disaster information announcement layer. All information such as sensor data, structural health, and location are exchanged via this service. For example, the WSN client will post an event to IEWS when a radiation accident occurs. After the IEWS receives the event, the notification will be sent to the mobile device-based information platform. Alternatively, the mobile device-based information platform can actively monitor the radiation by sending a request to the IEWS. Subsequent to the development of a well-defined IEWS, the creation of a cross-platform application can easily to be accomplished.

The third layer provides a smart mobile device-based app for disaster information delivery, developed for the Android smart phone. Its several functions include monitoring management, real-time warning, and disaster information reporting. Monitoring management is designed for monitoring sensor health, viewing the WSN topology, and showing the location of infrastructure components on Google Maps. Real-time warning is useful for warning people when damage or disaster is occurring, while disaster information reports are useful for confirming that such information has been delivered. An existing community website is also used to deliver significant information after a disaster and create an information hub for the public.

3 Design and implementation of IDIIP

The main purposes of the IDIIP are to monitor radiation levels and distribute necessary information to the public. Its three-layered architecture required us to design and implement both hardware and software, as discussed in the following subsections.

3.1 Hardware: design and implementation of radiation-sensing nodes and IOT center node

The WSN client is a key part of IDIIP, as it performs radiation sensing. Figure 2 presents its architecture, which consists of radiation-sensing nodes and an IOT center node. The former is deployed in infrastructure or buildings to perform radiation sensing. All their radiation-sensing data are sent to an IOT center node in their own community using one-hop transmission. The IOT center node is then able to calculate radiation distribution or the average level of radiation in its managed region. Subsequently, the IOT center node (which as previously mentioned has largest memory, most powerful processor and highest communication capability of any WSN component) will upload data to IEWS via Wi-Fi, GPRS/3G or Ethernet.

Fig. 2
figure 2

Architecture of radiation-based WSN client

Full size image

Each radiation-sensing node is deployed either close to nuclear power plants or in fixed infrastructure or buildings. The node is required—in addition to radiation-sensing capability—to have an independent power supply, as well as independent data-processing and wireless transmission capacity. Our prototype radiation-sensing node was developed based on these requirements. The prototype node consists of three main components: a radiation sensor unit, a microprocessor unit, and an RF transceiver. Figure 3 presents a functional block diagram of the radiation-sensing node prototype hardware, and Fig. 4 is a photograph of the prototype as built.

Fig. 3
figure 3

Functional block diagram of radiation-sensing node hardware

Full size image
Fig. 4
figure 4

Photograph of radiation-sensing node prototype

Full size image

The radiation sensor unit has two main components: a Geiger count board and a Geiger tube. The Geiger tube seals Ar gas in a thin glass container with a central wire. About 600–1,000 V potential difference is applied between the central wire and the tube. If any incoming α, β, or γ ray contacts the tube, it will ionize some of the Ar atoms. The increased number of these Ar+ ions will in turn produce a pulse of electrical current. The Geiger count board then measures this pulse, which is amplified. Therefore, it is possible to count the number of radiation particles passing through the tube in a given time period. There are two main parts of this radiation board: the power circuit and the signal circuit. The power circuit provides the high-voltage supply for the tube (400–1,000 V), while the signal circuit converts the pulse output from the tube and connects it to the microcontroller.

The microprocessor unit measures the pulse output from the tube and controls the RF transceiver’s sending of data to the IOT center node. The hardware used for the microprocessor unit is an open-source board, which includes an on-board power connector, voltage regulators, MicroSD connector, USB host and USB client connectors, as well as an XBee adapter for ZigBee or Wi-Fi XBee modules.

An XBee module was chosen for wireless communication and data transmission in the radiation-sensing node. XBee is the brand name of a product made by Digi International, designed for point-to-point and star communications based on the 802.15.4 standard. Xbee now can support the mesh topology rather than only using star topology. In this study, two models were used—a lower-cost 1 mW XBee and the higher-power 100 mW XBee-PRO. The TX peak current and RX current of XBee are 45 and 50 mA, respectively. Compared with XBee, XBee-PRO has a higher transmission distance (up to 1.6 km vs. 500 m), but requires more power.

A prototype of the more powerful IOT center node was also constructed. The center node has three main parts: a microprocessor unit, a communication unit, and a peripheral unit. Figure 5 is a functional block diagram of the IOT center node hardware, and Fig. 6 shows the IOT center node prototype as built. This platform is a plug-and-play design that provides a physical hardware interface that serves as a standardized mechanism for connecting hardware sensors and peripherals (modules) to a Micro-Framework-based processor board known as a mainboard. The Micro-Framework is a subversion of the .NET framework, written for 32-bit ARM processors. The user can write applications in managed code with a free development environment, allowing them to deploy applications and perform hardware debugging without an expensive debugger.

Fig. 5
figure 5

Functional block diagram of IOT center node hardware

Full size image
Fig. 6
figure 6

Photograph of IOT center node prototype

Full size image

The microprocessor unit is a mainboard with a 72 MHz 32-bit ARM7 processor, 4.5 MB flash, and 16 MB RAM. The mainboard uses an IDC ribbon cable with a 10-pin 1.27-mm connector for connecting to the modules. As such, a number of generic hardware interfaces ranging from digital inputs and outputs, to serial connections, to inter-integrated circuits (I2Cs) and serial peripheral interfaces (SPIs) can be used to control the modules, which include a GPS module to provide precise geo-locational information and to synchronize all sensing nodes; an SD card module, which saves received data; and a touch-display module used for displaying messages and debugging.

Each IOT center node must have the ability to receive data from sensing nodes and upload it to IEWS. Based on this requirement, three kinds of communication modules—an RF transceiver, a GPRS module, and an Ethernet module—were used in the center node prototype. If the IOT center node is set up in a well-networked infrastructure area, the Ethernet module has the first priority for uploading data, via the internet. However, because not every place has adequate internet infrastructure (if any), the GPRS module can be used for uploading data via GPRS networks instead.

3.2 Operation mechanisms

This section describes the functions and operation mechanisms of IDIIP. These software functions correspond to IDIIP’s three layers. There are only two functions of the WSN client: the radiation-monitoring function, which includes radiation detection and data transmission, and the upload or data-posting function for uploading data to IEWS. Subsequently, the smart mobile devices app can acquire radiation data from IEWS via the query-data function.

Figure 7 shows the software operation mechanisms of the WSN client. First, after the IOT center node is initialized, network connections are checked. If the network is not connected, the system will try to re-connect to networks up to five times. If the network still remains disconnected after five attempts, the system will display a pop-up message, reminding the user to check the network settings. If the center node successfully connects to the network within the first five attempts, the system will use network time protocol (NTP) time to synchronize the system clock. The IOT center node then sends an inquiry packet to confirm whether the sensing nodes are ready. The sensing nodes and IOT center node then exchange timestamp packets to synchronize with one another. The center node then waits to receive data from the radiation-sensing nodes.

Fig. 7
figure 7

Software operation mechanisms of the IDIIP’s WSN client

Full size image

After initialization, the radiation-sensing node creates a timer and sets it to tick at intervals of one second. The system then requests the timer-tick handler to start a radiation-sensing process. As mentioned before, the Geiger tube produces a pulse of electrical current; an interrupt event is used to count the pulses. The system will keep counting the pulses for 60 s. Next, the count per minute (CPM) value will be used to calculate the Sieverts per hour (µSv/h). Equation 1 shows how the μSv/h can be calculated. The conversion factor can be found in the datasheet of the Geiger tube. Subsequently, the CPM and μSv/h are sent to the IOT center node for uploading to IEWS.

$${\text{CPM}} \times {\text{conversion}}\,{\text{factor}} =\upmu{\text{Sv}}/{\text{h}}$$
(1)

The second layer of the IDIIP software is IEWS: A web service that was created using hypertext transfer protocol (HTTP) and uniform resource identifier (URI). It also follows the principles of representational state transfer (REST), a style of architecture for Web software design, and therefore can be described as RESTful. The IEWS uses HTTP methods that allow the client application to retrieve a resource, to fetch data, or to execute a query from a database. There are four basic HTTP methods that are generally used: GET, POST, PUT, and DELETE. Moreover, IEWS uses directory-structure-like URIs that allow the developer to understand what they points to and derive related resources. Based on these characteristics, our IEWS is the key interface between the WSN client and the mobile device-based information platform. All sensor data and locational data are exchanged via this service, which comprises two subsidiary services: (1) the upload-data service, which enables the WSN client to post radiation data to IEWS; (2) the query-data service, with which the mobile device-based information platform can actively monitor radiation via sending requests to the IEWS.

The third layer of our software consists of disaster information announcement. First, an Android-based app was developed for communicating radiation information to members of the public. Public users can use this app to check radiation distribution in their area, and if the radiation exceeds safety guidelines, the IEWS will send a notification to each user via the Android push notification service (APNS).

3.3 IOT-based data storage and exchange framework

IDIIP, like any IOT-based architecture, must make use of large amounts of data that have been connected to the Internet from different sources and by a variety of methods. When numerous sensors and related devices are deployed, great difficulties arise in maintaining, updating, and configuring them. We propose to address these issues via a novel IOT-based data storage and exchange framework. There are two main benefits associated with using this framework. The first is scalability: When site conditions or users’ requirements change, the IOT devices can be upgraded effortlessly. The second is commonality. Traditionally, when sensors are upgraded or replaced, the application software or drivers need be modified simultaneously, with driver modification in particular requiring a great deal of effort. Our framework allows sensors to be upgraded without rewriting of the sensor drivers.

Figure 8 is a functional block diagram of our IOT-based data storage and exchange framework, describing its functions and operation mechanisms. There are two main parts to this framework, the first being IO data storage (IODS). The function of IODS is to store IO data that support the drivers and applications for information exchange. IODS consists of two types of variables: IO variables and IO device variables. IO variables do not bind any devices or sensors, but are used for temporary data storage. IO device variables, in contrast, are binding to devices and drivers and are useful for sensor upgrades. When manufacturers upgrade their sensors, they do not change the complete design but rather some of its parameters, such as sampling rate, address, type, length and so on—all of which can be stored in IO device variables. The driver can access the IO device variables to modify existing parameters without itself being rewritten. After IODS, the second main part of our framework is sensor data storage (SDS), which uses data variables to save sensing data. SDS is essentially a file system, but smaller, simpler and faster.

Fig. 8
figure 8

IOT Data Storage and Exchange Framework

Full size image

This framework provides several interfaces for data access. The application system can use the “Ex Read/Write” interface to access the data in IODS. “IO Read/Write” is an interface between IODS and drivers for accessing sensor parameters or commands. The application system can write a command-set in IODS for a specific task. When the driver is loaded and reads the IODS, the task is executed automatically. Also, there are several interfaces such as “Create/Read/Write/Close” that can be used to operate sensor data in SDS, which is more convenient than directly operate the raw data in ram.

4 Experimental study

We conducted an experimental study to verify the proposed IDIIP. First, an experiment was conducted to validate the radiation measurement ability of the radiation-sensing node and IOT center node. There are three types of radiation: Alpha, Beta, and Gamma. Alpha radiation is emitted from the nuclei of atoms. It contains positively charged (+2) particles that can be blocked by a sheet of paper. Alpha particles are not a serious health hazard and occur naturally within the body as a result of eating. Beta radiation contains negatively charged (−1) particles. These particles have higher ability to penetrate materials than Alpha particles do and can be hazardous to living tissue if ingested. Nevertheless, they can be blocked by a few millimeters of aluminum. As such, the sensitivity of Geiger counters for detecting Beta radiation is generally dependent on the thickness of the Geiger–Mueller tube wall. Gamma radiation, which has the highest frequency and shortest wavelength of the three types, can pass through almost anything, excepting only some high-density materials such as lead. Gamma rays are also known as “cosmic radiation” due to their being produced naturally by the sun and other bodies in outer space. The Geiger tube used in our prototype radiation-sensing node is fairly sensitive to both Beta and Gamma radiation.

Because Gamma rays occur naturally in background radiation, the radiation-sensing node will inevitably make non-disaster-related detections at random intervals normally from 10 to 30 pulses per minute, as shown in Fig. 9. For the Alpha and Beta tests, we used a 2 % thoriated tungsten rod, a material commonly used in welding. The thorium used in 2 % thoriated tungsten is a radioactive element and thus is dangerous to the health of people exposed to it and to the environment. First, we set the radiation-sensing node to measure background radiation for a period of 20 min. Next, we moved a thoriated tungsten rod close to the radiation-sensing node for 5 min and then removed it. Figures 10, 11, and 12 illustrate the testing results for radiation detection of thoriated tungsten, in CPS, CPM, and µSV/h, respectively. As expected, the radiation-sensing node counted more when the thoriated tungsten rod was nearer to it. The distribution of CPM was from 10 to 30, corresponding to 0.1 to 0.3 µSV/h without the thoriated tungsten rod. Likewise, the radiation value significantly increased when the thoriated tungsten rod was closer to the Geiger tube. The peak detected value of µSV/h was about four times greater than that of average detected background radiation.

Fig. 9
figure 9

 Background radiation (cpm)

Full size image
Fig. 10
figure 10

The number of pulses by second (cps)

Full size image
Fig. 11
figure 11

The number of pulses by minute (cpm)

Full size image
Fig. 12
figure 12

Value of radiation in µSV/h

Full size image

Having validated the radiation-sensing node, we will proceed to a description of an IDIIP operational scenario. Generally, radiation-sensing nodes would be discretely deployed in buildings or infrastructure located between a nuclear power plant and residential areas. All information about radiation that they detect will be sent to an IOT center node within their communication range. Subsequently, that IOT center node will send data to IEWS by calling the web service, and then saving radiation data to the database. The public is informed if the disaster has occurred, via phone app and can see the radiation distribution on Google Maps. Figure 13 illustrates the main screen of our Android-based smart phone app. As can be seen in the figure, a radiation icon is shown in the monitoring panel. When a user clicks the icon, a Google Maps pop-up will show all deployed radiation sensor nodes that are marked on the map. The user therefore can know the radiation value in specific places, such as the nuclear power plant or their own house. Clicking on the text label will cause another page to appear, displaying the trend of radiation.

Fig. 13
figure 13

Radiation distribution as shown on Google Maps within our Android-based smart phone app

Full size image

5 Conclusion

This study developed an IDIIP for radiation monitoring. The architecture of this platform was introduced, and its hardware design and software design of all components were discussed in detail. An experimental study was conducted to verify the proposed IDIIP. First, an experiment for radiation measurement was conducted to validate our prototype radiation-sensing node and IOT center node. Subsequently, an operational radiation-monitoring scenario for this platform was described. All results indicate that this platform would be beneficial for radiation monitoring and disaster information dissemination to the public.