Discussion on the orthogonal design of embedded software systems

Discussion on the orthogonal design of embedded software systems

[Date:]

Source: single-chip microcomputer and Embedded System Application Author: Li Xing Hegu Jun Yin Song Jibo Ma Yanling Wu Yun

[Font:Large Medium Small]

　

 

1. Introduction to wavelet

Wavelet transform is one of the most brilliant scientific achievements in the 20th century, it has been widely used in signal processing, image analysis, nonlinear science, earth science, music radar, CT imaging, seismic exploration, celestial recognition, quantum field theory, mechanical fault diagnosis, fractal and other scientific and technological fields.

At the beginning of the 20th century, Alfred Haar was very interested in finding a base similar to Fourier in function space. In 1909, he first discovered and used wavelets. Later he was named Haar wavelets ). In 1970s, Jean Morlet, a geophysicist working at the French oil company, proposed the concept of wavelet transform. In 1980s, French scientist Y. Meyer and his colleagues began to study the system's wavelet analysis method. In 1985, Daubechies proposed "orthogonal wavelet basis" and constructed a smoothing wavelet with tight support, as well as the multi-resolution analysis and rapid wavelet transformation proposed by Mallat. Wavelet Analysis has become one of the fastest-growing and most-introduced disciplines, involving almost all disciplines in the information field.

Why is the proposal of orthogonal wavelet basis and multi-resolution analysis becoming a major breakthrough in the development history of wavelet analysis? One of the main reasons is that the conversion coefficient is not redundant, and the signal can be decomposed into orthogonal subsignals that do not affect each other. In this way, the subsignals of the required features can be conveniently analyzed as needed, in this way, the signal details are well reflected.

2. Orthogonal Design of Embedded Software Systems

In fact, there are also more or less orthogonal ideas in the field of software system design. A commonly referenced model is the modelviewcontroller framework of the Smalltalk programming language (krner and Pope, 1988. This mode forcibly separates the input, processing, and output of the software system to form three modules: Data Model, view, and controller, as shown in 1. The "Data Model" in the figure includes the program design section. "View" indicates the user interface, and "controller" defines the interaction between users and views.

Figure 1 Model View Controller framework

Each part is an independent object, and each object has its own data processing rules. This feature separation happens to lead to the orthogonal nature of each module and reduce the redundancy between them. Therefore, this framework has become one of the most widely used models.

2.1 Design of orthogonal Embedded Software System

Without a doubt, orthogonal thinking makes the system design clearer and more convenient. So how can we make the embedded software system "orthogonal" better?

(1) design a system architecture with orthogonal

To design a system, you must first design the system architecture. The macro design of the system also reflects the orthogonal idea, as shown in figure 2.

Figure 2 system architecture

Among them, the underlying driver and RTOS are the only modules associated with the system hardware. They are directly responsible for dealing with the hardware, managing and controlling the hardware, and providing required driver support for the upper-layer modules; with the support of RTOS, the scheduler schedules and manages different task modules in real time based on system requirements to ensure smooth and balanced execution of all tasks; the top-level task modules have different functions to meet user needs. They are independent, orthogonal, and have no redundancy. They also provide corresponding data interfaces for communication with other modules to form an organic whole.

The entire system architecture also embodies orthogonal thinking. Different modules at each layer are responsible for mutually independent and orthogonal tasks. From the vertical perspective, the architecture is the same as the orthogonal wavelet, which can be expressed by the multi-scale spatial thinking, as shown in 3. The more core the feature is, the more rough the feature outline is. The more detailed the feature is, the closer it is to your needs.

Figure 3 multi-scale Embedded Software Architecture

(2) Maintain loose coupling between modules

When dividing software modules, an important principle is to ensure loose coupling between modules and high aggregation within modules as much as possible. In fact, the system is orthogonal, reducing the redundancy and association between modules. The ideal system structure is tree-like, as shown in figure 4.

Figure 4 ideal tree structure of the embedded system

The entire system is in a tree structure. The connection between modules can only have the call relationship between the upper and lower levels. There cannot be a horizontal relationship between modules at the same level, that is, there cannot be a mesh structure or a cross call relationship.

4. By calling the I2C bus read/write sub-module, You can implement the I2C one-master multi-slave communication sub-module and the RTC and EEPROM read/write sub-modules, but these sub-modules cannot call each other. Therefore, when the system has no requirements for the EEPROM, it is convenient to remove the EEPROM read/write sub-module without affecting other modules.

(3) Maintain loose coupling between tasks

RTOS is often used in embedded systems. different tasks and the frequency or sequence of task execution are determined based on system requirements. To meet the requirements, ensure that each task has a fixed execution cycle as much as possible, because this allows the task to be executed at the specified frequency and reduces communication and calls between tasks, it also enhances the predictability of the system.

For example, the execution frequency of the system spi communication resolution task (ProcSPI task) is 10Hz. To ensure normal communication, a task is required to detect in real time whether the SPI communication is faulty (that is, the FaultSPI task ). For ease of description, it is assumed that the only source of SPI communication failure is that the verification fails during data parsing, And the SPI communication failure can be determined when the error probability exceeds 50%. Figure 5 shows two methods for calling the FaultSPI task.

In the figure, MCscheduler is a system scheduler that can call different tasks at a fixed frequency. Figure 5 (a) shows that each time the SPI data is parsed, The FaultSPI task is directly triggered. Obviously, this method makes a lot of useless judgments as needed. Figure 5 (B) shows that the FaultSPI task is called by the system scheduler at a frequency of 1Hz. This task only needs to confirm that the SPI data has more than five verification errors to determine the SPI communication failure. In this way, the direct call relationship between two tasks is eliminated, that is, the loose coupling between tasks is maintained.

(4) Merge similar items

In units of modules or files, each module or file is oriented to an independent device or requirement, and each module is composed of multiple sub-modules. These sub-modules are as independent and single tasks or functions as possible. For example, GetTime (), SetTime (), GetFault (), PushFault (), etc. These submodules may call the same function or method, or use the same attribute variable, if these sub-modules are combined and encapsulated into a file, the called functions, methods, or variables do not need the "extern" statement (in C ), therefore, other files are hidden and invisible, which increases the security of the system. In addition, when this function or device is not required, the file can be conveniently removed from the project, it does not affect the work of other modules.

(5) Avoid writing similar functions

Similar functions are often difficult to maintain orthogonal, so similar functions should be avoided or unified into a function. For example, a system has multiple communication methods, but in the communication process, developers often need to determine their own communication protocols and verification methods; if you write your own verification function for each communication method, the system communication verification function is too fragmented while increasing the amount of code, you can consider unifying the Communication Verification Method in the system and writing a verification function to support verification of various types of communication. This will make the system concise and easy to maintain.

2.2 benefits of orthogonal Embedded Systems

Orthogonal thinking involves almost all fields of natural science. Using this idea to design embedded software systems also has many advantages.

Figure 5 FaultSPI task call Method

(1) Easy unit test

Throughout the entire software development cycle, software testing takes a very important proportion, or even exceeds 50% of the entire cycle. If you do not start testing after all the code has been compiled, the various bugs in different layers of the software system and various task modules often make it difficult for programmers to clarify their ideas, thus, the root cause of the problem cannot be determined. Therefore, before testing system integration, we should minimize bugs in each module, which requires effective unit tests when writing each module. The premise of ensuring the smooth and effective conduct of unit tests is that this module has a high degree of independence, which is precisely the problem solved by the orthogonal design. Figure 6 shows the test process of the embedded software system.

Figure 6 embedded software system test process

(2) easier maintenance

Software System maintenance personnel often find problems in the system, but do not dare to modify it easily, especially the underlying part of the system. The reason is very simple: the system has been running well and there are no errors, and because there is no complete documentation, there is a worry that new problems will occur after the changes. This concern reflects the fact that programmers have doubts about whether the current software system has good orthogonal requirements. Therefore, an embedded software system with better orthogonal design can enable software maintenance personnel to take over more quickly and smoothly, improve maintenance efficiency, and ensure high correctness.

(3) Ease of transplantation

Hardware updates are fast. To reduce product upgrade costs and speed up the upgrade, the software system must be highly portable, especially the application layer that is not directly associated with the hardware in the embedded software system. An orthogonal embedded system ensures the independence between the layers of the system from the vertical direction, and well separates the application layer from the physical layer.

(4) facilitate collaborative development

One of the advantages of DSP and ARM over traditional MCU is the use of pipeline technology to enable parallel execution of commands. We also hope that the software can be developed in parallel. Each module of an orthogonal embedded system is independent of each other. As long as the interface of each module is defined, software developers do not need to wait for other modules to complete their work. Figure 7 shows the development mode of orthogonal embedded software system.

Orthogonal embedded software systems can be easily divided into independent modules that do not interfere with each other. Each software developer or development team is responsible for different modules and works in parallel. Developers can communicate with each other during the development process (as shown by the dotted arrow in 7), and even help their peers solve problems at any time.

Figure 7 orthogonal Software System Development Mode

3 Summary

In many research fields, we have started to solve various problems with the help of orthogonal ideas for a long time. From the linear transformation of Euclidean space to the Force Analysis of objects in classical mechanics, from Fourier transformation to signal processing, from wavelet analysis to seismic exploration, quantum field theory, signal processing (including image and speech), mechanical fault diagnosis and the formulation of the 2000standard. These are all based on the orthogonal idea, the object is divided into multiple relatively independent parts, and then separately research each part, so as to simplify the complexity. Similar ideas exist in Embedded Software Design. Orthogonal embedded software systems can reduce the dependence between modules of the system, making the system easier to maintain and test, it is easier to port the system. From the perspective of the software development process, the orthogonal thinking can also help the R & D team to parallel jobs and collaborative development, reduce the waiting time and greatly improve the development efficiency, therefore, this idea is worthy of discussion and use by software designers.