Author: Adam Taylor, Chief Engineer at e2v
Engineers never forget the need to deliver projects that meet quality, schedule, and budget goals simultaneously. One effective method is to leverage the lessons learned from the embedded systems developer community over the years. Let’s explore some important experiences that have brought best practices to embedded development. Feel free to take what you need.
Systems engineering is a broad discipline covering all development work from aircraft carriers to satellites and the embedded systems that realize their performance. We can apply systems engineering methods to manage the embedded systems engineering lifecycle from concept to disposal at the end of its operational life.The first phase of a systems engineering approach is not to establish system requirements, but to create a systems engineering management plan.This plan will not only define the engineering lifecycle of the system and the design reviews that the development team will conduct but also define the expected inputs and outputs of these reviews. The plan can provide clear definitions for project management, engineering, and stakeholders based on the sequence of engineering events and the prerequisites for each phase.In short, it can showcase expectations and deliverables.
With a clear understanding of the engineering lifecycle, the next step in systematic thinking is to establish the requirements for the embedded system being developed. A good set of requirements should cover three aspects:
-
Functional requirements define how the embedded system will operate.
-
Non-functional requirements define issues such as regulatory compliance and reliability.
-
Environmental requirements define aspects such as operating temperature and shock and vibration, as well as electrical environment (e.g., EMI and EMC).
In larger development efforts, these requirements will cascade down from higher-level specifications and can be traced, such as system or subsystem specifications (Figure 1). Without higher-level specifications, we must engage stakeholders during development to establish a clear set of stakeholder requirements, which will then be used to establish the embedded system requirements.
Figure 1: In development work, requirements cascade down from higher-level specifications and can be traced.
Generating a good set of requirements requires us to think carefully about each requirement to ensure it meets these criteria:
-
It is necessary. Without requirements, our project cannot succeed.
-
It is verifiable. We must ensure that the requirement can be realized through inspection, testing, analysis, or demonstration.
-
It is achievable. Within given constraints, the requirement is technically achievable.
-
It is traceable. The requirement can be traced from lower-level requirements and can trace higher-level requirements.
-
It is unique. This criterion prevents ambiguity between requirements.
-
It is simple and clear. Each requirement specifies one function.
To reflect intent, specific language is often used when defining requirements. Generally, we use “must” for mandatory requirements and “should” for non-mandatory requirements. Non-mandatory requirements allow us to express necessary system attributes.
Once we have established our baseline requirements, best practice is to create a compliance matrix that indicates how each requirement is met. We can also begin to establish our verification strategy by assigning a verification method to each requirement. These methods typically include testing, analysis, inspection, demonstration, and cross-reading. Creating requirements based on the compliance and verification matrix allows us to:
-
Clearly understand system behavior.
-
Demonstrate verification methods to both internal testing teams and external customers. This can not only identify any challenging testing methods early in the development process but also help us determine the resources required.
-
Identify technical performance indicators. These indicators come from the compliance matrix and consist of various requirements that pose risks of non-compliance.
Every engineering project encompasses a certain amount of budget, and we should allocate it to the solutions identified in the architecture. Budget allocation not only ensures that the project meets overall requirements but also ensures that each module’s design lead understands the allocation of the module to create appropriate solutions. Typical areas for budget allocation include overall quality of functionality, total power consumption of functionality, reliability defined by mean time between failures or success probabilities, and proper crosstalk between signal types in the design (usually a set of general rules applicable to many functions). One of the most important aspects of establishing the engineering budget is to ensure we have sufficient contingency allocation. But we must overcome the idea of contingency on top of contingency, as this can lead to serious technical issues affecting schedules and costs.
Allocating a technology readiness index for each technology used in our architecture, combined with the compliance matrix, can help us identify where technical risks lie.
From the generation of the compliance matrix and engineering budget, we should be able to identify technically challenging requirements. Each of these risky requirements should have a clear mitigation plan that will describe how we will achieve that requirement. One of the best ways to demonstrate this is to use the Technology Readiness Level (TRL). TRL has 9 levels, describing the maturity levels of design from observed basic principles (TRL1) to full functionality and field deployment (TRL9). Assigning TRL to each technology used in our architecture, combined with the compliance matrix, can help us identify where technical risks lie. We can then initiate a TRL development plan to ensure that as the project progresses, low-TRL areas rise to the required TRL levels. The content involved in this plan can ensure we achieve and test the correct functionality or perform functional or environmental/dynamic testing as the project progresses. 
Figure 2: In this power architecture example, the output rail of the module requires secondary regulation.
This architecture should not be limited to hardware (electrical) solutions but should also include the architecture of FPGA/SoC and associated software.
After understanding the behavior required of the embedded system, we need to create an architecture for the solution. This architecture will consist of requirements grouped by successful functional blocks. For example, if the embedded system must handle analog inputs or outputs, the architecture will include analog I/O modules. Other modules may be more evident, such as power regulation, clock, and reset generation.
This architecture should not be limited to hardware (electrical) solutions but should also include the architecture of FPGA/SoC and associated software. Of course, a key aspect of modular design is the creation of good interface documentation for modules and functional behaviors.
A critical aspect of this architecture is to show how the system is created at a high level so that the engineering team can easily understand how it is implemented. This step is also critical for supporting the system throughout its operational lifecycle.
When determining our architecture, we need to consider a modular approach that can be reused not only in the current project but also in future projects. Modularity requires us to think about possible reuse from day one and to archive each module as an independent unit. For internal FPGA/SoC modules, general interface standards like ARM® AMBA® Advanced Extensible Interface (AXI) help facilitate reuse.
A significant advantage of modular design is the ability to use commercial off-the-shelf modules for certain requirements. Commercial off-the-shelf (COTS) modules allow us to develop systems faster because, with COTS, we can focus our work on the part of the project that benefits most from our expertise.
The power architecture of the system is a design aspect that requires careful consideration. Many embedded systems will require isolation of AC/DC or DC/DC converters to ensure that failures in the embedded system do not propagate. Figure 2 shows an example of power architecture. The output rail from the module requires secondary regulation to provide voltage for the processing core and conversion devices. We must carefully guard against serious switching losses and efficiency drops occurring in these stages. Because reduced efficiency means increased thermal dissipation in the system, which, if not correctly addressed, can impact the reliability of the unit.
We must carefully understand the behavior of the linear regulators used and the requirements for further filtering on the power lines. This requirement arises because devices like FPGAs and processors have switching frequencies that far exceed the levels that the control loop of the linear regulator can handle. As the noise frequency increases, the noise suppression capability of the linear regulator decreases, necessitating additional filtering and decoupling techniques. Failure to understand this relationship can cause issues with mixed-signal devices.
Another important consideration is the clock and reset architecture, especially in cases where multiple development boards need to be synchronized. At the architectural level, we must consider the clock distribution network: Are we fan-outting a single oscillator across multiple development boards, or using multiple oscillators of the same frequency? To ensure robust reliability of clock distribution, we must consider:
-
Oscillator startup time. We must ensure that reset is activated throughout the entire time cycle (if needed).
-
Oscillator skew. If we are fan-outting an oscillator across multiple development boards, is timing critical? If so, we need to consider skew caused by traces on the PCB (due to connectors) and skew caused by the buffers themselves.
-
Oscillator jitter. If we are developing mixed-signal designs, we need to ensure that we use low-jitter clock sources, as increased jitter will reduce the signal-to-noise ratio of mixed-signal converters. The same applies when we are using gigabit-level serial links, as we need to use low-jitter clock sources to achieve good bit error rates on the link.
We must also pay attention to the reset architecture to ensure that reset is only used where necessary. For example, SRAM-based FPGAs typically do not require reset.
If we are using asynchronously activated resets, we need to ensure that removing it does not cause metastability issues.
Formal documentation of internal and external interfaces provides clear definitions for each interface at the mechanical, physical, and electrical levels, as well as protocols and control flows. This formal documentation is often referred to as Interface Control Documents (ICD). Of course, it is best to use standard communication interfaces whenever possible.
One of the most important aspects of interface definition is the “connectivity” of external interfaces. This process considers the pin assignments of the required connectors, the power ratings of the connector pins, the required number of insertions and withdrawals, as well as any shielding requirements.
When considering connector types for our system, we should ensure that using the same type of connector in subsystems does not lead to adverse cross-connection. By using different types of connectors or adopting different connector keying (if supported), we can avoid the possibility of cross-connection.
Connectivity is one of the first aspects we address when considering the budget requirements we established earlier. In particular, we can use crosstalk budgets to guide our pin assignment definition. The example in Figure 3 illustrates the importance of this process. By rearranging pin assignments and placing the ground reference voltage (GND) pin layout between Signal 1 and Signal 2, we can reduce mutual inductance and the resulting crosstalk.
Figure 3: Connectivity is one of the most important features of interface definition.
Interface Control Documents (ICD) must define system grounding, especially when external EMC is required by the project. In this case, we must be careful to avoid allowing noisy signals to radiate.
Engineers and project managers have a range of strategies to ensure that the embedded systems they deliver meet quality, cost, and scheduling requirements. However, when projects encounter difficulties, we can be confident that, barring significant changes in the project, its past performance is a good indicator of its future performance.
Scan the QR code to follow the WeChat public account “Embedded Hardware Development” and grow with those who love hardware. Any good ideas or suggestions can be replied directly in the public account.
Long press to automatically scan and follow
Sharing is a virtue. If you like the content of “Embedded Hardware Development”, you can forward it to your friends to let more people see it.