A method for realizing automobile control based on data response

Abstract

The present invention discloses a method for realizing automobile control based on data response, comprising the following steps: step 1: abstractly define each hardware device of a vehicle to obtain a data structure containing the whole vehicle; step 2: according to the data structure obtained in step 1, set the abstract definition corresponding to each hardware device of the vehicle as a corresponding module, and set the corresponding attributes and attribute operations of the module according to the hardware device; step 3: create a data center, and register the module corresponding to each hardware device, and the corresponding attributes and attribute operations of the module in the data center; the data center maintains the attribute registration information and status information of each module, and provides data storage and query services; step 4: the data center can monitor the stored data, and when the data in the data center changes, it can drive the corresponding software or hardware to take corresponding actions.

Description

Technical Field

[0001] The present invention relates to the technical field of automobile intelligence, and in particular to a method for realizing automobile control based on data response. Background Art

[0002] The current automotive industry is facing a revolution. In order to meet the needs of the development of intelligent automobiles, the concept of SDA (Software Defined Automobile) has been proposed. At present, it is generally recognized that a better system architecture for implementing SDA is SOA (Service-Oriented Architecture). Automobile manufacturers can choose to conduct rapid research and development based on mature platforms (such as AUTOSAR) or start from scratch. The current implementation of SOA basically divides the entire vehicle into several domains, such as driving domain, power domain, cockpit domain, etc., and then each domain provides various services that belong to its own domain. These services are atomic. The main advantages of SOA are: (1) It realizes basic decoupling between domains. Unlike the signal-oriented approach, changes often affect the entire system; (2) The services provided are black boxes. There is no need to worry about the implementation of the services, just use the services; (3) The atomic services make some functions at the hardware level software-based and empower the vehicle computer application layer, which greatly enriches the vehicle computer application. However, SOA still has its shortcomings: 1) The granularity of the interface design of atomic services is difficult to control; 2) There are timing issues with service interface calls. For example, if the requirement is to open all the doors and lights at the same time, it will inevitably involve calling a series of atomic service interfaces to open the left door, right door, left light, right light, etc., which may cause the doors and lights to be out of sync; 3) It cannot be completely decoupled, and changes in the interface will trigger changes in the dependent party. Summary of the invention

[0003] In view of the above-mentioned deficiencies in the prior art, the purpose of the present invention is to provide a method for realizing automobile control based on data response, so as to solve the problems in the prior art that the granularity of atomic service interface design is difficult to control, there are timing problems in service interface calls, and complete decoupling cannot be achieved.

[0004] In order to solve the above technical problems, the present invention adopts the following technical solutions:

[0005] A method for realizing automobile control based on data response comprises the following steps:

[0006] Step 1: Abstractly define each hardware device of the vehicle to obtain the data structure containing the entire vehicle;

[0007] Step 2: According to the data structure obtained in step 1, the abstract definition corresponding to each hardware device of the vehicle is set as a corresponding module, and the corresponding attributes and attribute operations of the module are set according to the hardware device;

[0008] Step 3: Create a data center and register the modules corresponding to each hardware device, as well as the corresponding attributes and attribute operations of the modules in the data center; the data center maintains the attribute registration information and status information of each module, and provides data storage and query services;

[0009] Step 4: The data center can monitor the stored data, and when the data in the data center changes, it can drive the corresponding software or hardware to take corresponding actions.

[0010] Compared with the prior art, the present invention has the following beneficial effects:

[0011] 1. The method described in the present invention abstractly defines various hardware devices in the vehicle, so that all the data of the vehicle are stored in the data center, providing data support for the application of emerging technologies such as artificial intelligence, big data, and data twins; at the same time, since the vehicle's hardware devices are stateful, by defining the communication protocol, multiple attributes of the hardware devices can be operated during a single communication operation, and the state of the entire vehicle can be changed in a timely manner, thereby effectively avoiding timing problems.

[0012] 2. In the method described in the present invention, the caller only relies on the abstract data structure of the vehicle in the data center. The data structure remains unchanged and the caller does not need to make any changes. At the same time, the interface design of each module is simple and there is no need to worry about granularity issues. As long as the hardware can provide attribute operations, the software layer can implement operations on the corresponding attributes. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 This is a schematic diagram of the present invention.

[0014] Figure 2 This is a vehicle data structure diagram of the present invention. DETAILED DESCRIPTION

[0015] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the present invention will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present invention. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present invention.

[0016] The present invention provides a method for realizing automobile control based on data response, such as Figure 1~2 As shown, the specific steps include:

[0017] Step 1: Abstractly define each hardware device of the vehicle to obtain a data structure containing the entire vehicle, wherein the hardware device at least includes each hardware device that can support the normal operation of the vehicle.

[0018] In the present invention, the abstract definition of each hardware device in the vehicle is based on human semantics, and a data structure with structural hierarchy and strong readability is defined as a digital / state description of a whole vehicle. Note that this data structure does not need to include all components of the vehicle, but must include the minimum working structure of the vehicle, that is, at least the most basic hardware devices that can support the normal operation of the vehicle. This data structure can be understood as reflecting the basic component structure of the vehicle, and the additional structural components that exist in practice are handled in a dynamic addition and deletion manner.

[0019] Step 2: According to the data structure obtained in step 1, the abstract definition corresponding to each hardware device of the vehicle is set as a corresponding module, and the corresponding attributes and attribute operations of the module are set according to the hardware device. The corresponding attributes of the module include static attributes and dynamic attributes, and the attribute operations include readable and writable.

[0020] Specifically, the abstract definition corresponding to each hardware device of the vehicle is set as a corresponding module. The module here refers to the hardware devices of the vehicle such as lights, doors, sunroofs, wheels, engines, batteries, wipers, and rearview mirrors. These vehicle component modules meet the definition of step 1 and form a tree data structure. These modules are designed according to the data structure containing the whole vehicle obtained in step 1, and provide their attributes and attribute-allowed operations. The attributes of the module include static attributes and dynamic attributes. The attribute operations are divided into static attribute operations and dynamic attribute operations according to their necessity. Among them, static attributes and static attribute operations require that the vehicle component modules must provide them, while dynamic attributes and dynamic attribute operations are additionally provided by the vehicle component modules and are flexible. The attributes and operations of different vehicle models will be different. The attribute operations are divided into readable operations and writable operations when they are implemented. For example, some vehicle models have sunroofs, while some vehicle models do not have sunroofs. The sunroof is designed as a dynamic attribute and dynamically registered. The operation of the switch state attribute related to it is also designed as a dynamic attribute operation. For sunroofs that support switching, the switch state attribute of the sunroof is dynamically registered for read and write operations, while for sunroofs that do not support switching, the switch state attribute of the sunroof is dynamically registered for read operations. Similarly, taking the car door as an example, the car door provides the attributes of the door switch, door opening angle, and maximum door opening angle according to the door data structure. Among them, the door switch and the maximum door opening angle are readable but not writable, that is, the specific parameters can be read but not modified, and the door opening angle is readable and writable, that is, the preset opening angle can be read and the opening angle can be modified. The window in the car door provides the lifting height, the maximum lifting height, and the lifting state attributes, among which the lifting height and lifting state are readable and writable, and the maximum lifting height is readable but not writable. The car lock in the car door provides the switch state and the anti-lock state attributes, among which the switch state is readable but not writable, and the anti-lock state is readable and writable. In addition, considering that the car lock can be upgraded to a hidden handle car lock, the car lock must provide the handle closed state attribute, because this attribute is variable and it is a dynamic attribute.

[0021] At the same time, the operation response and registration of each attribute of the door are completed by the controller. The controller here can be set to set one controller for each door, or one controller for multiple doors. A domain controller, such as a body domain controller, can also be used. Taking the method of using one controller to control four doors as an example, the controller communicates with the data center through the DDS (Data Distribution Service) protocol. When the vehicle is started, the main controller of the door will send the attribute information to the data center through the DDS communication protocol to complete the registration.

[0022] When the vehicle component module does not support attributes or attribute operations, it can ignore them or report an exception during actual execution.

[0023] Step 3: Create a data center and register the modules corresponding to each hardware device, as well as the corresponding attributes and attribute operations of the module in the data center; the data center maintains the attribute registration information and status information of each module, and provides data storage and query services.

[0024] In the specific implementation, the data center includes a memory-level database and a disk-level database; the data information of the whole vehicle is first stored in the memory-level database, and then synchronized to the disk-level database in the form of an asynchronous task. The data center stores the tree data of the vehicle in the form of a database. To this end, two databases are provided, a memory-level database and a disk-level database. The status information of the whole vehicle will be first stored in the memory-level database, and then the data will be synchronized to the disk-level database in the form of an asynchronous task. Among them, the memory-level database can select a relational memory database, a key-value memory database, a traditional database memory database engine, etc. This embodiment adopts a relational memory database method. The disk-level database can use a traditional relational database.

[0025] When the vehicle starts, the memory-level database and the disk-level database establish a vehicle information data table according to the static attributes. After that, the controller of the module in the vehicle registers the actual attribute information in the data center. The data center checks whether the registered attribute information meets the static attribute requirements. If not, an exception is reported. For registered dynamic attributes, the database adjusts the data table according to the dynamic attribute content.

[0026] When processing a storage request, the data center first determines whether the request belongs to the application software layer or the hardware device layer; if it is a storage request from the hardware device layer, the data center directly modifies the data in the database; if it is a storage request from the application software layer, the data center determines whether the request operation is legal; if the request is illegal, the data center rejects the request; if the request is legal, the data center first converts the request operation into an operation on the hardware device layer, waits until the hardware device layer completes the operation and receives the attribute storage request, and then changes the corresponding attribute data in the database. When processing a query request, the data center directly returns the query result regardless of whether the request comes from the application software layer or the hardware device layer.

[0027] Step 4: The data center can monitor the stored data. When the data in the data center changes, it can drive the corresponding software or hardware to take corresponding actions. The data center should provide data change monitoring services to the application software layer. When the data maintained by the data center changes, the data center can actively notify the various application software layer modules that are interested in the data change, and the modules that need to perceive the data change will monitor the data change.

[0028] Among them, the data changes in the data center include the following situations: when the data center receives a storage request, the attribute value in the storage request is compared with the original attribute value corresponding to it; if the two are different, the change notification of the attribute is triggered, and the data center receives the notification of the new attribute value. The data changes in the data center include the following situations: when the content of the data table in the database changes, the change notification of the attribute itself is triggered. Generally speaking, the application software layer needs the monitoring service. In order to provide the monitoring service, the data center needs to maintain the monitoring object of the application software layer. When a storage request is received, the attribute value in the storage request is compared with the original attribute value corresponding to it, that is, the new attribute value in the storage request is compared with the original old attribute value in the data center. If the two are not equal, the change notification of the attribute will be triggered, and the module that monitors the attribute will receive the notification of the new attribute value. When the data table in the database changes, the change notification of the attribute itself will be triggered. This situation mainly occurs in the hot plug-in of the vehicle component module. If the hot plug-in function is not supported, the change notification of the attribute itself does not need to be provided. When the application software layer monitors the change of the attribute value, it will respond accordingly.

[0029] The data center communicates with tbox through the DDS protocol, and the data that needs to be uploaded is uploaded to the cloud through tbox. Because, in some cases, the necessary data center data is uploaded to the cloud: this step is mainly to support vehicle abnormality sorting and high-tech applications such as big data and artificial intelligence. The data center of this embodiment will communicate with tbox through the DDS protocol, and the data that needs to be uploaded will be uploaded to the cloud through tbox. If you want to ensure the reliability of uploading to the cloud, the data center can have a built-in network communication chip. When the data center detects an abnormal condition of the vehicle, triggers the diagnostic device, and receives a remote upload command to the cloud, it will upload the vehicle information in the disk-level database to the cloud. This embodiment also uploads vehicle data periodically, which provides better support for iterative products.

[0030] Specifically, when the following situations occur (not mandatory, depending on the specific situation), the data in the data center needs to be uploaded to the cloud for further analysis or as support for big data applications and product iterations:

[0031] Case 1: Vehicle abnormality (active);

[0032] Case 2: Vehicle diagnosis (active);

[0033] Case 3: Periodic upload (active);

[0034] Case 4: Upload triggered by remote command (passive).

[0035] The present invention also provides a system for realizing automobile control based on data response, which is used to realize the method of the present invention, such as Figure 1~2 As shown in the figure, it includes the application software layer, data center, and various modules; each module is the hardware device layer, which is the lowest level to implement various operations; the application software layer is used to interact with the data center, and various actions are implemented by operating various modules through the data center, that is, the hardware device layer. The data center is used to connect the application software layer and various modules. When the data in the data center changes, it will drive the application software layer and the hardware device layer to make corresponding changes.

[0036] In the specific implementation, the data center needs to provide vehicle component module attribute registration service. When the vehicle starts, the data center will establish a database based on the data structure defined in step 1 of the method of the present invention and perform corresponding initialization. After the initialization is completed, the attribute registration request of each vehicle component module can be accepted. The data center will detect whether the static attribute registration from each vehicle component module conforms to the vehicle data structure established in step 1. If it does not conform, it can report an abnormality during the self-check phase of vehicle startup. For dynamic attributes and operations, the data center will change the established database structure. After that, the data center can provide storage and query of vehicle information.

[0037] The data center provides storage and query services for vehicle information. Vehicle information can be divided into real-time information and non-real-time information based on specific latency requirements. Real-time information has high latency requirements, so it is considered to be managed with a memory-level database, while non-real-time information has low latency requirements, so it is considered to be managed with a disk-level database. Among them, real-time information is further divided into persistent data and non-persistent data based on the survival time of the information. Non-persistent data will be lost after the vehicle loses power, while persistent data will be saved in the disk-level database even if the vehicle loses power.

[0038] The storage function of the data center serves the application software layer and the various vehicle components. When the application software layer stores vehicle information in the data center, it is actually performing vehicle control operations. When the vehicle component module stores vehicle information in the data center, it is actually changing the current vehicle status information. When the data center receives a storage request, it will determine the requester. For storage requests from the application software layer, the data center will first call the write operation of the attribute to the relevant vehicle component module. If the write is successful, the data value in the data center will be updated. For requests from vehicle component modules, the data center directly modifies the data value.

[0039] The query function of the data center serves the application software layer. The application software layer module can obtain the real-time information of the current vehicle through query. This function supports multi-attribute joint query and has structured characteristics. For example, a one-time door module status query or even a one-time vehicle status query. The data center also provides data change monitoring services to the application software layer. When the data maintained by the data center changes, the data center can actively notify each application software layer module that is interested in the data change, and the modules that need to perceive the data change will monitor the data change. Among them, the data change of the data center refers to two aspects: ① Changes in vehicle attribute values; ② Changes in vehicle attributes and their attribute operations themselves. Changes in vehicle attribute values ​​are triggered by the data center storage service. Changes in vehicle attributes and their attribute operations themselves are triggered by the vehicle component module requesting the data center attribute registration service again after the vehicle completes self-test. This situation mainly occurs when the vehicle component module is hot-swapped. For example, when the hardware of a vehicle component module is hot-swapped, its module controller will request registration services from the data center, and the data center will update its database structure based on the new registration information.

[0040] As described above, the reminder system of the present invention is not limited to the configuration described above, and other systems that can implement the embodiments of the present invention may fall within the scope of protection of the present invention.

[0041] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention rather than to limit the technical solution. Those skilled in the art should understand that those modifications or equivalent substitutions of the technical solution of the present invention that do not depart from the purpose and scope of the technical solution should be included in the scope of the claims of the present invention.

Claims

1. A method for realizing automobile control based on data response, characterized in that: The steps include: Step 1: Abstractly define each hardware device of the vehicle to obtain the data structure containing the entire vehicle; Step 2: According to the data structure obtained in step 1, the abstract definition corresponding to each hardware device of the vehicle is set as a corresponding module, and the corresponding attributes and attribute operations of the module are set according to the hardware device; Step 3: Create a data center and register the modules corresponding to each hardware device, as well as the corresponding attributes and attribute operations of the modules in the data center; the data center maintains the attribute registration information and status information of each module, and provides data storage and query services; Step 4: The data center can monitor the stored data. When the data in the data center changes, it can drive the corresponding software or hardware to take corresponding actions. In step 3, the data center includes a memory-level database and a disk-level database; the data information of the entire vehicle is first stored in the memory-level database, and then synchronized to the disk-level database in the form of an asynchronous task; When the vehicle starts, the memory-level database and the disk-level database establish a vehicle information data table according to the static attributes. After that, the controller of the module in the vehicle registers the actual attribute information in the data center. The data center checks whether the registered attribute information meets the static attribute requirements. If not, an exception is reported. For registered dynamic attributes, the database adjusts the data table according to the dynamic attribute content. When processing a storage request, the data center first determines whether the request belongs to the application software layer or the hardware device layer. If it is a storage request belonging to the hardware device layer, the data center directly modifies the data in the database. If it is a storage request belonging to the application software layer, the data center determines whether the request operation is legal. When the request is illegal, the data center rejects the request. When the request is legal, the data center first converts the request operation into an operation on the hardware device layer, and receives the attribute storage request after the hardware device layer completes the operation, and then changes the corresponding attribute data in the database.

2. The method for realizing automobile control based on data response according to claim 1, characterized in that: In step 1, the hardware equipment at least includes various hardware equipment that can support the normal operation of the vehicle.

3. The method for realizing automobile control based on data response according to claim 1, characterized in that: In step 2, the corresponding attributes of the module include static attributes and dynamic attributes, and the attribute operations include readable and writable.

4. The method for realizing automobile control based on data response according to claim 1, characterized in that: In step 3, the data center directly returns the query result when processing the query request.

5. The method for realizing automobile control based on data response according to claim 4, characterized in that: In step 4, changes in the data in the data center include the following situations: when the data center receives a storage request, it compares the attribute value in the storage request with its corresponding original attribute value; if the two are different, a change notification of the attribute is triggered, and the data center receives notification of the new attribute value.

6. The method for realizing automobile control based on data response according to claim 1, characterized in that: In step 4, the data in the data center changes include the following situations: when the content of the data table in the database changes, a change notification of the attribute itself is triggered.

7. The method for realizing automobile control based on data response according to claim 1, characterized in that: The data center communicates with tbox through the DDS protocol, and the data that needs to be uploaded is uploaded to the cloud through tbox.

Images