CN107885607B - Modeling method based on embedded system software multi-view accident model - Google Patents
Modeling method based on embedded system software multi-view accident model Download PDFInfo
- Publication number
- CN107885607B CN107885607B CN201710986470.3A CN201710986470A CN107885607B CN 107885607 B CN107885607 B CN 107885607B CN 201710986470 A CN201710986470 A CN 201710986470A CN 107885607 B CN107885607 B CN 107885607B
- Authority
- CN
- China
- Prior art keywords
- software
- view
- environment
- accident
- embedded
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/008—Reliability or availability analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/079—Root cause analysis, i.e. error or fault diagnosis
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses an evaluation and analysis method based on an embedded system software multi-view accident model, which comprises a top layer accident occurrence process model and a deep layer problem generation model, wherein the top layer accident occurrence process model analyzes an accident occurrence process from software failure and interaction errors between software and other components in a system, and the deep layer problem generation model comprises a development view, a composition view, a logic view and an environment view which are used for establishing a software layer and a system layer; the software layer analyzes the problem of causing accidents from the mechanism of software failure; the invention provides a hierarchical multi-view description method aiming at software failure accidents and software interaction accidents, which is more in line with the characteristics of an embedded system, fundamentally explains the reasons of accidents, and more detailedly and fully describes the process and mechanism of embedded system software accidents.
Description
Technical Field
The method relates to the field of embedded systems, in particular to the field of embedded software which is used as a control system and has higher reliability and safety requirements. In particular to a multi-view accident model based on embedded system software and a modeling method thereof.
Background
Embedded systems have found widespread use in advanced industrial fields, particularly the aerospace field. Embedded system software serves as an important control in these areas and is often an important component of the system that ensures the successful performance of safety critical tasks. Due to the characteristics of limited hardware resources, severe operating environment, strict sequential logic, long operating time, high safety key level and the like, once the embedded system software is in error operation, accidents can be caused, and losses are caused.
For the occurred accident, the accident occurrence mechanism and process can be accurately described by establishing an accident model, defects in aspects of safety design, management and the like are systematically summarized, and a targeted design rule or management measure is formed to avoid the reoccurrence of similar accidents.
The traditional accident model mainly takes an accident chain as a main part, and describes an accident as an event chain result caused by unsafe behaviors of people and unsafe states of objects, such as the domino principle of Heineshi, the theory of accidental release of energy, FTA, ETA, FMEA and the like. In addition to the event chain model, there is a class of accident models that consider that the system has multiple layers of protection against dangers, and the protective layers may have leaks, and once the danger develops through the protective layer leaks, the accidents can develop like the process of human infection epidemic, so that the accident model is called epidemiological theory, and more typically belongs to the Swiss cheese model.
Modern accident models are based primarily on a system perspective, considering the occurrence of an accident as a result of the interaction of the units within the system and with each other, such as STAMP, AcciMap, FRAM, as well as some formalization tools and dynamic continuum models. At present, the attention of the accident models, whether traditional or modern, is mostly focused on scientific and technical systems, namely safety accidents in the field of industrial production. Table 1 shows the characteristics of the various accident models and their application in the embedded domain.
TABLE 1 characteristics of various accident models and their application in embedded field
However, the traditional accident model is not suitable for describing embedded system software accidents with numerous interactions, and although the modern accident model based on the system theory can describe the interaction process of a complex system, the description of the specific mechanism of the embedded system software problem is not comprehensive and deep enough, and meanwhile, effective evaluation and analysis on the system generating the accident and the accident occurrence reason are lacked.
Disclosure of Invention
In order to solve the technical problems, the invention discloses an accident model for comprehensively describing the software accident of the embedded system and a method for describing the embedded system, and guides the safety control based on the accident model and the system description so as to improve the safety of the system.
The complete technical scheme of the invention comprises the following steps: multi-view accident model based on embedded system software, modeling method thereof and method for evaluating and analyzing accident occurrence reasons of embedded system by using model
It is characterized by comprising:
the embedded system software multi-view accident model comprises:
(1) a top layer accident occurrence process model;
(2) a deep problem generation model;
the top layer accident occurrence process model analyzes the reasons of the accident occurrence from two aspects of the failure of the embedded system software and the interaction errors between the embedded software and other components in the system; the safety control in the embedded system comprises internal safety control and real-time danger control, and when the internal safety control fails due to software failure or interaction error, the system enters a dangerous state; if the real-time danger control fails, the danger is spread to form an accident;
the deep problem generation model comprises a development view, a composition view, a logic view and an environment view which are used for establishing a software layer and a system layer;
the software layer analyzes the problem of causing accidents from the mechanism of software failure;
the system level analyzes the problem causing the accident from the mechanism of the interaction error between the software and other components in the system.
In the top accident occurrence process model, the safety control in the embedded system comprises the following steps:
1) internal safety control: the internal safety control is designed in the embedded system in advance, and when the defects of the embedded software are excited or interaction errors occur, the internal control is processed in time to avoid the system from entering a dangerous state;
2) real-time risk control: the real-time danger control is not designed in the embedded system, and when the system enters a dangerous state due to software defects or interaction errors, the danger can be processed in real time and the system can return to the normal operation safety control;
3) accident control: the accident control is a control for reducing accident loss after an accident occurs.
In the top accident occurrence process model, the accident occurrence reasons include the following conditions:
1) software failures and interaction errors
Considering that the embedded system enters a normal operation state after being started, and dividing the software in the normal operation state into defective software and non-defective software; for non-defective software, when the system enters a dangerous state, generating interaction errors for the object software and other system elements; for defective software, when the system enters a dangerous state, the interactive error of the object software and other system elements is formed, and/or the software defect is triggered to form failure;
2) internal safety control failure
The design and operation process of the embedded system follows a certain safety constraint set, the safety constraint set relates to the requirements of interface transmission, information communication, task execution flow and time sequence, time, precision and resources in a software system, and the system is constrained together to form a bounded safety range; meanwhile, related safety control is designed in embedded software or an embedded system; when the software fails or interaction errors cause the failure of an internal safety constraint set and design safety control, the system enters a dangerous state;
3) real-time hazard control failure
The system in the dangerous state controls the spreading of the danger through real-time danger control, or enables the system to return to a normal safe operation state, and if the real-time danger control fails, the danger is spread to form an accident.
The establishing of the development view comprises establishing a software development view and establishing a system development view; the software development view tracks defects at the software development stage, and the propagation and evolution process of defects in different stages.
Preferably, various defect behaviors of the software are sorted and classified through a development view of the software, and for each large class, the work content in the respective development stage is further subdivided.
Preferably, the software development view establishes trace information item by item according to the software requirement specification, analyzes whether the requirement is correct, and traces whether each requirement is designed, realized and tested in each development stage.
The system development view tracks the consistency of the interface design of the software and hardware and the mapping of the software and hardware.
Preferably, the consistency of the software and hardware interface design and mapping is analyzed by a software interface document.
Preferably, the system development view acquires software and hardware function segmentation information from a system document, establishes a software and hardware interface mapping matrix according to the interface document, analyzes the integrity and consistency of the interface, and tracks whether the analysis of the interface is realized.
The establishing of the composition view comprises establishing a software composition view and a system composition view, wherein the software composition view analyzes programs and documents, and preferably, the analysis of the programs and the documents comprises analyzing module design and division, module units and code composition of the programs; all contents of a software program are reserved in a software development document, and the analysis of software composition comprises the steps of analyzing the correctness and the integrity of codes and modules and establishing an interface matrix between the modules to analyze the consistency of the interfaces;
the system composition view analysis system is characterized in that the mutual relation of all components in the system composition view analysis system is used as a structural basis for describing the system behavior, and a system composition view is static description of an embedded system and embodies the components of the embedded system and interfaces among the components.
Preferably, the establishing of the system composition view completes the identification of the system composition and the interface. More preferably, when the system composition view is established, the hierarchical description is from coarse to fine.
The establishing of the logic view comprises establishing a software logic view and a system logic view, wherein the software logic view analyzes the division of software functions and the division of logic levels, namely the mode of converting requirements into software functions; preferably, the software logic view acquires function information and module division information from a development document, draws and establishes a software function hierarchical diagram, tracks the design and implementation process of the function, and analyzes whether the software function meets the requirement.
The system logic view analyzes dynamic activities related to software in the embedded system and reflects the running dynamics in the embedded system.
Preferably, the system logic views three aspects of system state, activity and interaction for analysis, and more preferably, analyzes by using state diagrams, activity diagrams (flowcharts) and interaction diagrams (collaboration and timing diagrams) in UML.
More preferably, the system logical view presents dynamic activity of the system with the analyzed objects from each object identified in the system component view. More preferably, the analysis is performed by means of a state diagram, an activity diagram and a communication diagram in the UML tool.
The creating an environment view includes creating a software environment view and a system environment view,
the software environment view analyzes a development environment and a support environment, the development environment influences the quality of a software product, and the support environment influences the running state of the software.
Preferably, the software environment view includes analyzing the influence of the development environment (development tool, development method) on the software quality, and analyzing the compatibility of the support environment (software support and hardware support) and software.
The system environment view analyzes the operation environment of the system, including the physical environment and the climate environment.
Preferably, when a system environment view is established, environment information including the environment where the system is located and environment parameters required to be collected during system operation is obtained from a system development document; for physical and climatic environments, the impact of the environment on the system materials is specified. For environmental parameters, analyzing the great influence of parameter changes on system operation, and analyzing the reasons influencing the abnormal changes of the parameters.
Compared with the prior art, the invention has the advantages that:
the method establishes a top-level accident model of the embedded system, provides a hierarchical multi-view description method aiming at software failure accidents and software interaction accidents, better accords with the characteristics of the embedded system, fundamentally explains the reasons of accidents, and more detailedly and fully describes the process and mechanism of the embedded system software accidents. The method can guide the development of the embedded system and the safety key development of the embedded software, the description of the embedded system and the embedded software is based on the embedded system and the software development engineering, and the control suggestion given by the description and analysis of the method can be applied to the engineering to improve the safety of the embedded system and the embedded software.
Drawings
FIG. 1 is a schematic diagram of a top level accident process model.
In the figure:
| 1 | start of | 6 | Lack of internal safety control or failure of |
| 2 | Software internal defects are excited | 7 | |
| 3 | |
8 | Lack of or failure of real- |
| 4 | |
9 | Real- |
| 5 | Interaction errors caused by |
10 | End up |
Fig. 2 is a schematic diagram of an accident model of the present invention.
FIG. 3 is a problem classification diagram of the accident model of the present invention.
Fig. 4 is a structural diagram of an interface between control software and hardware in an engine control system according to an embodiment of the present invention.
Fig. 5 is a block diagram of an engine control system according to an embodiment of the present invention.
Fig. 6 is a block diagram of the electronic controller of fig. 5.
FIG. 7 is a first level data flow diagram of the functional blocks of an engine control system according to an embodiment of the present invention.
FIG. 8 is an activity diagram of the engine control software "5 ms control task" in an embodiment of the present invention.
FIG. 9 is a timing diagram of the engine control software "5 ms control task" in an embodiment of the present invention.
Detailed Description
The invention is further described with reference to the following figures and detailed description.
The invention relates to an evaluation and analysis method based on an embedded system software multi-view accident model, which mainly comprises the following steps:
(1) a top layer accident occurrence process model;
(2) deep-level problem generation models;
1. the accident occurrence process model of the top layer:
the accident occurrence process model at the top layer divides the reasons of the embedded system software accident occurrence into the failure of the embedded system software and the interaction errors between the embedded software and other components in the system; the direct reason of the embedded system software accident is that danger control failure causes danger spreading to become an accident, the main reason of the accident is that the system enters a dangerous state due to failure of safety constraint, and the root reason of the accident is that problems exist in the embedded system, including software failure and interaction errors between software and other elements of the system.
In this model, the system itself has a safety control, and the occurrence of an accident is caused when a problem occurs simultaneously with the failure of the safety control. The model divides safety control within the system into three categories:
1) and (4) internal control. The internal control refers to safety control designed in the embedded system in advance, and when the defects of the embedded software are excited or interaction errors occur, the internal control can effectively process in time to avoid the system from entering a dangerous state.
2) And (5) real-time control. The real-time control is safety control which is not designed in an embedded system and can process dangers in real time and enable the system to return to normal operation when the system enters a dangerous state due to software defects or interaction errors.
3) And (4) accident control. Accident control refers to control to reduce the loss of an accident after the accident has occurred. The top level accident process model is shown in figure 1, which uses a state diagram to represent the change process of the system. The model mainly comprises the following three aspects:
1) software failures and interaction errors
Since the embedded system has undergone a great number of tests before being actually used, it can be generally considered that the embedded system enters a normal operating state after being started. Software in a normal operating state can be theoretically classified into defective software and non-defective software in terms of whether or not it contains defects. For software without defects, the reason for causing the system to enter a dangerous state is the interaction error of the object software and other system elements; for defective software, the cause of the system entering the dangerous state includes that the software defect is triggered to form a failure besides the interaction error of the object software and other system elements.
2) Internal safety control failure resulting in danger
The design and operation of embedded systems should follow certain security constraints. The safety constraint set relates to a plurality of requirements in the aspects of interface transmission, information communication, task execution flow and time sequence, time, precision, resources and the like in a software system, and jointly constrains the system to form a bounded safety range. On the other hand, some security controls are also usually designed in embedded software or embedded systems in order to avoid accidents. If software failures or interaction errors cause internal safety constraints and design safety controls to fail, the system enters a dangerous state.
3) Real-time hazard control failure leading to accidents
The system in the dangerous state can control the spread of the danger through some real-time control measures and even return the system to the normal safe operation state. If such real-time hazard control fails, the hazard can propagate into an accident.
2. Deep problem generation model
From the incident occurrence process model, it is seen that the root cause of the incident is due to problems in the embedded system, including software failures and software interaction errors with other elements of the system. However, the two kinds of problems in the embedded system are generated specifically, and analysis description needs to be performed by combining specific characteristics of the embedded system and the embedded software.
The problem generation model comprises the steps of establishing a development view, a composition view, a logic view and an environment view of a software layer and a system layer, wherein the software layer describes and analyzes the problem causing the accident from the mechanism of software failure as shown in FIG. 2. The system hierarchy describes and analyzes incident-causing problems from the mechanism by which interaction errors occur between software and other components within the system. See figure 3 for a problem generation model of the present invention based on two levels and four views of problem classification. The method specifically comprises the following steps:
(1) building a development view
The development views comprise a software development view and a system development view, and the software development view focuses on and tracks defects of each development stage of the software and propagation and evolution processes of the defects in different stages. Through the development view of the software, various defect behaviors of the software can be sorted and classified, such as the software development view part in fig. 3. For each large class, further refinements may be made in conjunction with the work content in the respective development phase.
The system development view focuses on and tracks the consistency of the hardware and software interface design and the hardware and software mapping. The consistency of the software and hardware interface design and mapping can be described by a software interface document.
The method specifically comprises the following steps:
1) software development views
And establishing tracking information item by item according to the software requirement specification, analyzing whether the requirement is correct, and tracking whether each requirement is designed, realized and tested in each development stage. As shown in table 1, taking an engine control system as an example, the control functions of the control software of the engine mainly include functions such as engine ground start, steady state control, transition state control, parameter limitation, etc., and these function requirements are tracked and analyzed, and first, it is determined whether each function and sub-function is designed, implemented and tested, and then, it is analyzed whether a problem occurs in different development stages.
TABLE 1 tracking table of the requirements of certain engine system control software
2) System development views
The system development view mainly focuses on software and hardware mapping and interface development. The software and hardware function segmentation information can be obtained from the system document, a software and hardware interface mapping matrix is established according to the interface document, the integrity and consistency of the interface are analyzed, and whether the interface is realized or not is tracked and analyzed.
Also taking an engine control system as an example, the system control software is communicated with hardware such as an analog quantity processing device, a frequency quantity processing device, a closed quantity processing device and a timer, so that the system software and hardware interface structure diagram is shown in fig. 4.
(2) Composition view
The embedded software composition view mainly focuses on programs and documents, wherein module design and division, module units and code composition of the programs are important concerns. All contents of a software program are kept in a software development document, and besides analyzing the correctness and the integrity of codes and modules, the description of software composition also needs to establish an interface matrix between the modules and analyze the consistency of the interfaces.
The embedded system composition view mainly reflects the mutual connection of all components in the system and serves as a structural foundation for describing the system behavior. The description of the system composition is accomplished by building a system composition diagram. The system composition diagram is a static description of the embedded system, and embodies the components of the embedded system and the interfaces between them. These components may be introduced into the logical view of the system as objects of description.
1) Software composition view
The software composition mainly comprises software codes and software documents, which are main contents in software engineering and are not described herein again.
2) System component view
The establishment of the system composition view is mainly to complete the identification of the system composition and the interface. When building a system composition view, hierarchical description from coarse to fine is needed. Taking a certain engine control system as an example, a system composition diagram as shown in the figure, as shown in fig. 5, can be established. The description can be further extended for the control device therein, as shown in fig. 6.
(3) Logical views
The embedded software logic view mainly focuses on the division of software functions and the division of logic levels, namely, the mode of converting requirements into software functions. The system logic view is mainly used for describing dynamic activities related to software in the embedded system and is a reflection of running dynamics in the embedded system.
The embedded software logic view needs to establish a software function hierarchical diagram, track the implementation process of the functions and analyze whether the software functions meet the requirements.
The embedded system logical view is described primarily in terms of system state, activity, and interaction, and may be described using state diagrams, activity diagrams (flowcharts), and interaction diagrams (collaboration and timing diagrams) in UML.
1) Software logical views
The embedded software logic view mainly focuses on the division of software functions and the division of logic levels, namely, the mode of converting requirements into software functions. The function information and the module division information can be obtained from the development document, and a function hierarchical diagram is drawn to track the design and implementation of the function.
Taking a certain engine control software as an example, the user requirements mentioned in the software requirement specification mainly include six aspects, which are shown in the column of "function" in a certain engine system control software requirement tracking table ". In order to realize the functions, the controller control software firstly performs hardware initialization to be suitable for a hardware platform on which the controller control software operates, and then performs data initialization to make data controllable when the corresponding task in the controller control software starts to operate. The software functions mainly comprise signal acquisition, signal processing, fault diagnosis and processing, control logic calculation, control calculation, signal output, communication and other functions. To describe the coordination among these functions in detail, a one-level data flow diagram composed of the functional blocks shown in fig. 7 may be established.
2) Logical view of system
The system logical view mainly presents the dynamic activity of the system, and the described objects come from each object identified in the system composition view. In describing, it may be described by means of state diagrams, activity diagrams and communication diagrams in the UML tool. Taking a certain task in the launch control system as an example, the dynamic information as shown in fig. 8 and fig. 9 can be plotted. In which fig. 8 is an activity diagram of the engine control software "5 ms control task", and fig. 9 is a timing chart of the engine control software "5 ms control task".
(4) And (6) environment view.
The embedded software environment view mainly focuses on development environment and support environment, the development environment influences the quality of software products, and the support environment influences the running state of software. The system environment view mainly describes the operation environment of the system, including a physical environment, a climate environment and the like.
The software environment mainly comprises a development environment and a support environment, and the work content mainly comprises two aspects, namely analyzing the influence of the development environment (development tools, development methods and the like) on the software quality and analyzing the compatibility of the support environment (software support and hardware support) and the software.
1) System environment view
When a system environment view is constructed, environment information including the environment where the system is located and environment parameters which need to be collected when the system operates needs to be obtained from a system development document. For physical and climatic environments, it is necessary to ascertain the impact of the environment on the system materials. For environmental parameters, it is necessary to analyze the large influence of parameter changes on system operation and to analyze possible reasons affecting abnormal changes of these parameters.
The above description is only a preferred embodiment of the present invention, and is not intended to limit the present invention, and all simple modifications, changes and equivalent structural changes made to the above embodiment according to the technical spirit of the present invention still fall within the protection scope of the technical solution of the present invention.
Claims (7)
1. A modeling method based on an embedded system software multi-view accident model is characterized in that the embedded system software multi-view accident model comprises the following steps:
(1) a top layer accident occurrence process model;
(2) a deep problem generation model;
the top layer accident occurrence process model analyzes the reasons of the accident occurrence from two aspects of the failure of the embedded system software and the interaction errors between the embedded software and other components in the system; the safety control in the embedded system comprises internal safety control and real-time danger control, and when the internal safety control fails due to software failure or interaction error, the system enters a dangerous state; when the real-time danger control fails, the danger spreads to form an accident;
the deep problem generation model comprises a development view, a composition view, a logic view and an environment view which are used for establishing a software layer and a system layer;
the software layer analyzes the problem of causing accidents from the mechanism of software failure;
the system level analyzes the problem causing the accident from the mechanism of the interaction error between the software and other components in the system.
2. The modeling method based on the embedded system software multi-view accident model according to claim 1,
in the top accident occurrence process model, the safety control in the embedded system comprises the following steps:
1) internal safety control: the internal safety control is designed in the embedded system in advance, and when the defects of the embedded software are excited or interaction errors occur, the internal control is processed in time to avoid the system from entering a dangerous state;
2) real-time risk control: the real-time danger control is not designed in the embedded system, and when the system enters a dangerous state due to software defects or interaction errors, the danger can be processed in real time and the system can return to the normal operation safety control;
3) accident control: the accident control is a control for reducing accident loss after an accident occurs.
3. The modeling method based on the embedded system software multi-view accident model according to claim 2,
in the top accident occurrence process model, the accident occurrence reasons include the following conditions:
1) software failures and interaction errors
Considering that the embedded system enters a normal operation state after being started, and dividing the software in the normal operation state into defective software and non-defective software; for non-defective software, when the system enters a dangerous state, generating interaction errors for the object software and other system elements; for defective software, when the system enters a dangerous state, the interactive error of the object software and other system elements is formed, and/or the software defect is triggered to form failure;
2) internal safety control failure
The design and operation process of the embedded system follows a certain safety constraint set, the safety constraint set relates to the requirements of interface transmission, information communication, task execution flow and time sequence, time, precision and resources in a software system, and the system is constrained together to form a bounded safety range; meanwhile, related safety control is designed in embedded software or an embedded system; when the software fails or interaction errors cause the failure of an internal safety constraint set and design safety control, the system enters a dangerous state;
3) real-time hazard control failure
The system in the dangerous state controls the spreading of the danger through real-time danger control, or enables the system to return to a normal safe operation state, and if the real-time danger control fails, the danger is spread to form an accident.
4. The modeling method based on the embedded system software multi-view accident model according to claim 1, wherein the establishing of the development view comprises establishing a software development view and establishing a system development view; the software development view tracks the defects in the software development stage and the propagation and evolution processes of the defects in different stages;
sorting and classifying various defect behaviors of the software through a development view of the software, and further subdividing each large class by combining the working contents in respective development stages;
the software development view establishes tracking information item by item according to the software requirement specification, analyzes whether the requirement is correct, and tracks whether each requirement is designed, realized and tested in each development stage;
the system development view tracks consistency of interface design of software and hardware and software and hardware mapping;
the consistency of the software and hardware interface design and mapping is analyzed through a software interface document;
the system development view acquires software and hardware function segmentation information from a system document, establishes a software and hardware interface mapping matrix according to an interface document, analyzes the integrity and consistency of the interface, and tracks whether the analysis interface is realized.
5. The modeling method based on the embedded system software multi-view accident model according to claim 1 or 4,
establishing a composition view comprises establishing a software composition view and a system composition view, analyzing a program and a document by the software composition view, and analyzing the program and the document comprises analyzing the module design and division, module units and code composition of the program; all contents of a software program are reserved in a software development document, and the analysis of software composition comprises the steps of analyzing the correctness and the integrity of codes and modules and establishing an interface matrix between the modules to analyze the consistency of the interfaces;
the system composition view analysis system comprises a system composition view analysis system and a system composition view analysis system, wherein the system composition view analysis system is used for analyzing the mutual relation of all components and is used as a structural basis for describing the system behavior, and the system composition view is static description of an embedded system and embodies the components of the embedded system and interfaces among the components;
the establishment of the system composition view completes the identification of system composition components and interfaces; when the system composition view is built, the hierarchical description is performed from thick to thin.
6. The modeling method based on the embedded system software multi-view accident model according to claim 1 or 4,
establishing a logic view comprises establishing a software logic view and a system logic view, wherein the software logic view analyzes the division of software functions and the division of logic levels, namely the mode of converting requirements into software functions; the software logic view acquires function information and module division information from a development document, draws and establishes a software function hierarchical diagram, tracks the design and implementation process of functions, and analyzes whether the software functions meet the requirements or not;
the system logic view analyzes dynamic activities related to software in the embedded system and reflects the running dynamics in the embedded system;
the system logic views three aspects of system state, activity and interaction for analysis, and the analysis is carried out by using a state diagram, an activity diagram and an interaction diagram in the UML;
the system logic view presents the dynamic activity of the system, and the analyzed objects come from each object identified in the system composition view; in the analysis, the description is made by means of a state diagram, an activity diagram and a communication diagram in the UML tool.
7. The modeling method based on the embedded system software multi-view accident model according to claim 1 or 4,
creating an environment view includes creating a software environment view and a system environment view,
the software environment view analyzes a development environment and a support environment, the development environment influences the quality of a software product, and the support environment influences the running state of the software;
the software environment view comprises the steps of analyzing the influence of a development environment on the software quality and analyzing the compatibility of a support environment and software;
the system environment view analyzes the operating environment of the system, including the physical environment and the climate environment;
when a system environment view is established, acquiring environment information from a system development document, wherein the environment information comprises the environment where the system is located and environment parameters needing to be acquired during system operation; for physical environment and climatic environment, the influence of the environment on system materials is determined; for environmental parameters, analyzing the great influence of parameter changes on system operation, and analyzing the reasons influencing the abnormal changes of the parameters.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710986470.3A CN107885607B (en) | 2017-10-20 | 2017-10-20 | Modeling method based on embedded system software multi-view accident model |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710986470.3A CN107885607B (en) | 2017-10-20 | 2017-10-20 | Modeling method based on embedded system software multi-view accident model |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107885607A CN107885607A (en) | 2018-04-06 |
| CN107885607B true CN107885607B (en) | 2020-11-20 |
Family
ID=61781877
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710986470.3A Expired - Fee Related CN107885607B (en) | 2017-10-20 | 2017-10-20 | Modeling method based on embedded system software multi-view accident model |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107885607B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108762749B (en) * | 2018-05-24 | 2021-12-21 | 福州大学 | System object diagram automatic generation method based on code analysis |
| CN113705616B (en) * | 2021-07-30 | 2024-05-10 | 三维通信股份有限公司 | Model construction method, software defect prediction method, device and electronic device |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1928816A (en) * | 2006-09-26 | 2007-03-14 | 武汉大学 | Model drive for embedded system software and component development method |
| CN103354055A (en) * | 2013-07-09 | 2013-10-16 | 宁海斌 | Simulating system for simulated training of electricity-consuming network operation |
| CN103677849A (en) * | 2013-12-26 | 2014-03-26 | 北京控制工程研究所 | Embedded software credibility guaranteeing method |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090009960A1 (en) * | 2007-07-05 | 2009-01-08 | Melanson Ronald J | Method and apparatus for mitigating dust-fouling problems |
| US9459840B1 (en) * | 2015-03-31 | 2016-10-04 | Toyota Jidosha Kabushiki Kaisha | Timing-oriented and architecture-centric system design using contracts |
| CN105301481A (en) * | 2015-11-20 | 2016-02-03 | 上海无线电设备研究所 | Circuit testing method and applicable testing system |
-
2017
- 2017-10-20 CN CN201710986470.3A patent/CN107885607B/en not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1928816A (en) * | 2006-09-26 | 2007-03-14 | 武汉大学 | Model drive for embedded system software and component development method |
| CN103354055A (en) * | 2013-07-09 | 2013-10-16 | 宁海斌 | Simulating system for simulated training of electricity-consuming network operation |
| CN103677849A (en) * | 2013-12-26 | 2014-03-26 | 北京控制工程研究所 | Embedded software credibility guaranteeing method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107885607A (en) | 2018-04-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Abdulkhaleq et al. | A comprehensive safety engineering approach for software-intensive systems based on STPA | |
| Kormann et al. | Automated test case generation approach for PLC control software exception handling using fault injection | |
| CN107885607B (en) | Modeling method based on embedded system software multi-view accident model | |
| Ibrahim et al. | State of the Art in Software Tool Qualification with DO-330: A Survey. | |
| Mosleh et al. | A model-based human reliability analysis framework | |
| Li et al. | Safety analysis of software requirements: model and process | |
| Yang | Software safety testing based on STPA | |
| Silva et al. | Towards making safety-critical systems safer: learning from mistakes | |
| Kassab | Testing Practices of Software in Safety Critical Systems: Industrial Survey. | |
| Ledinot et al. | Joint use of static and dynamic software verification techniques: a cross-domain view in safety critical system industries | |
| Jharko | Formalizing the Safety Functions to Assure the Software Quality of NPP Safety Important Systems. | |
| Jharko | Safety Functions in the Software Quality Assurance of NPP Safety Important Systems | |
| EP3961406A1 (en) | Computer-implemented method and computerized device for testing a technical system | |
| Hou et al. | Software interface failure modes and effect analysis based on UML | |
| Feiler et al. | Architecture-led Requirements and Safety Analysis of an Aircraft Survivability Situational Awareness System | |
| Wang et al. | A research for embedded system software accident mechanism | |
| CN113434120B (en) | Software development method based on data security | |
| Hwang et al. | Design of automatic testing tool for railway signalling systems software safety assessment | |
| Zhou et al. | Safety analysis and requirements verification of electronic checklist system based on STPA | |
| Jharko | Safety Function of Soft-and Hardware Complex within Aspect of NPP Safety Important Systems | |
| Rufino et al. | NORTH-Non-intrusive Observation and RunTime verification of cyber-pHysical systems | |
| Vyas et al. | The applications of SFTA and SFMEA approaches during software development process: an analytical review | |
| Suo et al. | Filling the gap between IMA development and safety assessment through safety-driven model-based system engineering | |
| Zavvar et al. | A method based on fuzzy system for assessing the reliability of software based aspects | |
| Hwang et al. | Development of automatic testing tool for software coding rules for railway signalling |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20201120 Termination date: 20211020 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |