Cloud server and vehicle ECU firmware management, vehicle data collection, and simulation model generation method thereof

Abstract

Provided is a vehicle ECU firmware management, vehicle data collection, and simulation model generation method. The method comprises the steps in which: a distribution manager receives ECU firmware developed by a developer; the distribution manager transmits the ECU firmware to a verification manager to request verification; the verification manager transmits, to a verification node manager, a node configuration file corresponding to the ECU firmware to request a verification node; the verification node manager composes the verification node on the basis of the node configuration file to transfer the verification node to the verification manager; the verification manager requests and receives a verification simulation model corresponding to the verification node from the distribution manager; the verification manager verifies the ECU firmware on the basis of the verification simulation model and the verification node; and the distribution manager distributes the ECU firmware on the basis of whether the distribution is approved when the distribution manager receives the verification result from the verification manager.

Description

Method for managing ECU firmware of cloud server and its vehicles, collecting vehicle data, and creating simulation models

[0001] The present invention relates to a cloud server and a method for managing ECU firmware of a vehicle, collecting vehicle data, and generating a simulation model.

[0002] Conventional ECU verification processes are manual, labor-intensive, and partially automated, resulting in low efficiency. Furthermore, when ECU errors occur, the time required to correct and deploy firmware is lengthy, making it difficult to respond quickly.

[0003] In addition, in the case of conventional technology, the function to detect and report in real time when an error occurs in the ECU during operation, not only during the vehicle development stage but also after vehicle development is completed, was inadequate.

[0004] Moreover, there was a problem in that data collection across diverse environments and error scenarios was insufficient, making it impossible to build and utilize a verification simulation model capable of satisfying quality and diversity requirements.

[0005] The problem to be solved by the present invention is to provide a cloud server and a method for managing vehicle ECU firmware, collecting vehicle data, and creating a simulation model thereof, which supports verification of vehicle ECU firmware during the development stage by increasing the usability of OTA service, and furthermore, supports update, verification, and distribution of firmware in which errors are detected through post-sale support for errors in vehicles in operation.

[0006] However, the problems to be solved by the present invention are not limited to the problems described above, and other problems may exist.

[0007] According to a first aspect of the present invention for solving the above-described problem, a method for managing ECU firmware, collecting vehicle data, and generating a simulation model of a vehicle comprises the steps of: a distribution manager receiving ECU firmware developed by a developer; a distribution manager transferring the ECU firmware to a verification manager to request verification; a verification manager transferring a node configuration file corresponding to the ECU firmware to a verification node manager to request a verification node; a verification node manager configuring a verification node based on the node configuration file and transferring the verification node to the verification manager; a verification manager requesting and receiving a verification simulation model corresponding to the verification node from the distribution manager; a verification manager performing verification on the ECU firmware based on the verification simulation model and the verification node; and a distribution manager distributing the ECU firmware based on whether distribution is approved upon receiving a verification result from the verification manager.

[0008] Some embodiments of the present invention may further include a step in which a state manager receives vehicle data from the developer or the vehicle; a step in which the state manager configures data for model generation based on the vehicle data and requests model generation to a model manager; a step in which the model manager generates the verification simulation model based on the data for model generation; and a step in which the model manager transfers the verification simulation model to a distribution manager.

[0009] In some embodiments of the present invention, the creation of the verification simulation model may be performed before the release of the vehicle, to verify the verification simulation model itself before the development of the ECU, or to verify the developed ECU with the verification simulation model after the development of the ECU.

[0010] In some embodiments of the present invention, the generation of the verification simulation model may be performed unconditionally after the vehicle is released, when an error occurs in the vehicle, or in a vehicle in which a collection event for the verification simulation model is registered.

[0011] Some embodiments of the present invention may further include a step of the state manager checking whether a vehicle state error and an internal ECU error have occurred based on the vehicle data; a step of checking whether a request for creation of the verification simulation model has been made if no error has occurred; and a step of waiting for reception of the vehicle data if a result of the checking indicates that there is no request for creation of the verification simulation model.

[0012] In some embodiments of the present invention, the step of requesting a verification node by transmitting a node configuration file corresponding to the ECU firmware to the verification node manager by the verification manager transmits the node configuration file including ECU number information, ECU core information, specification information for each ECU, connection information between ECUs, and verification item information, wherein the connection information between ECUs may include connection information with at least one of SILS, vHILS, HILS, and other verification cloud servers.

[0013] In addition, a cloud server for vehicle ECU firmware management according to a second aspect of the present invention includes a distribution manager that requests verification of ECU firmware developed by a developer upon receiving the ECU firmware, and distributes the ECU firmware based on whether distribution is approved upon receiving the verification result; a verification manager that requests and receives a verification simulation model corresponding to a verification node from the distribution manager upon receiving a verification request for the ECU firmware from the distribution manager, and performs verification of the ECU firmware based on the verification simulation model and the verification node; and a verification node manager that receives a node setting file corresponding to the ECU firmware from the verification manager, configures a verification node based on the node setting file, and transmits the verification node to the verification manager upon receiving a request for provision of a verification node.

[0014] In some embodiments of the present invention, the state manager may further include a model manager that receives a model generation request including data for model generation configured based on the vehicle data from the state manager when the state manager receives vehicle data prior to the launch of a new vehicle from the developer or the vehicle, generates the verification simulation model based on the model generation data, and transmits the verification simulation model to the distribution manager.

[0015] In addition, a computer program according to another aspect of the present invention is coupled with a computer as hardware to execute a method for managing the ECU firmware of the cloud server and its vehicle, collecting vehicle data, and generating a simulation model, and is stored in a computer-readable recording medium.

[0016] Other specific details of the present invention are included in the detailed description and drawings.

[0017] According to the present invention described above, errors occurring during vehicle operation can be quickly detected, and rapid and stable firmware distribution is possible through cloud-based ECU verification, thereby providing the advantage of being able to quickly respond to problems occurring during vehicle operation.

[0018] Additionally, the application of OTA technology allows firmware updates without having to visit a repair shop, providing convenience to users and minimizing the time spent on visiting a repair shop.

[0019] In addition, since a real environment is not required for error reproduction, it is possible to reproduce errors and identify their causes through various simulations. In addition, by having more test coverage in the same amount of time, development costs and verification time can be reduced, and the verification process can be unified to increase efficiency in vehicle ECU firmware development and improvement.

[0020] Furthermore, by enabling rapid response to errors, the likelihood of recalls can be reduced, and efficient development and testing facilitate high-quality service delivery. Furthermore, by integrating the development verification process and resolution of issues with released vehicles, efficiency is increased, and the ease of access to simulation models enables testing in a variety of environments, shortening development times.

[0021] The effects of the present invention are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description below.

[0022] FIG. 1 is a diagram illustrating a cloud server for vehicle ECU firmware management according to one embodiment of the present invention.

[0023] Figure 2a is a diagram for explaining the verification simulation model creation process in one embodiment of the present invention.

[0024] FIG. 2b is a drawing for explaining an ECU firmware verification process in one embodiment of the present invention.

[0025] FIG. 3a is a diagram for explaining the verification simulation model creation process in another embodiment of the present invention.

[0026] FIG. 3b is a drawing for explaining an ECU firmware verification process in one embodiment of another invention.

[0027] FIG. 4a is a diagram illustrating a process of generating data for model generation in one embodiment of the present invention.

[0028] FIG. 4b is a diagram illustrating a process of generating data for model generation in another embodiment of the present invention.

[0029] FIG. 5 is a diagram for explaining the verification simulation model creation process in one embodiment of the present invention.

[0030] The advantages and features of the present invention, and the methods for achieving them, will become clearer with reference to the embodiments described in detail below together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided solely 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 present invention, and the present invention is defined solely by the scope of the claims.

[0031] The terminology used herein is for the purpose of describing embodiments only and is not intended to limit the present invention. In this specification, the singular also includes the plural unless specifically stated otherwise. As used herein, the terms "comprises" and / or "comprising" do not exclude the presence or addition of one or more other components in addition to the mentioned components. Like reference numerals refer to like components throughout the specification, and "and / or" includes each and any combination of one or more of the mentioned components. Although "first", "second", etc. are used to describe various components, these components are not limited by these terms. These terms are only used to distinguish one component from another. Therefore, it should be understood that a first component mentioned below may also be a second component within the technical spirit of the present invention.

[0032] Unless otherwise defined, all terms (including technical and scientific terms) used herein may be used in their common sense to those skilled in the art to which the present invention pertains. Furthermore, terms defined in commonly used dictionaries are not to be interpreted ideally or excessively unless explicitly and specifically defined otherwise.

[0033] FIG. 1 is a drawing for explaining a cloud server (100) for vehicle ECU firmware management according to one embodiment of the present invention.

[0034] A cloud server (100) according to one embodiment of the present invention includes a distribution manager (110), a verification manager (120), a verification node manager (130), a state manager (140), and a model manager (150). At this time, each manager included in the cloud server (100) may be configured as an independent processor, or, depending on the embodiment, may be configured as a program with each function divided into separate programs and operated through a single processor.

[0035] As such, the cloud server (100) is comprised of administrators who perform various roles to effectively provide verification processes and OTA services. The cloud server (100) provides various interfaces to effectively connect with actual hardware, other verification cloud servers (100), vehicles, and ECUs under development.

[0036] The deployment manager (110) included in the cloud server (100) tracks the firmware development and build process and can manage the history of each build. Furthermore, it can manage the history of each verification simulation model created by the model manager (150), managing which models were created and what training data was used. Furthermore, the deployment manager (110) ultimately manages the verification simulation model and its deployment. Additionally, the deployment manager (110) can perform redistribution or rollback operations to immediately respond to errors.

[0037] The verification manager (120) is the entity that performs verification, and performs verification of specific firmware upon receiving a request from the firmware or developer based on a notification from the distribution manager (110). The verification manager (120) can transmit a node configuration file for setting up verification nodes required for verification to the verification node manager (130), thereby transmitting information on the environment in which verification will be performed.

[0038] The verification node manager (130) configures and delivers a verification node upon receiving a verification node configuration request from the verification manager (120). The verification node may include various components, and in one embodiment, may include a verification simulation model, a virtual machine, another verification cloud server (100), an actual hardware target board, a commercial verification module, etc. The verification node is connected to the cloud, and the verification node manager (130) can manage the connection of these verification nodes.

[0039] Meanwhile, the verification node may include elements necessary to verify various aspects of the firmware and system, which can be configured based on a node configuration file. The node configuration file may include the number of ECUs, the ECU core, ECU functions, whether SILS, vHILS, or HILS are supported, the firmware to be installed on the ECU, the ECU interface, and verification item information (vehicle type, vehicle release date, driving environment information, vehicle configuration information). Developers can upload the node configuration file when uploading firmware.

[0040] The status manager (140) collects various data generated from the vehicle, including vehicle status, sensor data, and other information generated during operation. Furthermore, the status manager (140) determines whether the collected data contains errors and assesses their importance. If an error is detected, the relevant person in charge is immediately notified of the issue and the issue is tracked to ensure prompt resolution. Furthermore, the status manager (140) forwards the collected vehicle data to the model manager (150) so that it can be utilized as training data for the model or as additional information to improve model performance.

[0041] The model manager (150) can receive a specific algorithm from a developer and create a verification simulation model, or can use vehicle data collected through the state manager (140) to create a verification simulation model of ECUs, sensors, external environments, etc.

[0042] At this time, the generated verification simulation model is utilized for verification at the request of the verification node manager (130). By integrating the verification simulation model into the verification node, it can be verified for operation in real-world scenarios and utilized for firmware verification. Furthermore, the model manager (150) can extract the verification simulation model in a form usable by external commercial tools at the developer's request, thereby supporting the effective utilization of the model in various tools.

[0043] Hereinafter, a method for managing vehicle ECU firmware, collecting vehicle data, and creating a simulation model in a new vehicle development stage according to one embodiment of the present invention will be described with reference to FIGS. 2a and 2b.

[0044] FIG. 2a is a diagram illustrating a verification simulation model generation process in one embodiment of the present invention. FIG. 2b is a diagram illustrating an ECU firmware verification process in one embodiment of the present invention.

[0045] First, referring to FIG. 2a, when the state manager (140) receives vehicle data from a developer at the vehicle development stage prior to the launch of a new vehicle (S201), it configures data for model creation based on the vehicle data and requests model creation to the model manager (150) (S202).

[0046] Next, the model manager (150) creates a verification simulation model based on the data for model creation (S203), and the model manager (150) transfers the verification simulation model to the distribution manager (110) (S204).

[0047] The process illustrated in Fig. 2a is a process for collecting a verification simulation model before the launch of a vehicle, and is intended to perform a process for verifying the verification simulation model itself before ECU development, or a process for verifying the developed ECU with the verification simulation model after ECU development, and this can be performed only when necessary.

[0048] Next, referring to FIG. 2b, when the distribution manager (110) receives the ECU firmware developed by the developer (S211), the distribution manager (110) transmits the ECU firmware to the verification manager (120) to request verification (S212).

[0049] Next, the verification manager (120) requests a verification node by transmitting a node configuration file corresponding to the ECU firmware to the verification node manager (130) (S213). At this time, the node configuration file may include ECU number information, ECU core information, ECU-specific specification information, ECU-to-ECU connection information, and verification item information. In addition, the ECU-to-ECU connection information may include connection information with at least one of SILS, vHILS, HILS, and other verification cloud servers (100).

[0050] Next, the verification node manager (130) configures the verification node based on the node configuration file and transfers the verification node to the verification manager (120) (S214).

[0051] Next, as the verification manager (120) requests the distribution manager (110) for a verification simulation model corresponding to the verification node (S215), the distribution manager (110) provides the verification simulation model to the verification manager (120) (S216).

[0052] Next, the verification manager (120) performs verification on the ECU firmware based on the verification simulation model and verification node (S217).

[0053] Next, the distribution manager (110) can distribute the ECU firmware based on whether the distribution is approved (S218) upon receiving the verification result from the verification manager (120). If the verification result indicates an ECU firmware error, the first step S201 of FIG. 2a or step S211 of FIG. 2b can be repeated.

[0054] In contrast, if there is no error in the verification result, the distribution manager (110) requests the distribution reviewer to approve the distribution (S219), and if the distribution reviewer approves the distribution (S220), the distribution manager (110) can distribute the ECU firmware (S221).

[0055] Figure 3a is a diagram illustrating the verification simulation model generation process in another embodiment of the present invention. Figure 3b is a diagram illustrating the ECU firmware verification process in another embodiment of the present invention. Note that the embodiments of Figures 3a and 3b, unlike Figures 2a and 2b, correspond to processes performed after the completion of new vehicle development and vehicle launch.

[0056] First, referring to FIG. 3a, when the state manager (140) receives vehicle data from the vehicle (S301), it configures data for model creation based on the vehicle data and requests model creation to the model manager (150) (S302).

[0057] Next, the model manager (150) creates a verification simulation model based on the data for model creation (S303), and the model manager (150) transfers the verification simulation model to the distribution manager (110) (S304).

[0058] The process illustrated in Figure 3a is performed unconditionally after the vehicle is released, unlike when a new vehicle is developed, when an error occurs in the vehicle, or when a collection event for a verification simulation model is registered in the vehicle.

[0059] Next, Fig. 3b is identical to the process of Fig. 2b. When the distribution manager (110) receives the ECU firmware developed by the developer (S311), the distribution manager (110) transmits the ECU firmware to the verification manager (120) to request verification (S312).

[0060] Next, the verification manager (120) requests a verification node by transmitting a node configuration file corresponding to the ECU firmware to the verification node manager (130) (S313). At this time, the node configuration file may include ECU number information, ECU core information, ECU-specific specification information, ECU-to-ECU connection information, and verification item information. In addition, the ECU-to-ECU connection information may include connection information with at least one of SILS, vHILS, HILS, and other verification cloud servers (100).

[0061] Next, the verification node manager (130) configures the verification node based on the node configuration file and transfers the verification node to the verification manager (120) (S314).

[0062] Next, as the verification manager (120) requests the distribution manager (110) for a verification simulation model corresponding to the verification node (S315), the distribution manager (110) provides the verification simulation model to the verification manager (120) (S316).

[0063] Next, the verification manager (120) performs verification on the ECU firmware based on the verification simulation model and verification node (S317).

[0064] Next, the distribution manager (110) can distribute the ECU firmware based on whether the distribution is approved or not upon receiving the verification result from the verification manager (120) (S318). If the verification result indicates an ECU firmware error, the first step S301 of FIG. 3a or step S311 of FIG. 3b can be repeated.

[0065] In contrast, if there is no error in the verification result, the distribution manager (110) requests the distribution reviewer to approve the distribution (S319), and if the distribution reviewer approves the distribution (S320), the distribution manager (110) can distribute the ECU firmware (S321).

[0066] FIG. 4a is a diagram illustrating a process of generating data for model generation in one embodiment of the present invention.

[0067] When the status manager (140) receives vehicle data from a developer or a vehicle (S401), it first checks whether an error exists in the vehicle status based on the vehicle data (S402).

[0068] If the verification result shows that no error exists, the status manager (140) checks whether an error exists in the internal ECU (S403).

[0069] If no error is found as a result of the verification, it is checked whether there is a request to create a verification simulation model (S404), and if there is no request to create a verification simulation model as a result of the verification, the data for model creation is not configured and the vehicle data reception standby state is maintained (S405).

[0070] In contrast, if an error exists in step S402 or S403, which is an error verification step, error notification information is generated (S406), and if there is a request to create a verification simulation model, data for model creation including error notification information is configured (S407), and then the data for model creation is transmitted to the model manager (150) (S408). At this time, if no error exists, data for model creation that does not include error notification information can be configured.

[0071] The model manager (150) that has received data for model creation (S409) creates a verification simulation model based on the data for model creation (S410) and transmits the created verification simulation model to the distribution manager (110) (S411).

[0072] As the distribution manager (110) receives the verification simulation model (S412), it can register and manage it (S413).

[0073] FIG. 4b is a diagram illustrating a process of generating data for model generation in another embodiment of the present invention.

[0074] Meanwhile, in the case of the existing method, the approach to development, verification, and distribution of vehicle software was to use separate cloud servers before and after release, but in the case of one embodiment of the present invention, a series of processes for the development, verification, and distribution stages of vehicle software before and after vehicle release can be performed in a single integrated cloud server (100).

[0075] Accordingly, the integrated cloud server (100) can efficiently manage the development and deployment stages before and after vehicle launch, and improve workflow by enabling efficient information and resource sharing through a unified device. Furthermore, it offers the advantage of enabling the collection and utilization of simulation models capable of verifying various scenarios during software verification.

[0076] Referring to FIG. 4b, when the distribution manager (110) receives ECU firmware from the developer (S421), it transfers the ECU firmware to the verification manager (120) to request verification. When the verification manager (120) requests a verification simulation model corresponding to the verification node from the distribution manager (110) (S423), the distribution manager (110) checks the verification simulation model (S424), and if a verification simulation model exists as a result of the check, or if no verification simulation model exists, it creates a verification simulation model (S425) and then provides it to the verification manager (120) (S426).

[0077] In contrast, if the verification manager (120) does not request a verification simulation model, it requests a verification node from the verification node manager (130) (S427). Upon receiving the request, the verification node manager (130) configures a verification node based on the node configuration file (S429) and transmits the verification node to the verification manager (120) (S430). At this time, if a pre-configured verification node exists, the verification node may be transmitted to the verification manager (120).

[0078] Next, the verification manager (120) performs verification (testing) on ​​the ECU firmware based on the verification simulation model and verification nodes (S431). At this time, the verification manager (120) provides a notification if an error occurs during verification (S432), and accordingly, the status manager (140) can receive a notification of the error occurrence (S433).

[0079] In contrast, if verification is completed without errors, the verification manager (120) provides a notification (S434). Accordingly, the distribution manager (110) receives the verification completion notification, verifies the verification results (S435), and requests distribution approval from the distribution reviewer (S436). If the distribution reviewer receives the distribution approval request and approves the distribution, the distribution manager can distribute the ECU firmware (S437).

[0080] Vehicles that have received the distributed ECU firmware can perform firmware updates based on the ECU firmware.

[0081] According to this structure, one embodiment of the present invention can create a simulation model that utilizes various sensor information collected from the vehicle to accurately analyze software defects that occur in a vehicle after its release. In other words, the simulation model accurately simulates the situation in which an error occurred, thereby enabling rapid detection and correction of the cause of the software defect. This simulation model can also be utilized in future software development. In other words, when developing new software, it can reproduce previously encountered defect situations and test software operation in those scenarios, thereby enabling the prevention and resolution of similar defects or problems in advance.

[0082] FIG. 5 is a diagram for explaining the verification simulation model creation process in one embodiment of the present invention.

[0083] In one embodiment of the present invention, the verification simulation model is generated by a process in which the model manager (150) receives data for model generation from the state manager (140).

[0084] Specifically, when data for model generation is received (S510), the model manager (150) checks whether a model generation request exists in the model generation event or an error is indicated (S511). If the check result indicates that an event exists or an error is indicated, the model manager (150) additionally collects vehicle status data (S512), internal ECU data (S513), driving environment data (S514), road condition data (S515), etc.

[0085] Next, the model manager (150) creates a verification simulation model corresponding to the error phenomenon or point based on each piece of collected information (S516).

[0086] Next, the model manager (150) can optimize the verification simulation model corresponding to the applicable environmental conditions (S517) and then transmit the verification simulation model to the distribution manager (110) (S518).

[0087] Meanwhile, in the above description, steps S201 to S518 may be further divided into additional steps or combined into fewer steps, depending on the implementation of the present invention. Furthermore, some steps may be omitted as needed, and the order of the steps may be changed. Furthermore, even if other details are omitted, the details described in FIGS. 2A to 5 and FIG. 1 are mutually applicable.

[0088] In one embodiment of the present invention described above, the cloud server (100) and its vehicle ECU firmware management, vehicle data collection, and simulation model generation method can be implemented as a program (or application) to be executed in combination with a computer as hardware and stored in a medium.

[0089] The above-described program may include codes coded in a computer language, such as C, C++, JAVA, Ruby, or machine language, that can be read by the processor (CPU) of the computer through the device interface of the computer, so that the computer reads the program and executes the methods implemented as a program. Such codes may include functional codes related to functions that define functions necessary to execute the methods, and may include control codes related to execution procedures necessary for the processor of the computer to execute the functions according to a predetermined procedure. In addition, such codes may further include memory reference-related codes regarding which location (address address) of the internal or external memory of the computer should reference additional information or media necessary for the processor of the computer to execute the functions. In addition, if the processor of the computer needs to communicate with any other computer or server located remotely in order to execute the functions, the code may further include communication-related code regarding how to communicate with any other computer or server located remotely using the communication module of the computer, and what information or media to send and receive during communication.

[0090] The above storage medium refers to a medium that stores data semi-permanently and can be read by a device, rather than a medium that stores data for a short period of time, such as a register, cache, or memory. Specifically, examples of the storage medium include, but are not limited to, ROM, RAM, CD-ROM, magnetic tape, floppy disk, and optical data storage device. That is, the program can be stored in various recording media on various servers that the computer can access or in various recording media on the user's computer. In addition, the medium can be distributed across network-connected computer systems, so that computer-readable code can be stored in a distributed manner.

[0091] The foregoing description of the present invention is for illustrative purposes only, and those skilled in the art will readily appreciate that the present invention can be readily modified into other specific forms without altering the technical spirit or essential characteristics of the present invention. Therefore, the embodiments described above should be understood as illustrative in all respects and not restrictive. For example, each component described as a single entity may be implemented in a distributed manner, and similarly, components described as distributed may be implemented in a combined manner.

[0092] The scope of the present invention is indicated by the claims described below rather than the detailed description above, and all changes or modifications derived from the meaning and scope of the claims and their equivalent concepts should be interpreted as being included in the scope of the present invention.

Claims

1. A method for managing vehicle ECU firmware, collecting vehicle data, and generating a simulation model performed by a cloud server. Step where the distribution manager receives the ECU firmware developed by the developer; A step in which the above distribution manager transfers the ECU firmware to the verification manager to request verification; A step in which the verification manager requests a verification node by transmitting a node setting file corresponding to the ECU firmware to the verification node manager; A step in which the verification node manager configures the verification node based on the node configuration file and transfers the verification node to the verification manager; A step in which the verification manager requests and receives a verification simulation model corresponding to the verification node from the distribution manager; The step of the above verification manager performing verification on the ECU firmware based on the verification simulation model and verification node; and Including a step of distributing the ECU firmware based on whether the distribution manager approves the distribution upon receiving the verification result from the verification manager. How to manage vehicle ECU firmware, collect vehicle data, and create simulation models.

2. In paragraph 1, A step in which the state manager receives vehicle data from the developer or the vehicle; A step in which the state manager configures data for model creation based on the vehicle data and requests model creation to the model manager; The step of the model manager generating the verification simulation model based on the data for generating the model; and The above model manager further comprises a step of transferring the verification simulation model to the distribution manager. How to manage vehicle ECU firmware, collect vehicle data, and create simulation models.

3. In paragraph 2, The creation of the above verification simulation model is done before the release of the vehicle, to verify the verification simulation model itself before the development of the ECU, or to verify the developed ECU with the verification simulation model after the development of the ECU. How to manage vehicle ECU firmware, collect vehicle data, and create simulation models.

4. In paragraph 2, The creation of the above verification simulation model is performed unconditionally in the event of an error in the vehicle after the vehicle is released, or in the vehicle for which a collection event for the verification simulation model is registered. How to manage vehicle ECU firmware, collect vehicle data, and create simulation models.

5. In paragraph 2, A step in which the above status manager determines whether a vehicle status error and an internal ECU error have occurred based on the above vehicle data; A step of checking whether there is a request for generation of the verification simulation model if the above error does not occur; and If there is no request for creation of a verification simulation model as a result of the above verification, the step of waiting for reception of the vehicle data is further included. How to manage vehicle ECU firmware, collect vehicle data, and create simulation models.

6. In paragraph 1, The step of requesting a verification node by the verification manager sending a node setting file corresponding to the ECU firmware to the verification node manager is as follows: The node configuration file including ECU number information, ECU core information, ECU-specific specification information, ECU-to-ECU connection information, and verification item information is transmitted. The above ECU-to-ECU connection information includes connection information with at least one of SILS, vHILS, HILS, and other verification cloud servers. How to manage vehicle ECU firmware, collect vehicle data, and create simulation models.

7. In a cloud server for vehicle ECU firmware management, A distribution manager that requests verification of the ECU firmware developed by the developer upon receiving the ECU firmware, and distributes the ECU firmware based on whether distribution is approved upon receiving the verification result; Upon receiving a verification request for the ECU firmware from the distribution manager, a verification manager requests and receives a verification simulation model corresponding to the verification node from the distribution manager, and performs verification for the ECU firmware based on the verification simulation model and the verification node. Including a verification node manager that receives a node configuration file corresponding to the ECU firmware from the verification manager and requests provision of a verification node, configures a verification node based on the node configuration file, and transmits the verification node to the verification manager. Cloud server for vehicle ECU firmware management.

8. In paragraph 7, As the state manager receives vehicle data prior to the launch of a new vehicle from the developer or the vehicle, it receives a model creation request from the state manager including data for model creation based on the vehicle data, Further comprising a model manager for generating the verification simulation model based on the data for generating the model and transmitting the verification simulation model to the distribution manager. Cloud server for vehicle ECU firmware management.

Images