The new paradigm introduced by the hybridization of a propulsion system has emerged real design problems for propulsion system engineers. A first problem is the introduction of new electrical subsystems into the existing propulsion system. Indeed, these new subsystems have an influence on the other ones, and reciprocally. This report highlights a gap in design process: consideration of mutual impacts of a system on its environment. Due to the fact that directs environment of each system is composed by other systems, introduction of a new system impacts all the entire sizing of the other systems. Consequently, interactions between systems are important to consider in order reaching a valid, or an optimized solution. A concept of impact is introduced to specify more precisely these interactions. A second problem detected by propulsion engineers, is their non-expertise on electrical systems. Consequently, the design and sizing of the system requires a close and smart collaboration with electrical experts who have the required knowledge. The method proposed in this paper is focused on these two problems, and addresses them via the use of systems engineering and physical models. In order to offer a common platform to collaborate, the method is model-based. The goal is to strengthen the link between the systems engineering and physical engineering worlds. With the concept of impact, and the collaboration between people of each world, the method supports project technical orientations and decision-making.
The global idea of the method, illustrated in Fig 1, is to create a collaborative process between the system design and model world and the physical one (systems design and sizing considering physics). The aim is to be able to transit from one world to another via an interface managed by a new actor of the collaboration named "simulation architect". The simulation architect (it can be a team) represents enablers for the architect to obtain expertise model-based conclusions. Each simulation architect has a multidisciplinary vision of a product, and simulation knowledge. It is the interface between the architect and the experts in term of models and simulations (model request, virtual product building, simulations...).
System engineering is a key to develop and produce complex products. The classical V-Cycle is often used to represent and manage the progress of the design process. Following this approach, the suggested method allows to perform integration, verification and validation activities (right part of the V) virtually and frequently, via the use of behavioural model and simulation. In that case, behavioural modelling is mandatory, but cannot be managed by architect only. In the method, the architect takes decision at high level. He proposes the functional architecture which represents an input data of the process. All the functional architecture analysis is supposed to have been done with methods out of the scope of the proposed work. Missions are also required as an input for the methodology. Mission parameters (phases, vehicle speed, alti-tude…) must be defined in order to be used for simulations. Another task dedicated to architect is the interactions and impact analysis. It is deduced from a physical analysis of each subsystem environment and relations. The result of this analysis can be represented under the form of context diagrams [1] [2]. In modelling, physical world is represented by experts, who built models with their specific knowledge. One of the interests of the approach is to address clear model request to the expert, in order to obtain the right model at the right moment for the architect. Consequently, the physical model is built based on an intermediate model, called model of intention. Liscouët-Hanke has proposed an approach to manage systems engineering and to transit to behavioural/physical in order to support design [3]. The link between two separated worlds is considered in her works. The formalization of system models to physics models transition motivates the method proposed in this paper.
De Tenorio works on conceptual design, via collaborative system engineering approach. He shows that the design of a complex system is multidisciplinary, and motivates interactions between systems analyses [4]. Following the conceptual phase, Basset & al. propose a tool to consider multidisciplinary design, and to manage physical discipline coupling [5]. The method proposed in this paper wants to focus more on transition from a world to another, and model building, than on tool or technical issues. The proposed method introduces a job, called "Simulation architect" whose main objective is to facilitate the collaboration between architects and domain experts. Simulation architect role is to insure that a dedicated simulation can be set up trough collaborate with experts, using their specific skills in various disciplines, modelling and simulation (M&S). He has to manage a global view of the architecture of the simulation which is one of the virtual views of the architecture of the product, with a behavioural M&S filter. Typically, he is in charge of selecting M&S strategy to support design and architect's questions when M&S seems to be the right path to answer ques-tion about mitigation in the design. His close link with project allows him to propose the most pertinent modelling strategy. In order to apply his strategy, he will build (or manage the creation of) different Models of intention, for a system, or for any interactions, to express what the architect has required in term of Physics (Phenomenon, equations, input/output), Information (Expected results, simulations, Interactions and Impacts) and Operations (Scenario, environment, constraints, missions…). In fact, a Model of intention does not represent a new way to specify a model when software is at stake or when functional model are in interaction: ports, compression processes, multiscale representation are already used. As far as physics is concerned, we have not yet identified any approach that mixes physical models and functional models to prepare integration. Our scope is there: environment of systems is physics (i.e. Thermal, vibration or electromagnetic fields) whilst systems are behaviour (i.e. Signal, black-boxes with I/O ports). The modularity, versus classical document-based model specification based on requirements, allows experts to deliver more relevant models. Indeed, the scenario knowledge, coupled with the systems interaction knowledge, and with informative complementary source, allows experts to propose more adapted models for the project.
I&I is the way selected for the method to augment knowledge and information directly in systems engineering models. This is a concept which considers that a system modifies its direct environment, and consequently the global design of a product.
• Interaction: Link between two subsystems with reciprocal action, effect or influence. If the architect modifies a subsystem, via a new technology or a new sizing, systems in interaction with it will suffer, or benefit, of this modification. • Impact: Directed from a subsystem to another. The concept of impact is set in order to allow modelling. For example, thermal behaviour of an electric motor will impact the behaviour of a battery. The relationship is physically easy to understand, but difficult to capture via a model, sizing and simulation.
Paredis & al. proposed an approach based on M&S and interactions [6]. Their approach allows creating a link between two subsystems models through a specific and multi-granularity interaction model. The method proposed in this paper wants to support the building of such interactions models, jointly with system model building, and based on trace and justification inside a global project.
The workflow proposed in Fig. 2 is sequential, and describes different actor's contribution. It starts with two inputs, Top Level Requirements (TLR: requirements from customer, safety, project …) and Functional Architecture (developed using methods not considered in this paper), and stops when the architect got an answer to his questions. Indeed, the method is set up to support the architect in his decisions, expressed through questions, with the support of the simulation architect and expert analysis, based on models. In the workflow, it is possible to highlight three major blocks, System, Interaction and M&S, which will be detailed in the next parts. Sequencing of this block is mandatory; no parallelism is possible due to the dependence of M&S phase on Interaction phase. Update of inputs during the process requires running it again from the point where the new information is considered. Three rules, one for each block, are defined to support the sub-steps. Description of these rules use is proposed under block description.
The method is based on decomposition named Requirements Functional Logical and Physical (RFLP) [7]. This decomposition is interesting because it keeps all the Model-Based System Engineering (MBSE) foundations. However, with the method, impact (I) is added to obtain FLP-RI decomposition for a system. In order to apply FLP-RI approach, all systems are defined with attributes, sorted through F, L or P. An attribute is an object defined with a template (Fig 3) which supports characterization of the system. Attribute supports M&S transition. This work is done for all involved systems, first by the architect, and updated by the simulation architect. In the method, FLP are customized differently from usual:
• Functional (F): All functional aspects; how the system runs and attributes that supports the system during its work. • Logical (L): Usually, L considers functions allocation on physical systems. Used in the method more as an operational view (mission, hybrid modes…). • Physical (P): Real objects, hardware and geometrical aspect, are considered.
At this point, the system has attributes ranked into FLP. To progress to FLP-RI, the next step is to manage R and I, which are defining new types for corresponding attributes. These types are associated to attributes by the architect, with the support of specific rules.
• Requirements (R): Requirements are cascaded as "top-down" approach, from topsystem to subsystems. Requirements can also derive from a specific technology. For example, a battery has specific thermal requirements, not cascaded from TLR.
The objective is to associate attributes of each system to an equality or inequality requirement. • Impact (I): Impacts is a new type introduced to consider how a system will influence another one. This type is associated to an attribute considering as "impacting". This selection is done by the simulation architect, supervised by the architect, in consideration of project and questions. This attribute selection is done from subsystem to system ("Bottom-up").
• Rules (IRrules): These rules authorize, or not, the assignment of R or I type to an attribute. For the moment, these rules are adapted for each project. The work is in progress to determine if rules are strongly dependent to a problem, and if generic rules could exist.
When all systems have been described with attributes, sorted in different FLP, and specified as R-I, it is possible to evolve to interactions management. The objective is to be able to generate connexions between two FLP-RI system descriptions. Due to the large number of potential interactions, generation shall be semi-automatic or automatic.
The idea is to link impacts type attribute from a subsystem to requirements type attribute of another subsystem. Port-based approach, completed with rules named INTrules to connect ports, automatize the process. Indeed, use of attribute as object is an advantage for this phase. To create rules, an approach by interaction matrix, Design Structure Matrix (DSM) or N² diagram applied to attributes is used [1] [8]. As for IRrules proposed in the last paragraph, INTrules are for the moment specific to a project, and matrixes fulfilled manually. Multiple solutions for generic rules are under investigation, and are not presented in this paper.
At the end of this sub-process, it is possible for architects to visualize specifically the impacts from one subsystem to another. This information will support the next steps: M&S request and building.
Modelling strategy is implicitly linked with simulation and scenario. The strategy is defined by the simulation architect to support the architect's questions or design process. This important part of the method drives the next phase, which is based on I&I information, to request model via model of intention. For the architect, questions will be used to progress in the design Strategy is defined based on results expected, via a modelling translation of the architect's question. Some several indicators shall be validated:
• Inputs: Data available, previous results, scenario.
To demonstrate the methodology, we investigate on the evolution of a Vertical Take-Off and Landing (VTOL) UAV from a Thermal Propulsion (TPUAV) to a Hybrid Propulsion (HPUAV). Hybrid term is defined as: "Vehicle in which propulsion energy is available from two or more kinds or types of energy stores, sources or converters, and at least one of them can deliver electrical energy."[9] [10]. The project's objective is to check if it is possible to obtain better performances (e.g. range, payload, operational cost…) with HPUAV than with TPUAV, satisfying the same requirements. As a first input, the architect has identified a viable functional architecture, which allows keeping TPUAV subsystems, and just added two supplementary systems (Electric Motor and Batteries, including power electronics). This architecture is inspired by automotive industry, and usually presented as "hybrid parallel" (Fig 5) [11]. In order to perform the entire method, a three phase's mission is fixed (Take-off, Loitering and Landing). All this work builds the "Scenario" (Fig. 2).
We take the hypothesis that the requirements cascading from UAV to propulsion system is done. The first step of the method is dedicated to subsystems, and highlighting of attributes that characterise them. Then, identified attributes are sorted with FLP decomposition. This identification and decomposition applied to the electric motor is presented in Figure 6. Same work is done for all systems. The R-I phase is done as presented in previously. With the attributes selected, each of it is treated with R-I type. Requirements identification and management is directed by cascading, or hypothesis (example, minimal efficiency of the motor is fixed at 95%). Impacts are selected on engineer experience, and degree of freedom of scenario. This work corresponds to "System block" in general process (Fig. 2).
Interaction phase objective is to connect all systems in a network. With HPUAV, 28 interactions are possible with 8 systems at 2 levels. The huge number of interactions justifies the automation of interaction object building. For the project, specific IN-Trules has been created around disciplines. Each attribute has an associated discipline and so, Impacts type attributes can be combined to Requirements with the same discipline. This tag association allows creating a simplified network, which represents an information source that can be filtered by the architect. As a simple example, it is possible to visualize that the size of a system will impact possible size of another one.
Note that with such tag association, some trans-disciplinary impacts cannot be identified directly. For example, the impact of subsystem's size on system thermal behaviour is not detected. However, thermal dissipation of subsystem is linked to its size and shape, so links are done inside each subsystem model. Finally, all subsystems are connected. The architect can express his questions. This work corresponds to "Interaction block" in general process (fig. 2).
The question is proposed by the architect, based on project's objectives: Is it possible to overpass requirements imposed to TPUAV with HPUAV, in term of endurance on loitering phase and payload?
The simulation architect proposes a first modelling strategy considering mass (for payload) and duration (for endurance). He proposes to develop a power exchange based simulator, which runs on the sizing mission. An optimization process must then be performed with this simulator. Due to power exchange modelling, 0D causal dynamic modelling is proposed. Modelling strategy used in this part is presented in upper left of Fig 4. This strategy starts with propulsion system, which delivers Mission and Mass information to Propeller. Propeller requests power to perform mission, and is cascaded to other subsystems and then reach the two different energy sources (battery and tank). Power requested to source is integrated versus time in order to determine energy. Energy contained in sources is directly determined with the mass of energy source subsystem (internal energy density). Simulator determines if mission is a success, and delivers results for future questions (i.e. design phases). To determine success of a mission, numerous constraints (based on R) are applied to subsystems (for example, no more energy in battery). Each set of parameters for a simulation represents an architecture sizing: if mission is successful, sizing is correct. In order to compare efficiently architectures, block-based modelling is proposed. It allows reusing subsystems models and easily builds architectures. Custom control of hybridation logic is applied.
With scenario and modelling strategy, I&I phase is used to select pertinent attributes. Each selected attribute receives a specific M&S type, according to M&Srules (parame-ter, input…). Subsystems models have a description, but no behavioural equation: Model of intention is built and can be sent to the experts. As this example is quite simple, models received are integrated in a Modelica tool, Openmodelica, supported by a custom library [12]. Optimization is based on maximization of two objectives (payload and loitering duration), and 8 optimizations variables. An evolutionary algorithm is selected to perform analysis. The double use of the simulator helps to answer the architect's questions, and brings information for future steps (Fig 9).
The proposed method follows the idea that increasing the knowledge on a system under design, with the support of physical world, will aid the architects in their decisions. Around a three-phase workflow, the method manages the transition from pure system approach to physical modelling and simulation, with enhancing of collaboration and expertise. Each method's phase brings traceable, storable, and reusable information.
The dynamicity and flexibility of the approach allow managing different phases of a system design project. For the moment, the method does not address the ranking of interactions, used to highlight where it is important to remain attentive and to deploy M&S studies. This feature will be added, by the use of parametric weights on impacts and requirements attributes. Another point concerns multidisciplinary aspects. Due to the flexibility, it is possible to add new discipline's attributes. Work progresses to consider, in the HPUAV use-case, thermal, electromagnetism and geometry (3D).