Method for switching virtualization instances based on transition profiles and apparatus therefor

Abstract

An apparatus and method for switching virtualization instances based on a switching profile are disclosed. An apparatus and method for switching virtualization instances according to one embodiment determine a device-specific migration method based on a switching profile collected from a current instance, and switch virtualization instances while maintaining service continuity by selectively reflecting or initializing the device state in a subsequent instance according to the determined method.

Description

Technology Field

[0001] The present invention relates to a virtualization instance switching technology, and more specifically, to a virtualization instance switching device and method that switches to a successor instance based on new firmware while selectively inheriting the state of each device based on a switching profile. Background Technology

[0002] Virtualization technology is widely used to ensure efficient utilization of system resources, enhance service flexibility, and facilitate maintenance by enabling the separation and operation of multiple execution environments on a single host. In particular, as the application of virtualization technology expands in embedded systems, industrial control systems, and operational technology (OT) environments, the importance of virtualization environment transition technology is growing in order to ensure security while minimizing interruptions to running services.

[0003] Meanwhile, the recent security paradigm is shifting from static boundary-centric defense to asset and resource-centric, continuous verification-based dynamic defense technologies. Consequently, there is an increasing need for firmware updates to address changes in trust standards or security vulnerabilities even during system operation. In particular, since attacks or security issues targeting the firmware layer can render the system inoperable for extended periods, there is a demand for technologies that can rapidly and safely transition existing firmware to new firmware.

[0004] However, while conventional firmware update methods based on rebooting or full restarts are relatively simple to implement, they have limitations in that services are completely interrupted during the update process, and device state, session information, buffer data, and execution flow are all initialized. This approach can act as a significant operational constraint in embedded environments or industrial systems where real-time performance, reliability, and safety are required simultaneously.

[0005] Furthermore, since general virtualization migration techniques focus on transferring the state of a running instance to a different execution environment, they are based on a structure that preserves the existing state as much as possible. Consequently, relying solely on a method that transfers the execution environment including the existing firmware state makes it difficult to sufficiently resolve the issue of directly launching a subsequent instance with the new firmware applied and selectively applying only the state necessary for that subsequent instance.

[0006] In particular, even when running a subsequent instance based on new firmware on the same host, it is difficult to simultaneously ensure service continuity and transition stability unless criteria are established for determining which device states can be reflected as is, which states should be reflected only partially, or which states should be discarded and re-initialized. For example, the scope of reflection and the method of initialization in the subsequent instance need to vary depending on the configuration state of the communication device, unprocessed data, interrupt state, or recent activity history. Prior art literature

[65535] Registered Patent Publication No. 10-1881625 (August 24, 2018) The problem to be solved

[0007] The present invention aims to provide a switching profile-based virtualization instance switching device and method that, in the process of switching to a subsequent instance based on new firmware, selectively determines the scope of state reflection based on device-specific state characteristics and compatibility with the new firmware, rather than uniformly transferring or discarding the device state of the current instance, and thereby controls whether to perform a reset or initialization. means of solving the problem

[0008] A virtualization instance switching device according to one embodiment includes: a switching profile collection unit that collects a switching profile containing state information for one or more devices controlled in a current instance; a migration determination unit that determines a migration method to be applied to each device based on the switching profile; a virtualization environment control unit that drives a subsequent instance based on new firmware according to the determined migration method; a state injection unit that selectively reflects at least a portion of the device-specific state information collected from the current instance to the subsequent instance according to the migration method; and a reset control unit that controls whether to perform a reset or initialization routine for each device according to the migration method.

[0009] The migration decision unit above can determine different migration methods for each of the one or more devices.

[0010] The above migration method may include a full migration that reflects the device state to the subsequent instance, a partial migration that reflects a part of the device state to the subsequent instance, and a disposal and initialization that initializes the device in the subsequent instance without reflecting the device state.

[0011] The above transition profile may include at least one of device identification information, configuration status, buffer status, event status, and activity status.

[0012] The above-described transition profile collection unit can generate the transition profile by collecting device register access information, input / output information for the device's internal buffer or queue, interrupt or event information, and time-based activity information.

[0013] One or more of the above devices may include a serial communication interface device.

[0014] The above serial communication interface device may include at least one of a UART device, an I2C device, and an SPI device.

[0015] The migration decision unit above can determine the entire migration if there is residual data in the device or if there is an ongoing event.

[0016] The migration decision unit above can determine the partial migration when there is no remaining data or ongoing events in the device and when it is necessary to maintain the device configuration state.

[0017] The migration decision unit above can determine the disposal and initialization when there is no residual data or ongoing events in the device, the device is in an idle state, and maintaining the device configuration state is not required.

[0018] The state injection unit and the reset control unit may reflect the configuration state, residual data, and event state of the device to the subsequent instance and suppress the device reset when the full migration is determined, reflect the configuration state of the device to the subsequent instance and suppress the device reset when the partial migration is determined, and allow the device reset and initialization without performing state reflection when the disposal and initialization are determined.

[0019] A virtualization instance switching method performed by a virtualization instance switching device according to another embodiment comprises: collecting a switching profile including state information for one or more devices controlled in a current instance; determining a migration method to be applied to each device based on the switching profile; driving a subsequent instance based on new firmware according to the determined migration method; selectively reflecting at least a portion of the device-specific state information collected in the current instance according to the migration method to the subsequent instance; and controlling whether to perform a reset or initialization routine for each device according to the migration method. Effects of the invention

[0020] According to the present invention, by analyzing the state of each device based on a transition profile and determining a migration method suitable for each device, the continuity of the running service can be effectively maintained during the transition to a subsequent instance based on new firmware. In particular, rather than uniformly replicating the entire existing execution state or, conversely, discarding it all, only the necessary state is selectively reflected according to the state characteristics of each device, thereby reducing unnecessary interruptions that may occur during the transition process while increasing transition accuracy.

[0021] Furthermore, according to the present invention, device states can be collected and structured in forms such as configuration state, buffer state, event state, and activity state to be utilized as a basis for migration decisions; thus, unlike simple state storage or batch restoration methods, sophisticated transition control reflecting the execution context at the actual transition point is possible. Accordingly, by comprehensively considering the existence of unprocessed data, the existence of ongoing events, the necessity of maintaining device settings, and idle states, an appropriate method among full migration, partial migration, or disposal and initialization can be selected, thereby ensuring both transition stability and service continuity.

[0022] Furthermore, according to the present invention, when full migration is required, not only the register configuration status but also the remaining TX / RX data and event status can be reflected in the subsequent instance, thereby reducing data loss or processing omissions and mitigating the problem of the logical flow of communication procedures being interrupted midway. Conversely, when partial migration is required, configuration inconsistencies with external communication partners can be prevented by reflecting only the device configuration status, and simplicity and stability can be ensured by omitting the reflection of status and re-initializing in a new environment when disposal and initialization are appropriate. In other words, since the present invention allows for the application of different transition policies depending on the nature of the device status, it is possible to perform transitions optimized for the characteristics of each device even within the same system.

[0023] In addition, according to the present invention, since the execution of a device reset or initialization routine after state injection can be controlled according to the migration method, the problem of already reflected state information being overwritten during a subsequent initialization process can be prevented. In particular, in full migration or partial migration paths, the inherited state can be maintained by suppressing the reset, and in the full migration path, the injected TX / RX data can be processed immediately, allowing the service flow performed in the current instance to continue more naturally. On the other hand, in the disposal and initialization path, the stable start state suitable for the new firmware environment can be secured by allowing the reset and basic initialization.

[0024] Furthermore, according to the present invention, since a subsequent instance based on new firmware can be directly started while selectively inheriting only the necessary state, it is possible to satisfy the often conflicting requirements of firmware updates for addressing security vulnerabilities and ensuring service continuity. In particular, in environments where the burden of rebooting or full restarts is significant, such as embedded systems, industrial control systems, and operational technology environments, this can be effectively utilized in terms of reducing transition time, ensuring communication continuity, preventing unnecessary state duplication, and supporting stable re-initialization.

[0025] Furthermore, according to the present invention, the transition profile collection unit, transition profile analysis unit, migration decision unit, virtualization environment control unit, state injection unit, and reset control unit are configured to be organically interconnected, thereby enabling the systematic execution of the entire procedure from the transition preparation stage to the startup of subsequent instances, state reflection, reset control, and service resumption. Accordingly, the transition judgment criteria and the actual transition execution procedure are consistently linked, and detailed transition policies based on the state of each device can be applied, thereby improving the reliability, predictability, and operational efficiency of the entire system. Brief explanation of the drawing

[0026] FIG. 1 is a block diagram showing the overall configuration of a virtualization instance switching device (100) according to one embodiment, FIG. 2 is a block diagram showing the configuration of a conversion profile collection unit (120) according to one embodiment, FIG. 3 is a conceptual diagram showing the data configuration of a conversion profile (150) according to one embodiment, FIG. 4 is a flowchart illustrating a migration method determination process according to one embodiment, FIG. 5 is a flowchart illustrating a subsequent instance switching process according to one embodiment, FIG. 6a is an example diagram of device processing according to a total migration according to one embodiment, FIG. 6b is an example diagram of device processing according to partial migration in one embodiment, FIG. 6c shows an example diagram of device processing according to disposal and initialization in one embodiment. Specific details for implementing the invention

[0027] The advantages and features of the present invention and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below but can be implemented in various different forms. These embodiments are provided merely to ensure that the disclosure of the present invention is complete and to fully inform those skilled in the art of the scope of the invention, and the present invention is defined only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same components.

[0028] In describing the embodiments of the present invention, if it is determined that a detailed description of known functions or configurations may unnecessarily obscure the essence of the invention, such detailed description will be omitted. Furthermore, the terms described below are defined considering the functions in the embodiments of the present invention, and these may vary depending on the intentions or conventions of the user or operator. Therefore, such definitions should be based on the content throughout this specification.

[0029] Additionally, each block or each step may represent a module, segment, or part of code containing one or more executable instructions for executing specific logical functions, and it should be noted that in some alternative embodiments, the functions mentioned in the blocks or steps may occur out of order. For example, two blocks or steps described in succession may actually be performed substantially simultaneously, and the blocks or steps may also be performed in the reverse order of the corresponding functions as needed.

[0030] Hereinafter, embodiments of the present invention will be described in detail with reference to the attached drawings. However, the embodiments of the present invention exemplified below may be modified in various different forms, and the scope of the present invention is not limited to the embodiments described below. The embodiments of the present invention are provided to more completely explain the present invention to those skilled in the art to which this invention pertains.

[0031] FIG. 1 is a block diagram showing the overall configuration of a virtualization instance switching device (100) according to one embodiment.

[0032] Referring to FIG. 1, a virtualization instance switching device (100) may include a current instance (110), a migration control unit (130), and a successor instance (140). The current instance (110) may be a virtualization environment that controls a hardware device (112) and performs services based on existing firmware (111), and the successor instance (140) may be a virtualization environment to be switched that operates based on new firmware (141). The migration control unit (130) may determine a device-specific migration method based on the switching profile (150) collected from the current instance (110) and the new firmware (141), and control the operation and state reflection of the successor instance (140) according to the result of the determination.

[0033] In one embodiment, the current instance (110) may include existing firmware (111), a hardware device (112), and a transition profile collection unit (120). The existing firmware (111) performs service logic currently being executed, and the hardware device (112) may include a serial communication interface device, a sensor interface device, or other input / output devices. The transition profile collection unit (120) may collect device-specific status information by monitoring device register access information, input / output information regarding the device's internal buffer or queue, interrupt or event information, and time-based activity information during the operation of the current instance (110). For example, the transition profile collection unit (120) may collect the device's configuration state, buffer state, event state, and activity state by performing hooking on trace information, interrupt request (IRQ) signals, and memory map input / output (MMIO) information occurring during the device access process, and generate this in the form of a transition profile (150). The generated transition profile (150) can be transferred to the migration control unit (130) at the time of transition to the subsequent instance (140).

[0034] In one embodiment, the migration control unit (130) may include a transition profile analysis unit (131), a migration decision unit (132), and a virtualization environment control unit (133). The transition profile analysis unit (131) receives a transition profile (150) transmitted from the transition profile collection unit (120) and can structure status information in the form of a file into device-specific status data. The migration decision unit (132) can analyze the structured status data to determine the migration method to be applied to each device. For example, the migration decision unit (132) can select one of full migration, partial migration, or disposal and initialization for each device. The virtualization environment control unit (133) can receive the decision result of the migration decision unit (132) and control the operation procedure of the subsequent instance (140). For example, the virtualization environment control unit (133) can control the subsequent instance (140) to be started without packaging the migration data or reflecting a separate status according to the determined method.

[0035] In one embodiment, the subsequent instance (140) may include new firmware (141), a state injection unit (142), a reset control unit (143), and a hardware device (144). The new firmware (141) may be a firmware image updated in response to security issues, and the hardware device (144) may be the same as or a corresponding device that was controlled in the current instance (110). The state injection unit (142) may reflect state information collected from the current instance (110) to the subsequent instance (140) according to a method determined by the migration control unit (130). For example, if full migration is determined, the state injection unit (142) may reflect the register configuration state, residual data in the TX / RX buffer, and the interrupt or completion event state, and if partial migration is determined, it may reflect only the device configuration state. On the other hand, if disposal and initialization are determined, the state injection unit (142) may not perform the state reflection procedure.

[0036] In one embodiment, the reset control unit (143) can control whether to execute a device initialization routine during the boot process of a subsequent instance (140). For example, if a full migration or a partial migration is determined, the reset control unit (143) can block or suppress the device reset immediately after state injection to prevent the injected state from being overwritten. Accordingly, the subsequent instance (140) can continue operation while maintaining the state inherited from the current instance (110). On the other hand, if disposal and initialization are determined, the reset control unit (143) can allow the device reset and basic initialization procedure so that the device is reconfigured according to the basic settings of the new firmware (141).

[0037] As illustrated in FIG. 1, the virtualization instance switching device (100) collects a switching profile (150) from the current instance (110), analyzes the switching profile (150) in the migration control unit (130) to determine a device-specific migration method, and then selectively reflects only the determined range of states to the subsequent instance (140), thereby maintaining service continuity while switching to a new firmware (141)-based virtualization environment. That is, the virtualization instance switching device (100) may be configured not to replicate and transfer the entire existing execution state, but to selectively inherit only the necessary states based on the compatibility of device-specific states and the execution state at the time of switching.

[0038] Additionally, the sequence shown in FIG. 1 is intended to illustrate an exemplary flow of transition profile collection, transition profile analysis, migration decision, subsequent instance drive, state injection, and reset control, and in an actual implementation, the order of some steps may be changed or two or more steps may be performed in parallel.

[0039] FIG. 2 is a block diagram showing the configuration of a conversion profile collection unit (120) according to one embodiment.

[0040] Referring to FIGS. 1 and 2, the transition profile collection unit (120) may be configured to collect device status information from a plurality of serial communication interface devices (160) controlled in the current instance (110) and to generate a transition profile (150) that is referenced when transitioning to a subsequent instance (140). In one embodiment, the serial communication interface devices (160) may include a Universal Asynchronous Receiver / Transmitter (UART) device (161), an Inter-Integrated Circuit (I2C) device (162), and a Serial Peripheral Interface (SPI) device (163).

[0041] In one embodiment, the transition profile collection unit (120) may include a register access tracking unit (121), an internal buffer / queue tracking unit (122), an IRQ / event tracking unit (123), a time-based statistics tracking unit (124), and a profile generation unit (125). Each tracking unit collects different state information of serial communication interface devices (160), and the profile generation unit (125) may structure the collected information into device-specific state data to generate a transition profile (150). In this way, the transition profile collection unit (120) may not merely read the current value of the device, but may also collect the device's configuration state, data retention state, event processing state, and recent activity history together, thereby supporting the determination of an appropriate migration method at the time of transition to a subsequent instance (140).

[0042] In one embodiment, the register access tracking unit (121) can track read and write access to the registers of the serial communication interface devices (160). For example, the register access tracking unit (121) can collect access information for the configuration register, control register, and status register using a callback function or a hooking technique. Through this, the register access tracking unit (121) can generate configuration status information such as whether the device is active, communication setting information, communication role information, whether interrupts are enabled, and flow control method. This information can be used to reconstruct the same or compatible communication conditions for a subsequent instance (140).

[0043] In one embodiment, the internal buffer / queue tracking unit (122) can track the status of the transmission buffer and reception buffer inside the device. For example, the internal buffer / queue tracking unit (122) can determine whether data received from the outside has not yet been processed, whether data to be transmitted to the outside has not yet been transmitted, and the RX data and TX data that actually remain at the time of switching by hooking the reception buffer input, reception buffer output, transmission buffer input, and transmission buffer output processes. The internal buffer / queue tracking unit (122) can generate buffer status information based on these tracking results, and the generated buffer status information can be used to determine whether there is a need to take over and process the unprocessed data as is in a subsequent instance (140).

[0044] In one embodiment, the IRQ / event tracking unit (123) can track interrupts, completion events, and error events occurring in serial communication interface devices (160). For example, the IRQ / event tracking unit (123) can track interrupt active status, transmission / reception completion status, whether a data frame is completed, whether a response is received, whether it has entered an active or idle state, and error statuses such as parity error, bus error, overrun, underrun, or timeout. Using this information, the IRQ / event tracking unit (123) can generate event status information including whether there is an event waiting to be processed, the type of event, whether a communication procedure is in progress, whether it is in a state just before completion, and whether it is in an error state. This information can be used as a basis for determining whether the logical execution flow has not yet terminated even if buffer data is not remaining.

[0045] In one embodiment, the time-based statistical tracking unit (124) can generate activity status information by analyzing information collected through the register access tracking unit (121), internal buffer / queue tracking unit (122), and IRQ / event tracking unit (123) along the time axis. For example, the time-based statistical tracking unit (124) can generate information indicating the last activity time, whether activity occurred within a recent threshold time, whether an idle state exists, whether activity occurred within the observation period immediately prior to the transition, and the final activity state of the device. Such time-based activity status information can be used as a criterion for determining whether the device is currently operating actively, is in a temporary idle state, or is close to a long-term idle state. This allows for a more accurate determination of whether the transition point to a subsequent instance (140) is stable.

[0046] In one embodiment, the profile generation unit (125) may receive information generated from the register access tracking unit (121), internal buffer / queue tracking unit (122), IRQ / event tracking unit (123), and time-based statistics tracking unit (124) and structure it into device-specific status data. For example, the profile generation unit (125) may integrate configuration status information, buffer status information, event status information, and activity status information into a single device-specific transition profile item, and may generate a transition profile (150) by gathering items for multiple devices. The transition profile (150) may be stored in the form of a file or transmitted to the migration control unit (130), and may be used as a basis for determining the device-specific migration method at the time of transition to a subsequent instance (140).

[0047] As illustrated in FIG. 2, the transition profile collection unit (120) can provide basis information to determine which method is suitable for transitioning to a subsequent instance (140) by collecting the static state, dynamic state, event state, and time-based activity state of the serial communication interface devices (160). That is, the transition profile collection unit (120) can be understood not as a configuration that simply stores the device state, but as a configuration that collects and structures the basis of the state for determining the transition policy for each device.

[0048] Additionally, the distinction between each tracking unit shown in FIG. 2 is merely an example for convenience of explanation, and in actual implementation, two or more tracking functions may be integrated into a single software component or a single hardware block, or some functions may be performed in a distributed manner. For example, the function of the time-based statistical tracking unit (124) may be performed by a separate analysis process using logs collected from other tracking units.

[0049] FIG. 3 is a conceptual diagram showing the data configuration of a conversion profile (150) according to one embodiment.

[0050] Referring to FIGS. 1 and 3, the transition profile (150) may be data structured by device for device status information collected from the current instance (110), and may be used as a basis for determining the device-specific migration method when transitioning to a subsequent instance (140). In one embodiment, the transition profile (150) may include device identification information (151), configuration status (152), buffer status (153), event status (154), and activity status (155).

[0051] In one embodiment, the transition profile (150) may be data in which the state of each device is stored based on compatibility with the new firmware. Accordingly, the transition profile (150) may be used as reference information to determine the range of the state to be reflected in the subsequent instance (140) and the migration method.

[0052] In one embodiment, the device identification information (151) may be information for identifying which device the transition profile (150) corresponds to. For example, the device identification information (151) may include a device identifier and a device type. Through this, the migration control unit (130) can distinguish which profile among the transition profiles for a plurality of devices corresponds to which device.

[0053] In one embodiment, the configuration state (152) may be information indicating the static configuration state of the device. For example, the configuration state (152) may include information regarding whether the device is active, communication settings, communication roles, whether interrupts are enabled, and data processing methods. This configuration state (152) may be used as reference information to ensure that a subsequent instance (140) operates under configuration conditions compatible with the existing device even after the transition. In particular, the configuration state (152) may be maintained if continuity of device configuration is required even if actual data is not retained.

[0054] In one embodiment, the buffer state (153) may be information indicating a dynamic state related to the transmission buffer and the reception buffer within the device. For example, the buffer state (153) may include whether the received data has not yet been processed, whether the transmitted data has not yet been completed, and the transmitted data or received data remaining at the time of switching. The buffer state (153) may be used to determine whether unprocessed data exists at the time of switching, and this information may serve as a basis for judgment to continue the service continuously without data loss.

[0055] In one embodiment, the event status (154) may be information indicating the interrupt processing status of the device or the progress status of the communication procedure. For example, the event status (154) may include whether there is an event waiting to be processed, the type of event, whether the communication procedure is in progress, whether it is in a state just before completion, and whether it is in an error state. The event status (154) may be used to determine whether the logical execution flow of the device or software has not yet terminated even if buffer data does not exist. Accordingly, the event status (154) may be used as reference information to determine how far the communication procedure has progressed at the time of device switching.

[0056] In one embodiment, the activity status (155) may be information indicating the device's recent operation history and idle status. For example, the activity status (155) may include the time of the last activity, whether there was activity within a recent period of time, whether there was an idle state, whether there was activity within the observation period immediately prior to the transition, and the device's final activity status. The activity status (155) may be used to determine whether the device is currently operating actively, is temporarily idle, or is idle for a long time. Such activity status (155) may serve as reference information for evaluating the stability of the transition point and determining whether there is a benefit in inheriting the state.

[0057] As illustrated in FIG. 3, the transition profile (150) can be understood not as simple state storage data, but as a data structure for determining a device-specific migration policy. That is, the transition profile (150) can provide base information that allows determining whether to reflect the entire state, reflect only a part of the state, or initialize without reflecting the state, by including the configuration state (152), buffer state (153), event state (154), and activity state (155) together based on device identification information (151).

[0058] Additionally, the data configuration illustrated in FIG. 3 is merely an example for the convenience of explanation. In actual implementation, detailed items included in each state information may be added or some items may be omitted, and the storage format may also be implemented as a JSON file, a table structure, an object structure, or various equivalent data structures. However, the fact that the configuration state (152), buffer state (153), event state (154), and activity state (155) are managed in conjunction with the device identification information may be maintained.

[0059] FIG. 4 is a flowchart illustrating the migration method determination process according to one embodiment.

[0060] Referring to FIGS. 1 and 4, the migration control unit (130) sequentially evaluates the transition point status of the device based on the transition profile (150) and new firmware (141), and can determine a migration method such as full migration (410), partial migration (420), or disposal and initialization (430) according to the evaluation result. The transition profile (150) can be used as data for judgment that includes device-specific configuration status, buffer status, event status, and activity status.

[0061] In one embodiment, the migration control unit (130) may first determine whether there is any remaining TX or RX data (401). The determination of whether there is any remaining TX or RX data (401) may be a determination step to check whether actual transmitted data or received data that has not yet been processed remains in the device at the time of transition. For example, this may apply to cases where transmitted data is loaded in the device but has not yet been fully transmitted to the outside, or where data received from the outside exists in the device but has not yet been fully processed by a processor or driver. In such cases where unprocessed data exists, data loss or processing omission may occur if transition is performed without reflecting the data, so the migration control unit (130) may determine a full migration (410).

[0062] If there is no remaining TX or RX data, the migration control unit (130) can determine whether there is an ongoing interrupt or transaction (402). The determination of whether there is an ongoing interrupt or transaction (402) may be a step to determine whether the logical processing flow between the device and the software has not yet ended, even if there is no data remaining in the buffer. For example, this may apply if there is an interrupt waiting state, if a completion event has not yet been processed, or if the communication procedure remains in an intermediate stage. If the device state is disconnected in this state, the subsequent instance (140) may not be able to know how far the communication procedure has progressed, so the migration control unit (130) can determine the entire migration (410).

[0063] If there are no ongoing interrupts or transactions, the migration control unit (130) may determine whether it is necessary to maintain the device settings (403). The determination of whether it is necessary to maintain the device settings (403) may be a step for determining whether it is necessary to maintain the static settings of the device used in the existing instance in the subsequent instance (140), even if there is no actual remaining data or ongoing events. For example, this may apply to cases where configuration states such as the device active state, baud rate or clock settings, frame mode, interrupt enable mask, addressing settings, chip select signal settings, or control mode must be maintained to ensure continuity with external communication partners. In this case, since it is not necessary to reflect all dynamic states or event states, but at least the static settings must be inherited, the migration control unit (130) may determine partial migration (420).

[0064] If maintaining the device configuration is not required, the migration control unit (130) can determine whether the device is in a sufficient idle state (404). Determining whether the device is in a sufficient idle state (404) may be a step for determining whether the device has been in an idle state for a long time, where there has been little device activity for a recent period, where there is no meaningful transmission / reception or interrupt activity within the observation period immediately prior to the transition, and where the device is in an idle state for a long time. For example, this may apply to cases where recent activity is denied, there is no activity history immediately prior to the transition, the idle safety condition is satisfied, and the device state is evaluated as being in an idle state for a long time. In this way, if there is no residual data or ongoing events in the device, the device is in an idle state, and maintaining the device configuration state is not required, the migration control unit (130) can determine disposal and initialization (430).

[0065] Meanwhile, if maintaining the device settings is not required and the device is not evaluated to be in a sufficient idle state, the migration control unit (130) may conservatively decide on partial migration (420). That is, in cases where it is difficult to conclude that the device is completely idle, transition stability can be ensured by selecting a transition policy that at least maintains the configuration state of the device.

[0066] As illustrated in FIG. 4, full migration (410) may be a method that reflects not only the static settings of the device but also dynamic data and event status, partial migration (420) may be a method that reflects only the static settings of the device, and disposal and initialization (430) may be a method that initializes the device in a new environment without transferring the device state. Accordingly, the decision flow of FIG. 4 can be understood as a decision procedure to evaluate the device state at the time of transition using the transition profile (150) and to select an appropriate transition policy that considers service continuity and transition stability together.

[0067] In addition, the judgment sequence and branching structure illustrated in FIG. 4 are merely examples. In actual implementation, the order of some judgment steps may be changed, two or more judgment steps may be performed in parallel, or some judgment criteria may be added or omitted depending on the type of specific device. However, the basic concept of selecting a migration method based on the presence of remaining data, the presence of an ongoing event, the need to maintain the configuration state, and the idle state may be maintained.

[0068] FIG. 5 is a flowchart illustrating a subsequent instance switching process according to one embodiment.

[0069] Referring to FIGS. 1 and FIGS. 5, the subsequent instance transition process may include a procedure for running a subsequent instance (140) according to the result of a migration decision, selectively reflecting the necessary state, and then controlling whether to allow a device reset to resume the service. The subsequent instance transition may proceed differently depending on one of the migration methods: full migration, partial migration, and disposal and initialization.

[0070] In one embodiment, the migration decision unit (132) can determine the migration result per device (S510). The migration result may be a full migration, a partial migration, or a disposal and initialization. The virtualization environment control unit (133) can receive the migration decision result (S520). Based on the received result, the virtualization environment control unit (133) can determine how to operate the subsequent instance (140) (S521).

[0071] In one embodiment, if the migration result is a full migration or a partial migration, the virtualization environment control unit (133) can package the migration data to be reflected in the subsequent instance (140) (S522). Here, packaging may be a procedure for structuring data so that the data within the transition profile (150) can be reflected when the subsequent instance (140) is launched. On the other hand, if the migration result is a discard and initialization, there is no information to be separately reflected in the subsequent instance (140), so the virtualization environment control unit (133) can apply default settings (S523). Subsequently, the virtualization environment control unit (133) can launch the subsequent instance (140) based on the new firmware (141) (S524).

[0072] In one embodiment, the subsequent instance (140) may be initialized (S530). Subsequently, the state injection unit (142) may determine a migration method (S531). If the migration method is a full migration, the state injection unit (142) may inject a register configuration state into the subsequent instance (140) (S541). Additionally, the state injection unit (142) may reflect TX / RX residual data (S542). Subsequently, the state injection unit (142) may reflect an event state including an interrupt, a completion event, or an error event (S543). Thus, in a full migration, not only the static state of the device but also dynamic data and event states may be reflected in the subsequent instance (140).

[0073] In one embodiment, when the migration method is partial migration, the state injection unit (142) can inject the register configuration state into the subsequent instance (140) (S541). In this case, the state injection unit (142) may not perform or may omit the TX / RX residual data reflection step (S542) and the event status reflection step (S543). That is, in partial migration, only the device configuration state is reflected, and the remaining reflection procedure may not be performed. Meanwhile, when the migration method is discard and initialization, the state reflection procedure by the state injection unit (142) may not be performed.

[0074] In one embodiment, the reset control unit (143) can control whether to perform a device reset or initialization routine during the boot process of the subsequent instance (140) (S550). Subsequently, the reset control unit (143) can determine a migration method (S551). If the migration method is a full migration or a partial migration, the reset control unit (143) can suppress the device reset (S552). By suppressing the reset in this way, the device reset is performed immediately after state injection, thereby preventing the injected information from being overwritten. Additionally, the injected TX / RX FIFO data can be processed immediately in the full migration path (S554). Accordingly, the continuity of the service performed by the current instance (110) can be maintained.

[0075] On the other hand, if the migration method is discard and initialization, the reset control unit (143) can perform a full initialization (S553). Subsequently, the reset control unit (143) can apply basic communication settings (S555). In this way, simplicity and stability can be ensured by using the basic initialization procedure of the new firmware (141) without separately inheriting the state.

[0076] Subsequently, the subsequent instance (140) can enter the service resumption and completion phase (S560). In the full migration path, the service can be resumed with the configuration state, residual data, and event state reflected, and in the partial migration path, the service can be resumed with the configuration state maintained. Additionally, in the disposal and initialization path, the service can be resumed with the default initialization and default communication settings applied. Thus, the transition procedure of FIG. 5 can be configured to transition to a subsequent instance (140) based on the new firmware (141), while selectively inheriting only the necessary range of states according to the device-specific state characteristics, and avoiding unnecessary re-initialization or unnecessary state reflection.

[0077] Additionally, the sequence and branching structure of each step illustrated in FIG. 5 are merely examples. In actual implementation, some steps may be integrated or separated, and some steps may be omitted or repeated depending on the specific device type or policy. However, the basic flow of driving a subsequent instance (140) based on the migration decision result, selecting a state injection range, and resuming service through reset control may be maintained.

[0078] FIG. 6a shows an example diagram of device processing according to a full migration in one embodiment.

[0079] As illustrated in FIG. 6a, a full migration may be determined based on the transition profile (150) (S610). A full migration may be applied when it is necessary to inherit the device's dynamic state and event state together at the time of transition. For example, a full migration may be selected if there is unprocessed data remaining in TX or RX, if an interrupt or transaction is in progress, or if there is an event or error state just before completion.

[0080] In one embodiment, when a full migration is determined, the register configuration state may first be reflected (S611). Here, the register configuration state may include static configuration information of the device, such as the device's active state, communication settings, whether interrupts are enabled, and control mode. Through this, subsequent instances (140) can reproduce a device configuration state compatible with the prior transition.

[0081] Subsequently, TX / RX residual data may be reflected (S612). TX / RX residual data may refer to actual data that has not yet been fully transmitted externally at the time of switching or has not yet been consumed by the processor or driver. By reflecting this data in the subsequent instance (140), the existing processing flow can be continued without data loss.

[0082] Additionally, event status may be reflected (S613). Event status may include whether to wait for an interrupt, a waiting state for processing a completion event, an error event, or the status of an ongoing communication procedure. By reflecting such event status, the subsequent instance (140) can not only inherit data but also continuously maintain the logical execution flow.

[0083] Subsequently, the device reset can be suppressed (S614). When the reset is suppressed, the previously reflected register configuration state, TX / RX residual data, and event state can be prevented from being overwritten by the initialization routine. As a result, the device can maintain a service continuity state (S615). That is, the entire migration path of FIG. 6a can be understood as a processing example to inherit the static state, dynamic state, and event state of the device, and to continue the existing service flow as much as possible by suppressing the reset.

[0084] FIG. 6b shows an example diagram of device processing according to partial migration in one embodiment.

[0085] As illustrated in FIG. 6b, partial migration may be determined based on the transition profile (150) (S620). Partial migration may be applied when there is no unprocessed data or ongoing events, but the configuration state of the device needs to be maintained in subsequent instances (140). For example, partial migration may be selected when the device active state, baud rate or clock setting, addressing setting, or control mode needs to be maintained to ensure continuity with an external communication partner.

[0086] In one embodiment, when partial migration is determined, the register configuration state may be reflected (S621). In this step, static configuration information of the device is injected into a subsequent instance (140), so that communication settings compatible with the existing ones can be maintained even in a new firmware environment.

[0087] Meanwhile, the reflection of buffer status and event status may be omitted (S622). This may be suitable when there is no remaining data to actually inherit at the time of transition, and no interrupts or transactions are being processed. In other words, in partial migration, it can be understood as a path that inherits only device settings without reflecting dynamic data and event status.

[0088] Subsequently, the device reset can be suppressed (S623). When the reset is suppressed, the previously reflected configuration state can be maintained, and subsequent instances (140) can continue operations based on that configuration. As a result, the device can maintain a configuration continuity state (S624). That is, the partial migration path of FIG. 6b can be seen as an example of processing to ensure configuration continuity by inheriting only the necessary device configuration state without reflecting unnecessary data or event states.

[0089] FIG. 6c shows an example diagram of device processing according to disposal and initialization in one embodiment.

[0090] As illustrated in FIG. 6c, disposal and initialization may be determined based on the transition profile (150) (S630). Disposal and initialization may be applied when there is no remaining data or ongoing events in the device, the device is idle, and maintaining the device configuration state is not required. In this case, it may be simpler and safer to re-initialize the device in a new environment rather than forcibly maintaining the existing state.

[0091] In one embodiment, if disposal and initialization are determined, state reflection may be omitted (S631). That is, register configuration state, TX / RX residual data and event state may not be injected into subsequent instances (140). This may be a measure to restart the device based on a new environment without inheriting the existing state.

[0092] Subsequently, a full device initialization may be performed (S632). A full device initialization may be a process of resetting the internal state of the device according to the basic initialization procedure of the new firmware (141). Then, a basic communication setting may be applied (S633). The basic communication setting may be an initial communication condition required for the device to operate normally in the new environment.

[0093] Afterward, the device can resume service in a new state (S634). That is, the discard and initialization path of FIG. 6c can be understood as an example of processing to restart service in a new state by omitting state reflection, performing a full initialization, and applying basic communication settings, without inheriting the existing state. Such a path can be advantageous for devices with a low need for state inheritance, in reducing unnecessary complexity and ensuring a stable transition.

[0094] Additionally, the processing procedure illustrated in FIGS. 6a, 6b, and 6c is merely an example for convenience of explanation. In actual implementation, some steps may be integrated, omitted, or changed in order depending on the device type, details of the transition profile, or system policy. However, the basic concept that static state, dynamic data, and event state are reflected in full migration, only configuration state is reflected in partial migration, and the initialization procedure is performed without reflecting state in disposal and initialization may be maintained.

[0095] The present invention has been described above with reference to its embodiments. Those skilled in the art will understand that the present invention may be embodied in modified forms without departing from its essential characteristics. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is defined by the claims, not by the foregoing description, and all variations within the scope of equivalents should be interpreted as being included in the present invention.

Claims

Claim 1 A virtualization instance switching device comprises: a switching profile collection unit that collects a switching profile including state information for one or more devices controlled in a current instance; a migration decision unit that determines a migration method to be applied to each device based on the switching profile; a virtualization environment control unit that drives a subsequent instance based on new firmware according to the determined migration method; a state injection unit that selectively reflects at least a portion of the device-specific state information collected in the current instance to the subsequent instance according to the migration method; and a reset control unit that controls whether to perform a reset or initialization routine for each device according to the migration method; wherein the migration method includes a full migration that reflects the device state to the subsequent instance, a partial migration that reflects a portion of the device state to the subsequent instance, and a disposal and initialization that initializes the device in the subsequent instance without reflecting the device state; and wherein the migration decision unit determines the full migration when there is residual data in the device or an ongoing event. Claim 2 A virtualization instance switching device according to claim 1, wherein the migration decision unit determines different migration methods for each of the one or more devices. Claim 3 delete Claim 4 A virtualization instance switching device according to claim 1, wherein the switching profile includes at least one of device identification information, configuration status, buffer status, event status, and activity status. Claim 5 A virtualization instance switching device according to claim 4, wherein the switching profile collection unit collects register access information of the device, input / output information for an internal buffer or queue of the device, interrupt or event information and time-based activity information to generate the switching profile. Claim 6 A virtualization instance switching device according to claim 1, characterized in that one or more devices include a serial communication interface device. Claim 7 A virtualization instance switching device according to claim 6, characterized in that the serial communication interface device comprises at least one of a UART device, an I2C device, and an SPI device. Claim 8 delete Claim 9 A virtualization instance switching device comprises: a switching profile collection unit that collects a switching profile including state information for one or more devices controlled in a current instance; a migration decision unit that determines a migration method to be applied to each device based on the switching profile; a virtualization environment control unit that drives a subsequent instance based on new firmware according to the determined migration method; a state injection unit that selectively reflects at least a portion of the device-specific state information collected in the current instance to the subsequent instance according to the migration method; and a reset control unit that controls whether to perform a reset or initialization routine for each device according to the migration method; wherein the migration method includes a full migration that reflects the device state to the subsequent instance, a partial migration that reflects a portion of the device state to the subsequent instance, and a disposal and initialization that initializes the device in the subsequent instance without reflecting the device state; and wherein the migration decision unit determines the partial migration when there is no residual data or ongoing events in the device and when it is necessary to maintain the device configuration state. Claim 10 A virtualization instance switching device comprises: a switching profile collection unit that collects a switching profile including state information for one or more devices controlled in a current instance; a migration decision unit that determines a migration method to be applied to each device based on the switching profile; a virtualization environment control unit that drives a subsequent instance based on new firmware according to the determined migration method; a state injection unit that selectively reflects at least a portion of the device-specific state information collected in the current instance to the subsequent instance according to the migration method; and a reset control unit that controls whether to perform a reset or initialization routine for each device according to the migration method; wherein the migration method includes a full migration that reflects the device state to the subsequent instance, a partial migration that reflects a portion of the device state to the subsequent instance, and a disposal and initialization that initializes the device in the subsequent instance without reflecting the device state; and wherein the migration decision unit determines the disposal and initialization when there is no residual data or ongoing events in the device, the device is in an idle state, and maintenance of the device configuration state is not required. Claim 11 A virtualization instance switching device comprises: a switching profile collection unit that collects a switching profile including state information for one or more devices controlled in a current instance; a migration decision unit that determines a migration method to be applied to each device based on the switching profile; a virtualization environment control unit that drives a subsequent instance based on new firmware according to the determined migration method; and a state injection unit that selectively reflects at least a portion of the device-specific state information collected from the current instance in the subsequent instance according to the migration method. A virtualization instance switching device comprising: a reset control unit that controls whether to perform a reset or initialization routine for each device according to the migration method; wherein the migration method includes a full migration that reflects the device state to the subsequent instance, a partial migration that reflects a part of the device state to the subsequent instance, and a discard and initialization that initializes the device in the subsequent instance without reflecting the device state; and wherein the state injection unit and the reset control unit reflect the device configuration state, residual data, and event state to the subsequent instance and suppress device reset when the full migration is determined, reflect the device configuration state to the subsequent instance and suppress device reset when the partial migration is determined, and allow device reset and initialization without performing state reflection when the discard and initialization is determined. Claim 12 delete

Images