/MSED-Analyzer

A Bayesian Network based tool for the safety evaluation in multi sensor event detection

Primary LanguageJavaGNU General Public License v3.0GPL-3.0

MSED-Analyzer

A Bayesian Network based tool for the safety evaluation in multi-\sensor event detection.

Context

The usage of smart-sensors in critical Cyber-Physical Systems (CPS) poses new risks and challenges in terms of dependability especially when low-cost COTS devices are employed instead of custom and high-dependable ones. In such applications, having an adaptive software systems able to choose the best configuration according to Safety Integrity Level (SIL) and other non-functional indices, is a must for such applications.

Objective

This repository reports a prototypical version of a tool able to translate a textual configuration of sensing, voting and exclusions mechianisms into a formal probabilistic model in order to infer the SIL of the configuration. The fomalisms used are Bayesian Networks (BN) and some of their derivated ones (Dynamic Bayesian Networks, DBNs, and Time-Variant Dynamic Bayesian Networks, TV-DBNs).

Repository structure

The repository is structured as follows:

  • eclipse_project: the java Eclipse project developed with source code;
  • replication: this package contains some notable configurations and related outputs. This folder is mainly devoted for a quick verification of the experiments and analyses reported in scientific submitted papers.

Replication package

The content of the replication folder is the following:

  • sil_eval.jar: runnable jar generated by exporting the Eclipse project as a "runnable Jar";
  • *.conf: input files describing notable configurations;
  • *.csv: generated CSV files.

To execute the batch, run experiment.bat under Windows or experiment.sh in a BASH terminal.

How to build your experiment

If you want to prepare your own sensor configuration and run some experiments, you need to write a configuration file. There is no formal grammar for the configuration files, yet. Three examples are used to show the tool features:

Plain model

A plain model represents simple KooN voting mechanisms on different sensors each of them characterized by its own error rate. Here you can find a plain model file:

// Basic
basic_0=A,0.05
basic_1=B,0.03
basic_2=C,0.025
basic_3=D,0.01

// Experiments
conf_0=3,4,A,B,C,D
conf_1=2,3,A,B,C

First you have to write a list of basic sensors (i.e., the basic section). Each row contains a characterization of a sensor:

basic_*i*=*name*,*error_rate*

then you must write a list of configurations to express how the different sensors are combined into a majority voting mechianism. Each analysis must be formatted as the following:

conf_*i*=*k*,*n*,*1st sensor name*,...,*n-th sensor name*

You can use sensor replicas in a configuration (i.e., by simply using a sensor more than once in a configuration). In this case, you are specifying two physically distinct sensors of the same type).

External model

An external model is able to represent the dependency of one or more sensors on external, environmental disturbances. In such a cases, a sensor is affected by multiplying its error rate by a correction factor. In case estimating the correction factor is not possible with the confidence needed by a safety analysis, a - can be used to specify the worst case (error rate is 0.5).

The user can customize the model by specifying for each sensor and for each affecting external disturbance a specific correction factor. Here you can find an external model file:

// External
ext_0=E1,0.2
ext_1=E2,0.05

// Basic
basic_0=A,0.05,E1(3)
basic_1=B,0.03,E2(-)
basic_2=C,0.025,E1(3),E2(3)
basic_3=D,0.01

...

The first section to specify is the external section. Each row specifyies an external disturbance (e.g., high temperature, moisture, etc.). It follows this pattern:

ext_*i*=*name*,*occurrence_probability*

Then sensor description can be improved by specifying, for each sensor, a list of affections:

basic_*i*=*name*,*error_rate*,*list of affections separated by commas*

each affection is specified as follows:

*name*(*correction factor*)

The Experiment section is unchanged. Please, note that by using correction factors between 0 and 1, you can model external conditions that boost the detection capabilities of a sensor. Even if possible, it is unuseful in safety analysis where conservative hypotheses rule.

Control model

Furthermore, it is possible to model cases where additional sensors are added to the model to check the presence of the external disturbances. In such a cases, reputation of "ordinary" sensors can be varied according to an updating factor. The model is structured as follows:

...
// Control
updt=0.5
control_0=T1,E1,0.00001
control_1=T2,E2,0.001

updt is the updating factor (number between 0 and 1).

control_*i*=*name*,*disturbance*,*error rate*

The first three sections are unchanged.

Output of the experiments

After the construction and the analysis of the BN models, the tool produces a CSV formatted output that contains as many lines as the number of the tested experiments and the following columns:

  • configuration: list of the sensors present in the sensor configuration;
  • K: needed number of the sensors to have a majority among the sensors;
  • N: cardinality of the list of sensors;
  • test: set of the values related to the external events tested in the experiments;
  • hazard___probability: the probability that the configuration does not sense a passage of a vehicle given its passage (that is the hazardous event in the considered application);
  • unavail: the probability that the configuration is not able to reach a quorum and than the system is not available;
  • executiontime(msec): time in milliseconds that the tool takes to solve the model one it is built;
  • buildtime(msec): time in milliseconds that the tool takes to solve generate the model from the input configuration.

License

The software is licensed according to the GNU General Public License v3.0 (see License file).

Feedback

Anyone can report bugs on GitHub! Here's how it works:

  • Click “New issue” and choose the appropriate format.
  • Fill out the template with all the relevant info.

Feature requests are also welcome. Before opening a feature request, please take a moment to find out whether your idea fits with the scope and goals of the project. Please provide as much detail and context as possible.

Thanks a ton for helping me making better software.

Credits

This software is build upon the following software library. Without it, building this software would be harder: