Difference between revisions of "System Architecture Design"
From EUDP
(→How) |
|||
| (14 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
== What == | == What == | ||
| − | + | [[File:Architecture-of-the-linux-kernel-2-728.jpg||200px]] | |
| − | + | '''Fundamental architecture of the Linux Kernel''' | |
| + | |||
| + | Source:''http://image.slidesharecdn.com/architectureofthelinuxkernel-090812191753-phpapp01/95/architecture-of-the-linux-kernel-2-728.jpg?cb=1250104715'' | ||
| + | |||
| + | [[File:Linux kernel map.png|300px]] | ||
| + | |||
| + | '''Map of the Linux kernel''' | ||
| + | |||
| + | Source: ''By Conan at English Wikipedia, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=6092674'' | ||
| + | |||
| + | Documents and figures describing the '''static layout of the functional blocks''' of the system-to-be. | ||
| + | |||
| + | At the end it will be possible to decompose the functional blocks into block or component diagrams illustrating the functional decomposition into HW and SW blocks, respectively. | ||
== How == | == How == | ||
| − | General | + | General architecture design consists of several steps which often require several iterations until the optimal architecture has been obtained. |
| − | The system | + | 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''' | '''Ingredients''' | ||
| − | * System constraints, see [[ | + | * System constraints, see [[Design Constraints Analysis]] |
| − | * Availible requirements, in | + | * Availible requirements, particularly in terms of: |
| − | ** | + | ** Performance requirements |
| − | ** Interface compatability (i.e. must be able to connect on | + | ** Interface compatability (i.e. must be able to connect on Ethernet, communicate on CAN, have an SD card, run Android OS, etc.) |
| − | * Drafts of | + | * Drafts of blockdiagrams for the system (perhaps split into blockdiagrams for HW and component or UML drafts for SW) |
==Example== | ==Example== | ||
| − | ''An example of | + | ''An example of system design activities'' |
*Identify the system constraints | *Identify the system constraints | ||
| − | ** Technical constraints are evaluated, e.g.: | + | ** Technical constraints are evaluated, e.g. in terms of: |
| − | *** | + | *** Performance of the given technical platform |
| − | *** | + | *** Preselected BSPs/operating systems |
*** Lifetime considerations | *** Lifetime considerations | ||
*** Target costs | *** 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.) |
| − | * | + | *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 |
| − | *Craft a detailed | + | *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 [[http://en.wikipedia.org/wiki/OSI_model OSI model]] is good as a template for dividing functionality | ** SW blocks based on functionality and responsibility. The 7 layer [[http://en.wikipedia.org/wiki/OSI_model OSI model]] is good as a template for dividing functionality | ||
| − | *Based on the results above evaluate | + | *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. |
| − | ** is | + | ** The design is divided into enough functional blocks (HW and SW). Are the responsibilities within each block small enough? |
Latest revision as of 16:51, 20 September 2020
What
Fundamental architecture of the Linux Kernel
Map of the Linux kernel
Source: By Conan at English Wikipedia, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=6092674
Documents and figures describing the static layout of the functional blocks of the system-to-be.
At the end it will be possible to decompose the functional blocks into 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 Constraints 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?
