A Practical Methodology for DO-178C Data and Control Coupling Objective Compliance

Transcription

1 236 Int'l Conf. Software Eng. Research and Practice SERP'18 A Practical Methodology for DO-178C Data and Control Coupling Objective Compliance T. Maia 1 and M. Souza 2 1 Performance Software, Embraer, Belo Horizonte, Minas Gerais, Brazil 2 Software Development and Process, Embraer, Belo Horizonte, Minas Gerais, Brazil Abstract - The DO-178B/C is a guidance accepted by the certification authorities for aeronautical software. It includes objectives to be met by applicants, one of them being the Data and Control Coupling objective, whose purpose is to provide a measurement and assurance of the correctness of software components interactions and dependencies. In this context, the goal of this article is to propose a methodology to show compliance with the Data and Control Coupling objective for Performance software. This article presents a literature review, along with a comparison between coupling concepts in software engineering and DO-178B/C. A demonstration of the results obtained with its usage in Embraer E2 program is also presented. Keywords: DO-178, coupling, performance software, critical software, integration testing 1 Introduction The data and control coupling coverage objective has been controversial since its first release in DO-178B. Some organizations simplify the compliance to only a design and code review activity. In spite of the fact that the release of the DO-178C has clarified the objective, it still creates challenges for aeronautical applicants to comply with data and control coupling aspects [1]. The purpose of the data coupling and control coupling verification is to evaluate the adequacy of the integrated testing and to provide an analysis of the integration activities [3]. In software engineering, the integration activity is quite challenging. Reference [7] raises some issues that integration faces: data may be lost across an interface, components may adversely affect one another, sub functions may not properly contribute to the desired functionality, global data can present problems, etc. This justifies the importance of integration tests to ensure that the components work together as intended and designed. This article s approach is to provide a practical methodology to verify the compliance with the DO-178C data and control coupling objective, considering the performance software. Initially, the performance software and DO-178C are described and their relevant aspects for the article are presented. Afterwards, an overview of data coupling and control coupling is provided, from the concepts in software engineering to the understanding of DO-178C guidance [1]. Finally, the methodology is described and the results of its application on an industry development are evaluated. 2 DO-178B/C and Performance Software Performance software applications developed by aircraft manufacturers are used to calculate approved performance information required to be in the Airplane Flight Manual (AFM). In Advisory Circular (AC) [4], the Federal Aviation Administration (FAA) provides guidelines for obtaining approval of a software version of an AFM that would replace or supplement parts of the conventional paper AFM. According to this AC: The integrity of the software components of the computerized AFM is achieved through the software development processes used. The applicant should propose the software development process in the plan for software aspects of certification. ( ) RTCA DO-178B provides an acceptable means of compliance for the software components of the AFM. RTCA DO-178B, as well as its latest version DO-178C, provides guidance for developing airborne software, while satisfying airworthiness requirements. Despite not being airborne, the performance software is safety-critical and subject to approval by certification authorities. Therefore, aircraft manufacturers tend to follow DO-178B/C guidelines when developing performance software applications. DO-178B and DO-178C are objective-oriented. They identify what the developer should do, but are not prescriptive on how it should be accomplished. The objectives to be fulfilled depend on the software criticality: the more critical the software is, the more objectives it must meet. DO-178B and C require applicants to document upfront in software plans how the compliance with the objectives will be accomplished. For most types of software, three development standards are also needed: requirements standard, design standard, and coding standard. The outputs of the development process are reviewed for conformance to these standards and for consistency with each other. The

2 Int'l Conf. Software Eng. Research and Practice SERP' verification process dictated by DO-178B/C includes reviews, tests and analyses to be performed throughout the software life cycle. 3 Data and Control Coupling Coupling is the degree of interdependence between software components, a component being understood as any software element, from a single code unit to an executable module or a data file. In software engineering, it is possible to identify six types of coupling [5]. In her book, [6] classifies the types of coupling from the tightest to the loosest coupling: discussed, because it includes objectives that are only found in the aviation industry and are not well documented in common software engineering literature, for instance modified condition/decision coverage. The Table A-7 contains objectives that are commonly fulfilled through review of test procedures, review of test results, requirements coverage analysis and structural coverage analysis. Content coupling: One component directly affects the working of another component, since one component refers to the inside of the other component Common coupling: Two components share resources, such as global data area External coupling: Components communicate through an external unit, for instance a file or database Control coupling: A component drives the execution of another component by passing the necessary control data Stamp coupling or data structure coupling: Two components refer to the same data structure Data coupling: Two components communicate by passing elementary parameters However, DO-178C [1] has a different understanding of the terminology for control coupling and data coupling. The definition is: Control coupling: The manner or degree by which one software component influences the execution of another software component. Data coupling: The dependence of a software component on data not exclusively under the control of that software component. Reference [6] associates the concept of control coupling from the point of view of DO-178C [1] with the software engineering s concept of control and content coupling, while the idea of data coupling can be associated to data, stamp, common and external couplings. In order to simplify the concepts, it is possible to summarize data coupling as the transaction of data values from a point in the source code where the value is set to another point where the value is referenced or used. On the other hand, control coupling can be outlined by the call sequence of the software. DO-178C Table A-7 [1], partially reproduced in Fig. 1, is called Verification of Verification Process Results and it contains the objective related to control and data coupling. This table can be understood as the checking of testing phase, including evaluating if the effort employed is suitable. According to [6], this table is the most controversial and Fig. 1. Excerpt from DO-178C Table A-7 In the context of DO-178C [1], it is important to differentiate structural coverage analysis from structural testing, which is a term more used in the software engineering discipline. As discussed by [6], while structural coverage intends to identify any code structure that was not exercised during the requirements-based testing, the structural testing purpose is to write tests based on the code to exercise the software. Since the tests in DO-178C [1] are necessarily requirements based, structural testing is not adequate for compliance with it. The coupling objective is part of the called structural coverage objectives. Besides the control and data coupling, that is represented in the objective 8, the other objectives that address structural coverage matter are the objectives 5, 6, 7 and 9. These objectives have the purpose of ensure that the

3 238 Int'l Conf. Software Eng. Research and Practice SERP'18 code was adequately exercised during the requirements-based testing. Usually, the structural coverage has the following purposes: Identify unintended functionality; Identify untested functionality; Identify gaps in the code not covered by any test; Improve the confidence of testing effort. The purpose of the aforementioned Table A-7 s objective 8 is to provide a measurement and assurance of the correctness of software components interactions and dependencies. According to [3], the intent is to show that the software components affect one another in a certain manner that was specified and defined by software designer and do not affect one another in an unplanned or erroneous behavior. In order to verify the compliance with the Table A-7 s objective 8, the analysis of data and control coupling involves a combination of reviews and tests. According to [2], it is possible to demonstrate compliance with reviews and analysis of software architecture, reviews and analysis of source code, and testing. DO-248C [2] states the intent of the objective is to ensure that applicants perform a sufficient amount of hardware/software integration testing and/or software integration testing. This clarifies the need for a measurement of the software testing completeness regarding the existing couplings. 4 Methodology The proposed methodology to comply with Table A-7 s objective 8 is a set of activities that considers the characteristics of a Performance Software: a desktop software application, where functions call each other according to the calculations specified in requirements. The activities are: Identification of sources of coupling; High-level requirements review; Design review; Code review; Verification cases; Structural coverage analysis. The identification of sources of coupling is an activity that shall be executed throughout the entire software development, but mainly in the initial concept and design detailing phases. Besides identifying and documenting the sources of coupling, which will substantiate the demonstration of the objective, this activity can be a measurement of the necessary effort during the verification phase, especially the tests. It also provides feedback of the software design, since as raised by [5], a good design minimizes coupling by eliminating unnecessary relationships, reducing the number of necessary relationships, and easing the tightness of necessary relationships [6]. While identifying the coupling, it is a recommended practice to always question the designers if the coupling is indeed necessary. In addition to reduce further efforts to test and to demonstrate that the software behaves as designed, every coupling eliminated improves the quality of the software as well. Considering that the Performance Software is an aeronautical performance calculator, it is very common that requirements refer to each other, with a high level of horizontal relationship. These references are later implemented in the code in the form of function calls. In order to ensure that these calls are well specified, it is recommended to create rules in the requirements standard not only to address the uniformity but also to ensure that the references are consistent. Consequently, in this case the high-level requirements review can contribute to data and control coupling verification. The same strategy is used in the design phase, for lowlevel requirements (LLR). With standard rules, data and control coupling aspects are analyzed during the review of LLR. Regarding the architecture, the data and control coupling matter is also evaluated during the review, when demonstrating compliance with other objectives such as architecture consistency. Again, it is recommended to include design standard rules to address the relationship between the components in the architecture. Since the design specifies the relationship between all software components, the review of code to verify if there is compliance with architecture automatically addresses data and control coupling issues. Regarding the data coupling, it is recommended to create code standard rules that define the usage of implicit type conversions, pointer type conversions and function calling, for instance. Since there are rules in the code standard, the demonstration of conformance to standards contributes to the data and control coupling analysis. During the requirements-based tests specification, it is important to include integration verification cases that ensure the software components interact correctly with each other and satisfy the software requirements. Consequently, these tests will also exercise the software architecture, since during the design review the consistency between architecture and requirements was well verified, as required by DO-178C [1]. During the verification cases specification, it is recommended to detail each verification case in such manner it is easy to select those tests whose purpose is to exercise the software couplings. Although there is a further activity to verify the test completeness, it is important to ensure that there is at least

4 Int'l Conf. Software Eng. Research and Practice SERP' one verification case covering each identified source of coupling. The strategy of verification cases creation and execution is another aspect that can contribute to the data control coupling analysis. If the strategy is a bottom-up creation and execution, when testing a function that calls another one, the called function will be also tested. In addition, test stubs shall be used only in special cases. As stated by [6] if the requirements-based testing is performed on an integrated system without using stubs, this helps improve confidence on data and control coupling aspects. The structural coverage evaluation, in special the statement coverage, is a powerful tool, mainly in software developments that have a high level of horizontal dependency in requirements (and so in the source code, between functions), which is the case of Performance Software. In such software, the statement coverage allows checking the completeness of the coupling coverage, since if there is a portion of the source code not covered, it means there are some lack on the control coupling. Thus, the data and control coupling due to function calls is covered through the achievement of structural coverage. This results from the incremental integration strategy used, where each function is tested with all its called functions actually integrated. In order to summarize all data produced to show compliance with Table A-7 objective 8, it is suggested to create a final report. In this report, an assessment of the activities proposed in this article shall be performed. The following aspects need to be evaluated: If the high-level requirements were consistently specified (high-level requirements review); If the components were correctly designed (LLR review + architecture review); If the designed components were correctly implemented (code review); If all sources of coupling, including each pair of producer and consumer, caller and called, source and destiny, etc., were properly exercised (verification cases); If there is any problem report in a verification case that exercise any source of coupling (verification cases); If all components are correctly called (structural coverage analysis); If there is no dead code (structural coverage analysis); Regarding the documentation of the sources of coupling, it is a good practice to detail them in a format of consumer and producer pairs. For each data coupling, it is mandatory that the component that produces the data and the component that consumes this data are exercised in at least one verification case. For each control coupling, it is mandatory that the caller component and the called component were exercised in at least one verification case. For better visualization and understanding of this information, a spreadsheet is recommended, listing each pair and the corresponding verification case. Finally, the measurement of the data and control coupling coverage is provided. 5 Conclusion The main advantage of this compliance process is to take credit from other objectives demonstration such a manner as the demonstration of the objective of data and control coupling coverage itself is a set of activities already performed and audited by the quality assurance team and the certification authority. The proposed method also reduces the risk of project once it anticipates a verification activity since the development phase, which is a good practice from project management view. The method has been used in the development of the Computerized Aircraft Flight Manual of Embraer aircraft E2, which had its certification approved in the beginning of Besides diluting an activity that is foreseen to be executed only in the final of the project throughout the development and other verification activities, the following points were raised as main benefits of usage of the methodology: The specification of the purpose of each verification case reduced the effort to verify if all sources of coupling were tested. Also, it helps to ensure that the coupling was correctly exercised. The bottom-up strategy for Verification, using the called functions without stubs, generated an incremental integration and reduced the effort on checking the coupling between functions. In a project management perspective, the method has contributed to a reducing of 50% of time estimated to execute the analysis. Therefore, it has demonstrated to be a good strategy, since it reduces the time to perform the analysis without losing assurance. 6 References [1] RTCA, DO-178C - Software Considerations in Airborne Systems and Equipment Certification, Washington: RTCA, Inc., [2] RTCA, DO-248C - Supporting information for DO- 178C and DO-278A, Washington: RTCA, Inc., [3] Certification Authorities Software Team, Clarification of structural coverage analyses of data coupling and control coupling, Rev. 2, 2004.

5 240 Int'l Conf. Software Eng. Research and Practice SERP'18 [4] Federal Aviation Administration, Advisory Circular (AC) , Airplane Flight Manual., Change 1, United States Department of Transportation: [5] M. Page-Jones, The Practical Guide to Structured Systems Design, 2nd edition, New York: Yourdon Press, 1980, pp [6] L. Rierson, Developing Safety-Critical Software, 1st edition, Boca Raton: CRC Press, 2013, pp , 216 and [7] R. S. Pressman, Software Engineering: A Practitioner s Approach, 8th edition, New York: McGraw-Hill, 2015, pp