Model verification method suitable for RUCM4CPS

Abstract

The invention relates to a model verification method suitable for RUCM4CPS, and belongs to the field of embedded system modeling. Comprising the following steps: extracting model components and attribute information of each component according to a model description file of RUCM4CPS to obtain a component attribute information mapping table; determining constraint conditions according to modeling requirements of the complex embedded system, and obtaining RUCM4CPS model verification rules based on the constraint conditions and attribute information of the components; according to the component modeling sequence, verifying all the components in sequence by using a verification rule; when each component is verified, a verification item corresponding to the component is obtained, attribute information corresponding to the component is obtained from the component attribute information mapping table, whether the attribute information meets the verification item or not is judged, and if the attribute information does not meet the verification item, a prompt is given. According to the method, the attribute of each component is verified according to the modeling sequence of the complex embedded system, and the problems that the current model verification is incomplete, the orderliness is poor, and the verification result lacks logicality are solved.

Description

Technical Field

[0001] The present invention relates to the field of embedded system modeling, and particularly to a model verification method applicable to RUCM4CPS. Background Art

[0002] Embedded systems are widely used in fields such as aerospace, medical devices, and transportation systems. Therefore, the reliability and security of embedded systems are of crucial importance. Conducting consistency verification on the system during the requirements modeling phase of the embedded system can discover potential security vulnerabilities and risks, and improve the reliability and security of the system.

[0003] Compared with other embedded systems, complex embedded systems have characteristics such as diverse task requirements and close software and hardware interaction. The complex embedded system usually realizes the normal operation of the system through the cooperation among multiple components. Therefore, during the requirements modeling phase of the complex embedded system, not only the correctness and integrity of the system need to be verified to ensure the correctness and integrity of each component of the system, but also the consistency of the system needs to be verified to ensure the consistency of the interaction among each component of the system.

[0004] Currently, existing model verification methods first do not analyze and classify according to the modular characteristics of complex embedded systems, resulting in incomplete verification; secondly, there is no regulation on the input granularity size, and usually all verification rules are used as inputs for verification, resulting in poor verification orderliness; thirdly, the verification results lack logic and cannot reflect the characteristics of complex embedded systems, and professional personnel are required to process the verification results to locate the problems existing in the model, consuming a large amount of manpower and reducing work efficiency. Therefore, in view of the characteristics of complex embedded systems, it is particularly important to provide a model verification method applicable to the system. Summary of the Invention

[0005] In view of the above analysis, the present invention aims to provide a model verification method applicable to RUCM4CPS to solve the problems of incomplete verification, poor orderliness, and lack of logic in the verification results of existing models.

[0006] The present invention provides a model verification method applicable to RUCM4CPS, and the method includes the following steps:

[0007] Extract model components and attribute information of each component from the model description file of RUCM4CPS to obtain a component attribute information mapping table;

[0008] Establish constraint conditions according to the modeling requirements of complex embedded systems, and obtain RUCM4CPS model verification rules based on the constraint conditions and the attribute information of the components;

[0009] Verify all components in sequence according to the component modeling order using the verification rules; wherein, when verifying each component, obtain the verification items corresponding to the component according to the verification rules, and obtain the attribute information corresponding to the component and the verification items from the component attribute information mapping table, and determine whether the attribute information meets the verification items. If not, give a prompt.

[0010] Further, the components include tasks, states, software configuration items, hardware resources, hardware devices, interfaces, data dictionaries, and faults.

[0011] Further, the constraint conditions include correctness, integrity, and consistency constraint conditions;

[0012] The correctness constraint conditions include task deadline correctness and software running device correctness; the integrity constraint conditions include component type integrity, task structure integrity, task modeling integrity, and resource configuration integrity; the consistency constraint conditions include software resource type consistency, task type consistency, and component reference consistency.

[0013] Further, the attribute information of a task includes: task name, parent task, child tasks, prerequisite tasks, successor tasks, system state where the task is located, whether it is a periodic task, whether it is an interrupt task, cycle length, interrupt trigger condition, task deadline, required hardware resources, required interfaces, and input data; the task deadline includes the best task deadline and the worst task deadline;

[0014] The attribute information of a state includes: state name, state type, tasks being executed in this state, and target state;

[0015] The attribute information of a software configuration item includes: software configuration item name, tasks involved in the software configuration item, corresponding device type, corresponding computing resource type, required hardware resources, required interfaces, input data, and output data;

[0016] The attribute information of a hardware resource includes: hardware resource name, resource type, resource configuration, number of cores, number of partitions, and transmission capacity; the resource type includes computing resources, storage resources, and transmission resources;

[0017] The attribute information of a hardware device includes: hardware device name, device type, tasks involved in the device, software configuration items deployed, hardware resources provided, and interfaces provided;

[0018] The attribute information of an interface includes: interface name, interface type, device providing the interface, connected interfaces, and hardware resources provided;

[0019] The attribute information of a data dictionary includes: data dictionary name and data dictionary data type;

[0020] The attribute information of the fault includes: fault name, fault source, fault type, probability of fault occurrence, severity of the fault, and precursor fault.

[0021] Furthermore, the verification rules include verification items and the components corresponding to the verification items; the verification items include correctness rules, integrity rules, and consistency rules;

[0022] The correctness rules include the verification of the correctness of the internal or inter-component logical relationships during the software requirements phase; the correctness of the internal logical relationships of the components includes the correctness of the task deadline; the correctness of the inter-component logical relationships includes the correctness of the task deadlines of subtasks and parent tasks, and the correctness of the device types corresponding to software configuration items;

[0023] The integrity rules include the verification of the integrity of component attribute information and task structure during the software requirements phase; the integrity of the component attribute information includes the integrity of component types, the integrity of the resource types of hardware resources, and the integrity of task attribute information;

[0024] The consistency rules include the verification of the consistency of hardware resource types, whether it is a periodic task or an interrupt task, and the inter-component reference relationships.

[0025] Furthermore, the components corresponding to the correctness rules are tasks and software configuration items; the verification of the correctness rules specifically includes:

[0026] Judging whether the best task deadline of the task satisfies being less than or equal to its worst task deadline, and judging whether the worst task deadline of the task satisfies being greater than or equal to the worst task deadlines of all its subtasks;

[0027] Judging whether the device type corresponding to the software configuration item is a control device, a sensor, or a measurement and storage device.

[0028] Furthermore, the components corresponding to the integrity rules are tasks, states, hardware resources, hardware devices, interfaces, data dictionaries, and faults; the verification of the integrity rules specifically includes:

[0029] Judging whether the task is set with at least one of a predecessor task and a successor task, and judging whether the task is set as a periodic task, an interrupt task, and a task deadline;

[0030] Judging whether the state is set with a state type;

[0031] Determine whether the hardware resource has a resource type set; for the resource type of the obtained hardware resource, if it is a computing resource, determine whether its core count is not 0, if it is a storage resource, determine whether its partition count is not 1, and if it is a transmission resource, determine whether its transmission capacity is not empty;

[0032] Determine whether the hardware device has a device type set;

[0033] Determine whether the interface has an interface type set;

[0034] Determine whether the data dictionary has a data type set;

[0035] Determine whether the fault has a fault type set.

[0036] Furthermore, the components corresponding to the consistency rules are tasks, states, software configuration items, hardware devices, interfaces, and faults; the verification of the consistency rules specifically includes:

[0037] Determine whether the task is a periodic task. If it is a periodic task, determine whether the task has a period length set; determine whether the task is an interrupt task. If it is an interrupt task, determine whether the task has an interrupt trigger condition set;

[0038] Determine whether the computing resource type corresponding to the software configuration item is a computing resource;

[0039] Search for and traverse the reference fields in the component attribute information mapping table, and determine whether the component name referred to by the reference field exists.

[0040] Furthermore, the reference fields include:

[0041] The system state in which the task is located, the parent task, the child task, the pre-task, the successor task, the required hardware resource, the required interface, and the input data in the task attribute information;

[0042] The tasks being executed in this state and the target state in the state attribute information;

[0043] The tasks involved in the software configuration item, the corresponding device type, the corresponding computing resource type, the required hardware resource, the required interface, the input data, and the output data in the software configuration item attribute information;

[0044] The tasks involved in the device, the deployed software configuration item, the provided hardware resource, and the provided interface in the hardware device attribute information;

[0045] The device providing the interface, the connected interface, and the provided hardware resource in the interface attribute information;

[0046] The fault source and the precursor fault in the fault attribute information.

[0047] Furthermore, the parent task includes a number of subtasks. The prerequisite task of the first subtask of the parent task is the parent task itself, and the successor task of the last subtask of the parent task is the parent task itself.

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

[0049] 1. By analyzing the architecture of the complex embedded system model, the association relationships between various components, and the attributes of the components, the present invention classifies and refines the verification rules for the verification of each component and its attributes, making the verification rules specific, standardized, and precise, thereby making the model verification complete.

[0050] 2. The present invention verifies all components in sequence according to the modeling order of the components of the complex embedded system model, ensuring that all components in the model are verified, thereby making the model verification systematic and complete.

[0051] 3. The present invention outputs the verification results in units of components, making the verification results consistent with the verification process, and prompting the component attribute information that does not meet the verification items, without the need for manual analysis of the verification results, so that problems can be quickly located. Therefore, while making the verification results logical, the work efficiency is improved.

[0052] In the present invention, the above technical solutions can also be combined with each other to achieve more preferred combination solutions. 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 achieved and obtained through the content specifically pointed out in the specification and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0054] Figure 1 It is a flowchart of the model verification method applicable to RUCM4CPS in an embodiment of the present invention;

[0055] Figure 2 It is a flowchart of component verification in an embodiment of the present invention;

[0056] Figure 3 It is a flowchart of software configuration item verification in an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0057] The preferred embodiments of the present invention will be specifically described below 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 principles of the present invention, rather than to limit the scope of the present invention.

[0058] A specific embodiment of the present invention discloses a model verification method applicable to RUCM4CPS. As Figure 1 shown, the method includes the following steps:

[0059] Step S1: Extract model components and the attribute information of each component from the model description file of RUCM4CPS to obtain a component attribute information mapping table;

[0060] Step S2: Establish constraint conditions according to the modeling requirements of complex embedded systems, and obtain RUCM4CPS model verification rules based on the constraint conditions and the attribute information of the components;

[0061] Step S3: Verify all components in turn using the verification rules according to the component modeling order; among them, when verifying each component, obtain the verification items corresponding to the component according to the verification rules, and obtain the attribute information corresponding to the component and the verification items from the component attribute information mapping table, and judge whether the attribute information meets the verification items. If not, a prompt will be given.

[0062] Specifically, in step S1, RUCM4CPS (Restricted Use Case Model for Cyber-Physical System) is a modeling method specifically applied to complex embedded systems. The model established based on RUCM4CPS contains several components, and there are corresponding association relationships between the components. Each component contains corresponding attribute information.

[0063] Specifically, the model description file of RUCM4CPS is the model description file in the software requirements phase. The component attribute information mapping table is a one-to-many mapping relationship between the component and its corresponding attribute information. Extract the components and their corresponding attribute information from the RUCM4CPS model description file (XML format) and store them in the component attribute information mapping table.

[0064] Furthermore, the components include tasks, states, software configuration items, hardware resources, hardware devices, interfaces, data dictionaries, and faults.

[0065] Furthermore, the attribute information of the task includes: task name, parent task, child tasks, prerequisite tasks, successor tasks, system status where the task is located, whether it is a periodic task, whether it is an interrupt task, cycle length, interrupt trigger condition, task deadline, required hardware resources, required interfaces, input data; the task deadline includes the best task deadline and the worst task deadline;

[0066] The attribute information of the status includes: status name, status type, tasks being executed in this status, target status;

[0067] The attribute information of the software configuration item includes: software configuration item name, tasks involved in the software configuration item, corresponding device type, corresponding operation resource type, required hardware resources, required interfaces, input data, output data;

[0068] The attribute information of the hardware resources includes: hardware resource name, resource type, resource configuration, number of cores, number of partitions, transmission capacity; the resource type includes operation resources, storage resources, and transmission resources;

[0069] The attribute information of the hardware device includes: hardware device name, device type, tasks involved in the device, deployed software configuration items, provided hardware resources, provided interfaces;

[0070] The attribute information of the interface includes: interface name, interface type, device providing the interface, connected interfaces, provided hardware resources;

[0071] The attribute information of the data dictionary includes: data dictionary name, data dictionary data type;

[0072] The attribute information of the fault includes: fault name, fault source, fault type, probability of fault occurrence, severity of the fault, precursor fault.

[0073] Specifically, in step S2, the constraint conditions include correctness, integrity, and consistency constraint conditions;

[0074] The correctness constraint conditions include task deadline correctness and software running device correctness; the integrity constraint conditions include component type integrity, task structure integrity, task modeling integrity, and resource configuration integrity; the consistency constraint conditions include software resource type consistency, task type consistency, and component reference consistency.

[0075] Furthermore, the verification rules include verification items and components corresponding to the verification items; the verification items include correctness rules, integrity rules, and consistency rules;

[0076] The correctness rules include the verification of the correctness of the internal or inter-component logical relationships during the software requirements phase; the correctness of the internal logical relationships of the components includes the correctness of the task deadlines; the correctness of the inter-component logical relationships includes the correctness of the task deadlines of subtasks and parent tasks, and the correctness of the device types corresponding to the software configuration items.

[0077] The integrity rules include the verification of the integrity of the component attribute information and the task structure during the software requirements phase; the integrity of the component attribute information includes the integrity of the component type, the integrity of the resource types of the hardware resources, and the integrity of the task attribute information.

[0078] The consistency rules include the verification of the consistency of the hardware resource types, whether it is a periodic task or an interrupt task, and the inter-component reference relationships.

[0079] Furthermore, the parent task contains several subtasks. The prerequisite task of the first subtask of the parent task is the parent task, and the successor task of the last subtask of the parent task is the parent task.

[0080] Exemplarily, the correctness rules for the correctness constraint condition "correctness of the software running device" are formulated through the following steps:

[0081] Extract the corresponding model component "software configuration item" according to the constraint condition "correctness of the software running device";

[0082] Based on the constraint condition and the model component "software configuration item", locate the corresponding component attribute information "corresponding device type";

[0083] Formulate the correctness rules for the software configuration item based on the attribute information.

[0084] It can be understood that based on the constraint conditions and the attribute information of the components, the constraint conditions are mapped to specific components and their specific attribute information, so as to obtain the model verification rules corresponding to the component attribute information. By analyzing the architecture of the complex embedded system model, the association relationships between various components, and the attributes of the components, the present invention classifies and refines the verification rules for the verification of each component and its attributes, making the verification rules specific, standardized, and precise, so that the model verification has completeness.

[0085] Specifically, in step S3, as Figure 2 shown, according to the modeling order of the components during the modeling of the complex embedded system, all components are verified in turn using the verification rules.

[0086] It can be understood that the RUCM4CPS model includes eight components. Each time when modeling, the modeling order of each component is not fixed. It is necessary to determine the modeling order of the components according to the requirements, and then determine the verification order of the components according to the current modeling order. The present invention verifies all components in sequence according to the modeling order of the components of the complex embedded system model, ensuring that all components in the model are verified, so that the model verification is organized and complete. Moreover, the verification rules can be integrated into the RUCM4CPS modeling tool, so as to perform verification in an automated manner during the modeling process, and timely discover whether there are problems with the correctness, integrity, and consistency of the components built in the model during the modeling, improving the modeling efficiency and accuracy.

[0087] Specifically, when verifying each component, since the verification items corresponding to each component are one or more of the correctness rule, integrity rule, and consistency rule, it is necessary to verify according to the verification items corresponding to each component respectively. According to the component attribute information corresponding to the verification item of each component, the attribute information corresponding to the component and the verification item is obtained from the component attribute information mapping table.

[0088] Further, the components corresponding to the correctness rule are tasks and software configuration items; the verification of the correctness rule specifically includes:

[0089] Judging whether the best task deadline of the task satisfies being less than or equal to its worst task deadline, and judging whether the worst task deadline of the task satisfies being greater than or equal to the worst task deadlines of all its subtasks;

[0090] Judging whether the device type corresponding to the software configuration item is a control device, a sensor, or a measurement and storage device.

[0091] Further, the components corresponding to the integrity rule are tasks, states, hardware resources, hardware devices, interfaces, data dictionaries, and faults; the verification of the integrity rule specifically includes:

[0092] Judging whether the task is set with at least one of a pre-task and a successor task, and judging whether the task is set as a periodic task, an interrupt task, and a task deadline;

[0093] Judging whether the state is set with a state type;

[0094] Judging whether the hardware resource is set with a resource type; for the obtained resource type of the hardware resource, if it is an operation resource, judging whether its core number is not 0, if it is a storage resource, judging whether its partition number is not 1, and if it is a transmission resource, judging whether its transmission capacity is not empty;

[0095] Judging whether the hardware device is set with a device type;

[0096] Determine whether the interface type is set for the said interface;

[0097] Determine whether the data type is set for the said data dictionary;

[0098] Determine whether the fault type is set for the said fault.

[0099] Furthermore, the components corresponding to the consistency rules are tasks, states, software configuration items, hardware devices, interfaces and faults; the verification of the consistency rules specifically includes:

[0100] Determine whether the task is a periodic task, and if it is a periodic task, determine whether the task has a set periodic length; determine whether the task is an interrupt task, and if it is an interrupt task, determine whether the task has a set interrupt trigger condition;

[0101] Determine whether the operation resource type corresponding to the said software configuration item is an operation resource;

[0102] Search and traverse the reference fields in the component attribute information mapping table, and determine whether the component name referred to by the said reference field exists.

[0103] Furthermore, the said reference fields include:

[0104] The system state where the task is located, the parent task, the child task, the pre-task, the successor task, the required hardware resources, the required interfaces, and the input data in the task attribute information;

[0105] The tasks being executed in this state and the target state in the state attribute information;

[0106] The tasks involved in the software configuration item, the corresponding device type, the corresponding operation resource type, the required hardware resources, the required interfaces, the input data, and the output data in the software configuration item attribute information;

[0107] The tasks involved in the device, the software configuration item deployed, the hardware resources provided, and the interfaces provided in the hardware device attribute information;

[0108] The device providing the interface, the connected interface, and the hardware resources provided in the interface attribute information;

[0109] The fault source and the precursor fault in the fault attribute information.

[0110] Exemplarily, the RUCM4CPS model sequentially includes software configuration items, tasks and hardware resource components according to the modeling order. First, as Figure 3As shown in the figure, the software configuration items are verified for correctness rules and consistency rules. For each verification item of the current software configuration item, if the conditions of the verification item are met, no record is made and no prompt is given; otherwise, the verification result of the verification item is recorded and a prompt is given; all verification items of the software configuration item are verified in turn. After the current software configuration item is verified, the task is verified for correctness rules, integrity rules, and consistency rules. Finally, the hardware resources are verified for integrity rules, and all the recorded results are output.

[0111] Specifically, when verifying each component, for each verification item of the component, it is judged whether the attribute information of the component meets the conditions of the verification item. If not, the verification result is recorded and a prompt is given. The verification result includes the corresponding component name, the attribute information of the component, and the error content.

[0112] It can be understood that the present invention outputs the verification results in units of components, making the verification results consistent with the verification process, prompting the component attribute information that does not meet the verification items, and eliminating the need for manual analysis of the verification results, thereby enabling quick problem location. Therefore, while making the verification results logical, the work efficiency is improved.

[0113] Compared with the prior art, the beneficial effects of the model verification method applicable to RUCM4CPS provided by the present invention are as follows:

[0114] 1. By analyzing the architecture of the complex embedded system model, the association relationships between various components, and the attributes of the components, the present invention classifies and refines the verification rules for the verification of each component and its attributes, making the verification rules specific, standardized, and precise, thereby making the model verification complete.

[0115] 2. The present invention verifies all components in turn according to the modeling order of the components of the complex embedded system model, ensuring that all components in the model are verified, thereby making the model verification systematic and complete.

[0116] 3. The present invention outputs the verification results in units of components, making the verification results consistent with the verification process, prompting the component attribute information that does not meet the verification items, and eliminating the need for manual analysis of the verification results, thereby enabling quick location of the problematic components. Therefore, while making the verification results logical, the work efficiency is improved.

[0117] 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, an optical disk, a read-only memory, or a random access memory, etc.

[0118] As described above, it 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 within the protection scope of the present invention.

Claims

1. A model verification method applicable to RUCM4CPS, characterized in that, The method includes the following steps: Extract model components and the attribute information of each component from the model description file of RUCM4CPS to obtain a component attribute information mapping table; Establish constraint conditions according to the modeling requirements of complex embedded systems, and obtain RUCM4CPS model verification rules based on the constraint conditions and the attribute information of components; Verify all components in sequence using the verification rules according to the component modeling order; wherein, when verifying each component, obtain the verification items corresponding to the component according to the verification rules, and obtain the attribute information corresponding to the component and the verification items from the component attribute information mapping table, and judge whether the attribute information meets the verification items. If not, give a prompt.

2. The model verification method applicable to RUCM4CPS according to claim 1, characterized in that The components include tasks, states, software configuration items, hardware resources, hardware devices, interfaces, data dictionaries, and faults.

3. The model verification method applicable to RUCM4CPS according to claim 1, wherein The constraint conditions include correctness, integrity, and consistency constraint conditions; The correctness constraint conditions include task deadline correctness and software running device correctness; the integrity constraint conditions include component type integrity, task structure integrity, task modeling integrity, and resource configuration integrity; the consistency constraint conditions include software resource type consistency, task type consistency, and component reference consistency.

4. The model verification method applicable to RUCM4CPS according to claim 2, wherein The attribute information of a task includes: task name, parent task, child tasks, predecessor tasks, successor tasks, system state where the task is located, whether it is a periodic task, whether it is an interrupt task, period length, interrupt trigger condition, task deadline, required hardware resources, required interfaces, input data; the task deadline includes the best task deadline and the worst task deadline; The attribute information of a state includes: state name, state type, tasks being executed in this state, target state; The attribute information of a software configuration item includes: software configuration item name, tasks involved in the software configuration item, corresponding device type, corresponding computing resource type, required hardware resources, required interfaces, input data, output data; The attribute information of a hardware resource includes: hardware resource name, resource type, resource configuration, number of cores, number of partitions, transmission capacity; the resource type includes computing resources, storage resources, and transmission resources; The attribute information of a hardware device includes: hardware device name, device type, tasks involved in the device, software configuration items deployed on it, hardware resources provided by it, interfaces provided by it; The attribute information of an interface includes: interface name, interface type, device providing the interface, connected interfaces, hardware resources provided by it; The attribute information of a data dictionary includes: data dictionary name, data dictionary data type; The attribute information of a fault includes: fault name, fault source, fault type, probability of fault occurrence, severity of the fault, predecessor fault.

5. The model verification method applicable to RUCM4CPS according to claim 4, characterized in that The verification rules include verification items and components corresponding to the verification items; the verification items include correctness rules, integrity rules, and consistency rules; The correctness rules include the verification of the correctness of the internal or inter-component logical relationships during the software requirements phase; the correctness of the internal logical relationships of the components includes the correctness of the task deadline; the correctness of the inter-component logical relationships includes the correctness of the task deadlines of subtasks and parent tasks, and the correctness of the device types corresponding to software configuration items. The integrity rules include the verification of the integrity of component attribute information and task structure during the software requirements phase; the integrity of the component attribute information includes the integrity of component types, the integrity of resource types of hardware resources, and the integrity of task attribute information. The consistency rules include the verification of the consistency of hardware resource types, whether it is a periodic task or an interrupt task, and the inter-component reference relationships.

6. The model verification method applicable to RUCM4CPS according to claim 5, wherein The components corresponding to the correctness rules are tasks and software configuration items; the verification of the correctness rules specifically includes: Judging whether the optimal task deadline of the task satisfies being less than or equal to its worst task deadline, and judging whether the worst task deadline of the task satisfies being greater than or equal to the worst task deadlines of all its subtasks. Judging whether the device type corresponding to the software configuration item is a control device, a sensor, or a measurement and storage device.

7. The model verification method applicable to RUCM4CPS according to claim 5, wherein The components corresponding to the integrity rules are tasks, states, hardware resources, hardware devices, interfaces, data dictionaries, and faults; the verification of the integrity rules specifically includes: Judging whether the task sets at least one of a pre-task and a post-task, and judging whether the task sets whether it is a periodic task, whether it is an interrupt task, and the task deadline. Judging whether the state sets the state type. Judging whether the hardware resource sets the resource type; for the obtained resource type of the hardware resource, if it is a computing resource, judging whether its core number is not 0, if it is a storage resource, judging whether its partition number is not 1, and if it is a transmission resource, judging whether its transmission capacity is not empty. Judging whether the hardware device sets the device type. Judging whether the interface sets the interface type. Judging whether the data dictionary sets the data type. Judging whether the fault sets the fault type.

8. The model verification method applicable to RUCM4CPS according to claim 5, characterized in that, The components corresponding to the consistency rules are tasks, states, software configuration items, hardware devices, interfaces, and faults; the verification of the consistency rules specifically includes: Judging whether the task is a periodic task, and if it is a periodic task, judging whether the task sets the period length; judging whether the task is an interrupt task, and if it is an interrupt task, judging whether the task sets the interrupt trigger condition. Judging whether the operation resource type corresponding to the software configuration item is an operation resource. Searching and traversing the reference fields in the component attribute information mapping table, and judging whether the component name referred to by the reference field exists.

9. The model verification method applicable to RUCM4CPS according to claim 8, characterized in that, The reference fields include: The system state where the task is located, the parent task, the subtask, the pre-task, the post-task, the required hardware resources, the required interfaces, and the input data in the task attribute information. The tasks being executed in this state and the target state in the state attribute information. Tasks involved in the software configuration item in the software configuration item attribute information, corresponding device types, corresponding computing resource types, required hardware resources, required interfaces, input data, output data; Tasks involved in the device in the hardware device attribute information, deployed software configuration items, provided hardware resources, provided interfaces; Devices providing interfaces in the interface attribute information, connected interfaces, provided hardware resources; Fault sources and predecessor faults in the fault attribute information.

10. The model verification method applicable to RUCM4CPS according to claim 5, characterized in that, The parent task contains several subtasks. The predecessor task of the first subtask of the parent task is the parent task, and the successor task of the last subtask of the parent task is the parent task.

Images