The Concept Design Report is used to validate your system's design feasibility and ensure that the physical architecture aligns with the functional requirements you have developed. It's not just a document—it’s your blueprint for moving forward with system development.
The CDR is an interim artifact during the execution of the Concept Definition life cycle phase (Kossiakoff SE P&P Chapter 7).
Begin by focusing on the top-level functions identified in your Functional Analysis Report. Allocate these functions to specific subsystems or components. For example, if a function is to "Process User Input," determine which subsystem (like a user interface module) is responsible for this function.
Ensure that the allocation of functions to subsystems is consistent with the functional domain analysis. Avoid arbitrary assignments. Each component in your physical architecture should be directly traceable to a specific function or functions.
Maintain a clear hierarchy in your system design. Allocate each function to one and only one component or subsystem. Avoid "gold plating," where a function is unnecessarily assigned to multiple components, as this can lead to redundancy and inefficiency.
Do not define specific internal elements too early in the design process. At this stage, your focus should be on what needs to be done, not how it will be implemented. For instance, instead of specifying "HP Envy" as a component, use a general "computer" instead. This allows the design teams leeway for choosing the proper computer.
Don’t overlook software components, from the software modules, or applications and the overarching operating system the apps need to run. Ensure that your design accounts for both hardware and software, particularly if software elements are distributed or centralized. For example, in a car, the software is distributed among the engine control unit (ECU), under-dash display, and the infotainment panel.
Pay careful attention to how components will interface with each other. The design should clearly define the inputs and outputs between subsystems, ensuring compatibility and integration.
Component (physical) interfaces should be labeled with the physical name: tube/hose, power cable, data cable, push/pull rod, mounting bracket, wi-fi, etc.
Lack of a clear hierarchy: Ensure there is a logical structure from system functions down to components.
Omitting software considerations: Even if your system is hardware-heavy, software plays a crucial role and should be included.
Over-detailed design at this stage: Focus on defining capabilities and leave room for design engineers to innovate within those parameters.
If you've gotten this far - and if this is your last class - and you are on track to finish this semester, don't forget to apply for graduation if you have not done so already.
Physical Context Diagram that includes all external entities (human and non-human actors which interact with the system). All inputs and outputs should be labeled with what the implementation of the external interface, if applicable. This is a change from the context diagram in your Functional Analysis Report!
A physical component hierarchy tree should be included that depicts the system, subsystems, and at least one level of components. Overachievers: include all levels of components.
A physical description of the system, including hardware and software elements. Each subsystem needs to be described in words (one or two paragraphs each). Include a picture if available.
A set of physical block diagrams is required. In SysML these are Internal Block Diagrams (IBDs). One top-level diagram will depict the subsystems and their interfaces. The interfaces on these diagrams should be depicted by lines (not arrows) and the implementation indicated (e.g., wires/cables, 802.11 wi-fi, comms link, mechanical, etc.) The diagrams and/or hierarchy should be two levels deep—and then each subsystem broken down one additional level, into components. [Thus, if you have 7 subsystems, then you will need 8 diagrams, one for the system as a whole, and then 7 diagrams, one for each subsystem.] Overachievers: critical components should be decomposed one or two additional levels to show detail.
Each subsystem and component needs to be designated as to whether it consists of hardware only, software only, or a combination. This can be done on the diagram using color, shape, or provided in the word description.
Physical N2 Diagrams with subsystems or components along the diagonal and what is passed from component to component within each cell.
include a data dictionary which identifies and describes each major data element within your system. Every data element found in your data flow diagrams should be included. This may be a table which includes:
ID
Title
Description
Subsystems or components used within
Internal physical interfaces are identified and described. Each physical interface should be identified as to what is transferred along that interface and how the interface is implemented physically (physical—keyboard/touch screen/keypad, electrical, communications—VPN/Ethernet/USB, etc.). Additionally, indicate what function or functional interaction is being implemented by the interface (In terms of material, energy, data, or signal). For example, a comms interface could be described as “Ethernet” instead of the generic “Comms.” This is typically a table with the following columns:
Interface ID
Title
Description
Source
Destination
What is being passed
Implementation
Function or functional interaction implemented
External physical interfaces are identified and described. Same as above.
A table or matrix mapping functions to physical elements. This traceability should be in two directions: components to functions (Backward traceability) and functions to components (Forward traceability). note: it's not necessary that the same tier in the functional domain maps across to the same deer in the physical domain. E.g., It's quite possible (and normal) to link tier 3 functions to tier 2 components, etc. Envision assigning a design team a list of functions for them to implement into their hardware solutions. This is how the traceability mapping should look.
A table matrix mapping functional interfaces to physical interfaces. In other words, list all of the physical interfaces and what functional elements flow across them.
Overachievers: Additional requirements, if any.
CDR Checklist Credit: Steve Biemer