Method for operating a communication interface for a vehicle development test bench system for data exchange with regard to a software product to be tested for a vehicle under development, communication interface and vehicle development test bench system

Abstract

Method for operating a communication interface (10) for a non-publicly accessible vehicle development test facility (30) for data exchange with regard to a software product to be developed by an external development partner and / or to be provided by the external development partner to the communication interface (10) within the framework of a specified test order at the vehicle development test facility (30) with regard to the implementation of at least one operating function for a vehicle to be developed, wherein the vehicle development test facility has a plurality of test stations, each of which is configured and / or configurable for testing at least one operating function of a plurality of operating functions for the vehicle to be developed.According to the invention, the communication interface, based on the specified test order, captures the software product to be tested as well as metadata assigned to the software product to be tested, on the basis of which a test station of the multitude of test stations can be assessed for its suitability for testing the software product to be tested, and makes this data available for transmission to the vehicle development test station system.

Description

[0001] The present invention relates to a method, in particular a computer-implemented method, for operating a communication interface for a vehicle development test bench system, in particular one that is not publicly accessible, for exchanging data relating to a software product to be tested at the vehicle development test bench system within the framework of a predetermined test order with regard to implementing at least one operating function, in particular a vehicle function, for a vehicle to be developed and to be developed by a development partner, in particular an external development partner. The present invention further relates to a communication interface for a vehicle development test bench system and a vehicle development test bench system.

[0002] In current vehicles, the complexity and degree of networking of various hardware (e.g., for data processing), sensor, and actuator components, as well as the number of different (at least automatically executable) vehicle functions, such as driver assistance functions, are increasing significantly. For example, a lane keeping assistance function can be based on a front camera for detecting lane markings, which are then detected by a control unit assigned to the front camera. The detected lane markings are then transmitted to another control unit, which compares the detected lane markings based on a (further) determined vehicle position, calculates a trajectory, and sends any resulting corrections for lane keeping to a control unit assigned to the steering system. Additional functions for automated driving further increase the networking of control units.

[0003] In addition, the degree of networking between vehicles and with the infrastructure (so-called Car-2-Car or Car-2-X communication) as well as with connections to backend systems to increase driving safety is increasing significantly.

[0004] As a result, the number of functions for each control unit installed in the vehicle is also increasing. Due to the growing functionality and simultaneous networking, the interactions between the various functions are also increasing. The resulting large number of software modules is sometimes developed by different companies and must be extensively tested both individually and in conjunction with the control unit software of other control units with which the control unit is networked – after manually flashing the control unit software to be tested.

[0005] The disadvantage of this approach is that software products developed by an external development partner and initially tested separately on their own hardware units exhibit previously unknown behavior in some test cases when tested on the hardware unit provided by the OEM. Furthermore, it would be desirable for the external development partner to be able to test the software product in conjunction with other interacting software and / or hardware units before deploying it.

[0006] From US 10,114,634 B2 a method for carrying out an update of a control unit in series vehicles is known.

[0007] DE 10 2017 100 751 A1 discloses a system configured to detect when a vehicle's ignition is turned off. Furthermore, a processor is provided that is configured to delete an existing software version of a control unit and download a new software version.

[0008] From CN 116 450 151 A, a software delivery method for the Internet of Vehicles is known, in which a security scan of the software code is carried out for quality and / or security.

[0009] DE 10 2020 115 371 A1 relates to a test device that makes it possible to test different variants of one or more vehicle components in an efficient and gentle manner.

[0010] From DE 10 2011 085 433 A1 a method and an arrangement for connecting functions of a control unit are known.

[0011] The present invention is based on the object of overcoming the disadvantages known from the prior art and of providing a method for operating a communication interface for a vehicle development test bench system, in particular one which is not publicly accessible, for exchanging data with regard to a software product to be tested for a vehicle to be developed, a communication interface and a vehicle development test bench system which enable the most user-friendly handling possible of software products developed by development partners - external to the vehicle development test bench system - during the development of networked components with these software products within the framework of the development of the vehicle to be developed.

[0012] In particular, the aim is to enable an even further improved testing procedure for software products developed by development partners external to the vehicle development test bench system, with regard to their subsequent use in hardware inaccessible to the external development partner. The invention is also based on the object of enabling the largely user-friendly integration of a software product developed by an external development partner into a networked network of (hardware and / or software) units, in particular a test bench, within the framework of the development of the vehicle to be developed.

[0013] The object is achieved according to the invention by the subject matter of the independent claims. Advantageous embodiments and further developments of the invention are the subject matter of the dependent claims.

[0014] In a method according to the invention (in particular computer-implemented) for operating (and / or providing) a communication interface for a vehicle development test bench system for data exchange with regard to a software product (in particular within the framework of a predetermined test order) at the vehicle development test bench system with regard to an implementation, preferably with regard to a validation of a functionality, of at least one operating function, in particular a vehicle function, for a vehicle to be developed, to be tested, to be developed by an external development partner and / or to be provided (and / or provided) via the communication interface by the (or an) external development partner, the vehicle development test bench system has a plurality of test stations.

[0015] In other words, the communication interface serves to exchange data between an external development partner and the vehicle development test bench system relating to the software product to be provided or developed by the development partner, for the development of which the external development partner was commissioned in accordance with the specified test order. In particular, such a communication interface is created and / or means for calling such a communication interface by an external development partner are provided.

[0016] The vehicle development test bench facility can preferably be a non-publicly accessible, in particular private, vehicle development test bench facility. Therefore, external development partners are preferably not allowed to access the vehicle development test bench facility (for testing) and / or, for example, flash a control unit within the vehicle development test bench facility with a new version of a software product and / or start a test run of a software product (e.g., a software product developed by them) and / or receive and / or retrieve test results.

[0017] The vehicle development test bench system is preferably a test bench system of an OEM (original equipment manufacturer) for the development of a vehicle. The vehicle development test bench system is preferably controllable from at least parts of the vehicle manufacturer's or OEM's internal network and / or (if necessary, with sufficient internal authorization) addressable for data exchange.

[0018] It would also be conceivable, however, that the vehicle development test facility is operated by a service provider (e.g. the OEM).

[0019] Preferably, the vehicle development test bench system is suitable, intended, configured, and / or configurable for testing components and / or systems for the vehicle under development that include a software component. Preferably, the vehicle development test bench system is not intended or used to test individual parts provided, for example, by a Tier 3 supplier.

[0020] In particular, the vehicle to be developed cannot already be a series-production vehicle, for example, whose software is to be updated. In particular, the development of the vehicle to be developed does not involve a software update of a vehicle already in series production (fully developed).

[0021] Components and / or systems for the vehicle being developed can be components and / or systems of the vehicle (to be developed) itself, i.e. (preferably fixed or non-destructively removable) parts of the vehicle (to be developed). Alternatively or additionally, components and / or systems for the vehicle to be developed can be parts that are not part of the vehicle (to be developed), but that interact and / or communicate with the vehicle (to be developed) (during operation of the fully developed vehicle).

[0022] For example, the component and / or system for the vehicle may be a component and / or system of a backend (of a vehicle manufacturer and / or a service provider) and / or an infrastructure facility and / or a communication facility (such as a Car2Car communication facility) which are intended or are being developed or are suitable and / or intended for communication or data exchange or interaction with the vehicle to be developed.

[0023] The present invention is described below with reference to (precisely) one vehicle to be developed. The present invention is also (analogously) applicable to software products that are developed (in particular simultaneously and / or in different (optional) embodiments) for use in or in multiple vehicles to be developed and are to be tested for this purpose. The vehicle development test bench system can also be suitable and / or intended for testing multiple operating functions or components and / or systems of multiple vehicles to be developed.

[0024] The operating function, in particular the vehicle function, for the vehicle to be developed is preferably a function of a component and / or a system (with software component) for the vehicle to be developed.

[0025] For example, the operating function can be communication with sensor devices of the vehicle to be developed and / or sensor data evaluation in a predetermined manner (e.g. evaluation of available environmental data for the presence of oncoming traffic and / or hazards in the vehicle's environment and / or the existence of critical traffic situations) and / or communication with actuators of the vehicle (e.g. control of a vehicle's steering system to carry out partially automatic and / or fully automatic lateral guidance of the vehicle) and / or control and / or communication with user interfaces of the vehicle to be developed (e.g. control of the output of at least one output device of the vehicle to be developed to a user of the fully developed vehicle, e.g. within the framework of the so-called infotainment system).

[0026] The operating function, in particular the vehicle function, for the vehicle to be developed is preferably an operating function for the vehicle to be developed that can be executed at least partially automatically and preferably fully automatically and / or in real time. It is conceivable that the vehicle function is a driving function (such as lateral and / or longitudinal guidance of the vehicle to be developed). The vehicle function is preferably a driver assistance function of the vehicle to be developed. The operating function is preferably an operating function based on at least one sensor data acquired by a sensor device for the vehicle to be developed (such as a sensor device of the vehicle to be developed, for example for detecting the vehicle's surroundings) and / or an operating function for determining and / or providing at least one control variable for an actuator device of the vehicle to be developed.

[0027] The test stations are each configured and / or configurable for testing at least one operating function of a plurality of operating functions, in particular vehicle functions, for the vehicle to be developed, in particular within a test environment that is specified and / or can be specified (in particular by a user of the vehicle development test station facility). Preferably, the test stations are configured and / or suitable and / or intended for testing a different operating function. It is conceivable that different test stations relate to the testing of different components and / or systems for the vehicle.

[0028] In particular, the vehicle development test bench facility preferably has at least one test station and preferably several (preferably at least two, preferably at least five, preferably at least 10, preferably at least 20, preferably at least 50) test stations for a vehicle to be developed, which test stations do not have a vehicle body. It would also be conceivable for all test stations to have no vehicle body.

[0029] The vehicle development test bench system preferably comprises at least one test bench (particularly preferably several test benches) which (also) comprise a body, which in particular can also be connected (to a central control device). Such test benches can be used, for example, in a very advanced development phase.

[0030] It is also conceivable that (at least) one test station comprises and / or uses a (substantially) fully functional or assembled or substantially fully manufactured vehicle (for testing a / the software product to be tested), and that this vehicle is connected in particular to the (central) control device and / or the at least one measuring device or measuring technology. It is also possible, in particular, to use vehicles as test locations.

[0031] Testing is understood to mean, in particular (particularly alongside or in addition to an "inherent" check of installability and / or flashability and / or integration of the software product) testing of the functionality of the software product with regard to its implementation, application or execution, in particular in a context in which operation of the fully developed vehicle to be developed or of a system or component connected thereto is simulated.

[0032] In other words, “testing” is understood to mean, in particular, a validation of a functionality of the software product to be tested and / or a review of an integration capability and / or an integration (i.e. an interaction with other or the remaining components or with other hardware and / or software units) of the software product to be tested with other components or with other hardware and / or software units.

[0033] Preferably, each test station is a (networked) network of hardware and / or software units that is suitable and / or intended to test at least one software product to be installed and / or flashed and / or integrated on the test station for its functionality within the network. This advantageously achieves the testing of individual components, particularly those from different suppliers and / or manufacturers, in the network that will be present or intended in the fully developed vehicle.

[0034] Preferably, the test bench(es) (in particular all hardware units) used to execute the software product to be tested are automotive grade hardware, preferably qualified according to AEC Q100.

[0035] The software product (to be tested) is preferably embedded software, and especially preferably ECU software. The software product (to be tested) is preferably a software product for automotive-grade hardware.

[0036] It is conceivable that the software product is control unit software for, for example, an infotainment control unit and / or a gateway and / or the like, in particular for control units that are integrated by the OEM (into the vehicle to be developed).

[0037] It is also conceivable that the software product to be tested is a model (virtual or computer-implementable and / or usable by means of high-performance computers, microprocessors and / or purely virtually with computers) for representing a (real) system, such as a model for a control unit.

[0038] Preferably, (each) test station has (at least) one embedded system (for testing a hardware and / or software product to be tested) and / or represents such a system (in a virtualized manner).

[0039] The test benches can include real or physical hardware.

[0040] Preferably, at least one test station, and preferably several test stations, virtually represent at least one component and / or unit of an embedded system and / or a (networked) network within which the software product to be tested is to be tested, or are suitable and / or intended for its virtualization. It is also conceivable for a test station to completely virtually represent an embedded system and / or a (networked) network within which the software product to be tested is to be tested, or are suitable and / or intended for its complete virtualization.

[0041] It is conceivable that the entire vehicle development test bench system consists only of virtual test benches, i.e. test benches which completely virtually map the embedded system and / or the (networked) network within which the software product to be tested is to be tested and / or which is suitable and / or intended and / or configured and / or configurable to test an implementation of the at least one operating function to be tested, or which is suitable and / or intended for its complete virtualization.

[0042] It is preferred that the vehicle development test bench facility has both virtual and (at least partially) real test benches.

[0043] The use of at least a partial virtual representation in or as test bench(es) offers the advantage that, in early development phases, prototypes of the control units for which the software product to be tested was developed are often not available. Preferably (in such cases), the control units can be recreated as (virtual or computer-implemented) models, and the behavior of the software product to be tested can be simulated on these models.

[0044] The vehicle development test bench system preferably has at least one test station and preferably a plurality of test stations, each of which represents and / or comprises a (networked) network with more than 5, preferably more than 10, preferably more than 20, preferably more than 30, preferably more than 50, preferably more than 60, preferably more than 70, preferably more than 80, preferably more than 100 control units. The vehicle development test bench system preferably has at least one test station and preferably a plurality of test stations, each of which represents and / or comprises a (networked) network with fewer than 200, preferably fewer than 150, preferably fewer than 120, preferably fewer than 100, and preferably fewer than 80 control units.

[0045] An electronic control unit (ECU) is particularly suitable and / or intended for implementing a function in an electronic system. It represents, in particular, the control unit of a mechatronic system.

[0046] Preferably, one (in particular each) test station has at least one bus system and preferably a plurality of bus systems for data exchange between control units of the test station, wherein the bus system(s) can be, for example, serial bus systems and / or bus systems such as CAN (abbreviation for "Controller Area Network"), LIN (abbreviation for "Local Interconnect Network"), FlexRay, MOST (acronym for "Media Oriented Systems Transport") or Ethernet. In particular, several and preferably all control units of a test station are integrated, preferably via bus systems, in an electrical-electronic (E / E) architecture (or an area or domain of an E / E architecture). This advantageously allows operating functions such as typical vehicle functions to be tested, which are not executed or calculated on a single control unit, but rather distributed across a control unit network.

[0047] The vehicle development test bench system preferably has at least two, preferably at least 5, preferably at least 10, and particularly preferably at least 30 test benches, which comprise a (networked) network of a different number of control units. In other words, the vehicle development test bench system has test benches of different sizes in order to be able to select a test bench according to the software product to be tested, which can map or simulate the embedded system or the (networked) network in which the software product to be tested is to be embedded in the vehicle being developed or in the later fully developed vehicle.

[0048] The plurality of test stations is in particular a plurality of test stations, in particular (in pairs) independent of one another and / or independently controllable (in particular by the central control device) and / or (in pairs) different from one another, which are in particular configured and / or configurable independently of one another and in different ways with respect to one another.

[0049] The vehicle development test bench system preferably has more than 10, preferably more than 20, preferably more than 30, preferably more than 50, preferably more than 100 test benches. It is conceivable that the entire vehicle development test bench system is located on company premises and / or within a building. The vehicle development test bench system is preferably distributed (territorially). With a purely virtualized test infrastructure, it is also conceivable that the vehicle development test bench system is a distributed system whose functions are performed, for example, on server farms. The data processing processes of the vehicle development test bench system can be carried out in the cloud.

[0050] A specified test order can be understood (e.g., by the manufacturer of the vehicle to be developed and / or the OEM and / or the operator of the vehicle development test bench facility) as a specification or description of a functional behavior or functionality of a software product to be developed. The specified test order can specify (required) interfaces, for example, between software and hardware. Furthermore, the test order can specify information about the network and / or the embedded system, in particular information about the hardware (such as the required hardware revision (and / or hardware version) within which the software product to be tested is to be tested or later used.

[0051] Preferably, the specified test order specifies at least one (intended) test procedure or is characteristic of the test procedure with which the software product to be tested is or is to be tested at a test station of the vehicle development test station facility.

[0052] For example, observation points can be defined or specified through which conclusions can be drawn about the behavior of the software product to be tested and / or states within an embedded system in which the software product to be tested is embedded, and / or states of a test bench on which the software product to be tested is tested. The test method preferably comprises test methods such as monitoring, manipulating and / or stimulating signals (sent and / or transmitted within the network), for example of a bus system (or multiple bus systems), taking taps at connection points between two hardware units, such as tapping one pin and / or multiple pins of connectors. For example, the test method can test bus communication on CAN, Ethernet and the like.

[0053] Preferably, one (in particular each) test station has at least one measuring device (and preferably a plurality of measuring devices), which is (in each case) suitable and / or intended to collect (test) data (preferably in accordance with the respective predetermined test order) during the execution of the software product to be tested on the test station selected for this purpose - in particular within the framework of a test procedure. The test data is preferably characteristic of the behavior of the software product to be tested (in particular within the test procedure). The test data can be compared with predetermined ranges and / or values. Preferably, a conclusion is drawn about the validity of the software product to be tested on the basis of the test data. Preferably, the test procedure is selected such that, based on the test data collected according to the test procedure, a validity of the software product to be tested orin particular the implementation of the operational function can be assessed.

[0054] The at least one measuring device can be, for example, a data logger, frame grabber, bus interface, GPS simulator, camera, or the like. Preferably, the at least one measuring device, and particularly preferably the plurality of measuring devices, is selected from a group comprising data loggers, frame grabbers, bus interfaces, GPS simulator, cameras, sensor devices, and the like, as well as combinations thereof.

[0055] It is conceivable that the specified test order includes target test results of a test procedure and / or expected test results or data characteristic of these.

[0056] It is also conceivable that the specified test order specifies at least one test case, and preferably several test cases, by means of which the software product to be tested is to be tested or is tested at a test station of the vehicle development test station facility. For example, the test case can specify or state which environmental data and / or sensor data and / or input data and / or route data and / or meteorological or weather-related data and / or vehicle movement data are used during the execution of the software product as part of the test procedure. The specific data sets can be specified. However, it is also conceivable that only a category and / or type of the respective data is specified, for example cross-country driving versus inner-city driving and / or winter driving versus summer driving and / or road type and / or movement profile and / or right-hand versus left-hand traffic and / or traffic data.

[0057] A test environment is preferably understood to mean information on the (hardware and / or software) versions and / or classifications and / or types, operating systems, interfaces, platforms, configurations, equipment, data communication protocols of the test bench or the embedded system in which the software product is to be embedded (for testing and / or for its subsequent use), as well as software and hardware components for operating the test infrastructure or the test bench (e.g. real-time computer) including configuration, test automation environment and measurement technology including configuration.

[0058] Preferably, the communication interface transmits characteristic data to the external development partner for the specified test order, which may include the information specified above individually or in combination with one another.

[0059] Preferably, the vehicle development test station system has (preferably exactly) one (preferably central), in particular processor-based, control device, which is particularly preferably part of the internal or private (corporate) network of the vehicle manufacturer or OEM and / or the vehicle development test station system.

[0060] Preferably, a communication connection for data exchange can be established between the (central) control device and each test station of the vehicle development test station system (particularly within the non-public and / or private or internal network). Preferably, each test station of the vehicle development test station system can be controlled and / or configured by the (central) control device (e.g., for installing and / or flashing a software product to be tested and / or for starting and / or executing a test procedure).

[0061] Preferably, the (central) control device is suitable and / or intended to control and / or configure the (in particular the entire) vehicle development test bench system and / or to carry out and / or monitor tests of software products to be tested on the vehicle development test bench system and / or to store and / or evaluate test results obtained therefrom on a storage device, for example by comparing them with expected and / or intended target test results.

[0062] An external development partner is understood to mean, in particular, an external development partner with regard to the vehicle development test bench facility. The external development partner is preferably a Tier 1 supplier.

[0063] However, it is also conceivable that a data exchange between an internal development partner in relation to the vehicle development test station system, for example a user of the vehicle development test station system, takes place in an analogous manner, so that a uniform communication procedure is advantageously used with all development partners.

[0064] It is conceivable that the communication interface represents an interface (in particular computer-implemented and / or provided by at least one server) for data exchange between a first domain (in particular a domain of the external development partner or a domain within which the software product to be tested is developed and / or provided and / or can be provided) and a second domain (in particular a domain of the OEM or the vehicle manufacturer).

[0065] According to the invention, the communication interface records (and / or receives) (in particular on the basis of the specified test order) the software product to be tested (provided by the external development partner, in particular by uploading and / or retrieving) as well as metadata associated with the software product to be tested.

[0066] It is conceivable that the communication interface provides input and / or transmission tools for transmitting the software product to be tested and / or the associated metadata. For example, it is conceivable that the communication interface provides website- and / or browser-based input and / or transmission options, such as input fields or a (form-like) input mask, particularly for the software product to be tested and for the metadata (in particular, different input fields or separate input options for different types of metadata), so that the external development partner can quickly capture the required data to be transmitted and conveniently provide it.

[0067] It is also conceivable that the communication interface is suitable, intended, and / or configured to be embedded in a development network of the external development partner. Preferably, the communication interface can be integrated into an automation system of the external development partner (e.g., Tier 1). In particular, the communication interface can be integrated into automated testing and / or release and / or development and / or transmission process steps of the external development partner (e.g., Tier 1). For example, the communication interface can be automatically embedded as part of the Tier 1 development.

[0068] Preferably, there is an automatic exchange of data regarding the specified test order between the development network of the external development partner and / or a test hardware or test infrastructure of the external development partner and the vehicle development test bench system (of the OEM). Preferably, test results of a test or test procedure carried out on the vehicle development test bench system (of the OEM) of the software product to be tested (captured by the communication interface) are automatically transmitted (via the communication interface) to the external development partner. Preferably, test results of a test or test procedure carried out by the external development partner are automatically transmittedTest procedure of the software product to be tested (to be made available to the communication interface for testing, but in particular not yet made available), preferably automatically transmitted via the communication interface to the vehicle development test bench system (of the OEM) and / or to the (central) control device for the vehicle development test bench system (of the OEM).

[0069] "Assigned" metadata is understood in particular to mean that the metadata is provided in such a way that it can be assigned (preferably unambiguously and particularly preferably unequivocally) to the software product to be tested by the communication interface and / or the vehicle development test bench system. Such assignment or assignability can be achieved, for example, by the metadata (and the software product to be tested), in particular unambiguously, being assigned and / or being assignable to the specified test order.

[0070] It is also conceivable that only software products and / or metadata to be tested for specified test orders can be transmitted to the communication interface. For example, the communication interface may only provide and / or offer input and / or transmission tools (or transmission options) once a specified test order or a characteristic value has been selected and / or specified.

[0071] Preferably, the communication interface (the external development partner) requests, particularly for a given test order, the provision of metadata (associated with the software product) for the transmission of the software product to be tested. Preferably, the communication interface checks (e.g., during a transmission and / or provision (or transmission and / or provision attempt) of the software product to be developed and / or developed and / or tested, particularly initiated by the external development partner, whether metadata (associated with the software product) has been / has been / will be provided.If this is not the case, the communication interface notifies and / or warns the external development partner and / or the vehicle development test facility and / or refuses to provide and / or transmit the software product under test (and issues an error message regarding the failed provision and / or transmission attempt).

[0072] Preferably, the communication interface (in particular on the basis of the specified test order) provides the (recorded) software product to be tested as well as the (recorded) metadata associated with the software product to be tested to the vehicle development test bench system (by transmission and / or for retrieval, for example from a storage device).

[0073] The communication interface preferably stores the software product to be tested (provided by the external development partner, in particular by uploading and / or retrieving) as well as metadata of the vehicle development test bench system associated with the software product to be tested on a storage device (in particular internal and / or cloud-based with respect to the vehicle development test bench system) (which, in particular, the vehicle development test bench system can access), preferably in such a way that the metadata is / are associated with the software product to be tested and / or the specified test order. Data characteristic of the specified test order is preferably (likewise) stored on the storage device.

[0074] Preferably, on the basis of the metadata (recorded and / or associated with the software product to be tested), in particular by the vehicle development test bench system and / or by the (central) control device, one, preferably each, test bench of the plurality of test benches can be assessed for its suitability, in particular with regard to its configuration and / or configurability, for testing the software product to be tested.

[0075] In other words, based on the metadata (preferably based solely on the metadata and / or based on the metadata and the specified test order and / or the software product to be tested), it is possible to determine whether a (preferably every) specified test station of the vehicle development test station facility is suitable for testing the software product to be tested. This offers the advantage that the data, and preferably all of them, required for testing the software product to be tested can be transmitted (or made available for transmission) at least partially automatically (e.g., after approval by an operator of the vehicle development test station facility) or fully automatically to a test station identified or assessed as suitable (in particular, installation and / or flash instructions for installing and / or flashing the software product to be tested on the test station).

[0076] Preferably, exactly one test station is determined from the plurality of test stations based on the metadata (e.g., by the control device). Preferably, the software product to be tested is tested at the determined test station.

[0077] It is also conceivable that, based on the metadata, several test stations (e.g., a predefined and / or a predeterminable number of test stations) are determined from the multitude of test stations (e.g., by the control device), in particular to test the software product to be tested using the determined test stations. This is particularly advantageous for parallelization or broader coverage of real vehicle variants.

[0078] Preferably, the communication interface informs the external development partner whether or not the metadata is sufficient to automatically select and / or determine a test station at which the software product to be tested is to be tested.

[0079] Preferably, the metadata are characteristic of an at least partial description of the software product, so that in particular the vehicle development test bench system can assess, on the basis of the metadata or data derived therefrom, for one, in particular each, test bench of the plurality of test benches, whether the test bench is suitable, in particular configured and / or configurable, as a target test bench for testing the software product to be tested.

[0080] In a preferred method, the communication interface of the vehicle development test bench system provides the metadata in a machine-readable data format for at least partially automated testing of the software product to be tested on the vehicle development test bench system, in particular for the automatic determination and / or (automatic) assignment and / or (automatic) configuration (at least and preferably precisely) of a (target) test bench for testing the software product to be tested. This offers the advantage that a test bench can be determined automatically based on the metadata.

[0081] Preferably, the communication interface records the metadata in a machine-readable data format for at least partially automated testing of the software product to be tested on the vehicle development test bench system.

[0082] The metadata preferably includes a version size characteristic of the versioning of the software product to be tested. The version size is preferably unique to the software product to be tested provided to the communication interface. The version size is preferably uniquely assignable to the software product to be tested provided to the communication interface (by the communication interface and / or the vehicle development test bench system). Based on the versioning, it is advantageous to determine the compatibility of one software delivery to the next or the extent of changes to this software delivery compared to the previous one.

[0083] A software version of the software product to be tested provided to the communication interface preferably corresponds to the software version read from the control unit via diagnosis.

[0084] Preferably, the data collected and / or provided by the external development partner is labeled according to specifications. The communication interface preferably specifies a uniform label for files to be transmitted and / or provided and / or made available by the communication interface (e.g., "release label"). The communication interface preferably assigns a unique release label, whereby the label is directly assigned to the software release. The communication interface preferably transmits the version size or version information of the software product to be tested in an unchanged form as part of the release label.

[0085] Preferably, the metadata (captured by the communication interface and / or provided and / or transmitted, in particular, by the external development partner of the communication interface) includes at least one (machine-readable) maturity level parameter characteristic of a maturity level of the software product to be tested. Preferably, by assigning a maturity level parameter, a classification of the software product to be tested is carried out, whereby it can advantageously be decided and / or assessed (in particular automatically or at least semi-automatically) (preferably by the (central) control device and / or by the vehicle development test bench system) in which context the software product to be tested is used and / or can be used.

[0086] Preferably, at least three, preferably four, preferably five and / or fewer than five, preferably fewer than four different maturity levels or maturity level variables are provided and / or specified, from which exactly one maturity level or exactly one maturity level variable can be selected for each software product to be tested (in particular by the external development partner) and transmitted (in particular as part of the metadata) to the communication interface.

[0087] For example, the communication interface and / or the control device and / or the vehicle development test bench system assigns a usability and / or at least a release (e.g., for use) to the (preferably each) particularly recorded software product to be tested. Depending on the maturity level, a (recorded) software product to be tested is preferably assigned a limited usability (e.g., for systems under test) and / or a more restrictive use and / or a (comparatively) increased monitoring (preferably by the communication interface and / or the control device and / or the vehicle development test bench system).

[0088] Preferably, the metadata includes a version size and a maturity level size.

[0089] In a further preferred method, the communication interface of the vehicle development test bench system provides the metadata in a data format independent of a programming language. This preferably results in an even broader application of the metadata. The metadata is advantageously not already available in one (of many) selected programming languages, but can be transformed into a programming language suitable for the target hardware or the target test bench, for example, using so-called parsers (in particular automatically, preferably by the (central) control device and / or the vehicle development test bench system and / or the target test bench).

[0090] The metadata preferably includes information on all partitions of a control unit. Preferably, all software artifacts of a software delivery or software product associated with a partition of a control unit are summarized and / or recorded in a manner attributable to the partition, for example, through characteristic information in the metadata. It is also conceivable for the communication interface to record and / or receive a (machine-readable and / or human-readable) delivery information file (provided, in particular, by the external development partner) containing a list of metadata and file references of the software product. It is conceivable for the delivery information file to be in JavaScript Object Notation (JSON) file format, YAML format, and / or XML format (XML stands for Extensible Markup Language).It is conceivable that one delivery information file per partition (provided by the external development partner) is received and / or recorded by the communication interface if the software delivery contains software artifacts for more than one ECU partition, which are addressed via different diagnostic addresses.

[0091] Preferably, the metadata (which is preferably in machine-readable data format) comprises a diagnostic address of the control unit and / or the control unit partition assigned to the software product to be tested, a version size characteristic of version information of the software product, a maturity level size characteristic of a maturity level of the software product to be tested, at least one and preferably for several / all hardware versions supported (by the software product to be tested) or hardware version size(s) characteristic thereof, a size characteristic of a version of the networking description, a changelog size from which a changelog description of the software product to be tested can be determined (for example, a reference to a changelog description), a flash instruction size from which a flash instruction of the software product to be tested can be determined (for example, a reference to the flash instruction and / or the flash instruction),and / or instructions for flashing and / or information from which these can be determined, such as a reference to included flash containers (and / or human-readable and / or machine-readable additional information).

[0092] It is conceivable that the included flash containers also contain a check value for digital data, such as the respective file hash values, determined using a (cryptological) hash function, such as the SH_256 (Secure Hash Algorithm). This check value is advantageously used to ensure the integrity of a message. If two messages produce the same check value, the identity of the messages should be guaranteed by common sense, regardless of deliberate attempts to manipulate the messages.

[0093] The (machine-readable) metadata preferably includes at least one changelog variable from which a changelog description of the software product to be tested can be determined. The (machine-readable) metadata preferably includes information / data characteristic of the changelog description, i.e., in particular, information about adaptations and functional implementations made by the software delivery. It is conceivable that adaptations and functional implementations (by the software product to be tested) are provided with references to implemented requirements.

[0094] Preferably, the (machine-readable) metadata, in particular the information / data characteristic of the changelog description, contains (all) information on (known) limitations relevant to the use of the software. Such limitations may be caused, for example, by behavior deviating from the specified test order, known diagnostic trouble codes (DTCs), restricted diagnostic protocols (CAN, CAN-FD, or DoIP only), or access options.

[0095] The (machine-readable) metadata preferably comprises at least one (machine-readable) flash instruction variable from which a flash instruction of the software product to be tested can be determined and / or data / information characteristic of the (machine-readable) flash instruction. The (stored) machine-readable flash instruction serves for the reproducible transfer of the flash containers to the target hardware. The data / information preferably provides the requirements for the test bench orthe test bench (and / or vehicle network) that must be created before the flash procedure, and / or the description of the hardware versions for which the flash procedure is suitable, and / or the description of the software versions of this partition to which this flash procedure can be applied, and / or the software version of the partition after applying the (flash) procedure, and / or instructions for flashing the partition that can be executed with the respective released versions of the diagnostic tools released within the group, and / or action instruction(s), parameters of the instruction, and in particular a goal of the instruction. Preferably, the metadata can include information on the tools with which the flash procedure was tested by the external development partner.

[0096] Preferably, the (machine-readable) metadata includes a separate description for different variants of a software release. Variants can represent a compilation of an implementation of the software product for different architectures.

[0097] The (machine-readable) metadata preferably comprises information and / or data that are characteristic of an automatable flashing process and / or installation process (of the software product to be tested on the target test bench, in particular a target hardware of the target test bench), or from which an automatable flashing process can be determined (in particular by the vehicle development test bench system and / or a test bench on which the software product to be tested is to be tested). For example, hardware and / or software tools necessary for the automated filling of the flash containers can be specified.

[0098] The machine-readable metadata can be present and / or recorded in a JavaScript Object Notation (JSON) file format and / or in a YAML format and / or in an XML format and / or provided to the test bench system. These file formats offer the advantage of describing the data exchange between applications in an easily readable text format and are independent of programming languages. Preferably, the vehicle development test bench system and / or the target test bench (i.e., the test bench intended for testing the software product to be tested) have appropriate parsers. Preferably, the metadata relating to the machine-readable changelog information and / or the (machine-readable) flash instructions / installation instructions are recorded in a JSON file format (provided by the external communication partner) and / or provided to the vehicle development test bench system (for transmission and / or retrieval).

[0099] Preferably, the communication interface checks whether the metadata, in particular the metadata relating to the machine-readable changelog information and / or the (machine-readable) flash instructions / installation instructions, which are provided by the external development partner of the communication interface, are available in a machine-readable file format, in particular in a programming language-independent file format, particularly preferably in a JSON file format and / or a YAML file format and / or XML file format.

[0100] In a further preferred method, the metadata comprises machine-readable configuration instructions for automatically configuring the target test bench for testing the software to be tested at the target test bench of the vehicle development test bench facility.

[0101] Preferably, the metadata is characteristic of at least one configuration setting of the determined test station required to carry out the test procedure according to the test order. Preferably, the vehicle development test station system, in particular the (central) control device, makes a configuration setting of the target test station (i.e., the test station at which the software product to be tested is to be tested) according to the required configuration setting.

[0102] The data / information described above, which preferably includes the metadata, offers the advantage that handling and installation (deployment) of software artifacts is possible completely automatically.

[0103] Software artifacts should be developed with backward compatibility in mind. However, for specific reasons, in some cases, software artifacts are modified in a way that is not backward compatible. Information about compatibility with hardware versions, dependencies on other software artifacts, and preconditions that must be met for installing the software artifact can thus be advantageously summarized and provided in the metadata (and are preferably summarized and provided). This facilitates automated processing and handling of the software products and advantageously enables continuous integration, continuous installation (continuous deployment), and / or continuous testing (continuous integration, deployment, and testing) of these software products.

[0104] The recorded metadata assigned to the individual and preferably all software products to be tested (and preferably all individual hardware components to be tested, particularly in a network) can advantageously enable continuous integration of the individual software and / or hardware products to be tested.

[0105] Preferably, the at least one configuration setting is selected from a group of configuration settings which includes configuration settings of the (networked) network of hardware and / or software units of a test station, configuration settings of at least one and preferably several measuring devices, configuration settings for carrying out a test procedure, in particular according to the test order, for example loading sensor data which is used in the test procedure as sensor data for participating sensor devices of the network or interfaces therefor, for example loading configuration settings, e.g. loading of environment, route and driver models, configurations of frame grabbers and image recognition software and configuration of the test automation software and the like as well as combinations thereof.

[0106] Preferably, the vehicle development test bench system, in particular the (central) control device and / or the (central) control device and / or the target test bench, retrieves current configuration settings of the target test bench and compares them with the required configuration settings specified in the metadata. If a deviation is detected, a configuration order or (machine-readable) configuration instructions are preferably created (in particular automatically), and the target test bench is particularly preferably configured according to this configuration order or (machine-readable) configuration instructions.

[0107] Preferably, the vehicle development test bench system and / or the (central) control device (in particular when determining the target test bench) and / or the target test bench, depending on the metadata (in particular the version sizes and / or hardware version sizes), checks whether the software product to be tested is compatible with the target test bench or with a specified test bench.

[0108] Preferably, the vehicle development test bench system and / or the (central) control device and / or the target test bench initiates an installation and / or flashing of the software product to be tested on the target test bench according to the metadata. Preferably, the vehicle development test bench system and / or the (central) control device and / or the target test bench (automatically) performs an installation and / or flashing of the software product based on the metadata or data derived therefrom.

[0109] Preferably, the vehicle development test station system, in particular the (central) control device, and / or the (central) control device and / or the target test station, and / or the communication interface (automatically) determines, on the basis of the (recorded) metadata and / or the specified test order, at least one test method (to be carried out) by means of which the software product to be tested is to be tested (at the target test station or selected test station).

[0110] It is conceivable that the metadata and / or the specified test order are characteristic of the test procedure. It is conceivable that data characteristic of the test procedure can be retrieved from a storage device in the vehicle development test bench system.

[0111] In a further preferred method, the communication interface is operated as a central, in particular sole, communication interface for all software products to be tested, which are to be provided / transmitted, in particular, by external development partners to the vehicle development test bench system. This advantageously provides a uniform portal for recording all software products to be tested and associated data, which are particularly suitable and / or intended for the automated execution of a test procedure for the software product to be tested (comprising configuration instructions and / or installation / flash instructions and / or instructions for executing the test procedure).

[0112] In a further preferred method, the metadata comprises at least one installation requirement variable which is characteristic of an installation requirement of the software product to be tested to the target test bench, in particular to a target hardware of the target test bench, and / or at least one compatibility variable which is characteristic of a compatibility of a target hardware, in particular of a predetermined version of a target hardware of the target test bench, and / or of a compatibility of a software installed on the target hardware before installation of the software product to be tested, in particular of a predetermined software version.

[0113] Preferably, the communication interface is suitable and / or intended for data exchange with respect to software products to be tested (according to specified test orders) from various external development partners. Preferably, all software products to be tested are recorded via the communication interface.

[0114] Preferably, the communication interface can retrieve data on specified test orders (in particular from a database of the vehicle development test bench system) and / or provide it to the external development partner. Preferably, the communication interface can retrieve time specifications for the provision of the software product to be tested and, depending on the time specification, notify the development partner and / or a user of the vehicle development test bench system.

[0115] Preferably, a sequence of software products to be tested (in particular individually for each test station) can be created (in particular automatically) on the basis of the software products to be tested and / or metadata recorded by the communication interface (in particular by the communication interface and / or the vehicle development test station system and / or the (central) control device).

[0116] Preferably, the metadata and / or the specified test order (optional) include information on prioritizing the testing process for the software product to be tested. The order is preferably determined based on the prioritization.

[0117] In a further preferred method, the communication interface provides the external development partner, depending on the specified test order, with at least one test case size that is characteristic of at least one specified test case to be tested, against which the software product to be tested is to be tested, and preferably with a specified plurality of test case sizes (for transmission to and / or retrieval by the, in particular, external, development partner). This offers the advantage that the external development partner can test the test case in advance, before the provision and / or completion of the development of the software product to be tested (to be provided to the communication interface).

[0118] In a further preferred method, the communication interface provides the external development partner with at least one further test environment variable (for transmission to and / or retrieval by the, in particular, external, development partner), which specifies (in particular for a test case to be tested) which test environment (in which version) and / or which type of test environment (if there are several "identical" test benches, this does not have to be named precisely; it is sufficient to state that, for example, a system test bench is required) is to be used. This offers the advantage that the external development partner can already take the test environment to be used later into account during the development of the software product to be tested.

[0119] In a further preferred method, the communication interface provides at least one test environment variable (for transmission to and / or retrieval by the external development partner) characteristic of a development partner test environment in which the software product to be tested is to be tested, in particular by the development partner, preferably before provision / transmission of the software product to be tested to the communication interface. This offers the advantage that it is traceable which test environment the external development partner used to test the software product (prior to transmission). Thus, potential (error) causes can be found (in particular automatically) when anomalies are detected during flashing / installation and / or when performing the test procedure (e.g., from the test results) of the software product to be tested.

[0120] Preferably, the external development partner of the communication interface provides the at least one test environment variable characteristic of a development partner test environment and / or transmits it to the communication interface.

[0121] In a further preferred method, at least one test environment variable is selected from a group of test environment variables which comprise test environment variables which are characteristic of a description of the test environment and / or a version of the test environment and / or a combination of several components and preferably their respective version.

[0122] In a further preferred method, the at least one test environment variable is characteristic of a simulation environment and / or an at least partial and preferably complete virtualization of the target test station to be selected, in particular a bus simulation and / or virtualized control units.

[0123] In a further preferred method, the communication interface retrieves at least one test result from a test of the software product to be tested, carried out by the development partner, in particular an external one, and / or requests the transmission of a test result repeatedly, in particular cyclically. This allows for automated monitoring of the progress of the development process and the adaptation of further development projects (e.g., the associated hardware).

[0124] Preferably, by detecting the software product to be tested through the communication interface (automatically or at least semi-automatically, for example after release), an installation / flashing of the software product to be tested on the target test bench or the target hardware or the target control unit and / or a performance of a test procedure of the software product on the test bench is initiated and / or effected.

[0125] In a further preferred method, when a test is carried out (and / or after a test has been carried out) - for example, when the test procedure is carried out - of the software product to be tested (recorded and / or provided to the communication interface), test results determined in the vehicle development test bench system are made available to the external development partner via the communication interface (for transmission to and / or retrieval by the external development partner) and / or the external development partner is notified of their provision.

[0126] Preferably, the test results are compared with specified and / or specifiable values ​​and / or ranges and / or limit values ​​(according to the specified test order and / or from the vehicle development test bench system). Preferably, depending on the comparison (particularly automated), the functionality of the software product to be tested is assessed or a determination regarding the validity of the software product to be tested is made. Preferably, the result of the comparison and / or the assessment of the functionality of the software product to be tested or a determination regarding the validity of the software product to be tested is transmitted from the communication interface to the external development partner and / or made available for retrieval.

[0127] The interface advantageously enables the exchange of test specifications, test results and test reports.

[0128] Test specifications and test jobs are often described in different ways and with varying levels of detail. Test specification formats and test tooling are often closely linked, requiring Tier 1 companies and OEMs to agree on specific solutions or connections to enable automated exchange and processing.

[0129] The proposed metadata advantageously offers a solution for enabling data exchange regarding test specifications, test results, and reports, allowing the use of different tooling without losing compatibility. In particular, the proposed metadata enables a structured exchange, as opposed to an exchange at a "report level," such as compiled human-readable test reports.

[0130] Therefore, not only the installation status and / or installability (flashability) of the software product to be tested is monitored in the test bench, but an execution of the (successfully installed / flashed) software product to be tested is tested and for this purpose preferably tested by at least one measuring device and measurement data is collected (and preferably transmitted to the external development partner).

[0131] In a further preferred method, a test environment provided to the communication interface by the external development partner, in particular during the development and / or testing of the software product to be tested, is provided by the communication interface (for transmission to and / or retrieval by at least one test station of the vehicle development test station system, in particular the test station determined and / or selected for testing the software product to be tested) of the vehicle development test station system.

[0132] Conversely, the communication interface can also provide and / or transmit to the external development partner (particularly depending on the specified test order) at least one test parameter characteristic of a test environment in which the software product (to be developed and tested) is tested in the vehicle development test bench system. This offers the advantage that the external development partner can use the same or similar test environments during development, so that as few differences in the hardware and / or software as possible need to be considered during development compared to later use, and so that behavioral changes and / or malfunctions caused by these changes occur.

[0133] In a further preferred method, the communication interface stores the acquired software product to be tested and / or the acquired metadata in a tamper-proof manner on a storage device. This offers the advantage that the data, in particular changes to the software product to be tested, can also be traced at a later point in time. Preferably, a status variable characteristic of the status of the software product is also stored and is retrievable (at least internally). Preferably, the software product to be tested is stored in a way that is automatically retrievable.

[0134] In a preferred method, the (central) control device is a cloud-based control device, in particular a cloud-based and / or a server. The server is, for example, a backend of a vehicle manufacturer or a service provider. The server's functions can be performed on (external) server farms. The (external) server can be a distributed system. The (central) control device can have all of the features described below in the context of the control device, individually or in combination with one another.

[0135] The vehicle function is preferably a function of a vehicle component of the (ego) vehicle. The vehicle component is preferably selected from a group comprising a vehicle safety system (e.g., a braking system), a system for guiding the (ego) vehicle, a particularly automatic vehicle lateral control system, a lane-keeping system, a lane-change assistance system, a navigation system, a locking system for a vehicle door and / or a vehicle window, a windshield wiper mechanism, a vehicle locking system, a roof opening mechanism, a sunroof mechanism, an infotainment system, an entertainment system, and / or a comfort system for increasing the driving comfort of an occupant, and combinations thereof.

[0136] The communication interface is preferably used for the development of a vehicle to be developed.

[0137] The communication interface is preferably used to define the test cases and / or delivery of test results that the external development partners must perform and deliver.

[0138] The communication interface is preferably used to deliver software artifacts. The communication interface is preferably used to exchange software artifacts and test results.

[0139] The communication interface is preferably used for the development and integration of software products to be tested, especially well before production mechanisms are available. During this phase, OEMs must be able to verify, flash (taking all metadata and dependencies into account), and test the software artifacts provided by external development partners, preferably via the communication interface, on a test infrastructure and vehicles in a development and integration context.

[0140] The present invention is further directed to a communication interface for a vehicle development test bench system, in particular one that is not publicly accessible, for data exchange with regard to a software product, preferably embedded software and particularly preferably control unit software, to be tested within the scope of a predetermined test order on the vehicle development test bench system with regard to an implementation of at least one operating function, in particular vehicle function, for a vehicle to be developed, to be developed by an external development partner and / or to be provided to the communication interface by the external development partner.

[0141] The vehicle development test station system comprises a plurality of test stations, each of which is configured and / or configurable for testing at least one operating function of a plurality of operating functions, in particular vehicle functions, for the vehicle to be developed.

[0142] According to the invention, the communication interface is suitable, determined and / or configured to record, on the basis of the specified test order, the software product to be tested as well as metadata assigned to the software product to be tested, on the basis of which metadata one, preferably each, test station of the plurality of test stations can be assessed in particular by the vehicle development test station system with regard to its suitability, in particular with regard to its configuration and / or configurability, for testing the software product to be tested, and to make said metadata available for transmission to the vehicle development test station system.

[0143] It is therefore also proposed within the framework of the communication interface according to the invention that the communication interface captures metadata by means of which (at least partially and preferably completely) automated testing of the software product to be tested can be carried out in the vehicle development test bench system.

[0144] The communication interface is, in particular, a communication interface for use in a (wireless and / or wired) communication system that connects a server and / or computer (or a data processing device), in particular a first domain, to at least one other device (in particular a data processing device or computer and / or server), in particular a second domain, for at least temporary data exchange and / or real-time data exchange.

[0145] Preferably, the communication interface is configured, suitable, and / or intended to execute the method described above as well as all method steps already described above in connection with the method, individually or in combination with one another. Conversely, the method can be equipped with all features described in the context of the communication interface, individually or in combination with one another.

[0146] The present invention is further directed to a use of a communication interface described above (in particular according to one or more of the preferred embodiments described above) for a vehicle development test bench system (in particular described above, in particular not publicly accessible) and particularly preferably as a component of the vehicle development test bench system, for the (preferably bidirectional) exchange of data with regard to a software product to be tested (preferably to be developed by an external development partner and / or to be provided to the communication interface by the external development partner) within the framework of a predetermined test order on the vehicle development test bench system (with regard to an implementation of at least one operating function, in particular vehicle function, for a vehicle to be developed).Preferably, the communication interface is used for data exchange with respect to embedded software to be tested on the vehicle development test bench system and / or to be developed for testing on the vehicle development test bench system, and particularly preferably control unit software.

[0147] The present invention is further directed to a vehicle development test station system comprising at least one communication interface described above (for a vehicle development test station system, in particular one not accessible to the public (described above)) as well as a vehicle development test station system (described above) or the vehicle development test station system according to an embodiment and preferably a communication device of the external development partner, with which a - preferably bidirectional and / or automatic and / or automatable - data exchange to the communication interface can be established.

[0148] A vehicle can be a motor vehicle, in particular a motor vehicle controlled by the driver himself (“driver only”), a semi-autonomous, autonomous (for example, autonomy level 3, 4 or 5 (of the SAE J3016 standard)) or self-driving motor vehicle. Autonomy level 5 refers to fully automated vehicles. The vehicle can also be a driverless transport system. The vehicle can be controlled by a driver or drive autonomously. In addition to a road vehicle, the vehicle can also be an air taxi, an aircraft and another means of transport or another type of vehicle, for example an aircraft, watercraft or rail vehicle.

[0149] The present invention is further directed to a method, in particular a computer-implemented method, for at least partially automatically, preferably fully automatically, controlling a vehicle development test bench system for testing, within the framework of a predetermined test order, a software product to be tested, in particular developed and / or provided by an external development partner, on the vehicle development test bench system with regard to implementing at least one operating function, in particular a vehicle function, for a vehicle to be developed. The software product is preferably embedded software and particularly preferably control unit software.

[0150] The vehicle development test bench system comprises a plurality of test benches, each of which is configured and / or configurable for testing at least one of a plurality of operating functions, in particular vehicle functions, for the vehicle to be developed. The vehicle development test bench system (or the plurality of test benches) can be designed as described above (in particular according to at least one preferred embodiment).

[0151] According to the invention (in particular within the scope of a computer-implemented method step), on the basis of received and / or recorded and / or determined metadata assigned to the software product to be tested (preferably by the vehicle development test bench system and / or a central control device for the vehicle development test bench system), at least one, preferably each, test bench of the plurality of test benches is assessed with regard to its suitability, in particular its configuration and / or configurability, for testing the software product to be tested and / or at least one and preferably exactly one test bench of the plurality of test benches is selected and / or on the basis of (orUsing the received and / or recorded and / or determined metadata associated with the software product to be tested, and preferably by (machine) data processing, at least one test bench size characteristic of at least one and preferably exactly one test bench (particularly suitable and / or selected for testing the software product to be tested) is determined. The (at least one) selected test bench is, in particular, the test bench referred to above as the target test bench.

[0152] The selection of the at least one, and preferably exactly one, test station from the plurality of test stations is preferably made depending on the suitability, preferably a configuration and / or configurability, of the at least one test station for testing the software product to be tested. The selection of the at least one, and preferably exactly one, test station from the plurality of test stations is preferably made depending on the result of the assessment of the at least one, and preferably each, test station from the plurality of test stations regarding its suitability, in particular its configuration and / or configurability, for testing the software product to be tested.

[0153] In a preferred method, at least one test bench size characteristic of at least one test bench suitable and / or selected for testing the software product to be tested is determined. In other words, based on metadata that is and / or can be assigned to the software product to be tested, at least one test bench size is determined that indicates on which test bench (of the plurality of test benches) the software product to be tested is to be tested or is to be tested.

[0154] The determination of at least one characteristic test station size can be carried out by the vehicle development test station system and / or the (central) control device for the vehicle development test station system.

[0155] It is also conceivable that the specified test order (or data derived from and / or linked to it) is used to determine the at least one test bench size and / or to evaluate at least one test bench and / or to select at least one test bench (in addition to the metadata). This offers the advantage that restrictions for and / or requirements for the test bench (to be used to test the software product being developed or tested) (e.g., with regard to the configuration and / or configurability of the test bench), which already arise from the specified test order, do not need to be repeated in the metadata or included in it.

[0156] It is conceivable that information or data that characterizes and / or indicates a suitability and / or a required configuration and / or a restriction and / or requirement for the test bench to be used for testing are included either in the specified test order or in the metadata. This offers the advantage that the metadata has the smallest possible data volume.

[0157] It is preferred that the metadata include all information or data which are characteristic of a suitability and / or a required configuration and / or a configurability of a test bench to be used for testing and / or a restriction for and / or requirement for the test bench to be used for testing and / or which indicate such.

[0158] Preferably, the assessment of the at least one test station and / or the selection of the at least one test station and / or the determination of the at least one test station size (in particular exclusively) can be carried out on the basis of the metadata without using the specified test station. This metadata is preferably provided (in particular together with the software product) by the (external) development partner and / or transmitted to the (central) control device (for example, via the communication interface described above). This offers the advantage that a (data) package comprising the software product to be tested and metadata is available (to the control device and / or the vehicle development test station system), which can be tested on its own (in particular automatically) on the vehicle development test station system without requiring any further data. This advantageously prevents data required for testing from being unavailable.

[0159] Preferably, a (preferably predefined and / or predeterminable) plurality of test bench sizes (preferably using the metadata) is determined (particularly by the control device) which are to be used and / or are to be used for testing the software product to be tested. Preferably, a plurality of test benches (such as a predefined and / or predeterminable number of test benches) is selected and / or determined (particularly by the control device), particularly preferably using the metadata and / or depending on the plurality of test bench sizes. This is particularly advantageous for parallelization or broader coverage of real vehicle variants.

[0160] It is also conceivable that (in particular by the (central) control device) a warning value is determined and / or generated for output to an operator of the vehicle development test station system and / or is output (by means of an output device, in particular of the vehicle development test station system), in particular to the operator, in the event that (in particular by the (central) control device) no suitable test station could be determined on the basis of the metadata or using the metadata.

[0161] The determined metadata are preferably determined by the (central) control device.

[0162] Preferably, “determining” (or “determined [metadata]”) is to be understood as meaning, in particular, retrieving from a storage device (internal or external to the control device and / or the vehicle development test station system) (or, accordingly, “retrieved [metadata]”) and / or receiving the metadata from the (in particular external) development partner and / or a communication interface (described above), wherein the receiving of the metadata preferably occurs in response to a metadata query signal initiated or triggered by the control device (or, accordingly, “received [metadata]”).

[0163] Preferably, the method is used for at least partially automatically, preferably fully automatically, controlling a vehicle development test station system for testing, within the scope of a predetermined test order, a software product to be tested, in particular one developed and / or provided by an external development partner, as part of a method step for developing a vehicle or the vehicle to be developed.

[0164] Preferably, on the basis of the metadata (and / or the specified test order), at least one and preferably exactly one test station of the plurality of test stations for testing the software product to be tested is assigned to the software product to be tested (in particular by the, in particular processor-based, control device (which is described in more detail below)).

[0165] Preferably, the vehicle development test bench system detects and / or receives the software products to be tested and the metadata (respectively) associated with the software products to be tested using a communication interface described above and preferably using a method for operating a communication interface described above.

[0166] According to the embodiments described above, the metadata can comprise or consist of information and / or data and / or have a data structure and / or a data format described above. Preferably, the metadata (as described above) is machine-readable. This offers the advantage that the information contained in the metadata can be automatically evaluated and a test of the software product to be tested can be automatically executed at the test station, even with complex settings and / or configurations that must be made at the selected test station(s) to perform the test.

[0167] Preferably, the method comprises automatically initiating and / or automatically executing and / or (automatically) starting (and / or performing) a flashing process and / or installation process of the software product to be tested (in particular only) on the (at least one) selected and / or determined test station and / or (in particular only) on the and preferably all selected and / or determined test stations.

[0168] The automatic initiation and / or automatic execution and / or starting and / or carrying out of a flashing process and / or installation process is preferably carried out on the basis of the metadata and is preferably carried out by the, in particular, processor-based control device (which is described in more detail below).

[0169] Preferably, based on the metadata, at least one configuration setting, in particular a change to a previous configuration setting, is made for the (at least one) selected and / or determined (target) test station (before the flash and / or installation process). Preferably, the (central) control device makes or initiates at least one configuration setting at the selected and / or determined (target) test station.

[0170] In a preferred method, at least one current configuration setting of the at least one selected test station is determined, and this configuration setting is compared with at least one configuration setting determined based on the metadata and preferably specified according to the metadata. In the event of a discrepancy (during the comparison), at least one machine-readable configuration instruction is preferably created for configuring the at least one selected test station according to the at least one configuration setting determined based on the metadata.

[0171] In a preferred method, at least one compatibility variable characteristic of a compatibility of hardware versions of the at least one test station and / or at least one compatibility variable characteristic of a compatibility of software products installed at the at least one test station with respect to the software product to be tested and / or a dependency variable characteristic of dependencies of the software product to be tested on other software artifacts at the at least one test station and / or at least one precondition variable characteristic of at least one precondition which must be fulfilled for the installation of the software product to be tested is determined (preferably exclusively) as a function of the metadata.As described above, in a preferred embodiment (and especially in this case), the metadata is characteristic of compatibility (of the software product under test) with hardware versions, dependencies with other software artifacts, (preferably all) preconditions that must be met to install the software artifact.

[0172] Preferably, the assessment and / or selection of the at least one test bench is carried out depending on at least one compatibility variable and / or dependency variable and / or precondition variable. This offers the advantage that a suitable test bench can be selected in a non-backward compatible manner when the software product to be tested is provided and / or modified. Supported hardware versions, software versions and / or information on known limitations relevant to the use or testing of the software product to be tested can advantageously be derived from the metadata. Furthermore, it is advantageous that, even before the software product to be tested is installed or flashed, the at least one test bench (in particular each test bench) can be assessed to determine whether the software product to be tested is compatible with the existing hardware and / or software (currently or previously) installed on the test bench.This can advantageously prevent installation or flash failures and the resulting damage. Furthermore, it facilitates automated handling of deployed software products for testing.

[0173] It is also conceivable that a setting and / or configuration of the at least one test station is made depending on the at least one compatibility variable and / or dependency variable and / or precondition variable. It is conceivable that, for example, a software and / or hardware unit that is incompatible with the software product under test is uninstalled and / or exchanged and / or replaced with a different version.

[0174] Preferably, the at least one selected test station is set up as a function of an installation requirement (described above) (in particular triggered and / or instructed by the control device).

[0175] Preferably, at least one control variable is determined on the basis of the metadata or using the metadata, which is particularly preferably determined on the basis of at least one compatibility variable and / or dependency variable and / or precondition variable and / or installation requirement variable. Preferably, depending on the at least one control variable, the at least one test station is set up and / or a configuration setting is made and / or a measuring device of the test station is set up and / or configured and / or flash instructions (flash instructions) and / or installation instructions for the software product to be tested are transmitted to the test station and / or the software product to be tested is transmitted to the at least one test station and / or data relating to the test method to be performed is transmitted to the at least one test station.Preferably, the test procedure is carried out at the at least one test station depending on the control variable.

[0176] Preferably, a test environment (predefined and / or determined based on the metadata) is set up at the (at least one selected) test station based on the metadata. This offers the advantage that the test station or test bench is set up in such a way that the intended test environment for the software product to be tested can be provided. The (intended) test environment can be identified, especially uniquely, by the metadata.

[0177] In a preferred method, at least one test station of the vehicle development test station system is controlled as a function of a test environment for the software product to be tested, provided by the external development partner (in particular transmitted via the communication interface), preferably by performing a test procedure for the software product to be tested at the at least one selected test station. Thus, the test station can be configured to perform the test in such a way that the (provided) test environment is replicated at the test station. This offers the advantage that the software product to be tested can be tested at the test station using the test environment that was used during the development of the software product to be tested.

[0178] Preferably, the method comprises a data exchange with the external development partner with respect to at least one test case and / or at least one test environment with which the software product to be tested is to be tested on the vehicle development test bench system.

[0179] Preferably, the method comprises a data exchange with the external development partner with respect to at least one developer test case and / or at least one developer test environment with which the software product developed and / or to be tested was and / or is to be tested by the external development partner.

[0180] Preferably, depending on the metadata and / or the specified test order, data sets for carrying out the test procedure, which serve as input data for (interfaces of the) sensor devices, are loaded and / or retrieved and preferably stored in a storage device of the test station.

[0181] In a preferred method, at least one test procedure is determined based on the metadata, by which the software product to be tested is to be tested at the at least one selected test station. Thus, the test procedure by which the software product to be tested is to be tested can be determined based on the (transmitted) metadata, as well as any required configuration settings and / or other settings (such as loading data sets required for conducting the test, such as models and / or sensor data).

[0182] The method preferably comprises executing a test procedure for the software product to be tested after performing the flash and / or installation process on the target hardware (e.g., a test bench or control unit of a test bench). The test procedure is preferably performed according to or depending on the specified test order. However, it is also conceivable that a test procedure is specified (in another way) and / or modified (e.g., depending on previous test results).

[0183] Preferably, the control device initiates and / or starts the execution of the test method of the software product to be tested (at the at least one selected test station). It is also conceivable for the control device to monitor the execution of the test method.

[0184] Preferably, at least one measuring device (in particular as described above) of the test station collects (measurement and / or) test data during and / or after the execution of the test procedure. Preferably, the test results collected and / or those obtained based on the (measurement and / or) test data are compared with specified limit values ​​and / or values ​​and / or ranges.

[0185] Preferably, based on the comparison, at least one result variable characteristic of the validity of the software product to be tested and / or the functionality of the software product to be tested is determined (preferably by an evaluation device, in particular a processor-based one, of the test station and / or the control device). Preferably, the at least one result variable (preferably via a communication interface described above) and / or the test results and / or the (measurement and / or) test data are transmitted (automatically) to the (external) development partner.

[0186] In a preferred method, after a test run of a test procedure on the software product to be tested, test data and / or test results collected in the test run and / or at least one result variable determined based thereon is provided for transmission to the external development partner and / or their transmission is initiated.

[0187] Preferably, the control device can, in particular as soon as the at least one result variable and / or the test results and / or the (measurement and / or) test data have been determined, provide these data for transmission to the (external) development partner (preferably for transmission by means of a communication interface described above).

[0188] It is conceivable that the control device, in particular automatically (in particular when (new) result variables and / or the test results and / or the (measurement and / or) test data are available), sends a release request to a user of the vehicle development test station system for transmitting the data to the (external) development partner. Preferably, the control device initiates the transmission of the data to the (external) development partner in response to a corresponding user input for releasing the transmission.

[0189] Preferably, when (new) result variables and / or the test results and / or the (measurement and / or) test data (from the control device and / or the communication interface) are available, a notification signal is generated to notify the external development partner and preferably transmitted to the latter (preferably from the communication interface).

[0190] In a preferred method, when performing a test procedure on the software product to be tested, at at least one selected test station, it is checked repeatedly and / or cyclically and / or at regular intervals whether test data and / or test results collected during the execution of the test procedure and / or at least one determined result variable based thereon are available for transmission to the (external) development partner. If test data and / or test results collected during the execution of the test procedure and / or at least one determined result variable based thereon are available for transmission to the external development partner, the control device preferably triggers a transmission of this data to the (external) development partner and / or transmits this data (preferably using the communication interface) to the (external) development partner.

[0191] It is also conceivable that the communication interface repeatedly and / or cyclically and / or at regular time intervals requests and / or queries the provision of test data and / or test results collected at the at least one selected test station during the execution of a test procedure of the software product to be tested and / or at least one result variable(s) determined based thereon from the control device and / or at the at least one test station.

[0192] Preferably, the method comprises an exchange of data with the external development partner with regard to test data and / or test results which were collected and / or determined in test procedures carried out by the external development partner (on the software product to be tested).

[0193] In a preferred method, at least one test station of the vehicle development test station facility is controlled depending on test results provided by the external development partner (in particular transmitted via the communication interface) for the software product to be tested, preferably by performing a test procedure for the software product to be tested at the at least one selected test station. Thus, the test results can be taken into account during the test procedure and / or used to determine at least one result variable and / or to compare (measurement and / or) test data collected during the test procedure.For example, in the event of a deviation from the test data collected in the test procedure at the selected test station, a change and / or repetition of the test procedure and / or the performance of additional test procedures could be triggered and / or instructed (in particular by the control device).

[0194] Preferably, the method comprises a data exchange with the external development partner with regard to test data and / or test results which were collected and / or determined in test procedures carried out at the test station or the vehicle development test station facility.

[0195] Preferably, the vehicle development test station system has a database in which a version size of a test station, and preferably of each test station, which is characteristic of the version of each hardware and / or software unit is stored and / or can be stored.

[0196] Preferably, the vehicle development test bench system stores in a database a version of each software product to be tested and / or tested and / or installed / flashed on a test bench, preferably with an assignment to the test bench in question, in a database and preferably in the (above-mentioned) database.

[0197] In a preferred method, a continuous integration of a plurality of software products to be tested is carried out (particularly preferably automatically). Preferably, the plurality of software products to be tested is developed and / or provided by different (external) development partners. The plurality of software products to be tested can relate to the same operating function or different operating functions (of the same or different components) of the vehicle to be developed.

[0198] The multitude of software products to be tested can be tested and / or tested at one or more of the same test benches or at different test benches. The multitude of software products to be tested can be tested (especially automatically) simultaneously or (successively) one after the other at the at least one selected test bench. Successive testing can offer the advantage that any unusual behavior detected during a test can be clearly assigned to a software product to be tested.

[0199] Preferably, a test of a plurality of software products to be tested is performed in an order that is and / or was determined (as described above) depending on the respective metadata (preferably specifying a prioritization) and / or depending on a predefined test order (specifying a prioritization of the test process). The determination of the order can be performed by the control device.

[0200] In a preferred method, the software product to be tested, and in particular the software product to be developed according to the test order, is tested and / or developed using incremental changes to the vehicle development test bench system. This offers the advantage that any (possibly undesirable) changes in behavior and / or functionality resulting from an incremental change can be quickly attributed to the respective change in the software product. This enables an overall accelerated development of the software product to be developed.

[0201] Preferably, incremental software changes to a software product under test are provided via the communication interface, and the changes are described in the metadata. Preferably, the incremental software changes are documented in the database.

[0202] Preferably, each incremental software change is assigned a unique version size (and stored in the metadata and / or the database).

[0203] In a preferred method, (all) incremental changes to the software product to be tested are recorded, in particular automatically (preferably by the control device) and / or stored in a database together with, in particular, machine-readable metadata associated with the respective incremental change to the software product to be tested, which metadata is characteristic of the scope of the respective change to the software product to be tested. Preferably, the respective incremental change to the software product to be tested (i.e., in particular, an incrementally modified software product) and preferably also the metadata associated with this software product to be tested (which metadata is characteristic of the scope of the change compared to the previous version of the software product to be tested) are stored, in particular, in a tamper-proof manner (in the database) in a storage device (in particular, the vehicle development test bench system).

[0204] Preferably, the and preferably all version sizes characteristic of a (respective) version of a hardware and / or software unit, in particular of the (networked) network (in which the software product to be developed and / or tested is to be tested), of the at least one selected test station are / are stored in a / the storage device and preferably in the database. The version sizes are preferably stored in the database or the storage device in such a way that they can be assigned to the respective test station. It is also conceivable that all versions of the measuring devices of a respective (or each) test station (in particular for each test station) are stored in the database or the storage device, or version sizes characteristic thereof.Preferably, these (all) version sizes are (also) updated and / or supplemented in the event of changes to the respective hardware and / or software unit(s) of the (networked) network, the at least one selected or the respective test station or the measuring device(s). This offers the advantage that (in particular the control device) can compare the respective version sizes with the compatibility sizes and / or dependency sizes and / or installation requirement sizes and / or precondition size(s). The control device can thereby advantageously assess (with each incremental change) whether the selected test station is (still) suitable for testing the software product to be tested (e.g., one that has been incrementally changed) and / or is configurable for this purpose (e.g., even in the event of, in particular, incremental changes to a hardware unit and / or a (virtual) model representing the hardware unit.

[0205] Preferably, a continuous integration of at least one hardware and / or at least one software product (to be tested) (so-called continuous integration) (and / or continuous deployment) is carried out by recording and storing the software products (to be tested) and documenting the version sizes (together with the other hardware and / or software units of the test benches or the (networked) network of a test bench). Preferably, the (particularly preferably all) individual development units (i.e., software and / or hardware components that were developed in a development process) are continuously integrated.

[0206] It is also conceivable that several software products to be tested (e.g. new versions of software already installed on the test bench), each with an incremental change, are to be tested at a test station. Continuous integration is preferably used to determine which of the software products to be tested leads to malfunctions in the entire (networked) network (in the test station). It is conceivable that, in order to develop a software product, a large number (preferably more than two, preferably more than five, preferably more than ten) of software products to be tested (particularly in a network) are recorded and / or received (via the communication interface), each of which differs from one another only by an incremental change.Preferably, by testing another software product of the external development partner, which differs from a previous software product of the external development partner only by an incremental change, a further incremental change or development of such a product is triggered and / or initiated by the external development result.

[0207] The present invention is further directed to a method for operating a vehicle development test station system, in which the vehicle development test station system is (automatically) controlled according to the method described above, in particular according to a preferred embodiment.

[0208] The present invention is further directed to a (central), in particular processor-based, control device for a vehicle development test station system for automatic, preferably fully automatic, control of the vehicle development test station system for testing, preferably within the framework of a predetermined test order, a software product to be tested (in particular developed and / or provided by a, preferably external, development partner) on the vehicle development test station system with regard to an implementation of at least one operating function, in particular vehicle function, for a vehicle to be developed.

[0209] The software product to be tested is preferably embedded software and particularly preferably control unit software.

[0210] The vehicle development test station system comprises a plurality of test stations, each of which is configured and / or configurable for testing at least one operating function of a plurality of operating functions, in particular vehicle functions, for the vehicle to be developed.

[0211] According to the invention, the control device is suitable and / or intended and / or configured to assess at least one, preferably each, test station of the plurality of test stations for its suitability, in particular its configuration and / or configurability, for testing the software product to be tested on the basis of recorded and / or received and / or determined metadata associated with the software product to be tested and / or to select at least one and preferably exactly one test station of the plurality of test stations.

[0212] Preferably, the control device is suitable and / or intended to carry out and / or have all of the features described above individually or in combination within the scope of the method for at least partially automatically controlling a vehicle development test bench system for testing a software product to be tested on the vehicle development test bench system within the scope of a predetermined test order.

[0213] The control device can be equipped with all features, individually or in combination with one another, which are described above in the context of the method for automatic control or in the method for operating a communication interface or in the context of the communication interface.

[0214] The present invention is further directed to a vehicle development test bench system (preferably as described above) comprising a control device for the vehicle development test bench system according to an embodiment described above (and preferably a communication interface described above, in particular according to a preferred embodiment described above).

[0215] The present invention is further directed to a computer program or computer program product comprising program means, in particular a program code, which represents or encodes at least some of the and preferably all method steps of the method according to the invention (in particular the method for operating a communication interface and / or the method for at least partially automatically, preferably fully automatically, controlling a vehicle development test station system) and preferably one of the described preferred embodiments and is designed to be executed by a processor device.

[0216] The present invention is further directed to a data memory on which at least one embodiment of the computer program according to the invention or a preferred embodiment of the computer program is stored.

[0217] The present invention has been described with reference to vehicle development or a test bench system for a vehicle to be developed. The present invention is also transferable to product development, in particular of (highly) networked products and / or products with software components and / or products with embedded software. The applicant reserves the right to also claim subject matter directed thereto. Thus, the vehicle development test bench system can be a test bench system of a manufacturer of the, in particular, (highly) networked product (with software components and / or embedded software) with at least one test station for testing the software product to be developed and / or tested at the test station. Furthermore, the above-mentioned operating function can be a function that can be performed and / or executed by the product to be developed after completion.

[0218] Further advantages and embodiments can be seen in the attached drawing: It shows: Fig. 1 a schematic representation of a data exchange between a vehicle development test station system and an external development partner via a communication interface according to the invention according to a preferred embodiment.

[0219] Fig. 1 shows a schematic representation of a data exchange between a vehicle development test bench system 30 and an external development partner 20 via a communication interface 10 according to the invention, according to a preferred embodiment. Reference numeral 1 denotes the (entire) system comprising a development and / or test environment of an external development partner 20, such as a supplier, and the development and / or test environment of an OEM (original equipment manufacturer), such as a vehicle manufacturer, as well as the communication interface 10 for the vehicle development test bench system (which is part of the OEM's development and / or test environment), in which developed software and / or hardware products are tested.

[0220] The interface serves as an interface between, in particular, an OEM, such as an original equipment manufacturer, and a software supplier (especially TIER 1) for the uncomplicated and automated delivery of vehicle software releases and the exchange of test artifacts.

[0221] With regard to software deliveries, this includes in particular the specification of metadata which the software supplier preferably (must) provide with each software delivery and which enables automatic handling and use (“deployment”) of the software in various test environments.

[0222] In addition, the interface should allow the exchange of test specifications and the return of test results and test reports.

[0223] The reference number 20 denotes Fig.1 a development and test environment (build & test environment) of a (software product) supplier or development partner. The circular arrow indicates the cycle of a preferred continuous integration and / or deployment (Integration - Build - Test - Deploy).

[0224] The reference numeral 22 denotes a, preferably cloud-based, data processing device and / or server, which serves for the development and / or testing of a software product, in particular in virtualized test stations or networks of (highly) networked hardware components.

[0225] Reference numeral 30 denotes a development and test environment (build & test environment) or a vehicle development test bench system of an OEM. The vehicle development test bench preferably comprises a plurality of hardware components that are (highly) interconnected in the form of a respective (hardware) network. For example, one or more control units can be interconnected with one or more sensors and / or actuators (for data exchange), in particular via a bus system. However, it is also conceivable that such a network (which serves as a test bench for testing an operating function and / or vehicle function of a vehicle under development) is (purely) virtualized or merely represented virtually.

[0226] Here too, the circular arrow indicates the cycle of continuous integration and / or deployment (Integration - Build - Test - Deploy).

[0227] The communication interface 10 now serves for data exchange 11 between the vehicle development test bench system 30 and the development partner 20 or its test and / or development environment or network, for example, originating from a (cloud-based) server and / or computer of the test and / or development environment or network. For example, test specifications 12, which are provided to the communication interface by the vehicle development test bench system 30 (arrow 13), can be exchanged.

[0228] Test results and reports 14 relating to the software product to be tested are provided to the communication interface 10 by the external development partner 20 or its test and / or development environment, and are transmitted from there to the vehicle development test bench system 30 (arrow 15). Reference numerals 32 and 34 indicate, by way of example, (networked) hardware of a test bench of the test bench system, at which, for example, a software product to be tested can be tested.

[0229] Reference numeral 2 denotes a control device for the vehicle development test bench system, which can preferably control at least one test bench and particularly preferably all test benches and / or can initiate and / or instruct the installation and / or flashing of a software product to be tested at a test bench and / or can make a configuration setting on a test bench and / or a measuring device of the test bench. Preferably, the control device selects at least one test bench depending on (provided) metadata associated with the software product to be tested. Preferably, the control device transmits the software product to be tested and / or data required for testing the software product to be tested to this test bench.

[0230] The communication interface 10 is provided with software artifacts or the software product to be tested and metadata 16 (associated and / or assignable to it) by the external development partner 20 and is transmitted from there to the vehicle development test bench system 30 (arrow 15).

[0231] Test results 18 (of the software product 16 tested in the vehicle development test station 30) are provided to the communication interface 10 by the vehicle development test station system 30 and transmitted from there to the external development partner 20 (arrow 13).

[0232] In general, the core of a preferred embodiment of the present invention is the definition of an interface 10 (referred to above as communication interface) between two domains, wherein one domain A (which can be, for example, a domain of a communication partner referred to above as an external development partner) has the task of developing and testing an artifact and domain B (which can be, for example, a domain of an OEM and / or operator of the vehicle development test bench facility or a service provider therefor) receives the artifact and test results.

[0233] Furthermore, domain B can use the interface to specify to domain A the test cases that domain A should perform before an artifact is delivered to domain B.

[0234] Furthermore, Domain B should also be able to provide a test environment (e.g., in the form of a simulation environment including bus simulations and virtualized ECUs) via the interface. The test environment can be versioned. Domain A can then reference the test environment, including the version used, in the test results.

[0235] Domain B can still specify which test environment in which version is to be used when providing the test cases.

[0236] The following are preferred options for communication between domain B and domain A, which (process steps or communication steps) can occur individually or in combination with each other: 1. Determination of the current test set by Domain B - Domain A sends a request to Domain B to specify a test set to be used; This request may contain the following information: ◯ A reference to one or more test cases, where the test cases and the reference of the test cases are known in both domains OR ◯ A complete description of the test cases, where the test case description can be proprietary between the two domains OR follow a defined standard ◯ Information indicating which type of test case description is used ◯ A reference to the test environment to be used, comprehensive and preferably consisting of ■ Description of the test environment ■ Version of the test environment ■ The description and version can also consist of a combination of several components and their respective versions - Domain B sends response with a confirmation that test set has been accepted or error message 2. Query of test results by domain B from domain A or cyclic request to provide test results 3. Provision of test results from domain A; e.g. after test run 4. Delivery of artifacts from domain A to domain B - Announcement of the place of delivery by domain A bidirectionally - Then message (POST) including the artifacts - Information according to specifications is provided 5. Provision of a test environment by Domain A - Notification mechanism when new test environment is available; Domain B informs Domain A about new versions of the test environments - Domain B gets development environment via stored link

[0237] The applicant reserves the right to claim all features disclosed in the application documents as essential to the invention, provided they are novel, individually or in combination, over the prior art. It is further noted that the figure also describes features that may be advantageous in and of themselves. The skilled person will immediately recognize that a specific feature described in a figure may be advantageous even without adopting further features from that figure. Furthermore, the skilled person will recognize that advantages may also arise from a combination of several features shown in individual or different figures. List of reference symbols 1 system 2 Control device 10 Communication interface 11 Exchanged data 12 test specifications 13, 15 Data exchange 14 Test results & reports 16 Software artifacts and metadata 18 test results 20 Test and development environment of the external development partner 22 servers 30 OEM development and / or test environment or vehicle development test facility 32, 34 Hardware of a test station of the vehicle development test station facility

Claims

[1] Method for operating a communication interface (10) for a vehicle development test station system (30), in particular one which is not publicly accessible, for exchanging data with respect to a software product, preferably embedded software and particularly preferably control unit software, to be tested within the scope of a predetermined test order at the vehicle development test station system (30) with regard to an implementation of at least one operating function, in particular vehicle function, for a vehicle to be developed, to be developed by an external development partner and / or to be provided to the communication interface (10) by the external development partner, wherein the vehicle development test station system (30) has a plurality of test stations, each of which is configured and / or configurable for testing at least one operating function of a plurality of operating functions, in particular vehicle functions, for the vehicle to be developed, characterized bythat the communication interface (10), on the basis of the predetermined test order, records the software product to be tested as well as metadata assigned to the software product to be tested, on the basis of which, in particular by the vehicle development test station system (30), one, preferably each, test station of the plurality of test stations can be assessed for its suitability, in particular with regard to its configuration and / or configurability, for testing the software product to be tested, and makes it available for transmission to the vehicle development test station system (30). [2] Method according to claim 1, wherein the communication interface (10) of the vehicle development test station system provides the metadata in machine-readable data format for at least partially automated test execution of the software product to be tested on the vehicle development test station system, in particular for automatic determination and / or assignment of a target test station for testing the software product to be tested. [3] Method according to the preceding claim, wherein the communication interface (10) of the vehicle development test station (30) provides the metadata in a data format independent of a programming language. [4] Method according to one of the preceding claims, wherein the metadata comprises machine-readable configuration instructions for automatically configuring the target test bench for testing the software to be tested at the target test bench of the vehicle development test bench facility. [5] Method according to one of the preceding claims, wherein the metadata comprises at least one installation requirement variable which is characteristic of an installation requirement of the software product to be tested to the target test station, in particular to a target hardware of the target test station, and / or at least one compatibility variable which is characteristic of a compatibility of a target hardware, in particular of a predetermined version of a target hardware of the target test station, and / or of a compatibility of a software installed on the target hardware before installation of the software product to be tested, in particular of a predetermined software version. [6] Method according to one of the preceding claims, wherein the communication interface provides the external development partner, depending on the predetermined test order, with at least one test case size which is characteristic of at least one predetermined test case to be tested on which the software product to be tested is to be tested, and preferably a predetermined plurality of test case sizes. [7] Method according to the preceding claim, wherein the communication interface provides the external development partner with at least one further test environment variable which specifies which test environment in which version is to be used for a test case to be tested. [8] Method according to one of the preceding claims, wherein the communication interface provides at least one test environment variable characteristic of a development partner test environment in which the software product to be tested is to be tested, in particular by the development partner, preferably before the software product to be tested is made available to the communication interface. [9] Method according to one of the two preceding claims, wherein the at least one test environment variable is characteristic of a simulation environment and / or an at least partial and preferably complete virtualization of the target test station to be selected, in particular a bus simulation and / or virtualized control units. [10] Method according to one of the preceding claims, wherein the communication interface retrieves at least one test result from a test of the software product to be tested carried out by the, in particular external, development partner and / or requests a transmission of a test result repeatedly and in particular cyclically. [11] Method according to one of the preceding claims, wherein, when carrying out a test of the software product to be tested, test results determined in the vehicle development test bench system are made available to the external development partner via the communication interface and / or the external development partner is notified of their provision. [12] Method according to one of the preceding claims, wherein a test environment provided to the communication interface by the external development partner, in particular during the development and / or testing of the software product to be tested, is provided by the communication interface to a test station of the vehicle development test station system, in particular to the test station determined and / or selected for testing the software product to be tested. [13] Method for at least partially automatically, preferably fully automatically, controlling a vehicle development test station system (30) for testing, within the framework of a predetermined test order, a software product to be tested, preferably embedded software and particularly preferably control unit software, developed and / or provided by an external development partner, on the vehicle development test station system (30) with regard to an implementation of at least one operating function, in particular vehicle function, for a vehicle to be developed, wherein the vehicle development test station system has a plurality of test stations, each of which is configured and / or configurable for testing at least one operating function of a plurality of operating functions, in particular vehicle functions, for the vehicle to be developed, characterized bythat on the basis of recorded and / or determined metadata assigned to the software product to be tested, by the vehicle development test station system (30) and / or a central control device for the vehicle development test station system, at least one, preferably each, test station of the plurality of test stations is assessed for its suitability, in particular its configuration and / or configurability, for testing the software product to be tested and / or at least one test station of the plurality of test stations is selected. [14] Communication interface (10) for a vehicle development test bench system (30), in particular one which is not publicly accessible, for data exchange with regard to a software product, preferably embedded software and particularly preferably control unit software, to be tested within the framework of a predetermined test order at the vehicle development test bench system (30) with regard to an implementation of at least one operating function, in particular vehicle function, for a vehicle to be developed, to be developed by an external development partner and / or to be provided to the communication interface (10) by the external development partner, wherein the vehicle development test bench system has a plurality of test stations, each of which is configured and / or configurable for testing at least one operating function of a plurality of operating functions, in particular vehicle functions, for the vehicle to be developed, characterized bythat the communication interface (10) is configured to record, on the basis of the predetermined test order, the software product to be tested and metadata assigned to the software product to be tested, on the basis of which metadata, in particular by the vehicle development test station system (30), one, preferably each, test station of the plurality of test stations can be assessed for its suitability, in particular with regard to its configuration and / or configurability, for testing the software product to be tested, and to provide it for transmission to the vehicle development test station system (30). [15] Vehicle development test station system (30) with a communication interface (10) according to the preceding claim.

Images