Setting transformer management and control method and system

Abstract

The invention relates to a method and a system for setting and changing management and control, which belong to the field of engineering change, and comprise the following steps: configuring a mark management comparison table in advance, the table comprises a plurality of evolution implementation windows, and each evolution implementation window corresponds to an evolution implementation time period; and setting a switching mark under the adjacent evolution implementation window according to the preset setting change implementation time, and using the switching mark to describe the software and hardware design categories which are subjected to the setting change before and after. The switching marks are added to all the vehicle type codes, after order information is received, the corresponding vehicle type codes are searched, the switching marks with the time periods covering the order time are extracted from the corresponding vehicle type codes, and corresponding software and hardware design is extracted according to the switching marks for implementation. According to the method, the time period and the implementation range of setting and transformation batch implementation are limited through the evolution implementation window, the types of software and hardware design subjected to setting and transformation are marked through the switching mark, and the switching mark is added in the design case, so that the software and hardware design needing to be adopted at the order time is conveniently searched according to the order information, and efficient setting and transformation batch management is realized.

Description

Technical Field

[0001] The present application relates to the field of engineering changes, and specifically to a method and system for engineering change management and control. Background Art

[0002] In the current fiercely competitive environment of the global automotive industry, the importance of controlling part design changes (abbreviated as design changes or changes) is self-evident. With the rapid development of technology and the diversification of consumer demand, automakers need to continuously optimize and adjust product designs to maintain market competitiveness. However, part design changes involve many links, including design, production, supply chain, etc. Each link may have a chain reaction due to changes, such as increased costs, production delays, quality control challenges, and may even affect the launch time and brand image of the entire model. Frequent and complex design changes, if not managed properly, may lead to rework and shutdown of the production line, increase production costs and affect delivery schedules. In addition, good change management can improve the stability and reliability of the supply chain and avoid delays and problems caused by changes on the supplier side.

[0003] As the company's production and sales volume continues to expand, the number of product evolutions (evolutions for short) continues to increase, and the change (design side) implementation (manufacturing side) control cycle continues to shrink. The existing single part or multiple parts matching multiple frequency product evolution release mode can no longer meet the deadline requirements well, and the change implementation efficiency is low. How to ensure that such a large number of product evolutions are released in a timely, efficient and coordinated manner is an urgent problem that needs to be solved. Summary of the invention

[0004] The present application provides a design change management and control method and system, which can solve the technical problem in the prior art that a large number of design changes cannot be delivered in a timely, efficient and coordinated manner.

[0005] In a first aspect, an embodiment of the present application provides a method for design change control, the method comprising:

[0006] Define multiple evolution implementation windows and their window boundaries, each evolution implementation window corresponds to an evolution implementation time period, and the window boundary of the evolution implementation window is used to limit all software and hardware designs included in the window;

[0007] A plurality of window classification marks are configured for each evolution implementation window to obtain a mark management comparison table, wherein the window classification marks are used to classify all software and hardware designs included in the window;

[0008] According to the preset design change implementation time, a switching flag is set under two adjacent evolution implementation windows in the flag management comparison table, and the switching flag is a window classification flag of the change of two adjacent evolution real-time windows;

[0009] Add a switching flag to the design use cases of the software and hardware designs with design changes in two adjacent evolution real-time windows, and to all vehicle model codes in the vehicle model code database;

[0010] After receiving the order information, according to the vehicle model code and order time contained in the order information, the corresponding switching mark in the corresponding vehicle model code is obtained from the vehicle model code database, and the order time is in the evolution implementation time period corresponding to the obtained switching mark;

[0011] According to the acquired switching flag, the software and hardware design with the corresponding switching flag in the design use case is obtained for implementation.

[0012] In combination with the first aspect, in one implementation, the total number of all window classification flags included in each evolution implementation window in the flag management comparison table is the same, and each window classification flag includes a classification flag and a flag value;

[0013] The classification marks of two adjacent switching marks under two adjacent evolution implementation windows are the same and the mark values ​​are different, and the classification marks and mark data of other adjacent window classification marks except the two adjacent switching marks under two adjacent evolution implementation windows are the same.

[0014] In combination with the first aspect, in one implementation, all vehicle model codes in the vehicle model code database have a first valid time period;

[0015] According to the vehicle model code and order time included in the order information, a corresponding switching mark in the corresponding vehicle model code within the first valid time period is extracted from the vehicle model code data.

[0016] In combination with the first aspect, in one implementation, the vehicle model code further includes a description mark, the description mark is used to describe the basic design included in the vehicle model, and the description mark has a second valid time period;

[0017] According to the vehicle model code and order time included in the order information, the corresponding switching mark in the corresponding vehicle model code within the first valid time period and the description mark within the second valid time period are extracted from the vehicle model code database.

[0018] In combination with the first aspect, in one implementation, the method further includes:

[0019] Add early trigger conditions to the design use case where the toggle flag is added;

[0020] After receiving the order information for pre-batch production, extracting the advance trigger information contained in the order information;

[0021] When it is determined that the advance trigger information meets the advance trigger condition, the switching mark extracted from the vehicle model coding database according to the order information is the switching mark corresponding to the next evolution implementation time period of the evolution implementation time period in which the order time is located.

[0022] In a second aspect, an embodiment of the present application provides a system for controlling a change in a device, the system comprising:

[0023] A table configuration module, which is used to define multiple evolution implementation windows and their window boundaries, each evolution implementation window corresponds to an evolution implementation time period, and the window boundary of the evolution implementation window is used to limit all software and hardware designs contained in the window; it is also used to configure multiple window classification flags for each evolution implementation window to obtain a flag management comparison table, and the window classification flag is used to classify all software and hardware designs contained in the window; it is also used to set a switching flag under two adjacent evolution implementation windows in the flag management comparison table according to a preset design change implementation time, and the switching flag is a window classification flag of the change of two adjacent evolution real-time windows;

[0024] A data preprocessing module, which is used to add a switching flag to the design use cases of the software and hardware designs with design changes in two adjacent evolution real-time windows, and to all vehicle model codes in the vehicle model code database;

[0025] An order processing module, which is used to obtain the corresponding switching mark in the corresponding vehicle model code from the vehicle model code database according to the vehicle model code and order time contained in the order information after receiving the order information, and the order time is in the evolution implementation time period corresponding to the obtained switching mark;

[0026] A design change implementation module, which is used to obtain the software and hardware design with the corresponding switching flag in the design case according to the acquired switching flag for implementation;

[0027] The vehicle model code database is used to store vehicle model codes.

[0028] In conjunction with the second aspect, in one implementation, the total number of all window classification flags included in each evolution implementation window in the flag management comparison table is the same, and each window classification flag includes a classification flag and a flag value;

[0029] The classification marks of two adjacent switching marks under two adjacent evolution implementation windows are the same and the mark values ​​are different, and the classification marks and mark data of other adjacent window classification marks except the two adjacent switching marks under two adjacent evolution implementation windows are the same.

[0030] In conjunction with the second aspect, in one implementation, all vehicle model codes in the vehicle model code database have a first valid time period;

[0031] The order processing module is used to extract the corresponding switching mark in the corresponding vehicle model code within the first valid time period from the vehicle model code data according to the vehicle model code and order time contained in the order information.

[0032] In conjunction with the second aspect, in one implementation, the vehicle model code further includes a description mark, the description mark is used to describe the basic design included in the vehicle model, and the description mark has a second valid time period;

[0033] The order processing module is used to extract the corresponding switching mark in the corresponding vehicle model code within the first valid time period and the description mark within the second valid time period from the vehicle model code database according to the vehicle model code and order time contained in the order information.

[0034] In conjunction with the second aspect, in one implementation, the data preprocessing module is used to add an advance trigger condition to a design use case to which a switching flag is added;

[0035] The order processing module is used to extract the advance trigger information contained in the order information after receiving the pre-batch production order information; when it is judged that the advance trigger information meets the advance trigger condition, the switching mark extracted from the vehicle model coding database according to the order information is the switching mark corresponding to the next evolution implementation time period of the evolution implementation time period in which the order time is located.

[0036] The beneficial effects brought by the technical solution provided in the embodiments of the present application include:

[0037] By evolving the implementation window, the time period and scope of batch implementation of design changes can be limited. By using switching marks, the software and hardware design categories where design changes occur are marked. By adding switching marks to design use cases, it is convenient to find software and hardware designs that meet order time requirements based on order information, effectively and collaboratively manage design changes, and improve the efficiency of design change management and control. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 It is a schematic diagram of a windowless delivery mode in the prior art;

[0039] Figure 2 This is a schematic diagram of the window delivery mode in the application;

[0040] Figure 3 A flow chart of an embodiment of a method for controlling the change of the present application;

[0041] Figure 4 A schematic diagram of vehicle type code and corresponding window switching in a specific embodiment of the present application

[0042] Figure 5 A schematic diagram of a design use case in a specific embodiment of the present application;

[0043] Figure 6 This is a schematic diagram of splitting the vehicle layer and the parts layer according to order information in a specific embodiment of the present application;

[0044] Figure 7 A schematic diagram of vehicle type coding with a valid time period in a specific embodiment of the present application;

[0045] Figure 8 This is a schematic diagram of the functional modules of an embodiment of a change control system of the present application. DETAILED DESCRIPTION

[0046] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0047] First, some technical terms in the present application are explained to facilitate those skilled in the art to understand the present application.

[0048] Product configuration code: also known as a flag, a fixed-length character or digital code string used to represent a certain feature or function of a product. Such a code set is called a flag dictionary. By using a flag dictionary to describe a product, ambiguity can be reduced and it is easier for computer information systems to perform calculations and processing.

[0049] Window evolution: also known as evolution packaging or centralized design change delivery, a change management model that implements multiple evolutions together. These evolutions can be independent of each other or have supporting relationships.

[0050] Reference Figure 1 , which is a schematic diagram of the windowless delivery mode in the prior art. On the timeline, the vehicle software and hardware will be constantly changed. These design changes include scattered design changes that are continuously introduced by the design end in daily life according to vehicle performance requirements, corresponding design changes introduced by the design end according to newly issued regulations, and batch design changes that are concentrated at a specified time point according to the annual model modification plan of the automobile manufacturer. Figure 1 It can be seen that design changes occur frequently, lack planning, and are highly random. Every time a design change occurs, the production and supply chain ends need to update the management data of the parts management system.

[0051] For example, in the prior art 1, a change implementation process control method based on MBOM drive is proposed, which provides a general design change implementation control method. The key technology is that a single design change is updated based on the MBOM difference point to drive the work in the industrialization field. However, the design change requirements are still scattered from various fields, and are proposed from their own requirements and plans. The implementation control is summarized in MBOM, which cannot solve the coordination problem between multiple changes. This solution will inevitably encounter some parts that have just been changed and are forced to change again with the matching design changes. The design change implementation order basically depends on the release order of the design definition, which is inconvenient to adjust. In addition, the prior art 1 is to manage according to the MBOM version, identify the difference points, that is, compare and analyze the new version of MBOM with the previous version of MBOM, and obtain the difference content. The difference content determines the impact of the change on the order and physical work-in-progress. This management method is not suitable for business fields with frequent changes in design change data and complex MBOM management structure. This solution will result in a large number of MBOM versions. Due to the complex MBOM structure, the MBOM version difference conversion rules that need to be established will be very complex and prone to errors. In addition, this solution directly drives orders and work-in-process disposal from the MBOM difference point, and cannot achieve data management in the small batch trial assembly stage. For example, in the automotive manufacturing industry, pre-batch verification is usually required for evolution. Each design variation is organized separately for pre-batch, which requires a large number of pre-batch vehicles and quality inspection and verification resources. At the same time, in each round of verification process, different part numbers may also be included. The above method directly leads to many links that require manual intervention, the process is cumbersome, and it is prone to errors.

[0052] Reference Figure 2 , is a schematic diagram of the window delivery mode in this application. Except for the design changes launched due to regulatory updates, they will be concentrated in several windows for delivery, to avoid the problem that the previous design change needs to be updated again as soon as the next design change is proposed after the previous design change is launched. It also avoids the problem that related design changes are launched at different time points, resulting in the inability to refer to each other's design content, leading to unreasonable design problems. After concentrating the design changes in several windows for delivery, the number of design changes during the annual model modification evolution can be reduced, making the implementation of changes throughout the year more evenly distributed.

[0053] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0054] In a first aspect, an embodiment of the present application provides a method for design change control.

[0055] In one embodiment, referring to Figure 3 , Figure 3 This is a flow chart of the first embodiment of the design and control method of this application. Figure 3 As shown, the design change control method includes:

[0056] Step S1, defining a plurality of evolution implementation windows and their window boundaries, each evolution implementation window corresponds to an evolution implementation time period, and the window boundary of the evolution implementation window is used to limit all software and hardware designs included in the window.

[0057] Step S2: configure multiple window classification marks for each evolution implementation window to obtain a mark management comparison table. The window classification marks are used to classify all software and hardware designs included in the window.

[0058] Step S3: according to the preset change implementation time, a switching flag is set under two adjacent evolution implementation windows in the flag management comparison table, and the switching flag is a window classification flag of the change of two adjacent evolution real-time windows.

[0059] Step S4: adding a switching flag to the design use cases of the software and hardware designs with design changes in two adjacent evolution real-time windows, and to all vehicle model codes in the vehicle model code database.

[0060] Step S5: After receiving the order information, the corresponding switching mark in the corresponding vehicle model code is obtained from the vehicle model code database according to the vehicle model code and order time contained in the order information, and the order time is in the evolution implementation time period corresponding to the obtained switching mark.

[0061] Step S6: According to the acquired switching flag, the software and hardware design with the corresponding switching flag in the design use case is obtained for implementation.

[0062] Step S1, step S2, and step S3 may be performed simultaneously.

[0063] In this embodiment, a flag management comparison table is configured in advance, which contains multiple evolution implementation windows, each of which corresponds to an evolution implementation time period. According to the preset design change implementation time, a switching flag is set under the adjacent evolution implementation window to describe the software and hardware design categories that have undergone design changes before and after. The switching flag is added to all vehicle model codes. After receiving the order information, the corresponding vehicle model code is searched and the switching flag whose time period covers the order time is extracted from it. According to the switching flag, the corresponding software and hardware design is extracted for implementation.

[0064] The present application limits the time period and scope of batch implementation of design changes by evolving the implementation window, marks the software and hardware design categories where design changes occur by switching marks, and adds switching marks to design use cases to facilitate searching for software and hardware designs that meet order time requirements based on order information, thereby efficiently and collaboratively managing design changes and improving the efficiency of design change management and control.

[0065] Furthermore, in one embodiment, the total number of all window classification flags included in each evolution implementation window in the flag management comparison table is the same, and each window classification flag includes a classification flag and a flag value.

[0066] The classification marks of two adjacent switching marks under two adjacent evolution implementation windows are the same and the mark values ​​are different, and the classification marks and mark data of other adjacent window classification marks except the two adjacent switching marks under two adjacent evolution implementation windows are the same.

[0067] In a specific embodiment, the planning of the general evolution implementation window (referred to as the window) will be about half a year to a year in advance, and it is determined in which quarter to organize a window, that is, to carry out a batch product upgrade. This approximate time is determined in advance, and the switching code is selected according to this approximate time, and the switching time is set in the code library. The switching code is the switching mark, and the switching time is the switching time of the evolution implementation window corresponding to the two switching marks. Next, the project team will start to plan the boundaries of this window - that is, which software and hardware need to be designed in this window. After the design department is determined, it will issue new definitions for these software and hardware. At this time, the switching mark can be added to the design use cases of these parts at the part level.

[0068] The synchronous upgrade of vehicle-mounted ECU hardware, ECU software, configuration parameters, etc. or the change of a batch of parts are abstractly defined as evolution implementation windows. At the same time, in order to meet multiple software upgrades and package evolutions within a year, multiple implementation windows are defined within a year, such as 2024 annual window 1, 2024 annual window 2, ..., 2024 annual window n. These window evolutions are associated with different window classification marks. These window evolutions are associated with a relatively specific implementation date that allows fine-tuning in the manufacturing field, that is, the evolution implementation time period, to achieve orderly implementation of package evolution in the design and manufacturing fields.

[0069] Combined with marketing planning, for a certain model product, complex and large-scale supporting changes and software upgrades are generally 1 to 3 times each year. Currently, 4 windows are defined each year to meet daily needs. At the same time, combined with regulatory events, business auto shows / business event needs, cold and hot zone experiments and other factors, the corresponding implementation time of the 4 windows is agreed to be March, May or July, September / October, November, etc.

[0070] If 4 windows are divided into one year and 8 window classification marks are used for management, the reuse period of all window classification marks is 2 years. Define 8 manufacturing mark classifications, the manufacturing mark classification code is F, and each manufacturing mark classification is rotated after 2 years of use, generating the mark management comparison table shown in Table 1 below.

[0071] Table 1 Sign management comparison

[0072]

[0073] According to the planned switching window, find the different window mark classification in the manufacturing mark management code comparison table as the control mark for this window switching. For example, a certain package change is implemented in September / October 2024. In the table below, it corresponds to 2024 Window 2-->2024 Window 3, and select the manufacturing code CC to control this window switching.

[0074] According to the planned product batch design change implementation time, the window switching marks found are CC11 and CC12. CC11 and CC12 are used as control marks for the switching of the two windows 2024 Window 2-2024 Window 3. Then add FCC11 and FCC12 to all vehicle model codes in the vehicle model code database. Later, when the product order information comes, search the database according to the vehicle model code and order time, and the switching mark found is either FCC11 or FCC12. If the order time falls into the window time period of 2024 Window 2 corresponding to CC11, then the switching mark obtained by splitting at the vehicle level based on the vehicle model code is FCC11. At this time, the parts level is split based on CC11, that is, all software and hardware designs including CC11 in the design use case are retrieved, and the vehicles required for the order are obtained by implementing these designs, that is, producing these software and hardware. If the order time falls within the window time period of 2024 Window 3 corresponding to CC12, the switching mark obtained by splitting the whole vehicle layer based on the model code is FCC12. At this time, the parts layer is split based on CC11, that is, all software and hardware designs including CC12 in the design use case are retrieved, and the vehicles required for the order are obtained by implementing these designs, that is, producing these software and hardware.

[0075] Reference Figure 4 , is a schematic diagram of the vehicle model code and the corresponding window switching in a specific embodiment of the present application. The vehicle model code includes a product configuration code starting with D and a manufacturing configuration code starting with F. The code starting with D is a description mark, which is used to describe some basic configurations that will not change in the vehicle model, such as a performance or structure of the vehicle. The letters in the description mark indicate the design category, and the numbers in the description mark indicate whether it has a sunroof or no sunroof, or whether it has LED headlights or no LED headlights. The code starting with F is a variation of the manufacturing switching mark, which is used to match the order time with the order information later. If any match is found, all the software and hardware designs corresponding to that switching mark will be retrieved to produce the order.

[0076] In the configured MBOM, add the switch flag to the use case logic expression of the relevant part. Figure 5 , which is a schematic diagram of a design use case in a specific embodiment of the present application, the logical expression of software_A represents the definition used before 2024 window 3, and software_B represents the definition used after 2024 window 3.

[0077] Reference Figure 6 , which is a schematic diagram of splitting the vehicle layer and the parts layer according to order information in a specific embodiment of the present application. According to the data splitting principle of the configured MBOM data, the vehicle orders before the 2024 window 3 switching time will be split into the FCC11 mark at the vehicle layer, and will be split into all parts associated with this manufacturing mark through FCC11 at the parts layer, such as software_A parts. Similarly, the vehicle orders after the 2024 window 3 switching time will be split into the FCC12 mark at the vehicle layer, and will be split into all parts associated with this manufacturing mark through CC12 at the parts layer, such as software_B parts.

[0078] This is achieved by selecting the corresponding window mark to obtain the corresponding part definition and its supporting relationship.

[0079] In some other embodiments, if one year is divided into three windows and eight window classification identifiers are used for management, the reuse period of all window classification identifiers is 2 years + 2 windows. At this time, a flag management comparison table as shown in Table 2 below is generated.

[0080] Table 2 Sign management comparison table

[0081]

[0082] If 4 windows are divided into one year and 4 types of window classification marks are used for management, the reuse period of all window classification marks is 2 years + 2 windows. At this time, the mark management comparison table shown in Table 3 below is generated.

[0083] Table 3 Sign management comparison table

[0084]

[0085] Furthermore, in one embodiment, all vehicle model codes in the vehicle model code database have a first valid time period.

[0086] According to the vehicle model code and order time included in the order information, a corresponding switching mark in the corresponding vehicle model code within the first valid time period is extracted from the vehicle model code data.

[0087] The vehicle model code also includes a description mark, which is used to describe the basic design included in the vehicle model. The description mark has a second valid period.

[0088] According to the vehicle model code and order time included in the order information, the corresponding switching mark in the corresponding vehicle model code within the first valid time period and the description mark within the second valid time period are extracted from the vehicle model code database.

[0089] In this embodiment, refer to Figure 7 , which is a schematic diagram of vehicle type coding with valid time periods in a specific embodiment of the present application. The vehicle type itself can have a first valid time period, and the description mark and the switching mark can also have a second valid time period. When extracting marks according to the order time, the marks that are valid at the order time are extracted to improve the precision of mark management and design change implementation management.

[0090] Furthermore, in one embodiment, the method further includes:

[0091] Add an early trigger condition to the design use case where a toggle flag is added.

[0092] After receiving the order information for pre-batch production, the advance trigger information contained in the order information is extracted.

[0093] When it is determined that the advance trigger information meets the advance trigger condition, the switching mark extracted from the vehicle model coding database according to the order information is the switching mark corresponding to the next evolution implementation time period of the evolution implementation time period in which the order time is located.

[0094] In this embodiment, after the driver code C11B is included in the pre-batch vehicle order, the new code CC12 can be effective before the implementation date corresponding to the window, and the new part software B can be effective. The driving condition is represented by SI:001, which means that if the condition after SI:001 is met, the above code is driven. That is, if the order information contains the advance trigger information C11B, and C11B just meets the condition after SI:001 in the design use case, when the time period CC11 that the order time should fall into is originally extracted, CC11 is not extracted but CC12 is extracted, so that the design change corresponding to CC12 is implemented in advance.

[0095] In summary, the present invention can realize the advance planning of the design change window of the vehicle model project within a few years. Combined with the boundaries of annual auto shows, regulations, etc., the project plans the vehicle model launch window in advance, and the driver design major matches the detailed design work according to the installation window plan.

[0096] All design changes can be matched with appropriate windows to achieve coordination. Especially when applied to the current vehicle software iteration management, the matching relationship between ECU software and vehicle software versions can be accurately defined through various signs, and the implementation sequence can be accurately controlled through the time of the window sign. The expected implementation date can also be determined in the form of a window sign. By adding this method, the process of change implementation of the product throughout its life cycle is greatly facilitated.

[0097] The pre-batch and delivery of design changes within the window can greatly save industrial resources and ensure the stability of vehicle quality. Through the window mark, all relevant parts can also be screened out, and it is convenient to identify which parts have undergone design changes, which is convenient for after-sales and clear tracing of design change history.

[0098] Realize pre-batch loading data management without manual intervention.

[0099] The parts included in the window evolution are directly defined by the relevant window codes, and the expected implementation date can also be determined in the form of window marks, reducing manual intervention in packaging evolution. By setting special marks for window marks, pre-batch data management is automatically driven, and pre-batch data is verified by the system in advance without manual intervention.

[0100] BOM maintenance and adjustment are flexible, and multiple window definitions can be managed at the same time. When the design window changes, it can be realized by simply adjusting the window mark logic of the part matching.

[0101] In a second aspect, an embodiment of the present application also provides a system for controlling and managing equipment changes.

[0102] In one embodiment, referring to Figure 8 , Figure 8 This is a functional module diagram of an embodiment of the control system of this application. Figure 8 As shown in the figure, the design change control system includes:

[0103] Table configuration module 1 is used to define multiple evolution implementation windows and their window boundaries. Each evolution implementation window corresponds to an evolution implementation time period. The window boundary of the evolution implementation window is used to limit all software and hardware designs contained in the window. It is also used to configure multiple window classification flags for each evolution implementation window to obtain a flag management comparison table. The window classification flag is used to classify all software and hardware designs contained in the window. It is also used to set a switching flag under two adjacent evolution implementation windows in the flag management comparison table according to the preset design change implementation time. The switching flag is the window classification flag of the change of two adjacent evolution real-time windows.

[0104] The data preprocessing module 2 is used to add the switching flag to the design use cases of the software and hardware designs with design changes in two adjacent evolution real-time windows, and to all vehicle model codes in the vehicle model code database.

[0105] The order processing module 3 is used to obtain the corresponding switching mark in the corresponding vehicle model code from the vehicle model code database according to the vehicle model code and order time contained in the order information after receiving the order information, and the order time is in the evolution implementation time period corresponding to the obtained switching mark.

[0106] The design change implementation module 4 is used to obtain the software and hardware design with the corresponding switching mark in the design case according to the acquired switching mark for implementation.

[0107] The vehicle model code database 5 is used to store vehicle model codes.

[0108] In this embodiment, a flag management comparison table is configured in advance, which contains multiple evolution implementation windows, each of which corresponds to an evolution implementation time period. According to the preset design change implementation time, a switching flag is set under the adjacent evolution implementation window to describe the software and hardware design categories that have undergone design changes before and after. The switching flag is added to all vehicle model codes. After receiving the order information, the corresponding vehicle model code is searched and the switching flag whose time period covers the order time is extracted from it. According to the switching flag, the corresponding software and hardware design is extracted for implementation.

[0109] The present application limits the time period and scope of batch implementation of design changes by evolving the implementation window, marks the software and hardware design categories where design changes occur by switching marks, and adds switching marks to design use cases to facilitate searching for software and hardware designs that meet order time requirements based on order information, thereby efficiently and collaboratively managing design changes and improving the efficiency of design change management and control.

[0110] Among them, the functional implementation of each module in the above-mentioned design change control system corresponds to the various steps in the above-mentioned design change control method embodiment, and its functions and implementation processes will not be repeated here one by one.

[0111] It should be noted that the serial numbers of the above-mentioned embodiments of the present application are only for description and do not represent the advantages or disadvantages of the embodiments.

[0112] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit "first", "second" and "third" to different types.

[0113] In the description of the embodiments of the present application, "exemplary", "for example" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary", "for example" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary", "for example" or "for example" is intended to present related concepts in a specific way.

[0114] In the description of the embodiments of the present application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; the “and / or” in the text is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, “multiple” refers to two or more than two.

[0115] In some processes described in the embodiments of the present application, multiple operations or steps that appear in a specific order are included, but it should be understood that these operations or steps may not be executed in the order in which they appear in the embodiments of the present application or in parallel, and the sequence number of the operation is only used to distinguish the different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed in sequence or in parallel, and these operations or steps may be combined.

[0116] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD) as described above, and includes a number of instructions for a terminal device to execute the methods described in each embodiment of the present application.

[0117] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A design change control method, characterized in that: The method comprises: Define multiple evolution implementation windows and their window boundaries, each evolution implementation window corresponds to an evolution implementation time period, and the window boundary of the evolution implementation window is used to limit all software and hardware designs included in the window; A plurality of window classification marks are configured for each evolution implementation window to obtain a mark management comparison table, wherein the window classification marks are used to classify all software and hardware designs included in the window; According to the preset design change implementation time, a switching flag is set under two adjacent evolution implementation windows in the flag management comparison table, and the switching flag is a window classification flag of the change of two adjacent evolution real-time windows; Add a switching flag to the design use cases of the software and hardware designs with design changes in two adjacent evolution real-time windows, and to all vehicle model codes in the vehicle model code database; After receiving the order information, according to the vehicle model code and order time contained in the order information, the corresponding switching mark in the corresponding vehicle model code is obtained from the vehicle model code database, and the order time is in the evolution implementation time period corresponding to the obtained switching mark; According to the acquired switching flag, the software and hardware design with the corresponding switching flag in the design use case is obtained for implementation.

2. The design change control method according to claim 1, characterized in that: The total number of all window classification marks included in each evolution implementation window in the mark management comparison table is the same, and each window classification mark includes a classification mark and a mark value; The classification marks of two adjacent switching marks under two adjacent evolution implementation windows are the same and the mark values ​​are different, and the classification marks and mark data of other adjacent window classification marks except the two adjacent switching marks under two adjacent evolution implementation windows are the same.

3. The design change control method according to claim 1, characterized in that: All vehicle model codes in the vehicle model code database have a first valid time period; According to the vehicle model code and order time included in the order information, a corresponding switching mark in the corresponding vehicle model code within the first valid time period is extracted from the vehicle model code data.

4. The design change control method according to claim 1, characterized in that: The vehicle model code also includes a description mark, which is used to describe the basic design included in the vehicle model, and the description mark has a second valid time period; According to the vehicle model code and order time included in the order information, the corresponding switching mark in the corresponding vehicle model code within the first valid time period and the description mark within the second valid time period are extracted from the vehicle model code database.

5. The design change control method according to claim 1, characterized in that: The method further comprises: Add early trigger conditions to the design use case where the toggle flag is added; After receiving the order information for pre-batch production, extracting the advance trigger information contained in the order information; When it is determined that the advance trigger information meets the advance trigger condition, the switching mark extracted from the vehicle model coding database according to the order information is the switching mark corresponding to the next evolution implementation time period of the evolution implementation time period in which the order time is located.

6. A design change control system, characterized in that: The system comprises: A table configuration module, which is used to define multiple evolution implementation windows and their window boundaries, each evolution implementation window corresponds to an evolution implementation time period, and the window boundary of the evolution implementation window is used to limit all software and hardware designs contained in the window; it is also used to configure multiple window classification flags for each evolution implementation window to obtain a flag management comparison table, and the window classification flag is used to classify all software and hardware designs contained in the window; it is also used to set a switching flag under two adjacent evolution implementation windows in the flag management comparison table according to a preset design change implementation time, and the switching flag is a window classification flag of the change of two adjacent evolution real-time windows; A data preprocessing module, which is used to add a switching flag to the design use cases of the software and hardware designs with design changes in two adjacent evolution real-time windows, and to all vehicle model codes in the vehicle model code database; An order processing module, which is used to obtain the corresponding switching mark in the corresponding vehicle model code from the vehicle model code database according to the vehicle model code and order time contained in the order information after receiving the order information, and the order time is in the evolution implementation time period corresponding to the obtained switching mark; A design change implementation module, which is used to obtain the software and hardware design with the corresponding switching flag in the design case according to the acquired switching flag for implementation; The vehicle model code database is used to store vehicle model codes.

7. The design change control method according to claim 6, characterized in that: The total number of all window classification marks included in each evolution implementation window in the mark management comparison table is the same, and each window classification mark includes a classification mark and a mark value; The classification marks of two adjacent switching marks under two adjacent evolution implementation windows are the same and the mark values ​​are different, and the classification marks and mark data of other adjacent window classification marks except the two adjacent switching marks under two adjacent evolution implementation windows are the same.

8. The design change control system according to claim 6, characterized in that: All vehicle model codes in the vehicle model code database have a first valid time period; The order processing module is used to extract the corresponding switching mark in the corresponding vehicle model code within the first valid time period from the vehicle model code data according to the vehicle model code and order time contained in the order information.

9. The design change control system according to claim 6, characterized in that: The vehicle model code also includes a description mark, which is used to describe the basic design included in the vehicle model, and the description mark has a second valid time period; The order processing module is used to extract the corresponding switching mark in the corresponding vehicle model code within the first valid time period and the description mark within the second valid time period from the vehicle model code database according to the vehicle model code and order time contained in the order information.

10. The design change control method according to claim 6, characterized in that: The data preprocessing module is used to add an advance trigger condition to the design use case with the switching flag added; The order processing module is used to extract the advance trigger information contained in the order information after receiving the order information of the pre-batch production; When it is determined that the advance trigger information meets the advance trigger condition, the switching mark extracted from the vehicle model coding database according to the order information is the switching mark corresponding to the next evolution implementation time period of the evolution implementation time period in which the order time is located.

Images