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

    久久久久精品国产欧美久久久| 国产1区2区3区精品| 欧美日本视频| 一本精品99久久精品77| 国内精品久久久久久久电影| 亚洲免费av在线视频| 免费看日本二区| 日本在线视频免费播放| 成年免费大片在线观看| 久久精品91无色码中文字幕| 久久人妻福利社区极品人妻图片| 91成年电影在线观看| 国产免费av片在线观看野外av| av天堂在线播放| 亚洲人成网站在线播放欧美日韩| 国产主播在线观看一区二区| 精品少妇一区二区三区视频日本电影| 中文字幕av在线有码专区| 欧美中文综合在线视频| 亚洲av熟女| 91麻豆精品激情在线观看国产| 老汉色∧v一级毛片| 久久精品国产综合久久久| 亚洲av第一区精品v没综合| 九色国产91popny在线| 午夜福利免费观看在线| 久久中文看片网| 国产不卡一卡二| 久久精品aⅴ一区二区三区四区| 丁香欧美五月| 夜夜看夜夜爽夜夜摸| xxx96com| 国产亚洲欧美98| 狂野欧美白嫩少妇大欣赏| 两性夫妻黄色片| 午夜两性在线视频| 国产成人精品无人区| 国产精品乱码一区二三区的特点| 好男人在线观看高清免费视频| 亚洲精品粉嫩美女一区| 欧美黄色片欧美黄色片| 亚洲国产高清在线一区二区三| 一级毛片高清免费大全| 母亲3免费完整高清在线观看| 草草在线视频免费看| 好男人电影高清在线观看| 色综合欧美亚洲国产小说| 欧美日韩中文字幕国产精品一区二区三区| 国语自产精品视频在线第100页| 俺也久久电影网| 欧美日韩中文字幕国产精品一区二区三区| 国产真人三级小视频在线观看| 99久久精品国产亚洲精品| 亚洲精品美女久久av网站| 日韩 欧美 亚洲 中文字幕| 久久久久久九九精品二区国产 | 亚洲av熟女| 香蕉丝袜av| 麻豆国产97在线/欧美 | 亚洲欧洲精品一区二区精品久久久| 亚洲精品美女久久久久99蜜臀| 午夜视频精品福利| 亚洲第一电影网av| 成年人黄色毛片网站| av在线天堂中文字幕| 宅男免费午夜| 国产真人三级小视频在线观看| 国产野战对白在线观看| 三级国产精品欧美在线观看 | 黄色女人牲交| 亚洲欧美日韩东京热| 国内精品久久久久久久电影| 黄色视频,在线免费观看| www.999成人在线观看| 成人特级黄色片久久久久久久| 91大片在线观看| 日本一二三区视频观看| 这个男人来自地球电影免费观看| 亚洲av成人av| 国产免费av片在线观看野外av| 又紧又爽又黄一区二区| 无限看片的www在线观看| 亚洲国产精品久久男人天堂| 午夜激情福利司机影院| 三级毛片av免费| 18禁黄网站禁片午夜丰满| 日韩精品免费视频一区二区三区| 国产私拍福利视频在线观看| 国产91精品成人一区二区三区| a级毛片a级免费在线| 女同久久另类99精品国产91| 99热6这里只有精品| 亚洲第一欧美日韩一区二区三区| 97超级碰碰碰精品色视频在线观看| 非洲黑人性xxxx精品又粗又长| 午夜福利成人在线免费观看| 老司机福利观看| 久久热在线av| 久久久久久久久中文| 国产乱人伦免费视频| 精品国产超薄肉色丝袜足j| 中文字幕人成人乱码亚洲影| 久久伊人香网站| 国产亚洲精品av在线| 白带黄色成豆腐渣| 国产精品免费视频内射| 国产亚洲精品一区二区www| 在线十欧美十亚洲十日本专区| 窝窝影院91人妻| 黑人巨大精品欧美一区二区mp4| 此物有八面人人有两片| 人人妻人人澡欧美一区二区| 国内揄拍国产精品人妻在线| 亚洲精品国产精品久久久不卡| 亚洲人成77777在线视频| 免费搜索国产男女视频| 欧美色视频一区免费| 99久久国产精品久久久| 国产亚洲欧美98| 50天的宝宝边吃奶边哭怎么回事| 亚洲中文日韩欧美视频| 亚洲一区二区三区不卡视频| 亚洲色图av天堂| av福利片在线观看| 亚洲精品中文字幕在线视频| 日本黄色视频三级网站网址| 最好的美女福利视频网| 巨乳人妻的诱惑在线观看| 草草在线视频免费看| 亚洲18禁久久av| 亚洲国产看品久久| 国产主播在线观看一区二区| 午夜a级毛片| 亚洲精品色激情综合| 俄罗斯特黄特色一大片| 香蕉丝袜av| 欧美日韩一级在线毛片| 国产v大片淫在线免费观看| 精品一区二区三区av网在线观看| 校园春色视频在线观看| 日韩欧美国产在线观看| 激情在线观看视频在线高清| 久久久久久九九精品二区国产 | 男人舔奶头视频| 男女下面进入的视频免费午夜| 18禁国产床啪视频网站| 黄频高清免费视频| 久9热在线精品视频| 国产区一区二久久| 熟女少妇亚洲综合色aaa.| 一卡2卡三卡四卡精品乱码亚洲| 色尼玛亚洲综合影院| 淫妇啪啪啪对白视频| 国产成+人综合+亚洲专区| 国产一级毛片七仙女欲春2| 在线观看www视频免费| 久久国产乱子伦精品免费另类| 国产黄a三级三级三级人| 99在线人妻在线中文字幕| 国产精品精品国产色婷婷| 久9热在线精品视频| 色综合欧美亚洲国产小说| 欧美国产日韩亚洲一区| 国产高清videossex| 日韩欧美在线乱码| 国产午夜福利久久久久久| 99精品欧美一区二区三区四区| 免费搜索国产男女视频| 国产成人aa在线观看| av片东京热男人的天堂| 亚洲天堂国产精品一区在线| 黑人巨大精品欧美一区二区mp4| 久久精品人妻少妇| 日韩免费av在线播放| 免费电影在线观看免费观看| 一个人免费在线观看电影 | 久久九九热精品免费| 蜜桃久久精品国产亚洲av| 日韩欧美在线乱码| 国产爱豆传媒在线观看 | 亚洲中文日韩欧美视频| 一本综合久久免费| 国产亚洲精品一区二区www| 久久久久久人人人人人| 99热只有精品国产| 免费电影在线观看免费观看| 久久人妻福利社区极品人妻图片| 免费在线观看成人毛片| 精品国内亚洲2022精品成人| 免费在线观看视频国产中文字幕亚洲| 老司机在亚洲福利影院| 天天躁夜夜躁狠狠躁躁| av欧美777| 听说在线观看完整版免费高清| 十八禁人妻一区二区| 精品久久久久久久久久久久久| 精品久久久久久久人妻蜜臀av| 日本成人三级电影网站| 熟女电影av网| 国产人伦9x9x在线观看| 国内精品一区二区在线观看| 精品电影一区二区在线| 亚洲av成人不卡在线观看播放网| 一区福利在线观看| 90打野战视频偷拍视频| tocl精华| 久久久久精品国产欧美久久久| 国产精品亚洲美女久久久| 亚洲全国av大片| 天堂√8在线中文| av超薄肉色丝袜交足视频| 久久久久性生活片| 啦啦啦韩国在线观看视频| 国内精品一区二区在线观看| 亚洲av成人不卡在线观看播放网| 欧美黄色片欧美黄色片| 国产精品一及| 免费看十八禁软件| 可以免费在线观看a视频的电影网站| 无限看片的www在线观看| 女人高潮潮喷娇喘18禁视频| 亚洲精品色激情综合| 最近在线观看免费完整版| 天堂影院成人在线观看| 亚洲熟女毛片儿| 久久精品夜夜夜夜夜久久蜜豆 | xxxwww97欧美| 日日摸夜夜添夜夜添小说| 日韩免费av在线播放| 黄片小视频在线播放| 久久久久国内视频| 成人亚洲精品av一区二区| 99国产精品一区二区三区| ponron亚洲| 丰满人妻一区二区三区视频av | 99热这里只有是精品50| 亚洲一区二区三区色噜噜| 亚洲国产欧洲综合997久久,| 国产成人影院久久av| 国产探花在线观看一区二区| 黄色 视频免费看| 九色成人免费人妻av| 色精品久久人妻99蜜桃| 成人亚洲精品av一区二区| 国产亚洲av高清不卡| 亚洲av美国av| 母亲3免费完整高清在线观看| 欧美国产日韩亚洲一区| av福利片在线观看| 久久天堂一区二区三区四区| 成人手机av| 国产精品电影一区二区三区| 日本黄大片高清| 久久精品aⅴ一区二区三区四区| 久久精品成人免费网站| 久久热在线av| 欧美+亚洲+日韩+国产| 免费看美女性在线毛片视频| e午夜精品久久久久久久| 亚洲va日本ⅴa欧美va伊人久久| 欧美黑人精品巨大| 制服诱惑二区| 波多野结衣巨乳人妻| 久久国产乱子伦精品免费另类| 嫩草影院精品99| 成年免费大片在线观看| 天天一区二区日本电影三级| 99re在线观看精品视频| 国产av不卡久久| 久久精品国产99精品国产亚洲性色| 国产精品99久久99久久久不卡| 日韩欧美三级三区| 禁无遮挡网站| 黄色毛片三级朝国网站| 久久久国产欧美日韩av| 国产成人精品久久二区二区91| 日本三级黄在线观看| 亚洲成人免费电影在线观看| 天堂动漫精品| 国产亚洲欧美98| 在线观看免费视频日本深夜| 丰满人妻一区二区三区视频av | 特级一级黄色大片| 国产高清激情床上av| www.www免费av| 可以在线观看毛片的网站| 最好的美女福利视频网| 国产亚洲精品久久久久5区| 国产片内射在线| 女同久久另类99精品国产91| 亚洲国产欧美人成| 久久草成人影院| av免费在线观看网站| 国产精品日韩av在线免费观看| 久久久久性生活片| 国产黄片美女视频| 美女大奶头视频| 给我免费播放毛片高清在线观看| 中文字幕高清在线视频| 午夜影院日韩av| 老鸭窝网址在线观看| 亚洲 欧美一区二区三区| 一级a爱片免费观看的视频| 舔av片在线| 蜜桃久久精品国产亚洲av| 999久久久精品免费观看国产| 久久精品综合一区二区三区| 午夜激情福利司机影院| 欧美性长视频在线观看| 国产欧美日韩一区二区三| 午夜精品久久久久久毛片777| 好看av亚洲va欧美ⅴa在| 国产精品久久久久久精品电影| 男插女下体视频免费在线播放| 精品高清国产在线一区| 国产精品香港三级国产av潘金莲| 精品欧美国产一区二区三| 一本精品99久久精品77| 老熟妇仑乱视频hdxx| 欧美成人性av电影在线观看| 久久人妻av系列| 日韩欧美国产一区二区入口| 国产成人精品无人区| 免费在线观看日本一区| 麻豆久久精品国产亚洲av| 男女之事视频高清在线观看| 黄色丝袜av网址大全| 999精品在线视频| 午夜亚洲福利在线播放| 在线播放国产精品三级| 999久久久国产精品视频| 69av精品久久久久久| 国产在线精品亚洲第一网站| 身体一侧抽搐| 视频区欧美日本亚洲| 狂野欧美激情性xxxx| 曰老女人黄片| 亚洲精品久久成人aⅴ小说| 午夜老司机福利片| 国产亚洲精品综合一区在线观看 | 精品久久久久久成人av| 两个人的视频大全免费| 国内毛片毛片毛片毛片毛片| 最新美女视频免费是黄的| 免费看a级黄色片| 国产欧美日韩一区二区精品| 欧美 亚洲 国产 日韩一| 99在线人妻在线中文字幕| 国产久久久一区二区三区| 大型黄色视频在线免费观看| 欧美在线一区亚洲| 亚洲 欧美一区二区三区| 男女做爰动态图高潮gif福利片| 国产日本99.免费观看| 欧美三级亚洲精品| 一二三四社区在线视频社区8| 精品日产1卡2卡| 伊人久久大香线蕉亚洲五| 久久精品成人免费网站| 亚洲av中文字字幕乱码综合| 久久精品国产亚洲av香蕉五月| 别揉我奶头~嗯~啊~动态视频| 国产精品野战在线观看| 99久久精品热视频| 老司机午夜十八禁免费视频| 成人特级黄色片久久久久久久| 制服丝袜大香蕉在线| 看免费av毛片| 亚洲国产精品999在线| 麻豆国产av国片精品| 757午夜福利合集在线观看| 中文字幕人妻丝袜一区二区| 国产精品亚洲av一区麻豆| 亚洲国产高清在线一区二区三| 免费观看人在逋| 中文字幕久久专区| 欧美av亚洲av综合av国产av| 久久久久国内视频| 国产熟女xx| 日韩三级视频一区二区三区| 熟女少妇亚洲综合色aaa.| 久久久久亚洲av毛片大全| 久久精品91无色码中文字幕| 91在线观看av| 国产精品,欧美在线| 亚洲欧美精品综合久久99| 99久久久亚洲精品蜜臀av| 亚洲国产精品成人综合色| 好看av亚洲va欧美ⅴa在| 一二三四社区在线视频社区8| 婷婷丁香在线五月| 一进一出抽搐gif免费好疼| 母亲3免费完整高清在线观看| 国产成人av激情在线播放| 一级a爱片免费观看的视频| 久9热在线精品视频| 免费一级毛片在线播放高清视频| 久久精品国产亚洲av香蕉五月| 欧美成狂野欧美在线观看| 国产精品国产高清国产av| 亚洲av日韩精品久久久久久密| 首页视频小说图片口味搜索| 国产午夜福利久久久久久| 一级片免费观看大全| 中文字幕高清在线视频| 丰满的人妻完整版| 99久久综合精品五月天人人| 欧美+亚洲+日韩+国产| 久久精品成人免费网站| 9191精品国产免费久久| 在线免费观看的www视频| 久久久久久久精品吃奶| 天堂av国产一区二区熟女人妻 | 日本 欧美在线| 高清在线国产一区| 亚洲精品在线美女| 国产一区二区在线av高清观看| 午夜久久久久精精品| 美女午夜性视频免费| 久久久精品国产亚洲av高清涩受| 1024香蕉在线观看| 亚洲激情在线av| 欧美人与性动交α欧美精品济南到| 成人高潮视频无遮挡免费网站| av有码第一页| 国产av一区在线观看免费| 久久人人精品亚洲av| 搞女人的毛片| 亚洲全国av大片| 国产精品 国内视频| 国产成人精品久久二区二区免费| 美女黄网站色视频| 狂野欧美激情性xxxx| 日韩欧美国产一区二区入口| 久久久久九九精品影院| 国产精品国产高清国产av| av在线天堂中文字幕| 久久午夜综合久久蜜桃| 亚洲国产看品久久| 黄色片一级片一级黄色片| 亚洲精品中文字幕在线视频| 亚洲精品久久国产高清桃花| 日本熟妇午夜| 最近视频中文字幕2019在线8| 麻豆成人午夜福利视频| 日本黄色视频三级网站网址| 国产精品久久久久久人妻精品电影| 中文资源天堂在线| 宅男免费午夜| 亚洲国产中文字幕在线视频| 久久久久亚洲av毛片大全| 日本一区二区免费在线视频| 夜夜看夜夜爽夜夜摸| 夜夜爽天天搞| 熟妇人妻久久中文字幕3abv| 女生性感内裤真人,穿戴方法视频| 熟女少妇亚洲综合色aaa.| 欧美在线黄色| 免费看日本二区| 国产精品影院久久| 国产欧美日韩一区二区精品| 777久久人妻少妇嫩草av网站| 国产成人精品无人区| 久久久久免费精品人妻一区二区| 日韩欧美三级三区| 国内久久婷婷六月综合欲色啪| 国产成人系列免费观看| 97超级碰碰碰精品色视频在线观看| 午夜两性在线视频| 中亚洲国语对白在线视频| 天天一区二区日本电影三级| 国产精品日韩av在线免费观看| 日韩大尺度精品在线看网址| 国产在线观看jvid| e午夜精品久久久久久久| 免费看a级黄色片| 亚洲人与动物交配视频| 麻豆久久精品国产亚洲av| 欧美zozozo另类| 少妇熟女aⅴ在线视频| 亚洲精品国产精品久久久不卡| 欧美大码av| 99re在线观看精品视频| 两人在一起打扑克的视频| 999久久久国产精品视频| 国产真实乱freesex| 999精品在线视频| 日韩高清综合在线| 久久精品亚洲精品国产色婷小说| 在线免费观看的www视频| 久久久精品国产亚洲av高清涩受| 好男人电影高清在线观看| 亚洲人与动物交配视频| 久热爱精品视频在线9| 国产高清视频在线观看网站| 中文在线观看免费www的网站 | 18禁美女被吸乳视频| 99久久99久久久精品蜜桃| 国产一区二区激情短视频| 欧美大码av| 草草在线视频免费看| 校园春色视频在线观看| 美女免费视频网站| aaaaa片日本免费| 成人国产一区最新在线观看| 最近在线观看免费完整版| 国产99白浆流出| 真人一进一出gif抽搐免费| 一边摸一边做爽爽视频免费| 中亚洲国语对白在线视频| 国产1区2区3区精品| 99精品欧美一区二区三区四区| 久久久久久久久免费视频了| 国产精品久久久久久精品电影| 校园春色视频在线观看| 亚洲欧美日韩无卡精品| 欧美丝袜亚洲另类 | 日韩大尺度精品在线看网址| 十八禁网站免费在线| 制服人妻中文乱码| 国产91精品成人一区二区三区| 国产高清videossex| 18禁黄网站禁片免费观看直播| 欧美黄色淫秽网站| 免费看a级黄色片| xxxwww97欧美| 日韩欧美国产一区二区入口| 老司机午夜十八禁免费视频| 国产野战对白在线观看| 桃色一区二区三区在线观看| 亚洲专区中文字幕在线| 最近在线观看免费完整版| 一区二区三区高清视频在线| 一进一出抽搐动态| 伊人久久大香线蕉亚洲五| aaaaa片日本免费| 亚洲乱码一区二区免费版| 性欧美人与动物交配| 国产三级中文精品| 亚洲成av人片免费观看| 欧美绝顶高潮抽搐喷水| 黄片小视频在线播放| 人成视频在线观看免费观看| 亚洲一区高清亚洲精品| 欧美日韩精品网址| 欧美午夜高清在线| 国产精品 国内视频| 高清在线国产一区| www日本在线高清视频| 五月伊人婷婷丁香| 久久中文字幕人妻熟女| 日日摸夜夜添夜夜添小说| 草草在线视频免费看| 精品午夜福利视频在线观看一区| 国产又色又爽无遮挡免费看| 婷婷丁香在线五月| 国内揄拍国产精品人妻在线| 国产人伦9x9x在线观看| 国产精品一区二区三区四区久久| 国产精品野战在线观看| 欧美日韩亚洲综合一区二区三区_| 不卡av一区二区三区| 精品久久久久久久末码| 欧美日韩黄片免| 别揉我奶头~嗯~啊~动态视频| 日本五十路高清| 老司机福利观看| 91麻豆精品激情在线观看国产| 淫妇啪啪啪对白视频| 午夜福利免费观看在线| 亚洲自偷自拍图片 自拍| 欧美在线一区亚洲| 亚洲人成网站在线播放欧美日韩| 成人av在线播放网站| 久久欧美精品欧美久久欧美| 老司机午夜福利在线观看视频| 两个人免费观看高清视频| 日本一本二区三区精品| 两个人免费观看高清视频| 欧美成人免费av一区二区三区| 两个人免费观看高清视频| 夜夜躁狠狠躁天天躁| 亚洲熟妇熟女久久| 久久久久久久久中文| 欧美日韩亚洲综合一区二区三区_| 国内精品一区二区在线观看| a级毛片在线看网站| 老汉色∧v一级毛片| 精品欧美国产一区二区三| 波多野结衣高清无吗| 精品日产1卡2卡| 久久精品国产清高在天天线| 一级毛片女人18水好多| 亚洲中文av在线| 特级一级黄色大片| 国产精品 国内视频| 999精品在线视频| 亚洲免费av在线视频| 日韩精品免费视频一区二区三区| 中文字幕最新亚洲高清| 长腿黑丝高跟| 国产成+人综合+亚洲专区| 欧美黑人巨大hd| 国产午夜精品论理片| 亚洲五月天丁香| 精品一区二区三区视频在线观看免费| 女警被强在线播放| 搡老岳熟女国产| 久久午夜综合久久蜜桃| 久久久久久国产a免费观看| 两性午夜刺激爽爽歪歪视频在线观看 | 亚洲国产精品999在线| 日本在线视频免费播放| 床上黄色一级片| 日韩国内少妇激情av|