Go Back  PPRuNe Forums > Flight Deck Forums > Tech Log
Reload this Page >

AF 447 Thread no. 4

Tech Log The very best in practical technical discussion on the web

AF 447 Thread no. 4

Old 2nd Jul 2011, 16:53
  #661 (permalink)  
 
Join Date: Jan 2008
Location: Blighty (Nth. Downs)
Age: 73
Posts: 2,091
Dozy Wanabee,

Sorry, and I couldn't find where you'd said it either. Guess you were misquoted.

Re the THS trimming. It occurred while the aircraft was in a semi-parabolic trajectory, having run out of lift. So G was well below 1.0, and stick was neutral or back, therefore commanding 1G or more. In the absence of high-AoA protections, I don't understand your problem. The up-elevator delivered by the EFCS would be backed up by THS movement. By the way, I cannot claim to be the originator of this simple theory.
Chris Scott is offline  
Old 2nd Jul 2011, 17:03
  #662 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,182
Originally Posted by RR_NDB View Post
The worst case scenario is just one failing?
Well, the worst-case scenario where the automatics can continue to function is, yes, because a software-driven triple-redundant quorum can only be effective if two components are working correctly (in this case giving readings within the acceptable tolerance range)

I've moved your quoted post around a bit so that my reply can deal with the questions properly - hope you don't mind.

Question (yet posted earlier): Why they put this redundancy? For what reason? What benefit?
Simple - as has always been the case, computers are better than humans when it comes to monotonous, repetitive tasks like comparing readings in a data stream. A computer will be much quicker at flagging a pitot failure problem specifically than a human will be able to. Compare the previous generation's B757 - classic triple redundancy with the flight computers linked to a single air data input at any one time - where, originally, the first warning you got was "MACH TRIM - RUDDER RATIO". This is logical in terms of the systems engineering, but to a pilot the message could be confusing. They later added an "AIRSPEED DISAGREE" warning if I recall correctly.

Redundancy is "powerful" when critical elements do not fail simultaneously. And UAS cases show clearly simultaneous "failing" (due product limitation)

Simultaneous "failure" of critical elements should be reported immediately.
They were, and there was a service bulletin in effect to replace the components (along with pilot information to assist recovery from the issue) - unfortunately the airframe that became AF447 had not been taken into MX for that fix yet.

@Chris Scott re: misquoting, no problem. The problem I have is how the system would attempt to calculate G-loading in this scenario. The whole design ethos seems to have been based around making sure that the computers did not interfere if any data was missing, because at that point the pilot is best suited to keeping the shiny side up. Of course, even if this was the case, you've got 3 ADIs in front of the crew telling them they're too nose high, so why is the stick neutral or back? IMO this is the 300-pound gorilla in the room that the people who want to blame the aircraft are wilfully ignoring.
DozyWannabe is offline  
Old 2nd Jul 2011, 17:26
  #663 (permalink)  
The Analog Kid
 
Join Date: Aug 2004
Location: Brecon Beacons National Park
Age: 53
Posts: 239
PA 18 151, sorry old bean but you said:

the evidence released by the BEA says the time between autopilot disconnect and recognition by the crew ("lost the speeds/alternate law") was 9 seconds.
Whereas the report says:

From 2 h 10 min 05, the autopilot then auto-thrust disengaged and the PF said "I have the controls".
i.e. straight away. The way you've phrased the quoted statement it comes across that you're interpreting "lost the speeds/alternate law" as recognition of AP disconnect, whereas it seems more likely that it's, again, immediate recognition of the latching of ALT2 at the end of the much-discussed monitoring period.
fyrefli is offline  
Old 2nd Jul 2011, 17:38
  #664 (permalink)  
 
Join Date: Aug 2009
Location: Brussels
Age: 68
Posts: 10
AoA and AS

To Gallerypower #632. Very interesting. Although, correct me if I'm wrong, it seems AoA is of paramount importance in these instances, and it is not directly available to the pilots on AB machines ?

To DozyWannabe #657. OK, AS is derived from 3 pitot tubes that could lead to problems if two of them are wrong but close enough to be taken as valid. Then why not compare AS history with GPS derived speed (history) together with thrust/attitude. I mean : compare the trends. If the plane is level flight, if thrust is not changed (even in turbulent weather) and a dire discrepency is noted (IAS significantly increasing/falling while GPS speed no change) wouldn't that be the case that AS should be highly suspected to be wrong ?

I don't mean the A/C should do something with that ! But the pilots might be warned.
vbp.net is offline  
Old 2nd Jul 2011, 18:09
  #665 (permalink)  
 
Join Date: Jan 2008
Location: Blighty (Nth. Downs)
Age: 73
Posts: 2,091
Dozy Wanabee, quote:
The problem I have is how the system would attempt to calculate G-loading in this scenario.
Not sure exactly what you mean by "calculate", but if not fully capable how could it offer Pitch-Alternate Law?
Chris Scott is offline  
Old 2nd Jul 2011, 18:44
  #666 (permalink)  
 
Join Date: Aug 2009
Location: Germany
Age: 63
Posts: 1,809
Cool

Hi,

DozyWannabee
The thought of two or more failing was thought to be exceptionally remote
be exceptionally remote

A short one ...
Put 3 fingers in water .. they will be all wet

Thales AA pitot probes in foul weather conditions with the voting logic of the FCU and FMC didn't raise its head until a decade later, and they've been trying to fix it since.
Airbus. December 1995 TFU 34.13.00.005: STRONG CUMULO-NIMBUS (Cb) CONTAINING A HIGH DENSITY OF ICE CRYSTALS CAN BEEN ENCOUNTERED, PARTICULARLY IN THE INTERTROPICAL CONVERGENCE ZONE (ITCZ). IN SUCH AN ICY AND TURBULENT ATMOSPHERE, THE A/C AIR DATA PARAMETERS (PRESSURE DEPENDANT) MAY BE SEVERELY DEGRADED, EVEN THOUGH THE PROBE HEATERS WORK PROPERLY. IT HAS APPEARED THAT THE CHARACTERISTICS OF SUCH AN ENVIRONMENT COULD EXCEED THE WEATHER SPECIFICATIONS FOR WHICH THE PITOT PROBES ARE CURRENTLY CERTIFIED.

January 1999. Report BFU accident 5X002-0/98 : The specification for the pitot tubes should be changed so as to allow unrestricted flight operations in heavy rain and under severe icing conditions. The installation of the improved pitot tubes already designed should subsequently be prescribed for all types concerned by the SIL no. 34-0147 (A 320, A 321, A 330, A 340).
jcjeant is offline  
Old 2nd Jul 2011, 19:41
  #667 (permalink)  
 
Join Date: Mar 2010
Location: South Korea
Age: 59
Posts: 119
The Interface

My first post, please be nice to me. I am not a pilot or an aeronautical engineer but I am an electrical engineer who deals in automation that can kill people if it goes wrong, such as transporting 150ton crucibles of molten steel around steel mills. I prefer to read the intelligent and enlightening discussions here than listen to some of our other sources of "entertainment".

There is lots of talk about the man-machine interface. What is the man machine interface? The machine is ideal for multiple repetitive monotonous, tasks. The human works best with minimal tasks at once, 2 or 3 tasks at once is ideal, 4-5 max. A machine can only perform tasks that it has been programmed to do. A human trained in the basic and fundamental technologies of his job can make decisions based on this training without ever having encountered or trained on the scenario in the past. So if the machine encounters a scenario that it is not programmed to deal with, it should naturally pass it over to the human. However the designer and programmers are responsible for passing it over in a format that can be easily handled by the average person. Ie a maximum of 5 tasks. Monitoring the planes speed, AOA, Multiple ECAM messages, A WOOP WOOP STALL, an auto pilot kicking out, a change in handling characteristics, changing trim settings etc. It seems excessive to me.

If one of my designers or programmers came up with such a scenario I would sit down with him and explain to him the situation as I have mentioned above and tell him to go back and redesign the system or rewrite his code.
Cool Guys is offline  
Old 2nd Jul 2011, 19:49
  #668 (permalink)  
 
Join Date: Jun 2009
Location: somewhere
Posts: 451
CONF iture:

If the ADR disagreement disappears, ALT2 is still latched, but in my understanding, AoA protection can be back
Edit: NOT Confirmed! (did read AOA stall warning i.s.o. protection)

Stall Warning:
If CAS <60Kts AOA = set to 0 degrees and System status matrix (SSM) set to NCD.
(Changed to 30 Kts if 'BUSS' option is installed, this A/C did not had 'BUSS' installed)

When any CAS => 60 Kts (30 @ BUSS), highest AOA value is taken.

Add: Hi-AOA protection:

Cryptic to me:


AOA is still monitored but warnings relate now to stall speed (Vsw) rather than AOA, if in dual ADR Failure Low speed stability* is lost so is Vsw.
If VS1G cannot be calculated due to loss of weight or s/f position information then there is no AOA protection at all.

* Low Speed stability:

An automatic nose down command is introduced to increase speed. No reference to AOA, only speed. Operates 5 to 10 kts above stall warning depending on weight &
slat/flap configuration. The pilot can override.
"STALL" announces and crickets heard prior to stall speed being reached. PFD shows black and red barbers pole for stall warning speed. V-apha-prot and V-alpha-max are

replaced by Vsw (stall warning speed). No alpha-floor protection is available.


The nature of the automation by Airbus is about protection. How is it clear that it has saved many lives ?
That would be hard to prove as is in general.
This one would not have happened for sure, can't say about 5A-ONG (Tripoli). Are there any others? (besides Test flight)

Last edited by Jetdriver; 2nd Jul 2011 at 23:36.
A33Zab is offline  
Old 2nd Jul 2011, 20:57
  #669 (permalink)  
 
Join Date: May 2011
Location: BOQ
Age: 75
Posts: 489
What exactly does the flight control system do to provide AOA protection in ALT2?

Last edited by OK465; 2nd Jul 2011 at 21:08. Reason: flight control system vice flight controls
OK465 is offline  
Old 2nd Jul 2011, 21:21
  #670 (permalink)  
 
Join Date: May 2011
Location: BOQ
Age: 75
Posts: 489
Are you referring to low speed stability again being active when both ADR's are recovered?

Please explain to me FCS-wise what occurs as you approach stall AOA in ALT2 with both ADR's recovered.
OK465 is offline  
Old 2nd Jul 2011, 21:47
  #671 (permalink)  
 
Join Date: Jun 2009
Location: somewhere
Posts: 451
The Interface

Well there is task sharing and a few rules,

* PF Fly, Navigate & Communicate.
* PNF Manage failure on PF command.

* Secured, Guarded switches and Clear P/B to be confirmed before switching.
* PNF NEVER touches the T/L.
* Read out load all actions.

For handling:

Failure announcement:
- Attention getter Visual [Master Warning/Master Caution] Audible [ CRC/SC/Special (e.g. Fire Bell/Calvary)/Svoice (e.g. STALLSTALL)]
- Check ECAM (format SYS msg) in red or amber.
- Perform Crew actions (next line ident) in Cyan
System panels are uncluttered and identified by SYS (in white letters) on the side.
- Identify Amber FAULT P/B (Local warning)
- Call SYS, SELECTOR, PROCEDURE (e.g. NAV, ADR 1, OFF) before switching. (In general action clears appropriate crew action line on ECAM
- check action result on SD (if any)
If all crew actions performed:
- PNF CALL SYS CLEAR, PF CONFIRMS.
- Clear SYS or Emergency Clear on ECAM control panel.

Done!

Next warning (if any)

Warnings are displayed by priority top-down.

If you apply the rules even a guest B. pilot can do this.
A33Zab is offline  
Old 2nd Jul 2011, 21:49
  #672 (permalink)  
 
Join Date: Jun 2009
Location: florida
Age: 77
Posts: 1,200
Gee sensing for FBW systems

As with Chris, I too wonder what does Doze think the "system" uses to sense and use Nz.

I don't have the box specs in front of me, but I doubt that the confusers use the basic inertial and attitude system data for anything other than the plethora of "protections" and all the approach, cruise, climb, descent, flare and other stuff that enables a pinball wizard to fly the jet ( sorry for the rant).

The system likely uses its own accelerometers and rate sensors. That is the core of the entire flight control system, fer chissakes. No shabby sensors to freeze up, no cosmic autopilot or flight phase inputs, just the basics.

We tried various core principles 40 years ago. AoA, body rates, attitude, mixes of all..... The Nz control law is the one that allowed humans to fly the FBW systems when compared to older systems, and it was very easy to implement internally, without a lotta data inputs from the outside. A basic FBW system would only emulate the hydraulic pressures to the control surface actuators via servos. Big deal. Kinda sounds like the 'bus "direct law". However, we then had the opportunity to control deflection rates and total surface movement and such that we didn't have with the systems that went back to the early 1950's. We could also use a few bits of outside data like dynamic pressure and AoA to provide some "limits", not "protections". Could also use those bits of external data to keep the jet smoother and less susceptible to PIO's and overstress and STALL!!!! We could also adjust the lag of AoA and body rate inputs to make rolling into a turn smooth, but "freeze" the rate command more quickly when relaxing stick pressure. Same for pitch/gee.

For the life of me, I can't understand why the core principle for the 'bus is not an AoA versus Nz principle. A gee command that uses AoA to limit the gee command. So you can pull as hard as you want, but your command will be reduced when at an AoA limt. In other words, work back up from a well-defined control philosophy and add bells and whistles along the way. The existing system starts the other way, and it's hard to figure out what HAL decides is necessary or will do that the human does not anticipate or fully understands.

Same goes for the "gains" that go south when the sensors freeze up. Good grief, use a fixed value for "q" and keep HAL happy. If and when the air data comes back, the humans can enable it for a smoother ride and such. That is one feature lacking that I cannot fathom about the 'bus design. And that lack of feature seems to have played a role in several instances. AoA is a different story, and the design should have a sufficient bias by body rates to keep the jet flyable if the humans use airspeed as an aid, kinda like the old days.

sorry for the rant.....
gums is offline  
Old 2nd Jul 2011, 21:51
  #673 (permalink)  
 
Join Date: Jun 2009
Location: Germany
Age: 67
Posts: 782
ChrisScott
The warnings and their hierarchy are not so different from yours in principle. On current Airbuses, there is no WLDP (warning-lights display panel), but the system PBs (push-button switches) have an amber "FAULT" W/L built-in. (If a PB's normal position is on, it will show a white "OFF" warning when off. The handful that are normally in the off position, like wing anti-ice, have a blue "ON" light.
I think the warning systems are quite different. They are overloading and im also not happy with the detail of the warning, if a understand the events of AF447 correctly.

If the speed gets unreliable, i want to be informed about it when the information is available. No need to backtrack it and second guess it from other indications like disconect of autopilot and autothrust.

If the system reverts to another LAW, it should say exactly that.

The message "use man Pitch Trim" is weird as well. If i dont want to use it, im gonna disregard that message probably, becaue i anyway never used it before. So the trim stayed all the way nose up. Wouldnt a THS Full nose up warning be more appropriate?

The Warning logic seems to be a kind of advisory logic like do this and do that without stating the big WHY you should do it.

And concerning chimes and chords or bells, very nice if they come single, noisy when they come repetitive and useless when they are overloading when multiple systems fail. They are momentary as well, if you miss one, the info seems to be gone.

Pushbuttons with fault indications are nice, but do i see that correct, 60 lights distributed over 5 m cockpit space? How long does it take to check all in a night with adverse WX or on a day with bright sunlight?

Im not convinced that this system is to the best benefit of pilots in abnormal situations.
RetiredF4 is offline  
Old 2nd Jul 2011, 21:58
  #674 (permalink)  
 
Join Date: Feb 2008
Location: In the Old Folks' Home
Posts: 396
Trim System Factor

Dozy:
I may be contradicted by the report when it finally arrives, but it would not surprise me in the least to discover that what the trim system was doing didn't even factor into the troubleshooting mode (by which I mean mental model) they were in.
I agree that they didn't factor the trim system into their troubleshooting.

Because the trim system (following the sidestick input) held the nose up and kept the Angle of Attack in the stall range, the aircraft continued its plunge to the ocean.

Why didn't one of the pilots do something about that? It seems apparent that they didn't even notice it.

Why didn't they notice it? It wasn't in their scan because they apparently were trained not to touch the pitch trim wheel(s) since pitch trim is always automatic and since it's automatic, why would you care?

I continue to believe that autotrim should disconnect along with the autopilot. That way, there is no doubt who is in control. That is a pilot's perspective.

The next report will confirm whether or not the plane did just what the pilot(s) told it to do. The bigger question is why did they tell it to do that?

Last edited by Smilin_Ed; 2nd Jul 2011 at 22:24.
Smilin_Ed is offline  
Old 2nd Jul 2011, 21:59
  #675 (permalink)  
 
Join Date: Jan 2008
Location: uk
Posts: 808
Originally Posted by OK465 View Post
What exactly does the flight control system do to provide AOA protection in ALT2?
Nothing. There is no AOA protection outside of normal law.

PFD and speed scale changes to indicate this.

There is a stall warning based on AOA (if the plane thinks it has a valid AOA), but nothing else protecting AOA.
infrequentflyer789 is offline  
Old 2nd Jul 2011, 22:24
  #676 (permalink)  
 
Join Date: May 2011
Location: BOQ
Age: 75
Posts: 489
Nothing. There is no AOA protection outside of normal law.
Exactly.

Then why are some folks claiming it is available when both ADR's are recovered?

@RetiredF4:

When an ADR fails there is no doubt that airspeed is unreliable. The airspeed tape on the PFD is blanked (black) and all that remains is a big red speed flag.
OK465 is offline  
Old 2nd Jul 2011, 22:36
  #677 (permalink)  
 
Join Date: Oct 2009
Location: UK
Posts: 1,271
Hi Smilin_Ed,
I continue to believe that autotrim should disconnect along with the autopilot.
I agree. Unfortunately even the loss of stab autotrim won't return speed stability.

The aircraft has been designed to cope with the loss of B & Y Hydraulic systems (hence NO Stab trim). Despite no stabiliser movement, the elevators are powerful enough to control the aircraft from cruising speed to approach and landing. So even if the autostab trim was disabled (or the trim wheel held still by the pilots), the elevators would be repositioned automatically to maintain 1g stick free attitude stability.

Edit. B & Y corrected iaw CONF iture's post 689

Last edited by rudderrudderrat; 3rd Jul 2011 at 06:25.
rudderrudderrat is offline  
Old 2nd Jul 2011, 22:37
  #678 (permalink)  
 
Join Date: Aug 2005
Location: fl
Posts: 2,561
Originally Posted by OK465
What exactly does the flight control system do to provide AOA protection in ALT2?

Nothing. There is no AOA protection outside of normal law.

PFD and speed scale changes to indicate this.

There is a stall warning based on AOA (if the plane thinks it has a valid AOA), but nothing else protecting AOA.

So the PF with less than a year experience in the Airbus used full nose up SS with this knowledge???? Did he forget? Why did both pilots use full up pitch control if they knew they had no stall protection? All us conventional airline pilots know exactly what would happen. Exactly what their profile did putting them in a deep stall.

The initial report left all the important stuff out like if they pulled up and with frozen pitot tubes and static pressure dropping did they get an erroneous overspeed warning.

They must have a reason to keep this quiet but eventually they will have to tell us what really happened up there.
bubbers44 is offline  
Old 2nd Jul 2011, 22:53
  #679 (permalink)  
 
Join Date: Jan 2008
Location: uk
Posts: 808
Originally Posted by Smilin_Ed View Post
Dozy: I agree that they didn't factor the trim system into their troubleshooting.

Because the trim system (following the sidestick input) held the nose up and kept the Angle of Attack in the stall range, the aircraft continued its plunge to the ocean.
Wrong. Look at the timeline A33Zab (I think) posted a while back (post 379 - found it) - the elevators alone took them up to 15+deg pitch and right into stall, the trim followed later (as it is supposed to).

Had the auto trim done nothing, as far as I can see they would have stayed stalled all the way down from the elevator input.

Why didn't one of the pilots do something about that? It seems apparent that they didn't even notice it.

Why didn't they notice it? It wasn't in their scan because they apparently were trained not to touch the pitch trim wheel(s) since pitch trim is always automatic and since it's automatic, why would you care?
If trim is manual, why on earth would you trim nose-down and hold the stick hard back ?

If they had noticed the trim they would have noticed it was doing as asked - they were asking for full nose-up.

I think autotrim is a complete red-herring and a diversion form the real question (in terms of recovery from stall, not why they ended up there) which is why did PF pull stick hard back through 30s or more of stall warning. I have no answer to that, except to say that in the history of aviation accidents, he is not the only one, and we can't ask any of them "why".

I continue to believe that autotrim should disconnect along with the autopilot. That way, there is no doubt who is in control. That is a pilot's perspective.
Yet doing it that way has killed or nearly killed a lot of people already (schipol, perpignan, bournemouth...) - tyring to recover when the autos have trimmed full up (for whatever reason) and then stick forward doesn't overrider the trim. Based on that accident and incident history, pilots tyring to recover a (approach to or) stall don't always grasp the need to re-trim.

Look at the pilot action / trim possibilities:

Stick-forward, manual trim
- may not recover unless pilot re-trims, may not have pitch auth to override trim

Stick forward, auto trim
- best chance to recover, without need to re-trim, reducing workload in emergency

Stick backwards - no chance of recovery, whatever the trim does.

What should the a/c designer do ?
infrequentflyer789 is offline  
Old 2nd Jul 2011, 23:02
  #680 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 873
Interfacing issue

Cool Guys
There is lots of talk about the man-machine interface. What is the man machine interface? The machine is ideal for multiple repetitive monotonous, tasks. The human works best with minimal tasks at once, 2 or 3 tasks at once is ideal, 4-5 max. A machine can only perform tasks that it has been programmed to do. A human trained in the basic and fundamental technologies of his job can make decisions based on this training without ever having encountered or trained on the scenario in the past. So if the machine encounters a scenario that it is not programmed to deal with, it should naturally pass it over to the human. However the designer and programmers are responsible for passing it over in a format that can be easily handled by the average person. Ie a maximum of 5 tasks. Monitoring the planes speed, AOA, Multiple ECAM messages, A WOOP WOOP STALL, an auto pilot kicking out, a change in handling characteristics, changing trim settings etc. It seems excessive to me.
We dontt have yet the required information to be able to understand what really happened in AF447. During 2 years + diligent professionals are trying to "model" possible scenarios based on some reliable (scarce) pieces of information. The analysis being performed is trying to cover all aspects. The interface of a complex System as you know very well must be "simple enough" to allow a safe operation in all scenarios before or during a "crisis". Even after a crisis if you implemented a true "Fault tolerant" and "Graceful degradation" System, the System and its interfaces ideally should work in a degraded mode still able to minimize consequences. E.g., Fukushima Plant dramatic failure.

In an highly dynamic environment, (a jet facing adverse conditions, sensor limitations, etc.) the interface requirements are severe. And is in this situations your design team must deliver what they developed during the R&D phase, to cover not only the probable faults but also the possible ones.

I pointed what seems to me a concerning conceptual error probably affecting several designs. In AF447 it seems this (design error + sensor limitation) triggered a major System reconfig and the subsequent lack of reliable Air Speed + probable human interfacing issues, probable played a role in the final result. Actually the plane in few minutes departed from an absolutely normal operation going to the bottom of the sea. And apparently without any more important "mechanism" problems other than Pitot tubes non compatible to the air space the plane entered. The first leak of information from the BEA investigation team surfaced in a French newspaper, Le Figaro, "suggested" crew faults. Also the BEA report (issued to stop damaging speculation before Paris Air Show, trade fair) emphasizes crew actions much different than the "normal", thus indirectly suggesting crew fault (from the pilot "flying" the plane during most of the crisis).

And as you know, its easy to put responsibilities in an operator if a Human machine interface (even a poor designed one) is working as designed. Always the management could point to lack of "training", etc. exempting the System.

Sounds intriguing (suggesting interfacing issues or even a possible System glitch that may have occurred during the critical moments) what we learned since the beginning. At least the trigger seems to be caused by improper sensors (product limitation) put in a System lacking the required redundancy in respect to a basic input, the Air Speed. The sensors (French company) were being replaced after showing its limitations, also existing (in a lesser degree) in its (US company) competitor.

You, being outside Aviation industry could eventually contribute to the discussion in respect the issues you face daily in your work.

On interfacing issues, take a look on the challenge an experienced crew faced when climbing out of Changi airport (SG) in a Airbus 388. They took a good time just to understand what happened and was going on after an uncontained engine failure in the inner left wing Rolls Royce engine. They eventually landed the plane in the same airport facing a complex situation.

Last edited by Jetdriver; 2nd Jul 2011 at 23:38.
RR_NDB is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service - Do Not Sell My Personal Information

Copyright 2018 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.