SOFTWARE MANAGEMENT CONTROL INTRODUCTION Software encompasses both the

SOFTWARE MANAGEMENT CONTROL

INTRODUCTION § Software encompasses both the executable code (i. e. the programs) run on aircraft computers as well as the data that these programs use. § The term also covers the operating systems (i. e. system software) embedded in aircraft computer systems. § All of these software parts require periodic upgrading as well as modification to rectify problems and faults that may arise as a result of operational experience. § The consequences of software failure can range from insignificant (no effect on aircraft performance) to catastrophic (e. g. major avionic system failure, engine faults, etc. ). § Because of this it is important that you should have an understanding of the importance of following correct procedures for software modification and upgrading.

SOFTWARE CLASSIFICATION § Aircraft software can be divided into five levels according to the likely consequences of its failure, as shown in Table 1. § The highest level of criticality (Level A) is that which would have catastrophic consequences; the lowest level of criticality is that which would have no significant impact on the operation of the aircraft. § Between these levels the degree of criticality is expressed in terms of the additional workload imposed on the flight crew and, in particular, the ability of the flight crew to manage the aircraft without having access to the automatic control or flight information that would have otherwise been provided by the failed software. § Table 2 provides examples of software applications and levels of software criticality associated with each.

EXAMPLES OF SOFTWARE LEVELS LEVEL A AHRS (attitude/heading reference system) GPS/ILS/MLS (microwave landing system)/FLS (field loadable software) SATNAV (satellite navigation) VOR (very high frequency omni-range)ADF (automatic direction finder) B TCAS ADSB (automatic dependent surveillance broadcast) Transponder Flight Displays C DME VHF voice communications D AHRS (attitude/heading reference system) Automatic Levelling CMC (central maintenance computer)/CFDIU (Centralized Fault Data Interface Unit) Data Loader Weather Radar E In-flight entertainment

SOFTWARE CERTIFICATION § The initial certification of an aircraft requires that the design organization (DO) shall provide evidence that the software has been designed, tested and integrated with the associated hardware in a manner that satisfies standard DO-178 B/ED-12 B (or an agreed equivalent standard). § In order to provide an effective means of software identification and change control, a software configuration management plan (CMP) (e. g. as defined in Part 7 of DO-178 B/ED -12 B) is required to be effective throughout the life of the equipment (the CMP must be devised and maintained by the relevant DO). § Post-certificate modification of equipment in the catastrophic, hazardous or major categories must not be made unless first approved by the DO. § Hence all software upgrades and modifications are subject to the same approval procedures as are applied to hardware modifications. This is an important point that recognizes the importance of software as an ‘aircraft part’.

SOFTWARE CERTIFICATION § Any modifications made to software must be identified and controlled in accordance with the CMP. § Guidance material is provided DO-178 B/ED-12 B and DO- 178 C/ED-12 C (2011). The relationship between the development of aircraft hardware and software is shown in Figure 13. 2. § Note that the two life cycles (hardware and software) are closely interrelated simply because a change in hardware configuration inevitably requires a corresponding change to the software configuration. § The safety assessment process (SAP) is a parallel activity to that of the system development process. It is important to be aware that changes to the system design and configuration will always necessitate a re-appraisal of safety factors.

SOFTWARE CERTIFICATION § Testing takes place throughout the development process. Independent tests are usually carried out in order to ensure that the results of tests are valid. § Testing generally also involves simulation of out-of range inputs and abnormal situations such as recovery from power failure (ensuring that a system restart is accomplished without generating dangerous or out of- range outputs. § Traceability of software is a key component of the DO-178 B criteria. § Planning documents and evidence of traceability help to ensure that not only are certification requirements met, but also that the final code contains all of the required modules and that each module is the most recently updated version. § Care is also needed to ensure that none of the final code will be detrimental to the overall operation of the system (for example, seeking data from sensors and transducers that may not be fitted in some configurations of a particular aircraft).

SOFTWARE UPGRADING § When considering software modifications and upgrades it is important to distinguish between executable code (i. e. computer programs) and the data that is used by programs. § Both of these are commonly referred to as ‘software’ and both are likely to need modification and upgrading during the life of an aircraft. (1) Field loadable software : Field loadable software (FLS) is executable code (i. e. computer programs) that can be loaded into a computer system while the system is in place within the aircraft. FLS can be loaded onto an aircraft system by a maintenance mechanic/technician in accordance with defined maintenance manual procedures. There are three main types of FLS: loadable software aircraft parts (LSAP); user modifiable software (UMS); and option selectable software (OSS).

SOFTWARE CERTIFICATION (a) Loadable software aircraft parts : LSAP is software that is required to meet a specific airworthiness or operational requirement or regulation. LSAP is not considered to be part of the aircraft approved design and therefore it is an aircraft part requiring formal (controlled) release documentation. Typical examples of target hardware for LSAP (FLS) include: • electronic engine controls (EEC) • digital flight data acquisition units (DFDAU) • auxiliary power unit’s electronic control units (ECU) • flight guidance computers (FGC).

SOFTWARE CERTIFICATION (b) User modifiable software UMS is declared by the aircraft Type Certificate holder’s design organization (or Supplementary Type Certificate holder’s design organization) as being intended for modification within the constraints established during certification. UMS can usually be upgraded by the aircraft operator, design organization or equipment manufacturer without further review by the licensing authority. Typical examples of target hardware for UMS include: • aircraft condition monitoring systems (ACMSs) • in-flight entertainment systems (IFEs).

SOFTWARE CERTIFICATION (c) Option selectable software : OSS is software that contains approved and validated components and combinations of components that may be activated or modified by the aircraft operator within boundaries defined by the Type Certificate or Supplementary Type Certificate holder. Typical examples of target hardware for OSS can be found in integrated modular avionics (IMA) units.

DATABASE FIELD LOADABLE DATA § Database field loadable data (DFLD) is data that is field loadable into target hardware databases. § Note that it is important to be aware that the database itself is an embedded item that resides within the target hardware and is not, itself, field loadable, and that the process of ‘loading a database’ is merely one of writing new data or overwriting old data from a supplied data file. § DFLD is usually modified or updated by overwriting it using data from a data file which is field loaded. § The data file can contain data in various formats, including natural binary, binary coded decimal or hexadecimal formats. § Of these, natural binary code produces the most compact and efficient data files, but the data are not readable by humans and, for this reason, binary coded decimal or hexadecimal formats are sometimes preferred.

DATABASE FIELD LOADABLE DATA § It is important to note that the updating of an aircraft database will usually have an impact on aspects of the aircraft’s performance. § However, if the data used by a program are invalid or have become corrupt, this may result in erratic or out of range conditions. § Because of this, it is necessary to treat DFLD in much the same manner as the executable code or LSAP that makes use of it. § Hence a DFLD must be given its own unique part number and release documentation. Typical examples of the target hardware with databases that can be field loaded with DFLD (and that need to be tracked in the same manner as other aircraft parts) include: Ø flight management computers (FMC) Ø Ø terrain awareness warning system (TAWS) computers integrated modular avionics (IMA) units.

DISTRIBUTION METHODS FLS and DFLD can be distributed by various methods, including combinations of the following: • Media distribution: a process whereby FLS or data files are moved from the production organization or supplier to a remote site using storage media such as floppy disk, a PCMCIA (Personal Computer Memory Card International Association)card, a CD-ROM or an onboard replaceable module (OBRM). § Electronic transfer: a process where a laptop, hand-held computer or portable data loader is used to transfer data using a serial data link or temporary bus connection. • Electronic distribution: a process whereby FLS or DFLD are moved from the producer or supplier to a remote site without the use of intermediate storage media, such as floppy disk or CD-ROM.

DISTRIBUTION METHODS § The method of release is dependent upon whether the FLS or DFLD is required to meet a specific airworthiness or operational requirement, or certification specification. § For FLS or DFLD that does not need to meet a specific airworthiness, operational or certification requirement, a Certificate of Conformity is normally sufficient. § In other cases an EASA Form 1 or FAA 8130 -3 should accompany FLS (executable code) that is required to meet a specific airworthiness or operational requirement or regulation, or certification specification, i. e. LSAP. § Examples of LSAP that would require such release would include electronic engine controls (EEC), DFDAU, auxiliary power unit’s ECUs, flight guidance computers (FGC) and IMA units. § An EASA Form 1 or FAA 8130 -3 should accompany DFLD that is required to meet a specific airworthiness or operational requirement or regulation, or certification specification. § Examples of DFLD that require such release include FMCs, TAWS computers and IMA units. A ‘Letter of Acceptance’ or equivalent should accompany the release of any navigational database’s DFLD because an EASA Form 1 or FAA 8130 -3 cannot be provided.

DISTRIBUTION METHODS By virtue of the speed of distribution and the removal of the need for any physical transport media (which can be prone to data corruption), electronic distribution is increasingly being used to transfer FLS or DFLD from the supplier to an operator. Operators should maintain a register that provides the following information: • the current version of the FLS and DFLD installed; • which aircraft the FLS and DFLD are installed on; • the aircraft, systems and equipment that they are applicable to; • the functions that the recorded FLS or DFLD performs; • where (including on- or off-aircraft location) and in what format it is stored (i. e. storage media type), the name of the person who is responsible for it and the names of those who may have access to it; • who can decide whether an upgrade is needed and then authorize that upgrade; • a record of all replicated FLS/DFLD, traceable to the original source.

DISTRIBUTION METHODS When transferring FLS or a DFLD, it is essential to ensure that: • the FLS or DFLD has come from an appropriate source; • effective configuration control processes are in place to ensure that only the correct data and/or executable code will be supplied; • the FLS or DFLD is accompanied by suitable release documentation and records are kept; • suitable controls are in place to prevent use of FLS and DFLD that have become corrupted during existence in any ‘open’ environment, such as on the internet or due to mishandling in transit; • effective data validation and verification procedures are in place; • the FLS and DFLD, as well as the mechanisms for transferring them (file transfer and file compaction utilities), are checked for unauthorized modification (for example, that caused by malicious software such as viruses and ‘spyware’).

DISTRIBUTION METHODS § Special precautions are needed when the FLS or DFLD are transferred or downloaded using the public internet. § These precautions include the use of an efficient firewall to prevent unauthorized access to local servers and storage media, as well as accredited virus protection software. § Further precautions are necessary when making backup copies of transferred or downloaded data. § In particular, backup copies should be clearly labelled with version and date information and they must always be stored in a secure place.

SOFTWARE LOADING PROCEDURE A typical software loading procedure for the electronic engine control (EEC) of a modern passenger aircraft is as follows: 1. Make sure the electrical power to the EEC is off. 2. Connect one end of the portable data loader (PDL) cable to the connector of the loader 3. Disconnect the electrical connector from the EEC. 4. Connect the other end of the PDL cable to the connector of the EEC. 5. Connect the 28 V DC power source to the brown (+), black (–) and shield (chassis ground) terminals of the loader cable. 6. Load the software using the following steps: (a) Check you have the correct disk needed to load channels A and B with the non-volatile memory (NVM) and the operating program software. (b) Turn on the 28 V DC supply to the loader.

SOFTWARE LOADING PROCEDURE (c) Turn on the 115 V AC (400 Hz) supply to the EEC. (d) Turn on the loader without the disk inserted. The PDL display will show DISK NOT INSERTED after the PDL is initiated. (e) Make sure you use the correct EEC software version disk and also ensure that the same software version is used for both the left and right engines. (f) Check that the software disk is not write protected before you load the new software (g) Insert the appropriate disk into the PDL drive within five minutes after you turned on the power. (h) The PDL will automatically load the NVM and the operating program software to the two channels of the EEC. If it is successful, the PDL will display LOAD COMPLETE. It will take approximately 12– 16 minutes to load the EEC. If the software loading has failed, it may take a few minutes before the transfer fail lamp illuminates. If the transfer fail lamp illuminates, make sure the cable connections are correct. Remove the power and repeat the software loading steps above. Note that no more than three attempts can be made if the failure recurs

SOFTWARE LOADING PROCEDURE (i) If LOAD COMPLETE is displayed on the loader, turn off the loader and then turn off the 115 V AC or 28 V DC. (j) Remove the disk from the loader. 7. Remove all electrical power from the EEC and the loader. 8. Remove the loader and reconnect the EEC cables. 9. Use the appropriate memory verification program (included in the software reprogramming disks) to make sure the EEC has been reprogrammed correctly. If the verify program displays PASS for the EEC part number as well as the checksums, the EEC has been programmed correctly. If FAIL is displayed because the comparison of the FADEC (full authority digital engine control)/EEC hardware part number did not agree with the software part number, make sure the FADEC/EEC hardware part number is correct on the nameplate. Use the PRINTSCREEN feature of the PC, and make a paper copy of the final results 10. Use a ball-point pen to write the number of the appropriate software version, Service Bulletin number and date on the Service Bulletin plate (a metallic sticker) on the EEC.

DATA VERIFICATION • Various techniques are used to check data files and executable code in order to detect errors. • Common methods involve the use of checksums and cyclic redundancy checks (CRC). • Both of these methods will provide an indication that a file has become corrupt, but neither is completely fool-proof. • Checksums involve adding the values of consecutive bytes or words in the file and then appending the generated result to the file. • At some later time (for example, when the file is prepared for loading) the checksum can be recalculated and compared with the stored result. • If any difference is detected the file should not be used. • Cyclic redundancy checks involve dividing consecutive blocks of binary data in the file by a specified number. • The remainder of the division is then appended to the file as a series of check digits (in much the same way as a checksum). If there is no remainder when the file is later checked by dividing by the same number, the file can be assumed to be free from errors.