NEMO: Real-Time Noise and Exhaust Emissions Monitoring for Sustainable and Intelligent Transportation Systems

Research and development efforts on sustainable and intelligent transportation systems are accelerating globally as the transportation sector contributes significantly to environmental pollution and produces a variety of noise and emissions that impact the climate. With the emergence of ubiquitous sensors and Internet-of-Things (IoT) applications, finding innovative transport solutions, including adequate climate change mitigation, will all be vital components of a sustainable transport future. Thus, it is essential to continuously monitor noise and exhaust emissions from road vehicles, trains, and ships. As a contribution to addressing this as part of an effort of the European Union project called “NEMO: Noise and Emissions Monitoring and Radical Mitigation,” in this article, we propose the design and development of a real-time noise and exhaust emissions monitoring for sustainable and intelligent transportation systems. We report real-world field testing in some European cities where vehicle noise and exhaust emissions data are gathered in the cloud-enabled Nautilus platform and evaluated using artificial intelligence (AI) algorithms to determine their categorization into different classes of emitters and, thereby, enabling the infrastructure managers to define logic and actions to be taken by high emitters in near real time. We outline the creation of a complete NEMO solution to monitor and reduce noise and emissions in real time for sustainable and intelligent transportation systems.

Digital Object Identifier 10.1109/JSEN.2023.3312861 attempts have been made to lower the noise levels.The European Environmental Agency's most recent report estimates that solely road traffic noise affects 113 million people, but that transportation noise affects more than 20% of the European Union's (EU) population in general [2].According to a growing body of research, transport noise may disrupt sleep, lead to cardiovascular illness, hormonal imbalances, and psychological issues, and even lead to early mortality [3], [4], [5].Studies on long exposure to noise have found cognitive decline and a lower quality of life among young children [6].Moreover, compared to other energy end-use sectors, the transport sector's share of global energyrelated CO 2 emissions has grown rapidly.In particular, the transportation sector causes 29% of global CO 2 emissions [7], and reducing its impact is an important step in any climate change mitigation plan.Therefore, transportation noise and exhaust emissions are considered one of the major threats to people's health and quality of life [8], [9], [10].Indeed, vehicle noise and exhaust emissions will continue to increase in scale and intensity due to population expansion, urbanization, and unprecedented growth associated with vehicle use if there are no intelligent methods to monitor and detect these pollutants [11], [12].
According to recent scientific studies, nearly 80% of the pollution produced by road traffic is due to the highest emitter vehicles [13], [14].These small number of high-emitter road users who make excessive noise and exhaust emissions are receiving more and more attention.Several European municipalities have stated that they intend to use noise measures to keep loud show-off vehicles and motorbikes with illegal exhausts out of the city center and off of scenic backroads [15].Cities are establishing low-emission zones (LEZs) to control access to older high-emission vehicles while avoiding punitive measures against more recent automobiles that are within the prescribed threshold limit of noise and emissions [16].LEZs are essentially metropolitan districts that require certain types of vehicles, such as heavy goods trucks (HGVs), delivery vehicles, buses, taxis, and private automobiles, to meet certain emission standards in order to enter free of charge or to avoid paying a fee [17], [18], [19].Therefore, it is necessary to regulate better the actual emissions generated by vehicles in urban areas.Because of this, there is a great interest in broadly identifying these high emitters (HEs) in real time in order to be prepared to control and reduce noise and exhaust emissions.This class of high-emitting vehicles must be adjusted; therefore, accurate measurements of their noise and exhaust emissions under actual driving conditions are required.Furthermore, for Europe to become the first climate-neutral continent in the world, emissions from the transportation sector must be monitored and reduced further and quickly.
With the rapid advancement in the Internet of Things (IoT), artificial intelligence (AI), and remote sensing technologies, it is now possible to sense and analyze various environmental events in real time for a variety of the Internet-of-Vehicles (IoV) applications [20], [21], [22], [23].With the advent of advance AI, IoT, IoV, and remote sensing technologies, it is possible to measure road traffic emissions on a large scale, effectively, and inexpensively.With these technologies, communities may more effectively and fairly enhance their noise and air quality by identifying high-emitting individual vehicles and, thereby, improving traffic decision-making.Leveraging cutting-edge remote sensing technology and extensive real-time sensor data analysis, researchers are now aiming to implement effective monitoring and mitigation methods to significantly decrease noise and exhaust emissions for all modes of transportation.
An assessment of the measurement performance of remote sensing devices (RSDs) to screen vehicle emissions was carried out in [24].The main focus was on gaseous pollutants such as nitrogen oxide (NO), nitrogen dioxide (NO 2 ), and carbon monoxide (CO) from light-duty vehicles.The findings suggested RSDs as a potential technique for screening automobile emissions to determine which vehicle types and which vehicles are high or low polluters under a particular set of driving conditions.Similarly, it has also been reported in [25] that using on-road remote sensing equipment as part of an enforcement campaign to enhance urban air quality can quickly, accurately, and affordably identify high-emitting vehicles.Moreover, there have also been some projects such as Life GySTRA1 that used RSDs to detect HEs on the road and then be checked for accuracy at a well-equipped inspection station [13].By taking such measures, their emissions may be brought down to levels that are typical for vehicles, which would greatly reduce overall road transport emissions and, in turn, the health problems that air pollution brings about.Data-driven analysis was used in [26] to assess how the electrification of the city of Rome's public transportation system and private vehicle fleet will affect energy demand, climate change, and air pollution emissions.However, all of these studies focused on monitoring vehicles' gaseous (exhaust) emissions and identifying HEs.In addition, research has been done on mapping, modeling, and measuring the amount of traffic noise in urban areas such as [27], [28], [29], [30], and [31].
Even though there is research on the noise and exhaust emissions of vehicles, these systems are either ineffective at measuring actual driving conditions or require a single vehicle to be installed intrusively and used for a long period to collect reliable data.Therefore, it is obvious that real-time measurements of the different types of vehicle noise and exhaust emissions are not readily available.This makes it challenging to accurately analyze and estimate the noise and exhaust emissions from various types of vehicles in real time.In addition, real driving emissions (RDEs) refer to the emissions produced by vehicles in real-world driving conditions.This type of testing accurately assesses vehicle emissions on an individual basis, while they are actually being driven.Unlike traditional laboratory testing, RDE testing evaluates vehicle emissions beyond controlled settings, taking into account various factors, such as speed, payload, and driving behavior.The primary goal of RDE tests is to verify that vehicles meet the emission standards as stated on paper when operating on the road.Hence, there is a need for standardized assessment techniques to improve the validity of the data gathered and the efficacy of the ensuing awareness-raising and mitigation measures.Systems built into the transportation infrastructure can assist in identifying high-emitter vehicles that do not respect the prescribed limits and, therefore, restrict their access to designated LEZs.
This work outlines the design and implementation of a real-time monitoring system for noise and exhaust emissions for intelligent and sustainable transportation systems, including road vehicles and trains, as an effort of the EU project called "NEMO: Noise and Emissions Monitoring and Radical Mitigation." 2 During the pilot testing in multiple European cities such as Rotterdam (The Netherlands), Barcelona (Spain), Florence (Italy), and the Austrian village Teesdorf, real-world sensor data from various vehicles and trains are monitored and gathered to effectively test the NEMO system and identify the HEs (both in terms of noise and exhaust emissions) in real time.We have developed a complete application that enables an analyst and an infrastructure manager to track real-time sensor data related to the noise and gaseous emissions of road vehicles and trains.The data on individual road vehicles and trains are collected in the cloud platform, assessed, and classified as high, medium, low, or normal emitters using AI-enabled classification algorithms.Through novel RSD technologies and NEMO system implementation, this article aims to provide a holistic solution to identify HEs in real time to simultaneously monitor noise and exhaust emissions for sustainable and intelligent transportation systems.

A. Comparative Analysis
In our comparative analysis of the NEMO system, it is important to highlight the novelty of our proposed solution.We have conducted a comprehensive evaluation of existing systems, and we have found that there are no comparable alternatives to the NEMO system currently available.While there are some solutions, such as the Hydra system developed by Bruitparif [32], which share certain functionalities with the NEMO system, it is essential to note the distinct capabilities and limitations of each.
In comparison to the Hydra solution, which primarily focuses only on tracking excessively noisy road vehicles, our NEMO system offers a more comprehensive approach.Unlike the Hydra system, the NEMO system is designed to detect, classify, and analyze both noise and exhaust emissions from road vehicles and also from trains.This distinction highlights the significant advantage of the NEMO system over existing competitors, as it provides a more comprehensive and accurate understanding of the impact of road vehicles and trains' noise and exhaust emissions.The NEMO system's advanced capabilities position it as an innovative and powerful tool for different stakeholders in addressing noise and pollution challenges in urban environments.

B. Article Contributions
In summary, the major contributions of this article can be outlined as follows.
1) In pursuit of the EU's commitment to monitoring noise and exhaust emissions, we present the NEMO system, a totally new autonomous remote sensing technology to accurately and cost-effectively identify and classify transgressing noisy and high exhaust emitter vehicles (including road vehicles and trains) in near real time to control noise and air quality and mitigate detrimental impacts on public health and the environment.2) We have integrated different sensors to effectively measure noise and emissions of road vehicles and trains in the existing infrastructures, which enables the NEMO system to identify noise origin in a dense traffic stream and localize HEs in real time.3) Moreover, we have also created a complete software and communication infrastructure, such as infrastructure-toinfrastructure (I2I) and infrastructure-to-vehicles (I2Vs) based on remote sensing data to enable different infrastructure integration options.4) Data from real-world field testing of individual road vehicles and trains in European cities such as Rotterdam and the Austrian village Teesdorf are collected in the cloud platform and evaluated using our AI-based classification algorithm to accurately detect and classify them as high, medium, and normal emitters.5) Finally, we present the development of a comprehensive NEMO solution.The appropriate traffic regulating agencies and stakeholders may use our NEMO system to put notification systems in place to address noise and pollution challenges in urban environments.

C. Article Organization
The rest of this article is organized as follows.Section II describes the NEMO system model.The NEMO system's functional architecture is briefly presented in Section III.The noise source detection and localization algorithm is described in Section IV.The AI-enabled classification model is presented in Section V. NEMO system deployment and its field testing results are explained in Section VI.The NEMO CDS system for real-time communication between the NEMO system and vehicles is detailed in Section VII.Section VIII outlines the NEMO system's graphical user interface (GUI) platform for road vehicles, and trains and provides the data analysis.Finally, conclusions are drawn, and future works are proposed in Section IX.

II. NEMO: NOISE AND EMISSIONS MONITORING
AND RADICAL MITIGATION SYSTEM MODEL In this section, we present our NEMO system that can measure noise and exhaust emissions from individual road vehicles and trains, and identify the HEs in real time.By empirically evaluating individual vehicles, applying customized tariffs on the most polluting vehicles, and blocking their entry to LEZs, our NEMO system seeks to develop cutting-edge RSD-based solutions to reduce emissions and noise from the transportation industry.The NEMO monitoring system model and its dataflow diagram are shown in Fig. 1.
Nautilus, an integral software infrastructure component of the NEMO system model, seamlessly merges remote sensing and data processing to effectively categorize the noise and exhaust emissions of road vehicles and trains.As illustrated in Fig. 1, Nautilus comprises four major components: the Synchronizer, the Data Hub, the classification Dialog system (CDS), and the Analytics components.In the subsequent section, we will delve into a comprehensive explanation of each of these components and their respective roles.
To facilitate the measurement of noise and exhaust emissions, remote sensing technology is strategically deployed at various locations, such as tolling stations, roadsides, and railway lines.At each site, the diverse sensor arrays capture raw measurement data, which is subsequently synchronized by the Synchronizer to obtain a holistic representation of the vehicle's noise and exhaust emissions.For illustrative purposes, we will primarily focus on road vehicles throughout our discourse.However, it is important to note that the design and interfaces of the Synchronizer can be appropriately adapted for train-specific applications by substituting relevant terminologies, such as "road," "rail," "lane," and "wagon." Upon successful synchronization of the raw data, the Synchronizer interfaces with a comprehensive vehicle registry database to retrieve crucial vehicle characteristics necessary for the subsequent classification process.These characteristics encompass aspects, such as fuel type, noise emission type, approval limits, and other pertinent details.Subsequently, this amalgamated dataset, comprising the sensor data and the aforementioned vehicle characteristics, is transmitted from the sensing site to a centralized Data Hub module.The transfer process is facilitated through a mechanism known as the "pass-by report," which allows the Data Hub to diligently store the pass-by report information, thereby generating a comprehensive registry for each passing vehicle.
Using the power of AI, the Data Hub employs an AI-enabled classification model, which is expounded upon in Section IV, to categorize the noise and exhaust emissions of vehicles.This classification process involves comparing the emissions of each vehicle with those of similar vehicles, as well as with the applicable type-approval limits or high-emitting thresholds (based on type-approval or local emission limits stipulated by the relevant authorities).Upon classification, vehicles exceeding the defined thresholds are flagged as HEs.The classification logic employed in this process can be customized to align with the specific requirements of the site, road authority, or the legislative framework of the respective jurisdiction.The resultant classifications are stored within the Data Hub for future reference.
Following the classification process, the Data Hub promptly notifies the CDS, which subsequently communicates the classification results back to the remote sensing site (I2I).In addition, the CDS conveys the classification outcomes to the respective vehicle or owner (I2V) through the HE message in near real time.Consequently, this streamlined flow of information ensures that all relevant stakeholders are promptly informed of the vehicle's emission categorization.
Finally, the Analytics component serves as an invaluable data analysis platform, facilitating in-depth studies of noise and exhaust emissions.This enables infrastructure managers and internal NEMO users to gain comprehensive insights, which can be utilized to refine the criteria for identifying highemitting vehicles, particularly in the context of LEZs.

III. NEMO SYSTEM FUNCTIONAL ARCHITECTURE
In this section, we present a comprehensive overview of the functional architecture of the NEMO system, focusing on the Synchronizer, the design of the Data Hub, and the main interfaces for the Nautilus platform components.

A. Synchronizer
The Synchronizer serves as a vital link between the NEMO system and the sensors, enabling the acquisition of sensor results.By establishing direct communication with the sensors, the Synchronizer facilitates the retrieval of sensory data related to passing vehicles.This interaction takes place through various interfaces within the measuring infrastructure, as illustrated in Fig. 1.Furthermore, the Synchronizer utilizes internet sources, such as the vehicle registration database (VRDB) service, to obtain vehicle characteristics based on identification details such as license plates or train wagon numbers, as depicted in Fig. 1.Once all the necessary data is gathered, it is consolidated into a pass-by report and transmitted to the Data Hub.
The Synchronizer constitutes a site-specific component of the Nautilus platform, tailored to a specific type of transport (road/rail) and a particular arrangement of sensors and their placement.While the fundamental operation of the Synchronizer remains consistent across various transport modes and measurement sites, this article focuses on describing the design and interfaces of the Synchronizer for the test site in Teesdorf, Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

TABLE I SYNCHRONIZER COLLECTED DATA
Austria, where Kapsch TrafficCom operates a test site.Thus, this design serves as a reference for all sites.For the design and interfaces of a railway-specific Synchronizer, terminologies such as road, rail/train, lane, and car can be substituted accordingly.
The Synchronizer process comprises several subprocesses.1) Collect data.
2) Synchronize collected data (to a pass-by report).
3) Provide a pass-by report to the Data Hub.4) Additional functionality and design considerations.These subprocesses are explained briefly here.
1) Collect Data: The subprocess of collecting data entails the Synchronizer gathering information during a vehicle passage.The Synchronizer's responsibilities within this subprocess include triggering sensors and systems to enable the measurement and data collection of passing vehicles (particularly in pilot tests where self-triggering of sensors is utilized, synchronized based on time stamps).In addition, the Synchronizer receives data from autonomous sensors and systems.Table I presents the sensors and systems that the Synchronizer interfaces with, accompanied by a brief description of the data they collect.The table also indicates whether the Synchronizer is triggered by the sensor/system or if it triggers them.
To initiate the sensors and systems, the Synchronizer initially needs to be notified of the vehicle's passage.The TollingModule pushes the information about the vehicle passage, serving as the initial step in the data collection process.Subsequently, depending on timing and vehicle type, further data collection takes place.The minimum set of sensor modules required to classify all vehicle emissions includes the VehicleIdentificationModule (e.g., the TollingModule at the Teesdorf test site), NoiseModule, ExhaustModule, and VRDBService module.
2) Synchronize Collected Data: Within this subprocess, the Synchronizer generates a single pass-by report for each passing vehicle and consolidates all the collected sensor and system data into this report.The synchronization process employs different criteria to match the data to the pass-by report of the vehicle passage, depending on the specific sensor/system and triggering type.The matching criteria used are outlined in Table II.
3) Provide Pass-By Report: During the subprocess of providing the pass-by report, the Synchronizer transmits the created pass-by report to the Data Hub.In addition, the Synchronizer sends a pass-by report to the Data Hub if one of the following conditions is met: the pass-by report is completed (i.e., all data are merged), or the pass-by report time-out is reached.The time-out mechanism is necessary since the Synchronizer lacks awareness of the functional state of the sensors and systems that it interfaces with.In the event of an error with a sensor or system, the Synchronizer must not wait indefinitely for a result.By adhering to the timeout threshold, the Synchronizer ensures the timely provision of pass-by reports to the Data Hub, avoiding any backlog.Moreover, the time-out feature enables the realization of the use case for vehicle-to-infrastructure (V2I) communication within the constraints of the vehicle passage.The time-out value is configurable within the Synchronizer.
4) Additional Functionality and Design Considerations: In addition to the provisioning of pass-by reports, the Synchronizer is capable of capturing additional information, such as images or sound clips, during a vehicle passage.While not strictly necessary to fulfill the NEMO use case, these data can assist operators in error assessment and situational analysis at the measurement site.The Synchronizer operates on hardware situated at the measurement site, ensuring minimal network latency and facilitating swift communication with road/trackside sensors and systems.Furthermore, the Synchronizer incorporates a data cleanup mechanism to comply with the General Data Protection Regulations (GDPRs).To achieve accurate matching of sensor and system data, the Synchronizer and all sensors and systems on the measurement sites synchronize their clocks using a common network time protocol (NTP) service.

B. Data Hub
The Data Hub in the cloud provides support to the following subprocesses.
2) Store the pass-by reports.The Data Hub encompasses various modules responsible for executing the subprocesses, as depicted in Fig. 2. Each module's role is elaborated upon in the following subsections.
1) Receive Incoming Pass-By Reports: In this subprocess, the Collector module receives the data.If vehicle information is not available, the Pass-By Enricher module attempts to query it from the vehicle registry.Subsequently, either the Collector or the Pass-By Enricher forwards the pass-by report to the Pass-By Queue for further processing.To ensure privacy, vehicle registration data are pseudonymized, removing any sensitive information.
2) Store the Pass-By Reports: Each pass-by report received by the Pass-By Store module from the Pass-By Queue is stored in the database for future retrieval.Separate storage areas exist for road and rail pass-by reports.The Collector module also receives health messages from different sensors.Each sensor periodically sends messages indicating its current state, whether healthy, or degraded.
8) Additional Functionality and Design Considerations: To ensure scalability, the Data Hub is designed as a collection of loosely coupled modules capable of interacting through simple protocols, such as hypertext transfer protocol (HTTP) 3 and advanced message queuing protocol (AMQP). 4This design allows individual modules to be containerized using Docker 5and deployed through container orchestration platforms, such as Kubernetes. 6

C. Interfaces
This section elucidates the principal interfaces utilized in the Nautilus platform.The underlying data model and interfaces shared by all modules are described using the OpenAPI7 specification.
1) Sensors to Synchronizer: This section elaborates on the interfaces between the Synchronizer and the sensors/systems responsible for gathering data related to vehicle passages.The Synchronizer interfaces aim to standardize communication technologies, minimizing operational costs.Details regarding these interfaces are presented in Table III, including interface identification, communicating entities, and a brief description of the scope and data exchanged.The interface naming convention follows the pattern: "three-letter abbreviation sender system"-"3-letter abbreviation receiver system"-"interface identifier" (e.g., SYN-DAH-1).Two different technologies are employed for data exchange.The sensors and systems at the measurement site employ the ZeroMQ message transport protocol (ZMTP),8 while the central system components utilize an REST 9 -based data format over HTTP.
2) Sensor Fusion: In the sensor fusion process, the Synchronizer receives image triggers from the roadside station and subsequently requests weather and noise measurement data from the corresponding stations and modules.The VRDB-Service is queried for vehicle registration information based on the license plate, which is then added to the road pass-by report upon receiving the image result [automatic number plate recognition (ANPR)].The Exhaust and V2X modules independently provide their data, triggered by their respective systems.Once all data are fused and added to the report, or a sensor timeout occurs, the road pass-by report is sent to the Data Hub.
3) Synchronizer to Data Hub: The interface from the Synchronizer to the Data Hub is specified using the OpenAPI document.Table IV provides an overview of the Synchronizer and Data Hub interface.Once the Synchronizer synchronizes the sensor data for a pass-by on-site, all relevant pass-by data are posted to the Data Hub as a JavaScript object notation (JSON) 10 document.The Data Hub's Collector API exposes POST interfaces for vehicle pass-bys and a generic interface for sending media files related to pass-bys.In addition,  • Initialize the microphone array and configure the beamforming algorithm; Data Collection: • Collect audio data from the microphone array and store it in the variable audioData; Position Estimation: • Estimate the position of the vehicle using the beamforming algorithm on audioData; • Store the estimated position in the variable estimatedPosition; Pass-by Trajectory Calculation: • Calculate the pass-by trajectory angle based on the estimatedPosition; • Store the pass-by trajectory angle in the variable passByTrajectory; Noise Interference Removal: • Obtain a list of surroundingPeakLevels; for each surroundingPeakLevel in surroundingPeakLevels do if the peak of interest value is at least 6 decibels below the smallest value in-between peak of interest and surroundingPeakLevel then • Retrieve the model curve corresponding to the vehicleSpeedCategory from the pre-trained dataset; • Overlay the neighbouring peak with the model curve for the specific vehicle speed; • Determine the contribution of the model curve at the peak of interest; • Subtract the contribution from the surroundingPeakLevel to obtain the corrected peak of interest level; return correctedPeakLevel; end end Stop vehicles within dense traffic streams.Our approach utilizes a microphone array comprising two side microphones per lane strategically placed in close proximity to the vehicles.The primary objective is to leverage these microphones to detect and locate vehicles emitting high levels of noise.The algorithm, referred to as "Noise Source Detection and Localization using Microphone Array in Dense Traffic Streams," is outlined in Algorithm 1.The algorithm begins by employing a beamforming technique to detect the primary sound source and estimate the position of the vehicle [33].Specifically, the side microphones, positioned at a height with a distance of approximately 20 cm in the driving direction, play a key role in localizing the vehicles.The determination of the source direction is derived from the signals captured by the microphones.These microphones are positioned along a horizontal array that is designed to encompass the horizontal plane.Let s m 0 ,l represent the measured sound signal of the first microphone in the lth frame, l = 1, 2, . . ., L, and s * m 1 ,l represent the complex conjugate of the measured sound signal of the second microphone in the lth frame, l = 1, 2, . . ., L. Now, the cross correlation of the lth frame is computed by the summation, as elaborated on in the following equation: where k represents the time shift between two signals, n pertains to the running index inside the specific frame of the microphone, n = 1, 2, . . ., N , and k = (−(N − 1), . . ., (N − 1).Now, the algorithm performs the maximization of c l in (1) over all the values of k and applies the following transformation to obtain the direction of the sound source as the horizontal angle: where d τ = (l/ f s l ) • c 0 , c 0 = 343 m/s is the speed of sound, f s l is the "sampling frequency" denoting how many frames are in one second, and d mic is the distance between the two microphones.
In (2), this angle α l of the source signal resembles the arctan() function, spanning a range from −90 • to 90 • .The algorithm estimates the position by processing this angle, commonly known as the "pass-by trajectory."In this context, an angle of 0 • signifies the position directly in front of the array, while angles of −90 • and 90 • represent the scenario where the vehicle is located at a far-away distance.However, an inherent challenge arises due to the potential interference caused by nearby vehicles, which can impact the accurate measurement of noise levels.To address this issue, our algorithm introduces a method called "peak level correction" [34].This method adopts a data-driven approach to correct the measured noise levels of individual vehicles by considering the contributions of nearby vehicles.The algorithm collects data from single pass-bys and generates characteristic mean level-time curves corresponding to different vehicle speed categories to achieve this.These curves serve as models to estimate nearby vehicles' contribution and correct the measured noise levels accordingly.Let us denote the model curve for a specific vehicle speed category as M(v), where v represents the speed category of the vehicle (e.g., 30, 50, and 75 km/h).
The peak level correction method is applied by examining the behavior of the noise level toward surrounding peaks.Let P be the set of detected peaks and p i represent the ith peak in P. Initially, the algorithm checks if the noise level exhibits a decrease of at least 6 decibels (dB) from the peak of interest p i toward the minimum in between p i and any surrounding peak p j .Let S( p i , p j ) represent the difference in sound level between peaks p i and the corresponding minimum of the pair ( p i , p j ), where p j is a surrounding peak S( p i , p j ) ≥ 6 dB ∀ p j . ( If such a decrease is observed as represented in (3), it suggests that the nearby vehicles' contribution is insignificant, and no further correction is necessary.However, when the decrease is below the specified threshold of 6 dB, the algorithm overlays the neighboring peak p j with the corresponding model curve based on the specific vehicle's speed.Let O j ( p i , M(v)) represent the overlaid curve of the model curve M(v) on peak p j surrounding the peak of interest p i .To calculate the contribution of the model curve M(v) at peak p i , we find the difference between the overlaid curve O j ( p i , M(v)) and the actual sound level curve s(t i ) at the peak time t i of p i .Let C j ( p i , M(v)) represent the contribution of the overlaid curve O j ( p i , M(v)) at peak p i .The corrected sound level at peak p i , denoted as C S( p i ) , is obtained by subtracting the contribution C j ( p i , M(v)) from the sound level s(t i ) at peak time t i .Hence, the correction calculation can be expressed as As shown in (4), this correction process is performed for all surrounding peaks contributing to the disturbance, resulting in a corrected maximum sound pressure level in identifying high-emitting vehicles within dense traffic streams.The proposed algorithm has been applied successfully during our testing in Rotterdam and Teesdorf (explained in Section VI).

V. AI-ENABLED CLASSIFICATION MODEL IN THE DATA HUB
The classification of vehicles as HEs or not is achieved using an AI-enabled model.This model tackles a supervised learning problem, where each vehicle measurement must be labeled during training.However, such labels are not readily available in the data configuration.Moreover, existing regulations do not provide a straightforward assessment of excessive noise based on a single pass-by measurement.A sound expectation model (SEM) has been developed to overcome this, leveraging available data and making certain assumptions to predict the expected noise level for each vehicle pass-by.
The fundamental principle underlying the SEM is characterized as follows: through the utilization of measured parameters encompassing noise levels, vehicle velocity, and engine speed during both cruising (crs) and acceleration (acc) phases, three distinct constituents are computed.These components encompass the expected tire-road surface noise level (L TR_EXP ), the expected powertrain noise level (L PT_EXP ), and the expected dynamic noise level (L DYN_EXP ).
Expected Tire Road Surface Noise Level: This component pertains to the noise generated as a result of the interaction between the vehicle's tires and the road surface.It considers factors such as the speed of the vehicle and the characteristics of the road, contributing to the estimation of the noise produced by the tire-road interface.
Expected Powertrain Noise Level: This component relates to the noise that originates from the powertrain of the vehicle, including the engine and other relevant mechanical components.It takes into account the engine speed and potentially other powertrain parameters to predict the noise produced by these elements.
Expected Dynamic Noise Level: This component captures the dynamic noise variations that occur due to changes in the vehicle's operational conditions, such as acceleration.It accounts for the dynamic aspects of the vehicle's movement and how they influence noise generation.
The collective interplay of these three facets results in an overall projected noise level.Of particular significance within the SEM framework are two pivotal components contributing to generating vehicle-specific outcomes.Primarily, the calculated parameters, as delineated, are uniquely tailored to each vehicle category and characterized by their own distinct parameter set.Second, a key aspect entails the incorporation of two discrete engine speed values: one relevant to a stable vehicular velocity scenario and another corresponding to acceleration conditions.This dichotomy arises due to the fact that the tire-road surface sound component is ascertained under constant vehicle speed conditions, while the powertrain sound component is derived during acceleration episodes.
The determination of the expected tire rolling sound component, denoted as L TR_EXP , is contingent upon the attained vehicle speed (v meas ) during measurement.Specifically, for vehicle speeds equal to or below a reference velocity (v ref ), L − TR_EXP is evaluated using the following formula: where v ref = 50 km/h, L ref_TR = 10 × log(x × 10 0.1×L meas_crs ), L meas_crs is measured sound pressure level, x refers to a parameter applicable to tire rolling sound energy fraction of L meas_crs , and θ TR_LO is low tire rolling sound slope parameter and is taken in accordance with the relevant vehicle characteristics.For vehicle speeds exceeding V ref , L + TR_EXP is computed as where θ TR_HI is high tire rolling sound slope parameter.The projected powertrain base mechanical sound component, denoted as L PT_EXP , hinges upon the attained engine speed (η meas ) during measurement.Specifically, for engine speeds equal to or below a critical engine speed (η meas_crs ), L − PT_EXP is computed as follows: Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
where L ref_PT = 10 × log((1 − x) × 10 0.1×L meas_crs ), θ PT_LO is low powertrain sound slope parameter, and η SHIFT_PT is the form factor for the logarithm function of the mechanical sound model.
Similarly, for engine speeds exceeding η meas_crs , L + PT_EXP is computed as follows: where θ PT_HI is high powertrain sound slope parameter.
The expected base dynamic sound component L DYN_EXP is calculated dependent on the achieved engine speed η meas during the measurement.For engine speeds up to and inclusive η meas_acc , L − DYN_EXP is calculated by (9) where L ref_DYN = 10 × log((1 − x) × 10 0.1×L meas_acc ), θ DYN_LO is low dynamic sound slope parameter, and η SHIFT_DYN is the form factor for the logarithm function of the dynamic sound model.
Similarly, for engine speeds exceeding η meas_acc , L + DYN_EXP is computed as follows: (10) where θ DYN_HI is the high dynamic sound slope parameter.
The dynamic delta sound component, denoted as L DYN_EXP , is calculated through the following equation: where L DYN = 10 dB.The outcome of each component's calculation contributes to determining the expected sound level for a particular measurement.This anticipated sound level is subsequently compared to the maximum measured sound pressure level.The methodology employed in this SEM draws inspiration from the formulas utilized in the new draft-type approval test for vehicle noise under real driving conditions, part of the Additional Sound Emission Provisions (ASEPs) in UNECE Regulation 51 [35].To establish a reference noise level for "normal" vehicles, we adopt an approach based on the vehicle's speed and acceleration.We aim to determine the reference noise level, denoted as L Amax,ref , by fitting a function to the data.The function is defined by the following equation: where v represents the vehicle speed in km/h, a represents the acceleration in m/s 2 , and c 0 , c v , and c a are coefficients specific to each vehicle category (such as M1 and N1).By finding the appropriate values for these coefficients, we can establish a reliable reference noise level that accounts for the vehicle's characteristics and contribute to the accurate identification and categorization of vehicles based on their noise emissions.This computational scheme produced a calculation model based on laws governing vehicle noise as a function of vehicle characteristics and driving parameters (speed, acceleration, and engine speed), including tire/road and propulsion noise separately.Each pass-by is given a label by comparing the expected level with the actual measured sound level, i.e., if the difference between the measured and expected sound level is more than 8 dB(A), the pass-by is considered an HE.Hence, the available data can then be used to create and train a supervised AI-enabled classification model using this labeling of HEs.Please refer to [15] for more details on the SEM used for our NEMO system.In order to optimize the performance of the AI-enabled classification model, data preprocessing and filtering techniques were employed to separate relevant data from irrelevant data.After evaluating eleven different AI models and considering their scores, advantages, and disadvantages in terms of accuracy and computation time, it was decided to proceed with a neural network, specifically a multilayer perceptron classifier [36]) as an AI model for classification.This was done over continuous testing of AI models with the data.More details on the evaluation of different classification models and selecting the AI-enabled classification model can be found in [15].The TensorFlow API 13 was utilized to develop the final model, which was rigorously assessed using separate training and test data to mitigate overfitting.Hyperparameter tuning was also conducted to further reduce the risk of overfitting.The resulting AI-enabled classification model was deployed in the Nautilus cloud platform, demonstrating accurate classification of high-noise emitters.It should be noted that this model specifically addresses high-noise emitters and does not encompass exhaust emissions.Furthermore, it is sitespecific and can be customized based on regulations governing vehicle noise, pavement type, the influence of nearby reflecting objects, and exhaust emissions.in Rotterdam.The findings in this figure unveil a noteworthy trend: vehicles tend to be categorized as illicit HEs when operating at reduced and lower engine speeds.This occurrence can be attributed to the type approval system, which grants vehicles the leeway to generate amplified noise levels at elevated engine speeds.However, if the objective is to evaluate and subsequently modify driver behavior, an alternative classification methodology can be employed.This approach not only recognizes vehicles as high-noise producers due to aggressive driving styles but also endeavors to influence drivers toward adopting a more considerate approach on the road.

VI. NEMO SYSTEM DEPLOYMENT AND TESTING
In order to test the NEMO system to identify the high emitters, the system was successfully deployed in Rotterdam, Florence, and Teesdorf.Owing to space constraints and for the sake of brevity, we only explain here the deployment of the NEMO system in Teesdorf.However, the deployment of the NEMO system will be more or less the same in other testing locations as well, subject to the adjustments of placement of cameras, microphones, and installations of different sensors.
The NEMO Nautilus platform was deployed partly on-site and partly in the Google cloud. 14The measurement-specific parts, such as the sensor-communication modules and Synchronizer, are deployed at the sensing site.These components need to be deployed on-site to ensure low-latency communication.The Data Hub is also deployed on the Google cloud.The VRDB service that interfaces between the Synchronizer and the vehicle registry databases of various authorities is also deployed as a cloud solution.A simplified overview of the deployment for the Teesdorf (Austria) test setup with different modules is shown in Fig. 4.
The Synchronizer services are deployed on a dedicated computer system on the measurement site.The Data Hub module (including the VRDBService module) is a collection of Linux Docker containers orchestrated via Kubernetes.The communication between the on-site and cloud components within Nautilus is done via a site-to-site virtual private network (VPN).This adds a layer of security and obviates the need for an extra layer of authentication and authorization between different modules.The Analytics module provides access to the data inside the Data Hub.The Analytics module handles the authentication and authorization of users, and the Data Hub trusts the Analytics module.An NTP server is made available for time synchronization between on-site sensors and systems.

A. Teesdorf Hardware Setup
A hardware setup illustration and a Teesdorf test site setup for testing the NEMO system are shown in Fig. 5.The figure clearly shows the planned hardware setup that illustrates the required equipment and rough location.Next to hardware equipment, the figure shows configured trigger lines for vehicle detection and the zone for V2X vehicle data readout.It also represents the NEMO installation integrated into an enforcement station for a highway installation.The station spans three lanes, two driving lanes, and one hard shoulder.The hard shoulder is not subject to testing and is not fully equipped with NEMO or tolling sensors.For safety reasons, the road is delimited with concrete jersey barriers.To support motorcycle use cases, rear cameras are needed to read the license plates.The equipment installed at the Teesdorf test site for testing the NEMO system is outlined in Table X.

B. NEMO System Testing
Several tests were executed at the Teesdorf test site in Austria to check the performance of our NEMO system in identifying HEs and communicating the classification message in real time.For instance, tests were performed for a road pass-by car with a vehicle speed of 70-and 50-km/h honking.In the first test case, the passenger car was equipped with a Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

TABLE X TEESDORF HARDWARE SETUP LIST
V2X OBU and passed the test gantry at a speed of 70 km/h, where we tested the vehicle for high noise and high exhaust emission.The test was done to check if our NEMO system could detect and perform the correct classification for the vehicle.The test case is considered passed as a V2X message with a resultId of 3 was received.Please refer to Table XI for different resultId and their corresponding descriptions.The resultId "3" was part of the solution space and indicated a high noise and high exhaust emission.This was correctly reflected by the V2X OBU screen, as shown in Fig. 6(a).In the second test case, the passenger car with a V2X OBU passed the test gantry with a 50-km/h speed.The car accelerated to the target speed and rolled through the gantry.Thus, neither engine exhaust emissions nor engine noise emissions were generated.Only rolling noise was generated.To generate additional noise, honking throughout the passage was performed.The expected result was a high-noise emitter message.The test case is considered passed as a V2X message with a resultId of 1 was received, matching the expectation.The resultId "1" was also part of the solution space and indicated a high noise.The V2X OBU screen correctly reflected this, as shown in Fig. 6(b).Similarly, several other test cases were executed with passenger cars and motorcycles under different driving conditions to test the NEMO system for correctly detecting and identifying HEs (both in terms of noise and exhaust emissions), and their corresponding classification data were recorded in the Data Hub for further analysis.The pilot testing of the NEMO system at Teesdorf and Rotterdam successfully detected and identified the HEs in real time under different driving conditions.Also, real-time classification messages from the CDS system were tested and are explained in Section VII.

VII. CLASSIFICATION DIALOG SYSTEM
The main aim of the CDS is to inform the results of the pass-by classification to the vehicle owner or directly to Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.the driver in real time.The communication's ultimate goal, whether it be purely informative or regulatory (such as a message restricting entrance to an LEZ), is a political decision and is, therefore, outside the scope of this article.The appropriate traffic regulating agencies and different stakeholders may use these developments to put notification systems in place for any purpose they see necessary.

A. General Considerations for CDS
The CDS system aims to promptly notify vehicle owners of real-time pass-by classification results.To achieve this, a CDS server based on NodeJS 15 has been deployed on the Google Kubernetes Engine (GKE).When the vehicle classification results reach the CDS classification endpoint, it triggers an emitter message for V2X OBU communication.In addition, a separate communication channel has been established for mobile applications, email, and mobile messages to receive the classification and emitter messages from the CDS in real time.
The CDS system also considers tolling fee calculations based on vehicle emission classifications, which are communicated via email and mobile messages.The following conditions serve as an example for tolling fee calculation and communication in real time.
1) If the vehicle is classified as an HE for both noise and exhaust emissions, then CDS will calculate tolling fees of 3 C. 2) If the vehicle is classified as a low emitter for noise and an HE for exhaust emission, then CDS will calculate tolling fees of 2C. 3) If the vehicle is classified as an HE for noise and a low emitter for exhaust emission, then CDS will calculate tolling fees of 1C. 4) If the vehicle is classified as a low emitter for both noise and exhaust emissions, then CDS will calculate tolling fees of 0C.For V2X OBU communication, the CDS sends the emitter message containing the corresponding resultId as soon as classification messages are received.The resultId and their descriptions implemented in the CDS for the Teesdorf test site are listed in Table XI.

B. I2V Communication
The NEMO classification outcome is communicated directly to the vehicle through the I2V communication channel.The CDS determines the feasibility of I2V communication based on the presence of a V2X OBU passage indicated in the road pass-by report.When the I2V communication channel is available, the CDS generates the emitterMessage, which includes an identifier and the corresponding resultId as specified in Table XI.The identifier is a temporary V2X OBU ID extracted from the road pass-by report being classified.
The CDS identifies the target roadside station for delivering the emitterMessage and transmits it to the I2V communication module.From there, the emitterMessage is passed to the V2X module, which, in turn, sends it to the V2X OBU.The V2X OBU, upon receiving the emitterMessage, searches for customized pictograms and text associated with the result code and presents the classification outcome to the driver through a display.To display the message correctly, the V2X OBU relies on the resultId provided.Fig. 6 illustrates a successful test of the I2V communication from the CDS at the Teesdorf test site, demonstrating the practical implementation and functionality of the system.

C. Email and SMS Communication Channel
Email and mobile SMS are widely recognized and commonly used digital communication methods.In our system, vehicle owners receive timely updates via email and SMS, including relevant vehicle information, tolling fees, and classification results from the CDS.To facilitate this communication, we have implemented an email server using Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.Nodemailer 16 in NodeJS, enabling the successful delivery of detailed information from the CDS through emails.In addition, the CDS NodeJS server utilizes the Twilio17 API to send real-time notifications via mobile SMS to vehicle owners as soon as classification results are received.
The successful testing of the email and real-time mobile message (SMS) communication path at the Teesdorf test site demonstrates the effective functioning of these communication channels.When classification data reaches the CDS classification endpoint, an email is promptly sent to the vehicle owner, and a near real-time SMS notification is also dispatched from the CDS.This ensures that vehicle owners are promptly informed of the relevant information related to their vehicles.

D. Mobile Application
A mobile application specifically designed to relay classification results, particularly for vehicles identified as HE, has  Comparison of L A,max for normal-medium-high emitters against the speed of the vehicle at the Rotterdam site.
been developed.The mobile app notifies the vehicle owner when their vehicle has been classified as an HE.Consequently, the owner will be informed that entering certain zones is prohibited.In addition, the owner will be prompted to inspect their vehicle for any malfunctioning components, such as through a periodical technical inspection (PTI) check.
Considering the legal restrictions on reading phone messages while driving, the mobile app utilizes mobile messages as a non-real-time communication channel between the vehicle owner and the driver.This ensures that important information can be conveyed without compromising safety regulations.

VIII. NEMO GRAPHICAL USER INTERFACE
The Analytics component of the NEMO system serves as a powerful data analysis platform for both internal use and the infrastructure manager.It enables the comprehensive examination of recorded noise and emission levels stored in the Data Hub.This functionality proves valuable for local transport authorities and councils, as it allows them to establish appropriate thresholds for high-emitting vehicles.
In compliance with the European GDPRs, the NEMO system has implemented measures to safeguard privacy during both system implementation and roadside sound disturbance (RSD) measurements.Close collaboration with privacy specialists from city councils and the NEMO project's privacy officer resulted in the following steps.1) The ANPR device employs real-time text recognition on camera photos, ensuring that original video images are not retained.This approach prevents the identification of vehicle drivers or any other individuals.2) Audio recordings are subjected to direct evaluation using various metrics, such as dB levels, spectra, and prominence.The original recordings are promptly deleted to prevent inadvertent capture of private audio information, including speech.The NEMO system's NAUTILUS platform supports the analysis of noise and exhaust emissions from both road and rail vehicles.To access pass-by and classification data, the Analytics module verifies the credentials provided by the Query Interface.This interface, implemented using Hasura GraphQL, 18 requires the retrieval of an initial token by the Analytics module.The Data Hub employs OAuth 2.019 authorization with bearer tokens, which are provided by auth0.com.An automated machine-to-machine authentication process facilitates secure communication between the Analytics module and the Query Interface.
For user access to the Analytics user interface, a dashboard with a login page and protected routes has been developed.Only authorized NEMO infrastructure managers or expert users are given credentials, such as a predefined username and password, to gain entry into the NEMO GUI dashboard.

A. Graphic User Interface for Road Infrastructure
As shown in Fig. 7, the NEMO expert user can click on the vehicle dashboard to view the results related to vehicle data after successfully logging in.The expert user can learn the high noise and exhaust emission vehicle classification by using the querying interface with different vehicle attributes.The query's outcome will be returned, and the outcomes will be shown in the form of tables and charts.An expert user such as an infrastructure manager has different options, for example, based on normal/high/medium emitters, site ID, and so on, to choose from to view the classification results as shown in Fig. 8.
For instance, data pertaining to medium-high emitters at the Rotterdam test site from February 22, 2022, to February 25, 2022, are displayed in a table format for enhanced visualization (see Fig. 9).The table shows the first ten rows, but additional data can be accessed by clicking the "Next" button.Sorting the table can be done by clicking on the column headers, providing direct insights into the classification of HEs.Moreover, the table data can be downloaded as a comma-separated value (CSV) file, enabling infrastructure managers to perform further analytics and visualizations.The CSV format facilitates analysis using tools, such as Microsoft Excel, MATLAB, and Python.
The dashboard tables offer the infrastructure manager the ability to query specific data using search fields.For example, Fig. 10 presents data from the Teesdorf test site, where the infrastructure manager can view information solely on vehicles fueled by diesel.The table in Fig. 11 showcases data filtered by site ID and HE classification for both noise and exhaust emissions.This table provides a clear overview of HEs within the Teesdorf test site.
In addition, real-time vehicle data can be displayed using charts.For this, Chart.js, 20a free and open-source JavaScript library, is employed.It offers various chart formats, such as bar charts, line charts, and 3-D charts, along with animations.Fig. 12 illustrates the initial vehicle test classification trials, comparing L A,max (Y -axis) for normal-medium-high emitters against vehicle speed (X -axis) at the Rotterdam test site.It is important to note that the classification criteria for low, medium, and high emitters can be adjusted based on guidelines set by relevant authorities, such as city councils or transportation and environment ministries.Therefore, Fig. 12 serves as an illustrative example of the comparison between L A,max values for different emitter classes and vehicle speed.
The GUI also allows the infrastructure manager to view and analyze the information in the form of different charts, such as pie charts and doughnut charts.A comparison of     classified as normal emitters, and 7% and 19% of the vehicles were classified as high and medium emitters, respectively.However, at the Teesdorf test site, out of nearly 250 passby test vehicles, 58% of them were classified as HE vehicles as we intentionally tested the vehicles to be HEs and tested them for real-time V2X communication from the CDS system.Similarly, a comparison of high-emitter vehicles based on different fuel types can also be intuitively visualized in the form of a doughnut chart, as shown in Fig. 14.It can be seen that 55.4% of HE vehicles were of petrol type, 37.7% were of diesel type, 6.3% were of a hybrid type, and so on.This entire collection of data provides a thorough overview of the classification findings on the NEMO GUI dashboard.
Moreover, the dashboard also gives the option to the infrastructure manager to sort the data of HEs based on different types of vehicle models.A comparison of high-emitter vehicles based on different vehicle models for the Rotterdam test site (query date: February 22, 2022, to February 25, 2022) is shown in Fig. 15.This type of analytics can be further improved or modified as desired.For instance, in the LIFE GySTRA project, a methodology to define high-emitting vehicle models has been proposed.They proposed the "highemitter tendency," a ratio that calculates how many times a vehicle model is a high emitter divided by the share of that vehicle model in the analyzed fleet.This eliminates the bias that the more a vehicle model is measured, the more HEs there are.Other similar statistics can also be calculated with this NEMO Analytics dashboard GUI platform, showing it

B. Graphic User Interface for Rail Infrastructure
A site for measuring train noise emissions has been built to test the NEMO system, as indicated in Fig. 16, similar to how road infrastructure is set up.The train measurements are also recorded on the Nautilus platform.The NEMO expert user can query the rail data and analyze the information by clicking on the railway dashboard, as shown in Fig. 7.At the time of writing this article, sound classifications based on ratings such as high, medium, low, and normal were made available on the Data Hub.Currently, each train wagon's recorded noise levels are compared to the threshold limit as defined in Table XII to determine its sound emission rating.
A comparison of L A,EQ values of different classes of emitters against the speed of the train is shown in Fig. 17.It should be noted that most trains with high and medium noise ratings have L A, EQ values exceeding 85 dB(A) and travel at speeds between 90 and 100 km/h.Similarly, for more intuitive visualization, a 3-D pie chart for comparison of normal, low, medium, and high emission ratings for train vehicles is shown in Fig. 18 where we can observe that 16% of the trains were rated as HEs, while 46% were rated as low emitters according to our NEMO classification model for trains.The train authority, railway ministry, and environmental protection agencies can utilize these details to establish rules relating to the various types of emissions from train vehicles.In Fig. 19, the train data with different available parameters from the NEMO train site "nemo1" for the query period December 5, 2021, to December 13, 2021, is displayed in the form of a table for analysis in the NEMO dashboard GUI.Similar to NEMO road infrastructure GUI, the train data can also be sorted based on the "Emission Rating," "Train Type," "Wagon Type," and so on, and the respective data can be visualized, as shown in Fig. 19.
In addition to the vehicle dashboard and railway dashboard, the expert user or infrastructure manager also has the option to see different sensors' health information, such as their degraded or healthy state.The expert user or infrastructure manager can also communicate with the vehicle's owner through registered email and mobile messages from the NEMO dashboard, as indicated in Fig. 7.

IX. CONCLUSION AND FUTURE WORKS
A sustainable transportation future will depend on finding new and intelligent transportation solutions, including effective climate change mitigation.Therefore, it is imperative to Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
constantly monitor train and vehicle exhaust emissions and noise levels.Real-time access to comprehensive measurements of different vehicle noise and emission types remains challenging, impeding accurate analysis, and estimation.Therefore, to accurately and affordably identify transgressing noisy and HE vehicles (including road vehicles and trains) in near real time, in this article, we proposed and outlined the design and implementation of the NEMO system as part of an EU effort.
Our proposed NEMO system is a new autonomous remote sensing technology to accurately and cost-effectively identify and classify transgressing noisy and HE vehicles, which enables the NEMO system to identify noise origin in a dense traffic stream and localize HEs in real time.We explained the development of the cloud-enabled, highly adaptable Nautilus platform of the NEMO system that collects data from internet sources such as VRDB service, individual road vehicles, and trains.The NEMO system has been thoroughly tested for I2I and I2V communication in the field in European cities, such as Rotterdam and the Austrian village Teesdorf, which uses our AI-based classification algorithms on real-time sensor data for noise and exhaust emissions to evaluate and accurately classify the vehicles and trains as high, medium, and normal emitters.The developed NEMO GUI served as a good visualization platform to analyze classification results of road pass-by vehicles and trains that can help infrastructure managers and stakeholders develop policies on the HEs.In addition, real-time communication of classification results from the developed CDS system via different communication channels, such as V2X OBUs, email, SMS, and mobile application, serves to communicate the classification results in real time.We also describe the creation of an all-encompassing NEMO solution that can be integrated with already-existing intelligent transportation systems.We hope that the NEMO system will serve as a tool for enforcement against HEs in LEZs and other sensitive regions.
As part of our future work, we plan to explore the application of the NEMO system in analyzing noise and emissions from ships.Innovative machine learning and edge computingenabled-data processing and decision-making solutions at the edge of the network, as well as using future sixth-generation (6G) communication technology further to reduce latency and notification time to the vehicle, are potentially interesting for our future works.

E
NVIRONMENTAL noise is still one of the main drivers of environmental pollution in Europe although several Manuscript received 10 August 2023; accepted 5 September 2023.Date of publication 12 September 2023; date of current version 16 October 2023.This work was supported by the European Union's Horizon 2020 Project "NEMO: Noise and Emissions Monitoring and Radical Mitigation" under Grant Agreement 860441.An earlier version of this paper was presented at the 2022 IEEE 12th Sensor Array and Multichannel Signal Processing Workshop (SAM) held on June 20-23, 2022, Trondheim, Norway [DOI: 10.1109/SAM53842.2022.9827835].The associate editor coordinating the review of this article and approving it for publication was Dr.-Ing.Tai Fei.(Corresponding author: Ashish Rauniyar.)

Fig. 2 .
Fig. 2. Interactions between the various components of the Data Hub.

3 )
Classify the Emission of the Individual Vehicle Pass-By: Within this subprocess, the Emission Classifier module receives each pass-by report from the Pass-By Queue.Based on the site identifier in the pass-by report, the Emission Classifier applies the appropriate classification model and generates a Classification Report.This report is then enqueued in the classification queue for further processing.4) Store the Classification Reports: The Classification Store module receives each classification report from the classification queue and stores it in a database for later access.Similar to pass-by reports, road and rail classifications are stored separately.

5 )
Notify the Classification Dialog System of a New Classification Report: The Classification Notifier module receives each classification report from the classification queue and forward/pushes it to the CDS.The CDS, equipped with various communication channels, such as vehicle onboard unit (OBU) (V2X OBU), email, short message service (SMS), and mobile application, facilitates communication with multiple sites.

6 )
Provide a Query Interface for Analytics to Access Pass-By and Classification Data: The Query Interface module serves as a gateway for external Analytics components to request data.Upon receiving a data request, it retrieves the relevant Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

Fig. 3 .
Fig. 3. Maximum noise level (L A,max ) versus speed for individual vehicle pass-bys.Colors indicate engine speed (rpm).Vehicles classified as HEs are indicated with stars.

Fig. 3
illustrates the outcomes of vehicle classification using AI algorithms based on measurements conducted

Fig. 4 .
Fig. 4. Overview of the deployment of the NEMO Nautilus platform with different modules at Teesdorf.

Fig. 6 .
Fig. 6.Testing and identification of different types of HEs in real time using NEMO system.(a) Road pass-by car with high noise and high exhaust emission.(b) Road pass-by car with high noise only.

Fig. 11 .
Fig. 11.Vehicle-classification results based on site ID and HEs.

Fig. 12 .
Fig. 12.Comparison of L A,max for normal-medium-high emitters against the speed of the vehicle at the Rotterdam site.

Fig. 13 .
Fig. 13.Comparison of different classes of emitters.(a) Comparison of normal-medium-high emitters at Rotterdam.(b) Comparison of normalmedium-high emitters at Teesdorf.

Fig. 14 .
Fig. 14.Doughnut chart for comparison of HE vehicles based on fuel type at the Rotterdam site.

Fig. 15 .
Fig. 15.Comparison of HE vehicles based on different vehicle models at the Rotterdam site.

Fig. 17 .
Fig. 17.Comparison of L A,EQ for normal-low-medium-high emitters against the speed of train.

Fig. 18 .
Fig. 18. 3-D pie chart for comparison of normal-low-medium-high emission rating for train vehicles.

Fig. 19 .
Fig. 19.Train data results from the NEMO test site.

TABLE IV SYNCHRONIZER
-DATA HUB INTERFACE information from the pass-by and/or classification stores and provides it, subject to the requester's appropriate access rights.
7) Receive Incoming Health Messages: Table V presents the pass-by report handling interface.Pass-by reports are stored in a PostgreSQL 11 database, which supports JSON format.This allows querying of pass-by reports based on their individual attributes.5) Interaction With Classifier: A Classifier interface is outlined in Table VI.The Emission Classifier module manages all processes related to emission classification.It receives new pass-bys from the pass-by queue and autonomously initiates the sound and exhaust classification processes.Once completed, the classifications are gathered, and a classification report is generated and sent to the classification queue.6) Classification Report Handling: The classification report handling interface is provided in Table VII.When a new classification report becomes available in the classification queue, it is processed by the classification notifier.Similar 11 https://www.postgresql.org/to pass-by reports, classifications are stored in a PostgreSQL database, enabling searching based on individual classification characteristics.7) Data Hub to the CDS: The Classification Notifier informs the CDS about new classifications.The classification report handling interface is presented in Table VIII.8) Data Hub and Analytics Interaction: The Query Interface module facilitates the receipt of pass-by and classification reports from the Data Hub.It utilizes GraphQL 12 to define and respond to queries flexibly.The Query Interface directly retrieves data from the PostgreSQL databases.Table IX provides an overview of the Query Interface module.IV.NOISE SOURCE DETECTION AND LOCALIZATION USING MICROPHONE ARRAY IN DENSE TRAFFIC STREAMS In this section, we present an algorithm designed to address the accurate identification and localization of high-emitting Algorithm 1 Noise Source Detection and Localization using Microphone Array in Dense Traffic Streams Input : Microphone data: A sequence of audio samples collected from the microphone array Output: Corrected peak sound pressure level: A numerical value representing the corrected peak sound pressure level