A requirement timing conflict detection method and system based on LLM and ontology reasoning

Abstract

The application discloses a demand timing conflict detection method and system based on LLM and ontology reasoning, and has the characteristics that the method comprises the following steps: constructing an upper ontology of embedded system timing related demand description, defining concepts, concept relations and constraint relations; designing concept extraction and relation extraction prompts based on the upper ontology, driving the LLM to perform ontology instance extraction on demand text; checking the extraction result based on constraints; and performing timing conflict analysis; and the system comprises an upper ontology construction module, an ontology instance extraction module and a timing conflict analysis module. Compared with the prior art, the application has the advantages of improving the automation degree, detection accuracy and analysis efficiency of demand verification, effectively processing implicit timing relations caused by multi-element coupling, reducing the cost of artificial formal modeling, realizing automatic detection of complex system demand timing conflicts, improving logical reliability, result traceability and analysis interpretability, and providing technical support for complex embedded system demand engineering.

Description

Technical Field

[0001] This invention relates to the field of requirements engineering technology for safety-critical embedded software, specifically a requirement timing conflict detection method and system based on LLM (Large Language Model) and ontology reasoning. Background Technology

[0002] In complex embedded systems such as aerospace, autonomous driving, rail transportation, and smart homes, requirements often involve multiple elements simultaneously, including various types of devices, operating modes, sensor data, control commands, and time constraints. These different elements can form complex couplings through data generation and consumption, device state changes, mode switching conditions, time-waiting relationships, and preconditions, resulting in an intertwined relationship between the execution sequence, triggering conditions, and state dependencies of requirements. If these temporal relationships implied by multi-element coupling are not identified and verified during the requirements phase, subsequent design and implementation are prone to problems such as unclear execution order, inconsistent state switching, mutual waiting of control actions, and conflicting behavioral constraints in different modes, thereby affecting the reliability and security of system operation. Because natural language requirements descriptions typically disperse information such as events, time points, durations, device states, operating modes, data dependencies, and preconditions across different statements or even different requirement items, relying solely on manual review or unconstrained text understanding methods is insufficient to promptly identify deep temporal conflicts caused by multi-element coupling.

[0003] Existing technologies primarily focus on the formal transformation and automated verification of requirements. They mainly employ temporal logic-based schema systems, such as SPS and SUP, to transform natural language requirements into temporal logic, such as LTL, TCTL, or Clock Constraint Specification Language (CCSL), and then use model checking tools or SMT solvers for consistency checks. For example, requirements are transformed into CCSL constraints, and SMT tools are used to verify their schedulability and temporal consistency, detecting logical contradictions and time constraint conflicts between requirements. Alternatively, structured English requirements are transformed into temporal event automata models to detect real-time inconsistencies. Furthermore, some technologies lower the formalization threshold while detecting temporal conflicts by defining domain-specific languages, such as SafeNL and Temporal Action Language, or by introducing partial consistency concepts. However, existing technologies still have significant limitations in handling temporal conflicts caused by the coupling of multiple factors such as multiple devices, multiple states, multiple schemas, data dependencies, and time constraints. First, most formal methods require converting natural language requirements into rigorous formal expressions beforehand. However, this conversion process typically relies heavily on deep collaboration between formal method experts and domain experts, resulting in high modeling costs and long cycles, making it difficult to scale up in industrial practice. Second, existing methods are generally better suited for handling explicitly given time constraints or logical relationships. They lack a unified semantic modeling mechanism for implicit relationships such as device state changes, data flow dependencies, mode switching conditions, and preconditions described in scattered natural language requirements, making it difficult to automatically discover indirect temporal conflicts formed by the interaction of multiple factors. Third, existing formal verification methods often focus on single-dimensional time constraints or state transition consistency, lacking sufficient ability to deduce combinations of data dependencies, state dependencies, mode dependencies, and time dependencies. This makes it difficult to cover the multi-factor coupling scenarios that truly exist in complex embedded systems.

[0004] In recent years, the application of LLM in requirements engineering has demonstrated its potential to extract requirement concepts from unstructured text, identify conceptual relationships, and even detect defects in requirement texts. However, relying solely on LLM for end-to-end analysis still suffers from problems such as unstable output, unverifiable reasoning processes, insufficient traceability of results, and illusions. Especially in safety-critical systems, without explicit semantic constraints and formal reasoning mechanisms, LLM struggles to reliably identify deep temporal conflicts arising from the combined effects of data, states, patterns, and time constraints, leading to risks of false positives, false negatives, or the generation of unreliable interpretations.

[0005] In summary, existing technologies mainly suffer from two types of problems: one relies on manual formal modeling, which is costly, has low automation, and struggles to fully handle the implicit temporal relationships arising from the coupling of multiple elements in natural language requirements; the other relies on pure LLM end-to-end analysis, which, while possessing natural language understanding capabilities, lacks strict semantic constraints, logical reasoning capabilities, and traceability guarantees. There is a lack of a technological bridge between these two approaches that can automatically map the various concepts, conceptual relationships, and temporal constraints in natural language requirements into reasonable knowledge representations, and further support temporal relationship derivation and conflict detection. Therefore, there is an urgent need for an automatic temporal conflict detection method and system for the natural language requirements of complex embedded systems. Summary of the Invention

[0006] The purpose of this invention is to address the shortcomings of existing technologies by designing a requirement timing conflict detection method and system based on LLM and ontology reasoning. This method employs a method of constructing a unified upper-level ontology for timing requirement descriptions to achieve effective mapping between natural language requirements and formal knowledge representations. LLM is used to automatically extract multiple types of elements and relationships from complex requirement texts, and ontology reasoning is combined to derive and verify the consistency of requirement timing relationships, thereby achieving automatic detection of timing conflicts in complex systems. This method pre-constructs an embedded upper-level ontology for timing-related requirement descriptions, providing a unified semantic framework for timing-related concepts and conceptual relationships such as requirements, devices, system modes, data, device states, control signals, and time constraints. Constraints are defined within this upper-level ontology. LLM, guided by concept extraction prompts and relation extraction prompts, extracts ontology instances from natural language requirement texts. This effectively handles implicit timing relationships caused by the coupling of multiple elements such as devices, states, modes, data, control commands, and time constraints, reducing the cost of manual formal modeling and improving the automation, logical reliability, result traceability, and analytical interpretability of timing conflict detection. This invention effectively solves the problems in existing complex requirement timing conflict detection processes, such as the difficulty in identifying, deriving, and verifying implicit timing relationships caused by the coupling of multiple requirement elements, including equipment status, operating mode, sensor data, control commands, and time constraints; the high cost of manual formal modeling; and the lack of reliable constraints and the tendency to produce illusions in the direct analysis results of large language models. It is particularly suitable for automatic timing conflict detection for natural language requirements of complex embedded systems and has good application prospects.

[0007] The objective of this invention is achieved as follows: a method for detecting demand timing conflicts based on LLM and ontology reasoning, characterized by the following steps:

[0008] Step 1: Construct the upper-layer ontology of the embedded system's timing-related requirements description.

[0009] A method combining manually predefined ontology structures with Protege explicit modeling is used to construct a high-level ontology describing the temporal requirements of embedded systems. This high-level ontology uniformly defines concepts, conceptual relationships, and constraints for describing temporal requirements. The defined high-level ontology is stored in a knowledge base, providing a unified and extensible semantic framework for subsequent LLM ontology instance extraction and ontology reasoning. The concepts include: system pattern classes, device state classes, time constraint classes, requirement classes, data classes, and control signal classes. The relationships are defined based on the constructed concept class hierarchy, defining the relationships between concepts. The constraints are a system of constraints that concepts and relationships must satisfy, including constraint rules that provide validation criteria for LLM extraction results, and SWRL rules that guide the inference engine in reasoning about the temporal relationships of requirements.

[0010] Step 2: Extracting instances of the embedded system timing-related requirements ontology based on LLM.

[0011] Based on the upper-level ontology design concept extraction prompts and relation extraction prompts, the LLM is driven to perform concept extraction, concept relation extraction, and constraint checks on the natural language requirement text. If the check passes, the extraction result is mapped to a specific instance that conforms to the upper-level ontology type specification and constraint requirements, and stored in the knowledge base. If the check fails, the system automatically generates structured error feedback, concatenates the feedback with the original requirement text fragment, and re-inputs it to the LLM to guide the LLM to correct the extraction result until the check passes. The error feedback includes the error type, error location, expected compliance description, and correction guidance.

[0012] Step 3: Temporal Conflict Analysis Based on Ontology Reasoning

[0013] Based on specific instances in the knowledge base and SWRL rules in the constraint definitions, an inference engine is used to infer and detect conflicts in the temporal relationships of requirements. First, the inference engine derives the explicit or implicit temporal relationships between requirements; then, it performs consistency checks on the derived temporal relationships. If inconsistencies are detected in the temporal relationships due to violations of constraints such as antisymmetry or reflexivity, a temporal conflict is determined to exist; finally, based on the temporal conflict detection results, the relevant inconsistent requirement sets are located, conflict evidence is extracted, and a temporal conflict detection report is generated.

[0014] The upper-level ontology construction in step 1 specifically includes:

[0015] 1) The concepts include at least: system mode class, equipment status class, time constraint class, requirement class, data class, and control signal class. Among them, the time constraint class includes: post-constraint, time constraint, and duration constraint, which are used in this invention to express the time when a requirement is triggered or the time interval between requirements, rather than the duration of the requirement itself;

[0016] 2) Conceptual relationships are defined based on the type of concepts, and are used to describe the semantic relationships between requirements and equipment status, system mode, data, control signals and time constraints.

[0017] 3) Constraint relationships are a system of constraints that concept classes and associations must satisfy. This includes constraint rules that provide validation criteria for LLM extraction results, and SWRL rules that guide the inference engine in reasoning about the temporal relationships of requirements. Constraint rules check whether the extraction results meet the constraints required for object integrity, relationship validity, and subsequent temporal reasoning. SWRL rules describe how to deduce the temporal order of requirements based on data dependencies, device state dependencies, time constraint dependencies, and system pattern dependencies in specific instances, providing a rule-based foundation for the inference engine to perform temporal relationship derivation and conflict detection.

[0018] The extraction of LLM ontology instances guided by the upper-layer ontology in step 2 specifically includes:

[0019] 1) Concept Extraction: Based on the concept types defined in the upper-level ontology, design concept extraction prompts to guide the large language model to identify and extract text objects corresponding to each concept type from the requirements document;

[0020] 2) Conceptual Relationship Extraction: Based on the conceptual relationships defined in the upper-level ontology, relation extraction prompts are designed to guide the large language model to identify the relationships between the text objects and form structured extraction results;

[0021] 3) Constraint Relationship Check: Semantic alignment and constraint checks are performed on the structured extraction results. Semantic alignment is used to merge synonymous or near-synonymous concept objects to eliminate naming inconsistencies and semantic ambiguities. Constraint checks are based on the constraint rules in the upper-level ontology constraint definition to check whether the concept objects and their relationships meet the constraint requirements for object integrity, relationship legality, and subsequent temporal reasoning. If the check fails, the system automatically generates structured feedback containing error location and correction suggestions, guiding the large language model to re-execute concept extraction and concept relationship extraction based on the feedback until the check passes.

[0022] 4) Specific instance generation: The checked concept objects and their associated mappings are converted into specific instances that conform to the upper-level ontology type specifications and constraints, and stored in the knowledge base to support the subsequent inference engine in deriving the demand sequence relationship and detecting the sequence conflict.

[0023] The temporal conflict analysis based on ontology reasoning in step 3 specifically includes:

[0024] 1) Requirement timing conflict detection: Based on specific instances in the knowledge base and SWRL rules in the constraint definition, the inference engine automatically derives the timing relationship between requirements and performs consistency detection on the derived timing relationship. When antisymmetry or reflexivity of requirements due to violation of timing relationship is detected, a timing conflict is determined to exist.

[0025] 2) Conflict evidence extraction: Based on the temporal conflict detection results, the relevant inconsistent requirement set is located. The system automatically backtracks and extracts the original requirement text, structured extraction results and reasoning basis corresponding to the relevant requirement set as conflict evidence.

[0026] 3) Conflict report generation: Based on conflict evidence, conflict report generation prompts are automatically constructed to guide the LLM in generating a time-series conflict detection report. The time-series conflict detection report includes: conflict summary, involved requirements, conflict causes, and modification suggestions.

[0027] An automatic detection system for complex requirements and temporal conflicts based on LLM and ontology reasoning is characterized by the system comprising: an upper-level ontology construction module, an ontology instance extraction module, and a temporal conflict analysis module.

[0028] The upper-layer ontology construction module is used to construct the upper-layer ontology describing the timing-related requirements of the embedded system, and to complete the definition of concepts, the definition of conceptual relationships and the definition of constraint relationships. The defined upper-layer ontology is then stored in the knowledge base, providing a unified and scalable semantic framework for subsequent LLM ontology instance extraction and ontology reasoning.

[0029] The ontology instance extraction module extracts ontology instances for embedded system timing-related requirements descriptions based on LLM. It also guides the large language model to extract concepts and concepts and relationships from the requirement text based on upper-level ontology design concept extraction prompts and relationship extraction prompts. The extraction results are checked according to the constraint rules defined by the upper-level ontology constraint relationships. If the check passes, the extraction results are mapped to specific instances that conform to the upper-level ontology constraints and stored in the knowledge base. If the check fails, structured feedback information is generated to guide the large language model to re-execute the extraction until the check passes.

[0030] The temporal conflict analysis module is based on ontology reasoning. It uses an inference engine to deduce the temporal sequence relationship between requirements by combining specific instances in the knowledge base and SWRL rules in the constraint relationship definition, and performs consistency detection on the derived temporal relationship. When an inconsistent relationship that violates the temporal relationship constraint is detected, it is determined that there is a temporal conflict. The module further locates the relevant inconsistent requirement set and extracts conflict evidence, and finally generates a temporal conflict detection report.

[0031] Compared with the prior art, the present invention has the following beneficial technical effects and significant technical progress:

[0032] 1) By pre-constructing an upper-level ontology describing the timing-related requirements of embedded systems, a unified semantic framework is provided for various timing-related concepts and conceptual relationships, such as requirements, devices, system modes, data, device states, control signals, and time constraints. This framework can effectively characterize the implicit timing relationships generated by the coupling of multiple types of requirement information in complex requirements, and solve the problem that existing methods lack structured semantic constraints and are therefore difficult to perform reliable timing conflict detection.

[0033] 2) By combining concept extraction, concept relation extraction and constraint checking and error feedback correction mechanisms guided by concept extraction prompts and relation extraction prompts in the large language model, the impact of semantic ambiguity of natural language requirements on the extraction results can be reduced, and the illusion problem of LLM when facing safety-critical time-series requirements can be effectively suppressed, ensuring the reliability of the extraction results in terms of type compliance, relation legality and semantic consistency.

[0034] 3) Utilizing the inference engine to perform formal logical reasoning based on specific instances in the knowledge base and SWRL rules, it automatically derives the temporal relationships between requirements and detects temporal conflicts. This transforms the traditional conflict detection process, which relies on manual review or pure LLM inference, into an ontology reasoning process with rule-based basis, significantly improving the automation and logical rigor of the detection.

[0035] 4) Based on the timing conflict detection results, the relevant inconsistency requirement set is determined, and the corresponding original requirement text, structured extraction results, and inferred timing relationships are automatically extracted as conflict evidence. Based on the conflict evidence, a report is automatically constructed to generate prompt words, driving the LLM to generate a highly readable timing conflict detection report. A complete traceability link from the original requirement text to the source of the timing conflict is established, realizing the interpretability and auditability of timing conflict detection. This provides high-quality, automated, and reusable technical support for requirement verification, security authentication, and subsequent change impact analysis of complex embedded systems. Attached Figure Description

[0036] Figure 1 This is an overall framework diagram of the method of the present invention;

[0037] Figure 2 This is a schematic diagram of the upper-layer ontology structure describing the timing-related requirements of the embedded system based on the architecture of this invention.

[0038] Figure 3 This is a schematic diagram illustrating the timing derivation from the dimensions of data, device status, time constraints, and system mode. Detailed Implementation

[0039] See Figure 1An automatic detection method for complex requirement timing conflicts based on LLM and ontology reasoning mainly includes three steps: First, constructing an upper-level ontology describing the timing-related requirements of an embedded system; second, extracting instances of the embedded system's timing-related requirement description ontology based on LLM; and third, analyzing timing conflicts based on ontology reasoning. Specifically, the upper-level ontology constructed in the first step and the concrete instances generated in the second step are jointly stored in a knowledge base. The second step is supported by LLM to complete concept extraction, concept relationship extraction, and constraint checking. The third step uses an inference engine to derive requirement timing relationships and detect conflicts based on the concrete instances in the knowledge base and the SWRL rules in the constraint definitions.

[0040] Step 1: Construct the upper-layer ontology of timing-related requirements description for the embedded system.

[0041] This step aims to pre-build a unified and scalable semantic framework, providing a formal conceptual foundation and constraint rules for subsequent LLM-based ontology instance extraction and inference engine-based temporal conflict detection.

[0042] See Figure 2 The upper-level ontology mainly includes three parts: concept definition, concept relationship definition, and constraint definition.

[0043] 1) Concept Definition

[0044] In terms of concept definition, the core concept classes defined in this method include: Requirement, Mode, Device, Device State, Transition, TranCondition, Data, Signal, Value, and TimeConstraints. Specifically, Requirement represents the functional requirement instances identified from natural language requirement documents and is the basic object for temporal relationship derivation and conflict detection; Mode represents the operating mode or control mode of the system under specific operating conditions; Device represents the sensors, actuators, timers, data management computers, or other hardware and software components involved in the execution of the requirement; Device State represents the possible states of the device before, after, or during the execution of the requirement; Device State Transition represents the transition relationship between different states of the same device; TranCondition represents the triggering conditions upon which the system switches from one mode to another; and Data represents the information objects read, generated, transmitted, or judged during the execution of the requirement, further including Signal and Value. Signals are used to characterize instruction-type data that can trigger device control actions or changes in device state, while values ​​are used to characterize ordinary data that participates in calculation, judgment, or transmission.

[0045] The time constraints are used to characterize the time-limited relationships between demand events, and further include waiting constraints (AfterConstraint), specified occurrence time constraints (AtConstraint), and time-slice rotation constraints (DurationConstraint). Specifically, the waiting constraint characterizes that a demand event occurs after a predetermined waiting time following another demand event; the specified occurrence time constraint characterizes that a demand event occurs at a specified time; and the time-slice rotation constraint characterizes that a demand event occurs within a specified time interval, periodic window, or time slice.

[0046] This invention assumes that the core events involved in each requirement are instantaneous events, and the time constraints involved are mainly used to express the moment when the requirement is triggered or the time interval between requirements, rather than to describe the complete execution time of a single requirement event itself.

[0047] 2) Definition of conceptual relationships

[0048] In terms of defining conceptual relationships, this method constructs object attributes around the semantic connections between requirements, data, equipment status, time constraints, and system patterns. First, taking requirements as the core object of time-series analysis, it defines the temporal sequence relationship Has_order (having order) between requirements, indicating that an event corresponding to one requirement should occur before an event corresponding to another requirement. Simultaneously, it defines data dependency relationships DataDepends and control dependency relationships ControlDepends between requirements, respectively representing the dependencies formed between requirements due to data transmission or control state constraints. Second, to describe the input-output relationship between requirements and data, it defines Produces (producing) to represent that a requirement produces certain data, and ConsumedBy (consuming) to represent that certain data is consumed or used by a requirement, thus providing a foundation for deriving data dependency relationships.

[0049] Furthermore, to describe the impact of demands on device states and the constraints of device states on demand execution, we define `Sets` to represent a signal or control command that can set a device state, `ChangesTo` to represent a change to a device state after demand execution, and `Is_precondition` to represent a device state that is a prerequisite for demand execution. Simultaneously, we define `Has_state` to represent the set of states a device can have, and `Has_tran` to associate the device with its state transitions. `Has_from` and `Has_to` represent the source and target states of the state transition, respectively. Through these relationships, we can describe the control dependency chain where "a demand output signal changes the device state, and this device state is a prerequisite for another demand."

[0050] For time constraints, this method defines `Has_timeCons` (possessing time constraints) to represent the relationship between a requirement and its time constraints. For waiting constraints, `Has_front` (depending on prerequisites) represents the prerequisite requirement that the waiting constraint depends on. For time-slice rotation constraints, `Has_start` (specifying start) represents its starting time constraint or the corresponding specified occurrence time constraint. Through these relationships, the time semantics described in the requirement text, such as "after a certain requirement," "after waiting for several cycles," and "execute at a specified time or within a time slice," can be transformed into inferable ontology relationships.

[0051] For system modes, this method defines `Has_tranCond` (meeting the transition condition) to represent the association between the mode and the mode transition condition, `SwitchTo` (switching to) to represent switching from the current mode to the target mode when the transition condition is met, and `Call` (calling execution) to represent the set of requirements called or executed under a certain mode. Through the association between modes, mode transition conditions, and requirements, the execution scope of requirements under different operating modes and the timing dependencies introduced by mode switching can be described.

[0052] To facilitate distinction and description, the original English names of each relationship will be used consistently in the main text below, while... Figure 2 and Figure 3 The corresponding Chinese name should be used.

[0053] Based on the above relationships, this method forms a semantic modeling path from natural language requirements to specific instances: first, it establishes explicit relationships between requirements and data, equipment status, time constraints, and modes, with requirements as the center; then, it uses intermediate relationships such as data dependency, control dependency, time constraints, and mode switching to deduce the Has_order temporal sequence relationship between requirements, thereby providing a formal basis for subsequent temporal relationship derivation and consistency detection.

[0054] 3) Constraint Definition

[0055] Regarding constraint definition, this method defines a constraint system that the above-mentioned concept classes and relationships must satisfy. This includes constraint rules that provide verification criteria for LLM extraction results, and SWRL rules that guide the inference engine to reason about the temporal relationships of the requirements.

[0056] The constraint definition specifically includes:

[0057] 3.1) Constraint Rules

[0058] Constraint rules are used to ensure that the LLM extraction results can be correctly mapped to specific instances that conform to the upper-level ontology type specifications and constraint requirements, and can enter the subsequent reasoning process. The constraint rules include object integrity constraints, relation validity constraints, and temporal reasoning constraints.

[0059] The object integrity constraints are used to ensure the integrity of basic information for specific instances. For example, each device should be associated with at least one set of device states; each device state transition should include a source state and a target state; each requirement should have an identifiable requirement name and its corresponding original requirement text; each mode transition condition should be associated with a target mode; and each time constraint should have a time parameter or associated object that matches its type.

[0060] The relation validity constraints are used to ensure that the extracted relations conform to the domain and value range defined by the upper-level ontology. For example, the subject of Produces should be demand and the object should be data; the subject of ConsumedBy should be data and the object should be demand; the subject of Sets should be signal and the object should be device state; the subject of Is_precondition should be device state and the object should be demand; the subject of Has_state should be device and the object should be device state; the subject of Has_from and Has_to should be device state transition and the object should be device state; the subject of Has_timeCons should be demand and the object should be time constraint.

[0061] The temporal reasoning constraints are used to ensure that the temporal relationships between requirements can be deduced from specific instances. For example, when a waiting constraint is associated with a requirement, the waiting constraint should point to its preceding requirement through Has_front; when a time-slice rotation constraint needs to specify a start condition, the time-slice rotation constraint should be associated with a specified occurrence time constraint through Has_start; when a mode has a switching condition, the mode should be associated with a mode switching condition through Has_tranCond, and the switching condition should point to the target mode through SwitchTo; when a requirement output signal is used to set the device state, and the device state is a preceding condition for another requirement, the relationship chain should be able to support the deduction of control dependencies and temporal sequences.

[0062] Through the above constraint rules, this method can automatically verify the LLM extraction results: when the extraction results lack necessary objects, the relation type does not conform to the ontology definition, or the relation chain cannot support subsequent temporal reasoning, the system generates structured feedback information to guide the LLM to re-execute concept extraction or concept relation extraction; when the extraction results meet the above constraint rules, the system maps the extraction results to specific instances that conform to the upper-level ontology type specifications and constraint requirements, and stores them in the knowledge base for subsequent inference engine execution of temporal relation derivation and conflict detection.

[0063] 3.2) SWRL Rules

[0064] SWRL rules are the inference rules part of the constraint definition, used to guide the inference engine to deduce the temporal sequence relationships between requirements from specific instances in the knowledge base. When implementing the logical rules in Protege, all variables must be prefixed with a question mark to identify them and drive inference decisions.

[0065] See Figure 3 The SWRL rules mainly include the following four dimensions:

[0066] 1) Data Dimensions

[0067] The data dimension focuses on the dependencies between demands formed through data generation and consumption. Its derivation process includes two stages: First, based on R1, it is determined whether the data generated by a certain demand is consumed by another demand. If so, it is deduced that the latter demand has a data dependency on the former demand. Then, based on R2, this data dependency is further transformed into a temporal sequence relationship between demands, that is, the data production demand that is depended on should be executed before the data consumption demand.

[0068] R1 is a data dependency derivation rule. If data generated by one requirement is consumed by another requirement, it indicates that the data source of the latter requirement depends on the execution result of the former requirement. Therefore, a data dependency relationship exists between the two, as expressed by the following formula:

[0069]

[0070] in, This indicates that there is a requirement. , This indicates that there is a data. , Indicate demand Data was produced , Representing data Demand Consumption, Indicate demand Data depends on demand , It is the conjunction symbol in mathematics, meaning "and", that is, the whole expression is true only when both propositions on the left and right are true.

[0071] R2 is the rule for converting data dependency to time-series relationship, if required Data depends on demand Then demand Prioritize demand Execution, therefore, leads to the deduction that there is a temporal sequence relationship between the two, which can be expressed by the following formula:

[0072]

[0073] in, This indicates that there is a requirement. , Indicate demand Data depends on demand , This indicates a need in terms of timing. Prior to demand .

[0074] 2) Device Status Dimension

[0075] The device state dimension focuses on the control dependencies formed by requirements changing device state or relying on device state as a prerequisite. Its derivation process includes three levels: First, based on R3, it determines whether a requirement sets the device state through an output signal, thus deducing that the requirement will change the device state; second, based on R4, it determines whether the device state is a prerequisite for another requirement. If so, it deduces that a control dependency exists between the two requirements; then, based on R5, it transforms the control dependency into a temporal sequence relationship. Furthermore, R6 is used to handle the implicit temporal order of consecutive state transitions of the same device, i.e., the requirement for a previous state transition should be executed before the requirement for a subsequent state transition.

[0076] R3 is the device state change derivation rule. If a signal generated by a certain demand can set a certain device state, it means that executing the demand will cause the device to enter the corresponding state. Therefore, it is deduced that the demand will change the device state, and this is expressed by the following formula:

[0077]

[0078] in, This indicates that there is a requirement. , This indicates the existence of a signal. , Indicate demand A signal was generated , This indicates the existence of a specific device's device status. , This indicates the existence of a specific device. , Indicates device Equipment status , Indicates signal Able to change device status Because of the device status and equipment Binding, so a more complete representation here is a signal. Able to put the device The device status changed Please refer to the explanation above. The complete representation of demand Able to put the device The device status changed .

[0079] R4 is the control dependency derivation rule. If a certain device state is a requirement... The prerequisite is that the device status is determined by the requirement. Change leads to demand. Execution depends on demand The settings for the device state indicate a control dependency between them, which can be expressed as follows:

[0080]

[0081] in, This indicates the existence of a specific device. , This indicates the existence of a specific device's device status. , Indicates device There is a device status , This indicates that there is a requirement. Because of the device status and equipment Binding, therefore A more complete explanation is equipment. The device status is It is a demand Prerequisites Indicate demand Able to put the device The device status changed , Indicate demand Control depends on demand .

[0082] R5 is the rule for converting control dependencies to time-series relationships, if the requirement is... Control depends on demand Then demand Prioritize demand Execution, therefore, leads to the deduction that there is a temporal sequence relationship between the two, which can be expressed by the following formula:

[0083]

[0084] in, This indicates that there is a requirement. , Indicate demand Control depends on demand , This indicates a need in terms of timing. Prior to demand .

[0085] R6 is the device state transition timing relationship rule, if required Make a device change state Migration to state And demand This also causes the same device to change state. Migration to state Then demand Prioritize demand Execution, and is expressed by the following formula:

[0086]

[0087] in, This indicates that there is a requirement. And a demand , This indicates the existence of a specific device. , This indicates the existence of a specific device's device status. , Indicates device Equipment status Because of the equipment and device status , and Binding, A more complete explanation is demand. Able to put the device The state becomes , Indicates device There is a specific device state transition For device state migration, Indicates device state transition From device status Start, to device status End. The state transition for the remaining devices is similar. This indicates a need in terms of timing. Prior to demand .

[0088] 3) Time Constraint Dimension

[0089] The time constraint dimension focuses on the time-limited relationships explicitly described in the requirements document, including: specified occurrence time constraints, waiting constraints, and time-slice rotation constraints. Unlike the data and device status dimensions, the time constraint dimension typically allows direct derivation of the temporal relationships between requirements based on their chronological order. Specifically, R7 derives the temporal order based on the chronological relationship between two specified occurrence times; R8 derives the temporal order based on waiting constraints and their preceding requirements; R9 derives the temporal order based on the chronological relationship between time-slice rotation constraints and specified occurrence times; and R10 derives the temporal order based on the chronological relationship between the start times of two time-slice rotation constraints.

[0090] R7 is a derivation rule for specified occurrence time constraints. If two requirements each have specified occurrence time constraints, and the requirements... The specified occurrence time is earlier than the demand. If the specified occurrence time is specified, then the requirement is... Prioritize demand Execution, and is expressed by the following formula:

[0091]

[0092] in, This indicates that there is a demand. , This indicates that a constraint exists that occurs at a specified time. . Indicate demand A constraint occurs at a specified time. Similarly, it can be seen that demand A constraint occurs at a specified time. , express Less than , This indicates a need in terms of timing. Prior to demand .

[0093] R8 is the waiting constraint derivation rule, if the requirement It has a waiting constraint, and this waiting constraint is a prerequisite requirement. Using this as a benchmark, the requirements are explained. Should be in demand This happened subsequently, therefore the demand is derived. Prior to demand And it can be expressed by the following formula:

[0094]

[0095] in, This indicates that there is a demand. , This indicates the existence of a wait constraint. . Indicate demand There is a wait constraint , Indicates a wait constraint In demand after, This indicates a need in terms of timing. Prior to demand .

[0096] R9 is the derivation rule for time slice rotation constraints and specified occurrence time constraints. If required... It has a time-slice rotation constraint, and its start time is earlier than the requirement. If the specified occurrence time is specified, then the requirement is... Prioritize demand Execution, and is expressed by the following formula:

[0097]

[0098] in, This indicates that there is a demand. , This indicates the existence of a time-slice rotation constraint. . Indicate demand There is a time slice rotation constraint , This indicates that a constraint occurs at a specified time. , Indicates time slice rotation constraint Constraints begin to occur at a specified time. The time indicated; This indicates that a constraint occurs at a specified time. , Indicate demand A constraint occurs at a specified time. , express Less than , This indicates a need in terms of timing. Prior to demand .

[0099] R10 is the timing derivation rule between two time-slice rotation constraints. If both requirements have time-slice rotation constraints, and the requirements... The start time is earlier than the demand. The start time, then the demand Prioritize demand Execution, and is expressed by the following formula:

[0100]

[0101] in, This indicates that there is a demand. , This indicates the existence of a time-slice rotation constraint. , Indicate demand There is a time slice rotation constraint , This indicates that a constraint occurs at a specified time. , Indicates time slice rotation constraint Constraints begin to occur at a specified time. The time indicated; similarly, the demand can be derived. There is a time slice rotation constraint It begins when a constraint occurs at a specified time. ; express Less than , This indicates a need in terms of timing. Prior to demand .

[0102] 4) System Pattern Dimension

[0103] The system mode dimension focuses on the calling relationships of requirement sets under different operating modes and the switching order between modes. Its derivation logic is as follows: if one mode calls a requirement, another mode calls another requirement, and the system can switch from the former mode to the latter, then the requirement called in the former mode should be executed before the requirement called in the latter mode. This dimension uses R11 to transform the mode switching relationship into a temporal sequence relationship between requirements.

[0104] R11 is the mode switching to timing relationship rule, if mode Calling requirements ,model Calling requirements And the system can be configured by mode Switch to mode , then the pattern The following needs It should precede the pattern The following needs Execution, and is expressed by the following formula:

[0105]

[0106] in, This indicates the existence of a system schema. , This indicates that there is a requirement. , Indicates that the system is in The mode will call the requirement Similarly, it can be seen that the system is in mode Next call requirement , Indicate system mode There is a mode switching condition , Indicates mode switching conditions The target switching mode is That is, there exists a mode switch from Mode switch model, Indicate demand and demand They are different needs. In terms of time sequence Prior to .

[0107] Step 2: Extracting instances of the embedded system timing-related requirements ontology based on LLM.

[0108] This step leverages the upper-level ontology to support LLM in performing concept extraction and concept relation extraction from unstructured natural language requirements documents, and maps the extracted results that pass the checks to concrete instances that conform to the upper-level ontology type specifications and constraints. This step includes: concept extraction, concept relation extraction, constraint checking, and concrete instance generation.

[0109] The concept extraction is based on the concept types defined in the upper-level ontology. Concept extraction prompts are designed, including: a task description, extraction guidelines, and output format requirements. The task description instructs the LLM to identify text objects corresponding to the concept types in the upper-level ontology from the given requirement text. The extraction guidelines guide the LLM to identify concepts categorized by type, such as requirement, device, mode, data, signal, device status, device status transition, mode transition conditions, and time constraints. The output format requirements constrain the LLM to return the extraction results in a structured format such as JSON. Using these structured prompts, the LLM identifies text objects corresponding to each concept type from the requirement document, such as the functional requirement name, original requirement text, involved devices, operating modes, input data, output data, control signals, device status, and time constraints.

[0110] The concept relationship extraction is based on the concept relationships defined in the upper-level ontology. Relationship extraction prompts are designed to guide the LLM in identifying the associations between different concept objects. For example, it identifies the "Produces" relationship where a requirement generates a certain data, the "ConsumedBy" relationship where a certain data is consumed by a certain requirement, the "sets" relationship where a certain signal sets a certain device state, the "Is_precondition" relationship where a certain device state is a precondition for a certain requirement, the "Has_timeCons" relationship where a requirement is associated with a certain time constraint, and relationships related to mode call requirements or mode switching. After concept extraction and concept relationship extraction, the system forms a structured extraction result including: concept objects, concept types, associations between concepts, and their correspondence with the original requirement text. The relationship extraction prompts include: task description, conflicting requirement text, structured extraction result, inferred temporal relationships, conflict determination criteria, and output format requirements.

[0111] The constraint check performs semantic alignment and constraint checks sequentially on the structured extraction results. The semantic alignment is used to merge synonymous or near-synonymous concept objects to eliminate naming inconsistencies and semantic ambiguities. For example, a semantic similarity model and a domain thesaurus can be used to merge "collecting temperature data" and "temperature data collection" into the same requirement object, and "door and window open status" and "OPEN status" can be aligned into the same device status object.

[0112] The constraint check is performed based on the constraint rules defined in the first step. It checks whether the extraction results meet the constraints required for object integrity, relational validity, and subsequent temporal reasoning. For example, it checks whether each time constraint is correctly associated with a requirement; whether waiting constraints point to their preceding requirements via Has_front; whether the subjects and objects of relations such as Produces, ConsumerBy, sets, and Is_precondition conform to the domain and value range defined by the upper-level ontology; whether the schema transformation condition is associated with the target schema; and whether the relation chains used to derive data dependencies, control dependencies, temporal dependencies, and schema dependencies are complete. If the constraint check fails, the system automatically generates structured feedback information containing error location and correction suggestions. The system concatenates this feedback information with the original requirement text fragment and re-inputs it to the LLM, guiding the LLM to re-execute concept extraction and concept relation extraction until the check passes. The structured feedback information includes: error type, error location, violated constraint rule, expected compliance description, and correction guidance.

[0113] The specific instance generation process involves mapping the checked concept objects and their relationships to concrete instances that conform to the upper-level ontology type specifications and constraint requirements after the structured extraction results pass semantic alignment and constraint checks. These concrete instances can be represented using OWL and stored in a knowledge base, providing directly processable input for subsequent inference engines. Through this processing, the concept objects, concept relationships, and temporal constraints in the natural language requirement text are transformed into formal knowledge representations that can be processed by the inference engine, thereby supporting subsequent requirement temporal relationship derivation and temporal conflict detection.

[0114] The third step is time-series conflict detection based on inference engines.

[0115] This step utilizes a reasoning component that supports OWL ontology and SWRL rules to perform logical reasoning on specific instances in the knowledge base to automatically detect temporal conflicts in requirements. In one specific implementation, the system can create a SWRL rule engine based on the SWRL API, perform rule reasoning on specific instances in the knowledge base, and obtain the temporal sequence relationships between requirements; subsequently, the Pellet inferencer is used to perform consistency checks on the derived temporal relationships. Through the above reasoning process, the system can automatically derive explicit or implicit temporal relationships between requirements and detect whether there are temporal conflicts caused by violations of antisymmetry or reflexivity of temporal relationships.

[0116] The inference-based temporal conflict detection specifically includes:

[0117] 1) Requirement timing conflict detection

[0118] Based on specific instances in the knowledge base and the SWRL rules in the constraint definitions, the inference engine automatically derives the temporal order relationships between requirements. These SWRL rules are already included in the constraint definitions constructed in the first step and are used to derive Has_order relationships from dimensions such as data dependency, device state dependency, time constraint dependency, and system mode dependency. After obtaining the Has_order relationships between requirements, the inference engine performs a consistency check on the derived temporal order relationships. If there is a reflexive situation where a requirement precedes itself, or if any two requirements simultaneously have a mutual precedence relationship, then the temporal relationship is considered to violate anti-reflexivity or antisymmetry constraints, and a temporal conflict is determined. For example, if both Has_order(A, B) and Has_order(B, A) exist simultaneously, it means that requirement A and requirement B have a symmetrical temporal relationship, violating antisymmetry; if Has_order(A, A) exists, it means that requirement A itself constitutes a self-precedence relationship, violating anti-reflexivity.

[0119] 2) Extraction of conflict evidence

[0120] Upon detecting a timing conflict, the system locates the relevant set of inconsistent requirements based on the consistency detection results, traces back the reasoning path that led to the conflict, and extracts the corresponding conflict evidence. This conflict evidence includes: the original requirement text corresponding to the relevant requirement, the structured extraction results, the relational facts in specific instances, the inferred timing relationship, and the SWRL rules or constraints that triggered the timing relationship. For example, when the inference engine detects a mutual precedence relationship between two requirements, the system traces back the origin of each Has_order relationship, extracts its corresponding data dependency, control dependency, time constraint, or mode switching relationship, and further locates the relevant requirement text fragment. In this way, the system can maintain a complete traceability link from the original requirement text to the timing conflict determination result.

[0121] 3) Conflict report generation

[0122] Based on conflict evidence, the system generates a time-series conflict detection report including: a conflict summary, involved requirements, causes of conflict, reasoning basis, and modification suggestions. In one implementation, the system automatically constructs report generation prompts based on conflict evidence, guiding and constraining the LLM to strictly generate a read-friendly report based on the conflict evidence.

[0123] In this way, LLM does not directly undertake the task of determining temporal conflicts. Instead, after the inference engine completes conflict detection and extracts evidence, it generates a natural language interpretation report for requirements engineers based on credible evidence, thereby improving the readability and traceability of the report and avoiding the uncertainty brought about by pure LLM end-to-end judgment.

[0124] The following uses a smart home management system as a specific embodiment to clearly and completely describe the technical solution of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0125] Example 1

[0126] The smart home management system in this embodiment communicates with distributed sensors, controllers, and actuators through a home web server and a smart home gateway to monitor and control temperature, humidity, security, home appliances, and lighting. First, based on the embedded system's timing-related requirements description, the upper-layer ontology determines the types of concepts and conceptual relationships that can be identified in the smart home system's requirement text. Second, concept extraction prompts and relationship extraction prompts guide the LLM to extract concepts and conceptual relationships from natural language requirements and accompanying structured materials, identifying requirements, devices, system modes, data, control signals, device states, time constraints, and preconditions. The extraction results are then checked and iteratively corrected based on the constraint rules defined in the constraint definitions. Finally, the checked and approved structured extraction results are mapped to specific instances that conform to the upper-layer ontology type specifications and constraint requirements, and stored in the knowledge base. The inference engine derives the temporal sequence relationships between requirements based on specific instances in the knowledge base and SWRL rules in the constraint definitions. It performs consistency checks, and upon detecting a temporal conflict, the system locates the relevant inconsistent requirement set based on the consistency check results, traces back the inference path leading to the conflict, extracts corresponding conflict evidence, and automatically constructs a report based on the conflict evidence, generating prompts to guide the LLM in generating a temporal conflict detection report for requirements engineers. The operation flow and specific processing of this embodiment are as follows:

[0127] (a) Functional requirements description and element extraction

[0128] The smart home system includes multiple operating modes to adapt to system behavior and state switching in different scenarios: Normal operation mode for daily automation services; security alarm mode triggers alarms when abnormal doors / windows or illegal intrusions are detected; manual overwrite mode allows users to temporarily intervene in automatic control strategies; backup mode periodically saves system configuration and operating data; fault mode handles abnormal states such as device offline or network anomalies; recovery mode restores the system to normal operating status from backup; and maintenance configuration mode allows administrators to set system parameters and upgrade firmware. The system's functional requirements cover multiple aspects such as user management, environmental monitoring, security linkage, device control, report statistics, and system self-maintenance. Specifically, this includes: user authentication, user account management, temperature control monitoring, temperature setting, temperature planning, manual overwrite, humidity monitoring, humidity setting, door / window contact sensor monitoring, security alarm activation, power switch monitoring, appliance status control, monthly planning, monthly reports, display refresh, system backup, and system recovery.

[0129] In the requirement extraction phase, with "requirement" as the core element, the system systematically identifies key attributes for each requirement, including input data, output data, involved devices, operating mode, triggering events, and time constraints. The extraction is performed using an LLM (Limited Management Model): design concept extraction prompts guide the LLM to parse each requirement text and automatically extract information from each dimension. Examples of some extraction results are detailed in Table 1, which shows examples of functional requirement concept extraction for smart home systems. These examples include requirement instances, requirement inputs, requirement outputs, and identified key attribute instances such as devices / modes and time constraints.

[0130] Table 1. Example of functional requirement concept extraction for smart home systems

[0131]

[0132] (ii) Mapping of extracted elements to the upper-level ontology.

[0133] The structured concept extraction results obtained by LLM are semantically aligned and constraint checked, and then mapped to class instances and object attributes in the upper-level ontology. For example, functional requirements such as monitoring temperature, executing temperature plans, manually overriding temperatures, security alarms, backing up system data, and restoring system state are mapped to Requirement class instances; programmable temperature controllers, magnetic contact switches, digital programmable power switches, and security alarm systems are mapped to Device class instances; the on / off state of contact sensors, security alarm activation state, power switch on / off state, and the planned setpoint state of temperature controllers are mapped to DeviceState class instances; temperature readings, contact sensor states, and system data are mapped to Value class instances; alarm activation commands, power switch commands, and temperature control commands are mapped to Signal class instances; sensor acquisition cycle, alarm activation waiting time, specified hour boundaries for executing temperature plans, and system backup time are mapped to TimeConstraints class instances. Some of these mapping relationships are detailed in Table 2 below.

[0134] Table 2. Examples of mapping relationships from elements to the upper-level ontology.

[0135]

[0136] (III) Specific Ontology Instance Fragments

[0137] Taking "monitoring door and window contact" and "security alarm" as examples, the LLM is guided by relation extraction prompts to extract relations from the extracted concept instances that have undergone semantic alignment and constraint checks, combined with the original requirements. After constraint checks, the structured relation extraction results obtained by the LLM are converted into the following specific instance relation fragments: Requirement (monitoring door and window contact) represents the requirement to monitor door and window contact sensors; Requirement (security alarm) represents the requirement to activate security alarms; Device (magnetic contact switch) represents door and window contact sensors; DeviceState (contact sensor on) represents the on state of the magnetic contact switch; Signal (alarm activation command) represents the sound and light alarm control command; Monitoring door and window contact Produces contact state, security alarm ConsumedBy contact state, contact sensor on Is_precondition security alarm, security alarm Has_timeCons alarm waiting constraint, alarm waiting constraint Has_front monitoring door and window contact.

[0138] Through the specific instance relational fragments mentioned above, the description in the original text, "When the contact sensor becomes active, an audible and visual alarm is activated within 100 milliseconds," is transformed into an ontology relation that can be processed by the inference engine.

[0139] See Table 3 below for examples:

[0140] Table 3 Examples of Ontology Instantiation Relationship Fragments

[0141]

[0142] (iv) Derivation of timing relationships using SWRL rules

[0143] After generating specific instances, the inference engine derives the Has_order temporal relationship between requirements based on the SWRL rules in the constraint definition. The SWRL rules are not a separate module independent of the constraint definition, but rather the rule portion of the constraint definition used to guide the inference engine in reasoning about the temporal relationship of requirements.

[0144] In this embodiment, SWRL rules revolve around the data dimension, device state dimension, time constraint dimension, and system mode dimension. Rules for different dimensions have different derivation chains: For the data dimension, R1 first derives the data dependencies between requirements based on the data generation and consumption relationship, and then R2 transforms the data dependencies into temporal sequences; for the device state dimension, R3 first derives the changes in device state caused by requirements, then R4 derives the control dependencies, and R5 transforms the control dependencies into temporal sequences, while R6 handles the temporal order implied by continuous state transitions of the same device; for the time constraint dimension, R7 to R10 directly or indirectly derive the temporal sequences between requirements based on specified occurrence times, waiting constraints, and time slice rotation constraints; for the system mode dimension, R11 derives the temporal sequences between requirements under different modes based on mode call relationships and mode switching relationships.

[0145] To cover the above set of rules, this embodiment selects data dependencies, device state changes, previous states, state transitions, specified occurrence times, waiting constraints, time slice rotation constraints, and mode switching relationships from the requirements of smart home systems as the basis for derivation. Examples of each rule are detailed in Table 4 below:

[0146] Table 4 Examples of SWRL rule derivation

[0147]

[0148] (v) Temporal relation set and consistency check

[0149] The inference engine continuously expands the Has_order relation set based on the facts and rules in section 4. For the smart home system example, several representative temporal relations can be obtained: monitoring temperature precedes executing the temperature plan, executing the temperature plan precedes manually overriding the temperature, monitoring door and window contact precedes security alarms, backing up system data precedes restoring the system state, and monitoring needs in normal operation mode precede alarm needs in security alarm mode.

[0150] The results of some of the derivations are detailed in Table 5 below:

[0151] Table 5 Examples of derived time series relationships

[0152]

[0153] During consistency checks, the inference engine queries whether any requirement precedes itself, or whether any two requirements simultaneously have a mutual precedence relationship. For example, in the requirements "Execute Temperature Plan" and "Manually Override Temperature," if the LLM does not distinguish between the "planned settings for the current time slice" and the "planned settings to be restored in the next time slice" during extraction, R6 can derive Has_order(Execute Temperature Plan, Manually Override Temperature) from the device state transition. Simultaneously, the system may derive Has_order(Manually Override Temperature, Execute Temperature Plan) after switching back to normal operation mode following the end of the manual override mode and re-invoking the temperature plan requirement. These two relationships violate antisymmetry due to the existence of mutual precedence, and the inference engine uses this to locate the relevant inconsistent requirement set. Examples of consistency checks and conflict localization are detailed in Table 6 below:

[0154] Table 6 Examples of Consistency Checks and Conflict Locations

[0155]

[0156] (vi) Conflict report generation.

[0157] After obtaining the conflict set shown in Table 6, the system traces back the derivation path of the two Has_order relationships, extracts the corresponding original requirement text, structured extraction results, relational facts in specific instances, state transition relationships, mode switching relationships, time constraints, and SWRL rules that trigger related temporal relationships, thus forming conflict evidence.

[0158] In this embodiment, the conflict evidence indicates that: R6 deduces from the device state transition relationship that the executed temperature plan should precede the manual temperature overlay; the system, based on the switch back to normal operation mode after the manual overlay mode ends and the temperature plan requirement is re-called, deduces that the manual temperature overlay should precede the executed temperature plan. Therefore, both Has_order(executed temperature plan, manual overlay temperature) and Has_order(manual overlay temperature, executed temperature plan) exist simultaneously between the two requirements, violating the antisymmetry of timing relationships, and are thus determined to be a timing conflict.

[0159] During the report generation phase, the LLM does not directly undertake the task of determining timing conflicts. Instead, it generates a user-friendly report based on the conflict detection results and conflict evidence generated by the inference engine. The system automatically constructs report generation prompts based on the conflict evidence, using these prompts to guide and constrain the LLM to strictly adhere to the conflict evidence when generating the detection report. The detection report generated by the LLM may include the following: the conflict summary is "there is a mutual precedence relationship between the execution temperature plan requirement and the manual coverage temperature requirement"; the requirements involved are "execute temperature plan" and "manual coverage temperature"; the conflict basis is that the plan setting value derived from R6 precedes the coverage setting value, and the reverse timing relationship derived from the requirement to return to normal operation and re-call the temperature plan after manual coverage ends; the modification suggestion is to explicitly distinguish between "current cycle plan setting value", "coverage setting value" and "next cycle plan setting value" in the requirement text and specific instances, or to model "restore plan value after coverage ends" as an independent next cycle recovery requirement.

[0160] As can be seen from the above embodiments, the present invention can automatically convert complex natural language requirements such as those for smart home systems into concrete instances that conform to the constraints of the upper-level ontology, and deduce the temporal relationships between requirements across multiple dimensions, including data dependencies, control dependencies, device state transitions, time constraints, and mode switching. When circular dependencies or reflexive relationships appear in the derivation results, the system can locate the relevant set of requirements, retain a complete chain of evidence from the original requirement text, structured extraction results, concrete instance relationships to inference rules and conflict determination results, and generate highly readable modification suggestions. This embodiment covers the main concepts, conceptual relationships, and SWRL rules in the constraint definition of the upper-level ontology of the present invention, demonstrating that the present invention can be used for requirement analysis scenarios of smart homes and other complex embedded systems involving multiple devices, multiple modes, multiple states, multiple data dependencies, and multiple time constraints.

[0161] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. For those skilled in the art, various modifications, equivalent substitutions, or improvements can be made to the above embodiments without departing from the technical concept of the present invention, and all such modifications, substitutions, or improvements should fall within the scope of protection of the present invention.

Claims

1. An automatic method for detecting demand timing conflicts based on LLM and ontology reasoning, characterized in that, The method includes the following steps: Step 1: Construct the upper-layer ontology of the embedded system's timing-related requirements description. 1-1: A method combining manually predefined ontology structures with explicit Protege modeling is used to construct an upper-level ontology describing the timing requirements of an embedded system. 1-2: Define the concepts, conceptual relationships, and constraint relationships used to describe timing requirements in the upper-level ontology; 1-3: Store the defined upper-level ontology into the knowledge base; Step 2: Extracting instances of the embedded system timing-related requirements ontology based on LLM. Based on the upper-level ontology design concept extraction prompts and relation extraction prompts, the LLM is driven to extract ontology instances from natural language requirement text, specifically including: 2-1: Based on the concept types defined in the upper-level ontology, identify the relevant concepts in the requirement text and extract the text objects corresponding to each concept type; 2-2: Based on the conceptual relationships defined in the upper-level ontology, identify the relationships between the concepts and form a structured extraction result; 2-3: Based on the constraint relationships defined in the upper-level ontology, semantic alignment and constraint checks are performed on the structured extraction results. If the check passes, the extraction results are instantiated into specific instances that conform to the constraints of the upper-level ontology and stored in the knowledge base. If the check fails, structured feedback containing error location and correction suggestions is generated to guide the LLM to re-extract until the check passes. Step 3: Temporal Conflict Analysis Based on Ontology Reasoning Using an inference engine to perform logical reasoning on the instantiated ontology, specifically including: 3-1: Derive the temporal relationship between requirements based on preset inference rules; 3-2: Input the inferred demand timing relationship into the inference engine for consistency detection. If the demand timing relationship is found to violate the timing relationship constraint, it is determined to be a timing conflict. The timing relationship constraint is the time when the demand occurs or the time interval between demands. 3-3: Based on the time-series conflict detection results, the system locates the set of inconsistent requirements. The system automatically backtracks and extracts the original requirement text, structured extraction results and reasoning basis corresponding to the relevant requirement set as conflict evidence. Based on the conflict evidence, the system automatically constructs conflict report generation prompts and drives the LLM to generate a time-series conflict detection report containing: conflict summary, involved requirements, conflict causes and modification suggestions.

2. The automatic detection method for demand timing conflicts based on LLM and ontology reasoning according to claim 1, characterized in that, In step 1, the concepts used to describe temporal requirements are uniformly defined in the upper-level ontology, including at least: system mode class, device state class, time constraint class, requirement class, data dependency class, and control signal class. The time constraint class consists of post-constraints, time constraints, and duration constraints that express the time of occurrence of a requirement or the time interval between requirements. The concept relationship is based on the constructed concept class hierarchy, defining the association between concepts. The constraint relationship is a constraint system that the concept class and the association relationship must satisfy, which includes: constraint rules that provide verification standards for LLM element extraction results and SWRL rules that guide the inference engine to reason about the temporal relationship of requirements.

3. The automatic detection method for demand timing conflicts based on LLM and ontology reasoning according to claim 1, characterized in that, Step 2 specifically includes: 1) Concept Extraction: Based on the concept types defined in the upper-level ontology, design concept extraction prompts to guide the large language model to identify and extract text objects corresponding to each concept type from the requirements document; 2) Conceptual Relationship Extraction: Based on the conceptual relationships defined in the upper-level ontology, relation extraction prompts are designed to guide the large language model to identify the relationships between the text objects and form structured extraction results; 3) Constraint Check: Based on the constraint system defined in the upper-level ontology, semantic alignment and constraint checks are performed on the structured extraction results. The semantic alignment is used to merge synonymous or near-synonymous concept objects to eliminate naming inconsistencies and semantic ambiguities. The constraint check is used to check whether the concept objects and their relationships meet the constraint requirements for object integrity, relationship legality, and subsequent temporal reasoning. If the check fails, the system automatically generates structured feedback containing error location and correction suggestions, guiding the large language model to re-execute concept extraction and concept relationship extraction based on the feedback until the check passes. 4) Specific instance generation: The checked concept objects and their relationships are mapped and converted into specific instances that conform to the upper-level ontology type specifications and constraints, and stored in the knowledge base.

4. An automatic requirement timing conflict detection system constructed using the requirement timing conflict automatic detection method based on LLM and ontology reasoning as described in claim 1, characterized in that, The system comprises: an upper-level ontology construction module, an ontology instance extraction module, and a temporal conflict analysis module. The upper-level ontology construction module uses a combination of manually predefined ontology structures and Protege explicit modeling to construct an upper-level ontology describing the temporal-related requirements of the embedded system. After defining concepts, conceptual relationships, and constraints, it stores the information in a knowledge base. The ontology instance extraction module, based on the upper-level ontology, guides a large language model to extract concepts and conceptual relationships from the requirement text. It then checks the extraction results against constraints. If the check passes, the extraction results are mapped to concrete instances conforming to the upper-level ontology constraints and stored in the knowledge base. If the check fails, structured feedback information is generated to guide the large language model to re-execute the extraction until the check passes. The temporal conflict analysis module uses an inference engine combined with concrete instances in the knowledge base and SWRL rules to deduce the temporal relationships between requirements. It performs consistency checks on the derived temporal relationships. When an inconsistent relationship violating temporal constraints is detected, a temporal conflict is determined, conflict evidence is extracted, and a temporal conflict detection report is generated.

Images