Model verification method for distributed systems suitable for sysml, simulink and aadl

Abstract

The application relates to a model verification method suitable for a distributed system of SysML, Simulink and AADL, and belongs to the technical field of system integration verification. The method comprises the following steps: according to model description files of SysML, Simulink and AADL, extracting model element sets and related attribute information respectively to obtain SysML, Simulink and AADL model information mapping tables; according to selected verification rules, obtaining required model elements and related attribute information from the SysML, Simulink and AADL model information mapping tables; according to the selected verification rules, verifying the obtained required model elements and related attribute information, if the verification is passed, no prompt information is generated; otherwise, it is prompted that the selected verification rules are not met, and a verification result is output. The application solves the problem that the consistency, real-time performance and safety of the design integration stage and the corresponding demand models and design models of each subsystem cannot be verified at present.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of system integration verification, and particularly relates to a model verification method for a distributed system based on SysML, Simulink and AADL. BACKGROUND

[0002] With the increase of the scale of a distributed system, the development process of the system generally involves the cooperation of multiple units. Each participating unit is responsible for the development of a certain module or a certain development stage of the system, so that the integrated system may have inconsistency between modules and inconsistency between stages. Therefore, the system obtained after integration will certainly have many inconsistency problems if not checked and verified. From the vertical level, there may be inconsistency between the design of a subsystem and the requirement of the subsystem, and between the requirement of the subsystem and the design of the system architecture. From the horizontal level, there may be problems that the subsystems cannot be integrated, and that the integrated system does not meet the requirements of safety and real-time.

[0003] From the perspective of system development, different modeling languages (such as SysML, AADL, etc.) may be used by each unit to construct the model of the corresponding subsystem or module. Due to the great differences in syntax, semantics and modeling methods between the multiple modeling languages, and the different domain knowledge involved in each subsystem or module, it is a difficult problem to extract necessary semantic information from the models based on different modeling languages. In addition, the entire system will have multiple levels of models, such as system architecture models, subsystem requirement models, subsystem design models, and various aspect-oriented model perspectives, such as functional models, safety models, real-time models, etc. This makes the semantic information extracted from the models very complex. If the information cannot be accurately extracted and processed according to the levels and different perspectives, the system verification at the model level will be ineffective. SUMMARY

[0004] In view of the above analysis, the present application aims to provide a model verification method for a distributed system based on SysML, Simulink and AADL, to solve the problem that the consistency, real-time and safety of the design integration stage and the requirement model and the design model of each subsystem cannot be verified at present.

[0005] The main purpose of the present application is achieved by the following technical solutions:

[0006] The application provides a model verification method for distributed systems of SysML, Simulink and AADL, comprising the following steps: extracting model element sets and related attribute information from model description files of SysML, Simulink and AADL respectively to obtain SysML, Simulink and AADL model information mapping tables; obtaining required model elements and related attribute information from the SysML, Simulink and AADL model information mapping tables according to selected verification rules; verifying the obtained required model elements and related attribute information according to the selected verification rules, and if the verification is passed, no prompt information is generated; otherwise, it is prompted that the selected verification rules are not met, and a verification result is output.

[0007] Further, the model description file of the AADL is a model description file of a system architecture design stage model, the model description file of the SysML is a model description file of a software requirement stage model, and the model description file of the Simulink is a model description file of a subsystem design stage model.

[0008] Further, the model elements include components, faults, interaction channels, exchange interfaces, tasks, states and state transitions; and the model information mapping table is a one-to-many mapping relationship between the model elements and related attribute information.

[0009] Further, the attribute information of the components includes ID, component name, component type, security level and worst execution time; the attribute information of the exchange interfaces includes ID, name, direction, communication protocol, period and data type of transmission; the attribute information of the tasks includes ID, worst execution time, deadline and a handled fault list; the attribute information of the states includes ID, worst execution time, Entry event, Do event, Exit event, whether a fault state and a corresponding fault type; the attribute information of the faults includes fault type and fault name; the state transitions include source state, destination state and event; and the interaction channels include ID, source port and destination port.

[0010] Further, the verification rules include consistency rules, real-time rules and security rules; the consistency rules include consistency verification of component-related attributes and interface-related attributes of models between system development stages and consistency verification of related attributes of interface data interaction of models within a system development stage; the real-time rules include verification of time attributes of components by models between system development stages and models within a system development stage, and the time attributes include worst execution time, period and deadline; and the security rules include verification of fault attributes by models between system development stages and models within a system development stage, and the fault attributes include fault level, fault handling and security level.

[0011] Further, the verification of the consistency rule specifically comprises:

[0012] Finding in the model element information mapping table whether there is a corresponding component between the software requirement stage and the subsystem design stage, if not, outputting that there is no corresponding subsystem component, if yes, traversing the interfaces of the software requirement stage component to find whether there is a corresponding interface with the subsystem design stage component, if not, outputting that the input and output interfaces of the components between the stages are inconsistent;

[0013] Finding in the model element information mapping table the components and interactive channels of the system architecture design stage, the software requirement stage and the subsystem design stage, and traversing the interactive channels of each model, finding the corresponding exchange interface in the interactive channel according to the attribute values of the source and the dest of the traversed interactive channel, and determining the consistency of the interface operation specification by comparing the consistency of the data types and the periods of the source and the dest;

[0014] Finding in the model element information mapping table the components and interactive channels of the software requirement stage, traversing the attribute values of the source and the dest of the interactive channel, and traversing the exchange interface contained by the component, finding the exchange interface corresponding to the attribute values of the source and the dest of the interactive channel, and comparing whether the combination of the in and out attributes of the source and the dest is consistent, if yes, outputting that the direction of the corresponding exchange interface between the components with message exchange is consistent;

[0015] Finding in the model element information mapping table the components and interactive channels of the system architecture design stage, the software requirement stage and the subsystem design stage, traversing the interactive channels of each model, finding the corresponding exchange interface in the interactive channel according to the attribute values of the source and the dest of the interactive channel, and outputting that the message variable name of the corresponding exchange interface between the components with message exchange is consistent by comparing whether the names of the source and the dest are consistent, if consistent;

[0016] Finding in the model element information mapping table and traversing the components of the software requirement stage, determining whether the current component has a subcomponent, if yes, finding the interface list of all the subcomponents of the current component, traversing the interface list of the current component, if there is a port not in the subcomponent list, outputting that the ports of the composite component and the subcomponent in the software requirement stage are inconsistent, if there is no port not in the subcomponent list, traversing the components of the subsystem design stage, and determining whether the current component has a subcomponent, if yes, finding the interface list of all the subcomponents of the current component, and traversing the interface list of the current component, if there is a port not in the subcomponent list, outputting that the ports of the composite component and the subcomponent in the subsystem design stage are inconsistent;

[0017] In the model element information mapping table, whether the corresponding components exist in the software requirement stage and the subsystem design stage is found, if not, it is output that no corresponding subsystem components exist, if yes, whether the type of the components in the subsystem and the software requirement stage is compared, if not, it is output that the component types between stages are inconsistent;

[0018] In the model element information mapping table, the components and the interactive channel of the software requirement stage are found, and the attribute values of the source and the dest of the interactive channel are traversed, and the exchange interface corresponding to the attribute values of the source and the dest of the interactive channel is found by traversing the components, and whether the protocols of the source and the dest are consistent is compared, if not, it is output that the communication protocols of the inter-stage interface corresponding to the interactive channel are inconsistent.

[0019] Further, the verification of the real-time rule specifically includes:

[0020] In the model element information mapping table, the components and the interactive channel of the subsystem design stage are found and traversed, the components are traversed and it is queried whether they are composite components, if yes, the sub-component list of the components is traversed to query whether they are composite components and all the non-cyclic paths in the sub-components are traversed, the sum of the worst execution times of the paths is calculated to return the maximum worst execution time, and whether the worst execution time of the composite component and the sum of the worst execution times of the sub-components are consistent is compared, and the consistency verification result of the worst execution times of the composite component and the sub-components is output;

[0021] In the model element information mapping table, the components of the subsystem design stage are found and traversed, it is queried whether the state list of the components is empty, if not, the state list of the components is traversed to query whether the states contain sub-states and all the non-cyclic paths in the sub-states are traversed, the sum of the worst execution times of the paths is calculated to return the maximum worst execution time, and whether the worst execution time of the subsystem and the sum of the worst execution times of the sub-components are consistent is compared, and the consistency verification result of the worst execution times of the subsystem and the states is output;

[0022] In the model element information mapping table, the components of the system architecture design stage are found and traversed, the exchange interfaces are traversed and it is judged whether the direction attribute of the exchange interface is out, if yes, all the non-cyclic paths in the sub-components are traversed, the sum of the worst execution times of the paths connected with the interface is calculated to return the maximum sum of the worst execution times, whether the period of the exchange interface and the sum of the worst execution times of the sub-components are consistent is compared, and the consistency verification result of the period of the interface and the worst execution times of the paths associated with the interface is output;

[0023] Find the components and subsystems of the software requirement stage and the subsystem design stage by ID in the model element information mapping table, determine whether the subsystem design stage model corresponding to the software requirement stage contains multiple components, if yes, calculate the worst execution time of the components in the subsystem design stage model, otherwise compare the delay attribute of the software requirement stage and the worst execution time of the subsystem design stage, output the flow delay delay of the software requirement stage and the consistency verification result of the corresponding worst execution time of the subsystem design stage.

[0024] Further, the verification of the security rule specifically includes:

[0025] Find whether there is a corresponding component in the software requirement stage and the subsystem design stage in the model element information mapping table, if not, output that there is no corresponding subsystem component, if yes, traverse each state transition in the component and view the source state and destination state ID in the transition, if the fault state corresponding to the destination state is true and the current fault type is not included in the component fault type list of the software requirement stage, output that the component fault type is inconsistent;

[0026] Traverse each component of the system architecture design stage in the model element information mapping table, and traverse each state transition of each component, view the source state and destination state ID in the transition, if there is a transition from the normal running state to the fault state and there is no transition from the fault state to the normal running state, output that the fault information of the system architecture design stage is not processed;

[0027] Traverse each component of the subsystem design stage in the model element information mapping table, and traverse each state transition of each component, view the source state and destination state ID in the transition, if the fault state corresponding to the destination state is true, if there is a record fault information behavior in the exit information of State, output record fault information processing in the log, and there is a transition from the fault state to the normal state, output recovery to normal state processing in the log; if there is no record fault information behavior in the exit information of State, and there is no transition from the fault state to the normal state, output that the fault is not processed in the log;

[0028] Traverse each component of the system architecture design stage in the model element information mapping table, determine whether each component has fault propagation, if yes, traverse the fault propagation list of the component, and view each propagated fault output interface, and view the specified input interface of the next component connected by the output interface in the channel list, if it is determined that the component has fault propagation, traverse the fault propagation and there is no propagation path with the specified input interface as the fault input interface, then output that the fault propagation is not processed, otherwise, determine whether the component fault is processed, if yes, output that the fault is not processed.

[0029] Further, the consistency, real-time and safety of the model between the development stages are verified by comparing the model elements corresponding to two development stages, and the consistency, real-time and safety of the model in one development stage are verified by comparing the model elements with data interaction in the development stage.

[0030] Further, the results of traversing and analyzing the model description files of SysML, Simulink and AADL are respectively stored in the model element information mapping table, and the model elements and related attribute information are extracted from the model element information mapping table according to the selected verification rule, the extracted model elements and related attribute information are traversed and queried and verified, and the results are output.

[0031] The beneficial effects of the technical scheme of the present application are as follows: the present application discloses a model verification method suitable for a distributed system of SysML, Simulink and AADL, comprising the following steps: model element sets and related attribute information are extracted from model description files of SysML, Simulink and AADL respectively to obtain SysML, Simulink and AADL model information mapping tables; required model elements and related attribute information are obtained from the SysML, Simulink and AADL model information mapping tables according to selected verification rules; the required model elements and related attribute information are verified according to the selected verification rules, and if the verification is passed, no prompt information is generated; otherwise, it is prompted that the selected verification rule is not met, and the verification result is output. The embodiment of the present application solves the problem that the consistency, real-time and safety of the design integration stage and the corresponding requirement model and design model of each subsystem cannot be verified at present.

[0032] Other features and advantages of the present application will be set forth in the following description, and in part will become apparent to those skilled in the art from the following description, or can be learned by practice of the present application. The objects and other advantages of the present application can be achieved and obtained by the structure particularly pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF DRAWINGS

[0033] The accompanying drawings are included to provide a further understanding of the present application, and are incorporated in and constitute a part of this specification, illustrate embodiments of the present application, and together with the description serve to explain the principles of the present application.

[0034] Figure 1 The model verification method flow chart suitable for the distributed system of SysML, Simulink and AADL of the embodiment of the present application is shown in the figure;

[0035] Figure 2 The relationship diagram of the verified model elements of the embodiment of the present application is shown in the figure;

[0036] Figure 3Verification flow chart for inter-stage component interface consistency of embodiments of the invention;

[0037] Figure 4 Verification flow chart for inter-component exchange interface operation specification consistency of embodiments of the invention;

[0038] Figure 5 Verification flow chart for direction consistency of corresponding exchange interfaces between components of embodiments of the invention;

[0039] Figure 6 Verification flow chart for message variable name consistency of corresponding exchange interfaces between components of embodiments of the invention;

[0040] Figure 7 Verification flow chart for composite component and subcomponent port consistency of embodiments of the invention;

[0041] Figure 8 Verification flow chart for inter-stage component type consistency of embodiments of the invention;

[0042] Figure 9 Verification flow chart for communication protocol consistency of inter-stage interfaces of embodiments of the invention;

[0043] Figure 10 Verification flow chart for worst-case execution time consistency of composite components and subcomponents of embodiments of the invention;

[0044] Figure 11 Verification flow chart for worst-case execution time consistency of subsystems and their states of embodiments of the invention;

[0045] Figure 12 Verification flow chart for period of interfaces and worst-case execution time of paths associated therewith of embodiments of the invention;

[0046] Figure 13 Verification flow chart for stream latency of requirements and worst-case execution time of corresponding designs of embodiments of the invention;

[0047] Figure 14 Verification flow chart for safety of component fault types of embodiments of the invention;

[0048] Figure 15 Verification flow chart for safety of migration of fault states of embodiments of the invention;

[0049] Figure 16 Verification flow chart for safety of fault information handling of fault states of embodiments of the invention;

[0050] Figure 17 Verification flow chart for safety of fault propagation paths of embodiments of the invention. DETAILED DESCRIPTION

[0051] The preferred embodiments of the present application will be described in detail below with reference to the drawings, in which the preferred embodiments of the present application constitute a part of the present application and are used to explain the principles of the present application, but are not used to limit the scope of the present application.

[0052] Keyword definition

[0053] Component represents a component in the model;

[0054] Fault represents a fault defined in the model;

[0055] CommunicationChannle represents a data interaction connection between components in the model;

[0056] Linkpoint represents an interface provided when the outermost component interacts with other outermost components;

[0057] Task represents a task, which is a type of component, and generally exists in the form of a sub-component;

[0058] State represents a state of a component;

[0059] Transition represents a transition before a state;

[0060] wcet represents the worst-case execution time.

[0061] One specific embodiment of the present application is shown in the figure, a model verification method for a distributed system of SysML, Simulink and AADL, comprising the following steps: Figure 1

[0062] S1, according to the model description files of SysML, Simulink and AADL, extracting a set of model elements and related attribute information respectively, obtaining a SysML, Simulink and AADL model information mapping table;

[0063] Specifically, a set of model elements and related attribute information are extracted from the AADL model description file (.xml format), the SysML model description file (.xml format) and the Simulink model description file (.xml format) respectively, and stored in the corresponding model information mapping table, i.e. the AADL model information mapping table, the SysML model information mapping table and the Simulink model information mapping table. Figure 2

[0064] S2, according to the selected verification rule, obtaining the required model elements and related attribute information from the SysML, Simulink and AADL model information mapping table; ​​

[0065] Specifically, the model description file contains relevant information required for verification, and corresponding model element information needs to be extracted according to different verification rules as input of the current rule verification process.

[0066] S3, verifying the required model elements and related attribute information obtained according to the selected verification rule, and if the verification is passed, no prompt information is generated, otherwise, it is prompted that the selected verification rule is not met, and specific information is given.

[0067] Specifically, the model element information related to the verification rule is extracted from the model description file, such as components, exchange interfaces, tasks, faults, states, state transitions, component interaction channels and the like, and the corresponding related attribute information is extracted. According to the selected verification rule, the specific verification is performed. The model elements and attribute information required by the current verification rule are obtained from the parsed model information mapping table, and it is determined whether the current verification rule is met. If it is met, no prompt information is generated, and if it is not met, the specific situation of not meeting the verification rule is prompted.

[0068] Compared with the prior art, the embodiment of the application performs automatic checking and positioning of inconsistencies between models, developers do not need to manually check, work efficiency is improved, and precise positioning of errors and inconsistencies in the model integration stage makes the cost of repairing errors smaller.

[0069] In one specific embodiment of the application, the AADL model description file is a model description file of a system architecture design stage model, the SysML model description file is a model description file of a software requirement stage model, and the Simulink model description file is a model description file of a subsystem design stage model. That is, data information extraction and verification are performed on the models generated in the three stages of the distributed system development process, and the three models are a system architecture model established using AADL, a software requirement model established using Sysml, and a subsystem design model established using Simulink.

[0070] It should be noted that the embodiment of the application studies and designs the levels of the distributed system from system architecture to software requirement, and then to software design, and the modeling languages of the three levels in the industry are AADL, SYSML and Simulink, respectively, so AADL is selected to construct a system architecture design model, SysML is selected to construct a software requirement model, and Simulink is selected to construct a subsystem design model.

[0071] In one specific embodiment of the application, the model elements include components, faults, interaction channels, exchange interfaces, tasks, states, and state transitions, and the model information mapping table is a one-to-many mapping relationship between the model elements and the related attribute information.

[0072] Specifically, the three-stage model contains many model elements and their attributes, and the model elements are not isolated, but have interaction relationship, and the interaction relationship is also defined in the model. The elements in the model are extracted as the element set Model = {Component, Fault, CommucationChannel, Linkpoint, Task, State, Transition}, the relationship between the model elements is as shown in Figure 2 Table 1, and the definition of the attribute of each element is shown in Table 1.

[0073] Table 1 Model element information table

[0074]

[0075]

[0076] According to the model elements and Model, the specific elements Component, Fault, CommucationChannel, Linkpoint, Task, State, Transition in the model and their attributes are obtained, such as Component type (type of the component), Component execution time (execution time of the component), Linkpoint communication protocol (communication protocol of the interface), interface transmission data (transmission data of the Linkpoint), and the like.

[0077] In one specific embodiment of the present application, the attribute information of the component includes ID, component name, component type, security level, and worst execution time; the attribute information of the exchange interface includes ID, name, direction, communication protocol, period, and transmission data type; the attribute information of the task includes ID, worst execution time, deadline, and a list of processed faults; the attribute information of the state includes ID, worst execution time, Entry event, Do event, Exit event, whether a fault state, and a corresponding fault type; the attribute information of the fault includes fault type and fault name; the state transition includes source state, destination state, and event; and the interaction channel includes ID, source port, and destination port. The model elements and their attribute related information in the verification process are listed in Table 1.

[0078] In a specific embodiment of the present invention, the verification rules include consistency rules, real-time rules, and security rules; the consistency rules include consistency verification of component-related attributes and interface-related attributes corresponding to the model between system development stages, and consistency verification of interface-related attributes of model data interaction within system development stages; the real-time rules include verification of the time attributes of components by the model between system development stages and the model within system development stages, the time attributes including worst-case execution time, period, and deadline; the security rules include verification of fault attributes by the model between system development stages and the model within system development stages, the fault attributes including fault level, fault handling, and security level.

[0079] Specifically, the verification rule types are base (consistency rule), safety (security rule), and realtime (real-time rule).

[0080] The consistency verification process is carried out according to a series of established consistency verification rules. It mainly involves the consistency verification of component-related attributes and interface-related attributes corresponding to the model between system development stages, as well as the consistency verification of the attributes of interfaces with data interaction within the system development stage.

[0081] The real-time verification process is carried out according to a series of established real-time verification rules. It mainly involves verifying the time attributes of relevant components in the model, including worst-case execution time, period, and latency, to determine whether the real-time requirements are met.

[0082] The security verification process is carried out according to a series of established security verification rules. It mainly analyzes information related to fault handling and fault propagation in the model, such as whether the faults defined in the architecture phase have corresponding fault handling modules defined in the software requirements phase, whether the corresponding fault handling modules are implemented in the subsystem design modules, whether the definition of fault propagation is complete, and whether corresponding fault handling is performed after propagation to a certain component.

[0083] In a specific embodiment of the present invention, the verification of the consistency rule specifically includes:

[0084] like Figure 3 As shown, the software requirements phase and subsystem design phase are checked in the model element information mapping table to see if there are corresponding components. If not, the output is that no corresponding subsystem component exists. If it exists, the interfaces of the components in the software requirements phase are traversed to find if there are corresponding interfaces for the components in the system design phase. If there are no corresponding interfaces, the output is that the input and output interfaces of the components between the phases are inconsistent.

[0085] like Figure 4As shown in the model element information mapping table, find out the components and interaction channels of the system architecture design stage, the software requirement stage and the subsystem design stage, and traverse the interaction channels of each model, find out the corresponding exchange interface in the interaction channel according to the attribute values of source and dest of the interaction channel, and determine the consistency of the interface operation specification by comparing the consistency of the data types and periods of source and dest.

[0086] As shown in the model element information mapping table, find out the components and interaction channels of the software requirement stage, and traverse the attribute values of source and dest of the interaction channel, and traverse the exchange interface contained by the component, find the exchange interface corresponding to the attribute values of source and dest of the interaction channel, and compare the combination of the in and out attributes of source and dest. If yes, output the direction consistency of the corresponding exchange interface between the components with message exchange. Figure 5 As shown in the model element information mapping table, find out the components and interaction channels of the software requirement stage, and traverse the attribute values of source and dest of the interaction channel, and traverse the exchange interface contained by the component, find the exchange interface corresponding to the attribute values of source and dest of the interaction channel, and compare the combination of the in and out attributes of source and dest. If yes, output the direction consistency of the corresponding exchange interface between the components with message exchange.

[0087] Figure 6 As shown in the model element information mapping table, find out the components and interaction channels of the software requirement stage, and traverse the attribute values of source and dest of the interaction channel, and traverse the exchange interface contained by the component, find the exchange interface corresponding to the attribute values of source and dest of the interaction channel, and compare the combination of the in and out attributes of source and dest. If yes, output the direction consistency of the corresponding exchange interface between the components with message exchange.

[0088] As shown in the model element information mapping table, find out the components and interaction channels of the software requirement stage, and traverse the attribute values of source and dest of the interaction channel, and traverse the exchange interface contained by the component, find the exchange interface corresponding to the attribute values of source and dest of the interaction channel, and compare the combination of the in and out attributes of source and dest. If yes, output the direction consistency of the corresponding exchange interface between the components with message exchange. Figure 7 As shown in the model element information mapping table, find out the components and interaction channels of the software requirement stage, and traverse the attribute values of source and dest of the interaction channel, and traverse the exchange interface contained by the component, find the exchange interface corresponding to the attribute values of source and dest of the interaction channel, and compare the combination of the in and out attributes of source and dest. If yes, output the direction consistency of the corresponding exchange interface between the components with message exchange.

[0089] As shown in the model element information mapping table, find out the components and interaction channels of the software requirement stage, and traverse the attribute values of source and dest of the interaction channel, and traverse the exchange interface contained by the component, find the exchange interface corresponding to the attribute values of source and dest of the interaction channel, and compare the combination of the in and out attributes of source and dest. If yes, output the direction consistency of the corresponding exchange interface between the components with message exchange. Figure 8 As shown in the model element information mapping table, find out the components and interaction channels of the software requirement stage, and traverse the attribute values of source and dest of the interaction channel, and traverse the exchange interface contained by the component, find the exchange interface corresponding to the attribute values of source and dest of the interaction channel, and compare the combination of the in and out attributes of source and dest. If yes, output the direction consistency of the corresponding exchange interface between the components with message exchange.

[0090] As shown in the model element information mapping table, find out the components and interaction channels of the software requirement stage, and traverse the attribute values of source and dest of the interaction channel, and traverse the exchange interface contained by the component, find the exchange interface corresponding to the attribute values of source and dest of the interaction channel, and compare the combination of the in and out attributes of source and dest. If yes, output the direction consistency of the corresponding exchange interface between the components with message exchange. Figure 9 ​As shown, the components and interaction channels of the software requirements phase are searched in the model element information mapping table. The source and dest attribute values ​​of the interaction channel are traversed, and the exchange interface corresponding to the source and dest attribute values ​​of the interaction channel is found by traversing the components. The protocol of source and dest is compared to see if they are consistent. If they are inconsistent, the communication protocol of the inter-phase interface corresponding to the interaction channel is inconsistent.

[0091] In a specific embodiment of the present invention, the verification of the real-time rule specifically includes:

[0092] like Figure 10 As shown, the system searches and iterates through the components and interaction channels in the subsystem design phase in the model element information mapping table. It iterates through the components and queries whether they are composite components. If they are, it iterates through the list of subcomponents of the component to query whether they are composite components and iterates through all non-cyclic paths in its subcomponents. It calculates the sum of the worst execution times of the paths and returns the largest worst execution time. It then compares the worst execution time of the composite component with the sum of the worst execution times of the obtained subcomponents and outputs the consistency verification result of the worst execution times of the composite component and the subcomponents.

[0093] like Figure 11 As shown, the components in the subsystem design phase are searched and traversed in the model element information mapping table. The state list of the component is checked to see if it is empty. If it is not empty, the state list of the component is traversed to see if the state contains substates and all non-cyclic paths in its substates are traversed. The worst execution time of the paths is calculated and the maximum worst execution time is returned. The worst execution time of the subsystem is compared with the sum of the worst execution times of the obtained subcomponents. The consistency verification result of the worst execution time of the subsystem and its state is output.

[0094] like Figure 12 As shown, the system searches and iterates through the components in the system architecture design phase in the model element information mapping table, iterates through the exchange interface and determines whether the direction attribute of the exchange interface is out. If so, it iterates through all non-cyclic paths in the sub-component, calculates the sum of the worst execution times of the paths connected to the interface, returns the largest sum of the worst execution times, compares the period of the exchange interface with the sum of the worst execution times of the obtained sub-components to see if they are consistent, and outputs the consistency verification result of the period of the interface and the worst execution time of its associated path.

[0095] like Figure 13As shown, the components and subsystems of the software requirements phase and subsystem design phase are found by ID in the model element information mapping table. It is determined whether the subsystem design phase model corresponding to the software requirements phase contains multiple components. If so, the worst execution time of the components in the subsystem design phase model is calculated. Otherwise, the delay attribute of the software requirements phase and the worst execution time of the subsystem design phase are compared to see if they are consistent. The consistency verification result of the flow delay of the software requirements phase and the worst execution time of the corresponding subsystem design phase is output.

[0096] In a specific embodiment of the present invention, the verification of the security rule specifically includes:

[0097] like Figure 14 As shown, the system searches the model element information mapping table to see if there is a corresponding component in the software requirements phase and the subsystem design phase. If it does not exist, the system outputs that there is no corresponding subsystem component. If it exists, the system iterates through each state transition in the component and checks the source state and destination state IDs in the transition. If the fault state corresponding to the destination state is true and the current fault type is not included in the component fault type list in the software requirements phase, the system outputs that the component fault types are inconsistent.

[0098] like Figure 15 As shown, each component in the system architecture design phase is traversed in the model element information mapping table, and each state transition of each component is traversed. The source state and destination state ID in the transition are checked. If there is a transition from normal operation state to fault state and there is no transition from fault state to normal operation state, the system architecture design phase fault information is output as unprocessed.

[0099] like Figure 16 As shown, the system iterates through each component in the subsystem design phase in the model element information mapping table, and then iterates through each state transition of each component. It checks the source state and destination state IDs in the transition. The fault state corresponding to the destination state is true. If the exit information of the State contains actions that record fault information, the log outputs "fault information recorded and processed," and if there is a transition from a fault state to a normal state, the log outputs "restored to normal state." If the exit information of the State does not contain actions that record fault information, and there is no transition from a fault state to a normal state, the log outputs "fault not processed."

[0100] like Figure 17As shown, each component of the system architecture design phase is traversed in the model element information mapping table, it is determined whether each component has fault propagation, if yes, the fault propagation list of the component is traversed, and each propagated fault output interface is viewed, and the next component connected by the output interface in the channel list is viewed. If it is determined that the component has fault propagation, the fault propagation is traversed and there is no propagation path in which the specified input interface of the next component connected by the output interface is a fault input interface, then fault propagation is output as unprocessed, otherwise it is determined whether the component fault is processed, if yes, the fault is output as unprocessed.

[0101] In one specific embodiment of the present application, the consistency, real-time performance and safety of the models between the system development stages are verified by comparing the model elements corresponding to two development stages, and the consistency, real-time performance and safety of the models within the system development stage are verified by comparing the model elements having data interaction within one development stage.

[0102] Specifically, there are inconsistency problems between the models of the three stages, and there are also inconsistency problems between the models of the same stage developed by different units. Based on such a situation, a method for verifying the consistency of the model elements is proposed: for the models between the stages, first find the model elements of the two stages to be compared, such as checking whether the component types in the software requirement model and the subsystem design model are consistent. First find a Component in the requirement model, then find the corresponding Component in the subsystem design model in the mapping table, and compare the types of the two Components. If the types of the two Components are inconsistent, a change prompt is generated, prompting that a change is needed here. For the models within the stage, first find two model elements having data interaction, such as checking the data types transmitted by the two connected interfaces in the system architecture model. First find a CommunicationChannel in the system architecture model, find the corresponding two Linkpoints through the source and destination attributes of the CommunicationChannel, and then compare the transmission data types of the two Linkpoints. If the transmission data types of the two Linkpoints are inconsistent, a change prompt is generated, prompting that a change is needed here.

[0103] There are inconsistencies in real-time properties between three-stage models and between models developed by different units in the same stage. Based on this situation, a method of real-time verification of model elements is proposed. For inter-stage models, first find the model elements of two stages that need to be compared, such as checking whether the execution time of the corresponding components in the software requirement model and the subsystem design model is consistent. First find a Component in the requirement model, then find one or more Components in the subsystem design model in the mapping table. If there is one Component, compare the execution times of the two Components. If there are multiple Components, find a path according to the connection between the Components, and calculate the execution time of the path. Compare it with the execution time in the requirement model. If the execution time in the subsystem design model does not meet the execution time set in the requirement model, a change prompt is generated, prompting that changes are needed here. For intra-stage models, first find a composite Component containing Components, such as checking whether the execution time of the sub-components in the system architecture model meets the execution time constraint of the composite Component. First find a Component containing Tasks in the system architecture model, find one or more paths according to the Connection between the Tasks, calculate the execution time of all paths, and compare the maximum execution time with the execution time of the composite Component. If the execution time of the path in the sub-component does not meet the execution time set in the composite Component, a change prompt is generated, prompting that changes are needed here.

[0104] There are inconsistencies in security properties between three-stage models and between models of the same stage developed by different units. Based on this, a method for verifying the security of model elements is proposed: for inter-stage models, first find the model elements of two stages that need to be compared, such as checking whether the fault types of corresponding components in the software requirement model and the subsystem design model are consistent. First find the fault type attribute of the Fault contained in a Component in the requirement model, then find one or more corresponding Components in the subsystem design model in the mapping table, if there is one Component, find the fault type attribute of the State in this Component, compare the two fault types to see if they are consistent; if there are multiple Components, find the fault type attribute of the State in these Components, compare the two fault types to see if they are consistent. If the fault types are inconsistent, generate a change prompt to prompt that changes are needed here. For intra-stage models, first find an element with security properties, such as checking whether a State of type Fault State can be migrated to a State of type Normal State through Transition in the subsystem design model. First find a State of type Fault State in the subsystem design model, find all States that it can migrate to according to the associated Transition, and check whether there is a State of type Normal State among them. If it cannot be migrated to a normal state State, a change prompt is generated to prompt that changes are needed here.

[0105] In one specific embodiment of the present application, the results of traversing and parsing the model description files of SysML, Simulink and AADL are respectively stored in the model element information mapping table, and the model elements and related attribute information are extracted from the model element information mapping table according to the selected verification rules, the extracted model elements and related attribute information are traversed, queried and verified, and the results are output. Referring to Figures 3-17 .

[0106] The verification process of a specific application example: start executing the selected security rules, traverse all source components and destination components of communicationchannel (data interaction channel between components) in the AADL model information mapping table and the SysML model information mapping table respectively, obtain the ids of the corresponding source components and destination components respectively, and extract the name and safety level of the component according to the id.

[0107] The safety level of the source component and the destination component is compared, if the safety level of the source component is lower than the safety level of the destination component, it indicates that the verification rule fails to pass the verification, and the prompt information "the safety level of the source component a (the name of the source component) is lower than the safety level of the destination component b (the name of the destination component) in the system architecture model (or the software requirement model), and there is a security risk" is prompted; if the safety level of the source component is higher than or equal to the safety level of the destination component, no prompt information is generated.

[0108] In conclusion, the application discloses a model verification method for a distributed system of SysML, Simulink and AADL, comprising the following steps: extracting a model element set and related attribute information according to model description files of SysML, Simulink and AADL, and obtaining a SysML, Simulink and AADL model information mapping table; obtaining required model elements and related attribute information from the SysML, Simulink and AADL model information mapping table according to a selected verification rule; verifying the obtained required model elements and related attribute information according to the selected verification rule, if the verification passes, no prompt information is generated; otherwise, it is prompted that the selected verification rule is not met, and a verification result is output. The embodiment of the application performs automatic checking and positioning of inconsistencies between models, the developer does not need to perform manual checking, the work efficiency is improved, and accurate positioning of errors and inconsistencies in the model integration stage is achieved, so that the cost of repairing errors is smaller.

[0109] Those skilled in the art can understand that all or part of the processes in the above embodiments can be completed by a computer program instructing related hardware, and the program can be stored in a computer readable storage medium, wherein the computer readable storage medium is a disk, an optical disk, a read-only memory or a random access memory, etc.

[0110] The above description is only the preferred embodiment of the application, but the protection scope of the application is not limited to this, any person skilled in the art can easily think of changes or replacements within the technical range disclosed by the application, which should be covered in the protection scope of the application.

Claims

1. A model verification method for distributed systems suitable for SysML, Simulink and AADL, characterized in that, The method comprises the following steps: According to the model description files of SysML, Simulink and AADL, a set of model elements and related attribute information are extracted to obtain a SysML, Simulink and AADL model information mapping table; According to the selected verification rule, the required model elements and related attribute information are obtained from the SysML, Simulink and AADL model information mapping table; According to the selected verification rule, the required model elements and related attribute information are verified, and if the verification is passed, no prompt information is generated; otherwise, it is prompted that the selected verification rule is not met, and a verification result is outputted; The verification rule comprises a real-time rule, and the real-time rule comprises verification of time attributes of components by a system development stage model and a system development stage model, wherein the time attributes comprise worst-case execution time, period and deadline; The verification of the real-time rule specifically comprises: In the model element information mapping table, components and interaction channels in the subsystem design stage are found and traversed, the components are traversed and it is queried whether the components are composite components, if yes, the sub-component list of the components is traversed to query whether the components are composite components and all non-cyclic paths in the sub-components are traversed, the sum of worst-case execution times of the paths is calculated, the maximum worst-case execution time is returned, and it is compared whether the worst-case execution time of the composite component is consistent with the sum of the worst-case execution times of the sub-components, and a consistency verification result of the worst-case execution time of the composite component and the sub-components is outputted; In the model element information mapping table, components in the subsystem design stage are found and traversed, it is queried whether the state list of the components is empty, if not, the state list of the components is traversed to query whether the state contains a sub-state and all non-cyclic paths in the sub-state are traversed, the sum of worst-case execution times of the paths is calculated, the maximum worst-case execution time is returned, and it is compared whether the worst-case execution time of the subsystem is consistent with the sum of the worst-case execution times of the sub-components, and a consistency verification result of the worst-case execution time of the subsystem and the sub-components is outputted; In the model element information mapping table, components in the system architecture design stage are found and traversed, the exchange interface is traversed and it is judged whether the direction attribute of the exchange interface is out, if yes, all non-cyclic paths in the sub-components are traversed, the sum of worst-case execution times of the paths connected with the interface is calculated, the maximum sum of worst-case execution times is returned, and it is compared whether the period of the exchange interface is consistent with the sum of the worst-case execution times of the sub-components, and a consistency verification result of the period of the interface and the worst-case execution time of the path associated with the interface is outputted; In the model element information mapping table, components and subsystems in the software requirement stage and the subsystem design stage are found by ID, it is judged whether the model of the subsystem design stage corresponding to the software requirement stage contains multiple components, if yes, the worst-case execution time of the components in the subsystem design stage model is calculated, otherwise, it is compared whether the delay attribute of the software requirement stage is consistent with the worst-case execution time of the subsystem design stage, and a consistency verification result of the flow delay delay of the software requirement stage and the worst-case execution time of the corresponding subsystem design stage is outputted.

2. The method of claim 1, wherein, The AADL model description file is a model description file of a system architecture design stage model, the SysML model description file is a model description file of a software requirement stage model, and the Simulink model description file is a model description file of a subsystem design stage model.

3. The method of claim 1, wherein, The model elements include components, faults, interaction channels, exchange interfaces, tasks, states, and state transitions. The model information mapping table is a one-to-many mapping relationship between the model elements and related attribute information.

4. The method of claim 3, wherein, The attribute information of the components includes IDs, component names, component types, safety levels, and worst execution times. The attribute information of the exchange interfaces includes IDs, names, directions, communication protocols, periods, and data types transmitted. The attribute information of the tasks includes IDs, worst execution times, deadlines, and lists of processed faults. The attribute information of the states includes IDs, worst execution times, Entry events, Do events, Exit events, whether fault states, and corresponding fault types. The attribute information of the faults includes fault types and fault names. The state transitions include source states, destination states, and events. The interaction channels include IDs, source ports, and destination ports.

5. The method of claim 1, wherein, The verification rules further include consistency rules and safety rules. The consistency rules include consistency verification of component-related attributes and interface-related attributes of models corresponding to system development stages, and consistency verification of related attributes of interfaces of model data interaction within a system development stage. The safety rules include verification of fault attributes, including fault levels, fault processing, and safety levels, of models corresponding to system development stages and within a system development stage.

6. The method of claim 5, wherein, The verification of the consistency rules specifically includes: In the model element information mapping table, it is determined whether corresponding components exist in the software requirement stage and the subsystem design stage. If the corresponding components do not exist, it is output that no corresponding subsystem components exist. If the corresponding components exist, interfaces of the components in the software requirement stage are traversed to determine whether corresponding interfaces exist in the system design stage. If the corresponding interfaces do not exist, it is output that the input and output interfaces of the components between stages are inconsistent. In the model element information mapping table, components and interaction channels of the system architecture design stage, the software requirement stage, and the subsystem design stage are found, and interaction channels of each model are traversed. According to attribute values of source and dest of the traversed interaction channels, corresponding exchange interfaces in the interaction channels are found, and consistency of interface operation specifications is determined by comparing consistency of data types and periods of source and dest. In the model element information mapping table, components and interaction channels of the software requirement stage are found, attribute values of source and dest of the interaction channels are traversed, and exchange interfaces included in the components are traversed. Corresponding exchange interfaces of source and dest of the interaction channels are found, and consistency of directions of the corresponding exchange interfaces is determined by comparing whether the directions are in and out. In the model element information mapping table, find the components and interactive channels of the system architecture design stage, the software requirement stage and the subsystem design stage, traverse each model interactive channel, find the corresponding exchange interface in the interactive channel according to the attribute values of source and dest, and compare the name attributes of source and dest, if they are consistent, output the message variable name of the corresponding exchange interface between the components with message exchange. In the model element information mapping table, find and traverse the components of the software requirement stage, determine whether the current component has subcomponents, if yes, find the interface list of all subcomponents of the current component, traverse the interface list of the current component, if there is a port not in the subcomponent list, output that the ports of the software requirement stage composite component and the subcomponents are inconsistent, if there is no port not in the subcomponent list, traverse the components of the subsystem design stage, and determine whether the current component has subcomponents, if yes, find the interface list of all subcomponents of the current component, and traverse the interface list of the current component, if there is a port not in the subcomponent list, output that the ports of the subsystem design stage composite component and the subcomponents are inconsistent. In the model element information mapping table, find whether there are corresponding components between the software requirement stage and the subsystem design stage, if not, output that there is no corresponding subsystem component, if yes, compare the type of the component in the subsystem and the software requirement stage, if they are different, output that the component types between the stages are inconsistent. In the model element information mapping table, find the components and interactive channels of the software requirement stage, traverse the attribute values of source and dest of the interactive channel, and traverse the components to find the exchange interface corresponding to the attribute values of source and dest, compare whether the protocols of source and dest are consistent, if not, output that the communication protocols of the interface between the stages corresponding to the interactive channel are inconsistent.

7. The method of claim 5, wherein, The verification of the security rule specifically includes: In the model element information mapping table, find whether there are corresponding components between the software requirement stage and the subsystem design stage, if not, output that there is no corresponding subsystem component, if yes, traverse each state transition in the component and view the source state and destination state ID in the transition, if the fault state corresponding to the destination state is true and the current fault type is not included in the fault type list of the component of the software requirement stage, output that the component fault types are inconsistent; In the model element information mapping table, traverse each component of the system architecture design stage, and traverse each state transition of each component, view the source state and destination state ID in the transition, if there is a transition from the normal operation state to the fault state and there is no transition from the fault state to the normal operation state, output that the fault information of the system architecture design stage is not processed. In the model element information mapping table, each component of the subsystem design phase is traversed, and each state transition of each component is traversed to view the source state and destination state ID in the transition. If the corresponding fault state of the destination state is true, if the exit information of the State exists, the behavior of recording fault information is output to the log, and there is a transition from the fault state to the normal state, the log outputs the processing of recovery to the normal state. If the exit information of the State does not exist, the behavior of recording fault information is output to the log, and there is no transition from the fault state to the normal state, the log outputs the processing of recovery to the normal state. If the exit information of the State does not exist, the behavior of recording fault information is output to the log, and there is no transition from the fault state to the normal state, the log outputs the processing of recovery to the normal state. In the model element information mapping table, each component of the system architecture design phase is traversed, and it is determined whether each component has fault propagation. If yes, the fault propagation list of the component is traversed, and each propagated fault output interface is viewed, and the next component specified input interface connected by the output interface in the channel list is viewed. If it is determined that the component has fault propagation, the propagation path of the fault propagation is traversed, and there is no specified input interface as the fault input interface. If the fault propagation is not processed, the fault propagation is not processed. Otherwise, it is determined whether the component fault is processed, and if yes, the fault is not processed.

8. The method of claim 5, wherein, The consistency, real-time and safety of the system development phase model are verified by comparing the model elements corresponding to two development stages. The consistency, real-time and safety of the system development phase model are verified by comparing the model elements corresponding to two development stages.

9. The method according to any of claims 1 to 8, characterized in that, The results of traversing and analyzing the model description files of SysML, Simulink and AADL are stored in the model element information mapping table, and the model elements and related attribute information are extracted from the model element information mapping table according to the selected verification rules. The extracted model elements and related attribute information are traversed, queried and verified, and the results are output.

Images