Method for assigning software components to control device architecture
Through the application of software components and optimizing the algorithm, the problem of transfer and adaptation of software in different control devices in the existing technologies has been solved, and efficient resource utilization and functional distribution is realized.
Patent Information
- Application Number
- CN202380044190.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2022-04-01
- Filing Date
- 2023-02-27
- Publication Date
- 2025-01-24
AI Technical Summary
The prior art is difficult to efficiently transfer and adapt application software and complex drivers between different control devices, resulting in limitations in software functions and uneven utilization of resources.
By classifying the software component into the category of near -hardware and far hardware, and the optimization algorithm is used to allocate according to the characteristics and boundary conditions of the control equipment architecture, optimizing the distribution of software components to achieve more efficient resource use and functional distribution.
It realizes the efficient distribution of software components among multiple control devices, reduces the cost and time of software adaptation, and improves the uniform utilization of resources and the distribution efficiency of functions.
Smart Images
Figure CN119365850A_ABST
Abstract
Description
Technical Field
[0001] The invention relates to a method for assigning a group of software components to a control unit architecture, as well as to a corresponding control unit architecture, a computing unit and a computer program for carrying out the method. Background Art
[0002] Electronic control devices are used in the automotive field and in other technical fields, such as facility control, for a large number of functions that require any type of control or regulation. Usually, for example, there are multiple control devices with different tasks in a vehicle, which are networked to each other. Here, not only the control device architecture in the vehicle, that is, the number and structure of networked control devices, but also the software functions in the control device can be implemented in different ways. For example, a decentralized control device architecture limited to basic functions can be set in a simple vehicle, or an architecture with a central control device and many extended functionalities can be set in an advanced vehicle. Here, for cost reasons, the hardware resources in the control device are often insufficiently arranged. In principle, it is therefore desirable to distribute the desired functionality in the total system to the existing control devices as efficiently as possible.
[0003] The AUTOSAR (AUTomotive Open System ARchitecture) standard is often used for software of all types of control devices. In this case, a layer architecture is used, in which the application software is abstracted from the hardware of the control unit by so-called basic software and runtime environment. Through this universal solution, the basic software can also be further used on similar microcontroller series, so that control devices with similar configurations can use the same basic software. However, the following problem often occurs for application software, that is, although in theory the application software can also be used on other control devices through the abstraction of the layer, in fact many functions use specific hardware interfaces of the control device, which are addressed via complex drivers (complex device drivers). Therefore, usually each control device develops its own software, so that the software functions can often only run with specific hardware and cannot be transferred to other control devices. However, if a transfer is set, the application software and the corresponding complex driver must often be redeveloped or greatly modified in order to run in the new environment. Summary of the invention
[0004] According to the invention, a method for assigning a set of software components to a control device architecture is proposed, as well as a corresponding control device architecture, a computing unit and a computer program for carrying out the method, having the features of the independent patent claims. Advantageous embodiments are the subject matter of the dependent claims and the following description.
[0005] In particular, a method for distributing a group of software components to a control device architecture having a plurality of interconnected control devices is proposed, wherein executable software functionality is defined by a sequence chain of the group of software components. The method firstly comprises, for each software component from the group of software components, detecting a classification, wherein the classification comprises at least one or more near hardware classes, which are assigned to software components whose functions are associated with a hardware interface of at least one specific control device, and wherein the classification comprises at least one or more far hardware classes, which are assigned to software components whose functions are not associated with hardware elements of a specific control device. Furthermore, the characteristics of the control device architecture are detected, wherein the detected characteristics comprise at least the number of control devices and the available resources for each control device. The number of software components in the group, the classification for each software component, the sequence chain of the software components and the characteristics of the control architecture are then input as input values of an optimization algorithm. Furthermore, additional boundary conditions for the software components and / or the control device architecture are input into the optimization algorithm.
[0006] At least one unique assignment of each software component from the group of software components to a plurality of control devices is then determined as an output value of the optimization algorithm, wherein the assignment is optimized according to predefined parameters for executing the executable software functionality and wherein the assignment is performed by the optimization algorithm according to a classification of each of the software components.
[0007] The classification used by the individual software components allows better separation of near hardware components from far hardware components. This also allows better classification of implicit dependencies of software components within the executable software chain, which makes distribution to multiple control devices simpler and better possible.
[0008] This also significantly reduces the complexity of adapting the software when transferring it from one control unit to another.
[0009] Taking boundary conditions into account in the optimization method ensures that only functionalities that can actually be implemented are formed in the result, ie, an optimized allocation of software components.
[0010] The predefined parameters on which the optimization allocation is based can include, in particular, waiting times for executing executable software functionalities and / or uniform utilization of the resources of the control unit.
[0011] For example, one or more of the following can be used as additional boundary conditions for each of the software components during optimization: the processor load of the software component, the memory consumption of the software component, the communication bandwidth required between two software components, the message frequency required for communication between two software components, the dependency between two or more of the software components, the waiting time of the software components, the communication protocol used, the hardware or software interface used by the software components.
[0012] Likewise, the characteristics of the control device architecture and / or additional boundary conditions for use in the optimization of the control device architecture may include at least one of the following: computing power provided by the control device, available memory size, the communication protocol used, the message type used, the available communication bandwidth between two control devices, respectively, information about the output stage installed in the control device, information about additional specific hardware interfaces in the control device, available inputs and outputs of the control device, and a safety rating.
[0013] For example, the proposed method can be used in a control device architecture implemented according to the AUTOSAR standard. In particular, a near hardware class can then be assigned to a "complex device driver" of the AUTOSAR layer structure, and a far hardware class can be assigned to an application software of the AUTOSAR layer structure. The additional classification and the defined interfaces between the individual classes make it possible to execute software components of the application software separately from software components of the "complex device driver" on different control devices, which software components are otherwise present in AUTOSAR as monolithic blocks specific to the control device.
[0014] For this refinement of the classification, in a possible implementation one or more near-hardware categories may be selected from: a first category of software components for performing manipulation of hardware inputs and outputs; and a second category of software components for performing abstractions of hardware manipulations.
[0015] Furthermore, when classifying, one or more far hardware classes can be selected from: a third class for software components for executing at least one of control, regulation or signal processing; a fourth class for software components for executing superordinate state control; and a fifth class for software components for forming predicted values and / or performing parameter modeling. This subdivision of the far hardware and near hardware software parts enables a better separation of functionalities (separation of concerns) and thus a more targeted allocation to other control devices in the system according to their classification and other boundary conditions.
[0016] In particular, an evolutionary algorithm may be used as the optimization algorithm; however, other known optimization algorithms may also be used.
[0017] A computing unit, for example a control unit of a motor vehicle, a computer suitable for software development or a group of connected computing units is configured in particular in terms of programming to carry out the method according to the invention.
[0018] It is also advantageous to implement the method according to the invention in the form of a computer program or computer program product with a program code for performing all method steps, because this causes particularly low costs. Finally, a machine-readable storage medium is provided, with a computer program as described above stored thereon. Suitable storage media or data carriers for providing computer programs are especially magnetic, optical and electrical memories, such as hard disks, flash memories, EEPROMs, DVDs, etc. It is also possible to download programs via computer networks (the Internet, intranets, etc.). Such downloading can be done wired or with cables or wirelessly (e.g., via WLAN networks, 3G, 4G, 5G or 6G connections, etc.) at this point.
[0019] Further advantages and embodiments of the invention are apparent from the description and the accompanying drawings.
[0020] The invention is schematically illustrated in the drawings on the basis of exemplary embodiments and is described below with reference to the drawings. BRIEF DESCRIPTION OF THE DRAWINGS
[0021] Figure 1 The software architecture according to the AUTOSAR standard in the prior art is schematically shown.
[0022] Figure 2 An example of distributing a software component to multiple control devices is shown, and
[0023] Figure 3 Possible method steps according to an exemplary embodiment are shown. DETAILED DESCRIPTION
[0024] Figure 1 The schematic diagram shows a common layer architecture of software according to the AUTOSAR standard, as can be used in the prior art for electronic control units (ECUs), in particular in the automotive field. A layered abstraction of the software is provided, wherein a basic software (BSW) with various abstract modules 120, 130, 140, 150 is used, which coordinates the functionality between the application layer 170 and the processing unit or microcontroller 110 of the control unit. Between the modules of the basic software and the application layer 170 is a runtime environment 160 (RTE), which implements the data exchange between the two layers.
[0025] The basic software has a common scheme so that it can be used flexibly on similar microcontroller series. Therefore, the individual modules of the basic software are defined in detail in the AUTOSAR standard. The microcontroller abstraction layer 130 (MCAL) includes internal drivers for accessing the memory, communication and input / output (I / O) of the microcontroller. The control device abstraction layer 120 (ECU Abstraction Layer, ECUAL) located below it includes interfaces for all functions of the control device such as communication, memory access and input / output or pin occupation, regardless of whether these functions are provided by external peripherals or by the microcontroller. The service layer 140 (Services Layer), which is the top layer of the basic software, includes background services such as communication services, system services, memory management and diagnosis.
[0026] Typically, the application software uses a large amount of functionality that requires specific hardware interfaces for specific control devices. These hardware interfaces can be implemented in particular by complex drivers (complex device drivers) 150, which extend from the hardware to the runtime environment (RTE) in parallel with the remaining basic software and are also integrated into the remaining architecture via standardized AUTOSAR interfaces. "Complex device drivers" can also model functions that are outside the remaining basic software, such as interfaces that are not directly supported by the AUTOSAR standard. In addition, complex drivers can be used, for example, to implement time-critical functions, because in this way, the hardware, such as sensors and actuators, can be accessed more directly and thus faster.
[0027] Further details of the AUTOSAR standard are known in the art and can be accessed at www.autosar.org. The steps and methods described below can be applied in particular with the AUTOSAR standard, but are not limited thereto, and can in principle also be used in other software platforms, in which it is desired to distribute the software over a plurality of processing units, in which hardware-specific interfaces and dependencies must be taken into account.
[0028] In order to temporarily or permanently transfer software parts between control devices in a system with multiple processing units, for example multiple separate control devices that each provide different hardware resources and implement different functions, it is proposed to divide the software functionality into multiple software components and classify them into newly defined categories. The categories can be selected for classification so that the corresponding single functions and dependencies are separated from each other as much as possible (Separation of Concerns) in order to enable optimal distribution to multiple control devices. First of all, a distinction can be made between near hardware categories and far hardware categories. The categories can be selected so that in the AUTOSAR architecture, the near hardware categories correspond to functions implemented in complex drivers or "complex device drivers", while the far hardware categories correspond to application software.
[0029] This classification can also be further refined in order to improve the assignability. Preferably, a function-specific classification is selected here.
[0030] A possible division of categories into which software components can be classified can be constructed as follows:
[0031] Near Hardware Category (Complex Device Drivers):
[0032] a) Hardware signal processing as a first category, for example for register manipulation of sensors and actuators or other peripheral devices; in particular, this category can include software parts that have been developed only for a specific control device, for example a hardware driver for a specific temperature detection element.
[0033] b) Hardware signal abstraction as a second category, i.e. encapsulation of connected sensors / actuators; for example, software parts can be classified here, which can also run on other but similar hardware, but still require adaptation, for example when the measuring principle changes, such as a changed calibration of the connected hardware.
[0034] Remote hardware category (application software):
[0035] c) Regulation, control, general signal processing as a third category; for example, taking over parts of regulation tasks, such as PID speed control or precontrol for temperature control of heating elements, filters for the primary voltage of transformers, noise filters for interior vehicle cameras or control of window lift motors.
[0036] d) Superordinate state control as a fourth category; this includes, for example, software elements containing state-based models or commands for subsystems, such as a state machine for the operating mode of an inverter; software for brakes and inverters for coordination between recuperation functions and friction brakes; state control of throttle valves; fault diagnostics, such as for temperature, voltage, signal loss, and
[0037] e) Prediction and model calculations as a fifth category, such as software models for estimating unmeasured quantities or for predicting future system states, including, for example, a temperature model of the coolant flow through a plurality of battery cells, which models the temperature of each cell, while only a portion of the cells are measured. Other examples are software for estimating wheel speed based on the speed of the motor, the applied torque and the torque obtained, software for predicting the maximum torque in the next few seconds based on the current state of the drive train, or observer software for calculating the vehicle slip angle.
[0038] The software functionality can then be developed and optimized in a targeted manner in a plurality of individual components according to these categories. Here, all interfaces between these categories should be clearly known and defined, so that data exchange across a plurality of control devices is also possible. Thus, the near hardware part can be used separately from the far hardware part on different control devices. For this purpose, the real-time capability can also be analyzed. Since, in the distributed allocation of software components, the signals communicate across the boundaries of the control devices instead of only within the control devices, the latency or signal delay of the interface is usually increased.
[0039] The software components developed in this way can thus each be assigned to a category, in particular one of the above-mentioned categories a) to e). On this basis, an optimal distribution of the software components to a plurality of control devices can then be determined. For this optimization task, various parameters or boundary conditions relevant for error-free and efficient execution as a distributed function can be taken into account.
[0040] The optimal distribution of software components that together form a functionality can be performed using any suitable optimization algorithm, for example by means of an evolutionary algorithm. As input variables for such an optimization, software components can be used together with the description of the categories into which the software components are classified, as well as the control device architecture. Here, the control device architecture can be defined in particular by the number of existing control devices and the existing free resources for each of the control devices, such as computing power, communication bandwidth or memory. For the communication bandwidth, different parameters and bandwidths can be specified for each individual connection, for example between the first and second and the first and third control devices. Protocols and message types supported by the control devices can also be defined as parameters.
[0041] The memory consumption of software components, the processor load of components, the utilization of resources of the control device already determined by other functionalities, the communication requirements between the control devices (e.g. data volume, bandwidth, message frequency), the safety rating, the number of digital and / or analog hardware inputs and outputs, the number and design of existing power output stages of the control device, the required communication protocols and messages (e.g. CAN frame requirements) can be defined, for example, as additional boundary conditions for the optimization algorithm. These and other boundary conditions can be selected arbitrarily, in particular all boundary conditions or only some of the boundary conditions can be used for the optimization, or other boundary conditions can be selected in addition or alternatively that are related to the utilization of the control device and the functional capacity of the software application.
[0042] In particular, the response time or waiting time of a functionality consisting of a plurality of software components and / or the uniform full utilization of the available hardware resources can be considered as an optimization parameter, i.e. as a goal of the optimization. In this case, the complete executable software functionality can include a defined sequence or chain of a plurality of software components, wherein a component can also be used multiple times within the chain, for example a specific calculation or regulation step. Likewise, the software functionality does not have to include a linear chain of software components, but can include parallel sequences, multiple dependencies and contents that differ from the usual way. The response time from the start of execution to the final result (e.g. the control of an actuator) can then be considered as the response time or waiting time of the software functionality.
[0043] As an example, the following should be combined Figure 2 A functionality is described, which regulates a coolant pump and for this purpose takes into account the cooling requirements at different parts of a drive having an electric motor. This function or application can be divided into different software components in order to be able to implement the previously described classification. The final software functionality then includes a specific sequence of processing steps across these different components. In this example, three interconnected control devices are to be provided, which have different characteristics and can be implemented, for example, according to the AUTOSAR standard. As already described, the functions that were otherwise assigned to the application layer (ASW) and complex drivers (CCD) are now further divided into a plurality of categories in order to be able to achieve an optimized allocation of software components to the control devices.
[0044] First, three software components a1, a2, and a3 can be set up, which read signals from hardware (for example, from temperature sensors, tachometers, or other input signals) and determine the cooling requirements of the motor and a predetermined transmission. Since direct signals, such as sensor signals, must be processed here, these components can be assigned to the first category a) of software components, which includes direct signal processing from and to sensors or actuators. For this purpose, two other software components b1 and b2 can be set up to abstract the cooling requirements of specific components (engines, transmissions, etc.) determined by the first software components a1, a2, and a3, so that the abstracted cooling requirements of the motor and transmission can be determined by software components b1 and b2 and further used. These components can be assigned to the second category b) (encapsulation) accordingly. These two categories correspond to the functions handled in the "complex device drivers" of the AUTOSAR architecture.
[0045] Furthermore, two software components c1, c2 can be provided as regulators to control or regulate the coolant pump and the throughflow valve, wherein the control is based on the cooling requirement determined by the components b1, b2. The two software components c1, c2 are accordingly assigned to the third category c) as part of the regulation or control.
[0046] As output signals of the regulators c1, c2, signals are thus obtained which in turn relate to the abstract cooling requirement and serve as input signals for two further components b3, b4. These components b3 and b4 facilitate the output signal from the abstract level to the concrete implementation by the actually existing electric motor and gearbox, so that these software components, such as components b1 and b2, can be assigned to the second category. The output signal is in turn transformed by components a4 and a5 into a concrete control signal for the actuator, i.e. as an actuator-type control signal for the coolant pump and the through-flow valve. Thus, the software components a4 and a5 are again assigned to the first category, which includes direct input and output signals for hardware.
[0047] Furthermore, a higher-level configurable temperature model is provided in the software component e1, which can estimate which coolant flow is required at which temperature (or other input value) in order to provide the desired cooling power. As a modeling component, this software component is therefore assigned to the fifth category. This model is included in the regulation of the components c1 and c2 and can, for example, specify a setpoint value for the coolant flow.
[0048] In addition, software component d1 is used to influence the overall state of the system, for example to switch parts of the system on or off when the motor is not running. In the present example, this additional control element receives input values from component b2, which forwards the abstract measured values of the motor, and from the two regulators c1 and c2. For example, the output value of this control can be fed to software component b3, which controls the coolant pump via components a4 and a5. Component d1 is therefore assigned to the fourth category d) as a superordinate control component.
[0049] Existing control devices can have the same, similar and / or different characteristics. In this example, there should be a first control device, which has been installed with a power output stage for manipulating the coolant pump. In addition, hardware-software components, i.e., components of the first and second categories, should be developed for the first control device, because they must access the special hardware interface and the obtained signals for manipulating. In this example, the second control device is first set to adjust the motor, and the third control device exists as a central control device. The second control device for adjusting the motor can have a short waiting time, but only has a small communication bandwidth for the data flow to the first control device. The third, i.e., central control device can be equipped with high computing power and high communication bandwidth, but has a poor waiting time due to the extensive responsibility for many other functionalities. In addition, as a boundary condition for coolant regulation, it can be pre-given: for example, after a new temperature request, it should take a maximum of 120ms until the coolant pump is activated.
[0050] By means of the described input and output values and the dependencies between the individual components, a component chain is thus predefined for the functionality to be divided. Due to the assignment to different classes, the individual software components can then be distributed to the available control devices. For this purpose, suitable optimization methods can be used, such as evolutionary algorithms, for which the software components and their definition parameters, their respective assignment to the classes, and the control devices and their definition parameters can be defined as input values. Additional rules can be specified as boundary conditions, such as communication bandwidth, desired latency or the coupling of the individual software components to specific hardware or specific control units, for example due to existing output stages at the control unit.
[0051] If hardware-specific software components exist, they can also be initially assigned to the control device for which they were developed specifically. In the present example, the five software components a1, a2, a3, a4 and a5, which read out hardware signals and control actuators and are therefore assigned to the first category of software components, can thus be assigned to the first control device S1, as can the four software components b1, b2, b3 and b4, which abstract between application software and signal levels and are therefore assigned to the second category of software components. In the present example, both categories are specific to the first control device and therefore cannot be used on another control device, since, for example, the corresponding input signals for the power output stages controlled by the software components a4 and a5 and for the software components a1 to a3 are missing there.
[0052] Then, as already described, the remaining software components of the third, fourth and fifth categories can be distributed to all control devices by means of an optimization algorithm, depending on the available resources and other boundary conditions. However, it is also possible to carry out the entire distribution directly by means of a corresponding optimization algorithm and to use a fixed assignment to the control devices as a boundary condition.
[0053] In this example, it is assumed that the software components are Figure 2 As a result of the optimization, the distribution shown in FIG. 1 is shown. Due to the hardware-specific characteristics of the software components a1 to a5 and b1 to b4 of the first and second categories, these components are assigned to the first control device S1. The regulators and state control devices (software components c1, c2, d1), i.e. the software components of the third and fourth categories, are here assigned to the second control device S2 in order to utilize the advantages of a central control device. The time correlation between the control devices can also be taken into account here. The software component e1 of the fifth category can be assigned as a non-critical part of the software chain (with no or only low time-critical requirements) to the third control device S3 with high computing power, in order to, for example, calculate very computing-intensive models.
[0054] It is also conceivable that a plurality of possible allocations of software components to control devices are found by the optimization method. In principle, a large number of different allocations of software components to control devices are possible. In this case, for example, all possible allocations can be output as results so that the developer or manufacturer can specify the final distribution. It is also possible to optimize with respect to a single value (e.g., uniform utilization or waiting time of the control device) and output the best result. Alternatively or additionally, priorities can also be specified for the different values that should be optimized with respect to. If it is possible to dynamically allocate software components or change the allocation, for example, when another control device is added to the system, a new optimal allocation can also be found for this, or the original allocation can be optimized so that it is easier to change the control device architecture.
[0055] exist Figure 3 Detailed description of the invention The exemplary method steps for optimizing the distribution of software components to a plurality of control devices are shown in a flow chart.
[0056] In this case, firstly in step 300 , software components are developed for a predefined software functionality and each software component is assigned exactly one of the predefined categories.
[0057] In step 310, the waiting times required for these software components can be determined, and in step 320, boundary conditions for the software components, such as the expected memory consumption, processor load, required communication protocol, required bandwidth, dependencies between software components, required interfaces and hardware access, etc., can be determined or specified. Such boundary conditions can be obtained in advance, for example, by measurements, test runs, estimations and optimization algorithms. For example, the maximum processor load (e.g. 80% utilization of the computing kernel) or the maximum bandwidth utilization (e.g. maximum 50% utilization of the CAN network) can be predetermined. The boundary conditions for memory consumption can be formed by measurements or static software analysis of the created software. Interfaces and applications can be predetermined in the application itself and exist, for example, as models that are automatically extracted and used to form boundary conditions. For example, the specific processor load that can be expected on the target system to which the software has not yet been delivered can be determined from measurements in known systems and by extrapolation of comparative hardware. In principle, the boundary conditions can also be estimated manually at first. For example, all data of the boundary conditions can be evaluated by an optimization algorithm.
[0058] In step 330, framework parameters of the control device architecture can be specified or determined, which can include, in particular, the number of existing control devices, freely available computing power, the architecture or association of the control devices, the type and bandwidth of existing communication connections, the protocols and messages used or supported, existing analog and digital inputs and outputs, existing power output levels and other parameters.
[0059] It goes without saying that the steps for detecting the parameters of the software component shown here as a sequence can also be executed in a different order independently of one another, at different times or in parallel.
[0060] The software components or their parameters defined in this way can be read out from a stored file or input by a user as input variables and / or boundary conditions for the optimization algorithm in step 340. Likewise, the detected characteristics of the control unit architecture can be input to the optimization algorithm in step 350. In step 360, one or more parameters can be defined according to which the optimization is to be performed, for example, a predetermined waiting time of the execution chain of the overall functionality or a uniform utilization of resources.
[0061] The optimization algorithm is then executed in step 370 and the result is checked in step 380 with respect to the interruption criterion. If the interruption criterion is not met, the optimization algorithm is rerun. The interruption criterion can, for example, include outputting a reasonable allocation of software components to control devices that meets all boundary conditions. As a result, one or more possible optimized allocation configurations for software components to control devices are output by the optimization algorithm in step 390, wherein each software component should be assigned to exactly one control device. Optionally, a plurality of allocation configurations can also be indicated to the user for selection or evaluated using quality criteria. If no valid result is found using the optimization, i.e., for example, no allocation can meet all boundary conditions, the method can be repeated from step 320 or optionally a later step. In this case, for example, the boundary conditions can be changed and adapted so that a valid allocation result occurs.
[0062] It goes without saying that the features and properties of the control devices mentioned here, like all numerical values, are mentioned only as examples, and that in other cases there may be control devices with different properties, different activation times, or more or fewer control devices available. The functions described here for coolant control only serve to illustrate the principle of dividing the software components of an application into a plurality of categories, so that these categories are taken into account when assigning to the control devices, and can also be transferred to any other control and regulation functions with corresponding actuators, sensors, controllers and calculation steps.
Claims
1. A method for distributing a set of software components (a1-a5, b1-b4, c1, c2, d1, e1) to a control device architecture having a plurality of interconnected control devices (S1, S2, S3), wherein executable software functionality is defined by a sequence chain of the set of software components, wherein the method comprises: For each software component from the set of software components, detecting (300) a classification assigned to the respective software component, wherein the classification comprises at least one or more near-hardware categories, the near-hardware categories being assigned to software components (a1-a5, b1-b4) whose functionality is associated with a hardware interface of at least one specific control device, and wherein the classification comprises at least one or more remote hardware categories which are assigned to software components (c1, c2, d1, e1) whose functionality is not associated with hardware elements of a specific control device, The method further comprises: detecting (330) characteristics of a control device architecture, wherein the detected characteristics include at least the number of control devices (S1, S2, S3) and resources available to each control device; Entering (350, 360) as input values to the optimization algorithm the number of software components, the classification for each software component, the sequence chain of the software components and the characteristics of the control architecture; inputting (350, 360) additional boundary conditions for the software components and / or the control device architecture into the optimization algorithm, and At least one unique assignment of each software component from the set of software components to a plurality of control devices is determined (390) as an output value of the optimization algorithm, wherein the assignment is optimized according to at least one predetermined parameter (360) for executing the executable software functionality, and The allocation (370, 380) is performed by an optimization algorithm according to the classification (300) of each of the software components. 2 . The method according to claim 1 , wherein the predetermined parameters according to which the allocation is optimized include waiting times for executing executable software functionalities and / or uniform utilization of resources of the control device.
3. The method according to claim 1 or 2, wherein the additional boundary conditions for each of the software components include at least one of the following: the processor load of the software component, the memory consumption of the software component, the communication bandwidth required between two software components, the message frequency required for communication between two software components, the dependency between two or more of the software components, the waiting time of the software components, the communication protocol used, and the hardware or software interface used by the software component.
4. A method according to any of the preceding claims, wherein the characteristics of the control device architecture and / or additional boundary conditions for the control device architecture include at least one of the following: computing power provided by the control device, available memory size, the communication protocol used, the message type used, the available communication bandwidth between two control devices, respectively, instructions about the output stage installed in the control device, instructions about additional specific hardware interfaces in the control device, available inputs and outputs of the control device, and a safety rating. 5 . The method according to claim 1 , wherein the plurality of control devices are implemented according to the AUTOSAR standard.
6. The method according to claim 5, wherein the near hardware class is assigned to a "complex device driver" (150) of the AUTOSAR layer structure, and wherein the far hardware class is assigned to an application software (170) of the AUTOSAR layer structure.
7. The method according to any of the preceding claims, wherein the one or more near-hardware categories are selected from: A first category of software components (a1, a2, a3, a4, a5) for performing manipulation of hardware inputs and outputs; and A second category of abstract software components (b1, b2, b3, b4) for performing hardware manipulation.
8. The method according to any one of the preceding claims, wherein the at least one or more remote hardware categories are selected from: a third category of software components (c1, c2) for executing at least one of control, regulation or signal processing; A fourth category of software components (d1) for performing superordinate state control; and A fifth category of software components (e1) for forming predictions and / or performing parametric modeling.
9. The method according to any one of the preceding claims, wherein the optimization algorithm is an evolutionary algorithm.
10. A control device architecture comprising a plurality of interconnected control devices (S1, S2, S3), wherein a set of software components is set up in a distributed manner on the control devices, wherein executable software functionality is defined by a sequence chain of the set of software components, and wherein the software components are assigned to the control devices according to any of the preceding claims. 11 . A computing unit which is configured to carry out all method steps of the method according to claim 1 . 12 . A computer program which, when executed on a computing unit, causes the computing unit to execute all method steps of the method according to claim 1 .
13. A machine-readable storage medium having stored thereon the computer program according to claim 12.