Skip to main content
Creating Smart Rail Services Using Digital Technologies
Tickets for uses such as rail travel have become widespread in the form of physical tokens that represent value in relation to particular rights, and therefore have intrinsic value. This intrinsic value has made tickets conveying information about various rights a commonplace everyday item around the world, and places responsibility for their use on the ticket holder. In contrast, a thin client-based ticketing system only stores ID information on the ticket medium, so the tickets themselves have no value and the value associated with each ticket (such as seat reservation information) can be managed in an integrated manner by a host server. Associating the value provided by various tickets with a single ID could pave the way to the creation of single-ticket systems. And if IDs can be linked to personal information, users will be able to exercise the various rights they possess without the need for any physical token, creating a major paradigm shift throughout society. By developing technologies for applications such as thin clients and personal identification, Hitachi will continue to benefit society and play a leading role in single-ticketing system innovation.
The Society 5.0 plan put forth by Japan's government calls for the use of the Internet of Things (IoT) and artificial intelligence (AI) to create a comprehensive network of links among people and objects that will enable required information to be provided whenever needed. The plan's aim is to harness infrastructure innovation to create a world that supports individual aspirations, enables mutual respect among people of different generations, and provides a pleasant environment in which individuals can thrive(1). Creating a super smart society is another of the aims of Society 5.0, and there are many ways in which this aim can be tackled by rail and other ticketing services. For example, one way is by creating single-ticket systems enabling the use of a single ticket for travel by rail and other means of transport such as air and bus travel.
Conventional ticketing services allocate functions and data to station service equipment, and use ticket media to store rights information. But thin client-based methods that use ticket media only for ID information storage will be an effective approach for creating single-ticket systems. This approach will be made possible by separating processes previously done by station service equipment from media-stored rights information, and managing the information in an integrated manner on host servers.
Integrated management of purchased ticket information on a host server will also eliminate the need to issue conventional ticket media. If biometric information such as finger vein information is used, passengers will be able to enter and leave facilities through finger vein authentication gates just by holding a hand up to a scanner(2). So thin client-based single-ticketing systems with personal authentication could help create a society that lets passengers use any means of transport without having to possess any physical tokens (see Figure 1).
Figure 1—Use of a Single-ticket System with Personal AuthenticationSingle-ticket systems with personal authentication will give users access to every form of public transport without the need to possess any physical tokens.
Generally, a thin client has its client functions and data implemented on a host server to reduce the client's processing scope and specifications. In this article, the term also encompasses server-based storage of the rights information conventionally stored on ticket media.
One feature of thin client-based ticketing systems is the elimination of restrictions imposed by the use of media. Since conventional rail and other ticket media store various rights information (such as reservation, fare, and rail pass information) in the medium itself, they are limited to types of media that can write this information, mainly magnetic or integrated circuit (IC) tickets. But since thin client-based systems store the rights information on a host server, the ticket medium only needs to store ID information enabling the ticket to be associated with its rights information. Therefore, these systems eliminate the need to limit tickets to conventional media, and ticket media could take forms such as radio frequency identification (RFID), QR codes*, or biometric identification. Eliminating the restrictions imposed by ticket media will help increase service flexibility and reduce the cost of station service equipment and media. Services will be greatly liberated from their previous dependence on service-specific equipment used in stations other facilities, and it will become easier to provide services to inbound passengers who do not possess service-specific media.
Thin client-based systems will also be able to provide several new benefits by enabling server-based integrated management of media-stored rights information and processes handled by station service equipment such as conventional ticket gates. When fares are revised for example, the system will be able to rapidly apply all the fare calculation process changes at once. The center server will also be able to immediately gather ticket usage conditions previously known only to individual station service equipment. Using these data as real-time people flow information will help respond on-demand to passenger movements for use in applications such as combating congestion.
Conventional ticketing systems are composed of a centrally located center server and station service equipment connected to it (such as ticket machines, ticket gates, and window terminals). Thin client-based systems generally have the main functions implemented on the server level. Configurations with intermediate servers placed between the station service equipment and the center server are devised to accommodate ticket collection processes and other processes with a high demand for real-time performance. The intermediate servers determine the area that controls each piece of station service equipment and deploys it for each area. This type of configuration prevents processes from becoming concentrated in the center server, and helps enable immediate processing at the time of use. It also enables continued processing in an autonomous decentralized manner when errors occur in the center server.
As the configuration described above indicates, thin client-based ticketing systems are devised with a three-layer configuration consisting of the station service equipment that performs the actual operations at the stations (edge layer), a host center server (cloud layer), and intermediate servers positioned between the other two layers (fog layer). The edge layer sends and receives ID information and physically controls the station service equipment. The fog layer performs ID information-driven authorization processes (such as fare calculations and facility access evaluations), and links ID information with rights information. The cloud layer serves as the system's information rights manager, providing unified rights management (see Table 1).
Table 1—Function Configuration of a Thin Client-based SystemThin client-based systems have a three-layer configuration composed of a cloud layer (center server) and fog layer (intermediate servers) positioned on a server (upper) level, and an edge layer (station service equipment) positioned on a client (lower) level.
Thin client-based systems implement the main functions on the server level, so one way to ensure the same responsiveness as existing systems is to use intermediate servers for prior storage of the rights information linked to the ticket media possessed by users. This approach involves placing the rights information of all the users on all of the intermediate servers. But doing so will require the rights information to be continually synchronized among all the servers, requiring a massive amount of communication. Whenever a ticket gate or other station service equipment is used, the user's information is conveyed to all the intermediate servers. So if there are 1,000 stations, 5 users per second in each station, and 100 intermediate servers, for example, the overall system will be accessed about 500,000 times per second, placing a considerable load on the network.
But taking user mobility into account reveals that information does not always need to be synchronized among all the intermediate servers right away. Only the user rights information at the time and location at which a user exercises a right needs to be kept up-to-date. In other words, the timing of synchronization can be delayed according to the timing of user mobility, and this property can be used to reduce communication congestion (see Figure 2). The method of accounting for the timing of user mobility when synchronizing rights information is referred to herein as the Rights Influence and Propagate Rule (RIPPLE) in reference to how updated information spreads out in waves.
Figure 2—Method of Synchronizing Rights Information that Accounts for Timing of User MobilityContinually synchronizing the rights information among all intermediate servers generates a massive amount of communication and imposes a considerable network load. Using a synchronization method that accounts for the timing of user mobility can reduce communication congestion.
Several methods could be used to propagate rights information according to the timing of user mobility. Two examples are the bucket relay method and the propagation control method. The bucket relay method relays information over time by having the intermediate server that receives updated information sequentially pass the information on to the neighboring servers. In the propagation control method, the intermediate server that captures a change in rights information controls the timing for sending it to the other servers according to the distance to each recipient server (correlated to the timing of users' mobility).
In the bucket relay method, each intermediate server only needs to be aware of its neighboring servers when sending updated information, but the lack of a component that manages information transmission conditions makes it difficult to monitor where information has reached in the overall system. It could also be possible for updated information to travel back-and-forth along multiple different routes several times, potentially giving this method limited effectiveness at reducing communication volumes.
In the propagation control method, the intermediate server that captures a rights information change needs to be aware of all the other servers to convey the information to. But identifying the information transmission state is simple since a series of synchronization requests is issued from a single server, and duplicate requests ware never sent since the transmission routes are preset. A primary aim of RIPPLE is to reduce communication congestion, so it uses the propagation control method (see Figure 3).
The timing used by the propagation control method for sending updated information is as follows: The nearest station in each area adjacent to the area controlled by each intermediate server is searched, the transport time is set from the user transport speed and the distance to the nearest station, and this time is used as the cue for sending the information. Information such as the type of usage location (station) and a flag indicating whether the user is entering or leaving the location can be used to more precisely set the timing for sending information. Rights information changes generated in each intermediate server are sent all at once to the applicable servers using the set timing as the cue, thereby reducing the frequency of synchronization processes and helping reduce communication volume.
Figure 3—Rights Information Propagation MethodsRights information can be propagated by methods such as the bucket relay method and propagation control method. The Rights Influence and Propagate Rule (RIPPLE) uses the latter method to reduce communication volume.
Using a 160-station model centered in the Tokyo area, a simulation was performed to determine RIPPLE's effectiveness at reducing communication congestion. The simulation used settings of 5 users per second at each station, a maximum user transport speed of 100 km/h, and station-to-station distances specified geographically from a route map. The simulation region was divided into 7 areas, and one intermediate server was placed in each area. The number of communications per hour generated by all the servers under these conditions was measured, and it was found that RIPPLE enabled a major reduction in communication volume, resulting in 845 communications instead of 17.28 million when it was not used (see Figure 4).
RIPPLE's logic structure results in the time interval in which information is sent becoming proportionately longer as server-to-server distance increases. If multiple actions requiring rights information updating (such as getting on or off a train) are performed by the user during this interval, only the result of the last update needs to be sent. The simulation in Tokyo sent both the old and new information, giving it poor efficiency. To address this issue, RIPPLE was revised by adding various conditions. For example, it was found that communication volume decreased by about another 20% after adding, as a condition, the specification that about 60% of users ride for no more than 15 minutes.
Figure 4—RIPPLE-based SimulationRIPPLE controls the timing for sending synchronization information in accordance with the timing of user mobility. Servers that control areas near each other have short sending cycles [(1) in the diagram], while servers that control areas far from each other have long sending cycles [(2)]. The size of each black circle in the diagram indicates the volume of information sent.
Since thin client-based ticketing systems generally only need a medium for storing ID information, associating the rights information managed by a host server with a single ID paves the way for single-ticket systems. Associating the ID information on the media with personal user information can further improve system convenience and help reduce infrastructure costs.
For example, by providing personal data on areas such as native language, physical disabilities, and preferences, passengers will be able to receive services that match their personal needs or assistance for disabilities. Linking information such as user bank account numbers will enable single-operation processing to pay fees incurred during transport, freeing users from time-consuming payment processes. Recent growth in inbound passengers along with Japan's declining birthrates and aging population are creating the need to respond to increasingly diverse needs with limited resources. Thin client-based ticketing systems will let service providers respond to this environment by improving customer satisfaction while reducing communication costs.
Maintaining the safety of public transport facilities is a major issue of public concern in relation to external threats such as terrorism and pandemics. But performing a robust security check on each and every user is not a realistic solution since it would impede transport system convenience and constrict urban passenger flow. The use of personal authentication should be somewhat effective in reducing these external threats, and could help ensure physical security in user spaces without impeding user convenience.
Along with rail service providers, rights information stored on center servers could also be distributed to airlines, bus services, and all other transport service operators as a way to give users access to all public transport facilities with a single ID. Rights information could also be distributed for use with applications extending beyond transport. Collaborations with service providers in areas such as finance, public services, logistics, and retail could enable the information to be shared for use in many different areas. If these aims can be achieved, it should be possible to further invigorate rights distribution and create various synergies. Properly designed use of personal information and rights information with adequate steps to protect privacy will enable creation of a personal authentication-based single ticket future that links individuals to the entire society through a single ID (see Figure 5).
Figure 5—Future Single-ticket System with Personal AuthenticationSingle-ticket systems with personal authentication will be used in many fields such as public transport, finance, public services, logistics, and retail. They will create a people-centric future in which each individual is connected to the entire society by a single ID.
Rail tickets have evolved from paper types to magnetic and IC types. The application of IC media to public transport systems has significantly improved public transport system convenience, particularly for urban transport. But several issues still remain, such as the need for multiple tickets for medium-to-long distance transport and transport spanning multiple carriers.
By developing technologies such as thin clients and personal authentication, Hitachi aims to collaboratively create ticketing services and other infrastructure innovations stemming from them. These innovations will be designed to reduce public transport user stress and to make the modern society a more comfortable place.