• <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蜜臀| 在线看a的网站| bbb黄色大片| 国产高清国产精品国产三级| 亚洲欧美精品综合一区二区三区| 在线永久观看黄色视频| 狠狠狠狠99中文字幕| 精品久久久久久电影网| 黄色怎么调成土黄色| 一边摸一边做爽爽视频免费| 午夜福利,免费看| 国产精品 国内视频| 91麻豆av在线| 精品福利观看| 国产主播在线观看一区二区| 电影成人av| 成人三级做爰电影| 午夜激情av网站| 男人添女人高潮全过程视频| 啪啪无遮挡十八禁网站| 中文字幕最新亚洲高清| 性色av一级| 国产又色又爽无遮挡免| 18在线观看网站| 国产精品欧美亚洲77777| 岛国在线观看网站| 久久狼人影院| 18在线观看网站| 亚洲精品国产色婷婷电影| www日本在线高清视频| 久久久国产成人免费| 一级毛片电影观看| 动漫黄色视频在线观看| 99精品欧美一区二区三区四区| 午夜福利在线观看吧| 国产男女内射视频| 国产亚洲av高清不卡| 久久精品国产亚洲av香蕉五月 | 国产亚洲精品第一综合不卡| 肉色欧美久久久久久久蜜桃| 欧美中文综合在线视频| 狂野欧美激情性bbbbbb| 亚洲,欧美精品.| 色精品久久人妻99蜜桃| 黄片播放在线免费| 亚洲 国产 在线| 大香蕉久久网| 欧美黄色淫秽网站| av不卡在线播放| 少妇精品久久久久久久| 亚洲欧美一区二区三区黑人| 午夜成年电影在线免费观看| 国产精品1区2区在线观看. | 欧美日韩黄片免| 男女床上黄色一级片免费看| 在线观看免费午夜福利视频| 少妇猛男粗大的猛烈进出视频| 午夜精品国产一区二区电影| 一个人免费在线观看的高清视频 | 国产精品久久久久久精品古装| 精品乱码久久久久久99久播| 久久香蕉激情| 91精品国产国语对白视频| 亚洲专区中文字幕在线| 肉色欧美久久久久久久蜜桃| 高清在线国产一区| 丝袜在线中文字幕| 日韩视频一区二区在线观看| 首页视频小说图片口味搜索| 水蜜桃什么品种好| 国产精品二区激情视频| 如日韩欧美国产精品一区二区三区| 久久久久久久久免费视频了| 亚洲av成人不卡在线观看播放网 | av免费在线观看网站| 美女中出高潮动态图| 交换朋友夫妻互换小说| 搡老乐熟女国产| 国产视频一区二区在线看| 久久中文看片网| 日本av免费视频播放| 久久99热这里只频精品6学生| 久久久久久人人人人人| 免费观看人在逋| av又黄又爽大尺度在线免费看| 欧美 亚洲 国产 日韩一| 国产精品久久久av美女十八| 亚洲国产欧美一区二区综合| 高潮久久久久久久久久久不卡| 久久久久久免费高清国产稀缺| 日韩电影二区| 十八禁人妻一区二区| 欧美久久黑人一区二区| 成年av动漫网址| 亚洲av电影在线进入| 亚洲伊人久久精品综合| 老司机在亚洲福利影院| 中文字幕人妻丝袜一区二区| 香蕉国产在线看| 国产av国产精品国产| 亚洲精品国产av蜜桃| 久久女婷五月综合色啪小说| 自拍欧美九色日韩亚洲蝌蚪91| 欧美激情久久久久久爽电影 | 日韩大码丰满熟妇| 在线观看免费高清a一片| av天堂在线播放| 国产精品av久久久久免费| 自拍欧美九色日韩亚洲蝌蚪91| 欧美日韩av久久| 热99久久久久精品小说推荐| 一区在线观看完整版| 在线观看免费高清a一片| 精品亚洲成a人片在线观看| 免费女性裸体啪啪无遮挡网站| 自拍欧美九色日韩亚洲蝌蚪91| 国产精品免费视频内射| 19禁男女啪啪无遮挡网站| 老司机午夜十八禁免费视频| 欧美精品亚洲一区二区| 亚洲第一青青草原| 日韩制服骚丝袜av| a 毛片基地| 91麻豆精品激情在线观看国产 | 欧美精品高潮呻吟av久久| 国产成人精品无人区| svipshipincom国产片| 精品少妇一区二区三区视频日本电影| 日韩熟女老妇一区二区性免费视频| 欧美黄色淫秽网站| 麻豆乱淫一区二区| 成人免费观看视频高清| 久久久国产一区二区| 一级黄色大片毛片| 亚洲av电影在线进入| 成人三级做爰电影| 久久久久久人人人人人| 国产精品久久久久久人妻精品电影 | 欧美激情高清一区二区三区| 中国国产av一级| 成人av一区二区三区在线看 | a 毛片基地| 人人妻人人爽人人添夜夜欢视频| av片东京热男人的天堂| 一边摸一边做爽爽视频免费| 国产精品av久久久久免费| 欧美中文综合在线视频| 天天躁夜夜躁狠狠躁躁| 一级片免费观看大全| 久久午夜综合久久蜜桃| 亚洲欧美日韩另类电影网站| 99香蕉大伊视频| 日本wwww免费看| 久久午夜综合久久蜜桃| 老熟妇乱子伦视频在线观看 | 狠狠婷婷综合久久久久久88av| 日本一区二区免费在线视频| 久久久精品国产亚洲av高清涩受| 国产97色在线日韩免费| 久久热在线av| 777久久人妻少妇嫩草av网站| 久久狼人影院| bbb黄色大片| 欧美日韩国产mv在线观看视频| 成年动漫av网址| 国产色视频综合| 国产免费视频播放在线视频| 国产一卡二卡三卡精品| 欧美黄色淫秽网站| 亚洲精品国产区一区二| 国产亚洲精品久久久久5区| 高清在线国产一区| 国产亚洲av片在线观看秒播厂| 男女边摸边吃奶| 亚洲 欧美一区二区三区| 热re99久久精品国产66热6| 色94色欧美一区二区| 亚洲综合色网址| 啦啦啦啦在线视频资源| 欧美日韩亚洲综合一区二区三区_| 国产亚洲午夜精品一区二区久久| 亚洲少妇的诱惑av| 伊人亚洲综合成人网| 日日夜夜操网爽| 国产又爽黄色视频| 亚洲天堂av无毛| 日韩免费高清中文字幕av| 1024香蕉在线观看| 日韩中文字幕视频在线看片| 飞空精品影院首页| 免费女性裸体啪啪无遮挡网站| 国产高清国产精品国产三级| 亚洲少妇的诱惑av| 亚洲精品久久久久久婷婷小说| 国产成人a∨麻豆精品| 男女无遮挡免费网站观看| 后天国语完整版免费观看| 我要看黄色一级片免费的| 欧美黑人欧美精品刺激| 老司机午夜福利在线观看视频 | 老熟女久久久| 大香蕉久久成人网| 色婷婷久久久亚洲欧美| 久久久国产精品麻豆| 国产精品免费大片| 精品人妻1区二区| 最近最新免费中文字幕在线| 亚洲专区字幕在线| 欧美日韩中文字幕国产精品一区二区三区 | 在线观看免费午夜福利视频| 麻豆乱淫一区二区| 欧美在线一区亚洲| 男男h啪啪无遮挡| 人妻 亚洲 视频| 国产成人av教育| 精品福利观看| 免费女性裸体啪啪无遮挡网站| 天堂8中文在线网| 丝袜喷水一区| 人人妻人人澡人人看| 老熟妇乱子伦视频在线观看 | 国产人伦9x9x在线观看| 午夜福利视频在线观看免费| 成人黄色视频免费在线看| 99国产精品一区二区三区| 精品少妇黑人巨大在线播放| 丰满人妻熟妇乱又伦精品不卡| 国产深夜福利视频在线观看| 欧美亚洲 丝袜 人妻 在线| 午夜日韩欧美国产| 亚洲精品美女久久久久99蜜臀| 大片电影免费在线观看免费| 91成人精品电影| 青草久久国产| 又紧又爽又黄一区二区| 亚洲精品中文字幕一二三四区 | 韩国精品一区二区三区| 制服诱惑二区| 亚洲精品成人av观看孕妇| 大陆偷拍与自拍| 两个人看的免费小视频| avwww免费| 视频区图区小说| 国产精品99久久99久久久不卡| 女性生殖器流出的白浆| 久久久久久久久免费视频了| 日韩欧美一区二区三区在线观看 | 51午夜福利影视在线观看| 午夜免费鲁丝| a级片在线免费高清观看视频| 成年女人毛片免费观看观看9 | 国产成人a∨麻豆精品| 亚洲精品一二三| av又黄又爽大尺度在线免费看| 老熟妇仑乱视频hdxx| 久久免费观看电影| 老司机影院成人| 国产亚洲欧美在线一区二区| 亚洲精品久久午夜乱码| 蜜桃在线观看..| 成人国语在线视频| 亚洲av成人不卡在线观看播放网 | 精品人妻1区二区| av网站免费在线观看视频| 丰满迷人的少妇在线观看| 亚洲伊人久久精品综合| 久久综合国产亚洲精品| 精品国产超薄肉色丝袜足j| 精品人妻熟女毛片av久久网站| 18在线观看网站| 看免费av毛片| 侵犯人妻中文字幕一二三四区| 亚洲自偷自拍图片 自拍| 波多野结衣av一区二区av| 欧美日韩亚洲综合一区二区三区_| 最新在线观看一区二区三区| 欧美性长视频在线观看| 日本91视频免费播放| 欧美激情高清一区二区三区| 日本wwww免费看| 午夜日韩欧美国产| 日韩欧美国产一区二区入口| 成人免费观看视频高清| 国产极品粉嫩免费观看在线| 国产成人免费无遮挡视频| 乱人伦中国视频| 久久人妻福利社区极品人妻图片| 首页视频小说图片口味搜索| 在线十欧美十亚洲十日本专区| 成年动漫av网址| 视频在线观看一区二区三区| 亚洲精品av麻豆狂野| 欧美 日韩 精品 国产| 久久女婷五月综合色啪小说| 国产成人av激情在线播放| 成年动漫av网址| 成人国语在线视频| 丝袜喷水一区| 国产成人欧美在线观看 | 人人妻人人添人人爽欧美一区卜| 午夜福利一区二区在线看| 亚洲精品乱久久久久久| 国产野战对白在线观看| 别揉我奶头~嗯~啊~动态视频 | 一区二区av电影网| 飞空精品影院首页| 国产熟女午夜一区二区三区| 婷婷色av中文字幕| tocl精华| 女人被躁到高潮嗷嗷叫费观| 别揉我奶头~嗯~啊~动态视频 | 国产极品粉嫩免费观看在线| 另类精品久久| 国产av又大| 黑人巨大精品欧美一区二区mp4| 男女免费视频国产| 午夜91福利影院| 亚洲中文av在线| 人人妻人人添人人爽欧美一区卜| 99精品欧美一区二区三区四区| av一本久久久久| 亚洲精品久久成人aⅴ小说| 日韩制服骚丝袜av| 亚洲 国产 在线| 别揉我奶头~嗯~啊~动态视频 | 日韩大片免费观看网站| 久久精品国产a三级三级三级| 麻豆国产av国片精品| 亚洲三区欧美一区| 一区二区三区精品91| 国产精品99久久99久久久不卡| 亚洲av日韩在线播放| 精品久久久精品久久久| 国内毛片毛片毛片毛片毛片| 欧美人与性动交α欧美软件| 精品国产乱码久久久久久男人| 黑人操中国人逼视频| videosex国产| 亚洲av成人一区二区三| 美女脱内裤让男人舔精品视频| 99国产精品99久久久久| 亚洲人成77777在线视频| 啦啦啦在线免费观看视频4| 国产欧美日韩精品亚洲av| 黄片播放在线免费| 国产一区二区三区综合在线观看| 亚洲 欧美一区二区三区| 国产精品二区激情视频| 国产av国产精品国产| 久久久久精品人妻al黑| av在线播放精品| 日本黄色日本黄色录像| 亚洲精品av麻豆狂野| 19禁男女啪啪无遮挡网站| 亚洲 欧美一区二区三区| 国产欧美日韩精品亚洲av| 黄色a级毛片大全视频| 黄片小视频在线播放| 亚洲av电影在线观看一区二区三区| 久热这里只有精品99| 欧美日韩亚洲国产一区二区在线观看 | 在线av久久热| 国产又爽黄色视频| 午夜成年电影在线免费观看| 国产一卡二卡三卡精品| 黄色a级毛片大全视频| 日本精品一区二区三区蜜桃| 中文字幕av电影在线播放| 99re6热这里在线精品视频| 精品国产乱子伦一区二区三区 | 我要看黄色一级片免费的| 免费观看人在逋| 超碰成人久久| 欧美精品人与动牲交sv欧美| 亚洲精品第二区| 1024视频免费在线观看| 精品国产超薄肉色丝袜足j| 中文欧美无线码| 美女视频免费永久观看网站| 最黄视频免费看| 亚洲国产欧美日韩在线播放| 三级毛片av免费| 999久久久国产精品视频| 三级毛片av免费| 人人妻,人人澡人人爽秒播| 国产国语露脸激情在线看| 韩国精品一区二区三区| 爱豆传媒免费全集在线观看| 美女午夜性视频免费| 国产区一区二久久| 男人添女人高潮全过程视频| 国产高清videossex| 1024香蕉在线观看| 精品国内亚洲2022精品成人 | 国产深夜福利视频在线观看| 在线av久久热| 久久亚洲精品不卡| 黑人欧美特级aaaaaa片| www.av在线官网国产| 免费一级毛片在线播放高清视频 | 最新在线观看一区二区三区| 国产日韩欧美在线精品| 熟女少妇亚洲综合色aaa.| 久久久精品免费免费高清| 国产高清国产精品国产三级| 捣出白浆h1v1| 亚洲av片天天在线观看| 日韩欧美免费精品| 老熟妇乱子伦视频在线观看 | 高清欧美精品videossex| 久久人妻熟女aⅴ| 亚洲国产精品成人久久小说| 又大又爽又粗| 黑人巨大精品欧美一区二区mp4| 男女之事视频高清在线观看| 窝窝影院91人妻| 日韩欧美一区视频在线观看| 精品熟女少妇八av免费久了| 欧美精品亚洲一区二区| 亚洲一码二码三码区别大吗| 国精品久久久久久国模美| 久久天堂一区二区三区四区| 亚洲三区欧美一区| 中文字幕人妻熟女乱码| 日韩欧美国产一区二区入口| 一本—道久久a久久精品蜜桃钙片| 亚洲第一av免费看| 搡老乐熟女国产| 一二三四社区在线视频社区8| 国产免费视频播放在线视频| 国产伦人伦偷精品视频| 亚洲欧美精品综合一区二区三区| 后天国语完整版免费观看| 久久人人97超碰香蕉20202| 国产麻豆69| 国产日韩欧美在线精品| 欧美精品av麻豆av| 日韩,欧美,国产一区二区三区| 亚洲精品久久午夜乱码| 丝袜美腿诱惑在线| 日韩 亚洲 欧美在线| 香蕉国产在线看| 美女视频免费永久观看网站| 国产区一区二久久| 国产精品久久久人人做人人爽| 国产精品国产三级国产专区5o| 国产精品av久久久久免费| 美女国产高潮福利片在线看| 国产色视频综合| 欧美+亚洲+日韩+国产| 成人国产av品久久久| 18禁国产床啪视频网站| av在线播放精品| 亚洲九九香蕉| 久久国产精品影院| 美女主播在线视频| av线在线观看网站| 午夜激情久久久久久久| 日本精品一区二区三区蜜桃| 咕卡用的链子| 大型av网站在线播放| 亚洲欧美日韩另类电影网站| 女警被强在线播放| 青春草视频在线免费观看| 丰满迷人的少妇在线观看| 在线天堂中文资源库| 美国免费a级毛片| 人成视频在线观看免费观看| 妹子高潮喷水视频| 最新在线观看一区二区三区| 两个人免费观看高清视频| 淫妇啪啪啪对白视频 | 久久青草综合色| 美女脱内裤让男人舔精品视频| 少妇人妻久久综合中文| 男人添女人高潮全过程视频| 色视频在线一区二区三区| 大陆偷拍与自拍| 黄色视频在线播放观看不卡| 午夜精品久久久久久毛片777| av在线app专区| 亚洲avbb在线观看| 欧美日本中文国产一区发布| 欧美性长视频在线观看| 久久九九热精品免费| 99久久人妻综合| 午夜久久久在线观看| 国产在线视频一区二区| 热99国产精品久久久久久7| 黄片大片在线免费观看| 日韩欧美国产一区二区入口| 免费久久久久久久精品成人欧美视频| 18禁国产床啪视频网站| 亚洲欧美一区二区三区久久| 中国美女看黄片| 91字幕亚洲| 各种免费的搞黄视频| 宅男免费午夜| 精品久久久精品久久久| 日韩大码丰满熟妇| 97在线人人人人妻| 国产精品一区二区在线不卡| 精品久久久久久久毛片微露脸 | 最近中文字幕2019免费版| 黄色视频在线播放观看不卡| 日韩有码中文字幕| 亚洲成人免费av在线播放| 中文字幕最新亚洲高清| 老司机影院毛片| a 毛片基地| 欧美日韩一级在线毛片| 国产精品香港三级国产av潘金莲| 亚洲精品av麻豆狂野| 久久99一区二区三区| 999精品在线视频| 老司机午夜福利在线观看视频 | 免费观看人在逋| 韩国高清视频一区二区三区| 欧美黄色淫秽网站| 亚洲成人国产一区在线观看| 黑人操中国人逼视频| 亚洲精品日韩在线中文字幕| 人人妻,人人澡人人爽秒播| 丰满人妻熟妇乱又伦精品不卡| 视频区欧美日本亚洲| 九色亚洲精品在线播放| 99热国产这里只有精品6| 国产xxxxx性猛交| 精品国内亚洲2022精品成人 | 考比视频在线观看| 亚洲av成人一区二区三| 亚洲人成电影观看| 亚洲精品国产av蜜桃| 免费久久久久久久精品成人欧美视频| 五月开心婷婷网| 欧美精品亚洲一区二区| 一区二区av电影网| 国产一卡二卡三卡精品| 国产在视频线精品| tocl精华| 成年动漫av网址| 在线观看免费高清a一片| 久久精品国产亚洲av高清一级| 黄色 视频免费看| 日韩中文字幕视频在线看片| 日本黄色日本黄色录像| 欧美日韩精品网址| 国产一区二区在线观看av| 亚洲视频免费观看视频| 女人爽到高潮嗷嗷叫在线视频| 在线观看免费日韩欧美大片| 在线观看一区二区三区激情| av在线播放精品| 亚洲av欧美aⅴ国产| 伊人久久大香线蕉亚洲五| 黑人猛操日本美女一级片| 老司机影院毛片| 建设人人有责人人尽责人人享有的| 首页视频小说图片口味搜索| 国产欧美日韩精品亚洲av| 国产精品久久久久久精品电影小说| 国产国语露脸激情在线看| 热99久久久久精品小说推荐| 国产亚洲精品一区二区www | 丝袜人妻中文字幕| 国产野战对白在线观看| 久久久久久久精品精品| 欧美精品人与动牲交sv欧美| 国产精品影院久久| 9色porny在线观看| 国产成人精品久久二区二区91| 好男人电影高清在线观看| 国产人伦9x9x在线观看| 性色av乱码一区二区三区2| 女人被躁到高潮嗷嗷叫费观| 丰满人妻熟妇乱又伦精品不卡| 99国产综合亚洲精品| 亚洲精品国产区一区二| 国产成人啪精品午夜网站| 人人妻人人澡人人爽人人夜夜| 久久人人爽人人片av| 成年女人毛片免费观看观看9 | 午夜视频精品福利| www.熟女人妻精品国产| 久久女婷五月综合色啪小说| 黄网站色视频无遮挡免费观看| 亚洲国产欧美在线一区| 黄色视频不卡| 黑人巨大精品欧美一区二区mp4| 一本色道久久久久久精品综合| 欧美日本中文国产一区发布| 97精品久久久久久久久久精品| 日本撒尿小便嘘嘘汇集6| 99re6热这里在线精品视频| 欧美日韩av久久| 夜夜夜夜夜久久久久| 欧美日本中文国产一区发布| 97精品久久久久久久久久精品| 18禁裸乳无遮挡动漫免费视频| www.av在线官网国产| 99热全是精品| 成人三级做爰电影| 国产男女超爽视频在线观看| 国产无遮挡羞羞视频在线观看| 美女扒开内裤让男人捅视频| 国产精品av久久久久免费| 飞空精品影院首页| 欧美精品av麻豆av| 亚洲av日韩在线播放| 亚洲伊人色综图| 看免费av毛片| 最新的欧美精品一区二区| 91成人精品电影| 国产免费视频播放在线视频|