• <tr id="yyy80"></tr>
  • <sup id="yyy80"></sup>
  • <tfoot id="yyy80"><noscript id="yyy80"></noscript></tfoot>
  • 99热精品在线国产_美女午夜性视频免费_国产精品国产高清国产av_av欧美777_自拍偷自拍亚洲精品老妇_亚洲熟女精品中文字幕_www日本黄色视频网_国产精品野战在线观看 ?

    A formal approach using SysML for capturing functional requirements in avionics domain

    2020-01-09 01:04:48ShofnZHUJinTANGJenMrieGAUTHIERRpheFAUDOU
    CHINESE JOURNAL OF AERONAUTICS 2019年12期

    Shofn ZHU, Jin TANG, Jen-Mrie GAUTHIER, Rphe¨l FAUDOU

    a Beijing Aeronautical Science and Technology Research Institute, COMAC, Beijing 102211, China

    b Samares-Engineering, Blagnac 31700, France

    Abstract In this work, a Model-Based Systems Engineering approach based on SysML is proposed.This approach is used for the capture and the definition of functional requirements in avionics domain. The motivation of this work is triple: guide the capture of functional requirements,validate these functional requirements through functional simulation,and verify efficiently the consistency of these functional requirements.The proposed approach is decomposed into several steps that are detailed to go from conceptual model of avionics domain to a formal functional model that can be simulated in its operating context.To achieve this work,a subset of SysML has been used as an intermediate modelling language to ensure progressive transformation that can be understood and agreed by system stakeholders. Formal concepts are introduced to ensure theoretical consistency of the approach.In addition,transformation rules are defined and the mappings between concepts of ARP4754A civil aircraft guidelines and SysML are formalized through meta-model. The resulting formalization enables engineers to perform functional simulation of the top-level functional architecture extracted from operational scenarios. Finally, the approach has been tested on an industrial avionics system called the Onboard Maintenance System.

    KEYWORDS Avionics systems;Conceptual model;Functional simulation;Model-Based Systems Engineering

    1. Introduction

    In the avionics domain, certification rules and ARP4754A1guidelines require that all engineering artifacts are traced to requirements. This makes capture of requirements a crucial sub process of the overall development process: any missed or misunderstood requirement can lead to wrong system definition and then wrong realization.With pure document-centric engineering approach, wrong or missing requirements may be detected very late in the system development life cycle, sometimes during product validation. Early validation is needed to decrease risk of such situation.In addition,systems become more and more complex with rising number of functions and of technologies to integrate,2which leads to a rising number of requirements to manage and engineer. Verification of individual requirements can still be addressed by humans but not the global consistency of the requirements set as the cross-checking leads to millions of cases.So, it is fundamental to transition to a ‘‘consistent-by-construction” approach.

    Model Based Systems Engineering(MBSE)is seen today as a good approach to allow early validation on model and to support building of a consistent set of system requirements.In this article, a SysML3approach is used to support the ARP4754A capture requirements process.The approach relies on two fundamental goals: ensuring a consistent by construction set of functional system requirements using models and giving means to execute those functional system requirements for early validation of the system seen as a black box. To achieve those goals, the proposed approach needs to address three main needs: being formal, enabling automation, and enabling execution for validation. The contributions of this article are threefold. First, a formalization of operational scenarios,functional scenarios and functional chains is proposed.Second, a transformation between operational scenarios and functional chains is defined and implemented. Finally, a mapping between the formal framework, SysML, and the ARP4754A is illustrated and formalized with meta-models.

    In this way,the proposed approach permits to capture blackbox operational scenarios using SysML sequence diagrams.Then,the functional scenarios are identified and combined into functional chains modeled by SysML activity diagrams.From the model, functional interface requirements can be identified and captured. Finally, the simulation of top-level functional chains model can be achieved to validate continuously functional chains against operational scenarios. Experiments have been conducted on an industrial case study:the Onboard Maintenance System(OMS)which is an avionics subsystem.

    The rest of the paper is organized as follows: existing related work are discussed in Section 2.The capture of requirements process is introduced in Section 3. Section 4 details the proposed approach with formal concepts and meta models to reach consistent and executable functional specification models. Experiments and results are presented and discussed in Section 5.Finally,the conclusion and future work are outlined in Section 6.

    2. Related work

    Writing requirements in natural language remains the most common approach currently found in industry.For more than 20 years most industrial companies involved in aerospace domain have put strong efforts on the quality of their requirements to reduce errors and ambiguities.After some local initiatives,good practices have been shared between different actors and different domains and today we can find good practices on writing requirements at INCOSE.4Most of those practices can be organized into patterns or boiler plates5,6and can be completed by the support of ontologies7to guide use of words and of their relations according to the domain and associated semantics. When applying those practices, requirements are of better quality.8But those approaches based on constrained or guided natural language are not yet very efficient to address relationships between requirements, i.e. dependencies, induction, and logic, even with support of ontologies. Those approaches do not help much in verification of global consistency.

    Through the advent of standard modelling languages like OMG UML/SysML, there have been many attempts to use semi-formal modelling approach to capture functional needs and functional constraints on a system of interest. For instance, IBM Harmony SE,9or SysMOD.10Those approaches provide some interesting results in detection of issues concerning consistency of requirements and missing requirements. But as they rely on semi-formal language with remaining semantic variation points,there can still exist multiple interpretations.

    Model-Based Systems Engineering approaches have been proposed for avionics systems.In Refs.11,12the authors present a SysML based approach to ensure consistent allocation between functional layer and software architecture. Interface Control Document (ICD) for ARINC 664 can be generated from the model.In addition,checkers are implemented to verify the consistency of the allocation between functional layer and logical or physical layer. The main difference with our approach concerns the requirements capture not considered in Refs.11,12.

    A method to optimize function allocation,and system configuration using constraints and Capella architecture is presented in Ref.13. The method succeeded to perform design space exploration and optimization of a Distributed Integrated Modular Avionics. This method is complementary to the one proposed in this article. Indeed, the synthesis of the highlevel functional architecture from operational scenario is at a higher level compared to the method proposed in Ref.13.Model-based robustness testing for avionics software has been investigated in Ref.14. SysML based safety analysis in presented in Ref.15. It combines MBSE with SysML and modelchecking to ease communication between system engineer and safety engineer.Refs.14,15focus on V&V rather than focusing on how to capture consistently functional requirements while ensuring functional validation using simulation in the context of ARP4754.

    Using a formal modelling language permits to remove all possible ambiguities related to different possible interpretations. B modelling language, for instance, has been used with success on RATP Meteor subway line in Paris16and more recently Event-B to build formal requirements refinement using patterns17. The use of Petri Nets to formally verify scenarios and use cases has been proposed in Ref.18.Stimulus tool from Argosim19allows expressing system requirements through a formal model.From that model it becomes possible to launch simulation and leverage the results to identify errors in requirement expression.

    This tool is thus considered as an enabler for requirement validation. FORM-L,20designed by EDF Research, aims at better describing requirements in multi-physical models and ease their verification.SDL-RT21is a formal and standardized language to describe the structure and the behavior of communicating systems.

    Synthesis of Activity Diagram from Sequence Diagrams are proposed in Ref.22.To that end,the authors identified patterns of Sequence Diagrams and defined rules for mapping them to corresponding parts of Activity Diagram.Finally,the work of Briand et al.23,24propose to generate activity diagrams from use cases. In particular, they propose restriction rules on the use of natural language to formalize the way preconditions,post-conditions, and flow steps are written within use cases.In the present work,sequence diagrams should respect conformance rules derived from systems theory, i.e. causality and data continuity.

    3. Requirements capture process

    COMAC (Commercial Aircraft Corporation of China)designed an SE process in line with ARP4754A. According to project management process, the avionics system development starts from project feasibility study and project approval,complying with ARP4754A and AIR6110. The avionics system development consists the following five phases:

    (1) JCDP(Joint Concept Design Phase)mainly focusing on feasibility study, project approval, sub-system bidding and supplier selection.

    (2) JDP (Joint Definition Phase) including system development planning, capture and validate requirements, preliminary design, system airworthiness and test environments definitions.

    (3) Development Verification&Manufacture Phase,including system critical design phase, manufacture for development phase, lab verification phase.

    (4) Certification Phase, including ground onboard test phase, flight test phase.

    (5) Post-certification Phase.

    The contributions of this article fit into the JDP,when capture and validation of requirements is performed. The Fig. 1 outlines the inputs and the outputs of the requirements capture activity.Capturing requirement starts by taking onto consideration the results of JCDP, i.e. customer requirements, reuse requirements, aircraft level requirements, and allocated aircraft level functions to the corresponding avionics systems.In addition, results of Functional Hazard Analysis (FHA)and Preliminary Aircraft Safety Assessment (PASA) are considered all along the requirements capture activity. The goal of this activity is to obtain a preliminary set of high-level System Requirements Specification(SRS)for System Requirements Review (SRR). In this article, non-functional requirements such as safety or performance are parts of further work.

    4. Using SysML to guide requirements capture

    In this section a set of concepts for capturing requirements in a progressive and iterative approach are defined. Fig. 2 depicts the proposed iterative approach.The first step consists in capturing functional needs using a semi-formal model, with some flexibility in the expression so that it does not require too much knowledge on notation. Focus is put on the structuring of needs using SysML Use Cases (UC). It is discussed in Section 4.1.

    In a second step, a guided dialog to solve remaining ambiguities is performed: this step is called ‘‘semantics clarification”. It permits to progressively raise the level of formalism of the operational scenarios. This step is discussed in Section 4.2.

    The formalized scenarios are then combined to produce executable top-level functional behavioral model thanks to the use of transformation rules.The resulting model conforms to Foundational subset for executable UML(FUML),25a formal subset of UML that provides execution semantics. Concurrently, we use each scenario to produce a simple behavioral model for each system actor (human operator or external system in interaction with considered system). Those models are used to trigger events to the system model as expressed in the operational scenarios.The top-level functional behavior of the system can then be automatically simulated in its functional operating context for each black box operational scenario.It provides a convenient means to support the validation of the system functional interfaces. Note that scenarios are also used to identify modes of operations, but this is beyond scope of this article. The approach ensures that final model is traced to initial functional requirements or assumptions made in case it was not possible to get customer feedback. It conforms to ARP4754A recommendations on traceability and provides support for impact analysis in case of any change in the input functional requirements. The progressive definition of functional chains and their simulation are discussed in Section 4.3.

    Fig.1 Capture requirements process overview.

    Fig.2 Flowchart of proposed approach.

    In the rest of this section,formal definitions of key concepts are proposed. First let us define the basis of the framework with a formal definition of a System from Ref.26. This system definitions is a refinement of the formal definition of a System initially proposed by Wymore.27A System of Interest(SoI)is a 7-tuple defined by:

    where Tsis a time scale called the time scale of the system,Input= {In, I}and Output= {Out, O}are input and output datasets, S is a non-empty ε-alphabet, called the ε-alphabet of states,q0is an element of S called the initial state,F is a function called functional behavior such that:

    and Q is a function called states behavior such that:

    An ε-alphabet is defined by Ref.26to be a set of data (any element that can be exchanged between any real systems)containing the universal blank symbol ε. In addition, a dataset is defined to be a pair D ={D, B}, where D is an ε-alphabet,and B is a pair {read, write} that enables to implement data behavior (persistent, consumable, accumulative).

    In the proposed formal framework, ∑is assumed to be a causal system, i.e. that requires a semantic notion of time to respect an intuitive notion of causality28:if one event A causes another event B, then every observer should see A occurring before B. Finally, we consider ∑to be an open system in the sense of Von Bertalanffy,29i.e. a system that interacts with its environment. Interactions can be energy, matter, or information transferred to or from the system boundary.In the rest of the article,the symbol Γ is used to denote a set of elements,and ε for the empty element.

    4.1. Structuring needs with use cases in avionic context

    In the context of civil aircraft engineering, the use of ARP4754A is strongly recommended. ARP4754A suggests identifying aircraft and system-level functions for the development of the aircraft or a system of the aircraft.

    The first step of the proposed approach for requirements capture is to structure the needs extracted from customer and aircraft level requirements input documents. In the proposed approach, SysML use cases support such structuring activity. In Ref.30the authors give practices concerning effective use case identification and modelling. At first, by definition, a use case should bring value for at least one system stakeholder. For instance, one of the aircraft flight recorder main functional values is to register the recent history of the flight so that it can be made available to the National Transportation Safety Board in case of accident. Next, a use case should be autonomous in its execution, meaning that it can be executed without the need of another use case except included use case. Finally, a use case should also be complete,meaning that,at the end of the UC execution,the system is in a stable or error state.

    Raw use cases are first defined from the aircraft functions allocated to the system. Those raw use cases are analyzed and checked to ensure that they respect rules including functional value for at least one stakeholder, autonomy and completeness as mentioned previously. Next, roles played by end users and external systems are identified and formalized as actors from all input stakeholders’ documents (including customer’s). SysML refine relationship is used to create links between use cases and aircraft level requirements allocated to the system under study.Those traceability links can be defined and maintained in a Use Case Diagram or using a traceability matrix.

    4.2. Capturing black-box operational scenarios

    After structuring functional needs within use cases, the expected behavior of the system is captured for each use case using black-box operational scenarios. As shown on Fig. 3,the black-box operational scenarios are defined as SysML interactions owned by UC (owned behaviors). Those interactions are represented graphically by Sequence Diagrams. For each use case,the focus is put on functional messages between system and use case’s associated actors. The first message shows the triggering event of the scenario. The expected responses of system to an input event can be described with reflexive messages attached to the Sequence Diagram lifeline representing the System of Interest. The capture of those reflexive messages is useful to provide a first list of top-level functions,but it is not main priority at that stage because that list is likely to change when other requirements are considered.Focus is rather put on functional interfaces, i.e. the incoming and outgoing functional messages, and on the causal dependencies between those functional messages. The goal is to deduce consistent functional scenarios that cross the system of interest and interact with its functional operating context represented by actors.

    The following defines the formal concepts used in this conceptual model. In addition, constraints on types and causality are formally defined.

    A black-box operational scenario is composed of one or more functional scenarios. A black-box operational scenario shall contain lifelines that represent either the System of Interest or an Actor.Let βsthe black-box operational scenario to be a 3-tuple defined by:

    where ΓLis the set of lifelines, Γφis the set of functional scenarios, and ftis a lifeline typing function defined by:

    In the proposed framework,a functional scenario φ ∈Γφis a causal consistent sequence of functional messages that starts by an incoming message (external request), followed by the system expected behavior as response to that request. The expected behavior is represented by a SysML execution specification (thin green rectangle on the lifelines). Let φ a functional scenario on a System ∑to be the 3-tuple defined by:

    Fig.3 Black-box operational scenario examples with only one functional scenario.

    where μ0is a triggering incoming functional message, Γμis a set of functional messages, and?is a function called occurs at that associates a message to a time instant:

    A functional message is emitted by a source lifeline and received by a target lifeline. In the proposed framework, three kind of message are defined:incoming,outgoing and reflexive.Incoming and outgoing messages carry functional data (data,material or energy) while reflexive messages specify internal functions. Let μin,μout∈Γμto be a functional incoming and outgoing message defined by the 3-tuple:

    where,source and target are respectively the source and target lifelines in ΓL,and data is a dataset. Reflexive functional message can now be defined. Let μra functional message defined by the 3-tuple:

    A functional scenario shall be causal consistent for each functional message.The causal dependency between two functional messages means that it always exists a causal relationship between these two messages. Therefore, reflexive and outgoing messages shall be considered as being consequences of new external events (incoming messages) or internal events(reflexive messages). Indeed,the System does not take any initiative by itself: if μ is a reflexive message or an outgoing message, then it has sense and exists because of a previous cause,e.g. a request from an actor. In addition, each outgoing message has sense and exists because of an internal cause, i.e.the system reaction.

    These causality properties are directly derived from the causality property stated in the general system theory29:a system’s output is a consequence of given system’s inputs and internal state change.

    Let φ be a functional scenario, μ0be an incoming message occurring at time t0and that triggers a new execution, Γμinthe set of incoming messages, Γμoutthe set of outgoing messages,and Γμrthe set of reflexive messages,then φ is said causal consistent if and only if:

    The meta model of the Fig. 4 shows the link between the previously defined formal concepts, SysML concepts, and the ARP4754A concepts.The data carried by functional incoming and outgoing messages are mapped to SysML signal concept since signals can be used to specify communication between systems and flow properties such as data, material or energy.Shortcut relations are used for simplification purpose: real associations can be found in the SysML specifications.

    4.3. Definition of executable functional chains

    The goal of this step is to combine all the functional scenarios that start with the same incoming message to define executable functional chains.As depicted by the Fig.5,SysML activity concept is used to formalize a set of functional chains and Activity Diagram(AD)to represent it.This last is a directed graph G={V,E},31where V is set of vertices and E is a set of edges.The vertices V are SysML actions and edges E of the graph are SysML control or object flows. SysML actions can be Call Behavior Action (call to Function 1), Accept Event Action(First Message),and Send Signal Action(Final Message).This activity is executable by any fUML animation engine.

    A functional chain connects the system functional interfaces to system function calls. Therefore, a functional chain consumes system’s inputs to produce system’s outputs through the activation of nested function calls.Let ξ,a functional chain to be a 4-tuple defined by:

    Fig.4 Meta model for black-box operational scenarios.

    Fig.5 Example of executable top-level functional chains.

    where Input and Output are datasets(see Definition(1)),G is a nested graph of function calls, and fpsis a function called system functional execution such that:

    There is no strict consensus on ‘‘function” definition between the considered domains: the ARP4754A gives its own definition,while the INCOSE Systems Engineering Hand-Book and INCOSE SEBoK glossary32propose slightly different definitions. In the proposed framework, a system function is defined to be the intended behavior of a system that consumes functional flows and produces functional flows regardless of implementation.

    This definition is a combination of the definitions given by the ARP4754A and the SE HandBook. The concepts of function definition and function call are separated.This separation is motivated by the need of reusable functions.In that way the same function can be called in several architectures, or several models.With that separation,the behavior of a given function definition can be expressed by a nested directed graph G of nodes V representing lower-level functions calls.

    Let ψ, a function definition to be a 5-tuple defined by:

    where ψinand ψo(hù)utare function input and output datasets,G={V,E}is a nested graph where V is a set of function calls and E is a set of functional flows,fpis a functional called function data production such that:

    and fψis a function called function definition instantiation that associates a typing function call to its definition:

    The meta model of the Fig. 6 summarizes the link between the previously defined formal concepts, SysML and the ARP4754A. Within the framework, accept event actions and the send signal actions are also linked to signal. Therefore,the signal concept become a shared concept between operational scenario and functional chains. Consequently, signals combine the different datasets usage (scenario) into a single definition that can be used later during functional chains extraction and refinement.

    4.4. Transformation rules

    Fig.6 Meta model for Functional Chain.

    The transformation step consists in combining functional scenarios to obtain a single definition of the top-level functional architecture that conforms to those scenarios. In addition,the same rules are applied to extract the simulation context and executable abstract test cases from the operational scenarios. To illustrate the combining approach, let’s take the two scenarios of the Fig.3.First,from the reception of a message,a new execution specification is created. Then, a new functional chain is created, through its processing with internal functions, and potentially sending and receptions of message to and from other actors. In our example, the second operational scenario starts with the same incoming message than in the first scenario. In that case, their respective execution logic is combined by adding SysML decision node. The Fig. 5 depicts the resulting top-level functional architecture obtained from the scenarios.

    Adding a decision node leads to a condition that shall be specified. In that case, two situations are identified:

    (1) the condition is directly dependent of the result of the Function 1 or of the first message value.

    (2) there is a missing function that provides the condition for routing to one branch or another.

    In the first case,a functional interface shall be created using SysML Pin. Then, an Object Flow is created to link the pin with the decision node. In the second case, a new function is added to complete the functional architecture, leading then to a new functional requirement. When such decision must be made, the customer is invited to clarify and approve the condition.

    The mapping presented in Table 1 permits to create an activity diagram that contains an arrangement of action nodes representing function activation and function calls. For each use case, an activity is generated. This last is a container for functional combined behaviors. Signal concept is used to formalize message contents exchanged asynchronously between systems. Reflexive messages refer to internal functions of the system. Hence, both an activity (the function definition), and its associated call behavior action, (the function call) are generated.

    Those call behavior actions,as parts of the system reaction,are put in the structured activity node. The order and the causality of messages are preserved using control flows.Finally, for each outgoing message, a signal and a send signal action are generated to formalize sending of message.

    5. Experiment results and discussion

    Experiments have been conducted on the OnBoard Maintenance System (OMS), which is an avionics subsystem. The OMS encompasses functions to assist in the maintenance operations, troubleshooting problems, and monitoring and isolation of software anomalies that occur during aircraft mission. One major objective of an OMS is to provide Human-Machine Interface for maintenance and service crew to support maintenance and aircraft reconfiguration. OMS is of crucial importance to aircraft safety and aeronautical maintenance. As a transverse system, OMS is interconnected withalmost all the onboard systems and aircraft functions,and acts as an ideal role for MBSE.2

    Table 1 Semantics mapping between scenarios and functional chains.

    5.1. Experiments and results

    During requirement capture, 8 main use cases and 4 actors were identified for the OMS.Among those use cases,the three depicted on the Fig. 7 were used for experiments. Those use cases were chosen to cover important functions and communication aspects of the OMS.

    (1) Execute ground tests: this use case provides functionality with the regards to aircraft equipment test management and test execution. This use case has a lot of interactions with aircraft equipment and with maintenance technician. For instance, while the aircraft in on ground,the maintenance technician can execute aircraft equipment test procedures from the OMS. The OMS then retrieve test results and give feedbacks to the technician.

    (2) Aircraft Condition Monitoring Function (ACMF): it

    provides important functionality with regards to failure messages and health monitoring of aircraft equipment.

    Fig.7 Chosen use cases for experiments.

    (3) Upload data to target member system: it provides important functionality with regards to aircraft software equipment configuration and maintenance.

    From those 3 use cases 17 operational black-box scenarios were derived, containing 108 functional messages between actors and the OMS. After semantics unification, functional messages were reduced to 71 messages.Then,using the semantics mapping of Table 1,the scenarios were automatically combined to create executable top-level functional chains. An excerpt of functional chains is depicted on the Fig.8.It shows three functional chains containing control flow(dashed arrow)and object flows (continuous arrows). The object flows (functional flows) are added by the engineer since the combining of scenario can only deduce control flow (see Table 1).

    Several benefits were identified when applying the approach.The first benefit concerns the semantics clarification:the team was able to work collaboratively to progressively formalize the operational scenarios. The second benefit concerns early functional validation: the team was able to run and debug the operational scenarios and found functional inconsistencies such as missing data or inconsistencies between several scenarios.The third benefit concerns the identification of missing functions, i.e. functions not identified in scenarios, during scenarios combining.

    This last point is important since getting complete requirements is mandatory.Finally,the approach provides direct navigation to impacted functions thanks to traceability.

    A plugin has been realized for the SysML tool Cameo System Modeler33This plugin enables to check the use cases and the scenarios regarding the causal consistency and the types of the lifeline.The scenario combining,and the automatic synthesis of function definitions and functional chains has been implemented.To map with SysML the algorithm generates five elements for each incoming triggering message:a signal,signal event for signal reception event,an accept event action for the subscription of system waiting for such event, a structured activity node for system reaction on signal reception and control flow between accept event action and structured node to reflect causality.

    Fig.8 Functional chains excerpt from execute ground test.

    5.2. Discussion

    Creating black-box operational scenarios using Sequence Diagrams can be conducted in two ways: either informal or formal. The informal way may lead to inconsistencies concerning use case granularity or functional messages causality. On the contrary, the formal way ensures consistency by construction, helps removing ambiguities in the first iterations and then allows reaching good quality (mature) requirements quickly.34

    The proposed approach aims at providing formal blackbox operational scenarios to identify and remove ambiguities early in the development cycle and to support simulation of functional requirements to ease their validation by customer.However,using a formal notation could be a strong constraint.Hence, the engineers first create simple Sequence Diagrams with a small subset of SysML concepts and some limited guidance through basic checking rules (causality, consistency between UC and scenarios). The engineers are free to use natural language to create the messages between the System and the actors. Then, the semantics of the messages is clarified(see Fig. 2). For instance, let us say that a functional message is named Start Request, and that another functional message in another scenario (defined by someone else) is named Start message.In such a case,there is a great chance that both messages represent same semantics (start request): those two messages are unified into one single definition.

    Finally, the OMS case study may introduce bias over the interpretation of the results.Indeed,the software nature of this system did not permit to cover all the aspect of a cyberphysical systems. Therefore, continuous aspects of a system should be considered and formalized. In addition, impacts on the simulation when continuous behavior is specified shall be investigated.

    6. Conclusions

    (1) A SysML method for capturing requirements is developed in this paper. The method starts from stakeholder requirements and reach functional system requirements through formal SysML model.The major concepts have been formalized and linked to SysML concepts and ARP4754A concepts using a meta model-based approach.

    (2) The automatic synthesis of functional chains from scenarios permitted to ensure automatic traceability from functions to scenarios.In addition,scenarios combining led to identification of missing functions. The proposed approach permitted to work in team as use cases were designed to be independent. Finally, the automatic synthesis of simulation context and was meaningful to execute and verify the model under design and to prepare V&V activities.

    (3) Currently the developed approach does not consider the temporal validity of the functions. The approach shall consider states and modes and add a transformation step to split functional chains into one top level state machine completed with a set of smaller Activity Diagrams.

    (4) The proposed approach should also be able to generate textual system functional requirements and functional interfaces. It could be done by using patterns based on functional chains.Those patterns still need to be formalized and the generation shall be automated with special attention to traceability.Finally,the inputs coming from Functional Hazard Analysis (FHA) and Preliminary Aircraft Safety Assessment(PASA)shall also be considered. The links between MBSE and MBSA (Model Based Safety Analysis) should be investigated.

    Acknowledgements

    This article results from an MBSE Integrated Project Team(IPT).The work was done within COMAC Beijing Aeronautical Science and Technology Research Institute.We are warmly grateful to Jiang XIN for his support to this project. We also kindly thank Jie DAI, Xie MIN, Cary WANG, and Wang CHEN, for the construction of the case study and for their valuable comments.

    女警被强在线播放| 国产99久久九九免费精品| 亚洲自偷自拍图片 自拍| 妹子高潮喷水视频| 亚洲第一青青草原| 成人手机av| 人妻久久中文字幕网| 国产激情欧美一区二区| 国产精品1区2区在线观看.| 欧美av亚洲av综合av国产av| 精品国产乱码久久久久久男人| 真人一进一出gif抽搐免费| 黄色丝袜av网址大全| 欧美性长视频在线观看| 在线视频色国产色| 满18在线观看网站| 亚洲男人的天堂狠狠| 超碰成人久久| 无遮挡黄片免费观看| videosex国产| 97超级碰碰碰精品色视频在线观看| 国产精品电影一区二区三区| 老司机靠b影院| 黄片小视频在线播放| 日本 欧美在线| 婷婷丁香在线五月| 欧美国产精品va在线观看不卡| 国产野战对白在线观看| 国产伦人伦偷精品视频| 久久久国产成人精品二区| 中文字幕高清在线视频| 午夜福利18| 视频区欧美日本亚洲| 国产熟女午夜一区二区三区| 人人澡人人妻人| 亚洲国产高清在线一区二区三 | 成年人黄色毛片网站| 正在播放国产对白刺激| 精品国产超薄肉色丝袜足j| 精品国产美女av久久久久小说| 日韩av在线大香蕉| 丰满人妻熟妇乱又伦精品不卡| 国产黄片美女视频| 中文字幕人成人乱码亚洲影| 亚洲五月天丁香| 国产激情久久老熟女| 亚洲va日本ⅴa欧美va伊人久久| 99国产极品粉嫩在线观看| 久久久久久国产a免费观看| 国产熟女午夜一区二区三区| 波多野结衣巨乳人妻| 12—13女人毛片做爰片一| 黄片小视频在线播放| 男人的好看免费观看在线视频 | 黑人巨大精品欧美一区二区mp4| 亚洲片人在线观看| 18禁裸乳无遮挡免费网站照片 | 啦啦啦免费观看视频1| 少妇裸体淫交视频免费看高清 | 国产精品爽爽va在线观看网站 | 免费在线观看日本一区| 此物有八面人人有两片| 成在线人永久免费视频| 国产区一区二久久| 欧美 亚洲 国产 日韩一| 2021天堂中文幕一二区在线观 | 曰老女人黄片| 国产私拍福利视频在线观看| 久久久国产成人免费| 日韩大尺度精品在线看网址| 久久久久久人人人人人| 午夜福利免费观看在线| xxxwww97欧美| 美女国产高潮福利片在线看| 久久精品国产亚洲av香蕉五月| 日韩av在线大香蕉| 久久久久精品国产欧美久久久| 国语自产精品视频在线第100页| 亚洲精品久久成人aⅴ小说| 99国产精品一区二区蜜桃av| 久久人妻av系列| 亚洲中文字幕日韩| 亚洲中文av在线| 黄色片一级片一级黄色片| 真人做人爱边吃奶动态| 中文字幕人成人乱码亚洲影| 夜夜爽天天搞| 国产成人av激情在线播放| 少妇粗大呻吟视频| 日本免费a在线| 亚洲成国产人片在线观看| 欧美绝顶高潮抽搐喷水| 国产精品久久久人人做人人爽| 1024视频免费在线观看| 亚洲欧美日韩高清在线视频| 色在线成人网| 黄片大片在线免费观看| 日本一本二区三区精品| 成人av一区二区三区在线看| 日韩欧美免费精品| 亚洲精品国产一区二区精华液| 精品福利观看| 亚洲精品美女久久久久99蜜臀| 精品欧美国产一区二区三| 日日夜夜操网爽| 亚洲全国av大片| 在线天堂中文资源库| 国产精品久久视频播放| 很黄的视频免费| 精品久久蜜臀av无| 亚洲欧美日韩高清在线视频| 久久国产亚洲av麻豆专区| 女人爽到高潮嗷嗷叫在线视频| 又黄又爽又免费观看的视频| 亚洲成人免费电影在线观看| 此物有八面人人有两片| 美女大奶头视频| 亚洲久久久国产精品| 日韩视频一区二区在线观看| 丝袜人妻中文字幕| 欧美人与性动交α欧美精品济南到| 国产亚洲欧美98| 一卡2卡三卡四卡精品乱码亚洲| 看片在线看免费视频| 国产爱豆传媒在线观看 | 午夜激情福利司机影院| 女性被躁到高潮视频| 国产主播在线观看一区二区| 欧美人与性动交α欧美精品济南到| 人人妻人人看人人澡| 91成人精品电影| 欧美zozozo另类| 国内久久婷婷六月综合欲色啪| 亚洲成人免费电影在线观看| av在线天堂中文字幕| 国产亚洲欧美精品永久| 久久精品91蜜桃| 欧美激情极品国产一区二区三区| 精品欧美一区二区三区在线| 欧美激情久久久久久爽电影| 午夜免费成人在线视频| 深夜精品福利| 日本a在线网址| 久久午夜亚洲精品久久| 97超级碰碰碰精品色视频在线观看| 九色国产91popny在线| 久久精品国产综合久久久| 少妇粗大呻吟视频| 亚洲av成人av| 后天国语完整版免费观看| 午夜福利成人在线免费观看| 日日夜夜操网爽| 亚洲国产日韩欧美精品在线观看 | 亚洲国产精品sss在线观看| 亚洲精品国产精品久久久不卡| 国产成人精品无人区| 后天国语完整版免费观看| 精品日产1卡2卡| 黄色毛片三级朝国网站| 曰老女人黄片| 人人妻人人澡欧美一区二区| 国产91精品成人一区二区三区| 亚洲国产精品成人综合色| 亚洲avbb在线观看| 久久精品人妻少妇| 亚洲精华国产精华精| 国内精品久久久久精免费| 欧美又色又爽又黄视频| 日韩高清综合在线| av电影中文网址| 国产主播在线观看一区二区| 亚洲人成伊人成综合网2020| 777久久人妻少妇嫩草av网站| 深夜精品福利| 亚洲av电影不卡..在线观看| 91字幕亚洲| 51午夜福利影视在线观看| 国产人伦9x9x在线观看| 国产精品久久久久久亚洲av鲁大| 国产成人精品无人区| 欧美一级a爱片免费观看看 | 一级片免费观看大全| 黄色a级毛片大全视频| 亚洲av成人不卡在线观看播放网| 欧美成人一区二区免费高清观看 | 国产aⅴ精品一区二区三区波| 国产高清视频在线播放一区| 久久欧美精品欧美久久欧美| 精品久久久久久久毛片微露脸| 91麻豆av在线| 午夜福利高清视频| 久久天躁狠狠躁夜夜2o2o| 黄色毛片三级朝国网站| 亚洲激情在线av| 18禁黄网站禁片午夜丰满| 99国产精品一区二区三区| 精品国产美女av久久久久小说| 国产麻豆成人av免费视频| www日本在线高清视频| 亚洲久久久国产精品| 女人被狂操c到高潮| 又紧又爽又黄一区二区| 香蕉丝袜av| 欧美大码av| 免费看a级黄色片| 俺也久久电影网| 亚洲av中文字字幕乱码综合 | 亚洲在线自拍视频| 国产不卡一卡二| 一本一本综合久久| 欧美日韩精品网址| 俄罗斯特黄特色一大片| 黑人欧美特级aaaaaa片| 久久精品aⅴ一区二区三区四区| 亚洲成人久久爱视频| 欧美国产精品va在线观看不卡| 欧美黑人欧美精品刺激| 精品久久久久久成人av| 色在线成人网| 人人妻人人澡人人看| 黄色成人免费大全| 国内毛片毛片毛片毛片毛片| 免费在线观看日本一区| 国产私拍福利视频在线观看| 美女扒开内裤让男人捅视频| 免费看a级黄色片| 男人的好看免费观看在线视频 | 精华霜和精华液先用哪个| 真人一进一出gif抽搐免费| 色婷婷久久久亚洲欧美| 久久中文字幕人妻熟女| 亚洲av中文字字幕乱码综合 | 精品久久久久久久人妻蜜臀av| 亚洲第一av免费看| 97超级碰碰碰精品色视频在线观看| 欧美成人午夜精品| 亚洲七黄色美女视频| 亚洲欧美日韩高清在线视频| 午夜免费观看网址| 亚洲国产中文字幕在线视频| 国产亚洲精品第一综合不卡| 桃红色精品国产亚洲av| 手机成人av网站| 午夜福利免费观看在线| 国内精品久久久久精免费| 一a级毛片在线观看| 在线观看免费午夜福利视频| 在线观看www视频免费| 午夜亚洲福利在线播放| 99久久99久久久精品蜜桃| 久久精品国产亚洲av香蕉五月| x7x7x7水蜜桃| 亚洲国产欧美日韩在线播放| 久久久久国内视频| 成人国产综合亚洲| 一夜夜www| 精品国内亚洲2022精品成人| 久久精品国产清高在天天线| √禁漫天堂资源中文www| 2021天堂中文幕一二区在线观 | 国产三级在线视频| 精品熟女少妇八av免费久了| 欧美三级亚洲精品| 色精品久久人妻99蜜桃| 久久精品亚洲精品国产色婷小说| 亚洲人成77777在线视频| 亚洲天堂国产精品一区在线| 国产在线观看jvid| tocl精华| 一边摸一边做爽爽视频免费| a级毛片在线看网站| 亚洲一区二区三区不卡视频| 琪琪午夜伦伦电影理论片6080| 亚洲男人的天堂狠狠| 国产三级在线视频| 日本撒尿小便嘘嘘汇集6| 亚洲精品中文字幕在线视频| 在线观看午夜福利视频| 老熟妇乱子伦视频在线观看| 51午夜福利影视在线观看| 一级毛片高清免费大全| 长腿黑丝高跟| 日本一本二区三区精品| 欧美激情 高清一区二区三区| 欧美一级毛片孕妇| 国产三级在线视频| 国产视频内射| 日韩精品青青久久久久久| 午夜精品在线福利| 在线观看www视频免费| 一个人观看的视频www高清免费观看 | 男人舔女人的私密视频| 1024手机看黄色片| 欧美亚洲日本最大视频资源| tocl精华| 999精品在线视频| 母亲3免费完整高清在线观看| 美国免费a级毛片| 亚洲熟妇熟女久久| 成人18禁高潮啪啪吃奶动态图| 美女免费视频网站| 久久久久国产一级毛片高清牌| 男人舔女人的私密视频| 好男人在线观看高清免费视频 | 精品一区二区三区四区五区乱码| 91字幕亚洲| 后天国语完整版免费观看| 国产精品亚洲一级av第二区| 精品久久久久久久末码| 亚洲专区国产一区二区| 中国美女看黄片| 手机成人av网站| 精品免费久久久久久久清纯| 亚洲专区字幕在线| 国产精品自产拍在线观看55亚洲| 久久精品国产综合久久久| 国产三级黄色录像| 男女那种视频在线观看| 欧美黑人欧美精品刺激| 午夜免费鲁丝| 天堂动漫精品| 国产精品一区二区免费欧美| 亚洲成av片中文字幕在线观看| 级片在线观看| 欧美激情 高清一区二区三区| 成人18禁在线播放| 精品国产美女av久久久久小说| 国产精品久久电影中文字幕| 久久国产精品男人的天堂亚洲| 免费在线观看亚洲国产| 免费看a级黄色片| 久久这里只有精品19| 久久婷婷成人综合色麻豆| 丝袜人妻中文字幕| 国产精品免费视频内射| 国产成人影院久久av| 白带黄色成豆腐渣| 男女视频在线观看网站免费 | 一区福利在线观看| 国产亚洲欧美精品永久| 日韩欧美一区视频在线观看| 法律面前人人平等表现在哪些方面| 天天躁狠狠躁夜夜躁狠狠躁| 亚洲第一欧美日韩一区二区三区| 午夜福利欧美成人| 欧美日韩亚洲国产一区二区在线观看| 在线观看一区二区三区| 欧美一级毛片孕妇| 久久精品夜夜夜夜夜久久蜜豆 | 欧美久久黑人一区二区| 中文字幕人妻丝袜一区二区| 亚洲在线自拍视频| 19禁男女啪啪无遮挡网站| 啦啦啦韩国在线观看视频| 久久久久久久久久黄片| 最新美女视频免费是黄的| 午夜福利在线观看吧| 99久久99久久久精品蜜桃| 亚洲无线在线观看| 好看av亚洲va欧美ⅴa在| 成在线人永久免费视频| 老司机深夜福利视频在线观看| 黑丝袜美女国产一区| 99国产精品99久久久久| 极品教师在线免费播放| 欧美性长视频在线观看| 日本a在线网址| 日本熟妇午夜| 精品免费久久久久久久清纯| 老熟妇乱子伦视频在线观看| 丝袜人妻中文字幕| 不卡一级毛片| 中文字幕人妻熟女乱码| 大型黄色视频在线免费观看| 桃色一区二区三区在线观看| 国产又爽黄色视频| 亚洲男人的天堂狠狠| 国产不卡一卡二| 99热这里只有精品一区 | 麻豆成人av在线观看| 免费看十八禁软件| 亚洲精品中文字幕在线视频| bbb黄色大片| 嫩草影视91久久| 亚洲人成电影免费在线| 日韩精品青青久久久久久| 非洲黑人性xxxx精品又粗又长| 亚洲 国产 在线| 精品一区二区三区四区五区乱码| 精品久久久久久,| 夜夜夜夜夜久久久久| 亚洲精品一区av在线观看| 性欧美人与动物交配| 天天躁狠狠躁夜夜躁狠狠躁| 国产成人啪精品午夜网站| 午夜a级毛片| 在线播放国产精品三级| 亚洲久久久国产精品| 99精品在免费线老司机午夜| 欧美日韩中文字幕国产精品一区二区三区| 国产亚洲精品综合一区在线观看 | 中出人妻视频一区二区| 久久精品国产亚洲av香蕉五月| 精品久久久久久久久久久久久 | 成熟少妇高潮喷水视频| 国产精品久久久久久精品电影 | 俄罗斯特黄特色一大片| 色老头精品视频在线观看| 久久亚洲真实| 中文亚洲av片在线观看爽| 亚洲色图 男人天堂 中文字幕| 少妇粗大呻吟视频| 国产亚洲欧美98| 精华霜和精华液先用哪个| 亚洲国产中文字幕在线视频| 亚洲男人天堂网一区| 欧美一级a爱片免费观看看 | 夜夜夜夜夜久久久久| 美女大奶头视频| 99热这里只有精品一区 | 久久久久久免费高清国产稀缺| 久久香蕉激情| 婷婷精品国产亚洲av在线| 久久精品国产99精品国产亚洲性色| 国产不卡一卡二| 亚洲欧洲精品一区二区精品久久久| 宅男免费午夜| 久久 成人 亚洲| or卡值多少钱| 亚洲va日本ⅴa欧美va伊人久久| 夜夜爽天天搞| 亚洲中文字幕一区二区三区有码在线看 | 男女之事视频高清在线观看| 老司机深夜福利视频在线观看| 99久久无色码亚洲精品果冻| 国产乱人伦免费视频| 亚洲精品久久国产高清桃花| 一区二区三区高清视频在线| 欧美黄色淫秽网站| 国产主播在线观看一区二区| 午夜免费鲁丝| 国产精品av久久久久免费| 不卡av一区二区三区| 99国产综合亚洲精品| 精品久久久久久久人妻蜜臀av| 男女床上黄色一级片免费看| 亚洲第一欧美日韩一区二区三区| 999精品在线视频| 亚洲精华国产精华精| www日本在线高清视频| 叶爱在线成人免费视频播放| 成人欧美大片| 国产精品免费一区二区三区在线| 老汉色av国产亚洲站长工具| 性欧美人与动物交配| 欧美成人午夜精品| 91av网站免费观看| 亚洲中文日韩欧美视频| 亚洲精品色激情综合| 日本三级黄在线观看| 精华霜和精华液先用哪个| 黄色片一级片一级黄色片| 欧美三级亚洲精品| 久久精品成人免费网站| 欧美精品啪啪一区二区三区| 99国产综合亚洲精品| 99国产精品99久久久久| 十八禁网站免费在线| 级片在线观看| 久久精品夜夜夜夜夜久久蜜豆 | 亚洲av免费高清在线观看| 国产视频一区二区在线看| 美女内射精品一级片tv| 少妇熟女aⅴ在线视频| 天美传媒精品一区二区| 久久久久免费精品人妻一区二区| 久久精品综合一区二区三区| 免费观看精品视频网站| 国产一区亚洲一区在线观看| 久久久a久久爽久久v久久| 热99在线观看视频| 别揉我奶头 嗯啊视频| 久久精品久久久久久噜噜老黄 | а√天堂www在线а√下载| 特级一级黄色大片| 国产精品一及| 亚洲欧美日韩卡通动漫| 欧美绝顶高潮抽搐喷水| 亚洲国产欧洲综合997久久,| 久久久久久久久久久丰满| 国产激情偷乱视频一区二区| 国产高清视频在线观看网站| 精品99又大又爽又粗少妇毛片| 国产成人精品久久久久久| 一个人观看的视频www高清免费观看| 熟妇人妻久久中文字幕3abv| 狠狠狠狠99中文字幕| 伦精品一区二区三区| 欧美日韩乱码在线| 国产精品99久久久久久久久| 久久久久久久久久黄片| 女的被弄到高潮叫床怎么办| 草草在线视频免费看| 国产aⅴ精品一区二区三区波| 国产男人的电影天堂91| 国产激情偷乱视频一区二区| avwww免费| 最近最新中文字幕大全电影3| 国产精品免费一区二区三区在线| 男女那种视频在线观看| 变态另类丝袜制服| 国产精品不卡视频一区二区| 我要搜黄色片| 天天一区二区日本电影三级| 亚洲七黄色美女视频| 精品福利观看| 男女视频在线观看网站免费| 欧美日韩一区二区视频在线观看视频在线 | 久久久久久久久久久丰满| 精品一区二区免费观看| 国产精品一二三区在线看| 久久精品人妻少妇| 日本黄色片子视频| 一区福利在线观看| 级片在线观看| 亚洲18禁久久av| 99精品在免费线老司机午夜| 国产精品爽爽va在线观看网站| 搞女人的毛片| 久久6这里有精品| 在线天堂最新版资源| 久久九九热精品免费| 在线观看av片永久免费下载| 国产日本99.免费观看| 国产三级在线视频| 欧美成人精品欧美一级黄| 成人国产麻豆网| 精品日产1卡2卡| 亚洲av.av天堂| 亚洲丝袜综合中文字幕| a级毛片免费高清观看在线播放| 日韩在线高清观看一区二区三区| 听说在线观看完整版免费高清| 一个人看视频在线观看www免费| 亚洲av第一区精品v没综合| 国产精品国产高清国产av| 国产一区二区三区在线臀色熟女| 久久精品国产亚洲av涩爱 | 毛片女人毛片| 精品人妻偷拍中文字幕| 成年免费大片在线观看| 男人舔女人下体高潮全视频| 国产久久久一区二区三区| av免费在线看不卡| 国产欧美日韩精品一区二区| 我要看日韩黄色一级片| 日韩在线高清观看一区二区三区| 久久久久久大精品| 天天一区二区日本电影三级| 国产成人a∨麻豆精品| 插逼视频在线观看| 别揉我奶头~嗯~啊~动态视频| 欧美又色又爽又黄视频| 美女高潮的动态| 午夜a级毛片| 免费观看精品视频网站| 黄色视频,在线免费观看| 免费无遮挡裸体视频| 亚洲精品久久国产高清桃花| 身体一侧抽搐| 在线看三级毛片| 亚洲欧美成人综合另类久久久 | 日韩av在线大香蕉| 日本-黄色视频高清免费观看| 国产美女午夜福利| 此物有八面人人有两片| 亚洲av电影不卡..在线观看| 亚洲av免费在线观看| 亚洲欧美成人精品一区二区| 欧美成人a在线观看| 国产精品一区二区性色av| 可以在线观看的亚洲视频| 美女大奶头视频| 观看免费一级毛片| 高清日韩中文字幕在线| 精品久久久久久久久久免费视频| 欧美性猛交黑人性爽| 国产伦一二天堂av在线观看| 午夜老司机福利剧场| 女的被弄到高潮叫床怎么办| 香蕉av资源在线| 国产 一区 欧美 日韩| 亚洲性夜色夜夜综合| 成人亚洲欧美一区二区av| 三级毛片av免费| 18禁黄网站禁片免费观看直播| 最近最新中文字幕大全电影3| 国产一区二区在线av高清观看| 在线播放无遮挡| 综合色丁香网| 日韩精品中文字幕看吧| 男人的好看免费观看在线视频| 此物有八面人人有两片| 亚洲人成网站在线播| 久久久久久伊人网av| 免费一级毛片在线播放高清视频| 免费大片18禁| h日本视频在线播放| 简卡轻食公司| 国产精品福利在线免费观看| 级片在线观看| 99在线人妻在线中文字幕| 日韩欧美在线乱码| 男女之事视频高清在线观看| 高清午夜精品一区二区三区 |