Method for transferring data in a vehicle communication system - Patents.com

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 the transfer of data in a vehicle communication system of the kind described in the independent claim. [Background technology]

[0002] AUTOSAR (Automotive Open System Architecture) is the name given to a development partnership between automobile manufacturers, control unit manufacturers, and manufacturers of development tools, ECU basic software, and microcontrollers, with the goal of facilitating the exchange of software on various control units.

[0003] AUTOSAR provides a set of specifications that describe basic software modules, define application interfaces and establish a common development methodology based on standardized exchange formats. The AUTOSAR layered software architecture provides basic software modules that can be deployed in vehicles from different manufacturers and in electronic components from different suppliers.

[0004] From US Pat. No. 8,966,443 a method for handling AUTOSAR software components of an AUTOSAR software system is known. Summary of the Invention [Problem to be solved by the invention]

[0005] The object of the present invention is, inter alia, to further increase the computing speed of AUTOSAR software systems. [Means for solving the problem]

[0006] This problem is solved by the features of the independent claims. The method according to the features of the independent claims allows high-performance forwarding or routing of specific data for control units with integrated gateway functionality. By appropriately transferring the routing functionality to a subsequent domain, the load on the first domain, in particular the AUTOSAR domain, can be reduced. This results in a better load compensation of the whole system and an improved utilization of the hardware resources, in particular when multi-core controllers are used. The proposed hybrid software architecture with task distribution using different domains allows, on the one hand, the software to be kept unchanged in the AUTOSAR domain for the hosting of vehicle functions, while on the other hand the software can be optimized in the subsequent domain, in terms of data forwarding performance and thus for performance-related application cases. The proposed distribution of functions to different domains and thus to different execution entities allows these functions to be flexibly distributed to one or several CPU cores depending on the system requirements and system design. Low latencies in routing can be achieved on the basis of the proposed solution, in particular during vehicle operation. This is achieved, among other things, by the fact that data exchange with the first domain is always performed via the subsequent domain featuring a high-power transfer mechanism. It is particularly preferred if performance-relevant data remains in the subsequent domain for further computational processing, while further data is transferred to the first domain.

[0007] In a preferred deployment configuration, a dedicated subsequent domain is used for the first bus system and a further dedicated domain for the subsequent bus system, with data exchange between both subsequent domains solely at the level of data units, in particular protocol data units (PDUs), in particular generic data units and / or data units encapsulated in containers.When the vehicle is running in normal mode, these very routing mechanisms are applied generically to application data exchanged between vehicle functions on the various control units.

[0008] In a preferred deployment configuration, data is allowed to be exchanged between the first domain and the subsequent domains at frame level and / or data unit level, in particular using a memory shared by both domains, while data is not exchanged between one of the subsequent domains and another of the subsequent domains at the frame level but only at the data unit level. This allows for a function- and protocol-independent data exchange mechanism to be used. It is thereby achieved that the interfaces defined in the AUTOSAR standard can be maintained, so that the integration of the first domain in the overall system is easier or can be maintained as usual. Data unit-based data exchange within these subsequent domains can be performed with particularly high speed and performance.

[0009] In a preferred deployment configuration, it is contemplated that the subsequent domain includes at least one driver for linking to a physical interface of the communication system, in particular a bus system, for data access or control mechanisms, in particular for layer 2 of the International Organization for Standardization's seven-layer OSI reference model (ISO / OSI), and / or that the subsequent domain includes at least one protocol memory or protocol stack, in particular for data access or control mechanisms, in particular for ISO / OSI layers 3-5, required for processing performance-related data from the subsequent domain, and / or that the subsequent domain includes at least one gateway for transferring at least one data unit, in particular between protocol stacks of different subsequent domains, thereby, in part, ensuring communication only through the subsequent domain. In addition, it is possible to perform high-performance processing of performance-related applications, for example, processing of non-transport protocols to extract data units for high-performance routing.

[0010] In a preferred deployment configuration, it is provided that in the first domain, in particular the AUTOSAR domain, virtual drivers are provided, in particular as proxies for real drivers, for exchanging frames with the respective drivers of the subsequent domain and / or with interfaces for frames provided in the first domain between the first domain and the subsequent domain, and / or that at least one adapter is provided in the first domain for exchanging data or data units with a gateway of the subsequent domain and / or with a router for data units provided in the first domain. This ensures that direct access to the physical communication interfaces is limited to the subsequent domain. Nevertheless, care can be taken to incorporate the subsequent domain in particular into the AUTOSAR architecture definition accordingly via these virtual interfaces. Via the adapter, data exchange with the subsequent domain at the level of data units can be ensured.

[0011] In a preferred deployment configuration, it is provided that from the full system description file of the first domain, in particular the AUTOSAR-ECU-Extract, a configuration code for the transfer of data in the subsequent domain and / or a reduced version of the system description file of the first domain, in particular the AUTOSAR-ECU-Extract, is generated. This allows optimizing the existing tool chain to derive domain-specific configurations from a set of ECU configurations. This allows an automated process of software generation for both domains. This refers to a tool-assisted solution for the computation of AUTOSAR standard input information (in particular the ECU-Extract in ARXML (AUTOSAR XML) format) for configuring the software of the AUTOSAR domain and also of the subsequent domain.

[0012] In one preferred deployment example, the configuration code is written using a data model describing the transfer of data, via which data about the routing devices extracted from the subsequent domain ECU extracts can be stored and visualized.

[0013] Further developments emerge from the further dependent claims and the description. [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 illustrates a classic E / E architecture for an automobile. [Diagram 2] FIG. 1 is a diagram showing a domain-based E / E architecture for an automobile. [Diagram 3] FIG. 1 illustrates a centralized E / E architecture for an automobile. [Figure 4] FIG. 1 is a conceptual diagram of a hybrid software architecture. [Diagram 5] FIG. 2 is a schematic diagram of a data structure. [Figure 6] FIG. 2 illustrates various data paths within a hybrid software architecture. [Figure 7] FIG. 1 illustrates a data path for routing PDUs and containers within one of the subsequent domains. [Figure 8] FIG. 1 illustrates a data path for routing PDUs and containers between two of the subsequent domains, with respect to the receiving portion. [Figure 9] FIG. 1 illustrates a data path for routing PDUs and containers between two of the subsequent domains, with respect to the transmission portion. [Figure 10] FIG. 1 illustrates data paths for sending and receiving frames by an AUTOSAR domain. [Figure 11] FIG. 1 illustrates data paths for sending and receiving PDUs by an AUTOSAR domain. [Figure 12]A diagram showing a data path for receiving a PDU by an application program and routing the PDU. [Figure 13] FIG. 1 illustrates tools and workflows for a hybrid software architecture. [Figure 14] FIG. 2 illustrates a data model of a routing device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] The invention is illustrated diagrammatically on the basis of an embodiment and will be described in detail below with reference to the drawings. In the automotive context, the vehicle's electric / electronic (E / E) architecture comprises a network of electronic control units (ECUs) 5 connected to each other via communication channels. These E / E architectures are designed in such a way that the exchange of information between the electronic control units (ECUs) 5 is limited. This limitation of information is technically done by a gateway functionality 3 that is integrated into the communication interfaces in the vehicle, either as a pure software solution or as a software / hardware solution in 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 vehicle bus technologies (e.g. CAN, LIN, FlexRay, Ethernet or similar) to each other and to allow the controlled transmission of communication messages between them. Different E / E architectures are shown in figures 1 to 3.

[0016] The classical E / E architecture according to Fig. 1 features a central gateway 2 with gateway functionality 3, via which several communication channels (each with a control unit 5) are connected to one another. The control units 5 of sub-groups may be connected to one another from a data link point of view via sub-gateways 4 that are also equipped with gateway functionality 3.

[0017] A domain-based E / E architecture associated with a domain according to Fig. 2 also comprises a central gateway 2 which interconnects a number of domain control units 6 containing gateway functionality 3 for data exchange purposes. Via these domain control units 6 further control units 5 for data exchange purposes or, depending on the architecture, sub-gateways 4 to which the control units 5 are connected may also be provided.

[0018] In the centralized E / E architecture associated with zones according to FIG. 3, several zone control units 9 with gateway functionality 3 are provided, which can be arranged, for example, at different locations in the vehicle. These zone control units 9 are connected to one another 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 comprises a gateway functionality 3. Via these zone control units 9, further control units 5 are connected from the point of view of data links, which are arranged in the area of ​​this zone in a spatially distributed manner (for example at the front left, front right, rear of the vehicle, etc.). Depending on the application case, sub-gateways 4 can also be provided, which are linked to the further control units 5.

[0019] The main application case for most control units 5 is the hosting of application software components for various vehicle functions (e.g. braking, engine control, energy management, etc.). To facilitate this, AUTOSAR defines a standard specification for an automotive software architecture. AUTOSAR defines standard interfaces to the application software components in the real-time environment (also called RTE (Real-time-environment)) and the corresponding infrastructure mechanisms for the basic software, such as operating systems, communication, diagnostics, non-volatile data memory, etc. It is therefore advantageous to maintain a standardized approach for this application case using the standard software AUTOSAR.

[0020] However, control units incorporating gateway functionality 3 are required to fulfill large volume data handling functions, e.g. high performance forwarding of communication messages. Although the required routing functionality is defined and supported by the AUTOSAR standard, the routing capabilities of the AUTOSAR standard software are often insufficient to meet performance requirements, e.g. as defined by vehicle manufacturers. The possibilities to optimize the software for performance are limited due to the software architecture, functionality and interfaces being standardized by AUTOSAR, as well as liability issues in case of changes to the standard software. Moreover, the different communication paradigms and routing mechanisms of vehicle manufacturers provide additional optimization possibilities via 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] In the following example embodiment, the gateway functionality 3 enabling large volume data handling or data routing for AUTOSAR environment is described in more detail. For the control unit 5 which is required to fulfill both the application case (hosting service function for vehicle functions) and also the gateway functionality 3, a high performance software architecture and a complete software solution is proposed. This is called a hybrid multi-core software architecture for the vehicle controller with the gateway functionality 3 embedded.

[0022] This hybrid software architecture is divided into independent execution entities, referred to below as domains 16, 18, 20; 40, 42, 44. These domains 16, 18, 20; 40, 42, 44 can be specified independently of one another and are characterized by different partitions, in particular software partitions. The communication between the different domains 16, 18, 20; 40, 42, 44 proceeds via corresponding interfaces or, for example, via a specific memory concept (shared memory concept: for example a ring buffer, which the different domains 16, 18, 20; 40, 42, 44 are allowed to access according to certain rules (write / read, storage area, etc.) in order to exchange data. In a multicore CPU system (microcontroller or microprocessor or System on Chip (SoC)), these domains can be flexibly distributed across one or several CPU cores depending on the system requirements and the design of the control unit. A generic data exchange mechanism allows the exchange of data between the domains 16, 18, 20; 40, 42, 44 and cores or within a computer core as an inter-domain communication part 30, 66 between at least the first domain 40, 42, 44, in particular the AUTOSAR domain, and the subsequent domains 16, 18, 20, in particular the communication domain.

[0023] An additional partitioning of the software architecture into independent execution units is introduced, referred to below as so-called domains 16, 18, 20; 40, 42, 44. These domains 16, 18, 20; 40, 42, 44 have corresponding execution functions available, which can be flexibly integrated into the scheduling of the operating system as cyclic, i.e. periodic or interrupt tasks, to achieve the required ECU system behavior.

[0024] The components of the AUTOSAR architecture are allocated to at least one (first) domain 40, 42, 44, or depending on the application also to several (first) domains 40, 42, 44, which are referred to in the following as first or AUTOSAR domains 40, 42, 44 and which correspond fully to the AUTOSAR standard without modification. The AUTOSAR domains 40, 42, 44 may be realized as an AUTOSAR single-core or multi-core architecture. Within the AUTOSAR domains 40, 42, 44, depending on the application, different application programs 46 may be provided, which are exemplarily illustrated as vehicle function programs 48.1, 48.2, ..., 48.n. Furthermore, each AUTOSAR domain 40, 42, 44 comprises basic software 52, which may include, for example, a router, in particular a PDU router 54 (I-PDU router (I-PDU: Interaction layer Protocol Data Unit, data unit defined by AUTOSAR, in the following also called PDU (Protocol Data Unit) or data unit)) and / or an interface 56 for the bus system used (for example CAN, FlexRay, Ethernet, etc.).

[0025] Independently of the at least one (first) AUTOSAR domain 40, 42, 44, there is at least one subsequent domain 16, 18, 20, preferably several subsequent domains 16, 18, 20, each of which has an independent execution function for data routing and handling. It is particularly preferred if for each communication protocol (of each communication system 11) a dedicated domain 16, 18, 20 is provided, e.g. a CAN domain 20, a FlexRay domain 18, an Ethernet domain 16, etc. The subsequent domains 16, 18, 20 have access to the respective physical interface 13 of the communication system 11 and process the messages of the respective communication system 11.

[0026] The functional division between the AUTOSAR domains 40, 42, 44 and the subsequent domains 16, 18, 20, in particular the division of the data routing functions, is performed in such a way that performance-related application cases featuring fast routing or forwarding of data are assigned to the subsequent domains 16, 18, 20. The majority of all data transfers to be realized by the gateway functionality 3 in the control unit make use of the so-called PDU and container routing mechanisms. This routing mechanism is applied comprehensively to application data exchanged between the vehicle functions on the control unit 5 when the vehicle is running (normal mode). This application case places high demands on low latency in routing and is therefore assigned to one or more subsequent domains 16, 18, 20 for routing or forwarding the data. Within the subsequent domains 16, 18, 20, the forwarding of data is performed in association with the data units PDU 72 or containers 74, in particular by information in the header 80 and forwarding information, such as is stored in a routing table. Through the header 80 or information attached thereto, it is possible to identify how the following payload 82 should be interpreted or forwarded.

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

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

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

[0030] The subsequent domains 16, 18, 20 specialized for communication protocols can be flexibly allocated to CPU cores to realize single or multi-core implementations: each subsequent domain 16, 18, 20 can be assigned to a different CPU core (e.g. a CAN core, an Ethernet core, ...) or several or all subsequent domains 16, 18, 20 can be assigned to individual cores (e.g. CAN, FlexRay and Ethernet on individual cores).

[0031] The communication data exchange between the AUTOSAR domains 40, 42, 44 and the subsequent domains 16, 18, 20 is carried out via a generic data exchange mechanism, which is based on the shared memory concept as described above, for example, and is called inter-domain communication 30, 66 located in the first and subsequent domains 16, 18, 20: 40, 42, 44, which communicate with each other as suggested in FIG. 4.

[0032] The inter-domain communication component 30, 66 is a function and protocol independent data exchange mechanism that allows the transmission of blocks of data from a sender to one or more receivers.

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

[0034] When the areas for exchanging data between each other are allocated to various cores according to the control unit design, the same data exchange mechanism is called an inter-core communication part. Within the framework of this application scheme, the data units frame 70, PDU 72 and container 74 according to Fig. 5 are of significant relevance. The format of these data units follows the TLV (Type-Length-Value) scheme. The type (identifier, additional protocol parameters) and the length (of the payload 82 or payload data in bytes) are meta-information, which together are called the header 80 and describe the contents of the data value (payload 82 or user data).

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

[0036] A PDU 72 corresponds to all or part of the payload 82 of a frame 70 in which application data (e.g. from signals of physical or functional relevance such as vehicle speed, ambient temperature, error status flags, ...) is contained. A PDU 72 has its own header 80 and data payload 82.

[0037] A container 74 for a PDU 72 is a collector that is used to group multiple PDUs 72 enclosed within it. A PDU 72 that is transmitted enclosed within a frame 70 without a container 74 is called a generic PDU 72. The container 74, the PDU 72 enclosed within the container 74, and the generic PDU 72 each have their own header 80 and data payload or payload 82. These data units may have a nested structure in which a frame 70 is made up of generic PDUs 72 and / or container-encapsulated PDUs 72, and the container-encapsulated PDU 72 itself is made up of a container 74-encapsulated PDU 72, as exemplarily shown in FIG. 5.

[0038] In order to accommodate the interfaces (APIs: Application Programming Interfaces) defined in the AUTOSAR standard, data can be exchanged between the subsequent domains 16, 18, 20 and the AUTOSAR domains 40, 42, 44 at the level of data units / frames 70 (see the double-headed arrow in the lower part of FIG. 4 between the communication driver 24 of the subsequent domain 16, 18, 20 and the virtual driver 64 of the first domain 40, 42, 44) and at the level of data units / PDUs 72 (generic and encapsulated PDUs 72 in containers 74, as suggested in FIG. 4 via the double-headed arrow 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 domain 40, 42, 44).

[0039] In order to accommodate data units exchanged with the AUTOSAR domains 40, 42, 44, between the subsequent domains 16, 18, 20 data exchange is only permitted at the level of data units PDUs 72 (generic and / or PDUs 72 encapsulated in containers 74). Between two subsequent domains 16, 18, 20 based on different communication protocols (CAN, FlexRay, Ethernet), data exchange at frame level is not possible, since the respective protocols have different frame layouts.

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

[0041] The software architectures of the subsequent domains 16, 18, 20 are similarly implemented for the respective communication protocol (CAN, FlexRay, Ethernet) (see Fig. 4). Every routing device 22 for each subsequent domain 16, 18, 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 protocol layers (e.g. CAN / FR / ETH...) and a protocol-independent PDU gateway 28 for forwarding PDUs 72. To exchange data with other (subsequent) domains 16, 18, 20 or AUTOSAR domains 40, 42, 44, an inter-domain communication entity 30 is required.

[0042] The communication driver 24 is responsible for the implementation of ISO / OSI Layer 2 with regard to data access (read / write) and control mechanisms (mode management and error management) essential to handle the communication control system and physical interface 13 of the respective communication protocol (CAN, FlexRay FR, Ethernet ETH, ...).

[0043] The communication protocol stack 26 or communication protocol memory is responsible for the implementation only of the data access and control mechanisms of ISO / OSI layers 3-5, which are essential for handling routing related applications on the subsequent domains 16, 18, 20. This area includes, among other things, the computation of non-transport protocol messages (Non-ISO-TP, UDP) to extract PDUs 72 for high performance routing.

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

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

[0046] The AUTOSAR layered architecture is an autonomous and completely standard architecture. To incorporate a proprietary routing architecture into it, software modules 58, 60, 62, 64 located on the first domains 40, 42, 44 and directly connected to any AUTOSAR standard modules 52, 54, 56 must be introduced and integrated into the definition of the AUTOSAR architecture of the control units. The AUTOSAR standard offers the possibility to use Complex Device Drivers 58 (CDD) for such integration.

[0047] Within the AUTOSAR standard architecture, the drivers of the communication interfaces (CAN driver / FlexRay driver / Ethernet driver) are part of the Microcontroller Abstraction Layer (MCLA) which constitutes a layered architecture. Since within the hybrid software architecture direct access to the physical communication interfaces 13 is limited to the subsequent domains 16, 18, 20, the MCALs on the AUTOSAR domains 40, 42, 44 have to adapt to the corresponding protocols via so-called Virtual Communication Drivers or Virtual Drivers 64 (CDD). As the name already suggests, these virtual drivers 64 are not real drivers but proxies for real drivers and are used as standard AUTOSAR-APIs to the higher interface modules (CAN interface / FlexRay interface / Ethernet interface) of the so-called ECU Abstraction Layer (ECUAL). These virtual drivers 64 also interact with their counterparts on the respective subsequent domains 16, 18, 20, specifically with the real communication drivers 24, via the inter-domain communication units 30, 66 located correspondingly on the AUTOSAR domains 40, 42, 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 the various software modules of the layers above and below. To enable the exchange of PDUs 72 between the AUTOSAR domains 40, 42, 44 and the subsequent domains 16, 18, 20, a driver CDD (AUTOSAR ComplexDeviceDriver) called 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 the respective subsequent domains 16, 18, 20 via the inter-domain communication units 30, 66 to exchange PDUs 72. This is done by the shared memory architecture already described, i.e. a common memory, for example a ring memory.

[0049] Within the AUTOSAR domains 40, 42, 44, an inter-domain communication entity 66 is implemented as specification to enable data exchange with the corresponding counterparts in the subsequent domains 16, 18, 20. Frames 70 and PDUs 72 are sent and received within the AUTOSAR domains 40, 42, 44 by transferring these data units to and from the virtual communication driver 64 (at frame level) or the PDU adapter 60 (at PDU level). However, unlike the virtual communication driver 64 and the PDU adapter 60, this inter-domain communication entity 66 is not directly connected to the standard AUTOSAR modules 52, 54, 56 and therefore must not be incorporated into the AUTOSAR architecture definition.

[0050] To address the in-vehicle functions and the hosting services of the gateway application case 5, data is transferred from both data sources, specifically the physical communication interface 13 and the application software components, along various data paths within the hybrid software architecture and processed as is evident from FIG. 6.

[0051] Within the subsequent domains 16, 18, 20 or their associated communication drivers 24, there are respectively forwarding decisions 90 for the received frames or frames 70 for further processing of the frames 70 received directly from the respective interfaces 13 (CAN, FlexRay, Ethernet). The subsequent domains 16, 18, 20 have independent execution functions for routing data. According to the configurable forwarding decision 90 after evaluation of the header 80 for the frame 70 inside the communication driver 24, the received frame 70 is forwarded (at step 88) to one of the following targets: - for AUTOSAR domains 40, 42, 44 only: frames 70 that are to be further processed only in the AUTOSAR domains 40, 42, 44 are forwarded to the AUTOSAR (CAN / FlexRay / Ethernet) interface module 56 only via the respective virtual driver 64 (CDD). - Only for the subsequent domains 16, 18, 20: The frames 70 with the application-related PDUs 72 to be extracted and further processed are forwarded only upwards (to the respective subsequent domains 16, 18, 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, 20. - for both the AUTOSAR domains 40, 42, 44 and the subsequent domains 16, 18, 20: for certain special cases, the frame 70 is also transferred to the AUTOSAR domains 40, 42, 44 and also upwards within the software stack or communication protocol stack 26 of the subsequent domains 16, 18, 20.

[0052] The forwarding decision 90 for a received slot or frame 70 can be summarized as follows: - For AUTOSAR domains 40, 42 and 44 only -Diagnostics 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)) -Diagnostics 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) - For subsequent domains 16, 18, and 20 only A frame 70 with a PDU 72 for PDU routing and / or container routing and / or reception by an application program. - For both AUTOSAR domains 40, 42, 44 and their successor domains 16, 18, 20 Only related to ETH: ARP (Address Resolution Protocol) SOME / IP-SD (Scalable service-Oriented Middleware over IP - Service Discovery) A forwarding decision unit 92 for the received PDU 72 Frames 70 transferred upward in the software stack 26 from the communications driver 24 are further processed to extract either a generic PDU 72 and / or a container PDU 72 that currently contains the PDU 72 contained therein as the smallest data unit that cannot be further divided.

[0053] A generic PDU 72 or an encapsulated PDU 72 (in a container 74) is forwarded within the PDU gateway 28 to one of the following targets according to a configurable PDU forwarding decision unit 92: Only for the AUTOSAR domains 40, 42, 44: PDUs 72 which are only relevant for receiving application programs 46, 48 hosted in the AUTOSAR domains 40, 42, 44 are forwarded to the AUTOSAR PDU router 54 via the PDU adapter 60 only. - For subsequent domains 16, 18, 20 only: PDU 72, which is only related to PDU Routing and Container Routing: - If the target interface 13 is located in the same subsequent domain 16, 18, 20, it is forwarded back down within the communication protocol stack 26 of the routing device 22 and within the communication driver 24 for transmission.

[0054] - If the target interface 13 is in another subsequent domain 16, 18, 20, it is forwarded to the PDU gateway 28 of the respective subsequent domain 16, 18, 20 for transmission. - For both AUTOSAR domains 40, 42, 44 and their successor domains 16, 18, 20: - PDUs 72, which are both received by the applications 46, 48 and which are also relevant for PDU routing and container routing, are forwarded to the AUTOSAR domains 40, 42, 44 and to the target domains of the subsequent domains 16, 18, 20.

[0055] Combining the transmission data of PDU72 and Frame70 for AUTOSAR domains 40, 42, 44 and the subsequent domains 16, 18, 20: Since only the subsequent domains 16, 18, 20 have direct access to the physical interface 13, the transmission data between the AUTOSAR domains 40, 42, 44 and the subsequent domains 16, 18, 20 must be combined and transmitted to the associated target interface 13 (CAN / FlexRay / Ethernet) on the subsequent domain 16, 18, 20.

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

[0057] The frames 70 are transferred from the basic software 52 in the 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 domain 16 , 18 , 20 .

[0058] Data paths for various application cases In a hybrid software architecture, a specific subset of the computation unit, forwarding decision unit, and data path becomes significant based on each application case. In the following paragraphs, we explain the data paths for various application cases in conjunction with Figures 6 to 12.

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

[0060] PDU routing and container routing between subsequent domains 40, 42, 44 are shown in Figure 8 (receiving part) and Figure 9 (sending part). In this application (steps 88, 90, 91, 92, 94 (Figure 8), steps 108, 110, 120, 104, 106 (Figure 9)), PDUs 72 and / or containers 74 received on the source domain 16, 18, 20 are first transmitted to the target domain 16, 18, 20 (step 88 receives the corresponding frame 70, the forwarding decision unit 90 forwards the received PDU 72 to the PDU gateway 28 or a forwarding decision unit 92 therein, step 94 forwards it to the corresponding target subsequent domain 16, 18, 20, and so on). Within the target subsequent domain 16, 18, 20, the PDUs 72 are received from another subsequent domain 16, 18, 20 in step 108, and in step 110, the PDUs 72 are combined and transmitted to the communication driver 24 of the target domain 16, 18, 20 (step 120), which completes the transmission of the PDUs 72 in the attached frame 70 (step 104) and subsequently to the attached interface 13 (step 106) to the target interface 13 of the target domain 16, 18, 20.

[0061] 10 shows the transmission and reception of frames 70 and PDUs 72 by the AUTOSAR domains 40, 42, 44. In this application example, a frame 70 received (step 88) on one of the subsequent domains 16, 18, 20 and related to the AUTOSAR domain 40, 42, 44 (as identified in the forwarding decision 90, for example via the header 80 and from the routing table) is transmitted (in step 96) from the communication driver 24 of this subsequent domain 16, 18, 20 to the virtual driver 64 of the AUTOSAR domain 40, 42, 44. Similarly, a frame 70 to be transmitted from the AUTOSAR domain 40, 42, 44 is first transmitted into the target domain of the subsequent domain 16, 18, 20 and then to the target interface 13. To this end, the corresponding virtual interface 56 transmits the respective frame 70 to the virtual driver 64 in step 100. The virtual driver 64 still residing in the AUTOSAR domain 40, 42, 44 transmits the respective frame 70 in step 102 to the communication driver 24 of the associated target domain 16, 18, 20 and then via step 104 to the associated interface 13 (see step 106).

[0062] In the application case sending and receiving a PDU 72 by an AUTOSAR domain 40, 42, 44 (FIG. 11), a generic PDU 72 or a encapsulated PDU 72 extracted from a frame 70 and a corresponding container 74, which is received on one of the subsequent domains 16, 18, 20 and is relevant to the AUTOSAR domain 40, 42, 44, is transmitted into the AUTOSAR domain 40, 42, 44. The frame 70 received in step 88 is checked for relevance or routing in a forwarding decision 90 and transmitted in step 91 to a forwarding decision 92 of the PDU 72 for the AUTOSAR domain 40, 42, 44. In step 112, transmission to the AUTOSAR domain 40, 42, 44 takes place via the PDU adapter 60 (via step 112) and the PDU router 54 (step 114). In the case of the transmission of PDUs from the AUTOSAR domains 40, 42, 44, the transmission takes place from the PDU router 54 to the PDU adapter 60 in step 116 and to the PDU gateway in step 118. By means of the transmission in step 110, the PDU 72 to be transmitted reaches the communication driver 24 in step 120, where it is converted in step 104 into the frame 70 belonging to the respective subsequent domain 16, 18, 20 and subsequently transmitted to the respective interface 13 (step 106).

[0063] 12 shows a combination of application cases. In addition to the three application cases mentioned above (forwarding decision on frame 70, forwarding decision on PDU 70, combining transmission data of PDU 72 and frame 70 of AUTOSAR domain 40, 42, 44 and subsequent domain 16, 18, 20), it is also possible to combine these application cases. An example of such an application case is the combination of receiving PDU 72 by application program 46, 48 inside the subsequent domain 16, 18, 20 and PDU routing. In this case, the received PDU 72 is split via PDU forwarding decision 92 to AUTOSAR domain 40, 42, 44 (through transmission path 112, 140 with PDU adapter 60) and in the software stack 26 of the same subsequent domain 16, 18, 20 through transmission path 93, 110, 120, 104. Further combinations of such application cases are supported by the hybrid software architecture.

[0064] In Figure 13, the off-board tool chain for the integration of the subsequent domains 16, 18, 20 for data routing is shown. The implementation of a hybrid software architecture in embedded software has to be supplemented by the adaptation of the so-called off-board tool chain or development environment as well as the generation workflow of the ECU configuration and the corresponding ECU flash container 146. In a hybrid software architecture, the full scope of ECU functionality is essentially split into parts covered by the AUTOSAR domain and parts covered by the subsequent domains. For this reason, the tool chain is optimized to derive a configuration specific to the AUTOSAR domain and a configuration specific to the subsequent domain from the complete configuration of the ECU (see Figure 13).

[0065] A configuration splitter 134 included in a tool 132 for generating configuration data 140, 142 for the subsequent domains 16, 18, 20 splits the AUTOSAR-ETC configuration defined in the so-called full AUTOSAR-ECU-EXTRACT 130 of the system description file (*.arxml) into configurations specific to data routing (as required for the subsequent domains 16, 18, 20) and stores them in the intervening data model 136 (of the subsequent domains 16, 18, 20) and in the AUTOSAR-specific configurations, which become a so-called reduced version of AUTOSAR-ECU-EXTRACT 150. The content of this reduced version of AUTOSAR-ECU-EXTRACT 150 is thus reduced from the complete AUTOSAR-ECU-EXTRACT 130 by the portions allocated for data routing in the data model 136 of the subsequent domains 16, 18, 20. Data routing configuration code (*.c, *.h) is generated from this data routing data model 136 .

[0066] This configuration data creation tool 132 for the subsequent domains 16, 18, 20 is integrated into the entry point of the software development tool chain and workflow. For example, the full version 130 of the AUTOSAR-ECU-EXTRACT of the vehicle manufacturer is input to this tool 132 in order to derive a configuration code 140 and a reduced version 150 of the AUTOSAR-ECU-EXTRACT. This reduced version 150 of the AUTOSAR-ECU-EXTRACT, although reduced in scope, remains consistent and can therefore be input to the respective AUTOSAR configuration tool and code generator 152 in order to generate the AUTOSAR configuration code 154. Both the static code 142 (*.c, *.h) of the routing unit 22 (of the subsequent domains 16, 18, 20), the static AUTOSAR code 156 (*.c, *.h) as well as the configuration code 140 and the AUTOSAR configuration code 154 of the routing unit 22 are fed to a compiler or linker 144, which compiles and combines them to generate a complete ECU software flash container 146 via which the software update can be flashed to the control unit 5.

[0067] This data model 136 of the routing units of the subsequent domains 16, 18, 20 is a compact ECU-centric object model whose content is derived from the complex and redundant vehicle-centric AUTOSAR data model. The specific configuration for the routing units is temporarily stored in the tool 132 in the format of the data model 136 of the routing units of the subsequent domains 16, 18, 20 before the configuration code 140 is generated. This format allows the data flows and communication relationships of the gateway functionality 3 to be more easily visualized and analyzed.

[0068] This data model 136 (see FIG. 14) depicts the data flow of the 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, AUTOSAR software components 230). The intermediate vertices are the computational steps of the gateway functionality (reception steps (204 (CAN: receive frame), 207 (CAN: receive container PDU), 209 (CAN: receive generic PDU), 212 (ETH: receive generic / encapsulated PDU), 216 (FR: receive frame), 223 (FR: receive container PDU), 226 (receive generic PDU)), in particular the unpacking steps of the PDUs in CAN and FR (208 (CAN: unpack PDU), 224 (FR: unpack PDU)), the forwarding steps, the packing steps (233 (CAN: pack PDU), 250 (FR: pack PDU)), the sending steps (223 (CAN: send encapsulated PDU, 248 (FR: send encapsulated PDU), 235 (CAN: send container PDU)), 252 (FR: send container PDU)), and in particular the unpacking steps of the PDUs in CAN and FR (208 (CAN: unpack PDU), 224 (FR: unpack PDU)), the forwarding steps, the packing steps (233 (CAN: pack PDU), 250 (FR: pack PDU)), the sending steps (223 (CAN: send encapsulated PDU, 248 (FR: send encapsulated PDU), 235 (CAN: send container PDU)), 252 (FR: send container PDU)). The vertices and directed edges represent the communication data units (Frame 70, PDU 72, Generic PDU 72), 253 (FR: Send PDU), 256 (FR: Send Frame), 260 (AUTOSAR CAN: Send Frame), 262 (AUTOSAR FR: Send Frame), 270 (CAN: Send Frame)), and the connected directed edges represent the communication data units (Frame 70, PDU 72, Generic PDU 72), including their interrelationships (PDU 72 of Frame 70) and the time order of their computation. 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 offers an optimal solution to the challenges posed. It combines the advantages of the AUTOSAR standard software architecture with a proprietary routing unit software architecture to solve the use cases of in-vehicle function hosting services or gateway functionality (high performance data transfer). Alongside the description of the adaptation needs for the embedded software, the required extensions and integrations of the configuration data creation tool 132 are also described.

Claims

1. A method for the transfer of data in a vehicle communication system (11), 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 to said application programs (46, 48), in particular the AUTOSAR real-time environment; A subsequent domain (16, 18, 20) is a subsequent execution entity independent of the first domain (40, 42, 44), and only the subsequent domain (16, 18, 20) accesses 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 in said subsequent domain (16, 18, 20) via a physical interface (13) of said communication system (11) is processed at least as to whether it needs to be forwarded or not; method.

2. said data comprising at least one data unit (72), in particular an AUTOSAR I-PDU or hereinafter a Protocol Data Unit (PDU); The data units (72) may be encapsulated in a frame (70) transmitted over the physical interface (13) and / or in a container (74) encapsulated in the frame (70), 2. The method according to claim 1, characterized in that the data unit (72) and / or the container (74) comprises at least one header (80) and a payload (82), in particular application data, such as a signal having physical or functional compatibility.

3. For a first bus system (10, 12, 14) a dedicated subsequent domain (16, 18, 20) is used and for a subsequent bus system (10, 12, 14) a further dedicated subsequent domain (16, 18, 20) is used, 3. The method according to claim 1 or 2, characterized in that the exchange of data between both subsequent domains (16, 18, 20) is carried out exclusively at the level of data units (72), in particular generic data units (72) and / or data units (72) enclosed in containers (74).

4. 4. The method according to claim 1, further comprising transferring data within the subsequent domain (16, 18, 20), in particular related to performance-related application data, in particular exchanged between on-board functions, in particular on a control unit (5), in particular when the vehicle is moving.

5. 5. The method according to claim 1, characterized in that data is allowed to be exchanged between the first domain and the subsequent domains (16, 18, 20; 40, 42, 44) at the level of frames (70) and / or at the level of data units (72), in particular using a memory shared by both domains (16, 18, 20; 40, 42, 44), while data is not exchanged between one of the subsequent domains (16, 18, 20) and another of the subsequent domains (16, 18, 20) at the level of the frames (70), but only at the level of the data units (72).

6. 6. The method according to claim 1, characterized in that the performance related data remains in the subsequent domain (16, 18, 20) for further processing, while further data is transferred to the first domain (40).

7. 7. The method according to claim 1, wherein a frame (70) transferred from a communication driver (24) to a protocol memory or protocol stack (26) is processed by the subsequent domain (16, 18, 20), in particular by extracting generic data units (72) and / or data units (72) encapsulated in containers (74) from the frame (70) and / or containers (74).

8. 8. The method according to claim 1, characterized in that within the first domain (40) application cases such as local termination (sending and receiving by hosted vehicle functions), transport protocols, diagnostic communication, diagnostic routing, network management, etc. are executed.

9. 9. The method according to claim 1, wherein the forwarding decision unit (90) determines for a received frame (70) whether a frame (70) having a data unit (72) and / or a container (74) is present for forwarding and / or is scheduled for reception by an application.

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

11. at least one virtual driver (58, 60) in said first domain (40, 42, 44) for exchanging frames (74) between said first domain and said subsequent domain (16, 18, 20; 40, 42, 44) with a respective driver (24) of said subsequent domain (16, 18, 20) and / or with an interface (56) for the frames (74) provided in said first domain (40, 42, 44), in particular an AUTOSAR protocol interface; 11. The method according to claim 1, wherein at least one adapter (60) is provided in the first domain (40, 42, 44) for exchanging data or data units (72) with the gateway (28) of the subsequent domain (16, 18, 20) and / or with a router (54), in particular an AUTOSAR PDU router, in particular an AUTOSAR complex device driver (CDD), provided in the first domain (40, 42, 44).

12. 12. The method according to claim 1, characterized in that from a full version of a system description file (130) of the first domain (40, 42, 44), in particular an AUTOSAR-ECU-Extract, a configuration code (140, 142) for the transfer of data in the subsequent domain (16, 18, 20) and / or a reduced version (150) of the system description file of the first domain, in particular an AUTOSAR-ECU-Extract, is generated.

13. 13. The method according to claim 1, characterized in that at least the configuration code (140) of the subsequent domain (16, 18, 20) and the configuration code (154) of the first domain (40, 42, 44) are provided to a compiler or linker (144) for creating a flash container (146) of a control unit (5).

14. 14. The method according to claim 1, wherein the configuration code (140, 142) is created using a data model (136) describing a data transfer.

Images