Advancing IoT Architectures Using Collaborative Computing Paradigms

for Dynamic and Scalable Systems

Prashant G Joshi and Bharat M. Deshpande

Department of Computer Science & Information Systems, BITS Pilani, K K Birla Goa Campus, Goa, India

{p20160413, bmd}@goa.bits-pilani.ac.in

Keywords:

Collaborative Computing Paradigms, CCP, IOT System, IOT System Architecture, IOT Reference

Architectures, Distributed Computing, System Software Architecture, Scalable IOT Architectures, Dynamic

IOT Environments.

Abstract:

The Internet of Things (IoT) continues to push the boundaries of traditional system architecture models, neces-

sitating more agile, scalable, and efﬁcient frameworks to handle complex, large, real-time applications. While

conventional architectures, like layered, provide a structured approach, they often suffer from limitations in

adaptability, latency, and dynamic resource utilisation. This paper presents a comprehensive design and im-

plementation a Collaborative Computing Paradigms (CCP)-based IoT Reference Architecture, deﬁned by ﬁve

core attributes: interconnection and interplay across paradigms, dynamic distribution of data processing, com-

puting ﬂuidity enabling seamless transitions across layers, collaborative data storage and management, and

scalability and extensibility of computational resources. To validate the proposed architecture, experiments

were conducted in Data Center Management System, Automotive Telematics, Smart Building (Fire Safety,

Environment) and Asset Tracking (Shipping carts in a mall). Comparative analysis against traditional lay-

ered IoT architectures reveals signiﬁcant improvements in latency reduction, resource utilisation, scalability

under variable workloads, and interoperability between computational layers. The CCP-based architecture

leverages dynamic orchestration of Edge, Fog, and Cloud paradigms, allowing for adaptive load balancing,

real-time analytics, and distributed decision-making, thereby overcoming the rigidity of layered models. The

results highlight the superiority of CCP architectures in enabling low-latency processing, high fault tolerance,

and dynamic resource optimisation in highly ﬂuid and demanding IoT environments. We believe this work

underscores the paradigm shift towards collaborative architectural models, establishing CCP as a benchmark

for next-generation IoT system design, particularly in domains requiring high degrees of responsiveness and

cross-layer integration.

1 INTRODUCTION

The Internet of Things (IoT) has rapidly transformed

how we interact with technology, embedding intelli-

gence into everyday devices, and enabling a seamless

ﬂow of data. From smart homes to industrial automa-

tion, IOT promises to revolutionise our lives by creat-

ing hyper-connected environments (Ericsson, 2024).

However, the success of IoT systems hinges on efﬁ-

cient data processing, communication, extandability

and scalability (Joshi and Deshpande, 2024a).

Collaborative computing paradigm (CCP), as dis-

cussed by the authors (Joshi and Deshpande, 2024a),

has emerged as an advanced solution to bridge the gap

between IoT devices and today’s real-world applica-

tions. Unlike centralised systems, collaborative com-

puting paradigms leverage distributed resources, en-

abling devices to work together, share computational

loads, and make real-time decisions. This approach

has potential to not only optimise the performance,

but also enhance fault tolerance, resource manage-

ment, and energy efﬁciency, all critical for IoT de-

ployment.

In addition to sensing and transmitting data, IoT

systems encompass several other critical features that

are key to enabling real-world applications. Data

processing allows for real-time decision-making by

analysing and extracting actionable insights from vast

streams of information. Storage plays a vital role

in preserving data for future use, support advanced

analytics, and train predictive models. Furthermore,

actuation enables IoT systems to achieve control by

triggering physical actions based on processed data,

such as adjusting a thermostat or activating machin-

Joshi, P. G. and Deshpande, B. M.

Advancing IoT Architectures Using Collaborative Computing Paradigms for Dynamic and Scalable Systems.

DOI: 10.5220/0013388900003896

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 13th International Conference on Model-Based Software and Systems Engineering (MODELSWARD 2025), pages 109-121

ISBN: 978-989-758-729-0; ISSN: 2184-4348

109

ery. These features, when integrated seamlessly, em-

power IoT to deliver intelligent, responsive, and auto-

mated solutions across diverse domains.

We achieve this by designing key components

from Collaborative Computing Paradigms (CCP), us-

ing the CCP-IOT-RA, a reference architecture vali-

dated by (Joshi and Deshpande, 2024b), which aligns

with the speciﬁc requirements of a dynamic IoT en-

vironment. The CCP-IOT-RA is adopted to address

real-world IoT challenges, ensuring its applicability

in diverse scenarios. Furthermore, we build and vali-

date these components through practical implementa-

tion and experimentation, demonstrating their effec-

tiveness in enabling scalable and efﬁcient IoT solu-

tions. We believe that, this structured approach, en-

sures that the proposed paradigms are not only the-

oretically sound but also practically viable for real-

world applications.

In this paper, we explore collaborative computing

paradigms, tailored for the IoT, and their role in build-

ing scalable, robust, and real-world applications. By

addressing both the technical and practical aspects,

this paper aims to provide a comprehensive frame-

work for future IoT development through collabora-

tive computing.

This paper is organised as follows. Section 2 pro-

vides a brief summary of the CCP and CCP-IOT-RA.

Section 3 provides the details of the methodology de-

veloped and used for overall experiment design and

processes. Section 4, we provide the details of the

design, and implementation of the CCP based IOT,

detailing the devices and nodes, and their functional-

ity. Section 5 describes in brief the experiments con-

ducted, and their results. We summarise the lessons

learned in Section 6. Section 7 provides a conclusion,

and Section 8 closes with the future work.

2 CCP BASED IOT

ARCHITECTURE: A

SUMMARY

As discussed by the authors (Joshi and Deshpande,

2024a), CCP with its ﬁve characteristics is used to

build a RA which is detailed in (Joshi and Deshpande,

2024b). The CCP employs a three-pronged approach:

• Build an architecture of infrastructure which can

enables and creates opportunities for dynamism,

and expansion of services

• Build the system using well-established standards

to enable ease of operation, and interoperability

• Build using such an infrastructure software sys-

tem, that brings functional dynamism

A typical system architecture, of the CCP (CCP-

IOT-RA), is depicted in Figure 1.

Participating

Mobile Nodes

Participating

Mobile Nodes

Other Systems

Cloud Computing

Remote Mobile

Access

Monitoring

System

Mobile Node

Participating

]Edge Nodes

Participating

Edge Node

IOT Devices / Edge Devices . Mist Nodes

To Internet

Participating

Fog Nodes

Participating

Fog Nodes

CCP-IOT-RA Topology of Interconnectivity

Traditional/Layered IOT Architecture

Figure 1: Collaborative Computing Paradigms (CCP-IOT-

RA) - Systems Architecture.

The characteristics of the Collaborative comput-

ing paradigms software system architecture are de-

tailed in TABLE 1.

By establishing a collaborative systems architec-

ture, the software can leverage available computing

paradigms depending on the level of dynamism it can

accommodate, such as in distributing tasks across dif-

ferent paradigms.

3 METHODOLOGY FOR DESIGN

& IMPLEMENTATION

Adoption of Reference

Architecture CCP-IOT-RA

Indentification of System

Level Use cases

Selection of Smart Devices &

Nodes

Implementation & Validation

1 2

Figure 2: Methodology and Steps for Design and Imple-

mentation.

The implementation of a tailored reference archi-

tecture, for IoT systems, involves several structured

phases to ensure robustness, scalability, and relevance

to critical applications. This section outlines the

systematic approach for tailoring the CCP-IOT-RA

framework, identifying relevant use cases, and vali-

dating the proposed architecture. The process steps

are depicted in Figure 2.

Our prime reference for the architecture is the

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

110

Table 1: Collaborative Computing Paradigms- Software Systems Architecture Characteristics (Joshi and Deshpande, 2024a).

No. Characteristic Description and details

1 Inter-connection and

interplay

Overcome the limitations imposed by layered approach by interconnection and

interplay between smart devices, and various computing paradigms.

2 Dynamic distribution

of data processing

Dynamic distribution, free from strict layering and predeﬁned computing allo-

cation, enhances ﬂexibility, efﬁciency, and overall computing capacity

3 Fluidity of comput-

ing across paradigms

Task allocation is dynamic, determined by the paradigm’s suitability, contex-

tual requirements, and available resources.

4 Storage and data

management

across participat-

ing paradigms

All participating paradigms will require the necessary data for processing and

thus, the data will be distributed across paradigms. This data, both input data

and processed data, will need to be collected and transmitted to a single store

of data, typically cloud storage.

5 Scalability and ex-

tendability of the ar-

chitecture

It supports the integration of newer devices seamlessly, allowing the architec-

ture to accommodate additional components to monitor subsystems, analyse

data, and ensure the scalability and reliability of the overall system.

(H. Washizaki, 2024)

In this section we detail the process steps and the

high level topics in each of the process steps for a

successful implementation of the IOT system using

the CCP.

3.1 Adoption of the Reference

Architecture CCP-IOT-RA

The CCP-IOT-RA serves as a foundational frame-

work for IoT systems, offering modularity, interop-

erability, and scalability. To meet the speciﬁc require-

ments of the targeted application, the following cus-

tomisations are considered:

• Component Selection: Key components such as

sensors, smart devices, nodes - edge, fog and

cloud, communication protocols, data processing

and storage nodes, and security modules are se-

lected and tailored to match the application con-

text.

• Adaptation to Use Cases: System-level use

cases, such as sensing, transmission, processing,

actuation and applications are created to ensure

seamless integration with critical functionalities.

• Scalability Considerations: The architecture is

designed to accommodate increasing the device

connections, high intervals of data transmission,

data volume, and computational demands without

compromising performance.

• Integration of Advanced Features: Smart com-

puting capabilities, edge processing, and adaptive

data storage mechanisms are integrated into the

architecture.

3.2 Identiﬁcation of System Level Use

Cases

Among the identiﬁed use cases, critical ones are

prioritised based on the need for robust computing

power, data processing, storage capabilities, and scal-

ability. The selection criteria include:

• Computing Requirements: Applications that

demand extensive edge or cloud-based computa-

tion, such as real-time decision-making systems

in smart cities.

• Data Processing Needs: Systems requiring

efﬁcient data preprocessing, such as machine

learning-based anomaly detection in industrial

IoT.

• Data Storage Demands: Applications requiring

long-term storage and retrieval of large datasets,

such as environmental monitoring logs in agricul-

ture.

• Scalability: Use cases that require seamless scal-

ing of resources, such as growing smart grid net-

works or expanding patient monitoring systems.

3.3 Selection of Smart Devices & Nodes

To achieve the functional goals of the architecture, ap-

propriate IoT devices and nodes are identiﬁed based

on the requirements of the critical use cases:

• Sensors and Actuators: Devices such as tem-

perature, humidity, motion sensors, and actuators,

such as relays, for physical control in industrial

and healthcare environments.

• Edge Devices: Microcontrollers (e.g., Raspberry

Pi, ESP32 SoC), and edge computing nodes for

local processing and data ﬁltering.

Advancing IoT Architectures Using Collaborative Computing Paradigms for Dynamic and Scalable Systems

111

• Communication Nodes: Protocols such as

MQTT, CoAP, and WiFi for efﬁcient communi-

cation between IoT devices and central systems.

• Storage Systems: Cloud-based platforms and

distributed data stores for data persistence and re-

trieval.

• Device and Node Selection: It ensures compati-

bility with the customised CCP-IOT-RA and pro-

vides optimal resource utilisation.

3.4 Implementation & Validation

This phase involves implementing the tailored archi-

tecture and validating its performance against critical

use cases. The following steps are performed:

• System Deployment: The selected devices and

nodes are integrated into the CCP-IOT-RA frame-

work. Use cases are implemented in real or simu-

lated environments.

• Performance Metrics Evaluation: Key perfor-

mance indicators (KPIs), such as latency, through-

put, computational efﬁciency, and energy con-

sumption, are measured.

• Scalability Testing: Tests are conducted to assess

system performance under increasing workloads,

and number of device connections.

• Data Validation and Accuracy: Data is collected

from sensors and processed by nodes are validated

for accuracy and reliability.

• Use Case Validation: Critical use cases, such

as industrial monitoring and smart healthcare sys-

tems, are evaluated for their ability to meet func-

tional requirements.

4 DESIGN & IMPLEMENTATION

OF CCP BASED IoT

In this section, we provide the components, subsys-

tems, and systems built for the experiments to validate

the CCP. The reference architecture based on (Joshi

and Deshpande, 2024b), for the system, is shown in

Figure 1. To ensure we are able to validate the archi-

tecture using various applications, we need to build

some of the smart devices and computing nodes. Each

device or node are made of the characteristic hard-

ware and software to participate in the IoT solution.

We refer to (Espressif, 2024), (Sensortec, 2024)

and (Pi, 2024) for the details on SoCs and sensors

used for our experiments. These components were

built using the process steps and methodology, from

3 as a guideline and those from (Bass et al., 2012)

(H. Washizaki, 2024)

4.1 Sensor Nodes: Smart Devices

Each of the device, sensor and smart, is characterised

speciﬁcally based on their capabilities. In the con-

text, sensor device maybe capable of sensing and digi-

tisation or sensing, digitisation and transmission to

the smart device. A smart device is capable of com-

mon features - OLED Display over I2C for a readout,

WiFi for connecting to internet or private network,

and Bluetooth for peer-to-peer communication, and

certain quantity of Local Storage. All the smart de-

vices, and nodes are summarised in Table 2.

4.1.1 Smart Device: Environment Sensor (T10i)

Our smart device employs the ESP32-WROVER-E

System-on-Chip (SoC) as its core processing unit.

The ESP32 is interfaced with the BME680 sensor

via an I2C communication bus. Developed by Bosch

Sensortec, the BME680—recently succeeded by the

BME690—is a multi-functional sensor capable of

measuring gas, pressure, temperature, and humidity,

making it ideal for environmental monitoring. In ad-

dition, the device supports seamless connectivity with

nodes over both WiFi and Bluetooth, enable robust

and ﬂexible communication within IoT networks.

4.1.2 Smart Device: Telematics CAN-OBD

(TX1)

This device integrates an ESP32-WROVER-

E System-on-Chip (SoC) paired with a CAN

transceiver, allowing it to interface with a vehicle’s

CAN network via the On-Board Diagnostics (OBD)

port. This enables the device to access and monitor

vehicular data for various automotive applications.

To further enhance its capabilities, a GPS receiver

is incorporated into the design, providing precise

location tracking. The system supports connectivity

over both WiFi and Bluetooth, enabling communica-

tion with other nodes, and facilitating real-time data

transmission and analysis.

4.1.3 Smart Device: Temperature Sensor (T10)

The device leverages the ESP32-WROVER-E SoC,

a versatile and efﬁcient microcontroller, as its main

platform. Integrated with a DS1820 temperature sen-

sor over a single wire interface, the system is designed

to monitor multiple environmental DS1820 sensors,

connected via the digital IOs of ESP32. Moreover, the

ESP32’s built-in capabilities allow it, along with local

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

112

Table 2: Summary of Smart Devices and Nodes.

No Device or Node Description and details Storage WiFi Bluetooth

1 Smart Device - Environ-

ment Sensor (T10i)

Sensor: BME680/BME690 (Temperature, Hu-

midity, Pressure, Air Quality)

Yes Yes Yes

2 Smart Device - Telemat-

ics CAN-OBD (T10X1)

Sensor: CAN/CAN-FD Transceiver (CAN

Protocol), GPS (Location)

Yes Yes Yes

3 Smart Device - Temper-

ature sensor (T10)

Sensor: DS1820 (Single wire semiconductor

temperature sensor).

Yes Yes Yes

4 Smart Device - Electrical

Energy Metering (T10E)

Interface: RS485 MODBUS for connecting

with a smart electrical energy meter

Yes Yes Yes

5 Edge Gateway - ESP32

(N32)

Multi-interface Edge Gateway Yes Yes Yes

6 Edge Gateway - Rasp-

berry Pi (NPi)

Multi-interface Edge Gateway Yes Yes Yes

7 Fog Node - Dell Mini PC

(NmPC)

Multi-interface Fog Node with medium com-

puting and storage

Yes Yes Yes

storage, to connect effortlessly to other devices or net-

works via WiFi and Bluetooth, ensuring efﬁcient data

transmission and enabling interoperability within IoT

ecosystems.

4.1.4 Smart Device: Electrical Energy Metering

(T10E)

The device incorporates the ESP32-WROVER-

E System-on-Chip (SoC) alongside an RS485

transceiver, enabling communication over the RS485

interface using the MODBUS protocol. This setup

facilitates seamless integration with smart energy

meters for efﬁcient data exchange and monitoring.

Leveraging the ESP32’s advanced capabilities, the

system also supports wireless connectivity via WiFi

and Bluetooth, ensuring compatibility with other net-

work nodes for ﬂexible and scalable deployment.

4.2 Node: Edge Computing

4.2.1 Edge Gateway: Raspberry Pi (NPi)

An edge computing node is developed using a Rasp-

berry Pi, which serves as a central communication

hub for smart devices. Functioning as an Access Point

(AP), the Raspberry Pi enables devices to connect via

WiFi for data exchange and coordination. Each fog

node is equipped with internet connectivity, and sup-

ports communication protocols such as MQTT and

HTTP (RESTful web services), allowing seamless

interaction with smart devices and other computing

nodes across both intranet and internet networks.

4.2.2 Edge Gateway: ESP32 (N32)

An edge computing node is developed using an

ESP32, which serves as a central hub for commu-

nication with smart devices. The ESP32 node oper-

ates as an Access Point (AP), enabling smart devices

to connect seamlessly over WiFi for data exchange

and coordination. Each fog node is connected to the

internet and supports communication protocols such

as MQTT and HTTP (RESTful web services), allow-

ing smooth interaction with smart devices and other

computing nodes across both intranet and internet net-

works. Additionally, the device is equipped with two

analog inputs, four digital inputs, two output relays,

and an RS485 transceiver, further expanding its ca-

pabilities for interfacing with sensors, actuators, and

other industrial systems.

4.3 Node: Fog Computing (NmPC)

A fog computing node is implemented using a Dell

Mini PC. This node acts as an intermediary between

edge nodes and smart devices, and other fog nodes,

facilitating seamless communication over WiFi net-

works. Whether connected through an intranet or the

internet, the fog node ensures efﬁcient data transmis-

sion, processing, storage and coordination, enabling

robust interactions across the IoT ecosystem.

4.4 Node: Cloud Computing

In the experimental setup, server instances are de-

ployed on SSD Nodes, which are standard Linux

Ubuntu Servers. These instances support communi-

cation via MQTT and HTTP (RESTful web services)

over the internet, enabling reliable and efﬁcient data

Advancing IoT Architectures Using Collaborative Computing Paradigms for Dynamic and Scalable Systems

113

and message transfer. To handle multiple server in-

stances and distribute workloads efﬁciently, a load

balancer is implemented using NGINX, ensuring op-

timal resource utilisation and system performance.

4.5 Node: Mobile Computing

Smartphones and laptops serve as versatile computing

devices within the system. A smartphone equipped

with the Android operating system and a custom-

designed application, using standard interfaces, en-

ables mobile computing with extensive connectivity

options. The application facilitates communication

over WiFi, 3G, or 4G networks, as well as Bluetooth,

ensuring seamless data exchange between nodes and

devices. With ample memory for data storage, suf-

ﬁcient computational power, and a built-in GPS sen-

sor, the smartphone provides real-time location data

and acts as a dynamic node within the IoT ecosys-

tem. Similarly, laptops equipped with required appli-

cations enhance connectivity and computational capa-

bilities, serving as central hubs for data monitoring,

analysis, and control.

4.6 Features of Computing Nodes

4.6.1 Software Platform for Data Collection,

Communication, and Storage

All computing nodes are equipped with a software

stack that includes Apache Spring Boot (for Web Ser-

vices APIs), MySQL Database, Mosquitto MQTT

broker, Eclipse Paho MQTT Client Library, and

Apache Tomcat. Each node runs a scaled-down ver-

sion of the software, tailored to its computing capac-

ity, storage space, and memory available for data pro-

cessing.

4.6.2 Push and Pull Mechanism

All computing nodes utilise a pull mechanism through

request-response over MQTT or HTTP. Additionally,

each node has the capability to push messages via

MQTT or Web Sockets.

4.6.3 Device Management

For the purpose of device and nodes Onboarding

(bootstrapping) and Deboarding (unbootstrapping)

the cloud maintains a registry of all devices and

nodes, while each node must be provisioned with the

devices or nodes it connects to, establishing a topol-

ogy and trust among all participants.

4.6.4 Requests and Responses

All requests and responses use standard JSON for-

mats. Each request or response, whether pull or

push, is structured with the following elements: de-

vice identiﬁer, action to be performed, source of the

request, expected destination of the response, appro-

priate timestamp, and the payload.

5 EXPERIMENTS FOR

APPLICATION DOMAINS

This section describes and provides details of the ex-

periments performed, to evaluate the CCP, to apply

the CCP in four applications. These are,

• Multi-location Data Center Cooling Management

System

• Automotive Telematics - Driver & Vehicle Be-

haviour

• Smart Building - Environment, Fire Safety, Elec-

trical Energy

• Asset Tracking - Track carts at shopping malls

Each application encompasses multiple use cases

for measurement, monitoring, and control. As we im-

plement IoT using CCP in these systems, we evalu-

ate CCP against the required use cases: (a) Notiﬁ-

cations for events (e.g., smoke, ﬁre, asset loss, over-

speeding), (b) Data collection for predictive health

monitoring (e.g., cooling system optimisation, mon-

itor driver behavior), and (c) Scalability and Extend-

ability, dynamic addition of devices or conﬁgurations

(e.g., adding smoke detectors or extinguishers to a

building, or air quality monitors in a vehicle cabin).

Our validation criteria is as follows:

• VQ1: Scalability of the system due to CCP: How

scalable is the IOT system with CCP?

• VQ2: Consistent functioning of the Use Case:

How reliably does the system perform the use

case?

• VQ3: Unique advantage of CCP: What advantage

does CPP provide for the IOT system?

All applications are built using the devices de-

scribed in Section 4

5.1 Multi-Location Data Center

Management System

5.1.1 Introduction

Data centers must maintain a speciﬁc temperature to

ensure the optimal functioning of servers and other

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

114

Cloud Server

Remote Access

Monitoring System

Gateway

(DC1)

Temperature

Other Systems

Electricity

Meter

Gateway

(DC2)

Temperature

Electricity

Meter

Location A

Location B

CCP-IOT-RA Topology of Interconnectivity

Traditional/Layered IOT Architecture

Internet

Figure 3: Multi-location Data Center Management System.

network equipment. In a typical setup, servers and

equipment are installed in racks, and data centers con-

tain multiple server or equipment racks. Tempera-

ture control within the acceptable range (typically 22

to 25°C) is achieved using air conditioners (ACs).

The primary goal is to provide efﬁcient cooling while

minimising electricity consumption. To achieve this,

temperature and electricity consumption are regularly

monitored. Authors have described the use cases in

detail in (Joshi and Deshpande, 2024a)

5.1.2 Experimental Set-Up

The architectural set-up of the system is shown in Fig-

ure 3. The set-up is such that the conﬁguration can

be updated to run the experiment in traditional IOT

(Layered) architecture and in an IOT with CCP. A T10

and an N32 is used in the set-up along with the cloud

server.

5.1.3 AC with IoT (Traditional Layered

Approach)

As described by the authors in (Kaushik and Naik,

2023), the data for temperature and electricity con-

sumption is collected periodically. This data is trans-

mitted to the cloud server over the wired or wireless

network interface. At the cloud node the data is pre-

processed, and stored in the database. The data is also

analysed, and based on the model of operation, com-

mands are sent to the smart device to operate the AC

system. Thus, switching based on a cooling model en-

sures optimal AC usage and electricity consumption.

During regular operations, the AC system is con-

tinuously monitored, and any fault codes are reported

to the server. On occurrence of a fault, notiﬁcation(s)

are sent to the operator by the cloud server. Notiﬁca-

tions are sent on email and/or web sockets.

Commands from the cloud must always be trans-

mitted to the device for switching operations. Thus,

in case of connectivity issues with the cloud, the com-

mands were not received and the operation was af-

fected.

5.1.4 AC with IoT with CCP

Now, we conﬁgure the system to include a smart gate-

way, capable of autonomous operation between the

smart sensor and cloud. While the computation of

the model for cooling continues to be computed on

the cloud, the switching schedule was transmitted to

the gateway which continued the operation using the

switching times which were provided by the cloud

server. Till the time that the cooling model does not

change the entire switching operation was performed

automatically by the smart gateway. Thus, there is

an evident reduction on the computing resources of

the cloud server. Further, smart gateway and cloud

server establish an interplay; wherein any increase in

the number of sensors or smart devices was handled

by the gateway. Data so sent to the server included

the new set of sensor devices. A mobile phone, with

an app, was used to remotely monitor the system and

receive alerts. With the smart sensor, even in event of

gateway downtime, it is connected with the server and

operation continued without any interruptions.

Thus, in conclusion the Multi-location Data Cen-

ter Management System, was equipped to perform

better, scalable and reliable even in anomalies of dis-

connected. System performed better with CCP IOT

than with only IOT with cloud. The comparison is

depicted in Table 3.

5.1.5 Conclusion

Based on the validation criteria, the assessment is:

• VQ1: Addition of multiple sensors or locations

is handled by the CCP with the capacity shared

between edge gateway and the cloud.

• VQ2: With the edge gateway, operations continue

seamlessly without cloud connectivity, function-

ing autonomously until switching times require

adjustment.

• VQ3: In the event of connectivity loss, the edge

gateway continues to operate. If the edge gate-

way fails or experiences connectivity issues, the

smart device connects directly to the cloud and

sends failure notiﬁcations to the intended user via

MQTT channels.

Advancing IoT Architectures Using Collaborative Computing Paradigms for Dynamic and Scalable Systems

115

Table 3: Multi-Location Data Centers - IOT (Layered), IOT with CCP.

Design of cool-

ing system

Temperature Control Electricity Optimisa-

tion

Scalability

Without IoT YES. Completely

Localised

None None

IoT (Layered) YES. Cloud Con-

trolled

YES. Cloud Controlled YES. Need more capacity on the cloud

with increase in locations. Mobile node

only for remote monitoring.

IoT CCP YES. Edge Gate-

way/Cloud Participa-

tion

YES. Edge/Cloud Par-

ticipation

YES. Not all times Cloud Resources re-

quired as Edge Gateway takes the pro-

cessing load. Mobile node participated

for conﬁguration changes.

5.2 Automotive Telematics: Vehicle &

Driver Behaviour

5.2.1 Vehicle and Driver Behaviour

Cloud Server

Remote Access

Monitoring System

Gateway

(VG1)

OBD-CAN + GPS

Other Systems

Driver Cabin

Air Quality

Gateway

(VG22)

OBD-CAN + GPS

Driver Cabin

Air Quality

Vehicle B

Vehicle A

Figure 4: Automotive Telematics - CAN OBD.

5.2.2 Introduction

To enhance the safety of vehicles and drivers on the

road, numerous IoT-based solutions have been imple-

mented, utilising data collected from the On-Board

Diagnostics (OBD) port. Key vehicle parameters such

as speed, engine RPM, odometer readings, coolant

temperature, fuel level, fuel consumption, and gear

position are frequently gathered from the Electronic

Control Units (ECU) for driver and vehicle behavior

analysis. OBD fault codes offer additional insights

into potential service or maintenance needs for the ve-

hicle. Data is also collected from other sensors and

smart devices, such as GPS and cabin environment,

which provide critical information about the vehicle’s

location and driver’s cabin environment. Using the

data, additional attributes like hard braking, acceler-

ation, deceleration, and compliance with speed limits

can be calculated, offer valuable feedback to drivers.

Fault codes and engine data further assists in assess-

ing the vehicle’s operational condition and overall ﬁt-

ness. Additionally, the collected data can be pro-

cessed for predictive analytics to support preventive

maintenance strategies. We refer to the work done by

the authors in (Malekian and et al., 2015) (T

urker and

et al, 2016).

5.2.3 Experimental Set-Up

The architectural set-up of the system is shown in Fig-

ure 4. The set-up is such that the conﬁguration can be

updated to run the experiment in traditional IOT (Lay-

ered) architecture and in an IOT with CCP. A TX1

along with a N32 is used in the set-up with the cloud

servers. An App, capable of connecting to the cloud

server and also the smart device was used in the set-

up.

5.2.4 Vehicle OBD with IoT (Traditional IoT

and a Layered Approach)

Data fusion combines data from the CAN OBD, and

GPS devices to capture vehicle parameters. This data

is transmitted to the cloud for processing, where alerts

for over-speeding, hard-braking, driver behavior, or

vehicle faults are generated and sent to the driver’s

mobile device.

Since all processing occurs on the server, vehi-

cle and driver behavior data must be computed in the

cloud, leading to continuous use of server resources

with no possibility of ofﬂoading.

5.2.5 Vehicle OBD with IoT with CCP

In the set-up a smart device, a mobile app and a gate-

way when operational provided capacity for comput-

ing at the edge. Over-speeding, hard-braking data was

computed on the mobile phone connected to the smart

CAN-OBD device with alerts to the driver in real-

time.

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

116

Thus, with ofﬂoading of this computing the ca-

pacity and dependency on the cloud was removed.

Local capacity to compute and collect data increased.

When the cabin environment monitor was added, the

same was seamlessly connected at the gateway. Thus,

in this case, Mobile Computing, Fog Computing and

Cloud computing were the paradigms participating in

the overall application.

Data collected from all sources by all computing

paradigms was ultimately sent to the cloud, where it

was collected, processed and stored for future use, in-

sights and analysis.

Thus, in conclusion the Automotive Telematics -

Vehicle & Driver Behaviour, was equipped to perform

better, scalable and reliable even in anomalies of dis-

connected. System performed better with CCP IOT

than with only IOT with cloud. The comparison is

depicted in Table 4.

5.2.6 Conclusion

Based on the validation criteria, the assessment is:

• VQ1: Addition of sensor devices can be handled

by the CCP with the capacity shared between mo-

bile phone, edge gateway and the cloud.

• VQ2: With the presence of the edge gateway and

mobile app, the operation continues even in ab-

sence of the connectivity to the cloud. Till such

a point that analytics are indeed required from the

cloud, the functioning can continue autonomously

at the edge using gateway and mobile phone.

• VQ3: In event of a connectivity loss, the edge

gateway and mobile app continues to operate.

With the smart device and mobile app connectiv-

ity to the internet and hence the cloud, the overall

communication of events and data is possible.

5.3 Smart Building: Environment, Fire

Safety, Electrical Energy

5.3.1 Introduction

IoT based solutions for smart buildings enable efﬁ-

cient monitoring and management of critical systems

such as electricity consumption, ﬁre safety equip-

ment, and air quality. Smart sensors installed across

the building track electricity usage in real time, iden-

tifying energy-intensive areas and providing insights

to optimize consumption. Automated systems can

adjust lighting, HVAC, and other electrical equip-

ment based on occupancy or pre-set schedules, re-

ducing energy waste. IoT-enabled smoke detectors

continuously monitor for ﬁre hazards and send in-

stant alerts to building management or emergency

Cloud Server

Remote Access

Monitoring System

Gateway

(Edge)

T/P/H/AQI

Other Systems

Smoke

Detectors

Floor 2

Electricity

Meters

Gateway

(Edge)

T/P/H/AQI

Smoke

Detectors

Floor 1

Electricity

Meters

Internet

Figure 5: Smart Building - Env., Fire Safety, Elect. Energy.

services in case of anomalies. These devices can

also perform self-diagnostics to ensure they are op-

erational, improving ﬁre safety reliability. Air quality

sensors measure parameters like CO

levels, humid-

ity, temperature, and the presence of pollutants, en-

suring a healthy indoor environment. Data collected

from these sensors can trigger ventilation systems to

maintain optimal air quality. Centralised dashboards

display real-time data, enabling facility managers to

make informed decisions and respond promptly to is-

sues. Predictive analytics, powered by IoT, can iden-

tify patterns helping with preventive maintenance of

equipment and avoiding costly failures. Overall, IoT

enhances energy efﬁciency, safety, and comfort in

smart buildings, creating a sustainable and secure en-

vironment for occupants.

5.3.2 Experimental Set-Up

The architectural set-up of the system is shown in Fig-

ure 5. The set-up is such that the conﬁguration can be

updated to run the experiment in traditional IOT (Lay-

ered) architecture and in an IOT with CCP. A T10i,

T10E and T10 (simulates the smoke detector) along

with a N32 is used in the set-up with the cloud servers.

An App, capable of connecting to the cloud server and

also the smart device was used in the set-up.

5.3.3 Smart Building with IoT (Traditional IoT

and a Layered Approach)

In the traditional set-up, all the sensors were send-

ing the data to the cloud, we had, per ﬂoor, tempera-

ture, pressure, humidity, air-quality, smoke sensor and

electricity consumption sent to the cloud. At all times,

the data was compared with the parameter thresholds

and the commands were issued to control example:

Advancing IoT Architectures Using Collaborative Computing Paradigms for Dynamic and Scalable Systems

117

Table 4: Automotive Telematics (Fleet Management) - IOT (Layered), IOT with CCP.

Design of Vehi-

cle/Fleet Mgmt.

Vehicle Behaviour Driver Behaviour Scalability

Without IoT YES. Completely

Localised

Yes. Completely Lo-

calised

None

IoT (Layered) YES. Cloud Con-

trolled

YES. Cloud Con-

trolled

YES. Need more capacity on the

cloud with increase in locations.

IoT CCP YES. Edge Gate-

way/Cloud Participa-

tion

YES. Edge/Cloud

Participation

YES. Not all times Cloud Re-

sources required as Edge Gateway

takes the processing load.

ON/OFF for HVAC were send by the cloud. Compu-

tation of the received data and control based on the

processing of the data was done at the cloud.

Addition of devices to simulate ﬂoors or addi-

tional equipment added the computing load on the

server. Since the processing was done only at the

server end, all the processing was to be computed on

the cloud. Thus, the server computing power is used

continuously with no ofﬂoading possibility.

5.3.4 Smart Building with IoT with CCP

In the set-up a smart device, a mobile app, and a gate-

way, when operational, provided capacity for com-

puting at the edge. Sensing and control based on

ON/OFF for temperature were done autonomously by

the gateway. The gateway continuously transmitted

data to the cloud, where the air quality or temperature

model was computed on the cloud server.

Ofﬂoading operations to the gateway reduced the

cloud server’s load and eliminated dependency on the

cloud. A mobile app was used for conﬁguration,

veriﬁcation, and updates. Field data was observed

and correlated by facility management with server-

analysed data. All smart devices, equipped with in-

ternet connectivity, could send notiﬁcations and mes-

sages about anomalies if links to the gateway or server

were disrupted. For example, a smart smoke detector

could directly notify the facility manager.

It is clear, from the experiment, that the cloud,

edge and mobile computing in a collaborative man-

ner, can be very effective and efﬁcient. System per-

formed better with CCP IOT than with only IOT with

cloud. The comparison is depicted in Table 5.

5.3.5 Conclusion

Based on the validation criteria, the assessment is as

follows:

• VQ1: With CCP addition of sensor devices can be

handled effectively by sharing the capacity across

mobile phone, edge gateway and the cloud.

• VQ2: With the edge gateway and mobile app,

operations continue even without cloud connec-

tivity. The system can function autonomously at

the edge using the gateway and mobile phone un-

til cloud-based analytics are needed. The mobile

platform offers portability and real-time insights

in the ﬁeld.

• VQ3: In event of a connectivity loss, the edge

gateway and mobile app continues to operate.

With the smart device and mobile app connectiv-

ity to the internet and hence the cloud, the overall

communication of events and data is possible.

5.4 Asset Tracking: Track Carts at

Multiple Shopping Malls

Mobile Nodes

Cloud Computing

Remote Access

Monitoring System

Edge Node

CCP-IOT-RA Topology of Interconnectivity

Traditional/Layered IOT Architecture

Mobile Nodes

Location A

Carts

Location B

Carts

Other Systems

Edge Node

Figure 6: Asset Tracking System - Carts at mall(s).

5.4.1 Introduction

An asset tracking system, for carts at malls, utilises

IoT devices with GPS to efﬁciently monitor and man-

age cart movement. Real-time data, and alerts en-

able staff to retrieve carts promptly, improving opera-

tional efﬁciency. Usage patterns are analyzed to iden-

tify high-demand areas, and optimize cart distribu-

tion. Maintenance alerts ensure carts remain in good

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

118

Table 5: Smart Building - IOT (Layered), IOT with CCP.

Design of BMS Air Quality Electricity Fire Safety Scalability

Without IoT YES. Fully lo-

calised

YES. Fully lo-

calised

YES. Fully lo-

calised

None

IoT (Layered) YES. Cloud

based

YES. Cloud based YES. Cloud based YES. Need more capac-

ity on the cloud with in-

crease in locations.

IoT CCP YES. Edge Gate-

way/Cloud/Mobile

Participation

YES.

Edge/Cloud/Mobile

Participation

YES. Edge Gate-

way/Cloud/Mobile

Participation

YES. Cloud resources

are not always required,

as the Edge Gateway

handles the processing

load.

Table 6: Asset Tracking (Carts in malls) - IOT (Layered), IOT with CCP.

Design of Cart Monitor Cart Tracker Scalability

Without IoT YES. Totally Lo-

calised

None

IoT Only YES. Cloud based YES. Increased locations require additional cloud capacity.

IoT CCP YES. Edge Gate-

way/Cloud/Mobile

Participation

YES. Cloud resources are not always required, as the Edge

Gateway handles the processing load.

condition, while a centralised dashboard allows seam-

less oversight of cart availability and performance.

5.4.2 Experimental Set-Up

The architectural set-up of the system is shown in Fig-

ure 6. The set-up is such that the conﬁguration can be

updated to run the experiment in traditional IOT (Lay-

ered) architecture, and in an IOT with CCP. A TX1

(CAN-OBD) is repurposed to track only the location

with a fog node NmPC and a cloud server was used

in the set-up.

5.4.3 Asset Tracking with IoT (Traditional IoT

and a Layered Approach)

Fusion of beacon/ping of presence, and location in-

formation by GPS is done per cart. This data is then

transmitted to the cloud for further processing. All

alerts for number of carts at a location are generated

by the cloud and then sent to the mobile app of the

facility staff.

Since processing was done solely on the server,

all cart data computations occurred in the cloud, re-

sulting in continuous server resource usage with no

option for ofﬂoading.

5.4.4 Asset Tracking with IoT with CCP

In the setup, a smart device, mobile app, and gateway,

enabled edge computing. Beacon/pings and GPS lo-

cation data were processed on the mobile phone con-

nected to the smart device, providing real-time alerts

to facility staff. This ofﬂoaded computing from the

cloud, reducing dependency and increasing local ca-

pacity. An environment monitor was added. It seam-

lessly connected to the gateway, integrating Mobile

Computing, Edge Computing, and Cloud Computing

into the application. Data from all sources was ulti-

mately transmitted to the cloud for storage and analy-

sis, offering insights into cart usage by location.

In conclusion, the Asset Tracking system for

shopping mall carts became more reliable even during

disconnections. The CCP IOT performed better than

traditional IoT with cloud-only reliance, as shown in

Table 6.

5.4.5 Conclusion

In conclusion,

• VQ1: The CCP efﬁciently manages the addition

of sensor devices by distributing capacity across

the mobile phone, edge gateway, and cloud.

• VQ2: The edge gateway and mobile app ensure

uninterrupted operation, even without cloud con-

nectivity, while mobile platforms offer portability

and real-time insights.

• VQ3: In case of connectivity loss, the edge gate-

way and mobile app maintain functionality, and

upon internet restoration, smart devices facilitate

data and event communication with the cloud.

Advancing IoT Architectures Using Collaborative Computing Paradigms for Dynamic and Scalable Systems

119

6 LESSONS LEARNED

The design and experimentation with the CCP-based

IoT RA have yielded valuable insights into the archi-

tectural requirements of dynamic IoT environments:

• Computation as the Core of Architecture: A

key takeaway is the importance of placing com-

putation at the core of IoT architectural de-

sign. Designing with computational efﬁciency

and adaptability in mind ensures that system com-

ponents are aligned to perform optimally under

varying workloads. The Collaborative Comput-

ing Paradigms (CCP)-based architecture demon-

strated that organising computational tasks across

Edge, Fog, and Cloud is critical for meeting the

demands of modern IoT systems. This includes

enabling real-time processing, adaptive workload

distribution, and dynamic resource allocation. Fu-

ture IoT architectures must be conceived with

computation as the organising principle, driving

decisions around hardware selection, data ﬂow

management, and system scalability.

• Use Cases as the Driving Force Behind Archi-

tectural Design: Another critical insight is the

centrality of use cases in guiding architectural de-

cisions. The experiments highlighted that design-

ing IoT systems with speciﬁc ”vertical” applica-

tions—such as building automation, telematics, or

ﬁre safety—at the forefront ensures that the archi-

tecture aligns with the functional and performance

requirements of real-world scenarios. Starting

with the use cases ensures the selection of appro-

priate components, computing paradigms, and re-

source allocation strategies. This user-driven ap-

proach prevents overengineering while ensuring

that the architecture is tailored to meet practical

demands.

• Leveraging System on Chip (SoC) for

Retroﬁtting Existing Solutions: When in-

tegrating CCP into existing IoT systems, the

use of advanced System on Chip (SoC) devices

emerged as a practical and efﬁcient solution. The

high-performance capabilities, energy efﬁciency,

and protocol support offered by modern SoCs

allow them to retroﬁt and upgrade legacy systems

with minimal disruption. By facilitating edge

analytics, real-time data processing, and seamless

communication across computational layers,

SoCs bridge the gap between outdated architec-

tures and advanced frameworks like CCP. This

learning underscores the value of SoC-enabled

nodes in transforming existing IoT deployments

into more scalable, responsive, and efﬁcient

systems.

• Use of Standardized Technologies Enhances

Interoperability: The adoption of standardised

technologies played a crucial role in ensuring in-

teroperability and ease of integration across di-

verse components in the IoT ecosystem. By lever-

aging widely accepted protocols and frameworks,

such as MQTT, HTTP REST, and WiFi-based

connectivity, the architecture facilitated seam-

less communication and coordination between de-

vices, computational layers, and external systems.

This learning highlights the importance of build-

ing IoT solutions with standardisation at their

core, as it not only simpliﬁes system implemen-

tation but also ensures compatibility and scalabil-

ity in complex and heterogeneous environments.

Systems designed around standardised technolo-

gies are inherently more robust and adaptable, al-

lowing for smoother integration with both existing

infrastructure and future advancements.

We developed a scalable, extensible, and ﬂexible

IoT solution by reimagining traditional system de-

sign. With CPP, we moved beyond the limitations of

layered architectures, and embraced a computation-

centric perspective, prioritised real-world use cases,

utilised advanced System on Chip technologies, and

focused on architectural innovation. We learned that

achieving such a solution requires balancing dynamic

resource allocation, adaptability to varying work-

loads, and seamless integration of new devices and

services while maintaining a focus on interoperability

and scalability. Our experiments emphasised the need

to break traditional boundaries in order to design IoT

systems that meet the evolving demands of modern,

interconnected environments.

We believe these learnings empower designers to

shape next-gen IoT solutions driven by CCP.

7 CONCLUSION

This study validates the Collaborative Computing

Paradigms (CCP)-based IoT Reference Architecture

as a superior alternative to traditional layered archi-

tectures for dynamic IoT environments. By incorpo-

rating critical characteristics such as interconnection

and interplay between computational paradigms, dy-

namic processing distribution, computational ﬂuidity

and scalability and extensibility, the CCP architecture

addresses key limitations of layered models, includ-

ing rigidity, high latency, and suboptimal resource

utilisation.

Experimental evaluations in Building Automa-

tion (ﬁre safety systems, air quality monitoring, and

HVAC control) and Telematics applications highlight

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

120

measurable performance improvements with the CCP

architecture. Speciﬁcally, it demonstrated enhanced

latency reduction, adaptive workload distribution pos-

sibilities, real-time analytics capabilities at the edge.

These results underscore its ability to dynamically op-

timize resource allocation and decision-making pro-

cesses across heterogeneous and ﬂuid IoT environ-

ments. There will also be a need to quantify the re-

sults in terms of performance parameters.

Thus, the CCP-based architecture offers a foun-

dational enhancement, and a fundamentally different

approach to IoT system design, moving beyond the

constraints of static, layered frameworks. By enabling

highly distributed, context-aware, and collaborative

processing, this architecture establishes itself as a vi-

able and scalable framework for next-generation IoT

deployments. Future work may focus on extending

the CCP paradigm to broader domains, further val-

idating its potential to redeﬁne IoT architectures in

increasingly complex and data-driven scenarios.

8 FUTURE WORK

Building on the demonstrated advantages of the CCP-

based IoT Reference Architecture, future research

will focus on extending its applicability across di-

verse IoT domains and industry verticals. Customized

models will be developed to address domain-speciﬁc

requirements in areas such as smart cities, health-

care, industrial automation, agriculture, and energy

management. Each vertical presents unique chal-

lenges—ranging from real-time decision-making and

scalability, to data security, and compliance—that

will require adapting the CCP framework to meet op-

erational demands.

Additionally, the integration of AI and ML within

CCP architectures will be a major focus. By em-

bedding predictive analytics, anomaly detection, and

adaptive resource allocation capabilities, CCP-based

systems can evolve into intelligent ecosystems ca-

pable of self-optimisation. Research will also ex-

plore the deployment of CCP, in ultra-low latency and

mission-critical applications, such as autonomous ve-

hicles, robotics, and remote healthcare, to assess its

suitability for high-stakes environments.

Finally, standardising CCP models for various

industries, enhancing security and privacy mecha-

nisms, and creating simulation tools for validation

and benchmarking will drive broader adoption. Fu-

ture studies will also evaluate the scalability and per-

formance of CCP architectures in globally distributed

IoT environments, ensuring their readiness for large-

scale, heterogeneous deployments. These efforts aim

to solidify CCP as a cornerstone for next-generation

IoT systems, delivering adaptive, secure, and highly

efﬁcient solutions for increasingly complex intercon-

nected ecosystems.

ACKNOWLEDGMENTS

We sincerely thank Leap&Scale

, India, for provid-

ing access to their Sensoyo

IoT Platform and IoT

devices, which facilitated our experiments and tests.

REFERENCES

Bass, L., Clements, P., and Kazman, R. (2012). Soft-

ware Architecture in Practice. Addison-Wesley Pro-

fessional, 3rd edition.

Ericsson (2024). Iot connections forecast - accessed on 10

dec 2024. In https://www.ericsson.com/en/reports-

and-papers/mobility-report/dataforecasts/iot-

connections-outlook.

Espressif (2024). Esp32 wiﬁ & bluetooth soc - accessed on

10 dec 2024. In https://www.espressif.com.

H. Washizaki, e. (2024). Guide to the software engineering

body of knowledge (swebok guide), version 4.0. In

SEWBOK, IEEE Computer Society.

Joshi, P. and Deshpande, B. (2024a). Collaborative com-

puting paradigms: A software systems architecture

for dynamic iot environments. In Proceedings of the

12th International Conference on Model-Based Soft-

ware and Systems Engineering - Volume 1: MODEL-

SWARD, pages 297–306. INSTICC, SciTePress.

Joshi, P. and Deshpande, B. (2024b). A reference architec-

ture for dynamic iot environments using collaborative

computing paradigms (ccp-iot-ra). In Proceedings of

the 19th International Conference on Software Tech-

nologies - Volume 1: ICSOFT, pages 193–202. IN-

STICC, SciTePress.

Kaushik, K. and Naik, V. (2023). Making ductless-split

cooling systems energy efﬁcient using iot. In Interna-

tional Conference on Communication Systems. COM-

SNETS.

Malekian, R. and et al. (2015). Design and implementation

of a wireless obd ii ﬂeet management system. In IEEE

Sensors Journal, vol. 17, no. 4, pp. 1154-1164. IEEE.

Pi, R. (2024). Products, accessed on 10 dec 2024. In

https://www.raspberrypi.com/products/.

Sensortec, B. (2024). Products - accessed on 10 dec 2024.

In https://www.bosch-sensortec.com/products/.

urker, G. F. and et al (2016). Survey of smartphone appli-

cations based on obd-ii for intelligent transportation

systems. In International Journal of Engg Research

and Applications. IJERA.

Advancing IoT Architectures Using Collaborative Computing Paradigms for Dynamic and Scalable Systems

121