Radiation level is one of the most critical hazards that must be taken care of due to its catastrophic and persistent consequences on the environment, humans and the other nonliving things. Radioactive incidents and disasters such as Chernobyl [1], Fukushima [2], and the most recent one at Russian nuclear missile test site [3], raised a serious concern. These events have given rise to the need for continuous monitoring of the radiation level in the environment. Since the radiation can be transmitted through the wind, it is important to monitor the radioactivity within widespread geographical locations to prevent any unwanted exposure. The continuous monitoring would greatly help in taking a proactive measure that would eventually raise an alert upon an occurrence of incidence. Therefore, many countries around the world raised the idea of developing several techniques for monitoring the radiation level in the environment to detect any abnormal release or discharge. Lebanon was one of these countries that developed a national environmental radiation monitoring program to establish radiation baseline level and determine trend of radiation level in the country. Air monitoring was one of the scopes of this program.
There exist different approaches to monitor and analyze the impact of high radiation levels. Among them is the Radiation Early Warning System (REWS) that is a widely used network system which exists in Lebanon since 2013. The REWS is composed of many radiation detection sensors (also called probes) disseminated on a specific region that monitor the gamma radiation level. This system reacts as soon as possible to anomalies by raising an alert. Typically, the alerts are determined by predefined threshold values that are essentially chosen based on observations (i.e. experience). It is worth noting that there are different threshold values at different locations since the threshold value depends strictly on the normal reading of the radiation level (known as background level) which is in turn is not fixed due to many factors such as the altitude. Once an alert is raised, it needs to be checked by an expert. Indeed, the expert needs to analyze the potential causes for the incident as some alerts refer to an authentic threat of high radiation level and others denote the rise of radiation level that has no hazardous impact on the environment or living beings. In order to do so the expert will consult additional information such as the weather broadcast and the quality factors (also called quality bits) of the probe. For instance, the alert is false when the quality bits of the probe indicate that there is a defect in the probe, meaning that we cannot trust the collected gamma dose rate value. The alert is innocent when external factors have occurred such as rain, wind, lightening, etc. These external factors are the more difficult to analyse, but they represent more than 90% of the alarms. Finally, the alert is real and an emergency action need to be taken by the authority immediately.
Existing REWS solutions have various shortcomings. The most critical one is the manual intervention of the expert that is heavily time-consuming, labor-intensive, and risk-prone. Indeed, when an alarm is raised a considerable amount of time and efforts are consumed by the expert to analyze the parameters that are stemming from external data sets such as weather data sets in order to classify the alert as false, innocent or real. As there is no automated data collector, the experts must carry out data searching and data fetching operations manually. Moreover, most of the time, the expert cannot classify the alert immediately as he/she needs to wait for further readings of the gamma dose rate to see if it will return to normal. This can take hours due to some parameters such as rain. Therefore, it is not possible to make a faster or real-time inference using the current approach.
Today, we assist to the explosion of machine learning techniques and complex algorithms in order to help experts or Figure 1. Low Dose Tube Broken Effect on Gamma Dose Rate non-experts to learn more about their data. Machine learning techniques might help building predictive models in order to have a real-time proactive system. However, in order to apply these techniques, some preliminaries analysis should be done to better characterize the problem that needs to be solved. The main objective of this research is to analyse REWS and see if the expert can be removed from the picture and replaced by an autonomous REWS. There are many challenges to address before reaching this goal. The work described in this paper is the first attempt to do so, as to our knowledge it does not exist autonomous REWS in the literature.
The main objective of this research is to develop an end-toend solution that will be integrated with running REWS systems without any disruption or without replacing it completely. Indeed, before replacing the expert, the system should prove its accuracy to predict the right answer. Thus, a supervised learning should take place at the beginning until it reaches its full potential and work on its own. In this paper, we present our RIMI framework (Refining Incoming Monitored Incidents) that highlight the different steps that need to take place before reaching an autonomous REWS solution. In this framework, we plan to develop a list of components from data acquisition and normalization, to building a predictive model on a real data set produced by a running REWS, then by using it to predict the right classification of the alarm on real-time data.
The remaining of this paper is organized as follows. Section 2 will highlight the nature of the problems that need to be solved in REWS. In Section 3, we describe our RIMI framework and detail each of its components. Finally, we will conclude our work in Section 4. Notice, that there will not be a related work section in itself, as it does not exist similar work in the literature but rather, once a problem has been refined we will give some hints of the approaches that have been proposed in the literature to solve this particular problem.
In this section, we illustrate some of the scenarios that an expert will encounter during his/her work. These scenarios reflect the variety of the situations that occur most of the time.
The scenario described in Figure 1 illustrates how an internal factor can affect the gamma dose rate. For instance, when the low dose tube of the probe is broken, thus it affects the quality of the gamma dose rate value. Its interpretation is no more reliable. This type of scenario will produce a false alarm.
In the scenarios respectively described in Figure 2 and Figure 3, we see how the wind and lightnings directly and immediately impact the gamma dose rate. In these scenarios, we observe many peaks that do not last very long. We called them hard parabola. These types of scenarios will produce a false alarm.
On the opposite, the rain impacts the gamma dose rate in a completely different manner. Rain for example can cause the soil to emit radioactive gases into the air resulting a true innocent gamma radiation readings. When hitting the soil, the rain can increase the gamma dose rate that will return to normal values after specific time. Sometimes, even if it continues to rain after the peak, it will not affect the gamma dose rate anymore. The effect is seen when the soil is dry, not when the soil is already humid. This behavior is described in the Figure 4 and corresponds to what is called soft parabola. It is classified as an innocent alarm.
Fortunately, real alarm are very rare, but as you can imagine the peak will not decrease after a short period of time but will continue to increase. Many other scenarios can also be found in practice. For instance, some factors like earthquakes Many data sources should be combined together. Some are collected in a continuous manner by the REWS and stored in an historical database. But many others data sources must be queried on demand when an investigation is launched by an expert. Combining all these heterogeneous data sources on the fly is also a difficult problem in itself.
Another dimension of the problem concerns the variability of the threshold values that evolve over time and that is also dependant on the location of the probe itself. As said earlier, these predefined threshold values are essentially chosen based on observations or experience at the beginning, but they evolve slightly over time on a monthly basis, making the comparison of the time series over multiple months not an easy task.
All these examples illustrate the difficulty and the heterogeneity of analysing the gamma dose rate shape and understanding its causes in order to classify properly the alarm in an automatic way. For all these reasons we believe that the research problem is interesting to be tackled as it will require many different techniques or approaches to be used. This is the reason why we define the RIMI framework to offer an end-to-end solution towards an autonomous REWS.
In this section, we provide a detailed description of our framework entitled, RIMI (Refining Incoming Monitored Incidents). The framework consists of three main components:
(1) the data collector and enrichment, (2) the building of the predictive model, and (3) the online detection and prediction. Figure 5 illustrates more in detail each of the main components. As the incident is caused by a high gamma dose rate level which can be harmful for humans and environment, this framework aims to replace a human-driven verification system that refines the incoming incidents and alerts and detect its cause by doing it automatically with a high level of accuracy.
As seen in the previous section, the data is heterogeneous (i.e. time series, quality bits, events) and comes either from the online REWS monitoring system or from the external data sources that must be queried on demand by experts in the case of a triggered alarm. The data collected by the REWS system is stored in an historical database. The data acquisition is done on a regular basis through secure channels between the radiation detection sensors (i.e. probes) and the server. In normal mode, the probe sends a message containing the gamma dose rate average every hour, but when an alarm is triggered because the gamma dose rate is over the threshold, the system switches to an alarm mode, thus the probe sends a message every minute. The system returns automatically to its normal mode when the gamma dose rate returns to normal. In addition to the gamma dose rate, the probes send other sensors data (also known as Quality Bits) as they are equipped with internal sensors that can detect the defectiveness of any of the system components. These sensors data are stored in the historical REWS database for later analysis. As we have seen earlier in one of the scenarios, the defect of the low dose tube can cause a direct false high gamma radiation level.
For the time being, three years of historical data have been collected by our REWS that is used in Lebanon and controlled by the Lebanese Atomic Energy Commission. These data are precious and can be used to train our predictive model, but these data needs to be enriched by external information in order to automatically find the causes of an alarm. The data sources that can be queried on demand are numerous. It can be a weather database, a radiation transportation database, etc. In order to be queried, we need to know the approximate timestamp of the alarm in order to better understand the past context or situation in which the alarm was triggered. On the historical data set, sometimes the data are annotated by the alarm timestamp (i.e. when the alarm was triggered) but most of the time it is not. So it is our responsibility to infer the alarm detection on past sensors data.
Because of the heterogeneity of the data sources, the data needs to have some validation and normalization before being integrated into our framework. The RIMI framework has to deal with multivariate time series that need to be integrated in a proper way. The main time series related to the gamma dose rate needs to be harmonized in respect with : (1) the normal and fast modes, (2) communication problems between the probe and the server which result in missing information. Moreover the enrichment of the time series should also be done in a proper way especially when it stems from external data sources. For instance, timestamps should be aligned or normalized to avoid inconsistencies in the analysis.
The predictive model is built upon the historical databases produced by the running REWS system, which continuously collect sensors data produced on the different probes. First, there is a need to identify all the incidents. Second, we should research the causes of each incident. This requires the data enrichment to better understand the past situation or context that occurred during the incident. Finally, all this mass of information should be organized and classified in order to build our predictive model that will be used at run-time.
1) Incident Extractor: Incident extraction consists in analysing the gamma dose rate time series data in order to identify a fragment (i.e. shape). A fragment corresponds in fact to a triggered alarm (i.e. incident). As said earlier, the threshold and the background values are not fixed but they evolved over time. At the beginning of the system, a value is given but it is refined over time to better suit the default gamma dose rate of the location on which the probe is installed. This value called the background can be different from one location to the next. At the end of each month, the average of the background values is calculated to find the background mean. This mean will be used for finding the background interval which is the range of the safe gamma dose rate values in the environment. It is important here to mention that this mean will be calculated after removing the threshold values from the month data set. To find the threshold value, we noticed that experts in different countries depend on different methods. Some consider that values that are equal and greater than 1.5 times the background mean as thresholds. Others refer to the values that are equal and greater than 2 times the background mean as thresholds. We decided to be more precise and rely on the 1.5 method knowing that this value can be changed to suit experts' expectations through different countries. We explored several methods to find the most suitable one that determines the lower and the upper bounds of the background interval. Our study revealed that the standard deviation [4] is promising to find the background level interval.
We choose standard deviation because of the nature of the distributions of data. According to our observation, radiation level data are uniformly distributed and to the best of our understanding standard deviation is a suitable technique for finding intervals when data are uniformly distributed in a two dimensional graph. This background level interval is calculated by adding and subtracting the value resulted in by calculating the standard deviation to the mean of the background values in the current month. This computation model produces a catalog of parameters with the corresponding means, thresholds, and the background intervals values for each month. Thus the Incident Extractor component relies on the catalog which defines the appropriate background interval values for each month. We assume that this catalog is fully computed on historical data before the extraction starts.
In the Figure 6, we define the background interval that corresponds to the acceptable background values. It is represented by a lower B1 and an upper B2 bounds. We also show the threshold value which is 1.5 times the background mean.
A fragment is defined by a beginning x and an end y timestamps. In other words, once a threshold value is found, the Incident Extractor will search for the nearest points x and y that represent the preceding and succeeding values of the threshold and extract the current fragment from x till y. Note that these two values must lie within the background level interval. They respectively identify the time when the gamma dose rate starts to increase in an abnormal way and when its return to a normal state. Moreover, it is worth noting that we designed a locking mechanism that does not allow the Incident Extractor to start a new extraction operation unless the previous one is completed. We used a locking mechanism because a graph may contain Shapelet extraction has drawn significant research attention, in recent years. Many algorithms have been proposed in the literature such as Piecewise Aggregate Approximation (PAA) [5] and the Multivariate Shapelets Detection (MSD) [6]. These approaches search for shapelets that are similar to a referent shapelet. These approaches are not be suitable to our problem as we do not have any referent shapelet and due to the evolving of the background level, the duration of our fragment can be multiple. Moreover, some of the approaches go beyond that and discuss extracting shapelets based on predefined key points [7]. These methods aim at detecting key points in the time series and then extract the shapelets referring to these key points. Such approaches need to be investigated more in order to check their compatibility with our evolving background interval.
2) Identifying the Incidents Causes: Once the fragments are extracted, we enrich them by querying external data sources to better understand the context that occurred in the past during a specific period of time as defined in the Figure 6 with the beginning x and the end y timestamps. Our goal is to annotate the fragments with its potential causes. Two kinds of incidents can be obtained based mainly on the duration of a fragment: the one representing incidents with hard parabola and the others representing incidents with soft parabola as illustrated in the different scenarios detailed in Section II. At this stage, the cause behind each incident is unknown.
For incidents with hard parabola, the cause will not be risky as it shows different peaks in a short period of time. In such case, the cause could be because of the quality bits readings indicating an error in one of the system components as shown in Figure 1. Other causes for hard parabola incidents could be the wind and the earthquakes. They will perform a shaking effect on the probe leading to a false increase in the gamma radiation level (Figure 2). Lightning can also cause the probe to represent a false increase in the gamma dose rate level (Figure 3).
On the other hand, the causes behind the incidents with soft parabola are few. Rain is one of the most frequent causes that can lead to the increase of the gamma radiation level for a long period of time. This increase produces time series data with soft parabola knowing that the radiation level will return to normal values after a specific period of time. Other causes leading to a soft parabola of gamma radiation level could be real threads. Although rain has an effect on the radiation level, its effect will not start directly on occurrence. For example, we can notice in Figure 4 the several rain events occurred before the gamma radiation level starts to increase. Also, we can notice how rain events continue after the gamma radiation level returned to normal values without affecting it again. This can tell us that the effect of the rain on the gamma radiation level is not simultaneous.
In the literature, it exist some causal models such as the most well-known one which is the Granger Causality Model [8] that can be helpful for finding the cause between time series especially for hard parabola. Indeed, many external factors, which come as time series data, have an immediate effect on the gamma dose rate. In other words, they are directly correlated and it is an evidence that the external factors are the cause, and not the other way round. If the external factors are not the cause for the hard parabola, we need to investigate the Quality Bits to look for a problem in the components of the probe. Moreover we need to inform some technicians that the probe needs some reparation. However for soft parabola, the Granger Causality Model will for sure not work as the correlations are not direct, nor obvious. In particular, we need to enrich the data in a more vaster way as the cause may have happened before the beginning timestamp of the fragment. How much before we do not know as it can depend on the nature of the soil. We also don't know if the quantity of heavy rain will have an impact of the increase and decrease of the gamma dose rate. At the moment, we do not know which techniques can be used, may be a specific causal model needs to be defined. Finally, if multiple causes are combined, such as rain and wind, the causal model that can be used for hard parabola will not work anymore. It is pretty sure that we may encounter some situations that we have not yet identified.
Once the possible causes for an incident have been identified, we might check the accuracy of our model by consulting the historical database. Indeed, some incidents have been annotated in the past by some experts and we can use this knowledge to tune our model. Moreover, there will be also the possibility at the beginning of this stage to involve an expert, to evaluate the accuracy of our findings. Most probably we will find more causes for incident, because most of the time the expert may focus on the main cause and will not look for all causes as it is time consuming. Finding the causes for a situation is in a way of finding a complex situation that occurred in the past. We plan to look at situation awareness models to better capture the complex nature of the causes (i.e. situation). For instance, knowing that the rain that occurred in the first week of October at a specific location may have more or less impact than the one occurring in the summer. What is clear is that each fragment will be annotated with the description of the situation (i.e. causes or events happening together).
3) Classification: After identifying the causes and calculating the situation for each fragment, we need to classify them in order to build and train our predictive model. We will start by comparing the different incidents extracted in order to set the main classes, then we will compare the situations inside each class to form the sub classes. The classification process will start forming the main classes by following a model-based approach. Through this approach, the incidents extracted from the gamma dose rate time series will be compared based on the graphical shapes representing the incidents. Several incident shapes will be gathered and classified as soft or hard parabola shapes.
Existing shapelet classifiers proposed in literature use different techniques. In [9], the authors proposed a model for classifying shapelets using minimum Euclidean distance between the input and the expected templates. Mahalanobis distance, introduced in [10], takes into consideration the correlation of the data and is scale-invariant. The authors believe that this approach will give more accurate results than the Euclidean Distance method. We found some works that focus on simplifying the distance calculation. For instance, the DTW (Dynamic Time Wrapping) algorithm [11] focuses on reducing the computing complexity and improves efficiency. In addition, many previous approaches dealing with time series classification will be investigated to perform this task. Some potential mathematical model could be used in developing our classifier including the Chebychev distance [12], Manhattan distance [13], and Minkowski distance [14]. We will investigate all potential algorithms and models to find the best technique that can fit our data.
After forming the main classes, the incidents will be compared based on their annotated situations. Sub classes will be formed based on the incident annotated cause or combined causes. This will refine the classes to form the sub classes based on the values obtained. We will end up with a wide range of classes that will be used in the online detection of the incident.
Once the classes are defined, the Online Detection and Prediction phase can take place. Its job starts when an incident alarm is triggered. As said earlier, the alarm can be categorized into three types: false, innocent, or true. The aim behind this phase is to check if the current incident occurring with the specific annotated information corresponds to a predefined class as quickly as possible. The main job of the online predictive model will be calculating the context by checking what is the current situation once an incident is captured. Based on the discovered situation, the model will start searching for similar incidents in the related classes.
The incident pattern matching engine is the analytical engine deployed to recognize the new incidents by performing a matching operation over the annotated patterns produced at the incident classification step. We designed this analytical engine based on Kappa Architectural Style which means that the incident pattern matching operations will be performed in real-time. At the same time, a pre-designed algorithm will be running in the background to calculate the parameters that will be used for next month's evaluation. On incident detection, the framework will search for the current situation, since it will be always connected to external and internal factors databases, and will run the Incident Matcher phase, which will look to the nearest point before the threshold belonging to the background level, and start matching the beginning of the current shapelet with those represented in the predefined classes.
For example, Figure 7 shows the analyzing process for incoming data. As we can notice, the readings started within the background level interval which means a normal situation with accepted values. Once the readings exceed the upper bound of the background interval (B2) and reached the threshold value, then the alarm will be triggered detecting incident case and the matching process starts. This will provide different possibilities for the continuity of the current shapelet referring to the already obtained shape after comparing it to the previously classified incidents. It will repeat this process until the possibilities become so limited that the cause can be detected. Thus, the framework will be able as soon as possible to detect the cause behind the incident and alert the experts if special procedures must be taken. To perform this task, we can reuse the techniques defined in the Incident Extractor module.
2) Accuracy and Verification: The objectives of our research is to propose a fully automated framework. However, we strongly believe that at the initial stage the solution needs an expert opinion to validate the results produced by the system. This validation is important due to the sensitivity of the use cases that will be implemented using this solution. This will help in increasing the accuracy rate of the proposed framework. Moreover, in case of exceptional use cases that were not known, the involvement of the experts would help to enhance the solution by training the classifier over the data and make it capable of recognizing incident patterns that were unknown before.
This paper presented an end-to-end framework for (pre)processing, processing and analysis of radiation level data. The objective of developing this framework is to eliminate the manual intervention in radiation level monitoring systems. In this paper, we explained the key components of the framework including data pre-processor, incident extractor, data enhancer, and incident classifier. We provided a detailed description of an analytical engine which matches the fragment patterns in realtime and helps the experts in faster decision making regarding verification of an alarm.
Several works have been lined up for future. In the near future, we planned to develop techniques for classifying the incidents. We will train, test, and optimize the classifier to guarantee that accuracy of classification. Also, we will develop a real-time analytical engine using advanced tools for performing classification in real-time.