Difference between revisions of "System Architecture Design"
From EUDP
(→Example) |
(→What) |
||
| Line 1: | Line 1: | ||
== What == | == What == | ||
| − | Documents and figures describing the static layout of the functional blocks of the system-to-be. | + | Documents and figures describing the '''static layout of the functional blocks''' of the system-to-be. |
Block or component diagrams illustrating the functional decomposition into HW and SW blocks, respectively. | Block or component diagrams illustrating the functional decomposition into HW and SW blocks, respectively. | ||
Revision as of 10:19, 14 November 2016
What
Documents and figures describing the static layout of the functional blocks of the system-to-be.
Block or component diagrams illustrating the functional decomposition into HW and SW blocks, respectively.
How
General architecture design consists of several steps which often require several iterations until the optimal architecture has been obtained.
The system architecture and the technical platform highly depend on one another, and also depend on the partition of functionality into HW and SW blocks. Therefore, one should expect to iterate between the tasks in the general architecture design.
Ingredients
- System constraints, see [Design Constraint Analysis]
- Availible requirements, particularly in terms of:
- Performance requirements
- Interface compatability (i.e. must be able to connect on Ethernet, communicate on CAN, have an SD card, run Android OS, etc.)
- Drafts of blockdiagrams for the system (perhaps split into blockdiagrams for HW and component or UML drafts for SW)
Example
An example of system design activities
- Identify the system constraints
- Technical constraints are evaluated, e.g. in terms of:
- Performance of the given technical platform
- Preselected BSPs/operating systems
- Lifetime considerations
- Target costs
- Compatibility issues (must be same CPU family as usual, same BSP as we use already, must be able to run older applications built for this architecture, etc.)
- Technical constraints are evaluated, e.g. in terms of:
- Assess the initial block diagram and the proposed technical solution
- Attempt to map the system-to-be’s functionality onto whatever architecture is provided by the technical solution, e.g.:
- See if the required communication protocols match the available HW
- Estimate the system-to-be’s memory footprint and evaluate the available memory and storage in the suggested technical platform (file systems, graphical libraries, large databases, webservers, etc. often have quite high demands in terms of memory)
- Predict the bottlenecks, if any, in terms of performance when running the system-to-be on the selected technical platform
- Attempt to map the system-to-be’s functionality onto whatever architecture is provided by the technical solution, e.g.:
- Craft a detailed block or component Blockdiagram with:
- HW blocks sketched based on responsibility and function
- SW blocks based on functionality and responsibility. The 7 layer [OSI model] is good as a template for dividing functionality
- Based on the results above, evaluate if:
- A slight Design Partitioning repartitioning of functionality between HW and SW will improve performance
- The available memory is capable of accommodating system-to-be needs (multiplying your memory footprint estimations with 2-3 is a good rule of thumb)
- The required HW support and SW BSPs are available. If not, consult the system constraints, and evaluate if a better suited technical platform, BSP, development tool is available and within budget reach.
- The design is divided into enough functional blocks (HW and SW). Are the responsibilities within each block small enough?
