Abstract: Modeling embedded systems using UML accurately achieves consistency between analysts and users at the formal level, establishes clear program structures and behavioral guidelines for developers, significantly shortens system development cycles, and makes system upgrades and reuse possible. This paper illustrates the application of UML in the analysis and design of embedded systems through a simple variable frequency speed controller system implemented using an Atmel 89C52 microcontroller. 1. Overview With the development of China's equipment manufacturing industry, embedded systems have become a core technology in manufacturing. They are widely used in numerous fields such as industrial control, simulation systems, medical instruments, information appliances, and communication equipment. Currently, research and development around embedded systems has become one of the most active directions in the development of computer software and hardware technology. Embedded systems differ from purely software or hardware systems; they integrate software and hardware. Some functions can be implemented using either software or hardware. Furthermore, the challenges of embedded system design involve not only computer software and hardware but also many non-computer engineering issues, such as mechanical size, power consumption, and manufacturing cost. Even within computer engineering, most systems have specific requirements regarding real-time performance, reliability, and multi-rate capabilities. Currently, the main hardware methods for implementing embedded systems are: ASIC (Integrated Application Logic), FPGA (Field-Programmable Gate Array), and embedded microprocessors. In practical system implementation, the vast majority of systems use embedded microprocessors, such as microcontrollers, single-board computers, or embedded microprocessor chips. This is because implementing embedded systems using microprocessors is a highly effective method, enabling the design of product lines with different features at different price points and allowing for the addition of new features to meet rapidly evolving market demands. 2. Problems and Solutions in Embedded System Design In the past, the main problems in embedded system analysis and design were: ① Lack of a unified standard for analysis and design; ② Inconsistent analysis and design methodologies; ③ Lack of a consistent engineering approach from analysis and design to manufacturing and programming, resulting in significant human influence at every stage of product development; ④ The inability to reuse the results of analysis and design in developing similar projects or products. These four issues have been the main bottlenecks restricting the development of embedded systems for many years, leading most organizations and groups engaged in embedded system application development to operate primarily in small groups or even workshop-style operations. This makes developing complex or large systems extremely difficult or even impossible, or leads to project failure due to constantly changing system requirements or team member turnover. We know that for humans to communicate about any event, the prerequisite is to standardize the form (or manifestation) and behavior of that thing. Only after standardization can the storage, processing, and communication of that thing be achieved. The main reason for the above four problems in the embedded system manufacturing process is the lack of a unified engineering description method for the structural and industry characteristics of the embedded system's requirements, analysis, design, manufacturing, testing, and maintenance processes. Currently, object-oriented technology is based on abstract thinking about the real world, and the Unified Modeling Language (UML) provides a visualization tool for this thinking, solving the above problems. Using UML to model embedded systems not only standardizes system analysis and design but also allows system analysis, design, manufacturing, and testing to be completed by different project members in a unified and consistent manner. It also makes it possible to reuse system analysis and design models in similar systems. 3. System Modeling Object-oriented embedded system modeling, like any software-intensive system modeling, begins with class modeling within the system. To understand the structure of the classes, a general description of the system's working process is first given. Whether using the problem space vocabulary abstraction method or the use case-driven modeling method, the goal is to find the class diagram of the system, with classes or objects as building blocks. If using a use case-driven system analysis method, this can also be modeled and specified using use case views, which can then be used as the basis for white-box testing. Since the specification using use case views is quite lengthy, this article only describes this part in text. The system exemplified in this article is a small variable frequency drive system. For any three-phase AC motor, with a single-phase AC power input, it achieves steady start-up and operation at any frequency within the range of 6Hz to [9Hz, 50Hz]. The system user interface includes a 2-digit display, a run/stop indicator, a power on/off indicator, a 6-button keypad, and a power switch. The 2-digit display shows the current operating frequency of the motor, and the 6 buttons represent start, stop, forward jog, reverse jog, frequency increase, and frequency decrease, respectively. The start command steadily increases the motor's frequency from 6Hz to the currently set frequency in steps of 0.2Hz, and then stabilizes it at that frequency. The forward jog command stabilizes the motor at 6Hz in the forward direction. The reverse jog command makes the motor rotate at the same frequency as the forward jog command, but in the opposite direction. The frequency increase command increases the motor's operating frequency and the current preset frequency at a rate of 1Hz/s while the motor is running, and only changes the preset frequency when the motor stops. The frequency decrease command is the opposite of the frequency increase command. The stop command stops the motor regardless of its operating state. As shown in Figure 1, there are two hardware classes, Button* and Light*, one active class, Microcontroller, and three general classes, Converter, Watchdog, and Display. The Button* class represents all buttons; the Light* class represents two LED displays and one running indicator light; the active class Microcontroller is the system's main control module, responsible for scheduling and managing all objects; the three general classes are three functionally independent program modules. [align=center][img=497,127]http://www.e-works.net.cn/images/127904195096718750.GIF[/img] Figure 1: Class Diagram of Variable Frequency Speed ​​Control System[/align] Figure 2: System Implementation Diagram. The microprocessor node is the main control node of the system, using an Atmel 89C52. Its internal 8KB Flash ROM and 128B RAM resources are sufficient for the system requirements, so no additional external memory is needed. Connections with other nodes can be completed entirely through its own serial-parallel interfaces. The button node represents all buttons, which can also be replaced by a keyboard when the system changes; in this example, there are 6 individual mechanical buttons. The display node represents the system display section; in this example, there are 2 digital tubes and 1 LED indicating the operating status of the circuit. The operation monitoring node has two functions: one is to monitor the operating status of the microprocessor through WatchDog technology, and the other is to monitor the pulse width of the converter output. The converter, designed as a dedicated circuit, receives three-phase sinusoidal pulses through the microprocessor's parallel port and converts them into the pulse voltage required by the motor coils of each phase according to the motor power. The three-phase motor nodes are not part of the embedded system itself, but are arranged in the same implementation diagram to illustrate the relationship between this embedded system and the controlled object. [align=center][img=500,125]http://www.e-works.net.cn/images/127904195276875000.GIF[/img] Figure 2 Implementation diagram of the variable frequency speed control system[/align] Figure 3 shows the finite state machine behavior model of the system. After the system is powered on, it automatically enters a waiting state after initialization. In the waiting state, the Microcontroller object schedules the corresponding operation objects according to the user's keyboard button commands. When the user issues a forward or reverse jog command, the system enters the jog running state, at which time the Converter object outputs 6Hz forward or reverse phase sequence three-phase pulses. When the user releases the forward or reverse jog button, the system returns to the waiting state. When the system's preset frequency is correctly set, the system enters the startup running state when the user presses the start button. In this state, the system steadily increases the motor operating frequency from 6Hz in steps of 0.2Hz until the preset frequency is reached, at which point it enters the stable running state. In the stable running state, the user can change the preset frequency in 1Hz steps. Each change of the preset frequency will cause an alternating transition from the stable running state to the startup running state. When a fault occurs during system operation, it enters the fault handling state for processing, and automatically returns to the waiting state after completion. [align=center][img=500,250]http://www.e-works.net.cn/images/127904195474687500.GIF[/img] Figure 3: Variable Frequency Speed ​​Control System State Diagram[/align] 4. System Implementation 4.1 Data Processing Since the system described in this paper is a small-scale variable frequency speed control embedded system, all three-phase sinusoidal PWM pulses are output from the P1.0 to P1.5 ports of the Atmel 89C52. When any frequency sinusoidal waveform is decomposed into N equal parts (N is an integer multiple of 6), it is equivalent to N rectangular pulses of equal amplitude but unequal width, as shown in Figure 4. Each frequency sinusoidal wave is divided into 6 phase sequences, each phase sequence being 60°. Each phase sequence is divided into N/6 intervals, and each interval is divided into 7 sub-intervals. Each interval uses a centrally symmetrical pulse waveform, so only one phase power drive switch commutates at the edge of each sub-pulse, thus balancing the change in drive power supply current. During any phase commutation, dead-time protection is automatically added by the software (the dead time is when the upper and lower arm switches of one phase are simultaneously closed, as shown in the part between the vertical double lines in Figure 4), to prevent the power drive switch from simultaneously conducting at the moment of commutation and damaging components. [align=center][img=500,267]http://www.e-works.net.cn/images/127904195634218750.GIF[/img] Figure 4 A small interval of a three-phase sine wave[/align] Although the number of pulse intervals and duty cycles within each phase sequence differ for different frequencies, the output waveform is the same. Furthermore, because the waveforms of the seven small intervals within each interval are centrally symmetrical, when outputting the last three small waveforms, it is sufficient to simply reverse the duty cycles and output waveform data of the first three small waveforms. Additionally, each pulse interval only requires four duty cycle timing intervals T, t2, t3, and t4 (see the next section for explanation), and each phase sequence only requires four pulse waveform data points. The data relationship of the three-phase sine wave intervals is shown in Table 1. [align=center]Table 1 Three-phase sine wave interval data relationship[img=500,184]http://www.e-works.net.cn/images/127904195825156250.gif[/img][/align] 4.2 System Resource Configuration When the system analysis and design adopts the object-oriented method, it does not mean that the programming language used must also be object-oriented. In fact, the specific implementation of this analysis and design method can use any programming language (such as assembly language or C language); however, in program design, object-oriented ideas should be used as much as possible, such as reflecting the encapsulation of program structure and message passing. This will make the program structure clear and facilitate the continuous updates and system maintenance caused by changes in requirements. In implementing this system, the most important resources are program memory and timers. Due to the use of the data processing technology discussed in the previous section, the data space is greatly compressed. In implementation, the 6Hz–50Hz frequency space is divided into 7 large segments, with each segment having a pulse period of approximately 900μs. The segment period timing utilizes the microcontroller's internal T2 timer's constant auto-reload method. Since the relationship between the segment period and the output frequency is fixed (T segment = 1/Nf frequency), the on-chip T0 timer is used for timing the smaller segments t2, t3, and t4 within each segment, while t1 timing is calculated as t1 = T segment - 2 × t2 - 2 × t3 - t4. The T1 timer monitors the pulse width of the system output. When the pulse width output from any end of port P1 exceeds 1000μs, the system enters a fault handling state via an interrupt. Additionally, the system includes a WatchDog circuit X5045 to monitor the system program's execution. When the program malfunctions, the system enters a fault handling state via a reset. The system's display interface is implemented through the microcontroller's serial interface. 5. Discussion Since the implementation tools for embedded systems are mostly non-object-oriented, how to bridge the gap between object-oriented analysis and design and non-object-oriented implementation tools becomes a worthwhile topic to explore. Furthermore, embedded systems generally have specific requirements different from those of large software systems, such as real-time performance, reliability, mechanical size, and energy consumption (e.g., battery power) requirements. Therefore, special handling based on the developer's experience is necessary during system implementation. However, adopting an object-oriented modeling approach before system implementation establishes a visual organizational and industry structure for the system, enabling a visual representation of user requirements, shortening the system development cycle, and effectively adapting to changes in user needs.