IVCPS demand generation method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides an IVCPS demand generation method and device, electronic equipment and a storage medium, and the method comprises the steps: building ontology models of different elements, generating corresponding knowledge maps according to the ontology models, carrying out the correlation of different knowledge maps, obtaining an IVCPS demand element knowledge base, and obtaining an IVCPS demand element knowledge base after obtaining a target element demand, the method comprises the following steps: performing matching in an IVCPS demand element knowledge base to obtain a corresponding entity node, generating a target demand link according to the entity node, and then analyzing the target demand link according to a trained large model to obtain a target description language corresponding to the target demand link, so as to obtain target demand data corresponding to a target element demand. And according to the target element demand of one of the benefit related parties, the constraint conditions of multiple parties are integrated to generate a corresponding target description language, so that the comprehensive coverage of regional elements is realized, the demand omission is reduced and eliminated, and the demand analysis efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of intelligent transportation technology, and more specifically, to an IVCPS demand generation method, apparatus, electronic device, and storage medium. Background Technology

[0002] As a complex system deeply integrating "vehicle, road, cloud, network, and map," Intelligent Vehicle Cyber-Physical Systems (IVCPS) must simultaneously meet the dynamic needs of multiple domain collaborations (vehicle control, road infrastructure, cloud computing platforms, communication networks, and high-precision maps) and multiple stakeholders (road managers, vehicle manufacturers, autonomous driving operators, drivers, passengers, pedestrians, and non-motorized vehicles). In the development of IVCPS, requirements analysis is a core step, used to define system functions, performance indicators, and safety constraints. However, in existing technologies, requirements analysis methods generally rely on static, manually-led processes, which cannot dynamically adapt to real-time changes in the intelligent vehicle environment (such as road conditions, user behavior, and sensor data fluctuations). In other words, if the needs of one party change and are constrained by the capabilities of other parties, the requirements analysis is based solely on input from one party (such as requirements documents provided by vehicle manufacturers) and fails to consider the needs of other stakeholders. This means that a dynamic coordination mechanism across domains and stakeholders has not been established, leading to one-sided requirements design, unidentified conflicts, and delayed decision-making. Ultimately, this results in system design deviations. For example, the failure to incorporate pedestrian safety requirements into autonomous driving decisions can lead to accident risks, extended system development cycles, and increased costs. Summary of the Invention

[0003] The purpose of some embodiments of this application is to provide an IVCPS requirement generation method, apparatus, electronic device, and storage medium. Through the technical solutions of the embodiments of this application, the following steps are taken: 1. Obtaining target element requirements; 2. Determining entity nodes corresponding to the target element requirements based on a pre-established IVCPS requirement element knowledge base. The IVCPS requirement element knowledge base is obtained by establishing ontology models of different elements, generating corresponding knowledge graphs based on the ontology models, and associating the different knowledge graphs; 3. Generating target requirement links corresponding to the entity nodes based on the entity nodes; 4. Parsing the target requirement links using a pre-trained large model to obtain a target description language corresponding to the target requirement links, and determining the target description language as target requirement data corresponding to the target element requirements. The embodiments of this application establish ontology models of different elements, determine entity nodes corresponding to the target element requirements based on the pre-established IVCPS requirement element knowledge base, wherein the IVCPS requirement element knowledge base is obtained by establishing ontology models of different elements, generating corresponding knowledge graphs based on the ontology models, and associating the different knowledge graphs; 5. Generating target requirement links corresponding to the entity nodes based on the entity nodes; 6. Generating target requirement links corresponding to the entity nodes based on the entity nodes; 7. Using a pre-trained large model, parsing the target requirement links to obtain target description language, and determining the target description language as target requirement data corresponding to the target element requirements. The embodiments of this application, through establishing ontology models of different elements, determine entity nodes corresponding to the target element requirements based on the pre-trained large model, obtain target requirement links, and determine the target requirement data corresponding to the target element requirements. The ontology model generates a corresponding knowledge graph, and the different knowledge graphs are associated to obtain the IVCPS requirement element knowledge base. After obtaining the target element requirement, it is matched in the IVCPS requirement element knowledge base to obtain the corresponding entity node. Based on the entity node, the target requirement link is generated. Then, based on the trained large model, the target requirement link is parsed to obtain the target description language corresponding to the target requirement link. In this way, the target requirement data corresponding to the target element requirement is obtained. Thus, based on the target element requirement of one of the stakeholders, combined with the knowledge, logic and system of various fields, a systematic, scientific and comprehensive stakeholder requirements, functional requirements at each level, performance requirements at each level and design constraint requirements are generated semi-automatically and automatically. By integrating the constraints of multiple parties, the corresponding target description language is generated, realizing comprehensive coverage of regional elements, reducing and eliminating requirement omissions, and improving the efficiency of requirement analysis.

[0004] Firstly, some embodiments of this application provide a method for generating IVCPS requirements, including: Obtain the target element requirements; Based on the pre-established IVCPS demand element knowledge base, the entity nodes corresponding to the target element demand are determined. The IVCPS demand element knowledge base is obtained by establishing ontology models of different elements, generating corresponding knowledge graphs based on the ontology models, and associating the different knowledge graphs. Based on the entity node, generate the target requirement link corresponding to the entity node; A pre-trained large model is used to parse the target demand chain to obtain the target description language corresponding to the target demand chain, and the target description language is determined as the target demand data corresponding to the target element demand.

[0005] Some embodiments of this application establish ontology models for different elements, generate corresponding knowledge graphs based on the ontology models, and associate the different knowledge graphs to obtain an IVCPS requirement element knowledge base. Then, after obtaining the target element requirement, it matches it in the IVCPS requirement element knowledge base to obtain the corresponding entity nodes. Based on the entity nodes, a target requirement link is generated. Then, based on a trained large model, the target requirement link is parsed to obtain the target description language corresponding to the target requirement link. This yields the target requirement data corresponding to the target element requirement. Thus, based on the target element requirement of one of the stakeholders, combined with knowledge, logic, and systems from various fields, a systematic, scientific, and comprehensive set of stakeholder requirements, functional requirements at each level, performance requirements at each level, and design constraint requirements are generated semi-automatically and automatically. By integrating the constraints from multiple parties, a corresponding target description language is generated, achieving comprehensive coverage of regional elements, reducing and eliminating requirement omissions, and improving the efficiency of requirement analysis.

[0006] Optionally, the requirement to obtain the target element includes: Obtain the target element requirements; The text data of the target element requirements is structured to obtain the processed target element requirements; The processed target requirements are semantically annotated to obtain searchable requirement text data.

[0007] Optionally, determining the entity node corresponding to the target element requirement based on a pre-established IVCPS requirement element knowledge base includes: Determine the first feature vector of the retrieveable demand text data; Calculate the similarity between the first feature vector and the second feature vector of the entity node in the IVCPS demand element knowledge base, respectively; If the similarity is greater than the similarity threshold, then the searchable demand text data and the entity node are determined to match; Based on the pre-established IVCPS demand element knowledge base, attribute information corresponding to the searchable demand text data is determined, wherein the pre-established IVCPS demand element knowledge base includes entities and attribute information corresponding to the entities. Some embodiments of this application begin with typical application scenarios, clarifying the scenario objectives and operational boundaries, and identifying key elements such as traffic participants, environmental conditions, system components, and stakeholders. Subsequently, by leveraging semantic retrieval and entity localization mechanisms, precise alignment of scenario elements and knowledge nodes is achieved in the demand knowledge graph, activating relevant entities and their attribute relationships, and providing a clear semantic starting point for demand reasoning.

[0008] Optionally, generating the target demand link corresponding to the entity node based on the entity node includes: Based on the pre-established demand association pattern, a general rule reasoning engine under the semantic web framework is adopted. Taking the entity type and semantic relationship defined in the demand ontology as the basic constraints, the entity node and the pre-established IVCPS demand element knowledge base are matched in the form of RDF triples to obtain the first demand link corresponding to the entity node. Based on the class hierarchy, attribute constraints and inheritance relationships defined in the requirement ontology, the implicit requirement relationship of the description logic is constructed, and based on the implicit requirement relationship of the description logic, the second requirement link corresponding to the entity node is generated. The demand relationship completion algorithm based on the graph convolutional network model (GCN) determines the probability corresponding to the entity node based on the knowledge graph, the embedding vector of the entity node, and the semantic relationship type, and determines the third demand link corresponding to the entity node based on the probability. Based on the first demand link, the second demand link, and the third demand link, determine the target demand link corresponding to the entity node.

[0009] Some embodiments of this application, based on the activated requirement knowledge subgraph, use various mechanisms such as rule-driven reasoning and graph structure reasoning to mine the requirement logic links across entities and levels, and deduce potential functional constraints, performance requirements and collaborative relationships. This process can not only characterize explicit requirements, but also reveal implicit requirement associations and system behavior constraints, thereby improving the systematicness and foresight of requirement analysis. Optionally, determining the target demand link corresponding to the entity node based on the first demand link, the second demand link, and the third demand link includes: The target demand link is determined from multiple demand links corresponding to the entity node by employing node importance calculation method, subgraph connectivity analysis method, and link importance aggregation method.

[0010] Optionally, the step of using a pre-trained large model to parse the target demand chain to obtain a target description language corresponding to the target demand chain, and determining the target description language as target demand data corresponding to the target element demand, includes: Based on a pre-established domain semantic constraint library, the demand chain corresponding to the entity node is transformed to obtain standardized expression data corresponding to the demand chain. The pre-established domain semantic constraint library includes terminology mapping rules, logical association rules, and description specification rules. The preset prompt words, the demand chain sequence in the standardized expression data, and the associated node attributes are input into the large model to obtain the target demand corresponding to the demand chain. The preset prompt words include at least top-level target type prompt words, scenario type prompt words, stakeholder type prompt words, entity type prompt words, functional service type prompt words, relationship type prompt words, and performance type prompt words.

[0011] Some embodiments of this application further extract and generate semantic information about requirements based on the results of requirement reasoning. They explore deep semantic relationships through multi-hop path search and Graph-RAG techniques. Combined with graph structure feature indicators and multi-objective optimization methods, they quantitatively evaluate and classify the importance of requirements.

[0012] Optionally, the IVCPS requirement element knowledge base is obtained in the following way: Based on standards, policy documents, technical white papers, research results, and typical application cases, the Stanford seven-step method and iterative method are used to generate the ontology model. An entity and relation extraction algorithm is used to extract entities and relations from the ontology model to obtain a knowledge graph corresponding to the ontology model. The graph embedding method is used to convert entity nodes in the knowledge graph corresponding to the ontology model into embedding vectors corresponding to the entity nodes. Hierarchical clustering algorithm, point similarity measurement method and community detection are used to calculate the association relationship between the knowledge graphs corresponding to two different ontology models; The IVCPS requirement element knowledge base is obtained based on multiple knowledge graphs and the relationships between them.

[0013] Some embodiments of this application perform unified modeling of demand element knowledge in structured, semi-structured, and unstructured forms to form a hybrid storage architecture that can be integrated. Secondly, based on knowledge engineering technology, a database supporting relational modeling and reasoning analysis is constructed to realize the large-scale management and engineered use of demand knowledge. Finally, combined with the demand engineering process, a retrieval and calling mechanism is designed so that demand knowledge can be systematically and traceably applied in the analysis, verification, and architecture design stages.

[0014] Optionally, the step of employing a graph embedding method to convert entity nodes in the knowledge graph corresponding to the ontology model into embedding vectors corresponding to the entity nodes includes: The BGE text vector model is used to generate embedding vectors of entity nodes in the knowledge graph corresponding to the ontology model. The BGE text vector model adopts a dual-tower structure based on Transformer Encoder. After text input is segmented and embedded, the contextual semantic relationship is modeled through a multi-layer self-attention mechanism.

[0015] Secondly, some embodiments of this application provide an IVCPS demand generation apparatus, including: The acquisition module is used to acquire the target element requirements; The determination module is used to determine the entity node corresponding to the target element requirement based on the pre-established IVCPS requirement element knowledge base. The IVCPS requirement element knowledge base is obtained by establishing ontology models of different elements, generating corresponding knowledge graphs based on the ontology models, and associating the different knowledge graphs. The generation module is used to generate a target requirement link corresponding to the entity node based on the entity node; The parsing module is used to parse the target demand chain using a pre-trained large model, obtain the target description language corresponding to the target demand chain, and determine the target description language as the target demand data corresponding to the target element demand.

[0016] Some embodiments of this application establish ontology models for different elements, generate corresponding knowledge graphs based on the ontology models, and associate the different knowledge graphs to obtain an IVCPS requirement element knowledge base. Then, after obtaining the target element requirement, it matches it in the IVCPS requirement element knowledge base to obtain the corresponding entity nodes. Based on the entity nodes, a target requirement link is generated. Then, based on a trained large model, the target requirement link is parsed to obtain the target description language corresponding to the target requirement link. This yields the target requirement data corresponding to the target element requirement. Thus, based on the target element requirement of one of the stakeholders, combined with knowledge, logic, and systems from various fields, a systematic, scientific, and comprehensive set of stakeholder requirements, functional requirements at each level, performance requirements at each level, and design constraint requirements are generated semi-automatically and automatically. By integrating the constraints from multiple parties, a corresponding target description language is generated, achieving comprehensive coverage of regional elements, reducing and eliminating requirement omissions, and improving the efficiency of requirement analysis.

[0017] Thirdly, some embodiments of this application provide an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, can implement the IVCPS demand generation method as described in any embodiment of the first aspect.

[0018] Fourthly, some embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, can implement the IVCPS demand generation method as described in any embodiment of the first aspect.

[0019] Fifthly, some embodiments of this application provide a computer program product, the computer program product including a computer program, wherein the computer program, when executed by a processor, can implement the IVCPS demand generation method as described in any embodiment of the first aspect. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of some embodiments of this application, the accompanying drawings used in some embodiments of this application will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating an IVCPS requirements generation method provided in an embodiment of this application; Figure 2 A flowchart illustrating another IVCPS requirement generation method provided in this application embodiment; Figure 3 This is a schematic diagram of the knowledge base construction process provided in an embodiment of this application; Figure 4 A schematic diagram of the IVCPS requirement ontology construction method that combines the Stanford seven-step method with a cyclic iterative method, provided for an embodiment of this application; Figure 5 A schematic diagram of the ontology model provided in the embodiments of this application; Figure 6 This is a schematic diagram of a knowledge graph provided for an embodiment of this application; Figure 7 A schematic diagram of the knowledge base provided for an embodiment of this application; Figure 8 A schematic diagram of the structure of an IVCPS demand generation device provided in an embodiment of this application; Figure 9 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0022] The technical solutions of some embodiments of this application will now be described with reference to the accompanying drawings.

[0023] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] As the demonstration projects progress in depth, the related industrial system is gradually shifting from breakthroughs in single technologies to systematic integration and development across industries and fields, exhibiting an overall trend of collaborative evolution among multiple stakeholders such as vehicles, roads, cloud computing, networks, and maps. With the rapid expansion of system scale, significantly increased real-time requirements for multi-stakeholder collaboration, and the continuous enrichment of application scenarios and task forms, the overall system is gradually showing characteristics such as highly complex interaction relationships, highly heterogeneous system forms, significantly enhanced coupling across spatiotemporal scales, and an accelerated pace of system evolution and demand changes. Its complexity has clearly exceeded the support capabilities of traditional single-system or single-domain technological paradigms.

[0025] As a complex system deeply integrating "vehicle, road, cloud, network, and map," IVCPS (Intelligent Vehicle Cyber-Physical System) needs to simultaneously meet the dynamic requirements of multi-domain collaboration (vehicle control, road infrastructure, cloud computing platform, communication network, high-precision map) and multiple stakeholders (road managers, vehicle manufacturers, autonomous driving operators, drivers, passengers, pedestrians, and non-motorized vehicles). In the development of IVCPS, requirements analysis is a core step, used to define system functions, performance indicators, and safety constraints. However, in existing technologies, requirements analysis methods generally rely on static, manually-led processes, which cannot dynamically adapt to real-time changes in the intelligent vehicle environment (such as road conditions, user behavior, and sensor data fluctuations). In other words, if the needs of one implementing party change and are constrained by the capabilities of other implementing parties, meaning the requirements analysis is based solely on input from one party (such as a requirements document provided by a vehicle manufacturer) and fails to consider the needs of other stakeholders—that is, if a dynamic coordination mechanism across domains and stakeholders is not established—it leads to one-sided requirements design, unidentified conflicts, and delayed decision-making, ultimately causing system design deviations. For example, the failure to incorporate pedestrian safety requirements into autonomous driving decisions increases accident risks, prolongs system development cycles, and increases costs. Therefore, if... Figure 1 As shown, embodiments of this application provide a requirement generation method for IVCPS, the method comprising: S101. Obtain the target element requirements; Specifically, the terminal device acquires the target element requirement, which is text data. It annotates the keywords in the text data to obtain searchable requirement text data. The target element requirement is the requirement of any party in IVCPS.

[0026] S102. Based on the pre-established IVCPS demand element knowledge base, determine the entity nodes corresponding to the target element demand. The IVCPS demand element knowledge base is obtained by establishing ontology models of different elements, generating corresponding knowledge graphs based on the ontology models, and associating the different knowledge graphs. Specifically, the terminal device uses the Stanford seven-step method and iterative processing to generate an ontology model based on standards, policy documents, technical white papers, research results, and typical application cases. It then uses entity and relation extraction algorithms to extract entities and relations from the ontology model, obtaining a knowledge graph corresponding to the ontology model. A graph embedding method is used to convert entity nodes in the knowledge graph corresponding to the ontology model into embedding vectors corresponding to those entity nodes. Hierarchical clustering, point similarity measurement, and community detection algorithms are used to calculate the relationships between the knowledge graphs corresponding to two different ontology models. Finally, based on multiple knowledge graphs and the relationships between them, an IVCPS requirement element knowledge base is obtained.

[0027] Once the terminal device obtains the target element requirement, it searches in the IVCPS requirement element knowledge base to obtain the entity node corresponding to the target element requirement.

[0028] S103. Generate a target demand link corresponding to the entity node based on the entity node; Specifically, after acquiring entity nodes, the terminal device uses a pre-established demand association pattern, a class hierarchy defined in the demand ontology, attribute constraints and inheritance relationships, and a demand relationship completion algorithm based on the graph convolutional network model (GCN) to calculate multiple demand links formed by each entity node. Then, it uses any one of the node importance calculation method, subgraph connectivity analysis method, and link importance aggregation method to select the optimal link from the multiple demand links corresponding to the entity node, and uses the optimal link as the target demand link.

[0029] S104. Using a pre-trained large model, the target demand chain is parsed to obtain the target description language corresponding to the target demand chain, and the target description language is determined as the target demand data corresponding to the target element demand.

[0030] Specifically, a large model is trained on the terminal device. This large model can parse the target demand chain, that is, convert the machine into a natural language description, i.e., the target description language, and determine the target demand data corresponding to the target element demand. In other words, based on the demand of one party in IVCPS, and combined with the constraints of other parties, a comprehensive analysis is performed to finally obtain the natural description language of the chain that satisfies the demand of one party.

[0031] Some embodiments of this application establish ontology models for different elements, generate corresponding knowledge graphs based on the ontology models, and associate the different knowledge graphs to obtain an IVCPS requirement element knowledge base. Then, after obtaining the target element requirement, it matches it in the IVCPS requirement element knowledge base to obtain the corresponding entity nodes. Based on the entity nodes, a target requirement link is generated. Then, based on a trained large model, the target requirement link is parsed to obtain the target description language corresponding to the target requirement link. This yields the target requirement data corresponding to the target element requirement. Thus, based on the target element requirement of one of the stakeholders, combined with knowledge, logic, and systems from various fields, a systematic, scientific, and comprehensive set of stakeholder requirements, functional requirements at each level, performance requirements at each level, and design constraint requirements are generated semi-automatically and automatically. By integrating the constraints from multiple parties, a corresponding target description language is generated, achieving comprehensive coverage of regional elements, reducing and eliminating requirement omissions, and improving the efficiency of requirement analysis.

[0032] Another embodiment of this application further supplements the description of the IVCPS requirement generation method provided in the above embodiments.

[0033] This application's embodiments address the heterogeneity, implicitness, and dynamic characteristics of IVCPS requirements. It constructs a systematic technical path from "explicit modeling of requirement knowledge" to "requirement logic reasoning" and then to "standardized requirement generation." It unifies the semantic boundaries of requirements across different domains and entities through a requirement ontology, alleviating ambiguity in requirement expression caused by cross-domain integration. It depicts the multi-level, multi-relational dependency structure between requirement elements through a requirement knowledge graph, supporting the structured expression of complex requirement logic. It mines implicit requirement relationships through knowledge reasoning and semantic embedding, addressing the implicit requirement issues arising from multi-temporal-scale collaboration and system emergence. Finally, it transforms the reasoning results into traceable natural language requirement descriptions that conform to requirement engineering specifications through a requirement generation mechanism driven by Graph-RAG and large language models.

[0034] like Figure 2 As shown in the embodiments of this application, the requirements analysis method for semantic unification, knowledge modeling, logical deduction, and requirements generation specifically includes: (1) Semantic unification principle: By constructing the IVCPS requirement ontology, the core concepts, object types and semantic relationships related to requirements are formally defined, providing unified semantic constraints for subsequent requirement knowledge extraction and reasoning analysis.

[0035] (2) The principle of demand knowledge structuring: using demand knowledge graph as a carrier, demand elements and their relationships are modeled in the form of triples to realize the transformation of demand from unstructured text to structured knowledge.

[0036] (3) The principle of demand logic reasoning, combined with rule reasoning and graph embedding method, is used to reason and analyze the multi-hop relationships and potential dependencies in the demand knowledge graph, revealing the demand logic across subjects and levels.

[0037] (4) Principles of requirement generation and standardization mapping: Based on the reasoning results, the Graph-RAG mechanism is further integrated to combine the structured relationships and multi-hop semantic paths in the knowledge graph with the generation capabilities of the large language model, thereby achieving deep activation and context enhancement of complex requirement semantics in IVCPS. In addition, by combining prompting engineering and requirement engineering standards, the knowledge and reasoning chain is mapped into standardized and verifiable requirement text.

[0038] To support the textual tracing and semantic verification of IVCPS requirement reasoning results, a semantic requirement library for IVCPS requirement analysis is constructed based on the aforementioned requirement knowledge system storage. This library provides unified modeling, indexing, and management of requirement source texts, domain specifications, and related supporting materials. First, requirement-related texts are structured and semantically annotated to form searchable requirement text units. Second, a multi-dimensional index is constructed based on semantic features and requirement elements to achieve efficient retrieval based on requirement semantics. Finally, the retrieval results serve as the textual basis and verification support for requirement reasoning results, achieving collaborative support between the requirement library and the requirement knowledge reasoning process.

[0039] Optionally, the requirement to obtain the target element includes: Obtain the target element requirements; The text data of the target element requirements is structured to obtain the processed target element requirements; The processed target requirements are semantically annotated to obtain searchable requirement text data.

[0040] Specifically, the terminal device acquires the target element requirement, annotates the target element requirement, determines the scenario type of the target element requirement, and uses a multi-level semantic parsing technology stack to ensure the accuracy and domain adaptability of the matching process.

[0041] Optionally, determining the entity node corresponding to the target element requirement based on a pre-established IVCPS requirement element knowledge base includes: Determine the first feature vector of the retrieveable demand text data; Calculate the similarity between the first feature vector and the second feature vector of the entity node in the IVCPS demand element knowledge base, respectively; If the similarity is greater than the similarity threshold, then the searchable demand text data and the entity node are determined to match; Based on the pre-established IVCPS demand element knowledge base, attribute information corresponding to the searchable demand text data is determined, wherein the pre-established IVCPS demand element knowledge base includes entities and attribute information corresponding to the entities. Specifically, the generation of terminal device requirements begins with typical application scenarios, clarifying scenario objectives and operational boundaries, and identifying key elements such as traffic participants, environmental conditions, system components, and stakeholders. Subsequently, using semantic retrieval and entity localization mechanisms, the scenario elements and knowledge nodes are precisely aligned in the requirement knowledge graph, activating relevant entities and their attribute relationships, and providing a clear semantic starting point for requirement reasoning.

[0042] After completing the matching of scene elements and obtaining the node set, the requirement reasoning enters the graph reasoning stage. This stage uses the entity types and semantic relationships defined in the requirement ontology as constraints, and generates requirement links with clear semantic orientations through a multi-layer reasoning mechanism around core entities such as vehicles, roads, cloud, networks, algorithm models, functional services, and information operation primitives, in order to characterize the relationships between requirements in different entities.

[0043] (1) Semantic preprocessing and scene element embedding representation The input scenario description text (such as "autonomous vehicles operating in complex urban road environments") is first subjected to basic semantic preprocessing by spaCy, including word segmentation, part-of-speech tagging and named entity recognition (NER) to extract core semantic units with demand semantic orientation (such as "autonomous vehicles", "urban roads", "complex traffic environment" etc.).

[0044] Building upon this foundation, a semantic embedding model based on BERT and fine-tuned using the IVCPS domain corpus (standard specifications, technical reports, and requirement documents) is employed to vectorize scene semantic units, thereby obtaining text embedding representations that can be used for semantic similarity calculation. Through domain-adaptive fine-tuning, this model significantly improves its ability to recognize specialized terms such as "vehicle-road cooperation," "Level 4," and "high-precision map."

[0045] Simultaneously, semantic embedding representations are pre-constructed for entity nodes corresponding to the 16 core concepts in the IVCPS demand ontology model (such as vehicle-physical entity, road-physical entity, road-information entity, vehicle-information entity, network-information operation primitives, etc.), forming a unified semantic matching space. The semantic similarity between scene elements and ontology entities is calculated using cosine similarity (see Equation 1.1 below), and low-confidence matching results are filtered by setting a threshold.

[0046] Cosine similarity formula: (1.1) Where E(s) is the scene text embedding, and E(n) is the predefined embedding of knowledge base nodes (such as "information entity"). A similarity threshold of 0.75 is set to filter low-confidence matches (for example, "high-precision map" and "road-information entity" have a semantic similarity of 0.82, which meets the threshold requirement and is judged as a valid match).

[0047] (2) Entity disambiguation and attribute-level matching based on ontology class hierarchy; To avoid ambiguity between the semantics of the scene description and the ontology concept (e.g., "vehicle" may correspond to different ontology classes in different contexts), the matching process introduces the class hierarchy and inheritance relationship of the requirement ontology for constraint. All candidate matching results must satisfy the class affiliation and inheritance structure defined in the ontology. For example, "autonomous vehicle" is explicitly classified as a vehicle—a physical entity—in the ontology, rather than a stakeholder entity, thus automatically excluding candidate nodes that do not meet the class hierarchy constraints during the matching phase.

[0048] Building upon entity category matching, further attribute-level matching and constraint verification are conducted. For concepts such as vehicle-physical entities, road-physical entities, and information operation primitives, fine-grained matching is performed based on their key attributes defined in the ontology (such as autonomous driving level, road type, map accuracy, etc.). For example, when matching "high-precision map," not only is it confirmed that it belongs to the road-information entity, but it also needs to meet attribute constraints such as map accuracy (associated attribute map accuracy = 0.1m).

[0049] Meanwhile, for the entity relationships implied in the scene description, consistency checks are performed on the relationships between entities based on the semantic relationship types defined in the ontology (such as relying on, carrying, depending on, supporting, etc.) to ensure that the matching results conform to the semantic constraints of the ontology relationship.

[0050] (3) Verification of matching results and structural integrity check After completing entity and attribute matching, the results undergo structured validation based on ontology constraints to ensure that the scene element set meets the definition requirements of the required ontology in terms of class affiliation, attribute values, and entity relationships. For example, complex road scenes need to fully cover key attribute ranges such as road type, road grade, road alignment, road environment, and traffic composition at the road-physical entity level. The final output is a set of structured nodes, such as: {“Vehicle – Physical Entity”: {“Autonomous Driving Level”, “Vehicle Type – Model”...}, "Road – Physical Entity": {"Road Type", "Road Class", "Road Alignment", "Road Environment", "Traffic Components"...} "Information Entities": {"Road-Information Entity", "Vehicle-Information Entity", "High-Precision Map"}.

[0051] Some embodiments of this application begin with typical application scenarios, clarifying the scenario objectives and operational boundaries, and identifying key elements such as traffic participants, environmental conditions, system components, and stakeholders. Subsequently, by leveraging semantic retrieval and entity localization mechanisms, precise alignment of scenario elements and knowledge nodes is achieved in the demand knowledge graph, activating relevant entities and their attribute relationships, and providing a clear semantic starting point for demand reasoning.

[0052] Optionally, generating the target demand link corresponding to the entity node based on the entity node includes: Based on the pre-established demand association pattern, a general rule reasoning engine under the semantic web framework is adopted. Taking the entity type and semantic relationship defined in the demand ontology as the basic constraints, the entity node and the pre-established IVCPS demand element knowledge base are matched in the form of RDF triples to obtain the first demand link corresponding to the entity node. Based on the class hierarchy, attribute constraints and inheritance relationships defined in the requirement ontology, the implicit requirement relationship of the description logic is constructed, and based on the implicit requirement relationship of the description logic, the second requirement link corresponding to the entity node is generated. The demand relationship completion algorithm based on the graph convolutional network model (GCN) determines the probability corresponding to the entity node based on the knowledge graph, the embedding vector of the entity node, and the semantic relationship type, and determines the third demand link corresponding to the entity node based on the probability. Based on the first demand link, the second demand link, and the third demand link, determine the target demand link corresponding to the entity node.

[0053] Specifically, the requirement chain provided in this application embodiment is as follows: Vehicle – Physical entity → Dependence → Algorithm model entity → Reliance → Cloud – Basic unit of information operation; Road – Physical Entity → Constraint → Road – Information Entity → Support → Vehicle – Information Entity → Vehicle – Physical Entity.

[0054] (1) A rule-based explicit relational reasoning mechanism is used to construct the Apache Jena general rule reasoning engine (Apache Jena: Semantic Web framework) for requirement association patterns with explicit engineering semantics in IVCPS. The rules are based on the entity types and semantic relationships defined in the requirement ontology as basic constraints, expressed in the form of RDF triples, and matched and triggered by the rule reasoning engine.

[0055] Here are some examples of rules (replacing the generalized predicate with the defined relation): (car rdf:type Car – Physical Entity) (car dependency or algo) (algo rdf:type Algorithm model entity) (algo relies on cloud) (Car depends on cloud) When the set of input nodes contains a specific "vehicle-physical entity" (such as having L4 autonomous driving capability) and its associated algorithm model entity, the rule engine can automatically deduce the vehicle's dependency requirements on "cloud-physical entity" or "cloud-information operation primitive entity".

[0056] These rules cover typical IVCPS application scenarios (such as "Level 4 autonomous driving requires cloud platform support for real-time data processing") and are executed efficiently through SPARQL queries. Each rule inference result is accompanied by a corresponding rule identifier ID (e.g., RULE-003) to support the interpretability and traceability of the required results.

[0057] (2) Implicit requirement relationship reasoning based on description logic: In order to uncover potential requirement relationships that are not explicitly expressed in the rules, an implicit reasoning mechanism based on description logic (Pellet) is introduced. This mechanism relies on the class hierarchy, attribute constraints and inheritance relationships defined in the requirement ontology to automatically deduce the implicit requirement relationships between entities.

[0058] For example, define the following logical constraints in the ontology: Car – physical entity Based on the Some algorithm model entity Road – Physical Entity (Road complexity = High) Constraint some path – information entity When a complex road scene is identified in the scene element matching results, the logical reasoning mechanism can automatically deduce the constraining requirements for road-information entities such as high-precision maps, thereby generating the following requirement chain: Road – Physical entity → Constraint → Road – Information entity → Support → Vehicle – Information entity; This type of reasoning does not rely on manual explicit rule configuration, and can effectively supplement the implicit but reasonable demand relationships in the knowledge base, avoiding reasoning omissions caused by insufficient rule coverage.

[0059] (3) Based on GCN, a demand relationship completion mechanism is introduced to further identify potential but not explicitly modeled demand relationships, building upon rule-based reasoning and logical reasoning. This mechanism takes the demand knowledge graph as input, uses entity node embedding and semantic relationship type as features, and uses a graph convolutional network to predict the probability of possible relationships between entities.

[0060] The inputs to the GCN model include: Ontology entity node embedding (TransE generation) (e.g., vehicle – physical entity, network – information operation primitive, algorithm model entity, etc.); Defined semantic relationship type features (such as dependency, support, empowerment, carrying, etc.).

[0061] The model output is the probability (i.e., the likelihood) that an entity pair holds true under a specific semantic relationship, which is used to discover potential demand chains, for example: Vehicle – Physical Entity → Dependence → Network – Basic Element of Information Operation → Support → Cloud – Basic Element of Information Operation This mechanism is mainly used for completing the demand chain and generating candidates. The results must be verified by rules or logical constraints before they can be included in the final demand reasoning results to ensure consistency with the semantics of the demand ontology.

[0062] Some embodiments of this application, based on the activated requirement knowledge subgraph, use various mechanisms such as rule-driven reasoning and graph structure reasoning to mine the requirement logic links across entities and levels, and deduce potential functional constraints, performance requirements and collaborative relationships. This process can not only characterize explicit requirements, but also reveal implicit requirement associations and system behavior constraints, thereby improving the systematicness and foresight of requirement analysis. Optionally, determining the target demand link corresponding to the entity node based on the first demand link, the second demand link, and the third demand link includes: The target demand link is determined from multiple demand links corresponding to the entity node by employing node importance calculation method, subgraph connectivity analysis method, and link importance aggregation method.

[0063] This application embodiment uses a graph theory analysis method based on knowledge graphs to perform multi-dimensional quantitative evaluation of links, subgraphs, and nodes. Specifically, it employs any one of the following methods: node importance calculation, subgraph connectivity analysis, and link importance aggregation, to select the optimal target demand link from multiple demand links corresponding to the entity node. 1) Node Global Importance Calculation (PageRank): The PageRank algorithm is used to evaluate the global influence of nodes in the knowledge graph. The specific implementation is as follows: Constructing the adjacency matrix of a knowledge graph ,in Represents a node To the node Edge weights (e.g., the "dependency" weight is 0.85); Initialize node weight vector , The total number of nodes; Iteratively update node weights: (1.2) in, The damping coefficient is... It is a uniformly distributed vector; Iterate until convergence: .

[0064] Node importance value This reflects its global influence as a hub node. For example, the PageRank values ​​of the "vehicle-physical entity" node and the "cloud-information operation primitive entity" node are significantly higher than those of other nodes, indicating that they occupy a core position in the critical business path.

[0065] 2) Subgraph Connectivity Analysis (Closeness Centrality): For subgraphs involved in the demand chain (e.g., vehicle – physical entity node → cloud – information operation primitive entity), Closeness Centrality is used to evaluate the connectivity efficiency of key business paths. Define subgraph This refers to the nodes and edges involved in the link; Calculate the average shortest path length from a node to other nodes in the subgraph: (1.3) in, For nodes arrive The shortest path length; Subgraph centrality is calculated as the average of the Closeness values ​​of all nodes within the subgraph. (1.4) The higher the value, the stronger the connectivity of the subgraph. For example, the Closeness value of the subgraph "vehicle – physical entity node → cloud – information operation primitive entity" is close to 1 in security requirements, indicating that it is a high-efficiency critical path.

[0066] 3) Link importance aggregation: By combining node importance, subgraph centrality, and edge weights, an overall link importance score is formed. Extract the PageRank value of each node in the link. ; Calculate the Closeness Centrality value of the subgraph to which the link belongs. ; Get the product of the weights of all edges in the link: ; Comprehensive weighted generation of link importance: (1.5) Among them, the weighting coefficient , , Based on domain experience, settings are implemented to ensure high security requirements. ) and core path (high ( ) to gain higher weight.

[0067] Optionally, the step of using a pre-trained large model to parse the target demand chain to obtain a target description language corresponding to the target demand chain, and determining the target description language as target demand data corresponding to the target element demand, includes: Based on a pre-established domain semantic constraint library, the demand chain corresponding to the entity node is transformed to obtain standardized expression data corresponding to the demand chain. The pre-established domain semantic constraint library includes terminology mapping rules, logical association rules, and description specification rules. The preset prompt words, the demand chain sequence in the standardized expression data, and the associated node attributes are input into the large model to obtain the target demand corresponding to the demand chain. The preset prompt words include at least top-level target type prompt words, scenario type prompt words, stakeholder type prompt words, entity type prompt words, functional service type prompt words, relationship type prompt words, and performance type prompt words.

[0068] In this embodiment, the links are processed into requirement items through a large model, and the corresponding importance is given by the importance analysis methods of links, subgraphs and nodes in knowledge graphs and graph theory.

[0069] The requirement generation stage aims to transform the structured requirement chain obtained from the aforementioned reasoning (e.g., vehicle – physical entity → road – information entity → map accuracy = 0.1m) into natural language requirement items conforming to the IVCPS domain specification. To ensure the generated results meet the requirements of semantic accuracy, specification consistency, and reusability, this study employs a domain knowledge-enhanced instruction fine-tuning large language model (LLM) to generate requirement text. Its technical implementation mainly includes two key sub-modules: the construction of a domain semantic constraint library and a link-requirement mapping fine-tuning mechanism. 1) Construction of the Domain Semantic Constraint Library: The domain semantic constraint library is built upon IVCPS-related standards, specifications, and technical documents (such as C-V2X communication standards and autonomous driving safety technical specifications) to impose domain semantic and expressive constraints on the requirement generation process. The constraint library mainly includes the following three types of semantic rules: Terminology mapping rules: used to convert attribute values ​​in the demand chain into standardized expressions that conform to industry standards, such as mapping "map accuracy = 0.1m" to "map accuracy not less than 0.1 meters"; Logical association rules: used to describe the necessary constraint relationships between scene attributes, such as automatically associating conditions such as "road segment type: general road segment, at-grade intersection, grade-separated intersection" in the smart bus scenario; Description guidelines: These are used to constrain the sentence structure and expression paradigm of requirement texts. For example, security requirements must follow the standardized expression logic of "It is necessary to ensure... to achieve...".

[0070] The aforementioned semantic rules are stored in the requirements knowledge base in the form of RDF triples and dynamically invoked during the requirements generation process through SPARQL queries to ensure that the generated results are consistent with the IVCPS domain specifications in terms of terminology, logic, and expression.

[0071] ② Link-Requirement Mapping Fine-Tuning Mechanism: Link-requirement mapping is achieved by fine-tuning the large language model through instructions. During fine-tuning, the model input consists of a structured requirement link sequence (e.g., [vehicle-physical entity, road-information entity, map accuracy = 0.1 m]) and its associated node attributes (e.g., vehicle-physical entity: autonomous driving level = Level 4). The model output is a standardized requirement text that meets domain semantic constraints. Through this mapping mechanism, a stable conversion from structured requirement semantics to natural language requirement items is achieved.

[0072] To support automated reasoning and data processing in IVCPS requirements analysis, this study designed a core prompting word system. This system unifies task instructions, data parsing, model invocation, and requirements generation processes through a standardized prompting framework, ensuring efficient operation of the entire chain from requirements element identification and requirements reasoning to requirements generation.

[0073] In this application embodiment, the prompts clarify the various stages and responsibilities in the requirements analysis process, focusing on core tasks such as requirement element identification, functional requirement reasoning, performance evaluation, and constraint analysis, thereby ensuring that the output meets engineering and standardization requirements.

[0074] Then, input and preprocessing rules are adopted to define the data types (such as text, images, tables, etc.) that the system can accept and the corresponding processing tools, including data format recognition, field validation, and time and space benchmark alignment. This part provides the foundation for data standardization processing, ensuring the accuracy of subsequent requirement modeling and reasoning.

[0075] The task instruction flow (F-series instructions) is designed: an execution chain from F1 to F7 is established, covering multiple steps in requirements analysis, including input parsing, data preprocessing, requirements reasoning, and standard compliance analysis. Each task instruction has a dependency relationship, ensuring the logic and traceability of the execution flow.

[0076] The prompt word system incorporates logical modules such as requirement reasoning, evidence fusion, and knowledge graph retrieval, enabling the system to perform multi-dimensional analysis and causal explanation. This module allows requirement analysis to comprehensively cover system functional requirements, performance requirements, and potential constraints.

[0077] The requirements analysis results are presented in a structured report format using a unified output template. The report includes requirements description, functional analysis, performance evaluation, optimization suggestions, and relevant standard clauses, ensuring the results are standardized, auditable, and reproducible.

[0078] The prompt words in this embodiment are set in the following way: ① Top-level target category suggestions, where top-level target type suggestions are high-level target types, that is, target category suggestions at the macro level: Goal achievement path: How to achieve the goal through multiple entities and relationships? Goal Priorities: What is the relative importance of different goals? Goal dependencies: Which goals are interdependent? Goal validation: How to measure the achievement of top-level goals? ②Scene-related prompts: Scene description: Provides a detailed scene background, including all physical and informational entities involved.

[0079] Interaction between scenes: Are there any overlaps or dependencies between different scenes? Scene Influencing Factors: Which external factors have a significant impact on changes in the scene? Scenario Requirements Analysis: How to define and refine requirements for different scenarios? ③ Stakeholder-related keywords: Interest Analysis: What are the needs and goals of the different stakeholders? Conflict Management: How to handle conflicts between different stakeholders? Influence analysis: How much influence do the various stakeholders have on the system? ④ Entity-related suggestion keywords: Entity feature definition: Define the features (such as functions, performance, interaction relationships, etc.) for each physical or information entity.

[0080] Entity Relationship Analysis: How to define the interaction between entities through relationships such as "mapping, control, dependency, and support"? Services and support of entities: What are the service or support functions that each entity undertakes? ⑤ Functional service prompts: Functional Requirements Analysis: Based on the objectives and scenarios, how do we define the functions that the system needs to implement? Service Level Constraints: Which services have performance constraints? How to measure and evaluate service quality? Service Priority: How is the priority of different functional services determined? Service Dependencies: What are the dependencies between functional services? ⑥ Relationship-related keywords: Relationship definition and classification: Based on relationships such as "mapping, control, dependency, and support", describe the connotation and extension of each relationship.

[0081] The impact and constraints of relationships: How do certain relationships affect the overall system architecture and requirements? Relationship optimization and adjustment: How to optimize the relationships between different entities during the requirement generation process? ⑦ Performance-related keywords; Performance metrics: How to define system performance standards? Performance Constraints and Measurement: How to measure and optimize a system through performance entities? Dynamic performance tuning: How can performance be adapted and adjusted in different scenarios? This embodiment of the application, after setting prompt words, employs a large model, combining semantic vector retrieval and keyword matching retrieval to construct a recall retrieval module, enabling the retrieval of relevant paragraphs from a local Elasticsearch index based on a user's natural language query. First, the vector model bge-large-zh-v1.5 is loaded to encode the query statement into a vector representation, allowing for similarity matching calculations between the query vector and vectors in the database. Simultaneously, matching conditions are constructed, including three keyword fields (document source, paragraph title, and paragraph content), and multi-field parallel matching is achieved using Elasticsearch's bool.should. In the scoring stage, vector similarity and keyword matching scores are merged to form a comprehensive score. A score value can be set, and the recall retrieval module returns knowledge fragment retrieval results with scores above a threshold. The large model generation stage undertakes the core tasks of language understanding and answer generation. Based on the Elasticsearch recall retrieval module, the most relevant paragraph content to the user's query is retrieved from the index. These recall results serve as contextual information for the large model generation, thus providing knowledge support for the generation process.

[0082] Based on the results of demand reasoning, further semantic extraction and text generation of demands are carried out. Deep semantic relationships are mined through techniques such as multi-hop path search and Graph-RAG; and the importance of demands is quantitatively evaluated and classified by combining graph structure feature indicators and multi-objective optimization methods.

[0083] Subsequently, using LLM and prompting engineering techniques, the reasoning chain and knowledge structure are transformed into natural language requirement descriptions that conform to engineering specifications. By mapping with standards such as IEEE 29148, the standardization and executability of the requirement expression are ensured.

[0084] Some embodiments of this application further extract and generate semantic information about requirements based on the results of requirement reasoning. They explore deep semantic relationships through multi-hop path search and Graph-RAG techniques. Combined with graph structure feature indicators and multi-objective optimization methods, they quantitatively evaluate and classify the importance of requirements.

[0085] Optionally, the IVCPS requirement element knowledge base is obtained in the following way: Based on standards, policy documents, technical white papers, research results, and typical application cases, the Stanford seven-step method and iterative method are used to generate the ontology model. An entity and relation extraction algorithm is used to extract entities and relations from the ontology model to obtain a knowledge graph corresponding to the ontology model. The graph embedding method is used to convert entity nodes in the knowledge graph corresponding to the ontology model into embedding vectors corresponding to the entity nodes. Hierarchical clustering algorithm, point similarity measurement method and community detection are used to calculate the association relationship between the knowledge graphs corresponding to two different ontology models; The IVCPS requirement element knowledge base is obtained based on multiple knowledge graphs and the relationships between them.

[0086] Specifically, such as Figure 3 As shown, this application's embodiments acquire unstructured data, such as standards and specifications, policy documents, technical white papers, research results, and typical application cases, using the Stanford seven-step method and iterative methods (e.g., Figure 4 (As shown) is processed to generate an ontology model (such as...) Figure 5 As shown in the figure, an entity and relation extraction algorithm is used to extract entities and relations from the ontology model, resulting in a knowledge graph corresponding to the ontology model. Each ontology model corresponds to one knowledge graph, such as... Figure 6 As shown, the pink knowledge graph corresponds to an ontology model (e.g. Figure 7 The pink part corresponds to the knowledge graph for specialized goods, while the green part corresponds to another ontology model (e.g., Figure 7 (The green area represents the knowledge graph of the bridge.) Then, each knowledge graph is stored in a graph database or Elasticsearch database. Using graph embedding methods, entity nodes in the knowledge graph corresponding to the ontology model are converted into embedding vectors corresponding to those entity nodes. Hierarchical clustering algorithms, point similarity measurement methods, and community detection are used to calculate the association relationships between the knowledge graphs corresponding to two different ontology models, resulting in... Figure 7 The diagram shown is an illustration of a knowledge base, for example. Figure 7 The relationships between the knowledge graph of special goods and the knowledge graph of bridges are obtained; based on multiple knowledge graphs and the relationships between them, the IVCPS demand element knowledge base is obtained.

[0087] Furthermore, given the continuous evolution of IVCPS-related standards, technologies, and application scenarios, the knowledge system for requirements needs to have the ability to be dynamically updated and adaptively evolved.

[0088] To this end, a dynamic influx and update mechanism for demand-driven knowledge is constructed: a stable knowledge input channel is formed by continuously collecting new policy documents, standards and specifications, research results, and industry cases; ontology alignment, entity disambiguation, and semantic consistency verification methods are used to achieve efficient integration of new knowledge with existing knowledge graphs; and graph construction and manual review mechanisms are combined to ensure the robustness and maintainability of the knowledge system during large-scale expansion. Simultaneously, version recording and evolution tracking mechanisms ensure good traceability and controllability of the knowledge update process.

[0089] Optionally, the step of employing a graph embedding method to convert entity nodes in the knowledge graph corresponding to the ontology model into embedding vectors corresponding to the entity nodes includes: The BGE text vector model is used to generate embedding vectors of entity nodes in the knowledge graph corresponding to the ontology model. The BGE text vector model adopts a dual-tower structure based on Transformer Encoder. After text input is segmented and embedded, the contextual semantic relationship is modeled through a multi-layer self-attention mechanism.

[0090] Specifically, to improve the completeness and reasoning ability of the demand knowledge graph, after the basic graph is constructed, semantic embedding and knowledge completion mechanisms are introduced to mine and expand potential missing relationships and implicit demand associations.

[0091] This stage, based on the IVCPS requirement ontology constraints, employs graph embedding methods (such as TransE and GCN) to map entities and relationships in the graph to a low-dimensional semantic space, achieving automatic completion of requirement relationships through link prediction. Simultaneously, a manual verification mechanism is used to validate the completion results, thereby enhancing the expressive power and intelligent reasoning potential of the requirement knowledge graph in complex scenarios.

[0092] Some embodiments of this application perform unified modeling of demand element knowledge in structured, semi-structured, and unstructured forms to form a hybrid storage architecture that can be integrated. Secondly, based on knowledge engineering technology, a database supporting relational modeling and reasoning analysis is constructed to realize the large-scale management and engineered use of demand knowledge. Finally, combined with the demand engineering process, a retrieval and calling mechanism is designed so that demand knowledge can be systematically and traceably applied in the analysis, verification, and architecture design stages.

[0093] While automated reasoning and generation technologies can significantly improve efficiency, manual verification remains a crucial step in ensuring the scientific validity and reliability of the IVCPS requirements system. Through consistency checks, expert review, and requirements tracing verification, generated requirements are comprehensively validated to ensure that each requirement can be traced back to a clear knowledge source and reasoning path.

[0094] A structured verification framework is built based on a knowledge base of demand elements to ensure that the generated requirements meet the IVCPS architecture design requirements in terms of semantic standardization, logical consistency, and business applicability. This step achieves scientific rigor and engineering implementation of the verification process through a triple mechanism of rule-driven, expert collaboration, and evidence closed-loop.

[0095] (1) Construction of verification standard system The verification criteria strictly rely on the RDF constraint rules of the IVCPS requirements library and are divided into three layers: Semantic specification layer: Based on a domain terminology library (such as the C-V2X protocol standard expression), it defines the mandatory syntactic structure for requirement descriptions. For example, security requirements must adopt the logical framework of "must ensure... to achieve...", and the "precision" attribute must use the standardized expression "not less than X meters".

[0096] Logical Consistency Layer: Utilizes the ontology reasoning engine to verify the logical chain of scenario – attribute – constraint. When the requirement involves a "rainstorm weather" scenario, the system automatically triggers ontology rules to check whether the "road type" is "complex road" and verifies whether the "map accuracy" meets the scenario requirements (e.g., rainstorm scenario accuracy ≥ 0.1m).

[0097] Business Applicability Layer: Based on the business rules associated with the top-level entity (the entity in the top-level objective) (such as autonomous driving safety), verify whether the requirements cover key constraints. For example, a requirement item involving "Level 4 autonomous driving" must include the explicit constraint of "complying with national autonomous driving safety standards".

[0098] All rules are stored in the knowledge base as RDF triples and dynamically loaded through SPARQL queries to achieve synchronous updates of verification standards and domain knowledge.

[0099] The verification process adopts a phased and traceable execution mode: Automatic pre-verification phase: The system automatically scans the generated requirements based on the rule engine and outputs a structured issue report. For example, if the text "map accuracy 0.1m" does not use the standard expression "not less than 0.1 meters", the system marks it as "semantic non-compliance" and associates it with a specific rule ID (such as RULE-007). The pre-verification results are output in JSON format, including the issue type, location, and correction suggestions.

[0100] In-depth expert verification phase: Domain experts and architects conduct manual verification based on the pre-verification report. Support for knowledge base context linkage: Clicking on the "Rainy Weather" scenario expands the associated rules (e.g., Road Type = Complex Road), and clicking on "Map Accuracy" displays the business basis (e.g., Section 5.2 of the C-V2X protocol). The verification process mandates the recording of decision-making basis, including the referenced rule ID, knowledge base node ID, and business scenario description.

[0101] Decision-making closed-loop stage: The verification results are divided into three categories: Passed: The requirement status is marked as "verified"; Correction required: The requirement should be returned to the generation module along with specific correction suggestions (such as "security constraints need to be added"). Rejection: The requirement triggers an update to the knowledge base rules (e.g., a rainstorm scenario must be associated with complex road attributes), and the reason for rejection is recorded.

[0102] All decisions generate RDF triples (format: Requirement ID – Verification Result – Rule ID), which are written to the knowledge base in real time to form an auditable verification evidence chain.

[0103] Evidence from the manual verification process is managed in a structured manner to ensure reproducibility. Evidence storage: All verification activities (timestamp, personnel ID, requirement ID, problem description, decision basis) are stored in RDF triples, for example: <demand_123><verified_by><expert_045> <demand_123><violated_rule> <rule-007> <demand_123><correction_suggestion> The map accuracy must be stated as "no less than 0.1 meters". Evidence retrieval: SPARQL allows you to trace the verification history of any requirement, for example: SELECT rule suggestion WHERE {<demand_123><violated_rule> rule; <correction_suggestion> suggestion} Version control: Knowledge base rules are bound to verification records. When a rule is updated (such as adding a new accuracy requirement for a rainstorm scenario), the system automatically marks the historical verification record as "requires re-verification" to ensure that the verification system evolves in sync with domain knowledge.

[0104] This stage is fully embedded in the IVCPS static knowledge base framework, independent of external environmental input, achieving a closed-loop connection with the requirement generation and importance classification stages. Rule-driven automated pre-verification reduces manual workload, in-depth expert review ensures verification of key logic, and the evidence closed-loop mechanism guarantees result traceability and engineering reliability, achieving end-to-end technical assurance from link reasoning to requirement implementation.

[0105] Ultimately, this forms a top-level requirement system for IVCPS that is semantically complete, logically consistent, manageable, verifiable, and capable of continuous evolution.

[0106] This application's embodiments can retrieve and map input terrain, landforms, schools, hospitals, etc., to task scenarios, generating corresponding requirements (e.g., "school perimeter" triggers "pedestrian safety" requirement). Through ontology semantic mapping (e.g., school → pedestrian safety requirement), the system automatically associates all elements, avoiding human oversight. For example, inputting "a smart park including a school" will simultaneously identify "the roads around the school are side roads with gentle terrain," triggering pedestrian crossing safety requirements and low-speed vehicle passage function requirements, ensuring comprehensive requirement coverage.

[0107] Requirements analysis is no longer constrained by human experience; regional elements (scale, road network, facilities, task scenarios) are all captured by the system, generating complete requirements that lay a solid foundation for subsequent design. A meta-layer semantic framework unifies multi-domain data and dynamically balances the demands of all parties: the system integrates data from road management departments (speed limit rules), cloud platform traffic flow, and vehicle-side sensor data into the meta-framework (physical entities / information entities / interaction entities), dynamically calculating benefit weights based on scenarios (e.g., in a school scenario, pedestrian safety is prioritized over vehicle efficiency).

[0108] This application proposes a knowledge reasoning-driven, large-model-enhanced IVCPS requirement analysis method (see figure). This method centers on the construction of a requirement knowledge system. By introducing requirement ontology, requirement knowledge graph, semantic embedding, and knowledge reasoning mechanisms, it transforms scattered and implicit requirement information from multiple sources of text into structured, computable, and reasonable requirement knowledge representations. Based on this, it combines Graph-RAG (Graph-based Retrieval-Augmented Generation) and Large Language Model (LLM) to achieve automated requirement generation and continuous evolution. Through multi-scale knowledge management and collaboration mechanisms, it accurately identifies key requirements from various cyber-physical heterogeneous entities such as vehicles, roads, and the cloud in physical-information interactions, and achieves comprehensive and adaptive requirement analysis through intelligent scenario decomposition and dynamic requirement mapping.

[0109] The requirements ontology modeling, multi-source knowledge fusion, meta-level semantic framework, and semantic-driven automation provided in this application's embodiments, by introducing requirements ontology modeling methods, semantically abstract and structurally express requirements information and related industry knowledge from different subjects, scenarios, and domains. Combined with knowledge extraction, graph representation learning, Graph-RAG, and large language models, this research constructs a top-level requirements analysis method and technical framework for the IVCPS overall system architecture. It systematically characterizes the core operational characteristics and key technical features of the system, forming a unified semantic specification to support systematic design and cross-subject collaboration. This enables a systematic, scientific, and automated generation method for IVCPS based on specific scenarios. It should be noted that each of the implementable methods in this embodiment can be implemented individually or in any combination without conflict. This application does not limit this.

[0110] Another embodiment of this application provides an IVCPS demand generation apparatus for executing the IVCPS demand generation method provided in the above embodiments.

[0111] like Figure 8 The diagram shown is a structural schematic of the IVCPS demand generation apparatus provided in an embodiment of this application. The IVCPS demand generation apparatus includes an acquisition module 801, a determination module 802, a generation module 803, and a parsing module 804, wherein: The acquisition module 801 is used to acquire the target element requirements; The determination module 802 is used to determine the entity node corresponding to the target element requirement based on the pre-established IVCPS requirement element knowledge base. The IVCPS requirement element knowledge base is obtained by establishing ontology models of different elements, generating corresponding knowledge graphs based on the ontology models, and associating the different knowledge graphs. The generation module 803 is used to generate a target requirement link corresponding to the entity node based on the entity node; The parsing module 804 is used to parse the target demand chain using a pre-trained large model, obtain the target description language corresponding to the target demand chain, and determine the target description language as the target demand data corresponding to the target element demand.

[0112] Regarding the apparatus in this embodiment, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0113] Some embodiments of this application establish ontology models for different elements, generate corresponding knowledge graphs based on the ontology models, and associate the different knowledge graphs to obtain an IVCPS requirement element knowledge base. Then, after obtaining the target element requirement, it matches it in the IVCPS requirement element knowledge base to obtain the corresponding entity nodes. Based on the entity nodes, a target requirement link is generated. Then, based on a trained large model, the target requirement link is parsed to obtain the target description language corresponding to the target requirement link. This yields the target requirement data corresponding to the target element requirement. Thus, based on the target element requirement of one of the stakeholders, combined with knowledge, logic, and systems from various fields, a systematic, scientific, and comprehensive set of stakeholder requirements, functional requirements at each level, performance requirements at each level, and design constraint requirements are generated semi-automatically and automatically. By integrating the constraints from multiple parties, a corresponding target description language is generated, achieving comprehensive coverage of regional elements, reducing and eliminating requirement omissions, and improving the efficiency of requirement analysis.

[0114] Another embodiment of this application further illustrates the IVCPS demand generation apparatus provided in the above embodiments.

[0115] Optionally, the requirement to obtain the target element includes: Obtain the target element requirements; The text data of the target element requirements is structured to obtain the processed target element requirements; The processed target requirements are semantically annotated to obtain searchable requirement text data.

[0116] Optionally, determining the entity node corresponding to the target element requirement based on a pre-established IVCPS requirement element knowledge base includes: Determine the first feature vector of the retrieveable demand text data; Calculate the similarity between the first feature vector and the second feature vector of the entity node in the IVCPS demand element knowledge base, respectively; If the similarity is greater than the similarity threshold, then the searchable demand text data and the entity node are determined to match; Based on the pre-established IVCPS demand element knowledge base, attribute information corresponding to the searchable demand text data is determined, wherein the pre-established IVCPS demand element knowledge base includes entities and attribute information corresponding to the entities. Some embodiments of this application begin with typical application scenarios, clarifying the scenario objectives and operational boundaries, and identifying key elements such as traffic participants, environmental conditions, system components, and stakeholders. Subsequently, by leveraging semantic retrieval and entity localization mechanisms, precise alignment of scenario elements and knowledge nodes is achieved in the demand knowledge graph, activating relevant entities and their attribute relationships, and providing a clear semantic starting point for demand reasoning.

[0117] Optionally, generating the target demand link corresponding to the entity node based on the entity node includes: Based on the pre-established demand association pattern, a general rule reasoning engine under the semantic web framework is adopted. Taking the entity type and semantic relationship defined in the demand ontology as the basic constraints, the entity node and the pre-established IVCPS demand element knowledge base are matched in the form of RDF triples to obtain the first demand link corresponding to the entity node. Based on the class hierarchy, attribute constraints and inheritance relationships defined in the requirement ontology, the implicit requirement relationship of the description logic is constructed, and based on the implicit requirement relationship of the description logic, the second requirement link corresponding to the entity node is generated. The demand relationship completion algorithm based on the graph convolutional network model (GCN) determines the probability corresponding to the entity node based on the knowledge graph, the embedding vector of the entity node, and the semantic relationship type, and determines the third demand link corresponding to the entity node based on the probability. Based on the first demand link, the second demand link, and the third demand link, determine the target demand link corresponding to the entity node.

[0118] Some embodiments of this application, based on the activated requirement knowledge subgraph, use various mechanisms such as rule-driven reasoning and graph structure reasoning to mine the requirement logic links across entities and levels, and deduce potential functional constraints, performance requirements and collaborative relationships. This process can not only characterize explicit requirements, but also reveal implicit requirement associations and system behavior constraints, thereby improving the systematicness and foresight of requirement analysis. Optionally, determining the target demand link corresponding to the entity node based on the first demand link, the second demand link, and the third demand link includes: The target demand link is determined from multiple demand links corresponding to the entity node by employing node importance calculation method, subgraph connectivity analysis method, and link importance aggregation method.

[0119] Optionally, the step of using a pre-trained large model to parse the target demand chain to obtain a target description language corresponding to the target demand chain, and determining the target description language as target demand data corresponding to the target element demand, includes: Based on a pre-established domain semantic constraint library, the demand chain corresponding to the entity node is transformed to obtain standardized expression data corresponding to the demand chain. The pre-established domain semantic constraint library includes terminology mapping rules, logical association rules, and description specification rules. The preset prompt words, the demand chain sequence in the standardized expression data, and the associated node attributes are input into the large model to obtain the target demand corresponding to the demand chain. The preset prompt words include at least top-level target type prompt words, scenario type prompt words, stakeholder type prompt words, entity type prompt words, functional service type prompt words, relationship type prompt words, and performance type prompt words.

[0120] Some embodiments of this application further extract and generate semantic information about requirements based on the results of requirement reasoning. They explore deep semantic relationships through multi-hop path search and Graph-RAG techniques. Combined with graph structure feature indicators and multi-objective optimization methods, they quantitatively evaluate and classify the importance of requirements.

[0121] Optionally, the IVCPS requirement element knowledge base is obtained in the following way: Based on standards, policy documents, technical white papers, research results, and typical application cases, the Stanford seven-step method and iterative method are used to generate the ontology model. An entity and relation extraction algorithm is used to extract entities and relations from the ontology model to obtain a knowledge graph corresponding to the ontology model. The graph embedding method is used to convert entity nodes in the knowledge graph corresponding to the ontology model into embedding vectors corresponding to the entity nodes. Hierarchical clustering algorithm, point similarity measurement method and community detection are used to calculate the association relationship between the knowledge graphs corresponding to two different ontology models; The IVCPS requirement element knowledge base is obtained based on multiple knowledge graphs and the relationships between them.

[0122] Some embodiments of this application perform unified modeling of demand element knowledge in structured, semi-structured, and unstructured forms to form a hybrid storage architecture that can be integrated. Secondly, based on knowledge engineering technology, a database supporting relational modeling and reasoning analysis is constructed to realize the large-scale management and engineered use of demand knowledge. Finally, combined with the demand engineering process, a retrieval and calling mechanism is designed so that demand knowledge can be systematically and traceably applied in the analysis, verification, and architecture design stages.

[0123] Optionally, the step of employing a graph embedding method to convert entity nodes in the knowledge graph corresponding to the ontology model into embedding vectors corresponding to the entity nodes includes: The BGE text vector model is used to generate embedding vectors of entity nodes in the knowledge graph corresponding to the ontology model. The BGE text vector model adopts a dual-tower structure based on Transformer Encoder. After text input is segmented and embedded, the contextual semantic relationship is modeled through a multi-layer self-attention mechanism.

[0124] Regarding the apparatus in this embodiment, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0125] It should be noted that each of the implementable methods in this embodiment can be implemented individually or in any combination without conflict. This application does not limit this.

[0126] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, can implement the operation of any of the methods corresponding to the IVCPS requirement generation methods provided in the above embodiments.

[0127] This application also provides a computer program product, which includes a computer program, wherein when the computer program is executed by a processor, it can implement the operation of any of the methods corresponding to the embodiments of the IVCPS requirement generation method provided above.

[0128] like Figure 9 As shown, some embodiments of this application provide an electronic device 900, which includes: a memory 910, a processor 920, and a computer program stored in the memory 910 and executable on the processor 920. When the processor 920 reads the program from the memory 910 via a bus 930 and executes the program, it can implement any of the methods included in the above-described IVCPS demand generation method.

[0129] Processor 920 can process digital signals and can include various computing architectures. For example, it can be a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements multiple instruction set combinations. In some examples, processor 920 can be a microprocessor.

[0130] The memory 910 can be used to store instructions executed by the processor 920 or data related to the execution of instructions. These instructions and / or data may include code for implementing some or all of the functions of one or more modules described in the embodiments of this application. The processor 920 of this disclosure embodiment can be used to execute the instructions in the memory 910 to implement the methods shown above. The memory 910 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memories well known to those skilled in the art.

[0131] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0132] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0133] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A requirement generation method for IVCPS, characterized in that, The method includes: Obtain the target element requirements; Based on the pre-established IVCPS requirement element knowledge base, the entity nodes corresponding to the target element requirements are determined. The IVCPS requirement element knowledge base is obtained by establishing ontology models of different elements, generating corresponding knowledge graphs based on the ontology models, and associating different knowledge graphs. Based on the entity node, generate the target requirement link corresponding to the entity node; A pre-trained large model is used to parse the target demand chain to obtain the target description language corresponding to the target demand chain, and the target description language is determined as the target demand data corresponding to the target element demand.

2. The IVCPS demand generation method according to claim 1, characterized in that, The requirements for acquiring the target elements include: Obtain the target element requirements; The text data of the target element requirements is structured to obtain the processed target element requirements; The processed target requirements are semantically annotated to obtain searchable requirement text data.

3. The IVCPS demand generation method according to claim 2, characterized in that, The step of determining the entity node corresponding to the target element requirement based on the pre-established IVCPS requirement element knowledge base includes: Determine the first feature vector of the retrieveable demand text data; Calculate the similarity between the first feature vector and the second feature vector of the entity node in the IVCPS demand element knowledge base, respectively; If the similarity is greater than the similarity threshold, then the searchable demand text data and the entity node are determined to match; Based on the pre-established IVCPS demand element knowledge base, attribute information corresponding to the searchable demand text data is determined, wherein the pre-established IVCPS demand element knowledge base includes entities and attribute information corresponding to the entities.

4. The IVCPS demand generation method according to claim 3, characterized in that, The step of generating the target demand link corresponding to the entity node based on the entity node includes: Based on the pre-established demand association pattern, a general rule reasoning engine under the semantic web framework is adopted. Taking the entity type and semantic relationship defined in the demand ontology as the basic constraints, the entity node and the pre-established IVCPS demand element knowledge base are matched in the form of RDF triples to obtain the first demand link corresponding to the entity node. Based on the class hierarchy, attribute constraints and inheritance relationships defined in the requirement ontology, the implicit requirement relationship of the description logic is constructed, and based on the implicit requirement relationship of the description logic, the second requirement link corresponding to the entity node is generated. The demand relationship completion algorithm based on the graph convolutional network model (GCN) determines the probability corresponding to the entity node based on the knowledge graph, the embedding vector of the entity node, and the semantic relationship type, and determines the third demand link corresponding to the entity node based on the probability. Based on the first demand link, the second demand link, and the third demand link, determine the target demand link corresponding to the entity node.

5. The IVCPS demand generation method according to claim 4, characterized in that, The step of determining the target demand link corresponding to the entity node based on the first demand link, the second demand link, and the third demand link includes: The target demand link is determined from multiple demand links corresponding to the entity node by employing node importance calculation method, subgraph connectivity analysis method, and link importance aggregation method.

6. The IVCPS demand generation method according to claim 5, characterized in that, The process involves using a pre-trained large model to parse the target demand chain, obtaining a target description language corresponding to the target demand chain, and defining the target description language as target demand data corresponding to the target element demand, including: Based on a pre-established domain semantic constraint library, the demand chain corresponding to the entity node is transformed to obtain standardized expression data corresponding to the demand chain. The pre-established domain semantic constraint library includes terminology mapping rules, logical association rules, and description specification rules. The preset prompt words, the demand chain sequence in the standardized expression data, and the associated node attributes are input into the large model to obtain the target demand corresponding to the demand chain. The preset prompt words include at least top-level target type prompt words, scenario type prompt words, stakeholder type prompt words, entity type prompt words, functional service type prompt words, relationship type prompt words, and performance type prompt words.

7. The IVCPS demand generation method according to claim 1, characterized in that, The IVCPS requirement element knowledge base was obtained through the following methods: Based on standards, policy documents, technical white papers, research results, and typical application cases, the Stanford seven-step method and iterative method are used to generate the ontology model. An entity and relation extraction algorithm is used to extract entities and relations from the ontology model to obtain a knowledge graph corresponding to the ontology model. The graph embedding method is used to convert entity nodes in the knowledge graph corresponding to the ontology model into embedding vectors corresponding to the entity nodes. Hierarchical clustering algorithm, point similarity measurement method and community detection are used to calculate the association relationship between the knowledge graphs corresponding to two different ontology models; The IVCPS requirement element knowledge base is obtained based on multiple knowledge graphs and the relationships between them.

8. The IVCPS demand generation method according to claim 7, characterized in that, The step of employing a graph embedding method to convert entity nodes in the knowledge graph corresponding to the ontology model into embedding vectors corresponding to the entity nodes includes: The BGE text vector model is used to generate embedding vectors of entity nodes in the knowledge graph corresponding to the ontology model. The BGE text vector model adopts a dual-tower structure based on Transformer Encoder. After text input is segmented and embedded, the contextual semantic relationship is modeled through a multi-layer self-attention mechanism.

9. A demand generation device for IVCPS, characterized in that, The device includes: The acquisition module is used to acquire the target element requirements; The determination module is used to determine the entity node corresponding to the target element requirement based on the pre-established IVCPS requirement element knowledge base. The IVCPS requirement element knowledge base is obtained by establishing ontology models of different elements, generating corresponding knowledge graphs based on the ontology models, and associating different knowledge graphs. The generation module is used to generate a target requirement link corresponding to the entity node based on the entity node; The parsing module is used to parse the target demand chain using a pre-trained large model, obtain the target description language corresponding to the target demand chain, and determine the target description language as the target demand data corresponding to the target element demand.

10. The IVCPS demand generation apparatus according to claim 9, characterized in that, The acquisition module is used for: Obtain the target element requirements; The text data of the target element requirements is structured to obtain the processed target element requirements; The processed target requirements are semantically annotated to obtain searchable requirement text data.

11. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it can implement the IVCPS demand generation method according to any one of claims 1-8.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, characterized in that, when the program is executed by a processor, it can implement the IVCPS demand generation method according to any one of claims 1-8.

Images