The optimal time to detect faults is early in the development process. With the Unified Modeling Language (UML), faults can even be found during analysis and design. However, software integration and testing are challenging, especially for embedded systems due to limited inputs and outputs, resulting in limited operability and visibility. Anomalous system states are particularly difficult to test because the system must be brought into a given state before its behavior can be determined. This paper proposes injecting instrumentation code into the UML model implementation to improve system controllability, observability, and testability. Instrumentation can be applied in both development and target environments and allows for interactive system debugging at the model level. In batch mode, instrumentation forms the basis for data acquisition, initialization, and test automation. This paper aims to: briefly introduce model-based software engineering and the implementation of these models; outline model-based software integration testing methods; identify important runtime data and execution critical points within the model system; describe several schemes for acquiring and manipulating model data at runtime; and enable instrumentation to perform tests automatically. Software faults refer to erroneous instructions or calculations in a program; the execution of software faults leads to errors in the software state. A failure occurs when an error propagates to the output and appears as an abnormal result outside the system. Program controllability refers to the ability of a test system to force the program under test to follow a specific execution path, although it is also possible for errors to occur along this path. Program observability refers to the ability of the test system to detect erroneous states and pinpoint the location of the failure. The internal state of the system is crucial for determining the correctness of the test. The output of the system is determined by its initial state and its inputs. Systems with different initial states will produce different outputs even with the same inputs. The final state of the system must also be considered as part of the test correctness assessment, because an incorrect internal state will eventually propagate to the system's output and cause errors. The complexity of the system also makes predicting the correct output increasingly difficult. Initial state + input —-> Final state + output In "black box" testing methods, only the system's external inputs and outputs are known. A special test stimulus sequence is needed to propagate the error to the output in order to distinguish between erroneous and correct programs. The longer the required special sequence, the lower the testability of the program. Similar to "black box" testing, embedded systems also have lower controllability and observability. Evaluating the final internal state of the system can shorten the specific input sequence required to detect errors, resulting in smaller, more manageable test cases. Test instruments aim to simultaneously improve the controllability and observability of software programs to obtain more testable programs. The technique of using test support instruments in application code is a "glass box" testing approach. When developing a system's UML model, developers must understand the tasks the system will perform. Error isolation strategies based on test instruments can apply the knowledge of the UML model to integration testing. The operation and state of a system are more visible at the analysis level than at the coding level because the latter is affected by implementation details. Setting the initial system state for testing from only external inputs requires a specific sequence of external stimuli. System operation under abnormal states is critical for verification in many embedded applications, but generating these initial states is not straightforward. The techniques described in this paper can significantly improve controllability and observability using test methods. Integration Testing Steps Integration testing can be divided into two important phases: dynamic verification and target integration. Dynamic verification involves running the UML model in the development environment to determine the model's correctness. Target integration involves integrating the software and hardware in the target environment. Both dynamic verification and target integration are performed at the analysis level, using the same tools: test support instruments. Dynamic verification testing is performed as much as possible for several reasons: hardware availability, hardware/software separation, shorter debugging cycles, and tool availability. If the model is confirmed to be problem-free after dynamic verification testing, target integration debugging can focus on interfaces between system components or platform-specific issues. a. Building Embedded System Models with UML Effectively using UML models in embedded application software engineering requires the development process to ensure: the model is rigorous and complete; the resulting system implementation is optimized without affecting the model; and the overall system architecture is maintained by the process through multiple version and requirement upgrades. To achieve these goals, model-based software engineering employs a transformation method, focusing on adding test support to the code, but this technique can also be applied to manually implemented UML models. The characteristics of this transformation method will be described below. b. Analyzing Models Analysis is the process of creating implementation-independent model solutions for the problem itself. An effective analytical model is rigorous and complete, and implementation-independent. UML is a standard notation defined by OMG, primarily used for expressing analytical modeling. The analysis process can generate: Domain Model: This is a UML class diagram that decomposes the system into independent thematic areas called domains. These domains are represented by packages and subordinate arrows, which represent the flow of requirements between domains. Domains can be analyzed or developed using other methods, such as manually written code, inherited code, generated from other sources, imported from a library, etc. Domain services are methods that make up the domain interface. Because a domain defines a complete specification for a problem area, it can be tested independently and then combined with other domains for further testing. Information Model: For each domain to be analyzed, a UML class diagram can be used to define the classes that make up the domain structure. Classes are interconnected and can inherit from other classes. Scenario Model: UML sequence lists or UML collaboration diagrams capture the main scenarios of a specific domain, used to represent the interactions between domain services (operations), class services (methods), class event messages, and external services referenced by that domain. State Model: For each class that receives event messages, a UML state diagram can be used to capture the class lifecycle and define the class's state-related characteristics. Behavioral Model: For each domain service, class service, and state behavior, a detailed and explicit behavioral description is generated. This is expressed using a behavioral language, an analysis-level "programming" language that provides complete analysis-level execution primitives without affecting the implementation. Representing behavioral details using a behavioral language allows for significant freedom before the transformation phase of implementing the analysis primitives, which is crucial for optimization. c. Design: Design is the process of generating strategies and mechanisms that map the analysis constructs to the runtime environment. Its concept differs from analysis; much of the preliminary design work can be done independently of the analysis activities. d. Transformation: Transformation is the process of mapping the UML model of each domain to be analyzed to the implementation using design strategies. Design is carried out in two phases: Structural Design: Identifying the system's execution units (threads/tasks/processes), assigning them to processors, and assigning domains to units. Mechanical Design: Developing detailed patterns (described using templates) that map the analysis to the implementation and establishing basic mechanisms to support this implementation.