|
Main / Do-178
Vance Hilderman: Coding is the easy part. It's hammering nails - anyone can do it. IntroductionDesign Assurance Levels are A through E. Inspections happen at different points of development. DO-178 is not a standard, not a guideline, not a recipe book. It has considerations, not requirements. Instead, it asks "Do you have a good process, and do you follow it?" https://en.wikipedia.org/wiki/DO-178B The certification process needs to be planned in advance, because DERs may want to be on site for part of the process. At times, this can make for scheduling difficulties because you often must share the DERs with other entities and if a pre-planned date is missed it can set you back months waiting to get the DER on site again. The DER has a lot of say in how much oversight is required for your test processes if much of the work is outsourced. If the test procedure work is seen to be not very thorough, he could ask for 100% oversight. Ideally you'd want to be closer to 20% oversight. Running code coverage, test procedures, and system tests are "run for score" when the results are to be recorded and submitted for approval. The SW QA rep will want to observe when these tests are kicked off because he'll have to sign off as a witness. It is often possible to get credit for such tests, find a change is needed, but still retain credit for the testing of code that is proven to be unrelated to the change. What is dead code?It is in the binary, but never executed. Code that's not in the binary is called ignored. Basic TenetsEvery line of code must have a reason to exists and map to a requirement. SW QA is the most important job on the project. The 6 inputs into code review are:
A system is "certified" while a module is "certifiable". Once approved, don't improve! Finding bugs, conducting reviews is done by the engineering group, not QA. Planning docs address what/when/who (not much how):
Verification refers to reviews + test + analysis. 30 year rule - how long programs should be able to run. SW is only as good as the requirements fed into it. Most SW errors are due to poorly specified requirements. A good requirement can be sent to Hawaii and Siberia and the same design comes back. ExamplesBoot ROM code: if included with CPU, pass | if loaded by the BSP, must be certified.
Modelsspecification model = WHAT (high level), design model = HOW (low level) The SM traces to system level or high level SW requirements, has no data structure, no control/data flow, no architecture. The DM traces to SW requirements. All models have bi-directional traceability. Verification = reviews, test, analysis (only if it can't be covered with reviews and test) Am I happy with how it will come back if I don't refine it further? If so, that's a low-level requirement. Cost of fixing a defect is 7 times the cost of preventing it. How many reviewers? If more than one, divide responsibilities. Read 8110.49 - the Rosetta Stone for aviation As a general rule, modelling tools do NOT require qual. C++ used to be a no-no, but it's becoming more common. Must only use a subset!! Standard libraries? Throw them out so you don't have to vet them. Beware of malloc - do not use at run time!!! Maybe init. Big Vulnerabilities
Cost vs. QualityThere are various ladders on the curve as you strive for perfection. Left to right:
Other DOsDO-331 and -332 cover verification: reviews, test, analysis 330-333 are technical supplements to 178.
For software, remember that coupling is bad and cohesion is good. FPGAs fall under "complex electronics HW" and usually certified under 254. |