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.
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.
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:
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.
Embedded systems run on hardware designed to meet the constraints 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.
Common constraints on embedded system hardware are:
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.
Target hardware examples include small microcontrollers like:
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, 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:
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.
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, and 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.
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 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.
The applications of embedded systems are too numerous to list but the obvious high-profile examples include:
Our smartphones, tablets, smartwatches, and smart TVs are all embedded systems! Here are more applications that run on embedded systems:
In fact, 98% of microprocessors produced in the world are used in embedded systems.
As ubiquitous as embedded systems are, there’s 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 Microsoft Windows operating systems, 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.
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.
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 lifecycle. 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 assure correct behavior when deployed.
A Sr. Technical Product Marketing Manager for Parasoft’s embedded testing solutions, Ricardo has expertise in the SDLC and test automation of embedded real time, safety, and security-critical applications, and software compliance to industry standards.