Our firmware development process is based on a five-step approach

Over the past few years, we have conducted extensive consultations and training with software development teams while developing firmware for successful, long-lasting products and product families. While creating robust firmware architecture and re-architecting legacy software can be a complex, months-long process, we have identified five key steps that form a step-by-step approach, enabling our team to start on the right track.

Step 1: Define the Requirements

Before an embedded system or its firmware can be designed, clear requirements are essential. Well-defined requirements specify what the product will do for the user without detailing how these objectives will be achieved. It is essential that each requirement statement is unambiguous and testable. An unambiguous statement is clear and concise, requiring no further explanation.

Testability is a key factor; a well-written requirement should allow for straightforward test creation to verify its fulfillment. A proper set of requirements consists of statements starting with 'the [product] should ...', focusing on what is needed rather than how it is achieved, and ensuring clarity and testability. Consequently, effective architecture relies on well-defined requirements.

Step 2: Differentiate Between Architecture and Design

It has been our experience that many engineers and their managers have difficulty distinguishing between the various aspects of firmware engineering. System architecture represents the highest level of HOW, defining the product's enduring features and making it challenging to alter once established. It requires careful consideration of the product's intended and permissible uses to ensure it is done correctly.

The design of a system represents the intermediate layer of how. While architecture outlines the broad features, it does not specify function or variable names. A firmware design document fills in these details, including task names and responsibilities within specific subsystems or device drivers, the RTOS used (if any), and the specifics of interfaces between subsystems.

The implementation phase represents the lowest level of the project management hierarchy. When the interfaces are clearly defined at the design stage, engineers can begin implementing the various components in parallel. While challenges may vary by industry, they typically fall into three main categories: meeting real-time deadlines, testing, and managing diversity. These issues are addressed in the final three steps.

Step 3: Time Management

Some product requirements will specify explicit time constraints. Typically, products include a combination of non-real-time, soft-real-time, and hard-real-time requirements. Of these, soft deadlines are often the most challenging to define clearly, test, and implement. Once deadlines are identified, the initial step in the architectural process is to offload as many time-sensitive requirements from the software to the hardware as possible.

The separation of real-time functionality from the main software provides two key benefits. Firstly, it simplifies the design and implementation of the non-real-time software. By removing time constraints from the bulk of the code, even novice developers can contribute without compromising user safety. Secondly, consolidating real-time functionality makes it easier to analyse and ensure that all deadlines are consistently met.

Step 4: Design with Testing in Mind

It is essential to test every embedded system at multiple levels. In many cases, testing at various levels is not only valuable but also mandatory.

The most common levels of testing include

1. System tests have confirmed that the product as a whole meets or exceeds the specified requirements. It is recommended that these tests be developed outside the engineering department, although they can be incorporated into a test harness designed by engineers.

2. Integration tests are conducted to ensure that subsets of the subsystems, as outlined in the architecture diagrams, interact properly and yield the expected results. These tests are typically developed by a testing team or individual within the software engineering department.

3. Unit tests guarantee that individual software components, as defined at the intermediate design stage, operate as intended. These tests concentrate on the public API (Application Programming Interface) that the component offers to other components. Typically, unit tests are developed by the same individuals who write the code being tested.

Of the three types of tests, system tests are the most straightforward to develop. A test harness may be required for engineering and factory acceptance tests, but this process is generally simpler than integration and unit tests, which require more internal visibility into the device's operation. To streamline the development, use, and maintenance of integration and unit tests, it's advisable to design the firmware in a way that aligns with a software test framework. The most effective approach is to structure the interactions between all software components at the levels you intend to test.

Step 5: Prepare for Change

During the firmware architecture phase, it is essential to prioritize the management of feature diversity and product customizations. To effectively plan for change, it is crucial to first identify the types of changes that are likely to occur in your product. Then, the firmware should be designed to accommodate these changes in the most efficient manner possible. A well-designed architecture allows for the management of feature diversity through a single build with compile-time and/or run-time switches, while also enabling the seamless addition of new features without disrupting existing functionality.