An embedded system is much more than a computer, because they often must have a real time response and several constraints to work within a given system that is tailored by industry and function. Real-time operation requires a response to input within microseconds. Delays in responding, termed latency, are often unacceptable, especially in real-time systems. Examples include robotic surgery, which, much like gaming, requires the remotely controlled action to respond instantaneously to the doctor’s physical commands, without 
delay. Embedded systems also have many design constraints. For example, software is created specifically for the embedded system and may replace functions that were previously handled by physical components. Once deployed in the field and under operation, embedded systems do not have a keyboard or typical input device, and if there is a display, it is limited. Cars have many embedded systems that incorporate an Electronic Control Unit (ECU) that monitor and govern certain functions in the car via algorithms. In a vehicle related embedded systems control example, a stack overflow was believed to have been the cause of uncontrolled acceleration when the driver used the cruise control function.[i] Embedded systems are unique and many more variations exist than with desktop systems because they are designed to fulfill a specific function with little user input.
Consumers, researchers, and other desktop users often measure a CPU by performance and cost. Monitors, printers, speakers, and other peripherals are all fairly standard and typically connect the same ways to collect and disseminate the same sensory data that people can understand. Embedded systems speak more to other machines than to people. Embedded systems are electronically designed and programmed to perform specific functions and are often required to convert signals from outside sensors for digital processing and decision making by the embedded CPU with no human intervention at all. An embedded system may need to interface with data convertors, FPGAs or other specialized chips, and external memory devices to achieve a dependable functioning process. Going back to the cruise control example, an ECU will control a loop that accepts the user’s input for a desired speed and adjust the braking and acceleration according to speed that’s externally monitored by another loop or ECU. The other loop continuously monitors ongoing speed, which changes based on external environmental influence, and feed actual speed to the cruise control loop. As two separate loops, if one loop fails to return a new speed value, the cruise control loop won’t issue a command to stop accelerating (because it doesn’t know it has reached the desired speed). The failed interaction of two embedded systems with different Inputs and Outputs (I/O) can cause the embedded equivalent of a “blue screen” that was common in the Microsoft Windows operating system when it hit an unexpected or unplanned-for snag. A blue screen on a desktop means you have to reboot and start over. A dead task within an embedded system cannot always produce a “blue screen” for the user to complete an equivalent reboot.
An embedded control system designer has access and control of the CPU, memory, and various peripherals like a desktop computer, however, embedded systems designers also have to program with outside inputs from sensors or other machines, provide diagnostic tools, implement loops to control automated output with electromechanical actuators, and provide hardware backup and/or safety mechanisms. The external environment of the embedded system must often be taken into account. Reboot by a human user is not an option; embedded systems typically work without expectation of human intervention. Embedded systems are constrained by functionality that meets or exceeds specifications, time-to-market, and cost.
There are several billion embedded processors versus several million computer processors sold annually. The PC/computer market is saturated, but embedded systems are growing, especially embedded systems that are connected to the internet (i.e., The Internet of Things devices.) Embedded control systems accomplish many different applications in many different ways. Examples of embedded applications include computers used in automotive and other transportation systems, automatic teller and electronic vending machines, video game platforms, IoT devices like the Amazon Echo (“Alexa”), point-of-sale payment systems, digital signage, embedded payment systems, anti-lock brakes, microwave ovens, pacemakers, thermostats, remote key fobs, digital road signs, floor cleaning robots, and much, much, more.
Hybrid embedded PC systems
There are some embedded systems that began as desktop PCs but are set to run a repetitive function or application with little human intervention, such as digital signs running menus on large displays in a restaurant, or touch screen kiosks. These desktop style PCs are meant to function as embedded devices, however, since the end user (or the customer) is supposed use the application, and should never need to reboot the system.
No blue screen allowed
There are, however, some distinctive attributes of embedded systems. A system that must react quickly with little delay (real-time) to an external event, whether periodic or random, is most likely an embedded system, especially if the function of time is “hard real time.” Hard real time event response is required when the response must always be immediate, otherwise the response is useless. Life-critical systems in military and medical systems are examples of applications that often require hard real-time. In this case, the embedded system, unlike a desktop, is not going to wait for a print buffer to finish a task before tracking and shooting down an incoming missile. Embedded systems with hard real-time constraints are often dedicated to one purpose. Soft-real time is another term used when a quick response is not as critical, but the benefit decays as the delay time to response increases.
Designing embedded
Embedded systems designers have to deal with a complex set of design trade-offs. They may have design goals for high dependability, affordability, scalability, safety and a fast time-to-market. Embedded designs cross over into several disciplines, involving electronic and mechanical hardware, software, and specific control algorithms while adhering to licensing, standards, and regulatory bodies. The lifecycle of the embedded system, especially for military/defense related systems, is much longer with embedded systems. The requirements, design, and manufacturing/production constraints for embedded systems differ greatly between market spaces. Medical devices have to be cleared by the FDA, whereas consumer devices have fewer regulatory bodies reviewing embedded designs.
Other distinguishing attributes of embedded systems
Embedded systems often need to be small and light-weight, especially if they are in a portable system. Hand-held devices and automobiles both need small size and weight if fuel costs are to remain as low as possible. A robot or vehicle has a greater chance of using less energy to run longer if the components are small and light weight. Many embedded systems endure harsh environments. Automotive chips in the engine compartment are often rated at 85°C to 256°C and must endure long periods of heavy vibration. Many embedded systems play a huge role in safety systems. “Drive by wire,” for instance, is an automotive control system that is electronically controlled without physical linkage. The throttle cable can be replaced by a drive-by-wire embedded system with inputs and outputs controlled by a CPU. Thus, reliability in software and in electronics hardware is a huge factor in some embedded systems.
Lastly, embedded systems can be quite cost-sensitive because they are often part of high-volume production systems. A few cents extra for one integrated chip over another can quickly add up with hundreds of thousands of the final products of these embedded devices sold.
[i] https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf
