Abstract
Traceability and visibility of outbound logistics are crucial for companies aiming to enhance customer satisfaction and ensure product quality and reliability. The Internet of Things (IoT) offers promising solutions by enabling real-time tracking and intelligent decision-making in supply chains. However, processing and interpreting heterogeneous IoT data (sensors, actuators) remain challenging, as timely and accurate information dissemination is required. In this paper, we propose EDSOA-OLP-IoT; novel semantic middleware architecture based on the OLP-IoT ontology and designed to optimize outbound logistics operations. Our approach integrates a service-oriented event-driven architecture with a Publish-Subscribe communication model, complex event processing (CEP), and ontology-based reasoning. Unlike traditional IoT frameworks, our system enhances anomaly detection, improves decision-making accuracy, and optimizes resource management by leveraging semantic reasoning. Through experimental simulations, we demonstrate that EDSOA-OLP-IoT effectively reduces response time to critical events and enhances supply chain efficiency. To validate our approach, we conducted simulations based on real-world-inspired scenarios, including temperature monitoring in refrigerated trucks and warehouses. These scenarios showcase the system’s ability to detect anomalies and trigger appropriate responses, highlighting the potential of semantic reasoning and event-driven architectures for real-time logistics optimization.
Keywords
Introduction
Currently, various devices are involved to improve the traceability and visibility of outbound logistics using Internet of things (IoT) technologies (Noura et al., 2019). The heterogeneity of these devices, namely, sensors, actuators and RFID tags, in addition to the different concepts related to outbound logistics influences the understanding and interpretation of the information produced, and makes knowledge management on the physical environment complex. Thus, to design an intelligent supply chain, there is a need to extract meaningful knowledge and analyze data from different sources to track and monitor the status of the different products and objects involved in the outbound logistics (Sallam et al., 2023). Despite existing literature, there is no established interoperable architecture for the Internet of Things that accomplishes two key objectives: (1) organizing outbound logistics functions by providing services to various stakeholders for tracking and monitoring product and logistics process statuses, and (2) ensuring real-time responsiveness to events, particularly in sensitive supply chains.
To overcome these challenges, middleware solutions facilitate the development and maintenance of complex distributed systems by providing the necessary abstractions, interfaces, and system support mechanisms (Medeiros et al., 2022). Indeed, they have gained a reputation in the literature for providing credible solutions that can meet several requirements for interoperability and availability of information in the system (Razzaque et al., 2016). They also help in managing the communication between the IoT system components and the different business applications (Lamnaour et al., 2024). Such an approach typically provides an abstract interface not only to the heterogeneous and possibly constrained underlying hardware, but also to the defined supporting software components of the system. In this context, we opted for the design of service-oriented and event-based middleware architecture.
In this article we define EDSOA-OLP-IoT, a middleware that we designed to meet the requirements of IoT-based collaborative architectures in the logistics domain. It is a middleware based on a semantic event-driven service-oriented architecture for IoT applications. This architecture is well suited for IoT applications in the context of the outbound logistics domain. It is based on the combination of two architectures: event-driven (EDA) (Zhang et al., 2021) and service-oriented (SOA) (Chelloug and El-Zawawy, 2018). This type of middleware is characterized by technological neutrality, loose service coordination, reusability and high service discovery. On the other hand, it supports real-time, event-driven and active service execution with loosely coupled communication between system components which is in line with the needs of IoT applications involved in the logistics domain (Liu et al., 2022). This architecture is based on the use of the OLP-IoT ontology developed in (Allouch et al., 2023), providing the necessary mechanisms to semantically describe the data and metadata of the different IoT sensors and devices used, as well as the different logistics processes and objects involved. Moreover, the proposed approach allows defining components capable of receiving semantic data generated by the different IoT devices, applying rules and complex event processing (CEP) and inferring higher-level information and semantic knowledge. This guarantees both visibility and control over product and equipment status, while enabling timely and appropriate actions in response to critical events.
The remainder of this paper is organized as follows. The next section presents related works, along with the background and the ontological approach. The subsequent section introduces the proposed architecture. Then, the results are discussed through practical use cases. The following section evaluates the EDSOA-OLP-IoT architecture and highlights the benefits achieved through its application. Finally, the paper concludes with a summary and perspectives for future work.
Background and Related Works
This section provides an overview of existing middleware approaches for the Internet of Things, focusing on service-oriented and event-driven paradigms. We highlight their strengths and limitations, especially in the context of logistics, and motivate the need for a unified architecture that leverages ontologies to ensure semantic interoperability and real-time responsiveness.
IoT Middleware
The main objective of IoT Middleware is to provide a software layer that acts as an intermediary between physical devices (sensors, actuators, relays, etc.) and data endpoints, and higher-level software applications (Elkhoukhi et al., 2025). The initial goal of this component is therefore to abstract various complex technical details, to simplify technical problems and to reduce the complexity of programming (Atzori et al., 2010).
In the Internet of Things domain, a diversity of connected devices (objects) and a huge volume of events are generated. As a result, developing applications and services that can fully exploit the potential of the IoT will be a challenging task. According to (Bandyopadhyay et al., 2011), middleware plays a crucial role in the realization of IoT systems. It is a software system designed to act as an intermediary between devices and IoT applications. Middleware can provide common services for all kinds of applications and facilitate application development (from the developer’s perspective) by integrating heterogeneous computing and communication devices and supporting interoperability within the various services running on IoT devices. While general IoT middleware solutions offer abstraction and interoperability, more specific paradigms such as Service-Oriented Architectures (SOA) have emerged to enhance modularity and semantic integration in dynamic environments like logistics.
Service-Oriented Middleware
Service-based middleware outperforms other solutions when it comes to interoperability, but there are several issues that need to be addressed when designing for logistics-related environments. The activities and processes involved in pharmaceutical and agri-food logistics require a high level of reactivity and real-time response to changes. Semantic models are widely regarded as an effective way to ensure interoperability. Additionally, the emerging Semantic Service-Oriented Architecture (SSOA) offers a robust approach for large-scale IoT infrastructures by utilizing rich, machine-interpretable descriptions of data, services, and processes, which enables systems to interact autonomously.
Hydra (Hoffmann et al., 2008), funded by the European Union and renamed LinkSmart (Kostelnık et al., 2011) in 2014, aims to integrate sensors into ambient intelligence systems by providing interoperability at the syntactic and semantic level using semantic web services. It provides contextual capabilities with powerful reasoning, based on the use of ontologies and low-level semantic processing approaches. It classifies contextual data into three categories: device contexts, semantic contexts, and application contexts, and provides acquisition, inference, and management policies for these contexts. However, the lack of ontology standards limits the scalability of Hydra.
The SENSEI middleware (Tsiatsis et al., 2010) develops an architecture for the future, real-world Internet, including the IoT. It includes a context model, context services, actuation tasks, and a dynamic service composition of primitive and advanced services. The resource layer sits between the application layer and the communication services layer and uses ontologies for semantic modeling. Currently, there is no standard ontology for very large-scale IoT, making SENSEI inadequate for IoT.
ubiSOAP (Caporuscio et al., 2012) is a service-oriented lightweight middleware that provides network-level resource management and interoperability by supporting heterogeneous network devices and technologies. It consists of a resource layer that provides unified abstraction for simple devices, a supporting services component that enables dynamic discovery and composition of resources, and privacy and security functions.
OM2M (Alaya et al., 2014) is an advanced semantic middleware based on SOA. It provides an interoperable system to connect billions of devices, but does not consider real-time analysis and fully loosely coupled architecture. The authors proposed the IoT Ontology (IoT-O) for autonomous management of M2M systems, with four main modules: Acting, Lifecycle, Service, and Energy. However, this ontology does not take into account virtual sensors and cognitive processing of information.
However, the need for reactivity and real-time responsiveness in logistics scenarios cannot be fully addressed by service orientation alone. This has led to the rise of event-driven paradigms, where events are central to enabling loosely coupled, real-time interactions.
Event-Based Middleware
Event-Driven Architecture (EDA) is a software architecture paradigm that facilitates event generation, detection, and reaction. In EDA, components, applications, and other participants communicate through events. Event-based middleware typically employs a Publish/Subscribe mechanism and generally consists of two main components: the event generator and the event consumer. The event generator creates events, while the event consumer subscribes to receive those events. Applications typically subscribe to events of interest, and when the middleware detects an event, it forwards the event to its subscribers (Zhang et al., 2020; Zhang et al., 2021).
Event-driven architecture is a style of architecture characterized by a number of relatively independent actors communicating events to each other to achieve a coordinated goal (Farias and Luan, 2023). Event-driven architecture is based on the asynchronous publish/subscribe model, which allows for the dissemination of information about business events in real time. In this model the publisher completely ignores the subscriber and vice versa. In an event-driven architecture, nodes generate events and do not depend on the availability of the receiving node. It is truly decoupled from other nodes (IBM Corporation, 2006). Such a system uses push mode for event communication, provides concurrent reactive processing, and is particularly suited for applications that use loosely coupled real-time communication and support sensing. EDA defines design guidelines for creating and building application systems (Cheng et al., 2016). Since an event message is transmitted via the “publish/subscribe” method, an event can be sent to multiple subscribers, allowing an enterprise to respond and process these events in a timely and appropriate manner.
Recognizing the complementary strengths of SOA and EDA, recent research has explored their integration into Event-Driven Service-Oriented Architectures (EDSOA), which aim to combine semantic interoperability with real-time responsiveness.
Related Works on EDSOA-Based Approaches
There are several studies that discuss the benefits of integrating service-oriented architectures with event-driven architectures (SOA and EDA). In (Niblett & Graham, 2005), authors illustrated how combining EDA and SOA into a single EDSOA infrastructure brings many benefits, as it is quite common for a single service to combine both request/response and event-driven message exchanges. The research of (Yuan & Lu, 2009) shows an EDSOA based on a value-centric processing concept and event-driven communication style. Event-based communication offers a service provider to have more information about its customers by creating customer profiles. In (Juric, 2010), authors explained how SOA can be extended with EDA concepts. In this approach, services act as producers and consumers of events while preserving interfaces and their operations. This approach also enables event-based service orchestrations in business processes. The research in (Lan et al., 2015) suggested analyzing the characteristics of IoT sensing services and proposed future service architecture. It focuses on middleware architecture and interface presentation technology. To improve this, a new sensing service system based on Event-Driven SOA (EDSOA) is proposed. To support real-time, event-driven and active service execution. It introduces new features of the IoT browser, including the use of augmented reality technology for input and output and the realization of the overlay of the physical world and abstract information. In this context, SOA plays a role in which it can organize and use all the IT capabilities distributed in different ownership areas to meet the needs of users. The services in EDSOA can be executed simultaneously if they receive the event at the same time. Thus, the performance of EDSOA is better than that of SOA in which services execute in sequence called by another service. In (Cheng et al., 2018), authors proposed an approach to improve flexibility and agility to respond quickly to dynamic changes in the physical world in a timely manner. It proposes an agile, event-driven, service-oriented IoT service communication and orchestration platform. They adopt an event-based SOA mechanism and consist of uniform sensory device access management, resource management, a common message communication infrastructure, and a service orchestration engine. The unified message space is a distributed overlay network based on a publish/subscribe mechanism. While these hybrid approaches demonstrate promising capabilities, they still face significant limitations when applied to large-scale, semantically rich IoT environments such as logistics.
The Research Gap
The literature highlights the growing importance of integrating Service-Oriented Architectures (SOA) and Event-Driven Architectures (EDA) to enhance interoperability and real-time responsiveness in IoT-based systems. Several works propose middleware solutions that leverage semantic models and event-driven mechanisms to improve system flexibility and automation. However, existing research lacks a unified approach that effectively integrates SOA, EDA, and ontologies in a scalable manner for large-scale IoT infrastructures. On one hand, while semantic middleware solutions such as Hydra, SENSEI, OM2M, Hetero-Genius (Elhabbash et al., 2022; Fahad et al., 2022) provide interoperability through ontology-based reasoning, they fail to support real-time event processing and dynamic service orchestration. On the other hand, EDSOA solutions enhance agility by enabling asynchronous, event-based interactions, yet they lack a structured semantic model that ensures interoperability across heterogeneous IoT systems. Furthermore, most existing middleware solutions are designed for general IoT applications and do not specifically address the challenges of logistics and supply chain management, where real-time monitoring, event-driven decision-making, and semantic interoperability are crucial (Jachimczyk et al., 2021; Knapp et al., 2023; Liu et al., 2022). Current approaches either lack ontology standardization for IoT-based logistics or fail to integrate cognitive processing and virtual sensors for enhanced situational awareness as increasingly required in smart environments (Elkhoukhi et al., 2025; Qaswar et al., 2022). While RFID technologies have proven effective in FMCG and Retail 4.0 for stock management and process optimization (Tebaldi et al., 2023), their integration into semantically enriched middleware for context-aware automation remains limited.
To bridge this gap, our proposed approach introduces a semantic-driven, event-based SOA middleware that combines the benefits of ontological reasoning, real-time event processing, and loosely coupled service orchestration. This approach aims to ensure scalability, interoperability, and dynamic adaptability in IoT-enabled outbound logistics, allowing real-time context-aware decision-making and automated event-driven responses.
The Ontological Approach
The OLP-IoT ontology (Allouch et al., 2023), as depicted in Figure 1, provides a shared and common reference model that can describe all relevant components and knowledge to improve traceability and interoperability of outbound logistics among stakeholders. It includes key terms and aspects to organize data and clearly maintain logistics elements and product information. It also helps to represent the processes and activities of the logistics sector and how IoT technologies are used to observe different parameters and properties in the supply chain. Global Architecture of the OLP-IoT Ontology (Allouch et al., 2023)
OLP-IoT integrates two domains of interest, each represented by a distinct module within the ontology. The outbound logistics domain is modeled by the OLP-Onto ontology, which includes key concepts, their relationships, and descriptions of phenomena occurring in the outbound supply chain. Conversely, the IoT domain is represented by the IoT4Log ontology, capturing the technologies and aspects necessary for enabling traceability and visibility of all items and equipment involved in the outbound logistics process. OLP-IoT merges these two ontologies, incorporating alignments and new relationships to model the interactions between them.
Building on this ontological foundation, we now present a layered architecture that integrates semantic reasoning with real-time event processing to support smart outbound logistics.
Overview of the EDSOA-OLP-IoT Architecture
Due to the lack of a general IoT architecture suitable for logistics environments, it is essential to design a flexible architecture that is sustainable to meet outbound logistics requirements, such as, responsiveness, real-time processing, collaboration, synchronization, and visibility. The EDSOA-OLP-IoT architecture is presented in Figure 2 and consists of four main layers: (1) the application layer, (2) the service layer, (3) the event processing layer, and (4) the physical layer. However, our contribution concerns the Middleware part which encompasses both layers: services and event processing. The physical layer in our context represents the layer in which the sources of data flows are placed, encompassing the different sensors, tags and technologies used for tracking and tracing products and logistics. For the application layer, it includes different types of applications that exploit semantically enriched information, and that are mainly intended for supply chain stakeholders in order to track and control product quality and to improve visibility on all relevant supply chain processes, as well as to support decision-making tasks in this layer. In the following sections, we introduce the service layer and the event processing layer, and we describe in detail the important components of these layers and how they work. We have selected and combined various software components appropriate for the smart outbound logistics domain, based on a literature review of previously done work (Al-Osta and AhmedGherbi, 2019; Gomes et al., 2019; Taye, 2010), which constitute the framework of our proposed architecture, presented in Figure 2. The main elements of the proposed architecture are described below. Overview of the EDSOA-OLP-IoT Architecture
Event Processing Layer
As illustrated in Figure 3, the event processing layer encompasses three main components as detailed in the following sections. The Event Processing Layer
Data Pre-processing
The data pre-processing component collects raw data from heterogeneous sources, including sensors that detect physical properties and RFID tags used for product and logistics equipment identification. The main objective of this module is to process and organize the raw data from sensor nodes and tags by filtering out redundant information and converting the remaining data into a well-defined format. IoT devices may transmit data in various formats, such as binary encoding, JSON, XML, or plain text. Given the heterogeneity of data sources and formats, it is necessary to store data from IoT devices in a NOSQL database, Mongo DB, for example. In this type of database, it is not necessary to define a data schema, so data from different structures can be grouped together on one system. This module is composed of three sub-modules, as shown in Figure 4, and detailed as follows. Data Pre-processing
Data Aggregation
The aggregation sub-module receives the data streams from the sensor nodes and RFID readers and stores them in a temporary file for analysis. Device description files (which contain device id, type and other characteristics according to the needs of the business applications) are used to describe the characteristics of sensors, readers and tags deployed in the supply chain. For this reason, the resources only send their identifier (idDevice), location, timestamp and the observed or detected value (RFID tag). By doing so, we minimize the size of the entries needed for aggregation.
Data Filtering
The main objective of this sub-module is to reduce the amount of data sent to the semantic annotation component. Predefined rules can be employed to process the data received from the aggregation sub-module, tailored to the specific requirements and preferences of the supply chain stakeholders. Among the rules that can be applied, we can cite the example of rules based on a combination of time intervals and locations to identify significant events that depict critical states for controlling and enhancing the visibility of the supply chain.
Example
In the warehouse “Warehouse A,” a temperature sensor “Temp01” is deployed to send the temperature every 20 seconds as shown in Figure 5 (a). In the sensor description file, Temp01 is configured to send only values that are greater than or equal to 25 degrees Celsius as shown in Figure 5 (b). Example of Unnecessary Sensory Data
Algorithm 1 (in Figure 6) represents the pseudo-code of the data filtering procedure performed in the filtering sub-module. This algorithm takes the aggregated temporary data file, the already specified rules file, and the device description file deployed in the system as inputs and produces filtered data as output. After reading and parsing the source files, we can obtain three lists listDesc, listRules, and listRData which represent, respectively, the list of device descriptions used, the list of rules to be applied to the sensors according to business needs, and the list of aggregated data (lines 1 to 3). In line 5, we begin iterating through the list of sent data and search for the device description in the description list (lines 6 to 7). We then check whether any processing has already been performed on this device (line 9). If no processing has been done, we proceed to search for all entries corresponding to this idDevice in line 11. Depending on the type of device in question (line 12/18) a particular treatment must be called. If the data is from an RFID tag, the filterTagList method will be called, taking as a parameter the list extracted in line 11. In the case of sensor types, the list of rules applicable to this type of sensor will be extracted in line 18 using the sensor type and the list of rules previously extracted in line 2. Then, we pass the extracted list and the list containing the relevant sensor data as parameters to the filterSensorList function for filtering (lines 18 to 19). The filter functions are defined based on specific requirements and needs. Aggregate Data Filtering Algorithm
Data Structuring
Is a sub-module that receives filtered data from the filtering sub-module and converts it into an exchangeable format (often JSON, XML or CSV). To format this data, the sensor description file must be used to derive other characteristics of the devices used and combine them with the filtered data to generate a formatted file. Once the data is structured, it becomes ready for semantic enrichment and integration into the knowledge base.
Semantic Annotation of Raw Events
Semantic annotation of data provides machine-readable and interpretable metadata on different resources by providing a normalized semantic representation of knowledge under the guidance of domain ontology. In our context, the raw events generated by the component mentioned above will be sent to the semantic annotation component for enrichment and semantic annotation using the OLP-IoT ontological approach. In order to provide a higher-level abstraction for user queries, we rely on IoT4Log, OLP-Onto, and OLP-IoT ontologies using the Web Ontology Language (OWL) to associate domain entities with raw events. Using ontologies enables us to leverage existing knowledge bases developed by experts, reason effectively about equivalent and related concepts, and swiftly incorporate new domain concepts (Zhou et al., 2012).
Ontologies are structured in a modular manner, allowing related domain components to be linked together using subject-verb-object triples that capture the relationship (verb) between two concepts (subject, object). We enrich the raw events with a semantic context by mapping their tuple attributes to their equivalent entities in the OLP-IoT ontological approach.
The OLP-IoT ontological approach and mapping process (i.e., the RML processor and the mapping specifications) are the two central elements of this component, as illustrated in Figure 7. The ontological approach provides a formal representation of the main IoT concept. The RML processor, which is provided with the mapping specifications from the different sources, consumes the raw IoT data and transforms it into an RDF graph, semantically annotated according to OLP-IoT. Raw Event Annotations
In the example in Figure 8, the RML mapping document produces the desired triples from the corresponding JSON data source and the IoT4Log ontology. It contains information on a temperature observation. The identifier, sensor and observed property are included, as well as the result value and unit. Example of Observations Generated in a JSON File
In Figure 9, we add the RML rules that define which JSON file is used and how we iterate over the objects it contains: Example of a Mapping File for Observations With RML Rules
The IRI representing a character is generated by concatenating https://example.org/Observation/ with the observation’s id. (1) This IRI is used as the subject of triples. (2) “Measurement” is annotated with the SOSA: Observation class. (3) “Property” is annotated with the property SOSA: ObservedProperty. (4) “Sensor” is annotated with the property SOSA: madeBySensor. (5) “Value” is annotated with the property IoT4Log: hasResultValue. (6) “Unit” is annotated with the property IoT4Log: hasUnit.
After executing these rules, the final triples are generated as shown in Figure 10. Once events are semantically enriched, higher-level reasoning becomes possible through the identification of complex event patterns. RDF Triples Generated by RML Mapping
Processing of Raw Complex Events
The proposed system relies heavily on a key component: taking semantically annotated events as input from the semantic annotation module, it then processes these simple events to identify complex events or activities that have just occurred or are anticipated in the near future. This processing employs Complex Event Processing (CEP) techniques, which specialize in detecting intricate patterns among incoming elements, including sequencing and scheduling relationships. Specifically, in our context, complex event processing involves analyzing these events to forecast the risk of fire or deviations in environmental conditions affecting product quality and safety, and potentially impacting consumer health.
We have concretized this process in our work based on two main parts. (1) The OLP-IoT ontological approach, which will be instantiated using data from two main sources: Firstly, it will incorporate data related to outbound logistics, which includes information on: (a) products to be stored or transported, along with their characteristics and requirements; (b) packaging units, loading units, transport units, and the means to be used, including their descriptions and requirements; and (c) symbolic locations and their addresses, such as warehouses, delivery zones, and ports. Secondly, the approach will utilize data from the preceding component, which contains data generated by the physical layer, annotated, and formatted into RDF triples. (2) A set of inference rules that we have proposed based on the SWRL language. These rules consist of an antecedent part specifying the condition to be satisfied and the consequent part defining the fact that may occur. They are used to discover new relationships, detect possible inconsistencies, and infer logical consequences from a set of affirmed facts or axioms. They allow defining and extracting models of complex events that can trigger important or abnormal business events influencing the quality of products and logistics processes. These events are then used to execute appropriate actions in response. The proposed rules are categorized into two main types: The first category focuses on detecting abnormal events that could impact product quality, achieved by comparing measured data with predefined thresholds for each product. The second category is concerned with generating suitable actions based on the detected events.
After processing and reasoning over events, the system must expose these insights through interoperable services to end users and applications.
Services Layer
This layer facilitates the discovery and interaction between applications and various information sources provided by IoT devices through services. These services support the logistics process and enable different stakeholders in the chain to monitor and control physical and informational flows. The system allows users to send requests through IoT applications to discover suitable services offered by a device, or to acquire data and receive notifications about subscribed services. Figure 11 provides a detailed view of the main components of the semantic service layer. Services Layer
Semantic Service Discovery
The service discovery component in our context aims to capture semantic descriptions of services offered by IoT devices involved in the physical flows of the supply chain. It also enables searching for suitable services after receiving a request from supply chain actors using IoT applications. The ontological approach OLP-IoT will be used to annotate different semantic services in the service registry. This component consists of two main parts.
Service Registration
The main role of this component is to add the semantic description of a new service to the service registry offered by IoT components used in logistics processes, or to delete a service description in the event of a device departure. Before registering the service in the service registry, the registration component generates the semantic service description of an IoT service after annotating it using the OLP-IoT ontology. Once annotated, the service can be registered in the service registry. These services can be sensing services, actuation services or others. Figure 12 illustrates the various interactions between an IoT device and the components of the service registry, when registering a service offered by this device. Sequence Diagram Representing the Interactions Between the IoT Device and the Service Registry Components
Service Discovery
This component is responsible for receiving user requests and returning an appropriate service based on the request and the service registry, as illustrated in Figure 13. The user sends a request specifying search criteria in the form of keywords describing concepts to be measured or acted upon, along with other parameters such as location, quality, and accuracy of the results. The query management component extracts a semantic description of the requested service and sends it to the service search component. This component then matches the extracted concepts with the appropriate service by querying the service registry for the corresponding service description. The service search component queries the OLP-IoT ontology using SPARQL queries to find the appropriate service. Sequence Diagram Representing the Interactions Between the User and the Components Responsible for the Service Search
Event-Service Manager
To tackle the challenge of limited interoperability between IoT resources and applications, our architecture incorporates an event and service manager component built on the “Publish-Subscribe” model. This communication approach promotes loose coupling and scalability, ensuring that subscribers consistently receive notifications and alerts regarding their subscribed topics. The service comprises two primary elements: the subscription manager and the event-service manager. Both components use the subscription register to record new subscriptions and determine the subscribers engaged in a service. The subsequent section will elaborate on the operation of each component.
Subscriptions Manager
This component handles the process of registering customer subscriptions for desired services. Using IoT logistics applications, customers can subscribe to notifications related to their chosen services. Each subscriber selects one or more specific topics based on their preferences and receives notifications whenever updates or changes occur in those topics. These notifications enable customers to receive timely information for immediate reaction and action. Every subscription is recorded in a subscription registry, detailing the subscriber and the service they have subscribed to.
Consider the WarehouseMonitoringTemperature web service, which is used to monitor and control the temperature in a perishable goods warehouse equipped with sensors and an air conditioner. This service enables the monitoring of temperature status in the warehouse, detects abnormal temperature changes, and reacts as necessary. Users (applications) interested in this service and wishing to receive information and notifications. In this context, the subscription manager handles subscriptions for notifications about temperature changes in the warehouse. It supports the following operations: The SubscribeToService () operation allows the subscriber to express interest in receiving notifications about specific types of events related to warehouse temperature monitoring. The UnsubscribeToService() operation allows the application to stop receiving notifications about the particular service. Among the notifications that the subscriber can receive, the higherTempReached event indicates that the warehouse temperature has exceeded the maximum threshold required for proper storage of products.
Event Service Manager
The publish/subscribe approach allows systems to announce events to multiple consumers by asynchronously broadcasting messages in the form of notifications to different system components. In this context, the event service manager coordinates and manages event services and notifies subscribers in case of a change. Once an event is detected, the manager is responsible for finding the appropriate event service and invoking it. The service search is performed by querying the service registry, which is populated with services published by each IoT resource. Similarly, this manager is responsible for notifying subscribers in case of a change; by calling the subscription register which contains the list of subscribers for each service. When subscribers subscribe to one or more topics, they are automatically notified of new data published on these topics, which are usually anomalous changes in the data observed by the IoT devices.
We can say that the event service management component is responsible for bridging the gap between events and services. Once events have passed the event processing stage, they can then invoke services through the SOA synthesizer. This is achieved either by attaching a precise description of the associated service invocation to the event or by specifying the required services, which are then processed by the service discovery component to find the appropriate services based on user requests.
Our architecture is based on the combination of SOA and EDA, which justifies the event-service policy that we used to provide a static correspondence between events and services. In this context, an event is associated with a specification of the required services that allows invoking the appropriate services for each event. Similarly, event providers notify subscribers by invoking the appropriate service to announce that event to those who are subscribed to that service.
A main feature of the proposed solution is its ability to combine the query principle, in which consumers express their requests, and the notification principle, which allows the publication of new information and updates. This integration relies on the common semantic ontological model OLP-IoT, which enables the involved devices to share information. This approach enhances interoperability and communication between the different components of the supply chain involved, allowing them to cooperate and collaborate effectively in controlling and monitoring physical and informational flows.
We consider the following requirements. (1) Every operation performed by an IoT device is considered as a service; (2) IoT devices can generate events; (3) Service Event is a specific type of service, representing a service that generates or responds to events; (4) A consumer subscribes to the global service, which can generate observed data and alarm events for the environment concerned (which relates to a particular subject, such as the temperature in warehouse X). (5) The global service can include several event services; (6) IoT devices can publish and consume services (they consume a certain type of information and are sources for other information).
Use Cases and Results
To validate our proposed approach and assess the system’s performance in real-world conditions, we defined two representative use cases. These scenarios simulate typical events in the cold supply chain and illustrate how our system responds to environmental deviations to ensure product integrity.
Scenario 1: An Alarm and Notification System for Food Transport and Storage
When ambient sensor data exceed predetermined critical thresholds, immediate actions and decisions are required to mitigate potential risks. In our test scenario, we evaluated the system’s response to temperature deviations in a controlled environment. Specifically, we considered a food product (Product_B) stored in a designated warehouse (Warehouse_B) equipped with a temperature sensor (TemperatureSensor_B) and an actuator (TemperatureAlarm_B) (Table 1). During the test, the TemperatureSensor_B recorded an observation (Observation_B) indicating that the ambient temperature had reached 25.0°C, while the maximum permissible temperature for Product_B was set to 22.0°C. This represents a +3.0°C deviation from the acceptable range. In response, the system applied Rule 1, triggering an alarm (TemperatureAlarm_B) and sending an alert to designated personnel. The warehouse staff inspected the storage conditions and identified that the cooling system required adjustment. The corrective action was taken promptly, and the temperature was restored to the acceptable range, thereby preventing potential product degradation.
This test demonstrates the effectiveness of our system in detecting and responding to critical temperature fluctuations in real-time, ensuring compliance with storage requirements for sensitive products (Figure 14). The Reasoning Mechanism Used in Scenario 1 to Deduce New Information About TemperatureAlarm_B after the Application of Rule 1
Instances Created in Scenario 1 to Evaluate Rule 1
Scenario2: Temperature Monitoring in a Warehouse for Storing Food Products
Temperature control in food logistics is essential for preserving the quality and safety of perishable goods during storage and transportation. Even brief exposure to extreme temperatures, whether too hot or too cold, can significantly reduce the shelf life and compromise product quality. To address this, we examined a warehouse equipped with two temperature sensors and one air conditioning unit, where the system autonomously adjusts temperature to maintain optimal conditions for stored products.
The scenario considered is as follows: When the detected temperature falls below the minimum threshold or exceeds the maximum allowable temperature, the system intervenes by adjusting the temperature. Initially, it activates the air conditioner to switch to either cooling or heating mode until the desired temperature is achieved. Once the target temperature is reached, the air conditioner maintains it. If the temperature persists above or below the reference level within a specified time interval, relevant users receive notifications. In this scenario, the warehouse has predefined temperature thresholds for safe product storage. (1) TempMin = 4°C (minimum required temperature), (2) TempMax = 8°C (maximum allowable temperature). (3) TempReq = 6°C (required temperature)
The system continuously monitors the temperature within the warehouse, and when the detected temperature exceeds TempMax or falls below TempMin, the system triggers corrective actions.
The following section and Figure 15 provide a more detailed description of the synchronization between events and services in the event service manager, based on the scenario we have presented. The aim is to achieve a high level of abstraction, enabling the semantic transformation of sensor and actuator data into information that can be used to control the perishables warehouse. Synchronization of Events and Services Illustrated by the Interaction Between the Air Conditioner and the Temperature
For instance, when the detected temperature exceeds TempMax = 8°C (a +2°C deviation) for more than 10 minutes, the system triggers the HigherTempReached event. This event is processed by the event service handler, which synchronizes it with the StartCooling(TempMax, TempMin, AirCondit) event service. This service sends an instruction to the air conditioning unit to activate the cooling function. The system then transitions to the Cooling state, where the air conditioner operates until the temperature reaches the required threshold (TempReq = 6°C).
If the temperature remains above TempMax for more than 15 minutes, the system triggers the HigherTempPersist event. In response, the NotifyEvent (HigherTempPersist) service is invoked, generating a notification to the WarehouseMonitoringTemperature service. This ensures that the personnel responsible for monitoring the warehouse temperature are informed that the cooling process has not yet restored normal conditions.
Conversely, if the temperature falls below TempMin (e.g., 3.5°C, a −0.5°C deviation), the system triggers the LowerTempReached event. This event is processed in the event service management component, which invokes the StartHeating(TempMax, TempMin, AirCondit) service. This service sends an instruction to the heating system to increase the temperature. The system transitions to the Heating state, where it remains until the temperature is restored to an acceptable level.
The system responds within 30 seconds to any temperature deviation, ensuring rapid activation of cooling or heating mechanisms. The temperature correction process typically restores the required range within 20 minutes. If the temperature remains stable within the defined range for more than 5 minutes, the system transitions to the Maintaining state to ensure stability.
If the temperature continues to deviate from the required range beyond 15 minutes, the system triggers a NotifyEvent(HigherTempPersist) or NotifyEvent(LowerTempPersist) event, depending on the situation. These notifications are sent to the WarehouseMonitoringTemperature service, ensuring that real-time alerts enable immediate corrective actions.
This approach highlights how event-driven responses and service-oriented architecture enable real-time monitoring of warehouse conditions. By maintaining precise temperature control, the system prevents product spoilage, reduces energy consumption, and ensures high-quality food preservation throughout the supply chain (Figure 16). Sequence Diagram Describing the Interaction Between Event Handler Components, Illustrated With the Case of Event Triggering (HigherTempReached)
Evaluation of the EDSOA-OLP-IoT Architecture and Benefits Achieved by Its Application
This section presents a comprehensive evaluation of the EDSOA-OLP-IoT architecture, focusing on both system performance and its practical benefits in real-world logistics scenarios. We compare it to a baseline system lacking semantic reasoning and event-driven capabilities To validate the system’s performance under realistic conditions, we implemented a simulation based on real-world sensor data and ontology-based semantic processing.
Methodology
To conduct this evaluation, we utilized a temperature and humidity dataset obtained from Kaggle, which contains 1,368 sensor readings along with their timestamps. The dataset represents real-time environmental conditions monitored through IoT devices, making it ideal for assessing ontology-based decision-making in logistics. The EDSOA-OLP-IoT architecture was integrated with an ontology-driven reasoning process to interpret the sensor data, enabling intelligent decision-making and anomaly detection. The dataset was processed using the OLP-IoT ontology, which defines key logistics concepts and their relationships. Temperature and humidity values were semantically mapped to ontology classes and properties using annotation and RML mapping files, enabling automated inference of product storage conditions and event detection. The reasoning process was implemented using RDFlib for ontology manipulation and Pellet as a reasoning engine. To evaluate the system in a real-world IoT-based logistics environment, to evaluate the system in a real-world IoT-based logistics environment, we developed a Python-based simulation that streams and processes sensor data in real time. This simulation leverages all the aforementioned components to analyze environmental conditions and detect anomalies. The system dynamically interprets the incoming data through the ontology, triggering event-driven notifications via MQTT upon detecting critical deviations, effectively replicating real-time alert mechanisms in logistics operations.
Comparison with the Baseline Approach
This significant improvement demonstrates the enhanced efficiency of the EDSOA-OLP-IoT system. The baseline system, which lacks IoT integration and real-time reasoning capabilities, takes a much longer time (5 seconds) to process and respond to events. In contrast, EDSOA-OLP-IoT reduces this processing time to only 0.2751 seconds, which corresponds to an improvement of 4.7249 seconds.
While previous architectures have explored semantic reasoning (Allouch et al., 2017; Gyrard et al., 2018) or event-driven processing in IoT systems (Giang et al., 2015), none provide an integrated, ontology-based, event-driven and service-oriented middleware tailored to outbound logistics applications, as EDSOA-OLP-IoT does. Our architecture uniquely bridges these dimensions, enabling real-time, context-aware decision-making with significantly improved response time.
The faster response time is attributed to the ability of the EDSOA-OLP-IoT system to leverage semantic reasoning with ontologies, enabling the system to make informed decisions in near real-time. The reasoning process, combined with the integration of IoT data, accelerates the decision-making process and reduces the system’s overall latency.
Response Time Analysis
The response time analysis clearly illustrates the effectiveness of EDSOA-OLP-IoT in optimizing event handling within IoT-based logistics systems. The low response time observed with EDSOA-OLP-IoT can be directly linked to the system’s ability to process sensor data and apply reasoning algorithms quickly (Figure 17). The use of an ontology-driven framework facilitates efficient querying and reasoning over the data, reducing the need for extensive data retrieval and processing, which is often a bottleneck in traditional systems. Responses Times Comparison: Baseline vs EDSOA-OLP-IoT
Similar benefits of fast and semantically aware processing have been demonstrated in building management systems, where ontology-driven frameworks significantly reduced response time for detecting inefficiencies and triggering automated actions (Lork et al., 2019).
The improvement in response time is critical for real-time logistics applications, where timely data processing and decision-making are essential for maintaining system efficiency and minimizing delays. The 0.2751-s response time of EDSOA-OLP-IoT allows for near-instantaneous adjustments to logistical processes, such as adjusting environmental conditions based on sensor readings, thereby improving overall system performance.
Cost-Benefit Analysis
The EDSOA-OLP-IoT architecture provides significant benefits in terms of:
Energy savings: By leveraging real-time IoT sensor data and semantic reasoning, the system optimizes energy consumption, especially in refrigeration systems. Instead of continuous operation, the system adjusts energy usage based on actual environmental conditions, leading to significant savings on electricity costs.
Semantic-based optimization techniques have also been shown to reduce energy usage and improve quality of service in distributed IoT environments (Reffad and Adel, 2023), reinforcing the effectiveness of our ontology-enhanced decision-making framework.
Reduced food wastage: In food logistics, maintaining optimal storage conditions is crucial to prevent spoilage. The EDSOA-OLP-IoT system ensures that temperature and humidity are consistently regulated, reducing food wastage. By preventing temperature deviations, perishable goods remain fresh, decreasing the losses associated with spoilage.
Efficiency improvements: The system improves efficiency by automating decision-making processes. Real-time data processing and semantic reasoning enable faster responses to issues, reducing the need for human intervention and improving operational throughput. This leads to cost savings and better productivity.
Improved decision accuracy: The semantic reasoning approach minimizes false alerts by considering contextual factors instead of using fixed thresholds.
Better product quality monitoring: By leveraging ontological knowledge, the system can differentiate between normal variations and critical anomalies, reducing unnecessary interventions.
Conclusions and Perspectives
In this paper, we present EDSOA-OLP-IoT middleware architecture for IoT-based outbound logistics applications. EDSOA-OLP-IoT combines service-oriented architecture (SOA) with event-driven architecture (EDA) to ensure independent, loosely coupled software components guided by semantic data representation and domain-specific requirements. This is achieved through event-driven SOA, which enables flexible, decoupled communication and real-time event processing, and the use of the OLP-IoT ontology to enrich exchanged data semantically and structure logistics concepts throughout the system.
To validate our approach, we conducted a simulation using a real-world dataset, integrating ontology-based reasoning and event-driven mechanisms. The evaluation demonstrated a significant improvement in system performance. Specifically, the response time of the proposed architecture was measured at 0.2751 s, compared to 5.0000 s for the baseline system, resulting in a 94.5% reduction in processing time. This substantial enhancement confirms the efficiency of EDSOA-OLP-IoT in handling real-time logistics operations while ensuring semantic consistency. Future work will focus on implementing this architecture in a real supply chain environment to further assess its practical benefits and scalability.
Footnotes
Funding
The authors received no financial support for the research, authorship, and/or publication of this article.
Declaration of conflicting interests
The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.