Question 1. What Is The Added Do-178b Cost?
DO-178B is often thought to add 50-200% to avionics software development. In reality, actual additional DO-178B cost should be on the order of 25%-40%, presuming basic high-reliability (SEI CMM and CMMI Level 2 or 3) software engineering principles are used from the onset. Our members can show how to minimize avionics software development costs.
Question 2. What Are The Do-178b Benefits?
In addition to being necessary for flight products, DO-178B benefits include: verifiable software quality, higher reliability, consistency, greater re-usability, lower lifecycle costs, decreased maintenance cost, faster hardware integration, and greater portability.
Question 3. Can You Apply Do-178b Reverse Engineering To Your Existing Software?
Yes, while DO-178B applies principally to new, custom software, there are provisions to apply DO-178B reverse-engineering to previously developed software, preserving most of the already completed work.
Question 4. What Is Do-178b Tool Qualification?
Software development requires many tools including design tools, code generation tools, compilers/linkers, libraries, test tools, and structural coverage tools. DO-178B tool qualification pertains to development and testing tools. Different qualification criteria apply to each and most tools do NOT need to be qualified. When required, DO-178B tool qualification utilizes a subset of DO-178B.
Question 5. What Is Do-178b Gap Analysis?
DO178B Gap Analysis is an evaluation of your current avionics software engineering process and artifacts as contrasted to those required by DO-178B. While DO-178B was principally written to cover original, custom developed avionics software, there is recognition that previously developed software can be DO-178B certified. In many cases, particularly military avionics software, DO-178B Compliance is used instead of DO-178B certification.
DO-178B Compliance is near-certification but does not require FAA involvement and several of the formal DO-178B requirements are lessened. DO-178B Gap Analysis is typically performed by trained DO-178B consultants or Designated Engineering Representatives. The resultant DO-178B Gap Analysis RoadMap assesses all of the software processes and artifacts. It provides details for filling the gap to meet DO-178B compliance or certification requirements.
Question 6. What Is Mc/dc?
The official definition of MCDC, Modified Condition/Decision Coverage) is Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken on all possible outcomes at least once, and each condition has been shown to affect that decision outcome independently. A condition is shown to affect a decisions outcome independently by varying just that decision while holding fixed all other possible conditions.
The key to successful, and accurate, MCDC testing is to analyze each sourcecode construct for potential MCDC applicability and then develop sufficient test cases to ensure that each condition in that construct is independently verified per the aforementioned MC/DC definition. Today, most MC/DC testing is done with the assistance of DO-178B qualified structural coverage tools, particularly MCDC tools.
Question 7. What Is Avionics Dead Code?
DO-178B dead code is executable (binary) software that will never be executed during runtime operations. D0178B generally does not allow for the presence of dead code: it must be removed. Dead code does not trace to any software requirements, hence does not perform any required functionality. Note that unreferenced variables or functions which are not called (hence are unreferenced) elsewhere in the program are usually removed via the compiler or linker. Since they are not present in the binary executable load image, they are not dead code per DO-178B.
Question 8. What Is Avionics Deactivated Code?
DO-178B deactivated code is executable (binary) software that will not be executed during runtime operations of a particular software version within a particular avionics box; however the code may be executed during maintenance or special operations or be executed within a different or future version of the software within a different configuration or avionics box. Unlike dead code (see above), deactivated code may be left in the source baseline. Special DO-178B deactivated code aspects must be followed. These are fully described in our member’s DO-178B classes;
Question 9. What Is Do-178b Requirements Traceability?
D0178B requirements traceability pertains to the correlation of individual requirements to the design, code, and test elements affiliated with implementing and verifying each requirement. Requirements traceability can be many-to-one, and one-to-many. Requirements traceability needs to be from top-to-bottom (requirements to design to code, and requirements to test). This proves that all requirements have corresponding design elements, sourcecode, and tests. Requirements traceability also needs to be bottom-to-up (tests to requirements, code to design, and design to requirements). This proves that all code, design, and test elements are necessary and have requirements which they implement or verify.
Question 10. Which Software Language Is Best For Avionics Software?
High order languages (requiring a compiler with complex syntax construction capabilities) are strongly preferred as they are simply safer. Safe avionics software? Yes, DO-178B emphasizes code consistency, visibility, determinism, defensive coding, robustness, requirements and design traceability, software peer reviews per detailed checklists, thorough testing via structural coverage and real-world asynchronous testing.
Per the above, avionics code is best written in Ada, C and C++. With all languages, a safe subset should be used. Ada was the former defacto avionics language standard, and Ada95 improved the Objected Oriented capabilities. However, the tide is behind C and C++; not because of inherent superiorities, but rather the wider availability of development tools and engineers able to develop real-time embedded C and C++.
Question 11. Which Do-178b Configuration Management (cm) Tools Are Best?
DO-178B requires configuration management of all software lifecycle artifacts including requirements, design, code, tests, documentation, etc. However, DO178B does not require specific tools, not even for avionics configuration management. Hence, avionics configuration management can be performed manually and even via a purely paper-based system. However, virtually all avionics and DO-178B software projects would be better served via configuration management tool. Simple tools (free or low-cost: $0 – $200/user) provide for basic software version control, check-in/check-out, and document management. Higher cost tools provide more complexity and automation of the required DO-178B configuration management processes including problem tracking, version branching, reviews/statusing, metrics, etc.
No commercially available FAA CM tool known to us, however, performs all of the required DO-178B configuration management process steps. In particular, data security, offsite backups, peer reviewing each change, and ensuring no unwarranted changes were made, are all DO-178B configuration management process steps that are typically performed outside the scope of an avionics configuration management tool.
Question 12. What Is A Do-178b Checklist?
Checklists are used to ascertain and track DO-178B compliance. DO-178B checklists are available from public domain information if you have the time to assemble it (no such checklist is really proprietary or trade-markable), or from private sources who have merely assembled public domain information;
Question 13. What Is Do-178b Independence?
DO-178B independence is the attribute of separate development and review authority applied to different DO-178B lifecycle process steps. Development refers to origination of a DO-178B required artifact (requirements, design, code, test, etc). Review authority refers to an individual tasked with the required DO-178B compliance review of that artifact. The tables in the back of DO-178B describe which artifacts must be reviewed. The tables also cite the level of DO-178B independence to be applied to each review. These independence levels are dictated by the criticality level associated with each review protocol.
Question 14. What Is A Do-178b Criticality Level?
There are five D0/178B criticality levels, with DO-178B Level A being most critical and DO-178B Level E being least critical. The DO-178B criticality level is based upon the contribution of the associated software to potential failure conditions. DO-178B failure conditions are determined by the FAA system safety assessment process. Each avionics system has one defined criticality level (and must be approved by the FAA); however different components within that system can have differing criticality levels subject to certain guidelines. The higher the DO-178B criticality level, the greater the amount of software development effort required. Our DO-178B Training provides additional details on DO-178B criticality levels and how to determine, apply and optimize.
Question 15. What Is Do-178b Level A?
DO-178B Level A software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a catastrophic failure condition for the aircraft. Failure of DO-178B Level A software could be typified by total loss of life. Approximately 20-30% of avionics systems and 40% of avionics software code must meet DO-178B Level A criteria.
Question 16. What Is Do-178b Level B?
DO-178B Level B software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a hazardous/severe-major failure condition for the aircraft. Failure of DO-178B Level B software could be typified by some loss of life. Approximately 20% of avionics systems and 30% of avionics software code must meet DO-178B Level B criteria.
Question 17. What Is Do-178b Level C?
DO-178B Level C software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a major failure condition for the aircraft. Failure of DO-178B Level C software could be typified by serious injuries. Approximately 25% of avionics systems and 20% of avionics software code must meet DO-178B Level C criteria.
Question 18. What Is Do-178b Level D?
DO-178B Level D software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a minor failure condition for the aircraft. Failure of DO-178B Level D software could be typified by minor injuries. Approximately 20% of avionics systems and 10% of avionics software code must meet DO-178B Level D criteria.
Question 19. What Is Do-178b Level E?
DO-178B Level E software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function with no effect on aircraft operational capability or pilot workload. Failure of DO-178B Level E software would have no impact on passenger or aircraft safety. Approximately 10% of avionics systems and 5% of avionics software code must meet DO-178B Level E criteria (note however that the amount of DO-178B Level E sourcecode is increasing due to passenger entertainment and internet communications subsystems that are currently designated Level E; it is deemed likely by us that the criticality levels of these systems will increase due to integration with other, more critical, avionics systems).
Question 20. What Is Avionics Software Structural Coverage?
RTCA/DO-178B structural coverage requirements pertain to the proof that formal software verification test cases fully covered the applicable software structures (conditions and paths). DO-178B structural coverage is not required for Level E and Level D software; it is required in increasing degrees for Level C, Level B, and Level A software. DO-178B statement coverage is required for Level C; this essentially requires each code statement to be executed by formal test cases.
DO-178B decision condition coverage is required for Level B; this essentially requires each code branch to be executed by formal test cases. DO-178B modified condition decision coverage is required for Level A; this essentially requires each condition within each decision statement to be independently verified for its effect on that statement. DO-178B structural coverage is complex and is a primary cost driver on avionics project. DO-178B structural coverage tools exist from many vendors to assist in verification.78B
Question 21. What Is Do-178b Certifiability?
DO-178B Certifiability is the designation of an avionics component to meet a defined subset of the DO-178B certification requirements, with the remaining certification requirements to be achieved subsequently. DO-178B certification pertains to individual systems, hence requires all software components of a system to be completed, with each component, and the system, fully meeting all DO-178B requirements. However, in the absence of a completed system, an individual software component (RTOS, graphics library, communications protocol, etc) can be designated certifiable by subjecting that component to all DO-178B requirements.
Question 22. What Is Do-178b Compliance (do-178b For Military)?
Military DO178 is a subset of DO-178B. Until recently, aerospace and military software standards emphasized documentation consistency rather than the modern software lifecycle attributes associated with avionics software safety (SEI CMM and CMMI). Led by the U.S. Military, there has been gradual adoption of DO-178B to emulate the commercial aviation industry. However, Military DO-178B does not require FAA and Designated Engineering Representative involvement, and certain DO-178B requirements are lessened.
Question 23. What Are The Top Ten Do-178b Certification Risks?
Specific risks are:
- inadequate DO-178B low-level software requirements
- vagueness within the five key DO-178B process plans prior to initiating those lifecycles
- insufficient independence of DO-178B reviews
- insufficient DO-178B checklists for reviews
- inadequate DO-178B traceability between components
- insufficient advance FAA coordination/approvals
- incomplete DO-178B structural coverage for decision condition and MCDC coverage
- over doing DO-178B tool qualification
- not applying DO-254 to hardware
- avionics outsourcing without a clear DO-178B Project Plan covering details for the avionic outsource team
Question 24. What Is Do-178b?
DO-178B is a document published by the Radio Technical Commission for Aeronautics (RTCA). It is a guideline used to determine if software components of airborne equipment and systems are FAA airworthiness-compliant. Application programs are certified as a system. Any changes to any part of the application program code require re-certification of the entire program.
Question 25. What Does Do-178b Guideline Specify?
DO-178B specifies that each line of code is required and tested, and that no unused code exists in the application program build.
Question 26. How Do The Keil Tools Assist In Do-178b Certification?
The Code Coverage feature of the Keil debugger shows statement and decision coverage at both the source and object code level. Code Coverage results may be logged and output using the µVision debug commands.
Question 27. Does The Keil Library Produce Unused Or “dead” Code?
The Keil compiler and linker automatically warn you of unused functions or inaccessible code. Only those library functions that are called from the application program are included in the application program build. Your certification test procedure must insure that all possible arguments supplied to any library function used are tested.
Question 28. Do I Need Library Source Code For Do-178b Certification?
That depends on what level of compliance you want to achieve. The Keil tools provide the capability to attain DO-178B, Level C compliance. For levels higher than that you may or may not need library source code depending on how your test procedures are designed.
Question 29. When Should I Start Do-178b Compliance Testing On My Code?
Don’t start testing until your product is completely debugged, tested and ready to release. Testing must be done to the entire product as a whole. If you happen to uncover a bug during certification testing, and have to change your code at all, the entire certification tests must be re-run to be compliant.
Question 30. What Is Software Planning Process?
- Process activities, plans,standards are defined.
- Software Life Cycles,Development Environment, Methods, Toolsare defined.
- Transition criteria betweenprocesses are established.
- All Objectives on DO178B Guidelines, Table A1
- Plan for Software Aspects of Certification.
- Software Development Plan.
- Software Verification Plan.
- Software Quality Assurance Plan.
- Software Configuration Management Plan.
- Software Requirements Standards.
- Software Design Standards.
- Software Coding Standards.
Project Management Interview Questions
Project Management Tutorial
Embedded Systems Interview Questions
Linux Embedded systems Tutorial
Linux Embedded systems Interview Questions
MATLAB Interview Questions
VB Script Interview Questions
Project Management Interview Questions
VB Script Tutorial
QUnit Testing Interview Questions
QUnit Testing Tutorial
XLink Interview Questions
Embedded Systems Interview Questions
Embedded C Interview Questions
Embedded Processors Interview Questions
Linux Embedded systems Interview Questions
Embedded firmware software Interview Questions
MATLAB Interview Questions