Real-Time Logistic Monitoring: System Prototype Overview

The average rate of fruit and other fresh food products that perishes during transport varies between 10 and 25%. This volume of losses justifies the need for quality control means. Under the Software as a Service (SaaS) paradigm, the Real-Time Logistic Monitoring (RTLM) system aims to respond to this problem through real-time monitoring of the conditions in which the fruit is transported. The RTLM project integrates a responsive web application, a monitoring services system, an Extract, Transform & Load (ETL) engine, a set of integrated services through sensor plugins developed with Arduino technology, and a Grafana dashboard instance.


INTRODUCTION Context and Motivation
The analysis of data provided by the Portuguese National Statistics (INE) and Transports and Mobility (IMT) Institutes, allows the conclusion that by 2018 there were 387 054 vehicles providing road transportation of fresh food products every day (INE, 2019) (IMT, 2018).
Hazards Analysis and Critical Control Points (HACCP) determines general best practices in the transport and distribution of food products in relation to food transport units: minimizing the risks of physical, chemical or microbiological hazards, reducing heat exchanges with the outside, and refrigeration systems suitable for closing or sealing the units (Hazard Analysis and Critical Control Point (HACCP) | Food Standards Agency, 2017).
ISO 22000 affects all organizations directly or indirectly involved in the food chain, including those responsible for logistics operations, such as the transportation, storage and distribution of food products. Regarding transport, this standard regulates especially on the refrigeration of containers, stipulating that a variation of more than 2º Celsius over the standard values is considered a non-conformity. The validation process, however, is still done only in the moments of dispatch and receipt of products (ISO 22000:2018 -Food safety management systems -Requirements for any organization in the food chain, 2018).
In economic terms, the average rate of fruit perishing during transport varies from 10 to 25% (Van Zeebroeck et al., 2007). This volume of losses, beyond the regulated quality control criteria, reinforces the need for additional means of quality control, alerting to the observation of values outside the safe parameters, throughout the logistics process. Beyond economic terms the bruising of fresh food products represents a potential bacteria concentration point and a consequential health hazard.

Problem and Main Goals
The main problem is the lack of an engineering solution to allow real-time monitoring of logistic processes related to the transport of fresh food products taking into account the several observation parameters.
In order to address this problem, a framework for a prototype is proposed, comprising an Arduino based device with sensor and communication shields that allow real-time communication of data to a cloud based solution which uses a SQL database, an ETL engine and a web responsive application. The web application provides an user interface with a dashboard solution updated in real time. Moreover, the web responsive application assures components interoperability and provides the user interface including access to CRUD (Create, Read, Update, Delete) operations and data visualization (e.g. tables and maps) in traditional and mobile devices from a 4' smartphone to a 70' smart TV. Wearable devices such as smartwatches weren't considered regarding reduced screen resolution that such small devices still offer.
The purpose of the Arduino device is to monitor the atmospheric and packaging conditions in which the transport of fruit and other fresh products is carried out through an engineering artifact that integrates the information obtained from thermal sensors, humidity sensors, vibration sensors, as well as GPS information and GPRS communication. The dashboard solution offers a continuously updated intuitive data visualization, allowing the instantaneous reading of a transport service critical climatization and handling indicators such as temperature, humidity, stability and weight pressure.

Methodology
The chosen methodology is the Design Science Research (DSR) reviewed by Alan Hevner in 2010, because it is a scientific research from which results the production of an artifact in the form of an information system (Hevner and Chatterjee, 2010).  (Hevner et al., 2004).
The research receives its relevance from the environment which comprises the people and organizations involved and both the available and necessary technology. The relevance is therefore expressed by the environment as a business need, which in this case is a Real-Time Logistic Monitoring Solution.
The rigor an information systems research requires to qualify as a scientific research is expressed as applicable knowledge sought in solid foundations such as food quality rules, as the HACCP and ISO 22000 and all the applicable information systems theoretical knowledge and methodologies. In this case, the state-of-the-art information systems theory and methodologies and the food safety rules are applied in the modeling of the architecture of a solution to the identified problem, which can later be generalized to solve similar problems in different contexts.
The research itself is a cycle of development, an assessment process of a solution evaluation and the refining or redesign and development of identified non-conformity issues or another entirely different solution. In this research an artifact was developed, comprising actually three autonomous solutions that when integrated, operate as one solution for the identified problem. The solution was tested on the field and its functional and non-functional requirements were evaluated.
The research output comprises both a solution applicable in the appropriate environment, as a solution to the identified business need, and additions to the knowledge base as the methodology used to design and develop the solution, or the precautions taken to respect the scientific standards which are responsible for granting it a scientific research status, rather than a consulting project.

Research Results
The research resulted in an integrated prototype of the Real-Time Logistic Monitoring (RTLM) Framework, assuring the measurement of the desired and critical indicators, it's persistency and real-time communication to the server and instantaneous visualization on a dashboard solution. The collected data was verified against alternate sources and the majority of non-functional requirements was positively evaluated.
The application in appropriate environment has been taken care of as research progresses, with trade and intellectual property registrations leading to the introduction of the product in the market, as well as progress in the negotiation of pilot tests with companies operating in the fruit distribution sector.  (Hevner et al., 2004) This paper is an example of an addition to the knowledge base, following up a previous publication (Machado et al., 2020).

Document Organization
In Section Literature Review, are covered regulations, related work and background. Section Requirements Specification presents the framework requirements. In Section RTLM Architecture, is presented the architecture of the framework and specific aspects of each component. Each component's prototype, and their integration is covered on Section The Prototype. Field tests and requirements validation are presented in Section Validation Scenario. Finally, in Section Conclusions and Section Bibliography lists references that inspired and helped to execute our research.

Regulations
The HACCP methodology is today the internationally accepted reference for the implementation of food safety systems. European Regulation Number 852/2004 states that all food companies engaged in any stage of the production, processing, storage and/or distribution of foodstuffs must develop an HACCP system. Specifically for the transport of food, in Chapter IV of Annex II it regulates the hygiene standards of conveyances and cargo containers, products separation whenever inevitable the simultaneous transport of foodstuffs and other goods, and generic rules on product containment, addressing no other topic than hygiene, separation and temperature control (Regulation HACCP among the best practices for foodstuffs transport, stands out the containers climatization and temperature control, without ruling the handling and conditioning of foodstuffs during loading and unloading processes (Hazard Analysis and Critical Control Point (HACCP) | Food Standards Agency, 2017).
ISO 22000:2018 also rules hygiene and temperature control and is vague about other factors of climatization, conditioning, handling and packaging of food products (ISO 22000:2018 -Food safety management systems -Requirements for any organization in the food chain, 2018).
The analysis of the relevant regulations can't be conclusive on whether regulations aren't more specific due to the lack of available technology, or, the technology hasn't been developed and implemented because it isn't required by the existing regulations.

Related Work
Regarding means of quality control available for fresh food products, Ruiz-Garcia states that monitoring the transport of fruit in refrigerated containers along the supply chain is the means by which product quality can be assured (Ruiz-Garcia et al., 2007). The author points out that monitoring provides all supply chain operators with accurate information about the products involved. Tracking is defined as the collection and management of information related to the current location of products or delivery items. While the screening refers to the preservation of the manufacturing and distribution history of products and components, the monitoring refers to the ongoing assessment of transport developments through continuous or repeated measurement and evaluation. Information technologies provide tools to help transport companies monitor the product from its origin to the end of the supply chain. To the author, this is particularly important in the area of the transport of refrigerated fruits.
Walter Lang describes a network of sensors in the smart container, which measure temperature and humidity and apply algorithms that allow estimating temperature-related quality losses (Lang et al., 2011). The author went ahead with the studies done up to then, which allowed only the consultation of the records stored offline.
Ana Cláudia Ferreira Preto, applied GPS sensors, accelerometers and resistive force sensors to study the behavior of a cargo pallet during its transport and the damage caused to the products, by the vibrations resulting from the conditions of the track or the driving style (Ferreira, 2013).
Her work introduces the study of aggressions resulting from packaging or handling, which Van Zeebroeck had already pointed out as one of the major causes of stock breaks during the transport of fresh food products, due to the bruising of food. Costanzo presents a system for measuring road traffic congestion by processing each user's location using Arduino technology (Costanzo, 2013). The author aims to propose a low-cost system based on GPS signals from Arduino-based systems to collect the traffic measurements needed to calculate the colored traffic map and the minimum path to the destination, depending on the current position. The comparison between the performance of the proposed system and that based on GPS signals from users' mobile phones points to greater accuracy of the Arduino-based monitoring system. The system can send user data to the main information center as anonymous messages, thus meeting the privacy requirements necessary for a broad activation of such monitoring methodology. Costanzo's article highlights the high accuracy possible to achieve through georeferencing by Arduino.
Yanping Wang applied Arduino Uno to the remote monitoring of temperature and humidity and the action of alarmist programs for the verification of observed values beyond the safe limits (Wang and Chi, 2016). Wang took advantage of Arduino's wireless communication capabilities to communicate temperature and humidity readings collected at an industrial facility point and display them on an LCD screen located elsewhere in the facility.
John M. Ryan presents technologies that are beginning to be available to track food shipments in real time and measure their temperatures and other variables and transmit the data through satellite or mobile communication systems (Ryan, 2017). In his book, Ryan presents an extensive survey of the international standards for this market, and discusses their suitability, pointing to the existence of risks whose prevention and monitoring are not legislated.
However, most of the companies involved in the development of parts of this technology are trying to sell their parts to customers who may or may not have the ability to integrate them into a system.
In this sense, following advantages for intelligent control systems are identified: • Visibility of transport 24 hours a day; • Possibility to collect different data with a network of sensors, such as temperature, sanitation, humidity, speed, inclination, tampering and others; • Data has the potential to launch a measurement system capable of providing critical quality control information to managers, allowing them to identify areas where financial losses occur; • The possibility to better control suppliers (loader/carrier), thus, a reduction in losses, and also a reduction in the liability of the retailer; • The possibility of systematically proving compliance with sanitation, traceability and transport standards has the potential to speed up waiting times in customs inspections; • Separate the products to be offered to end customers according to the useful life that can be calculated based on the knowledge of the environmental aggressions recorded during transport.

Background
Requirements Specification is a topic on Ian Sommerville's Software Engineering where the functional / non-functional classification stands out as the distinction of "what" and "how" to do (Sommerville, 2016). Functional requirements details what the information system needs to, or which functionalities to assure. On the other hand, non-functional requirements specify the quality standards to meet. Sommerville proposes a dozen dimensions for non-functional requirements as showed in Figure 2.
These twelve dimensions address product specific requirements, as it's usability, dependability, security and efficiency (space occupation and performance achieved), requirements from the user or developer organization (environmental, operational and development), and externally originated requirements as regulator, ethical and legislative requirements (accounting or safety/security).
Usability Requirements may include learnability or how intuitive the system is for the end users.
Efficiency addresses how fast can the system execute some procedure or task or questions like how much memory it requires.
Dependability may address the error rate and severity, and security addresses how resilient the system is to a cyber-attack.
Organizational requirements address both the client's and the developer's needs and constraints. These may include change management issues on the client side, such as process management resulting on how much the system must adapt to the client's business model, or how much the organization will need to change. It may address some developing constraints, including questions such as internal or external hosting, licensing, or interoperability with legacy systems.
External requirements reflect formal and informal norms, as regulations or laws and ethical issues.
Sommerville also indicates UML Use Cases as a form of specifying requirements.
Regarding modeling techniques, the chosen references were, the UML web site (UML Web Site, 1997), UML 0.9 specification (Booch, Rumbaugh and Jacobson, 1996) and "Applying Use Cases", one of the world's references regarding this diagram (Schneider and Winters, 2001). These references were vital to understand and apply UML's modeling techniques.
Steen and Tanenbaum defined distributed systems in a way that can be translated as the sum of all the components being one system, whose components are transparent to the user. In this work a special reference was found on the definition of cloud  (Sommerville, 2004) computing as a type of high performance distributed system, as Software as a Service (SaaS) as one of its service layers (Steen and Tanenbaum, 2017).
Banzi is an inescapable reference regarding Arduino technology, as the creator of this microprocessor (Banzi and Shiloh, 2014), as were the specifications of the board and each shield used or considered for this project.
Jiang, Pei and Zhao were a critical reference, leading to the adoption of a serverless architecture (Jiang, Pei, and Zhao, 2020). Farrukh Shazad was equally important leading the prototype's design into the Responsive Web Design model (Shahzad, 2017).
A vast array of programming languages was considered for the web development solution and consequently, one or more references for these languages, that included AJAX, Angular, ASP.NET, Bootstrap, C++, C#, CSS3, Dart, Elm, HTML5, Java, JQuery, JavaScript, JavaScript Object Notation (JSON), PHP, Practical Extraction and Report Language (PERL), Python, React, Ruby / Ruby on Rails, TypeScript, VB.NET, Extensible Markup Language (XML), or libraries like ArcGIS Online, Google Maps API, Leaflet.JS, DataTables for JQuery, Backgrid.JS, Uploader, jQuery File Upload and File Input by Krajee. The implementation of the web application prototype was supported mostly by the W3C website (W3C, 2020), Nixon's work combining HTML5, CSS3, JavaScript, JQuery and PHP with the MySQL database management system (Nixon, 2018) and DataTables, Leaflet and Uploader websites (DataTables, 2007) (Leaflet -a JavaScript library for interactive maps, 2010) (jQuery Ajax File Uploader Widget, 2018). Jakob Nielsen is a mandatory reference on the usability domain. Nielsen refutes the "user friendly" concept, stating the application doesn't need to be friendly, as long as it won't stand on the user's way (Nielsen, 1993). Instead he supports usability in 5 dimensions: 1. Learning: The system should be easy to learn so that the user can quickly start using it; 2. Efficiency: The system must be efficient to use, so that once the user has learned to operate with it, this allows him to achieve a high level of productivity; 3. Memorization: The system should be easy to remember, so that the casual user can return to the system after some period since using it, without having to re-learn the process; 4. Errors: The system should have a low error rate, so that users make few mistakes while using the system, and for them, if they occur, to maintain an easy recovery of them. The occurrence of catastrophic errors (without possible recovery) is prohibitive; 5. Satisfaction: The system should be pleasant to use, so that users like to use them.
Éric Quinton is a fundamental reference in the Cyber-Security field, as this investigation draws from his work the risk analysis process and techniques, and a reasonable checklist of most common web applications vulnerabilities, such as http security issues like forcing SSL/TLS encryption and https protocol, limiting the request types to GET or POST, preventing access to the host file system by url handling, preventing error messages display, password hashing, SQL injection, Cross Site Scripting (XSS) or cookies duration (Quinton, 2017).
Turban, Delan and Sharda were the reference regarding decision support systems in a business environment that evolves in complexity and pace of change, making decision-making increasingly difficult (Turban, Delen, and Sharda, 2014). Thus, the business must respond, and adapt to the changes in its environment, quickly and effectively. The time window for decision-making tends to shrink, and this decision tends to globalize in scope, which requires the development and use of computerized systems to support decision. Jane and Kenneth Laudon introduce the role of data visualization in decision support systems. Over 80% of the Business Intelligence (BI) audience is made up of casual users who rely largely on production reports. Senior executives tend to use BI to monitor activities using visual interfaces such as dashboards and score cards. The goal is for executive managers to focus on the performance of what is really important, with information about what affects global profitability and the success of the company. First, it is important to find a methodology to understand exactly what is "really important performance information" for a specific company, which executives need, and secondly, it will be necessary to develop systems capable of providing this information to the right people within useful timings (Laudon and Laudon, 2017).

REQUIREMENTS SPECIFICATION Use Cases
Figures 3 to 5 show use cases for each actor of the RTLM framework.
In this diagram the following actors are identified: • Web Application: Receiver of messages generated by sensors and shields; • User: Any human user who transports the device; • Administrator: User generalization with additional permissions inherent to system operation and management functions; • Temperature and Humidity Sensor: Measures temperature and humidity; • Accelerometer: Measures vibration; • Weight Sensor: Measures weight; • GPS/GPRS Shield: Measures the date and time, location coordinates and sends messages with the collected data.
As far as the relations of the actors are concerned, it is said that for the actors who are a generalization of others, operations are inherited. Thus, the cases identified are: • Receive Messages: The Web Application will receive messages sent by the GPS/GPRS shield with the data collected during transport; • Switch Device (On/Off): The user must turn on the device at the beginning of the transport and turn it off at the end; • Parameterize Device: The administrator can parameterize the device by setting the data communication frequency; • Access microSD Card: The administrator can access the microSD card to collect the recorded data; • Access SIM Card: The administrator can access the SIM card to change it; • Device Charging: The administrator must charge the device at the end of each transport; • Measuring Humidity: The sensor will measure humidity during transport; • Measuring Temperature: The sensor will measure the temperature during transport; • Measuring Vibration: The sensor will measure vibration during transportation; • Measuring Weight: The sensor will measure the weight exerted on the device during transport; • Measuring Coordinates: The shield will measure the location coordinates during transport; • Record Date: GPS/GPRS shield will measure the date during transport; • Record Time: The GPS/GPRS shield will measure the hours during transport; • Send Messages: the GPS/GPRS shield will communicate the data received to the Web Application. • User: Any human user who accesses the web application; • Manager: A user generalization that has additional permissions inherent to supervisory functions and leadership of teams and logistics operations; • Administrator: A generalization of Manager that has additional permissions inherent to the functions of logistics direction or system management; • Arduino Device: This actor represents the real-time logistics monitoring device that performs, records and communicates the observations of environmental factors and packaging conditions with potential for affecting the quality of fresh food products, during their road transport; • Dashboard: This actor represents the external data visualization platform.
At the level of the relations of the actors with the system it is emphasized that for the actors who are a generalization of others, they inherit the operations of these, as well as those that they would have already inherited from the previous ones. Thus, the relationships identified in the system are: • Authenticate User: The user must complete the authentication form with the username and password assigned to him/ her; • View Tables: The authenticated user will be able to see the authorized tables for the user profile assigned to them; • View Maps: The authenticated user will be able to view the authorized maps for the user profile assigned to them; • View Dashboards: The authenticated user will be able to see the authorized dashboards for the user profile assigned to them; • Manage Vehicles: The authenticated user, and cleared to, may create, view, modify or delete records relating to the vehicles of the client company that assigned him the user profile; • Manage Devices: The authenticated user, and cleared to, may create, view, modify, or delete records relating to real-time logistics monitoring devices and subscriber identity module (SIM) cards that equip these devices from the client company that assigned the user profile to him; • Manage Transportation Services: The user authenticated, and cleared to, may create, view, modify or delete records relating to each transportation service of the client company that assigned him the user profile, associating a driver, a vehicle and a device with a service to be performed at a certain date and time; • Import Data: The user authenticated, and cleared to, may import the data collected during a transport service of the client company that assigned him the user profile, using the microSD card that came with the device; • Manage Users: The authenticated user, and with an Administrator profile, can create, view, modify, or delete records relating to users of the company for which he or she is responsible; • Transmit Measurements: The Real-Time plugin will have at your disposal an interface that will receive your messages communicated by the web, each containing a record of the measurements made at a certain moment; • Receive Parameters: The Dashboard plugin will be invoked with the passing of the parameters that determine the transport service to be monitored and the initial and final dates and times foreseen for that transport service; • Monitor Data: The Dashboard plugin linked to the database and embedded in the web application will update your dashboards in real time, reflecting on the dashboard that is being viewed the measurements that are being sent from the Real-Time plugin to the web application database.

Figure 5 identifies the actors of the Dashboard System:
• User: It is a stakeholder who visualizes the data through the dashboard; • RTLM System: The dashboard, which consists of one or more panels, is designed so that it can be customized regarding the table where it reads the data from.
Moreover, the diagram presents the following application use cases: • Authenticate User -Authentic the user to use the tool; • Set Parameters -Filters the data to be viewed by buttons, between the transport and the dates; • Monitor Data -Checks and tracks the data by the user; • Invoke Dashboard -The RTLM system invokes the dashboard; • Send Parameters -Sends the parameters in the URL; • Provide Visualization -Provides visualization to RTLM authenticated users. Table 1 lists the RTLM functional requirements. Table 2 lists the RTLM non-functional requirements. Arduino Device The device must turn on and off when the On/Off button is pressed. FR02

Non-Functional Requirements
Arduino Device The device must measure the temperature. FR03 Arduino Device The device must measure humidity. FR04 Arduino Device The device must measure the vibration to which it is subjected. FR05 Arduino Device The device must measure the weight exerted on itself. FR06 Arduino Device The device must measure the coordinates of its location. FR07 Arduino Device The device must record the date. FR08 Arduino Device The device must record the time; FR09 Arduino Device The device must save the data received by the sensors in a comma-separated text file (CSV). FR10 Arduino Device The format of the temperature values to be written to the file must be the decimal number, with two decimal places. FR11 Arduino Device The format of the humidity values to be written to the file must be the decimal number, with two decimal places. FR12 Arduino Device The format of the vibration values to write to the file must be the decimal number, with two decimal places. FR13 Arduino Device The format of the weight values to be written to the file must be the decimal number, with two decimal places.

FR14 Arduino Device
The format of the coordinate values to be written to the file should be degrees, minutes, and seconds for latitude and longitude. FR15 Arduino Device The format of the values of the date to be written to the file must be year, month, day separated by hyphens. FR16 Arduino Device The format of the values of the hours to be written to the file should be hours, minutes, seconds. FR17 Arduino Device The generated CSV file must be saved on to the microSD card. FR18 Arduino Device The SMS sent must have the same structure as the CSV file.

FR19 Arduino Device
It must be possible, to the administrator, to parameterize the communication frequency before each transport is made. FR20 Arduino Device The device must send SMS message with the data, within the time interval set by the administrator. FR21 Arduino Device The CSV file must include the device serial number.

FR22 Web Application
The web application must enable user authentication.

FR23 Web Application
The web application must identify which user group the user who authenticated belongs to.

FR24 Web Application
The web application must facilitate the access of users with driver profile the table view of the records of the measurements made during the transport service being provided.

FR25 Web Application
The web application must facilitate access for users with driver profile viewing in a map of the records of the measurements made during the transport service being provided.

FR26 Web Application
The web application must facilitate the access of users with driver profile the dashboard view of the records of the measurements made during the transport service being provided.

FR27 Web Application
The web application must facilitate the access of users with manager or administrator profile to the table view of the records of the measurements made during the transport service that is being, or was provided, by a driver of the same company to which they belong.

FR28 Web Application
The web application must facilitate the access of users with manager or administrator profile to view in a map of the records of measurements made during the transport service that is being, or was provided, by a driver of the same company to which they belong.

FR29 Web Application
The web application must facilitate the access of users with manager or administrator profile to view in a dashboard the records of measurements made during the transport service that is being, or was provided, by a driver of the same company to which they belong.

FR30 Web Application
The web application must facilitate the access of users with manager or administrator profile to CRUD operations on the vehicle table, in records of the company to which they belong.

FR31 Web Application
The web application must facilitate users with a Manager or Administrator profile to CRUD operations on device tables and SIM cards in records of the company to which they belong.

FR32 Web Application
The web application must facilitate the access of users with manager or administrator profile to CRUD operations on the transport service tables, in records of the company to which they belong.

FR33 Web Application
The web application must facilitate the access of users with manager or administrator profile to an interface of import of data registered by a device on their microSD card, when the devices have been prevented from communicating (for lack of network coverage, or other reason).

FR34 Web Application
The web application must facilitate the access of users with administrator profile to CRUD operations on the user table, in records of the company to which it belongs.

FR35 Web Application
Record deletion operations on any table can only be performed if they do not compromise referential integrity in any other table.

FR36 Web Application
No user of a client company will be able to view (and consequently operate any CRUD operation) on any table, map or dashboard, a record belonging to another client company, and the sharing of data hosting resources shall remain transparent to all users of client companies. FR37 Dashboard The plugin must connect to the RTLM database. FR38 Dashboard The plugin must be able to graphically transmit the weight data. FR39 Dashboard The plugin must be able to graphically transmit the humidity data. FR40 Dashboard The plugin must be able to graphically transmit the temperature data.

FR41 Dashboard
The plugin must be able to graphically transmit the stability data.

RTLM ARCHITECTURE The Framework
The RTLM architecture is based on two main packages: 1. Monitoring Services; 2. Monitoring Client. Figure 6 shows the relationship between these packages. Arduino Device Usability SIM and microSD cards must be easily accessible.

NFR03
Arduino Device Usability The documentation and training material must be sufficient and adequate, enabling autonomous learning, in a short period of time that must not exceed one hour. NFR04 Arduino Device Maintainability It must be possible to charge the device battery after each transport. NFR05 Arduino Device Maintainability SIM and microSD cards must be replaceable.

NGR06 Arduino Device Dependability
The results obtained at the same time by RTLM and any other sensors must not differ by more than 10% (up to 0.4ºC difference for a temperature measurement of 4ºC, e.g.). NFR07 Arduino Device Reliability The battery of the device must ensure that it is used uninterruptedly during transport.

NFR08
Arduino Device Reusability The device will be reusable for similar purposes, such as the transport of refrigerated pharmaceutical products.

NFR09
Arduino Device Security The encryption of the CSV files stored must be ensured, preventing them from being changed by any user. NFR10 Arduino Device Security Data must be communicated in the https protocol, with TLS encryption. NFR11 Arduino Device Reliability Data persistence must be ensured by using microSD and the database. NFR12 Web Application Usability The use the of software must be intuitive.

NFR13 Web Application Usability
The documentation and training material must be sufficient and adequate, enabling autonomous learning in a non-face-to-face training period of less than 1 hour. NFR14 Web Application Usability Posting a record on any of the tables must be feasible within a period of up to 90 seconds.

NFR15 Web Application Maintainability
Feature modification or development must be feasiable without interrupting the service.

NFR16 Web Application
Reliability 999/1000 requests received by the application must be answered.

NFR17 Web Application Reliability
High Availability must be ensured, with sufficient redundancy to ensure a constant and permanent service.

NFR18 Web Application Performance
The response time for each application request must be less than 5 seconds. NFR19 Web Application Performance The processing time of records communicated by electronic devices should be less than 5 seconds.

NFR20 Web Application Performance
The software should run on both fixed and mobile devices requiring minimal memory and storage, so that even low-end equipment can run it.

NFR21 Web Application Portability
The software must run on any browser, on any operating system, from any type of device that has a screen with a minimum of 640p resolution available (4' iPhone SE and equivalent smartphones).

NFR22 Web Application Reusability
The RTLM architecture should be reusable with a minimum of reconfiguration to meet other market needs with a similar scope, albeit with different specificities.

NFR23 Web Application Scalability
It must be possible to maintain the growth in the number of users and the accumulation of data arising from the use of the application without compromising performance, even if it is necessary to hire a superior accommodation service. NFR24 Web Application Security All safety measures presented in the literature review must be ensured. NFR25 Dashboard Reliability The dashboard must ensure maximum availability time.

NFR26 Dashboard Security
Communications between the dashboard and the server should use the most secure protocols available.

NFR27 Dashboard Usability
The interaction between users and the system should be intuitive, enhanced by enlightening messages whenever possible and necessary.

Figure 6. Packages Diagram
The Monitoring Client package uses the Monitoring Services package to run a set of services that ensure features such as defining system users or plugins configuring for real-time monitoring. That is, the configuration of thermohydrometer, vibration and motion sensors and their addressing, and definition of environmental and geographic metadata. It is also through the Monitoring Client package that the administration of vehicles, transport containers and their association with sensors takes place. Responsive represents a responsive web application that uses the Monitoring Services system. The Monitoring Services system includes a library and a database.
Monitoring Database algorithms are implemented in the Library component of the Monitoring Services system. The Monitoring Services system also provides two types of interfaces: 1. Interfaces to support web applications (Responsive and Dashboards); 2. Interfaces to support external data integration (ETL Engine).
The Real-Time Plugins component offers an interface to provide access to sensor, general packet radio system (GPRS) and maps plugins. These plugins are responsible for the implementation of specific heuristics for executing real-time logistics monitoring processes.
The ETL component is of vital importance in this architecture because it is concerned with the integration in Monitoring Database of the data generated by the Real-Time plugin, both in real time and posteriori.    The assembly model the different hardware components assembled into the device:

Arduino Device
• Arduino UNO R3 ATmega328P; • Temperature and Humidity Sensor DHT11: Allow temperature readings between 0 to 50º Celsius and humidity between 20 to 90%; • 3 Axis Accelerometer ADXL335: Measures acceleration. It is an analog sensor that detects movement, responding through an electrical signal to a change in the environment caused by tilting or vibration; • 16 Channel Multiplexer CD74HC4067: Operates by combining multiple analog or digital signals into a single signal to transmit them in a single channel; • Weight Sensor -50kg: Measures the weight exerted on the equipment; • Weight Converter HX711: Amplifies signal sending data to the microcontroller; • SIM900 GPS/GPRS/GSM shield: Sends and receives GPRS data (e.g. through TCP/IP/HTTP); • 9V Battery Support with DC Connector: integrate the prototype as a form of power supply; • On/Off button: Controls the power of the prototype, allowing the rest of the equipment to exist inside a closed enclosure; • Micro SD Card Shield: ensures the registration of data.
Since the Arduino board and it's shields specifications and circuits are open source, a digital circuit can be drawn to order an integrated prototype which can be miniaturized and stylized for a pilot run before entering mass production. Figure 12 shows a hierarchical view of the RTLM website.

Figure 11. Arduino Device Assembly
Although Dashboard and Measurements (table or map view) appear as an extra layer under Transports, that's mainly because those screens are invoked with a transport service id parameter. Still the navigation is transparent and intuitive to end users, and a simple three layers navigation was achieved (authentication, data visualization and data management), keeping all screens at the distance of one mouse click.    versions of the menu depending on the user's profile. For users without special permissions only the "Transports" option appears, while the "Users" table is reserved for system administrators.
2. Operation buttons: All pages allow you to generally perform CRUD operations on the records, and an exception is displayed on the measurement table view page (records can't be added manually, as they must be communicated by a device, or imported from a microSD card). The Transports page also includes navigation for a selected record in the table. Selecting multiple records enables only the Delete button, and all other operations are for a single record. The New button is permanently enabled. Selecting a single record in the table will enable the remaining buttons.
3. Ordering: The up and down arrows over each column in the table allow sorting by that field, ascending or descending.
4. Browse: Allows you to search for records with what is inserted to the right of search, simultaneously in any column of the table.
5. Paging: The "Previous" and "Next" links allow you to observe the records before and after the ones displayed, according to the column by which the table is ordered at a given time. The square around the page number indicates the page being viewed. In tables with more records than that shown in this figure, the numbering of a range of nearby pages will also be displayed, as can be seen on the "Measurements" page.
6. The "Logout" button terminates the session and directs the user to the authentication page.
This interface was developed using HTML and CSS styles with JavaScript and PHP (See 1 and 6), and the use of the DataTables.JS library (See 2 through 5). Regarding tables data management, JQuery and AJAX was used. Figures 17 and 18 show the same transport service using a tabular view and a map view.

Figure 17. Tabular View
Map view is oriented to geospatial representation of the data and was achieved through leaflet.js library with OpenStreetMap tiles. It immediately shows where is the vehicle, and the route, but clicking on each marker to view the readings is only useful to check current data. Nor it is an easy task on the tabular view with measurements from this route spread through 145 pages of data. Data visualization as a time series can be observed in the dashboard, on the next section. Figure 19 exhibits the edit form, for a transport service, using a shared interface with other tables.
The interface to support CRUD (Create, Read, Update, and Delete) operations is shown over the greyed-out table, where in this case, the selected record is highlighted on the background. The form's title and submit button are elucidative to which operation the user is doing at the time, anticipating interruptions such as a phone call, or a colleague making some question.
The form carries data validation for input types and mandatory fields, besides escaping special characters and preventing SQL injection and cross site scripting. Figure 20 shows a Grafana dashboard embedded in the RTLM web application. In this case is showing the same data presented in Figures 17 and 18. The dashboard allows the visualization of data as a time series, allowing users to quickly spot some variation in any of the monitored variables. This is the recommended view for the driver, who can keep track of what is happening in the cargo container, and allowing head-office users, or even the client to monitor.

Dashboard
As future work, Grafana alternatives will be tested, as the co-existence of template variables and alarm queries is a subject that not supported by the developers, even being a major concern for the user community, even those with commercial licenses.
Grafana allows the setting of thresholds as maximum safe temperature, but the functionality loses its appeal if a different panel is needed to have the thresholds, or if the dashboard overruns data visualization privileges. E.g. A driver can only see his current transport service on the web application, but Grafana either allows the dashboard to be invoked with the transport.id parameter or the display of an unfiltered dashboard, viewing all transports and being alarmed of any anomality in any transport. This is especially critical if considering a shared environment where each user must only see his own, or his company's data.
Interoperability with the dashboard plugin is ensured by special care in the configuration of the Grafana server. Its integration into the web application requires the configuration of specific permissions for embedding in <iframes>, anonymous access, thirdparty rendering, and, no authentication screen. Parameters are sent in the url (variables in the dashboard). E.g. the transport.id, as well as global application variables, such as the time limits to be displayed, to which correspond to the estimated start and end dates and times of the service.

Components Interoperability and Integration
The persistence of the data sent by the Arduino device is guaranteed by an url to a PHP interface that accepts as parameters the timestamp of the communication, registering it with a sequential id and ensuring by ETL the identification of the device that transmitted it, since it sends its own serial number in the body of the message. In case of mobile communication unavailability, RTLM devices ensure redundancy of information by recording measurements in mass memory units (microSD cards). An user with a Manager or Administrator profile will be able to upload the log file written by the device during a transport service and, including the missing data in the database, thus, overwriting those that have been successfully reported.

This communication is inserted by the PHP interface in the Received_SMS
This feature was implemented using the Uploader.js library, which was chosen over the alternatives because it resulted in a cleaner and professional design.

VALIDATION SCENARIO
Field tests were prepared, in which the data was showed in real time and compared with data collected with alternative devices, namely: • Digital kitchen scale; • Accelerometer, GPS and hygrometer thermometer application on smartphones.
Tests revealed approximate values between both measurements, within the parameters established by the non-functional requirements, maintaining differences of less than 10%, except for the x value verified by the accelerometers, that it is possible to assign to the different positioning of the devices.
It wasn't possible to find out which measurements were the most accurate.
All the Functional Requirements were tested successfully.
Non-functional requirements related to Usability were taken into account during deployment, but only a pilot project with real users can validate how they were met.
The Maintainability requirements were observed during deployment by putting new features into production by uploading the changed files to the server without interrupting the availability of the server. The Arduino prototype also met these requirements, even if they are meant for the mass-produced device.
Reliability requirements will only be observable during a pilot project very close to real use, or even already in production.
Reliability requirements were verified by the field test.
Performance requirements weren't all possible to test on this scenario. Those tested were positive but can't be considered without real workload. The Arduino device showed a promising performance though.

Figure 21. Import RTLM Files
Portability requirements have been verified, and it is confirmed that RWD has been reached with the exception of the logo on the home page, which is hidden in views on smaller screens.
Reusability requirements, although not tested, is believed to be possible, for example, in the transport of refrigerated pharmaceutical products.
Scalability requirements have already been tested, when the infrastructure needed to be migrated to a commercial host to accommodate dashboard's requirements.
Safety requirements, despite respecting all the indications provided by the references, would require penetration tests performed by someone specialized.

CONCLUSIONS
This project allows instantiation in the cloud of SaaS applications for real-time logistic monitoring. Based on RTLM components architecture, and using the referred technologies, the RTLM framework gathers technical characteristics that allow the modular development of software and hardware parts to answer the main research challenges.
To validate RTLM, an Arduino prototype, a responsive web application, and a dashboard were created in order to support services integration from the plugins developed.
The validation scenario showed that the RTLM framework has conditions to prove its applicability in real scenarios, which motivated the researchers to pursue the first steps to register intellectual property and start a trial run with a company operating on the target market.
Moreover, as future work, genetic algorithms and neural networks will be used to find an optimal sampling rate for the Arduino device, and when a trial run occurs, we will take the chance to test the prevention of foodstuffs mis-handling or loading caused by behaviour changes of the logistic personnel aware of quality control monitoring.