LOADING SOFTWARE TO ENGINE CONTROLS IN THE,FIELD

Transcription

1 THE AMERICAN SOCIETY OF MECHANICAL ENGINEERS 345 E. 47th St, New York, N.Y GT-16 The Society shall not be msponsthle for statements or opinions advanced in papers or cricussion at meetings of the Society or of its Divisions or Sections, or printed in its publications. Discussion is printed only it the paper is published iri an ASME Journal. Authorization to photocopy material for internal or personal use under circumstance not falling within the fair use 'provisions of the Copyright Act is granted by ASME to libraries and other users registered with the Copyright Clearance Center (CCC) Transactional Reporting Service provided that the base fee of $0.30 per page is paid directly to the CCC, 27 Congress Street, Salem MA Requests for special permission or bulk reproduction stosuki be addressed to the ASME Teclmical Putishing Department Copyright by ASME All Rights Reserved. Printed in U.S.A LOADING SOFTWARE TO ENGINE CONTROLS IN THE,FIELD Scott F. Beecher Pratt & Whitney Aircraft Mail Stop Main Street East Hartford, Connecticut U.S.A. (860) Fax: (860) beechesf@pweh.com BREAK Bret G. Lynch Pratt & Whitney Aircraft Mail Stop Main Street East Hartford, Connecticut U.S.A, (860) Fax: (860) lynchbg@pweh.com ABSTRACT With the advent of electronically alterable memories in electronic gas turbine engine control systems, there is now the opportunity for updating software in the field. Field loading provides a means to economically correct problems or introduce enhancements to system operation through the electronic control. In this paper we describe the characteristics of high integrity reprogramming systems used to update engine controls in-the-field. Pratt & Whitney Aircraft supports two methods for inservice reprogramming of Electronic Engine Controls (EECs). These two methods are PC Laptop based loaders and ARINC loaders. This discussion will focus on the capabilities provided to support in-thefield reprogramming of engine controls. The flexibility, integrity, and the benefits of field reprogramming provided by these software loading systems will be explained. These reprogramming systems provide a PC based application and ARINC based systems for either on-wing reprogramming or on-board reprogramming directly from a flight deck device to. The PC Loader reprogramming utilities allow field personnel to reprogram engine control application software and/or constants and configuration information using a suitably equipped IBM PC or compatible computer. These utilities are intended to be operated per Service Bulletin authorization only. They require a PC compatible computer (presumably a laptop model) with 2 UART interface cards, an interfacing cable, and the new software to be loaded. The rigor and manner of the integrity checks to ensure proper loading of the control is essential to an acceptable loading system. There are two types of ARINC-based loaders: on-wing loaders and on-board loaders. Both types enable the operator to upload application, trim, and/or configuration software to the engine control. Additionally the ARINC 615 device allows operators to download fault and configuration data from the control. Each type of loader uses a specially formatted file to control the sequence of operations involved in a data loading session. The on-wing loader utilizes a specially designed portable data loader which connects directly to via dedicated cabling through the control's ARINC connectors. This type of data loader contains software which communicates via an ARINC 615 protocol to a peer software entity running on. The on-board loader uses the aircraft's central maintenance computer system to communicate with over the aircraft's ARINC 629 data bus. It also operates using a peer-to-peer communication protocol with. The ARINC 629 loader requires no extra equipment or cabling, nor does it require to be accessible for attachment of cables. ACRONYMS! DEFINITIONS ARINC - Aeronautical Radio Incorporated. ARINC provides a series of standards for the aeronautics industry. Checksum - Check Summation value, a data verification value created by summing across a block of electronic data. The Checksum value can be used to later verify your data is still valid. CRC - Cyclical Redundancy Check, a polynomial based value used to verify the integrity of electronic data or software. A 32 bit CRC provides an average probability of 2.3 x I0**-10 of not detecting single, double or burst errors. See the references for additional literature describing CRCs. EEC - Electronic Engine Control. PC - Personal Computer, assumed in this case to be an IBM or compatible computer. Service Bulletins - Specific authorization paperwork allowing software updates to revenue service engine controls. Service Instructions - Instructions accompanying the Service Bulletins detailing how to perform the authorized updates. Presented at the International Gas Turbine & Aeroengine Congress & Exhibition Orlando, Florida June 2 June 5, 1997

2 UART - Universal Asynchronous Receiver Transmitter, a communication interface used to communicate with an EEC or other electronic devices suitably equipped. INTRODUCTION Within the last 10 years, electronic control systems have moved towards the use of electronically alterable read-only memories. This discussion provides a guideline for the creation of a field reprogramming system for performing software upgrades in the field. Specifically, it provides a framework for a field loading process for an electronic control system which is on-wing or in the shop. The control systems addressed here must have external software loading capabilities and have loadable software with built-in integrity components (e.g. Checksums, Cyclical Redundancy Checks (CRCs), hardware and software compatibility information). In addition, two examples of loaders at Pratt & Whitney's Large Commercial Engine division are used to illustrate these characteristics. The classic approach to reprogramming has been to return the controls to established reprogramming stations, but now with minimal equipment and cost we can perform in-the-field reprogramming of engine controls. The two types of in-service loaders created by Pratt & Whitney's Commercial division for use in field reprogramming of Electronic Engine Controls (EECs) are PC Loaders and ARINC Loaders. The PC Loaders use a UART serial diagnostic interface to communicate with an internal software program in the engine control. The PC Loaders are all directly connected to s (on-wing or back in the shop). The ARINC Loaders interface to via serial ARINC lines. The ARINC loaders support two connection methods: on-wing and on-board reprogramming of engine controls for commercial aircraft. The information contained in this paper can be used to provide guidance in the conceptualization phase of loader development Most information discussed can be applied to the loading of any safety critical electronic systems whether maintained locally or in-the-field. HISTORY When engine controls transitioned from hydromechanical controls to supervisory and full-authority controls containing embedded software, the need for reprogramming of the software arose. Early controls contained read-only memory devices which required physical bum-in of the executable software. In order to be reprogrammed, each EEC had to be returned to the Original Equipment Manufacturer (OEM). This process involved the following steps: Ship the engine control from the customer to the OEM Reprogram Revalidate through a production acceptance test Ship the engine control from the OEM to the customer The expense and time delay involved in this process were considerable. Newer engine controls, equipped with electronically erasable and programmable memory devices, have made it technically feasible to ship the software from the OEM to located on-site at the customer facility, eliminating the need to ship EECs from the customer to the OEM. FIELD REPROGRAMMING Capabilities needed The reprogramming system components are made up of the electronic control hardware and the external support equipment. The control hardware must contain an interface to receive the updated software. In addition the control would generally include both a communication interface and a resident interface servicing software entity. The support equipment includes an interfacing cable (in some cases it may be "built-in" to the system), the support software and the reprogramming device. The full reprogramming process requires in addition to all the reprogramming system components (hardware and software), all procedures, authorization documentation, and any records that must be kept for configuration management purposes. The challenge here is to dependably move software from its configuration controlled repository into the control while located inthe-field. This process must be robust enough to withstand the urgency and often adverse conditions often present in field reprogramming. It must ensure that the target system contains the software exactly as it was extracted from its repository. Some tolerance to imperfect connections and adverse operating conditions is highly desirable. Operator mistakes of all types including improper cable hookups and invalid data entry should be detected and clearly annunciated. A record of reprogramming activity is needed to provide configuration traceability. Problems This remote capability for introducing remote software updates to the field has added some concerns for control system maintenance personnel and the certification authorities. This is a list of high priority issues that must be addressed for loader system design. Sufficient capability built into the target control system to allow for data integrity and configuration verification. Built-in protection against inadvertent modifications to unintended memory areas of the control system. Encapsulation / labeling of the controlled data/software (e.g. disk, CD-ROM, tape or electronic transfer) and protection during transport to the field location. Protection in the reprogramming process to ensure that proper authorization was received prior to introducing updates. Assurance that support equipment will detect improper loads to the target hardware. Appropriate software/data is loaded that is compatible with all other existing software/data in the target control hardware or other software/data that is also being loaded. All software/data loaded is compatible with the target control hardware. Operator has been authorized to perform this load. Reprogramming integrity cannot be achieved without confirmation that the data is correct after it is loaded and in the control system. It is important to have sufficient mechanisms in place to ensure that the software resident in the control system is identical to the controlled software retrieved from the configuration controlled software repository. Communication fault tolerance during loading can provide critical support for less than perfect loading situations. 2

3 PC LOADER SYSTEM The Pratt & Whitney PC loader system was developed with approval from the New England Region Federal Aviation Authority (NER FAA). The PC loader was developed to address field reprogramming of Electronic Engine Control (EEC) systems on many commercial and military aircraft. The PC loader support equipment consists of a laptop PC computer, two RS-422 UART communication cards and a Pratt & Whitney interface cable (EEC to UART cards). There is a software loader utility written to execute on the laptop PC which will perform the actual transfer of software/data from the PC to each of the two channels (referred to as channel A and channel B) in. The utility is designed to operate per Service Bulletin authorization only. This paperwork contains descriptive information including an enabling key value, part numbers for acceptable configurations of EECs and then the specific serial numbers this authorization applies to. Development of this software is performed per RTCA/D0-178B "Software Considerations in Airborne Systems and Equipment Certification" for Tool Qualification (Section 12.2) requirements. Due to the critical requirement to ensure that a proper load has occurred, the PC loader software is developed to the highest safety critical level. At this time all reprogrammable software and the loader utility are distributed to the field on floppy disks. The disk and a backup are "built" directly by the Software Configuration Management Administrator from the controlled master of each software entity from engineering records. For each EEC program, a specific directory structure has been established on the disk to organize all the software and data files. Process The following series of events describe a field reprogramming instance: Customer requests software update of EEC(s). Service Bulletin and Service Instructions are delivered along with configured PC loader floppy disk to customer. Customer supplies (or acquires) hardware for support equipment including cable and PC laptop with RS-422 cards. Using the Service Instructions the customer runs the PC loader utility on EECs authorized via the Service Bulletin. Loader Utility Operation The following steps provide an overview of the PC loader utility operation: Upon startup, the PC loader tests the environment in which it is executing to ensure that it can execute properly (this includes executing off the floppy disk, also verifying the directory structure and that they contain the proper number of files). Create a log file which will contain a text record of the entire reprogramming process. Ensure that a log file can be created and that it contains: the loader utility version number, date and time of reprogramming initiation, all error messages, proprietary notice and all operator entry. Ensure that the operating system installed in the PC laptop is sufficient to support loader system operation, and that UART cards are installed. Operator data entry of the following from the Service Bulletin: EEC Serial Number - after operator entry, the serial number is read from EEC memory and compared to operator entry to ensure agreement with. EEC Hardware Part Number - after operator entry, the part number is read from EEC memory and compared to operator entry to ensure agreement with. Enter checksum value for EEC software trim constants file which is used as an enabling key value which authorizes the operator to perform reprogramming. Determine reprogramming task: Full reprogramming or updates to trim constants only. Validate all data files prior to loading: Each file to be loaded has a header which includes the start/end address for load, checksum value (summation of all data contained within this file - as a truncated number), and other descriptive information about the contents of the file. Use the checksum value to verify the integrity of the file (compute what the checksum should be and then compare). Contained within the loadable data of each file is a checksum value and/or a cyclical redundancy check (CRC) value which are also verified at this time. These same values will be used by the control software after loading as one method to verify the integrity of the load. Verify communications by testing that each of channels is connected to the proper cable. This will ensure that EEC channel A is connected to UART channel A, and EEC channel B is connected to UART channel B. All communications will have built-in tolerance by performing re-tries on any communication error. Using configuration information embedded within the loadable data, verify the following: Loadable software components are compatible with each other. Loadable software is compatible with hardware (via part number). Hardware part number entered by operator from the Service Bulletin matches hardware part number read from memory. EEC serial number entered by operator from the Service Bulletin matches serial number read from memory. Loading Software into Control After all software/data files have had their configuration information and integrity verified then the reprogramming process can begin. The software/data transfers should be done in small blocks of data. This will allow for quick response to problems as reprogramming is occurring. Each block of data is read back from memory and compared against what was loaded. Verification/Validation Operations When all software/data has been loaded then the verification phase begins. Verification of the load includes either reading all software/data from the control's memory and performing a full bit for bit comparison against the data loaded or if a sufficiently accurate internal integrity value (i.e. CRC) is available then this can be used with internal control functionality to verify the data while in memory. As the final validation test, the loader system will return the control to operational mode. The internal checks built into the 3

4 safety critical software will validate that reprogramming was successful and that the unit is operating normally. Next, a series of tests is performed by the aircraft maintenance personnel for in-flight critical aircraft operations. ARNO LOADERS ARINC 615 Dataloader The ARINC 615 data loader system provides field operators with the capability of loading software directly to an aircraft-mounted engine control/engine system. Additionally, the loader is capable of initiating and completing a download of fault and configuration data from the engine control onto a floppy disk. This system operates using an electronic data loader and EEC resident software which coordinate the transmission of data. The custom data loader device is known as a Portable Data Loader (PDL). The PDL consists of a floppy disk drive, a set of status indicators, and a processor board. The engine control contains a PDL interface software module whose function it is to communicate with the PDL. The two interface through a dedicated cable which attaches directly to the PDL and to either directly or through an aircraft electronics bay. Typical loading session data transactions Perform an EEC fault and configuration data dump. This is initiated by a blank disk being inserted into the PDL. The PDL initiates a session with the data loader software module in the EEC, indicating that a blank disk is present. The EEC interprets this as a request to download the fault and configuration data from onto the blank floppy disk. The transmission of the requested data is then carried out between the two communicating entities. A disk containing application software and a PDL transmission script is inserted into the PDL. The PDL initiates a session with the data loader software entity in, indicating that a download of software to is requested. The EEC then establishes that conditions within hardware are acceptable for downloading software, allowing transmission of the requested data between the two communicating entities. Addressing the problems associated with field loading of software: The flight software in (both the existing software and the software which is to be downloaded) are verified for integrity upon power up. The integrity check includes a CRC check and a checksum of the entire program memory. Failure of these integrity checks will inhibit from controlling the engine (i.e. from starting the engine and turning on fuel). The flight software in performs a configuration check on the software resident in the control upon power up. This check verifies compatibility of the following entities: The different (up to five) software executables resident in The EEC hardware and the software executables resident in The software executables resident in the two channels of Failure of these integrity checks will inhibit from starting or controlling the engine. The data loader executable resident in performs the following checks on the software being transmitted to from the PDL: Verifies the checksum and CRC of each file that is transmitted to as it arrives Verifies the checksum and CRC of each file in EEC memory after it has been written Verifies that the parity of the memory device is correct after the software has been written to the device The PDL must use a PDL download script in order to carry out a load of software. This script is extracted from a software configuration management system using drawings maintained in an engineering records environment. In order to prepare a floppy disk for downloading, the download script plus the actual executables must be extracted from the engineering records environment. The script defines the executable files to be written, the label on which the data will be transmitted on the data bus, and other attributes of the communication session. ARINC 629 Dataloader The ARINC 629 data loader uses a different computer/communication system to provide capabilities similar to the ARINC 615 dataloader, namely the ability to program an engine control without removing the control from the engine/aircraft installation. The 629 loader provides the additional advantage of not requiring the engine cowl to be opened to allow access to connectors. The loader operates with the engine and engine control in their operational configuration. 629 loader system components: A data loader interface consisting of a disk drive and supporting processor system is typically located as a permanent component in the aircraft's flight deck. A data loader software entity resident in the engine control. A communication channel consisting of the aircraft's ARINC 629 data bus, an Engine Data Interface Unit (EDIU), and the engine control's ARINC 429 data bus. The EDIU performs protocol translation between the ARINC 629 protocol received from/sent to the aircraft and the ARINC 429 protocol received from/sent to the engine control. A communication session involving the ARINC 629 data loader consists of inserting a disk into the data loader disk drive in the flight deck, establishing a communication session between the flight deck data loader and the data loader software, and then the transmission of data between the data loader and. The ARINC 629 system does not provide the capability of transmitting fault and configuration data from to a floppy disk. In addressing the integrity assurance problems associated with field reprogramming, the ARINC 629 data loader system follows the same approach as the ARINC 615 system. CRC and checksum verifications of the executable software are conducted in the same manner, both as it is received and after writing to memory. The flight software itself performs the same integrity checks on the software regardless of the method with which it was downloaded. Additionally, the ARINC 629 system requires a specially prepared floppy disk which contains the executable software and transmission script extracted from an engineering records environment. The transmission script, like that for the ARINC 615 system, describes the 4

5 executable files to be transmitted and the transmission attributes to be used in the session. Additionally, the executable files are postprocessed to embed verification information into the header of the file including the CRC of the file. SUMMARY Lessons learned As in any good system design the planning phase is critical to ensure that all the key system components are available to create a high integrity system. The following issues must be addressed within the control system planning phase: Ensure that the loadable data has built-in integrity checking features such as checksums and CRCs. Ensure that the loadable data has built-in configuration control (including software to software compatibility and software to hardware compatibility). The hardware must have external loading capability and built-in functionality to support verification of the loaded data's integrity. During loader system design the following issues are essential to creating a sound system: The process integrity starts with the configuration controlled software extracted from its repository and continues through to the point where the software is resident in the target product. This end-to-end integrity assurance is critical in gaining process acceptance from certification authorities. Create a system which provides visibility into the reprogramming process. This means that the loading system allows access for verification of the software/data integrity AFTER it is resident in the target hardware. The loader system must be easy to use. Confusion in the field under adverse conditions will reduce or eliminate the systems use. REFERENCES 1991, "ARINC 615 Data Loader User Manual", Sundstrand Data Control Inc., Redmond, WA., FSCM No , "ARINC REPORT Airborne Computer High Speed Data Loader", ARINC, Annapolis, Md. Crenshaw, J., 1992, "Implementing CRCs," Embedded Systems Programming, January edition. 1992, "RTCA/DO-178B Software Considerations in Airborne Systems and Equipment Certification", RTCA SC-I67, Washington, DC. Note: ARINC documents are available from: ARINC 2551 Riva Road Annapolis, Maryland U.S.A. phone: (401) RTCA documents are available from: RTCA, Inc Connecticut Avenue, Northwest, Suite 1020 Washington, D.C U.S.A. phone: (202) Experience The PC loader system has been utilized for flight test and revenue service for both 150 program (V2500 engine controls) and for 170 program (Growth PW4000 engine controls). Although we are unable to present specific metrics addressing loads performed, there have been a considerable number of loads done by a variety of personnel under various field conditions. The general feedback received from airline customers and service personnel has been positive. Future Considerations Our next step is to use CD-ROM or Zip disks as our delivery media, and to perform direct electronic delivery of field software. Eventually, the industry will move towards the direct electronic transfer of software updates onto aircraft computers. Future systems upgrades will be paced by the support equipment that is available throughout the customer and maintenance community. Inevitably, as field reprogramming increases in popularity and acceptance, our control systems will be accessible via datalink right from our office desks. 5