Method and device for computer-aided monitoring of the operation of a vehicle service

Abstract

Method for computer-aided monitoring of the operation of a vehicle service, comprising an interaction between the vehicle, a real central computing system (40), and a data sink assigned to the vehicle via a unique vehicle identifier, such that status data (SD) of the vehicle is transmitted from an in-vehicle telematics control unit (30) to the central computing system (40) due to a change and otherwise at cyclical time intervals, and the most recently transmitted status data (SD) is stored by the central computing system (40) for later retrieval and processing by the data sink, in which a) in a test environment a telematics control unit (30) of the type of vehicle or vehicle type for which the vehicle service is to be monitored is provided; b) the vehicle is simulated by a first simulation unit (11) by generating test data (TD) and providing it as status data (SD) to the telematics control unit (30) on a vehicle bus (12); c) the data sink is simulated by a second simulation unit (15), wherein the simulated data sink is assigned to the simulated vehicle via a unique test vehicle identifier (VIN) by retrieving the status data (SD) stored for the simulated vehicle from the real central computing system (40); d) the test data (TD) generated by the first simulation unit (11) and the status data (SD) retrieved by the second simulation unit (15) are evaluated for agreement by comparison.

Description

[0001] The invention relates to a method and a device for computer-aided monitoring of the operation of a vehicle service.

[0002] A vehicle service involves an interaction between the vehicle, a central computing system, and a data sink assigned to the vehicle via a unique vehicle identifier. This interaction involves the transmission of vehicle status data from an in-vehicle telematics control unit to the central computing system, either upon a change or at regular intervals. The central computing system then stores the most recently transmitted status data for later retrieval and processing by the data sink. The data sink can then, for example, visualize, store, and / or process the status data.

[0003] Such vehicle services are developed for different types of vehicles, based on the assumption of known hardware and software components in the vehicle, the central computing system, and the data sink. Any changes to the hardware and / or software components compared to this initial state—for example, hardware or software changes in the central computing system, different types of data sinks, or changes in the software versions of the programs running on the data sinks—can disrupt the stable operation of the vehicle service with regard to their interaction. Since digitalization involves continuous functional enhancements of the data sinks, for example, through adjustments in the central computing system or mobile communication components, the new combinations of hardware and software may introduce previously unknown sources of error.Therefore, validation and monitoring of the interaction of the various components that enable the provision of the vehicle service is necessary.

[0004] In particular, it is essential to identify any errors as quickly as possible so that the number of customers affected by a fault can be kept to a minimum. Typically, errors are only discovered through customer complaints, which, however, only allows for targeted analysis and troubleshooting to a limited extent, since log files are only available for the central computer system, enabling analysis of the problem. For example, vehicle-related problems cannot be efficiently analyzed.

[0005] The publication DE 10 2018 212 560 A1 discloses a computer-based system for testing a server-based vehicle function, which is set up to execute a method in which a functional model of the vehicle function is simulated by a first simulator on a server, at least a partial vehicle model is simulated by a second simulator, and the vehicle function is tested while a data connection between the first simulator and the second simulator is systematically influenced.

[0006] Document CN 1 09 240 261 A discloses a hardware-in-the-loop (HIL) test procedure for performance testing of functions in the vehicle's Internet of Things (IoT). The procedure comprises the following steps: First, in a vehicle-wide HIL test system, a fault injection unit can simulate and generate electrical or bus faults; second, the simulated and generated faults are confirmed and recorded by a CAN bus monitoring and recording tool according to a diagnostic protocol; and finally, a client sends a fault diagnosis instruction via a server to a T-BOX and performs a comparison and verification of the diagnostic data returned by the T-BOX and displayed by the client with the analog fault data recorded by the CAN bus monitoring and recording tool.

[0007] The object of the invention is to provide a method and a device for computer-aided monitoring of the operation of a vehicle service, which are functionally improved and, in particular, enable the rapid detection of possible errors due to changes in the vehicle service. In particular, it should be possible to more precisely pinpoint the location or cause of an error.

[0008] These tasks are solved by a method according to the features of claim 1 and a device according to the features of claim 13. Advantageous embodiments are set forth in the dependent claims.

[0009] According to a first aspect, a method for the computer-aided monitoring of the operation of a vehicle service is proposed, which involves an interaction between the vehicle, a real central computing system, and a data sink assigned to the vehicle via a unique vehicle identifier. The unique vehicle identifier is, for example, and preferably, the Vehicle Identification Number (VIN), but can also be another unique identifier. As part of the interaction, vehicle status data is transmitted from an in-vehicle telematics control unit to the central computing system upon a change and otherwise at cyclical time intervals. The most recently transmitted status data is stored by the central computing system for later retrieval and processing by the data sink. Processing by the data sink includes, for example, visualization of the status data. The data sink can, for example,a user terminal device, a (service) database, a computer, or a computing system.

[0010] To carry out the computer-aided monitoring of the vehicle service operation, in step a) a telematics control unit of a vehicle type or a specific vehicle type for which the vehicle service is to be monitored is provided in a test environment. The telematics control unit is thus a "real" telematics control unit as it is installed in a specific vehicle or vehicle type. Step a) is a one-time, preparatory step of the method according to the invention.

[0011] In step b), the vehicle is simulated by a first simulation unit. This unit generates test data and provides it as status data to the telematics control unit via a vehicle bus. The vehicle bus corresponds in its topology and message transmission scheme (protocol) to the vehicle bus as installed in a real vehicle. Since the telematics control unit operates as if it were installed in a real vehicle, it transmits the status data, for example, to the central computer system, either due to a change, a predefined transmission trigger, or at cyclical time intervals. The central computer system then makes the status data available for retrieval by the data sink.

[0012] In step c), the data sink is simulated by a second simulation unit by retrieving the status data stored for the simulated vehicle from the real central computing system. This retrieval is performed according to the message protocol used in reality. When this description refers to retrieving the status data stored in the central computing system, this generally involves a request message transmitted from the data sink to the central computing system, requesting status data from the data sink. To respond to the request message, the central computing system transmits a reply message containing the requested status data. This data can then be processed by the data sink as intended, in particular, visualized for a user.The data sink simulated by the second simulation unit is assigned to the vehicle simulated by the first simulation unit via a unique test vehicle identifier. This test vehicle identifier corresponds to a real vehicle identification number (VIN) in terms of structure and nomenclature.

[0013] In step d), the test data generated by the first simulation unit and the status data retrieved by the second simulation unit are evaluated for consistency by comparison.

[0014] The proposed method is based on a stationary system that simulates the functions of a real vehicle in conjunction with the central computing system used for real-time operation, typically referred to as the backend in vehicle environments. For a realistic simulation of a vehicle or vehicle type, a real telematics control unit is used, with all necessary input variables being provided to the telematics control unit in the usual format via the first simulation unit. Since the first simulation unit generates the test data, a large event space can be covered, enabling the detection of errors—whether due to hardware defects, faulty transmission links, or malfunctioning software components—both on the side of the central computing system and on the side of the data sink.The method thus enables the realization of a hardware-in-the-loop (HIL) test bench, which can be used, for example, after changes have been made to the hardware or software of any components in order to test their functionality.

[0015] Since the test data traverses the communication links used in real-world operation and is stored as status data in the central computer system (where the central computer system cannot recognize that the status data is test data from the simulated vehicle), the respective real-world technical subsystems, which are also used by customers, are processed. The status data, comprising the test data, is then retrieved via the interface of the data sink, which corresponds to the actual customer interface, and compared with the test data generated by the first simulation unit. It is possible to collect the status data at multiple measurement points, thus enabling the localization of a fault in the event of an error.Furthermore, it is possible to analyze specific error times and thus the impact of the errors, in order to, for example, draw conclusions about certain time-of-day-dependent disruptions that may occur, for example, due to excessive utilization of the central computing system.

[0016] A suitable design provides that the execution of steps b) and c) constitutes a test run. Preferably, the evaluation is carried out by comparison in step d) after a large number of test runs. Related test data sent and status data retrieved by the data sink can be identified, for example, using a timestamp or by the pairwise successive steps b) and c).

[0017] Furthermore, it is advisable to process only those test runs during evaluation where a difference is found when comparing the test data with the retrieved status data of a given test run. A difference exists, for example, if a status of a specific data source in the test data does not correspond to the status of the corresponding data source in the status data.

[0018] It is still useful to deduce the error component causing the error from the frequency of an error type at the location when evaluating test runs that show a difference.

[0019] The test data comprises the current status of a set of data sources, particularly vehicle sensors such as flap sensors (e.g., door(s), trunk, hood, sunroof, etc.), window sensors, tire pressure sensors, fluid level sensors (e.g., fuel level, engine oil level, traction battery charge level, traction battery voltage, etc.), fault memory entries, and the like. The specific data sources included in a set depend primarily on the functionality provided by the vehicle service and the sensors installed in the respective vehicle. A vehicle service can include all of the aforementioned data sources or any selection thereof.

[0020] According to a further advantageous configuration, the test data, in particular the respective status state of the set of data sources, is randomly generated by the first simulation unit. If the data source is, for example, a flap sensor, status information such as "open" or "closed," or a corresponding digital value ("1" or "0" or "H" or "L"), is transmitted. Fill level information is transmitted in numerical form, e.g., the remaining tank contents. With each test run, the test data, and thus the respective status state of the set of data sources, is randomly regenerated by the first simulation unit.

[0021] It remains advantageous for the test data to be generated cyclically and provided to the telematics control unit as status data, which then transmits it directly to the central computer system for storage. The cyclical generation can, for example, be aligned with or deviate from the cycle of status data transmission to the central computer system.

[0022] It is still advisable to store the test data, including status data, a timestamp, and the test vehicle identifier (as a standard vehicle identifier), in a database of the central computer system, with the status data, timestamp, and test vehicle identifier forming a test data record. Optionally, the test data record in the database can include an error message indicating whether and which errors were detected during processing within the central computer system. This makes it easier, for example, during numerous test runs, to deduce the location or component causing the error, particularly within the central computer system, from the frequency of a specific error type or error message.

[0023] Another practical approach involves writing the test data generated by the first simulation unit and the status data retrieved by the second simulation unit in an associated format (e.g., contiguous) to a common test run table in a database. When this description refers to retrieved status data, it means retrieving the entire test data set, which includes the status data. Although comparing only the test data and the retrieved status data would suffice to identify the error, the additional information contained in the test data set makes it easier to determine the time and / or location of the error.

[0024] Another practical configuration involves the first simulation unit transmitting status data to the central computer system via a wireless communication link. For this purpose, the components of the telematics control unit are used, which transmit the data to the central computer system via a mobile network connection, e.g., 3G, 4G (UMTS), 5G, and the like. This utilizes the standard mobile network interface.

[0025] It is advantageous for the second simulation unit to retrieve status data from the central computer system via a wireless or wired communication link. The wireless communication link could, for example, be a mobile phone connection, such as one used by a user. However, since the second simulation unit can also be connected to the central computer system via a network connection, retrieval in this way is also possible.

[0026] According to a second aspect of the invention, a device for computer-aided monitoring of the operation of a vehicle service is proposed, which is configured as described above. The device comprises a telematics control unit of the type of vehicle or vehicle type for which the vehicle service is to be monitored, as well as a test computing unit configured to carry out the method according to the invention according to one or more embodiments as described herein. The device according to the invention has the same advantages as those described above in connection with the method according to the invention.

[0027] According to another aspect, a computer program product is proposed comprising program code stored on a non-volatile, machine-readable medium and used to carry out a method according to one or more embodiments of the present invention.

[0028] The invention is explained in more detail below with reference to an exemplary embodiment shown in the drawing. The drawing shows: Fig. 1 a schematic representation of a device according to the invention for computer-aided monitoring of the operation of a vehicle service; Fig. 2. A database table DBT, which is provided in a central computing system and contains the last saved status data for a given vehicle; and Fig. 3 a test run table TRT, which is processed for the evaluation and monitoring of the operation of the vehicle service.

[0029] The device for computer-aided monitoring of the operation of a vehicle service is a stationary system that simulates the functions of a real vehicle in conjunction with a central computing system 40 in a test environment. The vehicle service comprises an interaction between a vehicle, the central computing system 40, and a data sink uniquely assigned to the vehicle, such as a user terminal device (mobile phone or mobile device), a database, or a computer or computer system. For the sake of simplicity, the following description refers to a user terminal device as the data sink without limiting generality.

[0030] The vehicle's functions are implemented in the test environment by a first simulation unit 11, which runs on a test computing unit 10, and a real telematics control unit 30 coupled to the test computing unit 10. The telematics control unit 30 is of a type of vehicle for which the vehicle service is to be monitored. In other words, the telematics control unit 30 is a real telematics control unit 30, as installed in a specific vehicle type.

[0031] The functions of the user device, e.g., a smartphone, are simulated by a second simulation unit 15, which, for example, is also run on the test computing unit 10. However, the first and second simulation units 11 and 15 could also be run on separate test computing units configured for data exchange.

[0032] The first simulation unit, which simulates the vehicle, is configured to generate test data TD and provide it to the telematics control unit 30 on a vehicle bus 12. The test data TD comprises a respective status state SZi of a set of data sources i (i = 1...n), where the n data sources can be any vehicle sensors, in particular flap sensors (e.g., of the door(s), trunk, hood, sunroof, etc.), window sensors, tire pressure sensors, level sensors (e.g., of a fuel tank, engine oil reservoir, traction battery), fault memory entries, and the like. The status state of a flap sensor, for example, comprises binary information, e.g., "open" or "closed" (or their digital equivalents "1" or "0" or logical "H" or logical "L").Tire pressure sensors and fluid level sensors provide numerical values, such as the pressure of a particular tire, the fill level of a tank, the volume of engine oil, the energy content of a traction battery, and the like. Fault memory entries include, for example, fault codes, which can be in any notation. The test data TD, in particular the respective status state SZi of the data source sets, is randomly generated by the first simulation unit 11.

[0033] The vehicle bus 12 is connected to a processing unit 31 of the telematics control unit 30. The vehicle bus 12 corresponds in its topology and the message transmission scheme (protocol) used to the vehicle bus as installed in the real vehicle, which is simulated here. The test data TD, which comprises a respective status state SZi of a set of data sources, is interpreted by the processing unit 31 of the telematics control unit 30 as status data SD. The processing unit 31 is configured to receive the test data present on the vehicle bus 12 and transmit it, as the status data SD corresponding to the test data TD, via a transmit / receive unit 32 of the telematics control unit 30 to the central computing system 40 using a wireless communication link 33. The wireless communication link 33 is based on the technology used by the telematics control unit 30, e.g., a mobile network according to 4G or 5G.

[0034] The status data SD is transmitted by the telematics control unit 30 together with the unique test vehicle identifier VIN (which corresponds to a standard vehicle identifier in its notation) to the central computer system 40 and is received there by a transmitter / receiver unit 43 of the central computer system 40.

[0035] The central computing system 40, which represents a backend for the vehicle manufacturer, also comprises a processing unit 41 and a database 42. The processing unit 41 is configured to receive the data received at the transmit / receive unit 43 (status data SD together with the test vehicle identification number VIN) and to store it as a test data record in the database 42. The test data record, which includes the status data SD, the test vehicle identification number VIN, and a timestamp TS, is stored in a database table DBT. The test data record differs from a real data record of an actual vehicle only in that it contains the test vehicle identification number VIN, or that the test data record can be distinguished from data records of real customers based on a different identification number.

[0036] A portion of a database table DBT containing a test data record (recognizable by the exemplary test vehicle identifier "Q19X39D3" in the VIN column) and several data records from a real vehicle (recognizable by the exemplary vehicle identifiers "R36O789", "E43P23T", "S23J2K4" and "WA134P3" in the VIN column) is shown as an example in Fig. Figure 2 illustrates this. In reality, the database table contains one record, i.e., one row entry, for each vehicle corresponding to the type of the simulated vehicle. This record contains the currently valid (i.e., last received from the central computer system 40) status data SD for each vehicle, i.e., for each respective vehicle identifier.

[0037] The database table DBT includes, for example, a column for the timestamp TS (which indicates the time of generation, transmission, or reception of the status data SD, e.g., in the format day:month:year hour:minute:second), a column for the vehicle identification number VIN, a number n of columns for the status states SZi of the n data sources (which together represent the status data SD), and an (optional) column for an error message FM (where "zero" represents no error and "FM1" or "FM2" represents a specific error). Each row entry corresponds to a data record or test data record. Thus, the database table DBT stores not only the test data record of interest to the present method, which is generated by the operation of the device according to the invention, but also all data records that generate status data SD from real vehicles of a vehicle manufacturer.Since the respective test data sets for the computer-aided monitoring of the operation of the vehicle service include the same test vehicle identifier VIN, these can be easily extracted step by step (e.g. after each transfer from the telematics control unit 30) from the database table DBT for further analysis.

[0038] From the perspective of the central computing system 40, the test computing unit 10, which executes the first and second simulation units 11, 15, behaves in the result no differently than a real vehicle or a real user terminal device.

[0039] For example, the central computing system 40 has a further transmitter / receiver unit 44, which can be wireless or wired, for communication with the second simulation unit 15. Optionally, only a single transmitter / receiver unit 43 can be provided to implement the method according to the invention. In the present embodiment, the status data SD or the complete test data set can be retrieved from the second simulation unit 15, which simulates the user terminal device, via the transmitter / receiver unit 44.

[0040] The communication link between the second simulation unit 15 and the transmit / receive unit 44 can be of any type. In the present embodiment, it is assumed that the communication between the second simulation unit 15 and the transmit / receive unit 44 takes place via a wired or wireless network connection 16, any network 50, and a wireless or wired communication link 51.

[0041] To retrieve the status data SD stored in the database table DBT for the simulated vehicle, the second simulation unit 15 transmits a request message AF to the central computer system 40. The request message AF contains, for example, the unique test vehicle identifier VIN and an authentication code AUT. The information contained in the request message AF is received by the transmit / receive unit 44, processed by the computer unit 41, and, in the case of successful authentication, a response message AW is transmitted from the central computer system 40 to the second simulation unit 15. The response message AW contains at least the status data SD, which comprises the respective status state SZi of the set of data sources, as well as the timestamp TS. As explained, information about an error message FM can also be transmitted.

[0042] The random generation of test data TD, its transfer to the central computing system 40 and its retrieval by the second simulation unit 15 constitutes a test run, which is preferably repeated at cyclical or irregular intervals so that a large amount of data is available for evaluation.

[0043] Whether the vehicle service operates as intended is determined by a comparative evaluation of the test data TD generated by the first simulation unit 11 and the status data SD retrieved by the second simulation unit 15. For this purpose, the test computing unit 10 has a database 20 or is connected to an external database 20. The test data TD generated by the first simulation unit 11 and the retrieved status data SD of this test run are stored in a test run table TRT of database 20. This is shown in an example in Fig. 3 shown.

[0044] The test run table TRT contains, for each test run that includes generating and transmitting test data TD and retrieving the corresponding status data SD, the generated timestamp TS, the vehicle identifier in the form of the test vehicle identifier VIN, the test data TD (comprising each switching state SZi of the set of data sources), the retrieved status data SD (comprising the respective status states SZi of the corresponding set of data sources), a CONS column containing information about the consistency between transmitted and received data, the FM column for any error message generated by the central computer system 40, and an FTP column for an error type, which can be determined from the error message and / or any discrepancies between test data TD and status data SD. Each row in the test run table TRT contains the data for one test run.In the present example, the data from four test runs are shown, whereas in practice, several hundred or thousand test runs are contained in the test run table for an evaluation.

[0045] While in the database table DBT ( Fig. 2) thus containing test data sets and data sets from real vehicles, the test run table TRT contains exclusively test data sets, i.e. data sets with the unique test vehicle identifier, in the present embodiment “Q19X39D3”.

[0046] In the test run table TRT, the information contained in the CONS and FTP columns is already evaluative in nature. The CONS column indicates whether there is a match between the sent data TD and the received status data SD. In this example, this is only the case for the data record in the first row with CONS = "y". Correspondingly, the central database system 40 also did not detect an error, so the error message FM contains the value "Null". In contrast, the data records in rows 2 to 4 show a discrepancy between the test data and the status data SD, which is why the value "n" is contained in the CONS column in each case. In all cases, the central computer system 40 detected an error during processing, with the respective cause of the error being indicated by the error FM = "FM1" or "FM2". From the error message FM, an error type FTP, e.g.,“1” is detected in the error message “FM1” and “FM2” in the error message FM2.

[0047] To verify the proper functionality of the vehicle service, the test data TD is preferably generated cyclically and provided to the telematics control unit 30 as status data SD for further processing as described above. The generation of each test data TD results in a test data record, which, together with the status data SD, leads to a row entry in the test run table TRT. The procedure is preferably operated around the clock. With a large number of test data records, it can be determined, for example, whether a specific error type FTP occurs frequently. From the error type, it can be determined, for example, at which point in the central computer system 40 an error occurred.

[0048] If there is no error in the central computing system, but a discrepancy between sent test data and retrieved status data SD is nevertheless observed, then, for example, if this occurs frequently at a certain time of day, it can be concluded that the wireless communication link 33 or the communication link via which the status data SD is retrieved from the second simulation unit 15 is overloaded.

[0049] If a fault cannot be clearly located on-site, log files stored in the central computer system could be used to determine whether the fault occurred before or after reception by the transmit / receive unit 43. This would allow for a concrete statement to be made about the availability, reliability, response times, and accuracy of the vehicle service.

[0050] The computer-aided monitoring of the vehicle service operation is based on a hardware-in-the-loop system that utilizes a real telematics control unit of a specific vehicle type or vehicle type, as well as processing by the central computing system, which is also used for production operation. Only the vehicle and the data sink are simulated by simulation units in one or more test computing units.

[0051] Through the cyclical generation of random data on the vehicle side, the test data is sent to the central computer system via a real wireless communication link. The generated test data, processed as status data, can then be accessed at defined points and compared with the generated or transmitted test data. Access to the central computer system is via the same interfaces used by the vehicle's customers to access the central computer system 40. Reference symbol list 10 test processing units 11 First simulation unit for simulating a set of vehicle data sources 12 vehicle buses 15 Second simulation unit for simulating a data sink 16 Network connection (wired or wireless) 20 database 30 Telematics control unit 31 computing unit 32 Transmit / receive unit (antenna, amplifier) 33 wireless communication connection 40 central computing system (backend) 41 computing unit 42 database 43 Transmit / receive unit (antenna, amplifier) 44 Transmit / receive unit (antenna or connector, amplifier) 50 network 51 wireless or wired communication connection SD status data VIN unique test vehicle identifier (vehicle identification number) TD Test Data DBT database table TS timestamp SZi status state of the i-th data source (i = 1...n, where n ≥ 1) FM error message TRT test run table CONS: Data transmission and reception errors FTP error type AF Inquiry Message Re: Reply message

Claims

Method for computer-aided monitoring of the operation of a vehicle service, comprising an interaction of the vehicle, a real central computing system (40) and a data sink assigned to the vehicle via a unique vehicle identifier, such that status data (SD) of the vehicle is transmitted from an in-vehicle telematics control unit (30) to the central computing system (40) due to a change and otherwise at cyclical time intervals, and the most recently transmitted status data (SD) is stored by the central computing system (40) for later retrieval and processing by the data sink, wherein a) a telematics control unit (30) of a type of vehicle or vehicle type for which the vehicle service is to be monitored is provided in a test environment;b) the vehicle is simulated by a first simulation unit (11) by generating test data (TD) and providing it as status data (SD) to the telematics control unit (30) on a vehicle bus (12); c) the data sink is simulated by a second simulation unit (15), wherein the simulated data sink is assigned to the simulated vehicle via a unique test vehicle identifier (VIN) by retrieving the status data (SD) stored for the simulated vehicle from the real central computing system (40); d) the test data (TD) generated by the first simulation unit (11) and the status data (SD) retrieved by the second simulation unit (15) are evaluated for consistency by comparison. Method according to claim 1, wherein the execution of steps b) and c) constitutes a test run, wherein the evaluation is carried out by comparison in step d) after a plurality of test runs. Method according to claim 2, wherein only those test runs are processed during the evaluation in which the comparison of the test data (TD) with the retrieved status data (SD) of a respective test run shows a difference. Method according to claim 2 or 3, wherein, in the evaluation of the test runs exhibiting a difference, the location or component causing the error is inferred from the frequency of a fault type. Method according to one of the preceding claims, wherein the test data (TD) comprise a respective status state (SZi) of a set of data sources, in particular flap sensors, window sensors, tire pressure sensors, level sensors, fault memory entries. Method according to one of the preceding claims, wherein the test data (TD), in particular a respective status state (SZi) of the set of data sources, are randomly generated by the first simulation unit (11). Method according to one of the preceding claims, wherein the test data (TD) are generated cyclically and are provided to the telematics control unit (30) as the status data (SD). Method according to one of the preceding claims, wherein the test data (TD) are stored as the status data (SD) together with a timestamp (TS) and the test vehicle identifier (VIN) in a database (42) of the central computing system (40), wherein the status data (SD), the timestamp (TS) and the test vehicle identifier (VIN) form a test data set. Method according to claim 8, wherein the test data set in the database (4) includes an error message (FM) indicating whether and which error was detected within the processing of the central computing system (40). Method according to one of the preceding claims, wherein the test data (TD) generated by the first simulation unit (11) and the status data (SD) retrieved by the second simulation unit (15) are written in an associated form to a common test run table (TRT) of a database (20). Method according to one of the preceding claims, wherein the first simulation unit (11) transmits the status data (SD) to the central computing system (40) via a wireless communication link (33). Method according to one of the preceding claims, wherein the second simulation unit (15) retrieves the status data (SD) from the central computing system (40) via a wireless or wired communication link (16, 51). Device for computer-aided monitoring of the operation of a vehicle service, comprising an interaction of the vehicle, a real central computing system (40) and a data sink assigned to the vehicle via a unique vehicle identifier, such that status data (SD) of the vehicle is transmitted from an in-vehicle telematics control unit (30) to the central computing system (40) due to a change and otherwise at cyclical time intervals, and the most recently transmitted status data (SD) is stored by the central computing system (40) for later retrieval and processing by the data sink, comprising: - a telematics control unit (30) of a type of vehicle or vehicle type for which the vehicle service is to be monitored;and a test computing unit (10) configured to perform the following steps: b) simulate the vehicle by a first simulation unit (11) by generating test data (TD) and providing it as status data (SD) to the telematics control unit (30) on a vehicle bus (12); c) simulate the data sink by a second simulation unit (15), wherein the simulated data sink is assigned to the simulated vehicle via a unique test vehicle identifier (VIN), by retrieving the status data (SD) stored for the simulated vehicle from the real central computing system (40); d) evaluate the test data (TD) generated by the first simulation unit (11) and the status data (SD) retrieved by the second simulation unit (15) for consistency by comparison. Device according to claim 13, wherein the test computing unit (10) is further configured to perform the steps according to any one of claims 2 to 12. Computer program product comprising program code stored on a non-volatile, machine-readable medium for performing a method according to any one of claims 1 to 12 when the program code is executed on a computer.

Images