Does Embedded Development Require Architectural Design?

My Understanding of Architectural Design

1. Understanding of Architectural Design Concepts

I believe most readers of this article are engaged in embedded development, and you may have noticed that job postings for architectural design roles on recruitment websites are predominantly focused on Web development, with very few openings for system architects in embedded positions.

My understanding is that there are probably two reasons for this:

(1) Web Development: A Hundred Schools of Thought Contending, No Unified Standards or Dominance

In recent years, thanks to the development of mobile internet, the demand for front-end and back-end development positions has surged, and various frameworks have emerged.

There is no unified standard for how to leverage these frameworks to provide high-performance services to users, leading to a proliferation of design roles.

(2) Embedded Development: Linux is My Only Choice

In embedded system development, there is almost no room for choice regarding the operating system; most systems use an ARM+Linux combination..

At the Linux operating system level: the experts have already designed the kernel and driver layers very well, requiring developers to make minimal modifications.

At the application level: if developers have no particular aspirations, they can simply implement the functions defined in the specifications.

And as for the bosses, they only care whether the product functions as expected; they do not think about aspects like portability, scalability, or execution efficiency.

Even if the product needs to be updated, developers can simply reimplement it, as long as the functionality is okay.

2. Importance of Architectural Design in Embedded Systems

Let me share a short story.

A colleague wrote a program for a microcontroller product for a client, and after he left, he handed over the code to me.

There was a small functionality that needed modification, and at that time, I was busy with another project, so with my boss’s permission, I sent the source code to the client, asking them to modify it themselves.

The client was very happy to receive the source code because once they understood it, they could develop similar devices on their own.

After a while, I asked the client how the modification of that product was going. He said: “Not done yet; I lost the code you sent last time, which is a headache. Now I’m rewriting the code from scratch.”

This story is true.

Code is composed of characters; some code looks pleasing, while some makes you question life.

Code without architectural design guidance has the following drawbacks:

(1) Code cannot be reused, and porting is troublesome.

(2) When requirements change, code cannot be adjusted quickly.

(3) For existing code: developers are reluctant to change it, fearing that any change will affect everything.

(4) Debugging bugs is a headache.

Conversely, if the architectural design is good, it benefits all aspects:

For the project:

(1) Project cycle is controllable

(2) Code readability is good

(3) Functionality is extensible

(4) Modifying a single module does not affect other functionalities

(5) Parallel development is possible

(6) Unit testing is convenient

For developers:

(1) Saves development time

(2) Global perspective enhances the ability to develop large projects

(3) Debugging is easy and fast

How to Conduct Architectural Design

1. Design Documentation

Once you enter the programming field, everyone knows the importance of high cohesion and low coupling, modular and layered design.

But how exactly should this be done?

How to complete tasks within the specified project cycle without exhausting oneself?

How to lay a good foundation for future maintenance?

…..

These questions may be well planned at the initial stage of the project.

However, during execution, people tend to get lazier and deviate more and more from the predefined direction.

My suggestion is:

Regardless of the project’s size or duration, there must be design documentation, and the level of detail in the documentation should be flexibly adjusted based on the project’s actual situation.

The architectural design must be reflected in the design documentation. During implementation, one must strictly follow the requirements in the documentation.

Aim for the top, and you will achieve the middle; aim for the middle, and you will achieve the bottom.

2. Physical Model of Program Files

(1) Layered Design

Business Layer

Functional Module Layer

Driver Layer

(2) Modular Design

Divide modules based on functionality

Modules interact through API interface functions

Design flexible API interface functions

3. Choice of Processes and Threads

In embedded systems, product functionality can be achieved through multiple processes working together or through multithreading; there is no fixed standard for this choice, as it depends on the specific situation of the project.

My general approach is:

If the product’s functionality is not complex, try to use multithreading;

If the product involves many functionalities, then place strongly related modules in separate processes.

(1) Using Processes

Each module is compiled independently and will not affect each other.

When similar SegmentFault issues occur, it’s easy to locate the culprit.

Convenient for distributed deployment.

Code safety: except for the integration personnel, others only need to clone their responsible module code, without permissions or needing to access others’ code.

However: one must consider inter-process communication issues, such as IPC calls, socket communication, and buses. (I generally use an MQTT bus to connect all communication modules within the local system.)

(2) Using Threads

Creating threads is low-cost.

Threads share global variables (which can also be seen as a disadvantage).

Modules can call each other easily because function addresses are directly visible.

4. API Design

A module can be viewed as a black box; given an input, it will return a definite result or execute a specific function,

Modules only need to define this API interface function.

As for how the module is implemented internally, everyone can showcase their capabilities.

Additionally, if you are an API designer, you must ensure that the caller finds it comfortable to use. Just like handing a pair of scissors to someone, you must present the handle to them.

Another experience is that at the initial stage of project design, try not to make the API function design too rigid, as it can easily trap you.

For example:

(1) You can design variables with char *, using JSON format strings to pass data of any length and type.

(2) You can design variables with void *, to pass the address of any data type; this functionality has been used exceptionally well in many projects, such as the BREW platform from Qualcomm and the Z-Wave platform in smart homes.

5. Directory Structure Design

This part is easy to understand; files with different responsibilities should be stored in their respective directories: header files, library files, executable files, and related documents. If this part is not well organized, when you hand over the project to other colleagues, they will definitely think in their hearts: F-U-C-K Y-O-U!

6. Design of Compilation Scripts (Build Tools)

When we receive an embedded project, after determining the solution, the platform on which the program runs is usually fixed, most often embedded Linux or some variants.

During the development phase, I have seen some developers cross-compile the code after debugging each functionality, then place it, and execute it on real devices via NFS remote mount or scp remote copy. It looks exhausting to me.

In fact, you can compile a version for different platforms in the compilation script.

For example, when developing products using the Ubuntu system, as long as the x86 platform can simulate the product functionality, just compile the x86 version.

Once all functional points are tested and validated on the x86 platform, then deploy them on the actual embedded system for integration testing; this approach can save a lot of time.

Demo Description

1. Introduction

This demo is extracted from a smart home project, and it only reflects the design of various functional modules; the functions are not implemented internally, and it is solely for demonstrating the design process.

2. Code Access

https://pan.baidu.com/s/1B3F9byydXeNWdtgYEEQNLg

Password: 3a9p

It can be compiled and executed directly under Ubuntu 16.04.

3. System Architecture Diagram

4. Directory Structure

Makefile: Compilation script

application: Business layer

module: Functional module layer

driver: Hardware driver layer

5. Execution Sequence Demonstration

The orange arrows in the above figure indicate a control command sent from the cloud.

The business layer receives the command, parses it, and sends it to the Control module.

The Control module further parses the specific command and sends it to the ZigBee device while logging it.