Coding Standards in FACE Conformance. John Thomas, Chris Edwards, and Shan Bhattacharya

Transcription

1 Coding Standards in FACE Conformance John Thomas, Chris Edwards, and Shan Bhattacharya

2 LDRA Overview Provider of Software Quality, Compliance Management & Testing Solutions Established 1975 ISO 9001 certified company Active participants in standards e.g. DO-178C, MISRA C/C++, CERT, FACE Certified for use in safety related software development according to IEC 61508, EN 50128, ISO 26262, IEC & IEC 60880

3 Automating Software Quality Across the Lifecycle Requirements Traceability Requirements traceability Impact Analysis Traceability Matrix Import/Export Report Generation Verification Workflow Test Management Verification Workflow Management Automation Objective Fulfillment Audit trail LDRA Verification Coding Standards Unit Testing Code Coverage Quality Metrics Target Integration Data/Control Coupling REDUCING COST AND RISK ACROSS THE LIFECYCLE

4 FACE Conformance Utilizing the LDRA tool suite Efficiencies in Conformance Activities Scoping FACE requirements and generation of a populated conformance verification matrix Traceability to conformance artifacts across the lifecycle Automate execution of the CTS Application of a FACE coding standard to aid in conformance to reduce rework DO-178C FACE Security Safety, Security, and Interoperability applied throughout the software development and verification Integrated with an ecosystem of tools and technologies Evidence and artifacts generated to demonstrate adherence, compliance, and conformance

5 CVM and the LDRA tool suite FACE CVM with identifiers. Ready for parsing into TBmanager CVM perspective within the TBmanager requirements grid Tailored import of the CVM into TBmanager Automated generation of a conformance artifacts infrastructure Conformance Test Suite execution and artifact capture Generating a populated CVM to show conformance

6 TBmanager executes the CTS through the command line interface CTS report shows that the code has passed conformance but not which requirements are fully verified, partially verified, and not verified TBmanager automates regression, captures the reports and shows/reports which requirements have been verified Automating the Execution of the CTS FACE Conformance Test Suite configuration CVM perspective within the TBmanager requirements grid FACE Conformance Test Suite (CTS)

7 FACE Requirements and Static Analysis Violations of some requirements can be identified by static analysis Potential violations can be identified as needing further inspection Categories include Use of functions not allowed by the FACE Technical Standard Use of functions allowed but where usage has been limited by the FACE Technical Standard Use of potentially disallowed data pragmas Use of disallowed classes Use of functions from outside the FACE Technical Standard that are not in the UoP 7

8 Use of Functions Not Allowed FACE 2.1 Example Requirement: CVM Row 1844, Appendix A, Table of POSIX APIs CVM has a row 1844 marked as Test Suite Use of static analysis tools during development of the UoC can identify the same excluded function earlier in the lifecycle Reduces rework and can be applied during safety, security and runtime error checking static analysis Can be applied before the build for conformance infrastructure is in place 8

9 Use of Functions where Usage is Limited FACE 2.1 Example Requirement: CVM Row 2076 So#ware components use the communica2ons mechanisms provided by the TSS if communica2ng outside the FACE UoP Communicating outside the UoP is not allowed except through TSS CVM marked as Full Tested Requirement Testing of the requirement can utilize static analysis FACE 2.1 Example Requirement: CVM Row 1847 For the Security and Safety Profiles, mutex support (e.g., pthread_mutexattr_setprotocol() API) shall be _POSIX_THREAD_PRIO_PROTECT only 9

10 Use of Data Pragmas FACE 2.1 Example Requirement: CVM Row 1616 Programming language features described in ANSI/ISO/IEC 9899:1999: Programming Languages C, with the following exceptions: a) Component use of the pragma directive (ANSI/ISO/IEC 9899:1999, Section ) The Test Suite cannot test for the use of pragmas The CVM has part of the requirements marked as Fully Tested Requirements Supplier must provide evidence that the requirement is tested in a report Static Analysis report is ample evidence 10

11 Use of Disallowed Classes FACE 2.1 Example Requirement: CVM Row 1631 Other programming language features described.. with the following exceptions: c. Input/output library (ISO/IEC 14822:2003, Section 27) there are no input/output library functions supported Complementing the CTS to ensure conformance The Test Suite relies on the supplier compiling all of the library source against the Gold Standard Libraries in order to fully test Static Analysis can detect any calls to software that is not part of the analysis Better informs the supplier earlier in development when third-party libraries are used 11

12 Use of Other Libraries not included FACE 2.1 Example Requirement: CVM Row FACE UoPs shall include all software providing a service or capability. The FACE Technical Standard applies to all of the software that is in a conformant UoC This includes the third-party libraries that the UoC makes use of Complementing the CTS to detect uses of IO Stream classes and derivatives CVM has this part of the requirement marked as Test Suite Static Analysis can detect the use of these classes early in the development cycle, thereby reducing rework 12

13 Avoiding Portability Issues Easy to write non-portable code Bitshift operations Left-shifting a 32-bit one by 32-bits produces 1 on x86 On PowerPC or ARM produces 0 13

14 Combining FACE and Other Coding Standards Pre-empt security and reliability issues early in the lifecycle Reduce defects, verification cost Consistent coding style and form across teams Portability and reusability across environments Security, Reliability, Interoperability Standards families such as MISRA, CERT, CWE Tailorable for new development, legacy code, and runtime error checking FACE conformance support through static analysis Input Validation Buffer Overflows Data Type Overflows Errors and Exceptions Security Safety LDRA MISRA Committee members Professor Mike Hennell, Dr. Clive Pygott, Liz Whiting, and Chris Tapp 14

15 Utilizing Coding Standards for Conformance Detecting non-conformant calls statically FACE requirements can explicitly specify interface details Static Analysis can reduce the labor-intensive aspects Aid in the detection of other potentially non-portable software Automate portion of evidence generation Eliminate repeated inspection tasks and detect non-conformance issues early Aid software developers to adhere to FACE requirements and other coding standards during the development phase

16 LDRA In the Air The Northrop Grumman RQ-4 Global Hawk

17 LDRA In Defense

18 Integrated FACE and DO-178C Solution Reduce the cost of adopting both DO-178C and FACE by unifying the verification environment and leveraging work across standards Enforce and manage FACE and DO-178C conformance across a distributed set of suppliers Predict and manage effort and progress to improve proposal-to-contract execution Convergence of DO-178C and FACE standards Transition to DO-178C and increased rigor in use of the guidance Increasing number of RFI s are requiring FACE conformance

19 Any Questions Q & A 19

20 Contact Us Need more information?.com 20