## 4 ITS Architecture Proposed for the FMCS
### Proposed ITS Architecture  
According to the obtained and analyzed information, the ARC-IT American architecture was taken as a reference, due to the level of detail it presents for each service, which facilitates their development. Additionally, when the service areas of the different architectures are compared, ARC-IT is the one with the largest covered areas, which gives it a higher scope factor. However, this architecture must include the context of medium-sized cities in developing countries. The ITS architecture must also take into account the aspects identified in the systematic review as important requirements in this type of system (FMCS). One of the most critical requirements is security for communications, reliability, authenticity, among others. Another relevant requirement is the measurement of vehicle parameters and the choice of reliable, affordable communication technologies.  
The proposed architecture design is presented in Figure 3. The architecture is presented using ARC-IT notation. In addition, Table 4 briefly explains the flow of information in the proposed architecture.  
This architecture features a series of submodules (functional objects) for the Transit Management Center TMC and Transit Vehicle OBE physical objects. The ITS Roadway Equipment, with functionalities for the equipment on the road, is also included. Finally, two new actors (System Administrator and Enterprise Administrator) and new communication information were added. Thus, the ARC-IT base is preserved, keeping the Transit Vehicle OBE and Transit Management Center objects, and the Public Vehicle Operator actor together with most of the initial functions. It also includes several of the high-level functions of FRAME's Manage Public Transport Operations area, such as operational functions, continuous monitoring, continuous data collection, routes, schedule management, and provision of information for travelers, among others. Additionally, the on-demand service provisioning function of FRAME's Provide On-demand Services area was added.  
To keep the architecture fully functional and scalable, communication messages with the other modules are defined so that information can be shared between them. To comply with already mentioned security requirements, the messages that go through the \"Transit Vehicle OBE\" and \"TMC\" modules will need layers of security to guarantee confidentiality, integrity, and availability of the information. Messages requiring security are marked with red lines in Figure 3. Likewise, authentication methods are applied for all information communication services between actors and modules.  
It is important to emphasize that this architecture is generalizable to other medium-sized cities that handle the same context of the public transportation system (\"collective\" service). The use of an adequate architecture will allow the city to allow interoperability with other systems, in the same way, it facilitates the integration of new services that can be implemented to the system through modules and messages.  
Figure 3: Intelligent Transportation System (ITS) architecture proposal for FMCS.