Method and apparatus for computer-supported monitoring of the operation of a vehicle service

Abstract

The invention relates to a method for computer-supported monitoring of the operation of a vehicle service, the vehicle service comprising a vehicle, a central computing system and an interaction with a data sink assigned to the vehicle via a unique vehicle identification, such that status data of the vehicle is transmitted from a communication control device inside the vehicle to the central computing system due to a change and at periodic time intervals, the last transmitted status data is stored by the central computing system for calling up and processing by the data sink. A communication control device of a vehicle or of a vehicle type is provided in a test environment, for which the vehicle service should be monitored. The vehicle is simulated by a first simulation unit, test data is generated by the first simulation unit and provided as status data on a vehicle bus to the communication control device. The data sink is simulated by a second simulation unit, the status data stored for the simulated vehicle is called up from the central computing system. The test data and the status data are evaluated by comparison.

Description

TECHNICAL FIELD

[0001] The invention relates to a method and an apparatus for computer-supported monitoring of the operation of a vehicle service. BACKGROUND

[0002] A vehicle service comprises a vehicle, a central computing system and an interaction with a data sink which is assigned to the vehicle via a unique vehicle identification. The interaction is such that state data of the vehicle is transmitted from a communication control device inside the vehicle to the central computing system due to a change and furthermore at periodic time intervals, and the last transmitted state data is stored by the central computing system for subsequent calling and processing by the data sink. The state data can then be visualized and / or stored and / or processed on the data sink, for example.

[0003] Such a vehicle service is developed for respectively different types of vehicles, wherein the development is based on hardware components and software components which are known in the vehicle, the central computing system and the data sink. Every change to the hardware components and / or software components compared to this initial state, for example a hardware change or a software change in the central computing system, a change of the type of data sink or a software version of a program running on the data sink, can disturb the stable operation of the vehicle service in terms of the mutual cooperation. Since there is a continuous functional expansion of the data sink in the context of digitization, for example due to adjustments in the central computing system or radio components, new error sources can arise due to the new combinations of hardware and software. There is therefore a need to verify and monitor the mutual cooperation of the different components which enable the provision of the vehicle service.

[0004] In particular, it is necessary to recognize possible errors as quickly as possible, so that the number of customers who encounter errors can be kept as small as possible. Errors are typically only recognized through corresponding customer complaints, however this can only achieve a limited targeted analysis and error elimination, since there are only log files for the central computing system which enable an analysis of the problem. Problems on the vehicle side, for example, cannot be analyzed efficiently. SUMMARY

[0005] It is an object of the invention to specify a method and an apparatus for computer-supported monitoring of the operation of a vehicle service which is functionally improved and in particular enables a quick recognition of possible errors caused by changes to the vehicle service. In particular, it should be possible to more accurately delimit the location or cause of the error.

[0006] The object is solved by a method for computer-supported monitoring of the operation of a vehicle service according to the invention and an apparatus for computer-supported monitoring of the operation of a vehicle service according to the invention.

[0007] According to a first aspect a method for computer-supported monitoring of the operation of a vehicle service is proposed, the vehicle service comprising a vehicle, a central computing system and an interaction with a data sink assigned to the vehicle via a unique vehicle identification. The unique vehicle identification is for example and preferably a Vehicle Identification Number (VIN), however the unique vehicle identification can also be another unique identification. Within the scope of the interaction, status data of the vehicle is changed and is furthermore transmitted at periodic time intervals from a communication control device inside the vehicle to the central computing system, and the last transmitted status data is stored by the central computing system for subsequent calling and processing by the data sink. The processing by the data sink comprises for example a visualization of the status data. The data sink can for example be a user terminal device or a (service) database or a computer or a computing system.

[0008] In order to implement the computer-supported monitoring of the operation of the vehicle service, in step a) a communication control device of the type of a vehicle or of a determined vehicle type is provided in a test environment, for which vehicle or vehicle type the vehicle service shall be monitored. The communication control device is thus a "real" communication control device, as it is installed in the determined vehicle or vehicle type. Step a) is a step which is to be implemented or prepared once according to the method of the present application.

[0009] In step b) the vehicle is simulated by a first simulation unit in such a way that test data is generated by the first simulation unit and provided as status data on a vehicle bus to the communication control device. The vehicle bus corresponds in its topology as well as in the used message transmission scheme (protocol) to the vehicle bus installed in the real vehicle. Since the communication control device functions in a regular manner as it is installed in the real vehicle, the communication control device transmits for example status data to the central computing system due to a change of a further determined sending trigger or at periodic time intervals, which subsequently provides the status data for calling by the data sink.

[0010] In step c) the data sink is simulated by the second simulation unit in such a way that the stored state data for the simulated vehicle are called from the central computing system. The calling takes place in accordance with the message protocol used in reality. If reference is made in the present description to a call of the state data stored in the central computing system, this generally comprises a query message transmitted from the data sink to the central computing system with which the state data are requested by the data sink. In order to reply to the query message, the central computing system transmits a response message which contains the requested state data. The response message can then be processed in the usual way by the data sink, in particular the response message is visualized for the user. Here, the data sink simulated by the second simulation unit is set up in correspondence with the vehicle simulated by the first simulation unit via a unique test vehicle identification. The test vehicle identification corresponds in terms of construction and nomenclature to a real vehicle identification (VIN).

[0011] In step d) the test data generated by the first simulation unit and the state data called by the second simulation unit are evaluated by comparison.

[0012] The proposed method is thus based on a fixed system which simulates the functioning of a real vehicle in cooperation with a central computing system for real-time operation, which is typically referred to as a backend in the environment of the vehicle. In order to simulate the vehicle or the vehicle type in compliance with reality, a real communication control device is used for this, wherein all necessary input variables are provided for the communication control device in the usual form via the first simulation unit. Since the first simulation unit generates test data, a large event space can be covered, so that the discovery of errors, whether caused by a hardware fault, an incorrect transmission route or a wrongly functioning software component, can be determined not only on the part of the central computing system but also on the part of the data sink. The method can thus implement a hardware-in-the-loop test bench which can be used, for example, after a change to an arbitrary component in the hardware range or the software range in order to test the functionality.

[0013] Since the test data are passed through the communication connections used in real operation and stored as status data in the central computing system, which cannot recognize that the status data are test data of a simulated vehicle only, the corresponding technically subsystems really in operation are passed through, which are also used by the customer. The status data including the test data are then called via the interface of the data sink, which corresponds to the actual customer interface, and matched with the test data generated by the first simulation device. It is possible here to intercept the status data at a plurality of measuring points, whereby it is possible to delimit the error location in the event of an error. It is furthermore possible to analyze the specific error moment and thereby the error consequences in order to deduce, for example, a determined day-related disturbance, which can occur, for example, as a result of an excessive load of the central computing system.

[0014] An advantageous design provides that the execution of steps b) and c) forms a test run. Preferably, the evaluation takes place after a plurality of test runs by comparison in step d). The associated transmitted test data and the status data called by the data sink can be found, for example, by means of a time stamp or a pair of steps b) and c) successive to one another.

[0015] It is also advantageous that only test runs are processed in the evaluation in which the comparison of the test data of the respective test run with the called status data has a discrepancy. There is a discrepancy, for example, in the case in which the status of a determined data source in the test data does not correspond to the status of the corresponding data source in the status data.

[0016] It is furthermore advantageous that in the evaluation of the test runs with a discrepancy the location or the error component causing the error is deduced from the frequency of the error type.

[0017] The test data include the respective status of a group of data sources, in particular vehicle sensors, for example roll-over sensors (such as doors, trunk, hood, sunroof, etc.), window sensors, tire pressure sensors, level sensors (such as tank, engine oil, state of charge of traction battery, battery voltage of traction battery, etc.), fault memory records, etc. Which specific data sources are included in the group of data sources is essentially related to the functions provided by the vehicle service and the sensors installed in the respective vehicle. The vehicle service can include all of the mentioned data sources, however, the vehicle service can also include an arbitrary partial selection of the mentioned data sources.

[0018] According to another advantageous design, the test data, in particular the respective states of the group of data sources, are generated randomly by the first simulation unit. If the data sources are, for example, flip-flop sensors, the state information "on" or "off" is transmitted or a digital information corresponding to the state information ("1" or "0" or "high (H)" or "low (L)") is transmitted. The level information, for example the residual tank filling, is transmitted in digital form. With each test run, the test data and thus the respective states of the group of data sources are randomly regenerated by the first simulation unit.

[0019] It is furthermore advantageous if the test data are generated periodically and provided as state data to the communication control device, which then directly transmits the state data to the central computing system for storage. The periodic generation can, for example, follow or deviate from the period of the transmission of the state data to the central computing system.

[0020] It is furthermore advantageous if the test data are stored in the database of the central computing system as state data together with a time stamp and a test vehicle identification as a general vehicle identification, wherein the state data, the time stamp and the test vehicle identification form a test data group. The test data group can optionally comprise an error message in the database, which states whether and which error has been ascertained in the processing within the central computing system. This simplifies, for example, the inference of the location or the component causing the error from the error type or the frequency of the error message in a plurality of test runs, in particular within the central computing system.

[0021] Another advantageous design provides that the test data generated by the first simulation unit and the state data called by the second simulation unit are written in a coordinated manner, for example in correlation, into a common test run table in the database. If reference is made in this description to called state data, this is to be understood as a reference to all test data groups comprising state data. While it is sufficient for ascertaining errors to compare only the test data and the called state data, the information additionally contained in the test data group simplifies the inference of the error moment and / or the error location.

[0022] Another advantageous design provides that the first simulation unit transmits the state data to the central computing system via a wireless communication connection. For this purpose, a component of the communication control device is used, which transmits data to the central computing system via a mobile radio connection, for example 3G, 4G (UMTS), 5G, etc. Here, a mobile radio interface set up in general manner is used thereby.

[0023] Advantageously, the second simulation unit calls the status data from the central computing system via a wireless or wired communication connection. The wireless communication connection can for example correspond to a corresponding mobile radio connection used by the user. However, since the second simulation unit can also be connected to the central computing system via a network connection, a call in this way is also possible.

[0024] According to a second aspect of the application, a device for computer-supported monitoring of the functioning of a vehicle service is proposed, which vehicle service is constituted as described above. The device comprises a communication control device of a vehicle of the type or of the vehicle type for which the vehicle service is to be monitored, and a test computing unit, which is configured for carrying out the method according to one or more design versions according to the application as described herein. The device according to the application has the same advantages as described above in connection with the method according to the application.

[0025] According to another aspect, a computer program product is proposed, which comprises program code stored on a non-volatile machine-readable carrier and which is used for carrying out the method according to one or more embodiments of the application. BRIEF DESCRIPTION OF DRAWINGS

[0026] The application is explained in more detail below by means of embodiments in the drawings. In the drawings:

[0027] Figure 1 A schematic diagram of a device for computer-supported monitoring of the functioning of a vehicle service according to the application is shown;

[0028] Figure 2 A database table DBT is shown, which is provided in the central computing system and which comprises the last stored status data for the respective vehicle; and

[0029] Figure 3 A test run table TRT is shown, which is processed for evaluating and monitoring the functioning of the vehicle service. DETAILED DESCRIPTION

[0030] The device for computer-supported monitoring of the functioning of a vehicle service is a fixed system, which simulates the functioning of a real vehicle in cooperation with the central computing system 40 in a test environment. The vehicle service comprises the interaction of the vehicle, the central computing system 40 and a data sink assigned to the vehicle, such as for example a user terminal device (mobile radio telephone or mobile device), a database or a computer or computing system. In the following description, a user terminal device is referred to as a data sink without limitation in generality for the sake of simplicity.

[0031] The functions of the vehicle are implemented in the test environment by means of a first simulation unit 11, which is implemented on the test computing unit 10, and a real communication control device 30, which is coupled to the test computing unit 10. Here, the communication control device 30 is a communication control device of a vehicle of the type or of the vehicle type for which the vehicle service should be monitored. In other words, the communication control device 30 is a real communication control device 30, as it is installed in a defined vehicle type.

[0032] The functions of a user terminal device, for example a smartphone, are simulated by means of a second simulation unit 15, which is also implemented, for example, on the test computing unit 10. However, the first and second simulation units 11, 15 can also be separate from one another, with the test computing unit being configured for data exchange.

[0033] The first simulation unit, which simulates the vehicle, is configured for generating test data TD and for providing the test data to the communication control device 30 by means of the vehicle bus 12. The test data TD comprise a respective state SZi of a set of data sources i (i = 1... n), wherein the n data sources can be arbitrary vehicle sensors, in particular flip sensors (for example of doors, luggage compartments, bonnets, convertible roofs, etc.), window sensors, tire pressure sensors, level sensors (for example of tanks, engine oil tanks, traction batteries, etc.), fault memory entries, etc. The state of a flip sensor comprises, for example, binary information, for example "open" or "closed" (or its numerical equivalent "1" or "0" or the logical "high (H)" or the logical "low (L)"). Tire pressure sensors and level sensors give, for example, as digital values, pressure information of the respective tire, the level of a tank, the engine oil quantity, the energy content of a traction battery, etc. Fault memory entries comprise, for example, error codes, wherein the error codes can exist in arbitrary notations. The test data TD, in particular the respective states SZi of the set of data sources, are generated randomly by means of the first simulation unit 11.

[0034] The vehicle bus 12 is connected with a computing unit 31 of the communication control device 30. The vehicle bus 12 corresponds to a vehicle bus installed in a real, here simulated, vehicle with regard to its topology and the used message transmission scheme (protocol). The test data TD, which comprises a respective state Szi of a set of data sources, is interpreted by the computing unit 31 of the communication control device 30 as state data SD. The computing unit 31 is configured for receiving the test data present on the vehicle bus 12 and transmitting the test data as state data SD, which corresponds to the test data TD, via a sending / receiving unit 32 of the communication control device 30 to the central computing system 40 by means of a wireless communication connection 33. The wireless communication connection 33 is based on the technology used by the communication control device 30, for example a mobile radio network according to 4G or 5G.

[0035] The state data SD together with a unique test vehicle identification VIN, which corresponds to a general vehicle identification with regard to its notation, is transmitted from the communication control device 30 to the central computing system 40 and received there by a sending / receiving unit 43 of the central computing system 40.

[0036] The central computing system 40, which is a backend of a vehicle manufacturer, further comprises a computing unit 41 and a database 42. The computing unit 41 is configured for accepting the data received on the sending / receiving unit 43 (state data SD together with test vehicle identification VIN), processing the data and storing the data as a test data set in the database 42. Here, the test data set is stored in a database table DBT, which comprises the state data SD, the test vehicle identification VIN and a time stamp TS. The test data set is distinguished from real data sets of real vehicles only in that the test vehicle identification VIN is contained as vehicle identification, or the test data set can be distinguished from data sets of real customers based on another identification.

[0037] A part of the database table DBT is exemplarily shown in Figure 2 which has test data sets (visible from the exemplary test vehicle identification "Q19X39D3" in the VIN column) and data sets of a plurality of real vehicles (visible from the exemplary vehicle identifications "R360789", "E43P23T", "S23J2K4" and "WA134P3" in the VIN column). In reality, the database table comprises one data set, i.e. a row record, for each vehicle, which corresponds to a type of the simulated vehicles. Here, for each vehicle, i.e. for the respective vehicle identification, a data set is contained, which comprises the currently valid, i.e. last received by the central computing system 40, state data SD.

[0038] The database table DBT comprises, for example, a column for the time stamp TS (which gives the time at which the status data SD was generated or emitted or received, for example in the format day: month: year hour: minute: second), a column for the vehicle identification VIN, n columns for the status SZi of the n data sources (the status of the n data sources represents the status data SD as a whole) and (optionally) a column for the error message FM (where "Null" stands for no error and "FM1" or "FM2" stands for a determined error). Each row record corresponds to a data set or test data set. Thus, not only the test data sets which are of interest for the method (which are generated by the running of the device according to the application) are stored in the database table DBT, but also all data sets which are generated by real vehicles of the vehicle manufacturer with status data SD. Since the respective test data sets comprise the same test vehicle identification VIN in order to monitor the running of the vehicle service computer-supported, these test data sets can be extracted from the database table DBT step by step (for example after each transmission by the communication control device 30) in a simple manner for further analysis.

[0039] From the point of view of the central computing system 40, the test computing unit 10 which implements the first and second simulation units 11, 15 behaves in terms of results in no way differently from a real vehicle or a real user terminal device.

[0040] The central computing system 40 has, for example, a further sending / receiving unit 44 for communication with the second simulation unit 15, which can be of wireless or wired nature. Optionally, only one sending / receiving unit 43 can also be provided in order to implement the method according to the application. In this embodiment, the status data SD or the entire test data set can be called up by the second simulation unit 15 which simulates a user terminal device via the sending / receiving unit 44.

[0041] The communication connection between the second simulation unit 15 and the sending / receiving unit 44 can be of any type. In this embodiment it is provided that the communication between the second simulation unit 15 and the sending / receiving unit 44 is implemented via a wired or wireless network connection 16, any network 50 and a wireless or wired communication connection 51.

[0042] For calling the stored state data SD in the database table DBT for the simulated vehicle, a query message AF is transmitted from the second simulation unit 15 to the central computing system 40. In the query message AF, for example, the unique test vehicle identification VIN and the authentication AUT are contained. The information contained in the query message AF is received by the sending / receiving unit 44, processed by the computing unit 41 and, in the case of a positive authentication, a response message AW is transmitted from the central computing system 40 to the second simulation unit 15. In the response message AW, at least the state data SD, which comprises the respective states SZi of the set of data sources, and the time stamp TS are contained. As set out, information of an error message FM can also be transmitted.

[0043] The random generation of the test data TD, the transmission to the central computing system 40 and the calling by the second simulation unit 15 constitute a test run, which is repeated preferably at periodic or irregular time intervals, so that a large amount of data is available for evaluation.

[0044] By a comparative evaluation of the test data TD generated by the first simulation unit 11 and the called state data SD by the second simulation unit 15, it is determined whether the vehicle service is functioning according to the norm. For this purpose, the test computing unit 10 has a database 20 or is connected with an external database 20. In the database 20, the test data TD generated by the first simulation unit 11 and the called state data SD of the test run are stored in a test run table TRT of the database 20. This is shown, for example, in Figure 3 .

[0045] The test run table TRT comprises for each test run, which comprises the generation and emission of test data TD and the calling of the respective state data SD: the generated time stamp TS, the vehicle identification in the form of the test vehicle identification VIN, the test data TD, which comprises the respective switch states SZi of the set of data sources, the called state data SD, which comprises the respective states SZi of the corresponding set of data sources, a CONS column, which comprises information about the conformity between the transmitted and received data, an FM column for error messages, which can be generated by the central computing system 40, and an FTP column for the error type, which can be determined from the error message and / or from the possibly non-conforming test data TD and state data SD. Each row in the test run table TRT comprises the data of one test run. In the present example, the data of four test runs are shown, wherein in practice several hundred or several thousand test runs are contained in the test run table for evaluation.

[0046] Thus, in the database table DBT Figure 2The test data set and the data set of the real vehicle are contained in the test run table TRT, while the test data set, i.e. the data set with the unique test vehicle identification (in the present example "Q19X39D3"), is contained in the test run table TRT only.

[0047] The information contained in the columns CONS and FTP in the test run table TRT already has an evaluative character. The column CONS gives: whether there is a correspondence between the transmitted data TD and the received status data SD. For the present example, this is only the case for the data sets in the first line with CONS = "y". In correspondence therewith, no error has been ascertained by the central database system 40 either, so that the value "Null" is contained as error message FM. In contrast thereto, the data sets in lines 2 to 4 have a deviation between the test data and the status data SD, so that the value "n" is contained in the column CONS, respectively. In all cases, an error has been ascertained, for example by the central computing system 40, when processing in the central computing system 40, wherein the respective error cause is indicated by the error message FM = "FM1" or "FM2".

[0048] For ascertaining the regular functionality of the vehicle service, the test data TD are preferably generated periodically and provided as status data SD to the communication control device 30 for further processing as described above. The generation of the respective test data TD continuously forms a test data set, which, together with the status data SD, forms a line record in the test run table TRT. The method is preferably operated without interruption. In the case of a plurality of test data sets, it is possible to ascertain, for example, whether a certain error type FTP occurs frequently. From the error type, it is possible to ascertain, for example, at which location in the central computing system 40 an error occurs.

[0049] If no error exists in the central computing system, but an inconsistency between the transmitted test data and the called status data SD can still be ascertained, it can be concluded, for example, in the case of a frequent occurrence at a certain time of day, that the wireless communication connection 33 or the communication connection for calling the status data SD by the second simulation unit 15 is overloaded.

[0050] If the error cannot be located unambiguously on site, the log files stored in the central computing system can also be used in order to ascertain whether the error occurs before the reception by the transmission / reception unit 43 or after the reception by the transmission / reception unit. Thereby, specific conclusions can be drawn with respect to the availability, reliability, response time and content accuracy of the vehicle service.

[0051] The computer-supported monitoring of the operation of a vehicle service is based on a hardware-in-the-loop system which uses a real communication control device of a type of vehicle or of a vehicle type and on a processing by a central computing system which is also used for productive operation. Only the vehicle and the data sink are imitated by simulation units in one or more test computing units.

[0052] The test data is sent to the central computing system via a real wireless communication connection by periodically generating random data on the vehicle side. The test data which is generated and processed as status data can then be intercepted at defined points and compared with the generated or emitted test data. Access to the central computing system is achieved via a real interface via which also customers of the vehicle access the central computing system 40.

[0053] List of reference signs

[0054] 10 test computing unit

[0055] 11 first simulation unit for simulating a set of vehicle data sources

[0056] 12 vehicle bus

[0057] 15 second simulation unit for simulating a data sink

[0058] 16 network connection (wired or wireless)

[0059] 20 database

[0060] 30 communication control device

[0061] 31 computing unit

[0062] 32 sending / receiving unit (antenna, amplifier)

[0063] 33 wireless communication connection

[0064] 40 central computing system (backend)

[0065] 41 computing unit

[0066] 42 database

[0067] 43 sending / receiving unit (antenna, amplifier)

[0068] 44 sending / receiving unit (antenna or interface, amplifier)

[0069] 50 network

[0070] 51 wireless or wired communication connection

[0071] SD status data

[0072] VIN unique test vehicle identification (vehicle identification number)

[0073] TD test data

[0074] DBT database table

[0075] TS time stamp

[0076] SZi status of the i-th data source (i = 1... n, where n > 1)

[0077] FM error message

[0078] TRT test run table

[0079] CONS consistency between sent and received data

[0080] FTP error type

[0081] AF query message

[0082] AW response message

Claims

1. A method for computer-supported monitoring of the operation of a vehicle service, the vehicle service comprising interaction between a vehicle, a central computing system (40) for productive operation, and a data sink associated with the vehicle via a unique vehicle identifier, such that vehicle status data is transmitted from a communication control device (30) within the vehicle to the central computing system (40) at periodic time intervals, and the central computing system (40) stores the last transmitted status data for subsequent retrieval and processing via the data sink, wherein, a) Provide a communication control device (30) for a vehicle of the following type or vehicle type in the test environment, and monitor vehicle services for the vehicle or vehicle type; b) The vehicle is simulated by the first simulation unit (11) in such a way that test data is generated by the first simulation unit and the test data is provided as status data on the vehicle bus (12) to the communication control device (30). The communication control device (30) transmits the test data as status data together with the test vehicle identifier to the central computing system (40) and stores it in the first database (42) of the central computing system (40). The status data, timestamp and test vehicle identifier form a test data group. The first database (42) contains the test data group and the data group of the real vehicle. c) The data sink is simulated by the second simulation unit (15) in such a way that the state data stored for the simulated vehicle is retrieved from the central computing system (40) for production operation, wherein the simulated data sink is matched with the simulated vehicle via a unique test vehicle identifier, wherein a query message is transmitted from the second simulation unit (15) to the central computing system (40), the query message containing the test vehicle identifier and authentication, the information contained in the query message is received and processed by the central computing system (40) and, in the case of affirmative authentication, a response message is transmitted from the central computing system (40) to the second simulation unit (15). d) Evaluate the test data generated by the first simulation unit (11) and the state data invoked by the second simulation unit (15) by comparing consistency.

2. The method according to claim 1, wherein, The implementation of steps b) and c) forms a test run, which is evaluated by comparison in step d) after multiple test runs.

3. The method according to claim 2, wherein, The evaluation only processes test runs where the comparison between the test data and the state data of the corresponding test run is distinct.

4. The method according to claim 2 or 3, wherein, In the evaluation of differentiated test runs, the location or component causing the error is inferred from the frequency of error types.

5. The method according to any one of claims 1 to 3, wherein, The test data includes the corresponding status of a set of data sources.

6. The method according to claim 5, wherein, The set of data sources includes a flip sensor, a window sensor, a tire pressure sensor, a level sensor, and fault memory records.

7. The method according to any one of claims 1 to 3, wherein, The test data is generated randomly by the first simulation unit (11).

8. The method according to claim 5, wherein, The corresponding states of the data sources are randomly generated by the first simulation unit (11).

9. The method according to any one of claims 1 to 3, wherein, Test data is generated periodically and provided as status data to the communication control device (30).

10. The method according to any one of claims 1 to 3, wherein, The test data set in the first database (42) includes error messages that indicate whether an error has been identified within the processing of the central computing system (40) and what kind of error has been identified.

11. The method according to any one of claims 1 to 3, wherein, The test data generated by the first simulation unit (11) and the status data called by the second simulation unit (15) are written into a common test run table in the second database (20) in a matching format.

12. The method according to any one of claims 1 to 3, wherein, The first simulation unit (11) transmits the status data to the central computing system (40) via a wireless communication connection (33).

13. The method according to any one of claims 1 to 3, wherein, The second analog unit (15) retrieves status data from the central computing system (40) via a wireless or wired communication connection (16, 51).

14. An apparatus for computer-supported monitoring of the operation of a vehicle service, the vehicle service including interaction with a vehicle, a central computing system (40) for productive operation, and a data sink associated with the vehicle via a unique vehicle identifier, such that vehicle status data is transmitted from a communication control device (30) within the vehicle to the central computing system (40) at periodic time intervals, and the central computing system (40) stores the last transmitted status data for subsequent retrieval and processing via the data sink, the apparatus comprising: - A communication control device (30) for a vehicle of the following type or vehicle type shall monitor vehicle services for the vehicle or vehicle type; as well as - Test calculation unit (10), the test calculation unit is configured to perform the following steps: b) The vehicle is simulated by the first simulation unit (11) in such a way that test data is generated by the first simulation unit and the test data is provided as status data on the vehicle bus (12) to the communication control device (30). The communication control device (30) transmits the test data as status data together with the test vehicle identifier to the central computing system (40) and stores it in the first database (42) of the central computing system (40). The status data, timestamp and test vehicle identifier form a test data group. The first database (42) contains the test data group and the data group of the real vehicle. c) The data sink is simulated by the second simulation unit (15) in such a way that the state data stored for the simulated vehicle is retrieved from the central computing system (40) for production operation, wherein the simulated data sink is matched with the simulated vehicle via a unique test vehicle identifier, wherein a query message is transmitted from the second simulation unit (15) to the central computing system (40), the query message containing the test vehicle identifier and authentication, the information contained in the query message is received and processed by the central computing system (40) and, in the case of positive authentication, a response message is transmitted from the central computing system (40) to the second simulation unit (15). d) Evaluate the test data generated by the first simulation unit (11) and the state data invoked by the second simulation unit (15) by comparing consistency.

15. The apparatus according to claim 14, wherein, The test calculation unit (10) is also configured to implement the steps of the method according to any one of claims 2 to 13.

16. A computer program product comprising program code stored on a non-volatile, machine-readable medium for carrying out the method according to any one of claims 1 to 13 when the program code is executed on a computer.

Images