Data synchronization system based on design requirements and application thereof

Abstract

The invention discloses a data synchronization system based on design requirements. The data synchronization system comprises a system main thread and a plurality of work task threads started by the system main thread, wherein the system main thread is used for performing full life cycle management on the whole environment of the data synchronization system, loading, calling and releasing related resources and services, and starting, monitoring and destroying each work task thread; the work task thread comprises a design requirement list and a plurality of safety message queues, the design requirement list is used for circularly traversing each design requirement, a design requirement identifier and a design requirement name are added into the safety message queues, the safety message queues are used for monitoring respective message queue states, and once a data dictionary object is obtained, the design requirement identifier is added into the safety message queues; if yes, work task processing is carried out, and then results are written into a unified processing result queue; according to the method, efficient execution of research and development projects is guaranteed, design demand omission is avoided, and manufacturing on-time and high-quality delivery is greatly facilitated.

Description

Technical Field

[0001] This invention relates to the field of data synchronization technology, and in particular to a data synchronization system based on design requirements and its application. Background Technology

[0002] To do a good job, one must first have the right tools. The development of new energy vehicles requires a good toolchain, which can effectively assist in the rapid implementation of the vehicle development process. This includes aspects such as the vehicle's electronic and electrical architecture, functional requirement definition, subsystem division, component management, task delegation, real-time communication and collaboration between the original equipment manufacturer (OEM) and suppliers, requirement and task management, and real-time and efficient access to automotive component design requirements (text, images, tables, etc.).

[0003] For vehicle R&D project requirements management, each automaker OEM typically uses enterprise-level electronic and electrical collaborative R&D platforms such as SystemWeaver, Prevision, or Capital VSTAR to strictly design, control, freeze versions, and delegate tasks for vehicle R&D design requirements (generating SWRS documents and providing them to suppliers offline via email). Then, they use Lark multidimensional tables, and in earlier practices, Excel spreadsheets, to manage the progress of requirements and tasks, supplier collaboration, etc.

[0004] Although vehicle OEMs use relatively advanced software tools for managing project requirements, software task development, and defect correction, these tools are developed by different companies and exist independently, forming information silos that cannot be integrated. This means that after SystemWeaver freezes the release based on the vehicle's R&D baseline version, the generated R&D task requirements can only be communicated to suppliers offline. However, vehicle manufacturing involves numerous components and a vast number of suppliers. Offline communication, information transfer, work collaboration, and risk management are all severely hampered. Often, OEMs and suppliers even fail to align their R&D requirements, leading to omissions in design functionalities and ultimately preventing the timely and high-quality delivery of vehicle projects. Summary of the Invention

[0005] To address the problems existing in the prior art, the purpose of this invention is to provide a data synchronization system based on design requirements and its application. This invention ensures the efficient execution of R&D projects, avoids omissions of design requirements, and greatly assists in timely and high-quality manufacturing delivery.

[0006] To achieve the above objectives, the technical solution adopted by this invention is: a data synchronization system based on design requirements, comprising: a system main thread and multiple worker task threads started by the system main thread; wherein, the system main thread is used to perform full lifecycle management of the overall environment of the data synchronization system, load, call and release related resources and services, and start, monitor and destroy each worker task thread; the worker task threads include a design requirement list and multiple secure message queues, the design requirement list is used to iterate through each design requirement, add the design requirement identifier and design requirement name to the multiple secure message queues, the multiple secure message queues are used to listen to the status of their respective message queues, and once a data dictionary object is obtained, the worker task is processed, and then the result is written to a unified processing result queue.

[0007] As a further improvement of the present invention, the system main thread is also used to: after all the work task threads have completed their tasks, the system main thread will summarize and integrate the data in the processing result queue and generate data in the final summary result list.

[0008] As a further improvement of the present invention, it also includes a SystemWeaver service system, a Lark service system, and a Redmine service system that communicate with the data synchronization system in a multi-task, multi-threaded manner to achieve end-to-end collaborative data synchronization.

[0009] As a further improvement of the present invention, the communication method of the plurality of secure message queues is as follows:

[0010] Multiple secure message queues are encapsulated into a unified list of thread-safe communication message queues. When the design requirement list sends messages to other worker task threads, it iterates through the list of thread-safe communication message queues and sends a message with a dictionary object as the message body to each message queue. Each node within each message queue is an independent and unique dictionary object, which consists of two key-value pairs: the first key-value pair is the design requirement identifier and its specific identifier value, and the second key-value pair is the design requirement name and its specific name description value. When the design requirement list task is completed, it sends a dictionary object with a design requirement identifier value of None to each message queue. Other worker task threads terminate their tasks when they encounter this None value.

[0011] As a further improvement of the present invention, the processing result queue includes multiple tuples. When each task thread completes, it writes its own processing result list into the thread-safe processing result queue according to its own task thread identifier to prevent shared memory write conflicts caused by multi-task and multi-thread concurrency. Each tuple consists of the task thread identifier and the processing result list. Each processing result list consists of a series of dictionary objects. The dictionary objects in the same processing result list have the same key-value format but different contents. However, the dictionary objects in different processing result lists have different key-value formats and contents.

[0012] As a further improvement of the present invention, each element in the final summary result list is an independent dictionary object.

[0013] As a further improvement of the present invention, multiple task threads query various relevant data indicators of design requirements from the design requirements database. Each task thread uses its own processing class and processing function to execute tasks. Specifically, the task threads include a task consumer class and multiple consumer task processing classes. The task consumer class inherits from the abstract base class and defines the abstract method proc_func. The consumer task processing classes inherit from the task consumer class and implement the key abstract function proc_func according to their respective business processing logic.

[0014] As a further improvement of the present invention, it also includes one producer task processing class object instance and multiple consumer task processing class object instances built into the thread task manager; the consumer task processing class object instance is used to consume producer data after each consumer task thread is started, call each consumer's own task processing function proc_func to implement its own business logic, and then put the final processing result into the result processing queue for subsequent processing; the producer task processing class object instance is used to query the design requirement database in the core processing function after the producer task thread is started, obtain the list of all latest versions of design requirements, and the attribute information of each design requirement.

[0015] As a further improvement of the present invention, the workflow of the system's main thread is as follows:

[0016] Record the start time and initialize the logger;

[0017] Copy the design requirements database storage file to the target directory, and subsequent steps will read the files in the target directory;

[0018] Instantiate the latest baseline version task thread: This involves creating the task thread's logger, establishing a design requirements database connection object, preparing the work task thread service object, and initializing the latest baseline architecture version dictionary object.

[0019] Instantiate the task thread manager: Create the logger for the task thread manager, prepare various thread-safe communication message queues, prepare thread-safe processing result queues, and declare various work task processing classes and worker thread objects;

[0020] Create each thread-safe communication message queue, as well as a list of thread-safe communication message queues, and also create a processing result queue;

[0021] Start each worker task thread: Instantiate each worker task processing class, start each worker task thread, and provide the thread-safe communication message queue, processing result queue, and corresponding worker task processing object as input parameters to the corresponding worker task thread.

[0022] After all task threads have finished processing, the final summary result list is returned. In the processing result queue, the processing result list corresponding to each tuple is obtained according to the task thread identifier. Then, the final summary result list is created. According to business needs, the dictionary object data values ​​corresponding to each processing result list are added to each dictionary object in the final summary result list, thereby completing the transformation, alignment and summary of all design requirement data.

[0023] This invention also provides an application of the data synchronization system based on design requirements as described above, for end-to-end collaborative data synchronization of automotive electronic and electrical architecture control, requirement task management, and wiki knowledge base.

[0024] The beneficial effects of this invention are:

[0025] This invention establishes end-to-end connectivity between SystemWeaver, Redmine, and Lark, enabling the synchronization of design requirement data. Whenever the vehicle R&D manager freezes design requirements for release, they can activate the data synchronization system service. This system automatically retrieves basic design requirement information from the SystemWeaver database and achieves end-to-end data synchronization with the Redmine and Lark wiki knowledge bases. Once data synchronization is complete, the vehicle OEM and suppliers can log into the Redmine system to communicate, collaborate, and develop tasks online for each design requirement. This ensures efficient execution of vehicle R&D projects, rapid consensus among multiple partners on design requirements, and prevents any omissions in design requirements, significantly contributing to on-time and high-quality vehicle manufacturing. Attached Figure Description

[0026] Figure 1 This is a diagram of a multi-task, multi-threaded communication architecture in an embodiment of the present invention;

[0027] Figure 2 This is a structural diagram of the list of thread-safe communication message queues in an embodiment of the present invention;

[0028] Figure 3 This is a structural diagram of the thread-safe processing result queue in an embodiment of the present invention;

[0029] Figure 4 This is a structural diagram of the final summary result list in an embodiment of the present invention;

[0030] Figure 5 This is a diagram showing the relationship between worker thread task processing classes in an embodiment of the present invention.

[0031] Figure 6 This is a flowchart of the main thread workflow in an embodiment of the present invention;

[0032] Figure 7 This is a flowchart illustrating the workflow for synchronizing SystemWeaver design requirement data with Lark and Redmine systems in an embodiment of the present invention. Detailed Implementation

[0033] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0034] Example

[0035] SystemWeaver is an enterprise-level collaborative R&D platform for electronics and electrical systems developed by Systemite, a Swedish company. It is primarily used in the automotive and automated equipment industries. It supports the entire V-mode design and management process, from requirements, functions, and systems to ECUs and testing. It provides a real-time collaborative development environment and issue management mechanism, enabling cross-departmental collaboration and data traceability. Commercial licensing fees are charged per license. Furthermore, its client system, swExplorer, is extremely CPU-intensive and memory-intensive (over 870MB) after startup. When multiple component FO / SO managers access the system simultaneously, the interface becomes very laggy, and operational delays are significant. Additionally, there is a long waiting time when generating SWRS after data freezing and release.

[0036] Redmine is a free, open-source, cross-platform project management, task management, and defect tracking system built on the Ruby on Rails framework. Automotive OEMs typically use Redmine, Jira, and similar systems to collaborate with suppliers on requirements management, software development tasks, and defect remediation.

[0037] Lark Service System's cloud documents support real-time collaborative editing, structured content management, and seamless integration with the Lark ecosystem; Lark wiki knowledge base is used for structured knowledge accumulation, team knowledge sharing, and linkage with business systems.

[0038] This embodiment uses automotive component design requirements as an example and uses the System Weaver service system as the design requirement database to illustrate the invention. Figure 1 As shown, a data synchronization system based on design requirements is presented. The overall multi-task, multi-threaded communication architecture of the system consists of four parts: SystemWeaver service system, Lark service system, Redmine service system, and data synchronization system; specifically:

[0039] The SystemWeaver service system is an existing system, and its components include: an SQLite database, a SystemWeaver server, a SystemWeaverClient API.dll dynamic link library, and a swExplorer GUI client (a dedicated client that needs to be installed on the Windows operating system). The data synchronization system uses the SQLite database interface to access the SystemWeaver SQLite database and loads the SystemWeaverClient API.dll dynamic link library to access the SystemWeaver server through the interface.

[0040] The Lark service system is an existing system, and its components include: Lark SDK lark_oapi, Lark cloud service, Lark GUI client (including a dedicated client installed on the Windows operating system and a browser client); the data synchronization system loads the Python SDK and accesses Lark cloud service through Lark SDK lark_oapi.

[0041] The Redmine service system is an existing system, and its structure includes: a MySQL database, a Redmine server, and a Redmine GUI client (browser client); the data synchronization system uses the MySQL database interface to access the Redmine MySQL database.

[0042] The data synchronization system is the core of this embodiment. The multi-tasking processing of the entire data synchronization system consists of one main thread and seven worker task threads. Among them, the latest baseline architecture version (worker task thread), design requirement list (worker task thread), logic component name / ECU system (worker task thread), logic component / subsystem / functional domain (worker task thread), function name processing (worker task thread), design requirement status (worker task thread), Lark and RM data synchronization (worker task thread) are all started by the system's main thread.

[0043] The system's main thread is responsible for the full lifecycle management of the data synchronization system's environment, including loading, calling, and releasing related resources and services, and starting, monitoring, and destroying various worker task threads. Additionally, the main thread passes the latest baseline architecture version information and the final summary result list as parameters to Lark and RM data synchronization (worker task threads).

[0044] Latest Baseline Architecture Version (Worker Thread): Primarily responsible for establishing a connection with the SystemWeaver system's backend SQLite database and reading the latest baseline architecture version information, including: latest baseline architecture version identifier ID, latest baseline architecture name, and latest baseline architecture version number.

[0045] In the multi-task, multi-threaded communication architecture of the data synchronization system, four key thread-safe message queues are created: the logical component name / ECU system message queue, the logical component / subsystem / functional domain message queue, the function name message queue, and the design requirement status message queue. When the design requirement list (work task thread) iterates through each design requirement, it adds the design requirement identifier and design requirement name to each of these four message queues. Then, the logical component name / ECU system (work task thread), logical component / subsystem / functional domain (work task thread), function name processing (work task thread), and design requirement status (work task thread) monitor their respective message queue statuses. Once they obtain the data dictionary object, they perform the work task processing and then write the results to a unified processing result queue.

[0046] Design Requirements List (Work Task Thread): Primarily responsible for establishing a connection with the SystemWeaver system's backend SQLite database, reading the latest version design requirement ID, name, latest version, description information, object identifier, Change Log, and Last Changed date and time (accurate to "year, month, day") for each frozen release. Simultaneously, based on the design requirement object identifier, it retrieves: requirement owner, project applicability rating (optional values ​​include: A - fully applicable, D - slightly applicable, R - reserved, TBC - pending confirmation, NA - not applicable), vehicle model rating, and function ID.

[0047] Logic Component Name / ECU System (Worker Task Thread): Primarily responsible for establishing a connection with the SystemWeaver system's backend SQLite database, using recursive crawling to obtain the identifier and name of its parent LC logic component (levels 2-3) based on the latest version design requirement identifier of the frozen release; then, based on the obtained LC logic component identifier, using recursive crawling to obtain the identifier and name of its parent ECU system (level 2).

[0048] Logical Component / Subsystem / Functional Domain (Worker Task Thread): Primarily responsible for establishing a connection with the SystemWeaver system's backend SQLite database. Based on the latest version design requirement identifier of the frozen release, it uses recursive crawling to obtain the identifier and name of its parent LC logical component (levels 2-3). Then, based on the obtained LC logical component identifier, it uses recursive crawling to obtain the identifier and name of its parent subsystem (level 2). Finally, based on the obtained subsystem identifier, it uses recursive crawling to obtain the identifier and name of its parent functional domain (level 1).

[0049] Function Name Processing (Worker Task Thread): Primarily responsible for establishing a connection with the SystemWeaver system's backend SQLite database, obtaining the associated design function requirement identifier based on the latest frozen release version's design requirement identifier (note that the correspondence between design requirement identifiers and design function requirement identifiers includes: one-to-one, one-to-many, many-to-one, and many-to-many); then, based on the obtained design function requirement identifiers, using recursive crawling to obtain the function identifier and name of its parent layer (4 layers).

[0050] Design Requirement Status (Work Task Thread): Primarily responsible for establishing a connection to the SystemWeaver system's backend SQLite database. Based on the latest version design requirement identifier and the latest version baseline architecture, it checks and determines the change status of each design requirement. Specific statuses include: Reserved, New, Update, Delete, and Same.

[0051] After all the task threads have completed their tasks, the system's main thread will summarize and integrate the data in the processing result queue and generate data in the final summary result list. Then, Lark and Redmine data synchronization (task threads) will loop through the final summary result list, retrieve each design requirement object, and then operate on the Lark knowledge base and Redmine database.

[0052] Lark and RM data synchronization (worker thread): Primarily responsible for the following key tasks:

[0053] ① Obtain the tenant access token based on the APP_ID and APP_SECRET of the self-built robot application in the Lark system;

[0054] ② Based on the Lark wiki parent node (“Design Requirements Document”) token and the latest baseline architecture version information entered, construct the SystemWeaver baseline architecture version list child node of the Lark wiki knowledge base;

[0055] ③ Based on the set of ECU names in the final summary result list, construct a set of Lark knowledge base wiki node lists;

[0056] ④ Based on the final summary list entered, create a series of subdirectory folders under "Feishu Cloud Space Transfer Station";

[0057] ⑤ Based on the input final summary result list, load the SystemWeaverClientAPI.dll dynamic link library and call this dynamic link library interface for each design requirement object in the list to realize the export and generation of the design requirement description information as a local docx document; through the client SDK (HTTP Restful) access interface provided by the Lark system, establish a communication connection with the Lark service system backend, and finally upload the description information of each design requirement (which may contain multiple text paragraphs, multiple tables, multiple video images, etc.) in docx format to the Lark cloud space transfer station. Then, convert the uploaded document into a Lark online document and move the converted Lark online document to the wiki knowledge base space node so that users can browse, read, and comment / annotate online.

[0058] ⑥ Based on the latest baseline architecture version information and each design requirement object in the final summary result list, the system performs creation, reading, modification, and deletion (C / R / U / D) operations on the MySQL database table structure within the Redmine system through the remote access interface of the MySQL database. This achieves synchronization of SystemWeaver design requirement-related data with the Redmine system requirement tasks. Additionally, after step ③ is completed, the node URL link generated on Lark wiki for each design requirement description will be bound to the design requirement object and stored in the Redmine backend database. This allows users to quickly jump to the corresponding design requirement description page on Lark wiki by clicking the URL link when accessing the web interface of a design requirement in the Redmine system, thus achieving integrated linkage between SystemWeaver, Redmine, and Lark wiki knowledge bases.

[0059] ⑦ After SystemWeaver synchronizes the design requirements information to Redmine and Lark systems, it automatically deletes all temporarily generated subdirectories, uploaded documents, and online documents in the "Lark Cloud Space Transfer Station".

[0060] like Figure 2 As shown, the thread-safe communication message queue set list in this embodiment includes:

[0061] ① Four key thread-safe message queues (Logical Component Name / ECU System Message Queue, Logic Component / Subsystem / Functional Domain Message Queue, Function Name Message Queue, and Design Requirement Status Message Queue) will be uniformly encapsulated into a "Thread-Safe Communication Message Queue Collection List";

[0062] ② When the design requirement list (work task thread) sends messages to other work task threads, it will loop through the "thread-safe communication message queue collection list" and send messages (the message body is a dictionary object) to each message queue.

[0063] ③ Each node within each message queue is an independent and unique "dictionary object". The "dictionary object" consists of two key-value pairs: the first key-value pair is the design requirement identifier (Item_ID) and the specific identifier value, and the second key-value pair is the design requirement name (DR_Name) and the specific name description value.

[0064] ④ When the design requirement list (work task thread) task is completed, it sends a dictionary object with a design requirement identifier value of None to each message queue. Other work task threads will end their work tasks when they process this None value.

[0065] like Figure 3 As shown, the thread-safe processing result queue includes:

[0066] ① The thread-safe processing result queue contains 5 tuples: tuple (design requirement), tuple (logical component name / ECU system), tuple (logical component / subsystem / functional domain), tuple (functional name), and tuple (design requirement status). When each task thread completes, it writes its processing result list into the thread-safe processing result queue according to its own task thread identifier to prevent shared memory write conflicts caused by multi-task and multi-thread concurrency.

[0067] ② Each tuple consists of the thread identifiers for each task and a list of processing results. That is:

[0068] The tuple (design requirement) contains: the thread identifier of the design requirement task and a list of design requirement processing results;

[0069] The tuple (Logic Component Name / ECU System) contains: Logic Component Name / ECU System Task Thread Identifier and Logic Component Name / ECU System Processing Result List;

[0070] The tuple (logical component / subsystem / functional domain) contains: the task thread identifier of the logical component / subsystem / functional domain, and the list of processing results of the logical component / subsystem / functional domain;

[0071] The tuple (function name) contains: function name, task thread identifier, and function name, processing result list.

[0072] The tuple (design requirement status) contains: the thread identifier of the design requirement status task and a list of design requirement status processing results;

[0073] ③ Each processing result list consists of a series of dictionary objects. Dictionary objects within the same processing result list have the same key-value format but different contents; however, dictionary objects from different processing result lists have different key-value formats and contents. Specifically:

[0074] The dictionary object containing the design requirement processing results list has the following key-value pairs: Design Requirement Identifier (Item_ID), Design Requirement Unique Number (DR_ID), Design Requirement Name (DR_Name), Design Requirement Last Update Date (DR_LastChanged), Design Requirement Latest Version Information (DR_Version), Design Requirement Applicability Markup (DR_SYXDD), Design Requirement Vehicle Model Markup (DR_CXDD), Design Requirement Function Identifier (DR_GNID), and Design Requirement Function Owner (DR_RQFO).

[0075] The dictionary object containing the list of logical component names / ECU system processing results has the following key-value pairs: design requirement identifier (Item_ID), logical component identifier (LC_ID), logical component name (LC_Name), electronic control unit identifier (ECU_ID), and electronic control unit name (ECU_Name).

[0076] The dictionary object containing the processing results list of logical components / subsystems / functional domains has the following key-value pairs: design requirement identifier (Item_ID), logical component identifier (LC_ID), logical component name (LC_Name), subsystem identifier (SS_ID), subsystem name (SS_Name), functional domain identifier (FN_ID), and functional domain name (FN_Name).

[0077] The dictionary object containing the function name processing result list has the following key-value pairs: design requirement identifier (Item_ID), function name identifier (FN_ID), and function name (FN_Name).

[0078] The dictionary object containing the design requirement status processing results list has the following key-value pairs: design requirement identifier (Item_ID) and design requirement change status (DR_Change_Status).

[0079] like Figure 4 As shown, the final summary result list of this embodiment includes:

[0080] Each element in the final_combined_results list is an independent dictionary object. The key-value pairs in the dictionary object include: Design Requirement Identifier (Item_ID), Design Requirement Unique Number (DR_ID), Design Requirement Name (DR_Name), Design Requirement Last Update Date (DR_LastChanged), Design Requirement Latest Version Information (DR_Version), Design Requirement Applicability Marker (DR_SYXDD), Design Requirement Vehicle Model Marker (DR_CXDD), Design Requirement Function Identifier (DR_GNID), Design Requirement Function Owner (DR_RQFO), Logic Component Name (LC_Name), Electronic Control Unit Name (ECU_Name), Subsystem Name (SS_Name), Functional Domain Name (FN_Name), Function Name (FN_Name), and Design Requirement Change Status (DR_Change_Status).

[0081] like Figure 5 As shown, the worker thread task processing class relationship structure in this embodiment includes:

[0082] (1) Query various relevant data indicators of design requirements from the SQLite database in the SystemWeaver backend. Different task threads are required, and each task thread uses its own processing class and processing function to execute the task.

[0083] (2) Among them, four consumer task processing classes: Logic Component / Subsystem / Functional Domain (LcSsFdProc), Logic Component Name / ECU System (LcAndEcuSysProc), Function Name Processing (FuncNameProc), and Design Requirement Status (DrChangeStatusProc) all inherit from the WorkerConsumer class and implement the key abstract function proc_func according to their respective business processing logic;

[0084] (3) The WorkerConsumer class inherits from the abstract base class (ABC) and defines the abstract method proc_func. Additionally, its initialization function __init__ is responsible for creating the SQLite database connection object to access the SystemWeaver backend;

[0085] (4) The ThreadTaskMgr has 4 built-in consumer task processing class object instances. After each consumer task thread is started, each thread consumes producer data in the consumer_task function, calls its own task processing function proc_func, implements its own business logic (query the SQLite database to get the logical component name, ECU electronic control unit name, subsystem name, function name, and design requirement status), and then puts the final processing result into the result processing queue for subsequent processing.

[0086] (5) The ThreadTaskMgr also has a built-in instance of a producer task processing class object (SwDrListProc), which has a built-in SQLite database connection object for accessing the SystemWeaver backend and creates the SQLite database connection in the initialization function __init__. After starting the producer task thread, the instance of the task processing class object will query the SQLite database in the core processing function sw_search_task to obtain the list of all the latest versions of design requirements and the attribute information of each design requirement.

[0087] like Figure 6 As shown, in this embodiment, the workflow of the system's main thread is as follows:

[0088] (1) Record the start time (accurate to the millisecond level);

[0089] (2) Initialize the logger, which classifies log levels as: debug, info, warning, error, critical, and can simultaneously print log information to the console and write it to a log file. The log data recording format is defined as: "ASC time-thread name (ID: thread identifier)-file name-log level-log message-[log file name:line of code]", where the ASC time is accurate to the millisecond level. An example of a complete log message is as follows:

[0090] 2025-12-11 10:37:08,004 - MainThread (ID:92280) - func_name_proc -DEBUG - Thread Thread_tid_func_name processes data {'Item_ID': 288230376154071713} into {'Item_ID': 288230376154071713, 'FN_ID': 288230376153436156, 'FN_Name': 'Electronic Parking Brake'} - [logger.py:43]

[0091] (3) As a file-level database, SQLite has specific limitations in its concurrent processing capabilities. Write operations will lock the entire database file, blocking all other read and write operations. The execution of the data synchronization system is initiated by the user after freezing the design requirements data of SystemWeaver and releasing a new version. However, it cannot be guaranteed that during the execution of the data synchronization system (more than 10 hours), other users will continue to operate SystemWeaver through the swExplorer interface to modify the data, which will cause the data synchronization system to block and interrupt the SQLite reading task. Therefore, it is necessary to first copy the core SQLite database storage file of SystemWeaver to the target directory, and subsequent steps will read the SQLite database file in the target directory. This achieves read and write separation control of SQLite operations, so that they do not interfere with each other.

[0092] (4) Instantiate the latest baseline version task thread: This step will create the logger for the task thread, establish an SQLite database connection object, prepare the job task thread service object, and initialize the latest baseline architecture version dictionary object;

[0093] (5) Start the latest baseline version task thread: This task thread will access the SystemWeaver backend database system through the SQLite database connection object to obtain the latest baseline architecture version information;

[0094] (6) After the task thread completes, destroy the execution environment (this mainly refers to releasing and closing the SQLite database connection object to avoid resource leaks) and return the latest baseline architecture version information, including: the identifier, name, and version number of the latest baseline architecture;

[0095] (7) Instantiate the task thread manager: This step mainly creates the logger of the task thread manager, prepares various thread-safe communication message queues, prepares thread-safe processing result queues, and declares each work task processing class and worker thread object;

[0096] (8) Create each thread-safe communication message queue, including: logical component name / ECU system message queue, logical component / subsystem / functional domain message queue, function name message queue, design requirement status message queue, and a list of thread-safe communication message queues. Also create a processing result queue.

[0097] (9) Start each task thread: This step will instantiate each task processing class and start each task thread (provide each thread-safe communication message queue, processing result queue, and corresponding task processing object as input parameters to the corresponding task thread).

[0098] (10) Wait for all work task threads to finish processing and return the final summary result list: In this step, in the processing result queue, according to the work task thread identifier, obtain the processing result list corresponding to each tuple; then create the final summary result list, and according to business needs, add the dictionary object data values ​​corresponding to each of the previous processing result lists to each dictionary object in the final summary result list, thereby completing the conversion, alignment and summary of all design requirement data;

[0099] (11) Instantiate SystemWeaver to Lark and Redmine synchronization task threads: This step mainly creates the logger of the data synchronization task thread, declares instances of SystemWeaver client dynamic link library operation class, Lark wiki knowledge base operation class, and Redmine operation class;

[0100] (12) Initialize the execution environment for the data synchronization task thread. This includes:

[0101] ① Create a SystemWeaver client dynamic link library operation object:

[0102] a) Create the appropriate logger;

[0103] b) Set the directory for generating docx files;

[0104] c) Declare the series of interfaces required for SystemWeaver dynamic library calls;

[0105] ② Load the SystemWeaver system's dynamic link libraries:

[0106] a) Obtain the complete file path of the SystemWeaverClientAPI.dll dynamic link library;

[0107] b) Add the directory containing the dynamic link library to the Python system path so that the CLR can find the DLL;

[0108] c) Add the .NET Services Framework path and SystemWeaverClientAPI.dll path to the CLR;

[0109] d) Import the required SystemWeaver namespace;

[0110] ③ Connect to the SystemWeaver server:

[0111] a) Obtain the SystemWeaver server's IP address, port number, username, and password from the configuration file;

[0112] b) Try logging in and connecting to the SystemWeaver server;

[0113] ④ Initialize the HTTP RESTful operating environment for the Lark wiki knowledge base:

[0114] a) Create a logger for communication control operations in the Lark wiki knowledge base;

[0115] b) Obtain the APP_ID, APP_SECRET, cloud disk "SystemWeaver System Requirements Transfer Station" directory token, knowledge space identifier, Lark WIKI "Design Requirements Document" root node token, and Lark WIKI basic URL path from the configuration file.

[0116] ⑤ Instantiate an instance of the Redmine database business logic operation class:

[0117] a) Create a logger for Redmine system control operations;

[0118] b) Initialize the MySQL database connection pool and obtain a valid MySQL database connection object from the pool;

[0119] (13) Start and execute the data synchronization task thread: This step mainly involves uploading, converting and moving the description information of each design requirement into the Lark wiki knowledge base in the form of a docx document, and then operating the Redmine system's backend database to perform creation, retrieval, update and deletion operations;

[0120] (14) Terminating and destroying the execution environment of the data synchronization task thread, specifically including:

[0121] ① Wait for SystemWeaver to complete the synchronization task threads for Lark and Redmine systems;

[0122] ② Log out of the account and disconnect from the SystemWeaver server;

[0123] ③ Release the connection resources of the Redmine background MySQL database and close the database connection object;

[0124] (15) After the data synchronization between SystemWeaver and Lark and Redmine systems is completed, delete the target directory of the file system on the SystemWeaver server (this directory contains: the core SQLite database storage file of SystemWeaver copied and pasted, and a collection of docx files generated by calling the SystemWeaverClientAPI.dll interface for the description information of each design requirement).

[0125] (16) Record the end time of the entire work task (accurate to milliseconds);

[0126] (17) Calculate the difference between the start time and the end time, and display the time taken to complete the data synchronization task.

[0127] like Figure 7 As shown in this embodiment, the workflow for synchronizing SystemWeaver design requirement data to Lark and Redmine systems is as follows:

[0128] (1) Obtain APP_ID and APP_SECRET from the Lark self-built application robot, and then use Lark client SDK (lark_oapi) to realize Http Restful communication between the data synchronization system and Lark backend server to obtain the tenant access token (tenant_access_token).

[0129] (2) Based on the Lark Wiki space identifier and the parent node (design requirements document) token, construct the Systemweaver baseline architecture version list child nodes of the Lark Wiki knowledge base;

[0130] (3) Construct a Lark knowledge base Wiki node based on the ECU name;

[0131] ① Obtain a list of ECU names from the SystemWeaver query results list;

[0132] ② Perform uniqueness filtering and sorting on the ECU name list;

[0133] ③ Obtain all ECU name sub-nodes under the "SystemWeaver Baseline Architecture Version Node" in Lark's Wiki knowledge space;

[0134] ④ Under the target baseline architecture version name node in the Lark Wiki knowledge space, match and construct new ECU name sub-nodes;

[0135] ⑤ Retrieve all child nodes under the target baseline architecture version name node in Lark's Wiki knowledge space again (this step is repeated because the list of atomic node sets may contain new nodes);

[0136] (4) Based on the length of the design requirements list, create a series of subdirectory folders under the Lark Cloud Space transfer station;

[0137] (5) Build a project version for the Redmine system;

[0138] (6) Synchronize Systemweaver design requirement information with Redmine and Lark systems;

[0139] (7) Delete all newly created subdirectory folders in the Lark Cloud Space transfer station.

[0140] The embodiments described above are merely illustrative of specific implementations of the present invention, and while the descriptions are detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention.

Claims

1. A data synchronization system based on design requirements, characterized in that, include: The system comprises one main thread and multiple worker task threads started by the main thread. The main thread manages the entire lifecycle of the data synchronization system environment, loads, calls, and releases related resources and services, and starts, monitors, and destroys each worker task thread. Each worker task thread includes a design requirement list and multiple secure message queues. The design requirement list iterates through each design requirement, adding its identifier and name to each secure message queue. Each secure message queue listens to its own message queue status. Once a data dictionary object is obtained, the worker task is processed, and the result is written to a unified processing result queue.

2. The data synchronization system based on design requirements according to claim 1, characterized in that, The system's main thread is also used to: after all the task threads have completed their tasks, the system's main thread will summarize and integrate the data in the processing result queue and generate data in the final summary result list.

3. The data synchronization system based on design requirements according to claim 2, characterized in that, It also includes the SystemWeaver service system, Lark service system, and Redmine service system, which communicate with the data synchronization system in a multi-task, multi-threaded manner to achieve end-to-end collaborative data synchronization.

4. The data synchronization system based on design requirements according to claim 2, characterized in that, The communication method for multiple secure message queues is as follows: Multiple secure message queues are encapsulated into a unified list of thread-safe communication message queues. When the design requirement list sends messages to other worker task threads, it iterates through the list of thread-safe communication message queues and sends a message with a dictionary object as the message body to each message queue. Each node within each message queue is an independent and unique dictionary object, which consists of two key-value pairs: the first key-value pair is the design requirement identifier and its specific identifier value, and the second key-value pair is the design requirement name and its specific name description value. When the design requirement list task is completed, it sends a dictionary object with a design requirement identifier value of None to each message queue. Other worker task threads terminate their tasks when they encounter this None value.

5. The data synchronization system based on design requirements according to claim 4, characterized in that, The processing result queue includes multiple tuples. When each task thread completes its task, it writes its own processing result list into the thread-safe processing result queue according to its own task thread identifier to prevent shared memory write conflicts caused by multi-task and multi-thread concurrency. Each tuple consists of the identifiers of each worker task thread and a list of processing results. Each list of processing results consists of a series of dictionary objects. The dictionary objects within the same list of processing results have the same key-value format but different contents. However, the dictionary objects in different lists of processing results have different key-value formats and contents.

6. The data synchronization system based on design requirements according to claim 5, characterized in that, Each element in the final summary list is an independent dictionary object.

7. The data synchronization system based on design requirements according to claim 5, characterized in that, Multiple task threads query various relevant data indicators of design requirements from the design requirements database. Each task thread uses its own processing class and processing function to execute tasks. Specifically, the task threads include a work consumer class and multiple consumer task processing classes. The work consumer class inherits from the abstract base class and defines the abstract method proc_func. The consumer task processing classes inherit from the work consumer class and implement the key abstract function proc_func according to their respective business processing logic.

8. The data synchronization system based on design requirements according to claim 7, characterized in that, It also includes one producer task processing class object instance and multiple consumer task processing class object instances built into the thread task manager; the consumer task processing class object instance is used to consume producer data after each consumer task thread is started, call each consumer's own task processing function proc_func to implement its own business logic, and then put the final processing result into the result processing queue for subsequent processing; the producer task processing class object instance is used to query the design requirement database in the core processing function after the producer task thread is started to obtain a list of all the latest versions of design requirements, as well as the attribute information of each design requirement.

9. The data synchronization system based on design requirements according to claim 8, characterized in that, The specific workflow of the system's main thread is as follows: Record the start time and initialize the logger; Copy the design requirements database storage file to the target directory, and subsequent steps will read the files in the target directory; Instantiate the latest baseline version task thread: This will create the task thread's logger, establish a design requirements database connection object, prepare the work task thread service object, and initialize the latest baseline architecture version dictionary object; Instantiate the task thread manager: Create the task thread manager's logger, prepare various thread-safe communication message queues, prepare thread-safe processing result queues, and declare each work task processing class and worker thread object; Create each thread-safe communication message queue, as well as a list of thread-safe communication message queues, and also create a processing result queue; Start each worker task thread: Instantiate each worker task processing class, start each worker task thread, and provide the thread-safe communication message queue, processing result queue, and corresponding worker task processing object as input parameters to the corresponding worker task thread. After all worker task threads have finished processing, return the final summary result list: In the processing result queue, obtain the processing result list corresponding to each tuple according to the worker task thread identifier; Then, create a final summary result list. Based on business needs, add the corresponding dictionary object data values ​​from each processing result list to each dictionary object in the final summary result column, thereby completing the transformation, alignment, and summarization of all design requirement data.

10. An application of a data synchronization system based on design requirements as described in any one of claims 1-9, characterized in that, Used for end-to-end collaborative data synchronization for automotive electronic and electrical architecture management, requirement and task management, and wiki knowledge base.

Images