Engineers never forget the need to deliver projects that meet quality, schedule, and budget goals simultaneously. One effective approach is to leverage the lessons learned accumulated over the years by the embedded systems development community. Below, we will explore some important experiences that have brought best practices to embedded development. Feel free to use them.

Systems engineering is a broad discipline that encompasses all development work from aircraft carriers and satellites to the embedded systems that achieve their performance. We can apply systems engineering methods to manage the lifecycle of embedded systems engineering from concept to disposal at the end of use. The first phase of a systems engineering solution is not to establish system requirements but to develop a systems engineering management plan. This plan will not only define the engineering lifecycle for the system and the design reviews 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 customer groups based on the sequence of engineering events and the prerequisites for each phase. In short, it can illustrate 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 works.

• Non-functional requirements define issues such as regulatory compliance and reliability.

• Environmental requirements define requirements related to operating temperature, shock and vibration, and electrical environment (e.g., EMI and EMC).

In larger-scale development work, these requirements will extend 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 the development process 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 extend down from higher-level specifications and can be traced.

Generating a good set of requirements requires us to thoroughly think through each requirement to ensure it meets the following criteria:

• It is necessary. Without requirements, our project will not succeed.

• It is verifiable. We must ensure that the requirement can be achieved through inspection, testing, analysis, or demonstration.

• It is feasible. The requirement is technically achievable under given constraints.

• 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. We generally use “must” for mandatory requirements and “should” for non-mandatory requirements. Non-mandatory requirements allow us to express necessary system attributes.

Once we establish 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 for 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 help identify any challenging testing methods early in the development process and also help us determine the resources needed.

• Identify technical performance metrics. These metrics come from the compliance matrix and consist of various requirements that carry risks of non-compliance.

Every engineering project encompasses a certain amount of budget, which we should allocate to the solutions identified in the architecture. Budget allocation ensures that the project meets overall requirements and that each module’s design lead understands the allocation of the module to create appropriate solutions. Typical areas of budget allocation include overall quality of functionality, total power consumption, reliability defined by mean time between failures or success probability, and the legitimate crosstalk between signal types in the design (generally a set of common rules applicable to a large number of functions). One of the most important aspects of establishing an engineering budget is ensuring we have sufficient contingency allocation. However, we must overcome the idea of contingency plus contingency, as this can lead to serious technical issues affecting schedule and cost.

Assigning a technology readiness index to each technology used in our architecture, combined with the compliance matrix, can help us identify where the technical risks lie.

3Manage Technical Risks

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 outlines how we will achieve this requirement. One of the best ways to demonstrate this is by using the Technology Readiness Level (TRL). TRL has 9 levels, describing the maturity of the design from observed basic principles (TRL1) to full functionality and field deployment (TRL9). Assigning a TRL to each technology used in our architecture, combined with the compliance matrix, can help us identify where the technical risks lie. We can then initiate a TRL development plan to ensure that low TRL areas are elevated to the required TRL level as the project progresses. The content involved in this plan can ensure that we achieve and test the correct functionality as the project advances or perform functional or environmental/dynamic testing during the project’s progression.



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 related software.

4Create Architecture

　

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 into 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 obvious, 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 related software. Of course, a key to modular design is good interface documentation for modules and functional behaviors.

A critical aspect of this architecture is to demonstrate how to create the system at a high level, so the engineering team can easily understand how it is implemented. This step is also crucial for supporting the system throughout its lifecycle.

When determining our architecture, we need to consider a modular approach so that we can reuse it not only on the current project but also in future projects. Modularity requires us to consider possible reuse from day one and requires us 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 (COTS) modules for certain requirements. COTS modules allow us to develop systems faster because they enable us to focus our work on the areas of the project that benefit most from our expertise.

The power architecture of the system is an aspect that requires careful consideration. Many embedded systems will require isolation 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 this module requires secondary regulation to provide voltage for the processing core and conversion devices. We must carefully guard against significant switching losses and efficiency drops at these stages. Efficiency reductions mean increased thermal dissipation in the system, which, if not correctly addressed, can affect 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. The reason for this requirement is that devices like FPGAs and processors have switching frequencies that far exceed the levels that the control loops of linear regulators can handle. As noise frequency increases, the noise suppression capability of linear regulators decreases, leading to the need for additional filtering and decoupling techniques. Failure to understand this relationship can cause problems 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 architecture level, we must consider the clock distribution network: Are we fan-outting a single oscillator across multiple development boards, or are we 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 time period (if required).

• 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 (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 can reduce the signal-to-noise ratio of mixed-signal converters. The same is true when 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, ensuring that reset is used only where necessary. For example, SRAM-based FPGAs generally do not require reset.

If we are using asynchronous activation of reset, we need to ensure that its removal does not lead to metastability issues.

5Clearly Define Interfaces

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 (ICDs). 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 rated power of the connector pins, the required number of insertions and withdrawals, as well as any shielding requirements.

When considering the types of connectors for our system, we should ensure that using the same type of connector in subsystems does not lead to adverse cross-connections. By using different types of connectors or employing different connector keys (if supported), we can avoid the possibility of cross-connections.

Connectivity is one of the first aspects we consider when establishing the budget requirements identified earlier. In particular, we can use crosstalk budgets to guide our pin assignment definitions. The example shown in Figure 3 illustrates the importance of this process. Rearranging pin assignments to layout ground reference voltage (GND) pins between signal 1 and signal 2 can reduce mutual coupling and the resulting crosstalk.



Figure 3: Connectivity is one of the most important features of interface definition.

Interface Control Documents (ICDs) must define the system grounding, especially when the project requires external EMC. In such cases, we must be careful to avoid allowing noisy signal grounds to radiate.

Engineers and project managers possess 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 to the project, its previous performance is a good indicator of its future performance.