By Charlotte Adams
In the early years, because many players considered DO-254 too oppressive, the standard was evaded or ignored. Finally, in 2005, the Federal Aviation Administration (FAA) mandated DO-254.
However, understanding DO-254 in all of its ramifications is a different story. The same advisory circular (AC 20-152) that "advised" the avionics world to use DO-254 also rescoped DO-254 to focus primarily on custom-developed devices such as field programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs), excluding the board and box levels of hardware cited by the original document. Papers on the FAA Web site discuss DO-254 issues, and in 2008 the agency issued Order 8110.105 on the standard. Nevertheless there are still many questions.
A major concern behind the creation of DO-254 is that, particularly for the most complex parts, an inherent flaw could create a safety hazard, explains Tammy Reeve, an FAA designated engineering representative (DER) and president of Patmos Engineering Services in Issaquah, Wash. DO-254 attempts to provide design assurance via processes similar to those used in the software world. However, DO-254's obvious descent from the DO-178 software assurance standard -- some see as much as an 80 percent similarity -- is viewed as a problem by many in the community since hardware is not software, no matter how close the two may be.
Despite the requirement to use DO-254, there are nevertheless exemptions available if a part involves lower-criticality logic or commercial off-the-shelf (COTS) components, explains Vance Hilderman, president of HighRely in San Diego and the author of the only published book on DO-254.
There are also inconsistencies and ambiguities in the standard, together with questions about how it is being applied and a lack of knowledge about some technical aspects, Reeve says. The DO-254 document is "very immature, inconsistent in places, and unclear," she says.
Hilderman, however, asserts that the Certification Authorities Software Team's CAST-27 document was developed to clarify these inconsistencies.
Although the standard has been refocused on custom-developed logic for hardware, avionics systems designers were not relieved of the responsibility to get approval for the parts used in their products, says Frank Merlino, certification manager for ENSCO in Falls Church, Va., a company that helps clients negotiate the DO-254 process. The "applicant" for a DO-254 blessing is typically the FPGA or ASIC user, who seeks DO-254 approval as part of a system certification.
ENSCO has worked on a number of projects, including the implementation of AFDX (avionics full duplex ethernet) on the Boeing 787 and a display upgrade, says Jay Ficarro, director of avionics solutions for ENSCO.
User groups
Several years ago there was talk about the need for a revision of DO-254 -- a "Version A." But RTCA, the avionics industry standards group, has been so busy with the six-year-old project to develop a Version C of DO-178 that it has lacked the time and resources to address the hardware standard. This vacuum has been filled by industry groups, filing papers with the certification authorities to clarify points. As the DO-178C effort finally reaches closure, however, many support revising DO-254. The FAA is sponsoring a meeting this summer to discuss the standard, among other things, and an RTCA group could be formed as early as this year.
Given the long, drawn-out process to create DO-178C, others are convinced that it is better for DO-254 to be clarified as questions arise rather than from the top down. Reeve, who chairs the U.S. branch of the DO254 User Group, says that the problem with RTCA is that it relies on companies to volunteer people's time. "It takes too long," she says.
Reeve says user groups have had some success. The U.S. and European sides of her organization, for example, have submitted their thoughts on best practices regarding coding standards to the certification authorities.
A second group, known as the DO-254 Industry Group, also contributes to the understanding of the standard. Co-founded by Hilderman, this group includes more than 900 members in over 400 companies and 30 countries. Members share best practices via a daily blog at www.do254blog.com.
The FAA welcomes user groups as a source of feedback and international harmonization, say officials at the agency's Aircraft Certification Office. In FAA's strategic planning for 2012 and beyond, the agency will consider requesting RTCA to form a DO-254 committee, they say. Potential targets for revision are DO-254's tool qualification process, the use of intellectual property (IP) cores, the definition of a complex hardware item and documentation requirements for a "simple item."
Debating points
On a general level, FPGA designer Altera in San Jose, Calif., views the user groups as "trying to address the question of how DO-254 should be deployed and what the requirements should be," says Jeff Lamparter, senior business manager for the company's military and aerospace business unit. How will it go forward, he asks. "Will it be made more formal, more rigorous?" The company has had success so far. Last year the European Aviation Safety Agency (EASA) approved a Thales safety-critical avionics application containing a DO-254-certifiable version of Altera's FPGA-based Nios II embedded processor.
Observers also note that DO-254 is loosely written. Like the tax code it encourages people to take shortcuts that reduce costs but might not be appropriate. Another beef is that DO-254 and the guidance that has come down concerning it -- AC 20-152 and FAA Order 8110.105 -- need to be harmonized to remove any conflicts between the documents.
"It becomes a little ambiguous what to follow and what everything actually means," Merlino comments. He thinks it probably would be a good thing to get a revised standard that incorporates and harmonizes existing guidance.
DO-254 is also more loosely written than DO-178 is, Hilderman says. Level C is much easier to meet under the hardware standard than under the software standard. Level C in the hardware standard, for example, has a lower threshold to meet for internal verification of the logic than is required by DO-178.
Another issue is that there is very little difference between Level A and Level B in DO-254, he says. The authors of DO-254 missed this ambiguity, Hilderman says. They make it sound as though there's a difference, but they didn't follow through.
A further challenge is that the Europeans are perceived by some in the industry to be following DO-254 more strictly than the FAA is doing, in reaction to criticism that they took an easier stance on DO-178B. So developers coming under EASA's jurisdiction may face a tougher task.
Reusability
There is a host of more concrete issues bearing on the degree of labor required to get one's product approved. Among these are whether a device's IP core is COTS or non-COTS, complex or simple, and reusable or one-off.
An FPGA is typically programmed with a combination of COTS and custom IP, creating a device similar to an ASIC, explains Ching Hu, avionics market manager for semiconductor maker, Xilinx in san Jose, Calif. The FAA considers the hardware description language used to create the IP core as hardware, he says.
The big issue is reusability, Hu says. If the user certifies a product with five FPGA IPs and then develops a second, slightly different, end-product reusing three of the IPs, the user still has to "redo a lot of the certification effort," he says.
That is where Xilinx's forthcoming R2 Flows comes in. These soon-to-be-launched design flows encompass reusability and reliability. Hence the full name of the platform is Reliable and Reusable Design Flows. These design methodologies and tools will help to reduce the user's certification burden, Hu asserts.
First, R2 Flows will allow users to prove to the certification authorities that a previously certified IP has not changed from the first to the second product, Hu contends. This will greatly reduce or eliminate a recertification effort when reusing a previously approved IP, he says. If the second product adds some additional customized IP to the FPGA, the certification effort would still be greatly reduced, focusing mainly on the new IP rather than the full design, he says.
The technology also promises to allow an FPGA to host functions with different assurance levels on separate regions of the device. The Xilinx flow provides a means of preventing error propagation between regions and a means to verify the functional partitioning.
Xilinx now must convince the certification authorities that its approach will work, but the company is confident, based on the platform's extensive defense heritage, that the authorities and DERs will buy into its strategy, Hu says.
Hardware verification is also an issue, says Louie De Luna, DO-254 program manager with Aldec, a tool provider. FPGA-level verification is required for Levels A and B, but "not a lot of people are implementing it," he says. Aldec provides fully customized software and hardware, enabling a functional test at the FPGA level. "Our methodology is FPGA-level verification," which addresses the specification defined in AC 20-152, De Luna says.
What does all this mean for avionics hardware developers? "The days of acceptance based upon prior track record are over," Hilderman warns. "All avionics developers should heed the ABCs of hardware development, namely DO-254, AC 20-152, and CAST-27. It's a new and more rigorous world."
http://www.synopsys.com/Solutions/IndustrySegmentSolutions/MilAero/CapsuleModule/DO-254_WP.pdf
http://www.ukintpress-conferences.com/conf/aerona05/pres/otf_1/hilderman.pdf
http://www.militaryaerospace.com/index/display/avi-article-display/8843377420/articles/avionics-intelligence/features-and-analysis/2011/3/do-254_-thinking_outside.html
http://www.mentor.com/products/fpga/multimedia/do-254-overview-webseminar
http://en.wikipedia.org/wiki/DO-254
http://www.do254.com/
Your feedback is always welcome.
Thank you!
http://www.winncad.com/
http://www.docstoc.com/profile/corona7
http://www.linkedin.com/pub/paul-corona/10/63a/200
http://www.scribd.com/crown%20007
http://www.facebook.com/people/WinnCad-Elements/100001525374479
http://www.youtube.com/user/Winncad
Developed by the RTCA in 2000, DO-254 was prompted by the need to address potential safety issues regarding electronic hardware -- chips, boards, and boxes. It is now required on all civil aircraft types, including helicopters, and the military is adopting it as well.
Before DO-254 avionics software was governed by DO-178B, but equally complex, silicon-based logic, or firmware, was unregulated. In the early years, because many players considered DO-254 too oppressive, the standard was evaded or ignored. Finally, in 2005, the Federal Aviation Administration (FAA) mandated DO-254.
However, understanding DO-254 in all of its ramifications is a different story. The same advisory circular (AC 20-152) that "advised" the avionics world to use DO-254 also rescoped DO-254 to focus primarily on custom-developed devices such as field programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs), excluding the board and box levels of hardware cited by the original document. Papers on the FAA Web site discuss DO-254 issues, and in 2008 the agency issued Order 8110.105 on the standard. Nevertheless there are still many questions.
A major concern behind the creation of DO-254 is that, particularly for the most complex parts, an inherent flaw could create a safety hazard, explains Tammy Reeve, an FAA designated engineering representative (DER) and president of Patmos Engineering Services in Issaquah, Wash. DO-254 attempts to provide design assurance via processes similar to those used in the software world. However, DO-254's obvious descent from the DO-178 software assurance standard -- some see as much as an 80 percent similarity -- is viewed as a problem by many in the community since hardware is not software, no matter how close the two may be.
Despite the requirement to use DO-254, there are nevertheless exemptions available if a part involves lower-criticality logic or commercial off-the-shelf (COTS) components, explains Vance Hilderman, president of HighRely in San Diego and the author of the only published book on DO-254.
There are also inconsistencies and ambiguities in the standard, together with questions about how it is being applied and a lack of knowledge about some technical aspects, Reeve says. The DO-254 document is "very immature, inconsistent in places, and unclear," she says.
Hilderman, however, asserts that the Certification Authorities Software Team's CAST-27 document was developed to clarify these inconsistencies.
Although the standard has been refocused on custom-developed logic for hardware, avionics systems designers were not relieved of the responsibility to get approval for the parts used in their products, says Frank Merlino, certification manager for ENSCO in Falls Church, Va., a company that helps clients negotiate the DO-254 process. The "applicant" for a DO-254 blessing is typically the FPGA or ASIC user, who seeks DO-254 approval as part of a system certification.
ENSCO has worked on a number of projects, including the implementation of AFDX (avionics full duplex ethernet) on the Boeing 787 and a display upgrade, says Jay Ficarro, director of avionics solutions for ENSCO.
User groups
Several years ago there was talk about the need for a revision of DO-254 -- a "Version A." But RTCA, the avionics industry standards group, has been so busy with the six-year-old project to develop a Version C of DO-178 that it has lacked the time and resources to address the hardware standard. This vacuum has been filled by industry groups, filing papers with the certification authorities to clarify points. As the DO-178C effort finally reaches closure, however, many support revising DO-254. The FAA is sponsoring a meeting this summer to discuss the standard, among other things, and an RTCA group could be formed as early as this year.
Given the long, drawn-out process to create DO-178C, others are convinced that it is better for DO-254 to be clarified as questions arise rather than from the top down. Reeve, who chairs the U.S. branch of the DO254 User Group, says that the problem with RTCA is that it relies on companies to volunteer people's time. "It takes too long," she says.
Reeve says user groups have had some success. The U.S. and European sides of her organization, for example, have submitted their thoughts on best practices regarding coding standards to the certification authorities.
A second group, known as the DO-254 Industry Group, also contributes to the understanding of the standard. Co-founded by Hilderman, this group includes more than 900 members in over 400 companies and 30 countries. Members share best practices via a daily blog at www.do254blog.com.
The FAA welcomes user groups as a source of feedback and international harmonization, say officials at the agency's Aircraft Certification Office. In FAA's strategic planning for 2012 and beyond, the agency will consider requesting RTCA to form a DO-254 committee, they say. Potential targets for revision are DO-254's tool qualification process, the use of intellectual property (IP) cores, the definition of a complex hardware item and documentation requirements for a "simple item."
Debating points
On a general level, FPGA designer Altera in San Jose, Calif., views the user groups as "trying to address the question of how DO-254 should be deployed and what the requirements should be," says Jeff Lamparter, senior business manager for the company's military and aerospace business unit. How will it go forward, he asks. "Will it be made more formal, more rigorous?" The company has had success so far. Last year the European Aviation Safety Agency (EASA) approved a Thales safety-critical avionics application containing a DO-254-certifiable version of Altera's FPGA-based Nios II embedded processor.
Observers also note that DO-254 is loosely written. Like the tax code it encourages people to take shortcuts that reduce costs but might not be appropriate. Another beef is that DO-254 and the guidance that has come down concerning it -- AC 20-152 and FAA Order 8110.105 -- need to be harmonized to remove any conflicts between the documents.
"It becomes a little ambiguous what to follow and what everything actually means," Merlino comments. He thinks it probably would be a good thing to get a revised standard that incorporates and harmonizes existing guidance.
DO-254 is also more loosely written than DO-178 is, Hilderman says. Level C is much easier to meet under the hardware standard than under the software standard. Level C in the hardware standard, for example, has a lower threshold to meet for internal verification of the logic than is required by DO-178.
Another issue is that there is very little difference between Level A and Level B in DO-254, he says. The authors of DO-254 missed this ambiguity, Hilderman says. They make it sound as though there's a difference, but they didn't follow through.
A further challenge is that the Europeans are perceived by some in the industry to be following DO-254 more strictly than the FAA is doing, in reaction to criticism that they took an easier stance on DO-178B. So developers coming under EASA's jurisdiction may face a tougher task.
Reusability
There is a host of more concrete issues bearing on the degree of labor required to get one's product approved. Among these are whether a device's IP core is COTS or non-COTS, complex or simple, and reusable or one-off.
An FPGA is typically programmed with a combination of COTS and custom IP, creating a device similar to an ASIC, explains Ching Hu, avionics market manager for semiconductor maker, Xilinx in san Jose, Calif. The FAA considers the hardware description language used to create the IP core as hardware, he says.
The big issue is reusability, Hu says. If the user certifies a product with five FPGA IPs and then develops a second, slightly different, end-product reusing three of the IPs, the user still has to "redo a lot of the certification effort," he says.
That is where Xilinx's forthcoming R2 Flows comes in. These soon-to-be-launched design flows encompass reusability and reliability. Hence the full name of the platform is Reliable and Reusable Design Flows. These design methodologies and tools will help to reduce the user's certification burden, Hu asserts.
First, R2 Flows will allow users to prove to the certification authorities that a previously certified IP has not changed from the first to the second product, Hu contends. This will greatly reduce or eliminate a recertification effort when reusing a previously approved IP, he says. If the second product adds some additional customized IP to the FPGA, the certification effort would still be greatly reduced, focusing mainly on the new IP rather than the full design, he says.
The technology also promises to allow an FPGA to host functions with different assurance levels on separate regions of the device. The Xilinx flow provides a means of preventing error propagation between regions and a means to verify the functional partitioning.
Xilinx now must convince the certification authorities that its approach will work, but the company is confident, based on the platform's extensive defense heritage, that the authorities and DERs will buy into its strategy, Hu says.
Hardware verification is also an issue, says Louie De Luna, DO-254 program manager with Aldec, a tool provider. FPGA-level verification is required for Levels A and B, but "not a lot of people are implementing it," he says. Aldec provides fully customized software and hardware, enabling a functional test at the FPGA level. "Our methodology is FPGA-level verification," which addresses the specification defined in AC 20-152, De Luna says.
What does all this mean for avionics hardware developers? "The days of acceptance based upon prior track record are over," Hilderman warns. "All avionics developers should heed the ABCs of hardware development, namely DO-254, AC 20-152, and CAST-27. It's a new and more rigorous world."
http://www.synopsys.com/Solutions/IndustrySegmentSolutions/MilAero/CapsuleModule/DO-254_WP.pdf
http://www.ukintpress-conferences.com/conf/aerona05/pres/otf_1/hilderman.pdf
http://www.militaryaerospace.com/index/display/avi-article-display/8843377420/articles/avionics-intelligence/features-and-analysis/2011/3/do-254_-thinking_outside.html
http://www.mentor.com/products/fpga/multimedia/do-254-overview-webseminar
http://en.wikipedia.org/wiki/DO-254
http://www.do254.com/
Your feedback is always welcome.
Thank you!
http://www.winncad.com/
http://www.docstoc.com/profile/corona7
http://www.linkedin.com/pub/paul-corona/10/63a/200
http://www.scribd.com/crown%20007
http://www.facebook.com/people/WinnCad-Elements/100001525374479
http://www.youtube.com/user/Winncad
No comments:
Post a Comment