Complex embedded system software requirement modeling method based on multi-domain knowledge

Abstract

The invention relates to a complex embedded system software requirement modeling method based on multi-domain knowledge, and belongs to the field of embedded system modeling. The method comprises the following steps that domain analysis is conducted on the complex embedded system from the four aspects of system architecture, function requirements, real-time requirements and safety requirements, entities, attributes and the incidence relation of the entities and the attributes in the system are extracted, and a meta-model of the complex embedded system is established; establishing a demand template according to the class of the meta-model and the attribute of the class; and according to the modeling sequence, calling the corresponding demand template to model the complex embedded system. According to the method, the meta-model and the demand template are established by extracting entities, attributes and association relationships of the complex embedded system from multiple angles, so that modeling is performed, and the problem that a method for constructing the demand model based on comprehensive demand analysis for the complex embedded system does not exist at present is solved.

Description

Technical Field

[0001] The present invention relates to the modeling of embedded systems, and particularly to a method for modeling software requirements of complex embedded systems based on multi-domain knowledge. 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 realizes the perception of external physical data through various sensors and the transmission of data through the network. Compared with other embedded systems, a complex embedded system has the characteristics of diverse task requirements and close software-hardware interaction. Therefore, the system often has a large 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 charts are used to make the document content easier to understand. Since there are a large number of software and hardware entities in a complex embedded system and a huge amount of interaction information between entities, multiple requirement documents are needed to complete the complete requirement analysis, which is prone to inconsistency between documents, and it is difficult to analyze the traceability relationship between entities and is not conducive to users' understanding of the documents. Second, based on semi-formal modeling languages, which are represented by UML, SysML, and BPMN and have a graphical interface. Users can complete modeling by describing the attributes and relationships of graphical components. However, the semi-formal modeling languages focus on generality, while a complex embedded system needs to consider various requirements, so that this method cannot accurately depict the domain characteristics of complex embedded systems and cannot systematically and comprehensively conduct 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 formal models. 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 real-time performance and security of the system, resulting in that this method not only requires the support of formal experts, but also has a large modeling difficulty and only focuses 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 conduct requirement analysis. Therefore, in view of the characteristics of complex embedded systems, it is very necessary to provide a method for modeling software requirements of complex embedded systems based on multi-domain knowledge. Summary of the Invention

[0005] In view of the above analysis, the present invention aims to provide a method for modeling software requirements of a complex embedded system based on multi-domain knowledge, so as to solve the problem that there is currently no method for constructing a requirements model for a complex embedded system based on comprehensive requirements analysis.

[0006] The present invention provides a method for modeling software requirements of a complex embedded system based on multi-domain knowledge, and the method includes the following steps:

[0007] Conduct domain analysis on the complex embedded system from four perspectives: system architecture, functional requirements, real-time requirements, and security requirements, 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 classes in the meta-model and store the requirements template in the database;

[0010] Determine the modeling order of the entities according to the software requirements, and call the corresponding requirements template from the database according to the modeling order to model the complex embedded system.

[0011] Further, 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.

[0012] Further, the entities include system tasks, system states, data, software configuration items, devices, interfaces, hardware resources, and faults; each entity corresponds to a requirements template respectively.

[0013] Further, the requirements template includes several items to be filled in; select the classes and attributes of the corresponding meta-model according to the category of the requirements template, and use the classes and attributes of the corresponding meta-model as the items to be filled in the requirements template, so as to construct the requirements template.

[0014] Further, the entities corresponding to the meta-model of functional requirements and real-time requirements include system tasks, system states, and data.

[0015] Further, the entities corresponding to the meta-model of system architecture include software configuration items, devices, interfaces, hardware resources, and data.

[0016] Further, the entities corresponding to the meta-model of security requirements include faults, software configuration items, devices, interfaces, and system tasks.

[0017] Furthermore, system task templates and system status templates are established according to the classes and attributes of the functional requirement and real-time requirement meta-models.

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

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

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

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

[0022] 2. 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, realizes the systematicness and comprehensiveness of the system requirement analysis, improves the correctness of requirement modeling, and improves the quality of modeling.

[0023] 3. In view of the close interaction between software and hardware in a complex embedded system, the present invention extracts 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 functional requirement and real-time requirement meta-model, system architecture meta-model, and security requirement meta-model, thereby ensuring the association and matching between the system hardware architecture and software requirements.

[0024] 4. The present invention performs modeling by calling the 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.

[0025] In the present invention, the above technical solutions can also be combined with each other to achieve more preferred combined solutions. Other features and advantages of the present invention will be described in the subsequent description, and some advantages can be made obvious from the description, 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 description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The drawings are only for the purpose of illustrating specific embodiments and are not considered to be a limitation of the present invention. Throughout the drawings, the same reference numerals represent the same components.

[0027] Figure 1 This is a flowchart of the method for modeling software requirements of a complex embedded system based on multi-domain knowledge in an embodiment of the present invention;

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

[0029] Figure 3 This is a schematic diagram of the meta-model of functional requirements and real-time requirements in an embodiment of the present invention;

[0030] Figure 4 This is a schematic diagram of the meta-model of the system architecture in an embodiment of the present invention;

[0031] Figure 5 This is a schematic diagram of the meta-model of security requirements in an embodiment of the present invention;

[0032] Figure 6 This is a schematic diagram of software requirement modeling in an embodiment of the present invention. Detailed implementation manners

[0033] Next, the preferred embodiments of the present invention will be specifically described with reference to the accompanying drawings. The accompanying drawings form a part of this application and are used together with the embodiments of the present invention to explain the principle of the present invention, rather than to limit the scope of the present invention.

[0034] A specific embodiment of the present invention discloses a method for modeling software requirements of a complex embedded system based on multi-domain knowledge. As Figure 1 shown, the method includes the following steps:

[0035] Step S1: Perform domain analysis on the complex embedded system from four perspectives of system architecture, functional requirements, real-time requirements, and security requirements, and extract entities, attributes, and their association relationships in the system;

[0036] 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;

[0037] Step S3: Establish a requirement template according to the classes and attributes of the meta-model and store the requirement template in the database;

[0038] Step S4: Determine the modeling order of the entities according to the software requirements, and call the corresponding requirement templates from the database according to the modeling order to model the complex embedded system.

[0039] Specifically, in step S1, domain analysis is performed on the complex embedded system architecture to extract the software and hardware in the system architecture; the software and hardware are classified, and the functions, attributes, the association relationships and constraints between the software and hardware are extracted. The constraint is the requirement for the normal operation of the software and hardware in the system.

[0040] It can be understood that complex embedded systems have various application fields, such as aerospace, automotive, medical and other fields. Each field has different software and hardware requirements, different functional and real-time requirements, and different faults, and domain analysis needs to be carried out according to the specific application field of the system.

[0041] Domain analysis is performed on the functions and real-time requirements of the complex embedded system to extract the tasks of the system and their attributes; the tasks and their attributes are analyzed to 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. A task can correspond to multiple previous tasks, next tasks, father tasks, and child tasks respectively. The pre-task of the first child task of the father task is the father task, and the post-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 constraint of the task is the interaction process and constraint between the associated entities during the task execution process.

[0042] Research and induction are carried out on the common faults of the complex embedded system to extract the attributes of the faults and their propagation relationships; the propagation relationship is the triggering relationship between the faults; domain analysis is performed on the security requirements and design of the complex embedded system to 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; one fault can correspond to multiple security policies, and one security policy corresponds to one task.

[0043] 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 to return the system to a normal state after the fault occurs. 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.

[0044] It is understandable that due to the large scale and complex structure of complex embedded systems, the occurrence of single or multiple faults may cause other faults to occur, thus making the system 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 that of general system tasks. The fault detection policy is executed under specific conditions to detect faults in the system, the fault redundancy policy is executed under specific conditions to reduce the probability of system faults, and the fault tolerance policy is executed after a fault occurs to make the system return to a safe state as soon as possible.

[0045] Furthermore, the entities include system tasks, system states, data, software configuration items, devices, interfaces, hardware resources, and faults.

[0046] Specifically, each entity has corresponding attribute information. The attribute information of the system task 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, input data. The attribute information of the state includes: state name, trigger condition, tasks being executed in this state, target state. The attribute information of the data includes: corresponding data dictionary name, data type, data definition. The attribute information of the software configuration item includes: software configuration item name, tasks involved in the software configuration item, corresponding device type, required hardware resources, required interfaces, input data, output data. The attribute information of the device includes: device name, device type, tasks involved in the device, deployed software configuration items, provided hardware resources, provided interfaces. The attribute information of the interface includes: interface name, interface type, interface mode, device providing the interface, connected interfaces, transmission protocol, transmission direction, provided hardware resources. The attribute information of the hardware resource includes: hardware resource name, resource type, resource configuration. The attribute information of the fault includes: fault name, fault source, fault type, probability of fault occurrence, severity of the fault, precursor faults.

[0047] It is understandable that the present invention conducts domain analysis from four perspectives of the system architecture, functional requirements, real-time requirements, and security requirements of complex embedded systems, realizes the systematicness and comprehensiveness of the system requirements analysis, improves the correctness of requirement modeling, and improves the quality of modeling.

[0048] 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.

[0049] The relationship between the entities is as follows Figure 2 shown. Among them, system tasks, system status, and data correspond to the functional requirements of the system. The system tasks include the interaction processes between various 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 cause changes in the system status. 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 relationship 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 a fault occurs and execute corresponding task processes.

[0050] Furthermore, the entities corresponding to the functional requirements and the real-time requirements meta-model include system tasks, system status, and data.

[0051] Specifically, as follows Figure 3As shown, in the functional requirement and real-time requirement meta-model, 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, and 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 flow of the system (ActionSentence), and each action flow 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.

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

[0053] (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.

[0054] (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.

[0055] (3) SetDataSentence class: Describes the data setting action in the system interaction process. This action is completed by the Actor in the system, that is, the software configuration item or device. Among them, DataName describes the data to be assigned, corresponding to Data in the system architecture meta-model; Value describes the value to be assigned.

[0056] (4) SendDataSentence class: Describes the data sending action in the system interaction process. This action is completed by the software configuration item 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 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.

[0057] (5) ReceiveDataSentence class: Describes the data receiving action in the system interaction process. This action is completed by the software configuration item 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 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.

[0058] (6) DelaySentence class: Describes the delay operation in the system interaction process. This action is completed by the Actor in the system, that is, the software configuration item or device. 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.

[0059] Furthermore, the entities corresponding to the system architecture meta-model include software configuration items, devices, interfaces, hardware resources, and data.

[0060] Specifically, such as Figure 4As shown, in the system architecture meta-model, software runs on devices and has certain operating requirements for hardware resources. Devices need to provide the hardware resources required for software operation and also need to provide interfaces to allow information interaction between devices and software. Devices can be classified into Storage (storage devices), Sensor (sensors), Actuator (actuators), EnergySupply (energy supply devices), Controller (control devices) according to their types; hardware resources can be classified into ComputingResource (computing resources), StorageResource (storage resources), TimerResource (clock resources), TransmissionResource (transmission resources); 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)), CommunicationInterface (data interaction interface, including interaction interface type (communicationType), transmission direction (transmissionDirection), interface address (interfaceAddress), 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).

[0061] Furthermore, the entities corresponding to the security requirements meta-model include faults, software configuration items, devices, interfaces, and system tasks.

[0062] Specifically, such as Figure 5As shown, in the security requirement meta-model, the previous fault references the names of other faults, which means other faults that may trigger this fault. Faults can occur on actors (i.e., software and devices) and interfaces. The corresponding security policies for faults include detected data (TargetData in fault detection), corresponding redundancy (MitigationMechanism in fault redundancy), and fault tolerance mechanisms (ToleranceMechanism in fault tolerance). And it is necessary to describe the tasks corresponding to the security policies by referring to task templates.

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

[0064] (1) Functional requirement and real-time requirement meta-model and system architecture meta-model: The two are associated through the action sentences (ActionSentence class in Figure 3 and Figure 4 ) in the functional requirement and real-time requirement meta-model. Action sentences are important contents in the functional requirement and real-time requirement. Each task class will correspond to an action process (CPSFlowOfEvents), and the action process is composed of a series of sequential action sentences. There are 8 types of action sentences, and entities in the architecture are referenced through the attributes in the 8 types of sentences (such as InputData, SoftwareName, etc.) (such as Actor (including Software and Device), Data, Interface in Figure 3 and Figure 4 ) to model the dynamic interaction process of the system architecture at the functional requirement level.

[0065] (2) Functional requirement and real-time requirement meta-model and security requirement meta-model: For faults in security requirements, clear fault detection mechanisms (FaultDetection in Figure 3 and Figure 6 ), fault redundancy mechanisms (FaultMitigation in Figure 3 and Figure 6 ), and fault tolerance mechanisms (FaultTolerance in Figure 3 and Figure 6 ) need to be defined. And each mechanism needs to describe the execution process of the mechanism by defining clear mechanism tasks (Task in Figure 3 and Figure 4 ) to clearly model the security mechanism of the system.

[0066] (3) System architecture meta - model and security requirement 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 Software in Figure 3 and Figure 5 Device in Figure 3 and Figure 5 Interface in). Therefore, the association between the two is reflected in that the definition of faults ( Figure 3 and Figure 6 Fault in

[0067] in the security requirements needs to be mapped to the level of the system architecture, so as to ensure a clear traceability relationship between the system security requirements and the system architecture.

[0068] Specifically, in step S3, the requirement template contains several items to be filled; select the classes and class attributes of the corresponding meta - model according to the category of the requirement template, and use the classes and class attributes of the corresponding meta - model as the items to be filled in the requirement template, so as to construct the requirement template.

[0069] 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.

[0070] Furthermore, establish the system task template and system state template according to the classes and class attributes of the functional requirement and real - time requirement meta - model.

[0071] 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 branched task process part. Each task corresponds to only one basic information part and one main task process part, while the branched task process part can be increased according to the number of branches in the main process. The branched 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 functional requirement and real-time requirement meta-models, the main task process corresponds to the CPSFlowOfEvents class, and the branched task process corresponds to the AlternativeFlow class.

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

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

[0074]

[0075]

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

[0077]

[0078]

[0079] Table 3 Example of System Task Description Template (Branched Task Process Part)

[0080]

[0081] Among them, self-inclusion of system tasks (i.e., the task itself is its own parent task or child task) is not allowed. 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 refers to the data template by using the DataDictionary ID. Main Timeline records the task steps of components or subtasks included in a task, while Alternative Timeline is the branched task steps in Main Timeline and needs to be executed in cooperation with the judgment conditions in Main Timeline. The Action field is used to describe the actions of components in the system task, and the Timing Relationship is used to describe the synchronization relationship between the steps in a task and the steps in other tasks.

[0082] Specifically, the system state template is used to describe the states of the system and the transition conditions between the 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 one state can contain multiple state transitions. The basic information part corresponds to the State class in the function requirement and real-time requirement meta-model, and the state transition part corresponds to the StateTransition class.

[0083] Exemplarily, the content of the system state template is shown in Tables 4 and 5:

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

[0085]

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

[0087]

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

[0089] Furthermore, data templates, software configuration item templates, device templates, interface templates, and hardware resource templates are established according to the classes and class attributes of the system architecture meta-model.

[0090] 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.

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

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

[0093]

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

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

[0096]

[0097]

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

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

[0100]

[0101] 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 referring to other data items. The Invariants field describes the constraint conditions on the value range that the data needs to satisfy during its life cycle.

[0102] 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.

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

[0104] Table 9 Example of Software Configuration Item Template

[0105]

[0106] 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 references the data template by using the DataDictionary ID.

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

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

[0109] Table 10 Example of Device Template

[0110]

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

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

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

[0114] Table 11 Example of Interface Template

[0115]

[0116] Among them, the Provider Device is identified by referring to the device template through the Device ID; the Connection field is identified by referring to the interface template through the InterfaceID; the Provided Resources are identified by referring to the hardware resource template through the ResourceID.

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

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

[0119] Table 12 Example of Hardware Resource Template

[0120]

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

[0122] 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.

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

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

[0125]

[0126] Table 14 Fault Template Example (Fault Detection Part)

[0127]

[0128] Table 15 Fault Template Example (Fault Redundancy Part)

[0129]

[0130]

[0131] Table 16 Fault Template Example (Fault Tolerance Part)

[0132]

[0133] Among them, the source 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.

[0134] It can be understood that the present invention is modeled by calling the 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.

[0135] Specifically, in step S4, the modeling order of each entity is not fixed each time of modeling. It is necessary to determine the modeling order of the entity according to the requirements, and then call the corresponding requirement template from the database according to the current modeling order for modeling.

[0136] 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 templates from the database, and fill in the attributes in the requirement templates to establish a model corresponding to the system architecture; secondly, call the data template and fill in the attributes in the data template to establish a data model in the system; thirdly, identify the tasks in the system, call the system task template, fill in the system tasks and the corresponding real-time constraints and task flow attributes of the tasks, call the system state template, and fill in the system states and the migration relationship attributes between the states to complete the modeling of the system functional requirements, real-time requirements, system architecture, and its traceability relationship; finally, identify the faults in the system, call the fault template, and fill in the faults, the propagation relationship between the faults, and the safety policy attributes corresponding to the faults to establish a fault model. By completing the modeling of the entities, the modeling of the software requirements of the complex embedded software is completed.

[0137] It can be understood that the present invention establishes a meta-model for complex embedded systems, establishes a requirements template through the classes and attributes of the meta-model, and performs modeling by calling the corresponding requirements template, solving the problem that there is currently no method for constructing a requirements model for complex embedded systems based on comprehensive requirements analysis.

[0138] Compared with the prior art, the beneficial effects of the method for modeling software requirements of complex embedded systems based on multi-domain knowledge provided by the present invention are as follows:

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

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

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

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

[0143] Those skilled in the art can understand that all or part of the processes of implementing the methods in 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, optical disk, read-only memory, or random access memory, etc.

[0144] 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.

Claims

1. A method for modeling software requirements of complex embedded systems based on multi-domain knowledge, characterized in that The method includes the following steps: Conduct domain analysis on the complex embedded system from four perspectives: system architecture, functional requirements, real-time requirements, and security requirements, and extract the entities, attributes, and their association relationships in the system; 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; Establish a requirements template according to the classes and attributes of the meta-model and store the requirements template in the database; Determine the modeling order of the entities according to the software requirements, and call the corresponding requirements template from the database according to the modeling order to model the complex embedded system.

2. The method for modeling software requirements of a complex embedded system based on multi-domain knowledge according to claim 1, wherein 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.

3. The method for modeling software requirements of a complex embedded system based on multi-domain knowledge according to claim 2, wherein The entities include system tasks, system states, data, software configuration items, devices, interfaces, hardware resources, and faults; each entity corresponds to a requirements template respectively.

4. The method for modeling software requirements of a complex embedded system based on multi-domain knowledge according to claim 3, characterized in that, The requirements template contains several items to be filled; select the classes and attributes of the corresponding meta-model according to the category of the requirements template, and use the classes and attributes of the corresponding meta-model as the items to be filled in the requirements template, so as to construct the requirements template.

5. The method for modeling software requirements of a complex embedded system based on multi-domain knowledge according to claim 2, characterized in that, The entities corresponding to the meta-model of functional requirements and real-time requirements include system tasks, system states, and data.

6. The method for modeling software requirements of a complex embedded system based on multi-domain knowledge according to claim 2, characterized in that The entities corresponding to the meta-model of system architecture include software configuration items, devices, interfaces, hardware resources, and data.

7. The method for modeling software requirements of a complex embedded system based on multi-domain knowledge according to claim 2, characterized in that, The entities corresponding to the meta-model of security requirements include faults, software configuration items, devices, interfaces, and system tasks.

8. The method for modeling software requirements of a complex embedded system based on multi-domain knowledge according to claim 3, characterized in that 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.

9. The method for modeling software requirements of a complex embedded system based on multi-domain knowledge according to claim 3, wherein 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.

10. The method for modeling software requirements of a complex embedded system based on multi-domain knowledge according to claim 3, wherein Establish a fault template according to the classes and attributes of the security meta-model.

Images