Simulation based early Validation and Verification is a key enabler for the Model Based Development of complex systems. These activities usually require distinct models for the System of Interest and for its execution environment. For Cyber-Physical Systems, the second kind combines generic environment behavioral models with scenarios that drive specific simulations. When these systems are developed in Extended Enterprises, several sub-systems are developed concurrently and the associated models may not be available when assessing some specific sub-system S developed by a given partner P, or might be cloaked to protect the Intellectual Property of the other partners. These other sub-systems thus become parts of the environment of S and appropriate models might need to be developed by the P partner when conducting simulations. This contribution illustrates these issues relying on the AIDA plane inspection system developed in the IRT Saint Exupéry MOISE project.
Many complex Cyber-Physical Systems (CPS) are currently built in Extended Enterprises (EE) where stakeholders try to protect their know-how by minimizing the amount of data they share with the other stakeholders. Model Based Systems Engineering (MBSE) and early simulation based Validation and Verification (V & V) have been shown to significantly improve the efficiency of the development and the quality of the resulting products. In this context, stakeholders protect their know-how by cloaking parts of the models they have built when others need to simulate them during the V & V of their part of the system (called the System of Interest (SoI)). When these systems are built using Concurrent Engineering (CE), some models are even not available when a stakeholder need to conduct V & V activities for a SoI thus requiring him to build intermediate coarse models used for simulation. Our work targets an efficient methodology for building simulation models and associated tools for the V & V of complex CPS in EE. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s).
GEMOC@MODELS’2018, October 2018, Eindhoven, Netherlands © 2018 Copyright held by the owner/author(s).
This contribution first describes the MOISE project where our work takes place and the AIDA use case. Then, it provides first insights on the various categories of simulation models that must be built for AIDA and conclude on planned future activities. 2
The Technological Research Institute (IRT) Antoine de Saint Exupéry
groups industrial and academic partners to transfer research
results to industrial practice in the domain of Aeronautic and Space
industries. The MOISE (MOdels and Information Sharing in
Extended enterprises) project experiments EE aware MBSE Methods
and Tools where simulation is used for models V & V. MOISE relies
on the Arcadia method [
Our work focuses on improving the use of simulation in EE
relying on co-simulation standards like FMI [
To protect the confidential data and know-how of the various
stakeholders in the same project, the various parts of the models
developed by a stakeholder will only be partly available to the other
ones. The FMI standard [
The Airplane Inspection Drone Assistant (AIDA) use case was developed to illustrate and validate the work conducted in MOISE. A drone moves around a plane on the runway before take of (see Figure 2) to support the pilot in the mandatory pre-flight aircraft inspection. AIDA (i) quickens the pilot inspection task and (ii) improves its quality, by allowing scrutinizing all areas, even the ones not-easily-accessible (e.g., top of the wings, crown of the fuselage, . . . ), to detect irregularities, such as forgotten caps on sensors, ill closed trap doors, or mechanical defects. AIDA can be manually controlled following predefined paths (flight plans), with enhanced automated safety capacities to avoid hurting ground staf. AIDA is aware of the cartography of the plane and of the location of the points of interest to be scrutinized. It is equipped with various captors: vision system, GPS locator, and a radar, for a greater precision, to ensure a suficient safe distance with respect to the plane and the ground staf. To enable the diagnostic in case of malfunction, flight data are saved locally and transferred in real-time to the ground. The operator can watch live images taken by the drone, make sure that control points do not present any irregularities, and adapt the drone flight plan. The drone mission is sketched in Figure 2.
Figure 3 is a part of the drone functional architecture model. The left diagram illustrates diferent kinds of functions in the product model: the SoI function assessed by the simulation is in red dotted line; an already developed function whose model is available for the simulation is in orange full line; and the other undeveloped functions whose models are needed by the simulation. The right diagram explained hereafter corresponds to our work in MOISE: how to build the simulation models and yield the executable simulator taking into account EE constraints.
Edward Alan Lee advocates [
In a single enterprise, with a theoretical V lifecycle, the environment is well known, all models are fully shared between all actors and can be built in the best order to ensure the correctness of the model based V & V activities (i.e. the environment models are correct with respect to the real environment and all the needed product models are available when the assessments are conducted).
In an EE, the various stakeholders want to protect their
knowhow and confidential data. In MBSE, these elements can be revealed
by the models. Thus, the stakeholders do not want to share their
models and they wish to hide as much as possible their content.
The FMI standard [
Things can be even worse when using agile processes, where CE is used to maximize the eficiency of the development, it is mandatory to early conduct model based V & V activities even if some of the required external models are not available. The stakeholder that assesses an internal model he has designed must then build approximate external models that are neither fully prescriptive nor fully descriptive. Such models describe the behavior of the system parts that other stakeholders will build using their own prescriptive models. These models might combine parts of the system and parts of its environment. Then, he also wants to limit the level of detail of this model (as it is not prescriptive) to the one needed for a meaningful assessment. The right diagram in Figure 3 illustrates such functions using full red lines. These functions are tagged as internal environment as they are not part of the final models used to build the product. Recall that the function in full orange line is a prescriptive internal model that has already been developed and is thus not tagged in the same way. In these cases, additional verification activities must be conducted to compare the intermediate models that were built by other stakeholders to assess the models they were building, with the final models built by all intended stakeholders.
This contribution illustrated the need for intermediate simulation models when developing a system using agile Concurrent Engineering in an Extended Enterprise. These models are used only to conduct early model based V &V activities and are neither fully prescriptive nor fully descriptive with respect to the product. They must be the subject of additional verification activities. We plan for the future both to extend this work to the full AIDA model and other use cases and lift it to the level of an ontology of models categories for developing Cyber-Physical Systems; and to study the meaning and constraints regarding the work done by Lee.