Flying High with the LDRA tool suite
- Related Documents
-
LDRA Newsletter Issue 12NL
The Client
IHI is the premier manufacturer of jet
engines in Japan with approximately
70% share of the market.
The company is the primary contractor
for aircraft engines used by the
Ministry of Defence, and participates in
international co-operative projects that
develop large-to-small scale engines
for civilian aircraft.
The Projects
IHI has utilised the LDRA tool suite on
a number of projects, of which the Jet
Engines project forms the focus of this
article.
A key requirement for the software
development team working on this
project was to achieve DO-178B
certification. After studying the
available tools in the market place
IHI concluded that the LDRA tool
suite provided the best fit for their
requirements due to the depth and
diversity of tool facilities. IHI were also
keen to leverage LDRA’s many years of
experience of DO-178B certification.
IHI selected the LDRA tool suite for the
verification of both C and Ada source
code to DO-178B certification Level A,
the most rigorous testing standard for
avionics software.
Mr. Osamu Kanmoto,
Manager,
Control Systems
Engineering Group,
IHI Corporation,
commented:
“From the software design the
engineers carried out a thorough unit
and module test process, utilising T-VEC
Tester for Simulink to generate the test
vectors from the design model and LDRA
Testbed to measure code coverage.”
“We had to meet the requirements of
DO-178B Level A meaning testing to
Modified Condition Decision Coverage -
not an easy task.”
LDRA’s tools are classified as software
verification tools under the DO-178B
standard and as such are required to be
qualified on a project-by-project basis.
This means that when assessing the
merits of such tools it is essential to
consider the level of vendor assistance
for tool qualification. LDRA offer
assistance with this process and agree
to enable clients and the FAA to audit
the LDRA tool suite for project use.
The Benefits
IHI have configured and adapted both
the LDRA tool suite and their overall
development processes to accommodate
the requirements and rigours of DO-178B
certification for their embedded system. To
assist in this process, they have introduced
high levels of automation through the use
of tools and other techniques, all of which are designed to provide an efficient and
repeatable process.
ESPR Experimental Engine promoted by NEDO*
LDRA tool suite was
14 times quicker
than
previous processes
IHI reported that the LDRA tool suite was 14 times quicker than manual
coverage analysis processes and, given
their extremely tight development
schedule, this alone was of major
significance to the success of the project
as a whole.
IHI now have the ability to prove, with
confidence, the test coverage outcomes
associated with their embedded
software development processes.
The benefits to the company are that
they have an automated test coverage
process that supports the unit, module
system and integration levels, while
being both meaningful and productive.
This provides a significant improvement
in their ability to satisfy, audit and review.
The Future
IHI has future plans to leverage the powerful static analysis capabilities of the LDRA tool suite in order to support an objective and quantifiable view of the quality of their source code.
*NEDO, The Japanese Governments R&D management organisation support the development of environment-friendly Aircraft Engines. (www.nedo.go.jp/english/index.html)
Contact LDRA and discover how you too can harness the power of the LDRA tool suite and develop better, more reliable software.
CERT C
Secure Coding Programming Checker with TBsecure®
Background to CERT C
CERT was created by DARPA
(Defense Advanced Resource
Projects Agency) in November
1988 to deal with Internet security
problems after the Morris Worm**
struck. Its coordination centre
(CERT/CC) is located at Carnegie
Mellon University’s Software
Engineering Institute (SEI).
Although intended purely as an academic exercise to gauge the size of the Internet, the effect of the Morris Worm had repercussions throughout the worldwide Internet community, infecting thousands of machines. Many organizations, with systems attached to the Internet, suffered damaging denial of service attacks.
Consequently software vulnerabilities came under the microscope of the U.S. government in particular. The SEI CERT/CC was primarily established to deal with Internet security problems in response to the poor perception of security and reliability of the Internet. The CERT C standard is a result of extensive research undertaken by the CERT/CC. The goal of this standard is to eliminate insecure coding practices and undefined behaviours that can be exploited.
** The Morris Worm announcement and newspaper coverage
For a number of years prior to tackling programming guidelines, among other security-related activities, the CERT/CC studied and compiled cases of software vulnerabilities. The Secure Coding Initiative, launched in 2005, has used the database of catalogued vulnerabilities, built up over a period of 12-15 years at the CERT/CC, to develop secure coding practices in C and C++.
The application of the secure coding standard leads to higher quality systems that are robust and more resistant to attack.
Rules and recommendations included in the CERT C Secure Coding Standard are designed to be operating system and platform independent. Once implemented, these rules and recommendations can be used as a metric to evaluate source code using an automated process.
Why adopt CERT C?
New security vulnerabilities are discovered daily and these cause security flaws and leaks with systems inadequately protected. Society has become highly dependent on software applications in mission-, businessand safety-critical systems. Studies indicate that a majority of these vulnerabilities can be traced back to a set of common programming errors.
The primary aim of CERT C is to enumerate common errors in C language programming that lead to software defects, security flaws and software vulnerabilities before they enter production code. The standard then provides recommendations about how to produce secure code. Although the CERT guidelines shares traits with other coding standards, such as identifying non-portable coding practices, the primary objective is to eliminate vulnerabilities.
Structure of CERT C
Each item in the CERT C Secure Coding Standard is termed a guideline and is then classified as either a rule or a recommendation. Guidelines are defined to be rules if a violation of the coding practice is likely to result in a security flaw, and conformance can be determined through automated analysis, formal methods or manual inspection techniques.
CERT C Priority Levels
Guidelines are defined as recommendations when the rule conditions cannot be met but the application of the coding practice is likely to improve system security.
Recommendations are neither compulsory nor necessary to claim compliance with the standard but should be adopted for projects with high security requirements.
For each rule or recommendation there is a weighted priority factor which is graded 1-3 and an overall priority range of 1-27.
The emphasis upon security issues sets CERT C apart from other coding standards. Potential security risks associated with poor coding practices are highlighted, and in some cases driven home with real world code samples of past vulnerabilities.
CERT C Certification with the LDRA tool suite®, TBvision® & TBsecure®
LDRA’s TBsecure is a plug-in to TBvision, a module within the LDRA tool suite that enables developers to easily determine how the source code measures up against security vulnerabilities.
As its primary role, TBsecure applies the CERT C secure coding rules and relays findings to TBvision, which then indicates the quality, fault detection and avoidance measures associated with the code under test through code review reports and the use of graphical displays such as call graphs and flow graphs.
Conformance to the CERT C standard can be automatically checked using TBsecure and the advanced code analysis capabilities of the LDRA tool suite also provide compliance checking for the MISRA-C:1998, MISRA-C:2004 & MISRA C++:2008 guidelines. In addition, LDRA worked with Lockheed Martin developing the JSF++ AV standard and is also able to enforce Meyers Effective C++ and Effective STL coding guidelines amongst others.
Through TBsecure, the LDRA tool suite has been extended to support a wide range of programming rules with an emphasis upon increased application security using the following classification of security issues:
- Dynamic Memory Allocation (A) concerns: Dynamic memory management is a common source of programming flaws that can lead to security issues such as heap-buffer overflows, dangling pointers and doublefree issues. In particular, memory management encompasses allocating memory, reading and writing to memory and deallocating memory.
- Vulnerabilities (V): These rules are intended to eliminate insecure coding practices aside from those associated with dynamic memory. Examples of insecure coding practices include array indices out of range and dereferencing a null pointer.
LDRA’s products & services are widely used by companies whose names are synonymous with the development of security-sensitive embedded systems including: Honeywell, Raytheon, Elbit Systems, Rockwell Collins, eSysTech, Presagis and NASA.
The Future
The Secure Coding Initiative will continue to develop a C++ Secure Coding Standard and maintain and enhance the existing C Secure Coding Standard.
MISRA® is a registered trademark of MIRA Ltd, on behalf of the MISRA Consortium. No endorsement by MISRA is claimed or implied for any product.
Tool Integration News
The aim of the LDRA integration with the Analog Devices VisualDSP++ software development environment tool is to allow seamless testing of user code, either at system level or when performing unit testing. Whilst the LDRA tool suite handles the instrumentation of user code, test harness creation and the processing of the target responses, the VisualDSP++ environment takes care of the compilation and capture of the results from the target. The actual method of results capture is defined early in the process and is implemented in the instrumentation technique and harness code to accommodate the requirements and limitations of the target - whether real hardware or the VDSP++ simulator. The typical VDSP++ project includes assembler code, linker description and kernel files in addition to user code. When parsing the project files the LDRA tool suite can ignore these. In particular the VDK process auto-creates a source file that, not being user code, does not need to be analysed but must be present for the build process. The LDRA application accepts the results captured from the execution. These are the results for unit-tests and also the probe results for coverage analysis. When required the LDRA tool suite can provide the analysis to prove the required coverage for DO-178B Level A. The flexibility of this integration is that it can be used for all devices supported by VisualDSP++. Initially written and tested to support version 4.5 of VisualDSP++, it will be tested with v5.0 and also v3.5 (supporting the ADSP-21xx). |
Through our highly skilled
engineers, LDRA is able to offer a
wide range of services.
These include: Contact: Ian Smith
LDRA Training To obtain more information or book on-site or public training courses contact LDRA on:
Contributions from our readers are welcome. If you have any comments or stories that you feel are relevant to the world of software testing please contact us. |
|
LDRA will be introducing the LDRA newsroom which will provide up to date information on:
This will provide a portal of up to date LDRA information. For more details visit: www.ldra.com/newsroom.asp
|
||
LDRA will be participating in a number of trade shows, exhibitions and conferences throughout the year. This provides us with the opportunity to catch up with existing customers, and meet new ones and introduce them to our services, and how, by working together to improve software safety and efficiency substantial financial benefits can be achieved. For more information contact: www.ldra.com/events.asp |
