If I wish to downgrade my software's design assurance level (DAL) from Level A to Level C, what do I need to do? What are the benefits and drawbacks of doing this?
$\begingroup$
$\endgroup$
2
-
$\begingroup$ I'm not exactly sure what you are asking. Do you have software that is certified at level A, and you would like that same software to be certified at level C? Or do you have a level A system but you want to have level C software? Or something else entirely? $\endgroup$– usernumberAug 26, 2015 at 12:47
-
$\begingroup$ While I was giving an interview, he asked me about this. What are the consideration you would do if Level is degraded. And I answered as Certification/Verification effort(cost) would reduce, and was not sure that's what he was expecting $\endgroup$– LuckyAug 27, 2015 at 5:01
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
If I wish to downgrade my software's design assurance level (DAL) from Level A to Level C, what do I need to do?
DAL level A software is software which, if it fails, may have "catastrophic" results, defined as "Failure may cause multiple fatalities, usually with loss of airplane."
DAL level C, "Failure significantly reduces the safety margin or significantly increases crew workload. May result in passenger discomfort (or even minor injuries)."
So, to move your software from DAL level A to DAL level C, you'll have to reduce the responsibility of your software. Your software's operation or failure to operate cannot:
- result in passenger major injury or fatality
- produce a large negative impact on safety or performance of the aircraft
- reduce the ability of the crew to operate the aircraft due to physical distress or higher workload (though significant increases in workload is acceptable at Level C)
At most, your software's operation or failure to operate may:
- Significantly reduce safety margins
- Significantly increase crew workload
- Result in passenger discomfort or minor injury
If you can change your software, or change your customer's use of the software (ie, cannot be used or installed as part of a safety critical control system), then the certifying authorities may allow your software to be certified at Level C.
What are the benefits and drawbacks of doing this?
There are only 62 objectives that have to be met, and of those only 8 have to be verified by someone independent of the person who implemented the code that falls under that objective. While the number of objectives is only reduced a little (71 vs 62), the number requiring independent verification is cut by over 75% from 33 to 8. This significantly reduces the amount of work required to meet certification requirements, mostly in traceability.
The major drawback is that your software cannot be used or incorporated into systems which require a higher level of compliance.
So if your software is designed to control actuators and is currently certified to Level A, you might find that it's being used to control flight surfaces on some planes.
The move to Level C may, in that case, not require any software changes at all. If you stop performing the full traceability, tests, and meeting objectives with independence at Level A, and only perform those necessary for Level C, then your release under this new system will necessarily only be certified under Level C. The software can no longer be used to control flight surfaces, but if a new plane comes out with electronically adjustable air nozzles in the passenger compartment, it may be eligible for inclusion there where failure would, at worst, cause passenger discomfort and increase crew workload managing complaints about air vents being misdirected or opened/closed when the opposite is desired.
If your software is an autopilot, though, then it will never be used if it doesn't meet Level A. In this case, there's no way to change your software or process to a lower level and expect it to be used - the usage of the software defines the level to which it must comply.
In most cases, the usage will drive which level the software must be certified to, and there's no real way (or reason) for you to change your level. It would cease to be useful software at the wrong level.
$\begingroup$
$\endgroup$
1
If you are following DO-178B or DO-178C, you can't assign your software a design assurance level (DAL). That is the responsibility of the certification authority, such as the FAA in the US, Transport Canada in Canada, or EASA in Europe. There are analysis methods that are used to determine the appropriate level.
If a certification authority does downgrade your design assurance level, you will need to meet fewer objectives and fewer objectives satisfied with independence. An objective satisfied with independence means that the development processes and the verification and validation processes are carried out independently. Lower design assurance levels always have fewer objectives and fewer objectives with independence than the higher levels.
If you have software that is designed and certified at DAL Level A, then it can be used in place of software certified at any lower DAL level.
-
$\begingroup$ Software is not certified in itself; the certification is always in context of a system on a aircraft undergoing certificatoin. While it is true that software that has the certification artifacts for use in a DAL-A role on aircraft 1 will meet all the requirements for a DAL-C role on aircraft 2, nonetheless the DER (and ultimately the certifying authority) must be presented with the artifacts and acknowledge that it meets DAL-C before aircraft 2 can be certified. $\endgroup$ May 15, 2020 at 20:30