In the first three sections, we explained three program organization models: strictly hierarchical, componentized, and distributed. Within the team, we are used to calling it "layered and divided distribution" for simplicity. Combining these three strategies can basically determine the static organization relationship of each software module in a product. Therefore, "layered and divided distribution" is a static organization structure. At present, although they have their own priorities, almost all products developed by our team follow the static organizational structure of "layered, block-by-step".
Why does this static program organization continue to evolve? After reviewing the entire evolutionary process, I found that this model is not so much designed as it is grown.
In the real world, demands are constantly iterating, but human resources are always in short supply. In order to allow fewer people to do more work, platform-based R&D and high-reuse modules are almost our most natural choices. After eating the sweetness once, we will want to eat more, and the positive cycle again and again will push us to the current state. This is what I will repeatedly emphasize when communicating with many friends. Don't worry about the current chaos. As long as we can firmly grasp a few key hands, time will make us look like we once envied.
The static organizational structure of "layered and divided distribution" not only provides a program organization model, but also subtly affects our research and development model.
A core point of the static organizational structure of "layered and divided distribution" is platform-based R&D. The so-called platform-based R&D is not to take a single product as the R&D task, at least one field direction as the R&D task. For example, the focus of this book is microcomputer protection products, which actually include many product types, not only the comprehensive overcurrent protection and differential protection mentioned in this book, but also motor protection, bus tie protection, engine protection, distance protection, etc. Kind of type. Based on the platform-based R&D concept, when developing microcomputer protection products, a common platform will be built first, and then various products will be quickly developed based on the common platform.
Sometimes platform-based R&D will even cross field directions. For example, we have a communication management machine product for the power industry. Based on the platform-based R&D concept, this product has crossed many fields. It is placed in the meter industry as a meter reading system such as collectors and concentrators. , Put in the oil field industry is the oil field RTU product, each field protocol and drive may be different, but the overall structure and design concept are basically the same. As shown in the figure below, the red frame is the direction of the oil field RTU field. Similar to oilfield RTU, based on platform-based R&D, other products are also a configuration subset of the code product library.
Another core point of the "layered and divided distribution" static organization structure is high reuse. In fact, the platform-based R&D model is also a catalyst for building high-reuse modules. In order to make the platform more applicable, we have to iteratively optimize various platform basic modules. With more iterations, many excellent high-reuse software modules will naturally be born.
Based on the platform-based R&D model and high-reuse characteristics, the personnel organization structure of the R&D team will also slowly adapt. In the past, the R&D concept was based on the product boundary. Naturally, many project teams were built, and each project team was responsible for a product. Based on the platform-based R&D model, R&D personnel began to differentiate into two types of R&D personnel, platform and field, because each person can better focus on their own field, so many field experts will be born, and because it is often necessary to consider the products of various industries as a whole , So it will also give birth to some architects. With these excellent domain experts and architects, you can further feed back products, not only to improve the efficiency of research and development, but also to start research and development of some high-level products, which is precisely the most lacking in the domestic industrial field.
◇◇◇
Based on the platform-based R&D model, unlimited possibilities can be derived. We derived a special software module in practice: virtual device. The virtual device is divided into two parts: virtual hardware and virtual applications, which can be run separately. As shown in the figure below:
Embedded software development depends on hardware, which will bring many difficulties to project organization. From the beginning of the project to seeing the first complete hardware board, a project needs to go through many links such as demand analysis-schematic diagram-PCB-board-welding-testing. Even at this time, you need to complete the driver before you can start application code debugging. Does this process make the software team wait foolishly!
A better strategy is to add a virtual hardware module to simulate a complete device on a desktop computer. With the help of virtual hardware modules, the work efficiency of the software group can be greatly improved. In our team, almost 80% of the code is developed based on virtual devices, most of which are synchronized with the hardware group. After the new board is made, only additional driver R&D is needed, and then you can quickly enter the whole equipment integration test link.
Virtual hardware can not only improve the efficiency of the software group, but also provide an additional test environment. For example, the AD sampling module of a product we developed, found that the calculation accuracy is very high when the input is around 50hz, but the calculation accuracy begins to decline rapidly when the reference frequency is offset. It is necessary to know that there are a lot of high-frequency components when the power system fails. This will affect the accuracy of the microcomputer protection action.
Based on the virtual hardware, we did two tests: firstly, confirm that the calculation accuracy of the high-frequency components on the virtual hardware meets the requirements, indicating that the algorithm is okay; secondly, use the simulation data of the virtual hardware instead of AD sampling to calculate in the device, and find that the calculation accuracy also meets the requirements Claim. Therefore, we can determine that the problem occurs in the hardware AD sampling loop.
It was later discovered that the AD sampling loop of the hardware is a filter, and the filter has an impact on the amplitude of the input signal of different frequencies, which is the spectrum curve often mentioned in digital signal processing. Our AD sampling loop is shown in the figure below, which is a typical second-order RC filter loop.
The corresponding spectrum curve is shown in the figure below (based on matlab simulation):
Based on the spectrum curve, it is obvious that different frequencies correspond to different amplitude scaling factors. Therefore, if an inverse adjustment factor can be added in the calculation process, the amplitude calculation accuracy will be improved.
With the continuous iteration of products, the platform modules are also in continuous iteration, but at this time another problem will arise. Each specific product will only use a subset of the platform modules. How to integrate many modules in the platform What about testing?
To solve this problem, we will build a virtual application module whose focus is not on the application, but on coupling various platform modules through an application to facilitate integration testing.
In addition, the virtual application module is also a good learning reference module. When various application developers are conducting field product research and development, countless documents are not as applicable as a simulated product. In actual work, the starting point for the R&D of products in many specific fields is to fork a virtual application module and make modifications based on this module, which is simple and fast.
Virtual applications and virtual devices constitute a virtual device module, and the virtual device module in our team is far beyond a simple software module. After get off work in the evening, I made a call on the spot, and I quickly ran the virtual device on the engineering cloud computer to solve the problem quickly. The feeling of handling the problem with ease is very enjoyable. Maybe only if I have really experienced it can I appreciate it. Wonderful.
◇◇◇
Based on the platform-based R&D model, the program directory organization structure also needs to be adapted accordingly. The following is a possible program file organization format suitable for microcomputer protection devices for your reference.
relay 整个项目总目录结构
boot boot程序，用于主程序和参数下载
MMIBoard 面板can分布式程序
…… 不同尺寸液晶对应不同程序版本
expandBoard 各种di,do,ai和ao分布式扩展板
expand16DI 16路DI扩展板
expand16AI 16路AI扩展板
……
hardware 硬件相关资料，包括原理框图，版本，调试说明等
commit 最终提交的各版本程序
XXXXXX(2013-xx-x,V1.xx,0xabcd) 发布程序（时间，版本，校验码）
XXXXXX(2014-xx-x,V2.xx,0x1234)
……
documents 文档目录
设计文档 组织架构设计相关文档
对用户文档 包含对用户文档，如技术说明书，规约文档，工程说明等
测试文档 集成测试文档和测试记录
工作日志.doc 包含版本说明，现场各种反馈等信息
sysCfg 配置软件，基于平台统一研发
maintain 维护软件，基于平台统一研发
simEquip 虚拟设备平台统一构建部分
sysPlat 平台程序部分
sysPlat.h 平台部分给领域产品研发公开的统一接口
driver 驱动层目录
hardwareAbstract.h 硬件抽象层对外统一引用头文件
winSim win仿真实现，对应虚拟硬件部分
…… 具体实现
STM32F207 基于ST207芯片的驱动实现
…… 具体实现
…… 其他驱动版本实现
basePlat 基础平台层
xf 动态执行框架
gui gui模块
script 脚本
……
api API抽象层
apiInclude.h API抽象层对外的统一引用头文件
ai.h,ai.c,aiPrivate.h ai模块
di.h,di.c,diPrivate.h di模块
……
history.h,histroy.c 历史数据模块高级应用
trend.h,trend.c 趋势数据高级应用
……
app
appInclude.h app模块对外统一引用头文件
main.c 统一的主程序入口框架
103Protocol.c 103规约程序
a11Protocol.c A11规约程序
……
relayBoard 各种保护产品程序目录
simEquip 虚拟设备
550 过流综合保护装置
para 配置软件生成的参数存放目录
IAR_ST207 基于iar编辑器和st207芯片的开发环境
VS2017_SIM 基于VS的仿真运行环境。
src 特定领域代码
……
587T 变压器差动保护装置
……
supportToolsSrc 外围支持软件总目录
commSrc 外围支持软件公共代码
createS19 程序格式转换软件
MIMIC 主接线图工具软件
simDisturbFile 模拟采样数据
……
tools 外围支持软件可执行程序统一路径
clear.bat 用于清除整个项目中的中间文件，便于版本提交
Due to space limitations, although the complete directory structure has not been shown, everyone can clearly see that the program code is organized into platform parts and specific domain parts, and platform code accounts for a relatively large portion.
One extra point is that the above directory structure is just a simple example. The directory structure of the actual project may be much more complicated. For example, it will distinguish between source files and header file directories, divided into multiple compilable libraries, containing a large number of configuration files, and even some Configuration files and directories are generated by configuration software.
◇◇◇
The static organizational structure of "layered and partitioned distribution" not only affects the organizational model of the program, but even reconstructs the research and development model. In the next chapter, we begin to explore the dynamic organizational structure of the program. What surprises will it bring us?
——————————————
I am Xiaomaer, an embedded software engineer who longs for conscience and soul. Welcome your company and travel. If you are interested, you can add a personal WeChat account nzn_xiaomaer to communicate, and you need to note the word " different dimension ".