We receive a lot of questions about Safety Critical Engineering around Aerospace, especially concerning applications and products that are developed under the guidelines and requirements of DO-178 and DO-254. At Novel, we would like to share information that may help you in your endeavors under these guidelines, likely saving you money and time.
What is Safety Critical Engineering?
Simply put, Safety Critical Engineering is engineering around systems whose improper operation, malfunction or destruction may cause casualties. Typical Safety Critical Applications include some form of control over a transportation system or medical device. Depending on your industry, you may associate Safety Critical Engineering with a pacemaker, EKG, or automatic defibrillator. You may associate Safety Critical Engineering with airplanes, rockets, and other aerospace related modes of transport. In all cases, if these systems catastrophically fail, the result may be harm, injury or death.
Specifically, for Aerospace, what is DO-178 and DO-254?
DO-178 and DO-254 are guidelines published by RTCA, Inc. which provide guidance (process) for designing and developing complex electronic hardware and software for use in aircraft. Federal authorities, such as the FAA and EASA, have adopted these guidelines, as have agencies such as NASA. Many people view 178 and 254 compliance as a required set of “documents” that must be generated to get certification. This thinking usually results in a huge cost overrun as nothing could be further from the truth. The rest of the following questions may help clear up some misconceptions.
I have to be DO-178 compliant, so what do I have to do?
First, understand that the guidelines were developed to help engineers design and produce products with a process that will ensure best practices are used with an emphasis on reducing overhead, reducing overengineering, reducing latent errors, reducing bugs, all within a predictable cost. In order to achieve these results, you must plan properly. Attempting to apply DO 178/254 processes to products already developed is like trying to draw blueprints, develop architectural plans, and provide structural and mechanical PE sign off on a house that is already built. It can be done through intelligent “reverse engineering”, but that is not the most efficient way to do it.
Planning is the first phase in a DO-178/DO-254 project
Planning is critical to any successful project. During this phase, you are going to generate plans specifically around Quality Assurance, Process Assurance, Configuration Management, Development, Verification and Validation, and Certification. It’s crucial to know that your plan may change during execution of the project, but you really would prefer not to. Try to get your plans nailed down up front and don’t paint yourself into a corner!
Requirements Capture is the second phase
Requirements are a huge deal. In fact, in my humble opinion, they are the biggest driver of cost (both schedule and money). While I love agile processes like SCRUM (we use them at Novel), don’t fall into the trap that “requirements are bad”. As an avionics engineer, every time I heard the words “user story”, I think “stories don’t keep airplanes in the air.” I do believe in Agile Processes like SCRUM, but be careful in understanding the difference between process required documents and project managed methods. (More to come in future posts about applying AGILE to Safety Critical Processes).
Design is the third phase
Yes, you need design. Yes, requirements should constrain design. Design should constrain implementation. Enough Said.
Implementation is the fourth phase
If you’ve done the upfront legwork, Planning, Standards, Requirements, Design, then this is the easiest of phases. In this phase, you’re writing code, producing circuits, and starting to view the fruits of your labor.
Verification is the fifth phase
Now is the time to prove that the requirements were met. Does the product functionally work per the requirements? Have we completely exercised the product per the requirements? This is the time to test the heck out of your product to ensure that no failures, bugs or latent problems exist in the product, with respect to the requirements. See the subtle hint here? There are two main inputs to this phase, requirements, and implementation. One is the unit under the test, the other drives our effort.
Along the way, you’re doing Validation
Validation is easy, it’s the process of ensuring that each subsequent step is aligned with the previous. For example, does the implementation match the design? Does the design match the requirements? Is everything complete in regards to its parent? Was nothing added that should not be?
So the million dollar question (quite literally) is…
How do I save money on my project?
Requirements, Requirements, Requirements, Requirements. I often tell people that the hidden titles of DO178 and DO254 are “Requirements-based software development and hardware development”. In my future blog, I’ll describe some easy rules and methods for ensuring good requirements. As a rule of thumb, every dollar spent on achieving good requirements saves you 10 wasted on bad requirements. Want to cut your verification costs? Spend 10% of your V&V budget on fixing the requirements before you begin.
Part 2 of this series focuses on Requirements. Check it out here.
Novel Engineering, Inc.’s core competencies in engineering embedded applications for aerospace has evolved around the company’s expert-level knowledge of following the FAA standards associated with developing these safety and mission-critical systems. Novel also has partnerships with expert level DERs and will provide consultation during any Stage-of-Involvement (SOI) audit along with support and guidance for Type Certificate (TC), Amended Type Certificate (ATC), Supplemental Type Certificate (STC), and Technical Standard Order (TSO) certifications.