# Emerging Technologies for Advanced Power Electronics and Machine Design in Electric Drives
## 5 Tools for Electric Drive Design
### Software Design  
The first approaches to developing motor control software were completely customized. Through software reuse, MCU manufacturers soon began to offer software libraries that implemented specific blocks of motor control software (PID, SVM, Park and Clarke transforms, etc.). This naturally led to the availability of complete motor control software solutions (FOC, BLDC, etc.). The increase in available computational power even made it possible for complex solutions to become widely available (observers, sensorless control, etc.). Although the C programming language is the lingua franca for motor control software, recent code generation improvements have made graphical programming solutions (e.g., Simulink) a viable option. Such an approach was initially only an option for research and development, since only the powerful development hardware (dSpace, Typhoon, Speedgoat, etc.) could handle the computation overhead [224]. The code generation improvements and the increase in computational power, however, made it possible to use code generation tools even for MCUs used in multiphase drive solutions [225]. It has to be noted that when an application requires fault tolerance, modifications are needed not only in the power stage topology and/or machine design, but also in the control system. Most solutions involve the implementation of reconfigurable control systems, where a single control topology operates during normal conditions [226]. In the event of a fault, once detected, the control system switches to a different topology. Since each type of fault requires a specific control system topology, designing a fault-tolerant control system significantly increases the complexity and effort required for software implementation. Often these systems require additional physical or virtual sensors, enabling implementation of real-time observers or digital twins for monitoring the operating state for fault-detection and for post-fault operation [85; 227; 228]. Solutions with parallel power stages offer a more resilient design, where fault tolerance can be achieved through hardware design. In such cases, the same control system can be used both during normal and post-fault operation [76]. The increased complexity of multilevel/multiphase systems on the hardware and software side extends the development time, including the time-to-market, which consequently becomes one of the main competitive disadvantages. Several concepts and tools have been developed to shorten the design process (Figure 16) [229]. Nowadays, design engineers can test the behavior of the proposed topology or control system through computer simulations. The process is usually referred to as model in the loop (MIL). Here, the control or signal processing algorithm and the plant itself are simulated on the same mainframe computer, and there is no interface between the controller and the plant. To further test the final version of the software, the concept of software in the loop (SIL) is used. In this case, the algorithm is written in its final form (C-functions, etc.) to be implemented on the target processor and compiled with the compiler of the host processor. However, the executable code is tested on the same computer as the rest of the simulations, and the controller and the plant are only connected via a software interface. With processor in the loop (PIL), the algorithm code is executed on the target processor, while the rest of the simulations are executed on a personal computer (PC). The controller and the plant are connected via a type of communication interface. With the hardware in the loop (HIL) approach, the software is executed on the target processor while the rest of the system is emulated. The interface between two systems is at the signal level. To test the entire system, which consists of software, signal and power electronics, under controlled conditions, the power hardware in the loop (PHIL) approach offers much better flexibility than testing in the target application [230; 231].