NGIMS-FSW-51-CM Instrument Software Configuration Management Plan for NGIMS Flight Software Prepared By: Michael Paulkovich, Lead NGIMS Software Engineer for Hasso B. Niemann, Paul Mahaffy, NASA/GSFC Code 915 Laboratory for Planetary Atmospheres January 15, 2002 Rev 0 DOCUMENT CHANGE HISTORY revision Date Change 0 15 Jan 02 First release. CONTENTS Overview 1 1. Build Process 1 2. Test Process 1 3. Version Approval Process 1 3.1 Version Numbering 1 3.2 Programmer Tests 2 3.3 V&V Suite 2 3.4 Baseline Test 3 4. Configuration Management 3 4.1. Software Configuration Item Identification 3 4.2. Software Configuration Control 3 4.2.1 Discrepancy Reporting 3 4.2.2. WR Evaluation and Approval 4 4.2.3 Version Identification 4 4.2.4 Libraries 4 4.2.5 Databases 4 4.3 Software configuration auditing 4 4.4. Software configuration status accounting 4 OVERVIEW This document defines the Instrument Software Configuration Management Plan. Configuration Management includes the software build & test process, version approval and release process, and management of changes, configurations, backup and accounting. Contour/NGIMS is a quadrupole mass spectrometer instrument. The flight microprocessor is a 1750A (Marconi MA31750) running at 8 MHz, with 64KW primary RAM, 64 KW ROM, 128 KW EEPROM, and 32 KW "extra" (I/O-mapped) RAM. The programming languages used are Ada (Tartan compiler system, maintained by DDC-I) and 1750 assembly. Refer to GSFC/NGIMS-FSW-30 (Release Description Document, v3.6.00) for details on compiler version, support, known bugs and work-arounds. The Concurrent Versions System (CVS) tools are used by the flight software team for most of the configuration and version management. Refer to http://www.cvshome.org for details on CVS. A set of documentation related to the CM process and referenced herein is as follows: GSFC/NGIMS-915-FSW (Code 915 FSW Development Procedures) GSFC/NGIMS-FSW-01 (Contour/NGIMS Flight Software Management Plan) GSFC/NGIMS-FSW-34 (WOA - Build Procedures, Testing, Delivery) GSFC/NGIMS-FSW-52 (FSW Build Procedures Document) 1. BUILD PROCESS The source files and Ada Compilation system are maintained on Sun computer inms1 and also backed up to other media. Refer to GSFC/NGIMS-FSW-52 and GSFC/NGIMS-FSW-34 for complete instructions on the build process, including ISO-9000 Work Order Authorizations. 2. TEST PROCESS Refer to GSFC/NGIMS-FSW-52 and GSFC/NGIMS-FSW-34 for complete instructions on the testing process, including ISO-9000 Work Order Authorizations. 3. VERSION APPROVAL PROCESS This section describes version identification, testing and approval for software releases. Different versions are identified by the Version Number; various tests are run before releasing a new version. Refer to GSFC/NGIMS-915-FSW-01 (Code 915 FSW Development Procedures), §2.5 ("Flight Software Testing") for details of the tests and test scripts. 3.1 Version Numbering Each release of the flight software has a 4-digit Version Number identifying it, as follows: V.V.RR where: V.V is the Version RR is the Revision. The Version, V.V, is incremented (by 0.1) each time a new version is to be released that has been recompiled and re-linked by the Ada Development System. It it not incremented when a version of the load image is patched and released as a modification to a "baseline" compiled Version. The Revision number, RR, will typically be incremented when working on a new compiled version for "internal" releases to programmers and testers. After a "formal release," the Revision number will be incremented for each new release of that software that is a modified (patched) version that has been tested and approved. The four-digit version number is maintained also in computer RAM in hexadecimal format (each nibble being allocated a decimal digit), and is transmitted in TM to help identify which version of the flight software is running. Refer to GSFC/NGIMS-FSW-06 (Preliminary Telemetry Memo), §1.3 ("Detailed Scan Segment Format"). Example Versioning Process As an example, Flight Software version 3.6.00 was the final firmware version released for Flight. It represents a compilation dubbed "3.6" and a Revision "00". After v3.6.00 was released, following the Build Procedures document, the software was re-built and identified as v3.7.00. That version is compared to v3.6.00 to ensure the rebuild matches exactly; then, source code for v3.7.00 is modified for each approved Work Order. New compilations are released "internally" for programmer tests and V&V, incrementing the RR revision number for each internal release. The final approved compilation of v3.7.xx was v3.7.07. Version 3.7.07 was patched, yielding a formal release for 3.7.08, then again for 3.7.09. 3.2 Programmer Tests Naturally, programmer tests are performed during development of a new release. They are followed by complete regression testing using the V&V Suite (see below). There are other metrics than just correctness that are also tested, such as throughput margin and memory margins. There are also certain coding standards that are followed. Refer to GSFC/NGIMS-915-FSW (Code 915 FSW Development Procedures) and GSFC/NGIMS-FSW-01 (Contour/NGIMS Flight Software Management Plan). 3.3 V&V Suite The V&V Suite is a GSE script and procedure designed to test every telecommand and major software mode. Moreover, it provides "regression tests" to ensure that new releases didn't reverse previous fixes (there are specific tests for known past bugs). As far as is reasonable and feasible, as many of the flight software requirements are tested by the V&V suite. The V&V Suite is best run on a breadboard system connected to simulators. Once the V&V Suite has been performed to the satisfaction of an independent tester, the Baseline Test is run. 3.4 Baseline Test The Baseline Test is a GSE script and procedure designed to test the instrument. As such, it also makes a very good test of the flight software functionality. The Baseline Test is best run on a breadboard system connected to simulators first. After a version is approved and released it should be run again on the Brassboard Instrument if available, Engineering Model (N/A to NGIMS), Flight Instrument, and/or Flight Spare (N/A to NGIMS). Once all tests have been performed and pass, the software may be released to the Flight Instrument. 4. CONFIGURATION MANAGEMENT Software Configuration Management consists of the following four major elements: SCM Element Method Software configuration item identification Define baseline components. Software configuration control Mechanism for initiating, preparing, evaluating, approving or disapproving all change proposals. Software configuration auditing Mechanism for determining the degree that the current state of a software system reflects its baselines (requirements and planning documents). Software configuration status accounting Mechanism for maintaining a record of how a system has evolved, and the state of a system relative to published documents and written agreements. 4.1. Software Configuration Item Identification Baseline components for a major recompiled release of the Flight Software are delineated in the Delivery Report for v3.6.00, GSFC/NGIMS-FSW-32. See also GSFC/NGIMS-FSW-30 (RDD, v3.6.00). 4.2. Software Configuration Control This section describes the mechanism for initiating, preparing, evaluating, approving or disapproving all change proposals. 4.2.1 Discrepancy Reporting The mechanism for initiating change proposals is the Discrepancy Report system. The following web page holds the online DR system: http://fsw.gsfc.nasa.gov/CCR/CCR.cfm?name=NGIMS When a change is requested (including both bug fixes and Software Enhancement Proposals), interested personnel go to that web page and select "ADD New Work Request." A new WR (Work Request) is thus generated and numbered, and entered into the online database. 4.2.2. WR Evaluation and Approval Work Requests are evaluated for legitimacy by (a) the Flight Software programmers (usually in the case of bug reports) and/or the Science Team (usually in the case of Enhancement Proposals). 4.2.3 Version Identification Refer to §3.1 above. 4.2.4 Libraries Separate Ada libraries are maintained for each major build. Refer to GSFC/NGIMS-FSW-52 (FSW Build Procedures Document). 4.2.5 Databases There are databases associated with the "AMB" (Adaptive Memory Block) of memory. These are largely Calibration and Tuning parameters. The instrument test & cal team maintains these databases. They are converted to the appropriate software source code (mostly assembly "overlays"). Refer to GSFC/NGIMS-FSW-52 (FSW Build Procedures Document). 4.3 Software configuration auditing The Concurrent Versions System (CVS) tools are used by the flight software team for most of the configuration and version management. The V&V and Baseline Test scripts and procedures determine the degree that the state of a software version reflects its baselines (requirements and planning documents). A Traceability Matrix lists each high-level FSW requirement and correlates them to implementation, and related documents. To determine that source code used to begin generating a new build is the exact same source code that was used to build the most recent approved release, refer to GSFC/NGIMS-FSW-52 (FSW Build Procedures Document), under the "Verify rebuild properties" event. 4.4. Software configuration status accounting A record of how the software system has evolved is maintained automatically by the CVS database. Other procedures in the FSW Build Procedures Document (GSFC/NGIMS-FSW-52) and the RDD, Test Report and Delivery Reports also define how to determine and verify the state of the FSW versions relative to published documents and written agreements. (See also 4.3 above.) NGIMS-FSW-51-CM 1