UNCONTROLLED IF PRINTED IN-SERVICE MANAGEMENT OF SOFTWARE FOR AIRBORNE AND RELATED SYSTEMS

Transcription

1 UNCONTROLLED IF PRINTED AAP Sect 2 Chap 17 SECTION 2 CHAPTER 17 IN-SERVICE MANAGEMENT OF SOFTWARE FOR AIRBORNE AND RELATED SYSTEMS INTRODUCTION 1. The in-service maintenance and development of safety-related software for airborne and related systems, if conducted without sufficient rigour, has the potential to impact the integrity of those functions implemented by the software, and therefore the safety of the aircraft. Furthermore, the recording, tracking and resolution of problems associated with safety-related systems is critical to ensuring these systems achieve the required level of safety. Only through appropriate in-service management will software achieve and maintain its intended level of safety. 2. This chapter identifies a number of key issues which DGTA considers fundamental to the in-service management for ADF safety-related aerospace software. While their adoption is not mandatory, justification for their omission would normally be expected. SCOPE AND APPLICABILITY 3. This chapter addresses the in-service management of safety-related software for airborne and related systems. It focuses on software support agency requirements, in-service problem and change management, design review and approval guidance for in-service development, and contingency build requirements. It is not the intent of this chapter to prescribe a process to which all Software Support Agencies must comply, although the chapter does provide an example process (refer Annex A) to provide some basis for comparison of new support agencies with previous practice. Software should generally transition to an in-service support arrangement with the extant standards that applied during the acquisition phase; for this reason, development assurance and safety standards are not addressed in this chapter. Rather, this chapter restricts discussion to organisational requirements and Commonwealth interfaces to software processes. For guidance on requirements for transition to in-service, software assurance, software safety, and software development and lifecycle standards, refer to Section 2 Chapter While this chapter specifically focuses on safety-related software, the principles are equally applicable to mission software. Section 2 Chapter 7 presents guidance on missionised hazards, which provides a mechanism for assessing the importance of mission software. Software Support Agency SOFTWARE SUPPORT AGENCY OR REPRESENTATIVE Key Issue: In-service maintenance and development of software should be conducted by a Software Support Agency (SSA) that is an Authorised Engineering Organisation (AEO), and for which the scope and authority of software development is defined in an approved Engineering Management Plan (EMP). 5. The scope of authority of each SSA is likely to vary considerably across the ADF, depending on whether the in-service support is provided by the OEM, an OEM sub-contractor, the Commonwealth, or a non-associative third party contractor. Where the SSA belongs to the OEM or is an OEM sub-contractor, then there may be provision to waive the requirement for them to explicitly be an AEO. However the OEM s scope and authority of software development should still be defined within the relevant SPOs engineering system, and the SPO should still provide oversight of the OEM s software practices to the extent necessary to conduct design acceptance of software changes produced by the OEM. 6. An SSA s scope of responsibilities may typically include the following: a. in-service management of problem reports and point of contact for problem resolution; b. development of plans and requirements for software maintenance and development; c. configuration management and control of software products; 1

2 UNCONTROLLED IF PRINTED AAP Sect 2 Chap 17 2 d. development and implementation of software changes; e. test and evaluation of software products; and f. design review and approval of software changes. 7. To become an AEO, the SSA must demonstrate that it meets AAP s Organisation, People, Process and Data (OPPD) requirements. The following paragraphs outline specific OPPD considerations for the SSA. 8. Organisation. The SSA should satisfy the normal AEO criteria for any organisation performing aircraft engineering for the Commonwealth including having a quality system (ISO 9001), SDE (responsible to the TAR for the engineering), Engineering Management System (documented in an EMP), Design Support Network (DSN), etc. For SSAs, the DSN should, where possible, include the software OEM, operating system OEM, hardware OEM, tool vendor technical support, and equipment suppliers for development and integration environments. SSAs may also find it advantageous to build relationships with specialist expert software analysis and verification organisations to assist with complex software designs and technologies. 9. Personnel. The SSA should employ a sufficient number of suitably qualified, trained and experienced software personnel to ensure that all activities are conducted by competent, authorised staff. A paper detailing competency requirements for software personnel can be found on the DGTA intranet website under DAIRENG/SCI1. The typical software roles within an SSA include: a. Software Team Lead responsible for general oversight and management of software development activities, and for developing the competencies of software development staff. b. Software Architects (Designers) responsible for assessing the impact of new requirements on the existing software architecture, and translating new high level requirements into changes to the software architecture. c. Software Programmers responsible for translating high and low level requirements (and the software architecture) into source code, including any necessary analysis in support of coding. d. Software Testers responsible for testing and analysis of software at unit and integration levels. e. Software Quality Manager responsible for Software QA activities f. Software Configuration Manager responsible for Software CM activities. g. Technical Support Staff responsible for configuring and maintaining the software development and test environments, including a software test bench and systems integration laboratory. 10. While it is possible for an individual person within an SSA to share a number of these roles, it should generally be discouraged. Careful management is required to ensure that independence requirements are not violated on reviews and test activities, and the distinct attributes of each role are preserved. Furthermore, for most systems of any reasonable size, a minimum critical mass of personnel is required to maintain sufficient knowledge of the software (requirements, design and verification). 11. Process. The SSA should clearly document the engineering development activities for software products as part of their procedures and quality system. It is expected that the procedures will follow the guidance outlined in Section 2 Chapter 7 of this manual and address the elements as illustrated in Figure The process should address how the safety criticality for a software element or sub-element relates to the engineering rigour applied during development. Every effort should be made to ensure that the development process caters for the differing levels of criticality (e.g. Software Hazard Risk Index 1 through 5, or Design Assurance Levels A through E), and product types (e.g. Electronic Warfare Systems, Mission Computers) undertaken by the SSA. If the SSA only defines a single development process, it should be commensurate with the worst case criticality (i.e. function requiring the highest integrity) of the software products that the SSA is responsible for supporting. Section 2, Chapter 7 of this manual provides further details on the Software Assurance requirements for ADF airborne software. 12. Data. The SSA requires access to appropriate software design data including requirements specifications, design descriptions, source code, verification documentation, etc. SSAs that don t have sufficient access and understanding of original software design data are at risk of violating critical software design assumptions during subsequent in-service changes. This may result in software that lacks the required level of integrity, potentially leading to operating limitations or (if undetected) a latent reduction in the level of safety.

3 UNCONTROLLED IF PRINTED AAP Sect 2 Chap Figure 17-1 presents the key process elements of a SSA. Several of the elements are discussed in this chapter, while the remainder are addressed in Section 2 Chapter 7. Quality Assurance System CSCI Data (Requirements, Design, Verification) Development Environment - Qualified Support Tools (Development and Verification) Change Management (Requests, Analysis, Approval) Problem Reporting (ID, Tracking & Trend Analysis) Software Support Agency (SSA) Software Development Process (Documentation and Lifecycle) System Safety Program Configuration Records (S/W Version Traceability to Problem Reports or Change Requests) Configuration Records (Status of all S/W Problem Reports and Change Requests) Software Assurance (Standard) Figure 17 1 Key Process Elements of Software Support Agency Software Problem Reporting and Change Control SOFTWARE PROBLEM AND CHANGE MANAGEMENT Key Issue: The SSA should ensure that all software problems are recorded, tracked, and reviewed by appropriate operational and technical personnel to ensure software problems with safety implications can be assessed and addressed within an appropriate timeframe. Key Issue: The SSA should ensure that proposed capability enhancements to software are recorded, tracked, and reviewed by appropriate operational and technical personnel to ensure that only approved changes are incorporated into software builds. 14. While the application of best practice software development processes, a software assurance standard, and the formulation and integration of a software safety program with the system program should help to minimise the number of serious defects in safety-critical or safety-related software, most approaches do not guarantee the absence of errors. It is important that the SSA has a mechanism for detecting and assessing all types of software problems, including those experienced in-service, and during maintenance or development activities. Furthermore, the SSA requires an appropriate mechanism to permit operators to input minor change requests or enhancements to address capability deficiencies or improve the operational interface. SSAs should: a. establish a system for problem reporting and for documenting proposed changes or enhancements; b. maintain configuration control of all software problem reports or change requests; c. ensure that enough information is captured to permit analysis of the problem or proposed change; and d. ensure that every occurrence of a problem is documented, regardless of whether operators or maintenance staff believe that it is a recurrence of a previously documented problem. 15. For more subtle software defects, a significant amount of information (number of occurrences, initial conditions, contributing factors, etc) may be required to determine the specific problem. Problem reporting also assists 3

4 UNCONTROLLED IF PRINTED AAP Sect 2 Chap 17 with determining the actual system performance and can provide the basis for assessing requirements for major changes such as system replacement or major upgrades. 16. The problem reporting system established by the SSA is not intended to be used to replace current aircraft documentation and should not be used to sign off an unserviceability. Symptoms must be recorded in the EE500/EE435, as with any fault, and normal defect action initiated where appropriate. The problem reporting system should therefore operate in parallel with the existing defect system. Approval Authority for Software Changes and Release Key Issue: The weapon system Configuration Control Board (CCB) should be the approval authority for commencement of all minor type design in-service software changes, the approval authority for aircraft ground and flight testing, and the approval authority for fleet release. 17. For most minor type design changes the CCB, supported competent software SPO personnel, provides sufficient oversight of the software change. However, some DARs have found it useful to elevate software modifications to a major type design change, where based on technical difficulty alone the change might normally be considered to be a minor type design change. Such an approach has been used when the SPO has limited experience with software acceptance, and can benefit from the greater level of oversight provided by various ADF stakeholders for major type design changes. DGTA advice should be sought before classifying design changes on this basis. Problem Investigation and Review Key Issue: A subordinate CCB (eg. Software CCB) or Software Working Group (SwWG) should be established by the CCB to review and prioritise all software problems and change requests. 18. A SwCCB or SwWG is required to filter individual problems and enhancements to ensure adequate engineering investigation and user consideration occurs before a method of resolution is determined. The SwCCB or SwWG should determine a relative priority for each software problem or change request. IEEE Std IEEE Standard Classification for Software Anomalies and MIL-STD-498 Appendix C Figure 5 provides guidance on classifying priorities for software problems. The SwCCB/SwWG should provide the CCB with a report outlining the status of all software problems annually, or more frequently as specified by the CCB. 19. In some cases, investigation might reveal that certain problem reports might relate to system wide problems (e.g. the software problem is a symptom of a wider system or hardware issue), and therefore the SwCCB or SwWG should ensure that the results of the investigation, and any identified trends are communicated to the SPO for further investigation. 20. A typical SwCCB or SwWG would include the following: a. Operator representatives. Aircrew or Aircrew Liaison Officers. b. Acquirer representatives. SPO Software DSDE and/or Software Manager. c. Developer/Maintainer representative. Software Project Manager, and key personnel in the software development team. 21. A SwCCB or SwWG s typical scope of responsibilities includes the following: a. endorse software problem reports / change requests which are valid problems and cancel those that actually describe the system as it is specified or those which do not appear to provide tangible benefits, b. assign a priority for resolution of the software problem reports / change requests, c. ensure that all submitted software problem reports / change requests undergo appropriate analysis by the SSA, d. ensure that all relevant agency/project interfaces have been considered, e. ensure that appropriate action for each software problem report / change request is determined, and f. endorse the relevant plans submitted by the SSA for each version change. 4

5 UNCONTROLLED IF PRINTED AAP Sect 2 Chap The SSA should propose the schedule and content of future software updates through the SwCCB or SwWG to the CCB, based on the direction received. The SSA may also propose that a number of problem reports or change requests be grouped together for implementation in a future software version/build. Allocation should be performed with consideration of the priority, effect of the change, interoperability requirements, hardware resource limitations, hardware compatibility and schedule for the version development. The CCB should ensure that the proposed plan is appropriate in terms of technical and procedural content, resources, schedule and other logistics or operational factors. 23. Where the DAR wishes to provide more rigorous oversight of the SSA s problem reporting and change management activities, then the DAR (or representative) should also take an active role in a Software CCB (SwCCB) or Software Working Group (SwWG). For more information regarding Commonwealth oversight of software modifications, see Annex C to Section 2, Chapter 7 of this manual Software Lifecycle, Development and Assurance Standards 24. Section 2 Chapter 7 provides details on the application and tailoring of standards relevant to the software lifecycle, software development and software assurance. Annex A to this chapter illustrates an example change management approach for in-service software support activities, which is based on the Software Development Standard MIL-STD-498. It is not intended that all SSAs conduct in-service software support in accordance with the process detailed at Annex A, however it does provide a reference framework for SSAs to use in establishing their own processes. DESIGN REVIEW AND APPROVAL OF IN-SERVICE SOFTWARE DEVELOPMENT 25. Regulation 3 of AAP describes the requirements for design review and approval. However, the development approach employed for software does not fully lend itself to the AAP approach, where Design Reviews and Approval activities are conducted at the conclusion of the development project. This section provides some clarification to the role and purpose of Design Review and Approval for software. Readers may find it useful to refer to the diagram at Annex A when reading this guidance. 26. The development of an appropriate software design requires continued analysis and consideration of development products by the reviewers and approvers throughout the development process to ensure evolving issues are appropriately resolved. The first phases of design review for software typically commence during the requirements phase of the software lifecycle, and continue for each major phase of the software lifecycle. While this concept may be appear to violate AAP s requirements for design review independence, and thus places challenges on the design reviewer or approver in terms of maintaining their independence from design development, it is necessary to ensure that each phase of software development has been performed with sufficient rigour and is assessed to provide a valid starting point for the next phase of the software lifecycle. Note that some SSA s commence design development or coding before the requirements are finalised and reviewed. This approach should be discouraged, as it often leads to the introduction of design defects that require patching late in the development lifecycle. 27. Initial design review should typically be conducted by an authorised DE from the initial specification of requirements through to completion of the software design and coding, prior to the commencement of formal developer unit or integration testing. Formal design review, in terms of recording an assessment in Emerald or on the relevant engineering form, should typically be completed by a DE, based on the completion of developer unit testing, and the finalisation of the software test plan and software test description for integration and on-aircraft testing phases. 28. Initial design approval should typically be completed by a DE or SDE based on the completion of the software integration testing, and prior to the commencement of on-aircraft testing phases. This approval milestone is required to support a CCB decision to approve on-aircraft ground or flight testing. Formal design approval, in terms of recording a final assessment in Emerald or on the relevant engineering form, should be completed by a DE or SDE, based on completion of all test activities, and the finalisation of all software documentation supporting the build. The Functional and Physical Configuration Audits will confirm that the software documentation is accurate and complete. The design approval by the SDE is based on the contents of the approved software design package. If the resulting products have deviated from the initial specification in a way that impinges on operating characteristics of the systems, the SDE may consider referral of issues to the CCB to determine if release is appropriate. Contingency Builds OTHER ISSUES FOR CONSIDERATION 29. Under certain operational circumstances, there may be a requirement to perform a contingency software build to provide a rapid capability enhancement or address a capability inhibitor. The objective of contingency builds is to 5

6 UNCONTROLLED IF PRINTED AAP Sect 2 Chap 17 complete, within a reduced time-frame, a product that satisfies a minimum level of technical quality, without unacceptably compromising the safety or capability integrity objectives of the system. SSAs should define a contingency (or cut-down ) process in preparation for such a requirement. The contingency process should be related back to the normal software development process. Exclusion of certain elements within the normal process should be justified, and a remediation phase should be established after the release of the contingency build to complete any outstanding tasks that would normally be required under the normal build process. Note that contingency processes are generally only applicable to mission systems (e.g. electronic warfare systems), and are not normally applied to safety of flight critical systems (e.g. automatic flight control systems). Some systems host safety-related functions, mission functions or a combination thereof (e.g. mission computer). For such systems, the SSA should carefully consider the failure condition severity and the software architecture, specifically the amount of partitioning between safety and/or mission functions, to determine whether a cut-down process is appropriate. Annex: A. Example Software Support Approach 6

7 AAP UNCONTROLLED IF PRINTED Annex A to Sect 2 Chap 17 EXAMPLE SOFTWARE SUPPORT APPROACH 1. This annex describes the typical artefacts (documents and products) used during in-service software support. The artefacts are based on MIL-STD-498 and are presented in the context of a typical approach to the in-service software development life cycle (see Figure 17A-1). It is not the intention of this annex to require that all SSAs conduct in-service software support in this manner, however it does provide a reference framework for SSAs to use in assessing their own approaches. SSAs are encouraged to make use of incremental and evolutionary development techniques where appropriate and to conform with recognised software lifecycle and development standards as described in Section 2 Chapter 7. Documents Planning and Software 2. The remainder of this annex outlines the purpose and context of the documents detailed in Figure 17-1, as well defining the concept of a software product and approved design package. The major influence in determining documentation requirements should be the existing document set for support of a software product, and the minimum amount of data required for the SSA to successfully maintain the software throughout its lifecycle. The strict application of the entire MIL-STD-498 document suite is rarely necessary in-service. Efficiencies can often be gained in-service by combining various DID requirements into a single document. The DIDs should simply provide guidance on what information is important to record and provide a common framework for discussing document types. The requirement for specific documentation requires continual review to ensure relevancy to the development and support of software products. 3. The initiating document for in-service support is the Software Problem & Change Request (SPCR). This is the means the SSA uses to document software problems and change requests (sometimes referred to as Software Trouble Reports (STR) or System Trouble Reports). Other documentation can be broadly classified into the following categories: planning and software documentation. 4. Planning. The following planning documents are referenced in Figure 17A-1: a. Preliminary Engineering Change Proposal (PECP). The PECP provides an overall summary of the change and conveys to the SPO an outline of the software and hardware requirements. b. Systems Engineering Management Plan (SEMP). This optional document may be raised when the hardware component of the change is significant and the whole proposal needs formal planning of the hardware and software development and integration. The impact upon, and the effects of, other projects should be detailed in the SEMP to ensure adequate visibility of interactions between projects. c. Software Version Plan (SVP). This document is described later in this annex. d. Software Development Plan (SDP). The SDP (sometimes referred to as the Software Management Plan (SMP)), is the overarching plan that defines the software management processes to be followed by the SSA and the responsibilities, standards, procedures and organisational relationships for all activities associated with producing a software build. Refer to MIL-STD-498 for further information. 5. Software Documention. The following MIL-STD-498 software documentation is referenced in Figure 17A-1: a. Software Requirements Specification (SRS) b. Software Test Plan (STP) c. Software Test Description (STD) d. Software Test Report (STR) e. Software Development File (SDF) 17A-1

8 AAP UNCONTROLLED IF PRINTED Annex A to Sect 2 Chap 17 Figure 17A 1 Software Support Process 17A-2

9 AAP UNCONTROLLED IF PRINTED Annex A to Sect 2 Chap 17 Software Version Plan (SVP) 6. The SVP acts as a subsidiary plan to the SMP and details the software version development program. The SVP is also sometimes referred to as a Software Build Plan or the Software Design Management Plan. The MIL-STD-498 DID for SDPs may be used as a guide, however, the SVP should only detail specifics of the project and reference procedural information in terms of deviations from an established, documented software development process. The standing instruction or development process documentation should address without further discussion the majority of MIL-STD- 498 DID requirements and this should not be repeated in the SVP. Often software development is conducted in conjunction with a hardware change. In these cases the SVP detail should be integrated into an overall systems engineering plan that relates the components of the hardware and software development into a single coordinated plan. The following paragraphs discuss specific components of the SVP as detailed in Figure 17A-2. SCHEDULE RESOURCE ESTIMATES SVP TEST REQUIREMENT DEVIATION/ WAIVERS (SDE) APPROVED T&E TASKS LIST OF SPCRs APPROVED SYSTEM SAFETY PROGRAM APPROVED SOFTWARE DEVELOPMENT PROCEDURES Figure 17A 2 Software Version Plans a. List of SPCRs. The content of the software development task should be documented in clear requirement statements on the SPCRs. The approved SPCR should detail all known requirements for the outcome of the change. Thus, in the simplest case, the list of SPCRs in the SVP defines the scope of work required. b. Software Development Procedures. The application of a set of standard software development procedures should be clearly defined and established in accordance with a recognised standard and should be based on the requirements of AAP (AM1) and Section 2 Chapter 7 of this manual. These procedures are required for approval of the SSA as an AEO. c. System Safety Program. The application of a SSP should be clearly defined and established in accordance with a recognised standard and should be based on the requirements of Section 2 Chapter 1 of this manual. d. Resource Estimates. Quantitative estimates for the size of the software change should be demonstrated using a code size estimate for each change including staff hours and schedule duration for the project. Schedule milestones such as commencement of testing, user involvement and the timing of key reviews should be specified. Code size and staff hour estimates should be provided for each SPCR included in a software version. e. Test Requirements. The duration and resources for testing should be detailed showing how and when specific changes will be tested. Quantitative estimates for ground and flight testing should be provided. f. Deviations and Waivers. A software development process should be formally established at all SSAs and is normally documented in an SDP or similar document. The SVP will document the application of the process to a particular project and deviations that will be made from it. For example, sometimes a project may wish to tailor out a non-critical activity, or conversely increase the rigour of a particular critical activity. Approval of the SVP constitutes approval for any deviations from the standard process. 17A-3

10 AAP UNCONTROLLED IF PRINTED Annex A to Sect 2 Chap 17 Software Product: Computer Software Configuration Item (CSCI) 7. A software product is more than simply the executable code that provides the required functionality. Figure 17A 3 provides a pictorial view of the complete software product and highlights important aspects of its configuration. Without this additional information which defines the product, supportability of the overall system can be undermined. SOFTWARE INTEGRITY LEVEL UNIQUE IDENTIFIER MOD/ECP STATUS UNIQUE IDENTIFIER SOFTWARE SUPPORT AGENCY APPROVED VERSION HWCI CSCI CSCI COMPATIBILITY HAZARD LOG HAZARD ANALYSIS Outputs from System Safety Program ADP (PER VERSION) DEVELOPMENT ENVIRONMENT CONFIGURATION SPS SRS SDD IDD STD Figure 17A 3 A Software Product a. Hazard Log and Hazard Analysis. To ensure ongoing safety of the aircraft and associated systems the SSA must identify the potential hazards and ensure that they are continually assessed and minimised during development. The process of safety management will include additional techniques as required by the development activities. A formalised hazard analysis and resolution process in accordance with recognised safety standards should be applied to all significant software developments. The outputs from the original SSP under which the software product was developed should form the basis of support documentation. The methods applied and work products produced during initial development should be maintained as part of the CSCI configuration and updated as required by new development. b. Software Integrity Level. The safety criticality of a software component is based on assessment in accordance with the relevant safety and software assurance standard (eg. MIL-STD-882C, ARP4754/61, RTCA/DO-178B or Def Stan 00-55). The outcome determines the level of assurance required for a software component and thus the development requirements to be imposed in terms of the design and process standards. SSAs are to formally record the safety criticality associated with all supported software products. Safety criticality and integrity level definitions from recognised standards are discussed in Section 2 Chapter 7 of this manual. c. Documentation. The set of documentation that constitutes the design of a software product is to be formally managed by the SSA and placed under configuration management. In MIL-STD-498 terms, this refers to the complete set of product related data deliverables, where available. d. Development Environment. The SSA is responsible for establishing procedures to ensure the appropriateness of the development environment for its intended purpose. The development environment should be specified and placed under the same configuration control as delivered products of similar criticality. e. Identification and Compatibility. The compatibility of each CSCI with its associated Hardware Configuration Item (HWCI) should be formally documented. The SSA should maintain configuration data that relates CSCI version numbers to HWCI identifiers that include MOD/ECP status. 17A-4

11 AAP UNCONTROLLED IF PRINTED Annex A to Sect 2 Chap 17 Approved Design Package (ADP) 8. The ADP, as illustrated in Figure 17A 4, may take a variety of forms, and should in most cases be consistent with the development process applied by the initial developer. It would normally include: a. the CSCI source code; b. project documentation planning, requirements, design, test, and reports (eg. SRS, SDD, IDD, SDP, STP, STDs, STRs and SVD); c. records of all reviews and approvals; and d. an amendment package that updates the existing documentation for the system and updates the design documents, user manuals and existing test procedures. The level of design change documentation, testing and engineering review should be commensurate with the safety criticality of the system or change. For software products that undergo a number of changes in their service life, the existing document set should be amended to reflect the software product. This ensures that there is a single documentation baseline describing the software product. Alternatively some SSAs have found it convenient to issue supplements to existing documentation detailing only those aspects of the change. Note that the ADP submitted to the Commonwealth does not always include the complete set of information depicted in Figure 17A-4. This is acceptable, provided the Commonwealth has access to any information not included, but referenced, in the ADP. DESIGN REVIEW DESIGN APPROVAL ADP SDFs STP STRs SVD AMENDMENT PACKAGE SRS, SDD, IDD, STD, SUM CSCI Source Code Figure 17A 4 Approved Design Package 17A-5

12 AAP UNCONTROLLED IF PRINTED Annex A to Sect 2 Chap 17 Blank Page 17A-6