A Concurrent Design activity is a phased process to perform a feasibility or conceptual study using an iterative approach. Its clearly distinctive phases are:
The high level characteristics of Concurrent Design (CD) and its phases are presented here.
In the negotiation phase the organization performing the Concurrent Design activity needs to reach an agreement with the customer on how this activity will be performed. In this phase the duration, the goals for the design, requirements and limitations, identification of the needed domains and team members, together with several organizational matters need to be discussed, resulting in an agreement to perform the CD activity.
In order to perform a design it is necessary to start with a set of requirements. This set of initial requirements (or values) is identified together with the customer; the System Engineer (SE) and the Team Leader (TL). This should be done prior to the design sessions, in other words during the preparation phase, in which the CD activity is set up. Involving the whole team at this point is not necessary and will be counterproductive. Missing or erroneous requirements will be identified during the design sessions and added to or updated accordingly.
The design sessions are used to actually perform the design. Preferably the team is collocated; this is one of the strong points of Concurrent Design. The overall planning of a CD activity is prepared by the TL, SE and Customer to decide on the amount of sessions that will be required to perform the activity. Usually the amount of sessions is from 6 to 8, spread over several weeks. Duration of a session is typically 4 hours. This may be adjusted to the needs of a specific organization however.
In essence the Concurrent Design method makes use of model based parametric design. All the design information is available to the whole team and changes are immediately visible. In order to perform an integrated design it is necessary to exchange data between the team members or disciplines. This functionality is provided by the Concurrent Design Platform (CDP™) giving overviews of inputs, outputs and request of parameters. The exchanged information, in the form of parameters, is used to perform assessments in each discipline. Exchanging information is done through a question-and-answer mechanism. In the Concurrent Design method these questions are called requests and they are answered by parameters and actual values.
Frequently it is necessary for the team members to take a bit more time to perform a calculation or find the relevant information and prepare for next sessions. Nevertheless, the design is still a team effort and can continue without the team being collocated or working concurrently. This is performed in offline work. All the relevant data is still available through the CDP™, since it consists of a central database accessible via the internet. The workspace (in the form of spread sheets in the CDP™ workbooks) can be downloaded and uploaded from and to the CDP™ back-end and therefore can be used to perform the necessary calculations or assessments. In the CDP™ Client the sessions, with design iterations and options, with actions, minutes of meeting and much more can be managed and executed. Furthermore an overview of the team members and their contact details can be consulted to ease the communication.
The wrap-up of the Concurrent Design is a clear phase in the method where the results are gathered and reported on. These need to be extracted from the different discipline workspaces. In a CD activity there is usually an agreement at the beginning what the final result to be delivered will be. This can be for example a presentation or a report.
One of the most basic features of a Concurrent Design activity is that it is bounded in time: after a predefined number of sessions in a certain period the activity will stop. Due to this strict time limitation the team is forced to limit its scope and to limit itself in the level of detail under consideration. In the preparation phase the System Engineer, Team Leader and the Customer, possibly assisted by several key domain engineers identify several promising directions for a solution, usually two or three. These directions are established through alternatives of preliminary system breakdowns in so called options.
The results are evaluated at certain points in time, usually after a round-trip with all the domains or at the end of a session, by capturing the values of the parameters in a snapshot. One loop around all domains is usually referred to as an iteration. Within the scope of the CDP™ and other Concurrent Design tools an iteration is however basically a snapshot of the complete model that can be created on any required time. By comparing iterations an assessment can be made of the improvements by the team in reaching an adequate solution. Depending on the time, several of these iterations may be performed to create design alternatives, taking into account the different options.
Starting from the preparation, the phases of a CD Activity can be indicated in the status of the specific engineering model that is being developed in the CDP™ as the parametric design model. After the CD Activity has ended, the status of the resulting can be updated to indicate that it has been completed. The possible status indications on an engineering model are1:
Source ECSS-E-TM-10-25-Annex-A, v2.4.1, ToC Reference Manual, section 3.14 ↩
Last modified 11 months ago.