IoT apparatus for autonomous shared vehicles and control method thereof

Abstract

An IoT device for an autonomous shared vehicle is disclosed, which manages the dispatch of a vehicle in accordance with a user's request, collects status information of the vehicle dispatched to the user in real time to perform a remote diagnosis, and, if an abnormality in the IoT system applied to the vehicle is detected based on the result of the remote diagnosis, switches the autonomous driving mode of the vehicle to another driving mode.

Description

Technology Field

[0001] The present invention relates to an operation and management device for autonomous shared vehicles, and more specifically, to a device and method that integrates an IoT (Internet of Things) system to perform remote diagnosis, detect and take action on abnormalities in the IoT system, and enable intelligent dispatch management. Background Technology

[0002] With the recent advancement of autonomous driving technology, car-sharing services are rapidly expanding, and the convergence of these two technologies is creating a new mobility ecosystem. Autonomous shared vehicles have the potential to significantly improve operational efficiency and accessibility by providing mobility services to users without a driver. However, realizing such innovative services requires not only safe autonomous driving but also integrated management of the entire service process, ranging from dispatch and in-operation management to vehicle return.

[0003] Conventional autonomous vehicle technologies have been developed primarily with a focus on ensuring the safety of individual vehicles. Basic safety functions have been proposed, such as anomaly detection and mode switching, vehicle status diagnosis through remote monitoring, and switching from autonomous driving mode to manual or remote driving mode. Additionally, features have been developed including response to and control of passenger exit situations, collection and monitoring of real-time vehicle status information, automatic movement to a safety zone in the event of an emergency, and return to autonomous driving mode in the event of communication failure.

[0004] However, these conventional technologies have a fundamental limitation in that they fail to adequately reflect the complexity and requirements of the specialized operating environment of shared vehicles.

[0005] First, existing technologies were designed for privately owned autonomous vehicles and failed to account for the characteristics of shared vehicles, which are used sequentially by an unspecified number of users. As a result, practical problems are arising where user preferences, the provision of customized services, and the continuous management of vehicle status cannot be systematically implemented.

[0006] Second, conventional technologies focus solely on simple mode switching functions, resulting in a lack of integrated management for the entire operational process of shared vehicles. The complex service chain, ranging from dispatch requests to vehicle arrival, boarding, operation, disembarking, and preparation for the next user, is not organically connected, causing critical problems that significantly degrade service continuity and efficiency.

[0007] Third, existing approaches rely primarily on qualitative judgments, making it difficult to make consistent and reliable decisions in complex and dynamic real-world operating environments. In particular, the absence of objective and quantitative criteria in critical decision-making processes—such as risk assessment, determining mode switching timing, and evaluating communication quality—significantly undermines system reliability and predictability.

[0008] Due to these limitations, the commercialization of autonomous vehicle sharing services still faces many technical barriers, and there is an urgent need for a new approach that can ensure safe and efficient operation while satisfying the diverse requirements of users. Prior art literature

[0009] Published Patent 10-2025-0071297 (May 22, 2025) The problem to be solved

[0010] The embodiments disclosed in this disclosure disclose an IoT device capable of remote diagnosis by applying an IoT system to an autonomous shared vehicle and a method for controlling the same.

[0011] Another embodiment disclosed in this disclosure discloses an IoT device and a method for controlling the same, which can detect an anomaly in an IoT system applied to an autonomous shared vehicle and take action.

[0012] Another embodiment disclosed in the present disclosure discloses an IoT device and a method for controlling the same that provides a dispatch management service specialized for autonomous shared vehicles.

[0013] The problems that this disclosure aims to solve are not limited to those mentioned above, and other unmentioned problems will be clearly understood by a person skilled in the art from the description below. means of solving the problem

[0014] An apparatus according to the present disclosure for achieving the aforementioned technical objectives comprises: a memory storing at least one process for applying and verifying an IoT system to an autonomous shared vehicle; and a processor operating according to the at least one process. The processor manages the dispatch of a vehicle in accordance with a user's request, collects status information of the vehicle dispatched to the user in real time to perform a remote diagnosis, and if an abnormality in the IoT system applied to the vehicle is detected based on the result of the remote diagnosis, switches the autonomous driving mode of the vehicle to another driving mode, and switches the driving mode of the vehicle back to an autonomous driving mode based on the result of the remote diagnosis in the switched driving mode, thereby controlling the vehicle to move to a pre-set safety zone and stop.

[0015] Meanwhile, the processor can perform the remote diagnosis to detect the vehicle's entry into a preset autonomous driving-unable zone, switch the vehicle's driving mode to manual driving mode in the autonomous driving-unable zone to request manual operation by direct control of the user through the mobile app, perform the remote diagnosis to detect whether manual operation is performed in the autonomous driving-unable zone, and if manual operation is not detected, switch the vehicle's driving mode to autonomous driving mode to control the vehicle to move to a preset safety zone and stop.

[0016] In addition, the processor can perform the remote diagnosis to detect whether an emergency situation has occurred, and if the occurrence of the emergency situation is detected, switch the driving mode of the vehicle to a remote driving mode to perform remote operation through the transmission and reception of control commands by an administrator, and perform the remote diagnosis to detect whether the communication status for the transmission and reception of control commands is faulty, and if the communication status is faulty, switch the driving mode of the vehicle to an autonomous driving mode to control the vehicle to move to a preset safety zone and stop.

[0017] In addition, the processor can calculate a risk level for determining whether an emergency situation has occurred according to the following mathematical formula 1, and if the calculated risk level is greater than or equal to a threshold value, it can detect that an emergency situation has occurred.

[0018] [Mathematical Formula 1]

[0019] Risk Score = α × Traffic Condition Index + β × Weather Impact + γ × Vehicle Condition Index + δ × Driver Responsiveness

[0020] In addition, the processor can calculate a mode switching score according to the following mathematical formula 2, switch from the autonomous driving mode to the remote driving mode if the mode switching score is 70 points or higher, switch from the remote driving mode to the autonomous driving mode if the mode switching score is 30 points or lower, and control the vehicle to make an emergency stop if the mode switching score is 90 points or higher.

[0021] [Mathematical Formula 2]

[0022] Mode Switching Score = (Current Risk - Baseline Risk) × Reliability Coefficient + Urgency Correction Value

[0023] In addition, the processor may calculate a communication quality index for a plurality of communication channels for transmitting and receiving control commands according to the following mathematical formula 3, and select one of the plurality of communication channels according to the following mathematical formula 4.

[0024] [Mathematical Formula 3]

[0025] Communication Quality Index = Σ(Signal Strength per Channel × Channel Weight) / Total Number of Channels

[0026] [Mathematical Formula 4]

[0027] Optimal Channel = argmax(Signal Strength × Stability × Bandwidth / Latency)

[0028] In addition, the processor can predict the time of occurrence of a communication state failure according to the following mathematical formula 5, warn of switching to the autonomous driving mode if the predicted time is 30 seconds or less, and immediately switch to the autonomous driving mode if the predicted time is 10 seconds or less.

[0029] [Mathematical Formula 5]

[0030] Predicted Disconnection Time = Current Signal Decline Rate × Terrain Influence Factor × Weather Correction Factor

[0031] In addition, the processor, upon confirming the user's temporary disembarkation as a result of performing the remote diagnosis, checks whether the disembarkation area corresponds to a no-parking zone; if the disembarkation area corresponds to a no-parking zone, switches the vehicle's driving mode to an autonomous driving mode and controls the vehicle to move within a preset radius for a preset time; and if the preset time has elapsed, controls the vehicle to park in a preset parking spot.

[0032] Additionally, the processor may set a boarding and alighting location for the dispatched vehicle based on the user's current location, acquire the user's personal mobility information, set the boarding and alighting location by reflecting the personal mobility information, and generate movement linkage information to move from the user's current location to the boarding and alighting location via the personal mobility and provide it to the user.

[0033] Meanwhile, the method of the present disclosure, in a control method for an IoT device installed in an autonomous shared vehicle to apply and verify an IoT system, comprises: a step of managing the dispatch of a vehicle according to a user's request; a step of collecting status information of the vehicle dispatched to the user in real time and performing a remote diagnosis; a step of switching the autonomous driving mode of the vehicle to another driving mode when an abnormality in the IoT system applied to the vehicle is detected according to the result of the remote diagnosis; and a step of controlling the vehicle to move to a pre-set safety zone and stop by switching the driving mode of the vehicle back to an autonomous driving mode according to the result of the remote diagnosis in the switched driving mode.

[0034] In addition to this, a computer program stored on a computer-readable recording medium for executing the present disclosure may be further provided.

[0035] In addition, a computer-readable recording medium for recording a computer program for executing a method for implementing the present disclosure may be further provided. Effects of the invention

[0036] According to the present invention, real-time remote diagnosis can be performed by collecting vehicle status information through an integrated IoT system specialized for autonomous shared vehicles, thereby providing a technical effect that significantly improves the safety and efficiency of shared vehicle operations.

[0037] In addition, by detecting anomalies in the IoT system applied to the vehicle and providing information for corrective actions, it is possible to simultaneously improve vehicle uptime and reduce maintenance costs.

[0038] Furthermore, user satisfaction can be significantly enhanced by providing dispatch management services optimized for each user. Moreover, by offering features such as unmanned valet services, it contributes to improved user convenience and systematically ensures reliability through phased test verifications to facilitate the commercialization and acceleration of the service.

[0039] The effects of the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by a person skilled in the art from the description below. Brief explanation of the drawing

[0040] FIG. 1 is a conceptual diagram of an IoT system for an autonomous shared vehicle according to one embodiment of the present disclosure. Figure 2 is a control block diagram of the IoT device shown in Figure 1. Figure 3 is a flowchart of a control method for the device shown in Figure 2. Figure 4 is a detailed flowchart of step S100 shown in Figure 3. Figure 5 is a detailed flowchart of step S300 shown in Figure 3. Figures 6 and 7 are detailed flowcharts of the S500 step shown in Figure 3. Specific details for implementing the invention

[0041] Throughout this disclosure, the same reference numerals denote the same components. This disclosure does not describe all elements of the embodiments, and general content in the art to which this disclosure pertains or content that overlaps between embodiments is omitted. The terms 'part, module, component, block' as used in the specification may be implemented in software or hardware, and depending on the embodiments, a plurality of 'parts, modules, components, blocks' may be implemented as a single component, or a single 'part, module, component, block' may include a plurality of components.

[0042] Throughout the specification, when a part is described as being "connected" to another part, this includes not only cases where they are directly connected but also cases where they are indirectly connected, and indirect connections include connections made via a wireless communication network.

[0043] Furthermore, when it is stated that a part "includes" a certain component, this means that, unless specifically stated otherwise, it does not exclude other components but may include additional components.

[0044] Throughout the specification, when it is stated that a component is located "on" another component, this includes not only cases where a component is in contact with another component, but also cases where another component exists between the two components.

[0045] The terms first, second, etc. are used to distinguish one component from another, and the components are not limited by the aforementioned terms.

[0046] Singular expressions include plural expressions unless there is an obvious exception in the context.

[0047] In each step, identification codes are used for convenience of explanation and do not describe the order of the steps; the steps may be performed differently from the specified order unless a specific order is clearly indicated in the context.

[0048] The operating principles and embodiments of the present disclosure will be described below with reference to the attached drawings.

[0049] In this specification, the term "device according to the present disclosure" includes all various devices capable of performing computational processing and providing results to a user. For example, the device according to the present disclosure may include all of a computer, a server device, and a portable terminal, or may be in the form of any one of these.

[0050] Here, the computer may include, for example, a notebook, desktop, laptop, tablet PC, slate PC, etc. equipped with a web browser.

[0051] The above server device is a server that processes information by communicating with an external device, and may include an application server, a computing server, a database server, a file server, a game server, a mail server, a proxy server, and a web server.

[0052] The above portable terminal may include, for example, all types of handheld-based wireless communication devices such as PCS (Personal Communication System), GSM (Global System for Mobile communications), PDC (Personal Digital Cellular), PHS (Personal Handyphone System), PDA (Personal Digital Assistant), IMT (International Mobile Telecommunication)-2000, CDMA (Code Division Multiple Access)-2000, W-CDMA (W-Code Division Multiple Access), WiBro (Wireless Broadband Internet) terminals, smartphones, etc., as well as wearable devices such as watches, rings, bracelets, anklets, necklaces, glasses, contact lenses, or head-mounted devices (HMDs).

[0053] Functions related to artificial intelligence according to the present disclosure are operated through a processor and memory. The processor may be composed of one or more processors. In this case, the one or more processors may be general-purpose processors such as CPUs, APs, and DSPs (Digital Signal Processors), graphics-dedicated processors such as GPUs and VPUs (Vision Processing Units), or artificial intelligence-dedicated processors such as NPUs. The one or more processors control the processing of input data according to predefined operation rules or artificial intelligence models stored in memory. Alternatively, if the one or more processors are artificial intelligence-dedicated processors, the artificial intelligence-dedicated processors may be designed with a hardware structure specialized for processing a specific artificial intelligence model.

[0054] The present invention provides an IoT system specialized for autonomous shared vehicles, and can implement a comprehensive management platform that is differentiated from existing general autonomous vehicle control technologies.

[0055] FIG. 1 is a conceptual diagram of an IoT system for an autonomous shared vehicle according to one embodiment of the present disclosure.

[0056] Referring to FIG. 1, an IoT system (1) for an autonomous shared vehicle according to one embodiment of the present disclosure may be composed of an IoT device (100) mounted on a vehicle and a user terminal (200) carried by a user.

[0057] The IoT device (100) is responsible for the overall control and monitoring of the vehicle and can provide customized services through bidirectional communication with the user terminal (200). Through this configuration, the present invention can build an ecosystem that goes beyond simple vehicle control and integrates the entire process from dispatch to return.

[0058] The IoT system (1) of the present invention can be broadly divided into four core functional areas. First, as a user-customized dispatch management system, it can perform optimized vehicle assignment and route setting by learning individual preferences and usage patterns. Second, as a real-time remote diagnostic system, it can continuously monitor various status information of the vehicle and detect abnormal situations early. Third, as an intelligent driving mode switching system, it can support seamless switching between autonomous driving, manual driving, and remote driving modes depending on the situation. Fourth, as an unmanned valet service system, it can enable automated vehicle operation according to various scenarios.

[0059] Figure 2 is a control block diagram of the IoT device shown in Figure 1.

[0060] Referring to FIG. 2, an IoT device (100) according to one embodiment of the present disclosure may be configured to include a processor (110), a communication module (120), a memory (130), and a driving module (140). Each component may be organically connected to perform comprehensive IoT management functions for a vehicle.

[0061] The processor (110) is a central processing unit that performs the core functions of the present invention and may be, for example, an ARM Cortex-A78-based octa-core processor, but is not limited thereto, and may include a Neural Processing Unit (NPU) for artificial intelligence computation and a Digital Signal Processor (DSP) for real-time data processing.

[0062] For example, the processor (110) can analyze a user's dispatch request to select the optimal vehicle, comprehensively analyze vehicle status information collected in real time to perform remote diagnosis, and generate an immediate driving mode switching command when a dangerous situation is detected.

[0063] The communication module (120) may be implemented as a composite communication system that supports multiple communication channels. In one embodiment of the present invention, the communication module (120) may simultaneously support 5G NR (New Radio) communication, LTE-Advanced Pro communication, Wi-Fi 6E communication, and satellite communication functions, but is not limited thereto. Quality indicators such as signal strength, latency, bandwidth, and packet loss rate may be monitored in real time for each communication channel, and the processor (110) may dynamically select the optimal communication channel. For example, 5G communication may be used preferentially in urban areas, automatically switched to LTE communication in suburban areas, and Wi-Fi communication may be utilized in tunnels or underground sections.

[0064] The memory (130) can be designed as a hierarchical memory structure for large-capacity data storage and high-speed data processing. In one embodiment of the present invention, the memory (130) may be composed of, for example, 16GB of LPDDR5 RAM and 1TB of UFS 3.1 storage, but is not limited thereto, and may store user preference information, vehicle status history data, unmanned valet scenario programs, mathematical model algorithms, etc.

[0065] Additionally, the memory (130) may include a cache memory for real-time data processing and an archive storage for long-term data storage, and may support an ECC (Error Correcting Code) function to ensure data integrity.

[0066] The drive module (140) is an actuator control system responsible for the physical control of the vehicle, and can integrally control core driving functions such as steering, acceleration, braking, and gear shifting, as well as additional functions such as opening and closing doors, horns, and hazard lights.

[0067] In one embodiment of the present invention, the driving module (140) communicates with the vehicle's ECUs (Electronic Control Units) via a CAN (Controller Area Network) bus and can convert control commands received from the processor (110) into actual vehicle operations. Alternatively, in remote driving mode, the vehicle can be remotely operated by processing external control commands received through the communication module (120) in real time, and in the event of communication loss, the vehicle can be automatically switched to a safety mode to move to a safe zone.

[0068] Figure 3 is a flowchart of a control method for the device shown in Figure 2.

[0069] Referring to FIG. 3, a control method of an IoT device (1) according to one embodiment of the present disclosure may include a vehicle dispatch management step (S100), a remote diagnosis step (S300), a case in which an abnormality of the IoT system is detected (S400), and a step of switching the driving mode (S500).

[0070] When the processor (110) receives a request for vehicle dispatch from a user through a user terminal (200), it can analyze the user's request for dispatch and manage vehicle dispatch according to an optimal dispatch logic (S100). In this process, the processor (110) can comprehensively consider various variables such as the user's past usage patterns, current location, traffic conditions, and vehicle availability. Additionally, the processor (110) can support vehicle dispatch according to a plurality of pre-configured unmanned valet scenarios. A detailed explanation regarding this will be provided later with reference to FIG. 4.

[0071] The processor (110) can obtain real-time status information from a vehicle assigned to a user and perform remote diagnosis (S300). The processor (110) can analyze the real-time status information collected from the vehicle to detect potential problems early and suggest appropriate countermeasures. A detailed explanation regarding this will be provided later with reference to FIG. 5.

[0072] When the processor (110) detects an abnormality in the IoT system applied to the vehicle based on remote diagnosis (S400), it can control the switching of the vehicle's driving mode (S500). The processor (110) can dynamically switch the vehicle's driving mode according to the situation, and can make objective and reliable judgments by performing quantitative analysis such as risk assessment and calculation of a mode switching score. In addition, the processor (110) can ensure stable data transmission and reception by evaluating the quality of multiple communication channels in real time and selecting the optimal channel. A detailed explanation regarding this will be provided later with reference to FIGS. 6 and FIGS. 7.

[0073] Figure 4 is a detailed flowchart of step S100 shown in Figure 3.

[0074] Referring to FIG. 4, in one embodiment of the present disclosure, a vehicle dispatch management step (S100) may be composed of the steps of obtaining user preference information (S110), user-customized vehicle dispatch (S120), and performing an unmanned valet scenario (S130). Each step may be performed independently or may be interconnected to provide an integrated service.

[0075] In step S110, the processor (110) can obtain user preference information through various methods. Explicit methods may include preferred vehicle type (autonomous, manual, mixed, etc.) entered directly by the user, preferred boarding / alighting location (closest, convenient for boarding / alighting, etc.), preferred route (by recommendation, autonomous driving capability, by time, priority on free roads, etc.), and priority items (priority on preferred vehicle type, priority on preferred boarding / alighting location, etc.), and implicit methods may include preference inference through analysis of past usage patterns.

[0076] In one embodiment of the present invention, a user's past usage patterns can be analyzed by subdividing them by time of day, day of the week, and season. For example, a pattern may be found where a vehicle is mainly used near a subway station at 8 a.m. on weekdays, and near a shopping mall or park on weekend afternoons. These patterns can be modeled through a machine learning algorithm and utilized to calculate user preferences.

[0077] In step S120, the processor (110) can dispatch a user-customized vehicle based on the acquired user preference information.

[0078] In one embodiment, the processor (110) can dispatch a vehicle from among all available vehicles at the time of the user's request according to the priority included in the user's preference information.

[0079] In another embodiment, the processor (110) can calculate a service score for all available vehicles at the time of a user's request using the following mathematical formula 1, and prioritize dispatching the vehicle with the highest service score.

[0080] [Mathematical Formula 1]

[0081] Service Score = Σ(User Preference × Serviceability × Efficiency Index)

[0082] (User Preference = Past Usage Patterns × Current Settings × Time Zone Adjustment, Serviceability = Vehicle Availability × Route Suitability × Weather Suitability, Efficiency Index = 1 / (Estimated Waiting Time × Energy Consumption × Operating Costs))

[0083] The service score is calculated as the product of user preference, serviceability, and efficiency indices, and each element can be composed of detailed sub-variables.

[0084] User preferences are not based solely on historical data but can be dynamically adjusted through current settings and time zone corrections. For example, if a user requests a vehicle at an unusual time, a time zone correction factor can be applied to reflect the typical usage patterns of that time. This enables a proactive response to the changing needs of users.

[0085] Serviceability can be calculated as the product of vehicle availability, route suitability, and weather suitability. Vehicle availability considers the number and location of currently available vehicles, while route suitability evaluates the accessibility of each vehicle to the user's origin and destination. Weather suitability evaluates the suitability of each vehicle type under current weather conditions; for example, on snowy days, the suitability of 4WD vehicles may be rated highly.

[0086] The efficiency index can be calculated as the inverse of the estimated waiting time, energy consumption, and operating costs. This allows for the simultaneous provision of fast service to users and efficient operation to operators. In one embodiment of the present invention, the weights of each element when calculating the efficiency index can be dynamically adjusted according to the time of day and region. For example, the weight of waiting time can be set high during commuting hours, and the weight of energy consumption can be set high during late-night hours.

[0087] Meanwhile, when the processor (110) dispatches a vehicle, it can set a boarding and alighting location for the dispatched vehicle based on the user's current location. When the processor (110) sets a boarding and alighting location, it can generate and provide to the user at least one of the boarding and alighting location, the route from the vehicle's current location to the boarding and alighting location, and the estimated time for the vehicle to travel along the route to the boarding and alighting location in real time on a map. For example, the processor (110) can provide information related to boarding and alighting through a mobile app running on a user terminal (200).

[0088] In one embodiment, the processor (110) can set an optimal pick-up and drop-off location within a radius of 500m based on the user's current location. Criteria for selecting the pick-up and drop-off location may include traffic safety (e.g., whether a vehicle can stop, ensuring pedestrian safety), accessibility (e.g., flat ground without stairs, accessibility for the disabled), and legal compliance (e.g., avoiding no-parking zones, avoiding fire truck zones).

[0089] In another embodiment, the processor (110) may set a boarding and alighting location based on a first-mile movement linkage. The processor (110) acquires the user's personal mobility information and selects a boarding and alighting location by reflecting the personal mobility information. In this case, it may generate movement linkage information to move from the user's current location to the boarding and alighting location via personal mobility and provide it to the user through a mobile app.

[0090] The user's personal mobility information may include information on electric scooters, electric bicycles, personal mobility devices (PMAs), etc., that the user owns or that are available to the user through shared services.

[0091] When setting a boarding and alighting location, the processor (110) can calculate the range accessible from the user's current location using personal mobility. In one embodiment of the present invention, the boarding and alighting location can be set within a radius of 2 km for a kickboard, 5 km for a bicycle, and 3 km for an electric wheel, but is not limited thereto and can be adjusted according to the user's physical strength and preference.

[0092] When generating movement linkage information, the processor (110) can comprehensively consider the travel time of personal mobility, route safety, weather conditions, etc. In addition, by linking with real-time traffic information, it can provide a route that avoids sections where personal mobility cannot be used (e.g., construction zones, event zones).

[0093] In step S130, the processor (110) can perform an unmanned valet scenario to move the dispatched vehicle to the pick-up and drop-off location.

[0094] In this embodiment, the unmanned valet scenario is a four-stage automation scenario specialized for shared vehicle operation, each scenario is optimized for specific situations and environments, and can be interconnected to build a complete unmanned operation ecosystem.

[0095] The first unmanned valet scenario automates the movement of vehicles between pickup / return zones and parking spaces within a pre-configured private property, allowing the vehicle to automatically move from the designated pickup / return zone when a user picks up or returns it. For example, in the underground parking lot of a large shopping mall, if a user requests a vehicle from the B3 pickup zone, a vehicle parked in a B5 space can automatically move to the B3 floor to wait for the user.

[0096] The second unmanned valet scenario can maximize vehicle management efficiency by automating the movement of vehicles between the maintenance / car wash garage and the parking space. When the system detects the need for maintenance, it automatically moves the vehicle to the maintenance garage, and can return it to the parking space after the maintenance is completed. Similarly, for car washes, if the vehicle's cleanliness falls below a standard, it can automatically move to the car wash facility, receive a wash, and return to its original location.

[0097] The third unmanned valet scenario can support vehicle movement between a pre-configured parking lot and the user's pick-up / drop-off location outside of the pre-configured private property. For example, if a user requests a vehicle in a downtown business district but parking spaces are scarce in that area, the system can automatically move a vehicle parked in a nearby public or affiliated parking lot to the user's location. In this case, the optimal vehicle can be selected by comprehensively considering factors such as the distance from the parking lot to the pick-up / drop-off location, traffic conditions, and parking costs.

[0098] The fourth unmanned valet scenario can maximize the operational efficiency of shared vehicles by providing vehicle transport and return services. The transport service involves automatically moving a vehicle from another area to a user's requested location if no available vehicle is available there, while the return service involves moving the vehicle to the optimal location for the next user after the user has finished using it. For example, if vehicle demand surges in the Gangnam area but available vehicles are scarce, the system can respond to the demand by automatically moving idle vehicles from the Yeouido or Jongno areas to Gangnam.

[0099] Meanwhile, the processor (110) can provide a mobile app-based smart key function to provide the user with functions such as locking / unlocking the doors of the dispatched vehicle, controlling the emergency lights and horn.

[0100] Additionally, the processor (110) may provide status information such as the cleanliness, maintenance status, and charge level of the dispatched vehicle through a mobile app, and in particular, may determine whether the vehicle is movable by checking the charge level and provide whether the vehicle is movable through the mobile app.

[0101] Additionally, the processor (110) can set the vehicle's driving mode by receiving a selection from the user via a mobile app as one of the autonomous driving mode, manual driving mode, and mixed driving mode, and can finally set the driving mode by checking whether the user has completed safety training for the driving mode selected by the user.

[0102] Additionally, the processor (110) can receive at least one destination for autonomous driving of the vehicle through a mobile app and can provide a function to add or change the destination while driving.

[0103] Figure 5 is a detailed flowchart of step S300 shown in Figure 3.

[0104] Referring to FIG. 5, a remote diagnostic step (S300) according to one embodiment of the present disclosure may be composed of the steps of obtaining vehicle status information (S310), generating action information based on vehicle status information (S320), and providing action information (S330).

[0105] In step S310, the processor (110) can collect data in real time from various sensors and IoT devices mounted on the vehicle. In one embodiment of the present invention, the collected status information may include, but is not limited to, engine / motor status (e.g., RPM, temperature, vibration, efficiency), battery status (e.g., SOC, SOH, voltage, current, temperature), fuel status, tire status (e.g., air pressure, temperature, wear, grip), brake status (e.g., pad thickness, disc temperature, braking force), steering system status (e.g., steering angle, responsiveness, hydraulic pressure), suspension status (e.g., damper status, spring compression ratio), electronic system status (e.g., ECU error code, whether sensor is operating normally), vehicle body status (e.g., door open / closed status, window status, lighting status), and internal environment status (e.g., temperature, humidity, air quality, cleanliness).

[0106] The collected status information is processed through various analysis algorithms to detect potential problems at an early stage. The present invention can perform high-accuracy anomaly detection by combining rule-based analysis, statistical analysis, and machine learning-based analysis.

[0107] In steps S320 and S330, the processor (110) can analyze vehicle status information to perform a remote diagnosis, generate appropriate action information based on the diagnosis results, and provide the generated action information to the user through a mobile app.

[0108] In one embodiment, the processor (110) may analyze vehicle status information before the user boards the dispatched vehicle to check whether boarding conditions are met and generate action information to meet the boarding conditions. For example, boarding conditions may include vehicle cleanliness, fuel / battery sufficiency, normal operation of major components, insurance and registration status, etc., and if the conditions are not met, the processor may automatically dispatch a replacement vehicle or provide guidance on necessary actions.

[0109] In another embodiment, the processor (110) may analyze vehicle status information before the user returns the dispatched vehicle to check whether return conditions are met and generate action information to satisfy the return conditions. Return conditions may include checking for vehicle damage, fuel / battery levels, interior cleanliness, and the presence of lost items. When returning the vehicle, the user may record damage by photographing the exterior and interior of the vehicle via a mobile app, and the system may automatically detect and evaluate damage through AI-based image analysis.

[0110] In another embodiment, the processor (110) can perform remote diagnosis to identify event situations occurring while driving the vehicle and notify the user of various situations in real time. For example, if an event such as sudden braking, sudden acceleration, or sudden turning occurs, the location, time, and cause at that point in time can be recorded and a notification can be sent to the user. In addition, if an emergency situation such as a traffic accident, vehicle breakdown, or adverse weather occurs, it is automatically reported to the management center immediately, and situation information and response methods can also be provided to the user.

[0111] In another embodiment, the processor (110) can detect a situation where parking or stopping is not possible at a destination selected by the user and provide an alternative location. For example, the processor (110) can evaluate the possibility of parking around the destination in advance by combining real-time traffic information, parking lot operating status, road construction information, etc. If it is determined that parking / stopping is not possible, it can automatically search for an alternative location within a radius of 500m and present several options to the user. When selecting an alternative location, the distance from the destination, walking time, parking costs, safety, etc., can be comprehensively considered.

[0112] In another embodiment, the processor (110) can detect whether the user has temporarily disembarked, and in such case, it can switch the vehicle's driving mode to an autonomous driving mode, control the vehicle to roam within a preset radius for a preset time, and, if the preset time has elapsed, move the vehicle to park in a preset parking spot.

[0113] In another embodiment, when the processor (110) detects a user’s temporary disembarkation, it checks whether the disembarkation area is a no-parking zone. If the disembarkation area is a no-parking zone, it switches the vehicle’s driving mode to an autonomous driving mode to control the vehicle to roam within a preset radius for a preset time. If the preset time has elapsed, it can move the vehicle to park in a preset parking spot.

[0114] In one embodiment of the present invention, the user's technical level and preferences may be considered when generating action information. Users with extensive technical knowledge may be provided with various options along with detailed technical information, while general users may be provided with simple and clear guidance. Additionally, the most effective action method may be suggested first by analyzing the user's past response patterns.

[0115] Meanwhile, the processor (110) performs such remote diagnosis to detect abnormal conditions in the overall IoT system leading to state information sensing and drive control (S400), and can dynamically switch and control the driving mode of the vehicle according to the detection result. This will be explained with reference to FIGS. 6 and 7.

[0116] Figures 6 and 7 are detailed flowcharts of the S500 step shown in Figure 3.

[0117] Referring to FIG. 6, a driving mode switching step (S500) according to one embodiment of the present disclosure is a scenario for switching between an autonomous driving mode and a manual driving mode in response to a situation where autonomous driving is not possible, and may be composed of the steps of detecting a situation where autonomous driving is not possible (S510), switching to a manual driving mode (S511), checking whether manual operation is performed (S512), and returning to an autonomous driving mode (S513). Here, the manual driving mode may be a driving mode that is manually operated by a driver who is actually in the vehicle.

[0118] In step S510, the processor (110) can detect sections where autonomous driving is not possible through various methods. First, sections where autonomous driving is not possible, such as construction zones, complex intersections, and unpaved roads, can be identified in advance by utilizing a pre-established precision map database. Second, temporary situations where autonomous driving is not possible (e.g., accidents, road construction, adverse weather conditions) can be detected through real-time traffic information and V2I communication. Third, the vehicle's sensor system can determine in real time whether the current driving environment is not suitable for autonomous driving.

[0119] In step S511, if a section where autonomous driving is not possible is detected, the processor (110) may switch the vehicle's driving mode to manual driving mode. During this process, a request for manual operation may be conveyed to the user via a mobile app along with a description of the situation. The request for manual operation may include the current situation, expected manual operation section, precautions, etc.

[0120] In step S512, the processor (110) can continuously monitor whether the user is performing manual operation. Manual operation detection can be confirmed through input from the steering wheel, accelerator pedal, and brake pedal, and in one embodiment of the present invention, if manual operation is not detected within 30 seconds, it can be determined as an abnormal situation.

[0121] If no manual operation is detected, in step S513, the processor (110) may switch the vehicle to autonomous driving mode and move it to a pre-set safe zone. The safe zone may be a shoulder, a parking lot, a rest area, etc., and the safest place closest to the current location may be automatically selected.

[0122] Referring to FIG. 7, a driving mode switching step (S500) according to another embodiment of the present disclosure is a scenario for switching between an autonomous driving mode and a remote driving mode in response to an emergency situation, and may be composed of the steps of detecting an emergency situation (S520), switching to a remote driving mode (S521), checking the communication status (S522), and returning to an autonomous driving mode (S523). Here, the remote driving mode may be a driving mode that is remotely operated by receiving a control command transmitted by a remote manager.

[0123] In step S520, the processor (110) can determine whether an emergency situation has occurred.

[0124] For example, the processor (110) can calculate a risk score according to the following mathematical formula 2, and if the calculated risk score is greater than or equal to a threshold value, it can detect that an emergency situation has occurred.

[0125] [Mathematical Formula 2]

[0126] Risk Score = α × Traffic Condition Index + β × Weather Impact + γ × Vehicle Condition Index + δ × Driver Responsiveness

[0127] The risk score is calculated as a weighted sum of the traffic condition index, weather impact, vehicle condition index, and driver responsiveness, and each weight (α, β, γ, δ) can be dynamically adjusted according to the situation and environment.

[0128] The traffic condition index can be calculated on a scale of 0 to 100 by combining the density of surrounding vehicles, speed differences, distance between vehicles, and consistency of traffic flow. For example, on a highway, if the distance between vehicles is less than 2 seconds and the speed difference is 30 km / h or more, the traffic condition index can be calculated as 80 points or higher.

[0129] The weather impact score can be calculated by taking into account precipitation, visibility, wind speed, road surface conditions, etc. For example, if the hourly precipitation is 20 mm or more and the visibility is 100 m or less, the weather impact score can be calculated as 90 points or more.

[0130] The vehicle condition index can be calculated by combining the condition of major components such as brakes, steering, tires, and battery. For example, if the brake pad wear is 80% or more and the tire pressure is 80% or less of the recommended value, the vehicle condition index can be calculated as 70 points or higher.

[0131] Driver responsiveness is replaced by the system's responsiveness in autonomous driving mode and can be calculated by considering sensor accuracy, processing speed, communication delay, etc. For example, if the accuracy of the LiDAR sensor is 95% or less and the communication delay is 100ms or more, the driver responsiveness can be calculated as 60 points or more.

[0132] In mathematical formula 1, each coefficient can be dynamically adjusted depending on the situation, but generally, α=0.4, β=0.2, γ=0.3, and δ=0.1. If the calculated risk level is above a threshold (e.g., 70 points), it can be determined as an emergency situation.

[0133] In step S521, if the calculated risk score is greater than or equal to a threshold value, the processor (110) can switch the vehicle's driving mode to a remote driving mode. In the remote driving mode, a professional operator at the management center can directly control the vehicle, and for this purpose, real-time video of the vehicle, sensor data, and surrounding situation information can be transmitted to the management center. The management center can precisely control the vehicle through a remote operation facility equipped with a high-resolution monitor, steering wheel, pedals, etc.

[0134] In one embodiment, the processor (110) calculates a mode switching score according to the following mathematical formula 3, and if the mode switching score is 70 points or more, switches from autonomous driving to remote driving, if it is 30 points or less, switches from remote driving to autonomous driving, and if it is 90 points or more, can bring the vehicle to an emergency stop.

[0135] [Mathematical Formula 3]

[0136] Mode Switching Score = (Current Risk - Baseline Risk) × Reliability Coefficient + Urgency Correction Value

[0137] The mode switching score can be calculated by multiplying the difference between the current risk and the reference risk by a reliability coefficient and adding an urgency correction value.

[0138] Meanwhile, the processor (110) can select a communication channel for transmitting and receiving control commands for remote driving. The communication module (120) will be equipped with multiple communication modems to ensure communication stability.

[0139] In one embodiment, the processor (110) calculates a communication quality index for each of a plurality of communication channels for transmitting and receiving control commands for remote driving according to the following mathematical formula 4, and can select one of the plurality of communication channels according to mathematical formula 5.

[0140] [Mathematical Formula 4]

[0141] Communication Quality Index = Σ(Signal Strength per Channel × Channel Weight) / Total Number of Channels

[0142] [Mathematical Formula 5]

[0143] Optimal Channel = argmax(Signal Strength × Stability × Bandwidth / Latency)

[0144] The communication quality index according to mathematical formula 4 can be calculated by summing the product of the signal strength and channel weight of each channel for all channels and then dividing by the total number of channels.

[0145] In one embodiment of the present invention, the weight of the 5G channel may be set to 0.4, the weight of the LTE channel to 0.3, the weight of the Wi-Fi channel to 0.2, and the weight of the V2X channel to 0.1, but is not limited thereto and may be dynamically adjusted depending on the region and situation. In urban areas, the weights of 5G and Wi-Fi may be set high, and in suburban areas, the weight of LTE may be set high.

[0146] Optimal channel selection according to Equation 5 can be performed by selecting the channel where the value obtained by dividing the product of signal strength, stability, and bandwidth by the delay time is maximized. Through this, it is possible to select a channel with excellent overall performance rather than simply a channel with a strong signal.

[0147] In step S522, the processor (110) can continuously monitor the communication status for remote driving to detect a communication status failure, including a communication interruption.

[0148] In one embodiment, the processor (110) can predict the communication interruption time according to the following mathematical formula 6. The processor (110) can warn of switching to autonomous driving mode if the predicted time is 30 seconds or less, and can switch to autonomous driving mode immediately if the predicted time is 10 seconds or less. Through this predictive response, dangerous situations caused by communication interruption can be prevented in advance.

[0149] [Mathematical Formula 6]

[0150] Predicted Disconnection Time = Current Signal Decline Rate × Terrain Influence Factor × Weather Correction Factor

[0151] For example, if the current signal attenuation rate is -2 dBm / sec or higher, the predicted time can be calculated by applying a terrain influence factor (inside tunnel: 1.5, mountainous area: 1.2, urban area: 1.0) and a weather correction factor (heavy rain: 1.3, snow: 1.2, clear: 1.0).

[0152] In step S523, if the processor (110) detects a communication status failure, it can immediately switch to autonomous driving mode.

[0153] After switching to autonomous driving mode, the vehicle can automatically move to the nearest safe zone and stop. At this time, the vehicle utilizes GPS and high-precision maps to calculate the optimal route and moves safely by considering surrounding traffic conditions.

[0154] Meanwhile, an IoT device (100) according to one embodiment of the present disclosure can systematically verify all functions and scenarios before actual commercial service by performing testbed-based system verification.

[0155] In one embodiment, the processor (110) can perform verification of the vehicle's autonomous driving by executing the first unmanned valet scenario to the fourth unmanned valet scenario in stages.

[0156] The testbed can be configured as a hybrid form combining a closed test track that simulates a real road environment with a virtual simulation environment. For example, the closed test track can reproduce various road environments (highways, general roads, intersections, parking lots, tunnels, ramps, etc.) in an area of ​​10 km², and obstacles, traffic lights, signs, etc. can be installed to simulate actual traffic conditions.

[0157] In the first unmanned valet scenario verification, the accuracy, safety, and efficiency of vehicle movement between the pickup / return zone and the parking space can be evaluated. Test items may include accurate arrival at the pickup zone (error range ±50cm), maintenance of a safe speed (10km / h or less), obstacle avoidance capability, and prevention of collisions with other vehicles. Each scenario must be executed at least 100 times to achieve a success rate of 99% or higher before proceeding to the next stage.

[0158] In the second unmanned valet scenario verification, movement between the maintenance / car wash garage and the parking space can be tested. During this process, the entire procedure—in which the vehicle automatically detects the need for maintenance, moves to the appropriate maintenance facility, and returns to its original location after maintenance is completed—can be verified. In particular, precise positional alignment (with an error margin of ±10cm) with the lift or car wash equipment at the maintenance facility can serve as an important evaluation criterion.

[0159] In the third unmanned valet scenario verification, movement between the parking lot and the pick-up / drop-off location can be tested under various traffic conditions. The vehicle's response capabilities can be evaluated by artificially creating situations such as rush hour, inclement weather, and road construction, and the accuracy of the estimated arrival time (error range ±2 minutes) can also serve as an important evaluation metric.

[0160] In the verification of the fourth unmanned valet scenario, long-distance transport and return services can be tested. During this process, fuel / battery efficiency, long-distance autonomous driving stability, and the ability to maintain communication connectivity can be evaluated. In particular, the ability to respond in communication blind spots and the automatic response capability in the event of an emergency can be verified with emphasis.

[0161] Meanwhile, the processor (110) can evaluate the system reliability according to the following mathematical formula 7 during the verification process of each scenario.

[0162] [Mathematical Formula 7]

[0163] System Reliability = Π(Reliability of Each Component)^Weight

[0164] Component Reliability = (Normal Operating Time / Total Operating Time) × Performance Index × Error Frequency Correction

[0165] The reliability of each component (sensor, communication, control, actuation) is calculated by combining normal operating time, performance index, and error frequency, and the overall system reliability can be calculated as the weighted product of the reliability of each component. The target reliability can be set to 99.9% or higher, and if this is not achieved, improvement of the corresponding component may be required.

[0166] Meanwhile, the processor (110) can predict when the vehicle needs maintenance by calculating a maintenance need score according to the following mathematical formula 8. The processor (110) provides the maintenance need time to the manager so that vehicle maintenance can be performed at an appropriate time, thereby ensuring the stability of the shared vehicle service provision. Alternatively, the processor (110) may execute a second unmanned valet scenario in accordance with the maintenance need time to automatically move the vehicle to the maintenance area.

[0167] [Mathematical Formula 8]

[0168] Maintenance Requirement = Σ(Part Wear × Importance Factor × Frequency of Use)

[0169] Predicted Maintenance Time = Current Wear / Wear Progression Rate × Safety Margin

[0170] For measuring wear by component, sensors and measurement methods tailored to the characteristics of each part can be used. In the case of brake pads, the wear status can be measured in real time using a thickness sensor, allowing for continuous monitoring of wear progression from an initial thickness of 8mm to the replacement standard of 3mm. For tires, wear and condition can be measured using tread depth and air pressure sensors, enabling tracking of changes from an initial tread depth of 8mm to the legal standard of 1.6mm.

[0171] In the case of batteries, the overall health status can be evaluated through State of Health (SOH) measurements, and the degree of performance degradation can be calculated by comprehensively analyzing charge-discharge cycles, temperature history, and voltage changes. For engines or motors, the wear status of internal components can be indirectly measured through vibration sensors, temperature sensors, and oil condition sensors.

[0172] Importance coefficients can be set according to the impact each component has on the safety and operation of the vehicle. Since the brake system is directly related to safety, the highest coefficient (1.0) is applied, followed by the steering system (0.9), tires (0.8), battery / engine (0.7), suspension (0.6), air conditioning (0.3), and audio (0.1). These coefficients can be adjusted according to the type of vehicle, usage environment, legal requirements, etc.

[0173] Usage frequency is an indicator reflecting the actual usage of each component and can be calculated by combining daily mileage, driving environment (urban / highway / mountainous), driving patterns (frequency of sudden acceleration / braking), and weather conditions. For example, vehicles primarily driven in urban areas use their brakes and clutches frequently, while vehicles driven mainly on highways may experience heavy loads on their engines and tires.

[0174] Maintenance timing prediction is calculated based on current wear and wear progression rates, and a safety margin factor can be applied to allow for maintenance to be performed with sufficient margin. For example, if the current thickness of a brake pad is 5mm and the monthly average wear rate is 0.5mm, it can be predicted that it will take 4 months to reach the replacement threshold of 3mm. By applying a safety margin factor of 0.8, maintenance can be scheduled to be performed after 3.2 months.

[0175] Meanwhile, the processor (110) can apply path optimization and reset functions when controlled in autonomous driving mode.

[0176] In one embodiment, the processor (110) calculates a path score for a movement path according to the autonomous driving mode according to the following mathematical formula 9, and if the calculated path score is below a threshold value, the path can be reset.

[0177] [Mathematical Formula 9]

[0178] Route Score = Base Route Score × Real-time Traffic Correction × User Preference Correction

[0179] The basic route score can be calculated by combining distance, estimated travel time, road conditions, number of traffic signals, number of turns, etc. For example, if there are three routes from point A to point B, the basic score for each route can be calculated and compared. If the basic score of Route 1 (10 km, 20 minutes, 5 signals) is 80 points, the basic score of Route 2 (12 km, 18 minutes, 3 signals) is 85 points, and the basic score of Route 3 (8 km, 25 minutes, 8 signals) is 75 points, then Route 2 can be evaluated as the best.

[0180] Real-time traffic correction is a process of adjusting route scores to reflect current traffic conditions. Traffic information can be collected in real time from government traffic information centers, navigation companies, telecommunication companies, etc., and may include information such as average speeds by road, congested sections, accident locations, and construction zones. For example, if traffic congestion occurs on Route 2 and the estimated travel time increases from 18 minutes to 30 minutes, the score of that route can be lowered from 85 points to 70 points through real-time traffic correction.

[0181] User preference adjustment is the process of personalizing route scores by reflecting individual user preferences. For example, if User C prefers highways, bonus points can be assigned to routes that include highways, while if User D prefers scenic roads, the scores for routes that include riverside or mountain paths can be increased. Additionally, familiarity adjustments can be applied to routes frequently used by users by analyzing their past usage history.

[0182] If the route score falls below a threshold (e.g., 60 points), the system may automatically reset the route. Route reset occurs in real time, and the user may be provided with new route information along with a message such as, "We are guiding you to a faster route due to changes in traffic conditions." When the route is changed, detailed information regarding changes in estimated arrival time, whether additional costs will be incurred, and the reason for the route change may be provided.

[0183] Meanwhile, the disclosed embodiments may be implemented in the form of a recording medium that stores instructions executable by a computer. The instructions may be stored in the form of program code and, when executed by a processor, may generate a program module to perform the operation of the disclosed embodiments. The recording medium may be implemented as a computer-readable recording medium.

[0184] Computer-readable recording media include all types of recording media that store instructions that can be decoded by a computer. Examples include ROM (Read Only Memory), RAM (Random Access Memory), magnetic tape, magnetic disk, flash memory, optical data storage devices, etc.

[0185] As described above, the disclosed embodiments have been explained with reference to the attached drawings. Those skilled in the art will understand that the present disclosure may be practiced in forms different from the disclosed embodiments without changing the technical spirit or essential features of the present disclosure. The disclosed embodiments are illustrative and should not be interpreted restrictively. Explanation of the symbols

[0186] 1: IoT System 100: Device 200: User terminal

Claims

Claim 1 A memory storing at least one process for applying and verifying an IoT system to an autonomous shared vehicle; and a processor operating according to at least one process; wherein the processor manages the dispatch of a vehicle according to a user's request, collects status information of the vehicle dispatched to the user in real time and performs a remote diagnosis, and if an abnormality in the IoT system applied to the vehicle is detected according to the result of the remote diagnosis, switches the autonomous driving mode of the vehicle to another driving mode, and if the result of the remote diagnosis in the switched driving mode is detected, switches the driving mode of the vehicle back to the autonomous driving mode to control the vehicle to move to a pre-set safety zone and stop, and performs the remote diagnosis to detect whether an emergency situation has occurred, and if the occurrence of the emergency situation is detected, switches the driving mode of the vehicle to a remote driving mode to perform remote operation through the transmission and reception of control commands by an administrator, and performs the remote diagnosis to detect whether there is a failure in the communication status for the transmission and reception of control commands, and if the failure in the communication status is detected, switches the driving mode of the vehicle to an autonomous driving mode to control the vehicle to move to a pre-set safety zone and stop, wherein the risk level for determining whether an emergency situation has occurred is calculated according to the following mathematical formula 1, and the calculated risk level is greater than or equal to a threshold value An IoT device for an autonomous shared vehicle that detects the occurrence of the above emergency situation in the case of [Equation 1] Risk score = α × Traffic condition index + β × Weather influence + γ × Vehicle condition index + δ × Driver responsiveness Claim 2 An IoT device for an autonomous shared vehicle according to claim 1, wherein the processor performs the remote diagnosis to detect the vehicle's entry into a preset autonomous driving-unable zone, switches the vehicle's driving mode to a manual driving mode in the autonomous driving-unable zone to request manual operation by direct control of the user via a mobile app, performs the remote diagnosis to detect whether manual operation is performed in the autonomous driving-unable zone, and if manual operation is not detected, switches the vehicle's driving mode to an autonomous driving mode to control the vehicle to move to a preset safety zone and stop. Claim 3 delete Claim 4 delete Claim 5 An IoT device for an autonomous shared vehicle according to claim 2, wherein the processor calculates a mode switching score according to the following mathematical formula 2, switches from the autonomous driving mode to the remote driving mode if the mode switching score is 70 points or higher, switches from the remote driving mode to the autonomous driving mode if the mode switching score is 30 points or lower, and controls the vehicle to make an emergency stop if the mode switching score is 90 points or higher. [Mathematical Formula 2] Mode Switching Score = (Current Risk - Reference Risk) × Reliability Coefficient + Urgency Correction Value Claim 6 An IoT device for an autonomous shared vehicle according to claim 5, wherein the processor calculates a communication quality index for a plurality of communication channels for transmitting and receiving control commands according to the following mathematical formula 3, and selects one of the plurality of communication channels according to the following mathematical formula 4. [Mathematical Formula 3] Communication Quality Index = Σ(Signal Strength of Each Channel × Channel Weight) / Total Number of Channels [Mathematical Formula 4] Optimal Channel = argmax(Signal Strength × Stability × Bandwidth / Latency) Claim 7 An IoT device for an autonomous shared vehicle according to claim 6, wherein the processor predicts the time of occurrence of a communication failure according to the following mathematical formula 5, warns of switching to the autonomous driving mode if the predicted time is 30 seconds or less, and immediately switches to the autonomous driving mode if the predicted time is 10 seconds or less. [Mathematical Formula 5] Predicted time of communication failure = Current signal reduction rate × Terrain influence coefficient × Weather correction coefficient Claim 8 An IoT device for an autonomous shared vehicle according to claim 7, wherein the processor, upon confirming the temporary disembarkation of the user as a result of performing the remote diagnosis, checks whether the disembarkation area corresponds to a no-parking zone, and if the disembarkation area corresponds to a no-parking zone, switches the driving mode of the vehicle to an autonomous driving mode to control the vehicle to move within a preset radius for a preset time, and if the preset time has elapsed, controls the vehicle to park in a preset parking spot. Claim 9 An IoT device for an autonomous shared vehicle according to claim 8, wherein the processor sets a boarding and alighting location for the dispatched vehicle based on the user's current location, acquires the user's personal mobility information, sets the boarding and alighting location by reflecting the personal mobility information, and generates movement linkage information for moving from the user's current location to the boarding and alighting location through the personal mobility and provides it to the user. Claim 10 A method for controlling an IoT device to be installed in an autonomous shared vehicle for applying and verifying an IoT system comprises: a step of managing vehicle dispatch according to a user's request; a step of collecting status information of the vehicle dispatched to the user in real time and performing a remote diagnosis; a step of switching the autonomous driving mode of the vehicle to another driving mode if an abnormality in the IoT system applied to the vehicle is detected according to the result of the remote diagnosis; and a step of controlling the vehicle to move to a pre-set safety zone and stop by switching the driving mode of the vehicle back to the autonomous driving mode according to the result of the remote diagnosis in the switched driving mode; a step of detecting whether an emergency situation has occurred by performing the remote diagnosis; a step of performing remote operation through the transmission and reception of control commands by an administrator if the occurrence of the emergency situation is detected by switching the driving mode of the vehicle to a remote driving mode; and a step of detecting whether there is a defect in the communication status for the transmission and reception of control commands by performing the remote diagnosis. A control method for an IoT device for an autonomous shared vehicle, comprising: a step of, when a fault in the communication status is detected, switching the driving mode of the vehicle to an autonomous driving mode so that the vehicle moves to a preset safety zone and stops; wherein the step of detecting whether an emergency situation occurs comprises calculating a risk level for determining whether an emergency situation occurs according to the following mathematical formula 1, and detecting the occurrence of an emergency situation if the calculated risk level is greater than or equal to a threshold value. [Mathematical Formula 1] Risk Score = α × Traffic Condition Index + β × Weather Influence + γ × Vehicle Condition Index + δ × Driver Responsiveness

Images