"Git is the way and the truth and the life. No developer comes to the Heaven except through git."
When a user selects destination, the server automatically calculate (1) the optimal path, (2) which car(s) to drive, (3) where to change cars.
After a user inputs her or their destination and other data, the server divides the total route into one or more than one short sections, allocates each car for each section, and sends the plan to the user.
A user provides not only the number of passengers, but who they are also. The server calculates the optimal path and vehicles based on the data. For example, if any passenger is disabled or pregnant(Need care?), the server selects more proper vehicles and path for them.
Though the calculation by the server can be achieved by traditional programming, A.I. is more convenient and easy to code for this kind of process.
Table of Contents
Preface
SpaceWeb
Openhash
Traffic Server
Traffic Plans
Cloud Server Cluster
Server-based Full Self Driving(S-FSD)
Reinforcement Learning(RL)
Transportation Fees and ABC Bank
Vehicle Designs
Sky Trains
Cars
Buses
Trucks
Bicycles
Boards
Moving Chairs
100~200 programmers and mechanical engineers will devote to coding the ABC traffic by 2026.
The traffic infrastructure is designed for new cities to be constructed in 145+ BRI nations. Like other systems and infrastructures embedded in ABC, the traffic system will be first applied to ABC City(hereinafter, "the city"). The contents below assumes the traffic system to be applied to ABC Pilot City(실증 도시).
First of all, A.I. is more applied to the traffic servers than FSD(Full Self Driving) of vehicles.
All vehicles are public properties: bicycles, motorbikes, cars, and trucks etc.
Users pay as usage.
All are electrics.
Every vehicle updates its data in real time: where it is, who are its passengers and how many, parked or driving, battery status, speed, destination and so on. [Figure - Car Info]
All vehicles are driven by a server cluster in the cloud system(hereinafter, "the server") of each city.
All vehicles are linux machines communicating with the server in real time via 5G or 6G network.
The traffic server monitors which car drives with how many passengers and who is each of them to provide proper vehicles to each passenger.
This page is how to use and how to manage those vehicles. First of all, let's see what kinds of vehicles are designed for the city.
Skyrail - similar to subway, but runs on rails in the sky. [Figure - Skyrail]
Cars - ordinary cars for 1~4 passengers, but cloud based FSD(Full Self Driving).[Figure - City Car]
Bicycles - motored or pedaled. [Figure - Bicycles]
Trucks - Cloud based FSD with cargo loading devices.[Figure - Trucks]
Wheelchair - Such as for patients in a hospital.[Figure - Wheelchair]
Let's assume;
The city population is 200,000.
100 Sky trains with boarding capacity of 10
100 cars with boarding capacity of 4
100 buses with boarding capacity of 10
500 bicycles
500 boards
500 wheelchairs
Therefore, the server should find out the optimal way to utilize those vehicles to meet traffic demands of 200,000 citizens. The server will calculate how to control all the cars to achieve the least energy consumption and total driving distance.
Those who have read ABC Bank may be somewhat familiar to the SpaceWeb and the Openhash Architecture. The ABC Traffic is also based on them.
SpaceWeb is to divide the earth surface into billions of unit spaces or cubes, each of which is about 10mx10mx10m, and to allocate an IPv6 address onto each of them. {Figure - SpaceWeb]
Those unit spaces, called Ip(잎), are stored in a large database where all the information of each unit space is updated in real time.
SpaceWeb is hierarchical.
A few unit spaces form a larger space unit, called Namu(나무), a few namus form even larger space unit, called Supul(수풀), and all the supuls form Hansupul(한수풀).
For a simple illustration, the smallest rectangle in [Figure - SpaceWeb] is an Ip, four(4) Ips form a Namu, a rectangle of black thick lines, and all the namus form a supul, a rectangle of blue lines. Of course, they are not rectangles, but cubes.
However, that's just an example. Normally, more than 1,000 Ips form a namu and so on.
Unit Space(Ip, 단위 공간)
It's the smallest space unit in SpaceWeb. In [Figure - Unit Space and Namu], the cube on the left is a unit space, and a larger cube with several smaller cubes on the right is a namu.
The unit space is where actual data is recorded.
The IPv6 address of each space unit(ip, namu, supul and hansupul) is its ID.
Ip stores and updates data of fixed objects and moving objects, all of them also have IPv6 addresses as their IDs. The data includes other information such as the larger space unit it belongs to., length of one side of the cube, and UPS(Urban Positioning System) of the center of the cube etc. UPS is an ultra precise GPS of which error range is less than 1cm. [Figure - UPS]
So, if a vehicle passes through a unit space, the data is recorded in both the unit space and the vehicle itself. Notice that both have their own IPv6 address and database section.
The role of lager space units, which are namu, supul and hansupul, is not to store data, but to do some special works called Openhash.
Pseudo Codes
Openhash is to prevent data corruption. For example, when a car drives on a road section, it passes through many unit spaces(= ip, 잎), and each of the unit spaces records when the car comes in and out. The traffic server below depends on the data recorded and kept in each unit space.
What if the data of unit space is hacked or corrupted? All the infrastructures of the city will be broken down, and people will be panicked. Openhash is to prevent those disasters.
For example, when a car passes through a series of unit spaces, each unit space(= ip, 잎) updates its status due to the EVENT of the car's passing through it.
When a unit space updates its data, it updates its status, extract a hash from the status, commits the new status and merge requests the new hash to its git server, which is namu(나무).
After the git server(나무) merges the new data from a unit space, it returns its last hash to the unit space where the hash is committed again. [Figure - The Hash Chain of a Unit Space]
The previous hash was the last hash of the unit space before the event of car passing through.
The event data is the kind of event and related data. In this case, it's a traffic event, and the ID of the car etc. are included.
The merged hash is the new hash from the event data and the previous hash.
The hash from namu is the hash returned by the git server after it has merged the hash from the unit space.
The current hash is the hash from combining the merged hash and the hash from namu.
Therefore, all the commits of all the unit spaces in a namu are woven together via their hashes. It's quite simple to readers familiar to git. [Figure - Hash History of Namu].
No data of any unit space in a namu can be forged without forging all other unit spaces in the namu, and the data of the namu itself.
But, what if someone forge all the unit spaces and the namu they belong to? That's why supul and hansupul exist. The relation between unit spaces and a namu is same to that of namus and supul, and that of supuls and hansupul. [Figure - Hash History of Supul] [Figure - Hash History of Hansupul]
So, if anyone want to forge data of a unit space, she must forge all the data of the earth too.
Pseudo Codes
Different from current vehicles which are driven by humans or FSD(Full Self Driving) embedded into the vehicles, the vehicles in the city are driven only by the server.
The server is similar to Linux OS which controls all the hardwares and peripherals of a computer, communicates with other computers via network, and supporting all the applications installed in the computer. The server controls all the vehicles of the city, maintains them, and communicate with them and other kinds of servers of the city such as governmental servers.
For each of tens of thousand vehicles in the city, the server determines which vehicle to drive on what speed to what direction.
The server also determines which passenger or cargo is to use which vehicle from one point to another, where to change vehicles on what time.
Every traffic demand of a citizen yields a traffic plan. Every traffic plan is NOT to yield a best schedule for an individual demand, but to minimize the total cost of the city traffic as a whole.
When traveling to some place, there normally is a plan of traffics: whether use subway or bus, for which section to use trains and when to use a taxi etc.
Like a secretary arranging travel plans, the traffic server is to make traffic plans for all citizens' traffic demand.
It's not so easy to write a combination of various transportations for every citizen's traffic demand, but not so difficult.
All transports have different rates and the time value of a citizen is different one another.
Assuming there is only ONE citizen, the route of minimal cost is determine for just ONE traffic demand by using the well known path finding mechanism in machine learning.[Figure - Path Finding for One]
Then, we add one more citizen, and train the server to minimize the total cost of the two. [Figure - Path Finding for Two]
Then, we add citizens one by one until 200,000. [Figure - Path Finding for Many]
That's all. The path and vehicles to use for a citizen is not just for her alone, but also for the city or society as a whole. That is to say, you may have to use rather expensive vehicles such as a car for yourself alone, even though you prefer to use a bus or a skyrail which are more affordable than cars.
The server determines who use which vehicle for which section for his or her traffic plan, considering the traffic preferences and time value of each citizen. [Figure - Preference and Time Value of a Citizen]
The focus of the server is not to benefit an individual, but to benefit the city as a whole. That's why the traffic system of the city is partially free welfare. See Welfare for detail.
Pseudo Codes
Example
When Alice goes to school from home;
She opens the traffic app, and input some data such as destination and time to leave. [Figure - Traffic Request]
The traffic server calculates the UPS(Urban Positioning System) coordinates of both her home and the school, and generates a traffic plan of her which may include more than one sections of which vehicles are different one and the next. For example, she may use a bicycle from home to some place, then use a car, and lastly a bicycle or board to the destination. Each vehicle's riding is one section. [Figure - Traffic Plan]
The transportation fee is automatically transferred from her ABC account to the City, the operator of all the vehicles. Her git account generates a new hash from the transportation data, send it to ABC bank, receive a new hash, and combine the new hash from ABC bank with her last hash. [Figure -ABC Transfer]
Do you notice that the ABC Bank is, in fact, a namu(나무). The structure of Openhash is shown in [Figure - Supul Hierarchy].
An ip(잎) is a user which may be a human, a machine, a facility, a real estate, a legal entity and so on. The ip is the place where actual data is stored and updated. As the name "ip" implies, it's an IPv6 address.
A namu is an infrastructure such as the bank namu, the traffic namu, the medical namu, the market namu, the education namu, the IRS(Internal Revenue Service) namu and so on, each of which represent a social infrastructure such as banking, traffic, health, market, education, governmental organization etc.
A supul and the hansupul are to prevent data forgery or corruption.
ABC Bank & Time Value of Citizens
The city knows who earns how much via ABC Bank. That means the price or time value of one hour is different from person to person because of their different incomes. Even the price of each citizen can be calculated based on their tax reports which also are embedded into ABC infrastructure.
The time value of a patient in an ambulance is much higher than others. So, the server finds out the fastest route for the car.
The time value of a teacher is higher than that of a student. If, by accident, the two needs the same car, the teacher is given priority. Again, the server knows everything about every passenger in the city including his or her profession.
The most important thing for the server is not be cracked, hacked or broken. That's why we have made Openhash and SpaceWeb to prevent any forgery of data kept in vehicles or servers.
Both servers and vehicles are Linux machines.
The cloud is composed of multi servers distributed and hierarchical, and each of the servers is a mobile communication base station and git server at the same time. See SpaceWeb for details.
Every vehicle commits its status periodically, and sends merge requests to the nearest server, a base station, in the cloud. The status includes geolocation, time, passengers or cargos, speed, direction, destinations and so on. But, important ones are the last hash and the digital signature of the vehicle. See Openhash for details.
The nearest server merges any report from any vehicle to its master branch after verifying the digital signature of the vehicle. Then, send back its last hash to the vehicle.
The vehicle commits the hash from the server.
Again, the process above is to prevent data corruption by hacking or any other reason. Let's see an example.
As a human, a vehicle also is an economic entity similar to a legal entity like a cooperation.It has a user ID, ABC Bank account, financial reports and so on. That is, a vehicle is an ip(잎) in the Openhash architecture.
A vehicle manages and updates its status, commits and merge requests its last hash to the master branch in its namu, a traffic server in the cloud. [Figure - Vehicle Ip]
A vehicle also keeps and updates its own financial reports including a balance sheet and an income statement.[Figure - Balance Sheet] [Figure - Daily Income Statement]
The accounting principles of ABC are rather different from those of GAAP(Generally Accepted Accounting Principles). For example, BS and IS are generated in real time, not by the end of accounting periods such as a quarter, a half year or a year. See ABC Financial Reports for detail.
You may think it's too complicate or inefficient to generate and update the financial statements of all the vehicles, but it's quite simple and very efficient to manage the financial status of millions of economic entities in unified & standard forms.
Pseudo Codes
FSD consumes quite a lot energies(= batteries), but the battery capacity of a city car is less than 1/10 of ordinary electric cars. As ordinary FSD is not appropriate, we have developed an energy efficient FSD.
The speed limit in the city is less than 50km/hr.
Every vehicle has UPS(Urban Positioning System), similar to GPS with less than 1cm positioning error.
The server knows the exact position of each vehicle in real time with less than 1cm error.
More than 2 cars may drive in a row to reduce air resistance. In this case, only the first car does FSD, and the others just follow the car driving in front.
The server determines which car follows which car, which car leads the way, and when they join or depart each other.
A. The Server
Again, A.I. was born to do this kind of jobs, and easy to code.
Every vehicle sends its current status, on duty(= driving), charging or idle. [Figure - Vehicle Status]
If driving, a vehicle sends its geolocation periodically, normally one(1) second, to the server with its digital signature. [Figure - Updating Status of Vehicle]
The server updates data periodically, normally one(1) second, on vehicles. [Figure - Traffic Board]
The server also manages user information: whether she can drive a bicycle or not, how old, and so on. In addition, every user has time value of labor. For example, a doctor's labor might be higher than that of a police officer. [Figure - User Information]
Users are assumed to prefer more economic transportation. Fees are cars, buses, bicycles, and electric boards in order. [Figure - Transportation Fees]
If a user calls a vehicle via the traffic app of the city, the server calculates the most economic route and the combination of more than two vehicles. For example, if a user is to go about 20 km, the server may recommend that she had better use a specific bicycle for 5 km, then a specific sky rail for 14km, and lastly a specific electric board for the last 1 km. Note the word "specific". The server knows everything about everything in the city, and vehicles are not exception. [Figure - Driving Plan of a Vehicle]
The above process is done by a simple mathematic formula and path-finding algorithm. [Figure - Path Finding]
But, what if 200,000 citizens calls vehicles at random places at random time? That's what AI does.
We need a model to train the server to minimize the total cost of traffic of the city as a whole.[Figure - Traffic AI Model]
Then, we modify the model so that 911 vehicles have priority, avoid traffic jams and roads under repair.[Figure - Training AI Model]
Pseudo Codes
B. FSD of Vehicles
FSD is applied only to buses and cars, not bicycles and boards. The communication between the server and a vehicle is encrypted by the public-private key mechanism of blockchain to prevent data forgery.
When the server selects a vehicle to drive, it sends the data of where to drive to, who to board, and how many passengers. In addition, the server sends a series of photos which are geo tagged.
Again, the city uses UPS(Urban Positioning System) which is a kind of ultra precise GPS with less than 1cm error range.
After receiving photos from the server, the vehicle starts driving, comparing the vehicle looking through its camera in the direction of travel with the photo sent by the server. [Figure - Compare vehicle's looking with a photo]
If the two scenes match, it goes on, and sends the photo it has taken to the server for updating the photo database of the server. It's necessary because the landscape of the city is continuously changing from spring to summer, from summer to winter and so on. [Figure - Updating Photo DB]
Notice that all photos are geo tagged, of which error range is less than 1cm. [Figure - Geo Tagging]
A vehicle follows a special line drawn for the purpose of FSD, clearly distinguishable from surroundings. [Figure - Special Line for FSD]
If the two photos mismatch, the vehicle stops and sends the new photo to the server for analysis. The server determines whether the vehicle should stop or may go on. For example, if the abnormality is from a bird, the car may go on. But, if it's a human, then the car should stop until the person goes off the road.[Figure - Abnormality Detection]
If the server let a vehicle to stop for any reason, it also modify the driving plans of all the other vehicles of which driving plan may be affected by the stopped vehicle. .[Figure - Modifying Driving Plans ]
The FSD mechanism described above is quite easy to implement compared to other FSD such as those of Tesla, Google, Amazon and so on. In addition, the FSD of the city consumes energy(= battery) less than 1/10 of other FSD mechanisms, and its manufacturing cost also is less than 1/10 of others.
Pseudo Codes
The traffic of the city is rather different from any of current cities. It's mathematical.
As described above, every traffic demand of a citizen or a group of citizens yields a traffic plan of the server.
Based on the traffic plans of all citizens if any, the server calculate and determine the operation schedule of all the vehicles of the city to minimize the total cost of the city considering energy consumption and time value of citizens.
We can increase or decrease the number of each kind of vehicles(cars, buses, sky rails, bicycles etc.) to minimize the total cost of traffic of the city.
A well-known AI algorithm to solve this kind of task is "reinforcement learning(RL)". Below are how to apply RL to our task.
Determine the unit price, life time, and cost per km etc. of each vehicle.
Using the map of the ABC city, designate which kind of vehicle can or can not use which kind of roads because bicycle can not run on the sky rail and vice versa.
Specify which kind of vehicles can transport how many people at a time. For example, a bicycle may permit only one person at a time.
Generate traffic demands randomly over the city.
Train the server to minimize the total cost of traffic of the city.
Let's assume we are building a maglev skyrail in a virtual ABC city located at the west-south part of the Jejudo island, called 대정읍. [Figure - Jejudo]
For convenience, the rail of the skyrail is a grid of 25km x 25km. The thick lines are two lane rails for skyrail and the thin roads for bus and cars. [Figure - Sky rails]
There are 50 sky trains, 50 buses, 50 cars, 500 bicycles, and 500 boards for the city of 200,000 population.
A train can drive along the grid(thick lines), both horizontally and vertically, turning left or right.
A car and a bus can drive along the grid(thin lines), both horizontally and vertically, turning left or right.
A bicycle and a board can go anywhere in the grid.
The cross points of vertical and horizontal lines are stations or parking lots where trains are charged.
The server knows who and how many persons will arrive when at each station based on traffic plans of them.
Let's make the model which minimizes the total traffic cost of the city.
Pseudo Codes
Again, the transportation of the city is a partial welfare.
The server calculate the transportation fares of each traffic demand which may be composed of more than two different kinds of vehicles. [Figure - Traffic Plan]
The fare of each kind of vehicle is predetermined. For example, the fare of a car is higher than that of a bus or a bicycle.[Figure - Fare system by means of transportation ]
The fare is proportional to the distance traveled. [Figure - Fare of a Traffic Plan ]
The fare is automatically settled by the ABC bank, and recorded by ABC like other transactions. That is, who used which car when for how long and how much distance so on. [Figure - Traffic Records of a Citizen]
Pseudo Codes
Because of their different roles and characteristics, we need to design all the vehicles of the city from scratch.
It looks like subway of in the sky, but operates like taxies without drivers.
The rail is constructed in the sky not to disturb moves on the ground.
The skyrail might be a MagLev(Magnetic Levitation). A MagLev is rather expensive to construct, but consumes less energy than traditional wheel-based transportation.
MagLev is not so difficult to implement, and its mechanism is rather simple. We have already designed its prototype. See the MagLev transportation for detail.
Pseudo Codes
Cars of the city are similar to taxies without taxi drivers. However, there are notable differences between city cars and ordinary cars.
Very small compared to ordinary cars because it doesn't need a large battery or steel frames.
The main usage of cars is from departure point to a skyrail station or from station to destination. So, the maximum driving distance per passenger or group is less than 10 km. That's why the battery size of the city cars is 1/50 ~ 1/100 of ordinary electric cars.
Because all cars are FSD and their maximum speed is less than 50km/hr, they don't need any safety measure such as steel frame and airbag, not to mention of handle, brake, gear, instrument panel and so on. That's why the manufacturing cost of the city cars is 1/10 ~ 1/20 of ordinary cars.
Pseudo Codes
Pseudo Codes
Pseudo Codes
Pseudo Codes
E. Wheelchairs
Pseudo Codes
Pseudo Codes
Pseudo Codes
When a user selects destination, the server automatically calculate (1) the optimal path, (2) which car(s) to drive, (3) where to change cars.
After a user inputs her or their destination and other data, the server divides the total route into one or more than one short sections, allocates each car for each section, and sends the plan to the user.
A user provides not only the number of passengers, but who they are also. The server calculates the optimal path and vehicles based on the data. For example, if any passenger is disabled or pregnant(Need care?), the server selects more proper vehicles and path for them.
Though the calculation by the server can be achieved by traditional programming, A.I. is more convenient and easy to code for this kind of process.
Pseudo Codes
Pseudo Codes