AD/FMS/3 Amdt 1 - Honeywell NZ-2000 and IC-800 Navigation Computers

The Directive pivots on several interrelated technical and regulatory concepts. The primary subject matter is the Flight Management System (FMS) as implemented in Honeywell NZ‑2000 navigation computers and IC‑800 or IC‑800E integrated avionics computers. These computers compute aircraft position using data from multiple Inertial Reference Units (IRU). The unsafe condition arises from a software design error induced during a prior modification. Under normal operation, the number of IRUs supplying data can degrade from three to two or two to one, or increase from two to three or one to two. The software error causes an unannunciated shift in the computed position when these transitions occur. This is not a hardware failure but a logic flaw in the software’s handling of IRU state changes. The concept of “affected aeroplanes” is central: an aeroplane is affected only if its FMS computers have specific part numbers and software modification levels identified in Honeywell Technical Newsletter A23‑6111‑008, Revision 001. The newsletter itself is not reproduced in the Directive, but operators must obtain it (presumably from Honeywell). The Directive references a list of known airframe types that may install these computers: Bombardier CL‑600‑2B16 (CL‑601‑3A, CL‑601‑3R, CL‑604); Dassault Mystère‑Falcon 900; Gulfstream G‑1159A, G‑IV, GV; Lockheed 382G series; and Hawker Beechcraft BAe.125 Series 800A (including C‑29A and U‑125). However, Note 1 states these are “known to be installed on, but not limited to” those types. The applicability is defined by the computer part number and software level, not by the airframe model list. Therefore operators of other aircraft types that use these computers must also comply if they have the specified configurations. The Directive provides a “terminating action” - the software upgrade - that eliminates the unsafe condition permanently. After the upgrade, the interim AFM revision becomes redundant and may be removed. The concept of an Alternate Method of Compliance (AMOC) is also present: later revisions of the listed service bulletins are acceptable only if they are approved by the FAA as AMOC to FAA AD 2009‑08‑01. This ties Australian compliance to FAA approval, which simplifies cross-recognition but also means operators cannot use unauthorised modifications. The compliance timeline distinguishes between the initial identification and AFM revision (14 days) and the software upgrade (12 months). This two-stage approach allows immediate risk reduction via crew awareness while giving operators time to procure and install the upgraded software. The economic concept here is the trade‑off between speed of mitigation (cheaper interim step) and long‑term fix (costly upgrade but eliminates ongoing compliance burden). The Directive also involves a delegated decision‑making chain: the CASA Delegate signs the instrument, but the technical basis rests on FAA findings and Honeywell service information. This reflects the global nature of type certificate data and the reliance on foreign airworthiness authorities for common aircraft types.

The primary duty‑bearers are the registered operators of Australian‑registered aeroplanes that have Honeywell NZ‑2000 navigation computers or IC‑800/IC‑800E integrated avionics computers serving the FMS. The Directive does not distinguish between commercial air transport operators, private owners, or corporate flight departments - any operator of an affected aeroplane must comply. Maintenance organisations that perform work on these computers are indirectly affected, as they must be capable of executing the software upgrades specified in the Honeywell Alert Service Bulletins. The list of known airframe types gives an indication of which fleets are likely affected: Bombardier Challenger 601‑3A/3R/604, Dassault Falcon 900, Gulfstream G‑II/IV/V, Lockheed L‑382 / C‑130 (civil cargo variant), and Hawker 800A (including military derivatives). However, because applicability is based on computer part number and software level, operators of other types - such as other Dassault or Bombardier models not listed - must check their own configurations. The removal of Hawker 800XP and 1000 from the previous list suggests those models do not actually carry the affected computers, so their operators are no longer required to check. Manufacturers are affected indirectly: Honeywell produced the service information (Technical Newsletter and Alert Service Bulletins) and presumably supplies the software upgrade. The original equipment manufacturers (Bombardier, Dassault, Gulfstream, Lockheed, Hawker Beechcraft) may have incorporated the fix into their own service instructions. The Directive also affects insurance markets: an operator who fails to comply within the 14‑day or 12‑month deadlines exposes the aircraft to potential grounding and liability, which may affect hull and liability insurance terms. CASA itself is the enforcement agency: it must track compliance, issue approvals for AMOCs, and take action for non‑compliance. Foreign operators who fly into Australia are not directly bound by CASA ADs unless they operate Australian‑registered aircraft, but the specific FAA AD referenced may impose parallel obligations for US‑registered aircraft. The economic burden falls most heavily on smaller operators with limited engineering support: the cost of obtaining the newsletter, inserting the AFM revision, and arranging the software upgrade (including parts, labour, and possible ferry flights) can be significant relative to the value of older aircraft. The Directive creates a concentrated benefit (aviation safety) against a diffuse cost spread across operators. There is also a potential rent‑seeking aspect: Honeywell is the sole source of the upgraded software and the prescribed service bulletins, giving it a captive market for the fix. Operators cannot source alternative software or use a different engineering fix unless it is approved as an AMOC by the FAA, which adds transaction costs. The time pressure of the 14‑day deadline for the interim AFM revision may force some operators to defer other maintenance tasks or to pay a premium for expedited service.

The Directive imposes three explicit duties on operators. Duty 1: within 14 days after 4 June 2009, determine whether the installed NZ‑2000 navigation computers and IC‑800/IC‑800E integrated avionics computers have part numbers and software modification levels identified in Honeywell Technical Newsletter A23‑6111‑008, Revision 001. This is a pure information‑gathering obligation: the operator must inspect the computer nameplates or logbooks and cross‑reference them against the newsletter. Duty 2: for any affected aeroplane, within the same 14‑day window, revise the Limitations Section of the applicable AFM to incorporate the information in Appendix A of the newsletter. The Directive permits inserting a copy of Appendix A into the AFM, which is a low‑cost compliance action designed to alert the flight crew to the unsafe condition (the possible unannunciated position shift) and to specify operating limitations or procedures. Duty 3: within 12 months, upgrade the software in the IC‑800/IC‑800E and NZ‑2000 computers in accordance with the accomplishment instructions of the specified Honeywell Alert Service Bulletins (Table 1). For the IC‑800/IC‑800E, the ASB is 7017300‑22‑A6112, Revision 001, dated 7 February 2008. For the NZ‑2000 NAV computer, there are three parallel ASBs: 7018879‑34‑A6060, Revision 001, dated 21 January 2008; 7018879‑34‑A6062, dated 12 June 2007; and 7018879‑34‑A6063, dated 6 July 2007. The operator must use the ASB applicable to the specific NAV computer configuration. The Directive also includes a right to use an alternative method: after the software upgrade is performed, the operator may remove the AFM revision - it is no longer necessary. This is a right, not a duty; the operator may choose to leave the revision in place. The Directive further grants that actions accomplished before the effective date using Honeywell Service Bulletin 7017300‑22‑A6112 (the original, dated 22 June 2007) are acceptable for the IC‑800/IC‑800E upgrade. This recognises that proactive operators who acted early need not redo the work. Additionally, later revisions of the listed service bulletins are acceptable as compliance if they have been approved by the FAA as an Alternate Method of Compliance to FAA AD 2009‑08‑01. This provides flexibility for operators who may have access to updated service information, but it imposes a condition: the later revision must be FAA‑approved. The operator does not have an independent right to create their own AMOC; they must rely on FAA approval. The Directive does not explicitly state a right to request an AMOC from CASA, but such a right exists under general civil aviation regulations. The duties are strict liability - there is no fault requirement; failure to perform within the deadlines is a breach regardless of reason. The rights are conditional: the software upgrade right to remove the AFM revision only applies after the upgrade is completed. The economic effect of these duties is to compel expenditure on information retrieval, AFM binding, and software procurement and installation. The 14‑day timeline for duties 1 and 2 is short and may require resources to be diverted from other tasks.

The Directive itself does not specify penalties. However, as a legislative instrument made under the Civil Aviation Act 1988 (Cth) and the Civil Aviation Safety Regulations 1998 (CASR), non‑compliance with an Airworthiness Directive is a breach of the airworthiness requirements for the aircraft. An aircraft that does not comply with all applicable ADs is not airworthy (see regulation 42.010 of CASR for maintenance, and regulation 21.025 for design standards). Operating an aircraft that is not airworthy is an offence under the Civil Aviation Act. The maximum penalty for operating a non‑airworthy aircraft can be up to 50 penalty units (currently a penalty unit is $313, so $15,650) for an individual or 250 penalty units ($78,250) for a body corporate per offence. More significantly, CASA can vary, suspend, or cancel the aircraft’s certificate of airworthiness or registration. Enforcement actions can include directions to ground the aircraft, infringement notices, enforceable voluntary undertakings, or prosecution. CASA also has the power to issue a direction under section 20B of the Act to prevent an aircraft from flying if it considers the aircraft to be unsafe. The practical enforcement mechanism is often the requirement for the maintenance release to remain valid: an aircraft cannot be operated without a current maintenance release, and the release must certify that all applicable ADs have been complied with. Aircraft operators rely on approved maintenance organisations to track AD compliance and sign off. If the maintenance organisation detects non‑compliance, it will refuse to release the aircraft. This creates a market‑based enforcement effect - insurers, financiers, and lessees also require proof of AD compliance. The Directive’s delegated enforcement framework also references the FAA: later revisions of service bulletins are acceptable only if the FAA approves them as AMOC to FAA AD 2009‑08‑01. In effect, CASA delegates approval authority to the FAA for this specific purpose. If a later revision is not FAA‑approved, it cannot be used even if it is technically superior. This reduces flexibility for Australian operators who might otherwise pursue an engineering solution directly with CASA. The costs of non‑compliance extend beyond fines: an incident involving the unsafe condition could lead to civil liability, loss of insurance coverage, and reputational damage. CASA also publishes a list of non‑compliant aircraft and may refuse export certificates of airworthiness. The Directive imposes strict deadlines (14 days for identification and AFM revision; 12 months for software upgrade), so even a short delay exposes the operator to enforcement. There is no grace period or de minimis threshold. The likelihood of detection is high because maintenance organisations must verify AD compliance as part of scheduled inspections. The economic incentive to comply is strong: the cost of the software upgrade is likely less than the expected enforcement penalty plus the risk of grounding. However, for small operators with infrequently flown aircraft, the 14‑day deadline may be missed inadvertently, leading to a non‑compliance that is technically minor but still a breach.

This Directive is made under the delegation from the Civil Aviation Safety Authority (CASA), which itself derives its powers from the Civil Aviation Act 1988 (Cth) and the Civil Aviation Safety Regulations 1998 (CASR). Specifically, Division 2 of Part 21 of CASR (or the equivalent provisions at the time) authorises CASA to issue Airworthiness Directives as a means of mandating corrective action for unsafe conditions. The Directive explicitly references the corresponding FAA Airworthiness Directive: FAA AD 2009‑08‑01 Amdt 39‑15874. This reflects the bilateral agreement between Australia and the United States on airworthiness certification - typically, CASA will adopt FAA ADs for aircraft originally certified in the US, sometimes with modifications. The Directive states that later revisions of the service bulletins are acceptable only if approved by the FAA as an Alternate Method of Compliance to FAA AD 2009‑08‑01. This cross‑references the foreign AD and makes Australian compliance dependent on US approval. It also means that if the FAA amends its AD, the Australian AD may need to be amended separately to recognise the change. The Directive itself must be kept current. The Directive also interacts with the Airworthiness Bulletin system and with maintenance regulations under CASR Part 42 and 145. The aircraft’s maintenance program must incorporate the AD, and the maintenance organisation must have the appropriate approvals (e.g., for software modification, which is a design change). The software upgrade likely requires a certified maintenance organisation (CAMO or AMO) with capability for avionics modifications. The AFM revision interacts with the aircraft’s flight manual approval basis; inserting Appendix A is a temporary revision that must be accepted by CASA or by an authorised person. For aircraft operated under an Air Operator’s Certificate (AOC), the operator’s exposition must reflect the procedures for incorporating ADs and AFM revisions. The Directive also affects insurance law: standard aviation hull and liability policies typically require the aircraft to be maintained in an airworthy condition and in compliance with all ADs. Failure to comply could void coverage. In a leasing context, both the lessor and lessee must ensure compliance; the lessor may retain residual risk. The Directive may also have implications for export: if an aircraft is sold to a foreign operator, evidence of compliance with all CASA ADs is required for a Certificate of Airworthiness for Export. No state or territory consumer laws apply to this specific instrument, but general tort law could apply if a failure to comply leads to an accident. The Directive does not replace or override other CASA requirements, such as the obligation to have a maintenance release, but it adds a specific mandatory action. There is no conflict with workplace health and safety laws, though the software upgrade may require licenced aircraft engineers and compliance with handling procedures. The Directive also references Honeywell proprietary service information; the operator or maintenance organisation must purchase or access those documents. This creates a private‑sector dependency within the regulatory framework. Finally, the Directive’s reference to “Alternate Method of Compliance” is a concept found in the International Civil Aviation Organization (ICAO) Annex 8 and is consistent with global practice. However, the specific requirement that the AMOC must be FAA‑approved limits the Australian operator’s ability to use a locally developed alternative without FAA endorsement, which may add cost and delay.

The source text is AD/FMS/3 Amdt 1, which is an amendment to the original issue of AD/FMS/3. The original issue became effective on 18 April 2007. The original directive required identification of affected computers and, if necessary, a temporary revision to the AFM Limitations Section. It did not require a permanent software upgrade; the manufacturer was still developing a fix. This Amendment 1, effective 4 June 2009, continues those original requirements and adds a new requirement 3: the terminating action of a software upgrade. It also expands the applicability to include the IC‑800E integrated avionics computer (the original covered only IC‑800). It removes the Hawker 800XP and 1000 models from the list of possible affected aeroplanes. This removal reflects that Honeywell determined those models do not actually have the affected computers or software levels. The Amendment also updates the compliance times: for requirements 1 and 2, the original directive likely had similar 14‑day compliance, but the effective date shifts. For requirement 3, the 12‑month period is new. The Amendment introduces Table 1 specifying the ASBs to use for the upgrade. It also includes a provision that actions done before the effective date using Honeywell SB 7017300‑22‑A6112 (original, June 2007) are acceptable for the IC‑800/IC‑800E upgrade. That grandfather clause prevents operators from having to redo an upgrade already performed using the older service bulletin. The Amendment also adds Note 3 referencing FAA AD 2009‑08‑01. The background section explains that the original was an interim action and this Amendment provides the terminating action. The effective date of 4 June 2009 is given plainly. The instrument is signed by James Coyne as a Delegate of CASA on 24 April 2009. The original was effective 18 April 2007 - a gap of about 26 months. During that time, operators were required to operate under the AFM restriction. The Amendment does not alter the applicability for the original computers; it simply adds IC‑800E and removes the two Hawker models. The Amendment also makes clear that after the software upgrade, the AFM revision may be removed - terminating the interim measure. There is no provision for a later Amendment 2 in the source text. The AD number is AD/FMS/3, suggesting it is the third FMS‑related AD; amendment 1 is the first change. The absence of further amendments might imply that the software upgrade resolved the condition and no further action was needed, but we cannot assume that. The amendment history is evidence of a staged regulatory response: first an immediate warning, then a permanent fix once the manufacturer produced it. This is a common pattern in ADs for software‑related unsafe conditions. The timeline - notice to warn (2007) followed by a fix two years later (2009) - reflects the typical lag time for software certification and fleet implementation. The removal of Hawker 800XP/1000 also shows that the initial applicability was too broad and was refined based on later data.

The source text does not mention any litigation history. Airworthiness Directives are rarely the subject of court litigation in Australia. Challenges to CASA decisions, including AD amendments, are possible under the Administrative Decisions (Judicial Review) Act 1977 (Cth) or under the Civil Aviation Act itself, but they are uncommon because ADs are based on technical safety findings and the cost of challenging an AD is usually higher than complying. Moreover, the Collins‑class submarine affair and other aviation cases show that courts defer to CASA’s technical expertise. The FAA AD 2009‑08‑01 may have been challenged in US courts, but that is beyond the scope of this source. The Directive itself contains a technical error: it references “appendix A” of the newsletter, but does not reproduce it; any ambiguity in the newsletter text could theoretically be challenged, but no cases are cited. The removal of Hawker 800XP and 1000 from applicability suggests that the original inclusion may have been challenged by operators who argued their aircraft did not have the affected computers, leading to the revision. However, the source does not confirm litigation; it could have been simply a technical correction. There is also a possibility of tort litigation following an accident involving the unannunciated position shift if an operator failed to comply. The failure to comply with the AD would be relevant to negligence and breach of statutory duty. But no such case is referenced. The Directive itself creates a duty of care, and a court could use non‑compliance as evidence of negligence. Given that the AD is mandatory, a plaintiff in a personal injury or property damage claim would likely point to non‑compliance as causation. However, there is no reported Australian case specifically on this AD. The economic analysis suggests that the litigation risk is low because compliance costs are relatively low compared to the potential liability, incentivising compliance. The lack of litigation also reflects the technical nature of the requirement: it is hard to argue that the software upgrade is not necessary when the FAA and CASA have identified the unsafe condition. The only plausible ground for judicial review would be if an operator claimed that the AD was beyond power or that the unsafe condition did not exist on their specific aircraft. But such challenges have a high bar. In summary, the litigation history for this specific AD is nil; it is a routine safety directive that operators accept as a cost of doing business.

Several details in the Directive can trap an unwary operator or maintenance organisation. First, the applicability is not limited to the list of airframe models in Note 1. The text says “known to be installed on, but not limited to” those types. An operator of an aircraft not listed must still check if their computers match the part numbers and software levels in the newsletter. A Hawker 800XP was removed from the list, but an early series 800A that had been upgraded with an IC‑800E after the list was drawn up could still be affected. The only safe approach is to physically check the computer part numbers. Second, the 14‑day compliance for requirements 1 and 2 runs from the effective date of 4 June 2009. That is a narrow window. The operator must obtain Honeywell Technical Newsletter A23‑6111‑008, Revision 001 - a document that may not be readily available. The newsletter is not a free publication; operators may need to purchase it from Honeywell or get it from the airframe manufacturer. The 14 days include time to identify the procurement source and receive the document. Third, for requirement 2, the AFM revision may be accomplished by “inserting a copy of Appendix A of the newsletter into the AFM.” This is permissive, but the operator must still ensure that the AFM is legally revised - meaning the revision must be recorded in the AFM status page, and copies must be placed in each required flight manual aboard the aircraft. Simply inserting a loose sheet without proper AFM revision procedures may violate the airworthiness requirements. Fourth, for the software upgrade (requirement 3), the Directive lists three different ASBs for the NZ‑2000 NAV computer: ASB 7018879‑34‑A6060, Revision 001; ASB 7018879‑34‑A6062; and ASB 7018879‑34‑A6063. The operator must select the ASB specific to their computer configuration. Using the wrong ASB could result in an incorrect software load. The Directive does not cross‑reference the applicable hardware configuration to each ASB; the operator must consult the service documents to match them. Fifth, the grandfather clause for actions done before the effective date applies only to the IC‑800/IC‑800E upgrade performed in accordance with Honeywell Service Bulletin 7017300‑22‑A6112 (the original, dated 22 June 2007). It does not grandfather actions done using a later revision (e.g., Revision 001 of the ASB) before the effective date, but those would likely be acceptable anyway. However, actions done using an incorrect or older revision not listed could be rejected. Sixth, the Directive states that later revisions of the listed service bulletins are acceptable only if approved by the FAA as an AMOC to FAA AD 2009‑08‑01. This means an operator cannot use a later revision that simply appears on the market; they must verify that the FAA has specifically approved it for the AD. That approval may be documented in a separate FAA letter. Seventh, the removal of the AFM revision after the software upgrade is optional, not mandatory. If the operator leaves the revision in place, there is no penalty, but it adds clutter. However, if the revision contains limitations that are no longer applicable, it could confuse the crew. Eighth, the compliance period for the software upgrade is 12 months, but that may be tight if the upgraded software needs to be certified, procured, and installed across a fleet. The operator must plan the upgrade to avoid the last minute. Ninth, the Directive does not specify record‑keeping requirements, but the maintenance records must document the identification check, the AFM revision insertion, and the software upgrade. Failure to document properly could lead to a finding of non‑compliance during an audit. Tenth, the Directive is an amendment; the original issue had its own compliance times, and some operators might have already done the AFM revision. They must ensure that the AFM revision is still current and not removed prematurely. Finally, the Directive does not address the cost of the upgrade; operators bear all expenses. There is no government subsidy or reimbursement. The economic gotcha is that smaller operators may find the cost of the software upgrade disproportionate to the aircraft’s value and may consider retiring the aircraft rather than upgrading. The Directive thus has an unintended consequence of accelerating fleet retirement, which may have environmental and economic effects.

Compliance with AD/FMS/3 Amdt 1 requires a step‑by‑step approach that should be documented in the aircraft maintenance records. Step one: before the expiry of 14 days from 4 June 2009 (i.e., by 18 June 2009), obtain Honeywell Technical Newsletter A23‑6111‑008, Revision 001, dated 22 February 2007. This newsletter contains the list of affected part numbers and software levels, as well as Appendix A for the AFM revision. The newsletter can be ordered from Honeywell or accessed through the airframe manufacturer’s technical publications. Step two: inspect each installed NZ‑2000 navigation computer and IC‑800/IC‑800E integrated avionics computer. Record the part number and software modification level (found on the unit label or in the aircraft logbook). Compare these against the newsletter’s list. If any unit matches, the aircraft is an affected aeroplane. Step three: within the same 14‑day period, for each affected aeroplane, revise the Limitations Section of the applicable Aircraft Flight Manual (AFM). The revision must incorporate the information in Appendix A of the newsletter. The simplest method is to insert a clean copy of Appendix A into the AFM, but the operator must ensure this insertion is recorded in the AFM revision status page, and that all copies of the AFM aboard the aircraft and on the ground are updated. The revision should be dated and signed by an authorised person (e.g., a licenced aircraft maintenance engineer or an airworthiness review staff member). Step four: within 12 months of 4 June 2009 (i.e., by 4 June 2010), perform the software upgrade. For the IC‑800/IC‑800E, use Honeywell Alert Service Bulletin (ASB) 7017300‑22‑A6112, Revision 001, dated 7 February 2008. For the NZ‑2000 NAV computer, identify which of the three ASBs applies: 7018879‑34‑A6060, Revision 001; 7018879‑34‑A6062; or 7018879‑34‑A6063. The ASB will specify the parts, tools, procedures, and software media required. The upgrade must be performed by an approved maintenance organisation with the appropriate avionics capability. After the upgrade, test the system to verify the correct software is installed and that the unsafe condition is resolved. Step five: update the aircraft maintenance records to reflect the software upgrade. Include the ASB reference, the software part numbers installed, and the date. Step six (optional but recommended): remove the AFM revision that was inserted in step three. The Directive explicitly permits removal after the software upgrade is completed. The removal should be documented as a further AFM revision. If the operator leaves the revision in, it may cause confusion, but it is not non‑compliant. For operators who have already performed an IC‑800/IC‑800E upgrade before 4 June 2009 using Honeywell SB 7017300‑22‑A6112 (the original, June 2007), that action is acceptable for compliance with requirement 3. They need only verify that the upgrade was done correctly and record it. For operators who have later revisions of the ASBs (e.g., Revision 002), they must check whether the FAA has approved that revision as an AMOC to FAA AD 2009‑08‑01. If so, they may use it; if not, they must use the revision listed in the Directive or obtain separate approval from CASA. Operators should maintain a compliance log for this AD, including the date of identification, the AFM revision number, the ASB used, and the date of software upgrade. This log will simplify future audits by CASA or the maintenance organisation. Finally, if the operator has any doubt about the applicability, they should contact the airframe manufacturer’s technical support or Honeywell for clarification. The economic cost of compliance includes the purchase of the newsletter (perhaps a few hundred dollars), labour for the identification and AFM revision (a few hours), and the software upgrade (cost of software media, parts if needed, and labour - potentially several thousand dollars per aircraft). For a multi‑aircraft fleet, the cost may be significant but is likely lower than the risk of grounding or accident. The key to cost‑effective compliance is to perform the identification and AFM revision promptly and to schedule the software upgrade during routine maintenance downtime to minimise additional aircraft unavailability.