User talk:RubenVancoillie

= Opdracht ECS design process =

Introduction
This chapter describes the process of designing a new embedded system, or of improving an existing one. That is, how does an individual engineer, or a team of engineers and project managers, tackle the design of an embedded system in a systematic way. This chapter tries to incorporate more than just the engineer's view of the design process: often, a process starts with a company's CTO (chief technical officer) discussing the functionalities of a new product with a customer (requirement analysis), with the HR (human resources) and CFO (chief financial officer) stepping in in a second phase (high level design) to estimate how many and which people to put on the project, and how much complexity and risks it brings for the company. Only then, the engineers can start the detailed design phase, and begin to think about implementation and testing.

Although this book focuses on embedded systems with an important amount of mechanical subsystems, the design steps can probably also be applied to design problems in most other areas of engineering.

Design steps
When designing a system, there is a sequence of steps that has to be followed before finishing an end product. These steps to design are:
 * Requirement definition
 * System specification
 * Functional design
 * Architectural design
 * Implementation (Prototyping)
 * After-sales service/support

It’s not necessary to spend the same amount of time and budget on each of these six steps. One part will go faster than the other. Sometimes even a step can be skipped or cancelled. Mostly it will be necessary to iterate between these steps to reach an final product.

In the next subsections, there will be more explanation about each of these 6 steps. Hereby an impression will be given about how to implement the steps during the designing of a system or product.

Requirement definition
In this first stage of the design process, it’s important to recognize the needs. The question that must be asked is: What does the user want?

How the product will work and witch components to use is not important at this stage. A good way to look at the system is that of a black box. Now it is only important to know what the user has to be able to input, and the demanded output associated with the input.

System specification (Project description)
In this step, the real engineering begins. The implementation of the requirements from the first step has to be realized. It is important at this stage to distinguish between system requirements and system specifications. The requirements describe what the users want out of the system when they put something in it. The specifications describe what is necessary internally to meet the requirements. This takes into account that the final project will have some real world environment where it will have to operate. That means we should consider how our system will interact with the user and the actuators it will have to control.

During this phase, the complexity of the system will become clear. This is important to have a global view of the project you’re working on.(See complexities of systems)

Detailed description (functional design)
Once the development team understands the requirements needed in order to solve the issues from the previous step, the phase of looking at how the system will work begins.

During this step of the design, the designer decides how the system will be divided into functional blocks and how they will be interconnected and implemented. It’s important to have a view of the process as a system that consists of blocks.

To do this, it’s recommended to use a block diagram approach. By doing this, a data flow between the controller and the controlled object must be defined. So the first step in defining our detailed description would be to compile a data flow diagram.

The following step would be to define exactly what these data flows entail. What are the control signals to be given, and what are the returned variables.

It is important not to specify components at this stage of the designprocess, but to keep a broad view throughout this step, later on components can be chosen. This keeps all options open and will lead to a better solution.

Architectural design
After the previous stages, the design team gets a good view of the whole system and its functionalities. Now it’s time to translate this blocks and data flow into real hardware.

It’s necessary to have different possibilities for each individual block. Hereby the team has the best option to realize the design specifications and requirements.

After these architectural decisions have been made, it’s time to put all the functional blocks together. This can cause some serious ‘logical problems’. Therefore it can be necessary to iterate on this process.

When putting these blocks together one has to pay attention to the communication between the different blocks. If you connect these blocks you have to be sure that the logic between the different blocks is respected. This means that semantics are a relevant and important issue here.

Implementation (Prototyping)
When the design team finished the hardware design, a first prototype of the system can be made. This prototype is important because it’s necessary to do some tests.

By doing this tests logic errors and hardware disabilities can be found. Feedback will be generated which can be used as input to improve the whole system.

When huge errors are found or the system does not meet the specifications, it can be necessary to return to the functional design step.

After-sales service/Support
Some systems or products need to be followed during their lifecycle. This is called after-sales service. For example: some hardware will have to be replaced, software code must be updated, the system needs an upgrade,…

Also, the client may need support. Some systems can get very complex so it’s impossible to understand it without a detailed manual and instructions from the developer. The success of a product can improve if there is a good manual and good support.

Communication
Communication is one of the most important aspects in the whole process of designing an embedded system or a product in general. If there is no communication or a lack of communication projects can get delayed which raises the costs significantly. Communication is important especially when dealing with complex systems. Complex systems are almost always designed by many different people, teams, who often have a different professional background. Not only is communication important because of different professional backgrounds, but it also insures a smooth transition between different phases of the design process and thus less iterations which leads to a quicker development of the system. In other words, communication in an organisation may be used to influence, inform, control or inspire.

In general two broad categories of communication can be distinguished. The first is the strictly managed, structured formal communication. The second the informal communication. Both are very important for an efficient product development environment. Formal communication: Formal communication channels follow the organisational structure or hierarchy. In the process of designing a new system, the most important direction of communication is probably horizontal. Horizontal communication occurs across the same hierarchy level and involves for example meetings and coordination between teams of subsystems, or the transition of information from one department to the other after completing a phase in the design process, here documentation is an very important issue and will be dealt with further in this section.

Informal communication: Informal communication exists outside the formal lines of the organizational structure. An example of this is friendship groups. The informal communication channel serves two main purposes: it permits employees to satisfy their need for social interaction in the workplace and it can improve an organization’s performance by creating alternative, and frequently faster and more efficient, channels of communication (Robbins et al. 2000). So this type of communication is very important in an organization because solutions to problems can be found much more quickly than through the formal channels, and it can lead to more creative ideas coming from different backgrounds leading to a potential more optimal solution.

Documentation: Documentation is a crucial part of the communication when going through the whole design process. At the end of each phase of the design process, other teams and people are involved in the next phase of the project. This means that every action, decision that has been taken in the previous phase has to be documented so the working principle of the system as well as the semantics of every term that has been used is clear and transparent. Documenting is often a hard and time-consuming handling because the person who writes it has to be aware of the terms and principles that can be unclear. Documentation is not in each phase of the design process in the same form and in the same quantities. When defining the requirements, documentation consist mainly out of a list of key words that describe the requirements. System specifications needs more documentation but is still schematic. So in general we can conclude that how further the phase is in the design process how more detailed the documentation has to be.

Semantics: Semantics is as mentioned important when systems and people are communicating. Often a system consists out of different subsystems who will have to communicate with each other, so the input of one subsystem has to know what the meaning is of the output of the other system. Therefore when using terms, words, designers will have to explain exactly which connotation these terms and words have. If this is not done, misunderstanding can cause the whole system to fail and then it is very hard to know where the errors are, because same words have been used for other meanings.

Closely related to semantics is jargon, jargon causes problems when for example the end user has a totally different background then the engineer who designs the product and thus uses other words for same concepts.

Late design commitments
It is crucial for a good design not to make quick decisions about the implementation of the design but to wait as long as possible to fill in the real components and hardware for your design. A late design commitment leaves open a lot of options for the implementation later on and leads to a better solution and more creativity for the developed system. In the software jargon this late design commitment is called “delaying commitment”. Late commitment is actually a part of a development strategy called “lean software development”, this strategy focuses on quick response on the market. It’s a strategy adopted from Toyota who first implemented it in the automotive industry.

How far in the design process one can keep a broad view is often very market depending. The view can be kept broad until the point where a particular system or product is linked to a customer, this point is called the order penetration point. Depending on the product delivery strategy (make to stock, assemble-to-order, make-to-order, engineer-to-order) the view can be kept broad the whole process or is already determined by the end-user at the beginning of the design process.

Recources
Human resources: The most valued assets of an organization are without any doubt the people who individually and collectively contribute to the achievement of the objectives of the business. Human resource management (HRM) is thereby a crucial organizational activity which has to make sure that the right people are employed for the right product at the right time. HRM not only has to hire and fire, but it should also bring a culture into the organization of continued growing of individuals and teams by education and team building. If a certain complex embedded system has to be designed, HRM should make sure that enough people with the right backgrounds are assigned to the project.

Quality
Quality can mean different things for different people, a common factor is that they are all important. Consumers may focus on the specification quality, asking if the implemented specifications are really needed and useful or on the relative quality, meaning how the system compares to similar systems of the competition. Producers on the other hand probably will view quality as the amount of embedded systems/products that are produced correctly.

Two main issues have to be handled when dealing with quality. On the one hand there should be prevention, which can be achieved by implementing a quality management system or at system level FMEA can be used. More about these kinds of failure modes and prevention can be read in an separate chapter that deals with this issue (Embedded Control Systems Design/Failure modes and prevention). On the other hand there should be a control system to check if there are defects. In the early days of quality control, only the end-product was checked for errors, now the general trend is the implementation of a total quality management philosophy. This philosophy exist of a total control of the production process and the implementation of quality control not only at the end stage but most importantly at all stages throughout the design process. Another part of the philosophy is to make all people involved in the organisation aware of quality, this shows the importance of good communication in total quality management.

Because quality management is a key issue in the design process and the entire organisation, international standards have been made to help cope with quality in the design, development and delivery of a general product or service. These standards are called ISO 9000:2000 standards. This is an extensive family of standards and mostly a part of them are implemented like the ISO 9001, which deals with the quality of the end-product.

The organisation itself has to decide which level of quality they want to reach, this has to be in consultation with the resource management, because the higher the level of quality the company want to achieve, the more recourses there have to be allocated to it.