The CDP™4 consists of three components which are necessary to create an environment which makes it possible for a team of specialised engineers to come to an integrated design. These four different components or pilars are the CDP™ back-end, the CDP™ client and the CDP™ workbooks. CDP™ add-ons can be added to the design environment. The CDP™ client, CDP™ workbooks, CDP™ add-ons or other external tools communicate to the CDP™ back-end through the CDP™ web services.
The CDP™4 is based on and compliant with the draft open standard defined in the ECSS-E-TM-10-25 System Engineering - Engineering Design Model Data Exchange (CDF) Technical Memorandum. This draft open standard has been developed and continues to be developed on the initiative of the European Space Agency (ESA) by the Open Concurrent Design Tool (OCDT) Community:
This Technical Memorandum facilitates and promotes common data definitions and exchange among partner Agencies, European space industry and institutes, which are interested to collaborate on concurrent design, sharing analysis and design outputs and related reviews. This comprises a system decomposition up to equipment level and related standard lists of parameters and disciplines. Further it provides the starting point of the space system life cycle defining the parameter sets required to cover all project phases, although the present Technical Memorandum only addresses Phases 0 and A.1
This draft open standard is intended to provide the basis for:
- Creating interoperable Concurrent Design (CD) centres across the European space community.
- Allowing semantically consistent data exchange between CD centres.
- Enabling and supporting joint real-time collaborative design activities involving multiple CD centres.1
The underlying CDP™4 Data Model is an implementation of the Concurrent Design concepts that are modelled and described in ECSS-E-TM-10-25, reflecting those concepts that are agreed upon and accepted by the OCDT Community. In this way, the CDP™4 complies with and supports the points that are given above, contributing to interoperable Concurrent Design centres.
The CDP™ allows to connect to other data sources that are compliant with this draft open standard, see the description of connecting to data sources.
The CDP™ back-end is a database in which all relevant information is stored. The database can be accessed through a network connection, either from an internal network or from the Internet. Both secure and insecure communication with this database is possible (http or https). The CDP™ Client, CDP™ Workbooks or other external tools communicate to the CDP™ back-end through CDP™ Web Services. In the CDP™4, this type of connection is represented to the user as connecting to a data source.
The other components of the CDP™ rely on the back-end for their functionality, making the back-end the core of the CDP™.
Versions of the CDP™4 are using Web Services in the CDP™, giving more flexibility and better control of access rights, allowed actions and accessibility. An improved implementation of data base communication allows for a better setup of refresh mechanisms (tracing of changed items to be communicated). The implementation of the Web Services provides an intermediate communication layer between the database and tools that need to retrieve this data. These tools can be either the CDP™ client or CDP™ workbooks, but using the Web Services it will also be possible for other tools to have access to the database information. The user connects to the Web Services at login when connecting to a data source. Apart from the CDP™ Web Services, other ECSS-E-TM-10-25 compliant data sources, as well as JSON File Based data sources can be opened, see the description of data sources.
For the CDP™ Web Services, separate documentation on the API is available. This documentation can be generated from the Web Services. Contact your CDP™ Administrator for details on this.
The CDP™ Client is used by the different domain engineers. With this tool the domain engineer can login to one or more engineering models, representing the assigned domains. The client tool gives an overview of the element definitions and element usages, the parameters modelling these design items and their values accross different options and iterations. Both the owned parameters and subscriptions can be viewed from the CDP™ Client throught the Element Definitions and Product Tree Browsers. When the engineer is logged in it is possible to download and manage the CDP™ workbooks in which he needs to model his domain.
Based on the CDP™ name and password at login, only those combinations of iterations and domains for engineering models are presented to the user that he has been allowed to work with for a connected data source. Based on the [role][Purp_Roles] a user has he can perform certain operations with the CDP™ client in a specific activity.
The technical author is a special kind of domain engineer. There is no workbook for the technical author domain. The technical author is in charge of maintaining the minutes of meeting based on the comments and remarks of the team made during design sessions and updating the actions list. The minutes of meeting are stored in the CDP™ back-end, they can be edited and updated online. It is possible to retrieve the minutes of meeting from the CDP™ back-end in document form. The activity portal also presents the users with the session planning, the minutes of meeting and the actions list.
The presentation to the user in the CDP™ Client is done by a variety of browsers. For how to manage these, see the description of the application layout.
The CDP™ workbooks are the environment in which the actual mathematical modeling of a domain or subsystem is performed. The domain engineer has complete control over the structure of a workbook, except for the sheets that are generated or controlled by the CDP™. These are e.g. the Parameters sheet, Option sheets and generated Categorized Parameters sheets.
All the functionality of Microsoft Excel is present in the CDP™ workbooks, giving the domain engineers all the freedom they require to design their domain or subsystem. The CDP™ workbooks have added functionality which makes it possible to incorporate them in the CDP™.
Input and output parameters are requested and created through these workbooks.
The CDP™ workbooks are stored in the CDP™ back-end. When a domain engineer needs to work on his workbook he has to download a copy from the back-end using the CDP™ Client. When the workbook has been downloaded to a local system the domain engineer is free to work on it. When the work is finished the workbook needs to be uploaded to the back-end again where it is stored for future use. Old versions of the workbooks are maintained on the server and can be retrieved as well. The workbook that is stored in the back-end is considered to be the most up-to-date version of that workbook. In order to make sure that only one engineer can upload a new version of a workbook to the server that engineer needs to check-out the workbook first. Other users will not be able to upload that workbook to the server while it is checked-out by another user.
The parameters and option sheets of a workbook are necessary for the CDP™ workbooks to work properly. These sheets are the actual interfaces with the rest of the system. They allow parameters and there values to flow into a workbook and out of a workbook. These sheets are automaticaly rebuilt by the CDP™ every time a user requires this. Predetermined columns of the parameter sheet should be edited by the users to reflect the changes in their domain. When these columns are edited these changes still need to be comunicated to the CDP™ back-end, otherwise the next rebuild will overwrite these changes. It must be clear that editing the other columns of the parameter and option sheets is of no use, the changes are not communicated to the CDP™ back-end and will therefore be lost with the next rebuild.
The parameters and subscriptions in the workbook correspond to the current iteration. It is important to note that whenever a previous iteration is selected and activated some of the calculations in the sheets will become obsolete or useless because they relied on input that did not exist yet in that iteration.
The user can add any number of calculation sheets to interact with the CDP™ Datamodel as represented on the parameter and option sheets.
For a more detailed description of the actions from within the CDP™ client see the sections under managing CDP™ workbooks. More functionalities are described in the sections under the CDP™ workbooks itself.
Add-on functionalities are and can be developed that are either fully integrated into the CDP™, e.g. a Document Management System and the Requirements Manager, strongly integrated into the functionalities of the CDP™ client or workbooks but with a separate installer, or as separate self-standing tools that communicate to the CDP™ Web Services. An example of this is a web application making use of the Web API that has been developed by RHEA within the CDP™ tool suite.
The CDP™ works accross the internet, but a team of co-located engineers is highly preferable. An activity team normally meets on specific dates to work concurrently on the design in so-called design sessions. At these design sessions the engineers have the possibility to present their details to the team and decisions are made together with the team. This speeds up the design process and makes it very efficient.
The use of a switch control mechanism prevents parameter values to travel through the workbooks of the domain engineers without them knowing or having any control over them. This switch control mechanism is controlled from the CDP™ client and from the workbooks. This way the complete team has control over the parameter value flow.
Last modified 4 years ago.