Elements of embedded systems

Embedded systems are everywhere. Almost any electrical device you interact with that is more complicated than a simple light switch contains a digital processor that reads input data from its environment, executes a computational algorithm, and generates some kind of output that interacts with the environment.

From the moment you open your eyes in the morning (in response to an alarm produced by a digital device), to brushing your teeth (with an electric toothbrush that contains a digital processor), to toasting a breakfast bagel (in a digitally controlled toaster oven), to disabling your (digital) home alarm system, you interact with embedded devices. Throughout the day, you provide input to, and receive output from, many other devices, such as television remote controls, traffic signals, and railroad crossings. Highly digitized transportation systems, including automobiles, airplanes, and passenger ferries, each contain dozens, if not hundreds, of embedded processors that manage drive train operation, oversee safety features, maintain a comfortable climate, and provide entertainment for the humans they carry.

Let's take a moment to clarify the sometimes-murky dividing line separating embedded systems from general-purpose computing devices. The attribute that defines an embedded computing system is the integration of digital processing within a device that has some larger purpose beyond mere computing. Devices that do not contain any type of digital processing are not embedded systems. For example, an electric toothbrush that contains only a battery and a motor controlled by an on-off switch is not an embedded system. A toothbrush containing a microcontroller that illuminates a red light when you press down too hard while brushing is an embedded system.

A desktop computer, even though it is capable of performing many tasks, and can be enhanced through the addition of a wide variety of peripherals, is just a computer. An automobile, on the other hand, has as its primary purpose the transportation of passengers. In performing this function, it relies on a variety of subsystems containing embedded processing. Automobiles are embedded systems. Personal computers are not.

A smartphone is more difficult to clearly categorize in terms of membership in the set of embedded systems. When in use as a telephone, it is clearly performing a function consistent with the definition of an embedded system. When using it as a web browser, though, it more closely resembles a small general-purpose computer. Clearly, it is not always possible to definitively determine whether a device is an embedded system.

It is helpful to understand differences in the operating environment of general-purpose computers in comparison to embedded devices. Personal computers and enterprise servers tend to work best in climate-controlled indoor settings. Embedded devices such as those in automobiles are often exposed to far more rugged conditions, including the full effects of rain, snow, wind, dust, and heat.

A large percentage of embedded devices lack any sort of active cooling system (which is standard in personal computers and server computers) and must ensure their internal components remain at safe operating temperatures regardless of external conditions.

Embedded systems, whether they are relatively simple devices or highly complex systems, are typically composed of the following elements.

Power source

All electronic digital devices require some a of power. Most commonly, embedded systems are powered by utility electrical power, batteries, or by the host system in which the device operates. For example, an automobile taillight assembly containing a processor and a CAN bus communication interface is powered by 12 volts Direct Current (DC) provided by the car's electrical system.

It is also possible to power embedded devices from rechargeable batteries connected to solar panels that allow the device to continue operation at nighttime and on cloudy days, or even by harvesting energy from the environment. A self-winding wristwatch uses energy harvested from arm motion to generate mechanical or electrical power. Safety- and security-critical embedded systems often use utility power as the primary power source while also providing batteries as backup power to enable operation during power outages.

Time base

Embedded systems generally require some means of tracking the progress of time, also known as wall clock time, both in the short term (for durations of microseconds and milliseconds) and in the long term, keeping track of the date and time of day. Most commonly, a primary system clock signal is generated using a crystal oscillator or a Microelectromechanical System (MEMS) oscillator that produces an output frequency of a few megahertz.

A crystal oscillator amplifies the resonant vibration of a physical crystal, typically made of quartz, to generate a square wave electrical signal using the piezoelectric effect. A MEMS oscillator contains a vibrating mechanical structure that produces an electrical output using electrostatic transduction.

Once set to the correct time, a clock driven by a crystal oscillator or a MEMS oscillator will exhibit small errors in frequency (typically 1-100 parts per million) that accumulate over periods of days and weeks to gradually drift by seconds and then minutes away from the correct time. To mitigate this problem, most internet-connected embedded devices periodically access a time server to reset their internal clocks to the current time.

Digital processing

Embedded computing systems, by definition, contain some form of digital processor. The processing function is generally provided by a microcontroller, a microprocessor, or a system on a chip (SoC). A microcontroller is a highly integrated device that contains one or more central processing units (CPUs), random access memory (RAM), read-only memory (ROM), and a variety of peripheral devices. A microprocessor contains one or more CPUs, but has less of the overall system functionality integrated in the same device in comparison to a microcontroller, typically relying on external circuits for RAM, ROM, and peripheral interfaces.

An SoC is even more highly integrated than a microcontroller, generally combining one or more microcontrollers with additional digital hardware resources configured to perform specialized functions at high speed. As we will see in the FPGAs in embedded systems section and in subsequent chapters, SoC designs can be implemented as FPGA devices in architectures combining traditional microcontrollers with custom, high-performance digital logic.

Memory

Embedded systems generally contain RAM for working memory as well as some type of ROM, often flash memory, to store executable program code and other required information such as static databases. The quantity of each type of memory must be sufficient to meet the needs of the embedded system architecture over its planned life cycle. If the device is intended to support firmware upgrades, sufficient memory resources must be provided in the hardware design to support the anticipated range of potential system capability enhancements over its lifetime.

Software and firmware

In traditional computing environments, the executable code that users work with, such as web browsers and email programs, is referred to as software. This term is used to differentiate program code from the hardware that makes up the physical components of the computer system. In general-purpose computers, software is stored as files on some type of disk drive. In embedded systems, executable code is usually stored in some type of ROM, which is a hardware component within the device. Because of this arrangement, we can contemplate that the code occupies a middle ground between hardware and software. This middle ground is referred to as firmware. In the early days of embedded systems, code was often burned into a memory device that could not be changed after the initial programming. These devices were more hardware-like (hence more firm) than most currently produced embedded devices, which often contain rewriteable flash memory. Nevertheless, we continue to use the term firmware to describe code programmed into embedded systems.

Specialized circuitry

Embedded systems support a wide variety of applications, some of which are relatively simple processes such as monitoring button presses on a television remote control and producing the corresponding output signal, while other types of systems perform extremely complex processing-intensive work on high data rate input signals. While a simple embedded system may be able to use a tiny microcontroller to perform all of the digital processing required, a more complex system may require processing resources that exceed the capabilities of off-the-shelf microcontrollers and more capable microprocessors such as x86 and ARM processors.

In years past, architects of these more sophisticated embedded designs would turn to an application-specific integrated circuit (ASIC) to implement custom circuitry to perform the processing at the speed needed for proper system operation. An ASIC is an integrated circuit containing a custom digital circuit designed to support a particular application. The production of ASIC devices typically involves a very expensive production setup phase, which makes their use impractical during project prototyping and for small production runs.

Fortunately, much of the capability afforded by ASICs is available in low-cost FPGA devices. Because FPGAs are easily reprogrammable, they are generally used for embedded system prototyping and in low volume production runs. For high-volume production (thousands or millions of units), the lower per-unit cost of an ASIC can make the production setup costs worthwhile. This book will focus on the use of FPGAs in the prototyping of embedded systems.

Input from the environment

Embedded systems generally require input from their environment, whether it is from a human operating a user interface or from sensors measuring certain aspects of the system or environment in which they operate. For example, a battery-electric vehicle powertrain controller will track various aspects of the vehicle state, such as battery voltage, motor current, vehicle speed, and the position of the accelerator pedal. The system architecture must include hardware peripherals to measure input from each of the sensors with the necessary precision. The overall powertrain control system must be capable of performing measurements from all sensors at the rate required for proper vehicle operation.

Output to the environment

In addition to reading inputs from the environment, the embedded system will generally produce one or more outputs for use by human operators or by the host system. Continuing the battery-electric vehicle example, the powertrain controller uses the accelerator pedal position, along with other inputs, to compute a command to the controller for the drive motor. This command adjusts the torque output of the drivetrain.

In addition to directly supporting system operation, embedded controllers often provide output for human consumption, such as displaying the vehicle speed in the dashboard. Each output must be updated at a rate sufficient to support proper system operation, including the needs of human perception. When implementing human interfaces, graphical outputs should update smoothly without visible glitches or flicker and audio outputs must avoid timing-related problems such as gaps or skips.

Network communication

While many simple embedded systems operate in a completely self-contained manner, reading their inputs, computing outputs, and updating output devices in an isolated context, more and more embedded system designs support some form of network communication. This capability enables device features such as remote notifications from home video doorbells and the continuous monitoring of machinery on factory floors.

Enhancing an embedded system with an always available network communication capability can provide significant enhancements to functionality. However, this feature also presents a security risk that may be exploited by malicious actors if developers aren't careful to emphasize security within the system architecture. It is important to understand and address the security risks introduced by the inclusion of communication capabilities in an embedded system architecture.

Embedded system architects combine these elements to produce a system design that performs its intended functions, with appropriate safety margins, across the entire range of anticipated environmental operating conditions.

A suitable system design satisfies additional requirements such as size and weight constraints and power consumption limits, and holds production costs to an acceptable level. The design constraints for an embedded system depend heavily on such attributes as the number of units that will be produced, safety-critical aspects of the system, and the need for operation in rugged conditions.

There may be additional considerations that surface during the selection of the microcontroller or microprocessor architectural family and associated tools, such as the availability of suitable programming language compilers and debuggers. The selection of a processor family may depend in part on the past experience of the development team. It also depends on the cost, availability, and anticipated learning curve associated with the development tools.

Embedded system architectures that include persistent communication capability must address an additional dimension of the design space involving communications between individual devices and centralized nodes (typically servers accessed over the internet) and interactions between users and the embedded systems.

The widespread deployment of small-scale embedded systems with network connectivity has introduced the term Internet of Things (IoT). The next section discusses the relevance of IoT to the architectures of embedded systems.

The Internet of Things

Conceptually, the IoT represents an effort to maximize the utility of large numbers of disparate embedded devices through massive network communication. The feature that distinguishes IoT devices from more mundane embedded systems is the presence of a communication path between each device and one or more central nodes that gather data from the sea of devices and, in many cases, allow authorized users to issue commands to individual devices and to collections of devices.

During the IoT device development process, particularly when developing devices that will have access to sensitive personal information (such as home security cameras), responsible embedded system architects must undertake extensive measures to ensure the security of the end devices. IoT devices are often installed in consumer's homes, and security breakdowns that allow malicious actors to take control of cameras, microphones, or security systems must be prevented to the maximum extent possible. Although the system designer cannot prevent every security mistake an end user might commit, a more secure system can assist the user by taking steps such as guiding the selection of strong passwords and by being resistant to common types of attacks such as brute force password guessing.

Examples of IoT devices and systems include the following:

• A home alarm system consisting of window and door sensors and motion sensors: This type of system generally includes a smartphone app providing immediate notification of alarm events. This system not only notifies the alarm company to initiate a response to alarm events, it also notifies the homeowner to the occurrence of those events. Clearly, this type of alarm system must be resistant to cyberattacks that would render the alarm function ineffective.
• Electrical lights and power outlets: Many different illumination devices are available with internet-based monitoring and control, including light bulbs, light fixtures, and power strips capable of switching lights on and off. The app associated with each of these devices allows remote control of individual lights as well as the scheduling of light turn-on and turn-off times throughout the day. As with IoT alarm systems, security is an important feature that must be fully integrated into the system design.
• Smart speakers: IoT speakers such as Amazon Echo and Google Nest provide a voice interface that allows users to make requests in natural language. Users preface commands with a word or phrase to wake up the speaker, such as "Alexa" or "Hey Google," followed by a command or request. These devices enable interaction with a variety of other IoT devices, including alarm systems and lighting control. An example voice command is "Alexa, turn on the lights."
• Medical monitoring and treatment: A wide variety of embedded devices is deployed in hospitals and home environments to monitor aspects of patient health, such as temperature, blood oxygen, heart rate, breathing, and many more. These devices often communicate with a centralized database to enable tracking of current and historical health patterns by medical professionals. Other digital systems perform active treatment functions, such as infusing medications, and assisting with breathing.
• Industrial applications: Embedded systems are widely used in factory lines, energy generation systems, energy transmission systems, and in the oil and gas industries to monitor and control complex systems and processes. For example, a broad range of sensors and actuators is required to perform real-time monitoring and management of the operation of an oil pipeline that may be thousands of miles long.

This book is focused on the architecture and design of embedded systems. We will examine all aspects of the design of IoT embedded systems, including network communication. We will discuss IoT security requirements for embedded systems as well as the communication protocols used to monitor and control IoT embedded devices.

Embedded devices usually operate under tight time constraints. The next section introduces the key aspects of real-time operation and the approaches embedded systems use to synchronize with the passage of time.