## 5 Use Cases  
A system prototype is already available and has been tested in the laboratory. A detailed record of the selected vehicle's activity during a three-month period was made available for the laboratory tests. The record was possible thanks to the cooperation of the public intercity transportation company, Global Salcai-Utinsa, which operates on the island of Gran Canaria and allowed us access to its infrastructure and vehicles to obtain the required data. This detailed record consists of:  
* Record of the vehicle's GPS position every second (latitude, longitude, elevation, speed, quality of the measurement, when it was acquired).
* Record of vehicle operations and when they were carried out: when service commenced, when the line started operating, stops, travelers' journey payments, when the line stops, end of service.
* Record of technical alarms associated with the on-board devices and at what time they occurred.
* Record of planning irregularities: failures in line service commencement and stop times, full vehicle warning.  
With these data, a simulation was programmed to reproduce a real-life vehicle scenario and the two use cases were tested. The critical aspects that we tested were as follows:  
* Correct provision of required data from the infrastructure to the OBC. We checked that the OBC has all the data needed to represent the state of the vehicle at all times.
* Correct provision of data required by each type of ACli application developed. We checked that the ACli client application has all the necessary data to provide accurate and useful information to the user.
* Communication protocol latency between the infrastructure and the OBC. For changes in the state of the vehicle and the OBC, we measured the time elapsed from the moment the change of state occurs at one end (infrastructure or OBC) until it is received by the device at the other end.  
* Response times in the interactions between the OBC and the client application. For changes in the state of the vehicle and the client application, we measured the time elapsed from the moment the change of state occurs at one end (OBC or client application) until it is received by the device at the other end.
* Response time of the client application. We measured the time required to display the information to the user according to their preferences.  
In the laboratory tests, we also tested system behavior in anomalous situations:  
* Failure of any infrastructure component.
* OBC failure.
* Failure of communication with the OBC.  
This type of testing is especially important for those services designed for users with special needs: system behavior must at all times be predictable and keep the user informed. To illustrate the utility of the system, two use cases are described. In the first case, the utilization of the system as a tool for supervising accessibility to vehicles at the stops is explained. In the second case, the utilization of the system as a route assistant for the blind is illustrated. In each of these cases, we illustrate the use of the various components and functioning principles explained in the previous section. These systems should function when the vehicle is conducting line service. All data related to the state of the vehicle are communicated by the infrastructure via the protocol described in the previous section. In Figure 5, the structure of the packet utilized for this communication is detailed.