Difference between revisions of "System Architecture Design"

From EUDP
Jump to: navigation, search
(→‎Example)
Line 1: Line 1:
 
== What ==
 
== What ==
  
−
An overall system architecture divided into hardware and software specifications
+
Documents and figures describing the static layout of the functional blocks, of the system to be.
 +
 
 +
Block or component diagrams, that shows the functional decomposition into HW and SW blocks respectively
  
 
== How ==
 
== How ==
−
+
General architechture design consists of several steps, that often requires several iterations, untill the optimal architechtre is crafted.
−
'''The dish'''
+
  
−
An overall system architecture divided into hardware and software specifications
+
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.
 +
Therefore one should expect to iterate between the task in General Architechture design
  
 
'''Ingredients'''
 
'''Ingredients'''
  
−
*     General Architecture Analyse artefacts
+
* System constraints, see [[http://www.eudp.dk/index.php/Design_Constraints_Analysis Design Constraint Analysis]]
 +
* 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'''  
 
'''Process'''  
  
−
===Design Constraints===
 
−
 
−
Prepare the Design Constraints. Consider these topics:
 
−
 
−
'''The price of the product.'''
 
−
 
−
Consider how much the product must cost. This includes sales price, development cost, HW cost, etc.
 
−
 
−
'''Development time.'''
 
−
 
−
Consider the time it must take to develop the system-to-be.
 
−
 
−
When can the production start? When can the sale start?
 
−
 
−
'''Performance.'''
 
−
 
−
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.
 
−
 
−
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.
 
−
 
−
'''Reliability and lifetime.'''
 
  
−
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.
 
  
−
'''Already developed parts.'''
 
  
−
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===
 
===Partitioning===

Revision as of 07:14, 25 September 2012

What

Documents and figures describing the static layout of the functional blocks, of the system to be.

Block or component diagrams, that shows the functional decomposition into HW and SW blocks respectively

How

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. Therefore one should expect to iterate between the task in General Architechture design

Ingredients

  • System constraints, see [Design Constraint Analysis]
  • 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






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

    Issue         Critical       Very Important    Important   Less Important  Notes

Performance                           X                                          1
Usage                X                                                           2
Reliability          X                                                           3
Easy serviceable                                       X                         4
Remote maintenance                    X                                          5
Cost effective                                         X                         6


Notes:

1. The performance is very important.

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.

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.

Retrieved from "http://eudp.net/index.php?title=System_Architecture_Design&oldid=1579"