Bom synchronization processing method and device based on bom middle station, and medium

Abstract

This invention relates to the field of vehicle technology, specifically providing a BOM synchronization processing method, device, and medium based on a BOM middleware platform, aiming to solve the problem of efficiently and reliably utilizing EBOM to generate, manage, and trace BOMs and data. To this end, the method provided by this invention includes controlling the BOM middleware platform to send EBOM synchronization requests to upstream systems, receiving and storing EBOM data sent by upstream systems, controlling the BOM middleware platform to generate and store MBOMs based on the EBOM data, responding to upstream systems to modify MBOM data, and responding to downstream systems to send relevant data to downstream systems. Communication between the BOM middleware platform, upstream systems, and downstream systems is based on a message middleware-based communication method, and the communication initiator's identification information is carried during communication. This method enables efficient and reliable generation and management of BOMs using EBOMs and effective data traceability.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and specifically to a BOM synchronization processing method, device, and medium based on a BOM platform. Background Technology

[0002] Currently, conventional methods for managing Bill of Materials (BOMs) primarily utilize standard BOM software to generate and manage various types of BOMs required for business operations, including but not limited to Engineering Bill of Material (EBOM), Process Bill of Material (PBOM), and Manufacturing Bill of Material (MBOM). For example, Dassault Systèmes' 3DExperience (3DE) platform can be used to generate and manage the various types of BOMs needed for business operations.

[0003] However, with increasing business volume and complexity, conventional BOM software often fails to meet the performance requirements of high-volume and high-complexity BOM management. This is especially true when generating PBOM, MBOM, and other types of BOMs from the EBOM, which presents numerous technical challenges. This results in the inefficiency and unreliability in obtaining these various BOM types, impacting business implementation and expansion. Furthermore, conventional BOM software primarily uses Excel data transfer or APIs (Application Programming Interfaces) for data transfer. Neither of these methods allows for data traceability (or tracking), hindering rapid response to BOM changes and ultimately impacting business progress.

[0004] Accordingly, a new technical solution is needed in this field to solve the above problems. Summary of the Invention

[0005] To overcome the above-mentioned deficiencies, this invention is proposed to provide a BOM synchronization processing method, device and medium based on a BOM platform that solves or at least partially solves the technical problems of how to efficiently and reliably utilize EBOM to generate and manage various types of BOM such as MBOM, and how to effectively trace BOM data.

[0006] In a first aspect, a BOM synchronization processing method based on a BOM middleware platform is provided, the method comprising:

[0007] The system controls the preset BOM platform to send EBOM synchronization requests to the upstream system, and receives and stores the EBOM data sent by the upstream system according to the EBOM synchronization requests.

[0008] The system controls the preset BOM platform to generate and store MBOM based on EBOM data, respond to MBOM change requests sent by upstream systems to change MBOM data, and respond to EBOM data and / or MBOM retrieval requests sent by downstream systems to send EBOM data and / or MBOM to downstream systems.

[0009] The pre-defined BOM platform, upstream system and downstream system communicate using a message middleware-based communication method and carry the identification information of the communication initiator during communication.

[0010] In one technical solution of the BOM synchronization processing method based on the BOM middle platform mentioned above, the step of "storing the EBOM data issued by the upstream system according to the EBOM synchronization request" specifically includes:

[0011] Compress the EBOM data;

[0012] The compressed EBOM data is stored in a preset cache in the BOM platform so that the BOM platform can be controlled to generate MBOM and / or modify MBOM data and / or send EBOM data to downstream systems based on the EBOM data in the preset cache.

[0013] In one technical solution of the BOM synchronization processing method based on the BOM middle platform mentioned above, the step of "compressing the EBOM data" specifically includes:

[0014] The EBOM data is serialized to form a serialized file;

[0015] The serialized file is compressed using a compression algorithm.

[0016] In one technical solution of the BOM synchronization processing method based on the BOM middleware mentioned above, the step of "changing the MBOM data in response to the MBOM change request sent by the upstream system" includes:

[0017] Identify the change scenario corresponding to the MBOM change request;

[0018] Obtain the change responsibility chain that matches the change scenario;

[0019] Based on the aforementioned chain of responsibility for changes, data changes are made to the MBOM;

[0020] The change responsibility chain includes multiple sequentially executed change processing nodes, each configured to perform different change processing operations.

[0021] In one technical solution of the BOM synchronization processing method based on the BOM middle platform mentioned above, the step of "identifying the change scenario corresponding to the MBOM change request" specifically includes:

[0022] Get the request type of the MBOM change request;

[0023] Identify the change scenario corresponding to the request type;

[0024] The request types include at least CA (Change Action) requests, CR (Change Request) requests, and PCO (Protocol Configuration Option) requests.

[0025] Furthermore, the change scenarios corresponding to CA requests, CR requests, and PCO requests are respectively the first release scenario of a part, the change scenario of a part, and the change scenario of a part configuration expression.

[0026] In one technical solution of the above-mentioned BOM synchronization processing method based on a BOM middle platform, the step of "identifying the change scenario corresponding to the request type" specifically includes:

[0027] If the request type is a CR request, then obtain the CA (Change Action) node information contained in the MBOM change request;

[0028] Obtain the change intent carried by each CA node information;

[0029] Obtain the corresponding part change scenario for each change intention.

[0030] In one technical solution of the above-mentioned BOM synchronization processing method based on a BOM middle platform, the step of "controlling the preset BOM middle platform to send an EBOM synchronization request to the upstream system" specifically includes:

[0031] Obtain the structure tree type of the structure tree of the part to be synchronized, where the part structure tree is tree structure data used to represent the EBOM;

[0032] The BOM platform controls the generation of EBOM synchronization requests for each type of structure tree, and sends the EBOM synchronization requests to the upstream system so that the corresponding part structure tree can be obtained from the upstream system.

[0033] In one technical solution of the above-mentioned BOM synchronization processing method based on BOM platform, the method further includes: using a preset relational database in the BOM platform to store EBOM data and MBOM respectively.

[0034] In a second aspect, a computer device is provided, comprising a processor and a storage device, the storage device being adapted to store a plurality of program codes, the program codes being adapted to be loaded and executed by the processor to perform the method described in any of the technical solutions of the above-described BOM synchronization processing method.

[0035] In a third aspect, a computer-readable storage medium is provided, wherein a plurality of program codes are stored therein, the program codes being adapted to be loaded and run by a processor to perform the method described in any of the technical solutions of the above-described BOM synchronization processing method.

[0036] The above-described technical solutions of the present invention have at least one or more of the following beneficial effects:

[0037] In the technical solution of the BOM synchronization processing method based on a BOM middle platform provided by this invention, the preset BOM middle platform can be controlled to send EBOM synchronization requests to the upstream system, and to receive and store EBOM data sent by the upstream system according to the EBOM synchronization requests. The preset BOM middle platform can also be controlled to generate and store MBOM based on the EBOM data, to modify the MBOM data in response to MBOM change requests sent by the upstream system, and to send EBOM data and / or MBOM to the downstream system in response to EBOM data and / or MBOM retrieval requests sent by the downstream system. The preset BOM middle platform, the upstream system, and the downstream system communicate using a message middleware-based communication method, and the communication initiator's identification information is carried during communication.

[0038] An upstream system is a system capable of generating at least EBOM data. In this technical solution, the upstream system can be BOM software responsible for generating and managing various types of BOMs required by the business. Through this solution, after generating the EBOM through the upstream system, multiple tasks such as EBOM storage, MBOM generation, MBOM modification, MBOM forwarding, and MBOM storage can be decoupled and executed on the BOM platform. Even when facing high business volume and complex BOM management needs, it can efficiently and reliably utilize EBOM to generate and manage various types of BOMs, including MBOMs.

[0039] Furthermore, since the BOM platform, upstream systems, and downstream systems carry the initiator's identification information when communicating, the source of data transmitted in each communication can be accurately traced based on this identification information. This allows for a rapid response to changes in the BOM data even if the source is traced, preventing disruption to business implementation schedules. Attached Figure Description

[0040] The disclosure of this invention will become more readily understood with reference to the accompanying drawings. It will be readily understood by those skilled in the art that these drawings are for illustrative purposes only and are not intended to limit the scope of protection of this invention. Wherein:

[0041] Figure 1 This is a schematic flowchart of the main steps of a BOM synchronization processing method based on a BOM middle platform according to an embodiment of the present invention.

[0042] Figure 2 This is a schematic flowchart of the main steps of a method for modifying an MBOM according to an embodiment of the present invention;

[0043] Figure 3 This is a schematic diagram of the communication interaction process between the BOM middleware and the upstream system according to an embodiment of the present invention;

[0044] Figure 4 This is a schematic diagram of the main structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0045] Some embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0046] In the description of this invention, "processor" can include hardware, software, or a combination of both. A processor can be a central processing unit, microprocessor, image processor, digital signal processor, or any other suitable processor. The processor has data and / or signal processing capabilities. The processor can be implemented in software, in hardware, or a combination of both. Computer-readable storage media includes any suitable medium capable of storing program code, such as magnetic disks, hard disks, optical disks, flash memory, read-only memory, random access memory, etc.

[0047] The following describes an embodiment of the BOM synchronization processing method provided by the present invention.

[0048] See appendix Figure 1 , Figure 1 This is a schematic flowchart illustrating the main steps of a BOM synchronization processing method according to an embodiment of the present invention. Figure 1As shown, the BOM synchronization processing method in this embodiment of the invention mainly includes the following steps S101 to S102.

[0049] Step S101: Control the preset BOM platform to send EBOM synchronization requests to the upstream system and receive and store the EBOM data sent by the upstream system according to the EBOM synchronization requests.

[0050] An upstream system is a system capable of generating at least EBOM data. In embodiments of this invention, the upstream system may be BOM software responsible for generating and managing various types of BOMs required for business operations. In some preferred embodiments, the upstream system may be 3DE provided by Dassault Systèmes.

[0051] Downstream systems refer to systems that require data such as EBOM (External Embedded Item Data) provided by the BOM platform to achieve their respective functions. In the field of vehicle technology, the materials involved in the BOM can be vehicle parts. In this case, downstream systems can include at least Firmware Over The Air (FOTA) systems, Service Engineering Systems (SES) systems, and Global Purchasing Systems (GPS) systems.

[0052] EBOM synchronization requests can be generated by the BOM platform itself or input into the BOM platform via a human-machine interface. In the field of vehicle technology, when multiple vehicle models exist, an EBOM synchronization request can be a request to obtain EBOM data for one or more vehicle models, containing vehicle model information. After receiving the EBOM synchronization request, the upstream system can generate the corresponding vehicle model's EBOM data based on the vehicle model information, and then send the generated EBOM to the BOM platform.

[0053] Step S102: Control the preset BOM platform to generate and store MBOM based on EBOM data, respond to MBOM change requests sent by upstream systems to change MBOM data, and respond to EBOM data and / or MBOM acquisition requests sent by downstream systems to send EBOM data and / or MBOM to downstream systems.

[0054] In this embodiment of the invention, the BOM platform has multiple functions such as MBOM generation, MBOM modification, MBOM forwarding, and MBOM storage.

[0055] After receiving EBOM data from the upstream system, the BOM platform automatically generates and stores the MBOM. Change requests from the upstream system can include information such as the type of data to be changed and the content of the changed data. Upon receiving the change request, the BOM platform can modify the stored MBOM based on this information. Taking 3DE as an example, after receiving an EBOM synchronization request, 3DE can query the corresponding EBOM data, encapsulate it into JSON structure data, and then send the JSON structure data to the BOM platform. The JSON structure data mainly includes part nodes and relation row nodes. Part nodes store the main information of the parts, and relation row nodes store the relation rows of the parts. The BOM platform parses the JSON structure data, converts the parsed result into a Java tree, and then stores the main information of each part in the part table and the relation rows of each part in the relation table based on this Java tree.

[0056] The retrieval request sent by the downstream system can include the type of request (EBOM data request or MBOM retrieval request) and the identification information of the downstream system. After receiving the retrieval request, the BOM platform can send the corresponding data (EBOM data or MBOM) to the downstream system specified by the identification information.

[0057] In this embodiment of the invention, the BOM platform, upstream system and downstream system communicate using a message-oriented middleware-based communication method and carry the identification information of the communication initiator during communication.

[0058] For example, when the BOM middleware sends an EBOM synchronization request to the upstream system, it uses a message middleware-based communication method. Simultaneously, it also sends the identifier of the communication initiator, i.e., the BOM middleware's own identifier. Similarly, the upstream system also uses a message middleware-based communication method to send EBOM data to the BOM middleware, and simultaneously sends the identifier of the communication initiator, i.e., the upstream system's own identifier. The communication process between the BOM middleware and the downstream system is similar to the above process and will not be repeated here. It should be noted that the above embodiments do not involve direct communication between the upstream and downstream systems. However, direct communication between the upstream and downstream systems can be flexibly controlled according to actual needs. The communication method can also be a message middleware-based method, carrying the identifier of the communication initiator during communication.

[0059] It should be noted that, in the embodiments of the present invention, conventional message middleware-based communication methods in the field of communication technology can be used to realize communication between the BOM middleware, upstream systems, and downstream systems. The embodiments of the present invention do not specifically limit the type of message middleware. For example, in some preferred embodiments, Kafka can be used. Furthermore, in some embodiments, ActiveMQ, RabbitMQ, or RocketMQ can also be used.

[0060] Based on the methods described in steps S101 to S102 above, after the EBOM is generated through the upstream system, various tasks such as EBOM storage, MBOM generation, MBOM modification, MBOM forwarding, and MBOM storage can be decoupled and executed on the BOM platform. Even when facing high business volume and high complexity BOM management requirements, various types of BOMs, such as MBOMs, can be generated and managed efficiently and reliably using the EBOM. Furthermore, since each communication carries the identification information of the communication initiator, even if the BOM data changes, the source of the data transmitted in each communication can be accurately traced based on this identification information, thereby quickly responding to changes and avoiding impact on the progress of business implementation.

[0061] The following provides further explanation of steps S101 and S102.

[0062] I. Explanation of step S101.

[0063] The following sections describe the methods for controlling the BOM middleware to send EBOM synchronization requests to the upstream system, and the methods for storing the EBOM data sent by the upstream system.

[0064] (a) Method for controlling the BOM middle platform to send EBOM synchronization requests to the upstream system.

[0065] EBOM data can be represented as tree-structured data; therefore, EBOM is essentially a part structure tree. In practical applications, depending on different BOM construction requirements, there may be multiple part structure trees corresponding to an EBOM. For example, in some preferred implementations of a vehicle BOM, an EBOM for a vehicle model can correspond to two types of part structure trees: DWIP (Design Working in Progress Structure) and VPPS (Vehicle Partitioning & Product Structure). DWIP is a part structure tree generated based on the engineering design process, and its main function is to collaboratively confirm the vehicle development environment during vehicle development. VPPS is a part structure tree generated based on the vehicle hardware architecture, and its main function is to support rapid part retrieval and design function allocation during vehicle development.

[0066] It should be noted that the "parts" in the embodiments of this invention refer to the most basic unit or smallest management unit of the BOM. All operations on the BOM, such as EBOM synchronization and MBOM changes mentioned in this invention, are performed using this most basic unit as the smallest dimension. That is, all BOM synchronization and changes must be updated to the aforementioned most basic unit. The "parts" in the embodiments of this invention can be represented as System Variant, or SV.

[0067] Since there may be multiple part structure trees corresponding to the EBOM, it is possible to first determine which type of part structure tree needs to be synchronized, and then generate a synchronization request corresponding to that part structure tree to obtain the part structure tree from the upstream system. Specifically, in this embodiment of the invention, the BOM platform can be controlled to send an EBOM synchronization request to the upstream system through the following steps 11 to 12.

[0068] Step 11: Obtain the structure tree type of the part structure tree to be synchronized. The part structure tree is tree structure data used to represent the EBOM. For example, the structure tree type of the part structure tree to be synchronized can include DWIP and VPPS.

[0069] Step 12: Control the BOM platform to generate EBOM synchronization requests for each structure tree type, and send these requests to the upstream system. This allows the upstream system to retrieve the corresponding part structure tree types. For example, if the structure tree types include DWIP and VPPS, the BOM platform can generate EBOM synchronization requests for DWIP and VPPS respectively, and then send these requests to the upstream system. The upstream system can then issue DWIP and VPPS requests accordingly.

[0070] Based on the methods described in steps 11 to 12 above, the structure tree of each part to be synchronized can be accurately obtained from the upstream system, thereby ensuring the accuracy of EBOM synchronization.

[0071] (ii) Methods for storing EBOM data sent from the upstream system.

[0072] In some embodiments of step S101 above, the EBOM data sent by the upstream system can be stored through the following steps 21 to 22.

[0073] Step 21: Compress the EBOM data.

[0074] Compression can reduce the size of EBOM data, thus reducing its storage space requirements. In this embodiment of the invention, conventional compression algorithms from the computer technology field can be used to compress the EBOM data; however, this embodiment does not impose specific limitations on this method. For example, in some preferred embodiments, the GZIP compression algorithm can be used.

[0075] To further reduce the storage space occupied by EBOM data, in some embodiments, the EBOM data can be first serialized to form a serialized file, and then compressed using a compression algorithm. Serialization can reduce the size of the EBOM data to a certain extent, and further compression using a compression algorithm can greatly reduce the size of the EBOM data. For example, in some embodiments, the above method can reduce 40MB of EBOM data to 1MB. In the embodiments of the present invention, conventional serialization methods in the field of computer technology can be used to serialize the EBOM data, and the embodiments of the present invention do not specifically limit this.

[0076] Step 22: Store the compressed EBOM data in the preset cache in the BOM platform so that the BOM platform can be controlled to generate MBOM and / or modify MBOM data and / or send EBOM data to downstream systems based on the EBOM data in the preset cache.

[0077] In this embodiment of the invention, conventional caching techniques in the field of computer technology can be used to set the preset cache in the BOM platform, and this embodiment of the invention does not impose specific limitations on this. For example, in some preferred embodiments, Redis (Remote Dictionary Server) can be used to set the preset cache in the BOM platform.

[0078] Based on the methods described in steps 21 to 22 above, storing EBOM data in a preset cache allows for rapid processing or retrieval of EBOM data, thereby enabling efficient MBOM production, modification, and forwarding.

[0079] Furthermore, to reliably and persistently store EBOM data, in some embodiments of step S101 above, in addition to storing EBOM data through the aforementioned preset cache, a relational database can be set up in the BOM platform, and then this relational database can be used to store the EBOM data and MBOM. It should be noted that in the embodiments of the present invention, a conventional relational database from the field of computer technology can be used to set up the database in the BOM platform; the embodiments of the present invention do not specifically limit this. For example, in some preferred embodiments, MySQL can be used to set up the relational database in the BOM platform.

[0080] II. Explanation of step S102.

[0081] The following explains the methods for changing the MBOM.

[0082] See appendix Figure 2 In some embodiments of step S102 above, the following steps S1021 to S1023 can be used to control the BOM middle platform to make data changes to the MBOM according to the MBOM change request sent by the upstream system.

[0083] Step S1021: Identify the change scenario corresponding to the MBOM change request.

[0084] In this embodiment of the invention, the correspondence between different MBOM change requests and different change scenarios can be pre-set. After obtaining the MBOM change request, the matching is performed according to this correspondence to obtain the change scenario corresponding to the MBOM change request.

[0085] Change scenarios can be categorized based on the purpose of the change. For example, in some preferred embodiments, change scenarios include, but are not limited to, the initial release scenario of a part, the change scenario of a part, and the change scenario of a part configuration expression. In the embodiments of this invention, the part also refers to the most basic unit SV of the BOM.

[0086] Step S1022: Obtain the change responsibility chain that matches the change scenario.

[0087] In this embodiment of the invention, the correspondence between different change scenarios and different change responsibility chains can be pre-set. After obtaining the change scenario, the matching is performed according to this correspondence to obtain the change responsibility chain that matches the change scenario.

[0088] The change responsibility chain comprises multiple sequentially executed change processing nodes. Each change processing node is configured to perform different change processing operations, and all change processing nodes collectively implement the data changes to the MBOM. When constructing the change responsibility chain, first determine the types of all change processing operations that need to be performed based on the change scenario, as well as the execution order of each type of change processing operation. Then, set the change processing nodes according to the type and execution order of the change processing operations, with each change processing node corresponding one-to-one with each change processing operation. Finally, based on the set change processing nodes and the execution order among them, the change responsibility chain is formed.

[0089] Step S1023: Make data changes to MBOM based on the changed chain of responsibility.

[0090] Specifically, MBOM data can be input into the change responsibility chain, and then sequentially enter each change processing node to perform different change processing operations. The output data of the change responsibility chain is the MBOM after the data change is completed.

[0091] As described in step S101 above, the BOM platform can also be configured with a relational database, which can store the MBOM. Therefore, after the MBOM is changed, the changed MBOM can still be stored in this relational database.

[0092] Based on the methods described in steps S1021 to S1023 above, multiple different change processing nodes can be aggregated into the same change responsibility chain, giving the change processing operation the advantage of high aggregation. Simultaneously, each change processing node in the change responsibility chain executes its corresponding change processing operation independently, thus decoupling the various change processing operations and giving them the advantage of low coupling. This also improves the scalability of change scenarios.

[0093] The following provides a further explanation of step S1021.

[0094] In some implementations of step S1021 above, the change scenario corresponding to the MBOM change request can be identified through the following steps 31 to 32.

[0095] Step 31: Obtain the request type of the MBOM change request.

[0096] Step 32: Identify the change scenario corresponding to the request type.

[0097] In this embodiment of the invention, the correspondence between different request types and different change scenarios can be pre-set. After obtaining the request type, the matching is performed according to this correspondence to obtain the change scenario corresponding to the request type.

[0098] In this embodiment of the invention, the request types include at least three types: CA (Change Action) request, CR (Change Request) request, and PCO (Protocol Configuration Option) request. The change scenarios corresponding to CA request, CR request, and PCO request are respectively the first release scenario of the part, the change scenario of the part, and the change scenario of the part configuration expression.

[0099] Furthermore, when the request type is a CR request, there may be various different types of changes, and the change scenarios corresponding to different types of changes may be different. Therefore, in some preferred embodiments, when the request type is a CR request, the CA (Change Action) nodes contained in the MBOM change request can be obtained, and then the change intent carried by each CA node can be obtained, and the part change scenario corresponding to each change intent can be obtained. In this embodiment of the invention, the correspondence between different change intents and different change scenarios can be pre-set. After obtaining the change intent, matching is performed according to this correspondence to obtain the change scenario corresponding to the change intent.

[0100] Based on the methods described in steps 31 to 32 above, the change scenario corresponding to the MBOM change request can be accurately identified by utilizing the request type of the MBOM change request, thereby improving the accuracy and reliability of data changes to the MBOM.

[0101] The following is in conjunction with the appendix Figure 3 This paper briefly describes the communication and interaction process between the BOM middleware and the upstream system in this embodiment of the invention. Figure 3 In this context, MQ stands for Message Queue of the message middleware. Full data means that the EBOM data obtained by the BOM middleware from the upstream system is full data, and incremental data means that the modified data obtained by the BOM middleware from the upstream system when making MBOM changes is incremental data.

[0102] 1. Control the BOM platform to synchronize EBOM data.

[0103] like Figure 3 As shown, the BOM platform first sends an EBOM synchronization request to the upstream system using a message queue (MQ). The upstream system consumes this EBOM synchronization request based on the MQ, asynchronously generates EBOM data, and sends two MQ messages: Message 1 and Message 2. Message 1 is an event message indicating successful EBOM data generation, and Message 2 is a message containing the EBOM data. The BOM platform consumes these two messages based on the MQ, asynchronously retrieves the EBOM data from Message 2, and stores the EBOM data in the database. For example, the EBOM data can be stored separately in the BOM platform's preset cache and a relational database.

[0104] 2. Control the changes to the MBOM in the BOM middle platform.

[0105] like Figure 3As shown, after determining the MBOM change scenario, the upstream system sends an MBOM change request to the BOM via MQ. The BOM middleware consumes the MBOM change request based on MQ, asynchronously modifies the MBOM data according to the request, and then stores the modified MBOM in the database. For example, the modified MBOM is stored in the relational database of the BOM middleware.

[0106] The following example uses a CR request as an example to briefly explain the process of controlling MBOM changes in the BOM platform. Specifically, steps 41 to 45 below can be used to control MBOM changes in the BOM platform.

[0107] Step 41: The control BOM platform parses the JSON structure data of the CR request. This JSON structure data indicates that it includes CR nodes, multiple CA nodes, part nodes, and EBOM nodes. CR nodes are used to describe the main information of the CR, CA nodes are used to describe the main information of the CA, which at least includes the change intent, part nodes are used to describe the main information of the part, and EBOM nodes are used to describe the relationship rows of the part. A part also refers to the most basic unit of the BOM, the SV.

[0108] Step 42: Store the data parsed in Step 41 into the relational database of the BOM platform; if the database already contains information about the corresponding node, update the existing information based on the parsed data; if the database does not contain information about the corresponding node, insert and store the parsed data in the database.

[0109] Step 43: Determine the change scenario based on the change intent contained in the CA node.

[0110] Step 44: Invoke the corresponding change responsibility chain based on the change scenario.

[0111] Step 45: Modify the MBOM data by changing the chain of responsibility.

[0112] In this embodiment, the change responsibility chain includes the following change processing nodes executed in sequence:

[0113] Change processing node 1: Based on the part master information contained in the part node, filter out the parts (SVs) to be released (to be changed) and query whether the previous version of the current part already exists in the relational database; if it exists, disconnect the node of the previous version of the part from the part structure tree VPPS, and then associate the node of the current part with the part structure tree VPPS.

[0114] Change processing node 2: Traverse the master information of all parts for comparison and mark the parts to be compared. The parts to be compared include at least the parts added, deleted, and whose configurations have been updated in the current version compared to the previous version.

[0115] Change processing node 3: Based on information such as the part's level and type, remove parts that cannot be included in the MBOM.

[0116] Change processing node 4: Generate the set of parts to be included in the current version of MBOM.

[0117] Change processing node 5: Obtain the color codes of the parts in the aforementioned parts set from an external system, and replace the color codes of the parts in the aforementioned parts set according to the obtained color codes. In some embodiments, the external system may be a platform supporting the entire product development lifecycle management.

[0118] Change processing node 6: Compare the MBOM part sets of the previous version and the current version, and mark the parts that have changed in the previous version as to be deleted.

[0119] Change processing node 7: Based on the vehicle model corresponding to MOBM, obtain the vehicle factory associated with the vehicle, and associate the current version of the MBOM parts set with these vehicle factories.

[0120] Change processing node 8: Generate MBOM based on the MBOM part set associated with the vehicle factory mentioned above.

[0121] It should be noted that change processing nodes 1 to 8 are merely illustrative examples. Those skilled in the art can flexibly set the number of change processing nodes, the execution order, and the change processing operations corresponding to the change processing nodes according to actual needs. This embodiment of the invention does not impose specific limitations on these aspects.

[0122] Furthermore, it should be noted that although the steps in the above embodiments are described in a specific order, those skilled in the art will understand that, in order to achieve the effects of the present invention, different steps do not necessarily have to be executed in such an order. They can be executed simultaneously (in parallel) or in other orders. These adjusted solutions are equivalent to the technical solutions described in the present invention and therefore will also fall within the protection scope of the present invention.

[0123] Those skilled in the art will understand that all or part of the processes in the method of the above embodiment of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. The computer-readable storage medium can include any entity or device capable of carrying the computer program code, a medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory, a random access memory, an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc. It should be noted that the content included in the computer-readable storage medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable storage medium does not include electrical carrier signals and telecommunication signals.

[0124] Furthermore, the present invention also provides a computer device.

[0125] See appendix Figure 4 , Figure 4 This is a schematic diagram of the main structure of a computer device according to an embodiment of the present invention. Figure 4 As shown, the computer device in this embodiment of the invention mainly includes a storage device and a processor. The storage device can be configured to store a program for executing the BOM synchronization processing method based on a BOM middleware in the above-described method embodiments. The processor can be configured to execute the program in the storage device, which includes, but is not limited to, a program for executing the BOM synchronization processing method in the above-described method embodiments. For ease of explanation, only the parts related to the embodiments of the present invention are shown. For specific technical details not disclosed, please refer to the method section of the embodiments of the present invention.

[0126] In embodiments of the present invention, the computer device may be a control device comprising various electronic devices. In some possible implementations, the computer device may include multiple storage devices and multiple processors. The program executing the BOM synchronization processing method of the above method embodiments may be divided into multiple subroutines, each subroutine may be loaded and run by a processor to execute different steps of the BOM synchronization processing method of the above method embodiments. Specifically, each subroutine may be stored in different storage devices, and each processor may be configured to execute programs in one or more storage devices to jointly implement the BOM synchronization processing method of the above method embodiments, that is, each processor executes different steps of the BOM synchronization processing method of the above method embodiments to jointly implement the BOM synchronization processing method of the above method embodiments.

[0127] The aforementioned multiple processors can be processors deployed on the same device. For example, the aforementioned computer device can be a high-performance device composed of multiple processors, and the aforementioned multiple processors can be processors configured on that high-performance device. Alternatively, the aforementioned multiple processors can also be processors deployed on different devices. For example, the aforementioned computer device can be a server cluster, and the aforementioned multiple processors can be processors on different servers within the server cluster.

[0128] Furthermore, the present invention also provides a computer-readable storage medium.

[0129] In one embodiment of the computer-readable storage medium according to the present invention, the computer-readable storage medium may be configured to store a program that executes the BOM synchronization processing method based on a BOM middleware platform as described in the above-described method embodiments. This program may be loaded and run by a processor to implement the above-described BOM synchronization processing method. For ease of explanation, only the parts related to the embodiments of the present invention are shown; for specific technical details not disclosed, please refer to the method section of the embodiments of the present invention. The computer-readable storage medium may be a storage device comprising various electronic devices. Optionally, in the embodiments of the present invention, the computer-readable storage medium is a non-transitory computer-readable storage medium.

[0130] The technical solution of the present invention has been described above with reference to one embodiment shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions resulting from such changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. A BOM synchronization processing method based on a BOM middleware platform, characterized in that, The method includes: The system controls the preset BOM platform to send EBOM synchronization requests to the upstream system, and receives and stores the EBOM data sent by the upstream system according to the EBOM synchronization requests. The system controls the preset BOM platform to generate and store MBOM based on EBOM data, respond to MBOM change requests sent by upstream systems to change MBOM data, and respond to EBOM data and / or MBOM retrieval requests sent by downstream systems to send EBOM data and / or MBOM to downstream systems. Among them, the pre-set BOM middle platform, upstream system and downstream system communicate with each other using a message middleware-based communication method and carry the identification information of the communication initiator during communication; Sending the EBOM synchronization request to the upstream system includes: obtaining the structure tree type of the part structure tree to be synchronized, wherein the part structure tree is tree structure data used to represent the EBOM; controlling the BOM platform to generate EBOM synchronization requests corresponding to each structure tree type according to each structure tree type, and sending the EBOM synchronization requests to the upstream system respectively, so that the part structure tree of the corresponding structure tree type can be obtained from the upstream system respectively.

2. The BOM synchronization processing method according to claim 1, characterized in that, The steps of "storing the EBOM data issued by the upstream system according to the EBOM synchronization request" specifically include: Compress the EBOM data; The compressed EBOM data is stored in a preset cache in the BOM platform so that the BOM platform can be controlled to generate MBOM and / or modify MBOM data and / or send EBOM data to downstream systems based on the EBOM data in the preset cache.

3. The BOM synchronization processing method according to claim 2, characterized in that, The specific steps involved in "compressing EBOM data" include: The EBOM data is serialized to form a serialized file; The serialized file is compressed using a compression algorithm.

4. The BOM synchronization processing method according to claim 1, characterized in that, The steps for "responding to an MBOM change request sent by the upstream system and making data changes to the MBOM" include: Identify the change scenario corresponding to the MBOM change request; Obtain the change responsibility chain that matches the change scenario; Based on the aforementioned chain of responsibility for changes, data changes are made to the MBOM; The change responsibility chain includes multiple sequentially executed change processing nodes, each configured to perform different change processing operations.

5. The BOM synchronization processing method according to claim 4, characterized in that, The specific steps for "identifying the change scenario corresponding to the MBOM change request" include: Get the request type of the MBOM change request; Identify the change scenario corresponding to the request type; The request types include at least CA (Change Action) requests, CR (Change Request) requests, and PCO (Protocol Configuration Option) requests. Furthermore, the change scenarios corresponding to CA requests, CR requests, and PCO requests are respectively the first release scenario of a part, the change scenario of a part, and the change scenario of a part configuration expression.

6. The BOM synchronization processing method according to claim 5, characterized in that, The steps of "identifying the change scenario corresponding to the request type" specifically include: If the request type is a CR request, then obtain the CA (Change Action) node information contained in the MBOM change request; Obtain the change intent carried by each CA node information; Obtain the corresponding part change scenario for each change intention.

7. The BOM synchronization processing method according to claim 1, characterized in that, The method further includes: using a pre-set relational database in the BOM platform to store EBOM data and MBOM data respectively.

8. A computer device comprising a processor and a storage device, said storage device being adapted to store a plurality of program codes, characterized in that, The program code is adapted to be loaded and run by the processor to perform the BOM synchronization processing method based on the BOM middleware as described in any one of claims 1 to 7.

9. A computer-readable storage medium storing a plurality of program codes, characterized in that, The program code is adapted to be loaded and run by a processor to perform the BOM synchronization processing method based on a BOM middleware as described in any one of claims 1 to 7.

Images