CN103853871B - Safety requirement modeling method applicable for avionics system - Google Patents

Abstract

The invention discloses a safety requirement modeling method suitable for avionics systems. The method analyzes and extracts the concepts and constraints related to the safety of aviation embedded systems, and combines the extracted concepts and constraints with the basic The concept is combined to realize the expansion of UCMeta to establish a security-related domain model; through the analysis of the established domain model, the description template for the security requirements of the aviation embedded system is determined so that it can accurately describe the functional requirements and capture the security requirements at the same time. Sex-related non-functional constraints. The method of the present invention is a semi-formal security requirement description method, which adds a security requirement description template and corresponding restriction rules on the basis of RUCM, and is used to describe the security requirement completely and accurately, and supports Some degree of automated validation.

Description

A Safety Requirement Modeling Method Applicable to Avionics System

technical field

The invention relates to a method for modeling requirements, more particularly, a method for modeling safety requirements applicable to avionics systems.

Background technique

Software safety is a property that the system controlled by the software is always in a safe state that does not endanger human life, property and the ecological environment. Especially for embedded real-time software that requires high security, such as aerospace, as the proportion of software in the system gradually increases, the possible consequences of software failure will become more and more serious. In order to ensure the security of the system, it is necessary to describe and analyze the security of the system in the requirement analysis stage.

Requirements modeling is an important activity in software requirements engineering. Requirements engineers use different modeling methods to identify, understand, and mine the expectations of requirements providers for the system, so as to build structural models, behavior models, or other Various pairs of models showing different characteristics of the software to be developed. Modeling methods play an important role in this activity. Adopting different modeling methods means looking at software issues from different perspectives, how to derive expectations for the software system itself from expectations for the overall system, and to demonstrate software How the system behaves and how it functions in a software-enhanced system. See page 50 of the first edition of "Software Requirements Engineering: Principles and Methods" in July 2008, edited by Jin Zhi et al.

In the current demand modeling method, the main description methods and technologies used are natural language, graphic symbol language and formal language. From the perspective of practicality, there are: structured demand modeling method and object-oriented demand modeling method.

The technical route of the object-oriented method includes requirements engineering, software design and software implementation; among them, requirements engineering includes requirements acquisition and requirements analysis. The object-oriented method first obtains requirements from the source of requirements (mainly users), organizes user descriptions of requirement information, and establishes use case models. After obtaining a complete and accurate understanding of user needs, the object-oriented method begins to consider the realization mechanism of the software and carry out software design. April 2009, the first edition of "Requirements Engineering - Software Modeling and Analysis", page 315, edited by Luo Bin.

The software of the integrated modular avionics system (Integrated Modular Architecture, IMA, avionics system for short), including the operating system, application program, database, network, human-machine interface, etc., should follow a unified series of standards and specifications for research and development, and the software can be reused , standardization, intelligence, portability, quality, reliability, etc. should be included in the characteristic parameters of software technology.

Contents of the invention

In order to make the avionics system software to be constructed have higher safety requirements, the present invention provides a safety requirement modeling method suitable for avionics systems. The modeling method of the present invention uses the use case meta-model UCMeta in RUCM to safely expand the participant Actor and the use case Use Case, and realize the description of the demand modeling of the avionics system software to be built; The software of the avionics system performs safety defect identification; the safety requirement model designed by the invention can provide a complete and unambiguous requirement description for the software design of the avionics system.

A safety requirement modeling method applicable to avionics systems of the present invention specifically has the following steps:

Step 1: Establish a domain conceptual model of security requirements;

According to the RTCA/DO-178B standard, the security identification of the existing avionics system software is established to obtain the domain concept model;

Step 2: Construct the graphic extension of the avionics system based on the UCMeta meta-model; the graphic extension of the avionics system is obtained by extending the UCMeta meta-model based on the domain concept model of security requirements obtained in step 1;

Step 3: Build an avionics system security requirement template based on the RUCM description template; the avionics system security requirement template is obtained by adding related items to the RUCM description template.

In step 2 of the present invention, the domain conceptual model is converted into UML Profile, and the metamodel UCMeta of RUCM is safely extended; refinement is carried out in the Actor, and the Safety UseCase is established for Use Case; the domain conceptual model is analyzed , determine the description template of security requirements and the use of restriction rules and keywords; expand the RUCM description template to describe security requirements, add 10 security description rules and several keywords to ensure that the description of RUCM is complete, accurate, and unambiguous; The expanded UCMeta creates a Use Case Diagram that supports the description of security requirements. At the same time, the user has completed a complete and accurate description of the function and security requirements through each Use Case.

The advantages of the safety requirement modeling method of the present invention are:

①Aiming at high-security aviation embedded systems, the present invention has carried out in-depth study on the safety standard DO-178B and created a corresponding safety model, so that the safety requirements can be modeled in the software requirements stage.

② The present invention aims at modeling the security requirements of aviation embedded systems, and expands the UCMeta of the standard RUCM. UCMeta is the metamodel of the RUCM method, which is defined using MOF (Meta Object Facility). Through domain analysis, the model elements Actor and Use Case in the UML standard Use Case Diagram are refined and safely extended to support graphical security requirement modeling.

③ The present invention aims at modeling the safety requirements of the aviation embedded system, and expands the requirement description template and its restriction rules of the standard RUCM. By extending the requirements description template of RUCM, it can support the description of safety-related fault handling in the software requirements modeling stage, and the description of safety requirements is complete, accurate and unambiguous through the expansion of restriction rules.

Description of drawings

Figure 1 is a technical roadmap of a conventional object-oriented approach.

FIG. 2 is a conceptual model diagram of the field within the scope of application of the present invention.

Fig. 3 is a UCMeta package diagram of RUCM according to the present invention.

Fig. 4 is a package diagram of UCSTemplate according to the present invention.

Fig. 5 is a detailed model diagram of Actor according to the present invention.

Fig. 6 is a diagram of the extended model of Use Case according to the present invention.

Fig. 7 is a data exchange diagram between Use Case and Actor or resource according to the present invention.

Fig. 8 is a failure model diagram of the present invention.

Fig. 9 is a diagram of a failure treatment analysis model according to the present invention.

Fig. 10 is a model diagram of a failure handling statement according to the present invention.

Figure 11 is a schematic diagram of information in each column required by the Use case template.

detailed description

The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments.

Referring to Fig. 1, the "use case model" in Fig. 1 is the security requirement model that needs to be modeled in the application of the present invention.

A safety requirement modeling method applicable to avionics systems of the present invention specifically includes the following steps:

Step 1: Establish a Domain Conceptual Model of Security Requirements

Based on the RTCA/DO-178B standard, the security identification of the existing avionics system software is established to obtain the domain concept model.

The full name of the RTCA/DO-178B standard is Royal Technical Commision on Aviation DO-178B.

Security requirements are composed of two parts: security level requirements and security function requirements. The requirements for security levels are mainly security isolation measures, that is, software with different security levels need to be given different degrees of attention; the requirements for security functions mainly include identifying failures that cause harmful states in the system, reducing the probability of entering an unsafe state and weakening its harmful consequences.

Hazard refers to the potential unsafe state of the system caused by functional failure or external events. The DO-178B standard divides the hazard levels to indicate their impact on the system. These categories are: catastrophic, Dangerous/serious, heavy, light, and no impact; correspondingly define the safety level for safety-critical software, and divide it into 5 levels according to the severity of the harm it causes.

Table 1: Software Security Levels

Safety function requirements are the requirements to identify possible hazards in the system and take certain measures to reduce the probability of occurrence or mitigate their impact. Security functions are divided from the following perspectives:

1) Failure mode and failure effect analysis

Failure mode refers to the manner in which failure occurs. Through the study of GB7826 standard and GJBZ1391 standard, the failure mode is divided into five categories in the present invention: input data failure, output data failure, expected function failure, timeout failure and failure caused by abnormal hardware, user or environment.

The failure impact is used to represent the impact of the failure of the use case (Use Case) on the system or subsystem where the use case is located, and when the impact will cause certain harm to the system (impact on safety), the use case is safety-critical of.

Table 2: Definition of failure

English Chinese meaning FailureID invalid unique identifier FailureDescription Description of failure Failure Mode failure mode Failure Cause Reason for failure Level Failed security level Hazard Hazard due to failure

For each hazard (Hazard), define its severity and probability of occurrence, both of which are qualitative analysis. In the system requirements analysis stage, it may be impossible or difficult to determine the occurrence probability of a hazard. It can be represented by None first, and it will be supplemented when the data is complete. The risk of a hazard is its combination of probability of occurrence and severity, and hazards can be classified according to risk analysis. The severity of a failure is determined according to the hazard that it is likely to cause with the highest degree of risk.

Table 3: Definition of Hazards

English Chinese meaning Severity severity of harm Probability Probability of Hazard Occurrence Failure failure to cause the hazard

Hazards can be divided into two types: Single Failure Hazard and Combine Failure Hazard, that is, hazards caused by a single failure and hazards caused by multiple failures. For example, there may be multiple sets of brake systems in an aircraft, and the failure of a single brake system will not cause harm to the aircraft. Only when all the brake systems fail will cause the inability to decelerate and cause harm to the aircraft. This situation is caused by multiple failures. hazards. For process-level health monitoring, if it cannot handle faults, it may directly cause system damage, which is the damage caused by a single failure.

2) Failure cause analysis

The cause of the failure is described through failure analysis. Each failure has its own trigger condition, and Tigger is used to represent the trigger of the failure. During the execution of one or more statements, the guard condition is checked, and if the condition is not met, a fault is triggered and the use case is invalidated.

The description of the guard condition is expressed by the safety constraint (Safety Constraint). Security constraints are divided into three categories: real-time constraints, data constraints and state constraints. Real-time constraints are periodic or execution time constraints; data constraints are mainly constraints on data values, and state constraints are constraints on the execution status of use case statements. The status is divided into three categories: normal, abnormal termination, and infinite loop.

Table 4: Definition of Security Constraints

English Chinese meaning ConstraintID ID of the constraint Sentence The effective range of constraints defined in the field Constraint The field is the content of the constraint

In the domain concept model shown in Figure 2, the present invention defines 12 security attributes by following the DO-178B/C standard, and their specific meanings are as follows:

P1: Each security component must provide a corresponding security interface to detect and handle faults generated inside the component and transmitted from the outside.

P2: Security-related interfaces can only be activated by security components or fault registration components.

P3: Each security component and its security interface must have the same security level.

P4: Every security construct that provides access to shared data uses invariants to ensure that modifications to the data satisfy corresponding constraints.

P5: Each platform component should be able to provide sufficient resources for the corresponding deployment component.

P6: Each identified fault must be detected and handled by at least one component.

P7: Each identified failure must have corresponding incentives and handling strategies.

P8: Every fault that can propagate must be able to be handled by other security components.

P9: Faults can only be registered in the fault registration component by the secure channel.

P10: Registered faults can only be processed by registered components according to corresponding processing strategies.

P11: Each secure channel must provide an interface to protect the security of interactions between secure components.

P12: The security level of each security channel cannot be lower than the security level of those components connected to it.

Step 2: Construct the graphics extension of the avionics system based on the UCMeta meta-model

Referring to Fig. 2, in the present invention, the UCMeta meta-model is extended according to the domain concept model of safety requirements obtained in step 1, so as to obtain the graphic extension of the avionics system.

UCMeta is the metamodel of the RUCM method, which is defined using MOF (Meta Object Facility), including UCMeta, UML::UseCases, UCSTemplate, SentenceSemantics, SentencePatterns, and SentenceStructure. Among them, the latter three mainly complete the specification and limitation of natural language. The structure of UCMeta is shown in Figure 3.

Security extensions to UCMeta focus on the UCSTemplate package, and the metaclass UseCase can be extended by adding relationships to UseCaseSpecification. As shown in Figure 4, UseCaseSpecification includes a BriefDescription, Precondition, one or more FlowOfEvents, a primary actor, and 0 to more secondary actors. BriefDescription, Precondition, PostConditon and FlowOfEvents all contain a series of Sentences. There are two kinds of event flows: BasicFlow and AlternativeFlow. Each use case must contain a BasicFlow, and there can be 0 or more AlternativeFlows. Each event stream has a PostCondition consisting of a series of Sentences. There are three different ways of branching streams: GlobalAlternative, SpecificAlternative, and BoundedAlternative. Each AlternativeFlow has a condition corresponding to a reference flow.

There are three types of statements in UCSTemplate: simple statements (metaclass SimpleSentence), complex statements (subpackage ComplexSentence), and special statements (subpackage SpecialSentence). A simple statement is one that contains an independent clause and no dependent clauses: only one subject and one predicate. UCMeta has four complex statements, for four keywords: condition (IF-THEN-ELSEELSEIF-THEN-ENDIF), loop (DO-UNTIL), concurrent (MEANWHILE) and validation (VALIDATES THAT). There are four specific statements that illustrate how the flow of events in a use case interacts with another flow of events, and these four correspond to four keywords: RESUME STEP, ABORT, INCLUDE USE CASE, and EXTENDED BY.

The following introduces the detailed expansion of the present invention from the actors (Actor) and use cases (Use Case):

(A) Refinement of Actors

Actors are used in UML to describe the roles outside the system that interact with the system, which can usually be people who use the system, or external devices or logical entities. The UML standard does not classify actors. For each use case in RUCM, actors are divided into primary actors (Primary Actor) and secondary actors (SecondaryActor). The primary actor is the first actor to initialize the use case, the rest are secondary actors.

In the present invention, the concept of UML activists is classified into four types, as shown in Figure 5, and the specific contents are as follows:

(1) Timer, an entity that periodically generates specific events, has a duration (duration) attribute of type NFP_Duration. NFP_Duration is a data type imported from UML/MARTE, which contains a real number and a time unit information.

(2) HumanActor, indicating that the actor is an actual person.

(3) ExternalInstrument, which represents an external device, its direction attribute describes the data input and output direction of the device, and its signal attribute describes whether the signal type of the device is a digital signal or an analog signal. Sensor (sensor) and Actuator (actuator) are common concepts in the field of avionics systems, and they appear here as subclasses of ExternalInstrument.

(4) ExternalSystem, used to describe the external system.

(B) Security extension of Use Case

Use Case describes a set of actions performed by the system, and describes system behavior through interaction with actors, which is an important concept. The specification of Use Case is regulated in the RUCM method. In the present invention, Use Case is extended to Safety Use Case, which is defined as a use case that realizes a certain safety function, and safety function refers to the function of identifying and processing the failure of the system or its components. Therefore, each Safety Use Case must be associated with to the identification and handling of one or more failures. The following specifically introduces the relevant extension content:

(1) Refinement of Use Case. In the present invention, the Safety Use Case is inherited from the Use Case, and its model is shown in FIG. 5 . Define Safety Use Case as a use case that realizes a certain safety function. Each Safety Use Case has its own safety level and can identify corresponding failures. Each Safety Use Case must be associated with one or more failure identification and processing .

Security levels are defined and classified in the DO-178B standard. The safety level of Safety Use Case is determined according to the severity of its possible failure. The safety level is divided into five levels, namely level-A to level-E, which correspond to catastrophic, dangerous/serious, heavy, light and no impact respectively. Different levels of Safety Use Case should be given different degrees of attention.

(2) Requirements modeling of software security level. Define the requirements and constraints related to the software security level, that is, security isolation measures. Safety isolation measures refer to the isolation of safety-critical systems from non-safety-critical systems, and isolation of systems with higher safety levels from systems with lower safety levels, so as to ensure that non-safety-critical systems or systems with lower safety levels are not as expected. in a manner that affects the functionality of safety-critical modules.

In the present invention, the requirements and constraints related to the software security level, that is, the security isolation measures are defined, and the specific performance can be divided into two aspects:

a) When the Actor of the external system or external device type exchanges data with the Safety Use Case, the security level of the external system or external device should not be lower than that of the Safety Use Case. If it is an external system, the security of the external system should be ensured; if it is an external device, a more reliable external device should be selected.

b) When the Safety Use Case uses a certain resource in the system, the security level of the resource should not be lower than that of the Safety Use Case.

In the present invention, Communication Sentence is used to represent data exchange between use cases and executors or use cases and resources, as shown in FIG. 6 , and Communication Media is a communication medium to provide support for data transmission. Several common communication media are listed in the model: system_call (system call), hw_port (hardware port), bus_protocol (bus), lan_protocol (local area network) and sys_service (services provided by the system, such as blackboard, semaphore and buffer, etc. ).

Similarly, Resource also defines the corresponding security level attributes, and use cases can exchange data with resources, external devices or external systems through certain media. Use the keyword COLLECT INPUT FROM and the keyword DELIEVROUTPUT TO to indicate collecting or sending data from external devices, external systems or other use cases, and use the keyword VIA to indicate the data transmission method.

(3) Requirements modeling of software security functions. Safety function requirements are requirements for identifying possible hazards in the system and taking certain measures to reduce the probability of occurrence or mitigate their impact. The following is a detailed introduction from three aspects:

a) Failure mode and failure impact analysis, the model is shown in Figure 7. In the present invention, the failure impact is used to represent the impact of the failure of the use case on the system or subsystem where the use case is located, and when the impact will have a certain impact on the system A use case is safety-critical when it is compromised (impact on safety). Therefore, for Safety Use Case, its failure will definitely lead to one or more hazards. For each Hazard, define its severity and probability of occurrence, both of which are qualitative analysis. The risk of a hazard is its combination of probability of occurrence and severity, and hazards can be classified according to risk analysis. The severity of failure is determined according to the hazard with the highest risk that it may cause, while the safety level of SafetyUse Case is determined by the failure with the highest safety level.

b) Failure cause analysis, the model is shown in Figure 8, the present invention describes the cause of failure through failure analysis, and several common failure types are listed in the model. Use Tigger to represent the triggering of faults. During the execution of one or more statements, the guard conditions are checked. If the conditions are not met, a fault is triggered, which in turn leads to the failure of the use case. The description of guard conditions is expressed by Safety Constraint (safety constraints). Security constraints are divided into three categories: real-time constraints, data constraints and state constraints. Real-time constraints are periodic or execution time constraints; data constraints are mainly constraints on data values, and state constraints are constraints on the execution status of use case statements. The status is divided into three categories: normal, abnormal termination, and infinite loop. Use Safety Condition Sentence to describe the condition check statement. A condition check statement is a check of a constraint. Use the keyword CHECK CONSTRAINT to express conditional checks. If there is a constraint statement c1, its scope is STEP1, and the constraint is STATE=normal, the corresponding condition check statement example is as follows: The system CHECKCONSTRAINT c1.

c) Failure handling, the failure control method is modeled in Figure 9. Use certain mitigation measures to control the failure. Failure Mitigation is defined as a branch flow, and a series of processing procedures can be defined to handle the failure. In addition, several commonly used failure handling methods are modeled. Record means to record the failure; Retry means to retry the failed part of the function, and its attribute retry_times defines the number of retries; Progogate means that the failure is not processed in this use case, but is handed over to other use cases or systems for processing. At the same time, a series of processing procedures can be defined for each failure according to the type and cause of failure. Use several special sentences to indicate the special handling of failure, as shown in Figure 10. Among them, the use form of Record Sentence is RECORD THE FAILURE; the use form of Retry Sentence is RETRY FOR...TIMES; the use form of Propogate Sentence is PROPOGATE TO USECASE....

Step 3: Build an avionics system security requirement template based on the RUCM description template

As shown in Figure 11, the content of the RUCM description template includes: use case name (Use Case Nmae), use case brief description (Brief Description), use case execution precondition (Precondition), use case main actor (PrimaryActor), use case Other actors (Secondary Actors), the dependencies between this use case and other use cases (Dependency), the generalization relationship between this use case and other use cases (Generalization), the basic event flow of this use case (Basic Flow) and the other three Event flow (Global Alternative Flow, Bounded Alternative Flow, Specific Alternative Flow). After the execution of each event flow, there must be a Post Condition indicating the result of the event flow after execution. There is one and only one Basic Flow in each use case, and the Global Alternative Flow, Bounded Alternative Flow, and Specific Alternative Flow are based on specific The actual situation determines the number of its existence. The RUCM description template is also equipped with corresponding rules and keywords when used.

In the present invention, not only the relevant expansion of the security requirement description is carried out to the RUCM requirement description template, but also corresponding new rules and keywords are added. The following is a detailed expansion of these two aspects:

(1) Security requirements description template

The standard RUCM description template only defines three kinds of event flows, which are the basic event flow, the global extended event flow and the local extended event flow. In order to describe the security requirements, the event flow must be extended to describe the fault and its corresponding processing method. The extended event stream is aimed at other processing situations when one or some active events in a basic event stream or extended event stream occur.

The expanded security requirement description template in the present invention is as follows:

Table 5: Security Requirements Description Template

Table 6: System hazard table

Hazard Severity Probability Failure

The basic part of the safety requirement template is basically consistent with the common RUCM use case template, and only one line of SafetyLevel is added to describe its safety level.

On this basis, a security-related conceptual description is added, and the specific extensions are as follows:

a) Add a description of the failure

Table 7: Failure Description

b) Add a description of the degraded processing of failure

Table 8: Failure downgrade processing

Failure Mitigation: Failure downgrading measures, which are branch streams, can define a series of processing procedures to handle failures, and can also add predefined processing methods. Each Failure Mitigation must have a PostCondition to indicate the result of this processing.

c) Add constraint definition

Table 9: Constraint Definitions

ConstraintID Sentence Constraint

The Constraint part is to define the constraints in the use case, the ConstraintID is the tag of the constraint, the effective range of the constraint is defined in the Sentence field, and the Constraint field is the content of the constraint.

d) Add a list of hazards for the whole system

Table 10: Hazard List

Hazard Severity Probability Failure

After the above-mentioned security extension is carried out, it is also necessary to maintain a hazard list for the entire system. Through this list, various hazards existing in the system, the severity of the hazards, the probability of occurrence of the hazards, and the failures that cause the hazards can be recorded. Hazard represents the specific hazard, Severity represents the severity of the hazard, Probability represents the probability of occurrence of the hazard, and Failure represents the failure that caused the hazard.

In the present invention, some English words do not refer to Chinese meanings, and the meanings expressed in English can be directly translated into Chinese.

(2) Add new restriction rules and keywords to the security requirement template,

In order to strike a balance between ease of expression and expressive rigor, RUCM designed a total of 26 constraint rules, of which 16 rules are used to restrict the use of natural language, and 10 rules are used to define 10 activity descriptions with control structures. But these rules can not meet the relevant description of software security. Therefore, the standard RUCM rules will be expanded, and the restriction rules and keywords described in the present invention are as follows:

R1: When the type of executor of the use case is ExternalSystem or ExternalInstrument, the security level of ExternalSystem and ExternalInstrument should not be less than the security level of the use case.

R2: When a use case accesses a resource, the security level of the resource should not be lower than that of the use case.

R3: Use the keywords COLLECT INPUT FROM and DELIEVR OUTPUT TO to indicate collecting or sending data from other use cases or external devices, and use the keyword VIA to indicate the communication medium used for data communication.

R4: Use the keyword AND to indicate that multiple failures together cause a hazard.

R5: Use the keywords >, <, =, IN to indicate the range of constraint values, and use the keyword CHECK CONSTRAINT to check the constraints.

R6: Use the keyword RECORD THE FAILURE to indicate that a failure is recorded.

R7: Use the keyword RETRY FOR..TIMES to indicate the retry operation, which can define the number of retries.

R8: Use the keyword PROPOGATE TO USE CASE to indicate failure propagation.

R9: When the failure propagates to another use case for processing, the safety level of this use case should not be lower than the safety level of the current use case.

R10: The safety level of each failure is determined by the severity of the most serious hazard it causes, and the safety level of each use case is determined by its highest safety failure.

Example

In the following example, security requirements are described using security requirement templates and keywords.

Claims (2)

1. A safety requirement modeling method applicable to avionics systems, which includes the following steps: Step 1: Establish a domain conceptual model of security requirements; According to the RTCA/DO-178B standard, the security identification of the existing avionics system software is established to obtain the domain concept model; Step 2: Construct the graphic extension of the avionics system based on the UCMeta meta-model; the graphic extension of the avionics system is obtained by extending the UCMeta meta-model based on the domain concept model of security requirements obtained in step 1; Step 3: Build an avionics system security requirement template based on the RUCM description template; the avionics system security requirement template is obtained by adding related items to the RUCM description template; In step 2, the domain concept model is converted into UML Profile, and the RUCM meta-model UCMeta is safely extended; refinement is carried out in the Actor, and the SafetyUse Case is established through the security extension of the Use Case; the domain concept model is analyzed to determine the The description template of security requirements and the use of restriction rules and keywords; expand the RUCM description template to describe security requirements, add 10 security description rules and several keywords to ensure that the description of RUCM is complete, accurate, and unambiguous; the expanded UCMeta creates a Use Case Diagram that supports the description of security requirements, and at the same time, the user has carried out a complete and accurate description of the function and security requirements through each Use Case; It is characterized by: The steps for refinement in Actor are: Step 301: Expand the Actor according to the characteristics of the embedded real-time system, and divide the Actor into four types: Timer, Human Actor, External Instrument and External System; Step 302: Include periodic tasks in the embedded real-time system, and Timer is used to trigger a periodic action, its attribute duration represents the time length of the cycle; its value type NFD_Duration includes time units and time values; Human Actor represents the user who uses trigger its related use case; Step 303: External Instrument represents an external device that exchanges data with the use case, that is, a sensor or a signal receiver; its attributes direction and signal represent the data transmission direction and signal type, respectively; Step 304: External System represents an external use case, subsystem or system that interacts with the use case; Step 305: Both External Instrument and External System define security levels; The detailed steps of Use Case are: Step 401: Safety Use Case is inherited from Use Case; Safety Use Case is defined as a use case for implementing safety functions, and safety functions refer to the function of identifying and processing failures of the system or its components. Therefore, each Safety Use Case Shall be associated with the identification and handling of one or more failures; Step 402: According to the definition and classification of safety levels in the DO-178B standard, the safety levels of Safety Use Case are divided into five levels from level-A to level-E, corresponding to catastrophic, dangerous/serious, relatively serious heavy, light, unaffected; The described security description rules are: R1: When the type of executor of the use case is ExternalSystem or ExternalInstrument, the security level of ExternalSystem and ExternalInstrument should not be less than the security level of the use case; R2: When a use case accesses a resource, the security level of the resource should not be lower than the security level of the use case; R3: Use the keywords COLLECT INPUT FROM and DELIEVR OUTPUT TO to indicate collecting or sending data from other use cases or external devices, and use the keyword VIA to indicate the communication medium used for data communication; R4: Use the keyword AND to indicate that multiple failures jointly cause a hazard; R5: Use the keywords >, <, =, IN to indicate the range of constraint values, and use the keyword CHECKCONSTRAINT to check the constraints; R6: Use the keyword RECORD THE FAILURE to indicate that a failure is recorded; R7: Use the keyword RETRY FOR TIMES to indicate the number of retries for the retry operation; R8: Use the keyword PROPOGATE TO USE CASE to indicate failure propagation; R9: When the failure is propagated to another use case for processing, the safety level of this use case should not be lower than the safety level of the current use case; R10: The safety level of each failure is determined by the severity of the most serious hazard it causes, and the safety level of each use case is determined by its highest safety failure. 2. The safety requirement modeling method suitable for avionics systems according to claim 1, characterized in that the complete structure of the avionics system safety requirements template is: FailureID: the identification number of each failure; FailureDescription: a brief description of the failure behavior; Failure Mode: failure mode, its value is an enumeration type; Failure Cause: failure cause, which is the type of failure that caused the failure, and its value is an enumeration type; Level: The safety level of the failure, determined according to the severity of the harm it causes; Hazard: the name of the hazard caused by failure; FailureMitigate: failure mitigation measures; The Constraint part is to define the constraints in the use case, ConstraintID is the tag of the constraint, the effective range of the constraint is defined in the Sentence, and constraint is the content of the constraint.