Constraints in Embedded Development

Resource constraints unique to embedded development (CPU, memory, and power)

“Resources” in embedded software development refer to the computing power, storage area, power, etc., required for the software to operate. Specifically, this includes CPU processing power, RAM and ROM memory capacity, storage (external memory) for saving data, and power consumption. The difference becomes clear when comparing devices that use embedded software with PCs or smartphones.

To begin with, embedded devices are basically designed to be mass-produced at low cost, so costs must be reduced as much as possible. In particular, home appliances and automotive equipment require miniaturization, and power consumption must also be suppressed as much as possible. Because cost reductions of even a single yen can affect competitiveness, excessive specifications are not allowed, and designs that operate with the minimum required resources are required.

Be aware of limited CPU, memory, and power consumption

Since the operating frequency of CPUs used in embedded devices is lower than that of PCs, advanced and complex calculations and processing cannot be performed. While PCs operate at several GHz, embedded devices are required to operate with orders of magnitude smaller computing power, from several hundred MHz to tens of MHz.

As for memory, PCs commonly have several GB, while embedded devices may be limited to several MB or, in extreme cases, to the tens of KB level. Furthermore, the available power is limited, and because there are no data storage devices like HDDs or SSDs and the memory is not large, a large amount of operation logs cannot be saved.

If these limited resources are exhausted, problems that would not be expected with PCs can occur. For example, insufficient memory can cause stack overflow, while a small data buffer can cause buffer overflow. If processing takes time due to low CPU performance, the time constraints required by the specifications may not be met, and if this happens, the device will not operate as specified.

If power consumption cannot be controlled, there is also a risk that the battery will drain faster than expected. When any of these problems occur, it is often assumed that there is a problem with the embedded device, but in reality, the cause is often in the software design.

Strict resource constraints

Speed constraints unique to embedded development (response speed, processing time, and cycle)

The constraint of “speed” in embedded software does not mean performance, i.e., CPU speed, but rather strict adherence to deadlines, “always finishing processing within a determined time.” While PC software is considered “the faster, the better,” embedded software emphasizes the accuracy of “always finishing in the same amount of time every time.”

Be aware of response speed, processing time, and cycle accuracy

The following three points are important when considering speed: response speed, processing time, and cycle accuracy.

Regarding response speed, the question is how quickly a response can be made when a switch is turned on. For example, the speed from when a car’s airbag sensor detects an impact to when it inflates the airbag is a matter of life and death. Processing time concerns the amount of data that can be processed within a certain period of time. Regarding cycle accuracy, consistent timing is required, such as “always performing processing every 0.01 seconds.”
For example, to rotate a motor smoothly, it is necessary to send commands at the exact same interval every time without the slightest deviation. This is because even a slight deviation in the interval can cause uneven rotation of the motor, potentially leading to vibration or abnormal noise. In other words, when performing periodic processing, processing must be completed within each cycle.

With PC software, even if processing is slightly delayed, it is just a matter of waiting. However, in the case of embedded devices, processing delays lead to malfunctions or failures. Therefore, what is important is not simple processing speed, but the accuracy of always completing processing within a determined time every time.

The prerequisites to consider are that any processing always takes time, and that there is always a deadline for any processing. If such speed constraints are neglected, problems such as “occasional jerky operation,” “malfunction when conditions overlap,” or “problems appearing after long-term operation” are likely to occur. Moreover, these problems do not always occur, but appear only when processing fails to finish on time, making them troublesome issues for which identifying the cause is difficult.

• View PDF for details

Real-time performance unique to embedded development (hard/soft)

Although related to speed constraints, real-time performance has a different basic concept. Real-time performance requires not only accuracy and speed in processing, but also strict adherence to deadlines so that processing results are always produced at the correct timing.

Real-time performance is required because embedded devices are often directly connected to other devices and equipment in the real world. Software on PCs and smartphones mainly functions as an interface operated by humans, and some delay is acceptable. However, embedded devices work in conjunction with physical sensors and actuators, and they must respond with precise timing to the real world, which operates according to the laws of physics. Therefore, in motor control, brake control, medical devices, etc., the moment the output at the required timing is delayed, it can cause a malfunction or lead to an accident. No matter how correct the processing is, it is meaningless if it is delayed past the required timing.

Hard Real-Time and Soft Real-Time: Two Types of Real-Time Performance

Real-time performance is divided into two types based on its strictness: “hard real-time” and “soft real-time.” Hard real-time requires that the system always meet its specified response time—in other words, not even a one-millisecond delay is allowed. Examples include automotive brake control and emergency stop processing for industrial robots. In either case, a delay immediately leads to a serious accident. On the other hand, soft real-time permits occasional delays that result only in a noncritical decline in quality, such as a slightly jerky LCD display on a household appliance. Nevertheless, because it adversely affects product quality and user experience, delays must be minimized as much as possible.

To ensure real-time performance, what must be considered is not the average processing time, but whether processing can be completed on time even in the worst-case scenario. Even if a process normally finishes in 1 millisecond, if it takes 10 milliseconds when there is a large volume of data, the system must be designed assuming 10 milliseconds. In addition, it is important to minimize variation in processing time as much as possible to ensure predictability, allowing the system to respond at the same timing every time for the same input.

In doing so, one should not simply think that “making the CPU faster will solve the problem” or “using an RTOS (Real-Time OS) will guarantee real-time performance.” Real-time performance is not ensured by those tools; rather, it is determined by design, such as task division, priority setting, and processing time estimation.

Real-Time Performance

Embedded Software Development Requires Working Within Constraints

In embedded software development, you must constantly face three constraints: resources, speed, and real-time performance. Given limited memory, CPU performance, and power, you are required to always finish processing reliably within a set time and operate accurately with the same timing every time. These are major differences from the requirements in software development for PCs and smartphones.

In PC and smartphone development, the mindset of “if there is not enough memory, just add more” or “if processing is slow, just make the CPU faster” works. However, in embedded development, there are almost no such options. An attitude of extracting maximum performance within the given constraints—in other words, “accepting constraints as part of the design”—is required.

It is precisely because these constraints are strictly observed that safe and highly reliable equipment can be provided. The reason automotive brakes operate reliably, medical devices function precisely, and countless other electronic devices supporting our daily lives work as expected is that meticulous design and testing to confirm correct operation are conducted based on an understanding of these constraints.

To achieve this, it is necessary to anticipate the worst-case scenario, be conscious of time costs, and ensure that systems operate without issues according to specifications. Embedded development is not a battle against constraints, but a highly creative endeavor of understanding constraints and creating products that meet specifications within those constraints.

• View PDF for details