We follow a five-step process in designing the firmware

In recent years, we have spent significant time consulting and training software development teams. We have also played an essential role in developing firmware for successful and enduring products and product lines.

Mastering the creation of a robust firmware architecture and re-architecting legacy software concurrently can be a challenging and time-consuming process.

However, we have streamlined this journey into five distinct steps, serving as a foundation to guide our team in getting off to the right start.

Step 1: Determine the necessary specifications.

Clear requirements are crucial before starting the architectural design of an embedded system or its firmware. Precisely defined requirements outline the necessary attributes and qualities of a product.

What does the product offer the user? It's essential to note that a well-crafted requirement concentrates on the 'what,' avoiding details on the 'how' to accomplish a particular feature within a broader context.

Each requirement statement should possess clarity and testability to ensure it is easily understood and verifiable. A clear statement is concise and straightforward, requiring no further explanation.

The key element is testability. A well-written requirement permits the easy creation of a collection of tests to verify that the requirement has been met.

A complete set of requirements consists of written statements that begin with the key phrase "the [product] should ...".

These statements avoid specifying implementation details, ensuring that they remain clear, unambiguous, and testable. As a result, a sturdy architecture depends on requirements that are well-defined.

Step 2: Differentiate between architecture and design

Over time, we have observed that many engineers and their managers struggle to differentiate between the various components or levels of firmware engineering.

The architecture of the system is the top layer of the product's functionality. This layer defines long-lasting characteristics, making it difficult to change. As a result, it's important to thoroughly assess the targeted and approved purposes of the product.

The design of the system serves as the intermediate layer of implementation. It is important to note that the architecture does not include the specifics of function or variable names. These details are documented in the firmware design document.

Examples of these details include task names and associated responsibilities in designated subsystems or device drivers, the selected RTOS brand (if applicable), and interface specifications between subsystems.

Implementation is the most detailed stage of the process. Clear interfaces established during the design phase allow engineers to concurrently execute individual component parts.

The importance of these challenges may differ in various industries, but they consistently involve three crucial obstacles that require careful attention: meeting tight deadlines, conducting thorough testing, and effectively managing diversity. Addressing these concerns represents the last three steps.

Step 3: Time Management

The product specifications will include timeframes. Usually, products have a mix of non-real-time, soft-real-time, and hard-real-time requirements.

Establishing soft deadlines can often be challenging. Once the deadlines are set, the first step is to transition as many timeliness requirements from software to hardware as possible.

Maintaining a clear distinction between real-time functionality and the rest of the software holds great value for two reasons. Firstly, it simplifies the design and implementation of the non-real-time software.

Segregating timeliness requirements from the main software body allows for less experienced implementers to author code that will not jeopardize user safety.

Combining real-time functionality also simplifies the analysis required to prove meeting deadlines.

Step 4: Test-Oriented Design

Testing is crucial for every embedded system. Conducting testing at multiple levels is mandatory and highly important. The main testing levels comprise:

1. System tests verify if the product meets or exceeds the specified requirements. Typically, tests should be developed outside of the engineering department but can also be integrated into a test harness created by engineers.

2. Integration tests verify that a specified group of subsystems, as defined in the architectural diagrams, interact accurately to produce meaningful outcomes. The most effective approach to developing integration tests is usually led by a testing team or a software engineering expert.

3. Unit tests confirm that the designated software components, specified in the intermediate design, are operating as intended by the developer.

Unit tests evaluate the public API (Application Programming Interface) that the component presents to other elements. Developers should ideally create unit tests for their own code to maximize their effectiveness.

Among the three, system tests are typically the simplest to develop. An engineering or factory acceptance test may require creating a test harness, but this is generally less complex than integration and unit tests, which demand a deeper understanding of the device's internal operations.

To simplify the development, use, and maintenance of integration and unit tests, it's beneficial to structure the firmware in alignment with a software testing framework. The optimal strategy is to design the communication between all software elements at the levels that are to be tested.

Step 5: Prepare for Change

During the firmware architecture phase, it's crucial to prioritize handling feature diversity and product customizations. To prepare for potential changes, it's essential to understand the types of alterations that may occur in your specific product.

Structure the firmware in a way that simplifies implementing these changes. With appropriate software architecture, handling feature diversity can be achieved through a single software build that utilizes compile-time and/or run-time behavior switches within the firmware.

Similarly, a stronger architecture facilitates the integration of new features smoothly without compromising the functionality of the product.