Are Functions Implemented with Digital Electronics to Avoid Fundamental Verifications?
Draft version 0.1: August 10, 2009. Please send me comments or additional information.
Introduction
The title to this white paper raises a most serious question: Do engineers implement functions in digital electronics to avoid fundamental verifications? If the answer to this is yes, then this is a most serious matter.
I have heard and read this assertion from some members of the software community, over the past few years. My experience designing, reviewing, and analyzing electronics designs across a wide range of organizations -- various NASA Centers and contractors performing work for either NASA and/or the Department of Defense -- has not shown evidence supporting this thesis. Discussions with the members of the software community stating this assertion did not produce any such supporting evidence.
In this white paper, I shall discuss what I have found out about this thesis, and the supporting material. To date, no significant support has been found for the notion that digital electronics are being [ab]used to avoid fundamental verifications. I invite readers of this white paper to send me their comments or additional information to further develop this subject.
The Assertion
In addition to hearing about the [ab]use of digital electronics, I have statements about this in at least two documents. Here are the references, some relevant sections, and discussions:
First, in 2007:
"Filling the Assurance Gap on Complex Electronics," August 1, 2007, NASA/CR-2007-214939:
Application Specific Integrated Circuits (ASICs) and FPGAs are used to avoid the rigors of the software assurance process which ultimately results in bypassing fundamental verifications.
I contacted the author about this and he stated that this was used by the FAA for justification to create DO-254, it was part of the DO-254's charter, and that he thought that it was in DO-254. I couldn't find any such assertion in DO-254. DO-254 was released over 9 years ago, in April 2000.
Looking for NASA-specific information about ASICs and FPGAs that were used to bypass fundamental verifications, I followed up with the author for some examples to analyze. No NASA examples were identified and I was told that the FAA had stated that aircraft manufacturers and their vendors were doing this. The author is looking for that specific reference, which as of this writing has not been received.
Next, going back a few years to 2004:
"NASA Complex Electronics Guidebook for Assurance Professionals,"December 31, 2004:
One motivating factor for DO-254 is that organizations were implementing software functions in FPGAs and ASICs to avoid the need to follow the software assurance/safety standard, DO-178B!
I had verbal discussions with this author several years ago, and I was not able to obtain any specific information.
The second example also is a reference to a motivating factor for DO-254. And like the first example, I was not able to obtain any specifics.
Neither of these documents or authors could point to problems in NASA electronics, or specific problems in any other electronics. I have never seen such behavior, implementing functions in hardware to avoid "fundamental verifications." Clearly, it is critical that aircraft electronics, as well as spacecraft electronics, not bypass fundamental verifications. So I continued to dig.
Tracing the Assertion
Interestingly, I did find the following similar assertion:
"Design, Test, and Certification Issues for Complex Integrated Circuits," by L. Harrison and B. Landell, Report No. DOT/FAA/AR 95/31, August 1996:
ASICs have been used to avoid the rigors of the software approval process (Straw, Herzog, and Okubo 1986). Safety critical functions have been implemented completely in hardware. Fundamental verification issues can be bypassed with a silicon based implementation.
This quotation has a similarity to that in the above two documents. However, while they seem similar, I do not know if one document followed the other, or if they stem from the same or independent sources.
But, the assertion is quite clear, avoiding the rigor was the intent of using an ASIC (and an FPGA is, of course, just one type of ASIC, once designed). And fortunately the authors did provide a reference. Before diving into that, the second sentence, which describes safety critical functions being implemented completely in hardware, is not a fundamental problem: hardware in safety-critical roles is quite common and techniques for designing, analyzing, and verifying hardware designs are well-understood. The third sentence implies that hardware can be used to bypass fundamental verification issues. Of course, in principle anything can be used to bypass some process or other, and logical safety-critical functions can be implemented in such boring sounding technologies such as hydraulics. Indeed, voting at the actuators of the Space Shuttle is done hydraulically.
The full citation for Harrison's and Landell's reference is John L. Shaw, Hans K. Herzog, and Kenji Okubo, "Digital Autonomous Terminal Access Communication (DATAC)," Proceedings of the IEEE & AIAA 7th Digital Avionics Systems Conference, October 1986. I have attempted to locate the authors of this 1986 paper, or individuals familiar with their work, but have so far been unsuccessful.
The relevant paragraph from Shaw's 23-year-old paper follows. Both Shaw and Herzog worked for the Boeing Commercial Airplane Company, and Okubo worked for the NEC Corporation.
It was obvious to Boeing that the solution would require terminals that could keep the traffic orderly while under autonomous control. In addition, since one of the first envisioned applications would be fly-by-wire, the entire job should be done in hardware, since a software approach was considered to be very difficult to certify at that time. Since control laws would be the main users of the data on the buses, the protocol would have to be able to maintain the periodicity of all transmissions. It is from these requirements that DATAC was conceived and evolved. Integrity of the global bus was mandatory and kept foremost throughout the entire process.
The paper discusses the implementation and to gauge the scope of the hardware for this communications terminal, it states:
What followed was intensive work by Boeing and NEC to develop the single chip solution. It ended up as a 9000 gate, gate array device that essentially worked correctly right from the start.
The section from Shaw's 1986 paper does not support the assertion that "fundamental verification issues" were "bypassed." It appears that the design was relatively straightforward as it essentially worked correctly right from the start.
To this author, it appears that the Boeing engineers, with support from NEC, did a standard engineering trade-off in a logic design that was of rather modest size, about 9,000 gates, for a bus with a 1 Mbps rate. Indeed, integrity of this bus, developed for application to an advanced commercial transport airplane, was "mandatory and kept foremost throughout the entire process."
Now, let's fast forward about 20 years, and engineers still have and perform similar trade-offs. In fact, just a few years ago, we implemented a MIL-STD-1553B RT communications terminal, which was mission-critical for our instrument. This design was implemented in hardware (RTAX-S FPGA), there was absolutely no software involved, and it was a natural choice. And others, for their mission-critical communications, often use hardware implementations without pause.
Conclusion
It would be unethical for anyone to use any technology to avoid the rigor involved in assuring that a mission-critical or safety-critical design was reliable or safe. Several individuals from the software community have been raising the alarm that digital electronics are being used as a loophole of sorts to avoid fundamental assurance processes.
However, to date, no evidence supporting such an alarm has been found. Indeed, only "soft stories" from aircraft, over a decade ago, have been discussed. In my reviews of electronics in government and industry across the country, I have not seen evidence for supporting any such alarm, much less that it is widespread.
Home -
klabs.org
Last Revised:
February 03, 2010
http://twitter.com/klabsorg --
Web Grunt: Richard Katz