WO2018146000A1

WO2018146000A1 - Control unit for a motor vehicle and corresponding motor vehicle

Info

Publication number: WO2018146000A1
Application number: PCT/EP2018/052568
Authority: WO
Inventors: Rainer Baumgaertner; Michael Poehnl
Original assignee: Robert Bosch Gmbh
Priority date: 2017-02-08
Filing date: 2018-02-01
Publication date: 2018-08-16
Also published as: CN110291504B; CN110291504A; DE102017201966A1

Abstract

The invention relates to a control unit (10) for a motor vehicle, characterized by the following features: the control unit (10) is designed to operate a plurality of applications (11) and middleware programs (12), the control unit (10) comprises a memory (23), which can be jointly used by the applications (11) and the middleware programs (12), and the middleware programs (12) are designed to handle interprocess communication (29) between the applications (11) via the memory (23).

Description

Description title

Control device for a motor vehicle and corresponding motor vehicle

The present invention relates to a control device for a motor vehicle. The present invention also relates to a corresponding motor vehicle and a corresponding method.

State of the art

The term highly automated driving (HAD) commonly designates a developmental stage between assisted driving in which the driver is assisted by numerous (often separate) driver assistance systems in the driving task, and autonomous driving in which the vehicle is entirely self-propelled without driver intervention. In highly automated driving, the vehicle has its own intelligence, so to speak, which could plan ahead and take over the driving task, at least in most situations. Drivers and electronic control units (ECUs) together drive the vehicle, with the human driver always determining how much he is interfering with the handling of the vehicle.

US 2013/0145482 AI describes a vehicle that has one or more

Implemented processing modules. These modules are configured to connect to the various buses in the vehicle with the various buses connected to the various components of the vehicle to facilitate information transfer between the vehicles

To facilitate vehicle components. Each processing module is further modularized with the ability to add and replace other functional modules now or in the future. These function modules can themselves as independent vehicle components act. Each processing module can handle processing to other modules depending on its health,

Processing load or transferred by external control. Thus, the plurality of processing modules, a middleware control point for the vehicle with redundancy in the processing and the safety and security helps

Implement security awareness in their applications.

US 2007/076593 A1 discloses a vehicle control system having a plurality of nodes connected to a communication network for performing coordinated operations based on data sent over the communication network for controlling the vehicle, each of the nodes comprising: a node status Determination section that receives node status data from other nodes via the communication network and determines node status indicating one or more of a failure state and a non-failure state of the plurality of nodes, a node status evaluation result transmission / reception section for transmitting

Node status data including node status of the own node and the other nodes designated by the node status determination section to the other nodes and receiving node status data including node status of the own node and the other nodes designated by other nodes and sent via the communication network and a failure node identification section that identifies a failed node connected to the communication network based on the node status data including node status of the own node and the other nodes designated by the node status determination section and sent from the other nodes, the operations in the node status determination section, the node status evaluation result transmission / reception section and the failure node identification section, in synchronization with communications between the own node and the other nodes via the communication network z is executed and the failing node identification section is implemented with a middleware that includes an application program interface, the one the result of the failure node identification one

Provides control application program that runs on its own node. Disclosure of the invention

The invention provides a control device for a motor vehicle and a

corresponding motor vehicle and method according to the independent

Claims ready. The approach according to the invention is based on the finding that numerous driver assistance systems for highly automated driving are currently in the development phase. The realization requires the mastery of large systems. Especially the distribution of subtasks to different ones

ECUs places increased demands on the communication between the subtasks. A service layer of

Intermediate applications (middleware) should be the flexible distribution of

Enable subtasks.

Therefore, an efficient middleware approach is presented. This approach is based on inter-process communication (IPC) and shared memory. Such a thing

Services layer eliminates unnecessary copying of data or blocking of applications and thus proves to be highly efficient.

The approach discussed below may be used to design a

Reference platform software architecture for HAD serve and permitted

in particular a real-time processing of large amounts of data from several

Sensors as well as the communication of the vehicle with his

Environment (Car2X) with highest reliability, reliability and reliability

Protection against unauthorized manipulation. In this way, modern multi-core and in particular multi-core controllers are supported and, due to their increased performance potential, a wide variety of

Consumer electronics (CE) borrowed components. Overall, the proposed solution thus meets the highest requirements in terms of efficiency, scalability and maintainability, portability, data encapsulation, standard conformity and interchangeability, for example of software and in particular firmware via the air interface (software over the air, SOTA, firmware over the air, FOTA). The measures listed in the dependent claims are advantageous developments and improvements of the independent

Claim specified basic idea possible. Thus it can be provided that the controller and the operating system make a separation between the applications in such a way that certain applications do not become one

Access to the shared memory are authorized. It is particularly advantageous that the solution contains a flexible method for separation. The efficiency of the realization is largely maintained.

According to a further aspect, it may be provided that the control device further comprises a memory management unit (MMU) to perform the separation. A separation of different memory areas can thus be advantageously represented in corresponding hardware.

According to a further aspect, it may be provided that the applications access the intermediate applications via an intermediate application interface, which in turn has standardized interfaces

Operating system, data connections, controller abstraction layer,

Microcontroller abstraction layer, complex drivers or other services of the base software access. The traffic is thus completely abstracted by the service layer. Even a distribution of applications to different ECUs is possible, provided that latency and quality of service can be guaranteed.

Finally, in another aspect, a POSIX compliant

Operating system such as QNX be provided for the controller. In the latter case, said separation between applications may be through adaptive partitioning (AP) of the application software. An appropriate scheduler allows the designer of the real-time system to specify that a certain amount of processing resources be reserved for a particular partition - that is, a group of activity threads or threads that make up a subsystem. Brief description of the drawings

Embodiments of the invention are illustrated in the drawings and explained in more detail in the following description. It shows:

FIG. 1 shows an inter-application-oriented approach according to FIG

proposed solution strategy.

FIG. 2 shows the data traffic between control units by means of a

service layer according to the invention.

FIG. 3 shows the control unit-internal data traffic by means of the service layer according to the invention.

FIG. 4 shows a solution strategy for using shared memory in the context of an efficient intermediate application approach

Interprocess communication.

FIG. 5 Basics of the separation.

FIG. 6 shows the effect of the separation in connection with FIG

Between applications.

Figure 7 shows a solution strategy for inter-process communication while maintaining the separation of areas with different security requirements.

FIG. 8 shows the inter-process communication via shared memory while maintaining the separation of areas with different ones

Safety requirements.

Embodiments of the invention

Figure 1 illustrates an inter-application approach according to the proposed solution strategy. Applications (11) use the application programming interface (API) here special intermediate applications (12). Data traffic is handled exclusively via the intermediate applications (12), which enables portability, scalability and reusability, data encapsulation, etc. Such an approach could be, for example, within the framework of a future definition

track adaptive and open automotive system architecture (AUTOSAR).

FIG. 2 illustrates the data traffic between control devices by means of a service layer according to the invention. Each control unit (10) operates the specific one in addition to the AU TOS AR basic software (15)

HAD application software (14). The basic software (15) includes

According to the invention, the intermediate applications (12) of the service layer, while the application software (14) comprises the individual applications (11) in the strict sense. Like the applications (11) over a

The intermediate application interface (13) accesses the intermediate applications (12), the latter in turn access the operating system (17), data connection (18), control device abstraction layer (19), microcontroller abstraction layer (20), complex drivers (21) or others via standardized interfaces (16) Services of the basic software (15) too.

FIG. 3 shows, in a corresponding representation, the data traffic by means of the service layer according to the invention within a single one

Control unit (10). Such an efficient control unit internal

Interprocess communication (29) is controlled by selected elements

for example, in the context of AUTOSAR in combination with a suitable shared memory API (23) allows and provides a

Key capability of embedded HAD systems.

FIG. 4 illustrates a solution strategy for using shared memory (23) in the context of the approach discussed. The control unit (10) comprises such by various applications (11) and

Inter-application (12) shared memory (23) over which one of the intermediate applications (31) handles the inter-process communication (29) between applications A and B. The latter are in this case subject to the same security requirements imposed by a common Automotive safety integrity level (ASIL) designated A, B, C, D or QM. (This given

Safety requirement level carries the following representative

Reference X.)

The principles of separation (25) will now be explained with reference to FIG. POSIX-compliant operating systems such as QNX allow such a separation of applications (11) at the process level, which is therefore likely to be implemented as part of a future, adaptive AUTOSAR implementation. (This of course also applies to non-POSIX-compliant systems that contain appropriate mechanisms.) For this purpose, the control unit (10) comprises a memory management unit-not shown as such. When using a corresponding operating system (17) such as QNX whose microkernel supports the runtime separation (25) by an adaptive partitioning of the application software (14). Separate

Execution strands (24) within a process can not be easily separated in this way.

It should be noted that the exemplarily quoted QNX represents only one of numerous conceivable target operating systems. Nevertheless, the mechanisms described are also conceivable in the environment of other operating systems. Even a hypervisor approach may benefit from an embodiment of the invention.

The function of the intermediate applications (12) according to the invention in this context can be seen in FIG. 6. If one considers the range defined by the given security requirement level (X), then the separation (25) within this range can be due to the development process of the software and, in particular, stringent stratification be enforced. Where this is not possible - for example in cross-sector communication with applications (11) at a lower security requirement level (Y) - explicit mechanisms are required. Figure 7 illustrates such a mechanism for

Interprocess communication (29) while maintaining the separation of areas with different security requirements. While a first

Intermediate application (31) operates on said security requirement level (X), some applications (11) access a second intermediate application of lesser security requirement level (Y). Those applications (11) which access both the first intermediate application (31) and the second intermediate application (32) serve at the same time as

Safety limiter (26) between the safety requirement levels (X, Y).

The function of sharable memory (23) in this constellation is illustrated in FIG. 8: unlike Privileged Application A, nonprivileged application C does not have access to shared memory (23) in this scenario (28). The highest

Security level operated and correspondingly privileged application A also acts as a safety limiter (27) for cross-sector access to the memory (23) by means of the second intermediate application (32).

Claims

Control unit (10) for a motor vehicle,

characterized by the following features:

the control unit (10) is set up to operate a plurality of applications (11) and intermediate applications (12),

- The controller (10) comprises a by the applications (11) and intermediate applications (12) shared memory (23) and

- the intermediate applications (12) are set up, one

Interprocess communication (29) between the applications (11) via the memory (23) handle.

Control device (10) according to claim 1,

characterized by the following features:

the control device (10) is set up to operate an application software (14), in particular for a driver assistance system for highly automated driving of the motor vehicle and a basic software (15),

the basic software (15) comprises the intermediate applications (12) and

- The application software (14) includes the applications (11).

Control device (10) according to claim 2,

characterized by the following features:

- The applications (11) are set up via a

Intermediate application interface (13) on the

Intermediate applications (12) to access and

the intermediate applications (12) are set up, via standardized interfaces (16), to an operating system (17), a

Data link (18), a controller abstraction layer (19), a microcontroller abstraction layer (20), complex drivers (21) or other services (22) of the base software (15).

Control device (10) according to claim 3,

characterized by the following features:

the applications (11) include privileged applications (A, B) and nonprivileged applications (C), - The applications (11) each have at least one

Execution strand (24) on and

the control unit (10) and operating system (17) are set up,

between the applications (11) to perform a separation (25) such that the nonprivileged applications (C) are not authorized to access the sharable memory (23).

5. Control device (10) according to claim 4,

characterized by the following features:

- The controller (10) further comprises a memory management unit and

- The memory management unit is set up to perform the separation (25).

6. Control device (10) according to claim 4 or 5,

characterized by the following features:

for a given security requirement level (X) of the

Motor vehicle, the intermediate applications (12) include a first intermediate application (31) on said

Security requirement level (X) and at least a second one

Intermediate application (32) on lesser

Security requirement level (Y) and

those applications (11) which apply both to the first intermediate application (31) and to the second one

Intermediate application (32) are set up as safety limiters (26) between the safety requirement levels (X, Y).

7. Control device (10) according to one of claims 4 to 6,

characterized by the following feature:

- The operating system (17) is POSIX compliant.

8. Control device (10) according to claim 7,

characterized by the following feature:

The operating system (17) is QNX. Control device (10) according to claim 8,

characterized by the following feature:

- The separation (25) is carried out by an adaptive Partitionieru application software (14).

10. Motor vehicle with a control device (10) according to one of claims 1 to 9.

11. Method for controlling a motor vehicle

characterized by the following features:

- several applications (11) and intermediate applications (12) are operated on a common control unit (10),

- A memory (23) of the control unit (10) is shared by the applications (11) and intermediate applications (12) and

- Inter-process communication (29) between the applications (11) is handled by the intermediate applications (12) via the memory (23).

12. The method according to claim 11,

characterized by the following features:

an application software (14) is operated by the control unit (10) in particular for a driver assistance system for highly automated driving of the motor vehicle and basic software (15),

the basic software (15) comprises the intermediate applications (12) and

- The application software (14) includes the applications (11).

13. The method according to claim 12,

characterized by the following features:

- The applications (11) have access to one

Intermediate application interface (13) on the

Intermediate applications (12) to and

the intermediate applications (12) use standardized

Interfaces (16) to an operating system (17), a

Data link (18), a controller abstraction layer (19), a microcontroller abstraction layer (20), complex drivers

(21) or other services (22) of the basic software (15).