WO2019096713A1

WO2019096713A1 - Method and device for data-oriented information exchange with a vehicle network

Info

Publication number: WO2019096713A1
Application number: PCT/EP2018/080849
Authority: WO
Inventors: Daniel Krippner; Dennis Grewe; Marco Andreas Wagner
Original assignee: Robert Bosch Gmbh
Priority date: 2017-11-16
Filing date: 2018-11-12
Publication date: 2019-05-23
Also published as: DE102017220472A1

Abstract

A method (10) for data-oriented information exchange with a vehicle network (11), characterised by the following features: - a connection control unit (12) of the vehicle network (11) receives an external interest query, which designates data available via the vehicle network (11), - the vehicle network (11) forwards (13) the interest query within the vehicle network (11) on a case-by-case basis using the designated data, and - the connection control unit (12) sends back a data response depending on the interest query.

Description

description

title

Method and device for data-oriented information exchange with a vehicle network

The present invention relates to a method for data-oriented

Exchange of information with a vehicle network. The present invention also relates to a corresponding device, a corresponding computer program and a corresponding storage medium.

State of the art

In automotive engineering, the vehicle diagnostic system (DA) is any software or hardware application that can be used over the life of a motor vehicle to diagnose any malfunction. In addition to development and production, the said service life includes, in particular, the maintenance and servicing of the vehicle in specialist workshops within the scope of the so-called secondary market (aftermarket). Among other things, vehicle diagnostic systems use the capability of individual ECUs for on-board diagnostics (OBD). In conjunction with an evaluation of the

Data bus communication allows this approach a detailed error analysis.

The prior art includes in particular portable test equipment

C, Diagnostic Tester ") in the form of a tablet PC with wired or wireless communication module and preinstalled diagnostic software for maintenance, troubleshooting and repair. Advanced systems of this kind support the construction of a so-called networked workshop (connected workshop) or allow the updating of the installed software via the Air interface (over the air, OTA) while the device is in use. For this purpose, some devices are equipped with a cellular, WIFI or Bluetooth interface.

DE102011075432A1 discloses a vehicle diagnostic support data structure that maps a component model of a vehicle to components of the vehicle, each attribute being associated with attributes, using terminology with terminology terms of technical terms to uniquely identify the attributes. The data structure has components, data on components and / or

Attributes and structures with relationships between the components and / or attributes. Components may include other components. The data collection allows navigation among components or attributes using a navigation perspective, displaying data associated with the component or attribute under the navigation perspective.

Disclosure of the invention

The invention provides a method for data-oriented information exchange with a vehicle network, a corresponding device

corresponding computer program and a corresponding storage medium according to the independent claims ready.

An advantage of this solution lies in the possible omission of hard-coded

Diagnostic functionality and communication paths - traditionally mostly based on statically defined network architectures - for the benefit of one

Approach where diagnostic data and functionality are named

Data elements are made available based on network or protocol stack inherent intelligence, caching, buffering and routing. This approach is aimed at next-generation vehicle electronics architectures, at the node of which such capabilities can be created, but moreover adapted, during the design phase, using the network bandwidth and computing capacity available in the vehicle. The measures listed in the dependent claims are advantageous developments and improvements of the independent

Claim specified basic idea possible. Thus, central approaches of information-centric networking (ICN) can be taken up. A corresponding embodiment works for this purpose at the level of named data and function objects (named function networking, NFN), which are directly accessible via suitable naming schemes and thus from their physical location, e.g. B. a certain

Control unit (electronic control unit, ECU) are decoupled. This decoupling allows processing and keeping already computed results in the network without the need for low-level, bit and byte data definitions or static routing configurations.

An embodiment of the invention overcomes in this way the disadvantages of a conventional, usually completely static distribution. To this end, it treats the data itself as a unit essential for the dissemination of information and enables its processing and caching in the network, as well as dynamic routing and forwarding within variable ones

Network topologies.

A preferred variant complements the already mentioned approaches by already anchored in the design of authentication and security and uses this to an integrated encryption and authentication to data and

Function object level so that data receivers are reliable in the authenticity and protection of data or functional requirements they receive

can guarantee.

Another advantage of the invention is the avoidance of a

connection-oriented data exchange ^: The underlying mechanisms ICN and NFN are to implement a loosely coupled, z. B. pull-based communication model particularly suitable in which - instead of a fixed connection between two endpoints - is used to named data or function objects and the network topology can change dynamically, while the data exchange remains active and intelligent caching and routing strategies to optimize network utilization for the application come. This also enables the creation of content server entities that can store information in an easily accessible network location and thus relieve the burden on smaller controllers and the network as a whole.

BRIEF DESCRIPTION OF THE DRAWINGS Exemplary embodiments of the invention are illustrated in the drawings and explained in more detail in the following description. It shows:

FIG. 1 shows the external request for the version number of an ECU.

Figure 2, the requirement of a brake light control.

Figure 3 shows the transfer of large amounts of unstructured data (bulk data) for the reflash of the ECU, using caching in the network.

Figure 4 shows the exemplary E / E architecture of a vehicle of the next

Generation.

Embodiments of the Invention One of the objectives of vehicle diagnosis is usually to

To access information (data) pertaining to a business or organization

other condition, configuration, repair or software update inside and outside a vehicle. For example, by a diagnostic tester in-vehicle diagnostic data

(for example, the static version number of a given

Hardware device) wired or wireless. Also considered is access to data via a cloud infrastructure and corresponding radio interfaces while driving. FIG. 1 shows an example

Use case that covers just these processes in sequence. A - connected for example via OBD - diagnostic tester (15) requires the hardware version number of a particular application control device here (17) in the vehicle network (11), for example, as part of a

Inventory to gain an overview of the relevant vehicle for a maintenance record. In order to access the desired information, the diagnostic tester (15) creates a so-called INTEREST packet containing the name (for example, vin / ecu / version / hw ") of the desired

Information includes, and sends it to the vehicle network (11). The INTEREST packet is transmitted via the vehicle network (11) - for example a connection control device (12) and a domain control device (16) - to

Application control device (17) via a communication path (13) forwarded, which provides said information. Each intermediate node - z. B. the connection controller (12) - is able to check its local memory (cache) to the requested information (22), the z. B. could have been cached as part of a previously processed request. This behavior may depend on the ICN approach used and the configuration of the particular intermediate node.

When the INTEREST packet reaches the application controller (17), it is forwarded to the local application (31). In the next step (32), the application generates a DATA packet containing the desired content (eg, the hardware version) and hands the packet over to the ICN / NFN protocol stack. On a INTEREST packet opposite communication path (13), the DATA packet is then forwarded to the diagnostic tester (15). Each intermediate node - again, for example, the connection control unit (12) - can store the DATA packet with regard to renewed requests optionally in its local memory (cache) (21).

In the further course of the outlined application, a cloud backend (14) must also be based on the hardware number of the in-vehicle

Application control device (17) access to the rollout of a new

To coordinate firmware updates. The backend (14) sends for this purpose

INTEREST package specifying the same name (for example

, vin / ecu / version / hw "). If the INTEREST package is the

Reached connection controller (12), this node first searches its local cache for a copy of the desired data object (22) and responds accordingly if necessary (23). This procedure (22, 23) reduces the use of the bandwidth of the vehicle network (11) to transmit static content.

A second use case group of the vehicle diagnosis comprises the

Modifying the database on which ECUs operate and changing the state or behavior of a function of ECUs in the vehicle.

As an example of this application case group, the actuation (switching on) of a brake light is shown in FIG. This operation is also wired or wirelessly requested by the diagnostic tester (15) by the appropriate function notation of an INTEREST packet - for example, under designation of, / vin / ecu / brakeLight (setTo = ON) "- made. The INTEREST packet is transmitted via the vehicle network (11) by means of the

Connection control unit (12) and domain control unit (16) for

Application control unit (17) forwarded (13), which provides the functionality (31). Each intermediate node - z. The connection controller (12) - is able to check its local memory (cache) for the requested function (22).

When the INTEREST packet reaches the application controller (17) which provides the brake light actuation functionality, the packet is forwarded to the local application (22). In the next step, the application executes the operation (31), generates a DATA packet that transmits the result of the operation - for example, the brake light status - and passes the packet to the ICN / NFN protocol stack (32). On a communication path (13) directed counter to the INTEREST packet, the DATA packet is finally forwarded to the diagnostic tester (15).

A third use case group of vehicle diagnostics includes the

Transfer of large amounts of data, such as for updating

ECUs or for retrieving large amounts of data stored in the vehicle (for example as part of a performance monitoring or the

Acquisition of maintenance-related wear information). As an example of this use case group, Figure 3 shows how the

ICN / NFN networking in the vehicle network (11) can be combined with cloud-based command, control and data storage systems to enable flash over the air firmware updates (FOTA).

This update procedure for a particular application control device (17) is initiated by a cloud-based FOTA backend (14), using a

corresponding functional notation of an INTEREST packet is issued to instruct the vehicle network (11) to retrieve the so-called flash data from a data container (19) of the backend (14), for instance by specifying the name, vin / goFetch (flashData = ECUA, Version = 11) ". The INTEREST packet is received by a data memory manager (18) in the vehicle network (11).

- Illustratively about in the connection control unit (12) - processed, in turn, an INTEREST packet to the data container (19) of the

Backends (14) sent to request the relevant data, for example, with the name "getFlashData (flashData = ECUA, Version = 11)". The data container (19) of the backend (14) responds with a DATA packet containing the bulk data content stored in the local cache of the

Connection control unit (12) is stored. The

Data storage manager (18) generates a DATA packet in response to the initial INTEREST and forwards it to the FOTA backend (14). The FOTA backend (14) next sends an INTEREST packet to the

Vehicle network (11) to initiate the reprogramming sequence (34) on the application control device (17), such as the name, vin / doFlash (flashData = ECUA, Version = 11) ". This INTEREST is forwarded by the connection controller (12) via the vehicle network (11) until it reaches the domain controller (16), which in turn provides a local update agent (20) that can handle this INTEREST. Said update agent (20) in turn issues an INTEREST to retrieve the flash data needed for updating (34) the application control device (17) and propagates it via the vehicle network (11), for example, naming / getFlashData ( flashData = ECUA, version = 11) ". This INTEREST is received by the connection controller (12) which finds the requested data in its local cache (22) and the corresponding DATA packet to the update agent (20) back (23) can. The update agent (20) now uses all to update the

Application control device (17) suitable means, such as a conventional UDS-on-CAN update sequence (34). After

Completion, the update agent (20) generates a corresponding to the INTEREST

DATA packet forwarded from the ICN / NFN vehicle network (11) to the FOTA backend (14) (13).

Variations of this scenario are conceivable in which z. B. the off-board systems not cloud-based, but operated by workshop computers or update agents and data storage manager (18) are distributed differently in the system, without departing from the scope of the invention. Likewise, different implementation depths of ICN / NFN networking are in one

Vehicle network (11) conceivable. One option here is a complete implementation that covers an ICN / NFN that includes all control units in the vehicle network (11). Also the coding of the names of the data and

Functions may vary depending on the application, with hierarchical names - eg. As unified resource identifier (URI) -, flat, about hash-based names or a combination of both coding variants may be used. Another option, finally illustrated in FIG. 4, is a partial one

ICN / NFN implementation in which only the higher-level control devices such as connection control device (12) and domain control device (16) implement ION or NFN and legacy control devices (17) in their domain for connecting conventional protocols such as UDS or DolP in the vehicle network (11) Meet gateway-like features (25).

Claims

claims

A method (10) for exchanging information with a vehicle network (11), characterized by the following features:

a connection control device (12) of the vehicle network (11) receives an external request for interest, which is transmitted via the

Vehicle Network (11) names available data,

- The vehicle network (11) takes on a case by case basis of the named data forwarding (13) of the request for interest within the vehicle network (11) before and

- The connection control unit (12) returns a dependent of the request for interest data response back.

2. Method (10) according to claim 1,

characterized by one of the following features:

the request for interest is sent by a backend (14),

the request for interest is sent by a diagnostic tester (15) or

- the request for interest is from another display device,

especially a mobile device with an app sent

3. The method (10) according to claim 1 or 2,

characterized by the following features:

- The request for interest is forwarded to a domain controller (16) (13) and

- The domain controller (16) initiates the request for interest to

Application control unit (17) on (13).

4. The method (10) according to claim 3,

characterized by the following features:

the application control device (17) forwards the request for interest to an application (31) and

the application control device (17) receives (32) the data response from the application.

5. The method (10) according to claim 3,

characterized by the following features:

the request for interest is processed by a data storage manager (18) of the connection control device (12) depending on the named data,

- The data storage manager (18) retrieves content from an external

Data container (19) from (33) and

an update agent (20) of the domain controller (16) updates (34) the application controller (17) with the retrieved contents.

6. The method (10) according to one of claims 1 to 5,

characterized by the following features:

at least the connection control device (12) adds the respectively returned data response to a local cache (21),

- When receiving a further interest request, a query (22) of the cache is made to the named data and

if the query (22) succeeds, the data response is returned from the cache (23).

7. Method (10) according to one of claims 1 to 6,

characterized by the following features:

the connection controller (12) receives the request for interest and provides the data response via a wireless network connection (24) and

- the forwarding (13) takes place case by case

Interface control devices (25) by means of Ethernet (26), Flexray (27),

CAN (28), LIN (29) or MOST (30).

8. Computer program, which is configured to carry out the method (10) according to one of claims 1 to 7.

9. A machine-readable storage medium on which the computer program according to claim 8 is stored.

A device (11, 12, 14-20) adapted to carry out the method (10) according to any one of claims 1 to 7.