Learning to write requirements is similar to learning a new language: it takes time to learn a language, but with practice progress will be made. This learning experience applies to both individuals and organizations. Organizations may also have to experience a shift in culture as they adopt effective requirements writing and reading skills. Many practices and habits may need to change to adopt more effective and useful styles of writing and organizing requirements.
The information presented in this section on requirements is the culmination and synthesis of years of experience working on requirements writing and management. Best practices have been learned and gathered from numerous aerospace projects that span organizations working across the globe. After many years and numerous discussions, it became apparent that some ways of capturing, conveying, and organizing requirements were more effective than other methods. It also turns out that using this way of capturing, conveying, and organizing requirements streamlines the verification process and increases the test coverage of the design. Traceability became easier, readability improved, and comprehension of system functions was more apparent.
Traceability efforts and data can also be more streamlined and useful when the structure of the requirements mirrors the structure of the design, or in other words, if the requirements are written and decomposed from top to bottom and are organized by function, their structure will naturally default to a form that will match the functional structure of the resulting hardware. Ideally, requirements are isomorphic with respect to the design they describe.
Most important, there is a potential for more effective and more efficient verification when the requirements, the starting point for verification, is approached with the requirements tailored to that purpose. While it may seem counterintuitive, requirements that are written to be verifiable are always appropriate for designing, but the reverse is not always the case. The one exception to this rule is requirements that are written according to the requirement concepts presented in this chapter, since those requirements will be written to be equally appropriate for both design and verification. Thus in the general sense it is arguably more effective for requirement authors to get into the habit of writing (or learn to write) requirements with verification, rather than designing, in mind.
The authors do not intend to convey that there is a right or wrong way to capture or specify requirements. Rather, the idea is to convey a paradigm that is compatible with the objectives and guidance of ARP4754, DO-254, and DO-178. The ideas expressed pertain mostly to functional requirements, although it would be possible to apply the ideas to other types of requirements as well.
The paradigm presented here is often difficult for engineers and designers. Engineers and designers like to solve problems and design solutions. The educational system for engineers strongly emphasizes design, while requirements and functionality are often overlooked. Thus training may be needed to update people’s background and reference experiences with requirements. Companies can organize internal training that introduces new or updated requirements standards and company templates for requirements. Training is also an effective way to get a team to work in a consistent manner, to work through differing perspectives, and begin to apply new skills.
To work well with DO-254, requirements should specify what the hardware must do and not how it should do it. This is the fundamental reason for requirements: to capture the intended functionality of the hardware and provide the starting point for both the design and verification activities. However, documenting functionality is often a less valued behavior or skill set for an engineer. Adopting a black box perspective on a system or part and describing what it does rather than describing the details of how it does it can be a challenge. As it turns out, a functional perspective can also be a learned or acquired skill. It also turns out that designers do think about the intended function when they design a circuit, but the “what” is often subservient to the “how.”
Appreciating the difference between “what” and “how” can be confusing at first, particularly if a person was trained in an engineering culture that stressed the “how” over the “what.” However, there are analysis techniques that can facilitate the discrimination between functionality and implementation, and at the same time facilitate the understanding of the underlying concepts.
The way in which requirements are used, as well as the way in which they are written, is often influenced—or even dictated—by the prevailing engineering culture. Requirement writing skills are often learned from examples in the workplace: engineers use requirements documents from previous programs as the starting point, and may also look at customer or industry documents. While examining other requirements documents is a helpful practice, the issue of whether the requirements are well formed is often not considered. In the absence of any other guidance on requirements capture, the engineer will often assume that the requirements are well written or that their requirements should be written in a similar, or identical, manner.
Requirements are central to the design and verification processes. The design is developed from the requirements, traces to the requirements, and is peer reviewed against the requirements. The verification is requirements based—test cases for hardware testing and simulations are based on the requirements. Traceability is established between requirements, test cases, test procedures, and test results. These relationships are depicted in Figure 4.1. Using a well-formed set of requirements as the entry into design and verification will ensure that the resulting design complies with the requirements and that the verification demonstrates that the requirements were met. Rework of requirements due to ill-formed starting conditions can result in redesign and/or rework of the verification.
Ideally, requirements capture should start before the design begins. The hardware design is generated from the requirements. A design based on requirements helps ensure that the intended function is implemented. Extreme care must be used if a design exists and the requirements are backfilled or reverse engineered; this scenario often creates requirements that describe the existing design rather than the intended function.
FIGURE 4.1 Central Role of Requirements
The certification process and the regulations applicable to system and equipment installed on an aircraft state that the system must perform its intended function when installed on the aircraft. The industry has adopted the notion of requirements to express the aircraft functions. Thus, the use of requirements is needed to demonstrate compliance to the aviation regulations.
Requirements also inform the designer about what they need to design. Many designs are possible, but they may or may not be the correct design or a design that meets the requirements. Also, because verification relies on requirements-based testing, the use of requirements that describe the design rather than the design’s function will result in design-based testing, which will only prove that the design is the design. It will not prove that the design performs its intended function, which is the ultimate goal of verification as defined in DO-254.
Requirements allow functions to be established and described from the highest levels. The requirements are allocated down through the various levels until they are realized as a design. For example, ARINC outputs from a system are described at the system level, then at the circuit card level where they are generated, then at the software and PLD level where they are designed and implemented. The functions and their requirements flow all the way down to the level at which the design is formulated and can be realized. As design decisions are made through the various levels of the system, these decisions can add additional requirements to support the design decisions. These additional requirements are known as derived requirements. They are derived in the sense that they flow out of the design needed to realize the upper level requirement(s) and its function.
Hardware verification in DO-254 is requirements based. Requirements-based verification is central to showing that the system performs its intended function. Referring back to the FARs, systems and equipment installed on an aircraft need to be verified to ensure that they perform their intended function under all foreseeable operating conditions. The intent of the regulation is accomplished with requirements-based verification (as long as the requirements express the intended functionality).
Requirements can also be conceived as independent of the design. The same set of requirements can be given to different designers that come up with different designs, all of which meet the requirements. One design could be all analog components, another design could be all discrete combinatorial logic components, another design could use a microprocessor and software, while a fourth design could use one or more PLDs. Any design that meets the requirements could be acceptable with the caveat that the design meets the availability and failure probabilities.
Requirements can be formulated, organized, and shaped according to the associated function. DO-254 talks about functional elements and associated design. One very effective method of organizing a set of requirements is to group them by the functions or functional elements. In other words, put all the requirements for a function in one part of the document. The requirements within that group can be further organized to express the behavior of all the outputs from the function. Skillfully writing and organizing requirements can produce a set of requirements that is structurally similar to the design, or isomorphic, and facilitates the verification. The technique of organizing requirements by functional element, then the outputs within the functional element, uses the architectural principle of letting form follow function. Writing requirements with a specific sentence structure also leads to requirements that are isomorphic with respect to the design and verification processes.
Finally, requirements describe what a system or function does, not how it works. Understanding the functionality allows a good fit with the hazard assessment and safety processes. Separating the requirements from the design also allows the mind to develop distinct internal models about what a system or function does that is separate from the design or how the system does what it does. One technique that works well in keeping these abstractions distinct and separate is to imagine the system or function as a geometric object where only the inputs and outputs can be observed and described. The art of writing requirements is to keep the attention and description limited to the inputs and outputs of the function. This will also guarantee that the function can be verified through review, analysis, and test.
Too often, requirements specifications contain design or implementation requirements, which can make verification very difficult or even ineffective. Thus the author of the requirements should ideally be able to write about the functionality without describing design or implementation details. Normally this will be the person who knows the most about what the hardware item needs to do, which in turn is often the person who is responsible for the next higher level of hardware (parent hardware) because that is the person who determines how the hardware item will function and what its role will be. The design decisions at the parent hardware level will define virtually all of the requirements in the child hardware, especially the requirements that define how the item will interface and interact with the parent hardware, and that define how the item will contribute to the parent hardware’s functionality.
PLD requirements would ideally be written by the circuit card designer who selected the PLD because the card designer normally will know most about what the PLD must do in the circuit card. The best time to capture the requirements for a PLD is while the circuit board design is in work because the circuit card designer is working out the details of the PLD’s role in the card while looking at the data sheets for all the circuits that the PLD is connected to. The circuit card designer also does not yet know how the PLD will be designed, so the PLD requirements will tend to be more functionally oriented.
Similarly, the requirements for the circuit board are ideally written by the assembly or system designer. As with the PLD, the designer of the upper level will know what functions are to be performed by the circuit card and the signals that the circuit card connects to.
For requirements that describe function rather than design, the requirements author does not need to be a competent circuit card design engineer to write the requirements for the circuit card. Although understanding circuit card designs may help the requirements author and ensure that the requirements are realistic and realizable, it can also bias the requirements toward design and implementation. Similarly for a PLD, the requirements author does not need to be a competent PLD design engineer to write the requirements for the PLD. On the other hand, requirements that competently describe a design must be written by a competent designer.
Figure 4.2 shows the generalization of this concept. The requirements are ideally captured by the person that works on the design of the next higher level of abstraction within the system. Note too that not all systems will have or need all the levels shown in Figure 4.2. CCA in the figure stands for circuit card assembly.
In general the item’s designer is not always the best person to write the item’s requirements. The item’s designer is likely to know the most about the technology to be designed, but as previously stated, such competence is not a prerequisite for writing good functional requirements, and in fact may bias the requirements toward implementation over function. In addition, the item’s designer may not be the person who knows most about the item’s intended functionality. There is certainly no official guidance that discourages an item’s designer from writing his or her own requirements, but experience has shown that it is not always the best path to high quality requirements because it often results in incomplete requirements (requirements written by the designer may lack detail because the designer is too close to the topic and will not need the details for his or her own use of the requirements) as well as requirements that capture intended design rather than intended functionality (designers often look ahead and specify what they intend to design rather than look back at what the design has to do, plus they may not have an extensive understanding of how the item will integrate into the parent hardware). Overall, it is just a better idea to have the person who knows most about what the item has to do write the requirements.
FIGURE 4.2 Requirements Capture
However, as with any rule, there are always exceptions. In this instance, the designer may be an acceptable requirements author if they also designed the parent hardware or collaborated with the parent hardware’s designer to either design the parent hardware or to define the functionality that gets allocated to the item, so they will fully understand the item’s intended functionality. Without this understanding the designer may have a tendency to fill in the gaps in their functional knowledge with intended implementation.
System requirements development is governed by the processes and activities described in ARP4754 and are the starting point for DO-254 processes. Requirements for systems are driven by many factors. The system safety processes will generate performance constraints for the availability and integrity of a function. The availability expresses the continuity of a function while the integrity expresses the correctness of a function. The availability and integrity will become drivers for various architectural features of a design. These features will then generate requirements. It is helpful (and necessary) to tag or specifically identify these safety specific requirements to allow them to be traced down through the design to the actual implementation.
System processes will also gather the intended function for a system as requirements that specify the desired system performance under the associated operating conditions. The functions for a system are created from a combination of customer wants, operational constraints, regulatory restrictions, and implementation realities. Customer requirements will vary with the type of aircraft, the function of the aircraft (cargo or passenger, business jet or commercial transport), and the type of system. Customers may also drive requirements based on the intended payload of the aircraft, knowledge of routes that will be flown, operating practices used by the customer or airline, maintenance practices used by the customer or airline, and any desired features. Operational requirements are used to define the functions for the flight crew, maintenance crew, and support staff. The operational requirements will consist of the actions, decisions, information, and timing for all personnel interactions and interfaces.
Performance requirements define the attributes of a system that make the system useful to the customer and aircraft. Performance requirements will define expected system performance, system accuracy, fidelity, range, resolution, speed, and response times. Physical requirements specify the physical attributes of the system and include size, mounting provisions, power, cooling, environmental restrictions, visibility, access, adjustment, handling, storage, and production constraints.
Maintenance aspects can also add requirements for systems. Scheduled and unscheduled maintenance may have different types of requirements. Some maintenance may be certification driven in order to meet system safety failure probabilities. Maintenance requirements should specify actions and interfaces used to access and test the equipment.
Interfaces for power and signals also add requirements to systems. System designs need to be compatible with allocated power sources and associated power budgets. Interfaces can also have specific impedance and electrical characteristics that need to be met for proper operation. Interface characteristics are requirements and they are different than the definition of signaling through an interface. The meaning of data or signals on an interface is captured in an interface specification. The interface specification is meant to be a definition and should not be treated as requirements. Instead, the requirements should specify how all signals designated as system outputs in the interface specification are generated and how all signals designated as system inputs in the interface specification are used.
Last but not least, the certification process itself may add specific requirements for a system. The certification regulations or certification authorities may specify features, attributes, or specific implementations. These types of requirements are typically added to show compliance with airworthiness regulations.
Once the system requirements are gathered, they can be sorted into various types: physical, environmental, performance, functional, and so on. The process starts with the requirements that originate at the aircraft and system level. These requirements are validated through review, analysis, and even testing to determine whether they are the correct requirements and whether they are complete. The initial validation of all the requirements is performed in the scope of ARP4754. The entry into DO-254 assumes a validated (complete and correct) set of system requirements. The entry into DO-254 also assumes that the initial concept for the allocation of functions to software, electrical components, mechanical components, and electronic components such as PLDs has been done.
FIGURE 4.3 Requirements Decomposition
As the system design evolves, additional requirements are added to support the design decisions made along the way. For example, a system level decision that chooses to implement some of the system functions in software may add hardware requirements for a microprocessor and how it interfaces with peripheral circuitry. The software development process itself will add requirements as the software architecture, design, and packaging is chosen. Systems that need redundancy and/or dissimilarity will introduce additional requirements due to the architecture and topology.
Figure 4.3 shows the decomposition of functional requirements and the additional derived requirements added during the design process.
TYPES OF REQUIREMENTS FOR ELECTRONIC HARDWARE
Within the requirements allocated to the electronic hardware, there are some categories or types of requirements worth noting. These categories were developed based on observations of what engineers were actually putting in their requirements documents. Repeated occurrences of general types of requirements led to the categorization to help requirements authors understand what types of requirements are most effective and what types are not. These categories include:
• Functional requirements
• Implementation requirements
• Application requirements
• Input requirements
• Indirect requirements
• Referred requirements
• Global requirements
• Derived requirements
Functional requirements are the most recommended type of requirement. Functional requirements describe behavior and can be expressed as how an output responds to an input (or time event). In addition, functional requirements are testable, expressed in quantifiable terms, and are independent of the design and implementation of the hardware.
Implementation requirements describe specific aspects of the hardware design or implementation. Implementation requirements are not recommended as they skip the functionality and instead describe how to design or implement a function. Requirements that describe a specific design or implementation are not testable; they usually have to be verified through an inspection. Implementation requirements also compromise the integrity of the design and verification processes because there is simply no way to verify intended function. The verification will only prove that the design is the design or that the implementation is the implementation. If specific design or implementation features are important, they can be captured as textual information in the requirements document and not treated as a formal requirement. Some design or implementation features can also be elaborated in hardware design standards which also separates them from the requirements. The design or implementation features can also be documented in the hardware design documentation. Putting these details in the hardware design documentation allows them to be used to drive lower level derived requirements, if required.
Application requirements are used by requirements authors to describe how the hardware will be used. While this is good information, it should not be expressed as requirements. Information about the application of the hardware is beyond the scope of the functionality of the hardware. In addition, the application cannot be verified within the scope of verifying the functionality. While information about how the hardware is used is important, it should be documented as textual description and not as a requirement. The application should be considered, but any specific functions required for the application should be captured as functional requirements for the hardware.
Requirements for inputs are also often written. As with other nonfunctional requirements, input requirements are not recommended. No amount of design associated with an input requirement can cause the input to happen. Requirements should express how the hardware responds to the presence or occurrence of an input. Input behavior is important and can be captured as descriptive text or in an interface specification. However, a requirement for the electrical characteristics of an input port (such as input impedance) is different than an input requirement. The input characteristics can be expressed as a requirement and can be verified through test and other means.
Indirect requirements imply functionality rather than stating it directly. Indirect requirements often use keywords such as “capability,” “mechanism,” or “provision.” The problem with an indirect requirement is that it can be satisfied without actually implementing the function. Indirect requirements are also too ambiguous for a rigorous and methodical design and verification process. Indirect requirements can readily be converted to functional requirements by simply removing the “capability,” “mechanism,” or “provision.”
Requirements authors sometimes try to take shortcuts or increase efficiency by referring to other documents for requirements. These referred requirements can create problems for traceability and maintenance, especially if the referenced document changes. In addition, the referenced document may not meet the same control category for configuration management as the original document. Sometimes authors even reference textbooks for requirements; this is very problematic if the textbook goes out of print.
Global requirements are often used in documents. These are readily identified since they describe behavior from an input to a group of outputs, such as how a reset input will affect all of the outputs. While sentences with global requirements are easy to write and easy to understand, they do not necessarily make effective requirements. Global requirements will force the reader to go through an entire document searching for every signal that affects an output or function of interest. The functionality must then be synthesized from separate data points spread throughout the document. Global requirements can cause requirements conflicts, perpetuate errors and mistakes, and make it difficult to understand intended functionality.
Finally, derived requirements are another type of requirement, but they differ from the previously discussed requirement types because they do not have any clearly defined characteristics that are unique to the statements themselves, or in other words, requirements cannot be identified as derived just by looking at the statements. Derived requirements can only be identified when they are compared to higher level requirements. “Derived” is a label that is attached to requirements of all types to identify them as requirements that need to be validated—any of the previously described requirement types can be labeled as derived, and that designation does not change the requirement in any way.
Derived requirements are requirements that result from the design process. They normally originate from design decisions that occur during the decomposition of system functions to lower levels of electronic hardware, and can be identified most easily by looking at their content in comparison to the higher level requirements: if the information in the lower level requirement contains specifications that are new or different, or if they specify new functionality, then they are derived.
Derived requirements are singled out by DO-254 for special treatment, and deserve lengthy discussion because they can be problematic if not addressed properly. Derived requirements are closely related to the topic of Validation, so they are discussed in detail in the Validation chapter.
The most important distinction between the above requirement types is the difference between functional and implementation requirements. Functional and implementation requirements are the two requirement types that are arguably the most and least compatible with the goals of DO-254 processes.
When trying to understand the difference between functional requirements, which specify what the hardware should do, and implementation requirements, which specify how the hardware should be designed, it can be helpful to look first at how requirements fit into the engineering design process, and at the same time expand on the roles that function and implementation play in the design process, how they are most often confused, how they should be documented, and how to get from implementation to function.
As defined by DO-254, the four major phases of the standard design process are requirements capture, conceptual design, detailed design, and implementation, with these four phases intended to be executed in chronological order. Astute readers will immediately recognize that requirements capture occurs at the start of the process. This should be a clue as to how requirements are supposed to be used: if the requirements are supposed to be written before the design is started, then it follows that requirements should only define functionality (“what”) rather than design implementation (“how”) because specifying the design requires jumping ahead to the conceptual detailed design phases.
Probing further into the relationship between requirements and the design process, since the “how” of the hardware cannot be known until after the design has been conceptualized or designed, and the requirements are constrained to contain only the “what” of the hardware’s functionality, then the way to document the “how” of the hardware is to use another type of document that is written specifically for that purpose. That document is the Design Description document, sometimes referred to as a Design Document.
The design document captures the “how” of the hardware by documenting the hardware’s detailed design. It describes how the hardware was designed or how it should be implemented, and has the following features:
• It is written after the hardware has been designed.
• It documents the details of how the hardware works.
• It documents the design implementation.
• It documents how the hardware meets its intended functionality.
• It does not contain requirements.
In contrast to the design document, the requirements document:
• Is written before the design is started.
• Specifies the hardware’s intended functionality (what the hardware is supposed to do).
• Does not specify how the hardware should meet its intended functionality.
• Does not specify how the hardware should be designed.
• Does not document the design.
FIGURE 4.4 Requirements and Design Documents
The requirements document and the design document—and by extension, functionality and implementation—are essentially opposites. Both are important, although it can be argued that the design document is optional while the requirements document is essential, especially considering the processes in DO-254. Since the two documents are so different and serve such different purposes, then it makes sense that they not be combined or mixed together.
The difference between the two document types is straightforward, but again, depending on the engineering culture, the difference can be confusing at first. Using the design process again as a guide, if the design document is used to document the design, then it would appear near the end of the design process, in contrast to the requirements document, which appears at the beginning. If seen on a timeline, the two document types should bracket the design phases of the process as shown in Figure 4.4.
Ironically, in the real world it is a fairly common practice to combine the two documents into a hybrid document that is then misnamed a requirements document. There are numerous reasons, most of them well-intentioned, but most are due to not fully appreciating the difference between function and implementation and how they can affect the processes in DO-254, nor the difference between a requirement, a design description, and a design decision.
The difference between requirements, design descriptions, and design decisions can also be confusing at first, again depending somewhat on past training. The differences can be summarized as follows:
• A requirement defines a specific function that the hardware must implement.
• A design (implementation) decision is what designers do to get from the requirements to the end hardware design.
• A design description describes the hardware design, and should not contain specifications.
A very simple example of a card level functional requirement would be:
“DAT_OUT(11:0) shall output the 12-bit unsigned binary equivalent of the AIN_1 analog input.”
The above statement specifies what the output should do, not how it should do it. It contains no design information that will lead the designer to a specific solution, and it is written in the pre-design tense.
The design decision that results from this requirement might be to use a commercial 12-bit analog to digital converter integrated circuit (IC) to convert the analog input into a 12-bit unsigned binary value. It could also be to create a custom analog to digital converter out of transistors and passive components, or use a commercial 16-bit analog to digital converter and use only the upper 12 bits. Any of these solutions will meet the intended functionality, and because the requirement is written to express the intended functionality rather than its implementation, any of them (and more) can be considered as solutions.
Design decisions do not have to (in fact, they should not) be documented as requirements. Design decisions can be important, but it is the intended functionality of the design that is most important and most appropriate to DO-254 processes. Design decisions and the circuits that come from them should be documented in a design document.
The design description describes what the designer created to implement the function described in the requirement. It describes what was designed to allow the hardware to meet the requirement. It is written in the post-design tense and does not contain specifications. For the analog to digital converter example, the design description might contain the following:
“The AIN _1 input signal is buffered, scaled, and level shifted by an OP123 operational amplifier that converts the +/–10 Volt input to the 0–5 Volts required by the ADC123 16-bit analog to digital converter. The ADC123 is configured to generate an unsigned binary output by strapping the MODE (1,0) input pins to DGND. The upper 12 bits of the ADC123 digital output are passed through an LD123 tristate line driver to the DAT _OUT (11:0) output pins.”
The design decision for this design might be:
“The ADC123 converter was selected because it exceeds the performance needs of this function, and because it is in widespread use throughout the electronics industry it can be purchased at considerably less cost than the ADC234 12-bit converter IC. The OP123 is used in this buffering role because it was designed to work with the ADC123 and likewise exceeds the performance needs for this function. The alternative of using the ADC321 converter IC was considered since its input range will accommodate the full voltage range of the AIN _1 input signal, but its cost was considerably greater than the cost of using the ADC123 and OP123 combination, and there was some concern as to whether its performance over temperature would be adequate.”
Using the design description as a requirement is a common but unadvised practice. For example, “There shall be a 12 bit analog to digital converter configured for an unsigned binary output” might be a typical implementation requirement for the analog to digital converter example. While this approach to requirements can provide tight control (more likely too tight) over the design of the hardware, it does not capture the intended functionality of the hardware. In fact, such a requirement has no intended functionality at all because it only describes how the hardware should be designed. Alternatively, the design description will be almost identical to the requirement because both the requirement and the design description are describing the same thing. Thus a simple test to determine whether a requirement is functional or implementation is to compare the requirement to a description of the design. If they are similar or identical it means the requirement is capturing implementation rather than intended functionality.
The intended functionality in an implementation requirement is not often readily perceived, even by the person who wrote the requirement. In fact, it is often very difficult to determine the intended functionality even when the specified circuit is analyzed. However, one method to get from the implementation to the correct intended functionality is to perform a “root function” analysis. A root function analysis is similar to the well-known root cause analysis, and has a similar procedure: repeatedly ask, “why?” to identify the root functionality that is driving the specification.
The following example illustrates how an implementation requirement can be converted into its root functionality (and converted into a functional requirement) through this process.
Starting with the following card level requirement: “The ADC shall sample the AIN_1 analog output at least 20 microseconds after and 20 microseconds before a transition on any motor drive output.”
This requirement is clearly an implementation requirement—it tells the designer that there is an analog to digital convertor (ADC) on the card and that it should sample its input at a certain time. Underlying all implementation requirements is functionality that the implementation is meant to fulfill, and that functionality is what the requirement should be specifying. In this case there is a reason for causing the ADC to sample its input at the specified times, but the reason and the functionality that it serves is not clear from the requirement itself.
To get to the reason and its intended functionality the requirement can be analyzed through the root function process by asking a series of “why” questions. The first “why” question would be, “Why does the ADC have to sample its output at least 20 microseconds before and after a transition on a motor drive output?” The answer to this question would be, “The motor drive outputs are high current and can cause significant distortion in small signal analog circuits, which will cause conversion errors in the ADC. Sampling at least 20 microseconds from the motor drive output transitions will allow the ADC to convert the AIN_1 input after noise has settled and allow time for the ADC to convert the input before the next transition.”
The “why” portion of the answer, or in other words the part of the answer that actually provides the justification for the requirement, is the second sentence—that the ADC needs to convert its input after the motor drive transition noise has settled and with enough time to complete a conversion before the next transition.
If the original requirement is then rewritten to reflect the justification in the second sentence, the new requirement would state, “The ADC shall sample AIN_1 after motor drive transition induced noise has settled, and complete its conversion before the next incidence of motor drive transition induced noise.”
This requirement is a little more explanatory than the original in that it focuses more on the reason for sampling 20 microseconds before and after a motor drive transition rather than blindly specifying that it do so. However, while it is closer to a functional requirement, it is still more of an implementation requirement because it focuses on how the circuit should work rather than the functionality that it should satisfy.
If another “why” question is asked, i. e., “Why should the ADC sample the input after the motor drive noise has settled and with enough time to convert before there is more noise?” The next answer is “The noise caused by the motor drive outputs will cause errors and distortions in the ADC’s digital output. Avoiding the noise will minimize the errors and distortion in the ADC output.”
So if the requirement is rewritten again from the justification in the previous answer, it could be, “The ADC shall sample the AIN_1 input in a way that minimizes errors and distortion in its digitized output.” This requirement is better yet, but it still does not capture the root or core functionality that it is really trying to express.
So another question is in order: “Why does the ADC need to minimize errors and distortion?” The answer to this question is, “If the conversion errors in the ADC output are not minimized, the total error in the digitized output may exceed 2%, which is undesirable.”
If the requirement is again updated to include the last answer, it could be written as, “The total error in the digitized AIN_1 output shall be less than 2%.”
Note that at this point the requirement is free of implementation: there is no mention of circuit architecture, components, or anything else that hints at a physical implementation. It very simply specifies an input/output/performance relationship that defines the functionality of the output (the “what” of the output) without delving into how it should be done.
An additional check is to ask one more “why” question about the final requirement: “Why must the digitized AIN_1 output have less than 2% error?” The answer to this question is, “If the AIN_1 digitized output has more than 2% error the software system control loop that uses the value will become too inaccurate and potentially unstable.”
This last answer is significant in that its reason or justification now points to a higher level than the card, so the justification—and any requirement written from it—is now outside the scope of the hardware item (the card). This difference from the earlier answers tells us that the justification for the card level requirement has now gone high enough to be free of the implementation of the requirement. This is the sign that the requirement now captures the intended functionality at the card level, and that this intended functionality is flowing down from the parent hardware rather than being generated at the card level.
The process for determining underlying functionality in an implementation requirement is displayed in tabular form in Table 4.1.
The final form of the requirement specifies a limit for errors in the output and does not restrict the sources of the errors even though the original requirement focused on errors due to high current transients. This is a significant improvement in the effectiveness of the requirement, and one of the reasons that implementation requirements are not as effective as functional requirements: the system’s justification for the requirement was that the system needed the error in the digitized output to be kept below 2%, and without regard to the source of those errors. In contrast, the original requirement focused only on one potential source of errors out of the many different sources that exist in every electronic system, and some of those other sources could be more problematic than the one being addressed.
Finding the Root Functionality
Requirement |
Question |
Justification |
Justification Level |
The ADC shall sample the AIN_1 analog output at least 20 microseconds after and 20 microseconds before a transition on any motor drive output. |
Why does the ADC have to sample its output at least 20 microseconds before and after a transition on a motor drive output? |
Sampling at least 20 microseconds from the motor drive output transitions will allow the ADC to convert the AIN_1 input after noise has settled and allow time for the ADC to convert the input before the next transition. |
Card |
The ADC shall sample AIN_1 after motor drive induced noise has settled, and complete its conversion before the next incidence of motor drive induced noise. |
Why should the ADC sample the input after the motor drive noise has settled and with enough time to convert before there is more noise? |
Avoiding the noise will minimize the errors and distortion in the ADC output. |
Card |
The ADC shall sample the AIN_1 input in a way that minimizes errors and distortion in its digitized output. |
Why does the ADC need to minimize errors and distortion? |
If the conversion errors in the ADC output are not minimized, the total error in the digitized output may exceed 2%. |
Card |
The total error in the digitized AIN_1 output shall be less than 2%. |
Why must the digitized AIN_1 output have less than 2% error? |
If the AIN_1 digitized output has more than 2% error the software system control loop that uses the value will become too inaccurate and potentially unstable. |
System |
If the ADC circuit was designed as specified by the original requirement, it would only be designed to address one of those many sources, and in the end the method specified in the requirement might well have been inadequate to actually keep the error below 2%. The final design could meet its requirements and pass all of the requirements-based verification tests and still not meet its intended functionality, or in other words its performance would not meet the needs of the system.
Requirements that capture root functionality have significant advantages over requirements written to capture implementation and design features: (1) the requirements will express functionality rather than implementation, which will ensure that the hardware item meets the needs of the system; (2) they will express the functionality at the most appropriate level of detail for the hardware item; (3) they will express the functionality that is required or intended by the next higher level of the system in a form that is compatible with those needs, and thus be more true to the needs of the system; (4) the functionality in the requirements will have a clear connection (or trace) to the higher level functionality from which it flowed, which will enhance both validation of the requirement and an understanding of how the functionality of the item relates or integrates into the functionality of the system; and (5) the requirements will not restrict how the functionality can be implemented, allowing the real experts—in this case the card level designer—to perform their job to the best of their ability. In addition, requirements like these will express functionality in a way that can be measured and verified.
Another consideration in how requirements should be written is whether the contents of a requirement are actually essential (i.e., required) for the hardware to meet its goals (the intended functionality as defined or flowed down from the system level).
A requirement specifies a quality or parameter without which the hardware item cannot correctly or completely fulfill its role in the system. DO-254 alludes to this concept when describing validation activities, in which it states that requirements are complete when all of the attributes that have been defined (i.e., specified) are necessary, and all necessary attributes have been defined. Thus if a specification is not necessary, then it probably should not be a requirement.
In contrast to requirements, definitions contain information that is non-essential but still helpful for understanding the hardware item’s function, and for designing or verifying the hardware, such as descriptions of input signals, definitions of terminology, definitions of modes of operation, or a preferred method of implementation.
There can be a tendency in requirements authors to write too many requirements, or in other words, to specify more than they need to specify. One contributing factor is that they may confuse or blend requirements and definitions and capture definitions as requirements. This practice is understandable, but ultimately it can cause needless work by creating more requirements than are necessary and specifying more than needs to be specified.
One common example of crossing the line between definitions and requirements is the concept of modes of operation. Operating modes are often captured in requirements because humans are used to conceptualizing hardware operation in terms of modes. There is no question that using modes of operation is useful and even essential in some arenas, but despite their importance they are actually definitions that are good to define but are not always appropriate as requirements.
Consider the following requirement that defines a mode based on the states of four input signals:
“The Control box shall be in Spoiler Mode when the LOC(3:0) input signals are set to 1010 binary.”
This requirement seems useful enough by defining a mode of operation so the designer will know what the box is supposed to be doing when the inputs are in the defined states, but it really should not be a requirement: conditions that are dictated by the states of inputs are definitions, and a requirement like this one cannot be verified because there is nothing that can be measured to prove that the box is in Spoiler Mode. After all, the inputs can be measured to prove that they are in the 1010 states, but that does nothing to prove that the hardware is actually in a Spoiler Mode, whatever that may be.
If we compare this requirement to the definition of a requirement as stated previously, the information in the example requirement is non-essential, and the hardware will work just fine without declaring that the state of the LOC(3:0) inputs is called Spoiler Mode.
Modes that are specified as a condition of outputs are more appropriate because the outputs can be measured to verify that the hardware is in a particular mode, but even in this situation the definition of modes of operation is still not essential for the hardware to meet its goals. The reason is that modes are just an abstraction, a name given to a particular condition in the hardware that humans use to help them understand what is going on with their hardware. The hardware itself has no knowledge of modes of operation; it just responds to its inputs the way it is designed to. Humans, however, can more readily conceptualize and relate to the hardware’s operation if modes are assigned to its various functional states.
While it may not be advisable to define modes with requirements, it can be advantageous to define modes (but not with requirements) and then use the modes in requirements. Using modes in this manner allows the requirements to exploit their advantages (segregating operation into easily comprehended states) without needlessly increasing the number of requirements that have to be managed.
For example, if there is a fairly complex functional state that is characterized as (LOC(3: 0) = 1010) AND (SER_MES(65) = 1) AND (OPSTATE(4:0) = 11001) AND (BIT_SEL (6: 0) = 0010111), the requirements for the hardware can be greatly simplified and much easier to understand if a name is assigned to this functional state and then used in requirements in place of the actual signals. Thus instead of writing the following requirement:
“The ROT_UP output signal shall assert high when the EXT_UP input signal is high and LOC(3:0) = 1010 AND SER_MES(65) = 1 AND OPSTATE(4:0) = 11001 AND BIT_SEL(6:0) = 0010111.”
The requirement can be written as a definition combined with a requirement, as follows:
“The hardware will be defined as being in the EXTEND mode of operation when (LOC(3:0) = 1010) AND (SER_MES(65) = 1) AND (OPSTATE(4:0) = 11001) AND (BIT_SEL(6:0) = 0010111).”
“The ROT_UP output signal shall assert high when the EXT_UP input signal is high and the hardware is in the EXTEND mode.”
By adding this mode definition (and ostensibly defining a number of other modes as well) the operation of the hardware is more easily understood in terms that are conducive to human understanding as well as being in accord with the overlying functionality of the hardware.
So what is the issue with creating requirements for things that really do not need them? Cost is the main issue: each requirement creates a cascade of activities, each of which comes with a time, cost, and schedule impact. Every requirement has to be written, archived, reviewed, validated, traced, verified, and maintained throughout the life of the product. This cost can be significant, especially when the number of requirements is large. Reducing the number of requirements can have a significant impact on the long-term cost and schedule of the program.
Note, however, that reducing the number of requirements does not mean cramming more information into a fewer number of requirement statements. The cost of requirements is proportional to the number of attributes, not necessarily the number of statements. Writing huge requirements that each have 100 attributes will not cost less than writing 10 times as many requirements that each have 10 attributes.
Requirements and the functions they express flow down from the aircraft level to the design that realizes the function. Aircraft functions become the requirements for the aircraft systems—the functions are divided up and allocated to various aircraft systems. Each aircraft system has a requirements specification. If the system contains numerous parts, there may be a requirements specification for the controller or line replaceable unit (LRU). When the controller or LRU is initially designed, decisions are made as to how to implement the functionality and the type of architecture in the electronics that would best suit the purpose. This is the initial step in allocating system functions to mechanical or electrical components, software, or electronics such as an FPGA or an ASIC.
Initial efforts in programs using PLDs used system requirements that flowed directly to PLD requirements. For an extremely simple system this could be possible. With complex systems and highly integrated functionality, an allocation from system directly to an FPGA creates problems with traceability and verification. A more thorough approach would be to start with system requirements and allocate through the various levels of abstraction and design within the system. One such approach would start with the aircraft functions and system architecture. The next lower level of abstraction would be system requirements and associated design. The following level would be LRU (controller) requirements and associated design. The next level would be assembly requirements and associated design. The next level would be circuit card requirements and associated design. Finally, there are PLD requirements and the PLD design. The flow down of requirements is depicted in Figure 4.5.
The idea is that the functions get allocated or decomposed from a higher level of requirements to a lower level of requirements. A function could be the transmission of ARINC data. The ARINC outputs are visible at the system level and described in the system level requirements. The design and allocation of the ARINC transmission function does not happen until the circuit card level requirements are reached. At the circuit card level, the requirements can then be decomposed and allocated to the electronics and even software if needed.
Requirement flow down is performed by allocating the requirement from one level down to the next level. If the function is the same at both levels, the requirement can simply be copied. If the terms in the requirement change units or split into parts, then the requirement decomposes into more granular parts. For instance, a level n requirement can be the same on two or more levels. The requirements would look like this:
FIGURE 4.5 Requirements Flow Down
|
• System level: • Circuit Card level: |
The ARINC 429 output bus shall transmit at 100 Kbits-per-second. The ARINC 429 output bus shall transmit at 100 Kbits-per-second. |
If the terms in the requirement change units, then the requirement decomposes and takes on the relevant units. A requirement can be similar on two levels with different units. The requirements would look like this:
|
• System level: • Circuit Card level: |
The maximum flap output position command shall be limited to 30.0°. The maximum flap output position command shall be +15.0 V +/− 0.03 V. |
The requirements can decompose between levels, with parts allocated to software, electronic components, and PLDs. In this case the requirement will change between levels both in terminology and in the number of requirements. This example shows an upper level requirement decomposing into five lower level requirements:
|
System level: LRU level: Circuit Card level: PLD level: Software level: |
The LRU shall transmit Flap Position with Label 204 at a 50.0 Hz +/− 0.1Hertz rate. The ARINC 429 outputs shall transmit Flap Position with Label 204 at a 50.0 Hz +/− 0.1 Hertz rate. The ARINC 429 outputs shall output Flap Position with Label 204 at a 50.0 Hz +/− 0.1 Hertz rate. The ARINC_429_N and ARINC_429_P outputs shall generate a message with Label 204 when a write operation is performed to address 0x30334024 on the processor data bus. The message output shall start within 1 microsecond after the completion of the write operation, and use the data from the write operation as the message payload. Label_204_FLAP_POSITION shall be written to ADDR(0x30334024) every 20 +/− 0.04 milliseconds. |
In this example, at the circuit card level the functionality in the requirement is essentially unchanged from the LRU level because in this fictional system the ARINC messages are generated on the circuit card before being output unchanged through a connector on the LRU, so the output of the circuit card and the output of the LRU are the same. At the next lower level, the rate and payload functionality are allocated to the software while the functionality for generating the actual message and inserting the message label and data is allocated to the FPGA that generates the ARINC message. The FPGA has no knowledge of the system rate and data requirements; it only knows that when the processor writes a data word to a particular address that it should generate an ARINC message with a particular label and use the data from that write operation as the message payload. The software likewise has no knowledge of the particulars of the ARINC messages, or even of the existence of the ARINC transmitter function; it only knows that it has to write a particular data item to a particular bus address every 20 milliseconds. The combination of the functionality in the software and FPGA requirements satisfies the higher level requirements at the circuit card, LRU, and system levels.
The circuit card requirement is allocated rather than derived because its functionality flowed down unchanged from the LRU level. On the other hand, the FPGA and software requirements that were derived from design decisions made at the circuit card level (the decisions to generate the messages in the FPGA and generate the data and timing in software) are derived requirements that trace to the circuit card requirement and therefore need to be validated. Or more accurately, the two FPGA requirements need to be validated but the software requirement must be addressed as specified in DO-178.
Functions (and their requirements) can also originate at any level of the hierarchy, although this is often indicative of incomplete requirements capture in the upper levels. These requirements are added to allow testability or other features desirable for electronics or software development, but are not necessarily a system function. Suppose that the software developers want to add a test feature. They could add a requirement at their top level of requirements. An example might be:
• Level 5 (Software): The software shall output the status of monitor1, monitor2, and monitor3 every 100 milliseconds on ARINC maintenance label 350.
TIMING AND PERFORMANCE SPECIFICATIONS
It can be tempting for a requirements author to base timing and performance specifications on the capabilities of the technology or hardware rather than on a flow down of system performance requirements. For example, the author of a PLD requirement might specify the input to output timing of a signal from an understanding of how fast the PLD can generate that output rather than from the needs of the parent circuit card, or in cases where the requirements are being written after the design is underway, from a knowledge of how long the signal actually takes. From the perspective of how the PLD actually performs this requirement may seem more accurate, but because it captures only the actual performance of the hardware rather than the performance that the system needs from the PLD, it is in effect disconnected from the system and its performance. Relying on such methods can eventually result in performance specifications that are both inaccurate from the system perspective and problematic from the practical perspective.
Like other aspects of functionality, timing and performance specifications should flow down from higher level requirements and design decisions, with the exception of derived requirements that originate at the item’s level and are not related to system functions. The specifications should not be influenced by the characteristics of the hardware.
For example, if a PLD has to output a clock that is used to drive an analog to digital converter (ADC) IC on the parent circuit card, the specifications for the clock output should be derived from the clock specifications in the ADC data sheet combined with any system requirements for timing and performance. The speed of the PLD, the frequency of its input clock from the card, and the type of PLD should have no bearing on the timing and performance specifications because those parameters should flow down from higher levels to ensure that they are determined by system needs.
When specifications are flowed down from higher levels they will normally be expressed as a value with a tolerance or as a range of acceptable values, and those values and tolerances are dictated by what the system needs. For example, an FPGA requirement for a clock output to an ADC device should be determined by a combination of how many conversions must be performed and the performance limits of the ADC. In turn, the number of conversions that must be performed will flow down from the system as a number of analog inputs and how often each of those inputs needs to be converted, which will then define how much time can be allotted to each conversion, which will then define how fast each conversion must be performed, which will then define a range of clock frequencies that will satisfy the conversion performance while remaining within the capabilities of the ADC. The FPGA clock frequency does not factor into the derivation of the requirements because that is an implementation detail at the card level that should be determined by the requirements for the ADC rather than the other way around.
Decomposition of a requirement and its trace to a lower level requirement can follow several possibilities. The requirement can be copied directly, one upper level requirement to one lower level requirement. An upper level requirement can break out into two or more lower level requirements. Two or more upper level requirements can trace down to one lower level requirement. Two or more upper level requirements can trace down to two or more lower level requirements, although requirements decomposition and traceability work better when the 1:1 or 1:many types of relationships are used. In summary, requirements decompose as follows:
• 1 upper level requirement : 1 lower level requirement
• 1 upper level requirement : 2 or more lower level requirements
• 2 or more upper level requirements : 1 lower level requirement
• 2 or more upper level requirements : 2 or more lower level requirements
The decomposition relationships are shown in Figure 4.6.
One enhancement of the requirements process is to capture the traceability data when the requirements are captured. This is more effective and efficient than waiting and trying to figure it out at a later time. Trace relationships should be defined by the flow down and decomposition of functionality (requirements) from higher to lower levels. Since traceability is the natural byproduct of the hierarchical design process, the best time to document the traceability is when the requirements are being written so that the traceability and functional flow down will be faithfully captured. Writing requirements and then generating traceability later on as a separate activity is not recommended.
Requirements are used to identify and specify the functionality of an aircraft, a system, an LRU, a circuit card, a programmable logic device, and software. There is more to a requirement than the word shall. A sentence with the word shall in it is not necessarily a requirement let alone a well-written requirement.
FIGURE 4.6 Requirements Decomposition
Requirements should be expressed in the positive sense. Or, facetiously, the requirements document shall not use negative requirements. Negative requirements are difficult to verify; it is hard to prove that something does not happen.
Requirements also express a cause and effect relationship between the output(s) and the input(s) or the output(s) and a timing event. The timing event can be expressed as absolute timing, such as 20 microseconds, or relative timing such as 20 microseconds before the next rising edge of the clock.
The following are recommendations to help write well-formed requirements:
• Use the keyword “shall” to identify a requirement
• Make each requirement unique
• Assign a unique identifier or tag to each requirement
• Specify what is done, not how it is done
• Specify an observable behavior on an output in the requirement
• Describe how the outputs respond to valid inputs
• Describe how the outputs respond to invalid inputs
• Describe how the outputs respond to timing related events
• Make each requirement specific and concise
• Express requirements in the positive sense, no negative requirements or “shall not”
• For PLDs or circuits, express requirements in terms of pin level behavior
• Use descriptions of outputs that can be observed and inputs that can be controlled
Write the requirements for the target audience—the design engineer and the verification engineer. Requirements should not be written to show off the literary prowess of the author. The difficult part is for the requirements author to not use their assumptions, biases, or presuppositions when writing the requirements. Instead, the author should aim to impart their knowledge to the reader and explain the details. Writing for the target audience is enhanced with the following techniques:
• Define behavior from output to inputs, not input to outputs.
• Explicitly specify the behavior of the output(s) rather than implying the behavior.
• Put all relevant information in one place for each output or function. Do not force the designer to search through the entire document to get the information. Do not use global requirements where one input affects all the outputs.
• Define functionality, not implementation. The requirements should focus on what the hardware does, not how it does it.
• Use information statements to explain the application or other contextual information. Information statements can also contain definitions for specific terminology and keywords. If certain aspects of the design or implementation are important, then describe it in an information statement.
The author should add all details necessary to explain the functionality. Make no assumptions about what the reader already knows or about what assumptions the reader will make. Fill in the details in the requirements rather than forcing the reader to add details or figure things out. Use a glossary or designated section of the document to define terminology. Use the defined terminology in a consistent manner throughout the requirements document.
Requirements should define timing dependencies when they apply. Use tolerances for specific timing, such as “10.0 microseconds +/− 0.1 microsecond.” Another method to specify timing is to use a limit such as “within 5.0 microseconds” or “before the next rising edge of the input clock MSTR_CLK”. Specify timing with tolerances for all aspects of behavior. Provide measurable reference points for all timing specifications.
Requirements need to tell the reader the order of precedence so that behavior can be predicted in the presence of simultaneous inputs or events. Using language that conveys precedence lets the reader know which behavior occurs when a reset occurs and whether the reset overrides other inputs. Denoting a word such as “unconditionally” as the highest precedence will allow the requirements to specify order of importance. Another way to indicate precedence is to define the sequence in which inputs or events are processed or responded to. The sequence can be in a list or defined in a table.
While requirements standards are part of DO-254, they also enhance requirements capture and interpretation. Using a standard for requirements will result in a standardized document format. This allows team members to readily know where to find information in a requirements document. Team members can more readily contribute to a project or get added to the team when the requirements documents have a standard content and format. The standards also help new employees understand how to make technical contributions: they do not have to try to come up with documentation structure and presentation format because it is already defined. The standards define the meaning and usage of modal operators of necessity and modal operators of possibility, such as “should,” “shall,” “can,” “will,” “may,” and “might.” The use of a template is recommended for requirements capture. The template helps the requirements author think through all aspects of functionality. If certain aspects of the template do not pertain to a function, then that part of the template can be marked not applicable. Templates also ensure consistency in how requirements are written and help enforce the requirements standards. Other benefits of using a template across an organization can be realized when engineers can readily contribute to a project without having to learn new requirements methods for new projects. A typical template could be expressed as follows:
Function Name
Definition of terminology
Trace links
Justification for derived requirements
Output(s)
• Description
• Units
• Encoding (bus, number of bits and weighting of least significant digit)
Input(s) affecting the output
Power-on behavior—the behavior of the signal when power is first applied
Reset response—the state of the signal after reset asserts or reset deasserts
Assert behavior—the requirements for asserting the output to its active state
Deassert behavior—the requirements for deasserting the output from its active state
Invalid behavior—how the signal should behave when presented with invalid or undefined inputs
Finally, the requirements should express a cause/effect relationship between inputs and outputs. The inputs (or timing event) are the cause, the outputs are the effect. This can be expressed diagrammatically as follows:
The {output or verifiable aspect}
shall
{effect}
when {cause}
Once requirements are structured in this fashion, they support the design and verification process. Well-formed requirements may take additional time and effort, but it is time and effort well spent. Once a complete and well-formed set of requirements is created and reviewed, it is much faster and efficient to create a design to implement the functionality expressed in the requirements. The verification process for testing and analysis can proceed with the requirements before the design even starts.
Requirements for PLDs can be structured to facilitate the design and verification processes. Since the inputs and outputs are digital with a value of 0 or 1 (false or true), the requirements expressions can be patterned to state under which conditions an output is true (1) or false (0). Another approach is to define when an output is asserted or deasserted. The requirements document will then define whether an asserted or deasserted output means high or low, 1 or 0, true or false. Writing requirements with outputs as a function of input follows the same structure of hardware design language for a PLD or a schematic for a circuit. Hardware design language uses statements to express how output signals are assigned when a sequence of events has occurred, when a timing event occurs, or when a reset occurs.
Using a requirements template as previously mentioned:
Function Name
Output(s) of the function
Input(s) affecting the output
Definition of terminology
Trace links
Justification for derived requirements
Power-on behavior—the behavior of the signal when power is first applied
• Requirement(s) describing behavior of the output during power-on conditions
Reset response—the state of the signal after reset releases
• Requirement(s) describing behavior of the output during or immediately following reset conditions
Assert behavior—the requirements for asserting the output to its active state
• Requirement(s) describing behavior of the output(s) that are asserted when the input conditions are satisfied
Deassert behavior—the requirements for deasserting the output from its active state
• Requirement(s) describing behavior of the output(s) that are deasserted when the input conditions are satisfied
Invalid behavior—how the signal should behave when presented with invalid or undefined inputs
• Requirement(s) describing behavior of the output(s) when the input conditions are invalid or undefined
The structure of the template mirrors the structure of the HDL. The first requirement is for the response to a reset input. The first section of the HDL process decodes the clock and reset inputs and responds to a reset before processing normal inputs.
FIGURE 4.7 Structure of Requirements and Design
This also establishes the precedence of the reset over the other conditions shaping the output signal. The second requirement is to assert the outputs to their active state in response to the input conditions being satisfied. The second section of the HDL process decodes the clock and inputs and asserts the output if the gating conditions are satisfied. The third requirement is to deassert the outputs to their inactive state in response to the input conditions being satisfied. The third section of the HDL process decodes the clock and inputs and deasserts the output if the gating conditions are satisfied. When specific conditions to deassert the output are not needed, the deassert requirement could simply state to deassert the output when the conditions to assert are not satisfied.
Figure 4.7 shows the requirements structure and how it is set up to mirror the design.
PLD requirements can alternatively be stated with a similar template.
The {output or verifiable aspect}
shall
{effect}
when {cause}
This can be expanded into a more complete set of aspects of a typical requirement:
The {output or verifiable aspect}
shall
{precedence modifier}
{assert, deassert, set to value}
{timing modifier}
{absolute or relative time event}
when {input condition or absolute time event}
Filling in the modifiers shown in the brackets, the structure becomes:
The {output or verifiable aspect}
shall
{always, unconditionally, only}
{assert, deassert, set to value}
{before, after, when, during}
{xx nsec, the next rising edge of a lock, read/write asserts low}
when {inputs are set to a combination of hi/low, a sequence of events has occurred or a timed period elapses}
The following shows an example of a requirement that fills in the above structure to create a requirement:
The {d_out[15:0] pins}
shall
{unconditionally}
{be set to 0x0000}
{within}
{50 nanoseconds}
when {reset_n is asserted low}
Compacting this into a more readable sentence:
The d_out[15:0] pins shall unconditionally be set to 0x0000 within 50 nanoseconds when reset_n is asserted low.
This is another example of a requirement that fills in the above structure, leaving not applicable (n/a) for terms not needed in the requirement:
The {d_out[15:0] pins}
shall
{n/a}
{be set to the current_position_value}
{within}
{50 nanoseconds}
when—
{read_en_n is asserted low and cs_n is asserted low and addr_in[16:0] = 0x12C2} during a processor read
Compacting this into a more readable sentence:
The d_out[15:0] pins shall be set to the current_position_value within 50 nanoseconds when read_en_n is asserted low, cs_n is asserted low, and addr_in[16:0] = 0x12C2 during a processor read.
The preceding requirement also shows how to express access to an FPGA register. Rather than explicitly using registers in the requirements (which can be thought of as a design detail) the access to an address is described in terms of write and read transactions. For a register write, the requirements state the resultant observable effect of having data on the data bus for the address corresponding to what will be a register in the design while the control signals are configured to write data to the FPGA. For a register read, the requirements state what data will be on the data bus for the address corresponding to what will be a register in the design when the control signals are configured to read data from the FPGA.
Compound conditions can be formulated and expressed in the requirement. This is typically the case when an output has a dependency on several inputs or time events. The following examples show how to combine conditions to express the dependencies typically found in PLD logic. Also observe that these structures match the logic gate or expression that they express.
An output that asserts when a set of input conditions must be met all at the same time can be expressed:
out1 shall assert high within 50 nsec when the following conditions are satisfied:
• Condition1
• Condition2
• Condition3
This structure is a logical and (AND) of the input conditions.
An output that asserts when any one of a set of input conditions is met can be expressed:
out1 shall assert high within 50 nsec when one or more of the following conditions are satisfied:
• Condition1
• Condition2
• Condition3
This structure is a logical or (OR) of the input conditions.
An output that asserts when none of the input conditions are met can be expressed:
out1 shall assert high within 50 nsec when none of the following conditions are satisfied:
• Condition1
• Condition2
• Condition3
This structure is a logical not-or (NOR) of the input conditions.
An output that asserts when at least one of a set of input conditions are not met can be expressed:
out1 shall assert high within 50 nsec when at least one of the following conditions are not satisfied:
• Condition1
• Condition2
• Condition3
This structure is a logical not-and (NAND) of the input conditions.
An output that asserts when a set of input conditions must be all met or all not met at the same time can be expressed:
out1 shall assert high within 50 nsec when either all or none of the following conditions are satisfied:
• Condition1
• Condition2
• Condition3
This structure is a logical exclusive nor (XNOR) of the input conditions.
An output that asserts when only one of input conditions are met can be expressed:
out1 shall assert high within 50 nsec when only one of the following conditions are satisfied:
• Condition1
• Condition2
This structure is a logical exclusive or (XOR) of the input conditions.
ELECTRONIC HARDWARE REQUIREMENTS
An output data bus from electronic hardware can be described using techniques similar to those used for PLD requirements. The requirements first describe the physical behavior of the signal, then the logical aggregation is described. The output as a function of input structure is used again. The following requirements are an example of how ARINC output data requirements could be written. An ARINC bit is a high followed by a null or a low followed by a null.
MON_DBUS_P is an ARINC output bus that will have three output values, identified as the low output value, the null output value, and the high output value.
a. [ARINC-OUT-200] MON _ DBUS _ P shall be set to −10.0 Volts +/− 300 millivolts when a low value is output on the ARINC bus.
b. [ARINC-OUT-210] MON_DBUS_P shall be set to 0.0 Volts +/− 300 millivolts when a null value is output on the ARINC bus.
c. [ARINC-OUT-220] MON_DBUS_P shall be set to 10.0 Volts +/− 300 millivolts when a high value is output on the ARINC bus.
[ARINC-OUT-230] The MON_DBUS_P rise time from null to high and low to null output values shall be 1.5 microseconds +/− 0.5 microseconds when a bit is output on the ARINC bus.
[ARINC-OUT-240] The MON_DBUS_P fall time from null to low and high to null output values shall be 1.5 microseconds +/− 0.5 microseconds when a bit is output on the ARINC bus.
[ARINC-OUT-250] MON_DBUS_P shall unconditionally assert to its null output value within 2.0 microseconds after the RESET input signal asserts to logic low.
[ARINC-OUT-260] MON_DBUS_P shall unconditionally remain at its null output value while the RESET input is asserted to logic low.
[ARINC-OUT-270] Each bit of the serial data stream output on the ARINC data bus shall be 10.0 microseconds +/− 5% in duration.
a. [ARINC-OUT-280] MON_DBUS_P shall output either a high output value or a low output value during the first 5.0 microseconds +/− 5% of each bit of the serial data stream.
b. [ARINC-OUT-290] The time for each high or low shall include the time needed to transition from the null to high or the null to low output values.
c. [ARINC-OUT-290] MON_DBUS_P shall output a null value during the second 5.0 microseconds +/− 5% of each bit of the serial data stream.
d. [ARINC-OUT-295] The time for each null shall include the time needed to transition from the high to null or the low to null output values.
[ARINC-OUT-310] MON_DBUS_P shall assert to the high output value during the first 5.0 microseconds +/− 5% of the bit when the data content of the bit being generated is logic high.
[ARINC-OUT-320] MON_DBUS_P shall assert to the low output value during the first 5.0 microseconds +/− 5% of the bit when the data content of the bit being generated is logic low.
[ARINC-OUT-330] MON_DBUS_P shall default to the null output value when no data is output on the ARINC bus.
[ARINC-OUT-340] MON_DBUS_P shall output 32-bit serial data messages for each LABEL shown in Table 4.2.
ARINC Data Bus Messages
SSM |
SDI |
LABEL (Octal) |
DATA |
RATE |
00 |
00 |
050 |
Position Feedback1 |
30. 0 milliseconds |
00 |
00 |
051 |
Position Feedback2 |
30. 0 milliseconds |
00 |
00 |
055 |
Position Feedback3 |
30. 0 milliseconds |
00 |
00 |
057 |
Position Feedback4 |
30. 0 milliseconds |
00 |
00 |
113 |
Ram Position Feedback |
5.0 milliseconds |
00 |
00 |
240 |
Power Status |
50. 0 milliseconds |
[ARINC-OUT-350] MON_DBUS_P shall output a null with a minimum duration of 40.0 microseconds +/− 2.5% between successive 32-bit serial data messages.
[ARINC-OUT-360] Each message shall be output on the ARINC bus once within the period indicated in the RATE column in Table 4.2.
Complex functionality can also be expressed using the output as a function of the input format. The output is described as a transfer function to allow time domain or frequency domain characteristics to be added. The next example builds on the preceding ARINC output for the data field of Label 050. The note below (e) conveys the intent of the author without using an implementation requirement or stating the design explicitly as a requirement.
[ARINC-OUT-380] Message 050 shall have the content shown in Table 4.3.
[ARINC-OUT-390] The 16-bit digitized value in bits 11 through 29 of Message 050 shall be the binary representation of the FEEDBACK input signal (Digitized WING1POSFDBK), where 0xFFFF indicates a positive full-scale value corresponding to an input voltage of +10.00 Volts, and 0x0000 indicates 0.00 Volts.
Note: A filter is applied to the input for noise reduction and signal shaping.
The Digitized WING1POSFDBK will have the following characteristics:
a. [ARINC-OUT-400] The magnitude of Digitized WING1POSFDBK shall decrease linearly from the FEEDBACK input value when the input frequency is less than 100.0 Hertz.
ARINC Message 050
DATA STREAM BIT |
BIT FUNCTION |
CONTENTS |
1 |
Label msb |
0 |
2 |
Label |
0 |
3 |
Label |
1 |
4 |
Label |
0 |
5 |
Label |
1 |
6 |
Label |
0 |
7 |
Label |
0 |
8 |
Label lsb |
0 |
9 |
SDI |
0 |
10 |
SDI |
0 |
11 |
Data |
0 |
12 |
Data |
0 |
13 |
Data |
Digitized WING1POSFDBK bit 0 (lsb) |
14 |
Data |
Digitized WING1POSFDBK bit 1 |
15 |
Data |
Digitized WING1POSFDBK bit 2 |
16 |
Data |
Digitized WING1POSFDBK bit 3 |
17 |
Data |
Digitized WING1POSFDBK bit 4 |
18 |
Data |
Digitized WING1POSFDBK bit 5 |
19 |
Data |
Digitized WING1POSFDBK bit 6 |
20 |
Data |
Digitized WING1POSFDBK bit 7 |
21 |
Data |
Digitized WING1POSFDBK bit 8 |
22 |
Data |
Digitized WING1POSFDBK bit 9 |
23 |
Data |
Digitized WING1POSFDBK bit 10 |
24 |
Data |
Digitized WING1POSFDBK bit 11 |
25 |
Data |
Digitized WING1POSFDBK bit 12 |
26 |
Data |
Digitized WING1POSFDBK bit 13 |
27 |
Data |
Digitized WING1POSFDBK bit 14 |
28 |
Data |
Digitized WING1POSFDBK bit 15 (msb) |
29 |
Data Sign |
0 |
30 |
SSM |
0 |
31 |
SSM |
0 |
32 |
PARITY |
Odd Parity |
b. [ARINC-OUT-402] The magnitude of the Digitized WING1POSFDBK shall be 3 dB +/− 1.0% down from the amplitude of the FEEDBACK input at 100.0 Hertz.
c. [ARINC-OUT-404] The magnitude of Digitized WING1POSFDBK shall decrease by 12 dB +/− 1.0% from the amplitude of the FEEDBACK input over each octave (doubling) of the input frequency when the input frequency is greater than 100.0 Hertz.
d. [ARINC-OUT-406] The phase of the Digitized WING1POSFDBK shall be within 2.0 +/− 1.0% degrees of the phase of the FEEDBACK when the input frequency is between 0.0 and 500.0 Hertz.
Note: The intent is for the output to be filtered with a 2nd order low-pass Butterworth function with a 100.0 Hertz −3dB cutoff.
[ARINC-OUT-410] Each bit of the Digitized WING1POSFDBK shall have been digitized from the FEEDBACK input no more than 1.0 millisecond before being transmitted in the serial data stream on MON_DBUS_P.
[ARINC-OUT-420] Bit 32 of Message 050 shall be set to logic high if the sum of the logic highs in bits 1 through 31 is even. [ARINC-OUT-430] Bit 32 of Message 050 shall be set to logic low if the sum of the logic highs in bits 1 through 31 is odd.
Requirement documents benefit from providing a definition of the signals connected to the hardware. One approach is to first describe the hardware inputs, then describe the hardware outputs, and finally the bidirectional signals connected to the hardware. The definitions list the proper name for each signal. The signal name is then used consistently throughout the rest of the document. No requirements or “shalls” are used in the definitions. A pinout or connection diagram can also be included.
The next section of the document includes a textual description of the functionality of the hardware. Block diagrams should be included to show functional interfaces and how signals are grouped.
The requirements are then organized by what DO-254 calls a functional element. The simplified explanation is to organize the requirements according to the function. Within each functional element, list the output, then the requirements for each output. Organizing requirements by functional element will facilitate the functional failure path analysis and the elemental analysis, especially when using DO-254 as written, to cover all electronics. Figure 4.8 shows the organization of requirements functional element, then each output.
FIGURE 4.8 Requirements Organization
The document should be balanced where balanced means that there are requirements for each signal listed in the signal definition section as an output or the output side of a bidirectional signal. Each signal listed in the signal definition section as an input or the input side of a bidirectional signal should be consumed or utilized in the conditions associated with generating one or more outputs.
SYSTEMS, HARDWARE, AND SOFTWARE
While DO-254 was conceived and written for all complex electronic hardware, the current regulations only require compliance for programmable logic devices. Some programs and international certification authorities are starting to require compliance to DO-254 for all complex electronic hardware. One potential benefit of using DO-254 for electronics in systems is that it can pave a way through the dilemma of tracing software requirements directly to system requirements and PLD requirements directly to system requirements. Many times derived requirements are added to hold everything together and these derived requirements use the notion of derived meaning that there is no upward trace for a requirement. This style of derived requirements uses a paradigm of functionality being an orphan—not having a place to originate from.
A unified view of systems using ARP4754, DO-254, and DO-178 is now possible. The unified view includes the design decisions’ connections to the associated derived requirements. “Derived” in the unified view takes on the original meaning as defined in the glossary of DO-178 and DO-254. The unified view of systems and requirements takes the following path:
• Aircraft functions are identified
• These aircraft functions are expressed as requirements
• The aircraft level requirements are allocated to systems
• The system requirements capture the system functionality and any additional requirements from the safety processes
• The system design captures the architecture and features necessary to implement and realize the system functionality, safety, and reliability
• Allocation and decomposition then continues down through one or more levels of abstraction
• Each level of abstraction copies (and repeats) its allocated requirements until there is a design
• The design will then show how requirements are decomposed
• Divided up among software, electronics, PLDs
• Creating a transform between different representational systems
– Mechanical to electrical and vice versa
– Electrical to electrical
– Rotational to linear and vice versa
– Three dimensions to two dimensions and vice versa
– Logic bits or voltage into displays
• Design decisions are captured and become the drivers for derived requirements at the next lower level of abstraction
• Software requirements are allocated and decomposed from the requirements for the circuit card that hosts the microprocessor or microcontroller
• PLD requirements are allocated and decomposed from the requirements for the circuit card that hosts the PLD device
Figure 4.9 shows this unified concept for requirements. With the software traced and associated with the electronic hardware that hosts it and through which it acquires inputs and sends outputs, there can be greater clarity and justification for software derived requirements. The software will be closely aligned with the hardware and software memory map, the input/output circuitry, and the necessary interfaces between the hardware and the software.
Using the same principles above for form following function, this unified approach has the software functions and requirements emerging from the design where it is realized. In other words, the software is part of the circuit card that hosts the microprocessor or microcontroller. Software functions are fulfilling circuit card or board level functions through the electronic hardware that the software interacts with. Software drivers can now trace to the hardware design decisions for components and circuitry. Software access to input/output read/write can also be tied to the memory map and hardware/software interfaces.
Most profoundly, this unified concept resolves a lot of the issues associated with the use of an inconsistent definition and usage of derived requirements as originally presented in Section 5 of DO-178B and the glossary of DO-178B.
The unified approach has system level outputs that are driven by LRU outputs. The LRU outputs are defined as the response(s) to the LRU inputs and timing events. LRU outputs are driven by circuit card outputs; the LRU inputs drive the circuit card inputs. Circuit card outputs are driven by the combination of software, PLDs, and other electronic circuits. The software, PLDs, and other electronic circuit inputs come from the circuit card inputs and any front end, processing, or conditioning circuits on the circuit card. With a consistent signal naming scheme, an alignment of these signals and their decomposition through various layers of abstractions is possible. This alignment makes the traceability of requirements through various levels easier to identify and manage. Since design decisions are captured, derived requirements and their attendant traceability through various levels are easier to identify and manage.
FIGURE 4.9 Unified Requirements
The verification activities can also take advantage of and benefit from the alignment of signals and unified requirements. System level tests can be used for test coverage of system level requirements and associated LRU requirements. LRU level tests can be used for test coverage of LRU level requirements and associated circuit card requirements. Circuit card level tests can be used for test coverage of circuit card level requirements and associated software and PLD requirements. When PLDs are used as a bridge between a processor and other circuitry, the software tests for DO-178 verification credit can also be used to drive signals to/from the PLD. This allows test coverage of software and aspects of the PLD requirements to be verified together.
Currently, many projects use completely separate test teams and activities for verification of system, LRU, software, and PLD requirements. The separate approach results in duplication of effort and increases project costs. The separate approach also tends to test software and PLDs in isolation, which can miss the opportunity to observe and detect unintended functions or erroneous side effects of software and circuits. An integrated test and verification approach based on unified requirements can be used to reduce the overall number of test cases, test procedures, test results, and associated peer reviews.