Development Overview and Rework-Free Design

Overall Picture of Embedded Software Development

A characteristic of embedded software is that it works closely with hardware. There are many physical constraints derived from hardware, and if errors occur due to misunderstandings in the design phase, it is not uncommon for major rework involving hardware changes to occur.

Here, we will explain the difficulties unique to embedded software development and the importance of upstream processes.

Difficulties Arising from Parallel Development with Hardware

A difficult point in embedded software development is that design must proceed even when the specifications of the underlying hardware are not yet finalized.

For example, if a component used in a product is changed during development, a huge amount of man-hours will be spent rewriting drivers and signal processing logic that have already been implemented, and checking the impact on peripheral equipment due to the specification change.

Therefore, it is important to communicate closely with the hardware team from the early stages of development and share the hardware development status and the possibility of specification changes in real time.

The need for such hardware-aware development is the biggest difference and difficulty between general-purpose software development and embedded software development.

Importance of Upstream Processes in V-Model Development

Embedded software development is generally carried out along the V-model. V-model development is a development method in which the design process is placed on the left side and the test process is placed on the right side, and each is verified in a paired manner.

In V-model development, great importance is placed on building quality into the design phase, which is an upstream process. This is because the cost of correction in downstream processes is extremely high compared to upstream processes. According to a survey by NIST (National Institute of Standards and Technology), the cost of correction after release is reported to be approximately 30 times higher than the cost of correcting bugs found in the design phase.

In order to keep bug correction costs down, it is also important to build quality into the design phase so that defects themselves do not occur.

Role of the Design Phase That Affects the Quality of Embedded Software

The design phase consists of the following three processes.

1. Requirements Definition
2. System Design (Basic Design, Detailed Design)
3. Implementation

We will explain the role of each process.

1. Requirements Definition

Requirements definition is the process of giving shape to user requests and clarifying the content (functions) to be implemented in the software. In the case of embedded software, non-functional requirements that take hardware limitations into account must also be defined with specific numerical values.

Serious rework that occurs on-site is caused by inconsistencies such as insufficient memory and processing slowdowns. To prevent this rework, it is important to define specific numerical values for response speed, power consumption, memory footprint, etc., at the requirements definition stage, and verify whether they can be achieved within the hardware specifications.

Prior verification can prevent major trouble, such as development proceeding even though it was impossible to realize in the first place.

2. System Design (Basic Design, Detailed Design)

The role of system design (basic design, detailed design) is to translate the abstract behavior determined in the requirements definition into concrete operational logic. The key is to make it concrete to the level where implementers can code without hesitation.

First, the entire system is divided into independent modules, and their respective interfaces are strictly defined. For example, it is determined which module processes data acquired via communication and values from each sensor, and when they are output. Regarding performance, which is a non-functional requirement, if there are requirements that must be met, the implementation method is examined and finalized at this stage. Even if hardware specification changes or component replacements occur during development, the scope of modification can be limited.

In addition, rules for algorithms within each module, state transitions, and exception handling such as battery errors are also finalized at this point. By determining these rules during the design stage, pass/fail criteria for subsequent testing processes are established, preventing rework due to fundamental logic failures near the end of development.

At this stage, let’s confirm that both the functional and non-functional requirements can be met from both the hardware and software perspectives.

3. Implementation

Implementation is the process of materializing the intent of the design into source code. Rather than simply writing code, improving the quality of the program at the time of implementation directly leads to shortening the lead time of the entire project.

Fixing bugs discovered during actual hardware testing requires dozens of times more man-hours than fixing them during the design phase. To keep these correction man-hours down, it is important to remove the causes of defects as early as possible through code reviews and static analysis.

• View PDF for details

Building Quality into Embedded Software Through Design

Ideally, the quality of embedded software should not be found through testing, but built in during the design phase. Ambiguity in requirements manifests as defects in downstream processes, causing fatal rework for the project.

In order to improve quality while maintaining project progress speed, careful building-in during the development phase, such as the following, is essential.

Concrete Numerical Definition in Requirements Definition

By eliminating ambiguous expressions such as “fast response” and defining non-functional requirements with numerical values, inconsistencies with hardware can be prevented.

Concrete Structure in System Design

The design is made concrete to the level where implementers can code without hesitation. Furthermore, it is ideal to separate hardware and logic to build a testable structure that allows software verification without waiting for the completion of the actual hardware.

Static Verification at the Implementation Stage

Instead of fixing defects after actually running the software on the actual hardware, defects are thoroughly eliminated at the implementation stage through compliance with coding rules, analysis tools, and code reviews.

By thoroughly maintaining awareness of completing quality on the left side of the V-model, rework can be minimized even in complex embedded software development, allowing projects to proceed smoothly.