Due to the constantly increasing number of functions offered by a modern vehicle, the complexity of vehicle development is also increasing as a result. A first indication of this connection is provided by the number of ECUs (electronic control units) used in current development vehicles. Furthermore, each ECU also performs more functions and is not only electrically networked with the other ECUs, but also logically and functionally. On this basis, new cooperative functions are being developed, which are used for example for autonomous driving. In vehicle development, more and more test sequences (diagnostic scripts) are established for function testing of individual components, systems and cross-functional methods. Due to decentralization and the modular approach, modern development vehicles consist of different numbers of ECUs. The high number of ECUs in purpose and number poses a challenge for test creation and updating. The ECU software is also developed in cycles within the vehicle cycle. This results in a very high software variance. This variance leads to the fact that in the vehicle development with global test conditions works. Global test conditions at this point mean that more ECUs are included in the measurement procedure than are installed in the vehicle. The vehicle structure (control unit and its software version) is not known to the person performing the measurement. He relies on the fact that his ECUs are inside in the global measurement task. This means that the vehicle network architecture is uncertain, which can lead to errors during test execution. Since the ECUs that are actually installed in the vehicle are first determined during test execution, this results in a longer script runtime than would be necessary. To support the development engineer and prevent avoidable errors, the diagnostic system should configure itself as far as possible. This means that individually customized measurements for each vehicle should be calculated in the cloud and not the global measurement tasks. For a diagnostic system to be able to configure itself independently, the vehicle network structure must be determined in a first step. This can be done by a simple CAN measurement (measurementXY.asc). An AI is able to analyze this measurement and classify the occurring ECUs as well as CAN networks. For larger measuring devices with more than one CAN interface, the user who analyzes the measurement is interested in which CAN was connected. Here, the AI is suitable to determine the name of the network and the communicating ECUs based on the communication that runs over the bus. For this purpose, the AI classifies the number of communicating ECUs based on the time intervals at which messages are sent. In addition, the AI can be supported by a special diagnostic script (global.pattern) to determine the vehicle structure at the OBD (on-board diagnostics) interface with maximum accuracy. Three AI approaches are presented, all connected in series and passing results to each other (pipeline mode). First comes the AI that separates vehicle communication from diagnostic communication. Based on the vehicle communication, the network name can be determined. Based on the diagnostic messages, the ECUs can be determined.