CDP 4 User Manual

Develop Engineering Models



Various actions are required to manage an Engineering Model Setup and to assign team members to an Engineering Model. This section will describe at a high level the actions that are needed to setup and develop the actual design items in an engineering model.1

The details of managing the main modelling concepts within an engineering model are described in the topics of managing element defintions and element usages and managing parameters.

Modelling in the CDP4™

Required Modelling Actions

At a high level, the main actions that will have to be performed in the CDP4™ to develop an Engineering Model in the preparation phase are given here. This setup of the content of an engineering model is usually done by the System Engineer, System Engineer Assistant, or several key domains. These high level actions are:

These actions are usually performed to build the engineering model from a system level point of view, i.e. mainly defining the systems and elements (e.g. spacecraft, lander, rover,...) as Products that are needed in the design of the mission, and to define the subsystems in the design that will need to perform the required Functions.

Identification of Options as Solution Directions

An important aspect of the work of the System Engineer (supported by the System Engineer Assistant) during the preparation is to identify the possible solution directions that will be investigated during the CD Study. In Concurrent Design in general, and within the CDP4™ as tool implementation supporting this process, these different solution directions are represented by the concept of options. These options are managed through the Options browser.

Modelling Approaches

Thinking Ahead

During the preparation phase, the system engineer has to think ahead on how the engineering model has to be setup. For this the system engineer will have to discuss with the team leader to make sure that the modelling allows the investigation of multiple options within a desired process or study planning in the scope of the CD Study, and to assess the possible impact of modelling choices on the team members, the type and amount of work that these have to do, how these can use information from the design model to perform the calculations within their domain, and share the results with the rest of the team.

The differences between solution directions driving the design process for these options can be expressed in various ways. The design information that is applicable to a specific option, or more general how modelling differences at various levels are handled within an engineering model to represent different aspects of the design need to be understood and taken into account by the system engineering domain during the setup, to be able to take full advantage of the modelling capabilities that the CDP4&trade has to offer. Usually, this comes down to coming up with a way of modelling that brings together a structure and approach that is as generic as possible, while allowing to model and use specifics and exceptions. Several of these possible different ways are briefly described below.

Reuse Available Building Blocks

In the Concurrent Design approach several building blocks that will be used in the CD Study are defined in a generic way, that allow to reuse these in many CD Studies with the same or similar subjects, e.g. for:

As described in the higher level description of the engineering model setup, several mechanisms to reuse building blocks in an Engineering Model for a new CD Study are:

These mechanisms for reuse of building blocks mean that many of the parameters that are needed throughout a CD Study are already available within the structure provided by Element Definitions or even already Element Usages within an Engineering Model. Examples can be a generic catalogue containing an element definition for an equipment, which in a group for generic parameters contains information on:

Each of these groups contain various parameters that are used to characterise an equipment, such as the mass, the TRL, the shape, centre of gravity, etc.

Items from catalogues can be used in other engineering models by drag-and-drop. Element definitions can be copied between different engineering models as well by drag-and-drop. This will add this element definition as a new element definition to the target engineering model. Select the element definition, and then drag-and-drop the item on an empty space in the Element Definitions browser in the target Engineering Model, or on the Name header.

Please note that to be able to reuse parameters within element definitions these should be available as parameter types in the chain of RDLs of the target engineering model. Element definitions in a source model (completed study, template study, catalogue) that contain parameters (and by extension corresponding parameter subscriptions) for which a corresponding parameter type is not available in the RDL of the target engineering model cannot be copied. The user will get a notification that only a partial copy can be performed. In this notification, all items (parameters, parameter subscriptions, parameter groups) can be given with their ID, and an indication whether they can be copied or not together with the reason why if this is not possible; to do this, tick the Details check box. The simplest and most manageable way to achieve a full copy is to promote parameter types from a study specific RDL that have proven to be very useful within that engineering model to the generic RDL to make reuse more straightforward.


Working with Element Definitions and Element Usages

For the design of a space system, there is a generic breakdown that is used as given by ECSS-S-ST-00-01C (1 October 2012). This gives a generic structure of a space system that is the subject to be studied. For the design that is done within the scope of Concurrent Design, a space system can be broken down in subsystems that represent functions that need to be performed, and elements that represent the products that fulfil these functions. The elements can be broken down into equipment, subequipment, components or parts, and materials.

Differences between options that need to be expressed can be modelled or expressed by using different element definitions. This implies that at a fairly high level in the model the required characteristics of what the element definition represents will already be different from other element definitions. Different element definitions may be needed in different options due to large differences at a high level for the solution direction, e.g. a difference in high level breakdown given by option X which will use a lander and a rover to achieve the objectives for the mission, and option Y which will use an orbiter and an observation station. Within the CDP4™, for all these items separate element definitions will in any case need to be created in the engineering model. When creating element definitions, take into account the ECSS-E-TM-10-25 naming conventions. Alternatively, it is possible to include or exclude element usages from specific options.

The different mechanisms that can be used in the modelling in the CDP4™ are described in more (technical) detail in several separate topics.

For the actual creation and use of element definitions and element usages, see the description of managing element definitions and element usages. That topic includes an explanation about nested elements and option trees.

The parameters that the system engineering domain will add to the engineering model usually represent:

The system engineer will usually also review the setup for generic building blocks, mostly for e.g. elements, subsystems or a generic setup for equipment) that can be used by the domain experts. There will also be sets that are managed by domain experts themselves however; for these, it may be very well possible that these will be added to an engineering model during the design sessions phase, coming from catalogues that are managed by the domain experts themselves.

For details on how to add and use parameters in the engineering model, see the description of managing parameters. That topic includes an explanation about option dependency, state dependency, ownership, subscriptions and overrides.

Related Topics

  1. Parts of the description given here are adaptations from information written by RHEA and made available earlier on the OCDT Wiki. 

Last modified 4 years ago.

^ Top