CN117793136A - Method and system for distributing diagnostic/refresh data/messages - Google Patents

Abstract

The present invention relates to a method and system for distributing diagnostic/refresh data/messages. The method comprises the following steps: distributing diagnostic/refresh data/messages from one or more first diagnostic/refresh tools to a first type of Electronic Control Unit (ECU) via a first router running on a first operating system; distributing diagnostic/refresh data/messages from one or more second diagnostic/refresh tools to a second type of Electronic Control Unit (ECU) via a second router running a second operating system different from the first operating system; and performing diagnostic/refresh data/message interactions across the first router and the second router via a connection interface between the first router and the second router.

Description

Method and system for distributing diagnostic/refresh data/messages

Technical Field

The present invention relates to the field of in-vehicle electronic systems, and more particularly, to a diagnostic/refresh router having a novel architecture for efficiently transmitting/distributing diagnostic/refresh data/messages when diagnosing/refreshing various in-vehicle systems.

Background

In the current vehicle-mounted electronic system, diagnosis/refresh routing is generally implemented by adopting an Autosar (AUTomotive Open System Architecture: automobile open system architecture) CP (Classical Platform: classical platform) protocol stack-specified Pdur (Protocol Data Unit Router: protocol data unit router) module, and a service layer DCM (Data Communication Module: data communication module) and a CANTp (Controller Area Network Transmission Protocol: controller local area network transmission layer) of a lower transmission layer, a SoAd (Socket Adapter: socket Adapter) or a DoIP (Diagnostic over Internet Protocol: IP diagnosis) module. The diagnostic/refresh routing function is mostly implemented on an RTOS (Real Time Operating System: real-time operating system) system, and for a diagnostic router supporting ethernet refresh, a large amount of RAM (random-access memory) resources of the RTOS system need to be consumed, which disadvantageously limits the functional expansion of the RTOS system. Various diagnosis/refresh tools are mainly accessed from an OBD (On-Board diagnostics) system through a CAN bus or an Ethernet, and for the CAN bus refresh tools, the refresh speed of an Ethernet ECU (Electronic ControlUnit: an electronic control unit, also called a "driving computer", "On-board computer", etc.) is slow, and if the Ethernet ECU is refreshed at a production line, the operation efficiency of the production line is low. If an ethernet diagnostic/refresh tool is used to enable simultaneous refresh of multiple CAN ECUs and ethernet ECUs, it is likely that the RTOS system will be operating overload, resulting in system dysfunction.

Accordingly, there is a need for methods and systems for improving existing diagnostic/refresh routing mechanisms.

Disclosure of Invention

To solve or at least alleviate one or more of the above problems, the present invention provides the following technical solutions.

According to a first aspect of the present invention, there is provided a method for distributing diagnostic/refresh data/messages. The method comprises the following steps: distributing diagnostic/refresh data/messages from one or more first diagnostic/refresh tools to a first type of Electronic Control Unit (ECU) via a first router running on a first operating system; distributing diagnostic/refresh data/messages from one or more second diagnostic/refresh tools to a second type of Electronic Control Unit (ECU) via a second router running a second operating system that is different from the first operating system; and performing diagnostic/refresh data/message interactions across the first router and the second router via a connection interface between the first router and the second router.

Additionally or alternatively, the first diagnostic/refresh tool is coupled to the first router via a first OBD interface and the second diagnostic/refresh tool is coupled to the second router via a second OBD interface. Preferably, the first OBD interface and the second OBD interface are the same OBD interface. The method further includes distributing the diagnostic/refresh data/messages from the first diagnostic/refresh tool directly to the first type of electronic control unit via a CAN driver coupled to the first OBD interface.

According to a second aspect of the present invention, there is provided a system for distributing diagnostic/refresh data/messages. The system comprises: a first router running on the first operating system for distributing diagnostic/refresh data/messages from one or more first diagnostic/refresh tools to a first type of Electronic Control Unit (ECU); a second router running on a second operating system different from the first operating system for distributing diagnostic/refresh data/messages from the one or more second diagnostic/refresh tools to a second type of Electronic Control Unit (ECU); and a connection interface between the first router and the second router for diagnostic/refresh data/message interactions across the first router and the second router.

Additionally or alternatively, the system further comprises first and second OBD interfaces, wherein a first diagnostic/refresh tool is coupled to the first router via the first OBD interface, and wherein a second diagnostic/refresh tool is coupled to the second router via the second OBD interface. Preferably, the first OBD interface and the second OBD interface are the same OBD interface.

Additionally or alternatively, the system further comprises a CAN driver, wherein the first diagnostic/refresh tool is coupled to the CAN driver via the first OBD interface, and wherein the CAN driver is configured to distribute diagnostic/refresh data/messages from the first diagnostic/refresh tool directly to the first type of electronic control unit.

According to a third aspect of the present invention, an in-vehicle electronic system is provided. The in-vehicle electronic system includes an in-vehicle processor and an in-vehicle memory storing computer instructions that, when executed by the in-vehicle processor, perform various methods in accordance with the present invention.

According to a fourth aspect of the present invention, an in-vehicle electronic system is provided. The in-vehicle electronic system comprises a system for distributing diagnostic/refresh data/messages according to the invention.

According to a fifth aspect of the present invention there is provided a computer readable storage medium storing computer instructions which, when executed by an on-board processor, cause the on-board processor to perform the various methods according to the present invention.

Drawings

The foregoing and/or other aspects and advantages of the present invention will become more apparent and more readily appreciated from the following description of the various aspects taken in conjunction with the accompanying drawings in which like or similar elements are designated with the same reference numerals. In the drawings:

FIG. 1 illustrates a diagnostic/refresh system block diagram according to one embodiment of the present invention;

FIG. 2 illustrates a diagnostic/refresh router system architecture diagram according to one embodiment of the present invention;

FIG. 3 illustrates a multi-node parallel diagnostic/refresh schematic according to one embodiment of the present invention;

FIG. 4 illustrates a schematic diagram of CAN diagnostic/refresh routing scheme optimization utilizing an OBD interface in accordance with one embodiment of the invention; and

fig. 5 shows a flow chart of a method of distributing diagnostic/refresh data/messages according to one embodiment of the invention.

Detailed Description

The following description of the specific embodiments is merely exemplary in nature and is in no way intended to limit the disclosed technology or the application and uses of the disclosed technology. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, or the following detailed description.

In the following detailed description of embodiments, numerous specific details are set forth in order to provide a more thorough understanding of the disclosed technology. It will be apparent, however, to one skilled in the art that the disclosed techniques may be practiced without these specific details. In other instances, well-known features have not been described in detail so as not to unnecessarily complicate the description.

Terms such as "comprising" and "including" mean that in addition to having elements and steps that are directly and explicitly recited in the description, the inventive aspects also do not exclude the presence of other elements and steps not directly or explicitly recited.

DoIP is an ethernet transport layer protocol specifically used for diagnostic/refresh communications that can support the use of diagnostic tools, gateways, and in-vehicle ethernet nodes. The diagnostic/refresh router is capable of distributing or transmitting diagnostic/refresh messages according to specific rules onto a designated bus or network, and generally includes several parts/stages of receipt of diagnostic/refresh messages, firewall filtering, protocol conversion, and transmission of diagnostic/refresh messages. The efficiency of the diagnostic/refresh router is directly related to the diagnostic/refresh rate, thereby affecting production efficiency of the production line and after-market refresh and in-vehicle node OTA (remote refresh) upgrade rate. With the continuous expansion of automobile functions, the vehicle-mounted electronic control system is more and more complex, the software packages of parts in the automobile are also continuously increased, and even after sales, many parts are still in iterative updating, so that the expandability and the efficiency of the diagnosis/refresh router system are particularly important.

As described above, the current diagnostic/refresh routing function is mostly implemented on the RTOS system, and for the diagnostic router supporting ethernet refresh, a large amount of RAM resources of the RTOS system needs to be consumed, which disadvantageously limits the functional expansion of the RTOS system. Various diagnostic/refresh tools are then mainly accessed from the OBD via the CAN bus or ethernet, and for CAN bus refresh tools, the ethernet ECU speed is slow and if the ethernet ECU is refreshed on the production line, this CAN result in inefficient operation of the production line. If an ethernet diagnostic/refresh tool is used to enable simultaneous refresh of multiple CAN ECUs and ethernet ECUs, it is likely that the RTOS system will be operating overload, resulting in system dysfunction.

Chinese patent application number CN201610644872.0, publication number CN107707418a and entitled "a communication diagnostic system, communication diagnostic/refresh method and process" supports refreshing CAN ECU by ethernet tool. Chinese patent application No. CN201910185855.9, publication No. CN111694335A and entitled "a vehicle ECU diagnostic method and system thereof, gateway device" relates to performing diagnostic routing through the gateway device, processing a diagnostic request of an external device, and replying to a node in a vehicle. The Chinese patent application with application number of CN202010161693.8 and publication number of CN113377393A and named as diagnosis/refreshing system and method of vehicle-mounted system master node is realized by a diagnosis router at an RTOS core, and because an Ethernet protocol stack is required to be realized at the RTOS core, a large amount of RAM resources are consumed and more RTOS system load is occupied.

In order to solve/alleviate one or more of the above-mentioned problems, the present invention proposes a diagnostic/refresh router having a novel architecture for efficiently transmitting/distributing diagnostic/refresh data/messages including various data, software updates, diagnostic/refresh commands and/or requests, diagnostic/refresh parameters, etc. related to a diagnostic/refresh operation when diagnosing or refreshing an in-vehicle electronic system, and may also include various data, replies, acknowledgements, etc. associated with the result of the diagnostic/refresh operation execution.

FIG. 1 illustrates a block diagram of a diagnostic/refresh system included in an in-vehicle electronic system, according to one embodiment of the present invention. The in-vehicle electronic system includes a diagnostic/refresh system according to the present invention and an in-vehicle processor or controller (not shown) that can run computer instructions stored in-vehicle memory to control the various operations of the various software, hardware and/or firmware in the in-vehicle electronic system.

As shown in fig. 1, the diagnostic/refresh system includes an in-vehicle CANECU, an in-vehicle ethernet ECU, a diagnostic/refresh router, and a plurality of different diagnostic/refresh tools supported by the diagnostic/refresh router, including but not limited to an off-vehicle DoIP diagnostic/refresh tool, an off-vehicle CAN diagnostic/refresh tool, an in-vehicle ethernet diagnostic/refresh tool, an in-vehicle CAN diagnostic/refresh tool, an OTA, and the like. The in-vehicle CANECU, the in-vehicle ethernet ECU, the diagnostic/refresh router, and the various diagnostic/refresh tools communicate with each other via corresponding buses/connections. The diagnostic/refresh router routes diagnostic/refresh related data and/or various commands or messages between these diagnostic/refresh tools and the in-vehicle CAN ECU and/or the in-vehicle ethernet ECU via the respective buses.

FIG. 2 illustrates a diagnostic/refresh router system architecture diagram according to one embodiment of the present invention. As shown in fig. 2, the diagnostic/refresh router System may be implemented on a SOC (System on Chip: system on Chip) platform across an RTOS System and a HLOS (High level Operating System: advanced operating System) System, wherein the diagnostic/refresh router functions may be implemented separately at the RTOS System and the HLOS System, respectively.

In one example, the RTOS system diagnostic/refresh router includes a self-diagnostic/refresh server module, diagServer1, a router module, a CAN protocol stack, and a CAN Driver (CAN Driver) to route diagnostic/refresh related data and/or various commands or messages between a CAN ECU (not shown in FIG. 2) connected to the CAN Driver and various diagnostic/refresh tools. In one example, the RTOS system directly interfaces to each CAN bus and communicates directly with the off/in-vehicle CAN diagnostic/refresh tool and the in-vehicle CANECU.

In one example, the HLOS system diagnostic/refresh router includes OTA functionality, OTA underlying udsceent (Unified Diagnostic Services Client: unified diagnostic services client) middleware, self-diagnostic Server module diagnostics Server2, router module diagnostics router2, ethernet transport layer DoIP Server (DoIP Server), UDSonEth (UDS on Ethernet: UDS on Ethernet) module, and TCP/IP protocol stack to route diagnostic/refresh related data and/or various commands or messages between an Ethernet ECU (not shown in fig. 2) connected to the TCP/IP protocol stack and various diagnostic/refresh tools. In one example, the HLOS system accesses the ethernet and communicates directly with the off-board DoIP diagnostic/refresh tool, the in-vehicle ethernet diagnostic/refresh tool, and the in-vehicle ethernet ECU.

In one example, a DoIP Server is implemented in the HLOS system, and DoIP diagnostics/refresh is accessed in-vehicle through 100BaseTx ethernet of OBD port, thereby enabling fast in-vehicle transmission of large amounts of diagnostics/refresh data/messages. In one example, the OTA functionality is also implemented in the HLOS system, interacting with the HLOS system diagnostic/refresh router through a custom interface. The HLOS system diagnosis/refreshing router converts the diagnosis/refreshing message sent by the OTA software into a corresponding transmission layer protocol message and routes the message to a corresponding bus. In one example, an on-board ethernet diagnostic tool is deployed on an in-vehicle ethernet ECU in direct communication with a HLOS system diagnostic/refresh router.

In one example, the CAN diagnostic/refresh tool accesses the RTOS system diagnostic/refresh router through the OBD interface. The RTOS system CAN support data transmission at a 5MB rate and a single frame 64Byte length so that the CAN diagnostic/refresh tool CAN quickly diagnose/refresh an in-vehicle CAN ECU via the RTOS system. The on-board CAN diagnostic tool is deployed on the in-vehicle CAN ECU and is in direct communication with the RTOS system.

In one example, the RTOS system diagnostic/refresh router and the HLOS system diagnostic/refresh router communicate with each other via inter-core communication IPC to communicate diagnostic/refresh data and/or messages across the network. For this purpose, the RTOS system diagnostic/refresh router further includes IPC adaptation layers ipc_adaptation 1 and IPC driver IPC1, and the HLOS system diagnostic/refresh router further includes IPC adaptation layers ipc_adaptation 2 and IPC driver IPC2, so that diagnostic/refresh data and/or messages across the network are transferred between the RTOS system and the HLOS system through inter-core communication IPC via IPC driver IPC1 and IPC driver IPC 2.

FIG. 3 illustrates a multi-node parallel diagnostic/refresh schematic according to one embodiment of the present invention. As shown in fig. 3, the HLOS system accesses the ethernet, directly communicates with the off-board DoIP diagnostic/refresh tool (DoIP Tester), the in-vehicle ethernet diagnostic tool, and the in-vehicle ethernet ECU (Eth ECU), while the RTOS system directly interfaces to the various CAN buses, and directly communicates with the off-board/in-vehicle CAN diagnostic/refresh tool and the in-vehicle CAN ECU.

In one example, diagnostic/refresh data/messages from one or more DoIP testers are transmitted via connection (1), connection (2) and connection (3) to diagnostic/refresh server module DiagRouter2 through the TCP/IP protocol stack and the DoIP server in the HLOS system. The diag router2 parses the received diagnostic/refresh data/messages and transmits the diagnostic/refresh data/messages related to the ethernet ECU (EthECU) to the Eth ECU via the connection (a.4), the connection (a.5) and the connection (a.6), through the UDSonEth module and the TCP/IP protocol stack, and then the Eth ECU performs a corresponding diagnostic/refresh operation according to the received diagnostic/refresh data/messages, and a corresponding diagnostic/refresh operation execution result is transferred from the Eth ECU to the diag router2 via the connection (a.7), the connection (a.8) and the connection (a.9).

When the diagRouter2 in the HLOS system parses the received diagnostic/refresh data/message into the diagnostic/refresh data/message associated with the CAN ECU, the diagRouter2 transmits the parsed diagnostic/refresh data/message to the router module diagRouter in the RTOS system via the connection (b.4), the connection (b.5), the connection (b.6), the connection (b.7) and the connection (b.8) through the IPC adaptation layers IPC_Adapter2 and IPC driving IPC2 in the HLOS system and the IPC driving IPC I and IPC adaptation layers IPC_Adapter1 in the RTOS system. The DiagRouter1 in the RTOS system forwards the received diagnostic/refresh data/messages via connection (b.9), connection (b.10) and connection (b.11) to the CANECU via the CAN protocol stack and CAN driver in the RTOS system. Based on the received diagnosis/refresh data/message, the CAN ECU performs a corresponding diagnosis/refresh operation, and a result of the execution of the corresponding diagnosis/refresh operation is transmitted from the CAN ECU to the DiagRouter1 in the RTOS system via the connection (b.12), the connection (b.13), and the connection (b.14). Then, the DiagRouter1 in the RTOS system forwards via connection (b.15), connection (b.16), connection (b.17), connection (b.18) and connection (b.19) to the DiagRouter2 in the HLOS system through the IPC adaptation layers ipc_adaptation 1 and IPC driver IPC i in the RTOS system and the IPC driver IPC2 and IPC adaptation layer ipc_adaptation 2 in the HLOS system.

The DiagRouter2 in the HLOS system transmits the diagnosis/refresh operation execution result from the CAN ECU and the diagnosis/refresh operation execution result from the Eth ECU together or separately to the DoIP Tester through the DoIP server and the TCP/IP protocol stack in the HLOS system via the connection (20), the connection (21) and the connection (22) to display the corresponding diagnosis/refresh operation execution result to the user.

In one example, one or more CAN diagnostic/refresh tools are directly connected to CAN drivers in an RTOS system. Diagnostic/refresh data/messages from the CAN diagnostic/refresh tool are distributed to DiagRouter1 in the RTOS system via CAN drivers and CAN protocol stacks in the RTOS system. The diagnostic router1 in the RTOS system analyzes the received diagnosis/refreshing data/message, forwards the diagnosis/refreshing data/message which is obtained by analysis and is related to the CAN ECU through a CAN protocol stack and a CAN driver in the RTOS system, and forwards the diagnosis/refreshing operation execution result which is fed back by the CAN ECU to a corresponding CAN diagnosis/refreshing tool.

When the diagRouter1 in the RTOS system analyzes the diagnostic/refresh data/message associated with the Eth ECU from the received diagnostic/refresh data/message, the diagRouter1 in the RTOS system distributes the analyzed diagnostic/refresh data/message to the diagRouter2 in the HLOS system via the IPC adaptation layer and the IPC driver in the RTOS system and the IPC adaptation layer and the IPC driver in the HLOS system. The diag router2 in the HLOS system forwards the received diagnostic/refresh data/message to the Eth ECU, and forwards the diagnostic/refresh operation execution result from the Eth ECU back to the diag router1 in the RTOS system via inter-core communication IPC between the diag router1 and the diag router2. Then, the DiagRouter1 in the RTOS system transmits the diagnosis/refresh operation execution result from the Eth ECU to the corresponding CAN diagnosis/refresh tool to display the corresponding diagnosis/refresh operation execution result to the user.

The invention realizes that the Ethernet ECU refresh packets are larger, the transmission time is longer, the CAN ECU refresh packets are smaller, but the single frame transmission bytes are less, and the bottleneck is mainly time-consuming for forwarding the CAN bus by the RTOS system for the refresh of the CAN ECU. Therefore, the method CAN adopt a mode of refreshing with a plurality of CAN ECUs in parallel when refreshing the Ethernet ECU, and the Ethernet ECU replies a gap, and CAN refreshing data is transmitted to the CAN ECU through the RTOS system, so that the RTOS system router and the HLOS system router work simultaneously. Meanwhile, refreshing data are transmitted to the Ethernet ECU and the CAN ECU, and refreshing time CAN be reduced by nearly 50% through reasonable combination. For the production line refreshing, the multi-DOIP and CAN diagnosis/refreshing tools CAN be supported to refresh simultaneously, the CAN refreshing tools directly refresh a plurality of CAN ECUs in parallel through the RTOS diagnosis/refreshing router, and the DOIP refreshing tools directly refresh the Ethernet ECUs through the HLOS system, so that the production line refreshing time CAN be saved to a greater extent.

Fig. 4 shows a schematic diagram of a CAN diagnostic/refresh routing scheme optimization using an OBD interface according to one embodiment of the present invention, wherein CAN Tester refers to CAN diagnostic/refresh tools, including off-board and/or on-board CAN diagnostic/refresh tools, and canter is connected to CAN drivers via the OBD interface. The left figure shows that the off-or in-vehicle CAN diagnostic/refresh tool routes diagnostic/refresh data/messages to the CAN ECU via the DiagRouter1 and CAN protocol stack in the RTOS system to diagnose/refresh the CAN ECU. The right figure shows an optimized scheme for implementing CAN diagnosis/refresh routing by using an OBD interface when an in-vehicle or off-vehicle CAN diagnosis/refresh tool is used to diagnose/refresh an in-vehicle CAN ECU, wherein, unlike the left figure in which a manner of routing diagnosis/refresh data/messages from a DiagRouter1 and CAN protocol stack in an RTOS system to the CAN ECU is used, the diagnosis/refresh data/messages CAN be routed directly from the CAN diagnosis/refresh tool to the CAN ECU via the CAN interface, which CAN effectively reduce CAN protocol stack overhead and routing time.

Fig. 5 shows a flow chart of a method of distributing diagnostic/refresh data/messages according to one embodiment of the invention. As shown in fig. 5, the method includes distributing diagnostic/refresh data/messages from one or more first diagnostic/refresh tools to a first type of Electronic Control Unit (ECU) via a first router running on a first operating system, step 501. In one example, the first operating system is an RTOS system, the first router is an RTOS router, the first diagnostic/refresh tool is an internal/external CAN diagnostic/refresh tool, and the first ECU is an on-board CAN ECU.

The method further includes distributing, at step 502, diagnostic/refresh data/messages from one or more second diagnostic/refresh tools to a second type of Electronic Control Unit (ECU) via a second router running a second operating system that is different from the first operating system. In one example, the second operating system is a HLOS system, the second router is a HLOS router, the second diagnostic/refresh tool is an off-vehicle DoIP diagnostic/refresh tool and/or an in-vehicle ethernet diagnostic/refresh tool, and the second ECU is an on-board ethernet ECU.

The method further includes performing diagnostic/refresh data/message interactions across the first router and the second router via a connection interface between the first router and the second router at step 503. In one example, the connection interface includes a first IPC interface running on a first operating system and a second IPC interface running on a second operating system, the first and second IPC interfaces being connected to each other.

In one example, the first router and the second router are disposed on a system on a chip (SoC).

In one example, the first and second routers are configured to distribute diagnostic/refresh data/messages from the first diagnostic/refresh tool and/or the second diagnostic/refresh tool to the first and/or second type of electronic control units in parallel.

In one example, a first diagnostic/refresh tool is coupled to a first router via a first OBD interface and a second diagnostic/refresh tool is coupled to a second router via a second OBD interface. Additionally or alternatively, the method further includes distributing the diagnostic/refresh data/messages from the first diagnostic/refresh tool directly to the first type of electronic control unit via a CAN driver coupled to the first OBD interface at step 504.

By adopting one or more of the above technical schemes provided by the invention, one or more of the following benefits can be obtained:

at least two routers are arranged on the SOC platform and span a HLOS (such as linux, QNX and the like) system and an RTOS system;

support diagnostic/refresh routing between various in-vehicle ECU and in-vehicle off-vehicle diagnostic/refresh tools, support the conversion of various different transport layer protocols, such as UDSonCAN, UDSonEth, UDSonIPC;

for the diagnosis/refreshing request/reply between the in-car/out-car Ethernet diagnosis/refreshing tool and the CAN ECU and the diagnosis/refreshing request/reply between the in-car/out-car CAN diagnosis/refreshing tool and the Ethernet ECU, the method for supporting inter-core communication IPC is distributed, so that the diagnosis/refreshing message is rapidly transmitted between an RTOS system and an HLOS system, and the routing performance and the diagnosis/refreshing speed are improved;

aiming at the diagnosis/refreshing request and reply between the in-vehicle/out-vehicle CAN diagnosis/refreshing tool and the CAN node, the direct routing at the CAN Driver layer is supported, and the routing performance and the diagnosis/refreshing speed are improved;

aiming at diagnosis/refresh of the Ethernet node, diagnosis/refresh messages are directly distributed through the HLOS system, so that RAM resources of the RTOS system are greatly saved and diagnosis/refresh efficiency is improved;

and the production line parallel diagnosis/refresh and OTA parallel upgrade are supported, so that the whole vehicle diagnosis/refresh speed is greatly increased. Using hierarchical diagnostic/refresh routers, diagnostic/refresh time can be maximized, balancing the load of the RTOS system and the HLOS system at the time of diagnosis/refresh.

The embodiments and examples set forth herein are presented to best explain the embodiments consistent with the invention and its particular application and to thereby enable those skilled in the art to make and use the invention. However, those skilled in the art will appreciate that the foregoing description and examples have been provided for the purpose of illustration and example only. The description as set forth is not intended to cover various aspects of the invention or to limit the invention to the precise form disclosed.

Claims (21)

1. A method for distributing diagnostic/refresh data/messages, the method comprising:

distributing diagnostic/refresh data/messages from one or more first diagnostic/refresh tools to a first type of Electronic Control Unit (ECU) via a first router running on a first operating system;

distributing diagnostic/refresh data/messages from one or more second diagnostic/refresh tools to a second type of Electronic Control Unit (ECU) via a second router running a second operating system different from the first operating system; and

diagnostic/refresh data/message interactions are performed across the first router and the second router via a connection interface between the first router and the second router.

2. The method of claim 1, wherein the connection interface comprises a first IPC interface running on the first operating system and a second IPC interface running on the second operating system, the first IPC interface and the second IPC interface being connected to each other.

3. The method of claim 1, wherein the first router and the second router are disposed on a system on a chip (SOC).

4. The method of claim 1, wherein the first router and the second router are configured to distribute diagnostic/refresh data/messages from the first diagnostic/refresh tool and/or the second diagnostic/refresh tool to the first type and/or second type of electronic control units in parallel.

5. The method of any of claims 1-4, wherein the first operating system comprises a real-time operating system (RTOS) and the second real-time operating system comprises a high-level operating system (HLOS).

6. The method of claim 5, wherein the first diagnostic/refresh tool is a Controller Area Network (CAN) diagnostic/refresh tool and the second diagnostic/refresh tool is an IP diagnostic (DoIP) diagnostic/refresh tool.

7. The method of claim 6, wherein the first type of electronic control unit is a CAN electronic control unit and the second type of electronic control unit is an ethernet electronic control unit.

8. The method of claim 7, wherein the first diagnostic/refresh tool is coupled to the first router via a first on-board automatic diagnostic system (OBD) interface, and wherein the second diagnostic/refresh tool is coupled to the second router via a second OBD interface.

9. The method of claim 8, further comprising:

the diagnostic/refresh data/messages from the first diagnostic/refresh tool are distributed directly to the first type of electronic control unit via a CAN driver coupled with the first OBD interface.

10. A computer readable storage medium storing computer instructions which, when executed by an onboard processor, cause the onboard processor to perform the method of any one of claims 1-9.

11. A system for distributing diagnostic/refresh data/messages, the system comprising:

a first router running on the first operating system for distributing diagnostic/refresh data/messages from one or more first diagnostic/refresh tools to a first type of Electronic Control Unit (ECU);

a second router running on a second operating system different from the first operating system for distributing diagnostic/refresh data/messages from one or more second diagnostic/refresh tools to a second type of Electronic Control Unit (ECU); and

and a connection interface between the first router and the second router for performing diagnostic/refresh data/message interactions across the first router and the second router.

12. The system of claim 11, wherein the connection interface comprises a first IPC interface running on the first operating system and a second IPC interface running on the second operating system, the first IPC interface and the second IPC interface being connected to each other.

13. The system of claim 11, wherein the first router and the second router are disposed on a system on a chip (SOC).

14. The system of claim 11, wherein the first router and the second router are configured to distribute diagnostic/refresh data/messages from the first diagnostic/refresh tool and/or the second diagnostic/refresh tool to the first type and/or second type of electronic control units in parallel.

15. The system of any of claims 11-14, wherein the first operating system comprises a real-time operating system (RTOS) and the second real-time operating system comprises a high-level operating system (HLOS).

16. The system of claim 15, wherein the first diagnostic/refresh tool is a Controller Area Network (CAN) diagnostic/refresh tool and the second diagnostic/refresh tool is an IP diagnostic (DoIP) diagnostic/refresh tool.

17. The system of claim 16, wherein the first type of electronic control unit is a CAN electronic control unit and the second type of electronic control unit is an ethernet electronic control unit.

18. The system of claim 17, further comprising first and second on-board automatic diagnostic system (OBD) interfaces, wherein the first diagnostic/refresh tool is coupled to the first router via the first OBD interface, and wherein the second diagnostic/refresh tool is coupled to the second router via a second OBD interface.

19. The system of claim 18, further comprising a CAN driver, wherein the first diagnostic/refresh tool is coupled to the CAN driver via a first OBD interface, and wherein the CAN driver is configured to distribute diagnostic/refresh data/messages from the first diagnostic/refresh tool directly to the first type of electronic control unit.

20. An in-vehicle electronic system, comprising:

a vehicle-mounted processor; and

an in-vehicle memory storing computer instructions which, when executed by the in-vehicle processor, perform the method of any one of claims 1-9.

21. An in-vehicle electronic system comprising a system for distributing diagnostic/refresh data/messages according to any of claims 11-19.