Known information systems in the field of public transport management of urban transportation of a smart city are investigated. Existing software products in the area of passenger transportation and cargo transportation are analyzed. It is established that in the conditions of a smart city, the quality of passenger transportation is one of the key tasks of the intellectual system. An intelligent system of urban passenger transportation by self- driving electric buses has been developed, the work of which is designed in the UML environment. In order to achieve the proper quality of passenger transportation by means of selfmanned electric buses (eco-buses), appropriate decompositions of the processes responsible for the control of the state and processing of the emergency condition are proposed, which also helps to optimize the operation of public transport.
Today, the problem of improving the quality of passenger transportation has become widely discussed with the development of the concept of a smart city. Improving the quality of passenger transportation includes a wide range of indicators, including timely arrival and departure of public transport, safety of passenger transportation, reduction of harmful emissions of harmful and greenhouse gases to people, improvement of the general environmental status of the settlement, etc.
In a smart city, this problem can be solved with the help of modern information technologies. The information technology used in the concept of a smart city is designed to meet the needs of its residents. The introduction of self-driving electric buses (eco-buses) into the public transportation system makes it possible to comprehensively achieve improved efficiency of public transport, passenger safety and environmental protection. This clearly indicates the urgency of developing an intelligent passenger transportation system with self-managed ecobases, which will play the role of ordinary public transport in the future.
The purpose of this work is to create an intelligent system of self-piloted passenger transportation by electric bass, aimed at solving the problems of the concept of a smart city in the field of public transport. This will increase the standard of living of the urban population and make more productive use of resources. On the basis of the purpose the following tasks were allocated: 1) to investigate known information systems in the field of urban transport management; 2) analyze existing software products in the area of passenger transportation and cargo transportation; 3) to develop an intelligent system of passenger transportation by autopilot buses in a smart city.
Solving tasks based on smart city principles will improve real-time management of public transportation. The use of autopilot buses will create the preconditions for the introduction of higher quality passenger services. Gathering real-time information about the necessary resources for public transportation within the city, which will reduce the cost of passenger transportation, make sound management decisions, and more.
The object of the study is the process of creating an intelligent passenger transportation system by self-driving electric buses in a smart city. The subject of the study is the methodological and organizational principles of the development of an intelligent system of self-piloted passenger transportation by electric bass in a smart city. 2 2.1
Scientists from around the world have been working on the concept of a smart city for over 20 years. Key to the concept of smart cities is safe public transportation, comfortable stops, e-ticketing systems, controls, video surveillance, alarms and other comprehensive real-time, GPS-based communication systems.
Among the studies of the problems of using information technology can be
distinguished works of such scientists: Antonyuk N. [
Analyzing the concept of smart city in the leading cities of the world Boston, New
York, Boulder, Buenos Aires, Amman, Sydney, etc., we can conclude that public
transport is one of the key areas where the use of IT is rapidly due to the integration
of physical infrastructure cities with digital based on big data technologies. In the
process of realizing a smart city, new knowledge and experience bases are formed and
filled with current information. This creates opportunities for the creation of new
values, increases the efficiency of the decision-making process and improves the
quality of life [
The authors [
Dedicated to protecting the environment and reducing atmospheric emissions in a
smart city: Bublyk M. [
The concept of information systems of passenger transportation was developed by
both domestic and foreign scientists, among them: Yu.A. Coleber [
Yu. Coleber [
Approaches to increase the efficiency of rolling stock of buses in order to improve
the quality of passenger service are explored in [
When developing intelligent systems, researchers paid little attention to autopilot buses. There are practically no specified systems for working in a smart city, which confirms the unresolved problem regarding the development of an intelligent system of passenger transportation by autopilot buses. 2.2
Management of public transport in Ukraine is provided by the company "A + C Ukraine" [13], collection of data on sale of electronic ticket in the city of Zhytomyr is available on the relevant site [14]. In Ukraine, the Smartbus project [15] is intended to improve the quality and comfort of passenger transportation. The first releases of the Smartbus product were released back in 2010, in several cities of Ukraine PP is already operational. The software is positioned on the market as a public transportation automation system that integrates passengers, stops, vehicles and city services. It also includes a system for monitoring and planning public transportation, advertising on monitors in transportation with geolocation, a mobile application for non-cash travel, software and hardware to pay for transportation, and reasonable stops to increase the comfort of waiting passengers.
Autopilot electric buses are being developed by leading companies in the world, including Tesla. The autopilot electric buses information system is virtually nonexistent.
In order to develop the Intelligent System (IS) of passenger transportation by autopilot buses, 4 external entities were used, namely: Passenger, Bus, Operator and Server. The external entity (essence) of Passenger in this system reflects the ordinary passenger who wants to use automated transportation services. Its attributes are: 1) unique number; 2) personal data; 3) card details; 4) the route. The external entity (essence) of Bus depicts a self-driving public bus on electric motors without the use of any other fuel. The prototype of this project is a modernized ecobass, which runs on 29 trolleybus routes in Lviv. Attributes of the essence Bus is: 1) a state number; 2) technical data; 3) stop; 4) GPS data; 5) Route.
External entity (essence) Operator describes a person who helps solve problematic or critical situations that the proposed system is unable to automatically correct or correct. The Operator is also responsible for the passive oversight of IS integrity. Attributes of an entity Operator is: 1) an operator number; 2) error; 3) the route. Essence Server communicates all of the past entities with each other, providing the most automated action possible to minimize human interference and its attributes are information.
The data flows associated with the passenger in the IC of passenger traffic by autopilot buses were defined as follows: 1) the passenger's request for travel, which corresponds to the requirement to stop the autopilot bus at the appropriate stop; 2) payment and confirmation of payment by passenger. The data flows associated with the Bus include the following: 1) requesting the bus to stop at the next stop; 2) constant transmission of the exact location of the electric bus every 5-7 seconds; 3) data transmission of all bus life support systems, such as battery charge, tire pressure, or any other emergency; 4) received from the system of correction of the status of the bus, if any deviations from the set (norms) were determined.
Data streams associated with the Operator include the following: 1) continuous passive monitoring of system and electric bus status; 2) acceptance of critical errors or abnormal situations; 3) resolving problems as soon as possible and correcting the state of the system to bring it back, or to provide special assistance with the departure of specialized groups to the scene of an emergency.
The following processes have been developed for the intellectual system. 1. Query Formation - this process reflects the processing of the corresponding request from the passenger, as well as entering the request data in the query database. Input information streams for request generation: 1) request from the passenger for readiness to travel; 2) query data from the query database. Outbound information flows for the same process: 1) confirmation of the request for travel; 2) record the query data in the query database. A data store, defined as a query database, contains data about all passenger requests.
2. Fare - this process is responsible for accepting, processing, confirming or declining passenger fare. If a payment is declined, payment will be repeated until successful. Incoming information flows for the process of payment of the fare: 1) payment of the fare from the passenger side; 2) payment data from the database of requests. Outgoing information flows for the same process: 1) confirmation or rejection of the fare; 2) record payment information in the payment database. The data store, which is defined as the payment database, contains data on the payment of passengers' fare.
3. Stop Sequence Formation - The process that determines whether a bus needs to stop at the next stop, as well as continuously processing the location data of all buses. Input information streams for forming a sequence of stops: 1) request from the bus about the need for a stop; 2) GPS data from the GPS database. Outbound information flows for the same process: 1) confirmation or rejection of a stop; 2) GPS data recording in GPS database. The data store, which is defined as a GPS database, contains data on the permanent location of all vehicles. The input stream for this drive is data from the bus on its location.
4. Condition control is a process that constantly monitors, processes and corrects, if necessary, the status of each electric bus, ie, corrects the technical condition. Input information flows to monitor the status: 1) status of each electric bus; 2) request for status data; 3) data of correction of the status of the bus. Output information flows for the same process: 1) data on the status of the bus; 2) notification of an emergency; 3) adjustment of the status of the bus.
5. Emergency management - a process that processes emergencies and, if necessary, calls for special assistance, if the problem cannot be solved at the program level, all actions are based on data from the operator. Incoming information flows for processing emergency situations: 1) notification of an emergency situation; 2) status correction from the operator; 3) data from the database of emergency situations. Output information flows for the same process: 1) status correction data; 2) an error message to the operator. A data store, which is defined as an Emergency Database, contains information about all emergencies. A common data store in the developed IP defines a server that synchronizes the data of all databases on the system, to ensure the integrity and correctness of the data.
Based on the need to solve the key task in improving the quality of service in the developed intelligent system of urban passenger transportation by self-managed ecobases, the process of state control was decomposed. Detailing the status monitoring process includes the following processes: Accept status data; process status data; check the correctness of the condition; adjust the status; send correction commands.
Accept status data is the process that first receives data directly from the bus. The input information stream is the status of the bus. The original information streams for this process are: 1) battery stock data; 2) data on other technical condition of the bus.
Process status data is a process that makes the data susceptible to further validation. The input information streams of this process include: 1) battery stock data; 2) data on other technical condition; 3) request for data. Output information streams form: 1) battery stock data; 2) data on the number of passengers, 3) data on technical systems; 4) status data processed.
Check the correctness of the condition - a process that determines whether there is an emergency, which data does not meet the norm, and which fit. The input information streams of this process include: 1) battery stock data; 2) the number of passengers; 3) data on technical systems. Outgoing information streams are: 1) emergency notification; 2) unsatisfactory data that has not been verified; 3) Satisfactory data.
Status Correct - A process that is responsible for bringing data back to normal and creating a list of bug fixes. Input information streams of this process include: 1) data for correction; 2) unsatisfactory data that has not been verified. The output information stream is a list of bug fixes.
Send Correction Commands is a process that is responsible for creating and sending special commands that return the status of the bus to normal. The input information streams of this process include: 1) a list of bug fixes; 2) Satisfactory data. The output information flow is a status correction.
It should be noted that the proposed intelligent system works with the most up-todate data, downloaded at the user's request from the servers of the city. The proposed intelligent system is very flexible to use and does not require a long wait while updating and downloading data to control autopilot electric buses. The bulk of processes with large datasets are executed only once at the initial startup time, as well as on demand (forced). The data received was suggested to be cached so that the next update could be made at startup or on demand. The creation of additional files for filling occurs in a fully automatic mode, where the user needs to fill in the data either in accordance with a specified template, which is created specifically to unify the process of interaction between different systems, or in accordance with the international standard GTFS.
To facilitate understanding of the proposed intelligent passenger transportation system by self-guided ecosystems, a description of the behavior of the designed system is given in the form of an activity diagram (Fig. 1) and a state diagram (Fig. 2).
From its initial state, the system goes into an action state called Select Route. This action status is related to Passenger. The data transitions the system to the status Send bus information, and after successful transition to the next state Receive bus response. These two states of action belong to the Stop lane (Fig. 1).
After the state of Receive bus response, the answer is affirmative and negative (Fig. 1). When going over a branch with a sentry condition, the answer is negative going to the state Collect data about systems. And then it goes into the state Check the system. These two last states of action belong to the Bus lane. After the Check Validation status of the systems, the bus branch is defective and the bus is defective (Fig. 1).
When switching to a sentry condition, the bus will go into a new state of operation, namely Send status information. This also applies to the Bus track. After this state of action, the system transitions to the final state (Fig. 1).
If you return to the validation state Check the system and make the transition with the watch condition the bus is defective, then the system will go to the next state of action, namely to solve the bus problem. The last state of action already applies to the bus operator track. This is followed by the division into two parallel streams. These concurrent streams are the states of action Run Corrections and Expect Assistance. These threads exist in the Bus lane. At the end there is a merger of these two parallel flows and the transition to the final state (Fig. 1).
If you return to the state of action Receive the bus response and go on the transition with the sentry condition, the answer is affirmative, then the next state of action will be Stop. From the Run Stop status, you move to the Choose payment method that belongs to the Passenger track. And then proceeds to the status Make Payments, which is already in the Payment Gateway path. The following is a branch for successful payment and unsuccessful payment. If the payment condition is fulfilled, the successful system will go into action Check the passenger's complaints. The last state of action already applies to the Bus (Fig. 1).
If the transition from the status to process the payment with the security condition of payment failed, then the system enters into the status of repeat payment, which is in the payment gateway path, from which the branch for re-payment is already successful and the re-payment fails. This in the first case leads to the transition from the sentinel condition re-payment is successful to the status of Check passenger complaints. In the second case, when switching to a security condition, the re-payment of the unsuccessful system enters the status Send an error to the passenger operator (Fig. 1). All this is in the payment gateway.
The following is the action status Send a response to a payment error already in the Passenger Carrier track. Following this, everything goes into action Check passenger complaints. Here there is a new ramification for the absence of complaints. Therefore, when there is a transition with a sentinel condition, there is a complaint, the IS goes into the state Send a response to a passenger complaint (Fig. 1). The latest status is in the Passenger Operator track. From this state of action there is a transition to the state of the Passenger Transport action, which is similar to the state of transition with the guard condition of complaints there is no status of the action Check the complaints in the passenger. The next and final (Fig. 1) is the transition to the state Stop at the destination of the passenger. The last two states of action belong to the Bus track. After the transition occurs the final state.
In Fig. In Fig. 2 presents a constructed diagram of state transitions, which shows the processes that take place inside the information system.
From the initial state, the proposed IS of passenger transportation by self-managed eco-basses goes into the first state called Wait Route Choice. In this state, the system waits until the passenger at the appropriate stop makes his choice of the route on which he is planning to travel. When the route is selected, it switches to the Bus Send status. In this state, the system sends information about the passenger's desire to train on the selected route, the closest bus that is on the selected passenger route.
The next state of transition occurs after the successful transmission of data, and the system enters the status of Expect bus response. It awaits the bus's response to the possibility of a stop for the passenger. If the answer is affirmative, then there is a transition from the sentry condition, the answer is affirmative to the state Bus stop. If the answer is negative, then there is a transition from the sentry condition, the answer is negative to the state Check the bus systems. In this state, all vital bus systems are checked to further resolve the situation. From this state, the bus is sent to the condition Send status data when the guard condition is fulfilled. After this state, the transition to the state is expected. The choice of the route will be overcrowded because if there are no problems in the system, the inability to stop is caused by the overcrowded vehicle. If the bus is defective from the Check bus system condition, the bus is defective, then this transition will transfer the system to the Send error condition. The Send Error data state has an incoming action, such as Set up an encrypted connection, as well as an internal Encrypt data activity. All error data must be properly encrypted to prevent third parties from corrupting or correcting this important data.
Go to next state The bus operator's response is expected after the data has been successfully sent. The Pending Bus Operator Response is in the process of waiting for the bus operator to respond as soon as possible to resolve an emergency. From this state, a sentinel condition is sent from the correction command to the Execute correction command state.
In the Run command commands, the bus executes commands received from the bus operator to deal with an emergency. In this state, the input action is Start Command Line Interface, the internal activity is Enter and Execute Commands, and the exit action is Close Interface.
After leaving this state, the system returns to its final state.
When the condition is fulfilled, the repair team is sent from the Wait for bus operator response to Wait for assistance. The state of Expectation Assistance for domestic activities is to stay on the sidelines and release passengers. From this state the system goes into final state.
Returning to the state Expect bus response, where the transition from the sentry condition was completed, the answer is affirmative, there was a transition to the state Bus stop. In this state, the entrance action is the Open Door, the internal activity is to Wait for all passengers to board, and the exit action is the Close Door. After the passenger has boarded the bus, he switches to the Wait for the passenger payment option. This status contains the inbound Passenger on the bus, in-house advocates Suggest a payment method. After selecting the payment method, you will go to the Process of payment processing, in which the payment received from the passenger is processed. If the payment process fails from the payment processing condition, the payment fails, then the transfer to the Repeat payment status occurs. If the change to the security condition was successful, the payment is successful, then the system goes into the Check Passenger Complaints state.
If from the Repeat Billing state, the condition with the condition of re-payment fails, the system enters the status Send Error to the operator. In the Send to operator error condition, the incoming action is Connect to server and the internal activity is Transfer packets. If from the Repeat payment condition the transition from the security condition re-payment was successful, the system goes to the Check passenger complaints status. From the Send Error to the Passenger Operator status after the error is sent, the status is to wait for the Expected Response of the Passenger Operator where the answer is waiting.
After the answer is sent, it goes to the Check Passenger Complaints state. From the Check Passenger Complaints state, the Passenger Pass status is changed if no guard condition is fulfilled. If from this state there is a transition from the guard condition the complaint is, then the system goes into the state Expect a decision from the passenger operator.
From this state, you move to the Passenger Transport state after solving the problem. From the Transport Passenger status, when you reach your destination, you will go to the Run Stop state for the passenger exit. And from the state Exit stop for the exit of the passenger there is a transition to the final state after leaving the passenger from the cabin.
To design the specifications for the management of the intelligent passenger transportation system by self-managed ecobases, the state transition diagram was used and the state transition matrix was constructed (Table 1 - Table 4).
These means are intended to reflect the processes occurring within the proposed IC passenger transportation by self-managed eco-bases, namely from the moment when the passenger sends his / her desire (request) to board a certain bus route from the stop where he / she is located until the actual transportation service, which is basic for the developed IP.
It should be borne in mind that during this information processing, there is a transition between different states that depend on the previous ones. The operation of the proposed IP takes into account the possibility of unforeseen situations, for example, the bus refused to stop. Refusal to stop can be caused by both an unpredictable situation that could occur from the time of its passage, and the usual overflow of the car by passengers. In this case, the developed IP provides for the recording of data for further processing and determining the need to decide on increasing the number of rolling stock on the relevant route at certain peak hours. The next state Expectation Processing Transmission Processing Expectation Processing End condition Beginning condition rIenqteurersutpftoiornawphasesnenthgeerresitsopa sCtroepasting a common list of Expectation
Contingencies are handled by the operator for optimum rapid response, and recorded to further prevent such unforeseen situations. The sequence of stages (hierarchy of tasks) of the intelligent passenger transportation system by autopilotized buses is as follows.
Step 1. Receive a notification of the passenger's request for a stop. At this point, the passenger sends a message (request) that he or she wishes to board the stop at the appropriate transport route. Also, from the information system side, a list is created and a list of queries is processed for later use.
Step 2. Contacting the bus to request a stop. At this stage, the data that has been successfully processed and grouped is transmitted to the appropriate bus on the appropriate route and which is closest and will first be able to make a stop at the declared stop system. It is also determined whether an appropriate bus is able to execute such an order.
Stage 3. Stop, pay, and carry out transportation. This is where the bus stops, and the passenger at the entrance to the vehicle makes an automatic fare. If for some reason the payment is not made, it will be repeated until its success.
Step 4. Determining the problem of stopping deviation. If at stage 2 the bus declined the stop order, then the reasons for such refusal are identified. A request is made to obtain the bus system data and the data is processed to determine the exact cause of the failure.
Step 5. Designing and solving an emergency. If in stage 4 it is determined that the bus declined the stop due to reasons related to its technical condition, then at this stage there will be a solution to such problems already with the participation of the operator, who should immediately and as soon as possible correct the problems with the system.
Step 6. Passenger failure due to bus overflow. If no technical problems with the vehicle were identified in Step 4 and the reason for refusing a stop order was the overflow of the passenger compartment, then the system sends a response to the passenger that the stop of the nearest bus is impossible due to overflow. The data collected at this stage will be analyzed to increase the rolling stock along this route. The data obtained will then be forwarded to the appropriate management decision.
The state transition matrix of the proposed intelligent passenger transportation system by autopilot buses is given in Table 1 - Table 4, includes a list of IC states vertically and horizontally - a list of conditions, a list of actions and the name of the state to which the transition from the considered state is carried out under a certain condition.
The deployment diagram is shown in fig. 3. In the deployment diagram in Fig. 3 shows a Bus bus that is connected to a Network node that has a certain stereotype << closed network >>.
A note has been added for the Bus bus explaining the purpose of the Bus, such as an explanation of the Bus bus: an autopilot eco-bass that carries passengers. There are also three devices named GPS Navigators, Camcorders, and System Status Sensors that are connected to the Bus processor. These devices are paramount to ensuring that the bus processor and and, in general, the system's overall functioning are functioning properly.
A Passenger processor has also been added to the scheme, with a note explaining that processor and a connection to the Network node. Passen-ger himself is an ordinary person who wants to use the automated transportation service.
Figure 3 shows the processor Payment Processing Server used to pay for passenger fare. The IP also has an Operator processor, which is divided into two processors: Passenger Operator and Bus Operator. For each of the above processors, notes are provided explaining the purpose and role of each node. These two operators are different in their specialization. The Passenger Operator needs to know the fare system, as well as be able to communicate properly with people, and the Bus Operator needs to know thoroughly the structure of the internal automation system, as well as to be a highly qualified specialist in the structure of self-driving buses.
The developed IP has a Synchronization Server processor, which is responsible for synchronization and correctness of all actions on the system.
The main aspect is the Network device, which has a certain stereotype << closed network >>, and as it is an encrypted, safe way to manage and preserve the integrity of the designed system at all stages of its operation. 4
This paper examines a number of existing passenger software products on the market. It is revealed that in the conditions of a smart city, the list of tasks of public transport information systems include improving the quality of passenger service, increasing their capacity, accessibility to resources, optimization of passenger transportation.
It is established that the quality of passenger transportation is one of the key tasks of the intellectual system. It is proposed to solve the corresponding quality of passenger transportation by optimizing the operation of public transport by means of selfdriving electric buses (ecobasses). The intelligent system of urban passenger transportation of self-managed eco-basses has been developed, the work of which is designed in UML environment. In order to improve the safety of public transport, appropriate decompositions of processes responsible for controlling and processing both normal and emergency conditions have been proposed. 12. Li W. A dynamic simulation model of passenger flow distribution on a schedule-based rail transit network with train delays / Wei Li, Wei Zhu // Journal of Traffic and Transportation Engineering. - 2016. - T. 3. - № 4. - P. 364-373. 13. A+C Ukraine software [Electronic resource]. - Access mode: https://apluss.pro/ 14. Selling an electronic ticket in Zhytomyr [Electronic resource]. - Access mode: http://texty.org.ua/ 15. Smartbus - IT solution for smart city [Electronic resource]. - Access mode: https://www.smartbus.ua/uk/about-us/