תכנון והטמעה של מערכת שיגור וניטור מוניות על בסיס GPS

עם הפופולריות והשימוש הנרחב במערכת המיקום הגלובלית (GPS), התאפשר בענף המוניות להסתמך על GPS כדי להשיג את קו הרוחב והאורך של הרכב בזמן אמת ולהשתמש בו כבסיס למימוש זמן אמת של הרכב. מערכת תזמון וניטור. בעידן ההתפתחות המהירה של הכלכלה הלאומית, תעשיית המוניות, חלק חשוב בתחבורה הציבורית העירונית, נכנסה גם היא לתקופת התפתחות מהירה. סוגיות ניהול שונות הנובעות מתהליך הפיתוח המתמשך הונחו גם מול היחידות הממשלתיות המנהלות את ענף המוניות וניהול חברות המוניות. ענף המוניות הוא ענף שירותים הפונה ישירות לציבור. כלי רכב מפוזרים באזורים שונים בעיר, אשר משפיעה רבות על החברה וכרוכה במגוון רחב. עם הצמיחה המתמשכת של ארגונים, כיצד לתכנן באופן רציונלי את חלוקת קיבולת המוניות ולחזק את יכולת המוניות ניהול הבטיחות, חיזוק הפיקוח התאגידי על נהגים ומוניות, צמצום קילומטראז 'ריק ברכב, הפחתת צריכת הדלק, הפחתת בזבוז משאבים ומספק לנוסעים מהיר יותר ושירותים איכותיים יותר וכו ', לפתרון בעיות מעשיות הדורשות מערכות מתקדמות יותר לתמיכה בהן. לשתף פעולה כדי להשיג התפתחות בריאה ויציבה של הענף ולהבטיח שהחברה עצמה תהיה תחרותית יותר ומהירה יותר לקבלת החלטות בענף. מנקודת המבט של הנהלת הממשלה,  במערכת מבוססת GPS כדי לפתור עומסי תנועה עירוניים, להפחית את צריכת הדלק ברכב וזיהום האוויר, ולחזק את הפיקוח הממשלתי על מוניות. כיצד לתכנן ולבנות מערכת שלמה שתוכל לספק את המקיף והאחידות של הפיקוח הממשלתי במידה רבה ביותר; האופי המדעי והעתיד של ניהול ארגונים; יכולת הרחבה וחוסן של המערכת עצמה; יחד עם זאת, היא יכולה לספק לנהגים ולנוסעים להביא עזרה מעשית והטבות, וזו בעיה שיש לקחת בחשבון ולפתור אותה בתכנון מערכת שיגור מוניות ובקרה מבוססת GPS.

1

Roadragon’התפקיד העיקרי של  הוא
1. לתכנן מערכת שיגור וניטור מוניות המבוססת על הבנה מלאה של דרישות משלוח המוניות,
כולם מבנה היררכי ברור ויכולות הרחבה חזקות יותר.
2. בתהליך יישום המערכת, הציעו ופתרו מספר רב של חיבורי נתונים בין מוניות למערכת והקפידו על שלמות ואמינות העברת הנתונים. המטרה היא לגרום למערכת להגיע גבוה יותר עם משאבי שרת חסכוניים יותר
את היעילות והאמינות של העברת נתונים.
3. הציעו ופתרו את בעיית החיפוש המדויק אחר רכבים נשלחים בתנאי דרך מורכבים במהלך תהליך מימוש המערכת. המטרה היא לצמצם עוד יותר את הקילומטראז 'הריק של הרכב ולהפחית את צריכת הדלק של הרכב באמצעות חיפוש מדויק יותר ברכב.
להגיע לנקודת העלייה של הנוסע מהר יותר.
4. הציעו ופתרו את הבעיה של אחסון מהיר ויעיל ואחזור נתונים מאסיביים בתהליך הטמעת המערכת. ובשילוב עם ניתוח הפתרונות לבעיות ממשיות שנתקלו בתהליך יישום הפרויקט כדי להסביר את המערכת באופן יומיומי
את התפקיד בפועל של הניהול. המטרה היא לספק תמיכה מהירה ומדויקת בנתונים לניטור וניהול רכב בזמן אמת.
על פי הניתוח לעיל, ניתן לחלק את המערכת ל:
1. תת מערכת תחזוקת מידע בסיסית: אחראית בעיקר לתחזוקת מידע בסיסי של מפעילים, מידע בסיסי על כלי רכב, מידע בסיסי על נהגים ותחזוקת נתוני מפה בסיסיים.
2. תת מערכת תחזוקת הזמנות לרכב נוסעים: אחראית בעיקר על ממשק הנתונים עם המוקד הטלפוני ושמירת הזמנות הנוסעים, ושליחת מידע על הזמנת רכב למערכת שיגור הרקע.
3. תת מערכת משלוחי הזמנות: אחראית בעיקר על שמירת המידע הבסיסי בזמן אמת של הרכב, והתאמת הרכב בהתאם למידע ההזמנה שהתקבל. אינטראקציה בין הודעות לשער ההודעה.
4. תת מערכת מערכת הודעות: אחראית בעיקר להמרה ולהעברה בין פורמט ההודעה בתוך המערכת להודעה המוגדרת בין הטרמינל למערכת.
5. מערכת לניטור מפות : אחראית בעיקר לאינטראקציה של נתונים עם תת מערכת משלוחים, ואחראית על תצוגת מפות ותצוגה דינמית של כלי רכב בזמן אמת. ושלח פקודות בקרה לרכב.
זרימת הנתונים מלמטה למעלה היא: 1. הרכב שולח נתונים בזמן אמת לתת מערכת שער ההודעה; 2. שער ההודעות מעביר את הנתונים המנותחים לתת-מערכת השיגור; 3. תת-המערכת המשולחת האוטומטית מבוססת על ההזמנה
. הרכב מוקרן לפי קו רוחב ואורך הרכב; 4. תת המערכת המשולחת האוטומטית שולחת מידע נוסף כגון המידע בזמן אמת של הרכב ומצב הרכב אל תת המערכת לשירות מפות; 5. תת-מערכת שירותי המפה מתעדת את הנתונים ההיסטוריים של הרכב ושולחת אותם לתצוגה בזמן אמת של לקוח ניטור המפות.
זרימת הנתונים מלמעלה למטה מחולקת לשני חלקים עיקריים:
1. זרימת הנתונים שיזמה תת-המערכת המשלחת: 1. לקוח המשלוח מקבל את הבקשה לשימוש ברכב ושולח אותה אל תת-המערכת למשלוח אוטומטית; 2. תת-המערכת לשליחה אוטומטית מוצאת רכב מתאים על פי המצב בפועל.
רכבים מתאימים ושולחים בקשות לשימוש ברכבים לכלי רכב אלה דרך תת מערכת המסרים; 3. לאחר שתת-מערכת שער ההודעה מקבלת את ההודעה, היא ממירה את פרוטוקול ההודעה ושולחת אותה לרכב הספציפי
2. זרימת נתונים שיזם לקוח ניטור המפה: 1. לקוח הניטור יוזם בקשת ניטור לשרת המפה; 2. שרת מפות מעביר אותו לשער ההודעות דרך שרת השיגור; 3. שער ההודעות ממיר את הפרוטוקול ומעביר אותו לרכב ספציפי.
מזרמי הנתונים העליונים והתחתונים, ניתוח תת המערכות הוא בעיקר להודיע ​​אחד לשני על הבקשות היזומות באמצעות הודעות. אם לוקחים בחשבון את העדכניות המתאימה של המערכת ואת המקביליות הגבוהה של הנתונים, כל תת-מערכת בתהליך התכנון של המערכת מאמצת בעיקר את מודל "צריכת הייצור" לעיצוב כולל, והחשוב שבהם הוא להשתמש במודל הצופה להתנתק. הרעיון של מצב זה הוא לחתוך בקשות מקבוצות שרשורים שונות לעיבוד נתונים בצורה סינכרונית. "המפיק" הוא החוט המייצר את הבקשות שיש לעבד, וה"צרכן "הוא החוט המקבל את הבקשות הללו ומענה להן. היתרון בכך שהוא מספק הפרדה ברורה כך שחוטים יכולים להיות מתוכננים טוב יותר ויכולים להתאים יותר לפילוסופיית העיצוב של צימוד רופף. זה גם עוזר למפתחים למצוא ולפתור בעיות המתרחשות במהלך השימוש בפועל. העיצוב והיישום המודולרי של המערכת תורמים גם לתחזוקה והרחבת המערכת. יחד עם זאת, התכנון וההטמעה המודולריים מסייעים גם לבדיקת היחידות העצמאית של כל מודול כדי לשפר את ההתפתחות המקבילה בתוך הצוות, ויש לו גם ערבות מספקת לסיכוני תצורה מחדש של המערכת הבאים. הפונקציות העיקריות של כל תכנון תת-מערכת הן כדלקמן:
1. תת-מערכת שער הודעות: אחראית בעיקר על קליטה והעברה של הודעות, והמרת פרוטוקולי הודעות. קבלת והעברת הודעות צריכה לשקול תחזוקת חיבור במצבים מקבילים גדולים וכיצד שכבת היישום יכולה להבטיח את שלמות הנתונים שיישלחו בגודש רשת. הניתוק בין המסוף למערכת מובטח באמצעות המרת פרוטוקול. גם אם מוחלפת מערכת המשלוח והניטור של ספק הטרמינל, ניתן להבטיח את התקינות, ורק לשנות את מודול המרת הפרוטוקולים של תת המערכת של השער.
2. תת מערכת שיגור אוטומטי: אחראית על שיפוט אוטומטי אילו רכבים מתאימים לנוסעים על פי מיקום ומצב הרכב, בשילוב עם המידע הבסיסי של מכוניות הנוסעים והמידע הבסיסי של כבישי העיר. המודולים העיקריים כוללים מודול קבלת ושליחת הודעות, מודול המרה להודעות ומשימות (משימות), מודול מאגר חוטים. החלק המרכזי של הניתוק במערכת המשנה הוא מודול המרת המסר והמשימה. באמצעות מודול זה, הודעות שונות מומרות למשימה עצמאית אחת או יותר, והמשימות נשלחות לעיבודים שונים.
3. תת מערכת של שרת מפות: פיקוח על כלי רכב בזמן אמת ותעד נתונים של רכבים בזמן אמת לצורך ניתוח היסטורי.
תכנון ארכיטקטורת המערכת הכוללת מערכת
זו מאמצת את Java כשפת הפיתוח. בתהליך התכנון, המערכת כולה מחולקת למספר מערכות משנה על ידי תכנון מודולרי, ו- Socket משמש לאינטראקציה בין הנתונים למערכת למערכת. תת-המערכת מאמצת בעיקר את מצב הייצור והצריכה בכדי לממש את הניתוק בין משימות ופעולות ומשתמשת בטכנולוגיית ריבוי השחלות בגמישות רבה יותר כדי לשפר את יכולת העיבוד במקביל של המערכת. עבור המודולים הפונקציונאליים הנפוצים בין כל תת-מערכת (כגון ניהול חיבורי רשת ומודול תחזוקה, מודול מאגר פתילים וכו ') תכנון המערכת, המודולים הפונקציונליים והבלתי תלויים מתוכננים מראש בתהליך כדי למנוע פיתוח חוזר מיותר בתוך תת-המערכות. תת המערכת מתמודדת רק עם ההיגיון העסקי בפועל.
תכנון ומימוש מצב ייצור וצריכה
בהתחשב באינטראקציית המסרים בין תת המערכת למערכת המשנה, כמו גם דרישות העיבוד במקביל של מערכת המשימות בתוך תת המערכת, הבסיסית ביותר של המערכת בתהליך התכנון היא לאמץ את מודל ייצור וצריכה. הכנסת מצב זה לא תמצה במאמר זה. מאמר זה מציג בעיקר את מבנה העיצוב של מצב הייצור והצריכה במערכת זו, בשילוב עם ניתוח מפורט של התהליך העסקי של הזמנת משלוח המוניות והיישום הספציפי של מצב הייצור והצריכה. מבנה העיצוב הכללי של מצב הייצור והצריכה במערכת זו מבוסס על מאגר החוטים ואובייקטים המשימה. הפונקציות העיקריות המסופקות על ידי מאגר האשכולות כוללות תחזוקה וניהול פתילים, ותחזוקת וניהול תורי חיץ.
חשוב יותר במודל הייצור והצריכה הוא עיצוב מאגר החוטים. לדוגמה, OrderThreadPool אמור להשיג ביצוע על פי סדר מיון מותאם אישית. בהנחה שהמפעיל מסווג כסוג ו- New Order_Task הוא אובייקט העיבוד, אז OrderThreadPool יבוצע לפי הסדר בהתאם למשימות של כל מפעיל, מה שמבטיח שמבוצעת רק מאגר Order_Task אחד לכל מפעיל. העיקרון של התכנון הוא לשמור על שני HashMaps, HashMap אחד משמש לשמירה על הניהול בין תקן הסיווג למשימה המתאימה, המפתח הוא סוג הסיווג, והערך הוא רשימת המשימות של LinkedList. HashMap אחר המשמש לשמירת המשימה של קטגוריה זו מבוצע. ברגע שנשפט שיש משימה מאותו הסוג שמבוצעת במהלך getTask, סוג אחר של משימה נבחר להשוואה עד שהמשימה שהושגה היא סוג של משימה שאינה מתבצעת ומוחזרת למאגר האשכולות לביצוע. במקביל, המערכת מתמקדת גם בשימוש בכלים מקבילים בעלי ביצועים גבוהים המסופקים על ידי Java מאז 1.5, כגון: מנעולי קריאה-כתיבה, סמפורות, סנכרון חוטים למרכזיות זוגיות וכו '.
למרות שמערכת ניטור והעברת הרכב בעיקר כרוך רק במחלקת משלוחי הרכב, מכיוון שהיא מבינה את הקשר הישיר בין המערכת לרכב, היכולת להשיג נתוני רכב בסיסיים בזמן אמת הניחה בסיס איתן לניהול המעודן של החברה. לכן, בתהליך העיצוב, יש צורך גם לשקול באופן מלא את רעיונות הניהול של ההנהלה הבכירה של הארגון, ולשלב רעיונות ניהול גמישים עם מערכת תזמון קבועה יחסית. תן למערכת התזמון והניטור של הרכב להיות החלוץ של בניית מידע ארגוני ולשתף פעולה עם הארגון בכדי לממש את הכיוון האסטרטגי שלו.
תחזוקת הנתונים ההיסטוריים של הרכב

2

שמירה על הנתונים ההיסטוריים של הרכב היא המפתח לניתוח וניטור הרכב. הנתונים ההיסטוריים של הרכב כוללים בעיקר את נתוני קובץ המסלול ההיסטורי של הרכב, את נתוני התפעול ההיסטוריים של הרכב וכן הלאה. נתוני המסלול ההיסטוריים של הרכב משמשים בעיקר למציאת מסלול הנהיגה ההיסטורי של הרכב, המשמש לפתרון תלונות נוסעים, ניתוח תאונות דרכים ומציאת רכוש אבוד של נוסעים. בתהליך הגשת הבקשה בפועל, על מנת להבטיח את מסלול הרכב בצורה חלקה על המפה, יש צורך לוודא שתדירות הדיווח של נקודות מסלול הרוחב והאורך של הרכב צפופה מספיק. אם רכב מעלה דוח עמדה כל עשר שניות, יהיה 8640 ביום. נתוני דוח המיקום מחושבים כפיסת נתוני דוח מיקום [מספר זיהוי רכב 4 בתים + קו רוחב ואורך 8 בתים + זמן 4 בתים + מהירות בת 1 + בת אחד (כיוון, מיצוב) + מצב רכב 1 בתים + סוג אזעקת 4 בתים] א סה"כ 23 בתים, אחד ליום נתוני המסלול של המכונית הם עד 194K. עשרת אלפים כלי רכב ביום יכולים להגיע לנתונים של 1 גרם. כיצד לאחסן נתונים אלה? כיצד לספק למשתמשים שאילתות נוחות ומהירות? כיצד לנתח מידע שימושי על בסיס נתונים אלה כדי לספק רעיונות חדשים לניהול? יש לקחת בחשבון נושאים אלה בתהליך ויישום המערכת. נתוני ההפעלה ההיסטוריים של כלי רכב הם בעיקר ניתוח הכנסות היומי של כל רכב. ניתוח נתוני ההכנסות מסייע להנהלה לנתח האם החיובים הנוכחיים סבירים, האם קלט הקיבולת רווי ונתוני ניהול אחרים. נתוני התפעול כוללים בעצם נתונים בסיסיים כגון מספר לוחית רישוי, מספר זיהוי רכב, שעת התחלה, שעת סיום, קילומטראז 'תפעולי, סכום הפעלה וכו'. ניתוח 800,000 רשומות של 10,000 רכבים ליום עם 80 עסקאות לרכב ליום. כיצד להבטיח את תקינות נתוני ההפעלה, האחסון והניתוח של נתוני התפעול, וכיצד לחפור נתונים שימושיים לניתוח הניהול מנתוני ההפעלה הבסיסיים הללו, כך שמשתמשים יוכלו להשתמש בהם בצורה נוחה ומהירה הם כל הנושאים שיש לקחת בחשבון תהליך עיצוב המערכת.
 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

4

במערכת שיגור ובקרת מוניות מבוסס GPS, כיצד לממש את המערכת באופן אוטומטי מוצאת כלי רכב מתאימים שיספקו לנוסעים רעיונות ותוכניות עיצוב. מטרת פונקציית השיגור של המערכת היא לספק לנוסעים את הרכבים המתוזמנים ביותר, ולספק למוניות את הנוסעים הקרובים ביותר כדי להפחית את קילומטראז 'של הנהג כדי להשיג את המטרה של חיסכון באנרגיה והפחתת פליטה. זה חוסך כסף לנהגים ומספק נוחות לנוסעים.

שתי המטרות הראשונות שיש לקחת בחשבון בתהליך העיצוב של מציאת מכוניות למשלוח: מהיר ומדויק. ראשית, בואו להבין את התכונות הבסיסיות של נוסע שמתקשר בכדי לספק דרישה לרכב. 1) מספר הטלפון שהנוסע חייג אליו; 2) הזמן בו הנוסע השתמש ברכב; 3) המקום בו הנוסע עמד לעלות על המכונית. את מספר הטלפון של שלוש התכונות הבסיסיות הללו ניתן להשיג ישירות דרך מערכת השיחות, ואם המכונית מוזמנת בשם מישהו, ניתן להשיג אותה על ידי בקשה מהנוסע להתקשר חזרה למספר הטלפון. הנוסעים ייקחו יוזמה להודיע ​​לשולח על שעת המכונית. המפתח הוא הנקודה השלישית של מיקום העלייה למטוס. הנוסעים בדרך כלל מספרים רק כתובת פיזית כגון: איזו דרך קרובה לכביש מסוים ותיאורים טקסטואליים אחרים. עבור מערכת השיגור, המערכת צריכה להמיר את המידע על מצב הדרך הטקסטואלי למידע אורכי וקו רוחב ספציפי כדי למצוא כלי רכב, ולהשתמש במידע אורך ורוחב כדי לקבוע אם ישנם כלי רכב מתאימים למשלוח. לכן, העבודה הבסיסית ביותר לחיפוש מדויק ברכב היא כיצד להשיג את המידע אורך ורוחב של מקום עליית הנוסעים.

שמור על מידע רוחב ואורך נקודת האיסוף

שמירה על מידע אורך ורוחב של נקודת האיסוף היא לשמור על המידע על ספריית הדרכים בעיר. כולל בעיקר: נתוני קו רוחב ואורך אורך צומת דרך, נתוני קו רוחב ואורך אורך ציון דרך, נתוני קו רוחב ואורך של קטע הבית וכו '. על פי מאפייני הדרך בערים שונות, ניתן להשתמש בנתונים שונים כדי להעביר את מקור קו הרוחב והאורך. נתונים של נקודת האיסוף. לדוגמא, ערים עם מספרי בתים סטנדרטיים ובוגרים כמו שנחאי עשויים להעדיף את קו הרוחב והאורך של פלח מספר הבית כמקור לנתוני האורך והרוחב של נקודת העלייה לרכב. בערים קטנות מסוימות ניתן להשתמש בקו הרוחב ובאורך של מבנים בעלי ציוני דרך כמקור קו האורך והרוחב של נקודת העלייה לנוסעים. העיר הכללית מתאימה יותר לקו הרוחב והאורך של צומת הכביש כמקור קו האורך והרוחב של נקודת העלייה לנוסעים.

ישנם יתרונות וחסרונות של כל אחת משיטות אלה על פי קטע המספרים, מבני ציון דרך וצמתים. זה משמש בדרך כלל בשילוב במהלך היישום בפועל. לפלח מספרי הבית טווח יישומים קטן יחסית, ועל חלוקת מספרי הבית בעיר להיות סטנדרטית ורציפה. אך הדרך של קטע מספר הבית יכולה לאתר במהירות ובמדויק את קו האורך והרוחב של מקום עליית הנוסעים. העיקרון הוא כדלקמן: חלק את הכביש למספר כבישים קטנים לפי מספר הבית, והשתמש בכבישים הקטנים כנקודות אורך ורוחב. באשר למספר דלתות המחולקות לחלק אחד, הצוות שאוסף מידע על הכביש מחליט בעצמו על פי תנאי הדרך בפועל. איסוף קו האורך והרוחב של קטע מספר הדלתות יכול להיות הדרך בה הכונן נכנס לפלח מספר הדלתות של דרך מסוימת ומעלה את קו האורך והרוחב דרך מכשיר ה- GPS כדי להשיג את נתוני אורך ורוחב הדרך המדויקים ביותר. בשימוש בפועל במערכת, כאשר הנוסע מתקשר לטלפון הרכב ומודיע על הכביש ומספר הבית של מקום העלייה למטוס, המערכת יכולה למצוא את קטע הבית אליו מספר הבית שייך בהתאם לכביש ומספר הבית ולקבל את המספר המקביל בגזרת הבית. מידע על אורך ורוחב, למשל, כאשר נוסע מתקשר ומספר שכתובת הרכב היא מס '10 Zhongshan Road, המערכת תגלה כי מספר 10 Zhongshan Road נמצא בטווח של מס' 2 עד מס '50 Zhongshan Road אז המערכת תחזור למספר 2 עד דרך ז'ונגשאן 50. מידע אורך ורוחב המתאים לחלק הכביש משמש כמידע אורך ורוחב של נקודת העלייה לנוסע. שיטה זו להשגת קו רוחב ואורך מיקום העלייה למטוס מדויקת יחסית, והשגיאה לא תעלה על 500 מטר. החיסרון הוא שעומס העבודה הגדול יחסית של השגת נתוני מספרי בית דורש תקופה של איסוף נתונים בסיסי מפרך ומפורט בשלב המוקדם. יתר על כן, מידת הסטנדרטיזציה של מספרי בתי העיר גבוהה יחסית. הדרך העיקרית להשגת קו רוחב ואורך של דרך עירונית היא קבלת מידע רוחב ואורך של הכביש החוצה באמצעות ניתוח נתוני המפה של העיר. כאשר הנוסע מתקשר, מצוין כי הכביש המסוים קרוב לכביש המסוים כדי להשיג את קו הרוחב והאורך המשוער של נקודת העלייה למטוס. שיטה זו להשגת קו רוחב ואורך נוחה יותר, אך החיסרון הוא שלא ניתן להבטיח את דיוק המיקום. ברגע שנוסע נמצא בדרך ארוכה ללא פרשת דרכים במרחק של כמה קילומטרים מהכביש, המערכת לא תוכל להשיג במדויק את קו האורך והקו האורך המדויק של הנוסע בהתבסס על מידע אורך ורוחב של הצומת.

תזמון למצוא מכונית

3

תחזוקת נתוני האורך והרוחב של נקודת העלייה לנוסעים מספקת בסיס נתונים מוצק למערכת לשליחה אוטומטית של כלי רכב למציאת רכבים. יש עדיין לשקול את מימוש מציאת המכוניות בשילוב עם מאפייני הכביש של העיר המקומית ומספר המוניות המשתתפות במשלוח.
מצא מכונית על פי המרחק הקווי של קו רוחב ואורך.
שיטה זו למציאת מכונית נוחה יחסית ופרקטית ליישום והיא משמשת בתדירות הגבוהה ביותר ביישומים מעשיים. עקרון מימוש: צייר מעגל עם קו האורך והרוחב של נקודת עליית הנוסע כמרכז מרחק חיפוש המכונית כרדיוס, כל עוד הרכב בתוך המעגל הוא הרכב שהמשלח מחפש, אם אין רכב בכל פעם, הרדיוס ימשיך להיות מושווה לרכב על פי טווח מסוים, עד שהרכב נמצא או שהרדיוס יגיע לערך המקסימלי שהמערכת קובעת. שיטה זו פשוטה יחסית ליישום, אך היעילות אינה גבוהה במיוחד מכיוון שיש צורך לחשב את המרחק בין כל הרכבים למרכז המעגל. זה לא מדעי ויעיל. תארו לעצמכם נוסע על רציף עם 10,000 כלי רכב הקוראים לרכב. למעשה, לא יהיו יותר מ -20 רכבים סביב נקודת עליית הנוסעים, ורק רכב אחד יסופק לנוסעים. עם זאת, עלינו לחשב את המרחק עבור כל 10,000 הרכבים על הרציף. בעיקרון 9,980 חישובים הם חישובים חסרי תועלת. ואז בשימוש בפועל, עקב שיפור מתמיד בביצועי השרת הנוכחיים, שימוש בשיטה זו בפלטפורמת שיגור מוניות עם יותר מ -10,000 כלי רכב היא עדיין שיטת יישום מהירה ומדויקת. במיוחד בעיר עם תכנון כביש סביר כמו שנחאי, אין צורך להתחשב בתופעה שהרכב צריך לנסוע מרחק רב לפני מקום עליית הנוסעים כדי להסתובב לאסוף נוסעים. אם לוקחים בחשבון את החישובים הענקיים חסרי התועלת שהביאו מציאת מכונית לפי המרחק האורכי של קו האורך והרוחב, יש לעיצוב המערכת כיוון אופטימיזציה נוסף.
חיפוש מכוניות רשת
רשת החיפוש היא להימנע מחישובי ענק חסרי תועלת בתהליך מציאת מכונית במרחק ישר, ולייעל את ביצועי תהליך החיפוש. העיקרון הוא: ראשית, העיר מחולקת לרשתות על פי קו רוחב ואורך; שנית, מיקום הרכב ברשת נרשם על פי קו הרוחב והאורך בזמן אמת של הרכב. על פי מיקום נקודת העלייה לנוסעים, מתקבלים הרכבים ברשת שמסביב, והמרחק בין הרכבים ברשתות אלה לבין קו רוחב ואורך קו העלייה של הנוסעים מושווה להשגת הרכב המתאים ביותר לנוסעים.
נתוני מפת GPS כדי למצוא מכונית במדויק

5

לא משנה אם מדובר בחיפוש מכוניות בקו ישר המרחק הפרימיטיבי ביותר או בחיפוש נוסף ברשת, העיקרון הבסיסי ביותר הוא עדיין לשפוט אם המכונית מתאימה כרכב משלוח חלופי על סמך ההשוואה בין קו האורך לקו הרוחב של הנוסע. עלייה למרחק ומרחק קו ישר של הרכב. כיצד לשלב נתוני דרך בכדי להשיג מציאת רכב מדויקת אינו נפוץ במערכת השיגור הנוכחית. הסיבה היא שבדרך כלל יותר נוח לרכבי מבנה רשת כבישים עירוניים מקומיים להסתובב. ערים גדולות עם כבישים מהירים מוגדרות גם כן כי אסור להעלות רכבים ריקים. לכן, בסין, מציאת מכונית על ידי מרחק קו ישר בין נקודת עליית הנוסעים לנקודות אורך ורוחב של הרכב מספיקה בכדי לענות על הצרכים הבסיסיים של הלקוחות.
אבל כמה ערים מיוחדות כמו ג'קרטה באינדונזיה. כלי רכב בדרכי העיר הזו צריכים לעתים קרובות לנסוע כמה קילומטרים או יותר כדי להסתובב. מכיוון שאינדונזיה ממוקמת באזור המועד לרעידות אדמה, לעיר אין רכבת תחתית, ולכן באמצע הדרך נפתחות שתי דרכים מיוחדות לנסיעה באוטובוסים מהירים. האמת היא שהרכבים המופרדים כלל לא יכולים להסתובב. בעיר כל כך לא נוחה, אם משווים את קו האורך והרוחב של נקודת העלייה לנוסעים עם אורך ורוחב הרכב כדי למצוא מכונית, האדם והרכב יהיו בצדדים שונים, או שמצב הנוסע בדיוק היה מונע, כך שהרכב אולי יצטרך להסתובב באזור גדול. המעגל יכול לחזור לאסוף נוסעים. זה סותר את הכוונה המקורית של מערכת שיגור ה- GPS לחסוך בצריכת הדלק של הנהגים. על מנת לפתור סתירה זו, על המערכת לשקול להשתמש במרחק שבין הרכב למידע הנוסע למטוס הנוסעים וכדי למצוא רכב מתאים.
רעיון עיצוב: הכבישים המצויירים על המפה מיוצגים בדרך כלל על ידי "פלחים". דרך מחולקת ל"קטעים "רצופים. ובהתאם לרוחב של כל קטע כדי ליצור "להקה". באופן זה ניתן להציג על המפה תבנית דרך שלמה. על פי אם כל צומת יכול לפנות, האם הכביש הוא חד סטרי וכו ', מידע הדרך משולב תחילה לגרף מכוון. ואז, על פי מרחק החיפוש אחר מכונית, הוא מחושב היכן נקודת הדרך הרחוקה ביותר לנקודת העלייה לנוסעים, וכך מתקבל נתוני רוחב ואורך הכביש. על פי נתוני קו הרוחב וקו האורך המתקבלים מהגרף המכוון לכביש, בתוספת רוחב כל קטע בכביש כדי להשיג את קו הרוחב וטווח האורך של "החגורה". ואז שפט עם קו הרוחב והאורך האמיתי של הרכב אם הרכב נמצא על "חגורת" הדרך. אם קו רוחב ואורך הרכב נמצאים בטווח של "חגורת הכביש", המשמעות היא שהרכב פועל על דרך מוסמכת. למרות שהשילוב בין חציית גרפים למרחק החצייה המרבי יכול לממש את חיפוש הרכבים, כיצד להגדיר את נקודת ההתחלה בכביש "מפה", כלומר איך לגרום לנקודת העלייה של הנוסעים ליפול על הכביש, אחרי הכל, מיקום הכביש בו נוסעים רבים עולים על הרכב אינו חייב להיות על הכביש המתוחזק על ידי המערכת, וייתכן שגם קו הרוחב והאורך הם רק בקהילה. קשה להתמודד עם מצב זה ללא נתוני קו רוחב ואורך אורך מפורטים מאוד, מכיוון שלא ניתן פשוט לפנות אל הכביש עם קו האורך והאורך של הנוסע כקו רוחב ואורך האורך של הנוסע, מכיוון שסביר מאוד שהנוסע נמצא בקהילה. , ומשאיר את הנוסע לעלות לרכב עם קו הרוחב והאורך הקרובים ביותר הדרך מופרדת רק על ידי חומת הקהילה. על מנת לשפוט את הדרך הקרובה ביותר, נדרשים נתוני מפה מפורטים מאוד, והם צריכים להיות מדויקים לשער הקהילה. על מנת לצמצם את ההשקעה בפרויקט, המערכת יכולה להסכים רק שקו האורך והרוחב של נקודת העלייה לנוסעים יתבססו על קו האורך והרוחב של הכביש.
בתהליך הנתונים הבסיסי של ספריית הדרכים, יש למקם את נתוני ספריית הדרך על הכביש בפועל. תאר לעצמך תרחיש שבו המערכת מקבלת קו רוחב ואורך קו של נוסע, והמערכת צריכה לעבור במהירות מנתוני הדרך העירונית אל "קטע הכביש" בו נמצא קו הרוחב והאורך. ועל פי כביש "קטע" זה כדי להשיג את "קטע" הכביש המחובר ל"קטע ", כמובן, עלינו רק להשיג את מרחק האורך והרוחב הקווי של המכונית נמוך מהמרחק המרבי שצוין למציאת מכונית, מכיוון שהמרחק הליניארי בין שתי נקודות הוא הקצר ביותר. אם מרחק הקו ישר חצה את המרחק המרבי למציאת מכונית, אז מרחק העקומה בפועל של הכביש בהחלט יעלה על המרחק המרבי של מציאת מכונית. על פי כל "קטעי" הכביש שנמצאו העומדים במרחק המרבי של מציאת מכונית ומחוברים לכיוון הכביש בו עלו הנוסעים לרכב, "חגורת" הכביש מתקבלת על פי רוחב הדרך המוגדרת על ידי כל "קטע" כביש. . לכן, העבודה העיקרית בתהליך היישום היא בניית מודל דרכים וכיצד להשיג במהירות את הכביש המחובר לקו האורך והרוחב של הנוסעים העולים. לגבי מבנה נתוני דרך, שקול תחילה לחלק נתוני דרך בפועל ל"קטעים ". בהנחה שה"קטע "הארוך ביותר מחולק לאורך של קילומטר אחד, כל העיר שנחאי נלקחת כדוגמה. אורכם הכולל של הכבישים המהירים בשנגחאי הוא כ -11,000 ק"מ, והאורך הכולל של הכבישים העירוניים הוא כ -4,400 ק"מ. גם אם נפח הנתונים של קטע הכביש מחולק לק"מ אחד, זהו מאפיין חשוב בסדר גודל קטן בהתחשב ב"קטע "הכביש.
מסקנה
הפונקציה הבסיסית והקריטית ביותר בתזמון הרכב היא למצוא את הרכב המתאים במהירות ובדייקנות. פרק זה מציג ומנתח את העקרונות הבסיסיים של מציאת מכוניות ומימוש, יתרונות וחסרונות של מספר שיטות למציאת מכוניות. מהמרחק הנפוץ ביותר למציאת מכונית לרשת כדי למצוא מכונית, ולבסוף לשלב בין עיצוב ויישום חיפוש מכוניות מדויק למידע דרכים עירוני. אמנם ישנה כמות גדולה של תחזוקה וניהול מייגעים של נתוני דרך בסיסיים עירוניים בתהליך התכנון המדויק של מציאת מכוניות בשילוב מידע על הכביש, אך שיטה זו של מציאת מכוניות תהפוך מושלמת יותר ויותר עם מידע על הכביש ודרישות הלקוחות הדיוק למשלוח הולך וגדל. אחרי הכל, ככל שחיפוש אחר מכונית מדויק יותר, כך הוא יכול להפחית את הקילומטראז 'הריק של הרכב ולהפחית את צריכת הדלק המיותרת, והתלהבות הנהג תתגבר. שיטת התזמון של מציאת מכוניות עם מציאת מכוניות מדויקות בשילוב מידע גיאוגרפי בדרכים תשתמש בהרבה יותר ויותר בעתיד.
ניתוח נתונים ויישום
בעיית חניה במוניות

6

הדבר המטריד ביותר עבור לשכות התחבורה במקומות שונים הוא שהמוניות בתחומיהן שולחות שביתות ומפסיקות לנהוג באירועים. לא רק שזה משפיע על נסיעות האזרחים, אלא שהסיבה הגדולה יותר היא שהיקף ההשפעה הרע משפיע מאוד על יציבותה ואחדותה של החברה. ניתן לומר כי השעיית המוניות היא בראש סדר העדיפויות של לשכת התחבורה לשמור על יציבות. בשנים האחרונות, מסיבות שונות, אירעו מעת לעת שביתות במוניות והשעיות. הדרך לפתור השעיית מוניות היא בעצם שיטת ההתערבות הממשלתית, ופלטפורמת ניטור ה- GPS היא בעצם בתפקיד העזר במקרה של תאונה. ניתוח לפי תהליך פתרון בעיית עצירת המונית. הממשלה בדרך כלל יכולה לנקוט רק בשיטה של ​​דיכוי חברות מוניות, וחברות מסוימות מתייצבות לעשות את העבודה האידיאולוגית של הנהגים. הסיבה העיקרית לנהגים להפסיק לנהוג היא לא יותר מהכנסה נמוכה ועוצמת עבודה מוגזמת. מערכת ה- GPS ממלאת רק חלק מתפקיד הניטור, והממשלה עדיין צריכה לשלוח מספר רב של עובדים לביקור. עם זאת, האם פלטפורמת שיגור המוניות והניטור מבוססת ה- GPS יכולה לשחק רק חלק מתפקיד הניטור? לאחר ניתוח וחשיבה, ניתוח מעשי ותיאורטי. מערכת שיגור ובקרת המוניות מבוססת ה- GPS מסוגלת לחלוטין למנוע מראש, להזכיר מראש, לניטור במהלך האירוע ולסיכום לאחר האירוע.
מנע מראש
את המבנה הכללי של ענף המוניות המקומי מממשל לנהג זהה בעצם. ביסודו של דבר, לממשלה סמכות מנהלית לשלוט בהפעלת חברות מוניות בסמכותה; לחברות מוניות יש זכות להפעיל מוניות ולהעביר את התפעול היומיומי של המוניות לנהג על ידי חיוב הנהג בדמי ניהול מסוימים מדי חודש; הנהג אחראי לנהיגה. עלויות הדלק, עלויות התיקון וקנסות בגין הפרות של כללים ותקנות מוטלות בעצם על הנהג. דמי הניהול המשולמים לחברת מוניות מהווים בעצם כ -2 / 3 מהכנסותיו החודשיות של הנהג. באמצעות התקשורת עם עובדי הממשלה וההבנה של נהג המונית בתהליך הטיפול בהשעיית מספר אירועים, נמצא כי ישנן שתי סיבות להשעיית המונית בערך:

הכנסות הנהג נמוכות מדי;
2. ישנם מנהיגים שהוסתה וארגון. על ידי שילוב הגורם לאירוע ההפסקה עם המצב האמיתי של מערכת שיגור מוניות ובקרה מבוססת GPS, המערכת יכולה לתת למחלקות הרלוונטיות תזכורת מראש. בואו ננתח את המצב בפועל: מוניות נוסעות ברחובות ובסמטאות העיר. דווקא בזכות הניידות שלה מביאה את מורכבות הניהול שלה. המכשיר החשוב ביותר בתוך המונית הוא המונה, המתעד את המידע המפורט על כל עסק של הנהג. כולל סכום, זמן התחלה וסיום, קילומטראז 'וכו' מסוף ה- GPS המותקן על המונית יוצר חיבור בזמן אמת בין המונית למדד המוניות ברכב למערכת באמצעות תקשורת אלחוטית במסוף. מנהלים יכולים לשלוט ולנהל מוניות אלה. באמצעות מערכת מודולי התקשורת בטרמינל תוכלו לתפוס את רישום המונה של כל רכב ואת ההכנסה היומית. באמצעות שתי מערכות אינדקס אלה, ניתן לנתח את ההכנסה הבסיסית החודשית של כל נהג. על פי ההכנסה החודשית, ניתן לשפוט אילו נהגים עשויים להיות מופעלים, ומחלקת הניהול יכולה לנקוט במגוון אמצעים בכדי למנוע סכנות נסתרות ונביטה. לדוגמא, חברות יכולות לראיין נהגים בעלי הכנסה נמוכה באופן שידאג להם לעובדיהם, ללמוד על קשיי הנהגים בזמן ולספק סובסידיות מסויימות לקשיים, או להגדיל את ההכנסה בפועל של הנהגים על ידי הקניית ניסיון טוב בעבודה. רעיון הזהירות היה ברור: באמצעות ניתוח סטטיסטי של ההכנסות בפועל של הנהג כדי לקבוע אם לנהג יש אפשרות לעצור. באמצעות תקשורת פנים אל פנים עם נהגים בעלי הכנסה נמוכה מראש ושיטות אחרות, נסה לפתור את הקשיים האמיתיים של הנהגים, לטפל בנהגים בעלי הכנסה נמוכה ולהראות את דאגתה של החברה לנהגים כדי להשיג את האפקט של מניעת בעיות לפני שהם מתרחש. בתהליך זה המערכת ממלאת תפקיד בשיפוט מדויק של המרואיין לפני כן, הימנעות מחסרי מטרה של החברה והפיכת עבודת החברה לתכליתיות ויעילות יותר. בסיס הנתונים העיקרי לשיטת המימוש הוא נתוני ההכנסות של מד המוניות במונית, ורשומת מונית המונית. לכן, על המונה לספק ממשק נתונים למסוף רכב ה- GPS, ואת הנתונים ניתן "לירוק" למסוף הרכב לאחר כל שירות. לאחר קבלת הנתונים, המסוף המותקן ברכב מאשר ושולח הודעת משוב אישור למונה. המסוף המותקן ברכב מעלה את נתוני המונה למערכת דרך מודול התקשורת האלחוטית. לאחר שהמערכת מקבלת את הנתונים, היא שומרת אותם בבסיס הנתונים ושולחת הודעת משוב המאשרת את הקבלה למסוף המותקן ברכב. בתיאוריה, מובטח כי שלמות הנתונים תועבר באמצעות שליחת הודעת משוב לאישור. מצד שני, המערכת צריכה לקבוע ספי נתונים שונים על פי המצב בפועל במקומות שונים כדי לקבוע את מידת הסטייה בין הנתונים שהועלו לבין המצב בפועל כדי לקבוע אם הנתונים "אמינים". לדוגמא, קביעת המספר הממוצע היומי של "מדידה", כמות ההפעלה המרבית של הפרש בודד וכו '. המערכת מייצרת תוצאות השוואה על פי ספי נתונים שונים שנקבעו למנהלים לשפוט.
בהתחשב בכמות הנתונים העצומה על נתוני ההכנסות של מוניות, 80 נתוני הכנסות לרכב ליום כדי לחשב את רשומות נתוני התפעול היומיים של 10,000 כלי רכב הם 800,000. שקול לאמץ את טבלת המחיצות כדי לממש את תהליך העיצוב. כלומר, טבלת מחיצה אחת לחודש. קח את זמן ההתרחשות בפועל של נתוני ההפעלה שהועלו כמפתח של טבלת המחיצות וטבלת המחיצות. נתונים סטטיסטיים אוטומטיים נעשים פעם ביום כדי לחשב את ההכנסה היומית הכוללת של כל רכב, כמו גם את מספר המדידה, הקילומטרז 'התפעולי וקילומטראז' הנהיגה הריקה ביום. מספר המטרים משמש כדי לקבוע אם הכנסות הנהג תואמות את המצב בפועל, ומשווים את הקילומטראז 'התפעולי ואת הקילומטרז' הריק כדי לקבוע אם ניתן לחסוך את מטרת צריכת הדלק על ידי הקטנת הקילומטראז 'הריק.
להזכיר מראש
כיצד להזכיר להנהלה בהקדם האפשרי כאשר הנהג עצר את אירוע ההתכנסות, ולתת להנהלה מספיק זמן להבין את המצב בפועל ולהכין תוכנית פיתרון? זו גם פונקציה שמחלקת הניהול מייחסת לה חשיבות רבה. מטרת הנהג באירוע עצירת המונית היא להרחיב את ההשפעה החברתית ולקבל את תשומת ליבם של המחלקות הרלוונטיות ולהאזין לדרישותיהם. לכן, במקרה של עצירת מונית, רכבים יתאספו בכמה מקומות משפיעים בעיר. לכן, המערכת יכולה לאמץ שתי שיטות בעת תכנון ושיפוט עצירה ואיסוף: 1) הגדירו מראש את אזור הניטור כדי לקבוע את מספר הרכבים בזמן אמת ומצב הרכב באזור; 2) אל תקבע את אזור הניטור מראש ופעל באופן מוחלט אחר גבולות העיר. האזור המעודן משמש לקביעת האם הרכבים מתאספים. שתי שיטות אלה מבוססות בדרך כלל על שיטה אחת, ושיטה שתיים כתוספת. התכנון והיישום של אזור הניטור שהוגדר מראש הוא: הגדר מראש את האזור על המפה, שיכול להיות מצולע, מעגל וצורות שונות אחרות. המערכת מייצרת אובייקטים אזוריים ברקע על פי סוג הצורה שנקבע ונקודות קו רוחב ואורך. קו הרוחב והאורך שהועלה בזמן אמת קובעים אם הרכב נמצא באזור. לדוגמא, באזור ניטור המצולע, המערכת מייצרת אובייקטים מצולע מצולע על סמך נקודות המצולע שנבחר על ידי המשתמש במפה, ושופטת אם הרכב נמצא באזור על סמך מידע קו רוחב ואורך של כל רכב. ברגע שרכבים נמצאים באזור יותר מטווח מסוים, המערכת שופטת כי כלי רכב אלה חשודים בהתאספות. ברגע שמספר הרכבים באזור ניטור יעלה על הסף שנקבע על ידי אנשי ההנהלה, המערכת תתחיל להבהיל ותודיע לאנשי הרלוונטיות לשים לב באמצעות הודעות טקסט בטלפון הנייד וניטור חלונות קופצים של מפות. המערכת מספקת גם מידע מפורט אודות כלי רכב באזור הניטור המרכזי, כגון חברה, שם הנהג וכו '. אם נקבע כי מתקיים אירוע התכנסות אמיתי, המחלקות הרלוונטיות יכולות לתאם עם משטרת התנועה כדי למנוע מהרכבים ממשיכים להתכנס באזור, ובמקביל, על פי חברת הרכב שמספקת המערכת להוצאת צווי פיקוח על המיזם וכו ', להנחות את האחראי על המיזם לזכור זה את זה במקום נהגים עסקיים ורכבים. בקיצור, המטרה היא לנצל את הזמן להתמודד עם המצב לפני שהוא מתרחב ולנסות להימנע מהרחבת המצב.
הרעיון לפקח באופן אקראי על מספר כלי הרכב באזור הוא לקבוע האם מספר הרכבים בקילומטר אחד בעיר חורג מסף מסוים. מכיוון שהאזור שיש לשפוט הוא שילוב שרירותי, המערכת צריכה לבצע שיפוטים סטטיסטיים על ידי שילוב שטחים קטנים לאזורים גדולים בתהליך היישום. לדוגמה, שטח של קילומטר אחד מחולק ל -9 שטחים קטנים של 100 מטר. אם סף הרכבים בשטח של קילומטר אחד הוא 30, אם מספר הרכבים בכל שטח של 100 מטר עולה על 4, המספר הכולל של כלי רכב באזור 100 מטר עשוי להסתכם בסף של 30 כלי רכב. לכן טווח הניטור של המערכת הופך לניטור בשטח קטן של 100 מטר. התכנון והיישום של אזור הניטור האקראי הוא כדלקמן: המערכת מחלקת את העיר כולה לאזורים בכל 100 מטר על פי מיקום העיר וטווח הרוחב והאורך הגיאוגרפיים. השטח המחולק מגדיר את סף מספר הרכבים. המערכת שופטת על סמך מספר הרכבים באזור קטן, וברגע שמגיעים לסף, היא שופטת האם המספר הכולל של כלי הרכב באזור שמסביב מגיע לסף האזעקה למספר הרכבים המפוקחים. עם שיפור הבנת נהגי המוניות את מסופי ה- GPS, פלטפורמת הניטור צריכה גם לתת התראה מוקדמת מפני העלאת נתוני GPS לא תקינים. לדוגמא, מספר חריגות התקשורת ברכב עלה בצורה חדה לאורך תקופה, ומספר הרכבים במפת הניטור עלה בצורה חדה לצורך מיצוב וכו ', הם גם מדדי נתונים שמשרד הניהול צריך להיות ערניים לגביהם.
ניטור אירועים
בתהליך עצירה ואיסוף אירועים ניתן לייעד את אזור הניטור באמצעות המערכת, ולספור בזמן אמת את מספר הרכבים באזור ומידע בסיסי כמו החברה ונהג הרכב. . נזכר בנהגים דרך ארגונים.
סיכום לאחר מכן
השעיית איסוף נמשכת בדרך כלל כמה ימים או אפילו יותר משבוע. לאחר מכן, יש צורך לבצע ניתוח סטטיסטי על הנהגים והיחידות המעורבות בהתכנסות. המערכת יכולה לחשב את משך השהייה המצטבר באזור החניה במהלך החניה המצטברת על סמך מידע מסלול היסטורי של הרכב כדי לקבוע את עומק השתתפות הנהג בחניה. היא יכולה לשפוט אם הרכב שיבש את התקשורת של המסוף הנמצא על ידי איסוף הנתונים הסטטיסטיים של תעריף הרכב המקוון במהלך העצירה המצטברת. ספק תמיכה בנתונים לממשלה ולארגונים כדי למצוא ולרכז את מארגני אירוע ההשעיה.
כמוקד תחזוקת היציבות העירונית, עצירת מוניות והתכנסות משכו את תשומת ליבם של ערים רבות. פונקציית הניטור בפלטפורמת שיגור המוניות ובקרת ה GPS שלה מספקת בעיקר את פונקציות הזהירות וההתרעה מראש של אירועי איסוף בנסיעה בנסיעה. הגורם העיקרי לסכסוך המבוסס על התרחשות אירועי איסוף עצירת נהיגה יכול גם להפחית את קצב הנהיגה הריק של הנהג באמצעות פונקציית משלוח GPS, להפחית את צריכת הדלק הריקה של הנהג ולצמצם את הוצאות הנהג למתן סיוע.
צמצום העומס בכבישים וצריכת הדלק
עם ההתפתחות המהירה של הכלכלה המקומית, הפקקים בערים שונות הפכו לחמורים יותר ויותר. הסתירות שנגרמו כתוצאה מעומסי תנועה בערים מקומיות מהשורה הראשונה כמו בייג'ינג, שנחאי וגואנגג'ואו נעשו בולטות יותר ויותר. חמור עוד יותר הוא כי עומסי התנועה העירוניים התפשטו מערים מדרגה ראשונה לערים מדרגה שנייה ושלישית. אף על פי שערים גדולות רבות החלו לבחון כמה צעדים מגבילים להפחתת נסיעת כלי הרכב בכדי להשיג מטרה להקל על עומסי הכבישים העירוניים, כמו מספרם המוזר והאיזום של בייג'ינג, מכירה פומבית של לוחית הרישוי וכן הלאה. ערים מסוימות אף החלו לתכנן לגבות דמי עומס עירוניים. עם זאת, טרם שופרה תופעת עומסי התנועה העירוניים. נהפוך הוא, עם התפתחות הכלכלה הלאומית ושיפור רמת החיים של האנשים, הדרישה של האנשים לרכוש מכוניות התחזקה, והסתירה לעומס בכבישים עירוניים נעשתה בולטת יותר. הדרך לסייע בהפחתת העומס בכבישים היא לשקול החלפה הדרגתית של שיטת הובלת מוניות בצד הדרך באמצעות תזמון רכב. על פי הסטטיסטיקה, אם לוקחים את שנחאי כדוגמה, הקילומטראז 'הריק של מוניות מהווה יותר מ -40% מסך הקילומטרים. כלומר
נאמר שכמעט מחצית מהנפט במוניות מבוזבז ביום וכמעט מחצית מהמכוניות נוסעות על הכביש. זה לא רק בזבוז כספי דלק, מגביר את עוצמת העבודה של הנהגים, אלא גם גוזל משאבי דרך עירוניים יקרי ערך. תאר לעצמך שאם המערכת תחלוף את מערכת ההובלה המונית המקומית הנוכחית משיחה ציבורית לשיטת משלוח טלפוני, המונית תנוח כשאין נוסעים, כלומר היא חוסכת דלק ומפחיתה את עוצמת העבודה ומשחררת את העיר משאבי דרך. שינוי המושג הוא תהליך הדרגתי. גיוס לצד המוניות הוא מודל שנוצר מראשית ענף המוניות, והוא היה מודל עסקי נפוץ מהבית לחו"ל. המעבר ההדרגתי מגיוס למשלוח טלפוני דורש לא רק שינוי הרגלי העבודה של הנהגים, אלא חשוב מכך, שינוי הרגלי החשיבה של הנוסעים. נכון לעכשיו, ערים מקומיות וכמה ערים החלו להקים פלטפורמות למשלוח מוניות עירוניות, כמו וושי, ננצ'אנג, וונג'ו וכן הלאה. ועל ידי התקנת מסכי פרסום לד על מוניות כדי להשיג מאזן תשלומים ולמזער את המימון הממשלתי. יתר על כן, פלטפורמות משלוח מוניות ברמה העירונית בערים כמו וושי וננצ'אנג יכולות בעצם להגיע להספקה עצמית מאנשי כוח אדם לתחזוקת המערכת. מנקודת מבט זו, פלטפורמת משלוח המוניות ברמה העירונית הינה ברת השגה מבחינת השקעת הון. קחו את וושי כדוגמה. בוושי יש כ -4,000 מוניות. פלטפורמת השיגור נבנתה לפני שנתיים. מהשיחה הראשונית של עשרות נוסעים ביום להתקשר למוניות, ועד סוף 2010, היו בממוצע יותר מ -6,000 משלוחים מוצלחים ביום. יותר מ- 8000. זה לא רק מקל מאוד על נסיעתם של אזרחי וושי, אלא חשוב מכך, מאפשר לשיחת הטלפון
הדגם החדש של מכונית המכונית מברך מתחיל להשתרש. ניתן לשלוח את הגידול במספר שיחות הטלפון ומספר המשלוחים המוצלחים
. המצב הנוכחי של קריאת מכונית מקובל על הציבור, והנהגים מוכנים לשתף פעולה.
כיצד לחלק באופן סביר את יכולת המוניות באמצעות ניתוח נתונים היא גם הדרך היחידה לממש בהדרגה את המרת המוניות מגיוס ל- ESC. אם מוניות מסתמכות בעיקר על ESC, שמשמעותן צמצום הנהיגה הריקה בכביש, זה גם יביא לסתירה, כלומר, ההזדמנויות של הנהג לראות נוסעים הולכות ופחות, והכנסות הנהג יופחתו. כיצד להחזיק את המונית באזור בו משתמשים במכונית, כלומר, היא יכולה להגיע לעמדת עליית הנוסעים בהקדם האפשרי לאחר קבלת ההזמנה ממרכז השיגור כדי להפחית את הקילומטראז 'הריק ולשקול שעל הנהג לנהוג ברכב. לאזור ההוא להמתין לאחר שליחת הנוסעים עסק חדש. בקיצור, על מנת להשיג מעבר זה מהעברת הנהג למצב ESC, תחילה יש לפתור את שתי הבעיות של הנהג: 1) כיצד להבטיח כמות מסוימת של עסקי ESC במוניות; 2) כיצד לחלק את שטח החניה הרגיל של הרכב סביר. אם שתי הבעיות הללו לא נפתרות, אי אפשר להשיג את המטרה של שינוי המודל העסקי. בהתבסס על ניתוח הנתונים הסטטיסטיים של שלוש חברות המוניות בשנחאי, פולקסווגן, ג'ינג'יאנג ואוטובוס, נמצא כי למעט אוטובוסים שיכולים להשיג עסק משלוחים יומי של יותר מ -2 עסקאות לרכב, המספר הממוצע של משלוח מוצלח. הפעילות של פולקסווגן וג'ינג'יאנג היא בערך עט אחד. מספר המשלוחים המוצלחים לפולקסווגן ביום אחד הוא כ- 12,000, ג'ינג'יאנג הוא כ -4,000, ואוטובוסים יכולים להגיע ל- 8,000. מחולק במספר הרכבים המתאים לשלוש חברותיהם, ניתן למצוא כי המספר הנוכחי של שירותי ESC אינו יכול לעמוד באינדיקטורים העסקיים היומיים של הנהגים. זהו הגורם הבסיסי לכך שנהגים עדיין יבחרו לגייס כדרך הפעולה העיקרית שלהם. יתר על כן, עסקי ה- ESC של שלוש חברות המוניות הללו פועלים כבר יותר מחמש שנים. בהתבסס על המהירות של עסק ESC זה, ניתן לחזות בעצם שאם לא תהיה התערבות מנהלית, לא ניתן יהיה לעבור אוטומטית מהעלאת הגיוס ל- ESC. המודל העסקי עלה. אז מה יכולה לעשות פלטפורמת שיגור מוניות מבוסס GPS כדי לקדם את המרת המודל העסקי הזה?
באמצעות יתרונות ניתוח הנתונים של הפלטפורמה אנו יכולים לספק לנהגים אזורי שימוש ברכב סבירים ודרכים אחרות המסייעות לנהגים, כדי להשיג את מטרת הפלטפורמה להעמיק את ליבם של הנהגים. כלומר, המערכת ממלאת לא רק את תפקיד השיגור והניטור מנקודת מבט ההנהלה, אלא גם צריכה למלא את תפקיד הניתוח וההדרכה מנקודת מבטו של הנהג, על מנת לספק עזרה מעשית להגדלת הכנסה של הנהג ולהבטיח את בטיחות הנהג. באמצעות ניתוח הנתונים של נקודת העלייה של הנוסע ותקופת העלייה למטוס, הנהג מציין את האזורים שבהם נפח רכב הנוסעים גבוה יחסית באותן פרקי זמן, והמספר ההיסטורי של כלי רכב המשמשים בכל אזור ותקופת זמן מהווה היסטורי יומי. השוואת נתונים. בתהליך ההפעלה בפועל, אם מספר רכבי המוניות באזור זה עולה על אחוז מסוים בתקופות אלה, המערכת יכולה להתריע ולהעביר הודעה לכל הרכבים כדי להזכיר לאזור שהרכבים הפכו לרוויים, וכלי רכב יכולים לשקול לנסוע לאזורים אחרים כדי למנוע נהיגה ריקה. ובהתאם לנתונים ההיסטוריים של האזור ותקופת הזמן ומספר הרכבים באזור היום, נבחן אילו אזורים עדיין במצב של מחסור ברכבים, והנהג מונחה על ידי שליחת הודעות אל רכבים סמוכים. באמצעות הניתוח וההכוונה מנקודת מבטו של הנהג, מתבססים בהדרגה האמון והיוקרה של פלטפורמת השיגור בקרב הנהגים, כך שהנהג יהפוך מספק לאמון לסמוך על פלטפורמת השיגור. הטרמינל הקיים קישר קשר הדוק בין הרכב למערכת. כל עוד ההנהלה מתקשרת יותר מהנהג כדי להבין את רעיונות הנהג, ומציעה פתרונות ושיטות ניהול סבירות מנקודת מבט ניהולית, אני מאמין שהנהג נמצא בפלטפורמה להשיג יתרונות מעשיים. במקביל ניתן לתגמל באופן מוחשי את השקעתם של ארגונים וממשלות. זה חייב להיות שעסקי ה- ESC הנוכחיים עם פחות מ -2 עסקאות לרכב ליום אינם גבוהים עבור חברות שהשקיעו רבות בבניית מערכות בשלב מוקדם. צמצום עומסי הכבישים העירוניים וצריכת הדלק באמצעות שיגור מוניות הוא דרך ארוכה. הקושי נעוץ בהמרה של שיטות עבודה רגילות ושיטות עבודה חדשות שעדיין אינן מסוגלות לניהול וליישום מעשי. להוכיח שהוא יכול להחליף את דרך העבודה הישנה שמבוססת על הסברה. עם זאת, המערכת עדיין יכולה למלא תפקיד מסוים בהפחתת הנהיגה הריקה של הנהג ובצמצום צריכת הדלק. למרות שכרגע לא ניתן להחליף את עמדתו של יאנג ג'או על ידי ESC, מניתוח נתוני ESC בערים מקומיות כמו שנגחאי, וושי, ננצ'אנג וונג'ו, שיטת ESC מתחילה להתקבל לאט לאט על ידי הנוסעים והנהגים. רק שיש עוד דרך ארוכה להרחיב ולהחליף את יאנג ג'או כאמצעי העיקרי למשוך נוסעים.
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.


זמן פרסום: ספטמבר-04-2020