Difference between revisions of "System Architecture Design"

From EUDP
Jump to: navigation, search
(→‎How)
 
(30 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
== What ==
 
== What ==
  
−
An overall system architecture divided into hardware and software specifications
+
[[File:Architecture-of-the-linux-kernel-2-728.jpg||200px]]
  
−
== How ==
+
'''Fundamental architecture of the Linux Kernel'''
−
+
−
'''The dish'''
+
  
−
An overall system architecture divided into hardware and software specifications
+
Source:''http://image.slidesharecdn.com/architectureofthelinuxkernel-090812191753-phpapp01/95/architecture-of-the-linux-kernel-2-728.jpg?cb=1250104715''
  
−
'''Ingredients'''
+
[[File:Linux kernel map.png|300px]]
  
−
*    General Architecture Analyse artefacts
+
'''Map of the Linux kernel'''
  
−
'''Process'''  
+
Source: ''By Conan at English Wikipedia, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=6092674''
  
−
Prepare the Design Constraints. Consider these topics:
+
Documents and figures describing the '''static layout of the functional blocks''' of the system-to-be.
  
−
'''The price of the product.'''
+
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.
  
−
Consider how much the product must cost. This includes sales price, development cost, HW cost, etc.
+
== How ==
 +
General architecture design consists of several steps which often require several iterations until the optimal architecture has been obtained.
  
−
'''Development time.'''
+
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.
  
−
Consider the time it must take to develop the system-to-be.
+
'''Ingredients'''
  
−
When can the production start? When can the sale start?
+
* 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)
  
−
'''Performance.'''
+
==Example==
  
−
Consider the performance of the product when it is to be used. Is it an expensive high quality product or is it a low price product which is to be sold in large quantities?. If it is a product for which a customer has paid a large amount of money, then no defects are accepted. Is the system-to-be a product which must be safe in use, optimal performance is necessary and malfunctions are not accepted. Examples could be: Electronically controlled wheelchairs, systems for use in hospitals, etc.
+
''An example of system design activities''
  
−
Another important aspect is which part of the world it is planned to sell the product-to-be. Different countries have different legislations. If you are planning to sell the system-to-be in European countries you must test your product in compliance with EU regulation and consequently mark your product with the CE certification.
+
*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 [[http://en.wikipedia.org/wiki/OSI_model OSI model]] is good as a template for dividing functionality
  
−
'''Reliability and lifetime.'''
+
*Based on the results above, evaluate if:  
−
 
+
** A slight [[Design Partitioning]] repartitioning of functionality between HW and SW will improve performance
−
The reliability and lifetime must be considered. Is the system-to-be  a product which must be safe to use, then it is necessary that the reliability and lifetime are  high and  no failures are accepted. Examples could be: Electronically controlled wheelchairs, systems for use in hospitals, etc.
+
** 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.
−
'''Already developed parts.'''
+
** The design is divided into enough functional blocks (HW and SW). Are the responsibilities within each block small enough?
−
 
+
−
If it is important to use already developed parts, these must be considered early in the project phase, because it will have an effect on the selection of the technical platform. It is not certain that these parts fit completely into the system-to-be. You have to consider how they worked in previous projects. Do they fit into the new project? Was the design as wished or did some parts have defects? Are they good enough or do you have to design  new parts?
+
−
 
+
−
'''Service and maintenance'''
+
−
 
+
−
Consider service and maintenance. No matter how well- developed the system-to-be is, it will sometimes fail or must be maintained. Maintenance can be different sorts of adjustments of the system-to-be. Sometimes replacing old HW or changing SW.
+
−
 
+
−
'''Type of System.'''
+
−
 
+
−
Consider which type of system is wanted.
+
−
 
+
−
It is possible to design systems containing much or little electronics. The more electronics the more features are normally possible. The choice could be a system that contains no electronics at all.  It is, for instance, possible to construct a heating installation with no electronics and where the parts used are purely mechanical featuring only a few adjustment possibilities. It is also possible to construct a heating installation containing much electronics. In this case there are many adjustment  possibilities, and it  will be easy to guide the user.
+
−
 
+
−
===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==
+

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"