## 3 Materials and Methods
### Preliminary Considerations and Limit Exchange State  
The clarification of the capability of the test benches in advance is important. Forbidden operating points must therefore be identified and recorded as part of the preliminary considerations. These limits depend on the specific test bench hardware. For example, the speed control of the load machine of the test bench (asynchronous machine) is not fast enough to counter the much faster torque control of the device under test (permanently excited synchronous machine) at very low speeds (approx. 0 to 50 min\({}^{-1}\)) with enough torque to keep the speed at the defined value. In the worst case, oscillations occur in the control of the load machine, which can lead to a shutdown of the test bench. From the DCP specification, the state CONFIGURATION is defined. In this state, the master has taken control of the slave. At this point, the introduction of a new \"Limit Exchange\" sub-state has also proved useful. The test benches can exchange their respective limits, such as the maximum possible speed or temperatures, and check whether a test is possible. This prevents errors caused by wrong limits before the test even starts, and saves time due to the avoidance of possibly lengthy thermal component conditioning to a wrong initial temperature. This step can be carried out as a safety state in addition to the indispensable preliminary considerations already described. Extension of the PREPARING State  
According to the DCP specification, after successful configuration, the slave should initiate the transport protocol and thus allow for data exchange. Since the original use of DCP is for coupling software and simulation models, various transport protocols can be used for further communication. In the case of hardware coupling of test benches, however, this flexibility offers no advantage. Hardware coupled test benches require the communication and data exchange to be integrated in the TCU software. However, the availability of various data exchange protocols and the existing test bench systems compatibility cannot be assumed. Additionally, the interfaces are often already required upon start-up of the test bench, meaning that the interfaces are already in use when the DCP master or slave is started. In the case of the coupled test benches example, the state is already fulfilled when specifying its requirements strictly according to DCP. When coupling with a test bench, checking the test bench and components operational availability is advisable. This extends the PREPARING state, or can be implemented by using a \"test bench preparation\" sub-state. Within this sub-state, a check is performed whether the DUT of the respective test bench is ready and can be operated. In the case of an ICE, checks are, for example:  
* Fuel pump running and fuel present;
* Temperature control units switched on and coolant levels OK;
* Data acquisition devices enabled and ready for operation;
* No errors in the error memory;
* Operating mode remote control DCP selected. With an EM, checks are, for example:  
* Battery emulator running;
* Temperature control units switched on;
* Data acquisition devices enabled and ready for operation;
* No errors in the error memory;
* Operating mode remote control DCP selected. In summary, this sub-state checks whether all subsystems within the test bench environment are functioning and prepared for operation. If all aforementioned conditions are fulfilled, this is transferred to the DCP state machine via an internal signal of the TCU. Extension of DCP CONFIGURING State  
When using connectionless communication, as in the case of the coupling example via the UDP protocol, no specific actions are necessary at this point according to the DCP specification. In the case of hardware and test bench coupling, additional functionality is implemented at this point which deviates to the specification. Particularly in the case of thermal tests, very time-consuming thermal conditioning of the test items is sometimes necessary.