The CDP™ supports Concurrent Design & Engineering (CD&E) processes, allowing multidisciplinary teams to work compliant with the CD&E methodology. This involves customer participation and access to the design information within the CDP™. It provides a collaborative working environment for collocated teams through an intranet connection or geographically distributed teams through an internet connection. The CDP™ supports a clear division of tasks and responsibilities according to role assignment and additional settings to determine access rights to the integrated design model in the CDP™.
Concurrent Design & Engineering focuses on a parametric design, which is done mainly in the CDP™ Elements Definitions or Product Tree as main views in the CDP™. The CDP™ captures interactions between disciplines within a CD Activity, e.g. by ownership of parameters, or setting subscriptions to use these as inputs.
Options are used to capture clearly different solution directions under investigation and iterations are created as snapshots of the design data at a desired point. The concepts of representation of domains and ownership within options and iterations provide an audit trail in the Concurrent Design & Engineering process.
Within an Engineering Model, the CDP™ product tree describes a specific solution direction with parameters within modelling objects, as defined by the element definitions and element usages in the Element Definitions view or in the Product Tree directly. The element definitions (and related element usages) are the items that need to be modelled, where the parameters provide their characteristics. This can be modelled according to an industry- or project-specific breakdown structure, e.g. defining and applying categories that are following a Decomposition Rule. For a high level description of element definitions and element usages, see description on how to develop Engineering Models.
Various parametric descriptions can be used within the CDP™, not only physical quantities, such as e.g. a mass or power, but for example also boolean, composites, date, enumeration or free texts. As a basis, a large set of parameters, with associated measurement units and scales, are already defined as parameter types and available as a starting point in ECSS-E-TM-10-25 Annex B (informative) Space Engineering Reference Data Library1. This set can be extended to define any required new parameter, scale or unit according to any one of the supported types.
More dynamical behaviour can be modelled by defining finite state lists and setting a state dependency for parameters in the engineering model. Other concepts from ECSS-E-TM-10-25 that can be used to make distinctions in the modelling are setting an option dependency (i.e. a parameter gets a separate value set for every option that is defined in the engineering model) and using overrides (i.e. a parameter in a specific element usage gets a separate value set, allowing to provide a value different from the values given in the element definition).
All these concepts may be used to describe possible solutions or solution directions for the problem under investigation, providing information in a parametric way.
Parametric information should be in an engineering model, because other domains of expertise need this information to be able to work on their part of the design. To enable this, there is a subscription mechanism in the CDP™ to allow participants in a CD study to use the parameters. In an ideal case only parameters should be present in an engineering model that are indeed used by other domains. This subscription mechanism not only allows these domain experts to perform their work by facilitating a data exchange mechanism. It also serves as a more powerful mechanism to show dependencies within the engineering model, and making these relationships with the associated information flow more explicit.
With the implementation of an underlying data exchange mechanism, the parameters and subscriptions allows the domains of expertise to share and use information. Taking a subscription on parameters of other domains of expertise, a domain expert can view this information or use it in calculations, where the results of these calculations from this domain may often flow back as values for parameters to be shared with yet other domains of expertise. The main modelling space to perform these calculations is provided by the CDP™ Workbooks, implemented in Microsoft Excel.
The basic data exchange mechanism, which includes a publication mechanism as well, is described in more detail in the topic on the CD basic roundtrip.
Next to the main information flow using the CDP™ Client and CDP™ Workbooks, various functionalities or additional data exchange mechanisms that are implemented in the CDP™ allow to develop and support additional information flows.
A lot of the modelling can in principle be done by the team directly in the CDP™ Product Tree or Element Definitions view, but it’s an important aspect of Concurrent Design & Engineering to create a standardized approach, including defining generic building blocks that can easily be reused. The CDP™ therefore has several functionalities and mechanisms to facilitate re-use of information, allow to setup templates for projects and supporting the build-up of corporate knowledge in general.
A first example of this is the possibility to copy modelling items such as element definitions and element usages between multiple engineering models, see the description of developing engineering models. This can typically be used in a more informal way, or on ad-hoc basis.
A second is the use of catalogues as a specific engineering model kind. A catalogue is intended to collect element definitions as building blocks that can be used in other engineering models. The functionality can be used to setup a collection of generic modelling items, e.g. for personal use, within a specific discipline, or even within a department. A catalogue may be managed with different access rights to either allow updating the content of the catalogue itself, or only provide access to be able to use building blocks from the catalogue in other engineering models.
A further example is the use of a template model as model kind. This will allow to have a wider prepared engineering model to serve as a starting point for a new engineering model.
All the examples given here may have element definitions that provide mainly the structure (i.e. a predefined set of parameters describing the element definition) or even already have actual values (e.g. providing a catalogue including values for specific COTS equipment that can be used as a reference database).
The CDP™ architecture comes with a public (REST) API in the form of the CDP™ Web Services. The implementation of the Web Services provides an intermediate communication layer between the database and tools that need to retrieve this data. Using the Web Services it will be possible for other tools to have access to the database information.
The nature of a public API will allow developers to develop client applications interacting with the CDP™ Web Services. In principle, this could be for any specific purpose e.g. for specific tasks in user management (importing users), performing bulk operations, for automated testing purposes, or to create specific dashboards A wide variety of use cases can be imagined to use these CDP™ Web Services. A first example of an application that uses the CDP™ Web Services is the Web API available as part of the RHEA CDP™ tool suite. Another example is the integration of Domain Specific Tools using this API, see the description below.
Please contact RHEA for further information on this topic.
A substantial part of the analysis done by domain engineers is in the CDP™ Workbooks associated to their domain. Many forms of analysis that need to be performed within a CD study require Domain Specific Tools (DST) however. Examples of these kind ot tasks are performing calculations, creating 2D or 3D models, simulations, supported by tools such as STK, CATIA, Matlab, Simulink, EcoSim Pro, but also performing more architectural design work and analysis using e.g. MagicDraw (No Magic), System Architect (IBM) and Focal Point (IBM). These tools need to use values from subscribed parameters from the CDP™ and provide values for their owned parameters of the CDP™.
For a DST to be integrated it needs to have either an API for automated communication, or a mechanism to export and import data.
Two approaches can be taken:
The general principle is schematically illustrated in the figures below.
The integration of Domain Specific Tools can always be performed as a customization activity for customers. Please contact RHEA for further information on this topic.
See ESA OCDT Community Portal, https://ocdt.esa.int/projects/ocdt/wiki/ECSS-E-TM-10-25-Annex-B ↩
Last modified 4 years ago.