## 5 Case Study
### A Generic Application for Asset Tracking  
Based on the generic CPS Framework presented in the above section, an Asset Tracking Platform, which was used in the case study, was developed. This platform allows us to monitor in real time the location of vehicles, to know some basic information (e.g., operational status, total distance, total number of trips), and to see historical information about the trips of the vehicles. A block diagram of this platform is presented in Figure 2. This architecture is open enough to plug in new micro-services that implement different types of business logic. In the current use case, the objective is to have a generic platform that allows for the tracking of vehicles; however, simply by adding a module that can relate the tracked vehicle to a given product, it can then become a product tracking platform, and so on. As above mentioned, two types of devices were used in this case study. One of these device types, hereafter DT1, is a custom-tailored device that uses a custom proprietary Application-Level protocol, as used by the authors in [52; 53], to transmit the data. Support for this protocol is provided by the DT1 ecosystems, which handle all data transfers between the device and the cloud. Similarly, there is an ecosystem to handle the communications between the second type of device, hereafter referred to as DT2, which uses a plain socket to send information. These two ecosystems will provide the integration of the devices at the communications protocol level. DT1 and DT2 transmit information in two different formats, which are not the same. This means that the information needs to be adapted before being sent to the data sinks. To provide this translation, and therefore compatibility at the data format level, two translators that translate between the DT1 and DT2 data formats to a common JSON format were developed (\"DT1 to JSON\" and \"DT2 to JSON\"). Data from the devices are then sent to the data consumers that use it without needing to have knowledge about the original data transmission protocols or data format. For the use case, these consumers are as follows: a Data Storage service, which stores data sent from devices; and an application that processes the information and detects when the vehicle started or stopped a route (mentioned in the below images as \"rides\"). This detection is made both by decoding start/stop events that the DT1 devices send and analyzing the ignition, speed, and GPS data from the DT2 devices. The result of the processing is also sent to the Data Storage. To display data from the vehicles rides and their position in real  
Figure 2: Block diagram of Asset Tracking Platform. time, a Web Platform was developed. This Web Platform is also used to display historical data stored in the Data Storage. To fit in several mobility-related use cases, ranging from asset tracking to shared mobility applications, the Web Platform was built to be the most generic as possible. The information displayed by this application has two sources: the real-time data, related to the current vehicle position, which are sent directly by the Mediator as the data arrive from the devices, for Live Asset Location; and the historical data and other information related to vehicles that are retrieved from the Data Storage. Figure 3 presents a detail of the platform, where the status of the tracked vehicles is presented. In this view we have on the right side a map that displays the last location reported by each vehicle, and on the left a filter that allows the user to select the vehicle to see on the map by operational status. A detailed view of the vehicles that are available on the platform is presented in Figure 4. In this view, we can see some basic information about the vehicle, such as its unique identifier, license plate, status (in use, stopped, or charging--for electrical vehicles), the total distance, and the total number of trips/rides.