Featured Webinar: Simplify Compliance Workflows With New C/C++test 2024.2 & AI-Driven Automation Watch Now

What Are Embedded Systems?

Headshot of Ricardo Camacho, Director of Safety & Security Compliance
October 10, 2023
7 min read

Embedded systems have been with us for ages. Read on to learn what they are, some safety concerns of embedded systems, and how proper testing can help make them safe and secure.

Introduction to Embedded Systems

Embedded systems are microprocessor-based computer systems, usually built into a system or product, that have a dedicated operational role. In other words, embedded systems are the hidden “smarts” behind all the devices we use, the cars we drive, the planes we fly on, and the trains we ride in.

Rather than being made of separate components like desktop computers, servers, and other similar domains of computing, embedded systems are enclosed into products and include integral hardware and software.

How Are Embedded Systems Used?

What’s interesting about embedded systems is the breadth of applications. They range from small controllers in smart home devices to avionics systems in airplanes to large networking switches that make up our telecommunication networks. This also makes them challenging to design and develop. The constraints of the intended product impact the performance envelope of the embedded hardware and software.

Embedded systems are ubiquitous but relatively unknown to most consumers. Modern automobiles have up to 100 million lines of code in them and most of that is not in the infotainment system. So much of a modern car’s software and hardware is in the various microcontrollers and engine control units that control and monitor modern features.

The Architecture of Embedded Systems

Embedded systems consist of hardware and software as mentioned above. They’re often used in applications that require both sensing something physical in the environment and controlling something in response.

A simple example is an HVAC system with an embedded thermostat controller. Such a system would sense the room temperature and actuate either the heating or air conditioning. It might need some form of communication via a network interface and display temperature on an LCD screen (human/machine interface or HMI.)

Such systems are often called “real time” or “event driven” since they must react in a timely fashion to real world events. Depending on the type and criticality of the application, reacting to events at a specific time is important. Safety-critical systems like antilock brakes (ABS) in a car must react within milliseconds. Such systems are referred to as “hard real time” meaning they must meet required deadlines or a failure has occurred. Systems with looser deadlines are referred to as “soft real time”. In most of these cases, these systems run on top of some sort of real time operating system (RTOS).

Here’s a simple example of embedded system architecture:

Diagram showing an environment with an embedded system and controller inside. The embedded system is symbolized by a transparent box with blue outline and four connected boxes: HMI, Sensors, Actuators, Network/Serial/USB. These all point to and back from controller elements reflected and contained in a green controller box, which include RAM, ROM, I/O and CPU.

Also unique to embedded systems is the use of a microcontroller architecture. Unlike desktop or server systems, microcontrollers usually have all the RAM, ROM, and I/O on a single chip. These controllers often have the required I/O capabilities to interact with sensors and actuators and integrate with network and other communication devices.

Hardware Limitations of Embedded Systems

Embedded systems run on hardware designed to meet the limitations of the product they’re used in. The hardware is often specified to meet targets for business (for example, cost) and technical. These products can number in the millions of units and operate for decades, implying the need for both hardware and software reliability and quality.

Constraints on the Hardware

Common constraints on embedded system hardware are:

  • Limited processing power
  • Memory
  • Storage

These constraints limit the performance and complexity of the application that the hardware can support. In turn, this increases the design and development challenges, especially when trying to integrate more features.

Embedded system hardware constraints are driven by business requirements that often impact the profitability of the end product.

  • Bill of materials cost. Less complex hardware is cheaper to buy and has higher profit margins. However, as software complexity grows, it quickly outpaces the hardware capacity. Moving to larger-scale processors means higher bill of material (BOM) costs and significant software impacts.
  • Size and weight. End products are limited by size and weight, which can impact hardware selection. More complex hardware might require larger circuit boards, power supplies, and heat dissipation.
  • Power consumption. Embedded systems are often in battery-operated equipment where power consumption is tightly managed. They may also be in higher-end systems where heat is a concern.

Target hardware examples include small microcontrollers like:

  • The ubiquitous 8-bit 8051
  • Microchip’s PIC16 MCU
  • ST Micro STM32 32-bit ARM Cortex MCU
  • Embedded systems on a chip (TI’s OMAP or the Raspberry Pi)
  • Large scale, multiprocessor 64-bit systems based on ARM, Intel, and AMD processors

Software of Embedded Systems

Most of the engineering effort goes into the software of embedded systems. In fact, most manufacturers need a software group to develop the applications embedded in their products. Jokingly, CEOs of these companies jest, “We are a software company masquerading as a widget manufacturer.”

The reality is that software has become the key area of differentiation and innovation in many markets, including companies whose main product is not software.

Just as with hardware, the software complexity depends on the intended application which can vary greatly. However, there are three major categories that most embedded software fits into:

  • Small scale
  • Medium scale
  • Large scale

Small Scale, “Bare Metal”

These applications are usually on 8 and 16-bit microcontrollers with no formal operating systems, also known as bare metal. The applications are usually controlling a single subsystem based on a few sensors. They may not be connected to a network and might be operating autonomously. High-level control is elsewhere, such as with a supervisory control and data acquisition (SCADA) system, usually with much more complex hardware and software.

Medium Scale

These systems often use commercial or open source embedded operating systems which are frequently real-time as well (RTOS.) These operating systems provide the necessary hardware abstraction, multiprocessing, multithreading, network, and interface libraries. Examples include FreeRTOS, VxWorks, and QNX, and in some cases, embedded Linux. Applications can vary from hard real-time, safety-critical applications such as airplane avionics to wireless routers and HVAC systems.

Usually, the hardware is 32-bit microcontrollers and SoCs with more RAM and flash than small-scale systems. However, software complexity is orders of magnitude higher in this category with applications having tens of thousands to a million lines of code (LOC) or more.

Large Scale

Systems in this category are usually very complex with multiple features and capabilities. They often operate on server-like hardware that has multiprocessors. Applications often require real-time processing and may still use high-end RTOS or Linux. Examples of this include enterprise network switches and routers and telecommunication network backbone systems, stock exchange processing, and air traffic control. These systems are highly complex, interconnected with code bases of multiple millions of lines of code.

Despite the variety of applications there are some common characteristics such as the dedicated nature of the applications. Embedded systems often run all year round, 24 hours a day. They also share the need to be reliable, safe, power-efficient, and cost-effective to manufacture. More than ever is the need for them to be secure, which we’ll talk about later.

Applications of Embedded Systems

The applications of embedded systems are too numerous to list but the obvious high-profile examples include:

  • Life-saving devices like heart pacemakers
  • Critical applications like flight control in airplanes and automated driver assistance
  • Software that runs gadgets and smart home devices

Our smartphones, tablets, smartwatches, and smart TVs are all embedded systems! Here are more applications that run on embedded systems:

  • Industrial automation.
  • Command and control of nuclear power stations, power generation, and distribution.
  • Power, heat, and light to keep the economy running.
  • Safety-critical software in trains, planes, and automobiles.
  • Telecommunication towers, hubs, switches, and routers for Internet and telecommunications operations.
  • Sophisticated weaponry, fighter jets, tanks, and missiles have embedded systems at their heart.

In fact, 98% of microprocessors produced in the world are used in embedded systems.

What’s Not Embedded?

As ubiquitous as embedded systems are there are still a lot of systems and software that aren’t. All desktop software such as productivity, web browsers, and video games aren’t considered embedded. Enterprise software, cloud infrastructure, and backend systems aren’t embedded either.

Usually, if it runs on generic hardware such as a typical PC or server, it’s not considered embedded. Physically, the applications aren’t bundled with hardware as one and inseparable. For example, PCs might ship with the Microsoft Windows operating system, but that operating system can be replaced and removed without altering the main function of the PC. Non-embedded software is usually application software that can run on a variety of hardware, remotely or locally.

Safety and Security Concerns for Embedded Systems

Embedded systems play an important role in safety- and security-critical devices. Products like pacemakers and ABS brake controllers can’t fail. Lives depend on these devices working properly, all of the time. High-profile failures such as the Therac 25 incident where patients massively overdosed with radiation or the Ariane 5 rocket disaster caused by an integer overflow error.

Security is now a major concern as more embedded systems come online, connected through the internet (the Internet of things.) This interconnection creates new features and opportunities and opens the door to attacks. A litany of security problems in IoT devices is documented by our very own Code Curmudgeon in his IoT Hall of Shame. Insecure devices are unsafe so security and safety must be considered equally in these critical devices.

How Do We Make Embedded Systems Safe and Secure?

The only way to make sure embedded systems are safe and secure is through testing. More precisely, through rigorous verification and validation throughout the entire development life cycle. That includes before software development, in early requirements analysis, and all the way until end of life.

There are specific standards that must be followed by industries where safety is a major concern, including the following:

Manufacturers of these devices must follow the standards and prove via audits that they perform their due diligence and have addressed all concerns for security and safety. This type of hardware and software development is time-consuming and expensive to build and test, but essential to ensure correct behavior when deployed.

Ensuring the Safety & Security of Embedded Systems

Embedded systems, particularly safety- and security-critical embedded systems, can’t fail. If they do, the consequences are dire. Lives will be lost or persons will sustain serious injury. There’s also the possibility of damage to property. Therefore, software testing is critical.

Software testing ensures that the embedded system is safe, secure, and reliable. Testing also helps in the certification of these facts. The functional safety standards mentioned in the previous section provide guidance and recommend testing methods like static code analysis, unit testing, integration testing, system testing, regression testing, structural code coverage, and many other types of hazard analysis, threat analysis, and risk assessment activities to ensure the safest and most secure embedded system possible.

Many embedded systems also have certification requirements imposed by federal regulatory agencies. The U.S. has the FDA for medical devices, the FAA for avionics, the NHTSA for motor vehicles, the FRA for rail, and there are more. These agencies impose regulations that keep the public safe and secure. In addition, companies themselves strive for quality, because recalls, lawsuits, and lengthy litigations can destroy a company.

Static Code Analysis for Embedded Development