Computer-implemented method and control device for controlling a unit of an automotive system

Abstract

A computer-implemented method for controlling a unit (152) of an automotive system, wherein an electrical / electronic architecture of the automotive system comprises a first control unit (130), a second control unit (110), and the unit (152) to be controlled, wherein the second control unit (110) is configured by means of a primary software cluster (210) to control the unit (152), and wherein the first control unit (130) is configured by means of a backup software cluster (220) to take over the control of the unit (152) in the event of a failure of the second control unit (110), comprising the steps: - Detect that the control of the unit (152) via the primary software cluster (210) is faulty and / or defective; - Controlling the second control unit (110) by means of the first control unit (130), thereby putting the second control unit (110) into a fail silent state and no longer sending potentially erroneous data; - Control of the unit (152) by means of the backup software cluster (220) of the first control unit (130), whereby the functionality of the unit (152) is maintained, wherein the first control unit (130) has a microcontroller and wherein the second control unit (110) is configured as a vehicle server, has a microprocessor and is configured to execute a Portable Operating System Interface, POSIX, based operating system.

Description

[0001] The present disclosure relates to a computer-implemented method and a control device for controlling a unit of an automotive system, wherein the electrical / electronic architecture of the automotive system comprises a first control unit, a second control unit, and the controlling unit. The first control unit and the second control unit are, for example, electrical control units (ECUs). A software cluster executed in one of the control units is used to control the unit, which is, for example, an actuator or a sensor.

[0002] Current developments in the automotive industry, such as comprehensive driver assistance systems, are leading to exponential growth in the software volume of electronic control units. AUTOSAR Classic describes a standardized software architecture for such electronic control units. In conventional software architectures, the entire software of an electrical control unit must be developed as a holistic and closed element, which not only results in long development times but also in a strong interdependence of all software components. With the introduction of the AR Flex concept, AUTOSAR Classic now offers the possibility of dividing the entire software into individual subcomponents. The application layer of an ECU software is divided into software clusters (SWCLs) that are as independent as possible. All software clusters represent separate components that can be built and loaded separately.In addition to the software architecture, the electrical / electronic architecture of an automotive system is also undergoing profound change. In order to meet the growing demand for computing power in an automotive system without increasing the complexity of the E / E architecture, this is becoming increasingly centralized. Several domain-specific control units are being combined into a few high-performance vehicle servers and master controllers. The focus of the vehicle servers is on high computing power. The master controllers, on the other hand, are used for control tasks, for example. The two different architectures of vehicle servers and master controllers also influence the usable software architecture. The AUTOSAR Adaptive Architecture was designed to ensure optimal use of the resources of a vehicle server. This enables AUTOSAR-compliant software development on a POSIX-based operating system.

[0003] In conventional automotive systems, a unit such as an actuator or a sensor is controlled by a dedicated control unit, which in turn executes the corresponding software. To ensure redundancy in safety-critical units of the automotive system, several hardware components are conventionally installed, each of which can control the corresponding unit in the event of a control unit failure, thus replacing the failed control unit.

[0004] DE 10 2012 002 280 A1 discloses a method for dynamically allocating either a task or data / signal information in a statically embedded architecture of a vehicle.

[0005] DE 199 33 086 A1 discloses a method and a device for mutual monitoring of control units, wherein the control units are constructed from three program levels, a first level for carrying out the control unit functions, a second level for monitoring them and a third level for monitoring the programs of the second level.

[0006] DE 10 2016 106 572 A1 discloses a method for operating a control unit for a vehicle, which has at least one computing unit connected to at least one program memory in which a control program to be executed by the computing unit can be stored or is stored, and to a communication device for receiving a new control program.

[0007] DE 44 39 060 A1 discloses a microprocessor arrangement for a vehicle control system which has a plurality of microprocessor systems interconnected by bus systems, which execute at least one anti-lock brake system (ABS) and traction control system (ASR) as well as at least one further, computationally intensive control function, such as yaw moment control (YMT), and monitoring functions.

[0008] The object of the present disclosure is to provide a method and a device with which an advantageously simple and reliable control of a unit of an automotive system is enabled.

[0009] The object is achieved by a computer-implemented method and a control device having the features of the independent patent claims. Advantageous embodiments of the present disclosure are specified in the dependent claims.

[0010] According to the present disclosure, a computer-implemented method for controlling a unit of an automotive system comprises the following steps. An electrical / electronic architecture of the automotive system comprises a first control unit, a second control unit, and the unit to be controlled. The second control unit is configured to control the unit using a primary software cluster. In other words, the primary software cluster is executed on the second control unit, thereby controlling the unit of the automotive system to be controlled. According to the present disclosure, the first control unit is configured to assume control of the unit using a backup software cluster in the event of a failure of the second control unit. In other words, control of the unit can also be assumed using the backup software cluster, which is executed on the first control unit. The method steps are: - Detecting that the control of the unit via the primary software cluster is faulty and / or defective. According to this method step, for example, during operation of the automotive system, it is detected that the control of the unit via the primary software cluster on the second control unit is faulty and / or defective. Accordingly, the control of the unit via the second control unit does not function properly. - Controlling the second control unit by means of the first control unit, whereby the second control unit is placed into a fail-silent state and no longer sends potentially faulty data. According to this method step, after it has been detected that the control of the unit by means of the primary software cluster is faulty and / or defective, the faulty second control unit is placed into the fail-silent state by control by means of the first control unit, whereby no more faulty control data is sent to the unit of the automotive system to be controlled and / or no more faulty data is sent to other components of the automotive system. The fail-silent state accordingly serves to prevent potential error propagation within the automotive system and simultaneously put the faulty second control unit into a sleep state.According to one embodiment, the fail-silent state is initiated by switching off the corresponding receivers (e.g., ETH transceivers). - Controlling the unit using the backup software cluster of the first control unit, thereby maintaining the functionality of the unit. According to this method step, the control of the unit of the automotive system to be controlled is subsequently ensured by the first control unit, in particular by the backup software cluster, which is executed on the first control unit to control the unit. Accordingly, the functionality of the unit to be controlled can be maintained using the backup software cluster.

[0011] The first control unit has a microcontroller and the second control unit is designed as a vehicle server, has a microprocessor and is designed to execute a Portable Operating System Interface, POSIX, based operating system.

[0012] The first control unit is intended, for example, as a master controller, particularly for control tasks, and has a microcontroller, so that the master controller can advantageously implement the necessary properties for executing control tasks. The second control unit is designed, according to one embodiment, as a vehicle server and has a microprocessor that has the necessary properties to assume the tasks of the vehicle server. The microcontroller has compatibility advantages, since conventional automotive software was designed for microcontroller-based control units. Furthermore, microcontrollers are more cost-effective. Furthermore, software designed for a microcontroller can have higher real-time requirements. Microprocessors have greater computing power and can run POSIX-based operating systems, the use of which increases the compatibility of software with other systems.

[0013] According to the present disclosure, control of the unit can be ensured by means of the backup software cluster of the first control unit, even if the control of the unit by means of the primary software cluster of the second control unit is faulty and / or defective. Accordingly, redundancy can be established within the automotive system for controlling the unit without having to install additional hardware components, but simply by arranging a backup software cluster in another, already existing control unit within the automotive system. According to the present disclosure, advantageous simple and redundant control of the unit of the automotive system can be realized, for example, using the AR Flex concept of AUTOSAR Classic. The redundancy can be realized even if the first and second control units are based on different hardware and software architectures.

[0014] According to one embodiment, the electrical / electronic architecture of the automotive system additionally comprises a third control unit which is designed to receive control commands for controlling the unit from the first control unit or the second control unit, and wherein the control of the unit is carried out via the third control unit. According to one embodiment, the third control unit can be implemented as a virtual application in the first or the second control unit. According to a further embodiment, the third control unit can be installed as a physical additional control unit. The third control unit can, for example, receive control commands from the first or the second control unit, translate these into a language executable for the unit to be controlled, and control the unit to be controlled accordingly.In this regard, the third control unit can be viewed as an intermediary between the first or second control unit and the unit to be controlled. Accordingly, a multitude of different units to be controlled can be controlled by means of the third control unit.

[0015] According to one embodiment, the first control unit is a master controller, and the third control unit is a zone control unit. According to one embodiment, the vehicle server advantageously has high computing power. For example, according to one embodiment, the master controller is configured to assume control tasks within the automotive system, and the zone control unit is configured to assume specific control of a few predefined units, such as actuators and / or sensors, for a specifically predefined zone within the automotive system.

[0016] According to one embodiment, a heartbeat signal is sent continuously or cyclically from the second control unit to the first control unit during operation. The first control unit detects that the control of the unit by the second control unit is faulty or defective if the heartbeat signal is absent or faulty. In other words, the second control unit sends the heartbeat signal continuously or cyclically to the first control unit to communicate its full functionality to the first control unit. As soon as an error or defect occurs within the second control unit, the heartbeat signal is interrupted, whereby the heartbeat signal accordingly does not reach the first control unit.Accordingly, the first control unit can detect that the second control unit is faulty and / or defective, allowing further steps to be initiated to control the unit of the automotive system to be controlled. Using the heartbeat signal, it is therefore advantageous to easily detect whether the second control unit, which assumes control of the unit of the automotive system to be controlled during normal operation, is functioning properly. According to one embodiment, the heartbeat signal is sent by the second control unit every millisecond or every ten milliseconds. A millisecond interval between one and ten milliseconds is also conceivable.

[0017] According to one embodiment, the third control unit is controlled by the first control unit to filter out all data packets received from the second control unit and not to forward them as soon as it detects that the control of the unit by the second control unit is faulty or defective. If, for example, the heartbeat signal from the second control unit is missing, the third control unit is accordingly controlled by the first control unit to filter out or not forward all data packets sent from the second control unit to the third control unit.Accordingly, it is ensured that potentially faulty data packets from the second control unit are not used to control the unit of the automotive system to be controlled, but that control is taken over by means of the backup software cluster on the first control unit and accordingly it is ensured that a functioning software cluster can take over control of the unit to be controlled and is not controlled by faulty data from the second control unit.

[0018] According to one embodiment, the unit is controlled via the first control unit using the backup software cluster. The backup software cluster according to the AR Flex concept in AUTOSAR Classic is the redundant software cluster to the primary software cluster, which is used on the second control unit to control the unit during normal operation of the second control unit. However, if the primary software cluster is faulty or the second control unit is defective or faulty, according to this embodiment, the unit is controlled via the first control unit using the backup software cluster. According to a further embodiment, data required to control the unit and which is transmitted to the second control unit during normal operation is transmitted to the first control unit so that the backup software cluster can properly control the unit of the automotive system.According to a further embodiment, a synchronization is carried out between the primary software cluster and the backup software cluster, so that an advantageous control of the unit to be controlled can be realized.

[0019] According to one embodiment, the unit to be controlled is connected to the first control unit by means of service discovery as soon as it is detected that the control of the unit by means of the second control unit is faulty or defective. According to a further embodiment, the third control unit is connected to the first control unit by means of service discovery as soon as it is detected that the control of the unit by means of the second control unit is faulty or defective. Service discovery refers to the automatic detection of services in a computer network. The “Scalable service Oriented MiddlewarE over IP (SOME / IP)” enables service-oriented transmission of information. Service Discovery Protocol communicates the availability of functional entities, which are called services, in the automotive system. The service cyclically sends “Service Offer” messages to the entire network (broadcast).One or more clients receive this service offer and check whether they want to connect to it. If so, the client sends a Subscribe message to the sender (unicast), which in turn responds with an acknowledge. The client then waits for events from the server. Service discovery is advantageously widespread and standardized and is available in both AUTOSAR Classic and AUTOSAR Adaptive.

[0020] According to one embodiment, the control of the second control unit by the first control unit to place the second control unit into the fail-silent state is carried out using a packet filter. According to this embodiment, all input and output data of the second control unit are filtered out, so that the faulty second control unit does not lead to error propagation and faulty data transmission within the automotive system. According to this embodiment, all data packets with the second control unit (vehicle server) as the sender or receiver are not forwarded or processed. Accordingly, the (defective) second control unit is in a defined and safe state, and the error(s) of the second control unit do not affect the rest of the system.

[0021] According to one embodiment, the unit to be controlled is an actuator, a sensor to be monitored, or another unit to be controlled of an automotive system, or a combination thereof. The unit to be controlled is, for example, an electric machine, a generator, a pressure sensor, a temperature sensor, a drive train or part of a drive train, or another unit to be controlled of the automotive system.

[0022] According to one embodiment, the automotive system additionally has a monitoring unit designed to monitor whether the unit to be controlled is being properly controlled by the backup software cluster of the first control unit. According to this embodiment, the monitoring unit accordingly monitors whether, in the event of a fault in the second control unit, the control of the unit to be controlled is functioning properly by means of the backup software cluster. According to one embodiment, the monitoring unit can be designed, for example, within the first control unit; according to a further embodiment, the monitoring unit can be installed as a separate control unit in the automotive system; or according to a further embodiment, the monitoring unit can also be simply another software cluster designed explicitly for monitoring, implemented within the first control unit.

[0023] According to a further aspect of the present disclosure, a control device for controlling a unit of an automotive system is disclosed, wherein an electrical / electronic architecture of the automotive system comprises a first control unit, a second control unit, and the unit to be controlled, wherein the second control unit is configured to control the unit by means of a primary software cluster, and wherein the first control unit is configured to take over control of the unit by means of a backup software cluster in the event of a fault in the second control unit, wherein the control device is configured to carry out one of the aforementioned methods. The control device according to this aspect can consist of or comprise the first control unit, the second control unit, and the third control unit and / or comprise additional control units.According to a further embodiment, the control device according to this aspect can be installed as part of an additional control unit within the automotive system.

[0024] Embodiments and further developments of the method and device according to the present disclosure are illustrated in the figures and are explained in more detail in the following description.

[0025] They show: Fig. 1 a schematic representation of an EE architecture of an automotive system according to a first embodiment, Fig. 2 a schematic representation of an EE architecture of an automotive system according to a second embodiment, Fig. 3 a schematic representation of an EE architecture of an automotive system according to a third embodiment, Fig. 4 a schematic representation of an EE architecture of an automotive system according to a fourth embodiment, Fig. 5 a schematic representation of a method sequence for controlling a unit according to a first embodiment.

[0026] The Fig. 1 shows an EE / hardware architecture of an automotive system 100. The automotive system 100 has a first vehicle server 110 and a second vehicle server 120. The first vehicle server 110 and the second vehicle server 120 can communicate with each other according to this embodiment. This is schematically illustrated by the dashed line between the first vehicle server 110 and the second vehicle server 120. The automotive system 100 according to this embodiment additionally has a first master controller 130 and a second master controller 140. The master controllers 130, 140 can each communicate with each other and additionally with one of the vehicle servers 110, 120. The first master controller 130 can communicate with the first vehicle server 110 according to this embodiment, and the second master controller 140 can communicate with the second vehicle server 120 according to this embodiment.According to this embodiment, the first master controller 130 is additionally assigned a first sensor 132 and an actuator 134. The first master controller 130 is designed to control the first sensor 132 and to process its sensor data. In addition, the first master controller 130 is designed to control the first actuator 134. The second master controller 140 is assigned an electrical control unit 142, a second sensor 144, and a second actuator 146. The second master controller 140 is designed to control the first electrical control unit and to receive and further process its data. In addition, the second master controller 140 is designed to receive and further process sensor data from the second sensor 144 and, if necessary, to control the second sensor 144. In addition, according to this embodiment, the second master controller 140 is designed to control the second actuator 146.According to this embodiment, the automotive system 100 additionally comprises a first zone control unit 150, a second zone control unit 160, and an eighth zone control unit 170. In the . Fig. Figure 1 schematically illustrates the possibility of installing additional zone control units. The first zone control unit 150, the second zone control unit 160, and the further zone control units up to the eighth zone control unit 170 can communicate with each other.

[0027] According to the embodiment shown in the Fig. 1, the first zone control unit 150 is connected to the first vehicle server 110 and the first master controller 130. Additionally, it is schematically shown that the further zone control units can be or are also connected to the first master controller 130 and the first vehicle server 110 and the second vehicle server 120. According to this embodiment, the first zone control unit 150 is assigned a third actuator 152. The first zone control unit 150 is accordingly designed to control the third actuator 152. The second zone control unit 160 is accordingly assigned a third sensor 162 and a second electrical control unit 164. Accordingly, according to one embodiment, the second zone control unit 160 is designed, for example, to receive and forward the sensor data from the third sensor 162 and, if necessary, to control the third sensor 162.In addition, the second zone control unit 160 is configured to control the second electrical control unit 164 or to receive and forward its data. According to this embodiment, a fourth sensor 172 and a fourth actuator 174 are assigned to the eighth zone control unit 170. The eighth zone control unit is configured to control the fourth sensor 172 or to receive, process, and forward its sensor data. The eighth zone control unit 170 is additionally configured to control the fourth actuator 174 or to implement its control.

[0028] The Fig. 2 shows an EE / hardware architecture detail 200 of the automotive system 100 from Fig. 1. The first vehicle server 110, the first master controller 130, the first zone control unit 150 and the third actuator 152 are shown. As can be seen from Fig. 2, the first vehicle server 110 is configured to control the third actuator 152 via the first zone controller 150. As a backup, the first master controller 130 is configured to control the third actuator 152 via the first zone control unit 150. The first vehicle server 110 has a primary software cluster 210 for controlling the actuator 152. The first master controller 130 has a backup software cluster 220 for controlling the actuator 152 if the primary software cluster 210 cannot be used to control the third actuator 152. Both the first vehicle server 110 and the first master controller 130 have a failure OP agent 230. The failure OP agent 230 (Fail Operational Agent) handles all tasks required to restore the system, in particular monitoring, fail silent, and starting the backup software cluster.

[0029] The OP Agent 230 error allows all tasks required for the recovery process to be collected in a single software component. According to one embodiment, the actual functionality (primary and backup software cluster) can also be executed independently of the OP Agent 230 error.

[0030] The Fig. 3 shows a first network structure 300 between the first vehicle server 110, the first master controller 130 and the third actuator 152. The different components are connected to one another via an Ethernet or CAN connection 310.

[0031] The Fig. 4 shows a second network structure 400 between the first vehicle server 110, the first master controller 130 and the third actuator 152.

[0032] The connection between the individual components according to the second network structure 400 is realized by means of a CAN or LIN connection 410. In the Fig. 4 additionally schematically shows input data 420 which are sent from the third actuator 152 to the first vehicle server 110 and / or to the first master controller 130. Both in Fig. 3 as well as in Fig. 4, the primary software cluster of the first vehicle server 110 is shown schematically. In Fig. 4 also schematically shows a PWM signal 430, which can be sent from the first vehicle server 110 or from the first master controller 130 to the third actuator 152 via a CAN connection. The network structure 400 or the network structure 300 can be used according to the method of the present disclosure to control the unit to be controlled. The method according to the present disclosure can therefore be flexibly applied to various architectures. This allows cost advantages to be realized, since CAN or LIN architectures are more cost-effective than ETH architectures. In addition, ETH is a relatively complex protocol that requires comparatively powerful computer hardware. CAN or LIN architectures can be implemented with inexpensive hardware.

[0033] The Fig. 5 corresponds in its schematic structure to the Fig. 2, additionally shows the Fig.5, however, shows a flowchart 500 of the method according to the present disclosure. In a first step 510, the first master controller 130 detects that the first vehicle server 110 is not correctly or properly performing its tasks for controlling the third actuator 152. According to one embodiment, simple monitoring can be implemented using a so-called heartbeat signal, which the first vehicle server 110 cyclically sends to the first master controller 130. Due to the absence of the heartbeat signal, the first master controller 130 detects a malfunction of the vehicle server 110.

[0034] By means of the second step 520, the flowchart 500 schematically illustrates that the first master controller 130 ensures that the first vehicle server 110 switches to fail-silent mode and accordingly behaves in fail-silent mode, preventing it from transmitting potentially faulty data. To this end, the first master controller 130 additionally instructs the first zone control unit 150 to filter out all data packets sent by the first vehicle server 110 and not to forward them, thereby preventing control of the third actuator 152 by the faulty first vehicle server 110 or by the faulty primary software cluster 210.

[0035] In a third step 530 of the flowchart 500, it is schematically shown that the first master controller 130 continues the critical functionality of the third actuator 152. For this purpose, the backup software cluster 220 of the first master controller is switched from a so-called hot standby status to an active mode. This means that the backup software cluster 220 of the first master controller 130 is continuously executed and accordingly receives the same input values ​​as the primary software cluster 210 of the first vehicle server 110. Only the output of the backup software cluster 210 is not forwarded to the third actuator 152 outside of the error case. To continue the safety-critical function by the first master controller 130, activating the output of the backup software cluster 220 is thus sufficient.

[0036] In a fourth step 540, the flowchart 500 schematically illustrates that the third actuator must also receive the output of the backup software cluster 220. For this, the backup software cluster 220 must connect to the first zone control unit 150 of the master controller 130 using a service discovery so that it can control the actuator 152 via the latter. The service discovery reconfigures the system so that the third actuator 152 can exchange data with the backup software cluster 220 of the first master controller 130. If the service discovery was successful, the function of the third actuator 152 is restored using the backup software cluster 220 on the first master controller 130, and the automotive system 100 functions properly again.

Claims

[1] A computer-implemented method for controlling a unit (152) of an automotive system, wherein an electrical / electronic architecture of the automotive system comprises a first control unit (130), a second control unit (110) and the unit (152) to be controlled, wherein the second control unit (110) is configured to control the unit (152) by means of a primary software cluster (210), and wherein the first control unit (130) is configured to take over control of the unit (152) in the event of a fault in the second control unit (110), comprising the steps of: - detecting that the control of the unit (152) by means of the primary software cluster (210) is faulty and / or defective; - controlling the second control unit (110) by means of the first control unit (130), whereby the second control unit (110) is put into a fail-silent state and no longer sends potentially faulty data; - controlling the unit (152) by means of the backup software cluster (220) of the first control unit (130), whereby the functionality of the unit (152) is maintained, wherein the first control unit (130) comprises a microcontroller and wherein the second control unit (110) is designed as a vehicle server, has a microprocessor and is designed to execute a Portable Operating System Interface, POSIX, based operating system. [2] Computer-implemented method according to claim 1, wherein the electrical / electronic architecture of the automotive system further comprises a third control unit (150) configured to receive control commands for controlling the unit (152) from the first control unit (130) or the second control unit (110), to translate the control commands into a language executable by the unit (152) to be controlled, and to control the unit (152) to be controlled accordingly. [3] Computer-implemented method according to one of the preceding claims, wherein the first control unit (130) is a master controller, and / or the third control unit (150) is a zone control unit. [4] Computer-implemented method according to one of the preceding claims, wherein a heartbeat signal is sent continuously or cyclically from the second control unit (110) to the first control unit (130), and the first control unit (130) detects that the control of the unit (152) by means of the second control unit (110) is faulty or defective if the heartbeat signal is absent or faulty. [5] Computer-implemented method according to one of the preceding claims, wherein the unit to be controlled (152) or the third control unit (150) is controlled by the first control unit (130) to filter out all data packets received from the second control unit (110) and not to forward them as soon as it is detected that the control of the unit (152) by means of the second control unit (110) is faulty or defective. [6] Computer-implemented method according to one of the preceding claims, wherein the unit (152) is connected to the first control unit (130) by means of a service discovery as soon as it is detected that the control of the unit (152) by means of the second control unit (110) is faulty or defective. [7] Computer-implemented method according to one of the preceding claims, wherein the controlling of the second control unit (110) by means of the first control unit (130) for setting the second control unit (110) into the fail-silent state is carried out by means of a packet filter. [8] Computer-implemented method according to one of the preceding claims, wherein the unit (152) to be controlled is an actuator (152), a sensor to be monitored, or another unit of an automotive system to be controlled, or a combination thereof. [9] Computer-implemented method according to one of the preceding claims, wherein the automotive system additionally comprises a monitoring unit configured to monitor whether the unit (152) to be controlled is properly controlled by means of the backup software cluster (210) of the first control unit (130). [10] Control device for controlling a unit (152) of an automotive system, wherein the electrical / electronic architecture of the automotive system comprises a first control unit (130), a second control unit (110) and the unit (152) to be controlled, wherein the second control unit (110) is designed to control the unit (152) by means of a primary software cluster (210) and wherein the first control unit (130) is designed to take over control of the unit (152) by means of a backup software cluster (220) in the event of a fault in the second control unit (110), wherein the control device is designed to carry out one of the methods according to claims 1 to 9.

Images