Complex embedded system demand modeling method based on limited natural language

Abstract

The invention relates to a complex embedded system demand modeling method based on a limited natural language, and belongs to the field of embedded system modeling. The method comprises the following steps: performing domain analysis on the complex embedded system, extracting entities, attributes and association relationships thereof in the system, and establishing a meta-model of the complex embedded system; establishing a demand template and a constraint rule of the demand template according to the class of the meta-model and the attribute of the class; and calling the corresponding demand template and the constraint rule of the demand template according to the modeling sequence, and modeling the complex embedded system based on the limited natural language. According to the method, a demand template of the system and a constraint rule filled by the demand template are established by extracting attributes and association relationships of the complex embedded system from multiple angles, and the complex embedded system is modeled based on a limited natural language. The problem that the modeling content is ambiguous when the complex embedded system software demand is modeled is solved, and the modeling quality is improved.

Description

Technical Field

[0001] The present invention relates to embedded system modeling, and in particular to a method for modeling requirements of complex embedded systems based on restricted natural language. Background Art

[0002] A complex embedded system is a large-scale system that integrates the physical world, computing, and networking, enabling real-time interaction between the network and the physical world. The system senses external physical data through various sensors and transmits data through the network. Compared with other embedded systems, complex embedded systems have the characteristics of diverse task requirements and close software-hardware interaction. Therefore, such systems often have a huge scale and a complex structure, resulting in more complex requirement analysis and modeling.

[0003] Currently, there are mainly the following methods for requirement analysis and modeling of complex embedded systems: First, based on structured natural language requirement documents, which is the most commonly used method in current industrial practice. Requirement analysis is carried out through pre-defined documents, and diagrams are used to make the document content easier to understand. Since there are a large number of software and hardware entities in complex embedded systems and a huge amount of interaction information between entities, multiple requirement documents are required to complete the complete requirement analysis, which easily leads to inconsistencies between documents, and it is difficult to analyze the traceability relationships between entities and is also not conducive to users' understanding of the documents. Second, based on semi-formal modeling languages, represented by UML, SysML, and BPMN, which have a graphical interface and users can complete modeling by describing the attributes and relationships of graphical components. However, the semi-formal modeling languages focus on generality, while complex embedded systems need to consider various requirements, so that this method cannot accurately depict the domain characteristics of complex embedded systems and cannot systematically and comprehensively perform requirement analysis and modeling on complex embedded systems. Third, based on formal models, which prove its correctness or incorrectness in a mathematical way through the specifications or attributes of the formal model. For complex embedded systems, this method requires formal experts to symbolically represent the entities in the system and design the model, and focuses on single requirements such as the real-time performance and security of the system, resulting in the need for the support of formal experts, high modeling difficulty, and only focusing on single requirements.

[0004] It can be seen that the existing methods for requirement analysis and modeling of complex embedded systems are difficult to balance the accuracy of requirement analysis and the difficulty of requirement analysis, and cannot systematically and comprehensively perform requirement analysis. Moreover, the content of modeling is prone to ambiguity during modeling. Therefore, in view of the characteristics of complex embedded systems, it is very necessary to provide a method for modeling requirements of complex embedded systems based on restricted natural language. Summary of the Invention

[0005] In view of the above analysis, the present invention aims to provide a method for modeling requirements of a complex embedded system based on restricted natural language, so as to solve the problem of ambiguity in the modeling content when modeling the software requirements of a complex embedded system.

[0006] The present invention provides a method for modeling requirements of a complex embedded system based on restricted natural language, and the method includes the following steps:

[0007] Perform domain analysis on the complex embedded system, and extract entities, attributes and their association relationships in the system;

[0008] Based on the entities, attributes and their association relationships, establish a meta-model of the complex embedded system, and store the meta-model in a database; the meta-model includes classes and attributes of the classes, and there are association relationships between the classes;

[0009] Establish a requirements template according to the classes and attributes of the meta-model, establish constraint rules for the requirements template based on the entities, attributes and their association relationships, and store the requirements template and the constraint rules of the requirements template in the database;

[0010] Determine the modeling order of the entities according to the software requirements, call the corresponding requirements template and the constraint rules of the requirements template from the database according to the modeling order, and model the complex embedded system based on restricted natural language according to the requirements template and the constraint rules of the requirements template.

[0011] Further, the constraint rules of the requirements template include options of items to be filled and grammar rules.

[0012] Further, the requirements template includes several items to be filled, and some items to be filled only include limited options, and a list is provided for the user to select from the limited options.

[0013] Further, the grammar rule is a statement including a grammar structure, keywords and items to be input.

[0014] Further, the modeling of the complex embedded system based on restricted natural language according to the requirements template and the constraint rules of the requirements template includes:

[0015] For the items to be filled described in restricted natural language in the requirements template, generate corresponding restricted natural language expressions according to the grammar rules of the constraint rules of the requirements template; each grammar rule corresponds to at least one restricted natural language expression; select the items to be input in the restricted natural language expressions or input according to the constraint conditions of the items to be input;

[0016] For the items to be filled that only include limited options in the requirements template, select from the provided list;

[0017] For the items to be filled in described in natural language in the requirement template, free input is performed.

[0018] When all the items to be filled in the requirement template are completed, the modeling is completed.

[0019] Furthermore, the meta-model is divided into a functional requirement and real-time requirement meta-model, a system architecture meta-model, and a security requirement meta-model; the classes of the meta-model correspond to the entities or their attributes, the attributes of the classes of the meta-model correspond to the attributes of the entities, and the association relationships between the classes of the meta-model correspond to the association relationships of the entities and their attributes.

[0020] Furthermore, a system task template and a system state template are established according to the classes and attributes of the functional requirement and real-time requirement meta-model.

[0021] Furthermore, a data template, a software configuration item template, a device template, an interface template, and a hardware resource template are established according to the classes and attributes of the system architecture meta-model.

[0022] Furthermore, a fault template is established according to the classes and attributes of the security meta-model.

[0023] Furthermore, a domain analysis is performed on the complex embedded system from four perspectives: system architecture, functional requirements, real-time requirements, and security requirements.

[0024] Compared with the prior art, the present invention can at least achieve one of the following beneficial effects:

[0025] 1. By extracting the attributes and their association relationships of a complex embedded system from multiple perspectives, the present invention establishes a requirement template for the system and constraint rules for filling in the requirement template, and models the complex embedded system based on restricted natural language, solving the problem of ambiguity in the modeling content when modeling the software requirements of the complex embedded system and improving the modeling quality.

[0026] 2. The present invention establishes a meta-model of a complex embedded system, establishes a requirement template through the classes and attributes of the meta-model, and performs modeling by calling the corresponding requirement template, solving the problem that there is currently no method for constructing a requirement model for a complex embedded system based on comprehensive requirement analysis.

[0027] 3. The present invention performs a domain analysis on a complex embedded system from four perspectives: system architecture, functional requirements, real-time requirements, and security requirements, achieving the systematicness and comprehensiveness of the system requirement analysis, improving the correctness of requirement modeling, and improving the modeling quality.

[0028] 4. In view of the close interaction between software and hardware in complex embedded systems, the present invention establishes a meta-model of the system by extracting entities, attributes and their association relationships in the complex embedded system, so that the established meta-model includes the interaction relationships between entities; the system hardware architecture and software requirements are associated through the meta-models of functional requirements, real-time requirements, system architecture and security requirements, thus ensuring the associated matching between the system hardware architecture and software requirements.

[0029] 5. The present invention conducts modeling by calling corresponding requirement templates, which is easy for developers to understand, reduces the difficulty of requirement modeling, and improves the efficiency and quality of requirement modeling.

[0030] In the present invention, the above technical solutions can also be combined with each other to achieve more preferred combination schemes. Other features and advantages of the present invention will be described in the subsequent specification, and some advantages can be made obvious from the specification or understood by implementing the present invention. The objectives and other advantages of the present invention can be realized and obtained from the content specifically pointed out in the specification and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The drawings are only for the purpose of showing specific embodiments and are not considered as limiting the present invention. Throughout the drawings, the same reference signs denote the same components.

[0032] Figure 1 is a flowchart of the method for modeling requirements of a complex embedded system based on restricted natural language according to an embodiment of the present invention;

[0033] Figure 2 is a schematic diagram of the relationship between entities in a complex embedded system according to an embodiment of the present invention;

[0034] Figure 3 is a schematic diagram of the meta-model of functional requirements and real-time requirements according to an embodiment of the present invention;

[0035] Figure 4 is a schematic diagram of the meta-model of system architecture according to an embodiment of the present invention;

[0036] Figure 5 is a schematic diagram of the meta-model of security requirements according to an embodiment of the present invention;

[0037] Figure 6 is a schematic diagram of software requirement modeling according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0038] The following will specifically describe the preferred embodiments of the present invention with reference to the drawings. The drawings form a part of this application and are used together with the embodiments of the present invention to explain the principles of the present invention, rather than to limit the scope of the present invention.

[0039] A specific embodiment of the present invention discloses a method for modeling requirements of a complex embedded system based on restricted natural language. As Figure 1 shown, the method includes the following steps:

[0040] Step S1: Conduct a domain analysis of the complex embedded system, and extract entities, attributes, and their association relationships in the system;

[0041] Step S2: Based on the entities, attributes, and their association relationships, establish a meta-model of the complex embedded system, and store the meta-model in a database; the meta-model includes classes and attributes of the classes, and there are association relationships between the classes;

[0042] Step S3: Establish a requirements template according to the classes and attributes of the meta-model, and establish constraint rules for the requirements template based on the entities, attributes, and their association relationships, and store the requirements template and the constraint rules of the requirements template in the database;

[0043] Step S4: Determine the modeling order of the entities according to the software requirements, call the corresponding requirements template and the constraint rules of the requirements template from the database according to the modeling order, and model the complex embedded system based on the restricted natural language according to the requirements template and the constraint rules of the requirements template.

[0044] Specifically, in step S1, the complex embedded system is subjected to domain analysis from four perspectives: system architecture, functional requirements, real-time requirements, and security requirements.

[0045] Conduct a domain analysis of the complex embedded system architecture, and extract the software and hardware in the system architecture; classify the software and hardware, and extract the functions, attributes, association relationships, and constraints between the software and hardware. The constraint is the requirement for the normal operation of the software and hardware in the system.

[0046] It can be understood that complex embedded systems have various application fields, such as aerospace, automotive, medical, etc. Each field has different software and hardware requirements, different functions and real-time requirements, and different faults. It is necessary to conduct domain analysis according to the specific application field of the system.

[0047] Conduct domain analysis on the functions and real-time requirements of complex embedded systems, and extract the tasks and their attributes of the system; analyze the tasks and their attributes, and extract the timing relationships and constraints existing between the tasks. The timing relationships between the tasks include the previous task, next task, father task, child task, and time cost of the task execution of the task. A task can correspond to multiple previous tasks, next tasks, father tasks, and child tasks respectively. The previous task of the first child task of the father task is the father task, and the next task of the last child task of the father task is the father task. The task execution time includes the best deadline and the worst deadline of the task. The constraints of the task are the interaction processes and constraints between the associated entities during the task execution.

[0048] Conduct research and induction on the common faults of complex embedded systems, and extract the attributes of the faults and their propagation relationships; the propagation relationship is the triggering relationship between the faults; conduct domain analysis on the security requirements and designs of complex embedded systems, and extract the security policies corresponding to the faults and the task processes of the policies. The security policies corresponding to the faults include fault detection policies, fault redundancy policies, and fault tolerance policies. The task process of the security policy is the task execution process of the policy; a fault can correspond to multiple security policies, and a security policy corresponds to a task.

[0049] Specifically, the security policy refers to the security policy implemented by the system to maintain a safe state for specific faults. The fault detection policy is the policy for detecting the fault, and the fault redundancy policy is the redundancy policy for reducing the likelihood of the fault occurring. The fault tolerance policy is the policy for coping with the fault after the fault occurs to enable the system to return to the normal state. Each fault can correspond to multiple fault detection policies, fault redundancy policies, and fault tolerance policies respectively. Each security policy corresponds to a task process, and the task process is the tasks and their attributes in the system, the timing relationships and constraints existing between the tasks.

[0050] It can be understood that due to the large scale and complex structure of complex embedded systems, the occurrence of a single or multiple faults may cause the occurrence of other faults, resulting in the system being more dangerous. Therefore, extracting the propagation relationship of faults can effectively improve the security of the system. The task execution order of the security policy is different from the general system task execution order. The fault detection policy is executed under specific conditions to discover faults in the system, the fault redundancy policy is executed under specific conditions to reduce the probability of the system failing, and the fault tolerance policy is executed after the fault occurs to enable the system to return to the safe state as soon as possible.

[0051] Specifically, the entities include system tasks, system status, data, software configuration items, devices, interfaces, hardware resources, and faults. Each entity has corresponding attribute information. The attribute information of the system tasks includes: task name, parent task, child tasks, prerequisite tasks, successor tasks, task priority, whether it is a periodic task, whether it is an interrupt task, task execution time, required hardware resources, required interfaces, and input data. The attribute information of the status includes: status name, trigger condition, tasks being executed in this status, and target status. The attribute information of the data includes: corresponding data dictionary name, data type, and data definition. The attribute information of the software configuration items includes: software configuration item name, tasks involved in the software configuration item, corresponding device type, required hardware resources, required interfaces, input data, and output data. The attribute information of the devices includes: device name, device type, tasks involved in the device, deployed software configuration items, provided hardware resources, and provided interfaces. The attribute information of the interfaces includes: interface name, interface type, interface mode, device providing the interface, connected interfaces, transmission protocol, transmission direction, and provided hardware resources. The attribute information of the hardware resources includes: hardware resource name, resource type, and resource configuration. The attribute information of the faults includes: fault name, fault source, fault type, probability of fault occurrence, severity of the fault, and precursor faults.

[0052] It can be understood that the present invention conducts domain analysis from four perspectives of the system architecture, functional requirements, real-time requirements, and security requirements of a complex embedded system, achieving the systematicness and comprehensiveness of the system requirements analysis, improving the correctness of the requirements modeling, and improving the quality of the modeling.

[0053] Specifically, in step S2, the meta-model is divided into a meta-model of functional requirements and real-time requirements, a meta-model of system architecture, and a meta-model of security requirements; the classes of the meta-model correspond to the entities or their attributes, the attributes of the classes of the meta-model correspond to the attributes of the entities, and the association relationships between the classes of the meta-model correspond to the association relationships of the entities and their attributes.

[0054] The relationships between the entities are as Figure 2As shown in the figure. Among them, the system tasks, system states, and data correspond to the functional requirements of the system. The system tasks include the interaction processes between software configuration items and devices in the system. During the interaction processes, the software configuration items and devices use data for information interaction. At the same time, the execution of the system tasks will trigger changes in the system states. The software configuration items, devices, interfaces, and hardware resources correspond to the system architecture. The software configuration items run on the devices, and their normal operation depends on the hardware resources provided by the devices. At the same time, the devices need to provide interfaces to support data interaction in the system; both the devices and interfaces, as the hardware in the system, will provide corresponding hardware resources to meet the requirements of the software configuration items for hardware resources during normal operation. It can be seen that the system architecture is an important support for the system functional requirements. The system tasks also correspond to the real-time requirements of the system. The system tasks also include the timing relationships of task execution and the timing constraints for normal task execution. Faults correspond to the security requirements of the system. As an anomaly that may occur during the operation of the system, faults will occur on software configuration items, devices, and interfaces. To ensure the security of the system, faults need to have corresponding security policies to deal with them. The corresponding security policies have corresponding tasks, and the corresponding tasks are triggered when faults occur and execute corresponding task processes.

[0055] Specifically, the entities corresponding to the functional requirements and the real-time requirements meta-model include system tasks, system states, and data. As Figure 3As shown, in the meta-model of functional requirements and real-time requirements, a system state can correspond to multiple tasks. The execution of a task may trigger a system state transition. Each state can have multiple state transitions, and each state transition needs to specify the trigger condition, action, and target state of the state transition. System tasks can be divided into interrupt tasks and periodic tasks according to different task types. Each task corresponds to a task specification, which includes the basic information of the task (attributes of TaskSpecification) and the action flow information (FlowOfEvents). The basic information describes the timing relationship between tasks. The action flow information (FlowOfEvents) can be divided into the main task flow (CPSFlowOfEvents) and the alternative task flow (AlternativeFlow). The main task flow and the alternative task flow contain the action processes of the system (ActionSentence), and each action process corresponds to a timing relationship statement (CPSTimingRelationship). The syntax of the timing relationship statement needs to include three types of information: ActionKeyword, TimingKeyword, and Deadline.

[0056] For the six classes inherited from ActionSentence, they correspond to different action grammars, specifically as follows:

[0057] (1) CollectDataSentence class: Describes the data collection action in the system interaction process. This action needs to be completed by the device (Device) in the system. Among them, DeviceName is the name of the device that issues the collection action, corresponding to the Device in the system architecture meta-model; DataName describes the data collected, corresponding to the Data in the system architecture meta-model.

[0058] (2) CalculateSentence class: Describes the data calculation action in the system interaction process. This action is completed by the software configuration item (Software) in the system. Among them, SoftwareName describes the software configuration item that executes this calculation action, corresponding to the Software in the system architecture meta-model; InputData and OutputData respectively describe the input data and output data of this calculation action, corresponding to the Data in the system architecture meta-model.

[0059] (3) SetDataSentence class: Describes the data setting action in the system interaction process. This action is completed by the Actors in the system, namely software configuration items or devices. Among them, DataName describes the data that needs to be assigned a value, corresponding to Data in the system architecture meta-model; Value describes the value that needs to be assigned.

[0060] (4) SendDataSentence class: Describes the data sending action in the system interaction process. This action is completed by the software configuration items in the system. Among them, SenderName describes the execution entity of the data sending action, corresponding to Software in the system architecture meta-model; DataName describes the data that needs to be sent, corresponding to Data in the system architecture meta-model; InterfaceName describes the interface name required to send the data, corresponding to Interface in the system architecture meta-model; ReceiverName describes the target software object of the data sending, corresponding to Software in the system architecture meta-model.

[0061] (5) ReceiveDataSentence class: Describes the data receiving action in the system interaction process. This action is completed by the software configuration items in the system. Among them, ReceiverName describes the execution entity of the data receiving action, corresponding to Software in the system architecture meta-model; DataName describes the data that needs to be received, corresponding to Data in the system architecture meta-model; InterfaceName describes the interface name required to receive the data, corresponding to Interface in the system architecture meta-model.

[0062] (6) DelaySentence class: Describes the delay operation in the system interaction process. This action is completed by the Actors in the system, namely software configuration items or devices. Among them, ActorName describes the software configuration item or device that executes this action; TimeLength requires filling in the specific time information of the delay.

[0063] Specifically, the entities corresponding to the system architecture meta-model include software configuration items, devices, interfaces, hardware resources, and data. As Figure 4As shown, in the system architecture meta-model, software runs on devices and has certain operating requirements for hardware resources, while the devices need to provide the hardware resources required for software operation and also need to provide interfaces to allow information interaction between the devices and the software. Devices can be classified into Storage (storage device), Sensor (sensor), Actuator (actuator), EnergySupply (energy supply device), and Controller (control device) according to their types; hardware resources can be classified into ComputingResource (computing resource), StorageResource (storage resource), TimerResource (clock resource), and TransmissionResource (transmission resource); interfaces can be classified into InterruptInterface (interrupt interface, including interrupt type (InterruptType) and interrupt source (InterruptSource)), AD / DAInterface (AD / DA interface, including AD / DA type (addaType)), I / OInterface (I / O interface, including I / O interface type (ioType)), and CommunicationInterface (data interaction interface, including interaction interface type (communicationType), transmission direction (transmissionDirection), interface address (interfaceAddress), and connection (connect)) according to their types. Data undertakes the task of data interaction between interfaces and can be classified into DataSet (data set) and DataItem (data item) according to the type of data. Among them, a data set is composed of multiple data items and has an attribute corresponding to the number of data items it contains, while a data item has an attribute of data type (DataUnit).

[0064] Specifically, the entities corresponding to the security requirements meta-model include faults, software configuration items, devices, interfaces, and system tasks. As Figure 5 shown, in the security requirements meta-model, the previous fault (PreviousFault) refers to the name of other faults (Fault) that may trigger this fault. Faults can occur on Actors (i.e., software and devices) and interfaces (Interface). The security policies corresponding to faults include detection data (TargetData in fault detection), corresponding redundancy (MitigationMechanism in fault redundancy), and fault tolerance mechanisms (ToleranceMechanism in fault tolerance), and the tasks corresponding to the security policies need to be described by referring to task templates.

[0065] Specifically, the relationships between the functional requirements, the real-time requirements meta-model, the system architecture meta-model, and the security requirements meta-model are as follows:

[0066] (1) Functional requirements and the real-time requirements meta-model and the system architecture meta-model: The two are associated through the action sentences ( Figure 3 and Figure 4 the ActionSentence class in Figure 3 and Figure 4 ) in the functional requirements and real-time requirements meta-model. Action sentences are important elements in the functional requirements and real-time requirements. Each Task class corresponds to an action process (CPSFlowOfEvents), and the action process consists of a series of sequential action sentences. There are 8 types of action sentences, and entities in the architecture are referenced through the attributes (such as InputData, SoftwareName, etc.) in the 8 types of sentences (such as

[0067] the Actor (including Software and Device), Data, Interface in Figure 3 and Figure 6 ), so as to model the dynamic interaction process of the system architecture at the functional requirements level. Figure 3 and Figure 6 in Figure 3 and Figure 6 ), and each mechanism needs to describe the execution process of the mechanism through a clearly defined mechanism task ( Figure 3 and Figure 4 the Task in

[0068] (3) System architecture meta-model and security requirements meta-model: For complex embedded systems, faults occur in the entities corresponding to the system architecture, including software configuration items ( Figure 3 and Figure 5 the Software in Figure 3 and Figure 5 ), devices ( Figure 3 and Figure 5 the Device in Figure 3 and Figure 6The definition of Fault in [system name] needs to be mapped to the system architecture level to ensure a clear traceability relationship between system security requirements and the system architecture.

[0069] It can be understood that, in view of the close interaction between software and hardware in complex embedded systems, the present invention establishes a meta-model of the system by extracting entities, attributes and their relationships in complex embedded systems, so that the established meta-model includes the interaction relationships between entities; the system hardware architecture and software requirements are associated through the meta-models of functional requirements, real-time requirements, system architecture and security requirements, thus ensuring the associated matching between the system hardware architecture and software requirements.

[0070] Specifically, in step S3, the requirement template contains several items to be filled; the classes and class attributes of the corresponding meta-model are selected according to the category of the requirement template, and the classes and class attributes of the corresponding meta-model are used as the items to be filled in the requirement template, thereby constructing the requirement template.

[0071] Specifically, the categories of the requirement template include system task template, system state template, data template, software configuration item template, device template, interface template, hardware resource template, fault template; each entity corresponds to a category of requirement template.

[0072] Further, system task templates and system state templates are established according to the classes and class attributes of the meta-model of functional requirements and real-time requirements.

[0073] Specifically, the system task template is used to describe task information, relationships between tasks and task processes in the system. The system task template can be divided into a basic information part, a main task process part, and a branch task process part. Each task corresponds to only one basic information part and one main task process part, while the branch task process part can be increased according to the number of branches in the main process. The branch task process part is only used when there are branch statements in the main process. The basic information part corresponds to the Task and TaskSpecification classes in the meta-model of functional requirements and real-time requirements, the main task process corresponds to the CPSFlowOfEvents class, and the branch task process corresponds to the AlternativeFlow class.

[0074] Exemplarily, the content of the system task template is shown in Tables 1, 2, and 3:

[0075] Table 1 Example of System Task Template (Basic Information Part)

[0076]

[0077]

[0078] Table 2 Example of System Task Template (Main Task Process Part)

[0079]

[0080] Table 3 Example of System Task Description Template (Branch Task Process Part)

[0081]

[0082]

[0083] Among them, self - containment of system tasks is not allowed (that is, the task itself is its own parent task or child task). Task Priority is used to determine which system task should be executed first when a system task times out and needs to be forcibly stopped or system resources are preempted. Input references data templates by using DataDictionary ID. Main Timeline records the task steps of components or subtasks included in a task, and Alternative Timeline is the branch task steps in Main Timeline, which need to be executed in coordination with the decision conditions in Main Timeline. The Action field is used to describe the actions of components in system tasks, and Timing Relationship is used to describe the synchronization relationship between the steps in a task and the steps in other tasks.

[0084] Specifically, the system state template is used to describe the state of the system and the transition conditions between states. The system state template can be divided into a basic information part and a state transition part. The states are transferred through departure state transition events, and a state can contain multiple state transitions. The basic information part corresponds to the State class in the functional requirement and real - time requirement meta - model, and the state transition part corresponds to the StateTransition class.

[0085] Exemplarily, the content of the system state template is shown in Table 4 and Table 5 as follows:

[0086] Table 4 Example of System State Template (Basic Information Part)

[0087]

[0088] Table 5 Example of System State Template (State Transition Part)

[0089]

[0090] Among them, the Transition field is used to describe all state transitions of this state, and this field corresponds to three fields, namely the Trigger field, the Action field, and the Target State field.

[0091] Furthermore, data templates, software configuration item templates, device templates, interface templates, and hardware resource templates are established based on the classes and attributes of the system architecture meta-model.

[0092] Specifically, the data template is used to describe the data and data sets in the system. The basic information part of the data template corresponds to the Data class, DataSet class, and DataItem class in the system architecture meta-model.

[0093] Exemplarily, the content of the basic information part of the data template is shown in Table 6:

[0094] Table 6 Example of Data Template (Basic Information Part)

[0095]

[0096]

[0097] Specifically, when the Data Type is a data set, the content of the data template is shown in Table 7:

[0098] Table 7 Example of Data Template (Data Type is Data Set)

[0099]

[0100] When the Data Type is a data item, the content of the data template is shown in Table 8:

[0101] Table 8 Example of Data Template (Data Type is Data Item)

[0102]

[0103]

[0104] Among them, the Data Definition field is used to describe the specific definition rules of the data described by this data dictionary. Each line corresponds to a data definition statement, and a data set can be composed by referencing other data items. The Invariants field describes the constraint conditions on the value range that the data needs to satisfy during its life cycle.

[0105] Specifically, the software configuration item template is used to describe the software configuration in the system, corresponding to the Software class in the system architecture meta-model.

[0106] Exemplarily, the content of the software configuration item template is shown in Table 9:

[0107] Table 9 Example of Software Configuration Item Template

[0108]

[0109]

[0110] Among them, the Task Involved field records the ID identifiers of all system tasks in the system that involve this software configuration item. This ID identifier is the unique identifier of the system task and uniquely corresponds to each system task template; the Data field is divided into two parts: Input Data and Output Data, and the data template is referenced by using the DataDictionary ID.

[0111] Specifically, the device template is used to describe the devices in the system and corresponds to the Device class in the system architecture meta-model.

[0112] Exemplarily, the content of the device template is shown in Table 10:

[0113] Table 10 Example of Device Template

[0114]

[0115]

[0116] Among them, the Provided Resources are described by referencing the hardware resource template using the ResourceID; the Provided Interface uses the interface InterfaceID to reference the interface template for description.

[0117] Specifically, the interface template is used to describe the physical interfaces provided by the devices in the system. The interfaces are used to provide information interaction between the devices and the software configuration items as well as information interaction between the devices. The interface template corresponds to the Interface class in the system architecture meta-model.

[0118] Exemplarily, the content of the interface template is shown in Table 11:

[0119] Table 11 Example of Interface Template

[0120]

[0121]

[0122] Among them, the Provider Device is identified by referencing the device template using the Device ID; the Connection field is identified by referencing the interface template using the InterfaceID; the Provided Resources are identified by referencing the hardware resource template using the ResourceID.

[0123] Specifically, the hardware resource template is used to describe the hardware resources in the system, and the hardware resources include computing resources, storage resources, and communication resources. The hardware resources correspond to the Resource class in the meta-model.

[0124] Exemplarily, the content of the hardware resource template is shown in Table 12:

[0125] Table 12 Example of Hardware Resource Template

[0126]

[0127]

[0128] Furthermore, a fault template is established according to the classes and attributes of the security meta-model.

[0129] Specifically, the fault template is used to describe the relevant information of faults in the system. This template can be divided into four parts, namely the basic fault information part, the fault detection part, the fault redundancy part, and the fault tolerance part. The basic information part corresponds to the Fault class in the security meta-model, and the fault detection template, the fault redundancy template, and the fault tolerance template correspond to the FaultDetection class, the FaultMitigation class, and the FaultTolerance class respectively.

[0130] Exemplarily, the content of the fault template is shown in Table 13, Table 14, Table 15, and Table 16:

[0131] Table 13 Example of Fault Template (Basic Information Part)

[0132]

[0133]

[0134] Table 14 Example of Fault Template (Fault Detection Part)

[0135]

[0136] Table 15 Example of Fault Template (Fault Redundancy Part)

[0137]

[0138] Table 16 Example of Fault Template (Fault Tolerance Part)

[0139]

[0140]

[0141] Among them, the sources of Fault Source can be divided into software configuration items, devices, and interfaces. Therefore, this field references the corresponding template through the software configuration item ID, device ID, or interface ID; the detection data field is used to describe the data to be detected and the data determination conditions for faults; the detection task is used to describe the process of fault detection and is identified by referencing the task template using the task ID.

[0142] Furthermore, the constraint rules of the requirement template include the options and syntax rules of the items to be filled in.

[0143] Furthermore, the requirement template contains several items to be filled in. Some of the items to be filled in only contain limited options, and a list is provided for the user to select from the limited options.

[0144] Exemplarily, the Device Type in the device template only includes five types of devices, namely control devices (used to calculate and control other devices, which obtain data from sensors for calculation and output the results to actuators for execution), sensors (devices with sensors that can obtain external data), actuators (actuators in the system, which are the output devices of the system), energy supply devices (devices such as batteries that provide the energy required for the system to operate), and measurement and storage devices (used to store and transmit data in the system); the five types of devices are placed in the corresponding list for the user to select.

[0145] Furthermore, the syntax rule is a statement including syntax structure, keywords, and items to be input.

[0146] Specifically, the items to be input contain constraint conditions.

[0147] Exemplarily, the Action interaction in Table 2 includes collecting data. The collecting data is to collect external data through the devices in the system, and its syntax rule is as follows:

[0148] DEVICE “device name” COLLECT DATA “data name”

[0149] Among them, DEVICE and COLLECT DATA are keywords, “device name” and “data name” are items to be input, and the order of this statement is its syntax structure. The statement obtained after the user inputs the items to be input is: DEVICE D01COLLECT DATA Data01. “D01” references the device with Device ID 1 in the device template by combining with the keyword DEVICE, and “Data01” references the data with Data Dictionary ID 1 in the data template by combining with the keyword COLLECT DATA.

[0150] Specifically, in step S4, when modeling each time, the modeling order of each entity is not fixed. It is necessary to determine the modeling order of the entity according to the requirements, and then call the corresponding requirement template and the constraint rules of the requirement template from the database according to the current modeling order, and perform modeling based on the restricted natural language according to the requirement template and the constraint rules of the requirement template.

[0151] Further, the modeling of the complex embedded system based on the restricted natural language according to the requirement template and the constraint rules of the requirement template includes:

[0152] For the to-be-filled items described in the restricted natural language in the requirement template, generate corresponding restricted natural language expressions according to the syntax rules of the requirement template constraint rules; each syntax rule corresponds to at least one restricted natural language expression; select the to-be-input items in the restricted natural language expression or input according to the constraint conditions of the to-be-input items;

[0153] For the to-be-filled items in the requirement template that only contain limited options, make a selection from the provided list;

[0154] For the to-be-filled items described in the natural language in the requirement template, perform free input;

[0155] When all the to-be-filled items in the requirement template are completed, the modeling is completed.

[0156] Exemplarily, the restricted natural language expressions generated by the syntax rules for collecting data are as follows:

[0157] <collectdata> ::＝ <devicecomponentid>"COLLECT” <dataid> {, <dataid>}

[0158] <devicecomponentid>::="Device" <id>

[0159] <dataid>::="DATA" <id>

[0160] Among them, each line is a restricted natural language expression, and the in the expressions of the second and third lines <id>Is the item to be input. In each two-line expression <id>Corresponding to the "device name" in the acquisition data syntax rules, the constraint is that only the device ID can be filled in; in every three lines of expressions <id>Corresponding to the "data name" in the acquisition data syntax rule, its constraint condition is that only the data dictionary ID can be filled in.

[0161] It can be understood that by extracting the attributes and their association relationships from multiple perspectives of the complex embedded system, the present invention establishes the requirement template of the system and the constraint rules for filling in the requirement template, and models the complex embedded system based on the restricted natural language, solving the problem of ambiguity in the modeling content when modeling the software requirements of the complex embedded system and improving the modeling quality.

[0162] Exemplarily, as Figure 6 shown, first, identify the software configuration items, devices, interfaces, and hardware resources in the complex embedded system, call the corresponding requirement template and the constraint rules of the requirement template from the database, and select or input the items to be filled in the requirement template, so as to establish a model corresponding to the system architecture; secondly, call the data template and the constraint rules of the data template, and select or input the items to be filled in the data template, so as to establish the data model in the system; thirdly, identify the tasks in the system, call the system task template and the constraint rules of the system task template, select or input the system tasks and the items to be filled in the corresponding real-time constraints and task processes of the tasks, call the system state template and the constraint rules of the system state template, and select or input the system states and the items to be filled in the migration relationships between the states, so as to complete the modeling of the system functional requirements, real-time requirements, system architecture and its traceability relationships; finally, identify the faults in the system, call the fault template and the constraint rules of the fault template, and select or input the faults, the propagation relationships between the faults, and the items to be filled in the corresponding security policies of the faults, so as to establish the fault model. By completing the modeling of the entities, the modeling of the software requirements of the complex embedded software is completed.

[0163] It can be understood that the present invention establishes a meta-model of the complex embedded system, establishes a requirement template through the classes and attributes of the meta-model, and models by calling the corresponding requirement template, solving the problem that there is no method for constructing a requirement model based on comprehensive requirement analysis for the complex embedded system at present. Moreover, by modeling by calling the corresponding requirement template, it is easy for developers to understand, reduces the difficulty of requirement modeling, and improves the efficiency and quality of requirement modeling.

[0164] Compared with the prior art, the beneficial effects of the complex embedded system requirement modeling method based on restricted natural language provided by the present invention are as follows:

[0165] 1. The present invention extracts the attributes and their association relationships from multiple perspectives of a complex embedded system to establish a requirement template for the system and the constraint rules for filling in the requirement template, and models the complex embedded system based on restricted natural language, solving the problem of ambiguity in the modeling content when modeling the software requirements of a complex embedded system and improving the modeling quality.

[0166] 2. The present invention establishes a meta-model for a complex embedded system, and establishes a requirement template through the classes and attributes of the meta-model, and performs modeling by calling the corresponding requirement template, solving the problem that there is currently no method for constructing a requirement model for a complex embedded system based on comprehensive requirement analysis.

[0167] 3. The present invention conducts domain analysis from four perspectives of the system architecture, functional requirements, real-time requirements, and security requirements of a complex embedded system, realizing the systematicness and comprehensiveness of the system requirement analysis, improving the correctness of requirement modeling, and improving the modeling quality.

[0168] 4. In view of the close interaction between software and hardware in a complex embedded system, the present invention extracts the entities, attributes and their association relationships of the complex embedded system to establish the meta-model of the system, so that the established meta-model includes the interaction relationships between entities; the system hardware architecture and software requirements are associated through the meta-models of functional requirements and real-time requirements, the system architecture meta-model, and the security requirements meta-model, thereby ensuring the association and matching between the system hardware architecture and software requirements.

[0169] 5. The present invention performs modeling by calling the corresponding requirement template, which is easy for developers to understand, reduces the difficulty of requirement modeling, and improves the efficiency and quality of requirement modeling.

[0170] Those skilled in the art can understand that all or part of the processes of implementing the method of the above embodiments can be completed by instructing relevant hardware through a computer program, and the program can be stored in a computer-readable storage medium. Among them, the computer-readable storage medium is a magnetic disk, an optical disk, a read-only memory or a random access memory, etc.

[0171] The above is only a preferred specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by those skilled in the art within the technical scope disclosed by the present invention should be covered by the protection scope of the present invention.< / id> < / id> < / id> < / id> < / dataid> < / id> < / devicecomponentid> < / dataid> < / dataid> < / devicecomponentid> < / collectdata>

Claims

1. A method for requirement modeling of a complex embedded system based on restricted natural language, characterized in that The method includes the following steps: Conduct a domain analysis on the complex embedded system, and extract the entities, attributes, and their association relationships in the system; Establish a meta-model of the complex embedded system based on the entities, attributes, and their association relationships, and store the meta-model in a database; the meta-model includes classes and attributes of the classes, and there are association relationships between the classes; Establish a requirements template according to the classes and attributes of the meta-model, and based on the entities, attributes, and their association relationships, establish the constraint rules of the requirements template, and store the requirements template and the constraint rules of the requirements template in the database; Determine the modeling order of the entities according to the software requirements, call the corresponding requirements template and the constraint rules of the requirements template from the database according to the modeling order, and model the complex embedded system based on the restricted natural language according to the requirements template and the constraint rules of the requirements template.

2. The method for modeling requirements of a complex embedded system based on restricted natural language according to claim 1, wherein The constraint rules of the requirements template include options of items to be filled and grammar rules.

3. The method for modeling requirements of a complex embedded system based on restricted natural language according to claim 2, wherein The requirements template contains several items to be filled, and some items to be filled only contain limited options, and a list is provided for the user to select from the limited options.

4. The method for modeling requirements of a complex embedded system based on restricted natural language according to claim 3, wherein The grammar rules are statements including grammar structures, keywords, and items to be input.

5. The method for modeling requirements of a complex embedded system based on restricted natural language according to claim 4, characterized in that, The modeling of the complex embedded system based on the restricted natural language according to the requirements template and the constraint rules of the requirements template includes: For the items to be filled described in the restricted natural language in the requirements template, generate corresponding restricted natural language expressions according to the grammar rules of the constraint rules of the requirements template; each grammar rule corresponds to at least one restricted natural language expression; select the items to be input in the restricted natural language expressions or input according to the constraint conditions of the items to be input; For the items to be filled that only contain limited options in the requirements template, select from the provided list; For the items to be filled described in the natural language in the requirements template, input freely; When all the items to be filled in the requirements template are completed, the modeling is completed.

6. The method for modeling requirements of a complex embedded system based on restricted natural language according to claim 1, characterized in that The meta-model is divided into a meta-model of functional requirements and real-time requirements, a meta-model of system architecture, and a meta-model of security requirements; the classes of the meta-model correspond to the entities or their attributes, the attributes of the classes of the meta-model correspond to the attributes of the entities, and the association relationships between the classes of the meta-model correspond to the association relationships of the entities and their attributes.

7. The method for modeling requirements of a complex embedded system based on restricted natural language according to claim 6, wherein, Establish a system task template and a system state template according to the classes and attributes of the meta-model of functional requirements and real-time requirements.

8. The method for modeling requirements of a complex embedded system based on restricted natural language according to claim 6, characterized in that Establish a data template, a software configuration item template, a device template, an interface template, and a hardware resource template according to the classes and attributes of the meta-model of system architecture.

9. The method for modeling requirements of a complex embedded system based on restricted natural language according to claim 6, characterized in that, Establish a fault template according to the classes and attributes of the security meta-model.

10. The method for modeling requirements of a complex embedded system based on restricted natural language according to claim 1, characterized in that, Conduct a domain analysis on the complex embedded system from four perspectives: system architecture, functional requirements, real-time requirements, and security requirements.

Images