An IoT Software Architecture for an Evacuable Building Architecture
0 likes222 views
The document discusses an IoT software architecture aimed at improving emergency evacuations in buildings through an optimized network flow algorithm for real-time evacuation handling. It addresses research questions regarding optimal building dimensions for safety and minimizing evacuation time while highlighting the limitations of static evacuation plans. The proposed system focuses on simulations, real-time monitoring, and adapting evacuation strategies based on changing conditions.
![23
Door capacity
Door capacity = how many people «p» may pass
through a door of size «d», every second «s»
Daamen et al. [12] focuses on the relationship
between door capacity, user composition and stress
level
1.03 p/d/s - 3.23 p/d/s (d=1 meter)
resulting from a literature review
In our case, and since t = 5 seconds
pessimistic – optimistic: 5 – 16 pp/d=1/s=5
3
CS: 5 – 16 pp/d=1/s=5](https://image.slidesharecdn.com/hicss2019muccini-190111190056/85/An-IoT-Software-Architecture-for-an-Evacuable-Building-Architecture-23-320.jpg)
An IoT Software Architecture for an Evacuable Building Architecture
- 1. An IoT Software Architecture for an Evacuable Building Architecture Henry Muccini1, Claudio Arbib1, Paul Davidsson2, Mahyar T. Moghaddam1 1 University of L’Aquila 2 Malmo University, Sweden Slides available on my SlideShare account
- 2. Henry Muccini @HICSS 2019 2 The co-authors Software Architecture Operational Research IoT and People IoT architectures for Evacuation Handling
- 3. Henry Muccini @HICSS 2019 3 Context and Research Questions RQ1: Which are the optimal building dimensions/structures for a safe emergency evacuation? RQ2: How to minimize the time to evacuate people in a building? Context: safe emergency evacuation in a closed space
- 4. Henry Muccini @HICSS 2019 4 Context: building safe evacuation
- 5. Henry Muccini @HICSS 2019 5 Context: building safe evacuation
- 6. Henry Muccini @HICSS 2019 6 Context: building safe evacuation
- 7. Henry Muccini @HICSS 2019 7 Limitations of the static emergency evacuation plan possibly leading all pedestrians to the same route and making that area highly crowded; ignoring the individual movement behavior of people and special categories (e.g. elderly, children, disabled); lack of a comprehensive understanding for evacuation manager and operators by a real-time situational awareness ignoring abrupt congestion, obstacles or dangerous routes and areas;
- 8. Henry Muccini @HICSS 2019 8 What if?
- 9. Henry Muccini @HICSS 2019 9 Context: Solution Space Cyber- Physical Spaces IoT Architecture Network Flow Model
- 10. Henry Muccini @HICSS 2019 10 Context: Solution Space Data Network Flow Model
- 11. Henry Muccini @HICSS 2019 11 Goal of this Work Simulations for: Building constraints Bottleneck discovery Comparing routing optimization models Monitoring for: Run-time adaptation of the evacuation plan Discard paths that become unfeasible Integration in mobile applications Design Time evacuability assessment Run-Time evacuation
- 12. Henry Muccini @HICSS 2019 12 Solution for our goals Evacuation Model: We propose a network flow algorithm that is capable to support a precise simulation at design-time and an optimal evacuation handling at real-time. IoT-based System Architecture: We propose an IoT System Architecture to create an infrustructure for run-time monitoring 1 2
- 13. 13 Evacuation Model Network Flow Algorithm
- 14. 14 In brief We propose a network flow algorithm that is capable to support a precise simulation at design- time and an optimal evacuation handling at real-time.
- 15. 15 Network Flow Algoritm We solve a linearized, time-indexed flow problem on a network that represents feasible movements of people at a suitable frequency as a way to minimize the total evacuation time max the number of persons that occupy cell 0 (safe places) at time
- 17. 17 Model Construction The model construction requires to explicitly set a number of parameters: 1. Model granularity 2. Walking Velocity 3. Door capacity 4. Cell capacity
- 18. 18 Model Granularity - basic approach: based on the rooms dimensions 1
- 19. 19 Model Granularity Cell Shape Compatiblility √ Compatiblility X Compatiblility √ Isometry X Isometry √ Isometry √ Rectangular Hexagonal Square
- 20. 20 Model Granularity Cell Size Low resolution High Resolution Larger Error Smaller Error Smaller CPU time Larger CPU time
- 21. 21 Graph Nodes -> cell in the grid (space) Node 0 -> safe area Arcs -> passages between adjacent cells CS:112 nodes and 264 arcs
- 22. 22 Walking Velocity This parameter is important to perceive the distance that an individual can possibly walk during a specific period of time. It can vary for different categories of people, such as child, adult, elderly, disable 2 FW
- 23. 23 Door capacity Door capacity = how many people «p» may pass through a door of size «d», every second «s» Daamen et al. [12] focuses on the relationship between door capacity, user composition and stress level 1.03 p/d/s - 3.23 p/d/s (d=1 meter) resulting from a literature review In our case, and since t = 5 seconds pessimistic – optimistic: 5 – 16 pp/d=1/s=5 3 CS: 5 – 16 pp/d=1/s=5
- 24. 24 Cell capacity According to UK fire safety regulations, the maximum allowed density corresponds 0.3 square meters per standing person, 0.5 s.m. for public houses, (2pp per s.m.) 0.8 s.m. for exhibition spaces, (1.25pp per s.m.) 1.0 s.m. for dining places, (1pp per s.m.) 2.0 s.m. for sport areas, (0.5pp per s.m.) 6 s.m. for office areas (0.2pp per s.m.) 4 CS: 1.25 pp per s.m.
- 25. 25 Risk Consideration Static Risk Such as earthquake: have a momentary impact on building = static change in the graph Dynamic Risk Such as fire that propagates (Future work) 1 2 3 46 5 00
- 26. 26 IoT-based System Architecture IoT infrustructure for run-time monitoring
- 27. Henry Muccini @HICSS 2019 27
- 28. Henry Muccini @HICSS 2019 28 IoT Patterns IoT Components (data producers) IoT Components (data producers) IoT Components (data producers)
- 29. Henry Muccini @HICSS 2019 29 IoT Patterns IoT Components (data producers) IoT Components (data producers) IoT Components (data producers) Data consumer Data consumer Data consumer
- 30. Henry Muccini @HICSS 2019 30 Self-adaptive IoT patterns
- 31. Henry Muccini @HICSS 2019 31 CAPS MDE framework for IoT Patterns Simulation Centralized Master/Slave Collaborative Regional Planning
- 32. 32 Simulation
- 33. Henry Muccini @HICSS 2019 33 Simulation
- 34. 34 CS:112 nodes and 264 arcs Walking Velocity: 1.20 m/s Door Capacity: 5 – 16 pp/d=1/s=5 Cell Capacity: 1.25 pp per s.m. Simulation: N persons, randomly distributed in the building rooms. The code for simulation was written on OPL language and solved on CPLEX version 12.8.0.
- 35. 35 Simulated Cases N=1008 persons Pessimistic case = door capacity: 5pp/d=1/s=5 Our model: 4 min 15’’ (Table) Shortest path: 5 min 35’’ Optimistic case = 16 pp/1/5
- 36. 36Simulation with Risks 2 over 4 emergency exits are blocked Evacuation time: pessimistic: 8 min. 25’’ against 4 min. 15’’ optimistic: 4 min. against 1 min 20’’
- 37. 37 Simulation with different emergency exits width real optimal
- 38. 38 Ongoing and Future Work
- 39. 39 Microscopic Flow Modeling Based on Individuals Movements Reaction time, Grouping, Social Attachment Fire propagation: has a nature of (run-time) arc removal maximize the amount of people in the safe node Optimization/Simulation Approach We implemented our algo into PEDSIM Smart City
- 41. 41 Smart City – Future Work Multiple floors Multiple buildings Different evacuation areas
- 42. 42 Research topic in collaboration with
- 43. An IoT Software Architecture for an Evacuable Building Architecture Henry Muccini1, Claudio Arbib1, Paul Davidsson2, Mahyar T. Moghaddam1 1 University of L’Aquila 2 Malmo University, Sweden Slides available on my SlideShare account