15.

What are the differences between DO178-B and DO178-C

standards?
Errors and Inconsistencies: DO-178C addressed DO-178B’s known errors and
inconsistencies. For example, DO-178C has addressed the errata of DO-178B and has
removed inconsistencies between the different tables of DO-178B Annex A. In removing an
inconsistency regarding software standards for Level D software, DO-178B objective A-9 #1
addressing plans and standards was split into two DO-178C objectives, specifically:

 Assurance is obtained that software development and integral processes comply with
approved software plans. (Table A-9 #2)
 Assurance is obtained that software development and integral processes comply with
approved software standards. (Table A-9 #3)

Consistent Terminology: DO-178C addressed DO-178B’s issues with the use of specific
terms such as “guidance”, “guidelines”, “purpose”, “goal”, “objective” and “activity” by
expanding the Glossary and changing the text accordingly so that the use of those specific
terms was consistent throughout the document.
Wording Improvements: DO-178C made wording improvements throughout the
document. All such changes were made simply to make the document more precise; they
were not meant to change the original intent of DO-178B.
Objectives and Activities: DO-178C reinforced the point that, in order to fully understand
the recommendations, the full body of this document should be considered. For example,
Annex A now includes references to each activity as well as to each objective; and Section
1.4, titled “How to Use This Document” reinforces the point that activities are a major part of
the overall guidance.
Technology Supplements: DO-178C recognized that new software development
methodologies may result in new issues. Rather than expanding text to account for all the
current software development methodologies (and being revised yet again to account for
future software development methodologies), DO-178C acknowledged that one or more
technology supplements may be used in conjunction with DO-178C to modify the guidance
for specific technologies or methodologies. Section 12’s addressing of tool qualification and
alternative methods was heavily impacted since planned technology supplements more
completely address such technologies. They include Model-Based Development, OOT,
Formal Methods and Tools.
Coordinated System/Software Aspects: DO-178B updated Section 2, which provides
system aspects relating to software development, to reflect current system practices.
DO-178B “Hidden” Objectives: DO-178C added the so-called “hidden objectives” to Annex
A:
A means for detecting object code that is not directly traceable to the source code and a
means to ensure its verification coverage are defined. (Table A-7 #9)
Assurance is obtained that software plans and standards are developed and reviewed for
consistency. (Table A-9 #1)
DO-178B General Topics: DO-178C addressed a few general topics that resulted in changes
to several sections of the document. The topics included a variety of subjects such as
applicant’s oversight of suppliers, Parameter Data Items and traceability. In addressing
these topics, additional objectives were added to Annex A:
Correctness, Completeness and Verification of Parameter Data Item Elements. (Table A-5 #8
and #9)
Parameter Data Item file to be loaded in target computer. (Table A-2 #7)
Added Trace Data as required Lifecycle Data to be provided and verified (Section 11.21,
Table A-2 and Table A-6)
DO-178B Gaps and Clarifications: DO-178C addressed several specific issues that resulted in
change to only one or two paragraphs. Each such change may have an impact upon the
applicant as these changes either addressed clear gaps in DO-178B or clarified guidance
that was subject to differing interpretations.
Examples of gaps addressed include:
The “Modified Condition/Decision Coverage” definition changed. Masking MC/DC and Short
Circuit, as well as DO-178B’s Unique-Cause MC/DC, are now allowed. (Glossary)
For Level A, added that “if a compiler, linker or other means generates additional code that
is not directly traceable to Source Code statements, then additional verification should be
performed to establish the correctness of such generated code sequences.” (6.4.4.2.b)
Derived requirements should now be provided to the system processes, including the
system safety assessment process (rather than just provided to the system safety
assessment process) (5.1.1.b; 5.2.1.b)
Examples of clarifications include:
Clarified that the structural coverage analysis of data and control coupling between code
components should be achieved by assessing the requirements-based tests. (6.4.4.2.c)
Clarified that all tests added to achieve structural coverage are based on requirements.
(6.4.4.2.d)
Clarified the types of code that may be classified as Deactivated Code. (6.4.4.3.d)

16. What factors do you consider for estimating a DO178B/C

project?
Software Design Assurance Level, SW Tools required, SW to ATE to be developed and
maintained, Integration Support, Attrition and Reusability of existing hardware/software
tools

17. What sort of estimation techniques are used by you?

We use a heuristic method in many of the testing projects. The heuristic data is gathered
over many years of execution of similar projects. Organization metrics are created from
heuristic data and are updated annually. This data is used in estimating projects.
In addition, we use the following techniques in estimating new projects:

 Wide Band Delphi

 Work Breakdown Structure (WBS) Method
 Event-Chain Methodology/ Risk based estimation

18. Do you use only 'V-model' for all your software

development life cycle activities?
In addition to the V model, Accord uses many other development life cycles. Accord has
expertise in employing different lifecycle models to suit the needs of the Customer and the
requirements of the program:

 Waterfall Model
 Iterative Enhancement model
 Modified Waterfall model
 Agile Methodologies – Scrum and Kanban

Accords has always highlighted the value of accurate documentation for certification
purposes and irrespective of the lifecycle model selected, Accord ensures that
documentation of high standards is generated.

19. What are the projects for which you have contributed in
developing system requirements?
Accord has participated in developing System Level Requirements for the following projects:

 FAA Certified ADS-B System

 FAA Certified GPS Receiver
 FAA Certified Router/Filter
 CEMILAC Certified Control Saturation Warning System
 CEMILAC Certified Control Display Unit
 CEMILAC Certified Ruggedized Time Distribution Unit’
 EASA Certified AIBU – Cabin Lighting
 CEMILAC Certified IRIG-B Time Code Generator

20. What are the projects for which you have contributed in
developing software requirements?
Accord has generated Software Requirements in all the full life cycle products designed and
developed at Accord. These projects include:
  FAA Certified ADS-B System
 FAA Certified GPS Receiver
 FAA Certified Router/Filter
 CEMILAC Certified Control Saturation Warning System
 CEMILAC Certified Control Display Unit
 CEMILAC Certified Ruggedized Time Distribution Unit’
 EASA Certified AIBU – Cabin Lighting
 CEMILAC Certified IRIG-B Time Code Generator
 FAA Certified Data Acquisition Unit (DAU) and Configuration Module Unit (CMU)
 FAA Certified Display Unit

21. What software tools you use for managing requirements?

Accord uses DOORS as well as the inhouse developed tool ReMa (Requirements Manager)
for managing Requirements. DOORS is widely used tool for maintaining requirements but is
constrained by licensing costs. Accord developed its own tool, ReMa, as a cost-effective
solution to manage requirements. ReMa has most features supported by DOORS and
supports importing data from DOORS into its own database.

22. What is ReMa? Is it compatible with DOORS or Requisite

pro?
ReMa ( Requirement Manager) is a software developed by Accord for managing
requirements. It is a systematic and powerful tool which helps in organizing, tracing and
managing requirements throughout the project life cycle. ReMa helps in achieving
- Shorter release cycles - Low cost - High quality - Conformance to customer requirements -
Collaboration and communication among team members ReMa is compatible with DOORs.
ReMa has most features supported by DOORS and supports importing data from DOORS
into its own database.

23. Has ReMa undergone tool qualification?

Yes, ReMa has undergone tool qualification for DO-178B projects.

24. Is ReMa available for purchase?

ReMa is not available for purchase yet, but available as In-house tool. ReMa can be used
directly in customer projects or it can be used to reduce the purchase of number of licenses
of industry wide accepted DOORS requirements management tool. REMA supports
importing/export of its database from/to DOORs. Hence a bigger team can be managed
with ReMa and single license of DOORs.

25. Do you have a web-based version of ReMa?

No, we do not have web-based version of ReMa. Currently ReMa is available as Client Server
version

26. What sort of support is available for REMA?

No, support is available as ReMa is not for purchase.

27. What are the projects for which you have contributed in
developing System Architecture?
 a) Navigation Communication Radio Prototype
 b) L Band Transceiver Demo Project
 c) GPS-UAT Multilink Surveillance Systems for ADS-B applications
 d) Selective Calling Radio
 e) Multi Constellation GNSS Intellectual Property and System on Chip Design
 f) Integration of GPS Base band IP on customer SOC designs
 g) CDMA Receivers
 h) Satellite Ranging Receiver
 i) Aerospace GNSS Receivers
 j) FPGA DO-254 process Engineering Services
 k) IRNSS reference Receiver
 l) GNSS Simulator
 m) GNSS System on Chip

28. What are the projects for which you have contributed in
developing software Architecture?
Accord has developed and contributed to Software Architecture in many projects. A few are
listed below:

 a) Control & Display unit for rotorcraft

 b) Early Warning Systems for Roto craft
 c) Airborne Transponder Software for General Aviation
 d) Data Acquisition Units for Rotor craft
 e) Data loaders using 615A
 f) Base Software Architecture based on AUTOSAR
 g) Automotive Telematics Control Units
 h) Fleet Management Server Software Architecture
 i) Airport Baggage Handing Report Generation Software
 j) Network monitoring tool for Airport Networks
 k) Distributed database element Design for Airport Baggage databases
 l) Development of Generic Architectural Components
 m) Landing Gear, Steering Control Systems Software
29. What tools do you use to capture Architecture
specifications?
 Yordon
 Visio
 Rational Rhapsody
 SmartDraw

30. Can you list the Programming languages used by you in

past projects?
Following are the programming languages used in the past projects:

 C++ in GVision Project using MFC classes in Microsoft VC++.GVision is a GUI tool
developed on windows platform used for debugging and analyzing the data obtained
from a GPS receiver.
 C++ on WinCE operating system on a Notebook computer using Microsoft VC++ IDE.
It is basically porting of GVision which is a GUI application developed in C++ (using
MFC classes) language using Visual C++ IDE from windows platform to WinCE
platform.
 Pascal and C language were used in Allbase/SQL database maintenance project on
MPE-iX and HP-UX operating systems.
 C# language using Microsoft .NET IDE for development of Case Tool application -
which is basically a design tool used for software development life cycle activities.
 C++ language (using MFC classes) using Microsoft Visual C++ IDE in Shenzhen project
which is basically a check-in baggage system in Shenzhen Chinese Airport. It was used
basically in Work stations and IO developments. Apart from this PHP, Java, HTML
programming was also used a part of Web interface GUI for this project.
 C++ language under QT Framework was used for CISS work stations updating in
Schenzhen project.
 C language was used in Software development of Data Acquisition Unit and Display
Unit
 Java language used in DET(Data Extraction Tool) for Shenzhen project.
 ADA-95 language used in OAC Software subsystem development.

31. What activities are performed by you in low level testing?

Following are some of the activities performed in low level testing:

 Unit Testing
 Module Testing (Component Testing)
 Static Analysis
 Structural Code Coverage Analysis
 Code Review
  Code Walk through

32. Are there any tools used by you in low level testing?
Following are the tools used for Unit testing:

 RTRT
 Cantata
 SmartTester
 LDRA