SOVD server and method for executing same

Abstract

The present application relates to an SOVD server. The SOVD server comprises: an SOVD adaptation unit, configured to communicate with a local entity; an SOVD gateway unit, configured to communicate with a remote entity; an SOVD forwarding unit, configured to communicate with another SOVD server; and an SOVD routing unit, configured to receive a request from an SOVD client and route the request to the corresponding SOVD adaptation unit, SOVD gateway unit, or SOVD forwarding unit on the basis of an entity name or identifier in the request. The present application further relates to a method executed by an SOVD server, a computer program product, and a computer-readable storage medium.

Description

SOVD server and method performed thereby

[0001] Cross-reference to related applications

[0002] This PCT application claims priority to Chinese Patent Application No. 202411040452.2, filed on July 30, 2024, entitled “SOVD server and method performed thereby”, the entire contents of which are hereby incorporated by reference as a basis for priority claim of the present application. TECHNICAL FIELD

[0003] The present application relates to the field of service-oriented vehicle diagnostics, and more particularly, to a SOVD server, a method performed by the SOVD server, a computer program product, and a computer-readable storage medium. BACKGROUND

[0004] In July 2022, ASAM (Association for Standardization of Automation and Measuring Systems) released a new standard, Service-Oriented Vehicle Diagnostic (SOVD), which defines a series of diagnostic APIs (Application Programming Interfaces) to provide a unified access interface for high-performance computers and related applications of diagnostic content and traditional UDS (Unified Diagnostic Services) electronic control units (ECUs). However, there is currently no controller solution based on the SOVD standard on the market. SUMMARY

[0005] According to an aspect of the present application, a SOVD server is provided, comprising: a SOVD adaptation unit configured to communicate with local entities; a SOVD gateway unit configured to communicate with remote entities; a SOVD forwarding unit configured to communicate with other SOVD servers; and a SOVD routing unit configured to receive requests from SOVD clients and route the requests to corresponding SOVD adaptation units, SOVD gateway units, or SOVD forwarding units according to entity names or identifiers in the requests and entity names or identifiers in a configuration file.

[0006] In addition or alternatively to the above-mentioned solutions, in the above-mentioned SOVD server, the SOVD server is located in a first high-performance computer (HPC), the local entities include components, applications, and functions in the first high-performance computer (HPC) containing the SOVD server, and the remote entities include one or more electronic control units (ECUs) and one or more second high-performance computers (HPCs).

[0007] As a supplement or alternative to the above solutions, in the SOVD server, the SOVD adaptation unit is configured to directly access the description of diagnostic capabilities and scopes within the local entity, and perform read, write or control operations on the local entity according to the data and services defined in the description of diagnostic capabilities and scopes.

[0008] As a supplement or alternative to the above solutions, in the SOVD server, the SOVD gateway unit is configured to establish connection and exchange information with the remote entity through UDS, DoIP or SOME / IP protocol.

[0009] As a supplement or alternative to the above solutions, in the SOVD server, the SOVD gateway unit is configured to perform read, write or control operations on the remote entity according to the diagnostic data and services provided by the remote entity.

[0010] As a supplement or alternative to the above solutions, in the SOVD server, the SOVD forwarding unit is configured to transparently pass the request it receives to other SOVD servers, and forward the reply of the other SOVD servers to the SOVD client.

[0011] As a supplement or alternative to the above solutions, in the SOVD server, the request is an HTTP / S request, and the SOVD routing unit is configured to determine to route the request to the corresponding SOVD adaptation unit, SOVD gateway unit or SOVD forwarding unit according to the uniform resource locator (URL) in the HTTP / S request.

[0012] As a supplement or alternative to the above solutions, the SOVD server further comprises a protocol conversion unit configured to convert the HTTP request received from the SOVD gateway unit into a UDS request and send it to the corresponding UDS controller, and convert the reply of the UDS controller into an HTTP reply and transmit it to the SOVD gateway unit.

[0013] As a supplement or alternative to the above solutions, in the SOVD server, the SOVD server receives the request from the SOVD client via a SOVD API interface, and the SOVD client comprises an in-vehicle client, a near-field client and a remote client.

[0014] According to another aspect of the present application, a method performed by a SOVD server is provided, the method comprising: loading a configuration file containing information of all entities under the SOVD server; parsing each configuration node in the configuration file and loading corresponding dynamic library and static library plug-ins according to information and attributes of each configuration node; and saving a mapping relationship between a uniform resource locator (URL) corresponding to each configuration node and a SOVD adaptation unit, a SOVD gateway unit and a SOVD forwarding unit in the SOVD server, for subsequent request processing.

[0015] In addition to or instead of the above-mentioned solutions, in the above-mentioned method, the configuration file can be modified to add a node and a corresponding plug-in path.

[0016] In addition to or instead of the above-mentioned solutions, the above-mentioned method further comprises: after receiving a request from a SOVD client, processing the request by a SOVD routing unit to determine whether an instance in a uniform resource locator (URL) of the request belongs to the SOVD adaptation unit, the SOVD gateway unit or the SOVD forwarding unit, and forwarding the request to the corresponding unit for processing; and after the request processing is completed, replying a diagnosis result to the SOVD client.

[0017] According to yet another aspect of the present application, a computer program product is provided, comprising a computer program which, when executed by a processor, implements the above-mentioned method.

[0018] According to yet another aspect of the present application, a computer readable storage medium is provided, having stored thereon a computer program which, when executed by a processor, implements the above-mentioned method.

[0019] Each unit in the SOVD server of the embodiments of the present application has a specified function, and the SOVD routing unit well isolates the SOVD adaptation unit, the SOVD gateway unit and the SOVD forwarding unit. In addition, in one embodiment, the SOVD server uses a configuration file (for example, an XML configuration file) to load nodes of the SOVD adaptation unit, the SOVD gateway unit and the SOVD forwarding unit in the process of starting, thereby improving efficiency for subsequent processing of HTTP requests and facilitating subsequent node changes and addition of functions. BRIEF DESCRIPTION OF DRAWINGS

[0020] The above and other objects and advantages of the present application will become more apparent by describing in detail the following embodiments thereof with reference to the attached drawings, in which like reference numerals refer to like elements throughout the several views.

[0021] Fig. 1 shows a structural diagram of a SOVD server according to an embodiment of the present application; and

[0022] Fig. 2 shows a flow diagram of a method performed by a SOVD server according to an embodiment of the present application. DETAILED DESCRIPTION

[0023] In the following, a service-oriented vehicle diagnostic SOVD scheme according to exemplary embodiments of the present application will be described in detail with reference to the accompanying drawings.

[0024] In the description of the specification, descriptions with reference to the terms "one embodiment", "some embodiments”, "example”, "specific example”, or "some examples” etc. mean that a specific feature, structure, material or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. Descriptive expressions of the above terms in the specification do not necessarily refer to the same embodiment or example. Also, the specific feature, structure, material or characteristic described can be combined in suitable ways in any one or more embodiments or examples. In addition, the terms "first”, "second”, "third” are only for descriptive purposes, and cannot be understood as indicating or implying relative importance. In addition, different embodiments or examples described in the specification and features of different embodiments or examples can be combined and combined by those skilled in the art without contradiction.

[0025] Fig. 1 shows a structural diagram of a SOVD server 1000 according to an embodiment of the present application. As shown in Fig. 1, the SOVD server 1000 comprises a SOVD adaptation unit 110, a SOVD gateway unit 120, a SOVD forwarding unit 130 and a SOVD routing unit 140. The SOVD adaptation unit 110 is configured to communicate with local entities; the SOVD gateway unit 120 is configured to communicate with remote entities; the SOVD forwarding unit 130 is configured to communicate with other SOVD servers; and the SOVD routing unit 140 is configured to receive requests (e.g. HTTP requests) from SOVD clients and route the requests to the corresponding SOVD adaptation unit 110, SOVD gateway unit 120 or SOVD forwarding unit 130 according to the entity name or identifier in the request.

[0026] In the context of the present application, SOVD (Service-Oriented Vehicle Diagnostics) is a standardized vehicle diagnostic communication protocol. The SOVD standard covers diagnostic use cases throughout the vehicle's life cycle, from development, production, to operation and after-sales service. One major advantage of SOVD is the provision of a REST API that is independent of programming languages, which enables the development of new lightweight application scenarios for diagnostics, e.g. using modern programming or scripting languages like Python to read and evaluate vehicle data. The uniform interface of SOVD allows for uniform execution of diagnostic access and operations in close-range, remote, or in-vehicle scenarios, and the API is able to serve multiple clients at the same time, which paves the way for new application scenarios, e.g. while a workshop technician has access to a vehicle, a manufacturer's technical assistance center can also have remote access.

[0027] In one embodiment, the SOVD server 1000 is located within a first high-performance computer HPC. In one or more embodiments, the local entities comprise components, applications, and functions in the first high-performance computer HPC. The remote entities can comprise one or more legacy electronic control units ECUs and one or more second high-performance computers HPCs (different from the first high-performance computer HPC). In the context of the present application, an entity is determined to be a local or remote entity depending on its location, i.e. if it is located within the first high-performance computer HPC, it is considered a local entity, otherwise it is considered a remote entity.

[0028] In the context of the present application, the term "component" stands for hardware or software, but also for a combination of both (e.g. an ECU with basic software). A "component" representing hardware is characterized by having a CPU and executing software, e.g. an HPC, an ECU, and a smart sensor. Software that is part of a "component" is characterized by being basic software required for executing an application. Examples of basic software are operating systems or hypervisors. Only software components or components containing software parts shall be linked to an application App.

[0029] The term "application" (App) stands for an application program that is executed on a "component", e.g. an Advanced-Lane-Keeping or a Window Control function.

[0030] The term "Function" represents a functional view and allows the vehicle manufacturer OEM to define access to diagnostic information, which can be distributed over multiple "components". A "Function" is for example the Vehicle Identification.

[0031] In one embodiment, the SOVD adaptation unit 110 is responsible for communication with a local entity, such as a component, an application or a function. The SOVD adaptation unit 110 can directly access the diagnostic capability description inside the entity and can perform read, write or control operations with the entity according to the data and services defined in the description.

[0032] In one embodiment, the SOVD gateway unit 120 is responsible for communication with a remote entity, such as a legacy electronic control unit ECU or a high performance computer HPC. The SOVD gateway unit 120 is configured to establish a connection and exchange information with the remote entity through different protocols or technologies, such as UDS (Unified Diagnostics Services), DoIP (Diagnostic over Ethernet) or SOME / IP (Scalable service-Oriented MiddlewarE over IP), etc. The SOVD gateway unit 120 can perform read, write or control operations with the remote entity according to the diagnostic data and services provided by the remote entity.

[0033] In one embodiment, the SOVD forwarding unit 130 is responsible for communication with other SOVD servers. The SOVD forwarding unit 130 is configured to transparently forward a received request to another SOVD server and to forward a reply to an external SOVD client.

[0034] The SOVD routing unit 140 is configured to receive a request (e.g. an HTTP request or an HTTPS request) from a SOVD client and to route the request to a corresponding SOVD adaptation unit 110, SOVD gateway unit 120 or SOVD forwarding unit 130 according to an entity name or identifier in the request (and in a configuration file). In one embodiment, the SOVD routing unit 140 is configured to determine the routing of the request to a corresponding unit according to a uniform resource locator URL in the HTTP / S request.

[0035] Although not shown in Fig. 1, in one embodiment the SOVD server 1000 further comprises a protocol conversion unit for converting HTTP requests received from the SOVD gateway unit 120 into UDS requests and sending them to the corresponding UDS controller, and for converting replies from the UDS controller into HTTP replies and transmitting them to the SOVD gateway unit 120.

[0036] In one or more embodiments, the SOVD clients comprise in-vehicle clients, proximity clients, and remote clients. In the context of this application, remote clients denote clients under remote diagnostic use cases. By "remote use case or remote diagnostic use case" it is meant that the operator is assumed to not be in the vicinity of the vehicle, but to access the vehicle remotely over a (mobile) broadband network (wirelessly). Remote diagnostic use cases do not necessarily require a human end user, but can also include cloud-based services such as fleet management, data collection and analysis, which only indirectly provide information to a human user. Remote diagnostic use cases can rely on on-board use cases, e.g. to buffer data in case the network is not available. Remote diagnostic use cases include, but are not limited to, the following: information retrieval (e.g. fuel level, battery health check), check running status, configuration, emission check, workshop preparation for service, remote troubleshooting, remote activation of vehicle functionality, software update, firmware update, fleet management, and software configuration.

[0037] Proximity clients denote clients under proximity diagnostic use cases. For proximity diagnostic use cases, it is assumed that a technician or worker is in close proximity to the vehicle and has a test equipment connected to the specific vehicle (either by wire or wirelessly). Proximity diagnostic use cases include, but are not limited to, the following: troubleshooting, performing start-up or stimuli for functional checks, periodic technical check, emission check, check running status, software update, firmware update, and software configuration.

[0038] In-vehicle clients denote clients under on-board diagnostic use cases. For on-board diagnostic use cases, we assume that these use cases can run autonomously within the vehicle without a permanent connection to a remote server or a proximity tester. However, the results of on-board diagnostic use cases can also be accessed through proximity or remote diagnostic use cases. On-board diagnostic use cases include, but are not limited to, the following: on-board monitor, preventive / predictive maintenance, and fleet monitoring scenarios (e.g. periodic collection of vehicle status).

[0039] In one or more embodiments, the SOVD server 1000 receives requests from SOVD clients (not shown in FIG. 1) via a SOVD API interface. In one or more embodiments, the SOVD API interface follows REST principles. This means that diagnostic content is provided in the form of resources. Resources are accessible through their specific resource paths. In the SOVD standard, a resource path consists of the path of a single entity and the standardized resources and resource collections provided for this entity. The operations available for a single diagnostic content are expressed using HTTP methods. In the SOVD standard, the following HTTP methods are used: GET (read content from a resource), PUT (update content of a resource), POST (create a new resource), and DELETE (delete a created resource, reset content to default value).

[0040] FIG. 2 shows a flowchart of a method 2000 performed by a SOVD server (e.g., SOVD server 1000) according to one embodiment of the present application. The method 2000 includes the following steps:

[0041] In step S210, a configuration file (e.g., an XML configuration file) is loaded, which contains information of all entities under the SOVD server;

[0042] In step S220, each configuration node in the configuration file is parsed, and corresponding dynamic library and static library plugins are loaded according to the information and attributes of each configuration node; and

[0043] In step S230, a mapping relationship between a uniform resource locator (URL) corresponding to each configuration node and SOVD adaptation units, SOVD gateway units, and SOVD forwarding units in the SOVD server is saved for subsequent request processing.

[0044] In one embodiment, the XML configuration file contains information of all entities under the SOVD server, each node is parsed when the program is started (e.g., when the vehicle is powered on), information of the corresponding URL is saved, and dynamic libraries and static libraries corresponding to the SOVD adaptation units, SOVD gateway units, and SOVD forwarding units are loaded; when a subsequent HTTP request is received, the URL is directly forwarded to the corresponding units for processing. This scheme guarantees flexibility, can be flexibly configured according to needs, and separates configuration and definition from code, ensuring code clarity and maintainability, and also ensuring loose coupling.

[0045] In one embodiment, the configuration file can be modified to add nodes and corresponding plugin paths. That is, when a URL and corresponding processing logic need to be added, only the nodes and corresponding plugin paths need to be added in the configuration file, which guarantees flexibility and loose coupling characteristics.

[0046] Although not shown in FIG. 2, in one embodiment, the method 2000 further comprises, after receiving the request from the SOVD client, processing the request by the SOVD routing unit to determine whether the instance in the uniform resource locator (URL) of the request belongs to the SOVD adaptation unit, the SOVD gateway unit or the SOVD forwarding unit, and forwarding the request to the corresponding unit for processing; and after the request processing is completed, replying the diagnostic result to the SOVD client.

[0047] For example, the SOVD client sends an HTTP / S request to the SOVD server; after receiving the request, the SOVD server first processes the request by the SOVD routing unit to determine whether the instance in the URL of the current request belongs to the SOVD adaptation unit; if it belongs to the SOVD adaptation unit, it is forwarded to the SOVD adaptation unit, which then processes the HTTP request according to the processing library in the configuration file; if it belongs to the SOVD gateway unit, it is forwarded to the SOVD gateway unit, which then processes the HTTP request according to the processing library in the configuration file; if it belongs to the SOVD forwarding unit, it is forwarded to other SOVD servers. Finally, after the request processing is completed, the SOVD client is replied with the diagnostic result and specific content.

[0048] In addition, those skilled in the art can easily understand that the method 2000 performed by the SOVD server according to one or more embodiments of the present application can be implemented by a computer program. For example, the computer program is contained in a computer program product, and when the computer program is executed by a processor, the method 2000 performed by the SOVD server according to one or more embodiments of the present application is implemented. For another example, when a computer readable storage medium (such as a U disk) containing the computer program is connected to a computer, the computer program is run to perform the method 2000 performed by the SOVD server according to one or more embodiments of the present application.

[0049] In summary, based on the understanding of the vehicle area controller software and the SOVD protocol, the inventors of the present application designed the specific implementation of the vehicle diagnostic SOVD scheme as described above. Each unit in the SOVD server according to the embodiments of the present application has a specified function, and the SOVD routing unit well isolates the SOVD adaptation unit, the SOVD gateway unit and the SOVD forwarding unit. In addition, in one embodiment, the SOVD server uses the configuration file (such as an XML configuration file) to load the nodes of the SOVD adaptation unit, the SOVD gateway unit and the SOVD forwarding unit in the startup process, thereby improving the efficiency of subsequent processing of HTTP requests, and facilitating subsequent node changes and new functions.

[0050] The above examples primarily illustrate the service-oriented vehicle diagnostic (SOVD) approach of the present application. Although only a few implementations of the present application have been described, it will be understood by those skilled in the art that the present application can be practiced in many other forms without departing from the spirit and scope of the application as defined in the claims. Therefore, the examples and implementations described are to be considered as illustrative and not restrictive, and the application is not to be limited to the details given herein but can be practiced with the scope and range of equivalents thereof.

Claims

1. A SOVD server, characterized by, The SOVD server comprises: a SOVD adaptation unit configured to communicate with local entities; a SOVD gateway unit configured to communicate with remote entities; a SOVD forwarding unit configured to communicate with other SOVD servers; and a SOVD routing unit configured to receive requests from a SOVD client and route the requests to the corresponding SOVD adaptation unit, SOVD gateway unit or SOVD forwarding unit according to the entity name or identifier in the requests.

2. The SOVD server of claim 1, wherein, A first high performance computer HPC comprises the SOVD server, and the local entities comprise components, applications and functions in the first high performance computer HPC, and the remote entities comprise one or more electronic control units ECUs and one or more second high performance computers HPCs.

3. The SOVD server of claim 1 or 2, wherein, The SOVD adaptation unit is configured to directly access descriptions of diagnostic capabilities and scopes inside the local entities, and perform read, write or control operations on the local entities according to data and services defined in the descriptions of diagnostic capabilities and scopes.

4. The SOVD server of claim 1 or 2, wherein, The SOVD gateway unit is configured to establish connections and exchange information with the remote entities through UDS, DoIP or SOME / IP protocols.

5. The SOVD server of claim 4, wherein, The SOVD gateway unit is configured to perform read, write or control operations on the remote entities according to diagnostic data and services provided by the remote entities.

6. The SOVD server of claim 1, wherein, The SOVD forwarding unit is configured to transparently pass the requests it receives to other SOVD servers, and forward replies from the other SOVD servers to the SOVD client.

7. The SOVD server of claim 1, wherein, The requests are HTTP / S requests, and the SOVD routing unit is configured to determine to route the requests to the corresponding SOVD adaptation unit, SOVD gateway unit or SOVD forwarding unit according to a uniform resource locator URL in the HTTP / S requests.

8. The SOVD server of claim 4, further comprising: a protocol conversion unit configured to convert HTTP requests received from the SOVD gateway unit into UDS requests and send to corresponding UDS controllers; and convert replies from the UDS controllers into HTTP replies and transmit to the SOVD gateway unit. The SOVD server receives requests from the SOVD client via a SOVD API interface, and the SOVD client comprises an in-vehicle client, a near-field client and a remote client.

9. The SOVD server of claim 1, wherein, The method comprises:

10. A method performed by a SOVD server as claimed in any one of claims 1 to 9, characterized by, loading a configuration file containing information of all entities under the SOVD server; parsing each configuration node in the configuration file and loading corresponding dynamic library and static library plugins according to information and attributes of each configuration node; and saving a mapping relationship between a uniform resource locator URL corresponding to each configuration node and SOVD adaptation units, SOVD gateway units and SOVD forwarding units in the SOVD server, for subsequent request processing. The configuration file can be modified to add nodes and corresponding plugin paths.

11. The method of claim 10, wherein, 12. The method of claim 10, further comprising: ​ After receiving the request from the SOVD client, the request is processed by the SOVD routing unit to determine whether the instance in the uniform resource locator (URL) of the request belongs to the SOVD adaptation unit, the SOVD gateway unit or the SOVD forwarding unit, and the request is forwarded to the corresponding unit for processing; and After the request processing is completed, a diagnosis result is returned to the SOVD client.

13. A computer program product comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the method of any one of claims 10 to 12.

14. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program, when executed by a processor, implements the method of any one of claims 10 to 12.

Images