Category Archives: DO-330

DO-178C In a Nutshell

Posted on by

If you’re reading this, it’s a safe bet that you have something to do with the aerospace industry. And it would be a safer bet that you’ve (at least) heard of what most avionics professionals consider the quintessential avionics document, DO-178C. The multifaceted and highly technical go-to guideline for all commercial software-based aerospace systems, DO-178C is vital to modern-day avionics project planning and development. Although there are many dense details to cover, we wanted to quickly note some of the key concepts of 178C (the latest version of DO-178) and a couple ways it’s applied to today’s aerospace projects. We’ll Continue Reading > > >

Combined DO-178C Training and DO-330 Training Nov 2019

Posted on by

Applying Optimized DO-178C Practices    1- DO-178C Design Assurance and Relationship with ARP-4754A/4761. 2- DO-178C PSAC explanation in detailed. 3- Optimized DO-178C process planning (SDP and impact Lifecycle decisions). 4- DO-178C Development Process, Traceability & Development Best Practices. 5- Explanation of DO-178C Testing and Structural Coverage and how to craft SVP. 6- Impact of DO-178C Integral Process (SCMP and SQAP). 7- DO-178C Industry Facts and Compliance cost drivers. 8- Differences and Challenges between DO-178B and DO-178C.   Understand and Fine-tune DO-178C Engineering Challenges 1- Parameter Data Items and Requirement Workshop. 2- DO-178C Data Coupling & Control Coupling Analysis by test. Continue Reading > > >

DO-330 Understanding: Software Tool Qualification Considerations

Posted on by

DO-330 is a set of considerations which can also be used outside airborne and ground based avionics systems.  It is not a supplement DO-178C & DO-278A like DO-331, 223, and 333. DO-330 was developed for the following reasons: Tools are different from the software developed using the tools and form a unique domain; therefore, tool-specific guidance for both tool developers and tool users is needed. Tools are often developed by teams other than those who use the tools to develop software. Typically, these tool development teams do not have software guidance backgrounds. Having a tool specific document helps tool development Continue Reading > > >