Embedded Firmware Design
Offer system tests verify that the product exceeds the stated requirements
Embedded Firmware Design which offer system tests verify that the product exceeds the stated requirements
We design firmware in five steps
Over the past few years, we've spent a large amount of time consulting with and training software development teams and had already developed the firmware inside successful long-lived products or product families. Although learning to create solid firmware architecture and simultaneously re-architecting legacy software may take months of hard work, five key steps are easily identified which we use this step-by-step process to help our team get started on the right foot.
Step 1: Identify the requirements
Before we can begin to architect an embedded system or its firmware, we must have clear requirements. Properly written requirements define the WHAT of a product. WHAT does the product will do for the user, and note that a properly written requirement is silent about HOW this particular part of the overall WHAT is to be achieved.
Each requirement statement must also be two other things: unambiguous and testable. An unambiguous statement requires no further explanation. It is as clear and as concise as possible. Testability is the key. If a requirement is written properly, a set of tests can be easily constructed to verify that requirement is met. A proper set of requirements is a written list of statements each of which contains the key phrase "the [product] should ..." and is silent about how it is implemented, unambiguous, and testable. Thus, good architecture depends on good requirements.
Step 2: Distinguish architecture from design
Over the years, we’ve found that many engineers (as well as their managers) struggle to separate the various elements or layers of firmware engineering. The architecture of a system is the outermost layer of HOW. Architecture describes persistent features; the architecture is hard to change and must be got right through careful thinking about intended and permissible uses of the product.
The design of a system is the middle layer of HOW. The architecture does not include function or variable names. A firmware design document identifies these fine-grained details, such as the names and responsibilities of tasks within the specific subsystems or device drivers, the brand of RTOS (if one is used), and the details of the interfaces between subsystems.
An implementation is the lowest layer of HOW. If the interfaces are defined sufficiently at the design level above, individual engineers are able to begin implementation of the various component parts in parallel. These difficult parts vary in importance somewhat from industry to industry, but always center on three big challenges that must be traded off against each other: meeting real-time deadlines, testing, and diversity management. Addressing those issues comprise the final three steps.
Step 3: Manage time
Some of the product's requirements will mention explicit amounts of time. Most products feature a mix of non-real-time, soft-real-time, and hard-real-time requirements. Soft deadlines are usually the most challenging to define in an unambiguous manner, test, and implement. With deadlines identified, the first step in architecture is to push as many of the timeliness requirements as possible out of the software and onto the hardware.
Keeping the real-time functionality separate from the bulk of the software is valuable for two important reasons; first, because it simplifies the design and implementation of the non-real-time software. With timeliness requirements architected out of the bulk of the software, code written by novice implementers can be used without affecting user safety. The second advantage of keeping the real-time functionality together is it simplifies the analysis involved in proving all deadlines are always met.
Step 4: Design for test
Every embedded system needs to be tested. Generally, it is also valuable or mandatory that testing be performed at several levels. The most common levels of testing are:
1. System tests verify that the product as a whole meets or exceeds the stated requirements. System tests are generally best developed outside of the engineering department, though they may fit into a test harness developed by engineers.
2. Integration tests verify that a subset of the subsystems identified in the architecture diagrams interact as expected and produce reasonable outcomes. Integration tests are generally best developed by a testing group or person within software engineering.
3. Unit tests verify that individual software components identified at the intermediate design level perform as their implementers expect. That is, they test at the level of the public API (Application Programming Interface) the component presents to other components. Unit tests are generally best developed by the same people that write the code under test.
Of the three, system tests are most easily developed, and of course, a test harness may need to be developed for engineering and/or factory acceptance tests. But this is generally still easier than integration and unit tests, which demand additional visibility inside the device as it operates. To make the development, use, and maintenance of integration and unit tests easy, it is valuable to architect the firmware in a manner compatible with a software test framework. The single best way to do this is to architect the interactions between all software components at the levels you want to test.
Step 5: Plan for change
The key consideration during the firmware architecture phase of the project is the management of feature diversity and product customizations. To plan for change, you must first understand the types of changes that occur in your specific product. Then architect the firmware so that those sorts of changes are the easiest to make. If the software is architected well, feature diversity can be managed through a single software build with compile-time and/or run-time behavioral switches in the firmware. Similarly, new features can be added easily to a good architecture without breaking the existing product's functionality.
- Jarltech Touch Screen Solutions
Cleaning touch panel surfaces as become necessary because of the pandemic rage of COVID-19.Read More
- Industrial Automation
See the applications that how we can be the electronic product provider or IoT solution tailored to your environment.Read More
- Smart Retail
Jarltech's Smart Retail solution is a complete suite of AI-based video analytics products for the retail environment.Read More