Background introduction
DAB (Device Automation Bus) is a lightweight protocol based on MQTT communication, which is mainly used to connect consumer electronics (such as smart TVs and game consoles) in the living room, and achieve automated testing. Since equipment authentication needs to support DAB functions, we face the urgent task of developing DAB software. Time, heavy tasks, and huge challenges.
The first stage: learning and research
1. Learn the DAB protocol
In the early stage of the project, I thoroughly studied the DAB protocol and organized it into a document to share with the team. Through fast learning, I have a comprehensive understanding of the overall architecture and function of DAB, and sorted out 28 core interfaces. In the process, I found the lack of logo in the first edition protocol. In the second edition protocol, the equipment identification function is added.
2. The status quo of the research equipment
According to the DAB agreement, I conducted a detailed investigation of the basic situation of the current equipment, and focused on analyzing the following issues:
-
•
What components and functions need to implement DAB?
-
•
Is there any components or functions in existing equipment?
-
•
How to maximize the existing resources?
Through investigation, I clarified the status quo of the equipment and formulated two implementation solutions.
The second stage: scheme design and technology selection
1. Two sets of implementation plans
I designed two sets of DAB implementation solutions:
-
•
Plan: Deploy MQTT services outside the TV.
-
•
Second: Reuse the MQTT service inside the TV.
After evaluation, the second plan is more advantageous in the certification scenario because it reduces external dependence and simplifies the deployment process. However, the MQTT service inside the reuse equipment also brings potential security risks. To this end, we have taken the following safety measures:
-
•
Cloud authorization mechanism.
-
•
Automatically close the function.
2. Develop language selection
In terms of the choice of development language, we comprehensively considered the following factor:
-
•
DAB open source DEMO language support.
-
•
Language compatibility of certification equipment.
Although the team is more familiar with C ++, we finally chose to shorten the development cycle and catch up with the equipment certification time point. In addition, we integrated DAB services into the existing process, reducing the number of services and reused the equipment function.
The third stage: the development and challenge of the version
1. Development process
In the process of using DAB, we made full use of its unit testing function to significantly improve development efficiency and quality. However, we also encountered some challenges:
-
•
Memory leakage problem: Due to the increase in process memory, this problem was solved by adjusting the parameters.
-
•
Adaptation of interface and device functions: The DAB interface needs to be connected with multiple device function modules, involving the collaboration of multiple project teams, and the communication cost is high.
2. Limitation of the version
Although the version has successfully supported the DAB certification of multiple devices, the following problems still exist:
-
1.
Some devices do not support.
-
2.
Safety -related processing and business logic are distributed in different processes, which are responsible for different departments, and the coordination costs are high.
The fourth stage: the reconstruction and optimization of the C ++ version
1. Development background
In order to solve the limitations of the version, we have developed the second version of DAB and implemented C ++. This version not only avoids the problems of not supporting some equipment, but also integrates the logic of security processing to the inside of DAB, reducing the complexity of cross -departmental communication.
2. Multi -platform support and flexibility
In the second version of the design, we pay particular attention to flexibility and multi -platform support:
-
•
Support running on Windows, company development platforms and devices.
-
•
It can be operated independently or embedded in other processes.
To achieve this goal, I added a adaptation layer to block the differences in different platforms. The adapter layer provides a variety of implementation strategies, which is dynamic according to the operating scene, so as to speed up the development and debugging speed.
Fifth stage: experience and reflection in development
1. Project management and communication
Due to the urgent time, I took the following measures to ensure the smooth progress of the project:
-
•
Communicate with the participants in advance to clarify the goals, time requirements and precautions.
-
•
Use the JIRA tool to decompose and track the task.
-
•
During the development process, it is timely corrected to ensure that the project is planned as planned.
2. Technical design and optimization
In terms of technical implementation, I follow the principle of orthogonality and minimize the coupling between modules. For example:
-
•
Use a function object to replace the interface to make each module independent and unreasonable.
-
•
Wit test for each module to improve the quality and speed of development.
However, in the design of the adaptation layer, I once made an over -design error and tried to introduce the Netflix C language to objects into the project. After reflection, I adjusted the design in time and simplified the code structure.
The code before adjustment:
#include <string>
#include <vector>
#include "dab/dab_api.h"
extern "C" {
struct DAB_API_IO {
DAB_Interface iface;
bool (*getKeyList)(std::vector<std::string>& list);
bool (*pressKey)(const char* key, int durationMs);
bool (*catpureImage2png)(const char* file);
};
const DAB_API_IO& getDABAPIIO();
}Adjusted code:
#pragma once
#include <string>
#include <vector>
extern "C" {
bool dab_api_getKeyList(std::vector<std::string>& list);
bool dab_api_pressKey(const char* key, int durationMs);
bool dab_api_catpureImage2png(const char* file);
}The highlights and regrets of the second edition
Bright spot
-
1.
Unit test: Get rid of environmental dependence, quickly perform testing in the development of cloud platforms, equipment and other environments to improve development efficiency.
-
2.
Flexible deployment: Support to run separately on Windows, Development Cloud Platforms and devices, and can also be embedded in other processes, which greatly improves flexibility.
-
3.
Adaptation layer: Isolation changes, make the code logic quickly and stable.
-
4.
Flexible access strategy: Provide convenience for the switching of each platform, and can work smoothly even if the dependency items do not have.
-
5.
Combined with practice: I have proposed many application scenarios and extensions that are useful for testing.
-
6.
Efficient development speed: Through the appropriate model and strategy, the development speed has been greatly accelerated.
-
7.
Document generate code: Practice the method of generating code from a document, which accelerates development and ensures accuracy.
Pity
-
1.
The deployment method of embedding process: Increased dependence on security, especially for safety.
-
2.
Time to combine with practice: At first, it mainly focused on certification needs, and failed to combine with practice and users earlier, resulting in slow maturity.
Summarize
Through the development of DAB, I deeply realize the challenges and sense of accomplishment of completing complex projects within the urgent time. From the learning to the implementation of multiple platforms, we not only solved the technical problems, but also optimized team collaboration and project management processes.
Keyword: DAB, MQTT, C ++, Multi -platform support, orthogonal principles, unit testing, project management