Embedded Control Systems Design/A design example 2

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

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

In order to understand what is involved in the design of embedded control systems, it is useful to elaborate an example of such a system. The chosen example comes from a commonly known application domain, so that all readers can quickly grasp the complexity and the required features of the design. At the same time, the example is sufficiently realistic to cover all relevant aspects (economical, technical, human resources, etc.) that show up (during the various phases) in the design and the lifecycle of an embedded control system. The example of a (automated) people mover meets these requirements. This Chapter is conceived as the story of how a fictitious company (People Move Company) deals with the decision to design a new people mover; this story approach allows to illustrate the different design criteria that become relevant in different phases of the product's design and life cycle.

A people mover is an unmanned train. The first people mover became operational in 1967, as an attraction in Tomorrowland in Disneyland, California. (See the Wikipedia article for more details about the history and deployment of people movers.) Nowadays, people movers are used as transport systems all around the world.

As the staff of People Move Company knows, designing an embedded control system is quite a job. A lot of people have to work together to attain an operating whole. From the moment on that People Move Company decided to take part in the call for bids for a new people mover project, the company tries to operate in a structured way. It subdivides the design job into three parts.

• In a first step, the requirements analysis, the chief engineer of the company, together with (a representative of) the CEO, make a product requirements document, in which the company expresses its views on the requirements of the client. In case the Board of the People Move Company decides the company can compete realistically in the bid —and this decision is in itself not an easy issue!— the requirements list will be used to draw up a quotation.
• Secondly, and if the company is allowed to participate in the bid, it internally enters the high level design phase, during which it completes the list of client and product requirements with requirements the company imposes for the sake of internal interest. Design criteria as component reuse, service after sale, and maintenance get the attention during this phase, since these can make a large financial difference for the company. Moreover, the responsibles of the project make a plan of which of their employees can work on which parts of the job.
• Then all involved employees can implement the detailed design of the people mover.

After these design tasks, the peoplemover has to be produced, serviced and maintained. The production process will not be discussed in detail here though.

Requirements analysis

People Move Company wants to design a fully automated vehicle for public transport. The responsibles for the project make up a list of technical, commercial and practical requirements the system has to meet in order to comply to the client's call for bids. This result is the product requirements document that is written in plain language. As the document expresses the requirements of the client, People Move Company wants to draw up the product requirements in dialogue with the client. In one such meeting, the client explains that he already is in the possession of rails on which the people mover will ride. People Move Company gets the specifications of these rails, as well as the standards for people transport that apply in the client's country. This brings in some design constraints, for example with respect to maximum velocities, acceleration profiles, weight, energy consumption, etc. In turn, People Move Company profits from the interactions with the client to explain the company's competitive advantages (technically as well as economically) as well as some product constraints that the company will want to comply to, for internal technical and economical reasons. Making these new constraints clear, in both directions, can indeed be of great importance when it comes to a lawsuit between client and company.

The interaction with the client brings People Move Company to its final product requirements document, that will be submitted to the call for bids. Internally, the same document will serve as the first input for the company's own design team. While it cannot be intended to specify all requirements in full technical detail, it described the following list of important requirements that cannot be omitted. Where exactly the border lies between a detail and a high-level requirement, and between important and lower-priority requirements, is very hard to explain or teach in general; especially because it involves so many company-specific aspects: available man power and expertise, existing products whose design can be re-used (partially) for the new product, etc. The economic success of a company will to a large extent depend on how good the design requirements team is in its job to create a realistic and competitive requirements document.

Because of already existing products in its portfolio, the company decides to design a people mover that consists of a locomotive and one or more passenger carriages. The vehicle is driven by an electric motor and receives its power from the rails. The people mover can only run on special railroads that are equipped with beacons. These beacons are placed along the railroad and indicate to the people mover's control system a desired change in speed of the people mover. A map of the railroad together with the meaning of each beacon has to be loaded into the memory of the people mover controller before the vehicle can drive on this railroad. A sensor on the vehicle detects the beacons and reacts as indicated on the map. The possible reactions are:

• speeding up with a certain amount.
  Remark: velocity and acceleration are limited to a specified maximum, according to a specified smooth profile, in order to realize a user friendly peoplemover. Such profiles are part of many already existing railroad standards.
• slowing down with a certain amount.
  Remark: deceleration is limited to a certain maximum.
• stopping with a specified deceleration.

As an example, a beacon just before a bend in the tracks indicates that the peoplemover has to slow down to a specified velocity. On the places where a terminal is indicated on the tracks, the vehicle stops. The place where the people mover stands still is specified by the client to differ with a maximum of one meter from the place indicated on the map. The doors open at least 0.1 and at most 0.5 seconds after halting. Thirty seconds after the opening of the doors a warning signal sounds for one second and the doors close. At least 1 and at most 2 seconds after the warning signal the vehicle continues its travel.

When it is getting dark, the headlights of the people mover and the internal illumination in the carriages must switch on on. The lights have a minimal intensity, specified by the client.

The company is not responsible when the railroad is blocked by any obstacle.

Although the people mover is fully automated, a control tower is able to decide on the actions of the people mover. The speed and position of the vehicle (to a certain precision) can be seen on a display in the control tower.

High-level design

Hooray, People Mover Company was among the winners of the call for bids, and now gets some funding from the client to make a more detailed high-level design, in which all the technical details that are relevant to the client will have to be explained. The list of requirements mentioned above meets the overal needs of the client, but is not specific enough for the company's designers to make a complete analysis of the feasibility and the costs of the project. These people also have to take into account the requirements that are in the People Move Company's own interest, regardless of the client's wishes. For example, as People Move Company wants to accept only jobs that fit into its long term product portfolio vision and that it can support for decades, the designers have to think of features that facilitate component reuse and maintenance of the people mover product. These efforts will lower the cost of service after sale, and of later similar products that the company wants to bring to the market. To complete the list of requirements, the company's design team has a list of design criteria that its designers always have to have in mind. For the people mover these design criteria are:

• Functionality: the people mover's first functionality is its ability to transport people in a fully automated way.
• Safety: has to be incorporated at all levels of the design. Including failure modes and adding redundancy are common safety precautions.
• Robustness: the design should have some margin to survive in conditions that are somewhat beyond what is asked by the client.
• Cost: the price still has to be competitive.
• Energy consumption: the company wants to improve its image of the least energy consuming vehicles.
• Insensitivity for varying environmental conditions (humidity, temperature and vibrations)
• Controllability: the people mover must be controllable from a control room.
• Space and weight constraints
• Producibility
• Certification and standardization
• User interface
• Life time
• Maintenance
• Service after sale

Figure 1: Global architecture

Figure 2: Global architecture (refined)

Figure 3: Subsystems for the vehicle system of an automated peoplemover

Figure 4: Communication between subsystems

Now all design criteria have to be translated into requirements that can be added to the product requirements. The extra requirements thus ensure that all design criteria will be incorporated in the final peoplemover. Some examples illustrate how this can be done.

As already stated above People Move Company can save money by including features that facilitate service after sale. This could be implemented with a "maintenance from distance" system.

Another way to save money and time is reusing infrastructure and components of previous models of the peoplemover. The safety requirement was already partially included in the product requirements by specifying that a control tower has to be able to take over all commands. But this is not enough, as safety has to be incorporated in all design levels. For example, while designing the cruise control function, the designer has to make sure that the current in the motor never exceeds a limit value. This could occur when the vehicle tries to go too fast on a slope.

Some design criteria interfere with each other. User interface, for example, has to do with safety. The system design has to anticipate inattention of the users. It could happen that someone enters the peoplemover while the doors are already closing. A sensor detecting this dangerous act, can prevent accidents. Also the design criteria life time, robustness and cost can interact. A designer has to have an idea of how long the system has to be in use. A long life time asks for robust components of higher quality. Of course this has an influence on the price.

In high level design the requirements are translated in specifications, which means that vague requirements as cost, life time, maintenance, service after sale and energy consumption are expressed more precisely. Expected life time, cost and energy consumption are defined by a certain number.

After fathoming the design criteria People Move Company has a more extended version of the product requirements in hand. With this the system engineers or system architects create a more formal set of functional specifications. They make up the global system architecture. This scheme divides the system into three main parts:

• a traffic command system
• a control command system
• a vehicle command system

Each part has a couple of inputs and outputs, represented by arrows in figure 1. The traffic command system for example gets information from beacons placed along the railroad and from the slopes themselves. These beacons indicate a change in speed of the peoplemover. A map of the railroad together with the meaning of each beacon has to be loaded into the memory of the peoplemover before the vehicle can drive on the railroad. A sensor on the vehicle detects the beacons and reacts as indicated on the map. The slopes result in a certain load torque. The inputs and outputs of the other parts are indicated on figure 1. Figure 2 describes the content of each part in more detail.

Now the top of People Move Company decides who will work on which part of the job. In some cases it is useful to work with subcontractors. The company can also hire an expert with relevant experience. By dividing the system in subsystems, different teams can work concurrently to realize these different subsystems. This is called concurrent engineering. Good inter-team communication, e.g. in daily or weekly meetings, makes it possible to attune to each other. The optimal division in subsystems minimizes subsystem-communication and maximizes subsystem-independency. Afterwards the subsystems are assembled into a fully operational system. Applying the division strategy on the automated peoplemover results in seven subsystems. Figure 3 illustrates the subsystems for the vehicle system of the automated peoplemover. The last two subsystems are omitted in this illustration as they are not really related with the embedded aspect of the design. Therefore they will not be treated in the rest of this example.

• A "Wireless communication" subsystem implements the transfer of information from the control tower to the train and vice versa.
• Subsystem "CPU" functions as the brain of the train. In this subsystem all information is centralized and afterwards divided over the different subsystems.
• Subsystem "Power" is responsible for building in the motor.
• Subsystem "Control loop" makes the control loop of the drive.
• Of course the peoplemover needs information on the environment. Subsystem "Sensors" gathers information on bends in the railway, terminals, light intensity outside and detects the radio signal of the control room.
• As the peoplemover is a physical object, a subsystem has to take care of the "Mechanical design".
• Appearances also count, especially if People Move Company wants to impress the public at large. Therefore a subsystem is in charge of the "Aesthetic design".

Of course these subsystems cannot work on their own islands. Interaction between the different subsystems is inevitable. People Move Company designates an 'integrator' who will coordinate the discussions on how transfer of information between subteams will be implemented. Figure 4 shows which subsystems need to communicate with each other. The mechanical and aesthetic design teams are not drawn as they have to be in contact with all other teams. For example, "CPU" needs to know when the control room wants to take over control. This information can be wirelessly transferred to the peoplemover. "Sensors" can provide information from beacons that indicate a desired velocity. This is a necessary input for the "Control loop" subsystem.

Detailed design

Hooray again! The People Mover Company won the competition, and has a contract to deliver 100 people movers within 36 months from now. So, the design team sits together with the human resources manager, the CTO and the CFO, to turn the high-level design document into a detailed design document that will be used to plan and guide all activities in this new project.

Architecture

Figure 5: Detailed architecture

The starting point for the detailed design is the global architecture with the division in subsystems. In a first step each subsystem has to find out which components he needs. Brainstorm sessions can be of great help here. The result of this process is the architecture of the peoplemover, illustrated in figure 5.

Furthermore the subsystems agree on the form in which the information will be communicated. This can be in an analog or a digital signal. The specific number of bits or bytes is specified together with the exact meaning of each signal. If any of these conventions turns out to be unnatural in a later stadium of the process, the involved subsystems have to sit together again to modify the agreements. As already mentioned an 'integrator' coordinates these meetings.

Now the different subteams can be set to work. The system architects avoid to (re)design every component though. Components that already exist are part of the Intellectual Property (IP) and can be used without having to design them again. Here the system architect makes a "make-or-buy decision.

Wireless communication

The control tower wirelessly sends commands to the peoplemover. This set of commands is finite. Each command corresponds with a sequence of ones and zeros, a binary codeword. A huffman code is one way to assign a binary codeword to each command. The sequence of ones and zeros now has to be transferred to the peoplemover using a modulated electromagnetic wave.

A device that performs modulation and the inverse operation demodulation is known as a modem. The peoplemover must be with equipped with an antenna and a modem. More information on communication can be found in the wikibook on Communication Systems and the wikibook on Data Coding Theory. The system designer's task is to choose a modulation method, a code and hardware (antennas and modems).

Sensors

From the product requirements document it is already clear that sensors will be needed in the peoplemover. The system designer thus has to choose suitable sensors, decide where to place them and make sure that the sensor information ends up at the right address. For each type of sensor the designer has to look for different requirements.

In every fact the peoplemover needs sensors that can detect when it is getting dark outside. An obvious solution is a light sensor with fotovoltaic cells. Of course a lot of sensors of this kind exist. It is up to the designer which final sensor will be used. It is also important to decide where this sensor will be placed. The best place for the light sensors is probably on the roof of the vehicle.

Also the communication with the control room asks for a sensor. Here one can think of sensors for radio detection. The environment in which the peoplemover will be used is of great importance here, as the control tower always has to be able to make contact with the peoplemover, even when the vehicle is in a tunnel.

The designer has to choose how the beacons will work. At first sight optical sensors seem to be very interesting. The beacons could even send out coded signals. This choice will certainly lead to difficulties though, because the environment is very 'hostile'. A leaf or other natural object can easily disturb the signal. A more robust solution is thus needed. An option is to make the beacons magnetic. A sensor in the peoplemover can then detect this magnetic field.

Furthermore the peoplemover needs to be equipped with a velocity sensor and weight sensors to detect overload. The outputs of this subteam is sent to the CPU and will result in an action.

In general sensors are quite expensive. The cost design criterion has to be considered as a consequence when choosing the right sensors.

CPU

The central processing unit (CPU) handles the incoming information. In first instance this information comes from the magnetic beacons, but the control room can take over. The possible commands are:

Figure 6: Possible implementation of the CPU

• Desired speed = maximum speed
• Desired speed = 0.8*maximum speed
• Desired speed = 0.6*maximum speed
• Desired speed = 0.4*maximum speed
• Desired speed = 0.2*maximum speed
• Stop
• Desired speed = 0.2*maximum speed in the other direction
• Desired speed = 0.4*maximum speed in the other direction
• Desired speed = 0.6*maximum speed in the other direction
• Desired speed = 0.8*maximum speed in the other direction
• Desired speed = maximum speed in the other direction
• Reset counter
• Lights on
• Lights off

Each time the wheel senses a magnetic signal from the railway, a counter is incremented with one unity. In this way every beacon has a corresponding counter's output. A logic circuit decodes this counter output. A programmable logic controller (PLC) provides a robust implementation. Figure 6 shows a possible implementation of the CPU. For a trajectory with sixteen beacons a 4-bit counter is sufficient. The decoder contains the necessary information to give the right command each time a beacon signal arrives. A speed signal goes to the control loop subsystem or a signal is sent to the light controller.

Control loop

Figure 7: Implementation of the drive's control loop

One of the teams is in charge of the drive's control loop. The process this team implements is illustrated in figure 7.

This subsystem receives the desired speed of the CPU team and the measured speed of the Power Team. These are digital signals. To convert them into analog signals the inputs are sent through Digital to Analog Converters. With the design criterion of robustness in mind it is wise to include low pass filters here. This increases the signal-to-noise ratio. A comparison of the resulting signals has to lead up to a voltage signal that steers the motor. The associated controller is the PI velocity controller.

As already indicated in the high level design the current in the motor has to be limited for safety reasons. A clipper can be used to achieve this.

A second controller is the current controller, which allows quick motor control. In fact the two PI-controllers are in a master-slave configuration. The master PI controls the speed by adjusting the requested current, while the slave controls the current manipulating the motor voltage.

After all discussed manipulations the control loop gives a voltage signal in the output. This signal goes to the Power Team.

The conceptual scheme of figure 7 thus consists of Digital to Analog Converters (DAC1 and DAC2), low pass filters (LPF), PI-controllers (PI vel and PI curr), amplifiers (A) and a clipper. These elements can be realized with a collection of resistors, capacities and other simple electronic components.

Power

Figure 8: A PWM VFD diagram

An automated peoplemover is driven by an electric motor. Different implementations are used in practice.

Most trains nowadays are driven by a variable frequency drive. A variable-frequency drive (VFD) is a system for controlling the rotational speed of an alternating current (AC) electric motor by controlling the frequency of the electrical power supplied to the motor. The motor used in a VFD system is usually a three-phase induction motor. AC input power is first converted to DC intermediate power using a rectifier bridge. The DC intermediate power is then converted to quasi-sinusoidal AC power using an inverter switching circuit. The VFD steering circuit is pictured in figure 8.

Since the control loop subsystem steers the power subsystem, these two subsystems will have to communicate. The control loop's steer signal (named PWM) carries information in its frequency. This signal is compared with a triangle wave with a much higher frequency. The comparator's output steers the 2 switches of one phase. As a result each phase has a quasi-sinusoidal waveform with the same frequency as the control loop's steer signal. The power subsystem also has other functions to fulfill such as measuring the current through the motor and measuring the speed of the motor. Again multiple implementations are possible. Just one of those is described here.

The control loop subsystem limits the desired acceleration to avoid a large current through the motor. Therefore the control loop subsystem needs an input signal proportional to the motor current. The current can be measured by connecting a small resistance in series with the motor. The voltage across this small resistance is proportional to the motor current. A differential amplifier is used to become a voltage signal with a range of [-5V, 5V].

In the power subsystem itself, a current limiter is also built in. In all kinds of applications redundancy is used to increase safety. This is very important to become a robust and safe system.

The actual speed of the peoplemover is necessary information for subsystem control loop to control the speed. The speed can be measured by a rotary encoder placed on the wheel axis. The output of the encoder serves as input of a microcontroller that sends out a 8-bit digital signal to subsystem CPU and subsystem control loop.

Another important functionality that has to be implemented in the power subsystem is the emergency brake. When subsystem CPU sets the stop signal high (5V) the motor has to be stopped immediately. This functionality can be implemented in many ways. The most obvious way is to OR the Stop signal with the pulses from the pulse width modulation.

Testing

An indispensable part of the design is testing. All subteams have to test their own system. Moreover the different subsystems have to be tested in smaller groups. Of course the final step is to test the whole. For example, more on software testing can be found on software testing.

Implementation and production

When all design steps are passed through, People Move Company can start with the implementation and production of the peoplemover. These tasks again ask for a structured approach. They are not discussed in this Wikibook though.

Embedded Control Systems Design