A Novel Intelligent IoT System for Improving the Safety and Planning of Air Cargo Operations

Abstract

Being the main pillar in the context of Industry 4.0, the Internet of Things (IoT) leads evolution towards a smarter and safer planet. Being human-centered, rather than machine-centered, as was the case of wireless sensor networks used in the industry for decades, the IoT may enhance human intelligence with situational awareness, early warning, and decision support tools. Focusing on air cargo transportation, the “INTELLICONT” project presented a novel solution capable of improving critical air cargo challenges such as the reduction of total aircraft weight, detection and suppression of smoke and/or fire in a container, elimination of permanent moving and locking hardware, loading and unloading logistics enhancement and maintenance. In the present work, the IoT-based monitoring and control system for intelligent aircraft cargo containers is presented from a hardware perspective. The system is based on low-cost, low-energy sensors that are integrated into the container, can track its status, and detect critical events, such as fire/smoke, impact, and accidental misuse. The focus has been given to the design and development of a system capable of providing better and safer control of the aircraft cargo during the loading/unloading operations and the flight. It is shown that the system could provide a breakthrough in the state of the art of current cargo container technology and aircraft cargo operations.

1. Introduction

Since its conceptualization in the early 1980s, the Internet of Things (IoT), has revolutionized the way people work, move, trade, communicate or even live. During the last decade, concepts such as smart cities [1], smart factories [2], or smart agriculture [3] are part of our daily lives with a great impact on circular production [4] and blue growth [5], among others. Furthermore, advances in technologies such as 5G and parallel processing as well as data analysis techniques (i.e., machine learning, deep learning) enable the design and operation of large-scale digital manufacturing processes [6] and digital twins, even of an entire city [7]. A comprehensive review of the current state of the art of the IoT is provided in [8], while an overview of architectures and applications of industrial IoT (IioT) is critically presented in [9].

As a vital cell for international trade and economic development [10], the aviation industry provides USD 3.5 trillion in world economic activity which accounts for 4.1% of the global gross domestic product [11]. Focusing on its efficiency, optimization, and safety enhancement, the industry is gradually moving to the Industry 4.0 era [12]. Unit load devices (ULDs) are an integral component of air cargo operations. The International Air Transport Association (IATA) states that approximately 1 million aircraft ULDs are in service globally [13]. It provides the only rapid worldwide transportation network, which is vital to many industries’ global supply chains, used primarily to transfer time-sensitive goods. Fast delivery is essential to businesses that provide streamlined production processes or that rely on the urgent delivery of parts for machinery and equipment [11]. While in the last two decades, a large number of solutions have been presented aiming at secure and efficient transportation of hazardous or high-value cargo in the railway [14], ground transportation [15], and the shipping [16] industry, similar efforts in the aviation industry are limited. Technologies such as digital twin [17] have been introduced, but they are mainly focusing on cargo load planning and optimization [18,19], introducing RFID technology for ULD identification and monitoring (e.g., [20,21]), due to the high impact of the ULD operations on the delivery cost.

However, the occurrence of accidents regarding cargo transportation is alarmingly high. According to the International Air Transport Association (IATA) [22], ULD is one of the most common causes of aircraft damage among all ground operations. The utilization of batteries is particularly perilous, being inflammable. More than 100 incidents related to battery ignition in cargo holds have been reported since 2019, prompting the Federal Aviation Administration (FAA) to present a new regulation imposing the use of fire suppressant ULDs, to avert potential life-threatening emergencies [23]. The European Union Aviation Safety Agency (EASA) in the latest accident report [24], included the cargo handling risk among the major risks in the industry. Furthermore, in a recent report on the impact of COVID-19 in the aviation industry by EASA [25], it was emphasized that systems enabling ULD status monitoring are crucial for cargo handling and the elimination of human mistakes. Although there are examples of studies developing frameworks for remote monitoring and cargo handling [26], structural health monitoring approaches [27,28,29], and intelligent systems for fire detection [30,31], to the best of the authors’ knowledge, the currently available solutions do not comprehensively support remote monitoring and control of the container parameters regarding their structure, status, location, fire and smoke warning indication. In this regard, recognizing its necessity, through its project called “Interactive Cargo” [32], IATA targets establishing a new regulatory regime to enable the use of connected devices to monitor the transported cargo.

To address these issues, the “INTELLICONT” project integrates the best available technologies with novel solutions to enhance situational awareness and support relevant crew and technical staff in the execution of their duties and involvement. In our previous work [33], we described from the software point of view the intelligent human–machine interface that provides a novel visualization tool for loading and flight crew. The objective of the current work is to describe from a hardware and embedded software perspective, the novel intelligent remote monitoring system (RMS) that enables the accurate acquisition of the status and condition of the ULD as well as the fast and secure transportation of relevant data to the HMI and the loading/unloading robotic platform and status placement of aircraft cargo. The platform’s design was based on LAROS [34] and PrismaSense [35] systems, which were redesigned to comply with the specifications of the INTELLICONT project and the standards of the Aviation industry [36] and includes the five layers of modern IoT [37]. Focus has been given to the validation (lab-scale testing) and verification (field testing) of the system.

The main innovation of our work is the development of a system capable of integrating a hybrid cloud-fog-edge-mist data fusion pipeline in the aircraft and cargo-loading environment that is also capable of receiving a feed from sensors using any protocol in real-time, running IoT-enabled applications in a scalable manner for real-time control and analytics, providing transient storage, performing analysis on the IoT data collected from the sensors and data from other sources (e.g., external, third party) to gain business insight and handling application rules to the fog nodes based on these insights.

The rest of the article is structured as follows: Section 2 presents a detailed description of the system’s concept. Section 3 demonstrates the integration and the testing undertaken. Finally, in Section 4, the conclusions from this study are summarized.

2. System Description

The four fundamental parts of the developed system, which is presented in block form in Figure 1, are the ULD that incorporates sensors for monitoring its status and condition, the robotic platform that loads the ULD into the cargo compartment of the aircraft, the remote monitoring and control system (RMC), located inside the ULD, that collects data from the sensors placed on the ULD and transmits them to the fourth part of the system, which is the human–machine interface (HMI), via Wi-Fi. The HMI, via a dedicated application developed for the project, transfers data from the RMC system to the robotic platform during the ULD’s loading onto the aircraft up until it is securely locked inside the aircraft’s cargo compartment so that the robotic platform can monitor the ULD’s locking state at all times. It also allows the captain and the crew members to monitor the status of each ULD loaded on the aircraft during flight.

Before the loading of a ULD onto an aircraft, a unique ID for this ULD is generated and sent to the HMI. This ID is transmitted via Wi-Fi to the robotic platform carrying the ULD inside the aircraft’s cargo area and helps it lock securely in place inside that area. During the loading of the ULD onto the plane, the data received from the sensors are periodically sent to the HMI in the form of a status report. In case of an emergency event, during which an alarm signal must be sent to the HMI to inform the aircraft crew, an additional transmission to the HMI takes place between the periodical transmissions. A processing unit integrated into the RMC performs all data collecting and processing operations. The HMI also offers visualization of data retrieved from the sensors. The RMC system can control three basic operations: (a) structural health monitoring of the ULD, (b) fire and smoke detection, and (c) supervision of the locking status of the ULD. The RMC system architecture is shown in Figure 1.

The choice of Wi-Fi communication over any other originated from the design choice to use an HMI device that would be capable of creating a wireless network, collecting data from all ULDS, and visualizing the state of all ULDs loaded on the aircraft. The authors found the best choice was for it to be a portable device such as a tablet or a smartphone, which would be able to run an application for collecting data from the ULDs and presenting them to the crew members, host an SQLite database for ULD data local storage, as well as create a wireless network for the ULDs to connect to and send their data. The most popular solution for wireless network implementation on a portable device is currently a Wi-Fi network that many tablets and smartphones can provide right out of the box, with no need for hardware or software add-ons.

2.1. Hardware

In this paragraph, the elements that form the INTELLICONT system are presented, alongside their main features. Figure 2 illustrates the various components of the system in block diagram form, as well as the way the various subsystems communicate and exchange data.

Sensors: Four different types of sensors are mounted on the ULD, for measuring various parameters of the ULD’s locking state and status during flight, as presented in

Table 1. Type of sensors mounted on ULD.

Type	Use	Sensors per ULD
Piezoelectric sensors	Structural health monitoring (SHM)	3
Smoke detector	Fire, temperature, humidity	1
Contact switches	ULD lock status indication	8
Position sensors	ULD lock status indication	8

.

In each corner of the ULD’s baseplate, which is mainly used for moving the ULD around and locking it in place inside the cargo compartment of the aircraft, there is a box of contact switches and position/magnetic sensors for monitoring the ULD’s locking pins position and, via this, whether the ULD has been successfully locked in place. The ULD’s locking pins comprise a ferromagnetic material, able to cause excitation to the magnetic sensors and, of course, push the contact switches inside the locking pin box. Each box contains two (2) contact switches and two (2) position sensors, for detecting the position of the locking pin. A pair of sensors consisting of a contact switch and a magnetic sensor is placed near the spot in which the ULD’s baseplate comes into contact with the aircraft’s cargo compartment baseplate so that the magnetic sensor can be excited and the switch can be pushed once the locking pin has been released from its box and locks the ULD securely onto the cargo compartment baseplate. The other pair is located deep inside the locking pin box and its sensors can be triggered only once the locking pin has been fully withdrawn, the ULD has been released from the cargo compartment baseplate and it can move. There are four locking pin boxes inside the ULD’s baseplate, guaranteeing the ULD’s secure locking during flight, and eight (8) contact and position sensors in them, ensuring proper monitoring of the locking state of the ULD both during the loading/unloading processes and during flight.

Each ULD also incorporates three piezoelectric sensors that can monitor any impact on the container. The arrangement of the piezoelectric sensors on the ULD is as follows: one sensor is placed on the horizontal structural beam of the long side of the ULD, one is placed on the horizontal structural beam of the shorter side of the ULD, and one on the vertical structural shaft of the container. This placement provides better monitoring of the stresses which the container may suffer due to an impact.

The smoke detector is placed on the container’s ceiling, where smoke is quickly concentrated in case of fire.

Table 2. Sensors—technical specifications.

Type of Sensors	Output/Characteristics	Value
Piezoelectric sensors	Output voltage	100 mV to 100 V depending on force or circuit impedance
Smoke detector	Temperature and humidity measurements	°C/%RH
Contact switches	Operating frequency	30 operations/min (max)
Position sensors	Supply voltage	4 V to 10 V DC
	Output voltage	1.75 V to 2.25 V
	Typical sensitivity	0.90 mV/Gauss
	Operating temperature	−40 °C to 100 °C

presents the three types of sensors mounted on the ULD, along with their technical specifications.

RMC mainboard: The mainboard of the RMC is the cornerstone of its architecture and every peripheral component (piezoelectric sensors, smoke detector, contact switches, and position sensors) is connected to it. The board also undertakes the monitoring and control of their operations, along with data collection and its processing. It is powered by the power supply board, providing the necessary voltage levels for its operations. Lastly, the mainboard includes a USB port and a Wi-Fi communication module enabling the transmission of the received data to the HMI. Figure 3 demonstrates the utilized RMC mainboard.

Microcontroller: The mainboard includes an ultra-low-power microcontroller, the MSP430F5359 by Texas Instruments. It features a powerful 16-bit RISC CPU, 16-bit registers, and constant generators that contribute to maximum code efficiency [38].

Wireless module: The communication between the HMI and the mainboard is achieved by a dedicated microcontroller, the Espressif ESP32 [39], supporting communication in 2.4 GHz, 802.11 b/g/n, Wi-Fi and Bluetooth. The communication protocol selected is MQTT [40]. It was chosen due to its lightweight, low power, small bandwidth, easy-to-use characteristics, and extended use in IoT applications.

CAN bus module: The CAN protocol allows microcontrollers and devices to communicate with applications without a host computer. In the INTELLICONT system, the CAN bus module is used to achieve communication between the microcontroller and the smoke detector. The CAN controller used is MCP2515. It is a second-generation stand-alone CAN controller, and it includes features like faster throughput, data byte filtering, and support for time-triggered protocols [41].

Power management unit: The power management unit comprises two separate units: the power supply unit and the power switching and monitoring unit. The power supply unit is designed to provide diverse levels of voltage needed for the operation of the microcontroller and every sensor interface of the mainboard out of a single 24 VDC input. However, it is also capable of supplying the required voltage for an input voltage as low as 10 V. It can also provide an adequate amount of current for each device’s operation within its electrical specifications. The unit provides five separate DC voltages: +24 V, +12 V, −12 V, +5 V and +3.3 V.

The power supply unit incorporates several safety features that make it eligible for installation on an aircraft, according to the CS-25 certification requirements for aircraft [36]: it provides power isolation of 1500 VDC for protection of sensitive and expensive equipment such as the smoke detector; it features choke inductors for current limitation, proper fuses for overcurrent protection of all the main board’s devices and sensor interfaces, as well as reverse polarity protection circuitry. Moreover, it is designed to isolate its input reference voltage from its output reference voltage to eliminate input noise propagation and ground loop problems.

The power switching and monitoring unit consists of two battery packs that provide a constant voltage between 12 VDC and 17 VDC and three submodules. The first submodule constantly monitors the voltage of the two battery packs powering the device. In case the voltage of the battery pack drops below a certain level, it instantly switches to the second battery pack, provided that it is charged, to supply the device. The switching between the two battery packs is instant so that the functionality of the device is not affected and there is no downtime for the system. Each of the other two submodules monitors each battery pack’s charge level so that it can be presented to the aircraft’s crew via the HMI. The power switching and monitoring unit incorporate several safety features, such as battery overheat protection, so that it can ensure that its battery packs operate within their proper operating limits at all times. Therefore, the power switching and monitoring unit is an integrated unit that can provide power redundancy to the system and inform the aircraft’s crew about the charge level of the battery packs. Each battery pack, when fully charged can provide uninterrupted power to the system for 16 to 18 h, depending on the time interval between two consecutive reports and the number of ULDs that are being loaded and unloaded on the aircraft. Therefore, two fully charged battery packs can provide power to the system for 32 to 36 h, being able to fully support long flights.

2.2. Embedded Software

The microcontroller MSP430F5359 is responsible for receiving and processing data from the sensors installed in the ULD. It also acquires the battery monitoring modules’ data to update the HMI with the battery packs’ percentages. After initializing the application, calibrating the piezoelectric signals, and initializing the smoke detector, the communication between the microcontroller and the wireless communication module is implemented.

The wireless communication management microcontroller, ESP32, initially establishes a connection with the MSP430F5359 microcontroller and then scans for nearby Wi-Fi networks with a predefined SSID. After a successful Wi-Fi connection to the HMI wireless network, the ESP32 connects to the MQTT server hosted by the INTELLICONT HMI.

The INTELLICONT embedded software can set the ULD and the RMC unit in three different states: (a) “Idle”, during which the system does not send any report to the HMI. (b) “Lock”, during which the ULD sends one lock report to the robotic platform every 100msecs. The lock report contains two variables that correspond to the locking sensors’ state. When the robotic platform receives the appropriate values of the variables, the load or unload mode of the ULD is enabled. (c) “Normal”, during which the ULD sends periodic reports of the values of all the sensors of the ULD to the HMI. The reporting period is configurable via the HMI ULD dashboard.

2.3. Human–Machine Interface (HMI)

ULD–HMI communication protocol: The communication between a ULD and the HMI is achieved through the message queuing telemetry transport (MQTT) protocol. It is a lightweight, public-subscribe network protocol that transports messages between devices. It usually runs over TCP/IP and is designed for connections with remote locations where a “small code footprint” or limited network bandwidth is required [40].

In the RMC system, the electronics board located inside the ULD functions as an MQTT broker, collecting requests from several HMI clients and routing the appropriate messages to each one of them. As referred to in [40], every ULD using predefined credentials communicates with the available HMI. Final MQTT credentials are autogenerated according to a predefined hash algorithm and an encryption token. The next step is the ULD reconnection to MQTT using the last credentials. The replacement of sensitive data with randomly generated data can secure the platform from hackers’ attacks and data theft. Tokens cannot be reversed independently of the platform. Security checks and requirements for identity verification also prevent token exchanging. To enhance the security of the ULD system, the communication is based on an MQTT Ack–encryption key exchange, that occurs between the ULD and HMI. The exchange of the key and the establishment of the communication is taking place only after the connection to HMI’s MQTT server is successfully achieved with preconfigured static settings.

Human–machine interface (HMI): All actions performed by the HMI application are executed locally and through the device’s local network. A local database was created using SQLite to address communication with the aircraft containers (ULDs) and the robotic platforms (RP). The HMI application was developed using Xamarin. Forms (28.0.0.3) [42] to cover the main operating systems running on mobile devices (Windows, iOS, Android). Figure 4 presents the developed system’s use cases, upon which the HMI application design was based.

Moreover, the platform’s major interconnected entities and their roles are further explained in the following:

• Application user. The user of the HMI application can control the MQTT server’s state (active/inactive) and modify its details such as its IP and communication port, the data visualization for RPs and ULDs, and the operation of the robotic platform, according to the predetermined pipeline.
• Robotic platform. The robotic platform is responsible for connecting, transporting, loading, and locking ULDs. It can connect to the application’s MQTT server, interact with the user by following predefined steps in its pipeline, and connect to ULDs assigned to it.
• ULD. The ULD is responsible for data retrieval from the sensors placed inside the container. It can connect to the application’s MQTT server and transmit data from its sensors to the server.

A typical screenshot of the HMI application’s dashboard, where an overview of all the connected ULDs is summarized, is presented in Figure 5. As shown, the locking pin sensors are shown in red because no locking pin is near any sensor or touches one.

For each ULD sensor state report, a specific color representation has been selected for the most effective visualization of the measured data in the HMI application, as presented in Figure 6. Specifically, if the value of a magnetic sensor is above a predefined threshold, the indicator for the corresponding sensor is depicted in green in the application, as is the case for magnetic sensors 3 and 4 in Figure 6 (left). If it is under the threshold, the sensor is displayed in red. For the piezoelectric sensors: when the value of a piezoelectric sensor is above a threshold that can be set via the application, the indicator for the corresponding sensor is red. If it is under the threshold, the respective indicator is green. There is no color indicator for the smoke detector, but the smoke measurement, the temperature, and the humidity are shown as numbers in each status report. Regarding the switches, if a switch is pressed, the indicator of the corresponding sensor in the application is green; conversely, the indicator is red. The HMI operator can change several parameters regarding the data acquisition from the sensors, including the thresholds for the piezoelectric sensors, as depicted in Figure 6 (right).

2.4. Housing

The RMC system is integrated into two boxes: the processing and communication modules are placed inside one box and the power supply system (batteries and battery monitoring modules) are placed in the second one. One pair of boxes was installed in each ULD for the field tests. The boxes were mounted on the inner part of the ULD and very close to its ceiling. Figure 7 (left) depicts the 3D models and dimensions of the primary box. Figure 7 (middle and right) shows two photos of the first box during the RMC assembly process.

3. System Integration and Testing

3.1. Laboratory Testing

After the initial development phase, the system underwent several laboratory tests. In what follows, a summary of the results of laboratory evaluation tests performed on the hardware components and software services is presented. Figure 8 shows the RMC hardware fully connected for testing. During these tests, the system was supplied by an external power supply, which provided 24 V/0.75 A constantly. The components selected, including the sensors and the electronic boards, were the same as those that were eventually installed in the container during the system’s field testing.

Regarding the hardware of the system, the main functionality tests that were performed during the laboratory testing included continuity and functionality testing of each electronic board. Each test described in the following was performed at least five (5) times, according to standard laboratory testing practice. The system was also tested while powered by batteries. When tested, the battery switching and monitoring units were configured to sufficiently supply the system.

The continuity and functionality tests of the power supply and the mainboard showed that there were no unwanted short circuits on the PCBs or crosstalk between neighboring signal tracks. The power supply board and the power management unit were able to provide adequate power to the mainboard and the sensors. The power management unit’s redundancy functionalities were also tested by connecting and disconnecting several power cells during the system’s operation. The tests showed that the power management unit seamlessly transitioned between the two battery packs, without interrupting the system’s functionality. The minimum voltage level for the operation of the system was also tested during this test phase, by powering the system via a bench power supply in which the output voltage was gradually lowered. The system worked properly with a minimum power supply voltage of 10 V.

Every sensor that was going to be installed on the ULD was also tested to be read successfully by the RMC mainboard, using an oscilloscope, tracing its signal along the analog tracks of the mainboard, and making sure that it ended up properly in the corresponding microcontroller input. To test the contact sensors, each switch was pushed and its output change was measured on the mainboard. The position/magnetic sensors were tested by placing either a magnet or a ferromagnetic object near them. The smoke detector that communicates with the microcontroller via CAN bus was also tested, by placing two oscilloscope probes on the CAN bus signal lines and monitoring the CAN high and CAN low signals during the system’s normal operation. The two signals arrived simultaneously in the microcontroller’s input, without any phase shift or loss of power. The various functionalities of the embedded software of the system were tested using a serial monitor.

The first group of functionality tests were to do with the RMC’s initialization and communication with both its sensors and the HΜΙ. The device successfully initialized all of its functionalities and established its communication with the HMI during every test performed. Several tests regarding the embedded software’s ability to re-establish the RMC’s communication with the HMI once the connection between them had been temporarily lost were also performed by detaching the antenna of the RMC board and re-attaching it after a while. The communication between the devices was successfully re-established every time. The second group of tests involved acquiring data from every sensor of the ULD. During this testing phase, every sensor was excited and the effect of this excitation was monitored via the reports that the embedded software sent to the RMC’s serial output. Figure 9 shows one of these reports. The values labeled as “Mag” represent the digitized output of the position/magnetic sensors, “Pz” indicates the values of the three piezoelectric sensors, “Switches” is a two-digit hexadecimal number corresponding to a switch press combination, “WiFi.RSSI” indicates the Wi-Fi signal strength and “Battery 1” and “Battery 2” indicate the percentage of each battery pack. The fields “Smoke Status”, “value”, “threshold”, “humidity” and “temperature” correspond to measurements, status indications, and alarms collected from the smoke detector. During this test, the proper orientation of the sensors was determined, since placing a ferromagnetic object on one side of the sensor increased the sensor’s output while placing the same object on the other side of the sensor or changing its orientation, resulted in a decrease of the output of the sensor. The thresholds of the magnetic and piezoelectric sensors’ outputs, above which the device was going to send a status change indication, in the case of the magnetic sensors or an alarm in the case of the piezoelectric sensors, to the HMI were also initially set during this testing phase. The final values of the thresholds were determined during the field testing phase of the system.

The correct battery voltage reading of the microcontroller was also tested, by simultaneously monitoring the voltage reported by the microcontroller in its reports, such as the one presented in Figure 10, and the actual voltage of each cell using a multimeter. In this way, the battery percentage was properly adjusted to better represent the actual battery pack voltage percentage.

Τhe HMI application developed for the project’s needs was tested thoroughly regarding three main groups of functionalities: communication with the ULD, sensor data reporting, and communication with the robotic platform. As far as the HMI communication with the ULD is concerned, the MQTT broker initialization was tested and verified that it started every time. The establishment of the communication between the HMI and the ULD was verified for each test via both the messages posted by the RMC in the serial monitor and the dashboard screen of the HMI, as depicted in Figure 5, where the connected ULDs are presented, alongside a brief overview of the ULD sensors’ states. Regarding the sensor data reporting, once communication had been established between the ULD and the HMI, the sensors were triggered as described above, while checking the corresponding sensor indication in the HMI report, just as the one presented in Figure 6, to verify the change in the sensor’s state. Finally, regarding the testing of the communication between the HMI and the robotic platform, several test scripts emulating the robotic platform had been developed, to testi the communication and the effective exchange of data during the loading and the unloading processes of a ULD. This was achieved by sending specific commands to the scripts corresponding to complete loading and unloading processes of ULDs on an aircraft and receiving an acknowledgment that each command had been successfully executed. All the aforementioned laboratory tests led to a better understanding of the system’s capabilities as a platform for monitoring the status of a ULD at all times, as well as its limitations regarding the amount of data that can be accumulated for a single ULD locally.

3.2. Field Testing

After completing the laboratory testing procedure, the INTELLICONT system was installed on a demo ULD constructed for the project. The RMC and the power management unit were placed inside the ULD. The smoke detector was screwed permanently to the container’s ceiling, and the piezoelectric sensors were placed in their predefined positions on the container’s beams. In addition, four locking pin boxes were constructed, each one containing a locking pin and two sets of magnetic and contact sensors. The locking pin boxes were placed on the base plate of the container. Figure 11 depicts the integration and field testing team and the developed devices during the integration process.

To connect the RMC with the power management unit and the sensors placed on the ULD, special, sturdy, and lightweight cables with locking lightweight connectors were put together and channeled around the walls of the container and through its baseplate. Figure 12 depicts part of the installed system inside the ULD.

After the installation of the system in the ULD, the magnetic and contact sensors were remapped to appear in the right order on the HMI application. After the hardware and cable installation, all the tests performed during the laboratory testing procedure were repeated to specifically define the functional parameters of the system and to accurately pinpoint the thresholds for the alarms triggered from the sensors’ values. The field tests included testing the following:

Testing of accurate sensor signal transfer to the RMC unit with the new and significantly longer cabling. The test showed that the cabling did not affect the sensors’ signals and that data was accurately transferred to the HMI via the RMC unit with no false data due to noise or any other factor.

Testing regarding the HMI and ULD connectivity and the maximum distance between the devices with the RMC unit located inside the ULD. The test was performed by establishing a connection between the ULD and the HMI and moving within the test area with the HMI in hand while getting reports from the sensors on the HMI. This test showed that within the field test area that spanned a radius of approximately 150 m around the ULD, there was no spot in which the connectivity and the data transfer between the devices ceased.

Testing of the communication between the ULD, the HMI, and the robotic platform during the loading and unloading processes. For these tests, the actual robotic platform was used for moving the ULD around the cargo area. The field test team performed the entire loading and unloading process several times to test the accuracy of the data transferred by the RMC to the robotic platform, the connectivity between the robotic platform and the HMI, and the communication and the accurate execution of commands sent to the robotic platform from the HMI.

Testing of the system’s battery life. The battery life of the system was tested during all the kinds of scenarios that could be performed by the system, such as loading and unloading of a ULD and normal operation, in which the RMC sends periodic reports of every sensor’s value to the HMI. The alteration between different scenarios brought the testing conditions closer to real scenarios of the system’s operation. These tests showed that the RMC system could operate for about 32 to 36 h on two, initially fully charged, battery packs. The battery percentages for both battery packs were also verified during these tests.

Threshold evaluation and fine-tuning. By swapping the ferromagnetic materials used to simulate the locking pins with the actual locking pins that were located inside the dedicated boxes of the baseplate, the position sensor values were re-examined and the thresholds that indicated whether each locking pin was in the locked or the unlocked position were updated. The default thresholds for the piezoelectric sensors were also re-evaluated after their installation on the beams of the ULD, as the beams possessed shock absorption properties that differed from the ones of the test bench used for the laboratory tests.

3.3. System’s Limits Testing

A separate set of field tests regarding the identification of the system’s limitations and its response to unforeseen events was also performed. These tests revolved around two main axes that affect its functionality, namely power, and communication loss. The entirety of the tests performed, including the testing method, the response of the subsystem involved in the testing scenario, and the messages that the end-user receives via the HMI is presented in

Table 3. Test cases for the system’s response to unforeseen events.

Unforeseen Situation	Test Method	System Response	End-User Perception
Abrupt power source loss	Disconnect one or more cells of the battery providing power to the RMC unit	The system instantaneously switches to the other battery, without any loss of data or interruption of the system’s normal operation	A very low percentage is reported in the corresponding battery report on the HMI
	Disconnect the battery providing power to the RMC unit	The system instantaneously switches to the other battery, without any loss of data or interruption of the system’s normal operation	The corresponding battery percentage in the battery report on the HMI switches to 0%
	Disconnect both batteries providing power to the RMC unit	The RMC unit stops functioning The HMI stops receiving status reports from the ULD	The user receives no new ULD status reports in the HMI. The latest report’s cardinal number and retrieval time do not update
New power source connection	Connect a new battery pack while the system is already operating on another battery pack	The system resumes its operation powered by the battery it currently operates on	The battery percentage corresponding to the newly connected battery in the battery report on the HMI switches to the actual battery percentage
Connection loss between ULD and HMI in normal operation	Having the HMI in hand, move away from the test area or into a spot with multiple walls and beams between the HMI and the ULD or disconnect the RMC unit’s antenna	The RMC unit tries to reconnect to the HMI and restarts its operation after 5 tries The HMI stops receiving status reports from the ULD	The user receives no new ULD status reports in the HMI. The latest report’s cardinal number and retrieval time do not update
Connection re-establishment between ULD and HMI in normal operation	Having the HMI in hand, move into the test area or into a spot with few obstacles between the HMI and the ULD or reconnect the RMC unit’s antenna	The RMC unit reconnects to the HMI and resumes its operation in the last state set in the HMI The HMI receives new status reports from the ULD	The user receives new ULD status reports in the HMI. The latest report’s cardinal number and retrieval time update
Connection loss between ULD and/or the robotic platform and/or the HMI in loading/unloading operation	Having the HMI in hand, move away from the test area or into a spot with multiple walls and beams between the HMI and the ULD or the robotic platform or disconnect the RMC unit’s antenna	The RMC unit tries to reconnect to the HMI and restarts its operation after 5 tries The HMI stops receiving status reports from the robotic platform	The user sees an indication status in the HMI signifying the communication interruption with the robotic platform

.

The tests presented in Table 3 were executed multiple times, according to standard testing practice. Three typical test cases are presented to demonstrate the system’s response to several unpredictable events.

Abrupt power source loss

To test the system’s behavior in the case where one or more cells of a battery pack are removed from it or malfunction, one cell of the battery pack that provided power to the RMC unit was removed 15 times from the battery pack. Meanwhile, the ULD status reports in the HMI application were monitored to witness the percentage drop in the corresponding battery pack. Only one battery cell was removed during this test, to be as consistent as possible regarding the time required for the cell removal. In the case of more than one battery cell being removed, time inconsistencies could occur between the removal of cells, as the battery cells would be removed from the pack by one of the authors. Moreover, even by removing just one battery cell, the test was valid and adequately served its purpose. Since two battery packs provided power to the RMC unit during the tests, the power management unit immediately switched to the second battery pack upon removal of the cell, and, therefore, no power or communication loss occurred. The reporting time interval for the ULD was set to one (1) second, which is its minimum value, and the time between the cell removal and the battery percentage update in the HMI application was measured. Figure 13 presents the results of the test in the form of a chart. From this chart, it is obvious that the average time between a voltage drop in the system due to any reason and the time it is reported to the flight crew is two (2) seconds. The error of the measurement is set to one second since this is the minimum report time interval.

Connection loss between ULD and HMI in normal operation

In this test, the distance between the ULD and the HMI beyond which the connection between the two modules was lost, was measured. For this test, the ULD was set in normal reporting mode and the time interval between consecutive reports was set to one (1) second, which is its minimum value. The HMI was moved away from the ULD, beyond the limits of the test area, while monitoring the reports from the ULD in the HMI, up to the point where the HMI stopped receiving reports. The test was executed 15 times and the distance from the ULD at which the connection with it was lost was recorded. The test results are presented in Figure 14. In this chart, the average distance from the ULD beyond which the connection between the ULD and the HMI was lost was 160 m. Since the distance was measured using a tape measure and since the space between the ULD and the tester was littered with objects often preventing a straight measurement, an error of five (5) meters was applied to each measurement in the chart.

Connection re-establishment between ULD and HMI in normal operation

This test took place after the connection between the HMI and the ULD was lost. It involved moving towards the ULD having the HMI in hand, up to the point at which the connection between the two was re-established, i.e., up to the point at which the RMC unit connected to the Wi-Fi network of the HMI. The time interval between the connection establishment and the first report that was received by the HMI was measured for 15 different repetitions of the test and the results are presented in Figure 15. This figure indicates that an average value of four (4) seconds is sufficient time for the return of the system to its normal operation after a connection re-establishment.

3.4. General Outcome of the Field Testing and the System Demonstration

The last day of the field tests was dedicated to a live demonstration of the system, in which all of the developed subsystems operated as a unified system. The live demonstration of the INTELLICONT system was a success. During the field testing and the live demonstration of the INTELLICONT system, the RMC platform’s good performance and compliance with its design specifications were verified. The RMC system and the robotic platform operated efficiently during the testing of the entire system. The INTELLICONT HMI proved to be a very useful tool for the captain and crew members, providing complete control of the ULD and the robotic platform. The field tests allowed the development team to test the system’s capabilities in nearly real conditions and their successful outcomes were seen as an initial step towards an even better system with signal processing capabilities at the edge, apart from just sensor data acquisition and many more interesting and useful features.

4. Conclusions

The ability to exploit data to obtain useful and actionable information, make predictions, and provide insights is an essential element today for continuous process improvements and optimal performance throughout the lifetime of assets. The aviation industry is continually evolving in the context of Industry 4.0. Used wisely, data can help the aviation sector to achieve operating cost savings and efficiency increase, higher safety, and security of assets. From cargo loading to fire detection during flight, IoT technology can be integrated into all phases of the asset’s lifecycle and trigger/spur new developments as part of an iterative process.

In the current work, a novel intelligent IoT system for improving the safety and planning of air cargo operations was presented. The system is part of a smart ULD that integrates three types of sensors for structural health monitoring, fire detection, and locking status indication. The measured data are collected via a dedicated platform incorporating a microcontroller and several specialized interfaces and are visualized on an HMI. While not yet fully developed, the main benefit of the platform is its ability to harmonize data collected from various sensors onboard and to implement large-scale processing techniques, to perform operational efficiency optimization, performance optimization, and safety issue detection. The developed platform was based on a scalable edge-fog architecture and was tested and benchmarked on a series of pilot demonstrations. The system can contribute towards safer, environmentally friendlier, faster and less costly air transportation.

As a next step to our research, both the operational efficiency and cybersecurity of the system will be evaluated. Currently, we are working towards the implementation of an edge computing smart gateway located either on each ULD or on the aircraft that could provide decision support by employing machine learning techniques for ULD structural health monitoring, advanced fleet management, etc. Emergency data transfer to either a local cloud dedicated to an aircraft or a ULD fleet or to a bigger, central cloud that collects data from various aircraft and/or ULD fleets is also being considered.