[Tech Report] SDx in Embedded Systems: How to Maintain Control as Complexity Grows

Embedded systems have long evolved in a software-centric direction. Developers have used software to differentiate products, improve performance, and deliver functions beyond the limits of fixed hardware.

The recent change is less a shift in the concept itself than an expansion in scale and complexity. In today's embedded systems, more and more functions are being implemented in software.

Accordingly, more feature additions are being handled in software. More performance tuning is also being handled in software.

Software handling of connectivity is also expanding, as is software handling of security behavior. Software handling of product lifecycle management is also advancing, and software updates are being used more often instead of hardware redesigns.

This shift is called SDx (Software-Defined Everything). The best-known existing area of SDx is SDV (Software-Defined Vehicle), and the same trend is spreading to industrial automation, IoT, energy systems, and Medical devices.

From the perspective of embedded development teams, the core principles behind the concept have not changed much.

However, system connectivity has risen sharply, the need for updates during long-term operation has surged, and security requirements have also increased.

As safe software evolution has become necessary even after deployment, software responsibility has expanded and risks have increased as well.

At the same time, embedded systems still have the same characteristics: limited memory, limited processing resources, real-time requirements, safety-critical needs, and security-critical needs.

For that reason, flexibility alone is not enough, and the importance of controllability, predictability, and long-term stability is increasing.

Against this backdrop, SDx is not just a buzzword.

Against this backdrop, SDx has become a practical challenge that must be managed systematically.

In embedded systems, SDx does not mean removing the role of hardware, but separating system functions from specific hardware implementations, with the goal of enabling functional evolution through software over the product's lifetime.

There are several core principles in system design. Principle 1 is software-layer abstraction of system functions and data flow. The design focus is placed on what the system does, rather than direct handling of specific peripherals and interfaces.

The effect of this approach is that developers can reduce the burden of low-level implementation details such as how data is acquired, how it is transmitted, and how it is generated. As a result, developers can focus on application behavior and system purpose. This shift assumes that real-time performance, performance, and reliability requirements continue to be met.

The importance of this architecture becomes especially pronounced in long-lived systems with growing complexity. Function-oriented design criteria exclude hardware details and center on stable functionality. As a result, the nature of system evolution changes, and fragile changes turn into manageable extensions.

Principle 2 is portability. To achieve this, software must be designed to be independent of a single processor generation.

This kind of design makes it easier to respond to supply chain changes. It also reduces dependence on specific semiconductor vendors.

The premise is that when the hardware platform changes, the entire software stack does not need to be rewritten. As a result, existing investments can be preserved, and verified behavior can be maintained.

In this flow, one of the main areas transformed by SDx is the embedded industry. In the automotive sector in particular, SDV stands out as a core concept.

In automobiles, vehicle differentiation is becoming more software-centric. Examples of software-based differentiation include driver assistance, connectivity, user experience, and feature activation after purchase.

However, automobiles are essentially embedded control systems that must operate for more than 10 years. For that reason, automotive software requirements include maintaining determinism, maintaining functional safety, and maintaining predictability.

Accordingly, in the automotive sector, the ability to update functions alone is not enough. The need for manageable build processes and manageable deployment processes is also being raised.

In this process, the role of DevOps (CI/CD) is to help ensure that the same results can be reproduced even when people, development environments, and releases differ. The significance of reproducing the same results is that it forms a core foundation for long-term vehicle software operations.

When the SDx structure is applied to industrial automation systems and IoT, it brings benefits such as easier maintenance, easier reconfiguration, and continued functional expansion. Industrial automation and IoT environments are structured in a way that increases flexibility through SDx adoption.

However, most are continuous-operation systems, so failures do not immediately appear as crashes. As a result, problems tend to accumulate rather than surface right away.

Examples of such accumulated problems include timing drift, memory fragmentation, abnormal interactions between tasks, and performance degradation after long periods of execution. These issues accumulate and emerge in continuous-operation environments.

Because these problems are difficult to detect through simple debugging, the need to use dynamic and static debugging and analysis tools is increasing. In actual operations, the targets of analysis are memory usage, timing margin, and task interactions.

The purpose of using these tools is to identify the root cause, not the symptoms. Accordingly, analysis of the actual operating state is required.

In Medical technology, SDx can improve diagnostic functions, monitoring functions, and treatment functions. At the same time, traceability and auditability are required for all changes in Medical devices.

Certification readiness is not a task for the final stage of a project; it needs to be included in the development process.

To do that, functional safety solutions are needed.

Functional safety solutions need to support reproducible builds, consistent code analysis, and traceable verification results.

They must also be able to prove that verified behavior is maintained after updates.

Even in the SDx era, the realities of embedded systems remain unchanged.

Even as SDx spreads, embedded constraints persist: memory remains limited, real-time performance remains essential, and security threats continue to evolve.

What has changed is not the constraints themselves, but the way they are handled.

Security is not a post-processing item. In long-evolving systems, security needs to be maintained repeatedly and consistently.

In this context, an approach to supporting SDx-based embedded development is being proposed.

A reproducible build means that a trusted, certified toolchain must be integrated into an automated build environment.

Such reproducible builds make it possible to obtain the same build results across developers, maintain consistency across CI servers, manage releases for long-lived products, and secure documentation for certification response.

Because SDx systems assume continuous change, quality verification cannot end with a single pass and must be performed continuously. This has led to the need to make every build subject to automatic verification.

For this purpose, the use of static and dynamic analysis tools is increasingly important. These tools can automatically enforce coding rules, detect defects before integration, inspect vulnerability patterns, and reduce regression risk.

Security is not a post-add-on. Therefore, the full lifecycle must include device authentication, code signing, and protection mechanisms.

Modern embedded products pass through multiple hardware generations. As a result, the need for software structures that are independent of specific processors is increasing.

This approach leads to the need to minimize hardware replacement costs and hardware replacement risks. In other words, software must not be tied to a specific processor as hardware changes.

Ultimately, the key to SDx is not unconditional speed. What matters in embedded systems is control.

The embedded field is seeing future software-centric expansion across SDV to Medical and industrial systems.

In this trend, the need for planned change is growing.

At the same time, the need for predictable outcomes is also being raised.

In addition, the need for safe operation is becoming an important prerequisite.

The core challenge is not whether systems become software-centric, but how to maintain control in an environment of growing complexity.

To do this, a software process transition is being called for.

This transition must cover build, performance, security, and certification targets.

It must also ensure repeatability and controllability.

Specifically, reproducible builds are needed.

Consistent code analysis is also needed.

Visibility into performance and memory is also required.

Embedded security mechanisms are also needed.

At the same time, a development flow that can respond to certification requirements must also be secured.

Through such a framework, SDx innovation and predictability can be achieved at the same time.

Ultimately, the task for embedded teams is to achieve determinism, security, and long-term stability while adopting SDx, and the standard for future competitiveness will depend on maintaining that balance.

Source: TECHWORLD · Lee Gwang-jae
Original: https://www.epnc.co.kr/news/articleView.html?idxno=406432

References

• https://www.epnc.co.kr/news/articleView.html?idxno=406432