113,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Serie: Quantitative Software Engineering Series
- Sprache: Englisch
- Veröffentlichungsjahr: 2017
Offering comprehensive coverage of the convergence of Real-Time Embedded Systems scheduling, resource access control, software design and development, and high-level system modeling, analysis and verification Following an introductory overview, Dr. Wang delves into the specifics of hardware components, including processors, memory, I/O devices and architectures, communication structures, peripherals, and characteristics of real-time operating systems. Later chapters are dedicated to real-time task scheduling algorithms and resource access control policies, as well as priority-inversion control and deadlock avoidance. Concurrent system programming and POSIX programming for real-time systems are covered, as are finite state machines and Time Petri nets. Of special interest to software engineers will be the chapter devoted to model checking, in which the author discusses temporal logic and the NuSMV model checking tool, as well as a chapter treating real-time software design with UML. The final portion of the book explores practical issues of software reliability, aging, rejuvenation, security, safety, and power management. In addition, the book: * Explains real-time embedded software modeling and design with finite state machines, Petri nets, and UML, and real-time constraints verification with the model checking tool, NuSMV * Features real-world examples in finite state machines, model checking, real-time system design with UML, and more * Covers embedded computer programing, designing for reliability, and designing for safety * Explains how to make engineering trade-offs of power use and performance * Investigates practical issues concerning software reliability, aging, rejuvenation, security, and power management Real-Time Embedded Systems is a valuable resource for those responsible for real-time and embedded software design, development, and management. It is also an excellent textbook for graduate courses in computer engineering, computer science, information technology, and software engineering on embedded and real-time software systems, and for undergraduate computer and software engineering courses.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 493
Ähnliche
Table of Contents
Cover
Title Page
Copyright
Preface
Book Layout
Audience
Acknowledgments
Chapter 1: Introduction to Real-Time Embedded Systems
1.1 Real-Time Embedded Systems
1.2 Example: Automobile Antilock Braking System
1.3 Real-Time Embedded System Characteristics
1.4 Hard and Soft Real-Time Embedded Systems
Exercises
Suggestions for Reading
References
Chapter 2: Hardware Components
2.1 Processors
2.2 Memory and Cache
2.3 I/O Interfaces
2.4 Sensors and Actuators
2.5 Timers and Counters
Exercises
Suggestions for Reading
References
Chapter 3: Real-Time Operating Systems
3.1 Main Functions of General-Purpose Operating Systems
3.2 Characteristics of RTOS Kernels
3.3 RTOS Examples
Exercises
Suggestions for Reading
References
URLs
Chapter 4: Task Scheduling
4.1 Tasks
4.2 Clock-Driven Scheduling
4.3 Round-Robin Approach
4.4 Priority-Driven Scheduling Algorithms
4.5 Task Assignment
Exercises
Suggestions for Reading
References
Chapter 5: Resource Sharing and Access Control
5.1 Resource Sharing
5.2 Nonpreemptive Critical Section Protocol
5.3 Priority Inheritance Protocol
5.4 Priority Ceiling Protocol
5.5 Stack-Sharing Priority Ceiling Protocol
Exercises
Suggestion for Reading
References
Chapter 6: Concurrent Programming
6.1 Introduction
6.2 POSIX Threads
6.3 Synchronization Primitives
6.4 Communication among Tasks
6.5 Real-Time Facilities
Exercises
Suggestions for Reading
References
Chapter 7: Finite-State Machines
7.1 Finite State Machine Basics
7.2 Deterministic Finite Automation (DFA)
7.3 Nondeterministic Finite Automation
7.4 Programming Finite-State Machines
Exercises
Suggestions for Reading
References
Chapter 8: UML State Machines
8.1 States
8.2 Transitions
8.3 Events
8.4 Composite States
8.5 Pseudostates
8.6 UML State Machine of Antilock Braking System
Exercises
Suggestions for Reading
References
Chapter 9: Timed Petri Nets
9.1 Petri Net Definition
9.2 Petri Net Properties
9.3 Timed Petri Nets
Exercises
Suggestions for Reading
References
Chapter 10: Model Checking
10.1 Introduction to Model Checking
10.2 Temporal Logic
10.3 The NuSMV Model Checking Tool
10.4 Real-Time Computation Tree Logic
Exercises
Suggestions for Reading
References
Chapter 11: Practical Issues
11.1 Software Reliability
11.2 Software Aging and Rejuvenation
11.3 Security
11.4 Safety
11.5 Power Conservation
Suggestions for Reading
References
Index
End User License Agreement
Pages
xiii
xv
xvi
xvii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
179
180
181
182
183
184
185
186
187
188
190
191
192
193
194
195
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
293
294
295
296
297
298
299
300
301
302
303
305
306
307
308
309
310
Guide
Cover
Table of Contents
Preface
Begin Reading
List of Illustrations
Chapter 1: Introduction to Real-Time Embedded Systems
Figure 1.1 Relationship among the slip rate, braking force, and cornering force.
Figure 1.2 Wheel speed sensor.
Figure 1.3 Valves operate in the apply mode.
Figure 1.4 Valves operate in the hold mode.
Figure 1.5 Valves operate in the release mode.
Figure 1.6 Electrical control unit.
Figure 1.7 A Cascade control structure for ABS.
Figure 1.8 Structure of real-time embedded systems.
Figure 1.9 Value of hard and soft real-time tasks when deadline is missed.
Chapter 2: Hardware Components
Figure 2.1 Real-time embedded system hardware components.
Figure 2.2 Microprocessor elements.
Figure 2.3 Two fundamental computer architectures. (a) von Neumann architecture and (b) Harvard architecture.
Figure 2.4 Cache memory.
Figure 2.5 A dual-core processor with two levels of cache memory.
Figure 2.6 Structure of a 16-bit counter.
Figure 2.7 A timer with a prescaler and a capture register.
Chapter 3: Real-Time Operating Systems
Figure 3.1 (a) Single-threaded process; (b) Multithreaded process.
Figure 3.2 Structure of object module.
Figure 3.3 Memory areas of process.
Figure 3.4 Context switch between tasks A and B.
Figure 3.5 The block chaining scheme in file storage.
Figure 3.6 A high-level view of RTOS.
Figure 3.7 Structure of a microkernel.
Figure 3.8 Priority scheduling.
Figure 3.9 Shared memory and critical section.
Figure 3.10 Synchronous I/O versus asynchronous I/O.
Chapter 4: Task Scheduling
Figure 4.1 Task specification.
Figure 4.2 States of a task.
Figure 4.3 A task graph.
Figure 4.4 Two feasible schedules for
T
1
= (4, 1),
T
2
= (6, 1), and
T
3
= (12, 2).
Figure 4.5 Clock-driven scheduler.
Figure 4.6 A task instance released right after a frame starts.
Figure 4.7 A cyclic schedule of frame size 2.
Figure 4.8 Cyclic scheduler.
Figure 4.9 (a) Periodic task schedule. (b) Two aperiodic tasks. (c) Scheduling aperiodic tasks without slack stealing. (d) Scheduling aperiodic tasks with slack stealing.
Figure 4.10 Scheduling sporadic tasks.
Figure 4.11 Scheduling of periodic, aperiodic, and sporadic tasks.
Figure 4.12 RM scheduling of three periodic tasks.
Figure 4.13 Example of task missing deadline in RM schedule.
Figure 4.14 Time demand function for tasks in Example 4.11.
Figure 4.15 EDF schedule of three one-shot tasks.
Figure 4.16 EDF schedule of periodic tasks that cannot be scheduled by the RM algorithm.
Figure 4.17 Proof of optimality of EDF.
Figure 4.18 Infeasible EDF schedules.
Figure 4.19 Aperiodic task scheduling. (a) Aperiodic task scheduled at the background of periodic tasks. (b) Aperiodic task scheduled with a simple polling server. (c) Aperiodic task scheduled with a deferrable server.
Figure 4.20 Illustration of impact of task self-suspension.
Figure 4.21 Precedence constraints graph of tasks in Problem 7.
Chapter 5: Resource Sharing and Access Control
Figure 5.1 Critical sections.
Figure 5.2 Priority inversion.
Figure 5.3 Deadlock.
Figure 5.4 Priority inversion with Mars Pathfinder.
Figure 5.5 Apply nonpreemptive critical section protocol to the schedule in Figure 5.4.
Figure 5.6 Schedule of tasks in Example 5.4.
Figure 5.7 Schedule of tasks listed in Table 5.2.
Figure 5.8 A higher priority task is blocked by a lower priority task for at most once.
Figure 5.9 A higher priority task is blocked by multiple lower priority tasks.
Figure 5.10 Schedule of tasks in Table 5.3.
Figure 5.11 The priority ceiling protocol avoids deadlock.
Figure 5.12 The priority ceiling protocol avoids chained blocking.
Figure 5.13 Runtime stacks of tasks. (a) No stack sharing. (b) Stack sharing.
Figure 5.14 Stack-sharing schedule of tasks in Table 5.3.
Chapter 6: Concurrent Programming
Figure 6.1 Pthreads creation and termination.
Figure 6.2 Output of the program listed in Figure 6.1.
Figure 6.3 Use of mutex objects.
Figure 6.4 Execution of the program listed in Figure 6.3.
Figure 6.5 Solving the producer–consumer problem with condition variables.
Figure 6.6 Execution of the program listed in Figure 6.5.
Figure 6.7 Solving the readers–writers problem with semaphores.
Figure 6.8 A snapshot of the output of the program listed in Figure 6.7.
Figure 6.9 Sending messages to a message queue.
Figure 6.10 Receiving messages from a message.
Figure 6.11 Execution of programs listed in Figure 6.9 and 6.10.
Figure 6.12 Writing to a shared memory region.
Figure 6.13 Reading from a shared memory region.
Figure 6.14 Execution of programs listed in Figure 6.12 and 6.13.
Figure 6.15 Writing to a shared memory region with semaphore control.
Figure 6.16 Handling signals generated from key strokes of CTRL-C and CTRL-Z.
Figure 6.17 A screenshot of executing the program listed in Figure 6.16.
Figure 6.18 Implementing a periodic task.
Figure 6.19 A screenshot of the output of the program listed in Figure 6.17.
Chapter 7: Finite-State Machines
Figure 7.1 Finite-state machine of a light.
Figure 7.2 Graphic representations of (a) initial states and (b) final states.
Figure 7.3 Finite-state machine of a safe.
Figure 7.4 An acceptor for password pw123.
Figure 7.5 Moore machines: outputs depend solely on current states.
Figure 7.6 Moore machine state diagram of a vending machine.
Figure 7.7 Mealy machines: outputs depend on both inputs and current states.
Figure 7.8 Mealy machine state diagram of the vending machine.
Figure 7.9 Mealy machine diagram of a seat belt system.
Figure 7.10 A simple NDFA.
Figure 7.11 Code segment of the finite-state machine of Example 7.2.
Figure 7.12 Two three-state Mealy machines.
Figure 7.13 Keypad of a digital combination lock.
Figure 7.14 Keypad of a binary digital combination lock.
Chapter 8: UML State Machines
Figure 8.1 Representations of a state.
Figure 8.2 Initial state marker and end state marker.
Figure 8.3 UML state machine for a landline telephone.
Figure 8.4 A simple state with entry, do, and exit behaviors specified.
Figure 8.5 A transition.
Figure 8.6 A simplified UML state machine for an oven.
Figure 8.7 Change event and time event with a printer.
Figure 8.8 Partial representation of the
Active
composite state.
Figure 8.9 Decomposition of the
Connecting
state shown in Figure 8.8.
Figure 8.10 Composite state
Connecting
with decomposition hidden.
Figure 8.11 UML state machine of a soda machine.
Figure 8.12 Orthogonal composite state
Dispensing
.
Figure 8.13 Shallow history pseudostate and deep history pseudostate.
Figure 8.14 UML state machine of a CD player. (a) High-level state machine. (b) Composite state
Playing
.
Figure 8.15 A simple state machine for data processing.
Figure 8.16 Fork and join pseudostates. (a) Fork splits a transition. (b) Join merges transitions.
Figure 8.17 CD player state machine with a terminate pseudostate.
Figure 8.18 Components of ABS.
Figure 8.19 Wheel speed sensor state machine.
Figure 8.20 Valve state machine.
Figure 8.21 Pump state machine.
Figure 8.22 ECU state machine.
Figure 8.23 Composite state
Computing
.
Figure 8.24 Composite state
Proprocessing
.
Figure 8.25 A state machine for Problem 1.
Chapter 9: Timed Petri Nets
Figure 9.1 A simple Petri net.
Figure 9.2 Firing of transition
t
1
.
Figure 9.3 Two sequential transitions.
Figure 9.4 Transitions
t
2
and
t
3
are in conflict.
Figure 9.5 Transitions
t
2
and
t
3
are concurrent. Transition
t
4
synchronizes two sequences.
Figure 9.6 Mutual exclusion.
Figure 9.7 Transition
t
2
has priority over
t
4
.
Figure 9.8 A writing–reading system. (a) The mailbox is unbounded. (b) The mailbox can hold up to three mails.
Figure 9.9 A Petri net with
ω
markings.
Figure 9.10 Reachability tree and reachability graph of the Petri net shown in Figure 9.1. (a) Reachability tree. (b) Reachability graph.
Figure 9.11 Coverability graph. (a) A Petri net. (b) Coverability graph.
Figure 9.12 A Petri net with one minimal
T
-invariant.
Figure 9.13 A Petri net with two minimal
T
-invariants.
Figure 9.14 A deterministic timed Petri net.
Figure 9.15 Timed Petri net model of two periodic tasks scheduled on one processor. First attempt.
Figure 9.16 Timed Petri net model of two periodic tasks scheduled on one processor. Second attempt.
Figure 9.17 Timed Petri net model of two periodic tasks scheduled on one processor. m: maximum number of tokens in place
Count
while place
T2 in execution
is marked.
Figure 9.18 Petri net model of a communication protocol.
Figure 9.19 A TPN.
Figure 9.20 A time Petri net.
Figure 9.21 Three Petri nets with regular markings only.
Figure 9.22 Three Petri nets with
ω
markings.
Figure 9.23 Five dining philosophers.
Figure 9.24 Ferryman crosses river (incomplete).
Figure 9.25 Four Petri nets for Problem 7.
Figure 9.26 Petri net for Problem 8.
Figure 9.27 Petri net for Problem 9.
Figure 9.28 A deterministic timed Petri net.
Chapter 10: Model Checking
Figure 10.1 Model checking.
Figure 10.2 Modeling of time. (a) Linear-time model. (b) Branching-time model.
Figure 10.3 Parse tree of formula ¬
p
∧ (
G
q
∨ ¬
q
)
→ p
U
q
.
Figure 10.4 Illustration of semantics of LTL temporal operators.
Figure 10.5 Directed graph of a transition system.
Figure 10.6 Computation paths of the system shown in Figure 10.5.
Figure 10.7 CTL operators. P: path quantifiers; T: temporal operators.
Figure 10.8 Illustration of semantics of AX and EX.
Figure 10.11 Illustration of semantics of AU and EU.
Figure 10.12 A single-module SMV program.
Figure 10.13 The transition system corresponding to the SMV program in Figure 10.12.
Figure 10.14 SMV program of a three-bit counter.
Figure 10.15 SMV program of an inverter ring.
Figure 10.16 SMV program of the ferryman puzzle.
Figure 10.17 The state transition model for Problems 7 and 8.
Figure 10.18 The state transition model for Problem 9.
Figure 10.19 SMV program of mutual exclusion.
Figure 10.20 State transition system of a microwave oven.
List of Tables
Chapter 4: Task Scheduling
Table 4.1 The schedule Table for the first schedule shown in Figure 4.4
Table 4.2 The schedule Table for the schedule shown in Figure 4.7
Table 4.3 The aperiodic tasks in Example 4.12
Table 4.4 A set of periodic and preempTable tasks
Table 4.5 Task assignment by the first-fit algorithm
Table 4.6 Task assignment by RMFF
Chapter 5: Resource Sharing and Access Control
Table 5.1 Tasks in Example 5.4
Table 5.2 Tasks in Example 5.5
Table 5.3 Tasks in Example 5.6
Table 5.4 Worst-case blocking times of tasks in Example 5.8
Chapter 6: Concurrent Programming
Table 6.1 Pthread attributes
Table 6.2 Operations on a semaphore initialized to 1
Chapter 7: Finite-State Machines
Table 7.1 State transitions of FSM shown in Figure 7.2
Table 7.2 Moore machine states of Example 7.4
Table 7.3 State transition Table of the Mealy machine shown in Figure 7.9
Table 7.4 The state transition Table for Problem 7.3.
Table 7.5 The state transition Table for Problem 7.5.
Table 7.6 The state transition Table for Problem 7.6.
Chapter 8: UML State Machines
Table 8.1 Power modes of a projector.
Chapter 9: Timed Petri Nets
Table 9.1 Legend for Figure 9.18
Chapter 10: Model Checking
Table 10.1 Truth Table for propositional logic operators
Table 10.2 First two state transitions of the program listed in Figure 10.14
Quantitative Software Engineering Series
Lawrence Bernstein, Series Editor
The Quantitative Software Engineering Series focuses on the convergence of systems engineering and software engineering with emphasis on quantitative engineering trade-off analysis. Each title brings the principles and theory of programming in the large and industrial strength software into focus. This practical series helps software developers, software engineers, systems engineers, and graduate students understand and benefit from this convergence through the unique weaving of software engineering case histories, quantitative analysis, and technology into the project effort. You will find that each publication reinforces the series goal of assisting the reader with producing useful, well-engineered software systems.
Software Testing: Concepts and Operations by Ali Mili, Fairouz Tchier
Enterprise Software Architecture and Design: Entities, Services, and Resources by Dominic Duggan
Oracle Database Performance and Scalability: A Quantitative Approach by Henry H. Liu
Trustworthy Compilers by Vladimir O. Safonov
Managing the Development of Software-Intensive Systems by James McDonald
Software Performance and Scalability: A Quantitative Approach by Henry H. Liu
Web Application Design and Implementation: Apache 2, PHP5, MySQL, JavaScript, and Linux/UNIX by Steven A. Gabarro
Software Measurement and Estimation: A Practical Approach by Linda M. Laird, M. Carol Brennan
Trustworthy Systems through Quantitative Software Engineering by Lawrence Bernstein, C. M. Yuhas
Real-Time Embedded Systems by Jiacun Wang
Real-Time Embedded Systems
Jiacun Wang
This edition first published 2017
© 2017 John Wiley & Sons, Inc.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by law. Advice on how to obtain permission to reuse material from this title is available at http://www.wiley.com/go/permissions.
The right of Jiacun Wang to be identified as the author of this work has been asserted in accordance with law.
Registered Office
John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USA
Editorial Office
111 River Street, Hoboken, NJ 07030, USA
For details of our global editorial offices, customer services, and more information about Wiley products visit us at www.wiley.com.
Wiley also publishes its books in a variety of electronic formats and by print-on-demand. Some content that appears in standard print versions of this book may not be available in other formats.
Limit of Liability/Disclaimer of Warranty
The publisher and the authors make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties; including without limitation any implied warranties of fitness for a particular purpose. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for every situation. In view of on-going research, equipment modifications, changes in governmental regulations, and the constant flow of information relating to the use of experimental reagents, equipment, and devices, the reader is urged to review and evaluate the information provided in the package insert or instructions for each chemical, piece of equipment, reagent, or device for, among other things, any changes in the instructions or indication of usage and for added warnings and precautions. The fact that an organization or website is referred to in this work as a citation and/or potential source of further information does not mean that the author or the publisher endorses the information the organization or website may provide or recommendations it may make. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this works was written and when it is read. No warranty may be created or extended by any promotional statements for this work. Neither the publisher nor the author shall be liable for any damages arising here from.
Library of Congress Cataloging-in-Publication Data
Names: Wang, Jiacun, 1963- author.
Title: Real-time embedded systems / by Jiacun Wang.
Description: Hoboken, NJ, USA : Wiley, 2017. | Series: Quantitative software engineering series | Includes bibliographical references and index. | Identifiers: LCCN 2017015038 (print) | LCCN 2017030269 (ebook) | ISBN 9781119420705 (pdf) | ISBN 9781119420682 (epub) | ISBN 9781118116173 (hardback)
Subjects: LCSH: Embedded computer systems. | Real-time data processing. | BISAC: TECHNOLOGY & ENGINEERING / Electronics / Microelectronics.
Classification: LCC TK7895.E42 (ebook) | LCC TK7895.E42 W36 2017 (print) | DDC 006.2/2-dc23
LC record available at https://lccn.loc.gov/2017015038
Cover image: © spainter\_vfx/Gettyimages
Cover design by Wiley
Preface
Real-time embedded systems play a significant role in our daily life. These systems are inside our cars, cell phones, and home electrical appliances. Industrial process control, telecommunication, signal processing, vehicle navigation, air traffic control, and space exploration all depend on real-time embedded system technologies. The real-time embedded application market has been further driven to a new high by recent advances in the information and communication technology and by the emergence of Internet of things, ubiquitous computing, and pervasive computing. Therefore, there is an increasing demand from the related branches of industry for computer scientists and software engineers who are particularly capable of real-time embedded system hardware and software design and development. This textbook aims to prepare students with the fundamental knowledge and skills that are needed to meet the challenges.
This book introduces the characteristics of real-time embedded systems, typical embedded hardware components, fundamental real-time operating system features, well-known real-time task scheduling algorithms, and widely used resource access control protocols. It also presents several formal approaches for real-time embedded system design, modeling, analysis and critical property verification. For those who are interested in real-time software development, the text will familiarize them with techniques and skills in concurrent programming and real-time task implementation.
Monmouth University West Long Branch, NJ January 15, 2017
Book Layout
This book has four parts. Part 1 includes Chapters 1–3, which introduces the fundamental concepts and characteristics of real-time embedded systems, embedded system hardware basics, general operating systems, and real-time operating systems. The automobile antilock braking system is used as an example to show the components and characteristics of real-world real-time embedded systems.
Part 2 includes Chapters 4–6, focusing on real-time system scheduling, task assignment, resource access control, and real-time embedded system programming. Clock-driven and priority-driven scheduling algorithms, as well as several task assignment algorithms, are discussed in Chapter 4. Resource sharing issues and some well-known resource access control protocols that tackle the priority inversion and deadlock problems are presented in Chapter 5. Real-time task implementation, intertask synchronization and communication, and concurrent programming details are discussed in Chapter 6.
Part 3 is composed of Chapters 7–10, which introduces various modeling and analysis techniques for real-time embedded systems. Among them, finite-state machines are a traditional model of computation good for logic circuits and software design and are introduced in Chapter 7. UML state machines are an extension to traditional finite-state machines with hierarchy and orthogonality and composed of a rich set of graphical notations. They are introduced in Chapter 8. Petri nets are a high-level model, which is very powerful for event-driven system modeling and analysis. Timed Petri nets allow users to verify systems' timing constraints. The theory and applications of Petri nets and timed Petri nets are presented in Chapter 9. Model checking is a technique that verifies system properties against a model using a software tool. Model checking principles, the NuSMV model checker, and its underlying temporal logic and description language are introduced in Chapter 10.
Chapter 11 alone is the final part of the book, which briefly discusses some practical issues with real-time embedded system design and development, including software reliability, aging, security, safety, and power consumption.
Audience
This book is primarily written as a textbook for undergraduate or graduate courses in computer engineering, software engineering, computer science, and information technology programs in the subject of embedded and real-time systems. For students with certain level of familiarity with computer programming, operating systems, and computer architecture, the book will extend their knowledge and skills into the area of real-time embedded computing that has profound influence on the quality of our daily life.
Portions of the book could be used as reading material for undergraduate computer engineering, computer science, and software engineering capstone courses or as a reference for students who are doing research in the area of real-time embedded systems.
The book is also useful to industrial practitioners with real-time and embedded software design and development responsibilities.
Acknowledgments
This project was partially supported by Mexico's CONACYT program “Estancias Sabáticas en México para Extranjeros para la Consolidación de Investigación.” Chapter 9 was written by Dr Xiaoou Li, Professor of CINVESTAV-IPN, Mexico. In writing the book, I received constant help from my colleague and friend over a decade, Dr William Tepfenhart, Professor of Monmouth University. I discussed the contents of Chapters 6–8 intensively with him, and his insights into the subjects greatly influenced the writing of the three chapters. Dr Xuemin Chen, Professor of Texas Southern University, reviewed the book proposal and offered good suggestions on the layout of the book and contents of the first two chapters. Professor Lijun Chen, Xi'an University of Posts and Telecommunication, reviewed the draft of Chapter 6 and provided her constructive comments. Mr Bin Hu, a master's degree student of Monmouth University, tested most of the programming projects included in the book. I thank all of them for their generous help.
Chapter 1Introduction to Real-Time Embedded Systems
Real-time embedded systems have become pervasive. They are in your cars, cell phones, Personal Digital Assistants (PDAs), watches, televisions, and home electrical appliances. There are also larger and more complex real-time embedded systems, such as air-traffic control systems, industrial process control systems, networked multimedia systems, and real-time database applications. It is reported that in the Lexus LS-460 released in September 2006, there are more than 100 microprocessors embedded when all optional features are installed. It is also estimated that 98% of all microprocessors are manufactured as components of embedded systems. In fact, our daily life has become more and more dependent on real-time embedded applications. This chapter explains the concepts of embedded systems and real-time systems, introduces the fundamental characteristics of real-time embedded systems, and defines hard and soft real-time systems. The automotive antilock braking system (ABS) is used as an example to show a real-world embedded system.
1.1 Real-Time Embedded Systems
An embedded system is a microcomputer system embedded in a larger system and designed for one or two dedicated services. It is embedded as part of a complete device that often has hardware and mechanical parts. Examples include the controllers built inside our home electrical appliances. Most embedded systems have real-time computing constraints. Therefore, they are also called real-time embedded systems. Compared with general-purpose computing systems that have multiple functionalities, embedded systems are often dedicated to specific tasks. For example, the embedded airbag control system is only responsible for detecting collision and inflating the airbag when necessary, and the embedded controller in an air conditioner is only responsible for monitoring and regulating the temperature of a room.
Another noteworthy difference between a general-purpose computing system and an embedded system is that a general-purpose system has full-scale operating system support, while embedded systems may or may not have operating system support at all. Many small-sized embedded systems are designed to perform simple tasks and thus do not need operating system support.
Embedded systems are reactive systems in nature. They are basically designed to regulate a physical variable in response to the input signal provided by the end users or sensors, which are connected to the input ports. For example, the goal of a grain-roasting embedded system is regulating the temperature of a furnace by adjusting the amount of fuel being injected into the furnace. The regulation or control is performed based on the difference between the desired temperature and the real temperature detected by temperature sensors.
Embedded systems can be classified based on their complexity and performance into small-scale, medium-scale, and large-scale. Small-scale systems perform simple functions and are usually built around low-end 8- or 16-bit microprocessors or microcontrollers. For developing embedded software for small-scale embedded systems, the main programming tools are an editor, assembler, cross-assembler, and integrated development environment (IDE). Examples of small-scale embedded systems are mouse and TV remote control. They typically operate on battery. Normally, no operating system is found in such systems.
Medium-scale systems have both hardware and software complexities. They use 16- or 32-bit microprocessors or microcontrollers. For developing embedded software for medium-scale embedded systems, the main programming tools are C, C++, JAVA, Visual C++, debugger, source-code engineering tool, simulator, and IDE. They typically have operating system support. Examples of medium-scale embedded systems are vending machines and washing machines.
Large-scale or sophisticated embedded systems have enormous hardware and software complexities, which are built around 32- or 64-bit microprocessors or microcontrollers, along with a range of other high-speed integrated circuits. They are used for cutting-edge applications that need hardware and software codesign techniques. Examples of large-scale embedded systems are flight-landing gear systems, car braking systems, and military applications.
Embedded systems can be non-real-time or real-time. For a non-real-time system, we say that it is correctly designed and developed if it delivers the desired functions upon receiving external stimuli or internal triggers, with a satisfied degree of QoS (Quality of Service). Examples are TV remote controls and calculators.
Real-time systems, however, are required to compute and deliver correct results within a specified period of time. In other words, a job of a real-time system has a deadline, being it hard or soft. If a hard deadline is missed, then the result is useless, even if it is correct. Consider the airbag control system in automobiles. Airbags are generally designed to inflate in the cases of frontal impacts in automobiles. Because vehicles change speed so quickly in a crash, airbags must inflate rapidly to reduce the risk of the occupant hitting the vehicle's interior. Normally, from the onset of the crash, the entire deployment and inflation process is about 0.04 seconds, while the limit is 0.1 seconds.
Non-real-time embedded systems may have time constraints as well. Imagining if it takes more than 5 seconds for your TV remote control to send a control signal to your TV and then the embedded device inside the TV takes another 5 seconds to change the channel for you, you will certainly complain. It is reasonable that consumers expect a TV to respond to remote control event within 1 second. However, this kind of constraints is only a measure of system performance.
Traditional application domains of real-time embedded systems include automotive, avionics, industrial process control, digital signal processing, multimedia, and real-time databases. However, with the continuing rapid advance in information and communication technology and the emergence of Internet of things and pervasive computing, real-time embedded applications will be found in any objects that can be made smart.
1.2 Example: Automobile Antilock Braking System
A distinguished application area of real-time embedded systems is automobiles. Automotive embedded systems are designed and developed to control engine, automatic transmission, steering, brake, suspension, exhaustion, and so on. They are also used in body electronics, such as instrument panel, key, door, window, lighting, air bag, and seat bag. This section introduces the ABS.
An ABS is an automobile safety system. It is designed to prevent the wheels of a vehicle from locking when brake pedal pressure is applied, which may occur all of a sudden in case of emergency or short stopping distance. A sudden lock of wheels will cause moving vehicles to lose tractive contact with the road surface and skid uncontrollably. For this reason, ABS also stands for antiskid braking system. The main benefit from ABS operation is retaining the directional control of the vehicle during heavy braking in rare circumstances.
1.2.1 Slip Rate and Brake Force
When the brake pedal is depressed during driving, the wheel velocity (the tangential speed of the tire surface) decreases, and so does the vehicle velocity. The decrease in the vehicle velocity, however, is not always synchronized with the wheel velocity. When the maximum friction between a tire and the road surface is reached, further increase in brake pressure will not increase the braking force, which is the product of the weight of the vehicle and the friction coefficient. As a consequence, the vehicle velocity is greater than the wheel speed, and the wheel starts to skid. The wheel slip rate, s, is defined as
where V, ω, and R denote the vehicle speed, wheel angular velocity, and wheel rolling radius, respectively. Under normal driving conditions, V = ωR and thus, s = 0. During severe braking, it is common to have ω = 0 and V > 0, which translates to s = 1, a case of wheel lockup.
Figure 1.1 describes the relationship among the slip rate, braking force, and cornering force. The continuous line in the figure represents the relationship between the slip rate and braking force. It shows that the braking force is the largest when the slip rate is between 10% and 20%. The braking distance is the shortest at this rate. With further increase in slip rate, the braking force is decreased, which results in a longer braking distance. The dashed line depicts the relationship between the slip rate and cornering force. The cornering force is generated by a vehicle tire during cornering. It works on the front wheels as steering force and on the rear wheels to keep the vehicle stable. It decreases as the slip rate increases. In case of a lockup, the cornering force becomes 0 and steering is disabled.
Figure 1.1 Relationship among the slip rate, braking force, and cornering force.
1.2.2 ABS Components
The ABS is composed of four components. They are speed sensors, valves, pumps, and an electrical control unit (ECU). Valves and pumps are often housed in hydraulic control units (HCUs).
1.2.2.1 Sensors
There are multiple types of sensors used in the ABS. A wheel speed sensor is a sender device used for reading a vehicle's wheel rotation rate. It is an electromagnet illustrated in Figure 1.2. As the sensor rotor rotates, it induces AC voltage in the coil of the electromagnet. When the rotation of the sensor rotor increases, the magnitude and frequency of induced voltage increase as well.
Figure 1.2 Wheel speed sensor.
A deceleration sensor measures the vehicle's rate of deceleration. It is a switch type of sensor. It uses phototransistors that can be activated by light. In a deceleration sensor, two Light-Emitting Diode (LEDs) aim at two phototransistors that are separated by a slit plate. When the vehicle's rate of deceleration changes, the slit plate swings in the vehicle's rear-to-front direction. The slits in the slit plate act to expose the light from the LEDs to the phototransistors. This movement of the slit plate switches the phototransistors ON and OFF. The combinations formed by the two phototransistors switching ON and OFF distinguish the rate of deceleration into four levels, which are sent as signals to the ABS ECU.
A steering angle sensor (SAS) measures the steering wheel position angle and rate of turn. The SAS is located in a sensor cluster in the steering column. The cluster always has more than one steering position sensor for redundancy and to confirm data. The ECU module must receive two signals to confirm the steering wheel position. These signals are often out of phase with each other. The SAS tells the ABS control module where the driver is steering the vehicle while the body motion sensors tell it how the body is responding.
A yaw-rate sensor is a gyroscopic device that measures a vehicle's angular velocity around its vertical axis. The angle between the vehicle's heading and vehicle actual movement direction is called slip angle, which is related to the yaw rate.
A brake pressure sensor captures the dynamic pressure distribution between a brake pad and the rotor surfaces during actual braking.
1.2.2.2 Valves and Pumps
Auto brakes typically work with hydraulic fluid. The brake's master cylinder supplies fluid pressure when the pedal is applied. In a standard ABS system, the HCU houses electrically operated hydraulic control solenoid valves that control the brake pressure to specific wheel brake circuits. A solenoid valve is a plunger valve that is opened and closed electrically. When power is applied to the solenoid, a magnetic coil is energized, which moves the plunger.
There are multiple hydraulic circuits within the HCU, and each hydraulic circuit controls a pair of solenoid valves: an isolation valve and a dump valve. The valves have three operation modes: apply, hold, and release. In the apply mode, both valves are open and allow the brake fluid to freely flow through the HCU control circuit to the specific brake circuit, as illustrated in Figure 1.3. In this mode, the driver is in full control of the brakes through the master cylinder.
Figure 1.3 Valves operate in the apply mode.
In the hold mode, both valves are in the closed position that isolates the master cylinder from the brake circuit. This prevents the brake pressure from increasing any further should the driver push the brake pedal harder. The brake pressure to the wheel is held at that level until the solenoid valves are commanded to change its position. This is illustrated in Figure 1.4.
Figure 1.4 Valves operate in the hold mode.
In the release mode, the isolation solenoid valve is closed, but the dump valve is open to release some of the pressure from the brake, allowing the wheel to start rolling again. The dump valve opens a passage back to the accumulator where the brake fluid is stored until it can be returned by an electric pump to the master-cylinder reservoir. This is illustrated in Figure 1.5.
Figure 1.5 Valves operate in the release mode.
The pump is the heart of the ABS. Antilock brakes wouldn't exist without the hydraulic ABS pump. At the detection of wheel slip under heavy breaking, the pump in the HCU sends the brake fluid back to the master cylinder, pushing one or both pistons rearward in the bore. The controller modulates the pump's status in order to provide the desired amount of pressure and reduce slipping.
All valves are open during normal braking. When a wheel locks up, the braking pressure supplied to it should be reduced until it returns to spin. The ABS hydraulic unit works by closing the solenoid valve leading to the wheel that is locking up, thereby reducing the brake force the wheel receives. This way, the wheel's deceleration rate slows down to a safe level. Once that level is achieved, the solenoid opens again to perform its normal function.
1.2.2.3 Electrical Control Unit
The ECU is the brain of the ABS. It is a computer in the car. It watches all the sensors connected to it and controls the valves and pumps, as shown in Figure 1.6. Simply put, if the ABS sensors placed at each wheel detect a lockup, ABS intervenes within milliseconds by modulating the braking pressure at each individual wheel. In this way, the ABS prevents the wheels from locking up during braking, thus ensuring steerability and stability combined with the shortest possible braking distance.
Figure 1.6 Electrical control unit.
The ECU periodically polls the sensor readings all the time and determines whether any unusual deceleration in the wheels occurs. Normally, it will take a car 5 seconds to stop from 60 mph under ideal conditions, but when there is a wheel lockup, the car could stop spinning in less than 1 second. Therefore, a rapid deceleration in the wheels is a strong indication that a lockup is occurring. When the ECU detects a rapid deceleration, it sends a control signal to the HCU to reduce the pressure to the brakes. When it senses the wheels accelerate, then it increases the pressure until it senses the deceleration again. The deceleration–acceleration repetition occurs very quickly, with the rapid opening and closing of the valves, until the tires slow down at the same rate as the car. Some ABS systems can cycle up to 16 times per second.
1.2.3 ABS Control
ABS brake controllers pose unique challenges to the designers. The main difficulties in the design of any ABS controller arise from the strong nonlinearity and uncertainty of the system to be controlled. First of all, the interaction between the tire and the road surface is very complex and hardly understood. Existing friction models are mostly experimental-based approximations of highly nonlinear phenomena. The dynamics of the whole vehicle is also nonlinear, and it even varies over time. In addition, ABS actuators are discrete, and control precision must be achieved with only three types of control commands: build pressure, hold pressure, or reduce pressure (recall the three operation modes of solenoid valves).
Many different control methods have been developed for ABS. Research on improved control methods is still continuing. The method applied in early systems is threshold control, which is as simple as bang–bang control. It uses wheel acceleration and wheel slip as controlled variables. Once the calculated wheel deceleration or wheel slip is over one of the threshold values, the brake pressure is commanded to increase, hold constant, or decrease. Since the brake pressure is cyclically changed based solely on the binary states of the input variables, wheel speed oscillations over time are less controllable.
A class of more advanced control methods uses a cascade closed-loop control structure shown in Figure 1.7. The outer loop, which includes the vehicle velocity estimation (Vv) and desired slip calculation, provides the command signal (Vwd) for the inner wheel velocity loop. For inner-loop control, several mechanisms have been proposed. The PID controller, for example, is one of such mechanisms. PID stands for proportional–integral–derivative. PID controllers adopt feedback control law and are widely used in industrial control systems. A PID controller continuously calculates an error value as the difference between a desired set point and a measured process variable. It is an integration of three control policies. With the proportional control (P), the controller output is proportional to the error, which in our case is Vwd. With the integral control (I), the controller output is proportional to the amount of time the error is present, which eventually leads to a zero error. With the derivative control (D), the controller output is proportional to the rate of change of the error, which reduces the response time. It has been shown that even for complex and changing surface types, good results can be attained with the conventional PID control algorithms. In the recent years, the well-known features of the conventional PID have been combined with the robustness, self-tuning, or adaptability to nonlinear models of other control methods, which highly enhanced the ABS performance.
Figure 1.7 A Cascade control structure for ABS.
No matter what control law is adopted, the feedback control loop can be implemented as an infinite periodic loop:
set timer to interrupt periodically with period T; DO FOREVER wait for interrupt; read sensor data; compute control value u; output u; ENDDO;
Here, the period T is a constant in most applications. It is an important engineering parameter. If T is too large, then the control variables will not get adjusted quickly; if it is small, then it will result in excessive computation.
1.3 Real-Time Embedded System Characteristics
The ABS example should have given us some idea about what a real-time embedded system looks like and how it interacts with the larger system it resides in to fulfill the specified function. This section discusses the characteristics of general real-time embedded systems.
1.3.1 System Structure
A real-time embedded system interacts with its environment continuously and timely. To retrieve data from its environment – the target that it controls or monitors, the system must have sensors in place. For example, the ABS has several types of sensors, including wheel speed sensors, deceleration sensors, and brake pressure sensors. In the real world, on the other hand, most of the data is characterized by analog signals. In order to manipulate the data using a microprocessor, the analog data needs to be converted to digital signals, so that the microprocessor will be able to read, understand, and manipulate the data. Therefore, an analog-to-digit converter (ADC) is needed in between a sensor and a microprocessor.
The brain of an embedded system is a controller, which is an embedded computer composed of one or more microprocessors, memory, some peripherals, and a real-time software application. The software is usually composed of a set of real-time tasks that run concurrently, may or may not be with the support of a real-time operating system, depending on the complexity of the embedded system.
The controller acts upon the target system through actuators. An actuator can be hydraulic, electric, thermal, magnetic, or mechanic. In the case of ABS, the actuator is the HCU that contains valves and pumps. The output that the microprocessor delivers is a digit signal, while the actuator is a physical device and can only act on analog input. Therefore, a digit-to-analog conversion (DAC) needs to be performed in order to apply the microprocessor output to the actuator. Figure 1.8 shows the relations among all these system components.
Figure 1.8 Structure of real-time embedded systems.
1.3.2 Real-Time Response
A real-time system or application has to finish certain tasks within specified time boundaries. This is the character that distinguishes a real-time system from a non-real-time system. The ABS is a typical real-time system. When the sensors detect a dramatic deceleration of wheels, the system must act quickly to prevent the wheels from being locked up; otherwise, a disaster may occur. Moreover, the control law computing is also real-time: a cycle of a sensor data processing and control value computing must be finished before the next cycle starts; otherwise, the data to be processed will pile up. If a missile guidance system fails to make timely corrections to its attitude, it can hit the wrong target. If a GPS satellite doesn't keep a highly precise measure of time, position calculations based on its signal will simply be wrong.
Deadlines of real-time tasks are typically derived from the required responsiveness of the sensors, actuators, and the dynamics of the target that the embedded system controls. Real-time systems are expected to execute all tasks by their deadlines. However, “real-time” does not mean “real fast” or “the faster, the better.” Take a cardiac pacemaker as an example. Obviously, if it fails to induce current through the heart muscle at the right time, the patient's heart can go into fibrillation. However, if it induces current faster than normal heart rhythm, it will cause problem as well.
1.3.3 Highly Constrained Environments
Real-time embedded systems are often run in highly resource-constrained environments, which make the system design and performance optimization quite challenging. Although some embedded systems, such as air-traffic control systems and wireless mobile communication systems, run with very powerful processors, a lot of them are equipped with 8-bit processors only. Examples are the systems embedded in dishwashers, microwaves, coffee makers, and digital watches. Most embedded systems are constrained in terms of processor speed, memory capacity, and user interface. Many embedded systems operate in an uncontrolled harsh environment. They have to survive excessive heat, moisture, vibration, shock, or even corrosion. The ABS and automotive embedded systems that control ignition, combustion, and suspension are such examples. Therefore, embedded systems must be optimized in terms of size, weight, reliability, performance, cost, and power consumption to fit into the computing environment and perform their tasks. Thus, embedded systems typically require far more optimization than standard desktop applications.
1.3.4 Concurrency
Concurrency refers to a property of systems in which several computations are executing simultaneously and potentially interacting with each other. Embedded systems by design are closely interacting with their physical environment. We have demonstrated this feature through the ABS analysis. Physical environment is by its nature concurrent – multiple processes occur at the same time. For example, the following events in the ABS can occur at the same time:
Wheel speed sensor event
Deceleration sensor event
Brake pedal event
Solenoid valve movement
Pump operation
Almost all of these events have strict constraints on the response time. All deadlines should be met.
Because of the existence of multiple control processes and each process may have its own control rate, many real-time embedded systems are multirate systems. For example, a real-time surveillance system needs to process both audio and video inputs, but they are processed at different rates.
1.3.5 Predictability
A real-time system must behave in a way that can be predicted in terms of all timing requirements. For instance, it must be mathematically predictable if a specific task can be completed before a given deadline. Factors that go into this calculation are system workload, the power of processors, run-time operating system support, process and thread priorities, scheduling algorithm, communication infrastructure, and so on. A real-time system such as an ABS, or an airplane's flight-control system, must always be 100% predictable, or human lives are at stake.
Many real-time embedded systems contain heterogeneous computing resources, memories, bus systems, and operating systems and involve distributed computing via global communication systems. Latency and jitter in events are inevitable in these systems. Therefore, related constraints should be specified and enforced. Otherwise, these systems can become unpredictable.
A term related to predictability is determinism. Determinism represents the ability to ensure the execution of an application without concern that outside factors, such as unforeseen events, will upset the execution in unpredictable ways. In other words, the application will behave as intended in terms of functionality, performance, and response time, all of the time without question.
1.3.6 Safety and Reliability
Some real-time embedded systems are safety-critical and must have high reliability. Examples are cardiac pacemakers and flight control systems. The term safety means “freedom from accidents or losses” and is usually concerned with safety in the absence of faults as well as in the presence of single-point faults. Reliability, on the other hand, refers to the ability of a system or component to perform its required functions under stated conditions for a specified time. It is defined as a stochastic measure of the percentage of the time the system delivers services. Embedded systems often reside in machines that are expected to run continuously for years without errors. Some systems, such as space systems and undersea cables, are even inaccessible for repair. Therefore, embedded system hardware and software are usually developed and tested more carefully than those for general-purpose computing systems.
Reliability is often measured in failures per million operating hours. For example, the requirement for a typical automotive microcontroller is 0.12 failures per million operating hours. The measurement is 37.3 for an automotive oil pump. Failures could be caused by mechanical “wear-out,” software defects, or accumulated run-time faults.
1.4 Hard and Soft Real-Time Embedded Systems
There are hard real-time systems and soft real-time systems. A hard real-time system is a system in which most timing constraints are hard. A soft real-time system is a system in which most timing constraints are soft.
A hard real-time constraint is a constraint that a system must meet. If the deadline is missed, it will either cause the system failure or result in a zero usefulness of the delivered service. On the other hand, a soft constraint is a constraint that a system should meet, but when the deadline is occasionally missed, it won't cause any disastrous result, and the delivered service is still useful to a certain extent.
Normally, a hard constraint is expressed deterministically. For example, we may have the following constraints for the ABS:
The wheel speed sensors must be polled every 15 milliseconds.
Each cycle, the control law computation for wheel speed must be finished in 20 milliseconds.
Each cycle, the wheel speed prediction must be completed in 10 milliseconds.
These constraints are hard because the sensor data, control value, and wheel speed predicted value are all critical to the correct functioning of the ABS. It is also because these events are periodical. If the deadline of one cycle is missed, the next cycle starts immediately, and thus, the late result becomes useless.
Soft constraints are often expressed statistically. For example, we may have the following constraints for an automated teller machine (ATM):
After a credit card or debit card is inserted, the probability that the ATM prompts the user to enter a passcode within 1 second should be no less than 95%.
After it receives a positive response from the bank that issued the card, the ATM should dispense the specified amount of cash within 3 seconds at a chance of no less than 90%.
The deadlines with these two constraints are soft, because a few misses of the deadlines do no cause serious harm; only the degree of customers' satisfaction of using the system is negatively affected.
Figure 1.9 illustrates the value function of a real-time task in terms of response time. If the task has a hard deadline, then its value drops to zero when the deadline is missed. If the task has a soft deadline, then its value decreases when the deadline is missed, but not to zero right way.
Figure 1.9 Value of hard and soft real-time tasks when deadline is missed.
Many hard real-time systems also have soft constraints and vice versa. When a timing constraint is specified as hard, then a rigorous validation is required.
Exercises
1 Give an example of real-time database application. Is it a hard or a soft real-time system? Give your arguments.
2 The car engine management system (EMS) is a real-time embedded system. Read related online materials, and find out major hardware components of the system and how they interact with each other to ensure the best engine performance.
3 Give an example of real-time embedded systems in which an earlier response than expected is as bad as a late response.
4 Give an example of a real-time embedded system that has both hard and soft real-time constraints.
Suggestions for Reading
Shin and Ramanathan [1] introduces the basic concepts and identifies the key issues in the design of real-time systems. Axer et al. [2] summarizes the current state of the art in research concerning how to build timing-predictable embedded systems. A survey of ABS control laws is presented in Ref. [3].
References
1 Shin, K. and Ramanathan, P. (1994) Real-time computing: a new discipline of computer science and engineering.
Proceedings of the IEEE
,
82
(1), 6–25.
2 Axer, P., Ernst, R., Falk, H.
et al
. (2012)
Building Timing Predictable Embedded Systems
,
ACM Transactions on Embedded Computing Systems
.
3 Aly, A., Zeidan, E., Hamed, A., and Salem, F. (2011) An antilock-braking systems (ABS) control: a technical review.
Intelligent Control and Automation
,
2
, 186–195.
Chapter 2Hardware Components
This chapter introduces real-time embedded system hardware components. Because real-time embedded systems range from small ones such as those in coffee makers and digital watches to big and sophisticated ones such as railroad control systems and mobile communication switches, there is a big difference in the set of hardware components used. Figure 2.1 shows a set of typical embedded system hardware units.
Figure 2.1 Real-time embedded system hardware components.
2.1 Processors
The processors used in embedded systems vary with the need of computation power of individual embedded application. They fall into two general categories, however. One is general-purpose microprocessors, and the other is special-purpose processors. Microcontrollers and application-specific integrated circuits (ASICs) are the most popular special-purpose processors.
2.1.1 Microprocessors
Many real-time embedded systems use general-purpose microprocessors. A microprocessor is a computer processor on an integrated circuit. It contains all, or most of, the central processing unit (CPU) functions. Figure 2.2 shows a set of elements that are necessary for microprocessors to perform operations.
Figure 2.2 Microprocessor elements.
A microprocessor is designed to perform arithmetic and logic operations that make use of small storage called registers. It has a control unit that is responsible for directing the processor to carry out stored program instructions. It communicates with both the arithmetic logic unit (ALU) and memory. All the instructions that are fetched from memory are stored in the instruction register as binary values. The instruction decoder reads that values and tells the ALU which computational circuits to energize in order to perform the function. The ALU performs integer arithmetic and bitwise logic operations. These operations are the result of instructions that are part of the microprocessor design. Program counter stores the address of the next instruction to be executed. Microprocessors operate on numbers and symbols represented in the binary numeral system.
