Overview
Software is made of logic, data, and control decisions. Aircraft system software requires a top-down approach, beginning at the topmost level of system requirements and progressing “downward” into levels of greater detail. Even at the lowest, most detailed level, each element of software must be traceable to an aircraft or system performance requirement. For this reason, systems engineers must be involved with the software specifications from the start of a project.
One software program is worth a thousand hardware circuits. For aircraft builders, the reduction of weight, increased dispatch reliability, and design flexibility make software a genie that we cannot afford to ignore. While software can bring many benefits to aircraft design and manufacture, including reduced costs, these same cost benefits can be lost when the software contains errors, or is poorly conceived or designed.
Acquiring Software
Acquiring and certifying system software involves a formidable lineup of tasks, divided into two major categories:
- 1. Project organization
- • Approve all software planning and reporting documents.
- • Run all system and software formal reviews.
- • Set and monitor schedule and budget.
- • Ensure the certification of the software system.
- 2. Technical activities
- • Write system requirements.
- • Help write system design.
- • Help write software requirements.
- • Help verify software requirements.
- • Help verify software design and code (e.g., integration testing).
- • Approve all system and software technical documents.
Table 7.11.1, while not all-inclusive, indicates the major differences in responsibilities for the systems and software engineer.
Table 7.11.1
| Documents | Primary review/approval | Secondary review/approval |
|---|---|---|
| System specifications | Systems engineer | Software engineer |
| System verification | Systems engineer | Software engineer |
| Software plan | Software engineer | Systems engineer |
| Software requirements | Systems engineer | Software engineer |
| Software design and code | Software engineer | Systems engineer |
| Software verification | Software engineer | Systems engineer |
| Software aspects of certification | Software engineer | Systems engineer |
In the remaining section, these preceding activities and a number of software development processes and tools to assist the systems engineer are discussed.
Top-Down Development
The documents that govern software development are in fact based upon top-down development, but that fact is not always obvious. One of the reasons that top-down development is a big issue in the development of software-integrated aircraft systems lies in the fact that the software ends up being a “computerized statement” of your system requirement and design. For this reason, any shortcomings or errors in early specification end up being part of that computerized statement, where corrections become costly and time-consuming. In using a top-down development approach, each phase of product definition breaks the system down further, resulting in a specification for the next parse. Top-down development’s standard incarnation, though by no means its only incarnation, is the waterfall model (Fig. 7.11.1).
In top-down development:
- • there is a progressive refinement from problem to solution;
- • requirements specified before design;
- • the design becomes the new requirement for the next lower level; and
- • all phases are document-driven.
The following statements show how a system requirement would flow through the waterfall model:
- System requirement
- The system shall, upon command, display any voltage currently out of tolerance.
- System design
- The I/O Processor shall respond to display commands within 1 second.
- Software requirement
- The I/O Program shall write the ERROR_DISPLAY signal to output port 3 every 500 ± 10 ms.
- High-level design
- The voltage compare routine shall run every real-time clock cycle, receiving current voltage and returning the amount by which the current voltage is out of tolerance (error).
- Low-level design
- The voltage error (ERROR) is the unrounded difference between current voltage and the standard, minus the allowable tolerance, for each type of voltage monitored.
- Code
- V_ERROR(V_TYPE) = V_ERROR(V_TYPE)
- (V_ERROR(V_TYPE) > 0)
We divide the tasks and share the workload by:
- 1. specifying the external characteristics of the system—everything the system must do to comply with the constraints of its external environment;
- 2. choosing internal characteristics in the form of a set of subsystems, plus their communications with each other and the outside world; with the result that
- 3. each subsystem then becomes a next-lower-level “system” whose external constraints follow from the subsystem breakout we made before.
The divide and conquer process continues in this fashion until we’ve reached the point where we know all we need to know so we can proceed to software coding (by the software supplier).
The product definition process is top-down, but the product integration is bottom-up. Each level of specification is defined by a Data Item Description with which the supplier’s (or OEM’s) documents should comply. Once the supplier has coded the software (which by then has been broken into small units or modules), the software is integrated level-by-level and tested against requirements corresponding to each level. Each module should be limited to 100 source lines of code (SLOC). The testing process continues until the whole system is assembled and can be tested against its top-level specification.
System vs Software Requirements
Many software requirements are system functional requirements. When one writes the software requirements, he or she is reviewing and rewriting the system requirements.
One problem with software is that we are vending it out to people that are not knowledgeable on aircraft system requirements. Therefore, errors in our system requirements and design do not get noticed by the software supplier, so they are built into the software code.
When we test the supplier’s software code, we will end up testing our system requirements and design. But by that time, the errors are VERY expensive to fix. For example, it costs about $16,000 to change a single line of code for an error discovered in a system test.
Specification Review and Product Tests
As Fig. 7.11.2 demonstrates, for every definition specification there is a review; for every integration product there is a set of tests. Good development focuses on the front end—the requirements and design specs (Fig. 7.11.3).
Documentation
Request for Proposal (RFP): The process of acquiring system software begins with the RFP. This document is a request to qualified and interested suppliers to submit a proposal to perform software development work and specifies the high-level requirements for the job.
The RFP’s supporting documents are the Procurement Specification (PS), the Statement of Work (SOW), the Data Item Description (DID), and the Supplier Data Requirements List (SDRL).
Procurement Specification
The Procurement Specification (PS) document specifies the product to be made. It is also the preliminary Systems Requirements Specification (SRS), and therefore the basis of all further system development, including system design and software requirements. An ideal PS would define only system requirements, not system design. While the ideal is usually not considered practical (because of schedule and other constraints), it’s still an excellent goal.
Statement of Work: The Statement of Work (SOW) specifies the process that the supplier must use to produce the product. While the process is based on certification requirements, we must go well beyond this basis to ensure overall quality and economy of the project.
Data Item Description: The Data Item Description (DID) document specifies how the supplier documents the results of the process specified in the SOW.
Supplier Data Requirements List: OEM usually mandates the supplier’s submittal of a set of documents (described within the DID) in a Supplier Data Requirements List (SDRL). However, an SDRL for software documents may not be needed if the documents are always available when OEM needs them (e.g., by electronic transmission).
The Plan for Software Aspects of Certification—The PSAC
The PSAC is the supplier’s response to the software portion of the SOW, and should trace back to it. The PSAC should spell out exactly how each phase of the software development will be done. It should therefore be incremental by phase, though a high-level discussion of the entire development should be available as part of the proposal. For a systems engineer, the key areas of the PSAC are indicated by the Xs in Table 7.11.2.
Table 7.11.2
| Why (results deliverables) | What (tasks) | When (schedule) | How (standards methods tools) | Who | Where | |
|---|---|---|---|---|---|---|
| Project management | X | |||||
| Product definition | X | X | X | X | ||
| Product verification | X | X | X | X | ||
| Configuration management | X | |||||
| Quality assurance | X |
The OEM must provide the high-level direction if we are to acquire a well-produced, well-documented, certifiable, and economically developed product. Written procedures are the key to managing system software acquisition and keeping the development on track.
Software Requirements
In the most general terms, a software requirement is defined as:
- 1. An ability or attribute of a computer program to perform a system function.
- 2. An ability or attribute of a computer program to comply with the system design specification.
The problem with these definitions is that they are circular, and therefore not very useful. For example: “A requirement is whatever is needed to make the system work.”
From a software-specification point of view, one has finished the system design when one has:
- 1. specified every digital signal (or package of signals) that enters and leaves each processor,
- 2. identified the signal’s source or destination, and
- 3. explained the meaning and reason for each signal.
Quality Requirements vs Functional Requirements
Software requirements come in two basic flavors: those that define the software’s quality, and those that define the software’s function.
- • When we ask “what does something do?” we are referring to its functions or ability.
- • When we ask “how does something work?” we are referring to its qualities.
Make sure the requirements are complete, consistent, feasible, and testable. Use the context diagram to help determine the scope of the system software and its requirements.
Rules for Requirements
- • The word SHALL in text expresses a mandatory requirement.
- • The word SHOULD is text expresses a recommendation, or advice on, implementing a requirement.
- • The word MUST in text is used for legislative or regulatory requirements.
- • The word WILL in text expresses an intention.
- • The word MAY in text expresses a permissible practice of action (Table 7.11.3).Table 7.11.3Software levels178ASoftware levelHazard classFailure consequencesLevel IACatastrophicWe all dieLevel IIBSevere MajorSome of us may dieLevel IICMajorWe are cutting it closeLevel IIIDMinorNo big dealENoneNo safety issue
Leave a Reply