KR20240045601A - Indoor and outdoor continuous positioning switching device using sensor fusion, and Indoor and outdoor continuous positioning switching method - Google Patents

Abstract

The cloud server of the indoor/outdoor continuous positioning conversion method of the present invention assists in data exchange between each domain, and through the data exchange of each domain or the cloud server, continuous positioning is performed when the user or means of transportation passes indoors or outdoors. The positioning domain can receive different types of data obtained from other domains and perform data fusion of different types of data.

Description

Indoor and outdoor continuous positioning switching device using sensor fusion, and Indoor and outdoor continuous positioning switching method}

The present invention relates to an indoor-outdoor continuous positioning switching device and an indoor-outdoor continuous positioning switching method that calculates positions continuously without interruption and uses sensing data fusion between sensors belonging to each domain.

With the development of IoT technology for self-driving cars, continuously calculating positioning between indoors and outdoors without interruption is expanding its scope of application to a wide range of industries, and its importance is also increasing.

The present invention can calculate immediate, continuous, and accurate positioning, and for this purpose, sensor data fusion can be performed using surrounding domains or sensors based on a P-ITS that an individual can possess.

The indoor/outdoor continuous positioning switching device of the present invention includes a personal domain that provides user-related information; IoT domain providing vehicle-related information; an infrastructure domain that provides infrastructure-related information; A sensor domain that collects information for data exchange between domains; A positioning domain that calculates the position of the user or vehicle using data transmitted from the domain; It can include, and through data exchange between each domain and the cloud server, indoor and outdoor locations can be continuously calculated.

In addition, the cloud server of the indoor/outdoor continuous positioning conversion method of the present invention assists in data exchange between each domain, and through the data exchange of each domain or the cloud server, when the user or means of transportation passes indoors or outdoors, continuous Positioning can be calculated.

Additionally, the positioning domain of the present invention can receive different types of data obtained from other domains and perform data fusion on the different types of data.

Positioning Fusion Actor (PT-F) can integrate and process data from all domains. Information required for calculating positioning may be received from different domains. A common reception value of sensor data from each sensor in the personal domain (PD), sensor domain (SD), and IoT domain (IoTD) can be defined. These common received values can be a common message format, and the Positioning Fusion Actor (PT-F) can express the PVT service (position/velocity/time service) through an extended interface using the common received values for indoor and outdoor continuous positioning. You can.

Considering a case where a user (individual) in a building boards an external autonomous vehicle at a set time, the location of the unmanned autonomous vehicle is continuously tracked, the user's location is continuously tracked, and the vehicle and user's location is continuously tracked. By calculating the location and altitude, the meeting point can be matched.

Vehicle tracking, navigation indoors or indoors, traffic congestion monitoring and control, accident location detection, emergency situations, etc. can be linked to continuous location measurement.

1 is an explanatory diagram showing each component of the present invention.
Figure 2 is a configuration diagram of a personal domain of the present invention.
Figure 3 is a configuration diagram of the IoT domain of the present invention.
Figure 4 is a configuration diagram of the positioning domain of the present invention.
Figure 5 is a configuration diagram of the infrastructure domain of the present invention.
Figure 6 is a configuration diagram of the sensor domain of the present invention.
Figure 7 is an example where the user is located indoors.
Figure 8 is an example where the user is located outdoors.
Figure 9 is a relationship diagram between domains and actors, focusing on the personal domain of the present invention.
10 and 11 show operation sequences centered on the personal domain of the present invention.
Figure 12 is a relationship diagram between domains and actors, focusing on IoT of the present invention.
Figure 13 shows PVT calculation using common dataset conversion and sensor data fusion of the present invention.
Figure 14 shows a case where the P-ITS of the present invention moves from an open outdoor area to an underground area via indoors.
Figure 15 shows a case of PVT calculation using common data set conversion and sensor data fusion of the present invention in a reference signal weak area (Underground).
Figure 16 shows classification and standards for sensor signal strength of the present invention.
Figure 17 is a comparison before and after using the common data (message) format of the present invention.
Figure 18 is an explanatory diagram of input, processing, and output of the present invention.
Figure 19 is an example of sensor fusion of the present invention.

With reference to FIGS. 1 to 8, the indoor/outdoor continuous positioning switching device of the present invention will be described.

Delays or disconnected positioning of autonomous vehicles, whether indoors or outdoors, can cause serious problems, including several accidents.

What is important in calculating continuous positioning between indoors and outdoors based on personal domain (PD) is a common message format for calculating positioning and an extended interface for calculating stable and reliable positioning. It can be.

A common message format may mean a common structure of messages input for continuous indoor/outdoor positioning calculation, and may mean that structural complexity in encoding is greatly reduced. Therefore, information received from GNSS (Global Navigation Satellite System), IMU (Inertial Measurement Unit), WiFi (Wireless Fidelity), Odometer, Telecom Recv (Received Signal Strength Indication), etc. is used to calculate the positioning of PVT (Position, Velocity, Timing) service. For this reason, it can be sent to the calculation unit in a separate format, and the calculation to calculate it can be very complicated and take a long time. However, if the information data of sensors measured in each domain is received as a common reception value through a common message format, the complexity of calculation can be reduced and the time taken for calculation can be shortened.

Data from various sensors measured in various domains are not calculated in individual formats and displayed on individual interfaces, but the positioning fusion actor (PT-F) uses the sensing information received from individual domains in a common message format or common received value. It can be calculated and expressed as a PVT service in the extended interface.

The common actor is for continuous indoor and outdoor positioning through sensor fusion. To achieve this, the device attached sensor unit (GPS, Lidar, IMU, Odometer, etc.) used for location recognition and services are used. It may be a sensor actor (S-S) (A-GPS, D-GPS, etc.), and sub-actors of a positioning domain (PTD) that controls the sensor.

That is, common actors among the personal domain (PD), IoT domain (IoTD), and infrastructure domain (ID) may be constituent actors of the sensor domain (SD) and positioning domain (PTD).

In addition, depending on the calculation entity that calculates the final positioning using information from various sensor domains (SD), it can be divided into a server-based indoor positioning method or a terminal-based indoor positioning method, in which the calculation entity stores information for positioning judgment. In conjunction with what is being done, the sequence operation between each domain may be related to the information source. For example, in the case of server-based indoor positioning, information such as routing path can be requested from each actor or additional cloud server (CS), and in the case of terminal-based indoor positioning, each actor or additional terminal or personal device actor (P You can request a reply from -DEV) for information such as routing path.

The present invention may include a cloud server (CS) and multiple domains.

The plurality of domains may be a personal domain (PD), an IoT domain (IoTD), a sensor domain (SD), an infrastructure domain (ID), and a positioning domain (PTD). Each domain can be classified according to the performer and role, and elements belonging to each domain can be referred to as actors. Actor may have the same meaning as each part described below.

The entity performing the personal domain (PD) may be a device that is always carried by a moving user and transmits location information through a mobile communication network. A personal domain (PD) can independently provide location information of a person or object, or a personal domain (PD) can provide location information of a person or object through data exchange with another domain. The personal domain (PD) can use vehicles, bicycles, trains, e-mobility, etc. belonging to the IoT domain (IoTD).

The personal domain (PD) may include a personal device actor (P-DEV), a personal information actor (P-I), a personal state actor (P-S), a personal location actor (P-L), and a personal altitude actor (P-F).

The personal device actor (P-DEV) may be equipped with sensors such as GPS, Wi-Fi, BT (Bluetooth), and RFID. A personal device actor (P-DEV) may be an actor within a personal domain (PD).

The personal device actor (P-DEV) can store information on lower actors of the personal domain (PD) and can proceed with the processor. In other words, it can be equipped with a device sensor actor (S-DEV) for indoor and outdoor continuous positioning, and can be responsible for information processing with the service sensor actor (S-S) through an available communication network. Location and routing information can be transmitted to another domain or cloud server (CS) through a communication network.

A personal information actor (P-I) may be registered information such as gender, age, and type of disability required to calculate a person's location and travel distance. In other words, it may be information about whether the individual user is driving or walking, whether he or she is a man or a woman, whether he or she is an adult or a child, whether he or she has a disability, and the type of disability. A personal information actor (P-I) may be necessary for accurate calculation of location or route.

The personal state actor (P-S) can detect or determine whether the user is moving or not and whether the user is in the vehicle. Through the sensor mounted on the personal device actor (P-DEV), human motion can be detected based on the IMU sensor, and the presence or absence of occupants in the vehicle can be analyzed or determined based on Wi-Fi, BT, etc.

Personal location actor (P-L) is capable of accurate location analysis and judgment for continuous positioning of the user. Based on sensors or maps, access points, and routing mounted on the personal device actor (P-DEV), urban, rural, and indoor locations , places such as tunnels can be distinguished and judged, and surrounding traffic conditions such as crossings, longitudinal lines, and intersections can be analyzed or judged.

The personal height actor (P-F) may be indoor floor information of a user or vehicle. In other words, the indoor floor number information may be altitude information from the ground, such as whether it is a basement, a middle floor, or a top floor.

The subject performing the IoT domain (IoTD) may be a vehicle or an e-mobility service provider that provides vehicle means. The IoT domain (IoTD) can be independent or play the role of providing location information services, checking whether passengers are on board, and collecting or providing driving information through data exchange with other domains.

The IoT domain (IoTD) consists of IoT device actors (IoT-DEV), IoT information actors (IoT-I), IoT communication actors (IoT-C), IoT state actors (IoT-S), and IoT location actors (IoT-L). may include.

An IoT device actor (IoT-DEV) is a subject device that collects the location and vehicle information of a vehicle, and may be an autonomous vehicle or a regular vehicle.

In order for the vehicle means to collect information, the vehicle means may be provided with sensors, etc., and the sensors may include, for example, GNSS, IMU, Odometer, lidar, radar, cameras, etc. Methods for collecting information from an IoT device actor (IoT-DEV) may include various methods, such as collecting information directly from a connected vehicle or collecting information sensed by a vehicle through the vehicle's OBD port, etc.

The IoT device actor (IoT-DEV) may be the subject of action of the IoT domain (IoTD), may store information of lower actors of the IoT domain (IoTD), and may proceed with the processor.

A device sensor actor (S-DEV) may be provided for indoor and outdoor continuous positioning, and may be responsible for processing information with the service sensor actor (S-S) transmitted through the IoT communication actor (IoT-C).

IoT Information Actor (IoT-I) is used to identify the type of vehicle (passenger vehicle, minibus, bus, train, bicycle, quickboard, etc.), type (electric, engine (gasoline/if), none), and ownership/sharing. It may include registration information, etc.

In addition, IoT information actor (IoT-I) determines by what means the user uses the vehicle (bus with more than 15 seats, bus with less than 15 seats, truck with less than 1 ton, truck with more than 1 to 3 tons, truck with more than 3,0 tons, passenger car) , railway, motorcycle, bicycle, e-mobility, etc.), what type of vehicle you use (electric/hydrogen, hybrid, gasoline, diesel), type of use (general, rental, public, emergency (police/fire/medical)), etc. can be distinguished. Like personal information actors (P-I), this may be necessary to calculate accurate information such as location or route.

The IoT communication actor (IoT-C) can communicate with the cloud server (CS) through a communication network to improve the location information and information accuracy of the vehicle, and can also communicate with the cloud server (CS) mounted on the IoT device actor (IoT-DEV). It can be responsible for information processing with service sensor actors (S-S) through a communication network. In other words, location information can be transmitted through mobile communication networks such as Wi-Fi, UWB, and BT.

IoT State Actors (IoT-S) can represent the current state of a vehicle vehicle. In other words, the IoT state actor (IoT-S) may indicate whether the vehicle is running, stopped, or parked.

IoT location actors can analyze or determine accurate location information for continuous positioning of vehicles or situational information such as crossings, longitudinal lines, and intersections. Based on the sensors, maps, access points, and routing provided in the vehicle, locations such as downtown, rural areas, indoors, and tunnels can be classified and judged, and situations such as crossings, longitudinal lines, and intersections can be analyzed and judged.

The performer of the sensor domain (SD) may be a manufacturer of various sensors that can be used to provide location information or a service provider for generating location information and improving precision. It can refer to various sensors mounted on a device, and can be mounted on actors in each domain to provide location recognition services.

The sensor domain (SD) may include a service sensor actor (S-S) and a device sensor actor (S-DEV).

Service sensor actor (S-S) can collectively refer to service-type location recognition services such as triangulation by A-GPS, D-GPS, wi-fi, etc., and sensors will be provided to the actual performing entity in each domain. You can. A-GPS may provide GPS trajectory information to reduce GPS start speed and TTFF (Time to First Fix), and D-GPS may provide GPS error information.

Device sensor actor (S-DEV) collects location information through sensors such as GPS, lidar, radar, IMU, image, and odometer mounted on the personal device actor (P-DEV) or IoT device actor (IoT-DEV). Sensors can be collectively referred to as sensors, and can be provided to the actual performer of each domain.

The entity performing the infrastructure domain (ID) may be a public or private facility management agency. The location of infrastructure or surrounding traffic information data can be transmitted to other domains. Communication network connection or connection location information can be provided through triangulation of an access point (AP) in the personal domain (PD) or IoT domain (IoTD), and the location value determined by providing it to the connected communication network is sent to the cloud server (CS). It can be sent to .

The infrastructure domain (ID) may include an infrastructure communication actor (I-C), an infrastructure location actor (I-L), and an infrastructure altitude actor (I-F).

Infrastructure Communication Actor (I-C) refers to the network access terminal of a router installed at key locations in various infrastructure such as buildings and tunnels, or a cloud server (CS) connected to the access terminal, and uses triangulation. It can perform the role of transmitting location data of personal device actors (P-DEV) or IoT device actors (IoT-DEV). In other words, location data of a personal terminal or a transport vehicle transporting an individual can be transmitted to another domain or cloud server (CS).

The infrastructure communication actor (I-C) can transmit unique hardware identification values, such as the MAC address, to help the personal device actor (P-DEV) or IoT device actor (IoT-DEV) identify and recognize the location of a specific location. You can. In addition, it can provide information such as the signal strength of the access point for triangulation, and can use frequency-using electronic tag identification technology such as RFID to identify personal device actors (P-DEV) or IoT device actors (IoT-DEV). It can provide information on the presence or absence of passage through a specific area.

The infrastructure location actor (I-L) can transmit location records such as tunnels matched with the unique identification value of the infrastructure to other actors. The location record transmitted by the infrastructure location actor (I-L) is the unique identifier and mapped location information of the infrastructure stored in the cloud server (CS), and is composed of classification information such as roads, tunnels, and buildings of the corresponding infrastructure and address data. It can be configured.

Infrastructure elevation actors (I-Fs) may include location-specific records of infrastructure, including indoor floor numbers, elevators, and fingerprint maps using already-established radio maps.

The infrastructure altitude actor (I-F) includes the unique identifier of the infrastructure stored in the cloud server (CS) and the mapped floor number to check the floor number and altitude information of the personal device actor (P-DEV) or IoT device actor (IoT-DEV). And various information for triangulation may be included.

The positioning domain (PTD) can provide continuous indoor or outdoor continuous positioning. Through sensor fusion between each sensor and information exchange with the cloud server (CS), indoor or outdoor continuous PVT (Position, Velocity, Timing) services can be provided.

The positioning domain (PTD) may include a positioning altitude actor (PT-F), a positioning velocity actor (PT-V), a positioning state actor (PT-S), and a positioning accuracy actor (PT-A).

Positioning Fusion Actor (PT-F), as the domain performer, can recognize the location with an independently installed sensor and uses the core technology of Sensors Fusion, which performs continuous indoor and outdoor positioning, to determine low-level data such as speed. A decision can be made as a result of collecting the actor's data, and through this decision, positioning, which is the final location data, can be calculated.

Positioning Velocity Actor (PT-V) can generate speed data of a moving person or object through sensed data. In other words, the positioning speed actor (PT-V) can determine the speed of a moving object that is a personal device actor (P-DEV) or an IoT device actor (IoT-DEV). Sensed speed information of a usable moving object can be received, and the speed of the moving object can be calculated using the registration information of the moving object.

Based on the information received from the IoT domain (IoTD), the positioning state actor (PT-S) can calculate information such as whether a moving person or object moves horizontally or vertically, is at an intersection, is parked or stopped, etc. You can. In other words, by comprehensively judging the routing information stored through the cloud server (CS) or mobile map and available sensor information, the location information of the moving vehicle's road crossing, end, intersection, and overpass, and whether it is parked or stopped, etc. You can judge.

The Positioning Accuracy Actor (PT-A) can make accurate decisions by matching navigation or routing information and analyzing actual route data. In other words, the accuracy of the moving object can be determined by comparing and analyzing routing information stored through the cloud server (CS) or the map of the moving object.

To calculate the position of a user or vehicle, the personal device actor (P-DEV) can request positioning from the positioning fusion actor (PT-F), and the positioning fusion actor (PT-F) can send a request to another domain or actor. You can request or reply to the necessary information, and when collecting multiple pieces of information, sensor fusion can occur between the pieces of information.

In an embodiment where the user is located indoors, when the personal device actor (P-DEV) requests positioning from the positioning fusion actor (PT-F), the positioning fusion actor (PT-F) provides information about the user to the personal information actor (P-I). You can request information such as gender, age, and disability, and you can request information about the user's status, such as whether the user is currently running, walking, or riding a means of transportation, from the personal state actor (P-S).

Additionally, the positioning fusion actor (PT-F) can request location information of the infrastructure facility where the user is located from the personal location actor (P-L). When a user enters an infrastructure facility while boarding a means of transportation, infrastructure entry information may be generated and transmitted or stored in the infrastructure communication actor (I-C) or cloud server (CS).

When the location of the infrastructure facility where the user is located is specified by the personal location actor (P-L), the positioning fusion actor (PT-F) can request the personal elevation actor (P-F) for the number of floors or altitude information within the specified infrastructure. The personal altitude actor (P-F) can request information such as the access point (AP) installed in the infrastructure facility from the infrastructure communication actor (I-C) to determine the user's altitude location, and the infrastructure communication actor (I-C) returns the stored AP information. Alternatively, if the AP information is stored in the cloud server (CS), the request and reply can be sent back to the personal altitude actor (P-F).

Therefore, the positioning fusion actor (PT-F) can calculate the user's position by collecting information between different domains through sensor fusion.

In an embodiment where the user is located outdoors, the personal device actor (P-DEV) may request positioning from the positioning fusion actor (PT-F), and the positioning fusion actor (PT-F) may use another domain to collect the necessary information. Alternatively, you can request information from the actor or receive a response with corresponding information.

When the Positioning Fusion Actor (PT-F) requests the user's status information from the Personal State Actor (P-S), the Personal State Actor (P-S) uses the IoT Communication Actor (IoT-C) to check whether the user is on board the vehicle. ), you can request boarding confirmation.

When a user is on a vehicle, the Positioning Fusion Actor (PT-F) can request the location of the vehicle from the IoT Location Actor (IoT-L) instead of the Personal Location Actor (P-L), and the IOT Location Actor (IoT-L) can request the location of the vehicle. L) can send a location confirmation request to the cloud server (CS), and the cloud server (CS) can transmit location information to the positioning fusion actor (PT-F) or personal device actor (P-DEV).

Additionally, when it is confirmed that the user is on board the vehicle, the IoT communication unit (IoT-C) or the positioning fusion actor (PT-F) determines the positioning velocity actor (PT-V), positioning state actor (PT-S), and positioning accuracy. You can request or receive information about the speed, status, and accuracy of the transport from the actor (PT-A).

After confirming that the user is on board, the location of the means of transportation can be determined. After determining the location, based on the speed at the specified location, even if the means of transportation enters an area where signals such as a tunnel are not detected, the terrain and the means of transportation can be determined. The expected route can be calculated through information such as location and speed, and the final position of the means of transportation can be calculated by reflecting the accuracy of the expected route.

With reference to FIGS. 9 to 12, the indoor/outdoor continuous positioning switching method of the present invention will be described.

A cloud server (CS) and multiple domains may be provided for the indoor/outdoor continuous positioning switching method of the present invention.

The plurality of domains may be a personal domain (PD), an IoT domain (IOTD), a sensor domain (SD), an infrastructure domain (ID), and a positioning domain (PTD). Each domain can be classified according to the performer and role, and elements belonging to each domain can be referred to as actors.

The personal domain (PD) may include a personal device actor (P-DEV), a personal information actor (P-I), a personal state actor (P-S), a personal location actor (P-L), and a personal altitude actor (P-F).

The IoT domain (IOTD) consists of IoT device actors (IoT-DEV), IoT information actors (IoT-I), IoT communication actors (IoT-C), IoT state actors (IoT-S), and IoT location actors (IoT-L). may include.

The positioning domain (PTD) may include a positioning altitude actor (PT-F), a positioning velocity actor (PT-V), a positioning state actor (PT-S), and a positioning accuracy actor (PT-A).

The infrastructure domain (ID) may include an infrastructure communication actor (I-C), an infrastructure location actor (I-L), and an infrastructure altitude actor (I-F).

Users can receive PVT services from personal device actors (P-DEV). The PVT service may be a Positioning/Velocity/timing service. PVT services may include information about positioning or intersections, accuracy, etc.

We examine the process by which a personal device actor (P-DEV) obtains a PVT service, focusing on the personal domain (PD).

The personal device actor (P-DEV) can check registration information with the personal information actor (P-I) and then receive a reply with information about age, presence of disability, etc. In this way, personal registration information can be received after the Personal Device Actor (P-DEV) requests the Personal Information Actor (P-I) to inquire, but the Positioning Fusion Actor (PT-F) requests the Personal Information Actor (P-I) to inquire the information. Afterwards, you can receive a reply. This may be the case when requesting a positioning, the Positioning Fusion Actor (PT-F) collects all the information necessary for calculating the positioning and then calculates the final positioning data.

Therefore, when a user simply queries his/her registration information and receives a reply, the personal device actor (P-DEV) sends a reply to the personal information actor (P-I), and then the personal information actor (P-I) sends a reply to the personal device actor (P-I). DEV), but in order to calculate the final position according to the user's PVT service request, PVT information may be requested from the personal device actor (P-DEV) to the positioning fusion actor (PT-F). After a request to inquire about personal information is made from the Positioning Fusion Actor (PT-F) to the Personal Information Actor (P-I), the personal information to be used for positioning calculation is transferred from the Personal Information Actor (P-I) to the Positioning Fusion Actor (PT-I). F) can be transmitted.

At the user's request, the personal device actor (P-DEV) can request information data about PVT, intersection, accuracy, etc. from the positioning fusion actor (PT-F), and the positioning fusion actor (PT-F) uses various senses. The information data received from can be fused and the resulting data can be returned to the personal device actor (P-DEV).

The information data received by the Positioning Fusion Actor (PT-F) may include information obtained from the Personal State Actor (P-S). In other words, the personal device actor (P-DEV) can request the personal state actor (P-S) to detect an individual's motion or boarding a vehicle, and the personal state actor (P-S) is mounted on the personal device actor (P-DEV). Data from the sensor can be received, and the personal state actor (P-S) can transmit the received sensor data to the positioning fusion actor (PT-F).

The information data received by the Positioning Fusion Actor (PT-F) may include information obtained from the Personal Location Actor (P-L). In other words, the Positioning Fusion Actor (PT-F) can request the Personal Location Actor (P-L) to classify locations such as the city center, rural areas, and tunnels, and the Personal Location Actor (P-L) can request a map within the Personal Device Actor (P-DEV). Alternatively, the results from the map information of the Cloud server can be transmitted to the Positioning Fusion Actor (PT-F).

The information data received by the Positioning Fusion Actor (PT-F) may include information obtained from the Personal Altitude Actor (P-F). In other words, the personal device actor (P-DEV) can request information about the number of floors or altitude in the building from the personal altitude actor (P-F), and the infrastructure communication actor (I-C) can be requested through the network installed in the personal device actor (P-DEV). ), and this searched information can be transmitted to the Positioning Fusion Actor (PT-F).

The information data received by the Positioning Fusion Actor (PT-F) may include information obtained from the Positioning Velocity Actor (PT-V). In other words, the Positioning Fusion Actor (PT-F) can request speed information from the Positioning Velocity Actor (PT-V), and the Positioning Velocity Actor (PT-V) can request speed information through the sensor in the Personal Device Actor (P-DEV). can be replied to the Positioning Fusion Actor (PT-F).

The information data received by the Positioning Fusion Actor (PT-F) may include information obtained from the Positioning State Actor (PT-S). In other words, the positioning fusion actor (PT-F) can request information such as crossing, longitudinal, intersection, overpass, and stop from the positioning state actor (PT-S), and the positioning state actor (PT-S) can request the corresponding state. Information can be returned to the Positioning Fusion Actor (PT-F).

The information data received by the Positioning Fusion Actor (PT-F) may include information obtained from the Positioning Accuracy Actor (PT-A). In other words, the positioning fusion actor (PT-F) can request routing accuracy or path accuracy from the positioning accuracy actor (PT-A), and the positioning accuracy actor (PT-A) can request map data from the cloud server (CS). Alternatively, accuracy information through analysis of the terminal's map data can be transmitted to the Positioning Fusion Actor (PT-F).

Each of the above processes can be explained in chronological order with a sequence diagram, focusing on the personal domain (PD).

In order for a personal device actor (P-DEV) or positioning fusion actor (PT-F) to query personal information in a personal information actor (P-I), a step of registering personal information may be necessary.

In the step of registering personal information, the user can request personal information registration from the personal device actor (P-DEV), and the personal device actor (P-DEV) can request personal information registration from the personal information actor (P-I). A personal information actor (P-I) can register the entered personal registration information.

Registered personal information can be transmitted from the personal information actor (P-I) to the cloud server (CS), and after the corresponding personal information is also registered in the cloud server (CS), the fact of registration can be notified to the personal device. Through this, users can confirm that their personal registration information has been registered.

Once the user's personal information is registered with the Personal Information Actor (P-I) or Cloud Server (CS), the subject requesting personal information may request to view the personal information with the Personal Information Actor (P-I) or Cloud Server (CS). The retrieved personal information can be used to calculate the location after being transmitted to the information requesting entity. If the Positioning Fusion Actor (PT-F) must respond to a positioning calculation request, the information required for positioning calculation can be transmitted to the Positioning Fusion Actor (PT-F), and the final positioning is calculated based on this various information. can do. Therefore, in this case, the personal device actor (P-DEV) requests positioning calculation from the positioning fusion actor (PT-F), and the positioning fusion actor (PT-F) queries personal information with the personal information actor (P-I). Personal information registered in the Personal Information Actor (P-I) is transmitted to the Positioning Fusion Actor (PT-F), and the Positioning Fusion Actor (PT-F) uses the transmitted personal information to calculate the final positioning and then sends it to the Personal Device Actor. The positioning results can be transmitted to (P-DEV).

Looking at the case of detecting the user's motion state, the personal device actor (P-DEV) can request motion detection to the personal state actor (P-S), and the personal state actor (P-S) can make a motion detection request to the personal device actor (P-DEV). Sensor data can be requested, and the personal device actor (P-DEV) that receives the request signal can obtain sensor data and transmit the sensor data back to the personal state actor (P-S).

The personal state actor (P-S) can obtain operation status information data using the received sensor data, and the personal state actor (P-S) can determine whether to operate and transmit the result to the positioning fusion actor (PT-F). there is. If routing or path tracking is required after motion detection, the Positioning Fusion Actor (PT-F) can send a signal to the Personal Device Actor (P-DEV) to start monitoring for routing.

When detecting boarding for an IoT device actor (IoT-DEV) such as user mobility or transportation, the IoT device actor (IoT-DEV) requests pairing to the personal device actor (P-DEV). , the personal device actor (P-DEV) returns a pairing result indicating the user's boarding detection to the IoT device actor (IoT-DEV), and the IoT device actor (IoT-DEV) pairs with the personal device actor (P-DEV). You can move.

The personal device actor (P-DEV) can transmit connection information to the personal state actor (P-S), and the personal state actor (P-S) detects the user's boarding based on the transmitted connection information and positions this boarding detection result. It can be transmitted to Fusion Actor (PT-F). The positioning fusion actor (PT-F) can request routing information of the IoT domain (IOTD) for routing of the personal domain (PD) or personal device actor (P-DEV) to the IoT device actor (IoT-DEV).

For user positioning, when calculating information about the city center, region, tunnel, number of floors in a building, altitude, etc., the Positioning Fusion Actor (PT-F) can request information to determine the current location to the Personal Location Actor (P-L). there is.

If the user is outdoors, the location can be confirmed using map information from a personal device actor (P-DEV) or cloud server (CS). If the user is indoors, infrastructure connection information and connection access point (AP) registration information can be returned through the infrastructure communication actor (I-C).

When a user enters indoors from outdoors and simultaneously receives access point information and GPS information such as GNSS from the infrastructure communication unit, the final location is determined after checking the routing path, and the personal location actor (P-L) determines the final location value. You can receive a reply. The personal location actor (P-L) can determine whether the user's location is indoors or outdoors based on the final position value, and transmit this information to the positioning fusion actor (PT-F).

If the location information received by the Positioning Fusion Actor (PT-F) is outdoors, the Positioning Fusion Actor (PT-F) displays the positioning state actor (PT-S) as a crossing, longitudinal, intersection, overpass, or stop state. You can request information.

The positioning state actor (PT-S) can request a reply for routing information from the cloud server (CS) or personal device actor (P-DEV), and the cloud server (CS) or personal device actor (P-DEV) that has received the reply request sends a reply to the positioning state actor (PT-S) for routing information, and the positioning state actor (PT-S) uses the received result to determine the positioning state and sends the positioning state information to the positioning fusion actor (PT-S). F) can be transmitted.

The positioning fusion actor (PT-F) can determine the outdoor location using information received from the personal location actor (P-L) and the positioning state actor (PT-S). In this case, the positioning fusion actor (PT-F) can perform sensor fusion of sensing information from two different domains.

In addition, the positioning state actor (PT-S) can perform sensor fusion using the data of the personal state actor (P-S) and the routing data of the cloud server (CS) or personal device actor (P-DEV), and the sensor fusion The results can be sent to the Positioning Fusion Actor (PT-F).

That is, sensor fusion can be performed to calculate the final position in the positioning fusion actor (PT-F), but sensor fusion can also occur in each actor or unit for calculating the final position. Therefore, since sensor fusion of information from different domains may occur in the positioning fusion actor (PT-F) or in a specific domain actor or part before that before the final position calculation of the positioning fusion actor (PT-F), the positioning fusion actor (PT-F) It may be the principle way for sensor fusion to occur in PT-F).

If the location information received by the Positioning Fusion Actor (PT-F) is indoors, altitude information such as infrastructure or the number of floors in a building can be requested from the Personal Altitude Actor (P-F), and the Personal Altitude Actor (P-F) can be sent to the cloud server. (CS) or infrastructure communication actor (I-C) can be requested to confirm registration information for the access point (AP).

The cloud server (CS) or infrastructure communication actor (I-C) can reply access registration information to the personal altitude actor (P-F), and the personal altitude actor (P-F) can determine the floor number or altitude from the received floor number or altitude information. there is.

The personal altitude actor (P-F) can transmit the determined floor number or altitude information to the positioning fusion actor (PT-F), and the positioning fusion actor (PT-F) can transmit the data received from the personal location actor (P-L) and the personal altitude actor. The indoor location can be determined using the data transmitted from (P-F). At this time, sensor fusion of actors from two different domains can occur.

The Positioning Fusion Actor (PT-F) can determine speed information and accuracy information. Such speed information determination or accuracy determination may be performed after the location information determination.

The Positioning Fusion Actor (PT-F) can request speed information from the Positioning Velocity Actor (PT-V), and the Positioning Velocity Actor (PT-V) can sense the Personal Device Actor (P-DEV) or Cloud Server (CS). You can request speed information.

Sensed speed information can be received back from a personal device actor (P-DEV) or a cloud server (CS), and the positioning speed actor (PT-V) converts the speed value from the received data to the positioning fusion actor (PT-F). Can be transmitted.

The Positioning Fusion Actor (PT-F) can determine speed information using data received from the Positioning Velocity Actor (PT-V).

The Positioning Fusion Actor (PT-F) can make an accuracy request to the Positioning Accuracy Actor (PT-A), which then routes to the Cloud Server (CS) or Personal Device Actor (P-DEV). You can request information.

Routing path information can be returned from the map information of the cloud server (CS) or personal device actor (P-DEV). The Positioning Accuracy Actor (PT-A) can determine the accuracy value by verifying the received routing information, and transmit this accuracy value to the Positioning Fusion Actor (PT-F).

Positioning Fusion Actor (PT-F) can calculate the PVT service value, that is, the final positioning data, from various data such as transmitted location information, speed information, and accuracy information, and sends this final positioning data to the Personal Device Actor (P-F). DEV). The personal device actor (P-DEV) can present the received final positioning data to the user through a screen display such as a panel.

Looking at information exchange between different domains focusing on the IoT domain (IOTD), IoT device actors (IoT-DEV) can exchange information with the outside world through IoT communication actors (IoT-C). In other words, the IoT device actor (IoT-DEV) can communicate with the cloud server (CS), personal domain (PD), or infrastructure domain (ID) through the IoT communication actor (IoT-C). In other words, when the IoT location actor (IoT-L), positioning status actor (PT-S), etc. receives necessary information from the outside, it is sent to the outside world through the IoT communication actor (IoT-C) or IoT device actor (IoT-DEV). You can communicate with.

IoT device actors (IoT-DEV) and IoT communication actors (IoT-C) can be combined and performed in one place or individually in different places. For example, an autonomous car may be a model that combines IoT device actors (IoT-DEV) and IoT communication actors (IoT-C).

Overall, the IoT device actor (IoT-DEV) can receive the final positioning data resulting from the PVT service from the positioning fusion actor (PT-F), and for this purpose, various information can be transmitted to the positioning fusion actor (PT-F). The positioning fusion actor (PT-F) can calculate PVT data or final positioning data using various received sensing information or sensor fusion information.

The IoT device actor (IoT-DEV) can query registration information in the IoT information actor (IoT-I), and the IoT information actor (IoT-I) provides information such as the type of vehicle and the type of oil used in the vehicle. You can reply with IoT device actor (IoT-DEV). The IoT device actor (IoT-DEV) can request the IoT state actor (IoT-S) to detect whether the user is riding or not, indicating whether the user is driving or walking on the road, and whether the user is driving, stopping or parking, etc. The state actor (IoT-S) can request sensing data from the sensor domain (SD).

In other words, whether or not to ride can be determined through pairing from the sensor of the personal device actor (P-DEV), and whether or not to drive can be determined from the sensor data of the IoT device actor (IoT-DEV). The IoT state actor (IoT-S) can determine whether a vehicle is boarded or driving from the received data and transmits it to the positioning fusion actor (PT-F).

The Positioning Fusion Actor (PT-F) can request results from the IoT Location Actor (IoT-L) for the number of floors or existence of a tunnel, etc., and the IoT Location Actor (IoT-L) can request results from the IoT Location Actor (IoT-DEV). Location results such as floor numbers or tunnels can be transmitted to the Positioning Fusion Actor (PT-F) through the map or cloud server.

The Positioning Fusion Actor (PT-F) can request speed information from the Positioning Velocity Actor (PT-V), and the Positioning Velocity Actor (PT-V) can request velocity information through a sensor mounted on the IoT Device Actor (IoT-DEV). can be received, and the positioning velocity actor (PT-V) can transmit the velocity data to the positioning fusion actor (PT-F).

The positioning fusion actor (PT-F) can request information such as crossing, longitudinal, intersection, parking, stopping, etc. from the positioning state actor (PT-S), and the floor state handler can return the corresponding state data. The Positioning Fusion Actor (PT-F) can make a routing accuracy request to the Positioning Accuracy Actor (PT-A), and the Positioning Accuracy Actor (PT-A) can be sent to the Cloud Server (CS) or Personal Device Actor (P-DEV). Accuracy through map data analysis can be returned to the Positioning Fusion Actor (PT-F).

Regarding the registration information of the means of transportation, there may be a step of registering the registration information of the means of transportation and a step of inquiry.

In the IoT information actor (IoT-I) registration step, the user can request to register transportation information to the IoT information actor (IoT-I), and the transportation information includes the type of vehicle, such as whether it is a regular car or an autonomous vehicle. , vehicle model, type of fuel, etc.

The IoT information actor (IoT-I) can transmit transportation information to the cloud server (CS), and the cloud server (CS) registers the transportation information and then sends the transportation information registration results to the IoT information actor (IoT-I). You can reply with I), and the user can confirm that they have registered through IoT Information Actor (IoT-I).

In the transportation method information inquiry stage, the user simply requests a query for registered information in the transportation method information register and receives a reply, or when the information required to calculate the final position by the PVT service is needed, the Positioning Fusion Actor (PT-F) You can request registration information from the Sudan Information Register.

The IoT information actor (IoT-I) can immediately transmit the registration information according to the inquiry request to the positioning fusion actor (PT-F), and if necessary, the IoT information actor (IoT-I) sends a confirmation request to the cloud server (CS). can do. When the IoT information actor (IoT-I) makes a query request to the cloud server, the positioning fusion actor (PT-F), IoT information actor (IoT-I), cloud server (CS), and positioning fusion actor (PT-F) ), the data flow of request and reply can occur sequentially.

When detecting whether a means of transportation is running, stopped, or parked, the IoT device actor (IoT-DEV) can request the IoT state actor (IoT-S) to detect the state of the transportation device. ) can initiate monitoring of the sensor mounted on the IoT device actor (IoT-DEV), and the IoT state actor (IoT-S) can receive data by the sensor, and use this to create the IoT state actor (IoT-S). S) can detect or determine the status of the means of transportation, such as running, stopping, or parking.

The IoT state actor (IoT-S) can transmit the vehicle status value to the positioning fusion actor (PT-F), and the positioning fusion actor (PT-F) requests the cloud server (CS) to query the vehicle registration information. The positioning fusion actor (PT-F) can use the transportation vehicle registration information transmitted from the cloud server (CS) and the state value received from the IoT state actor (IoT-S) to calculate the transportation vehicle status determination. .

Looking at the process of determining location information such as the city center, rural area, tunnel, number of floors in a building, or altitude, focusing on the IoT domain (IOTD), the positioning fusion actor (PT-F) uses the positioning information for determining the current location as an IoT location actor. (IoT-L), and the IoT location actor (IoT-L) can request the IoT device actor (IoT-DEV) to confirm location information through a map or infrastructure access information.

In addition, the IoT device actor (IoT-DEV) can request location information through a map or infrastructure access information from the IoT communication actor (IoT-C), and the IoT communication actor (IoT-C) can request location information through a map or infrastructure access information. You can request location information from the infrastructure domain (ID) or cloud server (CS). The infrastructure domain (ID) or cloud server (CS) sends the location value through the connection access registration information or the cloud server (CS) map (which may include a map of the personal device actor (P-DEV)) to the IoT communication actor (IoT). -C), which in turn can be sent to the IoT device actor (IoT-DEV) and then to the IoT location actor (IoT-L).

When access point information and GNSS information such as GPS are received simultaneously, the final location can be determined after checking the routing path. The IoT location actor (IoT-L) can use the received information to determine the location of the city center, rural area, etc., and determine whether it is indoors or outdoors. This indoor or outdoor classification information can be transmitted to the Positioning Fusion Actor (PT-F).

If the information received by the Positioning Fusion Actor (PT-F) is outdoors, the Positioning Fusion Actor (PT-F) informs the Positioning State Actor (PT-S) of transportation methods such as crossings, longitudinal lines, intersections, overpasses, and stops. Status information can be requested, and the positioning state actor (PT-S) can request routing data from the cloud server (CS) or IoT device actor (IoT-DEV) and then reply. When the positioning state actor (PT-S) requests and replies to the cloud server (CS) for routing data, the IoT device actor (IoT-DEV), IoT communication actor (IoT-C), cloud server (CS), IoT Data flow can occur in the following order: communication actor (IoT-C) and IoT device actor (IoT-DEV).

When the positioning state actor (PT-S) determines the positioning state using the routing path data of the cloud server (CS) or IoT device actor (IoT-DEV) and the location data received from the positioning fusion actor (PT-F), , the positioning state actor (PT-S) can perform sensor fusion between information from actors in different domains. As a result of the sensor fusion, an outdoor location can be determined, and this determined information can be transmitted to the positioning fusion actor (PT-F).

If the information received by the Positioning Fusion Actor (PT-F) is indoors, the Positioning Fusion Actor (PT-F) can request information about the number of floors or altitude in the building from the IoT Location Actor (IoT-L), and IoT The location actor (IoT-L) can request confirmation of access point registration information from the cloud server (CS).

The cloud server (CS) can reply the access point registration information to the IoT location actor (IoT-L), and the IoT location actor (IoT-L) can use the returned information to determine the floor number or altitude and IoT location The actor (IoT-L) can transmit the judgment information to the positioning fusion actor (PT-F), and the positioning fusion actor (PT-F) can determine the indoor location using the received judgment information. The Positioning Fusion Actor (PT-F) can determine indoor location through sensor fusion between the location information received from the IoT Location Actor (IoT-L) and altitude information such as floor number.

Looking at the PVT service decision process in the IoT domain (IOTD), after the indoor location of the means of transportation is determined by the positioning fusion actor (PT-F), the speed information or accuracy of the means of transportation may be determined.

The Positioning Fusion Actor (PT-F) can request speed information from the Positioning Velocity Actor (PT-V), and the Positioning Velocity Actor (PT-V) can request sensed velocity data from the IoT Device Actor (IoT-DEV). The IoT device actor (IoT-DEV) can sense speed information using the sensor mounted on the vehicle, and the sensed speed data is transmitted from the IoT device actor (IoT-DEV) to the positioning speed actor (PT-V). can be sent to The positioning speed actor (PT-V) can calculate a speed value from the received speed data, and the positioning fusion actor (PT-F), which has received this speed value, can perform sensor fusion of the position information and speed information.

The Positioning Fusion Actor (PT-F) can make an accuracy request to the Positioning Accuracy Actor (PT-A).

If routing information is stored in the IoT device actor (IoT-DEV), the positioning accuracy actor (PT-A) can request routing information from the IoT device actor (IoT-DEV), and the IoT device actor (IoT- Routing information may be transmitted from the DEV) to the Positioning Accuracy Actor (PT-A).

When routing information is stored in the cloud server (CS), the signal requesting routing information is the Positioning Accuracy Actor (PT-A), IoT Device Actor (IoT-DEV), IoT Communication Actor (IoT-C), and Cloud Server ( CS), IoT communication actor (IoT-C), IoT device actor (IoT-DEV), and positioning accuracy actor (PT-A) may be transmitted in that order.

In either case, the positioning accuracy actor (PT-A) can determine the accuracy value by verifying the transmitted routing information, and transmit the verified accuracy value to the positioning fusion actor (PT-F).

The Positioning Fusion Actor (PT-F) uses the information received from the IoT Location Actor (IoT-L), the Positioning Velocity Actor (PT-V), and the Positioning Accuracy Actor (PT-A) to generate PVT service data, i.e. final transport. The location of the means can be determined.

Looking at the information exchange relationship between actors or parts of each domain centered on the sensor domain (SD), the personal device actor (P-DEV) can request data from the service sensor actor (S-S) from the infrastructure communication actor (I-C), and the infrastructure communication actor (I-C) can request data from the service sensor actor (S-S). The communication actor (I-C) can reply sensor data in response to the request, and the personal device actor (P-DEV) can receive unique AP (access point) information such as MAC address from the infrastructure communication actor (I-C). , AP registration location information can be requested to the cloud server (CS), and the cloud server (CS) can reply the registration information to the personal device actor (P-DEV).

The database of the cloud server (CS) contains AP registration location information, information by service sensor actors (S-S) such as A-GPS or D-GPS, and device sensor actors (S-DEV) such as UWB, Wi-Fi, Bluetooth beacon, and RFID. ) information may be included.

The IoT device actor (IoT-DEV) can request sensor data as a service from the infrastructure communication actor (I-C), and the infrastructure communication actor (I-C) can reply the corresponding sensor data to the IoT device actor (IoT-DEV). , After receiving the unique AP registration information from the IoT communication actor (IoT-C), the IoT device actor (IoT-DEV) can request AP registration location information to the cloud server (CS), and the cloud server (CS) Registration information can be returned to the IoT device actor (IoT-DEV).

The IoT communication actor (IoT-C) can request AP-specific registration information and triangulation calculations to the cloud server (CS), and the cloud server (CS) can respond with AP registration location information and triangulation calculation values. You can.

The location information of the moving object can be corrected using the registration information of the infrastructure communication actor (I-C). The moving object may mean a user's terminal or an IoT terminal of a means of transportation, and may be the location of a personal device actor (P-DEV) or the location of an IoT device actor (IoT-DEV).

When correcting the position of a personal device actor (P-DEV) located outdoors, the cloud server (CS) can transmit the changed GNSS data to the personal device actor (P-DEV) or IoT device actor (IoT-DEV). , This can be transmitted again to the Positioning Fusion Actor (PT-F), and the Positioning Fusion Actor (PT-F) can correct the position of the Personal Device Actor (P-DEV) using the changed GNSS data.

When correcting the location of an IoT device actor (IoT-DEV) located outdoors, the changed GNSS information can be transmitted from the cloud server (CS) to the IoT communication actor (IoT-C), which in turn is transmitted to the IoT device actor (IoT-C). -DEV) or personal device actor (P-DEV), which can then be transmitted to the positioning fusion actor (PT-F), which uses the changed GNSS data to control IoT The position of the device actor (IoT-DEV) can be corrected.

When correcting the position of an indoor personal device actor (P-DEV), the IoT device actor (IoT-DEV) or personal device actor (P-DEV) can acquire surrounding AP information from the IoT communication actor (IoT-C). and the acquired surrounding AP information can be transmitted to the positioning fusion actor (PT-F). The Positioning Fusion Actor (PT-F) can again request nearby AP registration information from the IoT Device Actor (IoT-DEV) or the Personal Device Actor (P-DEV), and the IoT Device Actor (IoT-DEV) or Personal Device Actor ( P-DEV) can request nearby AP registration information from the cloud server (CS), and the surrounding AP registration information is sent from the cloud server (CS) through the IoT device actor (IoT-DEV) or personal device actor (P-DEV). Can be transmitted to Positioning Fusion Actor (PT-F). Accordingly, the positioning fusion actor (PT-F) can correct the position of the indoor personal device actor (P-DEV) using the transmitted nearby AP registration information.

Compared to the case of position correction of the indoor personal device actor (P-DEV), in the case of position correction of the indoor IoT device actor (IoT-DEV), the IoT device actor (IoT-DEV) or personal device actor (P-DEV) A step in which data is transmitted and received between cloud servers (CS) through IoT communication actors (IoT-C) can be added.

The location information of the moving object can be utilized through the service sensor actor (S-S).

IoT device actor (IoT-DEV) (including the IoT communication actor (IoT-C) in cases where the IoT device actor (IoT-DEV) and IoT communication actor (IoT-C) are integrated, such as in an autonomous vehicle) or personal The device actor (P-DEV) may periodically or intermittently request service-type information disclosure or update from the cloud server (CS) or the service sensor actor (S-S) within the cloud server (CS). The service sensor actor (S-S) in the server (CS) can transmit service-type information initiated or updated information to the IoT device actor (IoT-DEV) or personal device actor (P-DEV) through methods such as downloading, and the IoT device Actors (IoT-DEV) or personal device actors (P-DEV) can store or utilize the transmitted information.

The Positioning Fusion Actor (PT-F) can request sensor-as-a-service information for determining the current location from the IoT Device Actor (IoT-DEV) or the Personal Device Actor (P-DEV), and the IoT Device Actor (IoT-DEV) or You can receive a reply with information stored or updated in the personal device actor (P-DEV), and use this to determine the current location of the personal device actor (P-DEV) or IoT device actor (IoT-DEV) and use it. .

Looking at the relationships between actors or parts of each domain, focusing on the infrastructure domain (ID), the infrastructure communication actor (I-C) registers or triangulates AP-specific information from the personal domain (PD) or IoT domain (IOTD). A calculation may be requested, and the cloud server (CS) may reply to the infrastructure communication actor (I-C) with registered AP location information and triangulation calculation values in response to the request. The cloud server (CS) may include AP registration location information, infrastructure location actor (I-L), and infrastructure elevation actor (I-F).

The location information of the moving object can be utilized through the registration information of the infrastructure communication actor (I-C).

In the case where an IoT device actor (IoT-DEV), such as an autonomous vehicle, and an IoT communication actor (IoT-C) are integrated, the IoT communication actor (IoT-C) or personal device actor (P-DEV) is connected to the cloud server (CS). ), the surrounding AP unique value or unique key can be obtained, and the IoT device actor (IoT-DEV) or personal device actor (P-DEV) can request surrounding AP registration information from the cloud server (CS), and the cloud server (CS) can transmit nearby AP registration information to the IoT device actor (IoT-DEV) or personal device actor (P-DEV) in response to this request. This surrounding AP registration information is transmitted from the IoT device actor (IoT-DEV) or personal device actor (P-DEV) to the positioning fusion actor (PT-F), so that the location of the moving object can be determined or utilized.

Looking at the personal domain (PD) with a focus on data transmission, personal information about the gender, age, presence of disability, or type of disability of the personal information actor (P-I) is provided according to the location calculation request of the personal device actor (P-DEV). can be transmitted to the Positioning Fusion Actor (PT-F).

Motion detection information, such as presence or absence of motion based on the IMU sensor, movement distance of the user, presence or absence of riding on the IoT device actor (IoT-DEV), or type of IoT device actor (IoT-DEV), is positioned in the personal state actor (P-S). Can be transmitted to Fusion Actor (PT-F).

Indoor location information, information on classification of outdoor locations such as downtown, rural areas, tunnels, and parking lots, information analyzing surrounding infrastructure conditions such as crossings, longitudinal lines, and intersections, or information on the user's location or altitude, which is altitude information such as the number of floors, It can be sent from the Personal Location Actor (P-L) or Personal Elevation Actor (P-F) to the Positioning Fusion Actor (PT-F).

Therefore, the Positioning Fusion Actor (PT-F) is a Personal Information Actor (P-I), Personal State Actor (P-S), Personal Location Actor (P-L), or Personal Altitude Actor (P-F) corresponding to each actor in the Personal Domain (PD). The positioning can be calculated using location information from at least one of the above.

Looking at the IoT domain (IOTD) with a focus on data transmission, in response to a positioning calculation request from an IoT device actor (IoT-DEV), the registration information of the means of transportation, such as vehicle type, model, type of fuel, and license plate, is stored in the IoT information actor. It can be transmitted from (IoT-I) to IoT device actor (IoT-DEV). IoT device actors (IoT-DEV) can be linked with personal device actors (P-DEV), and in order to exchange information with the outside world, data can be sent and received through IoT communication actors (IoT-C).

Motion detection information, such as the presence or absence of operations such as driving, stopping, and parking, the engine being turned on/off, the distance traveled by the means of transportation, whether a user is riding the means of transportation, the classification of the driver or passenger, or the number of passengers, is generated by the IoT state actor (IoT). -S) can be transmitted to the Positioning Fusion Actor (PT-F).

Indoor location information, information on classification of outdoor locations such as downtown, rural areas, tunnels, and parking lots, information analyzing surrounding infrastructure conditions such as crossings, longitudinal paths, and intersections, or IoT device actors (IoT-DEV), which are high-level information such as floor numbers. Location or altitude information can be transmitted from the Positioning Location Actor (PT-L) to the Positioning Fusion Actor (PT-F).

Therefore, the Positioning Fusion Actor (PT-F) is one of the IoT Information Actors (IoT-I), IoT State Actors (IoT-S), or IoT Location Actors (IoT-L) corresponding to each actor in the IoT domain (IOTD). Positioning can be calculated using location information of at least one means of transportation or IoT device actor (IoT-DEV).

With reference to FIGS. 13 to 16, data fusion of the present invention will be described.

The present invention may include at least one of P-ITS, V-ITS, and R-ITS.

Positioning can be provided to receive information detected from a sensor mounted on at least one of P-ITS, V-ITS, and R-ITS and convert it into a common data format, or to perform data fusion between different types of data. there is.

Here, ITS may mean Intelligent Transport Systems.

The domains described in FIGS. 1 to 12 may correspond to P-ITS, V-ITS, R-ITS, and positioning.

Hereinafter, to explain the data fusion of the present invention, sensors belonging to P-ITS, V-ITS, R-ITS, and positioning will be described. Each of these sensors may correspond at least in part to the actors described above. If they perform the same functions as the domain and actor described above, P-ITS, V-ITS, R-ITS, positioning, and sensors belonging to each can be used interchangeably with the domain and actor.

The invention may relate to intelligent transport systems and to seamless positioning for multimodal transport at ITS stations.

The present invention can perform data fusion between different types of data formats transmitted in different domains.

The present invention may be for seamless positioning of mobile users using multimodal transportation.

The present invention compensates for distortion of positioning data by specifying a data set collected from each sensor and derives PVT data to improve the accuracy of a smooth positioning service, as well as different types of data sets collected for each sensor. You can reduce the waste of system resources for converting.

In order to accurately and continuously calculate PVT, there are cases where sensors mounted in one domain are not enough, and it is necessary to integrate and fuse data from sensors belonging to each domain of P-ITS, V-ITS, and Infrastructure ITS.

In this way, fusion between sensor data may occur between sensors belonging to the same domain, between sensors belonging to different domains, or in a combination thereof, depending on the situation in which the P-ITS is located.

Therefore, utilizing various sensor technologies such as GNSS, Radar, LiDar, Camera, WiFi, Bluetooth, Odometer, etc. with different sensing functions may be essential to compensate for distortion of positioning data and improve accuracy.

In the multi-complex space of the future, moving away from the current limited space, it may be necessary to integrate using sensors from surrounding devices that can be used even if you do not own them.

The present invention seeks to minimize sensor fusion development efforts and maximize the reusability of various development and verification efforts in different environments by considering the properties and characteristics of each sensor possessed by each available ITS Station.

The present invention defines a common dataSet for accurate PVT calculation at the application level between other ITS stations such as P-ITS, V-ITS, Infrastructure ITS, etc., and can distinguish between mandatory data and usable optional data.

All techniques for sensor data fusion between three domains: Nomadic device (e.g. P-ITS-S), mobility (e.g. V-ITS-S) and infrastructure (e.g. R-ITS-S) All technical requirements may be included. Available sensors can be classified according to requirement level (RL-Requirement Level) depending on the situation.

Requirement level (RL) can be categorized as mandatory or optional-if available. The requirement level may have a two-level hierarchy structure of a domain requirement level (DRL) and a sensor requirement level (SRL) belonging to each domain.

The target of positioning calculation of the present invention may be P-ITS.

In other words, the present invention seeks to calculate the accurate location of a person holding a nomadic device such as a mobile phone. When a situation occurs in which the location calculation is not sufficient only with the sensor mounted on the mobile phone, information from surrounding domains or sensors occurs. By combining the results, it may be an attempt to quickly and accurately determine each individual's positioning calculation.

Depending on the situation P-ITS is in, P-ITS can exchange information with V-ITS and R-ITS. To this end, not only the P-ITS sensor, but also the V-ITS sensor and R-ITS sensor can be used for sensor data fusion as needed.

Calculating P-ITS's seamless PVT requires integrating data from sensors belonging to other domains, and for this, a comprehensive understanding of the situation according to the location of the P-ITS is required. In other words, the P-ITS may be driving on a V-ITS, the P-ITS may be located inside an R-ITS where satellite communication is not available, and the V-ITS on which the P-ITS is boarded may not have satellite communication. Various situations may occur, such as passing through an area where satellite signals are weak, and the sensors available for calculating positioning may vary depending on each situation the P-ITS faces.

If the sensing data used to calculate positioning comes from different sensors and has different fusion data formats, it may be difficult to synchronize the real-time and immediate data of each piece of information. Therefore, in this document, for fusion of different sensor data, it may be more efficient to exchange data between domains in a common message format.

Depending on the situation of the P-ITS, the sensors available for PVT calculation are determined, and the sensing data from each sensor is first converted to a common dataset and then fused, so fast and highly reliable sensor data fusion can be achieved. there is.

The standard for sensor data fusion may be the strength of the sensor signal (attenuation information).

If the GNSS signal strength received by P-ITS weakens below the preset standard value, P-ITS can request sensor fusion to another domain (V-ITS or R-ITS), and P-ITS can use available sensors. It is possible to detect and select and receive sensing data. Detection and selection of available sensors and reception of sensing data are determined by the situation in which the P-ITS is located.

A reference sensor, which serves as a standard for signal strength (reference signal) for sensor fusion, can be selected depending on the situation required for calculating P-ITS positioning.

Figure 13 shows a case where the reference sensor is selected as a Satellite mounted on P-ITS in an open sky with good GPS signal reception. In this case, P-ITS may be mandatory at the Domain Requirement Level (DRL), and Satellite may be mandatory at the Sensor Requirement Level (SRL). To improve the accuracy and reliability of positioning calculations, different sensors from the same or different domains can be used for sensor fusion.

In the drawing of the present invention, it can be indicated whether the domain requirement level (DRL) is mandatory or optional, and when the domain becomes mandatory, the location is determined among the sensors belonging to that domain depending on the situation. Sensors required for calculation may be selected. If a domain is optional, sensors belonging to that domain are also optional and may be waiting for a sensor data fusion request for positioning calculation. The indication of optional in the Sensor Requirement Level (SRL) may be omitted.

The present invention can specify sensor data fusion applicable to the use case of indoor and outdoor seamless positioning solutions for mobile users (multi-modal transport) at ITS stations. This document covers all technical requirements for data fusion between three areas: nomadic devices (e.g. P-ITS-S), mobility (e.g. V-ITS-S) and infrastructure (e.g. R-ITS-S). This is included. Data exchange between domains can be based on common messages and data formats.

Requirement level can mean whether each sensor or each domain is available as mandatory or optional depending on the situation.

Mandatory can mean always required.

Optional can mean permitted but not always required.

Domain Requirement Level may refer to the requirement level at domain level.

Sensor Requirement Level may mean the requirement level at sensor level.

Figure 14 shows that the P-ITS carried by a passenger passes from outdoors, where GNSS reception is good, to indoors, where GNSS signals are weak, and through the Underground, where GNSS signals are hardly received. It may represent.

Referring to FIG. 14, the present invention will describe indoor and outdoor seamless positioning for a person with a nomadic device in an urban area.

A nomadic device is a terminal for vehicle traffic information, but it can also refer to an IT convergence device that can be used as a personal portable multimedia terminal outside of the vehicle.

Assume that a passenger walks from point A to point B in a complex place such as Seoul Station.

Vehicles may take a long time to bypass the downtown area where the complex place is located. However, a passenger can traverse a complex place using a seamless positioning system, shortening the travel distance and travel time.

The short-range communication sensor (SRS) and long-range communication sensor (LRS) of R-ITS can be used for sensor data fusion to calculate positioning of P-ITS.

Outdoor (A), GNSS reception is good, so P-ITS and satellite unit (Satellite) may be mandatory. Indoors and underground (B), GNSS signals become weak and R-ITS (infrastructure-building) may be mandatory, and SRS (near field communication sensor) of P-ITS and SRS of R-ITS can interact with each other, and LRS (long-range communication sensors) can be used to transmit and receive data between domains.

FIG. 15 may relate to PVT calculation using common dataset conversion and sensor data fusion in the underground, where GNSS signal reception is weakened, when the reference signal is GNSS.

14 and 15 can be expanded to include a case where a person holding a P-ITS boards a V-ITS, and a person located in an R-ITS rides a parked V-ITS.

AT can mean Autonomous Tech and can include Lidar, Radar, Ultrasonic, Camera, etc.

LRS can mean long range sensors and can include LTE, 5G, etc.

RU may mean Roadside unit, and may be installed in outdoor areas including the roadside where V-ITS is driven, and includes detection sensors including CCTV, object recognition sensors, data transmission and reception sensors, etc. can do.

Satellite may refer to an artificial satellite or a sensor using an artificial satellite, and may include GPS, Assisted GPS (A-GPS), Differential GPS (D-GPS), etc.

SRS may mean short range sensors and may include Bluetooth (BT), NFC, Wi-fi, etc.

A sensor data format may be a sensing data structure acquired by sensors belonging to each domain and exchanged between domains.

A common dataset may be a common sensor data format structure used when sensor data is fused in the positioning domain.

Sensor data fusion may be where the sensor data formats of sensors belonging to different domains or the same domain are converted to a common message format and then synchronized and integrated for positioning calculation.

FIG. 16 is about sensor signal strength, and may be about sensor signal strength classification and criterion.

A reference signal that serves as a standard for accurate positioning calculation may be set according to the signal reception situation of the domain that is the target of positioning calculation. For example, if P-ITS is the target for positioning calculation, a GNSS signal can be the reference signal.

When a reference signal is selected, a criterion that discerns the strength of the reference signal can be set. When the reference signal becomes less than criterion, sensors in other surrounding domains can be searched and used for sensor fusion.

The criterion that classifies signal strength into strong and weak can be set to a specific value or a specific range (criterion 1 to criterion 2). The specific value or specific range of the criterion may be set differently for each sensor used in sensor fusion. The sensor signal strength within a specific range can be preset as either strong or weak, or can be determined as strong or weak depending on the type and strength of other sensors to be sensor fused.

The key elements (Key Performance Indicator, KPI) of data fusion of the present invention may include at least one of signal strength, Protocol Data type, cumulative error correction, and location accuracy.

Table 1 explains each KPI in detail.

Since the domains or sensors belonging to the P-ITS may be diverse, it may be necessary to decide which sensor to select to receive sensing data.

In this case, KPI can be the basis for sensor selection decisions.

When a person moves, the situation in which the P-ITS changes, and the domains or sensors needed to calculate positioning may change accordingly. In addition, even if there is no significant movement, if the positioning calculation becomes difficult due to changes in the sensor signal strength for calculating the positioning, a standard can be set and if the standard is not met, another sensor can be selected.

This can be expressed as a Requirement Level (RL).

Mandatory at the domain level may mean that sensors belonging to that domain must be used for sensor data fusion to calculate positioning.

Since the present invention uses P-ITS as the center of sensor data fusion, P-ITS always has a mandatory domain requirement level. V-ITS or R-ITS may be Mandatory or Optional-if available depending on each situation.

Mandatory at the level of a sensor belonging to a domain may mean that the domain to which the sensor belongs is mandatory and that the sensor is also mandatorily used to calculate positioning.

Even if it is mandatory at the domain level, it can be used optionally (optional-if available) among sensors belonging to that domain. The satellite sensor unit (Satellite) of P-ITS may be mandatory in the sense that it is always used as long as reception is possible.

The GNSS signal received by the P-ITS can be selected as a reference signal that serves as the standard for the signal strength of sensor fusion. This may be the case when sufficient GNSS signals for positioning calculation are transmitted to the P-ITS, and whether the domain requirement level or sensor requirement level is mandatory or optional may vary depending on whether the P-ITS is on board the V-ITS. there is.

For example, when the P-ITS is on a V-ITS, UVIP among the sensors of the V-ITS can be used for dataset fusion, and when the P-ITS calls the V-ITS indoors, the P-ITS located inside the indoor To determine the location, the sensor of R-ITS can be used for dataset fusion.

In this specification, data fusion, data set fusion, or sensor fusion may be used interchangeably with the same meaning unless specifically mentioned.

Table 2 is a default case, which may be a case where the P-ITS is located in an open outdoor area and the GNSS signal is strong. In this case, boarding the P-ITS may be optional. Because the GNSS signal strength is strong, only P-ITS may be sufficient to meet essential domain requirements, and only GNSS may be sufficient to meet essential sensor requirements. Of course, in addition to the Satellite unit, sensor units placed in other P-ITS can also be used.

Here, UVIP may mean Unified Vehicle Interface Protocol.

Referring to Table 3, this may be a case where the reference signal is weak, such as an underground parking lot, and an area where the GNSS signal received by the P-ITS is weak, such as a tunnel, while the P-ITS is riding a V-ITS. If it passes, signal conversion for positioning calculation may occur near the boundary according to the GNSS signal strength, and dataset fusion may occur between different domains near the boundary.

Table 4 may be the basic format of the common dataset of the present invention.

The common data set may include at least one of a starting block "$", an address block, a data block, a checksum block, and an ending block <CR><LF>.

The starting block can signal the beginning of a common data set statement.

The address block may include talker ID, sentence ID, sentence formatter, maker code, sentence type, etc.

For GNSS, it may be a fixed length of 5 bytes. The first 2 bytes represent the speaker ID, and the remaining 3 bytes can perform a sentence formatter. Talker ID is GN for GNSS, GP for GPS, and GL for GLONASS and can be changed by PERDAPI, GNSS commands, and a valid satellite system for positioning.

The block length of a data block can be basically variable. Data blocks can be separated by the delimiter "," (comma).

Data blocks can be expressed in ASCII codes or binary encoding.

Valid data characters can be based on any ASCII character, which can come from 0x20-0x7D, excluding "!", (Ox24), "$", etc.

If there is no data available in one of the data blocks, that block may be null.

Data blocks may contain actual information of the dataset.

The checksum block can be exclusive OR data of 8 bits and can be located between “$” and “*” (“$” and “*” can be excluded).

The checksum block can perform checksum, which is one of the redundancy checks performed to correct errors in data on the transmitting and receiving sides. The checksum block can perform an exclusive OR operation on all data between the end character and the start block. When the checksum block performs an exclusive OR operation between transmitted and received data, the block on which the operation is performed may be a data block.

The end block may mean the end of a common data set sentence and may be expressed by characters such as <CR>: 0x0D, <LF>: 0x0A, etc.

The sensor message fusion process of the present invention involves setting a reference sensor or reference signal, and when the strength of the reference signal received from the domain to calculate positioning weakens below a preset reference value, the domain around the P-ITS Detect available sensors, select and receive sensors for sensor fusion among other detected sensors, convert the sensor data format of each received sensor into a common dataset, and convert the common data of each sensor The set (common dataset) may include sensor data fusion, PVT calculation or localization calculation of the targeted domain or individual.

Based on the contents of the common data set and requirement level mentioned above, the signal attenuation information and signal attenuation area of the sensor signal can be specified from a local perspective, and Based on this, it can be extended to cases where a person holding a P-ITS travels a long area.

The sensor signal intensity attenuation information includes classification according to whether the sensor signal intensity is attenuated in a specific area or sensor signal intensity attenuated due to movement of the area, and classification of the sensor signal intensity attenuation area (e.g., underground, in R-ITS). indoor space, shaded area, etc.), and discrimination based on whether sensor fusion within the same domain or between different domains may be included.

FIG. 17 may relate to an ITS station of the present invention (at least part of the ITS station corresponds to a domain concept) and sensors included in the ITS station.

Referring to FIG. 17, the present invention can have an integrable yet simple system structure, can reduce processing unit load by using a common message format, and can be a system scheduled for commercialization based on technology development.

Referring to Figure 18, the present invention may include input values, processes, and output values. Inputs may include sensor data collected from images, point clouds, IMUs, satellites, or LiDAR, etc., processes may include data processing and sensor fusion, and outputs may include coordinates-oriented data. Can contain common data formats.

Referring to FIG. 19, the location for calculating positioning of the present invention can be determined according to the type of available sensor data, and the overall movement process can be divided into each module.

PD... Personal Domain P-DEV... Personal Device Actor
PI... Personal Information Actor PS... Personal Status Actor
PL... Personal Location Actor PF... Personal Altitude Actor
IoTD... IoT domain IoT-DEV... IoT device actor
IoT-I... IoT information actor IoT-C... IoT communication actor
IoT-S... IoT state actor IoT-L... IoT location actor
SD... Sensor Domain SS... Service Sensor Actor
S-DEV... Device Sensor Actor ID... Infrastructure Domain
IC... Infrastructure Communication Actor IL... Infrastructure Location Actor
IF... Infrastructure Altitude Actor PTD... Positioning Domain
PT-F... Positioning fusion actor PT-V... Positioning velocity actor
PT-S... Positioning state actor PT-A... Positioning accuracy actor
CS... Cloud Server

Claims (2)

Personal domains that provide user-related information;
IoT domain providing vehicle-related information;
an infrastructure domain that provides infrastructure-related information;
A sensor domain that collects information for data exchange between domains;
A positioning domain that calculates the position of the user or vehicle using data transmitted from the domain; Including,
Through data exchange between each domain and the cloud server, indoor and outdoor locations are continuously calculated,
The positioning domain is an indoor/outdoor continuous positioning switching device that receives different types of data obtained from other domains and performs data fusion of the different types of data.
A personal domain that exchanges user-related information with other domains, an IoT domain that exchanges information related to transportation with other domains, an infrastructure domain that exchanges information related to infrastructure with other domains, and a domain that receives data from each domain to provide information about the user or means of transportation. When at least one of the positioning domains that calculates the positioning is provided,
The cloud server helps exchange data between each domain,
Through data exchange between each domain or the cloud server, continuous positioning is calculated when the user or means of transportation passes indoors or outdoors,
The positioning domain is an indoor/outdoor continuous positioning switching device that receives different types of data obtained from other domains and performs data fusion of the different types of data.