From 0b075b6edf5c0cc1e28ebb2f00b8e329e0a7563a Mon Sep 17 00:00:00 2001 From: "DSTO\\pivatom" Date: Mon, 14 Jan 2019 11:20:15 +1030 Subject: [PATCH] Add voter class for fusion implementation --- .../DecentralisedActivityFusion/voter.py | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 DecisionSystem/DecentralisedActivityFusion/voter.py diff --git a/DecisionSystem/DecentralisedActivityFusion/voter.py b/DecisionSystem/DecentralisedActivityFusion/voter.py new file mode 100644 index 0000000..ebf3593 --- /dev/null +++ b/DecisionSystem/DecentralisedActivityFusion/voter.py @@ -0,0 +1,26 @@ +class Voter: + ''' + This class acts to replicate sensor information with the network to come to a consensus + of an activity occurrance. This is based upon research by Song et al. available at: + https://ieeexplore.ieee.org/document/5484586 + + The main advantage of this approach, as apposed to techniques such as by using zookeeper + or consul, is it can be completely decentralised and so works without a central server, + or needing to elect a central server. Additionally, it does not require all nodes + to run a Zookeeper/Consul server instance, which were not designed for these constrained + combat environments, which will fail if half the nodes fail, and also use a lot of resources + for handling services not required by this task. + + The original approach in the paper requires some previous training before sensing, so + that there is a probability of a given action based upon the previous set of actions. + ''' + def __init__(self, on_vote): + ''' + on_vote: Callback to get the required vote to broadcast. + ''' + self.on_vote = on_vote + + def submit_vote(self): + pass + + def \ No newline at end of file