Developing Requirements for Complex Electronics
This section is about developing the requirements for complex electronics, which is usually performed by the systems or electronics engineer. The associated assurance activities are described in the Assurance Process page. An assurance engineer, however, needs to be cognizant of the types of requirements that should be included in the specification. Assurance engineers also need to understand the overall process of requirements development for complex electronics, both to guide that development and to ensure that the resulting requirements are adequate.
Ideally, the complex electronics (FPGA, ASIC, CPLD, etc.) will have a separate requirements document. In less complicated systems, the requirements for the device may be included in a higher-level document (such as for a circuit board or electronic sub-system). In the situations where the requirements are not considered adequate (by the assurance engineer), a certain amount of additional requirement derivation will need to be performed. This is covered in the Reverse Engineering of Requirements section of the assurance process page.
This section covers:
Requirements Capture and Derivation
The specific requirements for a complex electronic device will derive from the system requirements, safety analyses, system architecture, performance requirements, and the operational environment. The objectives of the requirements capture and derivation/decomposition process are:
- Identify, derive, and document the requirements for complex electronics
- Assess derived requirements as part of the system requirements engineering processes
- Correct omissions and errors in requirements
The process of deriving requirements for complex electronics is basically the same as for any sub-system. The steps are out-lined below, with the addition of complex electronics-specific issues to consider:
- Allocate system and/or sub-system requirements to complex electronics. This is usually more than a cut-and-paste of the higher-level requirements, because those requirements are often implemented by multiple sub-systems. The requirements have to be decomposed to state the specific requirements for the complex electronics.
- Assess the safety, reliability, maintainability, and similar requirements for their implications for the complex electronics. Derive any specific requirements for the complex electronics. For example, the complex electronics may need to meet a particular Mean-Time-To-Failure (MTTF) requirement. Or, there may be an overall safety requirement that all sub-systems must have a built-in self test capability.
- Consider the effects of the chosen system and sub-system architecture, the selected electronics, standards, procedures, and processes. Derive any requirements for the complex electronics that are necessary. For example, the manufacturing process for an ASIC may constrain the design options. These constraints should be included as derived requirements. Also, the selection of a communications method between sub-systems may generate specific requirements for a complex electronic device that uses the communications method.
- Consider the effects of faults and anomalies in the complex electronic device on other system components, and also the effect of failures elsewhere in the system on the complex electronic device. If a Failure Modes and Effects Analysis (FMEA) was performed, use that as a starting point. Ask yourself:
- Should anomalies in the complex electronics be handled by the device itself or by a higher-level component?
- What anomalies or faults can be tolerated (i.e. no action is taken)?
- If the device has an anomaly or failure, will it affect the safety of the system?
- What failures or faults elsewhere in the system will have an impact on the device? How severe would the impact be? What actions should this device take?
- Identify all interfaces between the complex electronics and other parts of the system. This includes requirements for signal levels and timing. Be sure to specify data formats and protocols.
- Consider environmental constraints, such as radiation, thermal environment, and mission duration. Does the system need a mitigation strategy for Single Event Upsets and/or total radiation dose? If so, what part will the complex electronics play in that strategy? Has the complex electronic device been allocated a power dissipation budget?
- Consider any testability requirements, and how they will be met for the complex electronics. What testing can be done on the bench? What testing will require a system component, or the complete system? Do any special access pins or ports need to be defined, to aid in testing?
- Assess any off-the-shelf design components (e.g., IP cores) that will be used. Consider the functions of the component, and whether any will remain unused. Assess any unused functions for impact on the system if they were inadvertently executed, and add requirements to prevent this situation if appropriate. Add derived requirements for any constraints imposed by the off-the-shelf component on the complex electronics design.
- Are there any constraints imposed by the tools used to develop the complex electronics? If so, these constraints should be captured as derived requirements.
Specific requirements for complex electronics are detailed in the Requirements Review checklist. This checklist can be used as an aid in creating requirements for complex electronics, or in reviewing a set of requirements for the devices.
Feasibility Assessment
Once the requirements are developed, or concurrent with the development process, a feasibility assessment should be performed. The goal of the assessment is to determine if the requirements can be met with the anticipated technology. A secondary goal is to define certain strategies, such as mitigation for single event upsets, which will constrain the design.
The feasibility assessment should determine if the required functionality and performance can be met by the chosen technology, for all planned and anticipated off-nominal operational scenarios. If the requirements cannot be met, then the project needs to determine if the requirements should be modified, or if another technology is more appropriate.
The feasibility assessment process includes the following steps. The information produced by the assessment process should be documented in a report.
- Assess the probability that the requirements can be met by the chosen technology. Consider whether the design will reach any technical limitations, such as number of gates, complexity, operating frequency, and packaging limitations (e.g. number of pins).
- Check the availability of the selected technology. Consider how long the chip and tools will be supported, in relation to mission duration. When will the parts become obsolete? Also consider the availability of technical support.
- Estimate the design complexity
- Estimate the power consumption
- Perform a preliminary timing analysis to assess the feasibility of speed requirements
- Select a radiation hardening approach
- Select a production test approach and verify feasibility against all requirements
- Identify and evaluate suitability and qualification status of complex electronic technologies
- Identify suitable packaging; make a baseline selection
- Determine availability and status of design and test tools and libraries; necessary personnel; and IP cores
Requirements review
Once the requirements for the complex electronic
device are defined, they need to be reviewed by a
variety of people. Each person will bring a viewpoint
to the review that will identify gaps or errors in
the requirements set. The requirements review can
be a formal review (such as part of the Preliminary
Design Review), an informal review, or the result
of many individual reviews.
Details on Requirements
Review can be found in the Techniques
section.
|
