The old television cliché where the police detective tells the suspect that he can take the easy way by cooperating or the hard way by resisting, can apply to DO-254 compliance as well. Experience has shown that the easy way to DO-254 compliance is almost always through cooperation and an earnest desire to learn, adjust, and comply, as opposed to resisting and looking for loopholes in an effort to avoid compliance as much as possible. In fact, the seemingly eternal quest to avoid DO-254 is ironic in that it can take more time and effort to avoid DO-254 than it does to just embrace it and comply with it.

Taking the hard way or the easy way is a choice, and one that eventually confronts all airborne electronic hardware (AEH) developers. The choice that is eventually made will be based on considerations that are specific to the organization making the decision. Whatever the choice is, it will not be right or wrong—it will simply reflect the path that the organization wants to follow, and should only be judged according to how well it will work for them. Some choices will work better than others, and while choosing the easy way might be a better way, it is not the only way, nor is it the “right” way.

As discussed in the introductory chapter of this book, DO-254 is a compendium of the tried and true engineering best practices employed by the AEH industry, and in particular by companies that are known for producing the highest quality and safest aircraft in the world. As such it contains a wealth of useful information that can, in the long run, result in fewer problems, which in turn can translate into lower risk and even lower overall cost. The benefits of understanding and employing the processes in DO-254 can be especially valuable for companies that want to improve their engineering processes and culture, and/or that want to enter the AEH marketplace—those companies would do well to use DO-254 as a textbook on how to create a high integrity engineering culture. Trying to learn the equivalent skills on their own would be significantly more difficult and time consuming than simply embracing DO-254 and learning what it has to offer.

Much of DO-254 is fundamental engineering knowledge. For instance, the design process in Chapter 5 has been part of the engineer’s basic tool box for generations. There is nothing new or mysterious about it, and it has proven itself over the generations to arguably be the best way to conduct a design effort, so while it may be common knowledge it is still one of the industry’s best practices and is therefore rightfully included in DO-254. In contrast, DO-254 also contains other techniques, including most of Appendix B, that are more esoteric or even arcane, but they also have their roles in boosting the design assurance of a system or component, and so they too rightfully belong in DO-254. So in the final analysis there is little in DO-254 that has no role to play in supporting design assurance.

If DO-254 has any weaknesses, perhaps the most significant would be its reliance on requirements as the lynchpin for its design and verification processes. Or more realistically, the weakness is not in its reliance on requirements, because the use of requirements for both design and verification is one of the most effective and reliable means for expressing, implementing, and verifying functionality. The weakness only appears when the design and verification processes are based on poor quality requirements. Requirements are the input to the processes in DO-254, so the use of poor quality requirements will (not might) weaken and undermine the integrity of the output (the electronic hardware). Ironically, requirements are among the weakest and most poorly managed aspects of engineering in many engineering environments, and at the same time they are among the most difficult to improve. If ever there were a perfect example for bad habits dying hard, bad requirements practices would consistently be a prime contender for the title.

So if the lynchpin of the DO-254 design and verification processes is good requirements, then it is only logical to make sure that the requirements are of high quality. However, DO-254 does not provide detailed guidance on the characteristics of high quality requirements that are optimal for its processes, only that requirements should define the intended functionality of the electronic hardware. The transition from intended functionality to optimized requirements is what this book attempts to describe in its Requirements and Validation chapters. While those chapters provide an introduction to how requirements can work with DO-254 rather than work against it, they cannot provide the highly detailed treatment that will enable engineers to learn all that there is to learn about it. Giving requirements the full treatment to facilitate mastering those requirement skills would require a book of its own, and is beyond the scope of this book anyway: while the characteristics of requirements can be critical to the processes in DO-254, they are not really within the scope of DO-254 and are included in this book as additional guidance that can potentially save practitioners a great deal of money, time, and frustration. It can also facilitate the understanding of how the processes in DO-254 are intended to work.

If the attributes of a highly effective, efficient, and productive design program were listed, they would look similar to the contents of DO-254:

•  Plan all aspects of the project to ensure that:

•  Risk is minimized.

•  The product is built right and delivered on time.

•  The customer is in agreement with what is being built.

•  The certification authorities are in agreement with the project and its product.

•  Use a design process that will:

•  Use independent reviews to reveal as many errors as possible.

•  Systematically decompose functionality from the top down, and record the decomposed functionality in additional requirements and traceability.

•  Base the design on written requirements so everyone will be in agreement on what the electronic hardware has to do.

•  Confirm that the requirements are actually correct.

•  Catch errors as early as possible by confirming at multiple stages in the design process that the design is being developed properly.

•  Compare the design to its requirements to ensure that the design satisfies all of its requirements.

•  Use a verification process that will:

•  Confirm that the design is correct by comparing it against the same set of requirements that was used to create it.

•  Confirm that the design does what it is supposed to do, not what it was designed to do.

•  Test the design in a repeatable and documentable way.

•  Confirm that the design was completely verified.

•  Control the design and its data to make sure that:

•  Every version of every data item is tracked and protected.

•  None of the data will be misidentified or lost.

•  No one can make unauthorized changes.

•  Every problem is documented and tracked to closure.

•  Monitor the project to ensure that everyone is following the rules and not taking potentially damaging shortcuts.

•  Where possible reuse previously designed electronic hardware to reduce cost and risk.

•  Manage electronic components to minimize risk from obsolescence and unreliable suppliers.

•  Make sure the tools always produce the correct output.

These attributes address the most common sources of error in an attempt to address as many error sources as possible.

Proper planning is essential for identifying and mitigating as many sources of risk as possible. Addressing technical and safety related risks (another way to describe design assurance) are especially important for AEH programs, and is really what DO-254 compliance is all about. It also provides transparency into the entire program for the aircraft manufacturer and the certification authorities so they will know that the AEH will be developed, tested, and manufactured in a way that will not only produce high integrity and reliable electronic hardware, but that it will comply in every way with the certification basis. Writing the plans and standards during the planning process is not about satisfying a DO-254 objective; the early transparency provided by the planning process is critical for establishing confidence between the AEH supplier, the aircraft manufacturer, and the certification authorities. The plans also establish an agreement between the three parties on both the tasks that will be performed and on the expectations of all three parties that can prevent any of them from wandering too far off course. So from the AEH supplier’s perspective, the plans and standards should be approached as a contract that limits the customer or regulators from imposing additional design assurance related burdens, or from changing their minds about how the project will be conducted. In other words, if approached with the right perspective the planning process is the AEH supplier’s friend and should not be put off as long as possible.

Engineers will sometimes object when first confronted with a structured design process, but most will eventually turn around once they have seen the benefits. The engineer stereotype seems at odds with this initial reluctance to embrace a design process because logical minds often seek the kind of structure and order that a design process offers. However, designing hardware can seem more like fun (as opposed to work) when conducted without the restraints of a design process. The problem is that designing AEH is a very serious business that can be fun under the right circumstances, rather than being a fun business that can create serious AEH designs under the right circumstances. The difference is where the emphasis is placed, and the correct emphasis is on the AEH design rather than on the fun of creating it. That does not mean that designing AEH cannot be a satisfying and fulfilling experience, and for most engineers it is, but it does mean that the safety of the AEH should take priority, and that priority should be the basis for the design process.

Like other aspects of DO-254 compliance, complying with a structured design process is a lifestyle choice that can make things easier or harder depending on the choice. In addition, the way in which the design process is complied with can make even more of a difference in how easy or hard the process becomes. This book includes guidance on how complying with DO-254 can be made as easy as possible:

•  Plan ahead

•  Perform the activities in the intended manner and order

•  Combine activities (for example, performing requirements capture, functional decomposition, and traceability at the same time) to reduce needless rework and also to make all of the activities as effective as possible

•  Invest heavily in writing requirements that will provide high integrity functional expression and harmonize as much as possible with the processes in DO-254

•  Employ effective verification but still focus on creating a high quality design that will not need verification (in other words, do not use verification as a kind of safety net by skimping on the design under the assumption that if any errors are made the verification process will find them)

•  Approach the processes in DO-254 not as separate activities but from the higher perspective where they become a unified web of complimentary interlocked and interacting processes

•  Use a high integrity design philosophy that is focused on preventing potential errors (Design Assurance Through Design Practice)

•  Always pay attention to configuration management

Verification is one of those processes that is sometimes treated as being somehow inferior to design engineering. It can be tempting to treat verification as a peripheral activity that is performed more because it has to be done than because it should, and to make it entirely separate from design. This separation between design and verification, while good from the independence perspective, can be damaging if carried too far. Independence does not require separation; in fact, close cooperation, communication, and synchronization between the design and verification activities are far more efficient and effective than building a wall between them.

Verification should be embraced as the partner of design, and it should be performed as thoroughly as possible. There can be a temptation to minimize verification because it can be expensive and time consuming even when optimized according to the guidance offered in this book, but when tempted to shortcut verification, consideration must be given to the fact that every piece of hardware will always be completely verified one way or another: what is not tested in the lab will eventually be tested in the aircraft. Since what is not verified in the lab will be verified in flight, the question of how much verification to perform should be answered only after full consideration of the potential effects of discovering an error in service, including the potential of a catastrophic failure. No verification program can find every possible failure mechanism, but programs often find their most interesting and potentially serious failure sources under the most obscure testing conditions (i.e., robustness verification). Ironically, it is the obscure testing conditions that are often seen as being the least productive and therefore are the most tempting to cast aside.

Configuration management is not the most glamorous or interesting process, but it plays an important role in ensuring the AEH is designed, tested, and produced faithfully and as free of errors as possible. Without it the potential for serious errors would be considerably higher. Likewise, process assurance may operate in the back-ground, but its effect on design assurance can be profound.

Reusing previously developed hardware is a good business model and can result in higher quality hardware with a higher level of design assurance at less cost. This is ideal from the business, design assurance, and certification perspectives, so reuse should be employed where possible.

DO-254 has a total of thirty-four objectives that need to be satisfied to comply with the guidance it provides. One of the thirty-four objectives is to develop a design from the requirements. Consider the implication: one thirty-fourth or 2.94 percent of the objectives in DO-254 align with what engineers are trained, educated, and experienced at doing—designing electronic hardware. The other 33 objectives, or over ninety-seven percent of DO-254, entails planning, managing, standardizing, verifying, and validating the requirements and design and associated data. The over-whelming majority of objectives in DO-254 concern topics other than creating a design. It behooves us to learn, develop, and place value on the requisite skills for the other aspects of design assurance that are as refined as the engineering design skills themselves.

No process will eliminate all errors, nor can they completely plug all sources of errors, but employing countermeasures against the common error sources can still chip away at errors and noticeably improve the design assurance of the product, in turn ensuring that the AEH on our aircraft is as safe as it possibly can be. In the end, that is what DO-254 is all about.