Method for data transfer in a vehicle's communication system

Abstract

The present invention relates to a method for the transfer of data in a communication system (11) of a vehicle, comprising: said communication system (11) comprising at least one first bus system (10, 12, 14) and at least one subsequent bus system (10, 12, 14); at least one first domain (40, 42, 44) can be used as an independent execution entity, in particular an AUTOSAR domain (40, 42, 44), for exchanging said data between said bus systems (10, 12, 14), Within said first domain (40, 42, 44) application programs (46, 48), in particular vehicle functions, can be executed; and said first domain (40, 42, 44) comprising at least a standardized interface, in particular an AUTOSAR real-time environment, to said application programs (46, 48); The subsequent domains (16, 18, 20) are regarded as subsequent execution entities independent of the first domains (40, 42, 44), and only the subsequent domains (16, 18, 20) access a physical interface (13) of the communication system (11), thereby exchanging data between the communication system (11) and the first domain (40); data (70, 72, 74) received via a physical interface (13) of the communication system (11) in said subsequent domain (16, 18, 20) is processed at least with respect to transmission, It concerns the method.

Description

Technical Field

[0001] The present invention relates to a method for transferring data in a communication system of a vehicle of the type described in the independent claims.

Background Art

[0002] AUTOSAR (AUTomotive Open System ARchitecture) is a name that refers to a development partnership aimed at facilitating software exchanges on various control units, consisting of automotive manufacturers, control unit manufacturers, and manufacturers of development tools, ECU basic software, and microcontrollers.

[0003] AUTOSAR provides a series of specifications that describe basic software modules, define application interfaces, and establish a common development methodology based on a standardized exchange format. The basic software modules provided by the AUTOSAR layered software architecture can be introduced into vehicles of different manufacturers and electronic components of different suppliers.

[0004] A method for handling AUTOSAR software components of an AUTOSAR software system is known from US Patent No. 8966443.

Summary of the Invention

Problems to be Solved by the Invention

[0005] A problem of the present invention is to further improve the arithmetic processing speed of an AUTOSAR software system, among other things.

Means for Solving the Problems

[0006] This problem is solved by the features of the independent claims. In accordance with the characteristics of independent claims, a control unit incorporating gateway functionality can achieve high-performance transfer or routing of specific data. By appropriately transferring routing functionality to subsequent domains, the load on the first domain, particularly the AUTOSAR domain, can be reduced. This results in improved overall system load compensation and, especially when multi-core controllers are used, improved utilization of hardware resources. The proposed task-distributed hybrid software architecture using different domains allows the software within the AUTOSAR domain to remain unchanged to serve as a hosting service for in-vehicle functions, while on subsequent domains, the software can be optimized specifically for data transfer performance and, consequently, for performance-related application cases. The proposed distribution of functions across different domains and, consequently, different execution entities, allows these functions to be flexibly distributed across one or more CPU cores depending on system requirements and system design. Low latency during routing can be achieved, particularly during vehicle operation, based on the proposed solution. This is achieved primarily by ensuring that data exchange with the first domain is always carried out via a subsequent domain featuring a high-power transfer mechanism. It is particularly preferable that performance-related data remains within the subsequent domain for further computation, while additional data is transferred to the first domain.

[0007] In a preferred deployment configuration, a dedicated successor domain is used for the first bus system, and a further dedicated domain is used for subsequent bus systems, with data exchange between both successor domains occurring only at the level of data units, particularly protocol data units (PDUs), particularly general-purpose data units, and / or data units contained within containers. When the vehicle is running in normal mode, these routing mechanisms are comprehensively applied to application data exchanged between in-vehicle functions on various control units.

[0008] In a preferred deployment configuration, data is permitted to be exchanged between the first domain and subsequent domains at the frame level and / or data unit level, particularly using memory shared by both domains, while data is not exchanged between one of the subsequent domains at the frame level, but only at the data unit level. This allows for the use of a data exchange mechanism independent of both function and protocol. This makes it possible to maintain the interface defined in the AUTOSAR standard, thus facilitating or maintaining the integration of the first domain across the entire system as is customary. Data unit-based data exchange within these subsequent domains can be performed particularly quickly and with high performance.

[0009] In a preferred deployment configuration, the subsequent domain is intended to include at least one driver for linking to the physical interface of the communication system, particularly the bus system, for data access or control mechanisms targeting Layer 2 of the International Organization for Standardization's 7-tier OSI reference model (ISO / OSI), and / or to include at least one protocol memory or protocol stack for data access or control mechanisms targeting Layers 3-5 of ISO / OSI, particularly necessary for processing performance-related data from the subsequent domain, and / or to include at least one gateway for transferring at least one data unit, particularly between protocol stacks of different subsequent domains. This ensures, firstly, communication only through subsequent domains. In addition, it enables high-performance processing of performance-related applications, such as non-transport protocol arithmetic processing for extracting data units for high-performance routing.

[0010] In a preferred deployment configuration, it is intended that within the first domain, particularly the AUTOSAR domain, a virtual driver is provided, in particular as a proxy for the physical driver, for frames to communicate with the respective drivers of the subsequent domains and / or with the frame interface provided within the first domain; and / or, within the first domain, at least one adapter is provided for exchanging data or data units with the gateway of the subsequent domains and / or with the router for data units provided within the first domain. This ensures that direct access to the physical communication interface is limited to the subsequent domains. Nevertheless, consideration may be given to incorporating the subsequent domains appropriately into the AUTOSAR architecture definition, particularly through these virtual interfaces. Data exchange with the subsequent domains at the data unit level can be ensured through the adapter.

[0011] In a preferred deployment configuration, the system description file of the first domain, particularly the complete AUTOSAR-ECU-Extract, is intended to generate configuration code for data transfer within subsequent domains, and / or a reduced version of the system description file of the first domain, particularly a reduced version of the AUTOSAR-ECU-Extract. This optimizes the existing toolchain, allowing for the deriving of domain-specific configurations from the complete ECU configuration set. This enables automated software generation for both domains. This refers to a tool-assisted solution for configuring software in the AUTOSAR domain, and similarly for subsequent domains, particularly for the computation of AUTOSAR standard input information (ECU-Extract in ARXML (AUTOSAR specification XML) format).

[0012] In a preferred deployment configuration, configuration code is created using a data model that describes data transfer. Through this data model, data about routing devices extracted from ECU extracts in subsequent domains can be stored and visualized.

[0013] Further development examples will be revealed in the additional dependent claims and specification. [Brief explanation of the drawing]

[0014] [Figure 1] This diagram shows a classic E / E architecture for automobiles. [Figure 2] This diagram shows a domain-type E / E architecture for automobiles. [Figure 3] This is a diagram showing a centralized E / E architecture for automobiles. [Figure 4] This is a conceptual diagram of a hybrid software architecture. [Figure 5] This is a schematic diagram of the data structure. [Figure 6] This diagram shows various data paths within a hybrid software architecture. [Figure 7] This diagram shows the data paths for routing PDUs and containers within one of the subsequent domains. [Figure 8] This diagram shows the data paths for routing PDUs and containers between two of the subsequent domains, with respect to the receiving portion. [Figure 9] This diagram shows the data paths for routing PDUs and containers between two of the subsequent domains, with respect to the transmission portion. [Figure 10] This diagram shows the data path for sending and receiving frames using the AUTOSAR domain. [Figure 11] This diagram shows the data path for sending and receiving PDUs using the AUTOSAR domain. [Figure 12]A diagram showing a data path for receiving PDUs and routing PDUs by an application program. [Figure 13] A diagram showing tools and workflows for a hybrid software architecture. [Figure 14] A diagram showing the data model of a routing device. **Embodiments for Carrying Out the Invention**

[0015] The present invention is schematically illustrated based on one embodiment and will be described in detail below with reference to the drawings. In the context of an automobile, a vehicle's electrical / electronic (E / E) architecture includes a network of electronic control units (ECUs) 5 connected to each other via communication channels. These E / E architectures are designed such that the exchange of information between the electronic control units (ECUs) 5 is restricted. This restriction of information is technically achieved by the functionality 3 of a gateway incorporated into the communication interface within the vehicle as a pure software solution or a software / hardware solution within specific control units 2, 4, 6, 7, 8. The role of this gateway functionality 3 is to connect communication channels of the same or different in-vehicle bus technologies (e.g., CAN, LIN, FlexRay, Ethernet or the like) to each other and enable controlled transmission of communication messages between them. Figures 1 to 3 show different E / E architectures.

[0016] A classical E / E architecture according to Figure 1 features a central gateway 2 with gateway functionality 3 through which multiple communication channels (each connected to a control unit 5) are connected to each other. Subgroups of control units 5 may also be connected to each other via a sub-gateway 4 that also has gateway functionality 3 from the perspective of the data link.

[0017] Similarly, in a domain-based E / E architecture associated with the domain according to FIG. 2, a central gateway 2 is provided. The central gateway 2 connects a plurality of domain control units 6, which encapsulate gateway functionality 3, to each other for the purpose of data exchange. Depending on the further control unit 5 or architecture on which data is exchanged via these domain control units 6, a sub-gateway 4 to which the control unit 5 is connected may be provided.

[0018] In a centralized E / E architecture associated with the zone according to FIG. 3, a plurality of zone control units 9 with gateway functionality 3 are provided, which may be arranged, for example, at different locations within a motor vehicle. These zone control units 9 are connected to each other for the purpose of data exchange via a computing device 8, in particular a high-performance on-board computer. For this purpose, this computing device 8 also includes gateway functionality 3. Further control units 5, which are spatially distributed (for example, at the front left, front right, rear, etc. within the vehicle) within the area of this zone from the perspective of the data link, are connected via these zone control units 9. Depending on the application case, a sub-gateway 4 linked to the further control unit 5 may be provided.

[0019] The primary application of most control units 5 is hosting application software components to implement various in-vehicle functions (e.g., brakes, engine control, energy management, etc.). To facilitate this, AUTOSAR defines a standard specification for the in-vehicle software architecture. AUTOSAR defines a standard interface to application software components in a real-time environment (RTE), as well as the mechanisms of the corresponding infrastructure in the basic software, such as the operating system, communication, diagnostics, and non-volatile data memory. Therefore, for this application, it is advantageous to maintain a standardization approach using the standard software AUTOSAR.

[0020] However, control units incorporating gateway functionality 3 are required to perform high-capacity data handling functions, such as high-performance transmission of communication messages. Although the necessary routing functionality is defined and supported by the AUTOSAR standard, the routing performance of the AUTOSAR standard software is often insufficient to satisfy performance requirements, such as those defined by vehicle manufacturers. The possibility of optimizing the software to meet performance requirements is limited because the software architecture, functionality, and interface are standardized by AUTOSAR, and liability issues arise when modifying the standard software. Moreover, different communication paradigms and routing mechanisms of vehicle manufacturers provide additional optimization possibilities through vehicle manufacturer-specific solutions that are not available in the AUTOSAR standard software. Therefore, the AUTOSAR standard software is not optimal for the implementation of gateway functionality 3.

[0021] The following examples describe in more detail gateway functionality 3, which enables high-capacity data handling or data routing for the AUTOSAR environment. A high-performance software architecture and complete software solution are proposed for a control unit 5 that is required to perform both the application example (hosting service function for in-vehicle functions) and gateway functionality 3. This is called a hybrid multicore software architecture for an in-vehicle controller incorporating gateway functionality 3.

[0022] This hybrid software architecture is divided into independent execution entities, which we will refer to below as domains 16, 18, 20; 40, 42, and 44. These domains can have independent specifications and are characterized by different partitions, particularly software partitions. Communication between different domains 16, 18, 20; 40, 42, 44 proceeds via corresponding interfaces or, for example, via specific memory concepts (shared memory concept: for example, a ring buffer that different domains 16, 18, 20; 40, 42, 44 are allowed to access according to specific rules (write / read, storage area, etc.) for the purpose of exchanging data). Within a multicore CPU system (microcontroller or microprocessor or system-on-a-chip (SoC)), these domains can be flexibly distributed across one or more CPU cores depending on the system requirements and design of the control unit. General-purpose data exchange mechanisms enable data exchange between domains 16, 18, 20; 40, 42, 44 and the core, or within the computer core, as inter-domain communication units 30, 66 between at least the first domains 40, 42, 44, in particular the AUTOSAR domain, and subsequent domains 16, 18, 20, in particular the communication domain.

[0023] Additional partitioning is introduced to the independent execution units of the software architecture, hereafter referred to as domains 16, 18, 20; 40, 42, and 44. These domains 16, 18, 20; 40, 42, and 44 can utilize corresponding execution functions, and by flexibly incorporating these functions into the operating system's scheduling as cyclic tasks, i.e., periodic tasks or interrupt tasks, the required ECU system behavior can be achieved.

[0024] The components of the AUTOSAR architecture are assigned to at least one (first) domain 40, 42, 44, or, depending on the application, to multiple (first) domains 40, 42, 44, which are hereafter referred to as the first or AUTOSAR domains 40, 42, 44, and are fully compliant with the AUTOSAR standard without modification. These AUTOSAR domains 40, 42, 44 may be implemented as an AUTOSAR single-core architecture or a multi-core architecture. Within the AUTOSAR domains 40, 42, 44, depending on the application, there may be different application programs 46, illustrated exemplarily as in-vehicle function programs 48.1, 48.2, ..., 48.n. Furthermore, each AUTOSAR domain 40, 42, and 44 includes basic software 52, which may include, for example, routers, in particular PDU routers 54 (I-PDU routers (I-PDU: Interaction Layer Protocol Data Unit, a data unit defined by AUTOSAR, hereafter also referred to as PDU (Protocol Data Unit) or data unit)) and / or interfaces 56 for the bus system used (e.g., CAN, Flexray, Ethernet, etc.).

[0025] Independent of at least one (first) AUTOSAR domain 40, 42, 44, there are at least one successor domain 16, 18, 20, preferably multiple successor domains 16, 18, 20. These successor domains 16, 18, 20 have independent execution functions for data routing and handling. It is particularly preferable that each communication protocol (of each communication system 11) has its own dedicated domain 16, 18, 20, such as a CAN domain 20, a Flexray domain 18, and an Ethernet domain 16. The successor domains 16, 18, 20 access the respective physical interfaces 13 of the communication system 11 and process messages for each communication system 11.

[0026] The functional division between AUTOSAR domains 40, 42, and 44 and subsequent domains 16, 18, and 20, particularly the division of data routing functionality, is carried out so that performance-related application cases characterized by high-speed data routing or transfer are assigned to subsequent domains 16, 18, and 20. The majority of the total data transfer volume to be realized by the gateway functionality 3 in the control unit utilizes the so-called PDU routing mechanism and container routing mechanism. This routing mechanism is comprehensively applied to application data exchanged between in-vehicle functions on the control unit 5 when the vehicle is running (normal mode). This application case imposes a high requirement for low latency during routing, and therefore this application case is assigned to one or more subsequent domains 16, 18, and 20 to route or transfer data. Within subsequent domains 16, 18, and 20, data transfer is carried out in association with data units PDUs 72 or containers 74, particularly information in the header 80 and transfer information stored, for example, in the routing table. The header 80 or the information attached to it makes it possible to identify how the subsequent payload 82 should be interpreted or forwarded.

[0027] All other application cases that do not feature high-speed data transfer, or standard cases such as diagnostic tasks or similar tasks, are assigned to AUTOSAR domains 40, 42, and 44. All remaining application cases, such as local termination (transmission and reception by hosted in-vehicle functions), transport protocols (ISO-TP (International Standards Organization - Transport Protocol), TCP (Transmission Control Protocol)), diagnostic communications and diagnostic routing (UDS (Unified Diagnostic Services), OBD (On-Board Diagnostics), DoIP (Diagnostics over Internet Protocol)), and network management), are assigned to AUTOSAR domains 40, 42, and 44.

[0028] Within this hybrid software architecture, domains 16, 18, 20; 40, 42, 44 may be allocated to one or more CPU cores (microcontrollers or machine-processors or system-on-a-chip (SoC)) in a multi-core CPU system to satisfy control unit requirements and design (e.g., number of interfaces, data traffic, latency and throughput requirements, CPU load due to routing, etc.).

[0029] The first or AUTOSAR domains 40, 42, and 44 may be implemented as single or multi-core implementations as defined by the AUTOSAR standard.

[0030] The subsequent domains 16, 18, and 20, which are specialized for communication protocols, can be flexibly allocated to CPU cores to enable single or multi-core implementations. Each subsequent domain 16, 18, or 20 can be assigned to a different CPU core (e.g., a CAN core, an Ethernet core, etc.), or multiple or all subsequent domains 16, 18, or 20 can be assigned to individual cores (e.g., CAN, Flexray, and Ethernet on individual cores).

[0031] The exchange of communication data between AUTOSAR domains 40, 42, and 44 and subsequent domains 16, 18, and 20 is carried out via a general-purpose data exchange mechanism, which, as described above, is based on the shared memory concept and is referred to as inter-domain communication units 30 and 66 located within the first domain and subsequent domains 16, 18, 20:40, 42, and 44 that communicate with each other, as suggested in Figure 4.

[0032] The inter-domain communication units 30 and 66 are data exchange mechanisms independent of function and protocol, enabling the transmission of data blocks from one sender to one or more receivers.

[0033] These data blocks (e.g., payload 82 in Figure 5) are accompanied by additional metadata (e.g., header 80 in Figure 5), specifically, their recognition code and data length, which allows the sender and receiver to jointly interpret the exchanged data. The time schedule for this data exchange can be configured by a polling or interrupt scheme. The exchanged data may be further protected by security mechanisms such as an authentication system to ensure data integrity.

[0034] When the area for exchanging data between components is allocated to various cores according to the control unit design, the same data exchange mechanism is called the inter-core communication unit. Within the framework of this application scheme, the data units frame 70, PDU 72, and container 74 shown in Figure 5 have a significant relationship. The format of these data units follows the TLV (Type-Length-Value) scheme. The type (identifier, additional protocol parameters) and length (of the payload 82 or loaded data, expressed in bytes) are metadata, collectively called the header 80, which represents the content of the data value (payload 82 or user data).

[0035] A frame or segment 70 is a unit of data transmitted over the physical interface 13 of a particular communication protocol, and its exact format is defined by the protocol (CAN, Flexray, Ethernet).

[0036] The PDU 72 corresponds to all or part of the payload 82 of a frame or container 70 that contains application data (from signals with physical or functional suitability, such as vehicle speed, ambient temperature, error status flags, etc.). The PDU 72 has its own header 80 and loaded data or payload 82.

[0037] The container 74 for the PDU 72 is a collector, which is used to group multiple PDU 72s contained within it. A PDU 72 transmitted contained within a frame 70 without a container 74 is called a general-purpose PDU 72. The container 74, the PDU 72 contained within the container 74, and the general-purpose PDU 72 each have their own header 80 and loaded data or payload 82. These data units may have a nested structure, in which, as illustrated in Figure 5, the frame 70 consists of general-purpose PDU 72s and / or container-contained PDU 72s, and the container-contained PDU 72 itself consists of container-contained PDU 72s.

[0038] To comply with the Application Programming Interface (API) defined in the AUTOSAR standard, data can be exchanged between the subsequent domains 16, 18, and 20 and the AUTOSAR domains 40, 42, and 44 at the data unit / frame level (see the bidirectional arrows in the lower part of Figure 4 between the communication drivers 24 of the subsequent domains 16, 18, and 20 and the virtual drivers 64 of the first domains 40, 42, and 44) ​​and at the data unit / PDU level (general-purpose and containerized PDUs 72, indicated in Figure 4 via the bidirectional arrows in the upper part between the PDU gateway 28 and the PDU adapter 60, which are forwarded to the PDU router 54 of the first domains 40, 42, and 44).

[0039] To accommodate the data units exchanged with AUTOSAR domains 40, 42, and 44, data exchange between subsequent domains 16, 18, and 20 is permitted only at the data unit PDU72 level (general purpose and / or PDU72 contained within container 74). Between two subsequent domains 16, 18, and 20 based on different communication protocols (CAN, Flexray, Ethernet), data exchange at the frame level is not possible because each protocol has a different frame layout.

[0040] Within the hybrid software architecture, direct access to the physical communication interface 13 for the CAN, Flexray, and Ethernet protocols is limited to the respective subsequent domains 16, 18, and 20 involved in data routing or forwarding. This approach allows the subsequent domains 16, 18, and 20 to directly receive messages from interface 13 and divide them quickly. These messages are stored within their respective subsequent domains 16, 18, and 20 for further processing, while the remaining messages are forwarded to the AUTOSAR domains 40, 42, and 44. Thus, the AUTOSAR domains 40, 42, and 44 do not have direct access to interface 13 of their respective communication systems 11, but receive relevant messages indirectly through their respective subsequent domains 16, 18, and 20.

[0041] The software architectures of the subsequent domains 16, 18, and 20 are implemented specifically for their respective communication protocols (CAN, Flexray, Ethernet) and have similar configurations (see Figure 4). Each routing device 22 for the subsequent domains 16, 18, and 20 consists of a communication driver 24 for linking to the respective physical interface 13 of the communication system 11, a communication protocol stack 26 or stack memory for handling higher-order protocol layers (e.g., CAN / FR / ETH…), and a protocol-independent PDU gateway 28 for forwarding PDUs 72. An inter-domain communication entity 30 is required to exchange data with other (subsequent) domains 16, 18, 20, or AUTOSAR domains 40, 42, and 44.

[0042] The communication driver 24 is responsible for the ISO / OSI Layer 2 implementation of data access (read / write) and control mechanisms (mode management and error management), which are essential for handling the communication control systems and physical interfaces 13 of each communication protocol (CAN, Flexray FR, Ethernet ETH, ...).

[0043] The communication protocol stack 26 or communication protocol memory is responsible for implementing only the ISO / OSI layers 3-5 data access and control mechanisms, which are essential for handling routing-related application cases on subsequent domains 16, 18, and 20. This area primarily involves the processing of non-transport protocol messages (Non-ISO-TP, UDP) for extracting PDU 72 for high-performance routing.

[0044] The PDU gateway 28 performs high-performance forwarding of PDUs 72 between various data sources and data sinks, specifically between the communication protocol stack 26 on the subsequent domains 16, 18, and 20 to which it belongs, and the communication protocol stack 26 on other subsequent domains 16, 18, 20 and / or AUTOSAR domains 40, 42, and 44, via the inter-domain communication unit 30. This forwarding is regulated by configurable routing statements, also known as routing tables. This forwarding can be performed using the respective headers 80 as clues.

[0045] In order to exchange data with other successor domains 16, 18, 20 and AUTOSAR domains 40, 42, 44, an inter-domain communication entity 30 is implemented as a specification in each of the successor domains 16, 18, and 20.

[0046] The AUTOSAR layered architecture is a complete, autonomous standard architecture. To incorporate a proprietary routing architecture into this, software modules 58, 60, 62, and 64, located on the first domains 40, 42, and 44 and directly connected to any AUTOSAR standard modules 52, 54, and 56, must be introduced and incorporated into the definition of the control unit's AUTOSAR architecture. The AUTOSAR standard provides the possibility of using a complex device driver 58 (CDD) for such integration.

[0047] Within the AUTOSAR standard architecture, communication interface drivers (CAN drivers / Flexray drivers / Ethernet drivers) are part of the Microcontroller Abstraction Layer (MCLA) that constitutes the layered architecture. Within the hybrid software architecture, direct access to the physical communication interface 13 is limited to subsequent domains 16, 18, and 20. Therefore, the MCAL on AUTOSAR domains 40, 42, and 44 must adapt to the corresponding protocol via so-called virtual communication drivers or virtual drivers 64 (CDDs). These virtual drivers 64, as their name suggests, are not actual drivers but proxies of actual drivers and are used as standard AUTOSAR-APIs for the higher-level interface modules (CAN interfaces / Flexray interfaces / Ethernet interfaces) of the so-called ECU Abstraction Layer (ECUAL). These virtual drivers 64 also interact with their corresponding counterparts on subsequent domains 16, 18, and 20, specifically with the actual communication drivers 24, via inter-domain communication units 30 and 66 located on corresponding AUTOSAR domains 40, 42, and 44, to exchange frames 50.

[0048] Within the AUTOSAR standard architecture, the PDU router 54 is a software module through which PDUs 72 are transferred between various software modules in the upper and lower layers. To enable the exchange of PDUs 72 between AUTOSAR domains 40, 42, and 44 and subsequent domains 16, 18, and 20, a driver CDD (AUTOSAR ComplexDeviceDriver) called a PDU adapter 60 is incorporated into the architecture definition as a lower-level module of the AUTOSAR PDU router 54. This PDU adapter 60 interacts with the PDU gateways 28 of each subsequent domain 16, 18, and 20 via inter-domain communication units 30 and 66 to exchange PDUs 72. This is done using the shared memory architecture described above, i.e., a common memory such as a ring memory.

[0049] Within AUTOSAR domains 40, 42, and 44, an inter-domain communication entity 66 is implemented as a specification to enable data exchange with corresponding entities on subsequent domains 16, 18, and 20. Transmission and reception of frames 70 and PDUs 72 within AUTOSAR domains 40, 42, and 44 is made possible by transferring these data units from or to a virtual communication driver 64 (at the frame level) or a PDU adapter 60 (at the PDU level). However, unlike the virtual communication driver 64 and PDU adapter 60, this inter-domain communication entity 66 is not directly connected to the standard AUTOSAR modules 52, 54, and 56, and therefore should not be included in the AUTOSAR architecture definition.

[0050] To specify the address of the hosting service for the in-vehicle function and gateway application example 5, data is transferred within a hybrid software architecture from both data sources, specifically the physical communication interface 13 and the application software component, along various data paths and processed as is evident from Figure 6.

[0051] Within the subsequent domains 16, 18, 20 or their associated communication drivers 24, there is a forwarding determination unit 90 for the received frame or frame 70, which is used to further process the frame 70 received directly from the respective interface 13 (CAN, Flexray, Ethernet). The subsequent domains 16, 18, 20 have independent execution functions for data routing. According to the configurable forwarding determination unit 90, which has evaluated the header 80 of the frame 70 within the communication driver 24, the received frame 70 (in step 88) is forwarded to one of the following targets: - Regarding AUTOSAR domains 40, 42, and 44 only: Frames 70 that will be further processed only within AUTOSAR domains 40, 42, and 44 are forwarded to the AUTOSAR (CAN / Flexray / Ethernet) interface module 56 only via their respective virtual drivers 64 (CDD). - Regarding subsequent domains 16, 18, and 20 only: Frames 70 containing application-related PDUs 72 that will be extracted and further processed are forwarded only upward (to their respective subsequent domains 16, 18, and 20) within the software stack 26 or communication protocol stack 26 (communication protocol stack 26 and PDU gateway 28) of the subsequent domains 16, 18, and 20. - With respect to both AUTOSAR domains 40, 42, 44 and subsequent domains 16, 18, 20: In certain special cases, frame 70 is forwarded both to AUTOSAR domains 40, 42, 44 and upward within the software stack or communication protocol stack 26 of subsequent domains 16, 18, 20.

[0052] The transfer determination unit 90 regarding the received frame or frame 70 can be summarized as follows: - Regarding AUTOSAR domains 40, 42, and 44 only • Diagnostic communication CAN / FR: UDS (United Diagnostic Services) on ISO-TP (International Standards Organization - Transport Protocol) ETH (Ethernet): UDS over DoIP (Diagnostics over Internet Protocol) (UDP, TCP (Transmission Control Protocol)) • Diagnostic transfer CAN / FR: Message routing for ISO-TP messages ETH: DoIP routing for non-diagnostic TCP channels Related to CAN, FR, and ETH Non-diagnostic TCP channel: • Time synchronization, network management, XCP (Universal Measurement and Calibration Protocol) - Regarding only the subsequent domains 16, 18, and 20 • PDU routing and container routing, and / or a frame 70 having PDU 72 for reception by application programs - In relation to both AUTOSAR domains 40, 42, and 44, and subsequent domains 16, 18, and 20 • In relation to ETH only: ARP (Address Resolution Protocol) SOME / IP-SD (Scalable service-oriented middleware over IP - Service Discovery) Transfer determination unit 92 regarding the received PDU 72 The frame 70, which is forwarded from the communication driver 24 through the software stack 26, is further processed to extract either a general-purpose PDU 72 or / or a container PDU 72 that actually contains a PDU 72 that is contained within as the smallest data unit that cannot be further divided.

[0053] The general-purpose PDU 72 or the PDU 72 contained within the container 74 is forwarded to one of the following targets within the PDU gateway 28 according to the configurable PDU forwarding determination unit 92: - Regarding AUTOSAR domains 40, 42, and 44 only: PDU 72, which is only related to receiving application programs 46 and 48 hosted within AUTOSAR domains 40, 42, and 44, is forwarded to the AUTOSAR PDU router 54 via PDU adapter 60 only. - Regarding only subsequent domains 16, 18, and 20: PDU72 is related only to PDU routing and container routing: - If the target interface 13 is located within the same subsequent domains 16, 18, and 20, it is forwarded to move backward through the communication protocol stack 26 and communication driver 24 of the routing device 22 for transmission.

[0054] - If the target interface 13 is in another subsequent domain 16, 18, or 20, it is forwarded to the PDU gateway 28 in the respective subsequent domain 16, 18, or 20 for transmission. - Regarding both AUTOSAR domains 40, 42, and 44, and subsequent domains 16, 18, and 20: - PDU72, which is also involved in PDU routing and container routing, is forwarded to AUTOSAR domains 40, 42, and 44, as well as to the target domains of subsequent domains 16, 18, and 20.

[0055] Combining transmission data of PDU 72 and frame 70 from AUTOSAR domains 40, 42, 44 and subsequent domains 16, 18, 20: Since only subsequent domains 16, 18, and 20 have direct access to physical interface 13, the transmission data between AUTOSAR domains 40, 42, and 44 and subsequent domains 16, 18, and 20 must be combined and transmitted to the associated target interface 13 (CAN / Flexray / Ethernet) on subsequent domains 16, 18, and 20.

[0056] The PDU72s of application programs 46 and 48 in AUTOSAR domains 40, 42, and 44, the PDU72s of other subsequent domains 16, 18, and 20, and / or the PDU72s of said subsequent domains 16, 18, and 20 are combined within the PDU gateway 28 of said subsequent domains 16, 18, and 20 to construct the payload 82 of the target frame 70.

[0057] Frame 70 is forwarded from the basic software 52 in AUTOSAR domains 40, 42, 44 and the subsequent domains 16, 18, 20 to the target interface 13 by the communication driver 24 on the subsequent local domains 16, 18, 20.

[0058] Data paths for various application examples In hybrid software architectures, specific subsets of the processing unit, transfer decision unit, and data path become significantly relevant depending on the specific application. The following paragraphs will explain data paths for various application examples, linking them to Figures 6 through 12.

[0059] Figure 7 shows PDU routing and container routing within one of the subsequent domains 16, 18, and 20. In this application, the PDU 72 and / or container 74 received on one of the subsequent domains 16, 18, and 20 (encompassed in the frame 70 received in step 88) are transmitted to the target interface 13 of the same subsequent domain 16, 18, or 20 (transmission of the corresponding frame 70 in step 106) (e.g., routing from CAN to CAN). Thus, this data path (steps 91, 92, 93, 110, and 120) travels up and down within the software stack 26 of only one of the subsequent domains 16, 18, or 20, and no data is exchanged with the AUTOSAR domains 40, 42, 44 or the other subsequent domains 16, 18, or 20.

[0060] PDU routing and container routing between subsequent domains 40, 42, and 44 are shown in Figure 8 (receiving section) and Figure 9 (transmitting section). In this application example (steps 88, 90, 91, 92, 94 (Figure 8), steps 108, 110, 120, 104, 106 (Figure 9)), the PDU 72 and / or container 74 received on source domains 16, 18, and 20 are first transmitted to target domains 16, 18, and 20 (in step 88, the corresponding frame 70 is received, and upon receiving the PDU 72, the forwarding decision unit 90 forwards it to the PDU gateway 28 or the forwarding decision unit 92 located therein, and in step 94, it is forwarded to the corresponding target subsequent domains 16, 18, and 20, and this Within the target successor domains 16, 18, and 20, in step 108, a PDU 72 is received from another successor domain 16, 18, or 20, in step 110 the PDU 72 is combined and transmitted to the communication driver 24 of the target domains 16, 18, and 20 (step 120), which then transmits the PDU 72 within the accompanying frame 70 (step 104), and subsequently to the accompanying interface 13 (step 106), which is then transmitted to the target interface 13 of the target domains 16, 18, and 20.

[0061] Figure 10 shows the transmission and reception of frames 70 and PDU 72 by AUTOSAR domains 40, 42, and 44. In this application example, a frame 70 associated with AUTOSAR domains 40, 42, and 44, received on one of the subsequent domains 16, 18, and 20 (step 88), is transmitted (in step 96) from the communication driver 24 of this subsequent domain 16, 18, and 20 to the virtual driver 64 of AUTOSAR domains 40, 42, and 44 (as confirmed by the forwarding determination unit 90, for example, via the header 80 and from the routing table). Similarly, frames 70 to be transmitted from AUTOSAR domains 40, 42, and 44 are first transmitted within the target domains of the subsequent domains 16, 18, and 20 before being transmitted to the target interface 13. For this purpose, the corresponding virtual interface 56 transmits each frame 70 to the virtual drive 64 in step 100. The virtual drivers 64, still located within AUTOSAR domains 40, 42, and 44, transmit their respective frames 70 to the associated target domain communication drivers 24 in step 102, and then reach the associated interface 13 via step 104 (see step 106).

[0062] In the application example, transmission and reception of PDU 72 by AUTOSAR domains 40, 42, and 44 (Figure 11), an embedded PDU 72 extracted from a general-purpose PDU 72 or frame 70, and a corresponding container 74, which are associated with AUTOSAR domains 40, 42, and 44 and received on one of the subsequent domains 16, 18, and 20, are transmitted within AUTOSAR domains 40, 42, and 44. The frame 70 received in step 88 is checked for relevance or routing by the forwarding determination unit 90 and transmitted in step 91 to the forwarding determination unit 92 for the PDU 72 for AUTOSAR domains 40, 42, and 44. In step 112, transmission to AUTOSAR domains 40, 42, and 44 is performed via the PDU adapter 60 (through step 112) and the PDU router 54 (through step 114). In the transmission of PDUs from AUTOSAR domains 40, 42, and 44, transmission takes place from the PDU router 54 to the PDU adapter 60 in step 116, and to the PDU gateway in step 118. As a result of the transmission in step 110, the PDU 72 to be transmitted reaches the communication driver 24 in step 120, is converted into frames 70 associated with the respective subsequent domains 16, 18, and 20 in step 104, and subsequently transmitted to the respective interfaces 13 (step 106).

[0063] Figure 12 shows combinations of application examples. In addition to the three application examples described above (transfer decision regarding frame 70, transfer decision regarding PDU 70, and combination of transmission data of PDU 72 and frame 70 in AUTOSAR domains 40, 42, 44 and subsequent domains 16, 18, 20), it is also possible to combine these application examples. One example of such an application example is the combination of receiving PDU 72 and PDU routing by application programs 46, 48 within the subsequent domains 16, 18, 20. In this example, the received PDU 72 is distributed via the PDU transfer decision unit 92 (through transmission paths 112, 140 equipped with PDU adapters 60) to AUTOSAR domains 40, 42, 44, and through transmission paths 93, 110, 120, 104 to the software stack 26 of the same subsequent domains 16, 18, 20. Further combinations of such application examples are supported by a hybrid software architecture.

[0064] Figure 13 shows the offboard toolchain involved in the integration of subsequent domains 16, 18, and 20 for data routing. The implementation of the hybrid software architecture within the embedded software requires adaptation of the so-called offboard toolchain or development environment, as well as the ECU configuration generation workflow and the corresponding ECU flash container 146. In the hybrid software architecture, the entire range of ECU functionality is effectively divided into parts handled by the AUTOSAR domain and parts handled by subsequent domains. Therefore, the toolchain is optimized to derive configurations specific to the AUTOSAR domain and configurations specific to the subsequent domains from the complete ECU configuration (see Figure 13).

[0065] The configuration splitting unit 134, included in the creation tool 132 for the configuration data 140 and 142 for the subsequent domains 16, 18, and 20, splits the AUTOSAR-ETC configuration defined in the complete version 130 of the so-called AUTOSAR-ECU-EXTRACT in the system description file (*.arxml) into configurations specialized for data routing (as required for the subsequent domains 16, 18, and 20), and stores them within the interposed data model 136 (of these subsequent domains 16, 18, and 20) and within the configurations specialized for AUTOSAR. This constitutes a reduced version 150 of the AUTOSAR-ECU-EXTRACT. In other words, the contents of this reduced version 150 of the AUTOSAR-ECU-EXTRACT are reduced from the complete AUTOSAR-ECU-EXTRACT 130 by the amount allocated for data routing in the data model 136 of these subsequent domains 16, 18, and 20. The data routing configuration codes (*.c, *.h) are generated from this data routing data model 136.

[0066] The configuration data creation tool 132 for these subsequent domains 16, 18, and 20 is integrated into the software development toolchain and workflow entry point. For example, the full version 130 of a vehicle manufacturer's AUTOSAR-ECU-EXTRACT is input into this tool 132 to derive the configuration code 140 and the reduced version 150 of the AUTOSAR-ECU-EXTRACT. This reduced version 150 of the AUTOSAR-ECU-EXTRACT maintains consistency despite its reduced scope and can therefore be input into each AUTOSAR configuration tool and code generator 152 to generate the AUTOSAR configuration code 154. The static code 142 (*.c, *.h) of the routing unit 22 (of subsequent domains 16, 18, and 20), the static AUTOSAR code 156 (*.c, *.h), the configuration code 140 and AUTOSAR configuration code 154 of the routing unit 22 are all supplied to the compiler or linker 144, through which they are compiled and linked to generate a complete ECU software flash container 146, through which software updates can be flashed to the control unit 5.

[0067] This data model 136 for the routing units of subsequent domains 16, 18, and 20 is a compact, ECU-centric object model whose contents are derived from a complex and redundant vehicle-centric AUTOSAR data model. Configurations specific to the routing units are temporarily stored in tool 132 in the format of the data model 136 for the routing units of subsequent domains 16, 18, and 20 before the configuration code 140 is generated. This format allows for easier visualization and analysis of the data flow and communication relationships of gateway functionality 3.

[0068] This data model 136 (see Figure 14) depicts the data flow of gateway functionality 3 in the form of a directed acyclic graph (DAG), consisting of vertices (nodes) connected by directed edges (arrows). The vertices on the terminal endpoint side represent data sources 200 and data sinks 240 (communication controllers 202 (receive, e.g., CAN), 242 (transmit, e.g., CAN), 214 (receive, e.g., FR (Flexray)), 258 (transmit, e.g., FR), 210 (receive, e.g., ETH socket), 246 (transmit, e.g., ETH socket), AUTOSAR basic software 220, and AUTOSAR software components 230). The intermediate vertices are the computational steps of the gateway functionality (receiving steps (204 (CAN: receiving frames), 207 (CAN: receiving container PDUs), 209 (CAN: receiving general-purpose PDUs), 212 (ETH: receiving general-purpose PDUs / encapsulated PDUs), 216 (FR: receiving frames), 223 (FR: receiving container PDUs), 226 (receiving general-purpose PDUs)), especially the PDU unpacking steps in CAN and FR (208 (CAN: unpacking PDUs), 224 (FR: unpacking PDUs)), the transfer step, the packing step (233 (CAN: packing PDUs), 250 (FR: packing PDUs)), the transmission step (223 (CAN: transmitting encapsulated PDUs), 248 (FR: transmitting encapsulated PDUs), 235 (CAN: transmitting container PDUs)), 252 (FR: container PDUs) These represent PDU transmissions (frame 70, PDU 72, generic PDU transmission), 253 (FR: general-purpose PDU transmission), 256 (FR: frame transmission), 260 (AUTOSAR CAN: frame transmission), 262 (AUTOSAR FR: frame transmission), and 270 (CAN: frame transmission). The directed edges that connect to each other represent communication data units (frame 70, PDU 72, general-purpose PDU 72), including their interrelationships (frame 70 and PDU 72) and the temporal order of their processing. In addition, these vertices and directed edges have additional properties that describe them more precisely.

[0069] The proposed hybrid multicore software architecture for automotive control systems incorporating gateway functionality provides an optimal solution to the challenges raised. By combining the advantages of the AUTOSAR standard software architecture with a proprietary routing unit software architecture, it addresses application cases such as hosting services for in-vehicle functions or gateway functionality (high-performance data transfer). The need for adaptation to embedded software is described, along with the extensions and integrations required for the configuration data creation tool 132.

Claims

1. A method for transferring data in a vehicle communication system (11), The communication system (11) includes at least one first bus system (10, 12, 14) and at least one subsequent bus system (10, 12, 14) which is a bus system separate from the first bus system (10, 12, 14), It is possible to exchange the data between the bus systems (10, 12, 14) by using at least one first domain (40, 42, 44) as an independent execution entity. Within the first domain (40, 42, 44), application programs (46, 48) are executable, and The first domains (40, 42, 44) include at least a standardized interface to the application programs (46, 48), Successor domains (16, 18, 20), which perform functions different from the first domains (40, 42, 44), are designated as independent successor execution entities from the first domains (40, 42, 44). Only the successor domains (16, 18, 20) access the physical interface (13) of the communication system (11), thereby enabling data exchange between the communication system (11) and the first domain (40). The data (70, 72, 74) received via the physical interface (13) of the communication system (11) within the subsequent domains (16, 18, 20) is processed at least to determine whether or not it should be forwarded. Between the first domain and the subsequent domains (16, 18, 20; 40, 42, 44), data is permitted to be exchanged at the frame (70) level and / or at the data unit (72) level, using memory shared by both domains (16, 18, 20; 40, 42, 44), while between one of the subsequent domains (16, 18, 20) and another of the subsequent domains (16, 18, 20) In this case, data is not exchanged at the frame level (70), but only at the data unit level (72), characterized in that method.

2. A method for transferring data in a vehicle communication system (11), The communication system (11) includes at least one first bus system (10, 12, 14) and at least one subsequent bus system (10, 12, 14) which is a bus system separate from the first bus system (10, 12, 14), It is possible to exchange the data between the bus systems (10, 12, 14) by using at least one first domain (40, 42, 44) as an independent execution entity. Within the first domain (40, 42, 44), application programs (46, 48) are executable, and The first domains (40, 42, 44) include at least a standardized interface to the application programs (46, 48), Successor domains (16, 18, 20), which perform functions different from the first domains (40, 42, 44), are designated as independent successor execution entities from the first domains (40, 42, 44). Only the successor domains (16, 18, 20) access the physical interface (13) of the communication system (11), thereby enabling data exchange between the communication system (11) and the first domain (40). The data (70, 72, 74) received via the physical interface (13) of the communication system (11) within the subsequent domains (16, 18, 20) is processed at least to determine whether or not it should be forwarded. The performance-related data remains within the subsequent domains (16, 18, 20) for further computational processing, while additional data, which is separate from the performance-related data, is transferred to the first domain (40). method.

3. A method for transferring data in a vehicle communication system (11), The communication system (11) includes at least one first bus system (10, 12, 14) and at least one subsequent bus system (10, 12, 14) which is a bus system separate from the first bus system (10, 12, 14), It is possible to exchange the data between the bus systems (10, 12, 14) by using at least one first domain (40, 42, 44) as an independent execution entity. Within the first domain (40, 42, 44), application programs (46, 48) are executable, and The first domains (40, 42, 44) include at least a standardized interface to the application programs (46, 48), Successor domains (16, 18, 20), which perform functions different from the first domains (40, 42, 44), are designated as independent successor execution entities from the first domains (40, 42, 44). Only the successor domains (16, 18, 20) access the physical interface (13) of the communication system (11), thereby enabling data exchange between the communication system (11) and the first domain (40). The data (70, 72, 74) received via the physical interface (13) of the communication system (11) within the subsequent domains (16, 18, 20) is processed at least to determine whether or not it should be forwarded. Within the first domain (40, 42, 44), the first domain and the subsequent domain ( The invention is characterized in that, between the first domain (16, 18, 20; 40, 42, 44), at least one virtual driver (58, 60, 62, 64) is provided as a proxy for the actual driver in order to exchange frames (74) with the respective drivers (24) of the subsequent domains (16, 18, 20) and / or with the interface (56) for frames (74) provided within the first domain (40, 42, 44), and / or with at least one adapter (60) is provided within the first domain (40, 42, 44) in order to exchange data or data units (72) with the gateway (28) of the subsequent domains (16, 18, 20) and / or with the router (54) for the data units (72) provided within the first domain (40, 42, 44). method.

4. A method for transferring data in a vehicle communication system (11), The communication system (11) includes at least one first bus system (10, 12, 14) and at least one subsequent bus system (10, 12, 14) which is a bus system separate from the first bus system (10, 12, 14), It is possible to exchange the data between the bus systems (10, 12, 14) by using at least one first domain (40, 42, 44) as an independent execution entity. Within the first domain (40, 42, 44), application programs (46, 48) are executable, and The first domains (40, 42, 44) include at least a standardized interface to the application programs (46, 48), Successor domains (16, 18, 20), which perform functions different from the first domains (40, 42, 44), are designated as independent successor execution entities from the first domains (40, 42, 44). Only the successor domains (16, 18, 20) access the physical interface (13) of the communication system (11), thereby enabling data exchange between the communication system (11) and the first domain (40). The data (70, 72, 74) received via the physical interface (13) of the communication system (11) within the subsequent domains (16, 18, 20) is processed at least to determine whether or not it should be forwarded. The system description file (130) of the first domain (40, 42, 44) generates configuration codes (140, 142) relating to the transfer of data within the subsequent domains (16, 18, 20), and / or a reduced version (150) of the system description file of the first domain. method.

5. A method for transferring data in a vehicle communication system (11), The communication system (11) includes at least one first bus system (10, 12, 14) and at least one subsequent bus system (10, 12, 14) which is a bus system separate from the first bus system (10, 12, 14), It is possible to exchange the data between the bus systems (10, 12, 14) by using at least one first domain (40, 42, 44) as an independent execution entity. Within the first domain (40, 42, 44), application programs (46, 48), and The first domain (40, 42, 44) is the application program (46, 48) including at least a standardized interface, Successor domains (16, 18, 20), which perform functions different from the first domains (40, 42, 44), are designated as independent successor execution entities from the first domains (40, 42, 44). Only the successor domains (16, 18, 20) access the physical interface (13) of the communication system (11), thereby enabling data exchange between the communication system (11) and the first domain (40). The data (70, 72, 74) received via the physical interface (13) of the communication system (11) within the subsequent domains (16, 18, 20) is processed at least to determine whether or not it should be forwarded. The configuration codes (140, 142) are created using a data model (136) that describes data transfer. method.

6. The aforementioned data includes at least one data unit (72), The data unit (72) may be contained within a frame (70) transmitted via the physical interface (13), and / or within a container (74) contained within the frame (70). The method according to any one of claims 1 to 5, characterized in that the data unit (72) and / or the container (74) includes at least one header (80) and payload (82).

7. For the first bus system (10, 12, 14), a dedicated subsequent domain (16, 18, 20) is used, and for the subsequent bus system (10, 12, 14), further dedicated subsequent domains (16, 18, 20) are used. The method according to any one of claims 1 to 5, characterized in that data is exchanged between both of the aforementioned successor domains (16, 18, 20) only at the level of data units (72).

8. The method according to any one of claims 1 to 5, characterized in that, within the subsequent domains (16, 18, 20), data relating to performance-related application data is transferred and is exchanged between in-vehicle functions while the vehicle is in motion.

9. The method according to any one of claims 1 to 5, characterized in that a frame (70) transferred from a communication driver (24) to a protocol memory or protocol stack (26) is processed by the subsequent domains (16, 18, 20) by extracting data units (72) contained within a general-purpose data unit (72) and / or container (74) from the frame (70) and / or container (74).

10. The method according to any one of claims 1 to 5, characterized in that local termination (transmission and reception by hosted in-vehicle functions), transport protocol, diagnostic communication, diagnostic routing, and network management are performed within the first domain (40).

11. The transfer determination unit (90) determines that, for the received frame (70), the frame (70) having a data unit (72) and / or container (74) exists for transfer. The method according to any one of claims 1 to 5, characterized by determining whether and / or whether reception by the application is scheduled.

12. The method according to any one of claims 1 to 5, characterized in that the subsequent domains (16, 18, 20) include at least one driver (24) for linking to the physical interface (13) of the communication system (11) for a data access or control mechanism targeting layer 2 of the International Organization for Standardization's seven-tiered OSI reference model (ISO / OSI), and / or the subsequent domains (16, 18, 20) include at least one protocol memory or protocol stack (26) for a data access or control mechanism targeting layers 3 to 5 of ISO / OSI necessary for processing performance-related data on the subsequent domains (14, 16, 18), and / or the subsequent domains (16, 18, 20) include at least one gateway (28) for transferring at least one data unit (72) between protocol stacks (26) of different subsequent domains (16, 18, 20).

Images