Vehicle diagnostic data publishing system and methods, computer program products

Abstract

This application discloses a vehicle diagnostic data publishing system and method, as well as a computer program product. The publishing system includes a database storing entity data, a database storing configuration data indicating the entity data, a database storing diagnostic system information, and a publishing task module. The publishing task module can generate publishing task information based on the diagnostic system information, determine the target diagnostic system based on the publishing task information and configuration data, and automatically execute the publishing task based on the publishing time. This publishes the configuration data to the target environment of the target diagnostic system, causing the target diagnostic system to update the entity data corresponding to the configuration data. This method achieves decoupling between entity data of different target diagnostic systems and simultaneous publishing of entity data to multiple target diagnostic systems. The publishing platform is simple to configure, improves data scalability and data publishing efficiency, and reduces system and data maintenance costs.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and more specifically, to a vehicle diagnostic data publishing system and method, and a computer program product. Background Technology

[0002] Vehicle diagnostic technology, as a crucial component of vehicle technological development, is finding increasingly widespread applications. However, with vehicle diagnostic data becoming increasingly complex and the diagnostic data requirements differing across various scenarios, the challenge of disseminating corresponding diagnostic data to multiple diagnostic systems has become a pressing issue.

[0003] In related technologies, it is common practice to build databases for different target environments under the same service system, and then develop different database operation scripts based on these databases to publish diagnostic data to different diagnostic systems. However, because the diagnostic data required by different diagnostic systems is highly coupled, the diagnostic data publishing in related technologies cannot dynamically publish the corresponding vehicle diagnostic data to multiple diagnostic systems simultaneously. Summary of the Invention

[0004] This application provides a vehicle diagnostic data publishing system and method, as well as a computer program product. The various aspects involved in this application's embodiments are described below.

[0005] In a first aspect, a vehicle diagnostic data publishing system is provided. The publishing system includes: a data layer comprising a first database for storing entity data, a second database for storing configuration data, and a third database for storing information about the diagnostic system; the entity data has an entity data ID, the configuration data indicates the entity data and includes the entity data ID and a data user associated with the entity data ID, and the diagnostic system information includes a diagnostic system ID and a data user associated with the diagnostic system ID; and a logic layer comprising a publishing task module, the publishing task module being configured to perform the following operations: construct a publishing task based on the diagnostic system information and generate information for the publishing task, the information for the publishing task including a task ID associated with at least one diagnostic system ID, a publishing schedule, and a target environment; determine a target diagnostic system based on the at least one diagnostic system ID in the publishing task information, the data user in the diagnostic system information, and the data user in the configuration data; execute the publishing task based on the publishing task information to publish the configuration data to the target environment of the target diagnostic system, and after the target diagnostic system updates the configuration data to its configuration database, update the entity database of the target diagnostic system based on the configuration data.

[0006] Secondly, a method for publishing vehicle diagnostic data is provided. The method is applied to a vehicle diagnostic data publishing system, which includes: a first database for storing entity data, a second database for storing configuration data, and a third database for storing diagnostic system information. The entity data has an entity data ID, the configuration data indicates the entity data and includes the entity data ID and a data user associated with the entity data ID, and the diagnostic system information includes a diagnostic system ID and a data user associated with the diagnostic system ID. The method includes: constructing a publishing task based on the diagnostic system information and generating information for the publishing task, the information for the publishing task including a task ID associated with at least one diagnostic system ID, a publishing schedule, and a target environment; determining a target diagnostic system based on the at least one diagnostic system ID in the publishing task information, the data user in the diagnostic system information, and the data user in the configuration data; executing the publishing task based on the publishing task information to publish the configuration data to the target environment of the target diagnostic system, and after the target diagnostic system updates the configuration data to its configuration database, updating the entity database of the target diagnostic system based on the configuration data.

[0007] Thirdly, a computer program product is provided, characterized in that it includes: a computer program / instructions that, when executed by a processor, implement the method described in the second aspect.

[0008] Fourthly, a computer-readable storage medium is provided, having stored thereon information for performing the method as described in the second aspect.

[0009] This application embodiment can decouple entity data between different target diagnostic systems by adding configuration data corresponding to entity data and information of the diagnostic system. In addition, the publishing task module of the publishing system can publish entity data to multiple target diagnostic systems simultaneously based on configuration data, diagnostic system information and publishing task information. The system configuration of this publishing system is simple, improves the scalability of data and the efficiency of publishing vehicle diagnostic data, and reduces the cost of system and data maintenance. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of the architecture of a vehicle diagnostic data publishing system provided in one embodiment of this application.

[0011] Figure 2 This is a schematic flowchart of a method for publishing vehicle diagnostic data provided in an embodiment of this application.

[0012] Figure 3 This is a schematic diagram of the architecture of a vehicle diagnostic data publishing platform provided in another embodiment of this application.

[0013] Figure 4 This is a schematic diagram of the architecture of a vehicle diagnostic data publishing platform provided in another embodiment of this application.

[0014] Figure 5 This is a flowchart illustrating a data update method for a testing environment within a publishing system provided in an embodiment of this application.

[0015] Figure 6 This is a flowchart illustrating a method for building and publishing tasks according to an embodiment of this application.

[0016] Figure 7 This is a flowchart illustrating a method for constructing and publishing tasks according to another embodiment of this application.

[0017] Figure 8 This is a flowchart illustrating a method for publishing vehicle diagnostic data according to another embodiment of this application.

[0018] Figure 9 This is a flowchart illustrating a method for terminating a release in a data management module according to an embodiment of this application.

[0019] Figure 10 This is a flowchart illustrating a method for rolling back a release version provided in an embodiment of this application, whereby the release data management module performs the rollback.

[0020] Figure 11 This is a flowchart illustrating a method for comparing release version information in a release data management module according to an embodiment of this application. Detailed Implementation

[0021] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present application should fall within the scope of protection of the present application.

[0022] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0023] In the description of this application, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention; the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance; furthermore, unless otherwise expressly specified and limited, the terms "installed," "connected," and "linked" should be interpreted broadly, for example, they can refer to a fixed connection or a detachable connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two elements. For those skilled in the art, the specific meaning of the above terms in the present invention can be understood according to the specific circumstances.

[0024] Vehicle diagnostic technology, as a crucial component of vehicle technological development, is finding increasingly widespread applications. As vehicle diagnostic data (or basic vehicle diagnostic data or physical data) becomes more complex, and the required data differs across diagnostic systems in various scenarios (e.g., on-board diagnostic equipment, remote diagnostic equipment, after-sales diagnostic equipment, end-of-line (EOL) diagnostic equipment), distributing corresponding vehicle diagnostic data to multiple diagnostic systems is becoming increasingly important, directly impacting the entire vehicle development cycle. Therefore, how to distribute corresponding vehicle diagnostic data to multiple diagnostic systems has become a pressing issue.

[0025] In related technologies, the method for publishing corresponding vehicle diagnostic data to a diagnostic system involves constructing databases for different target environments within the same service system. Then, by developing database operation scripts and configuring database fields, diagnostic data can be published to different target diagnostic systems. For example, databases for a research and development environment, a testing environment, and a production environment can be simultaneously built in the backend service system. Data from the research and development environment can then be migrated to the testing and production environment databases via data replication, allowing different diagnostic systems to retrieve test and production environment data from these databases. Specifically, different diagnostic systems can develop automated database operation scripts based on different configurations to retrieve corresponding vehicle diagnostic data from the backend service system's testing and / or production environment databases.

[0026] However, because the diagnostic data required by different diagnostic systems are highly coupled, the release of diagnostic data in related technologies cannot dynamically release the corresponding vehicle diagnostic data to multiple diagnostic systems simultaneously.

[0027] To address the above issues, this application provides a vehicle diagnostic data publishing system. The system includes a first database storing vehicle diagnostic data (hereinafter referred to as entity data for brevity), a second database storing configuration data indicating the entity data, a third database storing diagnostic system information, and a publishing task module. This publishing task module can generate publishing task information based on the diagnostic system information, determine the target diagnostic system based on the publishing task information and configuration data, and automatically execute the publishing task based on the publishing time in the publishing task information. This publishes the configuration data to the target diagnostic system, prompts the target diagnostic system to update its configuration database, and then updates its entity database based on the configuration data. By adding configuration data corresponding to the entity data and diagnostic system information, decoupling between entity data from different target diagnostic systems can be achieved. Furthermore, the publishing task module can simultaneously publish entity data to multiple target diagnostic systems based on the configuration data, diagnostic system information, and publishing task information. This publishing system has a simple configuration, improves data scalability and vehicle diagnostic data publishing efficiency, and reduces system and data maintenance costs.

[0028] The following is combined Figures 1-11 This application provides a detailed description of the vehicle diagnostic data publishing system and the method for publishing data using the system.

[0029] like Figure 1 The vehicle diagnostic data publishing system comprises a data layer and a logic layer. The logic layer is used for control and management based on the data within the data layer.

[0030] The data layer includes a first database for storing entity data, a second database for storing configuration data, and a third database for storing information about the diagnostic system.

[0031] The first database can also provide Figure 3 The entity database of the publishing system. The entity data stored in the first database is vehicle diagnostic data. For example, the entity data can be entity data for a test environment, or entity data can be entity data for a production environment. In some embodiments, such as Figure 1 As shown, the first database may include an entity database for the test environment and an entity database for the production environment. Entity data may have an entity data ID and a data version. The entity data ID is a unique identifier for the entity data. The data version refers to the version number of the entity data being developed.

[0032] In some embodiments, the entity data in the first database may be obtained from an entity database in the R&D environment. As one implementation, the entity database in the R&D environment may reside in the deployment system. As another implementation, such as... Figure 3 As shown, the entity database in the R&D environment can reside in the source system. Entity data can be created, developed, or maintained by data development tools in the source system, for example. Optionally, entity data can be encrypted and stored in the entity database of the R&D environment.

[0033] This application does not impose specific limitations on the data type of entity data, and the data types include, but are not limited to, the following types.

[0034] Diagnostic database files contain diagnostic commands, communication protocols, communication parameters, and Diagnostic Trouble Code (DTC) information for each vehicle's Electronic Control Unit (ECU). The formats of these diagnostic database files include, but are not limited to, the Vector standard database file format (CANdela DiagnosticDescription, CDD) and the Open Diagnostic Data Exchange format (ODX).

[0035] Diagnostic program files: These are automated diagnostic script programming files used for vehicle diagnostics. The formats of diagnostic program files include, but are not limited to, programming files developed in languages ​​such as Java, Python, and Open Test Sequence eXchangeformat (OTX).

[0036] Text: Formats include, but are not limited to, Extensible Markup Language (Xml), JavaScript Object Notation (Json), txt text, Hyper Text Markup Language (HTML) text, etc.

[0037] Documents: Formats include, but are not limited to, DOC documents and Portable Document Format (PDF).

[0038] Tables: Formats include, but are not limited to, Excel format files.

[0039] Images: Formats include, but are not limited to, JPG, PNG, JPEG, GIF, etc.

[0040] Video: Formats include, but are not limited to, AVI, MPEG, WMV, etc.

[0041] The second database is Figure 3 The configuration database of the deployment system. The configuration data stored in the second database is data used to indicate entity data, that is, entity data corresponds to configuration data. The configuration data can be configuration data for the test environment, or configuration data for the production environment. In some embodiments, such as Figure 1 As shown, the second database may include a configuration database for the test environment and a configuration database for the production environment. The configuration data may be synchronized with the corresponding entity data as it is generated or changes.

[0042] In some embodiments, the configuration data in the second database may be obtained from the configuration database in the development environment. The configuration data in the configuration database in the development environment is generated synchronously based on the entity data in the development environment. That is, when new entity data is generated in the development environment, or when entity data changes, corresponding configuration data will be generated in the development environment. The storage formats of the configuration data include, but are not limited to, database field data and configuration files (such as XML files, JSON files, text documents, tables, etc.).

[0043] The configuration data includes, but is not limited to, the following: entity data ID; entity data name; data type of the entity data as described above; development status; availability status; data version; change information; and the data user associated with the entity data ID.

[0044] The development status can refer to the current development status of entity data, including but not limited to initialization (newly created entity data), development (entity data under development), and completed development (entity data completed development).

[0045] Availability status refers to an indicator of whether entity data is available. Statuses include disabled and available, with disabled indicating that the data is unavailable.

[0046] Change information refers to the descriptive information about the changes made to the entity data in the corresponding data version.

[0047] In some embodiments, the data user associated with the entity data ID may include a set of users (or a list of users) associated with the entity data ID and a set of vehicle identification information (or a list of vehicle identification information) associated with the entity data ID. The set of users here refers to the set of users of the entity data corresponding to the entity data ID, including but not limited to on-board diagnostic equipment, remote diagnostic equipment, after-sales diagnostic equipment, end-of-life diagnostic equipment, and engineering diagnostic equipment. The set of vehicle identification information here refers to the set of vehicle identification information associated with the entity data ID, including but not limited to vehicle model, vehicle configuration, brand, and sales market.

[0048] In some embodiments, the configuration data may further include a checksum. The checksum is generated by a checksum algorithm and is used to verify data consistency. The checksum algorithms used include, but are not limited to, checksum, XOR check, Cyclic Redundancy Check (CRC), MD5 Message-Digest Algorithm, SM3 cryptographic hash algorithm, etc.

[0049] The third database can provide Figure 3 The diagnostic system database within the publishing system. The diagnostic system database stores information about diagnostic systems that can be used to instruct on these systems. A diagnostic system is a system that can be built and maintained by the publishing system. The information about a diagnostic system can be generated by the publishing system during the construction, maintenance, or management of the diagnostic system, and the diagnostic system must require entity data. The diagnostic system database can store information about all diagnostic systems that the publishing system can build, maintain, or manage. In other words, the publishing system is used to manage, build, or maintain multiple diagnostic systems.

[0050] The information for each diagnostic system includes, but is not limited to, the diagnostic system ID, the target system name, the data user associated with the diagnostic system ID, the server authentication information of the diagnostic system, its availability status, and its creation time.

[0051] The diagnostic system ID is a unique identifier for the diagnostic system. Server authentication information for the diagnostic system may include, for example, the target diagnostic system server address, authentication account, and authentication key. The availability status indicates whether the diagnostic system is available; statuses include disabled and available, with disabled indicating that data is unavailable.

[0052] In some embodiments, the data users associated with the diagnostic system ID include a set of user objects (or a list of user objects) associated with the diagnostic system ID and a set of vehicle identification information (or a list of identification information) associated with the diagnostic system ID. The set of user objects refers to the set of user objects corresponding to the diagnostic system ID, as described above. The set of vehicle identification information refers to the set of vehicle identification information associated with the diagnostic system ID, as described above.

[0053] In some embodiments, the information of the diagnostic system may also include a release version. A release version refers to the data release version corresponding to the entity data in the production environment of the diagnostic system.

[0054] The logical layer 112 may include a publishing task module, which is used to automatically publish configuration data to the target environment of the target diagnostic system based on information from the first database, the second database, and the third database, so that the target environment of the target diagnostic system updates its entity database.

[0055] As one implementation method, such as Figure 2 As shown, the task publishing module can execute steps S210-S2S230 to publish configuration data to the target environment of the target diagnostic system.

[0056] In step S210: Construct a release task based on the information from the diagnostic system and generate information for the release task.

[0057] The publish task is used to send configuration data and entity data to the target diagnostic system. Specifically, the publish task can instruct the target diagnostic system to first send configuration data to the target diagnostic system, then update its configuration database, and finally update the entity data in the entity database based on the updated configuration data.

[0058] This application does not specifically limit the type of task to be published. For example, a task can be a periodically published task or a periodically published task.

[0059] The information used to publish a task indicates the specific content of the task. This information includes, but is not limited to, the following: task ID, planned release timeline, target environment, and at least one diagnostic system ID associated with the task ID.

[0060] The Task ID is a unique identifier for the released task. The Target Environment indicates the type of target environment for the diagnostic system to which the released task is intended; the target environment can be a test environment or a production environment. The Release Schedule indicates the time requirements for the execution of the released task. When the released task is a periodic release task, the release schedule includes the release cycle and the start-end time. The release cycle refers to how often the release task is executed. The start-end time refers to the effective time period for the periodic release task to execute. When the released task is a scheduled release task, the release schedule includes the release time. The release time indicates the specific time point at which the scheduled release task will be executed.

[0061] Optionally, when the published task is a periodically published task, the published task information may also include the creation time of the published task.

[0062] At least one diagnostic system ID associated with the task ID is used to indicate the diagnostic system associated with the task ID and to determine the target diagnostic system. The target diagnostic system is some or all of the diagnostic systems corresponding to the at least one diagnostic system ID associated with the task ID.

[0063] In some embodiments, the task publishing is constructed based on a job model, as detailed below. Therefore, the task publishing information may further include a job model ID, which is associated with a task ID. A task publishing can be associated with a job model based on the job model ID.

[0064] In some embodiments, when the publishing task is a periodic publishing task, the publishing task can be based on building publishing tags according to the job model, and then generating periodic task information based on the configuration data associated with the publishing tags. In this case, the information of the publishing tags includes the information of the aforementioned publishing task. The information of the periodic task and the information of the publishing tags can be different. For example, the information of the periodic task can include, but is not limited to, entity data ID, data version, task ID, publishing status, creation time, etc. The data publishing status includes, but is not limited to, pending publishing, publishing terminated, and published. In some embodiments, the information of the periodic task can be stored in... Figure 3 In the periodic task information database.

[0065] In step S220: Determine the target diagnostic system based on at least one diagnostic system ID in the information of the published task, the data user in the information of the diagnostic system, and the data user in the configuration data.

[0066] As an example, determining a target diagnostic system based on at least one diagnostic system ID in the published task information, the data user in the diagnostic system information, and the data user in the configuration data may include determining the target diagnostic system based on a first data user and a second data user. The first data user may be determined based on the data user in the configuration data, and the first data user is the data user associated with an entity data ID in the configuration data. The second data user may be determined based on at least one diagnostic system ID in the published task information and the data user in the diagnostic system information. The second data user is determined based on at least one diagnostic system ID associated with the task ID in the published task information and the data user associated with at least one diagnostic system ID indicated in the task system information.

[0067] In step S230: Execute the release task according to the release task information to release configuration data to the target environment of the target diagnostic system, and after the target diagnostic system updates the configuration data to the configuration database of the target diagnostic system, update the entity database of the target diagnostic system based on the configuration data.

[0068] The publishing system executes publishing tasks based on information such as the target environment and publishing schedule.

[0069] After the target diagnostic system updates the configuration data to the configuration database of the target diagnostic system, the method for updating the entity database of the target diagnostic system based on the configuration data can be similar to the method for updating the entity database in the release system, as described below.

[0070] This application embodiment achieves decoupling between entity data from different target diagnostic systems by adding configuration data corresponding to the entity data and information from the diagnostic system. Furthermore, the task publishing module allows for the simultaneous publishing of entity data to multiple target diagnostic systems based on the configuration data, diagnostic system information, and task publishing information. This publishing system has a simple configuration, improves data scalability and the efficiency of vehicle diagnostic data publishing, and reduces system and data maintenance costs.

[0071] As mentioned earlier, the release system can build or manage multiple diagnostic systems. In some embodiments, these multiple diagnostic systems can be built by the release system based on a unified interface document. That is, all diagnostic systems capable of obtaining configuration and entity data from the release system communicate and connect with it through this unified interface document, and the release system can build new diagnostic systems based on this unified interface document when needed. An interface document is a document that details how systems or components interact. It defines the communication methods, data formats, request and response structures, error handling mechanisms, etc., between different systems or modules.

[0072] In some embodiments, the diagnostic system may be Figure 3 The diagnostic system maintenance module is built and maintained in real time. Information from the diagnostic system can be stored... Figure 3 In the diagnostic system information database.

[0073] The deployment system can dynamically build or manage multiple diagnostic systems through a unified interface document, thereby avoiding the problem of secondary development of service systems required when using scripts to build diagnostic systems in related technologies, and reducing data and system management costs.

[0074] This application does not impose specific limitations on the architecture of the diagnostic system. For example... Figure 3 As shown, the diagnostic system may include a logic layer and a data layer. The logic layer of the diagnostic system includes a data processing module, while the data layer includes data for the test environment and data for the production environment. The data for the test environment includes entity data stored in an entity database for the test environment and configuration data stored in a configuration database for the production environment; the entity data and configuration data correspond to each other. The data processing module communicates with the release system to process sent and received data.

[0075] As mentioned earlier, the data in the first or second database can be obtained from corresponding data in the R&D environment. As one implementation method, such as... Figure 3 As shown, the release system communicates with the source system, and the release system and the source system together constitute a release platform. The source system independently manages the entity database and configuration database in the R&D environment. The second database in the release system can obtain data from the configuration database of the source system, and the first database in the release system can obtain data from the entity database of the source system.

[0076] In some embodiments, such as Figure 3As shown, the source system includes a research and development environment data layer and a logic layer. The research and development environment data layer includes an entity database and a configuration database for the research and development environment. The configuration data in the configuration database corresponds to the entity data in the entity database. The source system may include a data processing module, a basic data configuration module, and basic data development tools.

[0077] Combination Figure 4 As shown, the basic data development tool is used to create entity data, encrypt the entity data, store it in the entity database used in the R&D environment, and generate entity data IDs and data versions. In addition, the basic data development tool is also used to develop and maintain the entity data it creates, and after each development or maintenance, it is encrypted and stored in the entity database used in the R&D environment.

[0078] Combination Figure 4 As shown, the basic data configuration module is used to maintain (including generate or update) the corresponding configuration data when entity data is created, developed, or maintained (developed or maintained can be understood as updated) entity data in the basic data development tool. The basic data configuration module is also used to store the configuration data it maintains corresponding to the entity data in a configuration database used in the R&D environment. Therefore, the configuration data is associated with the entity data. Furthermore, combined with... Figure 4 As shown, after the configuration data in the configuration database used for the R&D environment is updated, the basic data configuration module is also used to send updated configuration data with a development status of "developed" to the release system.

[0079] For example, when the basic data development tool updates the entity data of an entity data ID, the basic data configuration module updates the development status, data version, and change information of the configuration data corresponding to that entity data to generate updated configuration data.

[0080] The data processing module communicates with the publishing system to process sent or received data. (Combined with...) Figure 4 As shown, the data processing module is used to enable the publishing system to obtain the corresponding entity data based on the updated configuration data.

[0081] As one implementation method, such as Figure 3 As shown, the logical layer of the publishing system also includes a data processing module. This module can communicate with the source system and the diagnostic system, and process sent and received data. The data processing module in the publishing system is also used to enable the publishing system to obtain the corresponding entity data (i.e., the entity data to be updated) based on the updated configuration data. The entity data to be updated can be obtained from the entity database of the source system based on the target entity data ID and data version in the updated configuration data. That is, the entity data ID of the entity data to be updated is the target entity data ID.

[0082] In some embodiments, the data processing module is configured to perform the following operations: receive updated configuration data from the configuration database of the source system; update the second database based on the updated (including replacement or addition) configuration data; and update (including replacement, addition, or deletion) the first database based on the updated configuration data in the second database. This method allows for timely receipt of updated configuration data from the source system and, based on that configuration data, the acquisition of entity data to be updated corresponding to the updated configuration data.

[0083] In this embodiment of the application, the first database includes an entity database for the test environment and / or an entity database for the production environment, and the second database includes a configuration database for the test environment and / or a configuration database for the production environment.

[0084] As mentioned earlier, the updated configuration data is obtained by updating the entity data in the entity database used in the development environment from the source system. Furthermore, the updated configuration data is the configuration data whose development status is "developed". As an example, the content of the updated configuration data could be... Figure 4 The configuration data content in the file. Among this, the entity data ID included in the updated configuration data is the target entity data ID.

[0085] As one implementation, the data processing module of the publishing system updates the second database based on the updated configuration data. Specifically, this includes: determining whether there is target configuration data in the second database corresponding to the target entity data ID; if target configuration data exists in the second database, replacing it with the updated configuration data; and if no target configuration data exists in the second database, adding the updated configuration data to the second database. Here, the target configuration data is the configuration data that originally existed in the publishing system's configuration database, and the entity data ID in this configuration data is the target entity data ID. The updated configuration data can be understood as the latest configuration data required by the publishing system.

[0086] As one implementation, the data processing module of the publishing system updates the first database based on the updated configuration data in the second database. Specifically, this includes: determining whether target entity data corresponding to the target entity data ID exists in the first database; in response to the existence of target entity data in the first database and the updated configuration data in the second database indicating that the entity data is available, replacing the target entity data with the entity data to be updated sent by the source system; in response to the absence of target entity data in the first database and the updated configuration data in the second database indicating that the entity data is available, adding the entity data to be updated sent by the source system to the first database; and in response to the existence of target entity data in the first database and the updated configuration data in the second database indicating that the entity data is disabled, deleting the target entity data. Here, the target entity data is the entity data that existed in the first database before the updated configuration data was updated to the second database, and the entity data ID of the target entity data is the same as the target entity data ID.

[0087] In some embodiments, the updated configuration data includes a checksum and a data version. Before replacing the target entity data with the entity data to be updated sent by the source system, the data processing module performs the following operations: in response to the existence of target entity data in the first database and the updated configuration data in the second database indicating that the entity data is available, it performs a first check on the target entity data based on the checksum and the data version to obtain a first check result; in response to the first check result indicating that the target entity data does not meet the consistency requirements, it receives the entity data to be updated sent by the source system. This setting ensures the security of data updates and avoids duplicate data replacements.

[0088] In some embodiments, when replacing target entity data with entity data to be updated sent by the source system or adding entity data to be updated sent by the source system to the first database, the data processing module may specifically perform the following operations: perform a second verification on the entity data to be updated sent by the source system based on the checksum and data version to obtain a second verification result; in response to the second verification result indicating that the entity data to be updated sent by the source system meets the consistency requirements, replace the target entity data in the first database with the entity data to be updated sent by the source system or add the entity data to be updated sent by the source system to the first database; in response to the second verification result indicating that the entity data to be updated sent by the source system meets the inconsistency requirements, report an error and restore the updated configuration data in the second database to the target configuration data. This setting can ensure the security of data updates and avoid invalid database updates.

[0089] As a concrete example, such as Figure 5 As shown, the data update logic flow for the test environment in the release system includes steps S510-S572.

[0090] In step S510, the publishing system receives updated configuration data with a development status of "developed" sent by the basic data configuration module of the source system; in step S520, the data processing module of the publishing system replaces or adds configuration data to the configuration database of the test environment based on the entity data ID; in step S530, the data processing module of the publishing system determines the availability status of the configuration data; regardless of whether it is available or not, proceed to step S540; in step S540, determine whether the entity data corresponding to the entity data ID in the configuration data exists in the entity database of the test environment; if it is available and exists, proceed to step S551; if it is available and does not exist, proceed to step S552; if it is disabled and exists, proceed to step S553; if it is disabled and does not exist, the process ends. In step S551, the system checks whether the data version and checksum in the configuration data are consistent. In step S552, the data processing module of the source system sends the entity data ID and the entity data corresponding to the data version in the entity database of the development environment to the release system. In step S553, the entity data corresponding to the entity data ID is deleted. After step S552, step S560 may be included, which verifies whether the entity data sent by the source system passes the data consistency test based on the checksum. If they are consistent, step S571 is executed; if they are inconsistent, step S572 is executed. In step S571, the updated entity data is added to the entity database of the test environment. In step S572, if the update fails, an error is reported, and the configuration data is restored to its previous state.

[0091] As mentioned earlier, task publishing can be based on a job model. As one implementation, the logical layer of the publishing system also includes a job model maintenance module. This module performs the following operations: Constructing job model information based on diagnostic system information. This job model information includes, but is not limited to: a job model ID and at least one diagnostic system ID associated with the job model ID, the job model name, a list of data types associated with the job model ID, and the creation time. The job model ID is a unique identifier for the job model. The at least one diagnostic system ID associated with the job model ID can also be referred to as a list of diagnostic system IDs associated with the job model ID. Based on this, the task publishing module performs the following operations: Constructing a publishing task based on the job model information and generating the publishing task information. The publishing task can be a periodic or recurring publishing task. The task ID is associated with a job model ID. The publishing task information can be as described above and will not be repeated here.

[0092] As an example, when publishing tasks as periodic tasks, the task publishing module is... Figure 3 The periodic release task module in the system dynamically constructs and executes periodic release tasks based on information from the job model. In some embodiments, the information (or configuration information) of the periodic release tasks is stored in... Figure 3 The information is stored in the periodic task information database. Periodic task configuration information includes, but is not limited to: task ID; release period; job model ID; start-end time; target environment.

[0093] As another example, when the task is published periodically, the task publishing module is... Figure 3 The system includes a periodic release tag module and a periodic release task module. The periodic release tag module dynamically constructs release tags based on information from the job model. In some embodiments, the release tag information includes information about the periodic release task (or configuration information), and the release tags can be stored in [the system / library]. Figure 3 The release tag information is stored in the release tag information library. Release tag information includes, but is not limited to: Task ID; Job Model ID; Release Time; Target Environment: Creation Time. The periodic release task module dynamically builds and executes periodic release tasks, associates test environment configuration data with release tags to generate periodic task information, and stores periodic task information in the periodic task information library, where the release status is "Pending Release". Periodic task information includes, but is not limited to, Entity Data ID, Data Version, Task ID, Release Status, Creation Time, etc.

[0094] In some embodiments, such as Figure 3 As shown, the data layer of the publishing system can also include a job model information database, where job model information can be stored.

[0095] As a concrete example, such as Figure 6 As shown, when the task is a periodic task, the process of the release system dynamically constructing the diagnostic system and configuring the periodic automatic task release includes: in step S610, the diagnostic system maintenance module dynamically constructs the diagnostic system and maintains the information of the diagnostic system in real time; in step S620, the job model maintenance module dynamically constructs the information of the job model based on the information of the diagnostic system; in step S630, the periodic task release module dynamically constructs the periodic task release based on the job model and executes it.

[0096] As a concrete example, such as Figure 7 As shown, when the task is a periodically released task, the process of the release system dynamically constructing the diagnostic system and periodically and automatically releasing task configurations includes: in step S710, the diagnostic system maintenance module dynamically constructs the diagnostic system and maintains the information of the diagnostic system in real time; in step S720, the job model maintenance module dynamically constructs the information of the job model based on the information of the diagnostic system; in step S730, the periodically released tag module dynamically constructs release tags based on the job model; in step S740, the periodically released task module dynamically constructs and executes the periodically released task.

[0097] As mentioned earlier, the data users include a set of vehicle identification information and a set of devices used. The publishing task module in the publishing system can determine the target diagnostic system based on at least one diagnostic system ID in the publishing task information, the data users in the diagnostic system information, and the data users in the configuration data. The task ID is associated with the operation model ID, and the operation model ID is associated with at least one diagnostic system ID; therefore, the task ID is associated with at least one diagnostic system ID. Based on this, the data users associated with at least one diagnostic system ID include a first data set group and a second data set group. The first data set group is at least one set of vehicle identification information associated with at least one diagnostic system ID, and the second data set group is at least one set of devices associated with at least one diagnostic system ID.

[0098] As one implementation, the task publishing module performs the following operations to determine the target diagnostic system: It calculates a first intersection between the set of vehicle identification information associated with entity data IDs in the configuration data and each vehicle identification information set in a first set group, where the vehicle identification information set in the first set group whose first intersection result is not empty is the target vehicle identification information set; it calculates a second intersection between the set of user devices associated with entity data IDs in the configuration data and each user device set in a second set group, where the user device set in the second set group whose second intersection result is not empty is the target user device set; and it determines the diagnostic system corresponding to the diagnostic system ID jointly associated with the target vehicle identification information set and the target user device set as the target diagnostic system. This method allows the determination of the target diagnostic system that needs updating based on the configuration information and the task publishing information. Therefore, by changing the configuration information or the task publishing information, it is also possible to build a new target diagnostic system or publish diagnostic data (entity data) to multiple different target diagnostic systems simultaneously. The system configuration is simple, requiring no secondary system development, improving data scalability, and reducing system development and maintenance costs.

[0099] In addition, since the source system, diagnostic system and release system in this application embodiment are equipped with entity databases and corresponding configuration databases, and the entity database is updated according to changes in the configuration database, this method can ensure the consistency of configuration data and corresponding entity data under the same configuration environment and avoid data redundancy.

[0100] As previously described, the release task module can execute release tasks. In some embodiments, when the target environment for the release task is a production environment, the release task module is configured to perform the following operations: in response to the target environment being a production environment, update configuration data from the configuration database for the test environment of the release system to the configuration database for the production environment of the release system; update the entity database for the production environment based on the configuration data updated to the configuration database for the production environment; and execute the release task to release the updated configuration data to the configuration database for the production environment to the production environment of the target diagnostic system.

[0101] In other words, when a task release requires updating the database of the production environment of the target diagnostic system, the configuration database and entity database of the production environment of the release system can be updated first. Then, the configuration database of the target diagnostic system is updated based on the configuration database of the production environment of the release system, and the entity database of the target diagnostic system is updated based on the update of the configuration database of the target diagnostic system.

[0102] This method isolates the test environment from the production environment, ensuring data security while maintaining consistency of entity and configuration data across different systems and environments. This reduces data maintenance costs and improves data scalability.

[0103] To further manage the data publishing status of the publishing system, in some embodiments, the data processing module of the publishing system is further configured to perform the following operations: receive update results sent by the target diagnostic system, the update results indicating whether the publishing task was successfully published; and generate publishing result information based on the update results. The publishing result information includes, but is not limited to, at least one of the following: entity data ID, data version, task ID, target diagnostic system ID, target environment, publishing result, and execution time. Publishing results include publishing termination, publishing success, and publishing failure. In some embodiments, the publishing result information may be stored in a... Figure 3 The information published is shown in the database.

[0104] To manage releases, in some embodiments, the release system's database may further include a fourth database for storing release information. The fourth database is, for example... Figure 3 The data processing module is also used to perform the following operations: In response to an update result indicating that the release task was successfully released and the target environment is a production environment, it generates information about the current release version in the entity database of the production environment of the target diagnostic system. This information includes, but is not limited to, at least one of the following: target diagnostic system ID, release version, entity data ID, data version, configuration data ID, and update time; and stores this information in [the database]. Figure 3 The release version information repository shown; will Figure 3 The published version of the diagnostic system information corresponding to the target diagnostic system in the database of the diagnostic system shown is updated to the current published version.

[0105] To further implement version management of vehicle diagnostic data for each target diagnostic system based on the release version information database, in some embodiments, such as Figure 3 As shown, the logical layer of the publishing system also includes a publishing data management module. This module can be used to perform publishing termination, publishing version data rollback, or publishing version data comparison. These tasks can be triggered by buttons or events.

[0106] As an example, the release data management module performs the following operations: In response to the need to roll back the current release version in the production environment of the target diagnostic system to a target historical release version, it retrieves a first configuration data ID from the information of the current release version and a second configuration data ID from the information of the target historical release version based on the target diagnostic system ID; it retrieves first configuration data corresponding to the first configuration data ID and second configuration data corresponding to the second configuration data ID from the configuration database of the production environment of the target diagnostic system; it determines the entity data of the difference based on the first configuration data and the second configuration data, the entity data of the difference being used to characterize the difference between the entity data corresponding to the second configuration data ID and the entity data corresponding to the first configuration data ID; and it publishes the second configuration data and the entity data of the difference to the target diagnostic system, so that the target diagnostic system updates the configuration database of the production environment of the target diagnostic system based on the second configuration data and updates the entity database of the production environment of the target diagnostic system based on the second configuration data.

[0107] To further manage periodically published tasks, in some embodiments, the published tasks are designated as periodically published tasks. These periodically published tasks have corresponding periodically published task information, which includes the following interrelated information: data ID, task ID, and publication status. Before a periodically published task is executed, the publication status is "pending publication." Before executing a periodically published task, the publication data management module performs the following operations: establishes a publication termination task, which includes a task ID and a data ID; based on the task ID and data ID of the termination task, modifies the publication status of the target task's task ID in the periodically published task information to "publish terminated" and generates a publication result indicating publication termination; and sends the publication result to a fifth database used to store publication information.

[0108] The target task's task ID is the task ID in the periodically published task information that is in the "pending publication" status. Furthermore, the target task's task ID is the same as the task ID of the terminated task, and the data ID associated with the target task's task ID is the same as the data ID of the terminated task. The fifth database can be, for example: Figure 3 The aforementioned database of published information.

[0109] In some embodiments, such as Figure 3 As shown, the logical layer of the publishing system may also include a publishing information query module, which obtains historical publishing results information based on different screening conditions.

[0110] As mentioned earlier, the publishing task module can automatically execute publishing tasks based on the information provided. To facilitate understanding of an implementation example of executing publishing tasks, the following section provides a detailed explanation. Figure 8 The flow of the periodic, periodic automatic publishing task execution logic of the publishing system in this application embodiment is described in detail. For example... Figure 8 As shown, the process includes steps S811-S890.

[0111] In step S811, the periodic release task module of the release system creates a periodic release task.

[0112] In step S812, the release system continuously checks the configuration data in the configuration database of the test environment according to the specified cycle (or event triggering) within the start-end time specified by the periodic release task.

[0113] In step S813, it is determined whether the configuration data has been updated. If there is an update, proceed to step S814; otherwise, the process ends and waits for the next cycle.

[0114] In step S814, the updated configuration data is published to the target environment of the server of one or more matching diagnostic systems according to the specified job model. The one or more matching diagnostic systems are the target diagnostic systems described above.

[0115] In step S821, the periodic release task module of the release system creates a periodic release task.

[0116] In step S822, the specified release time triggers (or an event triggers) to execute the release task, and the release status in the periodic task information corresponding to the task ID is adjusted to "released".

[0117] In step S823, the periodic release task publishes the configuration data with a release status of "pending release" in the periodic task information to the target environment of one or more matching target diagnostic system servers according to the associated release tag information. After steps S823 and S814, step 830 is executed.

[0118] In step 830, the data processing module of the target diagnostic system updates the acquired configuration data to the corresponding target environment configuration database.

[0119] In step 840, the data processing module of the target diagnostic system updates the entity database of the corresponding target environment based on the configuration data content.

[0120] In step 850, the data processing module of the target diagnostic system will update the results and feed them back to the diagnostic basic data publishing system.

[0121] In step 860, the diagnostic basic data publishing system data processing module generates publishing result information and stores it in the publishing information database.

[0122] In step 870, determine whether the update was successful and whether the target environment is a production environment. If the update was successful and the target environment is a production environment, proceed to step 880.

[0123] In step 880, the data processing module of the release system generates the release version information of the latest (or current) formal environment database of the target diagnostic system and stores it in the release version information repository.

[0124] In step 890, update the release version of the corresponding target diagnostic system information in the target system information database to the latest release version.

[0125] Specifically, steps S814 and S823 may include the following:

[0126] Identify the target diagnostic system. Specifically, this includes: obtaining the vehicle identification information list Vehicle_Ids_0 and the user list Users_0 from the configuration data; obtaining one or more diagnostic systems Target_Systems_0 associated with the job model, and the vehicle identification information list Vehicle_Ids_1 and the user list Users_1 associated with the diagnostic system; and matching one or more diagnostic systems (these one or more diagnostic systems are the target diagnostic system) Target_Systems_1 that have a non-empty intersection of the vehicle identification information lists Vehicle_Ids_1 and Vehicle_Ids_0 and the user list Users_1 and Users_0.

[0127] Define the target environment. This includes the following:

[0128] If the target environment is the test environment of the target diagnostic system, the configuration data will be sent to the test environment database of the target diagnostic system Target_Systems_1.

[0129] If the target environment is the production environment of the target diagnostic system, add the configuration data to the production environment configuration database of the release system, and add a configuration data ID to the configuration data content. The configuration data ID is a unique identifier for the configuration data. Then, based on the configuration data content, add the difference entity data to the production environment entity database of the release system, and finally send the configuration data to the production environment database of the target diagnostic system Target_Systems_1.

[0130] The method for adding entity data with differences based on configuration data content to the entity database of the production environment of the publishing system is as follows.

[0131] If the availability status in the configuration data is "available", then check whether there is entity data in the formal entity database corresponding to the entity data ID and data version in the configuration data;

[0132] If there is no entity data, retrieve the entity data corresponding to the entity data ID and data version from the configuration data in the test environment entity database, and verify the data consistency based on the check code. If it fails, the update fails, an error is reported, and the configuration data is restored to the previous state. If it passes, add the entity data to the production environment entity database.

[0133] If there is entity data, the consistency of the data is verified based on the data version and check code in the configuration data. If they are inconsistent, the entity data corresponding to the entity data ID and data version in the configuration data is retrieved from the entity database of the test environment, and the consistency of the data is verified based on the check code. If the verification fails, the update fails, an error is reported, and the configuration data is restored to its previous state. If the verification passes, the entity data is added to the entity database of the production environment.

[0134] If the available status in the configuration data is "disabled", then no action is taken.

[0135] Step 840 described above may specifically include the following:

[0136] If the availability status in the configuration data is "available", then determine whether there is entity data corresponding to the entity data ID in the configuration data in the entity database of the target environment corresponding to the target diagnostic system;

[0137] If there is no entity data, the data processing module of the diagnostic basic data publishing system sends the entity data ID and the entity data corresponding to the data version in the entity database of the target environment. The target diagnostic system obtains and verifies the data consistency based on the check code. If it fails, the update fails, an error is reported, and the configuration data is restored to the previous state. If it passes, the updated entity data is added to the entity database of the target environment of the target diagnostic system.

[0138] If entity data exists, the consistency of the data is verified based on the data version and checksum in the configuration data. If they are inconsistent, the data processing module of the diagnostic basic data publishing system sends the entity data ID and the entity data corresponding to the data version in the entity database of the target environment. The target diagnostic system obtains and verifies the consistency of the data based on the checksum. If it fails, the update fails, an error is reported, and the configuration data is restored to the previous state. If it passes, the updated entity data is added to the entity database of the target environment of the target diagnostic system.

[0139] If the available status in the configuration data is "disabled", then check whether there is entity data corresponding to the entity data ID in the entity database of the target environment corresponding to the target diagnostic system. If so, delete it.

[0140] As mentioned earlier, the release data management module can perform release termination and release version data rollback. The following section combines this with point 9. Figure 10 The execution logic of this process is explained.

[0141] For data in the periodic task information that has a release status of "pending release," the release data management module of the release system should execute the following specific method to terminate the release: Figure 9 As shown, the specific steps include S910-S960.

[0142] In step S910, the data management module sends a message to the periodic task information database to "filter periodic task information datasets with a release status of 'pending release'".

[0143] In step S920, the periodic task information database returns the screened dataset to the data release management module;

[0144] In step S930, the data management module sends a message to the periodic task information database: "Screen periodic task information based on task ID and entity data ID, and modify the corresponding publication status to 'publication terminated'."

[0145] In step S940, the periodic task information database returns the execution results to the release data management module;

[0146] In step S950, the data management module generates publishing result information, in which the publishing result is assigned the value "Publishing terminated".

[0147] In step S960, the data management module sends the publishing result to the publishing information database.

[0148] The specific method for reverting the database of the target diagnostic system's production environment to the corresponding data of a historical release version is as follows: Figure 10 As shown. Figure 10 The diagram includes steps S1010-S1092.

[0149] In step S1010, the release data management module of the release system retrieves the release version information of the production environment data from the release version information database based on the target system ID;

[0150] In step S1020, the release data management module retrieves the current release version from the target system information database;

[0151] In step S1030, the release data management module obtains the configuration data ID corresponding to the historical release version and the current release version of the target diagnostic system from the release version information.

[0152] In step S1040, the release data management module retrieves the configuration data corresponding to the configuration data ID from the configuration database of the production environment;

[0153] In step S1050, the release data management module obtains the entity data difference results based on the configuration data of the current release version and historical release versions; the differences include additions, replacements, deletions, etc.

[0154] In step S1060, the data management module deserializes the entity data information of the differences based on the difference results;

[0155] In step S1070, the release data management module releases the configuration data and difference entity data corresponding to the historical release versions to the corresponding target diagnostic system;

[0156] In step S1080, the target diagnostic system data processing module updates the configuration database of the target diagnostic system's production environment to the configuration data of historical release versions;

[0157] In step S1090, the target diagnostic system updates the entity data that differs in the entity database of the production environment based on the configuration data of the historical version; the update method is to add, replace, or delete.

[0158] In step S1091, the target diagnostic system returns the execution result to the release data management module; if all the formal environment configuration data and entity data of the target diagnostic system are successfully changed, the change result is fed back to the release data management module so that the release data management module executes step S1092.

[0159] In step S1092, the data management module updates the release version of the corresponding target diagnostic system information in the target system information database.

[0160] In some embodiments, if a failure occurs during the modification of the target diagnostic system's production environment configuration data or entity data, the target diagnostic system rolls back to the original data state through a transaction mechanism (such as Java transaction locking mechanism) and feeds back the failure result to the release system.

[0161] As mentioned above, the release data management module in this embodiment is also used to perform release version data comparison. The following is in conjunction with... Figure 11 This section provides a detailed comparison of target system data from different releases of the target diagnostic system in its production environment. For example... Figure 11 As shown, the execution logic for comparing release version data includes steps S1110-S1160.

[0162] In step S1110, the release data management module retrieves release version information for different release versions from the release version information database based on the target diagnostic system ID;

[0163] In step S1120, the data management module compares different release version information and filters data versions or release version information with different configuration data IDs based on entity data ID; where differences include additions, missing items, and differences.

[0164] In step S1130, configuration data for different release versions is obtained based on the configuration data ID in the release version information of the difference;

[0165] In step S1140, the differences in the field content of the configuration data of different release versions are displayed;

[0166] In step S1150, entity data files for different release versions are obtained based on the entity data ID and data version in the release version information of the difference;

[0167] In step S1160, the differences in the field content of the configuration data of different release versions are displayed.

[0168] The differences mentioned above can all be obtained using Git difference comparison tools.

[0169] In some embodiments, such as Figure 3 In the illustrated deployment platform and target diagnostic system, the logical modules of the source system, deployment system, and target diagnostic system can be built using the Spring Boot framework. The system's distributed microservice architecture module is executed using the Spring Cloud framework. Data transmission and reception between the various systems are achieved using HTTP communication and message queue frameworks. HTTP protocols send request and receive response data objects to achieve data interaction; message queue frameworks implement asynchronous communication, improving the system's scalability and flexibility. Common message queue frameworks include RabbitMQ, RocketMQ, and Kafka.

[0170] In addition, this application embodiment also provides a method for publishing vehicle diagnostic data. This method is applied to the vehicle diagnostic data publishing system described above. The publishing system includes: a first database for storing entity data, a second database for storing configuration data, and a third database for storing diagnostic system information. The entity data has an entity data ID, the configuration data is used to indicate the entity data and includes the entity data ID and a data user associated with the entity data ID, and the diagnostic system information includes a diagnostic system ID and a data user associated with the diagnostic system ID. The method includes: constructing a publishing task based on the diagnostic system information and generating information for the publishing task, the information for the publishing task including a task ID associated with at least one diagnostic system ID, a publishing schedule, and a target environment; determining a target diagnostic system based on the at least one diagnostic system ID in the information for the publishing task, the data user in the information for the diagnostic system, and the data user in the configuration information; executing the publishing task based on the information for the publishing task to publish configuration data to the target environment of the target diagnostic system, and after the target diagnostic system updates the configuration data to the configuration database of the target diagnostic system, updating the entity database of the target diagnostic system based on the configuration data.

[0171] This application also provides a machine-readable storage medium for storing a program. This program causes a computer to execute the methods described in the various embodiments of this application.

[0172] This application also provides a computer program product. The computer program product includes a program. The program causes a computer to perform the methods described in various embodiments of this application.

[0173] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any other combination. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this disclosure are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a machine-readable storage medium or transmitted from one machine-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The machine-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state drives (SSDs)).

[0174] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments of this disclosure can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0175] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0176] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0177] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0178] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A system for publishing vehicle diagnostic data, the system comprising: The system comprises: a data layer comprising a first database for storing entity data, a second database for storing configuration data, and a third database for storing information of a diagnostic system; the entity data has an entity data ID, the configuration data is used for indicating the entity data and comprises the entity data ID and a data usage end associated with the entity data ID, and the information of the diagnostic system comprises a diagnostic system ID and a data usage end associated with the diagnostic system ID; a logic layer comprising a release task module, the release task module being configured to perform the following operations: constructing a release task according to the information of the diagnostic system and generating information of the release task, the information of the release task comprising a task ID associated with at least one diagnostic system ID, a release time plan, and a target environment; determining a target diagnostic system according to the at least one diagnostic system ID in the information of the release task, the data usage end in the information of the diagnostic system, and the data usage end in the configuration data; performing the release task according to the information of the release task, so as to release the configuration data to the target environment of the target diagnostic system, and enabling the target diagnostic system to update the configuration data to a configuration database of the target diagnostic system, and then updating an entity database of the target diagnostic system based on the configuration data.

2. The publishing system of claim 1, wherein, The release system is communicatively connected with a source system, the source system comprising an entity database for a development environment and a configuration database, the configuration data in the configuration database corresponding to the entity data in the entity database, and the logic layer further comprises a data processing module, the data processing module being configured to perform the following operations: receiving updated configuration data in the configuration database from the source system, the updated configuration data being obtained after the source system updates the entity data in the entity database for the development environment; updating the second database according to the updated configuration data; updating the first database according to the updated configuration data in the second database; wherein the first database comprises an entity database for a test environment and / or an entity database for a formal environment, and the second database comprises a configuration database for a test environment and / or a configuration database for a formal environment.

3. The publishing system of claim 2, wherein, The entity data ID in the updated configuration data is a target entity data ID, and the data processing module is configured to perform the following operations: determining whether there is target configuration data corresponding to the target entity data ID in the second database according to the target entity data ID; in response to the second database having the target configuration data, replacing the target configuration data with the updated configuration data; in response to the second database not having the target configuration data corresponding to the target entity data ID, adding the updated configuration data to the second database.

4. The publishing system of claim 2, wherein, The data processing module is configured to perform the following operations: determining whether there is target entity data corresponding to a target entity data ID in the first database; in response to the target entity data existing in the first database and the updated configuration data in the second database indicating that entity data is available, replacing the target entity data with entity data to be updated sent by the source system; in response to the target entity data not existing in the first database and the updated configuration data in the second database indicating that entity data is available, adding the entity data to be updated sent by the source system into the first database; in response to the target entity data existing in the first database and the updated configuration data in the second database indicating that entity data is disabled, deleting the target entity data.

5. The publishing system of claim 4, wherein, The updated configuration data includes a check code and a data version, and the data processing module is configured to perform the following operations: in response to the target entity data existing in the first database and the updated configuration data in the second database indicating that entity data is available, performing a first check on the target entity data based on the check code and the data version to obtain a first check result; in response to the first check result indicating that the target entity data does not meet consistency requirements, receiving the entity data to be updated sent by the source system.

6. The publishing system of claim 1, wherein, The logic layer further includes a job model maintenance module configured to perform the following operations: constructing information of a job model according to the diagnostic system information, the information of the job model including a job model ID and the at least one diagnostic system ID associated with the job model ID; The task publishing module is configured to perform the following operations: constructing the publishing task according to the information of the job model and generating information of the publishing task, the publishing task being a periodic publishing task or a regular publishing task, and the task ID being associated with the job model ID.

7. The publishing system of claim 6, wherein, The data usage end includes a vehicle identification information set and a usage equipment set, at least one diagnostic system ID associated with the task ID is associated with a first data set group and a second data set group, the first data set group being at least one vehicle identification information set associated with the at least one diagnostic system ID one by one, and the second data set group being at least one usage equipment set associated with the at least one diagnostic system ID one by one, The publishing task module is configured to perform the following operations: performing a first intersection between the vehicle identification information set associated with the entity data ID in the configuration data and each vehicle identification information set in the first data set group, wherein the vehicle identification information set in the first data set group with a non-empty first intersection result is a target vehicle identification information set; performing a second intersection between the usage equipment set associated with the entity data ID in the configuration data and each usage equipment set in the second data set group, wherein the usage equipment set in the second data set group with a non-empty second intersection result is a target usage equipment set; A diagnostic system corresponding to a diagnostic system ID commonly associated with the target vehicle identification information set and the target use equipment set is determined as a target diagnostic system.

8. The publishing system of claim 2, wherein, The data processing module is further configured to perform the following operations: receive an update result sent by the target diagnostic system, the update result being used to indicate whether the publishing task is successfully published; generate publishing result information according to the update result, the publishing result information including at least one of the following information: entity data ID, data version, task ID, target diagnostic system ID, target environment, publishing result, execution time.

9. The publishing system of claim 8, wherein, The data layer further includes a fourth database for storing publishing version information, and the data processing module is further configured to perform the following operations: in response to the update result indicating that the publishing task is successfully published and the target environment being a formal environment, generate information of a current publishing version of an entity database of the formal environment of the target diagnostic system, the information of the current publishing version including at least one of the following information: target diagnostic system ID, publishing version, entity data ID, data version, configuration data ID, update time; store the information of the current publishing version in the fourth database; update the publishing version of the diagnostic system information corresponding to the target diagnostic system in the third database to the current publishing version.

10. The publishing system of claim 9, wherein, The logic layer further includes a publishing data management module, which is configured to perform the following operations: in response to a need to roll back the current publishing version in the formal environment of the target diagnostic system to a target historical publishing version, acquire a first configuration data ID in the information of the current publishing version and a second configuration data ID in the information of the target historical publishing version based on the target diagnostic system ID from the fourth database; acquire first configuration data corresponding to the first configuration data ID and second configuration data corresponding to the second configuration data ID from a configuration database of the formal environment of the target diagnostic system; determine differential entity data based on the first configuration data and the second configuration data, the differential entity data being used to represent the difference between the entity data corresponding to the second configuration data ID and the entity data corresponding to the first configuration data ID; publish the second configuration data and the differential entity data to the target diagnostic system, so that the target diagnostic system updates the configuration database of the formal environment of the target diagnostic system based on the second configuration data and updates the entity database of the formal environment of the target diagnostic system based on the second configuration data.

11. The publishing system of claim 7, wherein, The publishing task is the periodic publishing task, and the periodic publishing task has corresponding periodic publishing task information, the periodic publishing task information including the following information associated with each other: data ID, task ID, publishing state, wherein, before the periodic publishing task is executed, the publishing state is to be published, and before the publishing task is executed, the publishing data management module is configured to perform the following operations: establish a publishing termination task, the publishing termination task including a task ID and a data ID; modify a publishing state of a task ID of a target task in the periodic publishing task information to publishing termination based on the task ID and the data ID of the terminated task and generate a publishing result, the publishing result indicating publishing termination; send the publishing result to a fifth database for storing publishing information.

12. A method of publishing vehicle diagnostic data, characterized by, The method is applied to a publishing system of vehicle diagnosis data, the publishing system comprising a first database for storing entity data, a second database for storing configuration data, and a third database for storing diagnosis system information, the entity data having an entity data ID, the configuration data being used for indicating the entity data and comprising the entity data ID and a data usage end associated with the entity data ID, the diagnosis system information comprising a diagnosis system ID and a data usage end associated with the diagnosis system ID; The method comprises: constructing a publishing task according to the information of the diagnosis system and generating information of the publishing task, the information of the publishing task comprising a task ID associated with at least one diagnosis system ID, a publishing time plan, and a target environment; determining a target diagnosis system according to the at least one diagnosis system ID in the information of the publishing task, the data usage end in the information of the diagnosis system, and the data usage end in the configuration data; executing the publishing task according to the information of the publishing task to publish the configuration data to the target environment of the target diagnosis system, and causing the target diagnosis system to update the configuration data to a configuration database of the target diagnosis system, and updating the entity database of the target diagnosis system based on the configuration data.

13. A computer program product, characterised in that, comprise: a computer program which, when executed by a processor, implements the method of claim 12.

Images