Embedded Control Systems Design/The design process

The Wikibook of Embedded Control Systems Design

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.

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:

• system identification, understand the process and identify the relationship between input and output
• 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, life-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 structure 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 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 ).

Figure 1 Design process in a from scratch environment

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 Design process in an adapting environment

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. In the automotive industry for example, concept cars are firstly introduced to the public. Depending on their reaction, the car manufacturer can decide whether a concept is ready for production, or is still in need of some modifications.

It should be noticed that these requirements can't all be derived from market research. Airbags for example weren't directly derived from market research, because you can't expect such results from any market research. In this case the market research results probably dealt with safety shortcomings. The engineers then have to translate this requirement into a new system. There was no customer that said: "design a bag that blows up when cars collide".

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.

Figure 3 Design process in a competition environment

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.

Figure 4 Design process in a research environment

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 adapting environment. A nice example of a project in a research environment is the Solar Impulse.

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 similarities or items that are significant in all design steps are discussed in this section. These cross-sectional issues also cover the continuity between the different design phases. Information on obvious cross-sectional issues, i.e. communication, resources, quality, ..., can be found on wikipedia.

Late design commitments

A good design will wait as long as possible to fill in the real components and hardware. This leaves open a lot more options for the implementation later on and thus gives more margin for unexpected situations.

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.