HLD – High Level Design

A high-level design provides an overview of a solution, platform, system, product, service, or process. Such an overview is important in a multi-project development to make sure that each supporting component design will be compatible with its neighboring designs and with the big picture.

The highest level solution design should briefly describe all platforms, systems, products, services and processes that it depends upon and include any important changes that need to be made to them.

A high-level design document will usually include a high-level architecture diagram depicting the components, interfaces and networks that need to be further specified or developed. The document may also depict or otherwise refer to work flows and/or data flows between component systems.

In addition, there should be brief consideration of all significant commercial, legal, environmental, security, safety and technical risks, issues and assumptions. The idea is to mention every work area briefly, clearly delegating the ownership of more detailed design activity whilst also encouraging effective collaboration between the various project teams.

Today, most high-level designs require contributions from a number of experts, representing many distinct professional disciplines. Finally, every type of end-user should be identified in the high-level design and each contributing design should give due consideration to customer experience

High Level Design (HLD) is the overall system design - covering the system architecture and database design. It describes the relation between various modules and functions of the system. Data flow, flow charts and data structures are covered under HLD.

Low Level Design (LLD) is like detailing the HLD. It defines the actual logic for each and every component of the system. Class diagrams with all the methods and relation between classes comes under LLD. Programs specs are covered under LLD.

Read more: http://wiki.answers.com/Q/Difference_between_high_level_design_and_low_level_design#ixzz1KpWSiYNq

 

High Level Software Design

High level software design, also called software architecture is the first step to analyze and consider all requirements for a software and attempt to define a structure which is able to fulfill them. For this also the non-functional requirements have to be considered, such as scalability, portability and maintainability. This first design step has to be more or less independent of a programming language. This is not always 100% possible, but a good high level design can be further refined into a low level design, which then describes the implementation in any desired programming language.

The Architecture

The first step in designing software is to define the architecture. Simply speaking this is a very high level outline of the components and layers of software. There may be some requirements which explicitly ask for some of the below named features, but even if there are no explicit requirements it is a good design style to adhere to these principles:

Design layers which at least make the functional part of the software independent of a hardware platform. Any specialties which have to be covered when running on a certain platform have to be in a special hardware abstraction layer.

•  Design an adaptation layer to adapt to a special operating system (if necessary). Operating systems may offer services and semaphores, but never use them directly in your functional software. Define your own services and semaphores and go through an adaptation layer to adapt them to the operating system 
• Design any additional layers inside your functional software as appropriate.
• Design components inside your functional software. Depending on your requirements and future strategies it may be wise to e.g. design communication protocol components in a way that they can be easily removed and replaced by another protocol, to adapt to different platforms and systems. E.g. in the automotive industry the CAN bus is widely used for communication between the various electronic systems in a vehicle. However some customers require different proprietary protocols. Your software can be designed in a way to modify the protocols easily. Almost as easy as "plug and play", if the design is done properly.
• Design an own framework which controls the calls and interactions of your functional software.
• Design an own framework which controls the calls and interactions of your functional software.

Of course this was only a very rough outline of how architecture may look like and what we found to be the best way for many applications. However, your own system may require some additional features of the architecture. 

Object Orientation

Object orientation is nowadays usually associated with certain design methods like UML and programming languages like C++ or Java. However the principles of object orientation were developed long before these methods and programming languages were invented. The first steps of object oriented design were done by using C. And indeed object orientation is a principle of design rather than a tool or method based feature. Some of these principles are:

•   Orientation of program components at the real physical world. This means that the division of a software package is done according to the real outside world of a system and according to main internal tasks of such a system.
• Combining of all elements of software (i.e. data, definitions and procedures) into an object. This means that everything that is needed to handle an element of the system is grouped and contained in one object
• Access to the object's data and functions via a clearly defined narrow interface and encapsulation of elements which are not required for the outside world to be hidden in the object.

Interfaces

The design of your interfaces is another element which adds to the stability, portability and maintainability of your software. The following things have to be observed:

Only use function calls as interfaces and refrain from using memory pools or any other globally shared elements as interface. Make your interfaces as narrow as possible. I.e. use simple basic data types rather than complicated proprietary structures at the interfaces. It is sometimes amazing how simple interfaces can be if the functionality is distributed in a sensible way in appropriate components. Preferably make your interfaces uni-directional. This means that higher level components acquire data from lower level components and layers. Try to avoid bidirectional interaction between the same components. Describe your interfaces clearly. Even at a high level design the kind of information, the data width, resolution and sign has to be determined. This can be done on an abstract level i.e. there is no need to define them in terms of data types of a special programming language.

More details will be given in the description of low level design related to the programming language C.

Operating Systems and Timing

Basically there are two categories of microcontroller systems. The first one is EVENT driven, as e.g. cell phones and other modern communication equipment.

The other kind of application is TIME driven. These microcontroller systems usually have the task to measure and evaluate signals and react on this information accordingly. This measuring activity means that signal sampling has to be performed. Additionally there may be activities like feedback current controls which have to be performed. Both activities imply by the underlying theories that sample frequencies have to be as exact as possible.

Both categories of systems are called REALTIME SYSTEMS, but they are like two different worlds!

         The EVENT driven systems are comparatively simple. The are usually in an idle state until one of the defined events triggers a task or process, which is executed sequentially until it is finished and the system returns to the idle state. During the execution of such a task these systems usually do not react on other events. This "first comes first serves" principle e.g. can be seen in a cell phone, where incoming calls are ignored after you started to dial an outgoing call.

          TIME driven systems are much more complicated. Usually all possible inputs to the system have to be sampled and all outputs have to be served virtually simultaneously. This means that time slices have to be granted to the various activities and their duration has to be defined and limited to ensure the overall function of the system. It would be too much to go into more details here. However there are some general rules which should be considered:

The CPU selection should be made according to the application. There are some CPUs which support time driven application in an optimized way. E.g. it is recommendable to have sufficient interrupt levels, CAPCOM units and I/O ports which can be accessed without delays for time driven applications. It is sad to see that in recent years some well known microcontrollers which originate in the event driven world were pushed into the time driven market. The ease of development and stability of the systems suffer from this. Although the attempt was made by the CPU manufacturer to cover for that by designing suitable peripheral units, the whole situation still looks like an odd patchwork rather than a sound design.Operating systems can be event driven and non-preemptive for EVENT driven applications.Operating systems should be time driven and preemptive for TIME driven systems.Standard operating systems may fail you for high speed tasks, such as 250 us tasks for feedback current controls. In this case you have to do this by tricks and timer interrupts outside of the operating system. Therefore have a close look at the OS from the shelf before you base your system on it.

A Word about Modern Design Methods and Tools

Most of our ideas concerning high level design were outlined above. To some this may look outdated, because there are so many design tools around which promise to make life easy. However there are a few things we want to point out concerning modern high level design methods and tools.

           There would be a lot to say about modern design methods, such as UML, SDL and others. But there are a lot of good web-sites which specialized on this. Tools are available which allow high level design in one of these methods and even make an automatic code generation. Praises are sung that these 4th level "programming languages" will be the future way of designing software and leave the skill of coding to an automatic code export triggered by a simple hit on a button. There are certainly applications where this makes sense and where this is a sensible way to go, as e.g. the use of such a tool (SCADE) for the programs in nuclear power plants. But does this also make sense for high volume microcontroller applications? There are a few stumbling blocks for this which may not be cleared away so easily in near future:

Autocoders still generate a big overhead in resource consumption (RAM/ROM/Runtime) which can not be optimized. Autocoders usually generate highly cryptical code which thus fails to be subject to any further human inspection or test. This means that all testing that can be done on a low level has to be done by the respective design tool. Some tools support this (SCADE and SDT) where the demand for an "executable specification" is met and thus a sufficient testing is possible. But this also means that a decision for such a method is at the same time a decision for higher resource consumption and a decision to have no mixed design, i.e. all the code has to come out of the tool otherwise it fails to be testable. For safety critical applications the tool and auto coder has to be certifiable. I.e. it has to be subject to checks by organizations such as the TÜV. A shoe which is too big for many modern tools, but a step which is necessary to lift a toy to the status of a real tool. So far none of the well known design methods and associated tools is able to consider the timing aspect in microcontroller systems in a satisfying way. Interrupt service routines, and especially preemptive operating system tasks in microcontroller systems are not supported in these methods and tools. But they are one of the most important aspects of design for microcontrollers.

Some of these design methods and tools may be justified in appropriate environments, but the conclusion and our recommendation for high volume microcontroller systems is:

Use design methods and associated tools for rapid prototyping. This may be a big advantage to develop functions, but do not try to bring this tool output into series production for high volume microcontroller systems. You will hopelessly fail. Use design methods to specify and describe complex functionality even for a microcontroller system. This may make the way of design easier, it uses a syntax which can be trained and understood by others, but be prepared to have a deliberate break in the tool chain where you set up a proper low level design and coding. Do not attempt to use such a design tool to design your interrupts and operating system tasks. Although some tools recently offer the inclusion of a standard microcontroller operating system, this usually does not allow preemptive tasks and does not support interrupt service routines.