• <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.

    大香蕉97超碰在线| 五月开心婷婷网| 久久久亚洲精品成人影院| 亚洲伊人久久精品综合| 久久99热这里只频精品6学生| 国模一区二区三区四区视频| 乱人伦中国视频| 人妻一区二区av| 日本黄大片高清| 极品人妻少妇av视频| 日本爱情动作片www.在线观看| 少妇人妻精品综合一区二区| 久久久精品免费免费高清| 成年美女黄网站色视频大全免费 | 黄色毛片三级朝国网站 | www.色视频.com| 亚洲色图综合在线观看| 丝瓜视频免费看黄片| 十八禁网站网址无遮挡 | 九九爱精品视频在线观看| 亚洲欧美成人精品一区二区| 街头女战士在线观看网站| 免费av中文字幕在线| 在现免费观看毛片| 精品视频人人做人人爽| 亚洲精品乱码久久久久久按摩| 中文精品一卡2卡3卡4更新| 一级毛片我不卡| 午夜精品国产一区二区电影| 国产黄片美女视频| 女人精品久久久久毛片| 精品久久久精品久久久| 久久久久久久亚洲中文字幕| 成人毛片60女人毛片免费| 99久久精品热视频| av国产久精品久网站免费入址| 国产成人精品福利久久| 亚洲精品久久久久久婷婷小说| 九色成人免费人妻av| 色婷婷久久久亚洲欧美| 久热这里只有精品99| 人妻夜夜爽99麻豆av| 国产欧美另类精品又又久久亚洲欧美| a 毛片基地| 欧美97在线视频| 亚洲电影在线观看av| 久久久久久伊人网av| 精品卡一卡二卡四卡免费| 午夜精品国产一区二区电影| 国产精品久久久久久久电影| 七月丁香在线播放| 好男人视频免费观看在线| 熟妇人妻不卡中文字幕| 日韩熟女老妇一区二区性免费视频| 国产一区二区在线观看日韩| 王馨瑶露胸无遮挡在线观看| 九九爱精品视频在线观看| 国产黄片美女视频| 自拍欧美九色日韩亚洲蝌蚪91 | 亚洲精品日韩在线中文字幕| 18禁在线播放成人免费| 特大巨黑吊av在线直播| 欧美日本中文国产一区发布| 五月伊人婷婷丁香| av国产久精品久网站免费入址| 国产在线一区二区三区精| 色94色欧美一区二区| 视频区图区小说| 毛片一级片免费看久久久久| 91成人精品电影| 精品国产一区二区三区久久久樱花| 精品久久久久久电影网| 在现免费观看毛片| 国产欧美日韩精品一区二区| 国内少妇人妻偷人精品xxx网站| 国产亚洲午夜精品一区二区久久| 水蜜桃什么品种好| 麻豆成人av视频| 街头女战士在线观看网站| 在线观看美女被高潮喷水网站| 欧美丝袜亚洲另类| 国产黄片美女视频| 欧美精品国产亚洲| 麻豆精品久久久久久蜜桃| 熟女av电影| 国产精品偷伦视频观看了| 人人澡人人妻人| 亚洲精品中文字幕在线视频 | 狂野欧美激情性xxxx在线观看| 韩国av在线不卡| 久久亚洲国产成人精品v| 国产真实伦视频高清在线观看| 午夜免费鲁丝| 日日啪夜夜爽| 在线看a的网站| 少妇的逼好多水| 国产精品99久久99久久久不卡 | 在线观看免费日韩欧美大片 | 91精品国产九色| 岛国毛片在线播放| 菩萨蛮人人尽说江南好唐韦庄| 国产成人免费无遮挡视频| 久久精品国产a三级三级三级| 久久久久久久久久人人人人人人| 国产成人免费观看mmmm| 亚洲av免费高清在线观看| 青春草视频在线免费观看| 成人毛片a级毛片在线播放| 一级毛片电影观看| 晚上一个人看的免费电影| 日韩熟女老妇一区二区性免费视频| 日韩制服骚丝袜av| 国产成人aa在线观看| a级片在线免费高清观看视频| 黄片无遮挡物在线观看| 午夜福利视频精品| 日韩精品免费视频一区二区三区 | 91精品一卡2卡3卡4卡| 国产精品成人在线| 好男人视频免费观看在线| 国产一区有黄有色的免费视频| 我的老师免费观看完整版| 国产亚洲最大av| 欧美3d第一页| 成人亚洲精品一区在线观看| 国国产精品蜜臀av免费| 女的被弄到高潮叫床怎么办| 老司机影院毛片| 五月玫瑰六月丁香| 免费看av在线观看网站| 国产av码专区亚洲av| 国产男人的电影天堂91| 人妻系列 视频| 国产精品99久久久久久久久| 日韩大片免费观看网站| 青春草国产在线视频| 看免费成人av毛片| 大片电影免费在线观看免费| 国产精品久久久久久久久免| 九九在线视频观看精品| 国产高清国产精品国产三级| 亚洲精品一区蜜桃| 亚洲av中文av极速乱| 青青草视频在线视频观看| 免费黄网站久久成人精品| 全区人妻精品视频| 人人妻人人添人人爽欧美一区卜| 久久久久久久久久久丰满| 国产女主播在线喷水免费视频网站| 久久ye,这里只有精品| 国产精品久久久久久久久免| 纵有疾风起免费观看全集完整版| 男女国产视频网站| av女优亚洲男人天堂| 99久久精品一区二区三区| 高清午夜精品一区二区三区| 中文精品一卡2卡3卡4更新| 少妇熟女欧美另类| 熟女电影av网| 精品少妇久久久久久888优播| 国产日韩欧美亚洲二区| 久久99蜜桃精品久久| 热re99久久国产66热| 欧美精品高潮呻吟av久久| 午夜av观看不卡| 亚洲婷婷狠狠爱综合网| a级片在线免费高清观看视频| 26uuu在线亚洲综合色| 国语对白做爰xxxⅹ性视频网站| h视频一区二区三区| 国产 一区精品| 亚洲国产最新在线播放| 久久久久久久久久成人| 国产亚洲欧美精品永久| 亚洲国产欧美日韩在线播放 | 少妇熟女欧美另类| 国产探花极品一区二区| 亚州av有码| 人妻系列 视频| .国产精品久久| 一级a做视频免费观看| 亚洲av综合色区一区| av福利片在线观看| 丰满乱子伦码专区| tube8黄色片| 这个男人来自地球电影免费观看 | 亚洲不卡免费看| 午夜福利网站1000一区二区三区| 91精品国产国语对白视频| 国产日韩欧美在线精品| 看非洲黑人一级黄片| 大香蕉97超碰在线| 日韩熟女老妇一区二区性免费视频| 精品午夜福利在线看| 免费看av在线观看网站| 天天躁夜夜躁狠狠久久av| 一区二区三区四区激情视频| 午夜免费男女啪啪视频观看| 各种免费的搞黄视频| 韩国高清视频一区二区三区| 日本黄大片高清| 日本av手机在线免费观看| 久久久国产欧美日韩av| 精华霜和精华液先用哪个| 在现免费观看毛片| 老司机影院毛片| 亚洲欧洲精品一区二区精品久久久 | 美女福利国产在线| 亚洲精品一二三| 国产精品秋霞免费鲁丝片| 下体分泌物呈黄色| 全区人妻精品视频| 卡戴珊不雅视频在线播放| 亚洲第一av免费看| 国产真实伦视频高清在线观看| 免费观看的影片在线观看| 蜜桃在线观看..| 国产欧美日韩综合在线一区二区 | 在线天堂最新版资源| 中国国产av一级| 丁香六月天网| 如日韩欧美国产精品一区二区三区 | 校园人妻丝袜中文字幕| 日韩欧美一区视频在线观看 | 男人添女人高潮全过程视频| 少妇人妻久久综合中文| 国产亚洲一区二区精品| 日韩人妻高清精品专区| 久久国内精品自在自线图片| 日韩熟女老妇一区二区性免费视频| 欧美另类一区| 大又大粗又爽又黄少妇毛片口| 日本色播在线视频| 一级黄片播放器| 欧美区成人在线视频| 青春草亚洲视频在线观看| 国产色爽女视频免费观看| 国产一区二区三区av在线| 久久久久网色| 中文字幕人妻丝袜制服| 精品卡一卡二卡四卡免费| 熟女av电影| 五月玫瑰六月丁香| 涩涩av久久男人的天堂| 亚洲av成人精品一二三区| 久久精品夜色国产| 两个人的视频大全免费| 中文字幕精品免费在线观看视频 | 欧美变态另类bdsm刘玥| 777米奇影视久久| 亚洲精品国产av蜜桃| 天天躁夜夜躁狠狠久久av| 午夜91福利影院| 午夜福利,免费看| 大片电影免费在线观看免费| 欧美成人午夜免费资源| 精品久久久久久久久亚洲| 下体分泌物呈黄色| 国产免费福利视频在线观看| 日韩免费高清中文字幕av| 不卡视频在线观看欧美| 亚洲国产精品一区三区| 成人午夜精彩视频在线观看| xxx大片免费视频| 国产爽快片一区二区三区| 欧美亚洲 丝袜 人妻 在线| 欧美 亚洲 国产 日韩一| 人人妻人人爽人人添夜夜欢视频 | av卡一久久| 精品亚洲乱码少妇综合久久| 永久网站在线| 黑人猛操日本美女一级片| 极品教师在线视频| 国产有黄有色有爽视频| 狂野欧美激情性xxxx在线观看| 黑人巨大精品欧美一区二区蜜桃 | 国产精品久久久久久精品古装| a级片在线免费高清观看视频| 日本色播在线视频| av国产精品久久久久影院| 国产亚洲一区二区精品| 99re6热这里在线精品视频| 免费高清在线观看视频在线观看| 久久影院123| 三级国产精品片| 人人妻人人爽人人添夜夜欢视频 | 日韩强制内射视频| 少妇人妻精品综合一区二区| 亚洲性久久影院| 久久精品国产自在天天线| 国产成人免费无遮挡视频| 极品少妇高潮喷水抽搐| 国产女主播在线喷水免费视频网站| 一级片'在线观看视频| 六月丁香七月| 精品久久久噜噜| 亚洲欧美精品专区久久| 女性被躁到高潮视频| 国产白丝娇喘喷水9色精品| 欧美日韩视频高清一区二区三区二| 两个人免费观看高清视频 | 国产精品人妻久久久久久| 精品久久久久久电影网| 黄色视频在线播放观看不卡| 人人妻人人添人人爽欧美一区卜| av不卡在线播放| 丁香六月天网| 男人狂女人下面高潮的视频| 久久久久久久久久成人| 这个男人来自地球电影免费观看 | 嫩草影院入口| 一级av片app| 久久久久久久久久成人| 欧美亚洲 丝袜 人妻 在线| 精品一区在线观看国产| 日韩一区二区三区影片| 高清视频免费观看一区二区| av福利片在线| 最后的刺客免费高清国语| 久久久久久久亚洲中文字幕| 免费高清在线观看视频在线观看| 国产精品免费大片| 国产亚洲一区二区精品| 国产又色又爽无遮挡免| 纵有疾风起免费观看全集完整版| 少妇被粗大猛烈的视频| 日韩大片免费观看网站| 国产在视频线精品| 欧美成人精品欧美一级黄| 亚洲久久久国产精品| 精品久久久久久电影网| 男人和女人高潮做爰伦理| 亚洲人成网站在线观看播放| 99视频精品全部免费 在线| 久久ye,这里只有精品| 久久久久久人妻| 全区人妻精品视频| 日本av免费视频播放| av天堂久久9| 日本黄色片子视频| 国产精品久久久久久精品古装| 国产精品久久久久久久久免| 97超碰精品成人国产| 永久网站在线| 一本色道久久久久久精品综合| 一级毛片黄色毛片免费观看视频| av一本久久久久| 中文字幕亚洲精品专区| 99视频精品全部免费 在线| 大片电影免费在线观看免费| 国内精品宾馆在线| 久久狼人影院| 老司机影院毛片| 亚洲av.av天堂| av国产久精品久网站免费入址| 免费黄频网站在线观看国产| 大话2 男鬼变身卡| 校园人妻丝袜中文字幕| 熟妇人妻不卡中文字幕| av网站免费在线观看视频| 一级二级三级毛片免费看| 久久久a久久爽久久v久久| 自拍偷自拍亚洲精品老妇| 性色avwww在线观看| 国产又色又爽无遮挡免| av播播在线观看一区| 欧美性感艳星| 国产中年淑女户外野战色| 国产精品麻豆人妻色哟哟久久| 夜夜看夜夜爽夜夜摸| 欧美少妇被猛烈插入视频| 一级av片app| 成人免费观看视频高清| 大片电影免费在线观看免费| 乱系列少妇在线播放| 成年人免费黄色播放视频 | 亚洲精品国产成人久久av| 亚洲av在线观看美女高潮| 汤姆久久久久久久影院中文字幕| 亚洲国产精品一区三区| 国产91av在线免费观看| 欧美区成人在线视频| 成人特级av手机在线观看| 天堂俺去俺来也www色官网| 欧美日本中文国产一区发布| 亚州av有码| 建设人人有责人人尽责人人享有的| 欧美老熟妇乱子伦牲交| av福利片在线| 国产美女午夜福利| 久久精品国产亚洲av涩爱| 一本色道久久久久久精品综合| 国产亚洲一区二区精品| 亚洲欧美精品自产自拍| 久久97久久精品| 久久久欧美国产精品| 草草在线视频免费看| 欧美精品亚洲一区二区| 国产精品一区二区三区四区免费观看| 黑人高潮一二区| 女性被躁到高潮视频| 在线观看一区二区三区激情| 亚洲av日韩在线播放| 2018国产大陆天天弄谢| 国产69精品久久久久777片| 亚洲中文av在线| 2018国产大陆天天弄谢| 丝袜在线中文字幕| 一区二区av电影网| 亚洲不卡免费看| 91aial.com中文字幕在线观看| 国产精品熟女久久久久浪| 午夜视频国产福利| 街头女战士在线观看网站| 久久精品久久精品一区二区三区| 嘟嘟电影网在线观看| 人人妻人人澡人人爽人人夜夜| 日韩av免费高清视频| 亚洲美女搞黄在线观看| 日韩欧美 国产精品| 国产综合精华液| 久久鲁丝午夜福利片| 大片免费播放器 马上看| 在线天堂最新版资源| 国产精品熟女久久久久浪| 成人毛片a级毛片在线播放| 亚洲欧美日韩另类电影网站| 中文在线观看免费www的网站| 国产精品国产av在线观看| 亚洲欧美成人综合另类久久久| 国产精品国产三级国产专区5o| 全区人妻精品视频| 最近中文字幕高清免费大全6| 国产欧美日韩精品一区二区| 亚洲伊人久久精品综合| kizo精华| 多毛熟女@视频| 在线观看一区二区三区激情| 美女国产视频在线观看| 国产69精品久久久久777片| 成人毛片a级毛片在线播放| 18禁在线无遮挡免费观看视频| 亚洲精品国产av蜜桃| kizo精华| 国产精品秋霞免费鲁丝片| 韩国av在线不卡| 免费观看在线日韩| 久久 成人 亚洲| 秋霞伦理黄片| 国产成人91sexporn| 美女视频免费永久观看网站| 久久久午夜欧美精品| 免费黄色在线免费观看| 看非洲黑人一级黄片| 欧美3d第一页| 亚洲精品自拍成人| 五月天丁香电影| .国产精品久久| 亚洲精品国产色婷婷电影| 亚洲精品456在线播放app| 纵有疾风起免费观看全集完整版| 91精品国产国语对白视频| 午夜免费男女啪啪视频观看| 国产一区亚洲一区在线观看| 国产在线一区二区三区精| 久久99蜜桃精品久久| 国产淫片久久久久久久久| 你懂的网址亚洲精品在线观看| 一本大道久久a久久精品| 日韩人妻高清精品专区| 中文字幕亚洲精品专区| 日韩中文字幕视频在线看片| 日日摸夜夜添夜夜添av毛片| 日日摸夜夜添夜夜爱| 国产有黄有色有爽视频| 久久人人爽人人片av| 国产欧美日韩综合在线一区二区 | 99国产精品免费福利视频| 亚洲国产精品一区三区| 国产又色又爽无遮挡免| 97超视频在线观看视频| 99热这里只有精品一区| 亚洲精品亚洲一区二区| 久久国内精品自在自线图片| 亚洲欧美日韩东京热| 亚洲av电影在线观看一区二区三区| 国产成人精品一,二区| 少妇丰满av| 国产乱来视频区| 亚洲欧美精品自产自拍| 午夜91福利影院| 亚洲av二区三区四区| 亚洲,一卡二卡三卡| 不卡视频在线观看欧美| 9色porny在线观看| a级片在线免费高清观看视频| 色哟哟·www| 青春草视频在线免费观看| 国产亚洲91精品色在线| 男人添女人高潮全过程视频| 欧美精品国产亚洲| 夜夜爽夜夜爽视频| 免费观看av网站的网址| 3wmmmm亚洲av在线观看| 亚洲不卡免费看| 亚洲国产av新网站| 亚洲图色成人| 又大又黄又爽视频免费| 伊人久久国产一区二区| 色婷婷av一区二区三区视频| 中文字幕人妻熟人妻熟丝袜美| 日日撸夜夜添| 亚洲精品乱码久久久v下载方式| 又爽又黄a免费视频| 中文欧美无线码| 国产乱来视频区| 日产精品乱码卡一卡2卡三| 男人爽女人下面视频在线观看| 你懂的网址亚洲精品在线观看| 国产成人a∨麻豆精品| 国产在线免费精品| 天美传媒精品一区二区| 18+在线观看网站| 欧美国产精品一级二级三级 | 亚洲av中文av极速乱| 亚洲人与动物交配视频| 男的添女的下面高潮视频| 熟女人妻精品中文字幕| 久久免费观看电影| 精品人妻熟女av久视频| 国产精品国产三级专区第一集| 成人影院久久| 亚洲精品成人av观看孕妇| 大话2 男鬼变身卡| 日韩亚洲欧美综合| 国产女主播在线喷水免费视频网站| 一区二区三区免费毛片| 色网站视频免费| 日韩免费高清中文字幕av| 日本免费在线观看一区| 一级毛片我不卡| 中文字幕人妻丝袜制服| 美女cb高潮喷水在线观看| 制服丝袜香蕉在线| 色视频www国产| 爱豆传媒免费全集在线观看| 一个人看视频在线观看www免费| 热99国产精品久久久久久7| 国产熟女午夜一区二区三区 | 黄色配什么色好看| 国产成人aa在线观看| 日本wwww免费看| 97超碰精品成人国产| 一区二区三区乱码不卡18| 亚洲真实伦在线观看| 免费黄频网站在线观看国产| 观看美女的网站| 我的老师免费观看完整版| 午夜精品国产一区二区电影| 久久久精品94久久精品| 国产av精品麻豆| 国产无遮挡羞羞视频在线观看| 亚洲av.av天堂| 午夜免费观看性视频| 美女内射精品一级片tv| 自拍偷自拍亚洲精品老妇| 一级爰片在线观看| 高清不卡的av网站| 久久免费观看电影| 精品亚洲成a人片在线观看| 国产综合精华液| 两个人的视频大全免费| 黑人巨大精品欧美一区二区蜜桃 | 2018国产大陆天天弄谢| 亚洲经典国产精华液单| 建设人人有责人人尽责人人享有的| 一级毛片 在线播放| 十八禁网站网址无遮挡 | 少妇被粗大猛烈的视频| 赤兔流量卡办理| 日韩免费高清中文字幕av| 久久国产乱子免费精品| 午夜免费观看性视频| 欧美日韩国产mv在线观看视频| 亚洲美女黄色视频免费看| 久久精品熟女亚洲av麻豆精品| 好男人视频免费观看在线| 中文欧美无线码| 日韩精品免费视频一区二区三区 | 亚洲一级一片aⅴ在线观看| 免费看光身美女| 国产成人aa在线观看| av免费在线看不卡| 亚洲国产日韩一区二区| 免费黄色在线免费观看| 少妇人妻久久综合中文| 99热这里只有是精品50| 久久韩国三级中文字幕| 自拍偷自拍亚洲精品老妇| 久久狼人影院| 国模一区二区三区四区视频| 亚洲熟女精品中文字幕| 国产av一区二区精品久久| 美女cb高潮喷水在线观看| 3wmmmm亚洲av在线观看| 免费看不卡的av| 日本欧美国产在线视频| 亚洲av成人精品一二三区| 色5月婷婷丁香| 下体分泌物呈黄色| av免费在线看不卡| 岛国毛片在线播放| 三级国产精品片| 免费久久久久久久精品成人欧美视频 | 日韩成人av中文字幕在线观看|