User talk:Wieland

Introduction
This chapter describes the process of designing a new embedded control system, or improving an existing one. That is, how can an individual engineer, or a team of engineers and project managers, tackle the design in a systematic way. With respect to the traditional views on the design process, this chapter adds an extra point of view—the design context of each particular system—to increase insight in the various interactions between the traditional design steps, and their relative importance. The last section treats some cross-sectional issues in the design of large-scale systems.

Design process: a predefined pattern?
The literature describes a set of phases or steps that each development team will pass through:
 * Requirement definition, determining the needs or conditions to meet for a new or altered product, taking into account the possibly conflicting (technical, functional and non-functional) requirements of the various stakeholders, such as beneficiaries, legal parties or users.
 * System specification, describing the requested behaviour of the system.
 * Functional design. defining which subprocesses (or components) are needed in the system.
 * Detailed design, resulting in a concrete structure of all modules from which the system must be made.
 * Implementation, building and testing prototypes of the eventual system.

Some cases (such as this example) pass all of these phases, but it is difficult to give a clear description of what phases each new design has to go through exactly, and of what the design team should do exactly in each phase. Some designs will spend more time in the functional design phase, others on the system specification, etc.

The market demands to deliver ever more complex systems, with ever more customization, live-long maintenance support, and recycling and disassembly requirements at the end of the active life of the system, have resulted in design activities that can no longer follow any of the traditional, very structured design process models. Except maybe for domains such as aviation, where strict regulations and certifications are to be satisfied.

Traditional design process models
This section discusses some of the popular, traditional design process models:
 * The Waterfall model is the most rigid one, suggesting to move to a phase only when its preceding phase is completed and perfected. Phases of development in the waterfall model are kept very separated, and there is no room for iteration or overlap.
 * The V model has the same strict serial strucuture as the waterfall model, but it suggests that, before going to a more detailed design level, one should already test all the system features and properties that can be tested at the current level of design abstraction.
 * The [[w:Incremental_build_model|Incremental Model ]] allows multiple iterations in some of the design phases, resulting in a multi-waterfall process.
 * The Spiral Model is similar to the incremental model, with more emphases placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model).
 * Model-Driven Engineering is an emerging design process, that improves on the V-Model by supporting the test phases at each design level by software models that simulate the system before real implementations exist already.

Design contexts
In practice, the design process of a particular system is not only determined by what phases to go through, in what order, but also by the particularities of the context in which the system is to be designed: does one make a next version of an already successful product? Does one design the first prototype of an innovative system based on still partially immature technology? Does one design a system to participate in a contest? Etc. The following sections bring some structure into this issue of design contexts, by presenting a (non-exhaustive) set of typical contexts.

From Scratch Environment
In this sort of project the design team starts working from scratch so everything needs to be organized and designed. This is an disadvantage as well as an advantage: it takes a lot of work (time and money) to complete these projects, but the whole system can be designed in such a way that every component has a good interaction with others. Let's take the Senseo coffee machine as an example. This product is not a result from previous models, but it is designed out of nothing. The used techniques, the basic principle, the looks,... all those things are totally new and are not recovered from old coffee machines (neither from the Philips company or from any competitor ).

A typical project in this environment goes on the cycle shown in figure 1. Starting from the "requirement definition", which can be defined by the design team or deduced from a market research, the process undergoes a level of more and more details. It's convenient that issues are coming up in the "system specification", "functional design" or "detailed design" step by which the requirements need to be adjusted.

Another important step is the testing or "implementing" phase. Because the product is completely new, the system should be tested thoroughly. The feedback of error messages is quite crucial at this point. These prototypes are also a source of adjustments in the architectural or detailed design. In extreme situations even the requirement definitions need to be redeveloped, e.g. when the prototype indicates the requirements are physically impossible.

This whole of iterations makes the project very time-consuming.

Adapting Environment
Here the design team starts from a previous model, version,... of their product and they try to improve the concept by reducing the shortcomings and to emphasize the plus points. It’s obvious that these projects are more time-efficient than when people have to start from scratch. One can apply this method of working for a few versions, but there’s the danger of making things more complex than they should be. Therefore it’s useful to start over some times.

We report the fact that there exist different adaptations. Sometimes the system is expanded with totally new features, this can vary from one or two radical changes in design requirements to a lot of small adjustments. Another adaptation is the optimization of existing design requirements.

In automotive industry, designers are usually working in this kind of environment. A car manufacturer typically has a few models which are improved with latest technologies e.g. the first Porsche Carrera 911 was introduced in 1963, but the concept is still renewed every few years. Even when a new model in a new segment is developed, the design team can reuse older concepts or components like a chassis.

Figure 2 shows there is obviously less feedback or iteration involved compared to a design process in a from scratch environment. The requirement definitions are mainly derived from market research. Customers are asked for the satisfaction and shortcomings of the current product so the company can counter these imperfections.

Prototypes can force the detailed design to change, because the required functions are not fulfilled, nevertheless iteration towards the system specifications is unusual.

Nowadays the aspect of maintenance (or after sale-support) is becoming important. In the early days of commercialisation a working product was a good product, but now customers are more demanding and a company is punished in short term or in long term when a product isn't designed in a good way. Total quality management is therefore a helpful tool.

Competition Environment
A lot of companies organize a competition where the winning team is accepted to produce or build the proposed product (e.g. in architectural environment). Typical for these kind of projects are the deadline and the strict boundary conditions or specifications which are dictated by the organizers. Often these targets are hard to succeed, and cause the designers to be creative and flexible. It typically demands an iterative way of working, the first design will be adapted a lot of times before it’s finished.

An example of this environment is the Robocup Challenge. In this competition different teams are trying to build a robot that is able to play a soccer game.

In figure 3 one can see the cycle that describes the design process. Iteration is involved in the design, but it's focused on the testing phase. Although the concepts, used technologies and details can change very frequently the requirements are firm as a rock and irreplaceable (symbolised by the stout frame in figure 3). These frequent conversions are only allowable if they are not too expensive. Changing some parameters in a driver's source code costs no money, but changing the hardware-components in a system does!

The maintenance aspect of the system is not on the designer's mind. The product should meet the requirements, but there's no need for commercialisation or mass fabrication. In some situations (e.g. architecture-competition) the maintenance or durability facet can be one of the requirements defined by the organiser. In that case it's obviously not negligible.

Research Environment
Research, although often linked to universities, is an important activity in modern companies (sometimes more than 20% of sales are injected into the R&D department). The main characteristic of these kind of projects is the flexible set-up of requirements. One starts from a given objective and by doing this, he finds related items where he can work on and which might lead to interesting new developments.

Google for instance is famous for its "20 percent time". In this philosophy all Google employees are encouraged to spend 20% of their time (or one working day in a week) on a subject they think is interesting. In this way a lot of new fields can be discovered, which wasn't thought of before.

In contrast with the competition environment, the requirements aren't outlined very strictly. By defining the system specifications, by searching for new developments or by analysing the prototypes some interesting new topics may come up which replace or complete the earlier defined demands.

Similar to the competition environment is the lack of the maintenance design step. The treated system doesn't have commercial objectives, so there is no need to take account for possible customers. Once there are clear results from a research project and the company decides to bring a specific product on the market, these steps become important and the project moves to a from scratch or adaptive environment.

It's often difficult to terminate these projects, "Is it effective and useful to go on with the research?" or "Do we have enough information to build a new product?" are questions that are not easy to answer. In a company the R&D manager is accountable for these topics just like he is the person to see which research items are interesting and which are not.


 * A design team in a research environment focuses typically on one or two user requirements.
 * Another important issue concerning this environment is money. Spin off's for example are constantly spending time to find persons or organisations who are willing to finance their project.

Cross-sectional Issues
The previous section sets up different environments in which the design process has some inherent characteristics. Nevertheless there are some similarities or items that are significant in all environments. This section handles these cross-sectional issues. Cross-sectional also covers the continuity in time and the linking between the different design phases.

Communication
Communication is an aspect that is present during the whole design process. If there is no communication or a lack of communication projects can get delayed which raises the costs significantly. Communication is essential 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 progress 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 organizational structure or hierarchy. In the process of designing a new system, two directions of formal communication exist, horizontal and vertical. 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. Vertical communication deals with the communication between different hierarchy levels, following the strict order of it. Top-down communication allows management for example to communicate the specifications a designed product has to have from company point of view, i.e. target cost, time to order, etc. Bottom-up communication is the feedback from the bottom of the hierarchy towards a higher hierarchical level. Documentation is a main issue when dealing with formal communication 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).

Both categories are present in every design environment, but which of both categories is the most important and in what quantities they are used is dependent of the [ "design environment"] that one is in.


 * From scratch environment:In this environment formal communication takes the upper hand. Research from the marketing department has to be formally communicated to set up the requirements of a new to be designed product. When patents for the new product have to be acquired these specific issues need to be documented.


 * Adapting environment: Here formal as well as informal communication are used as a means of communication. In some industries like aviation, formal communication is the number one means of communication because in this sector all the products that are designed have to meet strict legislation.


 * Competition environment: Almost all internal communication is informal communication, i.e. in the Robocup teams there is often no formal communication and documentation when designing component for the robots. The goals, defined by the organisers of the competition, on the other hand are formal.


 * Research environment: Informal communication is also a key note here, because a lot of information is acquired through informal communication channels. Formal communication exists mainly out of papers or summaries of the achieved work or progress of the research.

Not only the design environments are an influencing factor for the mode of communication used, the type and magnitude of the organisation where the design process is being handled is an influencing factor.

Documentation: Documentation is a crucial part of the communication. 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 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 instance 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 a product is on the time line of 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 Toyota uses in the automotive industry and that has been adapted to software development.

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 resources there have to be allocated to it.

Welcome to Wikibooks, Wieland!  First steps tutorial Wikibooks is for freely-licensed collaboratively-developed textbooks. You don't need technical skills in order to contribute here. Be bold contributing and assume good faith about the intentions of others. Remember, this is a wiki, so you're allowed to change just about anything, and changes can be made easily. Come introduce yourself to everyone, and let us know what interests you.

If you're coming here from other Wikimedia projects, you should read our primer for Wikimedians to get quickly up-to-speed.  Getting help  Goodies, tips and tricks  Made a mistake? Thanks, Swift (talk) 22:05, 13 April 2009 (UTC) (P.S. Would you like to provide feedback on this message?)
 * See the Wikibooks help pages for common issues.
 * Remember, every edit is saved, so if you make mistakes, you can revert to an earlier version if needed.
 * Get help from the community in the Reading room or in our IRC channel.
 * You cannot upload an image until you have been a member for at least 4 days. If your upload is tagged with, , or , please read the template message as it explains the violation of our media policy. Please be sure to provide the required : a license tag and source citation are always required; fair use images require a . Get help in the user assistance room.
 * Please fill in the edit summary and preview your edits before saving.
 * Sign your name on discussion pages by typing &#126;&#126;&#126;&#126;
 * User scripts can make many tasks easier. Look at the Gadgets tab of my preferences; check off the boxes for the scripts you want, and hit save!
 * Please make sure you follow our naming policy - modules should be named like.
 * Need to rename a page? Use the move tab (only become available once your account is 4 days old - until then, ask for help).
 * To get a page deleted, add to the top of the page.
 * If something you wrote was deleted, please read the deletion policy, and check the deletion log to find out why. Also check the VFD archives if applicable. You can request undeletion at WB:VFU, or ask the administrator who deleted the page.

Talk pages
You may wish to have a look at Help:Talk page and Help:Starting a new page or book. This page is not intended for drafting books or pages, but for discsussion. --22:05, 13 April 2009 (UTC)