Með vinsældum og mikilli notkun Global Positioning System (GPS) hefur orðið mögulegt í leigubifreiðaiðnaðinum að treysta á GPS til að fá breiddargráðu og lengdargráðu ökutækisins í rauntíma og nota það sem grunn til að útfæra rauntíma ökutækis tímasetningar- og eftirlitskerfi. Á tímum hraðrar þróunar þjóðarhagkerfisins hefur leigubílaiðnaðurinn, mikilvægur hluti þéttbýlisflutninga, einnig farið inn í hröð þróun. Ýmis stjórnunarmál sem stafa af stöðugu þróunarferli hafa einnig verið lögð fyrir stjórnvöld sem stjórna leigubifreiðageiranum og stjórnun leigubílafyrirtækja. Leigubílaiðnaðurinn er þjónustuiðnaður sem beinist beint að almenningi. Ökutæki eru dreifð á ýmsum svæðum í borginni, sem hafa víðtæk áhrif á samfélagið og fela í sér fjölbreytt úrval. Með stöðugum vexti fyrirtækja, hvernig á að skynsamlega skipuleggja dreifingu á leigubílgetu og styrkja leigubifreiðargetu Öryggisstjórnun, styrkja eftirlit fyrirtækja með ökumönnum og leigubílum, draga úr tómum kílómetra í ökutæki, draga úr eldsneytisnotkun, draga úr auðlindasóun og veita farþegum hraðari og meiri gæði þjónustu o.s.frv., til að leysa hagnýt vandamál sem krefjast fullkomnari kerfa til að styðja við það. Að vinna til að ná fram heilbrigðri og stöðugri þróun iðnaðarins og til að tryggja að fyrirtækið sjálft sé samkeppnishæfara og hraðari viðbrögð við ákvarðanatöku í greininni. Frá sjónarhóli stjórnenda ríkisins þarf GPS-byggt kerfi til að leysa umferðarþunga í þéttbýli, draga úr eldsneytisnotkun ökutækja og loftmengun og efla eftirlit ríkisins með leigubílum. Hvernig á að hanna og byggja heilt kerfi sem fullnægir alhliða og jafnræði eftirlits stjórnvalda að mestu leyti; vísindalega og framsýna eðli stjórnunar fyrirtækja; sveigjanleika og styrkleika kerfisins sjálfs; á sama tíma getur það veitt ökumönnum og farþegar koma með hagnýta aðstoð og ávinning, sem er vandamál sem verður að taka til skoðunar og leysa við hönnun á GPS-byggðu leigubifreiðakerfi og eftirlitskerfi.
Roadragon ' s aðalstarf er
1. Design leigubíl afgreiðslu og eftirlit kerfi sem byggist á fullan skilning á þörfum leigubíl afgreiðslu- og átta sig á atburð-ekin kerfi hönnun sem styður multithreading og stór samverkandi gagnaflutning. Tilgangurinn er að láta deildina
Öll hafa skýrari stigskiptingu og öflugri stækkunargetu.
2. Í ferlinu við innleiðingu kerfisins skaltu leggja til og leysa mikinn fjölda gagnatenginga milli leigubifreiða og kerfisins og tryggja heiðarleika og áreiðanleika gagnaflutninga. Tilgangurinn er að láta kerfið ná hærra með hagkvæmari auðlindum miðlara
Skilvirkni og áreiðanleiki gagnaflutninga.
3. Leggja til og leysa vandamálið við að leita nákvæmlega að sendibifreiðum við flóknar aðstæður á veginum meðan á framkvæmd kerfisins stendur. Tilgangurinn er að draga enn frekar úr tómu kílómetrafjölda ökutækisins og draga úr eldsneytisnotkun ökutækisins með nákvæmari ökutækjaleit.
Náðu hraðar upp á stig farþega.
4. Leggja til og leysa vandann við hraðvirka og skilvirka geymslu og söfnun gífurlegra gagna í kerfisútfærsluferlinu. Og ásamt greiningu á lausnum á raunverulegum vandamálum sem koma upp í framkvæmd verkefnisins til að útskýra kerfið í daglegu
raunverulegu hlutverki stjórnunar. Tilgangurinn er að veita skjótan og nákvæman gagnastuðning fyrir eftirlit og stjórnun ökutækja í rauntíma.
Samkvæmt ofangreindum greiningum má skipta kerfinu í:
1. Undirkerfi grunnupplýsinga: Aðalábyrgð á viðhaldi grunnupplýsinga stjórnenda, grunnupplýsingum ökutækja, grunnupplýsinga ökumanna og viðhalds grunnkortagagna.
2. Pöntun undirkerfis fyrir pöntun farþega bíla: Aðalábyrgð á gagnagrunninum við símaverið og viðhald farþega pantana og senda upplýsingar um bílapöntun í bakgrunnssendingarkerfið.
3. Sjálfvirkt undirkerfi fyrir sendingu pöntunar: Aðal ábyrgð á að viðhalda grunnupplýsingum í rauntíma ökutækisins og samræma ökutækið í samræmi við mótteknar upplýsingar um pöntunina. Samskipti skilaboða við skilaboðagáttina.
4. Aðalkerfi skilaboðagáttar: Aðallega ábyrgt fyrir umbreytingu og sendingu á milli skilaboðasniðs innan kerfisins og skilaboðanna sem skilgreind eru milli flugstöðvarinnar og kerfisins.
5. Kortvöktunarkerfi : Aðalábyrgð á gagnasamskiptum við sendingarkerfi og ábyrgð á kortasýningu og virkri sýningu ökutækja í rauntíma. Og sendu stjórnskipanir til ökutækisins.
Gagnaflæðið frá botni og upp er: 1. Ökutækið sendir rauntímagögn til undirkerfis skilaboðagáttarinnar; 2. Skilaboðagáttin framsendir gögnin til sendingarkerfisins; 3. Sjálfvirka sendingarkerfið er byggt á röðinni
. Ökutækið er skimað eftir breiddargráðu og lengdargráðu ökutækisins; 4. Sjálfvirka sendingarkerfið sendir viðbótarupplýsingar, svo sem rauntímaupplýsingar ökutækisins og ástand ökutækisins, til undirkerfis kortaþjónustu; 5. Undirkerfi kortaþjónustu skráir söguleg gögn ökutækisins og sendir það í rauntímaskjá viðskiptavinar fyrir kortavöktun.
Uppflæðisgagnaflæðið skiptist í tvo meginhluta:
1. Gagnaflæðið sem sendi undirkerfið hefur frumkvæði að: 1. Sendingarviðskiptavinurinn tekur á móti beiðni um bílanotkun og sendir það til sjálfvirka sendingarkerfisins; 2. Sjálfvirka sendingarkerfið finnur viðeigandi ökutæki byggt á raunverulegum aðstæðum.
Viðeigandi ökutæki og senda beiðni um notkun ökutækja til þessara ökutækja í gegnum undirkerfi skilaboðagáttarinnar; 3. Eftir að undirkerfi skilaboðagáttarinnar tekur á móti skilaboðunum umbreytir það skilaboðasamskiptareglunni og sendir til tiltekins farartækis
2. Gagnaflæði sem frumkvæði kortavöktunarforritsins hefur frumkvæði að: 1. Vöktunarviðskiptavinurinn ræsir eftirlitsbeiðni til kortamiðlarans; 2. Kortamiðlari framsendir hann til skilaboðagáttarinnar í gegnum sendiþjóninn; 3. Skilaboðagáttin breytir samskiptareglunum og framsendir hana í tiltekið farartæki.
Frá efri og neðri gagnaflæðunum er greining á undirkerfunum aðallega til að tilkynna hvort öðru um upphafsbeiðnirnar með skilaboðum. Að teknu tilliti til samsvarandi tímabærleika kerfisins og mikils samhliða gagna, samþykkir hvert undirkerfi í hönnunarferli kerfisins aðallega „framleiðslu-neyslu“ líkanið fyrir heildarhönnun, það mikilvægasta er að nota áhorfendalíkanið til aftengja. Hugmyndin með þessum ham er að skera niður beiðnir frá mismunandi þráðahópum um að vinna gögn ósamstillt. „Framleiðandinn“ er þráðurinn sem býr til þær beiðnir sem þarf að vinna úr og „neytandinn“ er þráðurinn sem tekur við þeim beiðnum og bregst við þeim. Kosturinn er sá að það veitir skýran aðskilnað svo að hægt sé að hanna þræði betur og geta verið meira í takt við hönnunarheimspeki lausrar tengingar. Það hjálpar einnig verktaki að finna og leysa vandamál sem eiga sér stað við raunverulega notkun. Hönnun og útfærsla kerfisins er einnig til þess fallin að viðhalda og stækka kerfið. Á sama tíma hjálpar hönnun og útfærsla mála einnig sjálfstæðu einingaprófanir hvers einingar til að bæta samhliða þróun innan teymisins og það hefur einnig næga ábyrgð fyrir síðari endurstillingaráhættu kerfisins. Helstu aðgerðir hverrar undirkerfishönnunar eru sem hér segir:
1. Undirkerfi skilaboðagáttar: Aðalábyrgð á móttöku og áframsendingu skilaboða og umbreytingu samskiptareglna. Við móttöku og áframsendingu skilaboða þarf að huga að viðhaldi tenginga í stórum samhliða aðstæðum og hvernig forritslagið getur tryggt heiðarleika gagnanna sem senda á undir þrengslum í netkerfinu. Aftengingin milli flugstöðvarinnar og kerfisins er tryggð með breytingum á samskiptareglum. Jafnvel þó að skipt sé um flutnings- og eftirlitskerfi flugstöðvaraðilans er hægt að tryggja heilleika og aðeins þarf að breyta samskiptareglu gáttar undirkerfisins.
2. Sjálfvirkt sendingarkerfi: Ábyrgð á því að dæma sjálfkrafa hvaða ökutæki henta farþegum út frá stöðu- og stöðuupplýsingum ökutækjanna, ásamt grunnupplýsingum fólksbifreiða og grunnupplýsingum um vegi borgarinnar. Helstu einingarnar fela í sér móttöku og sendingu skilaboða, skilaboða- og verkefna (verkefna) viðskiptaeiningu, þráðlaugareiningu. Lykilhluti aftengingarinnar í undirkerfinu er skilaboða- og verkefnabreytiseiningin. Í gegnum þessa einingu er mismunandi skilaboðum breytt í eitt eða fleiri sjálfstæð verkefni og verkefnin send til mismunandi þráðaauga til úrvinnslu.
3. Kortakerfi undirkerfi: fylgist með rauntímabifreiðum og skráðu rauntímagögn ökutækja til sögulegrar greiningar.
Hönnun á heildarkerfisarkitektúr
Þetta kerfi tekur upp Java sem þróunarmál. Í hönnunarferlinu er öllu kerfinu skipt í nokkur undirkerfi eftir mátahönnun og Socket er notað til gagnasamskipta milli kerfisins og kerfisins. Undirkerfið samþykkir aðallega framleiðslu- og neysluháttinn til að átta sig á aftengingu verkefna og aðgerða og notar fjölþráða tækni sveigjanlegri til að bæta samhliða vinnslugetu kerfisins. Fyrir algengar hagnýtar einingar milli hvers undirkerfis (svo sem stjórnun netviðbóta og viðhalds einingar, þráðlaugareiningar o.s.frv.) Kerfishönnun, eru opinberir og sjálfstæðir hagnýtir einingar hönnuð fyrirfram í ferlinu til að koma í veg fyrir óþarfa endurtekna þróun innan undirkerfanna. Undirkerfið stendur aðeins frammi fyrir raunverulegri viðskiptarökfræði.
Hönnun og framkvæmd framleiðslu- og neysluhams
Að teknu tilliti til skilaboðasamskipta milli undirkerfis og undirkerfis, sem og samhliða vinnsluþörf verkefnakerfisins innan undirkerfisins, er það grundvallaratriði kerfisins í hönnunarferlinu að taka upp framleiðslu- og neyslumódel. Inngangur þessa háttar verður ekki búinn í þessari grein. Þessi grein kynnir aðallega hönnunaruppbyggingu framleiðslu- og neysluháttar í þessu kerfi, ásamt nákvæmri greiningu á viðskiptaferli leigubílaflutningspöntunarinnar og sérstakri beitingu framleiðslu- og neysluhams. Heildaruppbygging hönnunar framleiðslu- og neysluháttar í þessu kerfi er byggð á þráðlauginni og verkefnahlutum. Helstu aðgerðirnar sem þræðasamlagið veitir eru ma viðhald og stjórnun þráða og viðhald og stjórnun biðraða.
Mikilvægara í framleiðslu- og neyslulíkaninu er hönnun þráðlaugarinnar. Til dæmis er OrderThreadPool að ná framkvæmd samkvæmt sérsniðinni röðun. Miðað við að rekstraraðilinn sé flokkaður sem gerðin og Nýtt Order_Task er vinnsluhluturinn, þá verður OrderThreadPool keyrð í röð í samræmi við verkefni hvers rekstraraðila og tryggir að aðeins ein Ný Order_Task fyrir hvern rekstraraðila sé keyrð í þráða lauginni. Meginreglan um hönnunina er að viðhalda tveimur HashMaps, eitt HashMap er notað til að viðhalda stjórnun milli flokkunarstaðalsins og samsvarandi Verkefni, lykillinn er flokkunargerðin og gildið er LinkedList verkefnalistinn. Annað HashMap notað til að viðhalda verkefni þess flokks er unnið. Þegar það er dæmt að það sé verkefni af sömu gerð sem er keyrt meðan á getTask stendur er önnur tegund verkefna valin til samanburðar þar til verkefnið sem fæst er tegund verkefnis sem ekki er í gangi og skilað í þráður laugina til framkvæmdar. Á sama tíma leggur kerfið einnig áherslu á notkun afkastamikilla samtímatækja sem Java hefur veitt frá 1.5, svo sem: læsa og skrifa læsingar, hálfmyndir, þráður samstillingu fyrir pöruð skiptibúnað o.fl.
Þó að eftirlitskerfi og sendingarkerfi ökutækisins aðallega felur aðeins í sér flutningadeild ökutækja, vegna þess að hún gerir sér grein fyrir beinni tengingu milli kerfisins og ökutækisins, hefur hæfileikinn til að afla rauntímagagna um ökutæki lagt traustan grunn fyrir fágaða stjórnun fyrirtækisins. Þess vegna, í hönnunarferlinu, er einnig nauðsynlegt að íhuga að fullu stjórnunarhugmyndir yfirstjórnar fyrirtækisins og sameina sveigjanlegar stjórnunarhugmyndir við tiltölulega fast skipulagningarkerfi. Láttu tímasetningar- og eftirlitskerfi ökutækisins sannarlega verða framvarðasveit upplýsingagerðar fyrirtækisins og vinna með fyrirtækinu til að átta sig á eigin stefnumörkun.
Viðhald sögulegra gagna ökutækja
Að viðhalda sögulegum gögnum ökutækisins er lykillinn að greiningu og eftirliti með ökutækinu. Söguleg gögn ökutækisins fela aðallega í sér sögulegar brautargögn um ökutækið, söguleg gögn ökutækisins osfrv. Sögulegar brautargögn ökutækisins eru aðallega notuð til að finna sögulega akstursleið ökutækisins, sem er notuð til að leysa kvartanir farþega, greina umferðarslys og finna týnda hluti farþega. Í raunverulegu umsóknarferlinu, til þess að tryggja að hægt sé að teikna braut ökutækisins á kortinu, er nauðsynlegt að tryggja að skýrslutíðni breiddar- og lengdarbrautarpunkta ökutækisins sé nægilega þétt. Ef ökutæki hleður inn stöðuskýrslu á 10 sekúndna fresti verða 8640 á einum degi. Gögn um stöðuskýrslu eru reiknuð sem hluti af stöðuupplýsingagögnum [4byte auðkennisnúmer + 8byte breiddargráða og lengdargráða + 4byte tími + 1 byte hraði + 1 byte (stefna, staðsetning) + 1 byte stöðu ökutækis + 4 byte viðvörun gerð] a samtals 23 bæti, einn á dag Lagagögn bílsins eru allt að 194K. Tíu þúsund ökutæki á dag geta náð 1G af gögnum. Hvernig á að geyma þessi gögn? Hvernig á að veita notendum þægilegan og fljótlegan fyrirspurn? Hvernig á að greina gagnlegar upplýsingar byggðar á þessum gögnum til að veita nýjar hugmyndir fyrir stjórnendur? Þessi mál verða að vera í huga við kerfisgerð og innleiðingarferli. Söguleg rekstrargögn ökutækja eru aðallega til að greina daglegar tekjur hvers ökutækis. Greining tekjugagna hjálpar stjórnendum að greina hvort núverandi gjöld séu sanngjörn, hvort afkastageta sé mettuð og önnur stjórnunargögn. Rekstrargögn fela í grundvallaratriðum í sér grunnupplýsingar eins og númeraplötu, kennitölu ökutækis, upphafstíma, lokatíma, akstursfjölda, rekstrarmagn osfrv. Greindu 800.000 skrár um 10.000 ökutæki á dag með 80 færslum á ökutæki á dag. Hvernig á að tryggja heiðarleika rekstrargagna, geymslu og greiningu rekstrargagna og hvernig á að grafa upp gagnleg gögn til stjórnunargreiningar úr þessum grunnrekstrargögnum svo notendur geti notað þau á þægilegan og fljótlegan hátt eru öll mál sem verður að huga að í kerfishönnunarferli.
GPS Vehicle historical data
According to the implementation of the system, the system is implemented in JAVA programming language, deployed on the server of the Linux operating system, and the database uses Oracle11g. Regarding the massive amount of data and the operating frequency of the data, the system is stored in two ways: file disk storage and database storage. For the vehicle trajectory file, a data system with a high upload frequency, it mainly uses file disk storage to store basic data. For vehicle operating data, data that is relatively infrequently uploaded, is stored in the form of database storage. The following will introduce solutions for processing two kinds of data. The main purpose of the vehicle trajectory file is to trace the historical driving situation of the vehicle and to statistically analyze the number of historical vehicles in each time period in different areas.
Scenarios for retrospecting the historical driving situation of the vehicle include: 1) Lost and found by passengers: Passengers left their belongings in the vehicle, but cannot provide specific vehicle information, and can only provide a certain place during a certain period of time. The system needs to find out all the vehicles that have passed the locations recalled by the passengers based on the historical trajectory information of all vehicles in a certain period of time for investigation. 2) Passenger detour complaints: Passengers provide information about the vehicle they are in, and the system queries the vehicle's driving route during the service period to determine whether the vehicle is detouring illegally. 3) Vehicle statistics for each time period in different areas: Generally used to monitor whether the number of vehicles in the area is abnormal, so as to determine whether the vehicles in the area have stopped or went on strike. In practical applications, the monitored city needs to be divided into multiple monitoring areas, and the number of vehicles in the area is counted according to the 24 hours a day. The number of vehicles in the area is divided into 24 hours a day to form weekly averages, monthly averages and other reference data, combined with the real-time number of vehicles on the day The situation is compared to draw a reference conclusion whether there is any abnormality. According to the above three common scenarios in the actual business process, it can be found that the main analysis and query conditions for vehicle historical trajectory data are: time, latitude and longitude, and specific vehicle. According to the analysis in the previous question, the number of trajectories of a car in a day can reach up to 8,640, and the amount of data can reach 194K, so it is not an ideal solution to store these data in a database. Because each vehicle reports a position in 10 seconds, 10,000 vehicles will have 1,000 database insertions in one second. Frequent database table operations will definitely affect the performance of the system. From the perspective of query analysis, a car has a maximum of 8,640 position report data a day, and 10,000 cars equals 864 million position report data. Even if the database partition table or sub-table is used and the key fields are indexed, if the vehicle trajectory is used The playback operation query will generate various I/O waits at the database level, leading to a sharp drop in system performance. Therefore, when the system is designed, the storage of the vehicle trajectory file adopts the file disk for direct storage. Choose the file storage structure. According to the actual business reference analysis and the determined storage method, the system design needs to consider how to store it to be more efficient. The most common is to use the storage structure of the hash file. Hashing files is similar to the Hash table in the data structure, that is, according to the characteristics of the keywords in the file, a hash function and a method to handle conflicts are designed to hash the records on the storage device. The difference from the Hash table is for the file , File records on the disk are usually stored in groups. Several records form a storage unit, which is also called a "bucket". Since our development language is Java, we can find from the HashMap structure implemented in the Java language API that the data structure of the hash table is composed of an object array and multiple object linked lists. The object array is similar to the concept of "bucket". Each bucket is identified by a hash value. If there are objects with the same hash value, they are stored in the object linked list of the "bucket". The search time of the data structure hash table is complicated. The ideal situation can reach O(1), that is, each "bucket" has only one object, and the worst may be only one "bucket". All data is put into the object list of this "bucket", so the worst The search time complexity will reach O(n). Of course, in the HashMap implementation process, there is a function of judging the total number of objects and the number of "buckets" and regenerating the correspondence between the new distribution "buckets" and objects. Understanding the data structure implementation of an actual hash table structure helps us design our own hash file based on the hash table data structure. Hash distribution of trace files. According to the use of the trajectory file and the attributes of the file itself, the system divides the file into storage levels according to the hierarchical structure of year, month, day, and vehicle license plate. Considering the scalability of the system, it is convenient to access more vehicles in the future. Use the last character of the license plate number for hash processing.
The principle and design of dispatching to find a car
Hvernig á að átta sig á kerfinu finnur sjálfkrafa viðeigandi ökutæki til að veita farþegum hugmyndir og hönnunarkerfi í GPS-byggðu leigubifreiðakerfinu og eftirlitskerfinu. Tilgangurinn með flutningsaðgerð kerfisins er að sjá farþegum fyrir tímanlegu ökutækjunum og sjá leigubílum fyrir næstu farþega til að draga úr akstursfjarlægð ökumannsins til að ná markmiðinu um orkusparnað og losunarlækkun. Það sparar peninga fyrir ökumenn og veitir farþegum þægindi.
Fyrstu tvö markmiðin sem þarf að hafa í huga í hönnunarferlinu við að leita að bílum til sendingar: hröð og nákvæm. Fyrst af öllu skulum við skilja grundvallareiginleika farþega sem hringir inn til að veita eftirspurn eftir bíl. 1) Símanúmerið sem farþeginn hringdi í; 2) Tíminn sem farþeginn notaði bílinn; 3) Staðurinn þar sem farþeginn ætlaði að fara um borð í bílinn. Símanúmer þessara þriggja grunneiginleika er hægt að fá beint í símtalakerfinu og ef bíllinn er bókaður fyrir hönd einhvers er hægt að fá það með því að biðja farþegann að hringja aftur í símanúmerið. Farþegar munu einnig hafa frumkvæði að því að tilkynna sendanda um tíma bílsins. Lykillinn er þriðji punkturinn á staðsetningu um borð. Farþegar segja almennt aðeins heimilisfang, svo sem: hvaða vegur er nálægt ákveðnum vegi og aðrar textalýsingar. Fyrir sendingarkerfið þarf kerfið að breyta upplýsingum um texta um ástand vega í sérstakar upplýsingar um lengdar- og breiddargráðu til að finna ökutæki og nota upplýsingar um lengdar- og breiddargráðu til að ákvarða hvort til séu hentug ökutæki til sendingar. Þess vegna er grundvallaratriðið við nákvæma leit í ökutæki hvernig á að fá lengdar- og breiddarupplýsingar um staðsetningu farþega.
Haltu upplýsingum um breiddargráðu og lengdargráðu pallbílsins
Að viðhalda lengdar- og breiddarupplýsingum upptökustaðarins er að viðhalda upplýsingum um vegasafn borgarinnar. Aðallega eru: breiddar- og lengdargrunnsgötumót gatnamóta, gögn um breiddar- og lengdargráðu við húsbyggingar, gagna um breiddar- og lengdargráðu hússins osfrv. Samkvæmt vegareinkennum mismunandi borga er hægt að nota mismunandi gögn til að senda uppruna breiddar- og lengdargráðu. gögnum af afhendingarstað. Til dæmis geta borgir með stöðluð og þroskað húsnúmer eins og Shanghai frekar breiddar- og lengdargráðu húsnúmeraflokksins sem uppsprettu lengdar- og breiddarupplýsinga um borð í ökutæki. Í sumum litlum borgum er hægt að nota breiddargráðu og lengdargráðu kennileita bygginga sem uppsprettu lengdar- og breiddargráðu farþega um borð. Almenna borgin er heppilegri fyrir breiddargráðu og lengdarveg gatnamóta sem uppruna lengdar- og breiddargráðu farþega um borð.
Það eru kostir og gallar við hverja af þessum aðferðum í samræmi við fjölda hluta, kennileiti og gatnamót. Það er venjulega notað í samsetningu meðan á raunverulegri notkun stendur. Húsnúmerið hefur tiltölulega lítið forritasvið og húsnúmeradreifing borgarinnar verður að vera stöðluð og samfelld. En leiðin á húsnúmerinu getur fljótt og nákvæmlega fundið lengdargráðu og breiddargráðu farþega um borð. Meginreglan er sem hér segir: Skiptu vegi í nokkra litla vegi eftir húsnúmeri og notaðu litlu vegina sem lengdar- og breiddarpunkta. Hvað varðar hversu mörg hurðarnúmer eru skipt í einn hluta, þá ákveður starfsfólkið sem safnar upplýsingum um veginn sjálft eftir raunverulegum aðstæðum vegarins. Að safna lengdar- og breiddargrunni hurðarnúmera getur verið sá háttur sem safnari keyrir inn í hurðarnúmer hluta ákveðins vegar og hleður lengdar- og breiddargráðu í gegnum GPS-tækið til að fá nákvæmustu lengdar- og breiddargögn götunnar. Í raunverulegri notkun kerfisins, þegar farþeginn hringir í bílasímann og tilkynnir veginn og húsnúmerið um borð, getur kerfið fundið húshlutann sem húsnúmerið tilheyrir samkvæmt vegi og húsnúmeri og fengið samsvarandi númer í húsakaflanum. Upplýsingar um lengdar- og breiddargráðu, til dæmis þegar farþegi hringir inn og segir að heimilisfang heimilisins sé nr. 10 Zhongshan Road, mun kerfið komast að því að nr. 10 Zhongshan Road er á bilinu nr. 2 til nr. 50 Zhongshan Road. , þannig að kerfið mun snúa aftur í 2. sæti í nr 50 Zhongshan Road. Upplýsingar um lengdar- og breiddargráðu sem samsvara vegarkaflanum eru notaðar sem lengdar- og breiddarupplýsingar farþega um borð. Þessi aðferð til að fá breiddargráðu og lengdargráðu umborðsstaðsetningar er tiltölulega nákvæm og skekkjan fer ekki yfir 500 metra. Ókosturinn er sá að tiltölulega mikið álag við öflun húsnúmeragagna krefst tímabundinnar og ítarlegrar grunnöflunar á fyrstu stigum. Ennfremur er stöðlunin í fjölda húsa í borginni tiltölulega mikil. Helsta leiðin til að fá breiddar- og lengdargráðu borgarvegar er að fá breiddar- og lengdargráðu um veginn með greiningu á kortagögnum borgarinnar. Þegar farþeginn hringir kemur fram að tiltekinn vegur er nálægt tilteknum vegi til að fá áætlaða breiddargráðu og lengdargráðu umferðarpunktsins. Þessi aðferð til að fá breiddar- og lengdargráðu er þægilegri, en ókosturinn er að ekki er hægt að tryggja nákvæmni staðsetningar. Þegar farþegi er kominn á langan veg án krossgata innan nokkurra kílómetra frá veginum, mun kerfið ekki geta fengið nákvæmar breiddar- og lengdargráðu farþega miðað við lengdar- og breiddarupplýsingar um gatnamótin.
Viðhald lengdar- og breiddarupplýsinga farþega um borð býr til traustan gagnagrunn fyrir kerfið til að senda sjálfkrafa ökutæki til að finna ökutæki. Enn þarf að íhuga að átta sig á bílaleit í sambandi við vegareiginleika borgarinnar og fjölda leigubíla sem taka þátt í sendingunni.
Finndu bíl eftir línulegri fjarlægð breiddar- og lengdargráðu
Þessi aðferð við að finna bíl er tiltölulega þægileg og hagnýt í framkvæmd og er oftast notuð í hagnýtum forritum. Framkvæmdarregla: Teiknaðu hring með lengdargráðu og breiddargráðu farþega um borð í miðju bílaleitarfjarlægðar sem radíus, svo framarlega sem ökutækið innan hringsins er ökutækið sem sendandinn er að leita að, ef engin er ökutæki í einu, mun geislainn halda áfram að bera saman við ökutækið í samræmi við ákveðið svið, þangað til ökutækið finnst eða radíus nær hámarksgildi sem kerfið setur. Þessi aðferð er tiltölulega einföld í framkvæmd, en skilvirkni er ekki mjög mikil, vegna þess að nauðsynlegt er að reikna fjarlægðina milli allra ökutækja og miðju hringsins. Það er ekki vísindalegt og skilvirkt. Ímyndaðu þér farþega á palli með 10.000 ökutæki sem kalla eftir bíl. Reyndar verða ekki meira en 20 ökutæki í kringum farþega um borð og aðeins eitt farartæki verður útvegað farþegunum. Við verðum hins vegar að reikna vegalengd allra 10.000 ökutækja á pallinum. Í grundvallaratriðum eru 9.980 útreikningar gagnslausir útreikningar. Í raunverulegri notkun, vegna stöðugrar umbóta á núverandi afköstum netþjónsins, er ennþá fljótleg og nákvæm útfærsluaðferð að nota þessa aðferð á leigubíl með fleiri en 10.000 ökutækjum. Sérstaklega í borg með eðlilega vegáætlun eins og Shanghai þarf ekki að huga að því fyrirbæri að ökutækið þarf að keyra langa leið áður en farþegi fer um borð til að snúa við til að sækja farþega. Að teknu tilliti til gífurlegra gagnslausra útreikninga sem myndast með því að finna bíl eftir línulegri fjarlægð lengdar- og breiddargráðu hefur kerfishönnun frekari hagræðingarstefnu.
Netbílaleit
Netleitin er til að forðast mikla gagnslausa útreikninga við að finna bíl í beinni fjarlægð og til að hámarka árangur leitarferlisins. Meginreglan er: í fyrsta lagi er borginni skipt í net eftir breiddargráðu og lengdargráðu; í öðru lagi er staða ökutækisins í ristinni skráð í samræmi við breiddargráðu og lengdargráðu ökutækisins í rauntíma. Samkvæmt staðsetningu farþega um borð, fást ökutækin í nærliggjandi netkerfi og fjarlægðin milli ökutækjanna í þessum ristum og breiddar- og lengdargráðu farþega er borin saman til að fá hentugasta farartækið fyrir farþegana.
GPS kortagögn til að finna bíl nákvæmlega
Burtséð frá því hvort það er frumstæðasta fjarlægð beinlínuleitar eða frekari netleitar, er grundvallarreglan ennþá að dæma um hvort bíllinn henti sem annar sendibifreið byggt á samanburði milli lengdar- og breiddarfarþega farþega um borð og fjarlægð ökutækisins með beinni línu. Hvernig á að sameina gögn til að ná nákvæmum bílaleitum er ekki algengt í núverandi sendingarkerfi. Ástæðan er sú að það er yfirleitt þægilegra fyrir innanlands vegakerfi uppbyggingar vegakerfa að snúa við. Stórar borgir með hækkuðum þjóðvegum kveða einnig á um að ekki sé heimilt að hækka tóma ökutæki. Þess vegna, í Kína, er nægjanlegt að finna bíl í gegnum beina fjarlægð milli farþega um borð og lengdar- og breiddarstig ökutækisins til að uppfylla grunnþarfir viðskiptavina.
En nokkrar sérstakar borgir eins og Jakarta í Indónesíu. Ökutæki á vegum þessarar borgar þurfa oft að keyra nokkra kílómetra eða meira til að snúa við. Þar sem Indónesía er staðsett á jarðskjálftasvæði hefur borgin ekki neðanjarðarlest og því eru tveir sérstakir vegir opnaðir um miðjan veginn til að aka hröðum strætisvögnum. Sannleikurinn er sá að aðskildu ökutækin geta alls ekki snúið við. Í svo óþægilegri borg, ef lengdar- og breiddargráða farþegapunkta er borin saman við lengdar- og breiddargráðu ökutækisins til að finna bíl, þá mun viðkomandi og ökutækið vera á mismunandi hliðum, eða staða farþega hefur bara verið ekið, þannig að ökutækið gæti þurft að fara um stórt svæði. Hringurinn getur komið aftur til að sækja farþega. Þetta stangast á við upphaflegan ásetning GPS sendingarkerfisins til að spara eldsneytisnotkun ökumanna. Til að leysa þessa mótsögn verður kerfið að íhuga að nota fjarlægðina milli ökutækisins og farþega um borð og upplýsingar um veginn til að finna viðeigandi ökutæki.
Hönnunarhugmynd: Vegirnir sem eru teiknaðir á kortinu eru almennt táknaðir með „hluti“. Vegi er skipt í samfellda „hluti“. Og í samræmi við breidd hvers hluta til að mynda "band". Á þennan hátt er hægt að sýna heilt vegamynstur á kortinu. Samkvæmt því hvort hver gatnamót geta beygt, hvort vegurinn er einstefna o.s.frv., Eru upplýsingarnar um veginn fyrst sameinaðar í beint línurit. Síðan, miðað við fjarlægð þess að leita að bíl, er reiknað út hvar vegpunkturinn er lengst frá farþegapunktinum og fær þannig upplýsingar um breiddar- og lengdargráðu vega. Samkvæmt gögnum um breiddargráðu og lengdargráðu sem fengust frá vegstýrðu línuritinu, auk breiddar á hverjum vegarkafla til að fá "belti" breiddargráðu og lengdargráðu vegarins. Dæmdu síðan með raunverulegri breiddar- og lengdargráðu ökutækisins hvort ökutækið sé á "beltinu" á veginum. Ef breiddargráða og lengdargráða ökutækisins eru innan sviðs „beltisins“ á veginum þýðir það að ökutækið gangi á hæfum vegi. Þrátt fyrir að samsetning grafferðar og hámarksfjarlægð færslu geti áttað sig á leit ökutækja, hvernig á að stilla upphafsstaðinn á "kortinu" á veginum, það er hvernig á að láta farþega sem fara um borð falla á veginn, þegar allt kemur til alls, vegastaðan þar sem margir farþegar fara um borð í ökutækið er ekki. Það verður að vera á veginum sem kerfið heldur og það er einnig mögulegt að breiddar- og lengdargráða sé bara í samfélaginu. Erfitt er að takast á við þessar aðstæður án mjög ítarlegra gagna um breiddar- og breiddargráðu í borginni, vegna þess að þú getur ekki einfaldlega farið að veginum með breiddar- og lengdargráðu farþega sem breiddar- og lengdargráðu farþega, því það er mjög líklegt að farþeginn sé í samfélaginu og láta farþegann fara um borð í ökutækið með næstu breiddargráðu og lengdargráðu. Vegurinn er bara aðskilinn með samfélagsveggnum. Til þess að dæma næsta veg er krafist mjög nákvæmra kortagagna og þau þurfa að vera nákvæm við hlið samfélagsins. Til þess að draga úr fjárfestingu í verkefninu getur kerfið aðeins samþykkt að lengdar- og breiddargráða farþegapunkta skuli byggjast á lengdar- og breiddargráðu vegarins.
Í grunnferli gagna bókasafnsins þarf að setja gögn bókasafnsins á raunverulegan veg. Ímyndaðu þér atburðarás þar sem kerfið fær breiddargráðu og lengdargráðu farþega og kerfið þarf að fara hratt frá gögnum í þéttbýli yfir á vegaflokkinn þar sem breiddar- og lengdargráða farþega er staðsett. Og samkvæmt þessum „kafla“ til að fá veginn „hluta“ sem er tengdur við „kafla“, þurfum við auðvitað aðeins að fá lengdar- og breiddargráðu bílsins minni en hámarksfjarlægðin sem tilgreind er til að finna bíll, vegna þess að línuleg fjarlægð milli tveggja punkta er styst, Ef beinlínufjarlægðin hefur farið yfir hámarksfjarlægð þess að finna bíl, þá mun raunveruleg ferilfjarlægð vegarins örugglega fara yfir hámarksfjarlægð þess að finna bíl. Samkvæmt öllum „köflum“ á veginum sem uppfylla hámarksfjarlægð þess að finna bíl og tengdur við vegstefnuna þar sem farþegarnir stigu um borð í ökutækið, fæst „beltið“ í samræmi við vegbreiddina sem skilgreind er af hverjum „kafla“ . Þess vegna er aðalvinnan í innleiðingarferlinu að byggja upp vegalíkan og hvernig hægt er að fá veginn fljótt tengd lengdar- og breiddargráðu farþega um borð. Fyrir uppbyggingu veggagna skaltu fyrst íhuga að skipta raunverulegum gögnum í „hluti“. Miðað við að lengsta „hlutanum“ sé deilt með lengdinni 1 km er öll Shanghai borgin tekin sem dæmi. Heildarlengd þjóðvega í Sjanghæ er um 11.000 kílómetrar og heildarlengd þéttbýlisvega er um 4.400 kílómetrar. Jafnvel þótt gagnamagni veghluta sé deilt með 1 km, þá er það mikilvægur eiginleiki af lítilli stærðargráðu miðað við „hluti“ vega.
Ályktun
Grundvallar og mikilvægasta aðgerð skipulags ökutækja er að finna rétta ökutækið hratt og örugglega. Þessi kafli kynnir og greinir grundvallarreglur um bílaleit og skilning, kosti og galla nokkurra aðferða við bílaleit. Frá algengustu fjarlægðinni til að finna bíl að rist til að finna bíl og að lokum sameina hönnun og útfærslu nákvæmrar bílaleitar við vegupplýsingar í þéttbýli. Þrátt fyrir að mikið sé af leiðinlegu viðhaldi og stjórnun á grunngögnum í þéttbýli í nákvæmu hönnunarferli bílaleitar ásamt upplýsingum um veginn, verður þessi aðferð við bílaleit fullkomnari með vegupplýsingum og kröfum viðskiptavina um sendingarnákvæmni er að verða hærri og hærri. Þegar öllu er á botninn hvolft, því nákvæmari sem leit að bíl er, því meira getur það dregið úr tómum kílómetrafjölda ökutækisins og dregið úr óþarfa eldsneytisnotkun og áhugi ökumannsins verður meiri og meiri. Tímasetningaraðferð bílaleitar með nákvæmum bílaleitum ásamt landupplýsingum á vegum verður notuð í auknum mæli í framtíðinni.
Gagnagreining og umsókn
vandamál með bílastæði
Það erfiðasta fyrir flutningaskrifstofurnar á ýmsum stöðum er að leigubílar í lögsögu þeirra senda frá sér verkföll og hætta að keyra atvik. Það hefur ekki aðeins áhrif á ferðalög borgaranna heldur er stærri ástæðan sú að slæm áhrifamáttur hefur mikil áhrif á stöðugleika og einingu samfélagsins. Það má segja að stöðvun leigubifreiða sé forgangsatriði hjá Samgöngustofu til að viðhalda stöðugleika. Undanfarin ár, vegna ýmissa ástæðna, hafa leigubílaverkföll og stöðvun átt sér stað af og til. Leiðin til að leysa stöðvun leigubíla er í grundvallaratriðum stjórnvaldsaðgerðaraðgerðir stjórnvalda og GPS vöktunarvettvangur er í grundvallaratriðum í aukahlutverki ef slys verður. Greindu í samræmi við ferlið við að leysa vandamálið með stöðvun leigubíla. Ríkisstjórnin getur almennt aðeins tekið þá aðferð að bæla leigubílafyrirtæki og sum fyrirtæki koma fram til að vinna hugmyndafræðilegt starf bílstjóra. Helsta ástæðan fyrir því að ökumenn hætta að keyra er ekkert annað en lágar tekjur og óhófleg vinnuálag. GPS-kerfið gegnir aðeins hluta eftirlitshlutverksins og stjórnvöld þurfa enn að senda fjölda starfsmanna í heimsókn. Getur þó GPS-byggður leigubílaútsending og eftirlitspallur aðeins spilað hlutverk eftirlitshlutverksins? Eftir greiningu og hugsun, verklega og fræðilega greiningu. GPS-byggt flutnings- og eftirlitskerfi leigubifreiða er fullkomlega fært til að koma í veg fyrir, áminna, fylgjast með meðan á atburðinum stendur og yfirlit eftir atburðinn.
Koma í veg fyrirfram
Almenn uppbygging leigubifreiðageirans frá stjórnvöldum til bílstjóra er í grundvallaratriðum sú sama. Í grundvallaratriðum hefur ríkisstjórnin stjórnsýsluvald til að stjórna rekstri leigubílafyrirtækja innan lögsögu sinnar; leigubílafyrirtæki hafa rétt til að stjórna leigubifreiðum og flytja daglegan rekstur leigubifreiða til bílstjórans með því að innheimta ökumanninum ákveðið stjórnunargjald í hverjum mánuði; ökumaður ber ábyrgð á akstri. Eldsneytiskostnaður, viðgerðarkostnaður og sektir vegna brota á reglum og reglugerðum eru í grundvallaratriðum bornar af ökumanni. Umsýslugjaldið sem greitt er leigubílafyrirtæki er í grundvallaratriðum um 2/3 af mánaðartekjum bílstjórans. Í gegnum samskiptin við starfsmenn ríkisins og skilning leigubílstjórans við meðferð frestunar á nokkrum atvikum kom í ljós að það eru u.þ.b. tvær ástæður fyrir stöðvun leigubifreiðar:
Tekjur ökumanns eru of lágar;
2. Það eru leiðtogar hvattir til og skipulagning. Með því að sameina orsök stöðvunaratburðarins við raunverulegt ástand GPS-byggða leigubifreiða- og eftirlitskerfisins getur kerfið veitt viðkomandi deildum áminningu fyrirfram. Við skulum greina raunverulegar aðstæður: leigubílar keyra á götum og sundum borgarinnar. Það er einmitt vegna hreyfanleika þess sem færir stjórnun flækjustigsins. Mikilvægasta tækið inni í leigubílnum er mælirinn sem skráir ítarlegar upplýsingar um hvert fyrirtæki ökumannsins. Að meðtöldum upphæð, upphafs- og lokatíma, mílufjöldi osfrv. GPS-stöðin sem sett er upp í leigubílnum kemur á rauntímatengingu milli leigubílsins og gjaldmælisins í bílnum og kerfisins með þráðlausum samskiptum í flugstöðinni. Stjórnendur geta stjórnað og stjórnað þessum leigubílum. Með samskiptakerfinu í flugstöðinni er hægt að átta sig á mælumetningu hvers ökutækis og daglegum tekjum. Með þessum tveimur vísitölukerfum er hægt að greina mánaðarlegar grunntekjur hvers ökumanns. Samkvæmt mánaðartekjum er hægt að dæma um hvaða ökumenn eru líklegir til að verða hvattir til og stjórnunardeildin getur gert margvíslegar ráðstafanir til að útrýma duldum hættum og verðandi. Til dæmis geta fyrirtæki tekið viðtöl við lágtekjubílstjóra á þann hátt að þeim sé annt um starfsmenn sína, kynnt sér erfiðleika ökumanna í tíma og veitt ákveðna erfiðleika niðurgreiðslur eða aukið raunverulegar tekjur bílstjóranna með því að veita góða starfsreynslu. Hugmyndin um varúðarráðstafanir hefur verið skýr: með tölfræðilegri greiningu á raunverulegum tekjum ökumannsins til að ákvarða hvort ökumaðurinn eigi möguleika á að stöðva. Með augliti til auglitis samskipta við lágtekjubílstjóra fyrirfram og aðrar aðferðir, reyndu að leysa raunverulega erfiðleika ökumanna, sjáðu um lágtekjubílstjóra og sýndu umhyggju fyrirtækisins fyrir ökumönnum til að ná þeim árangri að koma í veg fyrir vandamál áður en þeir eiga sér stað. Í þessu ferli gegnir kerfið því hlutverki að dæma fyrirfram nákvæmlega viðmælandann, forðast markmiðslaus fyrirtækisins og gera starf fyrirtækisins markvissara og árangursríkara. Helsti gagnagrunnur framkvæmdaraðferðarinnar er tekjugögn gjaldmælisins í leigubílnum og leigumælumetið. Þess vegna verður mælirinn að veita gagnaviðmót við GPS ökutækjastöðina og hægt er að „spýta“ gögnunum í flugstöðina eftir hverja þjónustu. Eftir móttöku gagna staðfestir flugstöðin sem er fest á ökutækinu og sendir staðfestingartilkynningarskilaboð til mælisins. Ökutæki, sem er uppsett á ökutæki, hleður upp mælagögnum í kerfið í gegnum þráðlausa samskiptaeininguna. Eftir að kerfið hefur fengið gögnin, geymir það þau í gagnagrunninum og sendir viðbragðsskilaboð sem staðfesta móttökuna til flugstöðvarinnar. Í orði er tryggt að heiðarleiki gagnanna verði afhentur með því að senda staðfestingarskilaboð. Á hinn bóginn þarf kerfið að setja ýmsar gagnamörk í samræmi við raunverulegar aðstæður á ýmsum stöðum til að ákvarða hversu mikið frávik er milli gagna sem hlaðið var upp og raunverulegu ástandi til að ákvarða hvort gögnin séu „áreiðanleg“. Til dæmis að stilla daglegan meðaltalsfjölda „mælinga“, hámarks rekstrarmagn stakrar mismunar o.s.frv. Kerfið býr til samanburðarniðurstöður samkvæmt ýmsum settum gagnamörkum fyrir stjórnendur að dæma um.
Að teknu tilliti til gífurlegs gagna um tekjugögn leigubifreiða eru 80 tekjugögn á ökutæki á dag til að reikna út dagleg gagnaupplýsingar um 10.000 ökutæki 800.000. Íhugaðu að samþykkja skiptingartöfluna til að átta sig á hönnunarferlinu. Það er ein skiptingartafla á mánuði. Taktu raunverulegan tíma uppsettra rekstrargagna sem lykil að skiptingartöflu og skiptingartöflu. Sjálfvirk tölfræði er gerð einu sinni á dag til að reikna út daglegar heildartekjur hvers ökutækis sem og fjölda mælinga, aksturs mílufjölda og tóma aksturs mílufjölda á dag. Fjöldi metra er notaður til að ákvarða hvort tekjur ökumanns séu í samræmi við raunverulegar aðstæður og rekstrarakstursfjöldi og tómur akstur er borinn saman til að ákvarða hvort hægt sé að spara markmið um eldsneytiseyðslu með því að minnka autt akstur.
Áminning fyrirfram
Hvernig á að minna stjórnendur á sem fyrst þegar ökumaðurinn stöðvaði samkomuna og gefa stjórnendum nægan tíma til að skilja raunverulegar aðstæður og gera lausnaráætlun? Þetta er líka aðgerð sem stjórnunardeild leggur mikla áherslu á. Tilgangur bílstjórans með stöðvunaratvikinu er að auka félagsleg áhrif og vekja athygli viðkomandi deilda og hlusta á kröfur þeirra. Þess vegna, ef leigubíl stoppar, munu ökutæki safnast saman á nokkrum áhrifamiklum stöðum í borginni. Þess vegna getur kerfið tekið upp tvær aðferðir við hönnun og mat á stöðvun og söfnun: 1) Forstilltu vöktunarsvæðið til að ákvarða rauntímafjölda ökutækja og stöðu ökutækis á svæðinu; 2) Ekki stilla eftirlitssvæðið fyrirfram og fylgja borgarmörkunum alveg. Hreinsaða svæðið er notað til að ákvarða hvort ökutækin séu að safnast saman. Þessar tvær aðferðir eru almennt byggðar á aðferð eitt og aðferð tvö sem viðbót. Hönnun og útfærsla fyrirfram ákveðins vöktunarsvæðis er: forstilltu svæðið á kortinu, sem getur verið marghyrningur, hringur og önnur mismunandi lögun. Kerfið býr til svæðishluti í bakgrunni í samræmi við stillt lögun og breiddar- og lengdarpunkta. Breiddar- og lengdargráða sem hlaðið er upp í rauntíma ákvarða hvort ökutækið sé á svæðinu. Til dæmis, á eftirlitssvæði marghyrninga, býr kerfið til marghyrninga hluti sem byggjast á punktum marghyrningsins sem notandinn hefur valið á kortinu og dæmir hvort ökutækið sé á svæðinu miðað við breiddar- og lengdarupplýsingar hvers ökutækis. Þegar ökutæki eru komin á svæði í meira en ákveðið svið, dæmir kerfið að þessir ökutæki séu grunaðir um að safnast saman. Þegar fjöldi ökutækja á eftirlitssvæði fer yfir viðmiðunarmörk sem stjórnendur setja, mun kerfið hefja ógn og láta viðkomandi starfsfólk vita um að fylgjast með farsímaskilaboðum og sprettiglugga fyrir kortakort. Kerfið veitir einnig ítarlegar upplýsingar um ökutæki á lykilvöktunarsvæðinu, svo sem fyrirtæki, nafn ökumanns osfrv. Ef það er metið að raunverulegur samkomuviðburður eigi sér stað geta viðkomandi deildir samið við umferðarlögregluna til að koma í veg fyrir að ökutækin komi frá halda áfram að safnast saman á svæðinu og á sama tíma, samkvæmt ökutækjafyrirtækinu sem kerfið veitir til að gefa út eftirlitspantanir til fyrirtækisins o.s.frv., hvetja þann sem sér um fyrirtækið að muna hvort annað á staðnum Viðskiptabílstjórar og farartæki. Í stuttu máli er tilgangurinn að nýta tímann til að takast á við ástandið áður en það stækkar og reyna að forðast útþenslu ástandsins.
Hugmyndin um að fylgjast með tilviljunarkenndum fjölda ökutækja á svæði er að ákvarða hvort fjöldi ökutækja innan eins kílómetra frá borginni fari yfir ákveðin þröskuld. Þar sem svæðið sem á að dæma er handahófskennd samsetning þarf kerfið að taka tölfræðilega dóma með því að sameina lítil svæði í stór svæði í innleiðingarferlinu. Til dæmis er 1 kílómetra svæði skipt í 9 litla 100 metra svæði. Ef þröskuldur ökutækja á 1 kílómetra svæði er 30, ef fjöldi ökutækja á hverju 100 metra svæði er meiri en 4, getur heildarfjöldi ökutækja á 100 metra svæði numið upp að þröskuldi 30 ökutækja. Þess vegna er vöktunarsviði kerfisins breytt í vöktun á litlu 100 metra svæði. Hönnun og útfærsla handahófsvöktunarsvæðisins er sem hér segir: kerfið skiptir allri borginni í svæði á 100 metra fresti eftir staðsetningu borgarinnar og landfræðilegri breiddar- og lengdargráðu. Skipt svæði er þröskuldur fyrir fjölda ökutækja. Kerfið dæmir út frá fjölda ökutækja á litlu svæði og þegar þröskuldinum er náð, dæmir það hvort heildarfjöldi ökutækja á nærliggjandi svæði nær viðvörunarmörkum fyrir fjölda bifreiða sem fylgst er með. Með því að bæta skilning leigubílstjóra á GPS-útstöðvum þarf vöktunarvettvangurinn einnig að gefa snemma viðvörun um óeðlilegt GPS-gögn. Til dæmis hefur fjöldi frávika á samskiptum ökutækja aukist verulega á tímabili og ökutækjum á eftirlitskortinu hefur fjölgað verulega til staðsetningar o.s.frv., Eru einnig gagnvísar sem stjórnunardeildin þarf að vera vakandi fyrir.
Vöktun viðburða
Í því ferli að stöðva og safna atburðum er hægt að tilgreina vöktunarsvæðið í gegnum kerfið og telja fjölda ökutækja á svæðinu og grunnupplýsingar eins og fyrirtækið og ökumann ökutækisins í rauntíma . Muna eftir ökumönnum í gegnum fyrirtæki.
Yfirlit á eftir Að
safna stöðvun varir venjulega í nokkra daga eða jafnvel meira en viku. Síðan er nauðsynlegt að framkvæma tölfræðilegar greiningar á ökumönnum og einingum sem taka þátt í samkomunni. Kerfið getur reiknað út uppsafnaða dvalartíma á bílastæðasvæðinu meðan á heildar bílastæði stendur miðað við sögulegar brautarupplýsingar ökutækisins til að ákvarða dýpt þátttöku ökumanns í bílastæðinu. Það getur dæmt hvort ökutækið hafi truflað samskipti flugstöðvarinnar um borð með því að safna tölfræðilegum gögnum á netinu á meðan á heildarstoppinu stendur. Veita gagnastuðning fyrir stjórnvöld og fyrirtæki til að finna og safna skipuleggjendum stöðvunarviðburðarins.
Þar sem þungamiðja stöðugleika í þéttbýli hefur stöðvun leigubíla og söfnun vakið athygli margra borga. Vöktunaraðgerðin í GPS-byggðum leigubílasendingar- og vöktunarpallinum veitir aðallega varúðar- og viðvörunaraðgerðir við að safna viðburðum við stöðvunarakstur. Helsta orsök átaka sem byggjast á atburðum við að koma saman við stöðvunarakstur getur einnig dregið úr tómum aksturshraða ökumanns með því að senda GPS, dregið úr tómri eldsneytisnotkun ökumanns og dregið úr útgjöldum ökumanns til að veita aðstoð.
Draga úr umferðarþunga og eldsneytisnotkun
Með hraðri þróun innlends hagkerfis hafa umferðarteppur í ýmsum borgum orðið sífellt alvarlegri. Mótsagnir af völdum umferðarteppna í innlendum fyrsta flokks borgum eins og Peking, Sjanghæ og Guangzhou hafa orðið æ meira áberandi. Enn alvarlegra er að umferðarþungi í þéttbýli hefur breiðst út frá borgum í fyrsta lagi til annars og þriðja borgar. Þrátt fyrir að margar stórar borgir séu farnar að kanna nokkrar takmarkandi ráðstafanir til að draga úr ferðalögum ökutækja til að ná þeim tilgangi að draga úr þéttingu vega í þéttbýli, svo sem stakur og sléttur fjöldi Peking, númerauppboð Shanghai og svo framvegis. Sumar borgir eru jafnvel farnar að skipuleggja gjaldtöku vegna þéttingar þéttbýlis. Fyrirbærið umferðarþungi í þéttbýli hefur enn ekki verið bætt. Þvert á móti, með þróun þjóðarhagkerfisins og bættum lífskjörum fólks, hefur eftirspurn fólks eftir bílakaupum orðið sterkari og mótsögnin við umferðarþunga í þéttbýli hefur orðið meira áberandi. Leiðin til að aðstoða við að draga úr umferðarþunga er að íhuga að skipta smám saman um leigubifreiðaraðferð við veginn með skipulagningu ökutækja. Samkvæmt tölfræðilegum tölum, ef tekið er Shanghai sem dæmi, þá er tómur akstur aksturs leigubíla meira en 40% af heildarakstri. Það er
Það er sagt að næstum helmingur af olíu í leigubíla til spillis á dag, og næstum helmingur bíla eru að aka á veginum. Þetta sóar ekki aðeins bensínpeningum, eykur vinnuafl ökumanna, heldur tekur einnig dýrmætar auðlindir í þéttbýli. Ímyndaðu þér að ef núverandi innanlands leigubílakerfi er breytt úr almennu símtali í símaúthleðsluaðferð, þá mun leigubíllinn hvíla þegar engir farþegar eru, það er, það sparar bensín og dregur úr vinnuafli og losar borgina auðlindir vega. Hugtakabreytingin er smám saman ferli. Ráðning leigubifreiða við vegkant er fyrirmynd sem hefur verið mótuð frá upphafi leigubifreiða og það hefur verið algengt viðskiptamódel heima og erlendis. Smám saman umskipti frá nýliðun til símsendinga þurfa ekki aðeins að breyta vinnubrögðum ökumanna heldur meira um vert að breyta hugsanavenjum farþega. Á þessari stundu hafa innlendar borgir og sumar borgir byrjað að koma upp flutningapöllum fyrir leigubíla í þéttbýli, svo sem Wuxi, Nanchang, Wenzhou og svo framvegis. Og með því að setja LED auglýsingaskjái á leigubíla til að ná fram greiðslujöfnuði og lágmarka fjármögnun ríkisins. Þar að auki geta flutningapallar leigubíla í þéttbýli í borgum eins og Wuxi og Nanchang í grundvallaratriðum náð sjálfbærni frá starfsfólki til viðhalds á kerfinu. Frá þessu sjónarhorni er flutningsvettvangur leigubíla á borgarstigi fullkomlega náð hvað varðar fjárfestingu fjármagns. Tökum Wuxi sem dæmi. Það eru um 4.000 leigubílar í Wuxi. Sendipallurinn var smíðaður fyrir tveimur árum. Frá upphafssímtali tuga farþega á dag til að hringja í leigubíla og til ársloka 2010 voru að meðaltali meira en 6.000 vel heppnaðar sendingar á dag. Meira en 8000. Það auðveldar ekki aðeins ferðalög Wuxi-borgara, heldur mikilvægara, gerir símtalið
Nýja bíldagandi líkan bílsins er byrjað að skjóta rótum. Fjölgun símhringinga og fjöldi árangursríkra sendinga er hægt að senda
Núverandi háttur til að hringja í bíl er almenningur viðunandi og ökumenn eru tilbúnir til samstarfs.
Hvernig dreifa má hæfileikum leigubifreiða með eðlilegum hætti er einnig eina leiðin til að átta sig smám saman á umbreytingu leigubifreiða frá ráðningum til ESC. Ef leigubifreiðar treysta aðallega á ESC, sem þýðir að draga úr tómum akstri á veginum, mun það einnig koma til mótsagnar, það er, möguleikar ökumanns til að sjá farþega verða minni, og tekjur ökumanns minnka. Hvernig á að halda leigubílnum á svæðinu þar sem bíllinn er notaður, það er, hann getur komist í farangursstöðu eins fljótt og auðið er eftir að hafa fengið pöntunina frá sendimiðstöðinni til að draga úr tómum akstursfjarlægð og íhuga að ökumaðurinn ætti að aka ökutækinu á það svæði til að bíða eftir að hafa sent farþegunum Ný viðskipti. Í stuttu máli, til að ná þessum umskiptum frá flutningi ökumanns yfir í ESC-stillingu, verður að leysa tvö vandamál ökumannsins fyrst: 1) Hvernig á að tryggja ákveðið magn af ESC-viðskiptum með leigubíl; 2) Hvernig á að skipta venjulegu bílastæði ökutækisins sanngjarnt. Ef þessi tvö vandamál eru ekki leyst er ómögulegt að ná markmiðinu umbreytingu viðskiptamódela. Byggt á tölfræðilegri gagnagreiningu leigubílafyrirtækjanna þriggja í Sjanghæ, Volkswagen, Jinjiang og Strætó, kemur í ljós að, að undanskildum strætisvögnum sem geta náð daglegum flutningsviðskiptum sem eru meira en 2 viðskipti á ökutæki, er meðalfjöldi árangursríkrar sendingar starfsemi fyrir Volkswagen og Jinjiang er aðeins Um það bil 1 penni. Fjöldi árangursríkra sendinga fyrir Volkswagen á einum degi er um 12.000, Jinjiang er um 4.000 og rútur geta náð 8.000. Skipt eftir fjölda ökutækja sem samsvarar þremur fyrirtækjum þeirra, má finna að núverandi fjöldi ESC þjónustu getur ekki uppfyllt daglegar viðskiptavísar ökumanna. Þetta er undirrótin sem ökumenn munu samt velja að ráða sem aðal rekstrarmáta. Þar að auki hafa ESC viðskipti þessara þriggja leigubílafyrirtækja verið starfandi í meira en fimm ár. Miðað við hraðann í þessum ESC viðskiptum er í grundvallaratriðum fyrirsjáanlegt að ef engin stjórnunarleg afskipti eru af því verður ekki hægt að skipta sjálfkrafa úr því að hækka nýliðun til ESC. Viðskiptalíkanið kom upp. Svo hvað getur GPS-byggður leigubifreiðarpallur gert til að stuðla að umbreytingu þessa viðskiptamódels?
Með gagnagreiningarkostum pallsins getum við veitt ökumönnum sanngjörn bílanotkunarsvæði og aðrar leiðir sem eru gagnlegar fyrir ökumennina til að ná því markmiði pallsins að dýpka hjörtu ökumannanna. Það er að segja að kerfið gegnir ekki aðeins hlutverki flutnings og eftirlits frá sjónarhóli stjórnenda heldur þarf það einnig að gegna hlutverki greiningar og leiðbeiningar frá sjónarhóli ökumannsins til að veita hagnýta aðstoð til að auka tekjur ökumanns og tryggja öryggi ökumanns. Með gagnagreiningu á stigi farþega og stigtímabili um borð, bendir ökumaður á þau svæði þar sem rúmmál fólksbifreiða er tiltölulega hátt á þessum tímabilum og sögulegur fjöldi ökutækja sem notaðir eru á hverju svæði og tímabili myndar daglegt sögulegt gagnasamanburður. Í raunverulegu rekstrarferlinu, ef fjöldi leigubifreiða á þessu svæði fer yfir ákveðið hlutfall á þessum tímabilum, getur kerfið brugðið og sent skilaboð til allra ökutækja til að minna svæðið á að ökutækin séu orðin mettuð og ökutæki geti hugsað sér að fara til annarra svæða til að koma í veg fyrir tóman akstur. Og miðað við söguleg gögn svæðisins og tímabilsins og fjölda ökutækja á svæði dagsins er dæmt hvaða svæði eru ennþá í skorti á ökutækjum og ökumaðurinn er leiðbeindur með því að senda skilaboð til nærliggjandi ökutæki. Með greiningu og leiðbeiningum frá sjónarhóli ökumanns er traust og álit sendipallsins smám saman komið á fót meðal ökumanna, þannig að ökumaður mun snúa úr efa í traust til að treysta á sendipallinn. Flugstöðin um borð hefur tengt ökutækið og kerfið náið. Svo framarlega sem stjórnendur eiga í meiri samskiptum en bílstjórinn til að skilja hugmyndir ökumannsins og leggur til sanngjarnar lausnir og stjórnunaraðferðir frá stjórnunarsjónarmiði, tel ég að bílstjórinn sé á vettvangi til að ná fram hagnýtum ávinningi. Samtímis er einnig hægt að verðlauna fjárfestingu fyrirtækja og ríkisstjórna áþreifanlega. Það hlýtur að vera að núverandi ESC viðskipti með minna en 2 viðskipti á bíl á dag eru ekki mikil fyrir fyrirtæki sem hafa fjárfest mikið í byggingarkerfum á fyrstu stigum. Það er langt í að draga úr þrengslum í þéttbýli og eldsneytiseyðslu með flutningi leigubifreiða. Erfiðleikinn liggur í umbreytingu venjubundinna vinnuaðferða og nýrra vinnuaðferða sem eru enn ófær um stjórnun og hagnýtingu. Sannið að það geti komið í stað gömlu vinnulaganna sem byggjast á hagsmunagæslu. En kerfið getur samt leikið ákveðið hlutverk við að draga úr tómum akstri ökumanns og draga úr eldsneytisnotkun. Þrátt fyrir að ekki sé hægt að skipta um stöðu Yang Zhao fyrir ESC eins og er, frá greiningu ESC gagna í innlendum borgum eins og Shanghai, Wuxi, Nanchang og Wenzhou, er aðferð ESC hægt og rólega farin að verða samþykkt af farþegum og ökumönnum. Það er bara það að enn er langt í land með að stækka enn frekar og skipta út Yang Zhao sem helsta leiðin til að laða að farþega.
GPS-based taxi dispatching and monitoring system technology is not a new set of technologies. As an application in the taxi industry, it has slowly begun to enter the use stage on a large scale. The realization of a taxi dispatch and monitoring platform has gradually become a must on the road of enterprise and government management and information construction.
Today, the number of vehicles connected to the platform is increasing, and the function of calculating the degree of road congestion can be gradually achieved through the platform. The investment in calculating whether the city road traffic is congested is very expensive. Taking the speed measuring coil laid on the high-speed driving road as an example, not only the investment is huge, but the maintenance workload is also huge. Through the real-time running speed of the taxis connected to the platform and the road where the latitude and longitude are located, as long as the connected vehicles reach a certain proportion, it can be used to achieve the basis of real-time road conditions of urban roads. This technology that relies on the basic data of the taxi dispatching and monitoring platform to access vehicles to determine the real-time road conditions of urban roads is currently in the research and preliminary use stage. It is believed that the application of this technology will be more perfect and popular in the future. Of course, this kind of road condition analysis also has certain limitations. After all, the distribution of taxis on urban roads does not reach the various roads of the city. Therefore, the data of road congestion analysis cannot be complete, but it is an economical The basic data source method of road analysis, the data source and analysis of GPS-based taxi dispatch and monitoring system are still trustworthy and cannot be ignored.
In the future with the continuous development and improvement of mobile communication technology, GPS-based taxi dispatch and monitoring systems can achieve many things that are currently desired but cannot be achieved through high-speed and high-bandwidth wireless communication networks. For example, real-time monitoring of the actual situation in the car, real-time monitoring of the actual situation in the car, and other tasks that require network bandwidth. At present, the monitoring of the situation in the car basically uses a camera to take pictures, such as taking pictures when passengers get in the car, take pictures when passengers get off, and take pictures when the vehicle is alarmed. And transmitted to the server through the wireless communication network. Due to the limitation of bandwidth, the sharpness of photos taken will be limited. If a 4G network is adopted, the network bandwidth will be able to withstand the upload of video surveillance data, and the system can achieve real-time viewing of every move in the car. With the continuous development of smart phones, it is very common for mobile phones to support GPS positioning. The GPS-based taxi dispatch system can even be developed in the direction of online car booking. Passengers can directly use a mobile phone with GPS positioning function to book a vehicle, the system can directly obtain GPS positioning data on the passenger's mobile phone, and generate passenger car orders, which can more accurately obtain passengers' boarding latitude and longitude.
Póstur: Sep-04-2020