As someone wanting to transition from a rapid-prototype environment where CI/CD* tools are used, to a formal DO-178C environment.. would love to see an end to end example of a project that implements all the DO-178C guidelines for a Design Assurance Level A project (or LM says SEAL Level 1 or Boeing XXX, etc). For example, what are the typical outputs/documents required.. what are the typical software tools that are a must-have in the various stages of the software life cycle.. noting the difference between checking style and finding bugs: Requirement Management - DOORS, Jama Static Source Code Analysis - Parasoft, PolySpace, CodeSonar, horusec , sonar cloud, veracode PREFast Dynamic Analysis - VectorCAST, RapiTest Configuration Management - Git, SourceSafe QA - Helix ALM V&V - VectorCAST, LDRA Testbed What is the general attitude towards open source software (ex. FreeRTOS) and code-generation tools (ST's Cube MX). How do CPLD and FPGAs fit in to the picture.. since not exactly software, but they are programmable devices written in a HDL. *CI - Continuous Integration / CD - Continuous Delivery/Deployment : Travis CI , Bugzilla, Jira, jenkinsio, GitLab
I paid close attention to what was being said, reviewing the slides, etc., only to be somewhat distracted by the frequent filler words "uh" and "um" ... it would have been helpful if the speaker had rehearsed his presentation several times prior to delivery. Otherwise, I appreciated what was expressed.
@4:30 Before DO-178 there were no catastrophic events in aviation directly attributed to uncertified software. That said, the closest hull-loss event attributed directly to software was Malaysia Airlines Flight MH 124, where certified software caused a voting system malfunction that nearly destroyed the aircraft. I work in this industry and feel like DO-178, ARP-4754, and DO-254 are contributing to serious workmanship issues in software systems. @21:00 "[we didn't want someone to build a model ans say that the model is the requirements]" That's exactly what happened to Boeing.
No question that all of the documents you’ve listed have reduced product quality by limiting the amount of competition allowed in avionics. I think we can count on our fingers the number of companies that can afford to produce DAL-A level software.
I also work in the avionics industry - 7 years with designing systems and software for integrating supplier systems into the core avionics system, and the last 2/3 years as an engineer of "supplier systems". Most engineers I've worked with which are following in-house processes derived from DO-178B/C know jack shit about the intricate details of computers, operating systems and associated software, which are essential in order to design safe (or at least requirements-compliant) software. Almost always, this results in the engineers spending the majority of their time filling in checkboxes in Excel sheets or requirements databases. This is not helpful in order to achieve safe and high-quality software. Even worse are all company-internal process and review meetings filled with staff from the quality engineering department which know jack shit about computers or software. I'd rather see strict regulations as to which people are allowed to work with avionics software, including mandatory training each year to keep staff up-to-date as to what's happening within the world of software development. My experience is that DO-178C is so goddamn anal that it's prohibiting software engineers from quickly fixing bugs, re-factoring the software in order to increase quality or keeping up-to-date with newer and better compilers and libraries. Who the fuck wants to qualify compilers, libraries, debuggers, unit testing tools etc. all day long? Nobody. What does this lead to? Skilled engineers with ample of other career opportunities flee the world of avionics software development, leaving behind two categories of engineers: 1) Those who are skilled and are in the game because they like avionics and like the challenge. 2) Those who seek employment stability in large corporations. It's a tragedy that the first category needs to be dragged down by the second.
As someone wanting to transition from a rapid-prototype environment where CI/CD* tools are used, to a formal DO-178C environment.. would love to see an end to end example of a project that implements all the DO-178C guidelines for a Design Assurance Level A project (or LM says SEAL Level 1 or Boeing XXX, etc).
For example, what are the typical outputs/documents required.. what are the typical software tools that are a must-have in the various stages of the software life cycle.. noting the difference between checking style and finding bugs:
Requirement Management - DOORS, Jama
Static Source Code Analysis - Parasoft, PolySpace, CodeSonar, horusec , sonar cloud, veracode PREFast
Dynamic Analysis - VectorCAST, RapiTest
Configuration Management - Git, SourceSafe
QA - Helix ALM
V&V - VectorCAST, LDRA Testbed
What is the general attitude towards open source software (ex. FreeRTOS) and code-generation tools (ST's Cube MX).
How do CPLD and FPGAs fit in to the picture.. since not exactly software, but they are programmable devices written in a HDL.
*CI - Continuous Integration / CD - Continuous Delivery/Deployment : Travis CI , Bugzilla, Jira, jenkinsio, GitLab
I paid close attention to what was being said, reviewing the slides, etc., only to be somewhat distracted by the frequent filler words "uh" and "um" ... it would have been helpful if the speaker had rehearsed his presentation several times prior to delivery. Otherwise, I appreciated what was expressed.
Very comprehensive. Thank you.
@4:30 Before DO-178 there were no catastrophic events in aviation directly attributed to uncertified software. That said, the closest hull-loss event attributed directly to software was Malaysia Airlines Flight MH 124, where certified software caused a voting system malfunction that nearly destroyed the aircraft. I work in this industry and feel like DO-178, ARP-4754, and DO-254 are contributing to serious workmanship issues in software systems.
@21:00 "[we didn't want someone to build a model ans say that the model is the requirements]" That's exactly what happened to Boeing.
No question that all of the documents you’ve listed have reduced product quality by limiting the amount of competition allowed in avionics.
I think we can count on our fingers the number of companies that can afford to produce DAL-A level software.
I also work in the avionics industry - 7 years with designing systems and software for integrating supplier systems into the core avionics system, and the last 2/3 years as an engineer of "supplier systems".
Most engineers I've worked with which are following in-house processes derived from DO-178B/C know jack shit about the intricate details of computers, operating systems and associated software, which are essential in order to design safe (or at least requirements-compliant) software.
Almost always, this results in the engineers spending the majority of their time filling in checkboxes in Excel sheets or requirements databases. This is not helpful in order to achieve safe and high-quality software. Even worse are all company-internal process and review meetings filled with staff from the quality engineering department which know jack shit about computers or software.
I'd rather see strict regulations as to which people are allowed to work with avionics software, including mandatory training each year to keep staff up-to-date as to what's happening within the world of software development.
My experience is that DO-178C is so goddamn anal that it's prohibiting software engineers from quickly fixing bugs, re-factoring the software in order to increase quality or keeping up-to-date with newer and better compilers and libraries.
Who the fuck wants to qualify compilers, libraries, debuggers, unit testing tools etc. all day long?
Nobody.
What does this lead to? Skilled engineers with ample of other career opportunities flee the world of avionics software development, leaving behind two categories of engineers: 1) Those who are skilled and are in the game because they like avionics and like the challenge. 2) Those who seek employment stability in large corporations.
It's a tragedy that the first category needs to be dragged down by the second.
very nice