CN115731652A

CN115731652A - Control method, control device, server and vehicle

Info

Publication number: CN115731652A
Application number: CN202111013067.5A
Authority: CN
Inventors: 邹琪; 彭帝; 杨志伟; 施银辉; 门逸飞
Original assignee: Beijing Qisheng Technology Co Ltd
Current assignee: Beijing Qisheng Technology Co Ltd
Priority date: 2021-08-31
Filing date: 2021-08-31
Publication date: 2023-03-03

Abstract

Disclosed are a control method, a control device, a server and a vehicle. And after the control request is received, combining the configuration information and the control instruction corresponding to the control request to generate a service instruction, and controlling the target vehicle through the service instruction. Therefore, the control instruction and the configuration information can be issued to the vehicle together, so that the vehicle can obtain the latest configuration along with the issuance of the control instruction, the time waste and the workload caused by upgrading central control are reduced, and meanwhile, a larger-scale vehicle set can be comprehensively covered on the premise of low cost.

Description

Control method, control device, server and vehicle

Technical Field

The invention relates to the technical field of vehicles, in particular to a control method, a control device, a server and a vehicle.

Background

Small vehicles such as bicycles, electric vehicles, and motorcycles are becoming major transportation means for short trips. Due to safety concerns for riders and the requirements of some cities, riders need to wear helmets while riding. Therefore, for the existing vehicle equipped with the helmet, the control flow of the helmet and/or the vehicle needs to be modified correspondingly according to different requirements.

No matter the vehicle purchased by the ordinary user or the shared vehicle, the configuration upgrading is required, and the common practice in the prior art is to write a new configuration instruction in the central control of the vehicle through wired connection or wireless connection, but on one hand, the original whole control program needs to be re-edited, which brings a great workload, and on the other hand, the new configuration instruction is written in the central control, which causes the problems of overlong whole time, untimely configuration, incomplete coverage and the like.

Disclosure of Invention

In view of this, an object of the embodiments of the present invention is to provide a control method, a control apparatus, a server, and a vehicle, so that the vehicle can obtain a latest configuration along with issuing of a control instruction, time waste and workload caused by upgrading central control are reduced, and a larger-scale vehicle set can be comprehensively covered on the premise of low cost.

In a first aspect, an embodiment of the present invention provides a control method, where the method includes:

receiving a control request for characterizing an operation that a user desires to be performed by a target vehicle;

generating a corresponding service instruction according to the control request, wherein the service instruction comprises configuration information and a control instruction corresponding to the control request, and the configuration information is a configuration parameter corresponding to the control request; and

and sending the service instruction to the target vehicle.

In some embodiments, the generating a corresponding service instruction according to the control request includes:

configuring the radio values of all the configuration items according to the control request to generate configuration information; and

and combining the configuration information and the corresponding control instruction to generate the service instruction.

acquiring configuration information in a configuration library according to the control request; and

In some embodiments, the control request includes a vehicle identification of the target vehicle;

wherein configuring the radio values of the configuration items according to the control request to generate configuration information comprises:

determining version information corresponding to the vehicle identification; and

and configuring the radio values of the configuration items according to the version information to generate configuration information.

wherein the configuring the radio values of the configuration items according to the control request to generate the configuration information includes:

determining address information corresponding to the vehicle identification; and

and configuring the radio values of the configuration items according to the address information to generate configuration information.

wherein the obtaining configuration information in a configuration library according to the control request includes:

and acquiring the configuration information in a configuration library according to the version information.

and acquiring the configuration information in a configuration library according to the address information.

In some embodiments, the configuration items include at least one of a lock control type, a control condition of a vehicle lock, a helmet verification enable, a helmet default identification, or a protocol configuration.

In some embodiments, the lock control types include a single-open type and a double-open type, the single-open type is a single-control helmet lock, and the double-open type is a helmet lock and a vehicle lock linkage control.

In some embodiments, the lock control condition includes at least one of:

before the helmet lock is unlocked, in response to detecting that the helmet is not in place, not unlocking the vehicle lock;

before the helmet lock is opened, the helmet is in place, and after the helmet lock is opened, the helmet is not in place, and the vehicle lock is opened;

the lock of the helmet is unlocked abnormally, and the lock of the vehicle is not unlocked; or

After the vehicle lock is unlocked, the helmet is in place, and the vehicle lock is locked.

In some embodiments, the protocol configuration includes at least one of a helmet in-position condition, a car return and also a helmet, and a helmet lock only being closed.

In some embodiments, the control request is a vehicle borrowing request, the control command is an unlocking command, and the configuration information includes:

the lock control type is a double-opening type;

lock control conditions; and

the protocol configuration includes a helmet in-position condition.

In some embodiments, the control request is a car return request, the control instruction is a lock closing instruction, and the configuration information includes:

performing helmet verification enabling; and

protocol configuration includes returning to the vehicle and also to the helmet.

In some embodiments, the control request is a helmet borrowing request, the control instruction is an unlocking instruction, and the configuration information includes:

the lock control type is a single-opening type.

In some embodiments, the control request is a helmet return request, the control instruction is a lock closing instruction, and the configuration information includes:

performing helmet verification enabling; and

the protocol is configured to turn off only the helmet lock.

In some embodiments, the method further comprises:

detecting whether a helmet bound with the target vehicle exists in a database after receiving a control request; and

sending a borrowing failure notification in response to the absence of a helmet bound to the target vehicle.

In some embodiments, the method further comprises:

and sending helmet warning information, wherein the helmet warning information is related information for prompting a user to wear a helmet.

In some embodiments, the method further comprises:

and receiving feedback information of the target vehicle, wherein the feedback information comprises at least one of helmet lock unlocking success information, helmet lock unlocking failure information, vehicle lock unlocking success information, vehicle lock unlocking failure information and lock unlocking failure reasons.

In a second aspect, an embodiment of the present invention provides a control method, where the method includes:

receiving a service instruction sent by a server, wherein the service instruction comprises configuration information and a control instruction corresponding to the control request, and the configuration information is a configuration parameter corresponding to the control request;

analyzing the service instruction to obtain the configuration information and the control instruction; and

and controlling the helmet lock and/or the vehicle lock according to the configuration information and the control instruction.

In some embodiments, the configuration information includes at least one of a lock control type, a control condition of a vehicle lock, a helmet verification enable, a helmet default identification, or a protocol configuration.

In some embodiments, the lock control condition includes at least one of:

before the helmet lock is unlocked, the helmet is in place, and after the helmet lock is unlocked, the helmet is not in place, and the vehicle lock is unlocked;

In some embodiments, said controlling a helmet lock and/or a vehicle lock according to said configuration information and control instructions comprises:

responding to the control instruction as an unlocking instruction, and controlling the helmet lock to perform self-checking to acquire the state of the helmet lock, wherein the configuration information comprises that the lock control type is a double-opening type, the lock control condition and a protocol configuration are helmet in-place conditions;

detecting whether the helmet is in place or not in response to the normal state of the helmet lockset;

controlling the helmet lock to open in response to the helmet being in place; and

and controlling the vehicle lock to be unlocked in response to the helmet lock being successfully unlocked.

In some embodiments, in response to the control instruction being a lock-off instruction, the configuration information including a helmet verification enable and protocol configuration being a vehicle return and helmet return, the controlling the helmet lock and/or the vehicle lock according to the configuration information and the control instruction comprising:

detecting whether the helmet is in place;

controlling a helmet lock to lock in response to the helmet being in position; and

and controlling the lock of the vehicle to be locked in response to the successful lock closing of the helmet lock.

In some embodiments, in response to the control instruction being an unlock instruction and the configuration information including a lock control type being a single-open type, controlling the helmet lock and/or the vehicle lock according to the configuration information and the control instruction comprises:

controlling the helmet lock to perform self-checking so as to acquire the state of the helmet lock;

detecting whether the helmet is in place or not in response to the normal state of the helmet lockset; and

and controlling the helmet lock to be unlocked in response to the helmet being in the position.

In some embodiments, in response to the control instruction being a lock-off instruction and the configuration information including a helmet verification enable, a helmet default identification, and a protocol configuration to only turn off the helmet lock, controlling the helmet lock and/or the vehicle lock according to the configuration information and the control instruction comprises:

detecting whether the helmet is in place; and

and controlling the helmet lock to lock in response to the helmet being in the position.

In some embodiments, the method further comprises:

in response to receiving helmet alert information, playing the helmet alert information;

the helmet warning information is related information for prompting a user to wear a helmet.

In some embodiments, the method further comprises:

and sending feedback information to a server, wherein the feedback information comprises at least one of helmet lock unlocking success information, helmet lock unlocking failure information, vehicle lock unlocking success information, vehicle lock unlocking failure information and lock unlocking failure reasons.

In a third aspect, an embodiment of the present invention provides a control apparatus, where the apparatus includes:

a control request receiving unit that receives a control request for characterizing an operation that a user desires a target vehicle to perform;

a service instruction synthesizing unit, configured to synthesize a corresponding service instruction according to the control request, where the service instruction includes configuration information and a control instruction corresponding to the control request, and the configuration information is a configuration parameter corresponding to the control request; and

and the service instruction sending unit is used for sending the service instruction to the target vehicle.

In a fourth aspect, an embodiment of the present invention provides a control apparatus, where the apparatus includes:

a service instruction receiving unit, configured to receive a service instruction sent by a server, where the service instruction includes configuration information and a control instruction corresponding to the control request, and the configuration information is a configuration parameter corresponding to the control request;

the analysis unit is used for analyzing the service instruction to acquire the configuration information and the control instruction; and

and the lock control unit is used for controlling a helmet lock and/or a vehicle lock according to the configuration information and the control instruction.

In a fifth aspect, an embodiment of the present invention provides a vehicle, including:

a helmet;

the helmet lock is arranged at a preset position of the vehicle and used for locking a helmet;

a vehicle lock for locking a vehicle; and

a memory for storing one or more computer program instructions, and a processor, wherein the one or more computer program instructions are executed by the processor to implement the method of the second aspect.

In a sixth aspect, an embodiment of the present invention provides a server, including a memory and a processor, the memory being configured to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement the method according to the first aspect.

In a seventh aspect, an embodiment of the present invention provides a computer program product, where the computer program product includes a computer program, and when the computer program runs on a computer, the computer executes the method described in the first aspect and the second aspect.

In an eighth aspect, the present invention provides a computer-readable storage medium on which computer program instructions are stored, the computer program instructions, when executed by a processor, implementing the method according to the first and second aspects.

According to the technical scheme of the embodiment of the invention, after the control request is received, the configuration information and the control instruction corresponding to the control request are combined to generate the service instruction, and the target vehicle is controlled through the service instruction. Therefore, the control instruction and the configuration information can be issued to the vehicle together, so that the vehicle can obtain the latest configuration along with the issuing of the control instruction, the time waste and the workload caused by upgrading central control are reduced, and meanwhile, a larger-scale vehicle set can be comprehensively covered on the premise of low cost.

Drawings

The above and other objects, features and advantages of the present invention will become more apparent from the following description of embodiments of the present invention with reference to the accompanying drawings, in which:

FIG. 1 is a schematic diagram of a control system of an embodiment of the present invention;

FIG. 2 is a schematic structural diagram of a vehicle according to an embodiment of the present invention;

fig. 3 is a flowchart of a control method of a server of an embodiment of the present invention;

FIG. 4 is a flow diagram of obtaining a business instruction, in accordance with one embodiment of the present invention;

FIG. 5 is a schematic diagram of a configuration library of an embodiment of the present invention;

fig. 6 is a schematic view of configuration information of a borrowing request according to an embodiment of the present invention;

FIG. 7 is a schematic structural diagram of a service instruction according to an embodiment of the present invention;

FIG. 8 is a flow diagram of a get service instruction according to another embodiment of the present invention;

fig. 9 is a schematic view of configuration information of a loan request of another embodiment of the present invention;

FIG. 10 is a schematic diagram of a first correspondence of an embodiment of the invention;

FIG. 11 is a schematic illustration of configuration information for a carriage return request according to an embodiment of the present invention;

FIG. 12 is a schematic illustration of configuration information requested by a helmet borrowing implementation of the present invention;

FIG. 13 is a schematic illustration of configuration information requested by a driver in accordance with an embodiment of the present invention;

fig. 14 is a flowchart of a control method of the vehicle of the embodiment of the invention;

fig. 15 is a flowchart of a method of controlling a borrowing service according to an embodiment of the present invention;

FIG. 16 is a flow chart of a helmet borrowing service according to an embodiment of the present invention;

FIG. 17 is a flow chart of a car return service of an embodiment of the present invention;

FIG. 18 is a flow chart of a helmet return service of an embodiment of the present invention;

fig. 19 is a schematic diagram of a control device of the server of the embodiment of the present invention;

fig. 20 is a schematic diagram of a control device of a vehicle of an embodiment of the invention.

Detailed Description

The present invention will be described below based on examples, but the present invention is not limited to only these examples. In the following detailed description of the present invention, certain specific details are set forth. It will be apparent to one skilled in the art that the present invention may be practiced without these specific details. Well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the present invention.

Further, those of ordinary skill in the art will appreciate that the drawings provided herein are for illustrative purposes and are not necessarily drawn to scale.

Meanwhile, it should be understood that, in the following description, the "circuit" refers to a conductive loop constituted by at least one element or sub-circuit through electrical connection or electromagnetic connection. When an element or circuit is referred to as being "connected to" another element or element/circuit is referred to as being "connected between" two nodes, it may be directly coupled or connected to the other element or intervening elements may be present, and the connection between the elements may be physical, logical, or a combination thereof. In contrast, when an element is referred to as being "directly coupled" or "directly connected" to another element, it is intended that there are no intervening elements present.

Unless the context clearly requires otherwise, throughout the description, the words "comprise", "comprising", and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is, what is meant is "including but not limited to".

In the description of the present invention, it is to be understood that the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. In addition, in the description of the present invention, "a plurality" means two or more unless otherwise specified.

FIG. 1 is a schematic diagram of a control system of an embodiment of the present invention. As shown in fig. 1, the control system of the embodiment of the present invention includes at least one server 1, at least one vehicle 2, and at least one user terminal 3. The embodiment of the present invention is described by taking an example in which the control system includes a server 1, a vehicle 2, and a user terminal 3.

In this embodiment, the server 1 may be an independent server, or may be a server cluster formed by a plurality of servers.

Further, the server 1 is a shared vehicle platform.

Specifically, the server 1 includes a data processing module 11 and a data storage module 12. The data processing module 11 is configured to process data, and may be implemented by a processor. The data storage module 12 is used for storing data, and may be implemented by a memory. Further, the data storage module 12 at least includes a database and a configuration library, wherein the database is used for storing the binding relationship between the helmet identifier and the vehicle identifier, and the configuration library is used for storing the configuration information.

In this embodiment, the vehicle 2 is a shared vehicle and can communicate with the server 1 in a wireless manner.

In the present embodiment, the user terminal 3 is a terminal device of a vehicle user.

Further, the user terminal 3 may be a mobile phone, a tablet computer, or other special-purpose device.

Further, fig. 2 is a schematic structural diagram of a vehicle according to an embodiment of the present invention. In the embodiment shown in fig. 2, the vehicle includes a processor 21, a memory 22, a communication unit 23, a helmet latch 24, and a vehicle latch 25.

In the present embodiment, the memory 22 is used for storing one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor 21 to implement the control method of the embodiment of the present invention.

In this embodiment, the communication unit 23 is configured to communicate with the server in a wireless manner.

Further, the communication unit 23 may be a GSM (Global System for Mobile Communications) module, a GPRS (General packet radio service) module, an eMTC (enhanced machine communication) module, an NB-IoT (Narrow Band Internet of Things) module, or the like.

In some embodiments, the vehicle further comprises a second communication unit for communicating with the user terminal.

Further, the second communication unit is a short-range wireless communication module.

For example, the second communication unit may be a bluetooth communication module and/or an NFC communication module.

Specifically, when the second communication unit is a bluetooth communication module, a two-dimensional code can be preset in each vehicle, a user opens a pre-installed application program through a user terminal, scans the two-dimensional code of the vehicle through the application program to acquire a bluetooth communication address of the vehicle, and then establishes bluetooth communication connection with the vehicle.

When the second Communication unit is an NFC (Near Field Communication) module, when a user wants to borrow a vehicle, the user terminal having an NFC function is brought close to the identification area of the vehicle, and a Communication connection between the vehicle and the user terminal is established through the NFC function.

In the present embodiment, a helmet lock 24 is provided at a predetermined position of the vehicle for locking the helmet to the vehicle.

In some embodiments, the helmet lock 24 is disposed within a basket of the vehicle for locking the helmet within the basket.

In the present embodiment, the vehicle lock 25 is used to lock the vehicle.

Further, the vehicle lock 25 may be implemented by an electronic horseshoe lock, an electronic band-type brake lock, or the like.

In an alternative implementation, the vehicle further comprises an identification unit 26, and correspondingly the helmet is provided with an electronic tag 28.

Further, the Identification unit 26 is a Radio Frequency Identification (RFID) reader, and the electronic tag 28 is an RFID tag having a unique identifier and used as a helmet identifier. Specifically, RFID is an automatic identification technology, which performs non-contact bidirectional data communication in a radio frequency manner, and reads and writes a recording medium (an electronic tag or a radio frequency card) in a radio frequency manner, thereby achieving the purpose of identifying an object and exchanging data. Therefore, when the helmet is placed at the corresponding position, the RFID reader can acquire the helmet identification by reading the tag.

Alternatively, a dynamic key may be adopted for matching between the RFID tag and the RFID reader, and the RFID tag and the RFID reader generate the dynamic key based on a predetermined algorithm. In particular, the algorithm for generating the dynamic key may be implemented using various existing technologies.

It should be understood that the identification unit 26 and the electronic tag 28 may be implemented in other ways, and the embodiment of the present invention is not limited thereto. For example, it may be implemented by NFC (Near Field Communication) technology. Specifically, NFC is developed by combining a wireless interconnection technology on the basis of an RFID technology. The NFC operation mode is divided into a passive mode and an active mode. An NFC initiator device (also called a master) in passive mode requires a power supply device, and the master uses the power of the power supply device to provide a radio frequency field and to transmit data to an NFC target device (also called a slave). The slave device does not generate a radio frequency field, so that a power supply device is not needed, the radio frequency field generated by the master device is converted into electric energy, the circuits of the slave device are powered, data sent by the master device are received, and the data of the slave device are transmitted back to the master device at the same speed by using a load modulation technology. The passive mode is called a passive mode because the slave device does not generate a radio frequency field in this operating mode, but passively receives a radio frequency field generated by the master device, and in this mode, the NFC master device can detect a contactless card or an NFC target device and establish a connection therewith. In the active mode, the initiator and target devices must actively generate the rf field when transmitting data to each other, and therefore, they are called active mode, and both of them need a power supply device to supply energy for generating the rf field. This communication mode is a standard mode of peer-to-peer network communication, and a very fast connection rate can be obtained.

In another alternative implementation, the vehicle comprises a sensor 27, and correspondingly the helmet is provided with a magnetic element 29.

Further, the sensor 27 is a hall sensor. In particular, a hall sensor is a magnetic field sensor made according to the hall effect. Specifically, there is a Hall semiconductor chip in the magnetic field, passing a constant current through the conductor chip. Under the action of Lorentz force, the electron current of the current is deflected to one side when passing through the Hall semiconductor, so that the conductor piece generates a potential difference, namely a Hall voltage. The Hall voltage changes along with the change of the magnetic field intensity, the stronger the magnetic field, the higher the voltage, the weaker the magnetic field, the lower the voltage, the small Hall voltage value, and the voltage can be amplified by an amplifier in the integrated circuit to be enough to output a stronger signal. The Hall integrated circuit can play a sensing role by changing the magnetic induction intensity. From this, when the helmet was put in the position that corresponds, magnetic element in the helmet can change magnetic induction, and then influences hall voltage, can detect the helmet through detecting hall voltage.

In yet another alternative implementation, the vehicle comprises an identification unit 26 and a sensor 27, and correspondingly the helmet is provided with an electronic tag 28 and a magnetic element 29. Thus, the identification of the helmet can be obtained by the identification unit 26, and whether the helmet is placed at the corresponding position can be detected by the sensor 27. The implementation of the identification unit 26, the electronic tag 28, the sensor 27 and the magnetic element 29 is as described above, and will not be described herein.

Thereby, it can be detected by the sensor 27 and/or the identification unit 26 whether the helmet is in place.

In some embodiments, set up the trigger detection circuit in helmet tool to lock for detect the position of the lockpin of helmet tool to lock, when the lockpin is in the position that helmet tool to lock was opened, generate helmet tool to lock and open signal transmission to the treater, when the lockpin is in the position that helmet tool to lock closed, generate helmet tool to lock and close signal transmission to the treater, from this, the state of helmet tool to lock can be acquireed to the treater.

In some embodiments, the vehicle is further provided with a playback unit for playing back information. For example:

when the helmet lock is successfully unlocked, the warning sound of successful unlocking of the helmet lock is played.

When the helmet is put in or taken out, a prompt tone for putting in or taking out the helmet is played, or a buzzing prompt tone with fixed time duration is used.

After the vehicle lock is successfully unlocked, if the helmet is not taken out, the helmet taking prompt tone is played. Such as "please get the helmet, ride safely". In particular, it may be played once every predetermined length of time (for example 5 seconds) until it is detected that the helmet is removed.

Further, the connection between the processor 21 and the communication unit 23, the helmet lock 24, the vehicle lock 25, the identification unit 26, and the sensor 27 may be implemented by a bus interface such as CAN (Controller Area Network), LIN (Local Interconnect Network), RS-485, UART (Universal Asynchronous Receiver/Transmitter), and the like. Among them, CAN is a serial communication protocol of ISO international organization for standardization. LIN (bus is a low-cost serial communication protocol based on UART/SCI (universal asynchronous receiver/transmitter/serial interface) and is mainly used for serial communication of sensors and controllers, RS-485 bus standard is a very wide two-way and balanced transmission standard interface used in industry (attendance, monitoring and data acquisition system) and supports multipoint connection, and UART is a universal serial data bus used for asynchronous communication, and the bus can realize full-duplex transmission and reception by two-way communication.

Further, the Processor 21 may be implemented by an MCU (Microcontroller Unit), a PLC (Programmable Logic Controller), an FPGA (Field-Programmable Gate Array), a DSP (Digital Signal Processor), or an ASIC (Application Specific Integrated Circuit).

Fig. 3 is a flowchart of a control method of a server according to an embodiment of the present invention. As shown in fig. 3, the method for controlling a server according to the embodiment of the present invention includes the following steps:

and step S110, receiving a control request.

In this embodiment, the server receives a control request, where the control request may be from a user terminal or from the server, and is different in different service scenarios.

Further, the control request is used to characterize an operation that the user desires the target vehicle to perform. For example, the control request may be a vehicle borrowing request, a vehicle returning request, a helmet borrowing request, a helmet returning request and the like, wherein the vehicle borrowing request represents that an operation that the user desires to be performed by the target vehicle is to open a vehicle lock, the vehicle returning request represents that an operation that the user desires to be performed by the target vehicle is to close the vehicle lock, the helmet borrowing request represents that an operation that the user desires to be performed by the target vehicle is to open a helmet lock, and the helmet returning request represents that an operation that the user desires to be performed by the target vehicle is to close the vehicle lock.

For the vehicle borrowing service, a user can obtain the vehicle identification by scanning the vehicle two-dimensional code or approaching the identification area of the vehicle through a mobile phone with an NFC function, and then sends a control instruction to a server. Specifically, when a user borrows a vehicle by scanning a two-dimensional code of the vehicle, the two-dimensional code is preset in each vehicle, when the user needs to borrow the vehicle, a pre-installed application program is opened, the two-dimensional code of the vehicle is scanned by the application program to obtain a vehicle identifier, and a vehicle borrowing request is sent to a server, wherein the vehicle borrowing request comprises the vehicle identifier. When the vehicle borrowing is carried out through NFC, each vehicle is provided with an NFC module in advance, when a user needs to borrow the vehicle, a user terminal with an NFC function is close to an identification area of the vehicle, then NFC communication connection is established with the vehicle, a vehicle identification is obtained through NFC communication, and a vehicle borrowing request is sent to a server, wherein the vehicle borrowing request comprises the vehicle identification.

It should be understood that the two vehicle lending manners are only two examples provided by the embodiment of the present invention, which is not limited in this respect, and the user terminal borrows a vehicle in other manners and is also applicable to the technical solution of the embodiment of the present invention.

It should also be understood that the above description is given by taking the example of the user terminal sending the vehicle borrowing request as an example, but the embodiment of the present invention is not limited thereto, and the vehicle borrowing request may also be sent by the vehicle. Specifically, when a user borrows a vehicle by scanning a two-dimensional code of the vehicle, the two-dimensional code is preset in each vehicle, when the user borrows the vehicle, a pre-installed application program is opened, the two-dimensional code of the vehicle is scanned by the application program to obtain a Bluetooth communication address of the vehicle, bluetooth communication connection is further established with the vehicle, an unlocking instruction is sent to the vehicle through Bluetooth communication, and after the vehicle receives the unlocking instruction sent by the user terminal, a vehicle borrowing request is generated and sent to the server. Or when the user borrows the vehicle through NFC, the NFC modules are arranged in advance on each vehicle, when the user borrows the vehicle, the user terminal with the NFC function is close to the identification area of the vehicle, then the MFC communication connection is established with the vehicle, an unlocking instruction is sent to the vehicle through NFC communication, and the vehicle sends a vehicle borrowing request to the server.

The vehicle returning service is carried out on the premise that the vehicle is subjected to the vehicle borrowing service before. When the user finishes riding and needs to return the bicycle, triggering a bicycle returning control through an application program of the user terminal so as to send a bicycle returning request to the server; or when the vehicle detects that the helmet lock is triggered or the vehicle lock is triggered, a vehicle returning request is generated by the vehicle and sent to the server.

For the helmet borrowing service, when a user needs to borrow the helmet of a vehicle in use, or when the user only borrows the helmet for an idle vehicle and does not borrow the vehicle, the user triggers a helmet borrowing control through an application program of the user terminal, and the user terminal sends a helmet borrowing request to the server.

For the helmet returning service, when the user needs to continue using the vehicle and does not need to use the helmet for the vehicle being used, or when the user needs to return the helmet borrowed from other vehicles to the idle vehicle for the idle vehicle without the helmet, the user terminal triggers a helmet returning control through an application program of the user terminal, and the user terminal sends a helmet returning request to the server.

It should be understood that the above-listed triggering manners of the service request are only examples provided in the embodiment of the present invention, and the embodiment of the present invention does not limit the triggering manners of the service request.

And step S120, generating a corresponding service instruction according to the control request.

In this embodiment, after receiving a control request, a server generates a corresponding service instruction according to the control request, where the service instruction includes configuration information and a control instruction corresponding to the control request.

In an alternative implementation manner, a process of generating the service instruction by the server is shown in fig. 4, and includes the following steps:

and step S121, configuring the radio values of the configuration items according to the control request to generate configuration information.

In this embodiment, the configuration information is a configuration parameter corresponding to the control request. Further, the configuration information is instructions executable by a processor of the vehicle.

In particular, fig. 5 shows various configuration items and their corresponding radio values. In the embodiment shown in fig. 5:

a01: the lock control types comprise three single selection values, namely, only starting the helmet lock, only starting the vehicle lock, and checking the helmet lock, and starting the vehicle lock.

The helmet lock is suitable for the scene that a user only borrows a helmet.

For only unlocking the vehicle lock and verifying the helmet lock, when a user borrows the vehicle, only the vehicle lock is unlocked, the helmet lock is not unlocked, but the helmet lock needs to be verified.

The lock for the front helmet and the lock for the driving vehicle are suitable for scenes that a user borrows a vehicle and a helmet and the user needs to wear the helmet.

Further, for convenience of description, the following description is given by taking the lock control type including a single-opening type and a double-opening type as an example, wherein the single-opening type is an individually controlled helmet lock, that is, only a helmet lock is opened, the double-opening type is a helmet lock and a vehicle lock linkage control, that is, only a vehicle lock is opened, and the helmet lock is verified, and the helmet lock is opened, and the vehicle lock is opened.

A02, A03, A04 and A05 are control conditions of the vehicle lock. The lock control type can be a helmet lock, and the lock can be used as a control condition of the vehicle lock when the vehicle lock is unlocked.

A02: no helmet and no vehicle. The vehicle latch is not unlocked in response to detecting that the helmet is not in place before the helmet latch is unlocked.

A03: the helmet lock is unlocked abnormally, and the vehicle cannot be used. When the lock of the helmet is abnormally unlocked, the lock of the vehicle is not unlocked.

A04: the lock is successfully unlocked, and the helmet can be taken. Before the helmet lock is unlocked, the helmet is in place, and after the helmet lock is unlocked, the helmet is not in place, and the vehicle lock is unlocked.

A05: the unlocking is successful, and the self-locking is not realized. After the helmet lock and the vehicle lock are unlocked, the helmet is detected not to be taken, and the vehicle lock is controlled to be locked. The single value is 0-65536 seconds, namely, the preset time can be set to any value between 0-65536 seconds, and after the helmet lock and the vehicle lock are successfully unlocked, when the helmet is not taken for a preset time, the vehicle lock is controlled to be locked.

A06: the helmet identification defaults to fill 00. The helmet identification is populated with all 0's by default so that the vehicle does not verify the helmet identification when verifying the helmet.

A07: and (4) carrying out verification enabling. And the method is used for triggering execution of a helmet returning verification process.

A08: and (5) configuring a protocol. Comprises helmet in-position condition, vehicle returning, helmet returning and helmet only closing lock.

For the in-place condition of the helmet, the lock control type is a starting helmet lock, and when a vehicle lock is started, the lock can be used for judging whether the helmet is in place.

And for returning the vehicle and the helmet, the condition of returning the vehicle can be used when the user returns the vehicle.

For only closing the helmet lock, the lock can be applied to the scene that the user only borrows the helmet to return the helmet, or does not need to wear the helmet during riding.

Therefore, the server can select the corresponding configuration item as a candidate configuration item under different service scenes, generate a corresponding control instruction, and combine the control instruction and the candidate configuration item to obtain the service instruction.

It should be noted that the configuration items and the corresponding radio values shown in fig. 5 are only an example of the embodiment of the present invention, and the embodiment of the present invention does not limit the specific configuration, and the specific configuration may be set correspondingly according to the function of the vehicle, the function of the helmet, and the actual control requirement.

Further, the server configures the radio values of the configuration items according to the control request to generate configuration information. Specifically, it is assumed that, for a borrowing request, the settings need to be made as follows:

a01: the lock control type is a lock for a helmet and a lock for a vehicle.

A02: no helmet and no vehicle.

A03: the helmet lock is unlocked abnormally, and the vehicle cannot be used.

A04: the lock is successfully unlocked, and the helmet can be taken.

A05: the unlocking is successful, the self-locking is not taken, and the time is 10 seconds.

A08: the protocol is configured for a helmet in-place condition.

The server generated configuration information is shown in fig. 6.

And step S122, combining the configuration information and the corresponding control instruction to generate the service instruction.

In this embodiment, the server generates the service instruction according to the combined configuration information and the corresponding control instruction.

Further, fig. 7 is a schematic structural diagram of a service instruction according to an embodiment of the present invention, and in the embodiment shown in fig. 7, the service instruction includes a configuration information portion and a control instruction portion, where the control instruction portion is used to indicate an operation to be performed, such as unlocking or locking. The configuration information part is used for indicating specific processes, such as lock control types, control conditions of vehicle locks, helmet verification enabling, helmet default identification or protocol configuration and the like.

In another alternative implementation, a process of generating a service instruction by a server is shown in fig. 8, and includes the following steps:

and step S121', configuration information is obtained in a configuration library according to the control request.

In this embodiment, the server obtains the configuration information from the configuration library according to the control request.

Further, the configuration library includes a plurality of configuration items and corresponding radio values, and reference may be made to fig. 5 in particular.

Specifically, it is assumed that, for a borrowing request, the settings need to be made as follows:

a01: the lock control type is a lock for a helmet and a lock for a vehicle.

A02: no helmet and no vehicle.

A03: the helmet lock is unlocked abnormally, and the vehicle cannot be used.

A04: the lock is successfully unlocked, and the helmet can be taken.

A08: the protocol is configured for a helmet in-place condition.

The server generated configuration information is shown in fig. 9.

It should be noted that although the configuration information shown in fig. 9 and the configuration information shown in fig. 6 have different formats, the contents are the same, and the difference is that the configuration information in fig. 6 includes unnecessary configuration items, for example, a06 and a07, but the radio values of these unnecessary configuration items are "no". And only the required configuration items are included in the configuration information shown in fig. 9.

Step S122', merging the configuration information and the corresponding control instruction to generate the service instruction.

Thus, the server can obtain the service instruction.

Further, as for the above step S121 and step S121', which configuration items can be specifically set for each control request. And selectively and correspondingly configuring a part of vehicles according to the requirements of different cities and different application scenes. When the server receives the control request, whether the configuration information corresponding to the vehicle identification exists or not is judged firstly, and if yes, the corresponding configuration information is obtained. If not, the current processing flow is executed, for example, the server only sends a control command to the vehicle. The embodiment of the present invention is described only for the case where there is configuration information. The specific method for acquiring the configuration information may be implemented in various ways.

In an optional implementation manner, the server obtains a first corresponding relationship between the vehicle identifier and the configuration information in advance, and the server determines whether the configuration information corresponding to the vehicle identifier exists according to the first corresponding relationship. Taking the first correspondence shown in fig. 10 as an example, for example, assuming that the vehicle identifier of the target vehicle is id002, the configuration information corresponding to the vehicle identifier is config01, where config01 may include one or more of a01-a 08. For another example, assuming that the vehicle identification of the target vehicle is id220, there is no configuration information corresponding to the vehicle identification. Therefore, when a certain batch of vehicles need to be configured, the staff only need to add the configuration information and the corresponding vehicle identifications in the server in advance.

In another optional implementation manner, the server obtains address information of the target vehicle according to the vehicle identifier, and determines whether configuration information corresponding to the vehicle identifier exists according to the address information. The address information may be a delivery address of the vehicle, or a location address of the vehicle or the user terminal obtained in real time. Therefore, different configurations can be carried out according to the management requirements of different cities. For example, assuming city C1 requires that a helmet must be worn while riding, a corresponding configuration may be to unlock the vehicle latch after detecting that the helmet is taken, and not unlock the vehicle latch if the helmet is not taken. For another example, if the city C2 does not require to wear a helmet when riding, the corresponding configuration may be that the helmet lock and the vehicle lock are controlled separately, and the user may freely select whether to wear the helmet.

In yet another optional implementation manner, the server obtains version information of the target vehicle according to the vehicle identifier, and determines whether configuration information corresponding to the vehicle identifier exists according to the version information. Specifically, assuming that the version of the currently released vehicle is version 1.0, the configuration of the vehicle is controlled by a helmet lock and a vehicle lock respectively, and a user can freely select whether to wear the helmet or not. However, according to the requirements of superior management, vehicles in a certain city must wear a helmet to ride. Thus, the staff can mark the vehicle identification of the vehicle in the city as version 2.0, and the corresponding configuration can be that the vehicle lock is unlocked after the helmet is detected to be taken, and the vehicle lock is not unlocked if the helmet is not taken.

Therefore, the system can be selectively configured correspondingly to a part of vehicles according to the requirements of different cities and practical application scenes. And after receiving the control request, the server judges whether the configuration information corresponding to the vehicle identification exists or not.

Further, the control request comprises a vehicle borrowing request, a vehicle returning request, a helmet borrowing request and a helmet returning request. The configuration information obtained by the server is different for different control requests.

For a borrowing request, the corresponding configuration information may be as shown in fig. 6 or fig. 9, including:

a01: the lock control type is a double-opening type, namely only a vehicle lock is opened, a helmet lock is checked or opened, and the vehicle lock is opened.

The lock control conditions specifically comprise one or more of A02, A03, A04 and A05, and the protocol configuration comprises helmet in-position conditions. Wherein, the lock control condition comprises at least one of the following: before the helmet lock is unlocked, in response to detecting that the helmet is not in place, not unlocking the vehicle lock; before the helmet lock is unlocked, the helmet is in place, and after the helmet lock is unlocked, the helmet is not in place, and the vehicle lock is unlocked; the lock of the helmet is unlocked abnormally, and the lock of the vehicle is not unlocked; or after the vehicle lock is unlocked, the helmet is in place after the preset time (10 seconds), and the vehicle lock is locked.

A08, the protocol is configured to be in-position in the helmet. Specifically, the in-position condition of the helmet can be specifically set according to actual conditions, and for example, the in-position condition of the helmet can include at least one of the following: the output signal of the sensor indicates that the helmet is in place, the electronic tag is detected by the identification unit, and the electronic tag detected by the identification unit is consistent with the electronic tag stored in advance.

For the car return request, the corresponding configuration information is shown in fig. 11, and includes:

a07: and (4) performing helmet verification enabling. Wherein the vehicle may perform helmet verification under a trigger of a helmet verification enable. For example, whether the output signal of the detection sensor indicates that the helmet is in place, whether the detection identification unit acquires the electronic tag, whether the electronic tag detected by the detection identification unit is consistent with a pre-stored electronic tag, and whether the helmet lock is locked are detected.

And A08, configuring the protocol to return to the vehicle and also to helmet. When the protocol is configured to return the vehicle and the helmet is returned, the vehicle controls the lock of the helmet to be locked and controls the lock of the vehicle to be locked.

For the helmet borrowing request, the corresponding configuration information is shown in fig. 12, and includes:

a01: the lock control type is a single-opening type, and the single-opening type is only a helmet lock.

Meanwhile, other configuration items are invalid.

For the helmet return request, the corresponding configuration information is shown in fig. 13, and includes:

a07: and (4) carrying out verification enabling. Wherein the vehicle may perform helmet verification under a trigger of a helmet verification enable. For example, whether the output signal of the sensor indicates that the helmet is in place or not, whether the electronic tag is acquired by the detection and identification unit or not, whether the electronic tag detected by the detection and identification unit is consistent with a pre-stored electronic tag or not, and whether the lock of the helmet is locked or not are detected.

A08: the protocol is configured to turn off only the helmet lock.

Therefore, through the configuration, the server can acquire corresponding configuration information for different services.

It should be understood that only the required configuration items are shown in the configuration information shown in fig. 11 to 13, but this is not limited in this embodiment of the present invention, and the configuration information may also include the unnecessary configuration items, and correspondingly, the radio value of the unnecessary configuration items is set to "no".

It should be further understood that the configuration information shown in fig. 6, 9, and 11 to 13 is only one example of the embodiment of the present invention, and the configuration items of each service are not limited in the embodiment of the present invention, and may be specifically set according to actual situations. Meanwhile, the embodiment of the present invention is not limited to the four service scenarios listed above, and the technical solution of the embodiment of the present invention is also applicable to other service scenarios.

And step S130, sending the service instruction to the target vehicle.

In this embodiment, the server sends the service instruction to the target vehicle, so that the target vehicle executes a corresponding service process according to the service instruction.

According to the embodiment of the invention, after the control request is received, the configuration information and the control instruction corresponding to the control request are combined to generate the service instruction, and the target vehicle is controlled through the service instruction. Therefore, the control instruction and the configuration information can be issued to the vehicle together, so that the vehicle can obtain the latest configuration along with the issuance of the control instruction, the time waste and the workload caused by upgrading central control are reduced, and meanwhile, a larger-scale vehicle set can be comprehensively covered on the premise of low cost.

Further, referring to fig. 14, a method for a vehicle to execute a corresponding service process according to a service instruction includes the following steps:

and step S210, receiving a service instruction sent by the server.

Step S220, analyzing the service instruction to obtain configuration information and a control instruction.

And step S230, controlling a helmet lock and/or a vehicle lock according to the configuration information and the control instruction.

In this embodiment, after the vehicle receives the service instruction, the vehicle analyzes the service instruction to obtain corresponding configuration information and a control instruction, and controls the helmet lock and/or the vehicle lock according to the configuration information and the control instruction.

According to the embodiment of the invention, after the control request is received, the configuration information and the control instruction corresponding to the control request are combined to generate the service instruction, and the target vehicle is controlled through the service instruction. Therefore, the control instruction and the configuration information can be issued to the vehicles together, so that the vehicles can obtain the latest configuration in real time, the time waste and the workload caused by upgrading central control are reduced, and meanwhile, each vehicle can be comprehensively covered.

Further, with the control system of the embodiment of the present invention, a user may implement a car borrowing service, a car returning service, a helmet borrowing service, a helmet returning service, and the like, and the following description is respectively provided for different services of vehicle processing.

Fig. 15 is a flowchart of a method for controlling a lending service according to an embodiment of the present invention. In the embodiment shown in fig. 15, the method for controlling the borrowing service of the vehicle includes the steps of:

and step S301, receiving a service instruction.

Step S302, whether the service instruction comprises configuration information is detected.

As described above, the service command sent by the server may include only the control command, or may include the configuration information and the control command. Therefore, after the vehicle receives the service instruction sent by the server, the vehicle analyzes the service instruction and detects whether the service instruction comprises configuration information.

If there is no configuration information, the service command only includes a control command, and the process proceeds to step S400.

In step S400, the vehicle executes the control command according to the existing control logic. For example, the vehicle may execute control instructions according to a program pre-stored in memory.

If there is configuration information, the process proceeds to step S303.

And step S303, detecting the control type of the helmet lockset.

In this embodiment, if the received service instruction has configuration information, the helmet lock control type in the configuration information is detected. As mentioned above, the helmet lock control types can be divided into two types, one is a single-open type, and the other is a double-open type.

And responding to the helmet lock control type being a single-opening type, and entering the step S500.

In step S500, the vehicle executes a single-start flow. The specific implementation is as described in fig. 16.

And responding to the helmet lock control type being a double-opening type, and entering the step S304.

And S304, self-checking the helmet lockset.

In this embodiment, if the helmet lock control type is a double-open type, helmet lock self-checking is performed.

Further, helmet tool to lock self-checking is used for detecting helmet tool to lock, for example, to helmet tool to lock circular telegram back, through the inside circuit of helmet tool to lock, whether the voltage of detecting each check point is normal. And/or detecting the state of a locking part of the helmet lock, namely whether the locking part is in a locking state or an opening state, and the like.

And step S305, detecting a double-opening type.

As described above, the double-open type includes two types, one is a lock for only opening a vehicle, a lock for checking a helmet, and the other is a lock for opening a helmet, and a lock for opening a vehicle.

And responding to the double-opening type that only the vehicle lock is unlocked, verifying the helmet lock, and entering the step S312.

In response to the double-open type being the helmet lock and the vehicle lock being unlocked, the process proceeds to step S306.

And step S306, whether the self-check is passed or not.

As described above, step S304 performs self-checking on the helmet lock, and detects whether the self-checking on the helmet lock passes or not.

In response to the self-check passing, step S307 is performed.

In response to the self-test failing, step S314 is performed.

And step S307, detecting whether the helmet is in place.

In the embodiment, whether the helmet is in place or not is judged according to the helmet in-place condition in the configuration information. Wherein the helmet in-position condition may be at least one of: the output signal of the sensor indicates that the helmet is in place, the identification unit acquires the electronic tag, and the electronic tag detected by the identification unit is detected to be consistent with the electronic tag stored in advance.

In response to the helmet being in position, step S308 is entered.

In response to the helmet not being in place, the process proceeds to step S314.

And S308, controlling the helmet lockset to be unlocked.

In this embodiment, the vehicle generates an unlock signal of the helmet lock to control the helmet lock to unlock.

And S309, detecting whether the helmet lockset is successfully unlocked.

In response to the helmet lock being successfully unlocked, the process proceeds to step S310.

In response to the helmet lock being unlocked unsuccessfully, the process proceeds to step S316.

And step S310, controlling the vehicle lock to be unlocked.

In this embodiment, after the helmet lock is successfully unlocked, the vehicle generates an unlocking signal of the vehicle lock to control the vehicle lock to be unlocked.

And step S311, returning information of successful borrowing and successful unlocking of the helmet lock.

In this embodiment, after the vehicle lock is unlocked, the vehicle returns the information of successful vehicle borrowing and successful unlocking of the helmet lock to the server.

Therefore, through the steps S301 to S311, the vehicle lock can be unlocked after the helmet lock is unlocked, so that the user can borrow the helmet and the vehicle at the same time.

Further, in step S306 or step S307, if the self-checking of the helmet lock fails, or if the self-checking passes but the helmet is not in place, the process goes to step S314.

Step S314, whether A02 is configured or not is detected.

In this embodiment, if the self-check of the helmet lock fails, or the self-check of the helmet lock passes but the helmet is not in place, which indicates that the helmet cannot be lent or the helmet is not in place, the vehicle detects whether the configuration information includes a02, where a02 is no helmet and is not available for the vehicle, i.e., before the helmet lock is unlocked, the vehicle lock is not unlocked in response to detecting that the helmet is not in place.

In response to the configuration information including a02, which indicates that the vehicle cannot be borrowed, the process proceeds to step S315.

In response to the fact that a02 is not included in the configuration information, it is indicated that the vehicle can be borrowed, and the process proceeds to step S318.

And step S315, returning that the car borrowing fails, unlocking the helmet lock fails and no helmet exists.

As described above, if the vehicle detects that there is no helmet and a02 is provided, it is impossible to borrow the vehicle, and thus, the vehicle lock is not unlocked. Meanwhile, information such as vehicle borrowing failure, helmet lockset unlocking failure and no helmet is fed back to the server.

Therefore, through the steps S301 to S311 and the steps S314 to S315, the vehicle lock is not unlocked when no helmet is arranged, and the situation that a user rides and does not wear the helmet is reduced through the configuration A02.

Further, as described above, in step S309, if the helmet lock fails to be unlocked, the process proceeds to step S316.

Step S316, detecting whether the configuration information includes a03.

In this embodiment, if the helmet lock fails to be unlocked, it is detected whether a03 is included in the configuration information. Wherein, A03 is that the helmet lock is unlocked abnormally and the vehicle cannot be used.

If a03 is located, indicating that the vehicle is not available, the process proceeds to step S317.

If A03 is not configured, the vehicle availability is indicated, and the process proceeds to step S318.

Step S317, the returning vehicle borrowing fails, and the helmet lock is unlocked abnormally.

In this embodiment, if the helmet lock fails to be unlocked, the configuration information includes a03. And feeding back the borrowing failure to the server, and meanwhile, determining the failure reason: the helmet lock is unlocked abnormally and is sent to the server together.

Therefore, through the steps S301 to S311 and the steps S316 to S317, the vehicle lock is not unlocked when the helmet lock is abnormally unlocked through the configuration A03, and the occurrence of the situation that a user rides and does not wear the helmet is reduced.

Further, as described above, in step S314, a02 does not exist in the configuration information, or in step S316, a03 does not exist in the configuration information, and the process proceeds to step S318.

And step S318, unlocking the vehicle lock.

In this embodiment, when the vehicle detects that there is no helmet and there is no configuration a02, or detects that there is a helmet unlocking abnormality and there is no configuration a03, it indicates that although the helmet lock has failed to unlock, the vehicle can still be borrowed, and thus the vehicle lock is controlled to unlock.

And step S319, returning that the car borrowing is successful, and unlocking the helmet lock fails.

Thus, through the steps S301 to S311 and the steps S314 to S319, it is possible to apply to the lending in different scenes by selecting whether to configure a02 or a03. For example, assuming that a helmet must be worn to cycle, the corresponding a02 and a03 are configured, and if a helmet is not worn, the corresponding a02 and a03 are not configured.

Through the steps S301 to S311 and the steps S314 to S319, the unlocking logic when the double-open type is "head-helmet lock and vehicle lock" is unlocked "can be realized.

Further, as described above, in step S305, if the double-open type is "drive only vehicle lock and verify helmet lock", it proceeds to step S312.

Step S312, whether the self-check passes.

As described above, step S304 performs self-checking on the helmet lock, and detects whether the self-checking on the helmet lock passes.

In response to the self-check passing, step S313 is performed.

In response to the self-test failing, step S314 is performed.

And step S313, detecting whether the helmet is in place.

In the embodiment, whether the helmet is in place is judged according to the helmet in-place condition in the configuration information. Wherein the helmet in-position condition may be at least one of: the output signal of the sensor indicates that the helmet is in place, the identification unit acquires the electronic tag, and the electronic tag detected by the identification unit is detected to be consistent with the electronic tag stored in advance.

In response to the helmet being in position, the process proceeds to step S318.

Further, the implementation manners of step S314 to step S315 and step S318 to step S319 are as described above, and are not described herein again.

Therefore, through the steps S301 to S305, the steps S312 to S315 and the steps S318 to S319, the helmet can be verified before the vehicle lock is unlocked. Meanwhile, the verification result can be configured by selecting whether to configure a02 or a03. For example, if only the verification result is obtained, but the verification result does not affect the car, a02 and a03 are not configured. If the verification fails, the disabled vehicles are configured A02 and A03.

It should be noted that, steps S301 to S311 and steps S314 to S319 are unlocking logics for "start helmet lock and unlock vehicle lock" in the double-opening type, and at this time, after the helmet lock is unlocked, the vehicle lock is unlocked. And S301-step S305, step S312-step S315 and step S318-step S319 are in a double-opening type of 'only starting the vehicle lock and checking the helmet lock', and at this time, only the vehicle lock is started without starting the helmet lock.

According to the embodiment of the invention, after the control request is received, the configuration information and the control instruction corresponding to the control request are combined to generate the service instruction, and the target vehicle is controlled through the service instruction. Therefore, the control instruction and the configuration information can be issued to the vehicle together, so that the vehicle can obtain the latest configuration along with the issuing of the control instruction, the time waste and the workload caused by upgrading central control are reduced, and meanwhile, a larger-scale vehicle set can be comprehensively covered on the premise of low cost.

Further, as described above, in step S302, if it is detected that the service command does not include configuration information, only the control command is included, and step S400 is performed to execute a single-open process, that is, a helmet-attaching service.

Specifically, fig. 16 is a flowchart of a helmet borrowing service according to an embodiment of the present invention. The single-opening process in fig. 16 is used for single-opening helmet locks, and is mainly applied to helmet borrowing businesses, for example, a user only borrows a helmet, or a user borrows a helmet during riding. Correspondingly, the configuration information sent by the server may be as shown in fig. 12. The method specifically comprises the following steps:

and S501, performing self-checking on the helmet lockset.

In this embodiment, if the helmet lock control type is a single-open type, the helmet lock self-check is performed.

Step S502, whether the self-check is passed or not.

As described above, step S501 performs self-checking on the helmet lock, and detects whether the self-checking on the helmet lock passes or not.

In response to the self-check passing, step S503 is performed.

In response to the failure of the self-test, step S506 is performed to send a failure of unlocking the helmet lock to the server, and the failure reason is that the self-test is failed.

And step S503, controlling the helmet lockset to be unlocked.

And step S504, detecting whether the helmet lockset is successfully unlocked.

And responding to the helmet lock opening success, and entering the step S505.

In response to the helmet lock opening failure, step S507 is performed, and the helmet lock opening failure and the failure reason are sent to the server.

And step S505, returning the information of successful helmet borrowing.

In this embodiment, the vehicle returns the helmet borrowing success information to the server.

Therefore, the lock is configured to control the single-opening type, and the independent helmet borrowing can be realized.

Fig. 17 is a flowchart of a car return service according to an embodiment of the present invention. The embodiment shown in fig. 17 is mainly applied to a car returning service, and in a car borrowing service corresponding to the car returning service, a user borrows a helmet. Correspondingly, the configuration information in the service command issued by the server may be as shown in fig. 11. The method specifically comprises the following steps:

step S601, receiving a service instruction.

In this embodiment, the vehicle receives a service instruction sent by the server, and parses the service instruction to obtain configuration information and a control instruction, where the configuration information includes a07 return helmet verification enable and a08 protocol configuration for returning to the vehicle and returning to the helmet as shown in fig. 11.

Wherein A07 further enables a helmet verification for triggering the vehicle to perform steps S602-S611 as follows.

And step S602, returning the vehicle and performing helmet mounting.

In the present embodiment, the a08 protocol in the configuration information acquired by the vehicle is configured as a return to the vehicle and also as a helmet.

Step S603, detecting whether the helmet is in place.

In the embodiment, the vehicle determines whether the helmet is in place according to the helmet in-place condition acquired in advance. Wherein the helmet in-position condition may be at least one of: the output signal of the sensor indicates that the helmet is in place, the identification unit acquires the electronic tag, and the electronic tag detected by the identification unit is detected to be consistent with the electronic tag stored in advance.

In response to the helmet being in position, step S604 is entered.

In response to the helmet not being in place, the process proceeds to step S609, a return failure message is sent to the server, the helmet lock is failed to be closed, and the failure reason is no helmet.

And step S604, controlling the helmet lock to be closed.

In this embodiment, the vehicle generates a close signal of the helmet lock to control the helmet lock to close.

And step S605, detecting whether the helmet lockset is successfully closed.

In response to the helmet lock being successfully closed, the process proceeds to step S606.

In response to the failure of closing the helmet lock, the method proceeds to step S610, and information of a vehicle return failure, failure of closing the helmet lock, and a failure reason is sent to the server as an instruction reason.

And step S606, executing a vehicle returning process.

In this embodiment, if the helmet lock is successfully closed, the unlocking process is performed.

The embodiment of the invention does not limit the specific implementation mode of the vehicle returning process and can be implemented by various existing modes.

And step S607, whether the vehicle returning is successful.

In response to the return success, the process proceeds to step S608.

In response to the car return failure, the process proceeds to step S611, where the car return failure and the successful helmet lock closing information are sent to the server.

And step S608, returning back the information that the car is successfully returned, and successfully locking the helmet lock.

Therefore, the car returning service can be realized through the configuration information.

Fig. 18 is a flowchart of a helmet return service according to an embodiment of the present invention. The embodiment shown in fig. 18 is mainly applied to still helmet services. Correspondingly, the configuration information in the service command sent by the server may be as shown in fig. 13. The method specifically comprises the following steps:

and step S701, receiving a service instruction.

In this embodiment, the vehicle receives a service instruction sent by the server, and parses the service instruction to obtain configuration information and a control instruction, where the configuration information includes a07 return helmet verification enable and a08 protocol configuration that only the helmet lock is closed, as shown in fig. 13.

Wherein, A07 further checks the enabling for triggering the vehicle to execute the following steps S602-S611.

In some embodiments, if the vehicle and the helmet are one-to-one bound and not changeable at will, the configuration information further includes a helmet identification, wherein the helmet identification is an identification of the borrowed helmet. So that the user can only return on the original vehicle when returning the helmet lock.

In some embodiments, if the vehicle and helmet are not bound and can be replaced, the configuration information further includes a06: the helmet identification is filled with all 0's by default so that the vehicle does not verify the helmet identification when performing a helmet verification. Thus, the user can return the helmet to another vehicle.

And step S702, only closing the helmet lock.

In this embodiment, the a08 protocol in which the vehicle acquires the configuration information is configured to turn off only the helmet lock.

And step S703, detecting whether the helmet is in place.

In the embodiment, the vehicle judges whether the helmet is in place according to the helmet in-place condition acquired in advance. Wherein the helmet in-position condition may be at least one of: the output signal of the sensor indicates that the helmet is in place, the identification unit acquires the electronic tag, and the electronic tag detected by the identification unit is detected to be consistent with the electronic tag stored in advance.

In response to the helmet being in position, the process proceeds to step S704.

In response to the helmet not being in place, step S707 is entered, and failure information about the helmet lock is sent to the server, and the failure reason is no helmet.

And step S704, controlling the helmet lock to be closed.

Step S705, whether the helmet lock is successfully closed is detected.

In response to the helmet lock being successfully closed, the process proceeds to step S706.

In response to the failure of closing the helmet lock, step S708 is entered, and failure information about the helmet lock and the reason for the failure are sent to the server as the instruction reason.

And S706, returning the locking success information of the helmet lock.

Therefore, the helmet returning service can be realized through the configuration information.

Fig. 19 is a schematic diagram of a control device of the server according to the embodiment of the present invention. As shown in fig. 19, the control apparatus of the server according to the embodiment of the present invention includes a control request receiving unit 191, a service instruction synthesizing unit 192, and a service instruction transmitting unit 193. The control request receiving unit 191 is configured to receive a control request. The service instruction synthesizing unit 192 is configured to synthesize a corresponding service instruction according to the control request, where the service instruction includes configuration information and a control instruction corresponding to the control request. The service instruction transmitting unit 193 is configured to transmit the service instruction to the target vehicle.

In some embodiments, the service instruction synthesizing unit comprises:

the first configuration information generation subunit is used for configuring the radio values of the configuration items according to the control request to generate configuration information; and

and the first merging subunit is used for merging the configuration information and the corresponding control instruction to generate the service instruction.

In some embodiments, the service instruction synthesizing unit comprises:

the second configuration information generating subunit is used for acquiring configuration information in a configuration library according to the control request; and

and the second merging subunit is used for merging the configuration information and the corresponding control instruction to generate the service instruction.

wherein the first configuration information generating subunit includes:

the first version information determining module is used for determining the version information corresponding to the vehicle identification; and

and the first configuration information generation module is used for configuring the radio values of all the configuration items according to the version information to generate configuration information.

wherein the first configuration information generating subunit includes:

the first address information determining module is used for determining address information corresponding to the vehicle identification; and

and the second configuration information generation module is used for configuring the radio values of all the configuration items according to the address information to generate configuration information.

In some embodiments, the control request includes a vehicle identification of a target vehicle;

wherein the second configuration information generating subunit includes:

the second version information determining module is used for determining the version information corresponding to the vehicle identification; and

and the third configuration information generation module is used for acquiring the configuration information in a configuration library according to the version information.

wherein the second configuration information generating subunit includes:

the second address information determining module is used for determining address information corresponding to the vehicle identifier; and

and the fourth configuration information generation module is used for acquiring the configuration information in a configuration library according to the address information.

In some embodiments, the lock control condition includes at least one of:

In some embodiments, the protocol configuration includes at least one of a helmet in-position condition, a vehicle return and helmet return, and a helmet lock only off.

the lock control type is a double-opening type;

lock control conditions; and

the protocol configuration includes a helmet in-place condition.

In some embodiments, the control request is a vehicle return request, the control instruction is a lock closing instruction, and the configuration information includes:

performing helmet verification enabling; and

the lock control type is a single-opening type.

performing helmet verification enabling; and

the protocol is configured to turn off only the helmet lock.

In some embodiments, the apparatus further comprises:

the helmet detection unit is used for detecting whether a helmet bound with the target vehicle exists in a database after receiving the control request; and

a notification sending unit for sending a borrowing failure notification in response to an absence of a helmet bound to the target vehicle.

In some embodiments, the apparatus further comprises:

the helmet warning information sending unit is used for sending helmet warning information, and the helmet warning information is related information for prompting a user to wear a helmet.

In some embodiments, the apparatus further comprises:

and the feedback information receiving unit is used for receiving feedback information of the target vehicle, wherein the feedback information comprises at least one of helmet lock unlocking success information, helmet lock unlocking failure information, vehicle lock unlocking success information, vehicle lock unlocking failure information and lock unlocking failure reasons.

Fig. 20 is a schematic diagram of a control device of a vehicle of an embodiment of the invention. As shown in fig. 20, the control device of the vehicle according to the embodiment of the present invention includes a service instruction receiving unit 201, an analysis unit 202, and a lock control unit 203. The service instruction receiving unit 201 is configured to receive a service instruction sent by a server. The parsing unit 202 is configured to parse the service instruction to obtain configuration information and a control instruction. The lock control unit 203 is used for controlling a helmet lock and/or a vehicle lock according to the configuration information and the control instruction.

In some embodiments, the lock control condition includes at least one of:

In some embodiments, the lock control unit comprises:

the first helmet lock self-checking subunit is used for responding to the control instruction as an unlocking instruction, controlling the helmet lock to perform self-checking to acquire the state of the helmet lock, wherein the configuration information comprises the control type of the lock as a double-opening type, the control condition of the lock and the configuration of a protocol as the helmet on-site condition;

the first helmet on-position detection subunit is used for responding to the normal state of the helmet lockset and detecting whether the helmet is on position;

the first helmet lock unlocking sub-unit is used for responding to the helmet in place and controlling the helmet lock to be unlocked; and

and the first vehicle lock opening subunit is used for responding to the helmet lock opening success and controlling the vehicle lock to be opened.

In some embodiments, the lock control unit comprises:

the second helmet in-place detection subunit is used for responding to the control instruction, configuring the configuration information including helmet returning verification enabling and protocol into a vehicle returning and helmet returning, and detecting whether the helmet is in place;

the second helmet lock closing subunit is used for responding to the helmet in place and controlling the helmet lock to close; and

and the second vehicle locking subunit is used for responding to the successful locking of the helmet lock and controlling the locking of the vehicle lock.

In some embodiments, the lock control unit comprises:

the third helmet lock self-checking subunit is used for responding to the fact that the control instruction is an unlocking instruction, and the configuration information comprises that the lock control type is a single-opening type, and controlling the helmet lock to perform self-checking so as to obtain the state of the helmet lock;

the third helmet on-site detection subunit is used for responding to the normal state of the helmet lock and detecting whether the helmet is on site; and

and the third helmet lock opening subunit is used for responding to the helmet in place and controlling the helmet lock to be opened.

In some embodiments, the lock control unit comprises:

the fourth helmet in-place detection subunit is used for responding to the control instruction as a locking instruction, and the configuration information comprises helmet verification enabling, helmet default identification and protocol configuration, namely only a helmet lock is locked, so as to detect whether the helmet is in place; and

and the fourth helmet locking subunit is used for responding to the helmet in place and controlling the helmet lock to lock.

In some embodiments, the apparatus further comprises:

the information playing unit is used for responding to the received helmet warning information and playing the helmet warning information;

In some embodiments, the apparatus further comprises:

and the feedback information sending unit is used for sending feedback information to the server, wherein the feedback information comprises at least one of helmet lock unlocking success information, helmet lock unlocking failure information, vehicle lock unlocking success information, vehicle lock unlocking failure information and lock unlocking failure reasons.

It should be understood that the processor 21 and the memory 22 shown in fig. 2 are connected by a bus. The memory 22 is adapted to store instructions or programs executable by the processor 21. The processor 21 may be a stand-alone microprocessor or a collection of one or more microprocessors. Thus, processor 21 implements the processing of data and the control of other devices by executing instructions stored by memory 22 to thereby perform the method flows of embodiments of the present invention as described above. The bus connects the above-mentioned components together, and at the same time, connects the above-mentioned components to a display controller and a display device and an input/output (I/O) device. Input/output (I/O) devices may be a mouse, keyboard, modem, network interface, touch input device, motion-sensing input device, printer, and other devices known in the art. Typically, the input/output devices are connected to the system through input/output (I/O) controllers.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, apparatus (device) or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may employ a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations of methods, apparatus (devices) and computer program products according to embodiments of the application. It will be understood that each flow in the flow diagrams can be implemented by computer program instructions.

These computer program instructions may be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows.

These computer program instructions may also be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows.

The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made to the present invention by those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A control method, characterized in that the method comprises:

and sending the service instruction to the target vehicle.

2. The method of claim 1, wherein the generating the corresponding service instruction according to the control request comprises:

3. The method of claim 1, wherein the generating the corresponding service instruction according to the control request comprises:

4. The method of claim 2, wherein the control request includes a vehicle identification of a target vehicle;

5. The method of claim 2, wherein the control request includes a vehicle identification of a target vehicle;

6. The method of claim 3, wherein the control request includes a vehicle identification of a target vehicle;

7. The method of claim 3, wherein the control request includes a vehicle identification of a target vehicle;

8. The method of claim 2 or 3, wherein the configuration items include at least one of a lock control type, a control condition of a vehicle lock, a helmet verification enable, a helmet default identification, or a protocol configuration.

9. The method of claim 8, wherein the lock control types include a single-release type and a double-release type, the single-release type being a single control helmet lock, and the double-release type being a helmet lock and a vehicle lock in linkage control.

10. The method of claim 9, wherein the lock control condition comprises at least one of:

11. The method of claim 10, wherein the protocol configuration includes at least one of a helmet in-position condition, a return to car and also a helmet, and a mere closing of a helmet lock.

12. The method of claim 11, wherein the control request is a vehicle borrowing request, the control command is an unlocking command, and the configuration information comprises:

the lock control type is a double-opening type;

lock control conditions; and

the protocol configuration includes a helmet in-position condition.

13. The method of claim 11, wherein the control request is a vehicle return request, the control command is a lock off command, and the configuration information comprises:

performing helmet verification enabling; and

14. The method of claim 11, wherein the control request is a helmet borrowing request, the control command is an unlocking command, and the configuration information comprises:

the lock control type is a single-opening type.

15. The method of claim 11, wherein the control request is a return to helmet request, the control command is a lock command, and the configuration information comprises:

performing helmet verification enabling; and

the protocol is configured to turn off only the helmet lock.

16. The method according to claim 12 or 14, further comprising:

in response to the absence of a helmet bound to the target vehicle, sending a borrowing failure notification.

17. The method of claim 16, further comprising:

18. The method of claim 1, further comprising:

19. A control method, characterized in that the method comprises:

analyzing the service instruction to acquire the configuration information and the control instruction; and

and controlling a helmet lock and/or a vehicle lock according to the configuration information and the control instruction.

20. The method of claim 19, wherein the configuration information comprises at least one of a lock control type, a control condition of a vehicle lock, a helmet return verification enable, a helmet default identification, or a protocol configuration.

21. The method of claim 20, wherein the lock control types include a single-open type and a double-open type, the single-open type being a single control helmet lock, and the double-open type being a helmet lock and a vehicle lock in linkage control.

22. The method of claim 21, wherein the lock control condition comprises at least one of:

23. The method of claim 22, wherein the protocol configuration includes at least one of a helmet in-position condition, a return to car and also a helmet, and a helmet lock only being closed.

24. The method of claim 23, wherein the controlling a helmet lock and/or a vehicle lock according to the configuration information and control instructions comprises:

responding to the normal state of the helmet lockset, and detecting whether a helmet is in place;

25. The method of claim 23, wherein in response to the control command being a lock-off command, the configuration information includes a helmet return check enable and protocol configuration as a vehicle return and a helmet return, and wherein controlling the helmet lock and/or the vehicle lock according to the configuration information and the control command comprises:

detecting whether the helmet is in position;

and controlling the vehicle lock to lock in response to the helmet lock being successfully locked.

26. The method of claim 23, wherein in response to the control command being an unlock command and the configuration information including a lock control type being a single-open type, the controlling the helmet lock and/or the vehicle lock according to the configuration information and the control command comprises:

responding to the normal state of the helmet lockset, and detecting whether a helmet is in place; and

and controlling the helmet lock to be unlocked in response to the helmet being in position.

27. The method of claim 23, wherein in response to the control command being a lock-off command and the configuration information including a helmet verification enable, a helmet default identification, and a protocol configured to only turn off a helmet lock, the controlling the helmet lock and/or the vehicle lock according to the configuration information and the control command comprises:

detecting whether the helmet is in place; and

28. The method of claim 19, further comprising:

29. The method of claim 19, further comprising:

30. A control device, characterized in that the device comprises:

a control request receiving unit configured to receive a control request for characterizing an operation that a user desires a target vehicle to perform;

31. A control device, characterized in that the device comprises:

32. A vehicle, characterized in that the vehicle comprises:

a helmet;

a vehicle lock for locking a vehicle; and

a memory for storing one or more computer program instructions, and a processor, wherein the one or more computer program instructions are executed by the processor to implement the method of any of claims 19-29.

33. A server comprising a memory and a processor, wherein the memory is to store one or more computer program instructions, wherein the one or more computer program instructions are to be executed by the processor to implement the method of any one of claims 1-18.

34. A computer program product comprising a computer program, characterized in that when the computer program runs on a computer, the computer performs the method of any of claims 1-29.

35. A computer-readable storage medium on which computer program instructions are stored, which computer program instructions, when executed by a processor, implement the method of any one of claims 1-29.