Difference between revisions of "System Architecture Design"

From EUDP
Jump to: navigation, search
(→‎How)
(→‎How)
 
(25 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
== What ==
 
== What ==
  
−
Documents and figures describing the static layout of the functional blocks, of the system to be.
+
[[File:Architecture-of-the-linux-kernel-2-728.jpg||200px]]
  
−
Block or component diagrams, that shows the functional decomposition into HW and SW blocks respectively
+
'''Fundamental architecture of the Linux Kernel'''
  
−
== How ==
+
Source:''http://image.slidesharecdn.com/architectureofthelinuxkernel-090812191753-phpapp01/95/architecture-of-the-linux-kernel-2-728.jpg?cb=1250104715''
−
General architechture design consists of several steps, that often requires several iterations, untill the optimal architechtre is crafted.
+
  
−
The system architechture and the technical platform, are highly dependant on each other, and again depends on the partition of functionality into HW and SW blocks.
+
[[File:Linux kernel map.png|300px]]
−
Therefore one should expect to iterate between the task in General Architechture design
+
  
−
'''Ingredients'''
+
'''Map of the Linux kernel'''
  
−
* System constraints, see [[http://www.eudp.dk/index.php/Design_Constraints_Analysis Design Constraint Analysis]]
+
Source: ''By Conan at English Wikipedia, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=6092674''
−
* Availible requirements, in particular concerning
+
−
** performance requirements
+
−
** Interface compatability (i.e. must be able to connect on ethernet, communicate on CAN, have and SD card, run Android OS, etc...)
+
  
−
'''Process - An example'''  
+
Documents and figures describing the '''static layout of the functional blocks''' of the system-to-be.
−
*Identify the system constraints
+
−
** Technical constraints are evaluated, e.g.:
+
−
*** performance of the given technical platform
+
−
*** are there preselected BSP’s / 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 build for this architechture etc…)
+
−
*Asses the initial blockdiagram and proposed technical solution
+
−
** attempt to map the system-to-be’s functionality onto whatever architechture the technical solution suggests e.g
+
−
*** does the required communication protocols match the available HW
+
−
*** estimate the system to be’s memory footprint, and evaluate the vailible meory and storage in the suggested technical platform (i.e. filesystems, graphical libraries, large databases, webservers etc often have quite high demands in terms of memory)
+
−
*** attempt to predict any bottlenecks, in terms of performance, when running the the system to be on the selected technical platform.
+
−
*Craft a detailed Block and Component [[http://www.eudp.dk/index.php/Blockdiagram diagram]] with:
+
−
** hardware blocks sketched, based on what responsibility and function they are assigned
+
−
** sw blocks based on functionality and responsibility. The 7 layer OSI model is good as a template for dividing functionality - link
+
  
−
*Based on the results above evaluate
+
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.
−
** if a slight repartitioning of functionality between HW and SW will improve performance
+
−
** if the available memory is capable of accommodating system-to-be-needs (multiply your memory footprint estimations with 2-3, is a good rule of thumb…)
+
−
** do I have the required HW support and available SW BSP’s, if not consult your system constraints, and evaluate if a better suited technical platform, BSP, development tool is available, and within budget reach.
+
−
** do I have my design slip into enough functional blocks (HW & SW), and are the responsibilities within each block small enough
+
  
 +
== 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)
−
 
+
−
 
+
−
===Partitioning===
+
−
 
+
−
There is several ways to partition the general blocks from the architectural block diagram into software and hardware parts. In EUDP we recommend to follow the instructions given at [[Design Partitioning]].
+
−
 
+
−
Having defined the most effective partitioning prepare the necessary class diagrams to describe the software partition and corresponding diagrams for the hardware.
+
−
 
+
−
== Why ==
+
−
 
+
−
In order to find the most effective partitioning that at the same time respects the constraints and gives the best value for the customer it is essential to define the constraints for the project. Without proper definition of the constraints the design space is wide, but may not give the customer the best value.
+
  
 
==Example==
 
==Example==
  
−
    Issue        Critical      Very Important    Important  Less Important  Notes
+
''An example of system design activities''
  
−
Performance                          X                                          1
+
*Identify the system constraints
−
Usage                X                                                          2
+
** Technical constraints are evaluated, e.g. in terms of:
−
Reliability          X                                                          3
+
*** Performance of the given technical platform
−
Easy serviceable                                      X                        4
+
*** Preselected BSPs/operating systems
−
Remote maintenance                    X                                          5
+
*** Lifetime considerations
−
Cost effective                                        X                        6
+
*** 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.:
−
Notes:
+
*** 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)
−
1.    The performance is very important.
+
*** Predict the bottlenecks, if any, in terms of performance when running the system-to-be on the selected technical platform
−
 
+
*Craft a detailed block or component [[Blockdiagram]] with:
−
2.    There must not be any difficulties using the system. All kinds of people must be able to use it, there must not be special training! The system-to-be must contain enough electronics to ease and secure the use. It is also preferable to have the possibility to collect different kinds of data from the system-to-be.
+
** 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
−
3.    Errors must not occur. It will be critical if an error shuts down the heating of the house. If the temperature outside is below zero, the house and the system can be damaged if it is not heated. Therefore, the reliability must be high!
+
−
 
+
−
4.     The system must be easy to repair, if errors occur.
+
−
 
+
−
5.     All maintenance must be easy, with no or a minimum of disturbances for the user. 
+
  
−
6.    Many of the parts in the system may already have been developed by other companies. It must be considered how the lowest price is obtained. For all parts of the system-to-be it must be a choice between developing the different parts or buy something similar and redesign if necessary.
+
*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?

Latest revision as of 16:51, 20 September 2020

What

Architecture-of-the-linux-kernel-2-728.jpg

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

Linux kernel map.png

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.)
  • 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 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?
Retrieved from "http://eudp.net/index.php?title=System_Architecture_Design&oldid=1956"