Embedded Control Systems Design/A design example 1

From Wikibooks, open books for an open world
Jump to navigation Jump to search
The Wikibook of


Embedded Control Systems Design


This chapter illustrates the various steps in the design of an embedded system by means of a concrete example: an automated People Mover.

Introduction[edit | edit source]

A Bombardier_CX-100 people mover in Signapore's Light Rapid Transit.

To get a better understanding of the Design Process an example of an ECS is studied. The various phases of the design process are discussed with regard to the example.

The selected ECS for the example is the (automated) people mover. Information of what a people mover is can be found on its wikipedia page.

Phases of the design process[edit | edit source]

This chapter discusses the different phases of the design process. Please note that the design process is not black and white but gray. That is there are many different ways to get to a design and there most certainly is no ultimate design process in which no interpretation or intellect is necessary.

These discussions give you an idea of what kind of information is necessary in which phase of the design process.

The chapter Design Criteria explains the approach of a design on a system level. It's useful to read this chapter first before you read further on.

Requirements definition[edit | edit source]

Goal of this phase is the product requirements document. It is a list of important requirements that can't be omitted. In this example, the product requirement document is:

  • Railway is given by client, specifications are known.
  • Lay-out of the people mover is 1 locomotive with 1 (or more) carriages.
  • Vehicle is driven by electric motor.
  • Power for the motor comes through the rails.
  • The railroad needs to by equipped with beacons at known locations.
  • Locomotive is equipped with a beacon sensor.
  • Every beacons yields its own reaction. 3 kinds of reactions exist:
    • Speeding up with a certain amount.
    • Slowing down with a certain amount.
    • Stopping with a given deceleration.
  • Safety measures.
  • Headlights and internal illumination must switch on when it's dark.
  • A control tower:
    • must know the speed and position of the people mover at all times.
    • must be able to take over control of the people mover when necessary.

System specifications[edit | edit source]

Here the requested behaviour of the system is described. Some specifications are:

  • Wanted speeds dependent of the position (every corner has a different speed).
  • What to do in case of certain scenario's (i.e. a fire, a rail block, ...).
  • How fast to stop.
  • Where are the different stops.
  • ...

Functional design[edit | edit source]

The functional design phase defines which subprocesses and subsystems are necessary in the system.

Figure 1: Subsystems for the vehicle system of an automated peoplemover
Figure 2: Interaction between subsystems

The system can be divied into three main parts:

  • Traffic command system
  • Control command system (= wireless communication)
  • Vehicle command system

The vehicle command system can be divided further into subsystems. In the end it leaves a total of 7 subsystems:

  • Wireless communication: Implements the transfer of information from the control tower to the train and vice versa.
  • CPU: Is the brain of the people mover. All information is centralized and afterwards divided over the different subsystems.
  • Power: Is responsible for the motor, its management system, ...
  • Control loop: Makes the control loop of the drive.
  • Sensors: Gathers information of the environment.
  • Mechanical design.
  • Esthetic design.

Figure 1 gives a schematic overview of the subsystems. The interaction between the different subsystems is presented in figure 2.

Detailed design[edit | edit source]

This phase results in a concrete structure of all modules from which the system must be made. The functional design is worked out on the component level. After this phase the only thing left is the implementation. This phase can be thought of as the translation of the functional requirements into technical specifications.

Implementation[edit | edit source]

Building and testing prototypes of the system. Eventually leading to the production model. This phase needs no further explanation.

Design context[edit | edit source]

The chapter Design Contexts explains the different contexts of a design.

The people mover is either a from scratch environment or an adapting environment, depending on the presence of a previous model. The implications of a certain design context also are discussed in the section Design Contexts.

System complexity[edit | edit source]

The chapter System Complexity explains the different categories of systems as a function of their complexity as well as the definition of complexity itself.

Using this chapter it's clear that the people mover is a system of type 2: Distributed hardware - Centralized control. Perhaps in the future, when different autonomous people movers (of different companies) all use the same railroad system, the necessity of distributed control becomes obvious and this system of systems would be of the complexity class type 3. Note the analogy with air traffic control.

Process vs system control[edit | edit source]

Process vs System control describes 2 types in which ECS can be divided. The people mover, with its clear subsystems, is clearly of the type system control.