[JPDC,JCC@LMN22] Ad hoc systems Management and specification with distributed Petri nets

Ad hoc systems management
and specification with distributed
Petri nets
Jornadas Chilenas de Computación
Lo Mejor de lo Nuestro (LMN)
JCC 2022
Juan Sebastián Sosa 🇨🇴,1 Paul Leger 🇨🇱,2 Hiroaki Fukuda 🇯🇵⚽,3 Nicolás Cardozo 🇨🇴1
1School of Engineering - Universidad de los Andes, Bogotá - Colombia
2Universidad Católica del Norte, Coquimbo - Chile
3Shibaura Institute of Technology, Tokyo - Japan
js.sosa10@uniandes.edu.co, pleger@ucn.cl, hiroaki@shibaura-it.ac.jp, n.cardozo@uniandes.edu.co
@ncardoz

2
Petri nets have been successful in modeling concurrent and
classic distributed systems.
In this work we want to use the Petri nets formalism to
specify and manage ad hoc distributed systems.
[Sosa et. al, Ad hoc systems management and speci
fi
cation with distributed Petri nets, JPDC. 2022. https://doi.org/10.1016/j.jpdc.2022.06.015]

3
Ad hoc distributed systems
device1
device2
Local Network

3
Ad hoc distributed systems
device1
device2
Local Network
message

4
Ad hoc ping
ping1
ping2 pong1
pong2

5
Ad hoc ping
ping1
ping2 pong1
pong2

6
How to manage such systems
Manage spontaneous communication between
unknown entities
Assure resilient communication in case of transient
disconnections (resume communication, messages
are not lost)

7
Distributed ad hoc Petri nets (DaPNs)
𝒩
1
𝒩
2
Node Node
(p1, ping)
(p2, pong)
tpong
tping
ℰ = ⟨Pe ∪ P, T, f, fr⟩

7
Distributed ad hoc Petri nets (DaPNs)
Local Network
𝒩
1
𝒩
2
Node Node
(p1, ping)
(p2, pong)
tpong
tping
The connection between nodes (for discovery and communication) is done through serviceNames
remote arcs
ℰ = ⟨Pe ∪ P, T, f, fr⟩

8
Spontaneous communication
Local Network l
𝒩
2
Node
(p2, pong)
tpong
Systems in a local network are discovered and composed by means of
serviceNames connecting a transition of one net to a remote interface of the other.

8
Local Network l
𝒩
1
𝒩
2
Node Node
(p1, ping)
(p2, pong)
tpong
tping
join(N1, l)

8
Local Network l
𝒩
1
𝒩
2
Node Node
(p1, ping)
(p2, pong)
tpong
tping
remote arcs
join(N1, l)
fr : T × serviceNames → Pe ∪ {sentinel}
(tping, pong) ↦ (p, pong)
(tpong, ping) ↦ (p, ping)

8
Local Network l
𝒩
2
Node
(p2, pong)
tpong
join(N1, l)
leave(N1, l)
fr : T × serviceNames → Pe ∪ {sentinel}
(tping, pong) ↦ (p, pong)
(tpong, ping) ↦ (p, ping)

9
Reliable communication
Local Network
𝒩
1
𝒩
2
Node
Node
(p1, ping)
(p2, pong)
tpong
tping remote arcs

9
Local Network
𝒩
1
Node
(p1, ping)
tping

9
Local Network
𝒩
1
Node
(p1, ping)
tping
sentinel

9
Local Network
𝒩
1
Node
(p1, ping)
tping
sentinel
Mailbox

9
Local Network
𝒩
1
𝒩
2
Node
Node
(p1, ping)
(p2, pong)
tpong
tping remote arcs
𝒩
3
Node
(p2, pong)
tpong
Mailbox

10
Evaluation
1. Ensure Petri net behavior
2. Demonstrate the ability to connect to unknown nodes
3. Manage transient disconnections

All experiments are implemented in docker images and
deployed on a kubernetes cluster
11
Evaluation
Implementation in Go, following the definition of the Petri Net
Kernel (PNK) with the addition of Remote arcs and Service Nodes
Node discovery is managed using sleuth (zero congif library)
[Available at: https://github.com/FLAGlab/DistributedPetriNets]
All experiments use 3 physical nodes on a single LAN

12
Vehicular ad hoc networks
Dom
Brian
RSU 1
RSU 2
RSU 3
RSU 4
RSU 5

13
RSU
c
push
V
vsadb
commit
ism
flush
ISM1
flush
ISMm
receive
send
ism
commit
sadb

14
rsu1
rsu2
rsu3
rsu4
rsu5
dom
brian
0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40
Dom’s vehicle Brian’s vehicle

15
0 5 10 15 20 25 30 35 40
rsu1
rsu2
rsu3
rsu4
rsu5
dom
brian
0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40
0 5 10 15 20 25 30 35 40
rsu1
rsu2
rsu3
rsu4
rsu5
dom
brian
0 5 10 15 20 25 30 35 40
rsu1
rsu2
rsu3
rsu4
rsu5
dom
brian
0 5 10 15 20 25 30 35 40
rsu1
rsu2
rsu3
rsu4
rsu5
dom
brian
0 5 10 15 20 25 30 35 40
RSU 5
RSU 1
RSU 4
RSU 2 RSU 3

➡Full formalization of our approach
➡Detailed differentiation of this approach with the
state of the art
➡Full evaluation:
➡3 case studies: (1) Mutex, (2) Disaster and
Crisis Management, (3) VANETs (Vehicular Ad
hoc Networks)
16
In the paper
fi
Mutex Disaster Management VANETs
Petri net behavior
Structural changes
Disconnection handling

➡Evaluate Petri net verification techniques
➡Develop an incremental approach for Petri net verification
techniques as reachability
17
Conclusion and future work
fi

✓Effective formalization to model ad hoc distributed system
✓Manage the run-time execution of Petri nets across different nodes
✓Manage spontaneous communication with previously unknown nodes
in the network
✓Satisfy a node communication that is resilient to transient
disconnections
18
fi

@FLAGlab in all media channels
Ad hoc systems management and
specification with distributed Petri
nets

✓Development and implementation of an adaptive architecture to
address the selected Challenges.
✓The Execution Guidepost provide adaptive connections.
✓Greater inclusion of IoT devices physical properties on devices
description and matching operations.
✓Weight adjustment on the matching algorithm to assign priorities on
system properties, bases on user application.
20
fi
Questions

[JPDC,JCC@LMN22] Ad hoc systems Management and specification with distributed Petri nets

Recommended

Recommended

More Related Content

Similar to [JPDC,JCC@LMN22] Ad hoc systems Management and specification with distributed Petri nets

Similar to [JPDC,JCC@LMN22] Ad hoc systems Management and specification with distributed Petri nets (20)

More from Universidad de los Andes

More from Universidad de los Andes (18)

Recently uploaded

Recently uploaded (20)

[JPDC,JCC@LMN22] Ad hoc systems Management and specification with distributed Petri nets