Structural Usage Monitoring and Flight Regime Recognition

1
Structural Usage Monitoring and Flight Regime
Recognition

• Presented by
• Richard P. Anderson, Ph.D., ATP
• Assistant Professor
• Embry-Riddle Aeronautical University
• Daytona Beach, Florida
• June 7th, 2007

2
The Team

• Richard Pat Anderson, ERAU, PI
• Andrew Kornecki, Ph.D., ERAU, Computer and
  Software Engineering
• Rachel Rajnicek, ERAU graduate student in
  Aerospace Engineering
• Two undergradute students in Aerospace
  Engineering with Computer Science background
• Systems and Electronics, Inc. (SEI), industry
  partner
• Embry-Riddles Eagle Works, flight-test facility

3
Objectives and Goals

• The objective of this contract is to move a HUMS
  system for Usage Monitoring (UM) from a
  technology readiness level of 6 (system/subsystem
  prototype demonstration) to level 8 (operational
  qualified through test and demonstration).

The desired maintenance credit is the elimination
of the 100hr inspection tail rotor balance (TB)
on a reciprocating helicopter (Schweizer 300) and
a turbine helicopter (Bell 206) through the use
of an onboard monitoring system and associated
ground station.
4
Objectives and Goals

• In this case, the core prototype is SEIs
  Structural Integrity Monitoring System (SIMS).
• The final (three year) goal is perform a mock
  qualification of a variant of the SIMS, through
  test demonstration and validation, for UM under
  the guidance of AC-29-2C MG-15.

5
Required Tasks
Year 1
Year 2
Year 3
System Requirements Document
Conformity Report and supporting documents
Hardware/Software Requirements Document
Installation and Flight Testing of system in Bell
206 and S-300
System Test Requirements Document
Data set of flight test results
Contractor and HUMS manufacturer's software
change report
Technology Transfer Plan
A complete HUMS prototype system
Validation of structural UM/FRR algorithm
6
Preliminary HUMS System Hazard Assessment Report

• Top level system architecture feasibility study
• Preliminary HUMS system hazard assessment.
• Rationale for a Level D system with statistical
  database.
• A description of airborne and ground based
  systems and UM.
• A description of the online, offline, and
  diagnostic functions that need to be performed by
  the HUMS.
• A description of the types of inaccurate data as
  well as ways to detect and mitigate this data.
• Fault tree analysis showed the types of
  undercounts and mitigations for these undercounts.

7
Architecture Configuration of a HUMS Prototype
System

• The proposed initial system includes a single
  modified SEI SIMS. This system will include
  Data Acquisition and Processing Unit (DAPU), a
  Data Storage Unit (DSU), a Cockpit Display Unit
  (CDU) and various transducers.

The ground system will use a Commercial-Off-The-Sh
elf (COTS) PC running a standard commercial
operating system and a Data Transfer Interface
Unit (DTIU)
8
Aircraft Level Functional Hazard Assessment Report
A major source of data loss is digital
conversion, quantization (larger than
computed data drop out and errors.
From an end-to-end perspective, there are
sufficient mitigation processes that can be
put in place to insure equivalent levels of
safety for usage credits.
This analysis showed that a single SIMS will be
sufficient in a UM role for production
HUMS. This FHA continued support Level D
assurance for HUMS UM.
9
Methodologies for addressing data collection
discrepancies and compromised data integrity
Methodologies were developed for determining and
mitigating both in-flight and ground data drop
outs, discrepancies, faults and errors.
Some methodologies will check data ranges and
computer integrity. Other methodologies
depend upon an end-to-end testing and initial
statistical comparisons.
10
Report on assessment of applicable technologies

• The SEI SIMS was analyzed with respect to use in
  this application. It was found that although
  there will be substantial software modifications
  required, there are no showstopper with respect
  to using this basic system.
• The required changes are specified after a system
  requirements document has been generated.

11
Road map from applicable technologies to a
changes document
12
System Requirements Document

• Top level system requirements for a HUMS to
  eliminate the 100hr inspection TRTB include
• Nine general requirements which may not be
  explicitly testable and include The HUMS must be
  AC-29 MG-15 compliant and the HUMS must be
  compatible with the selected rotorcrafts for UM.
• Sixteen onboard subsystem requirements which are
  explicitly testable and include the nominal
  sample rate (6Hz) and display messages.
• Nine ground subsystem requirements which are
  explicitly testable and include a way to
  download the airborne data from the portable
  storage unit and criteria for FRR.

13
Parameters and Sensors
14
Hardware/Software Requirements Document

• Top level hardware requirements for a HUMS to
  eliminate the 100hr inspection TRTB include
• Seven certification requirements which may not be
  explicitly testable and focus on AC-29 MG-15
  hardware compliance requirements.
• Fifteen onboard subsystem requirements which are
  explicitly testable and include the type of
  connectors utilized for onboard processing and
  storage units and data channel requirements.
• Seven ground subsystem requirements which are
  explicitly testable and include interface
  requirements for the COTS PC as well as the type
  of connectors for the transfer unit.
• Top level software requirements for a HUMS to
  eliminate the 100hr inspection TRTB include
• Twenty three onboard subsystem requirements which
  are explicitly testable and include timing and
  functionality requirements as well as onboard
  software modes.
• Nineteen ground subsystem requirements which are
  explicitly testable and include ground software
  memory capacity requirements and data transfer
  rate requirements.

15
System Test Requirements Document

• Top level system test requirements for a HUMS to
  eliminate the 100hr inspection TRTB include
• One end-to-end test case covering the operation
  of the HUMS from onboard power on and data
  collection to ground system comparison of the
  recorded data to the supplied data.
• Twelve onboard subsystem test cases which include
  testing of real-time display message, parameter
  recording and saving, and component communication
  failures.
• Seven ground subsystem test cases which include
  testing of data download and erasure, FRR
  algorithm confirmation, and failed storage unit
  communication.

16
Contractor and HUMS manufacturer's software
change report

• Top level change requirements for a HUMS to
  eliminate the 100hr inspection TRTB include
• Fourteen onboard subsystem changes which include
  fixing the sample rate to 6Hz, defining the
  START/STOP recording criteria, and including
  specific RS-232 communications.
• Two ground subsystem which include updating the
  Engineering Unit Program to meet the specific
  calibration and conversion factors required for
  the sensors utilized and updating the
  time-to-next inspection functionality.

17
Project Review Year 1

• In the first fiscal year beginning October 1st,
  2005 three intermediate reports were completed.
• The first report, Preliminary Functional Hazard
  Analysis End-to-End HUMS Component Level
  Assurance Determination Methodology, focused on
• Preliminary HUMS system hazard assessment.
• Rationale for a Level D system with statistical
  database.

18
Project Review Year 1

• The Preliminary Functional Hazard Analysis
  End-to-End HUMS Component Level Assurance
  Determination Methodology report included
• A description of airborne and ground based
  systems and UM.
• A description of the online, offline, and
  diagnostic functions that need to be performed by
  the HUMS.
• A description of the types of inaccurate data as
  well as ways to detect and mitigate this data.
• Fault tree analysis showed the types of
  undercounts and mitigations for these
  undercounts.
• Life limiting rationale, a mathematical proof
  that a Level D HUMS can monitor flight critical
  components.

19
Project Review Year 1

• The second report, Preliminary Functional Hazard
  Analysis End-to-End HUMS Hardware Software
  Architecture, focused on
• End-to-End HUMS hardware and software
  architecture.
• Modified aircraft level Functional Hazard
  Assessment (FHA).
• Methodologies for addressing data collection
  discrepancies and compromised data integrity.
• Methodologies for electronically tracking
  rotorcraft components.

20
Project Review Year 1

• The Preliminary Functional Hazard Analysis
  End-to-End HUMS Hardware Software Architecture
  report included
• A detailed description of the airborne subsystem
  hardware and software architectures.
• A detailed description of the ground based
  subsystem hardware and software architectures.
• A modified aircraft level FHA including fault
  tree analysis.
• A description of the electronic tracking required
  including component tracking and statistical
  databases.
• A brief system compliance assessment illustrating
  that AC-29, DO-254, and DO-178B compliances must
  be shown.

21
Project Review Year 1

• The third report, Rotorcraft Structural Usage
  Monitoring Compliance Assessment, focused on
• Assessment of applicable UM and Flight Regime
  Recognition (FRR) technologies.
• Strategies for refining and implementing the
  UM/FRR technologies selected for the project.
• Strategies for validating the selected UM/FRR for
  the project.

22
Project Review Year 1

• The Rotorcraft Structural Usage Monitoring
  Compliance Assessment included
• A detailed AC-29-2C-MG-15 compliance assessment
  that illustrated no show stoppers with the SEI
  SIMS.
• A description of the desired maintenance credit,
  eliminating the 100hr inspection TRTB.
• A detailed strategy for refining the SEI SIMS for
  full AC-29-2C-MG-15 compliance including credit
  validation, independent verification, and
  continued airworthiness.
• Detailed strategies for implementing and
  validating the SEI SIMS and usage credits for
  eliminating the 100hr inspection TRTB.

23
Project Review Year 2

• In the Second fiscal year beginning October 1st,
  2006 two additional reports have been completed.
• The fourth report, Annual Technical Report,
  focused on
• Summarizing the year one progress through October
  2006 .
• The Annual Technical Report included
• Level D Life Limiting Rationale completed
  February 2006.
• Compliance Assessment performed September 2006.
• A preliminary HUMS verification plan completed
  October 2006.

24
Project Review Year 2

• The fifth report, Structural Usage Monitoring
  Refinement and Testing Assessment, focused on
• An assessment of applicable technologies and
  strategies for refining, implementing, and
  validating the selected UM/FRR.
• Specifications for FRR algorithm refinement.
• Contractor and HUMS manufacturers software
  change report.
• Results of benched tests of refined algorithm and
  software for UM/FRR.

25
Project Review Year 2

• The Structural Usage Monitoring Refinement and
  Testing Assessment included
• A project review from December 2006 until May
  2007.
• Change requirements for the SEI SIMS to be used
  for elimination of the 100hr inspection TRTB.
• SIMS verification plan including detailed test
  cases.
• SIMS requirements including the System,
  Hardware, and Software Requirements Documents.
• SIMS testing reports including SEI First Article
  SIMS Testing procedures and Radiometrics Midwest
  Corp DO-160 SIMS tests.

26
Project Status

• The first year AC-29 compliance assessment
  demonstrated that there are no show stoppers with
  the SEI equipment.
• The team has completed the top-level system,
  hardware, and software requirements for
  eliminating the 100hr inspection TRTB. The
  hardware and software requirements were derived
  from the system requirements. Analysis showed
  that there are no top level show-stoppers in the
  use of a modified SEI SIMS.
• The DAPU, DSU, and DTIU were received in Jan/Feb
  2007. The DAPU and DSU have been sent back to SEI
  for firmware updates as per the changes required.
  
• The CDU and TRVMS were ordered in May 2007 and
  will receive firmware updates prior to the July
  2007hardware delivery.
• The other transducers needed have been ordered
  and will be at ERAU for the Summer 2007 in-house
  bench testing.

27
Project Status

• The team has just completed the change
  requirements. The change requirements include
  hardware and software changes for the SIMS and
  ground station. No show stoppers were found as
  the change requirements were completed.
• The change requirements were completed after a
  team visit to SEIs facility in Illinois to
  observe the operation and testing of the SIMS.
  The change requirements include changes required
  by the ERAU team as well as changes needed by
  SEI. These changes show that SEIs software and
  equipment still has no show stoppers and will be
  ready for ERAU in-house testing in July 2007.
• The team has also just completed a verification
  plan with test cases. The verification plan and
  requirements documents were used to develop
  detailed test cases for the end-to-end, onboard,
  and ground portions of the HUMS.

28
Next Phase

• The next phase of this contract (June 2007) is
  the development of a complete HUMS prototype
  system, airborne and ground units, with a
  selected algorithm/software for flight test.
• The project will continue with bench testing and
  flight testing once the updated hardware and
  software are received. The bench testing will
  begin Summer 2007 and the flight testing phase
  will begin in Fall 2007.
• The ERAU bench testing will confirm the SEI bench
  tests and verify the SIMS changes are effective.
  Flight testing will be done to verify the SIMS as
  well as the FRR algorithm and gain sample flight
  data.