Fitness trackers, ATMs and central heating all have one thing in common: they work thanks to embedded software. This controls, monitors and regulates the devices – in a way that users do not even notice.
However, to enable these applications to run unobtrusively in the background, special development know-how is required, especially in the rapidly changing IoT environment.
Documentation and organized testing are some of the biggest challenges when it comes to embedded development. Our experts from Concept Reply show what you should bear in mind and which processes and tools facilitate successful development.
Software documentation is an important part of software development. It explains the purpose and features the software offers. Moreover, good documentation improves efficiency during the development process and the maintainability of the software. Therefore, the following tips should be borne in mind when it comes to documentation:
Provide Basic Information
Use "Documentation-as-Code"
Rely on the Industry Standard for Code
Record Test Results
When it comes to embedded development, providing a README file that contains the basic information about the purpose and instructions for creating or executing the software is advisable. In addition, it should provide insight into protocol definitions, branching strategies, code style and testing strategy.
The architecture documentation should be an integral part of every embedded software project. Ensuring it is easy to access and update is important. For this reason, the experience of Reply according to the "documentation-as-code" approach is the key to success. Linking the project status to the documentation is essential. For this reason, we recommend using PlantUML and the C4 model. The description should be saved as a markdown file directly in the code repository. This facilitates easy access, uncomplicated updating and the possibility of version control.
Using the industry standard Doxygen for the code is helpful. This is freely accessible, easy to operate and can be integrated in the build system. This facilitates automatic execution for each build. As a result, access to APIs can be guaranteed, which can be useful in analyzing dependencies.
Apart from the documentation, which provides information about the general test strategy, tools used and the tests carried out, the test results themselves must also be documented. A predefined format (test report) is essential here. This should be provided with each release to ensure the status of the project is easy to understand at each specific release point.
Unfortunately, testing is repeatedly considered to be not essential for the end product, which is why it is often left out. This is why effort assessments should already include the testing whenever possible. If the testing is planned from the start, the effort involved is not too great. There are many different advantages: Tests show whether the implementation meets the requirements, ensure improved quality and reduce errors before the project reaches users. In addition, they can lower the overall development costs.
If possible, a comprehensive test strategy should be implemented. At any rate, the following tests should be carried out:
These check the behavior of an individual component isolated from the rest of the system. A component can be an individual function or a collection of related functions. The rest of the system is simulated in unit tests. If they are set up at the beginning of the project, unit tests can be written parallel to the implementation – without involving too much effort. Ideally, implementation of the unit tests should be automated to detect any regression at an early date.
These are an additional building block apart from the unit tests. Instead of testing modules in isolation, several modules are combined to examine their behavior and interactions. The challenges in the integration tests are similar to the unit tests. Although less of the system has to be simulated, the hardware dependence can still present a problem. If the complexity of the system is low enough, skipping the integration tests and replacing them with more comprehensive function tests can make sense.
These are carried out to confirm that the functionality demanded behaves as expected. Specific use paths are defined and tested based on the requirements without insight into the internal structure of the program. Even if it is not realistic that every use case is covered by tests, the tests should still be carried out. A comprehensive set of tests that covers the most important aspects of the software should be defined for this.
Concept Reply works exclusively according to these principles. Our experts have solid expertise and would be pleased to support you in your embedded development project. We take your specific situation into account in this regard and the tools you are already familiar with. Based on this, we jointly develop secure, reliable and cost-efficient products or improve your processes.
)
Concept Reply is an IoT software developer specializing in the research, development and validation of innovative solutions and supports its customers in the automotive, manufacturing, smart infrastructure and other industries in all matters relating to the Internet of Things (IoT) and cloud computing. The goal is to offer end-to-end solutions along the entire value chain: from the definition of an IoT strategy, through testing and quality assurance, to the implementation of a concrete solution.
,allowExpansion)