Architectural Patterns

Starting an embedded project from scratch means progressively stepping towards the final solution by going through all the research and development phases and considering the synergy among all the parts involved.

Software development needs to evolve accordingly throughout these phases. In order to get the best results without excessive overhead, there are a few best practices to follow and tools to discover.

This chapter describes a possible approach toward configuration-management tools and design patterns, based on real-life experiences. Describing this approach may help you to understand the dynamics of working in a team focused on producing an embedded device or solution.

We will discuss the following topics in this chapter:

• Configuration management
• Source code organization
• The life cycle of an embedded project
• Security considerations

By the end of the chapter, you will gain an overview of the architectural patterns useful...

Configuration management

When working as a team, coordination and synchronization can be optimized to improve efficiency. Tracking and controlling the development life cycle smoothens the development flow, cutting downtime and costs.

The most important tools known to help manage the software life cycle are the following:

• Revision control
• Issue tracking
• Code reviews
• Continuous integration

Different options exist for the four categories. The source code is synchronized among developers through a revision control system. Issue tracking systems (ITSs) usually consist of web platforms that keep track of the activities and known bugs of the system. Code reviews can be encouraged with specific web-based tools and enforced through rules on the revision control systems.

Continuous integration tools ensure that build and test execution tasks are scheduled to automatically execute, periodically or upon changes in the code, collecting test results and notifying...

Source code organization

The code base should contain all the source code, third-party libraries, data, scripts, and automation needed to build the final image. It is a good idea to keep self-contained libraries in separate directories so that they can be easily updated to newer versions by replacing the subdirectory. Makefiles and other scripts can be placed in the project’s root directory.

Application code should be short and synthetic and access the modules abstracting the macro functionalities. Functional modules should describe a process while hiding the details of the underlying implementation, such as reading data from a sensor after it has been properly sampled and processed. Aiming for small, self-contained, and adequately abstracted modules also makes the components of the architecture easier to test. Keeping the majority of the logic for the application components separated from their hardware-specific implementation improves portability across different platforms...

Security considerations

One of the most important aspects to consider when designing a new system is security. Depending on the characteristics of the system, the requirements, and the evaluation of the risks, different countermeasures may be appropriate. Security-enhancing features are often a mix of hardware and software efforts to provide specific protections against known attacks.

Vulnerability management

Software components keep evolving as new features are introduced, and defects are fixed along the way. Some of the defects that are discovered and fixed in a later version may impact the security of the system running outdated software if proper action is not taken promptly. Once vulnerabilities in third-party components are fully disclosed to the public, it is no longer a good choice to keep running outdated code.

Older versions with known defects running on public networks have an increased possibility of becoming the attack surface for attempts to damage the system...

The life cycle of an embedded project

Modern development frameworks suggest splitting the work into smaller action points and marking milestones through the project development while producing intermediate working deliverables. Each deliverable focuses on giving a prototype of the entire system, with the missing features temporarily replaced using dummy code.

These recommendations seem particularly effective for embedded projects. In an environment where every error could be fatal to the entire system, working on small action points, one at a time, is an efficient way to promptly identify defects and regressions while working on the code base, provided that a Continuous Integration (CI) mechanism is in place from the early stages of the development. Intermediate milestones should be as frequent as possible, and for this reason, it is advisable to create a prototype of the final system as soon as possible in the development phase. This has to be taken into account when actions are...

Summary

The methodologies that have been proposed are meant as an example of reference patterns used to design and manage the development of embedded projects. While it is possible that some of the patterns described may not apply to all projects, the goal of this chapter is to encourage embedded architects to look for improvements in the process that may result in a more efficient and less expensive software life cycle. Finally, we analyzed the possibility of increasing security by adding appropriate processes and components when required by the use case.

In the next chapter, we shall analyze what happens at boot time inside the embedded system, and how to prepare a bootable application using a simple, bare-metal, main-loop approach.