Here is an interesting analysis by @Pulkit_Saraf from X which not only describes the functioning of the FSOV's in the 787 but in addition how they tie into the system on a whole and also a comparison to the Airbus' system solution. There is of course the question of how accurate this description of the 787's systems is, but if true, then indeed worrisome. Of course we still do not know what happened to AI171, but his theory is interesting in that it also includes explanations for why the gear was still down on AI171 when it crashed and an explanation for why the RAT deployment and a timeline for the events.
"I believe the cause was a combination of Fuel Shutoff Valve (FSOV) activation due to an cascading electrical system failure. It’s not the first time a 787 has experienced electrical cascade system failure during the first minutes in flight and required RAT deployment. Let me explain my reasoning: On the Boeing 787, the engines will keep running even if all hydraulic systems fail. Each engine has its own FADEC (Full Authority Digital Engine Control), powered by a Permanent Magnet Alternator (PMA) that’s driven by the engine itself. Once the engine is spinning, the FADEC operates independently — controlling fuel, thrust, and safety — with no need for aircraft hydraulics or external electrical power. A simultaneous FADEC failure is extremely unlikely. So, why did the engines shut down if they are supposed to be so resilient? There is one important component that can override the FADEC: the FSOV. This spring-loaded fuel shutoff valve is not powered by the PMA, but instead by the aircraft's electrical DC system. If power is lost, the spring closes the valve instantly, cutting off fuel to the engine. FSOVs are a fail-safe, designed to protect the airframe, not the engine. In Boeing’s logic, it's safer for the engine to shut down than to keep feeding fuel into a potential fire. In the video footage, the truck tilt actuator is in the forward position (toes down). This movement requires a hydraulic system force to overcome the wind and gravity. This forward position only happens when the landing gear retracted sequence is initiated by the pilots. The strange thing is that it is only the second step of the main gear retraction sequence to tilt the wheel truck forward. The first step is to open the doors, and if the doors are fully open, the next step is to tilt the wheel truck. It’s unclear why the doors are closed but the truck already tilted forward. Most likely the pilot selected “gear up,” which triggered the retraction sequence. The truck tilt was initiated as step 2, but the doors didn’t open due to power or hydraulic failure, or the sequence froze mid-process. The aircraft lost main power (hence the RAT), and the sequence halted with the gear in a partially commanded state: truck tilted, doors closed, gear extended. That gear retraction moment may have been the exact point when the whole system collapsed just 3-4 seconds after takeoff.(there was a positive climb rate at 600ft AMSL and 174kt ) The engines kept running briefly (3seconds), powered by the remaining fuel in the lines before flaming out. The main landing gear hydraulics are powered by an electric-hydraulic system — if there’s no electricity, there’s no hydraulic pressure. In contrast, other hydraulic systems on the aircraft are supplied by engine-driven mechanical pumps. (20-30kw power needed to retract gear) Since the aircraft remained stable in flight, it's likely that both engines flamed out simultaneously. Flaps, fly-by-wire, landing gear, and other systems likely froze for a moment and possibly regained functionality after the RAT deployed. The +-15kW RAT powers the electric motors on the blue hydraulic lines of a 787. This controls the key flight-control actuators for the rudder, elevators, and primary ailerons. It appears that the pilot slightly increased the nose attitude during the final phase of the flight. (landing gear retraction is not possible with a RAT) For both FSOVs to close, the aircraft would have to lose both AC buses, both DC essential buses, and the battery backups. That requires a massive electrical failure to overcome all possible redundancy layers. This is a possibility because there are known cases where a 787 and a 777 experienced a total electrical cascading failure of most systems. So it is possible. All signs point to fuel cutoff via the FSOVs. The big question is why did they fail? This is hard to say but as said electrical failure is a very plausible cause. The RAT was automatically deployed. This means there is a total loss of AC electrical power. I suspect a scenario where a partially working or unstable electrical system triggers RAT deployment amid a power transition event. This could escalate into a full-blown electrical disruption, possibly interfering with the DC essential buses and battery backup. When switching power sources (from main buses to RAT), the system can behave unpredictably — especially if one source is competing with the RAT or is unstable. In such a power chaos, RAT deployment might introduce transients or delays in power restoration, which could make power delivery unstable and possibly affect the digital managed power to the FSOVs. If they lose power, all fuel will be cut off. On the 787, FSOVs don’t have guaranteed dedicated or hot battery backup, unlike the Airbus A320, which powers them directly from the battery. The 787’s battery backup supports the entire DC bus, and power management software prioritizes flight-critical systems. If power is limited or loads are erratic, less critical systems like FSOVs can be deprioritized. This is a very complex system with a lot of software rules. This also reflects Boeing's design philosophy: in a severe power failure, airframe survivability and flight control take precedence over engine continuity. Their assumption is that it’s safer to shut off fuel than risk uncontrolled flow in to an engine on fire. The whole idea of the posibility of losing both engines at 400 ft during takeoff feels inherently unsafe. From a thrust continuity perspective, this design approach is a vulnerability and may have played a role in Flight AI171’s dual-engine flameout."
Every message on the aircraft's internal comms bus - basically ethernet - has a time stamp. If you're getting out of date messages, they should be ignored. But when the counter assigning time-stamps wraps around after 51 days you'll get a (possibly transient?) situation where all the messages in the system have invalid time-stamps. I'm not certain if it's something that'll clear itself because all the timestamps will then become sequential again, or if it'll cause a longer-lasting failure condition.
There was no electrical failure. There was a transient situation where the conditions for automatic FSOV deployment (in the air, thrust surges) were true on both engines. The system worked as designed, but there was insufficient protection around a bounce on landing combined with rapid thrust reverser cycling.
ETA: I've modified this to strike out 'in the air', as I now understand it, TCMA should only trigger on the ground.
Because FSOV operation is intended to happen when everything else has failed. The scenario is engine fire, unable to shut down fuel pumps, no engine controls work; but eventually the FSOV will lose power due to the fire damage, that power holds the valve open and without it the valve will spring shut and shut down the engine. FSOV functionality requires it to be able to operate independently of any input.
But everything cannot fail by design objective, unless external impact/attack or sabotage.
A tansient situation cannot be seen as failure. If transient time takes even 1 second the system has to be designed at H/w & S/w level both to include it.
There are fire sensors informing pilots. There is also fire extinguishing handle/knob for each engine behind throttle. But in these cases there was no fire.
If no engine controls work - start switch overhead, throttle, fuel switches behind throttle, how can this happen when cockpit is backed by batterries & then RAT?
I can understand risk of fire getting through fuel pipe into fuel tanks, but after FSOV shut down there should be some way to re-open it when no fire, no permanent electricity loss, etc.
IMO this is a design flaw & will be definitely be modified in future.
Just simulate all these incidents in our mind in slow motion, we'll autmatically get what needs to be modified to avoid glitches, false alarms, etc. hat's how upgrades actually happen.
I respectfully disagree, thats very short, incomplete statement/condition. It also depends on segment of flight, speed, altitude, orientation.
Both the things are equally important & separate.
Flight controls needs hydraullic fluid, engine needs fuel, & both systems need electricity to operate respective sub-components which are NOT inter-dependent.
Control surface acuators, rotating screw-rods, pistons, etc have NO relation to fuel valves, sprayers, ignitors, etc. So both systems should have independent backups.
NOTE - Man made things are as good as the men who think it out & different men/teams/companies think differently.
I won't risk my life on it so i don't buy this reason if true.
At homes, offices, when UPS/invertors take over after electricity grid cuts, the switching is instantanious.
In Datacenter equipments - storage, switches, routers, servers, each modular unit has 2 independent main power supplies, can survive on 1 MPS. If both MPS are gone, there are 2 SPS (Standby Power Supplies), 1 SPS can give power for few minutes sufficient for all units to send the READ data in RAM to internet & WRITE data to disks/SSD.
And then we're talking about Avionics of life-critical flying machine.
Hence by design the cockpit controls & FMC in avionics bay should not lose power, no transients, no fluctuations.
Because airliners are very good gliders, but do not continue to fly without any flight controls.
If a jet engine loses fuel in flight, the engine will continue spinning for a long time. There's entire in-flight engine restart procedures, which mostly involve nosing down to increase the airflow into the engine and increase the RPM and then opening the fuel valves and turning on the ignitors. Restarting a jet engine in flight is trivial, even needing to do so happens so rarely that pilots can go entire careers without needing to.
Like i said, it also depends on flight segment, altitude, speed, orientation.
And 2 systems are NOT inter-dependent for power, so they should have independent backups.
In a 2 spool engine for example, when the overhead engine knob is rotated from NORM ro START, at ground the N2 spool starts by APU/GPU bleed air, attains minimum 15-20% RPM, then fuel switch is turned on. So there's no need to nose down to increase the RPM as the ambient air speed/pressure keeps the spools turning like a windmill unless there are rotation brakes.
In 1x engine failure pilot follow checklist which looks slow.
But In emergency, after checking MFD for errors, overhead panel red lights, engine fire & if no fire, the backups should continue electricity to FMC & EEC, pilots would take just 2 seconds to turn overhead engine switch & fuel switch behind throttle.
What happens when all the avionic network messages have invalid timestamps, including the ones used by the power management systems? We don't have the information to tell, but a sudden glut of invalid messages may have problematic effects.
If no engine controls work - start switch overhead, throttle, fuel switches behind throttle, how can this happen when cockpit is backed by batterries & then RAT?
Physical damage severing the engine from the cockpit controls. Chafed wiring bundles, things blowing up, fire in the avionics bay, all sorts of scenarios.
I can understand risk of fire getting through fuel pipe into fuel tanks, but after FSOV shut down there should be some way to re-open it when no fire, no permanent electricity loss, etc.
IMO this is a design flaw & will be definitely be modified in future.
I don't think you understand the purpose of the FSOV. It isn't there to keep fire out of the fuel tanks, in the fire situation it's there to stop adding fuel to the fire if the fuel flow can't be stopped any other way. It also isn't there just to deal with fire, but with situations such as a turbine runaway. Whether fire or turbine runaway, the last thing you want in either case is to restore the fuel flow. If you want a system you can turn back on, then you create a more complex system, increasing the risk it won't work when you need it, or will re-enable fuel flow when it shouldn't. The vanishingly rare case of FSOV triggering dual engine shutdown by mistake likely doesn't outweigh the risks of FSOV not functioning when needed because it's been made needlessly complicated.
Just simulate all these incidents in our mind in slow motion, we'll autmatically get what needs to be modified to avoid glitches, false alarms, etc. hat's how upgrades actually happen.
No, upgrades happen because scores, even hundreds, of people have spent large amounts of time working out the problem, working out the change, working out the safety cases, running prototype systems in test rigs and convincing the airworthiness authorities they've thought of everything. There is nothing 'automatic' about it. MCAS is a perfect example of an 'update' that went catastrophically wrong even though the people involved thought they'd thought of everything.
I respectfully disagree, thats very short, incomplete statement/condition. It also depends on segment of flight, speed, altitude, orientation.
Both the things are equally important & separate.
I can understand risk of fire getting through fuel pipe into fuel tanks, but after FSOV shut down there should be some way to re-open it when no fire, no permanent electricity loss, etc.
IMO this is a design flaw & will be definitely be modified in future.
I won't risk my life on it so i don't buy this reason if true.
At homes, offices, when UPS/invertors take over after electricity grid cuts, the switching is instantanious.
In Datacenter equipments - storage, switches, routers, servers, each modular unit has 2 independent main power supplies, can survive on 1 MPS. If both MPS are gone, there are 2 SPS (Standby Power Supplies), 1 SPS can give power for few minutes sufficient for all units to send the READ data in RAM to internet & WRITE data to disks/SSD.
What happens when all the avionic network messages have invalid timestamps, including the ones used by the power management systems? We don't have the information to tell, but a sudden glut of invalid messages may have problematic effects.
Are these LOG messages or the real-time control signals?
Log messages need time-stamp, while control signal is simply sent out instantly.
No matter which protocol is used - Ethernet, Fiber Channel, PPP, etc, these are reliable, connection-oriented protocols with CRC & other checks, ackowledgement of each transmitted PDU (Protocol Data Unit). The sequencing & flow control are inbuilt. These protocols can be used in physically redundant lines also.
I don't think you understand the purpose of the FSOV. It isn't there to keep fire out of the fuel tanks, in the fire situation it's there to stop adding fuel to the fire if the fuel flow can't be stopped any other way. It also isn't there just to deal with fire, but with situations such as a turbine runaway. Whether fire or turbine runaway, the last thing you want in either case is to restore the fuel flow. If you want a system you can turn back on, then you create a more complex system, increasing the risk it won't work when you need it, or will re-enable fuel flow when it shouldn't. The vanishingly rare case of FSOV triggering dual engine shutdown by mistake likely doesn't outweigh the risks of FSOV not functioning when needed because it's been made needlessly complicated.
There can be many reasons for something in for/against.
"Adding fuel to fire", Runaway turbine, etc, we all know that there can be false situations & alarms also. So there should be protection both ways.
Complexity - Humans are not at zenith of any technology/complexity. It is just beginning. Today millions of engineers wouln't think same way. Different humans/teams/companies worry about complexity & risk differently. For example the Space Shuttle was said to be most complex & risky tech object on Earth. Who knows some capable nations might have simply rejected making something similar due to complexity.
Preemtively assuming that things won't work when needed is a pesimistic approach even before the design phase, then accidents are obviously waiting to happen.
So it is not case of weighing when needed vs not functioning bcoz the shut down is auto-mechanical but re-opening would be manual & powered by redundant backup.
Have all engine makers implemented this auto-mechanical FSOV in all their engine models?
No, upgrades happen because scores, even hundreds, of people have spent large amounts of time working out the problem, working out the change, working out the safety cases, running prototype systems in test rigs and convincing the airworthiness authorities they've thought of everything. There is nothing 'automatic' about it. MCAS is a perfect example of an 'update' that went catastrophically wrong even though the people involved thought they'd thought of everything.
But ultimately 100s of people spending huge time, convincing authorities, resulted in big loss of life & assets, law suits, bad reputation.
IMO, after watching many videos about MCAS crashes, i think the MCAS logic's intent was right to regain control against stall, but may be amount & duration of pitch down was not proper. MCAS was designed to rely on a single AoA sensor, making it vulnerable to erroneous input from that sensor.
2-hour iPad course & 13 page handbook were created, but Training material to pilots was missing MCAS in case of Lion Air 610 accident. AoA sensor was mis-calibrated during earlier repair & not detected in following repair. Xtra Aerospace making the sensor had its license revoked & went out of business.
In Etheopian 302 crash, pilots did take manual control but it was too late. Pilot errors were also pointed.
Bcoz civil jets & humans have low G tolerances, so recovery altitude would be very high. Royal Air Force famous retired pilot Andy Green flew recreated sims, covered by National Geographic & said that if MCAS failure happened below 10K feet then crash is certain.
As i myself said that human have not reached zenith of tech, it means glitches & improvements will continue till eternity, but the practical result, that too multiple times, itself acts as a proof of efficiency of design.
Some people/teams/companies would be more efficient than others.
We should not intentionally put our brain at dangerous crossroad on creating & chosing b/w these kind of 2 choices.
Like i said, different flight segments have different needs, safety margin, options, procedures, reaction time, etc.
A/c becoming a glider at high altitude cannot be compared to A/c stalling at very low altitude or after takeoff. The idea of safety & redundancy is to avoid crossroads, especially when multiple things should work a same time.
Humans implement how they think & suffer the consequences.
That's what i wrote that pilots trying to restart would operate the fuel switches behind throttle.
But this theory of spring-shut FSOV seems to negate that, assuming all controls are lost.
So if there is 1x engine failure & pilots can restart engine then by design, if we wan't to save humans, then it should be possible in 2x failure too.
Why would they need to be aviation rated? And what is Aviation rated exactly w.r.t. electricity?
Computer for -
- Ground application,
- Air application,
- Space application.
All have their own ISO & dedicated concerns, standards, design, SOPs, etc.
But all need power & redundancies should be there at primary & secondary levels, that's it.
Real time control signals. And they're still timestamped*, and a problem with that time-stamping following likely counter-wraparound after 51 days was serious enough to require an AD mandating regularly powering the aircraft on and off to restart the counter.
"The FAA has received a report indicating that the stale-data monitoring function of CCS may be lost when continuously powered on for 51 days. This could lead to undetected or unannunciated loss of CDN message age validation, combined with a CDN switch failure. The CDN handles all the flight-critical data (including airspeed, altitude, attitude, and engine operation), and several potentially catastrophic failure scenarios can result from this situation. Potential consequences include:
Display of misleading primary attitude data for both pilots.
Display of misleading altitude on both pilots’ primary flight displays (PFDs).
Display of misleading airspeed data on both pilots’ PFDs, without annunciation
of failure, coupled with the loss of stall warning, or over-speed warning.
Display of misleading engine operating indications on both engines."
See this blog for an extended analysis, which concludes the relevant timestamp may be that in Boeing's Error Detecting Encoding (EDE), which is transmitted as data within the message, not as part of the ARINC 664 message structure :
Uncover the implications of hacking a Boeing 787 as we analyze recent FAA directives and aviation technology concepts.
www.ioactive.com
* Actually multiply timestamped, with a Sequence Number (1 byte) in the ARINC 664 protocol and a second Sequence Number (2 Bytes) and a full Timestamp (six bytes, first bit always zero), in the EDE data portion.
No matter which protocol is used - Ethernet, Fiber Channel, PPP, etc, these are reliable, connection-oriented protocols with CRC & other checks, ackowledgement of each transmitted PDU (Protocol Data Unit). The sequencing & flow control are inbuilt. These protocols can be used in physically redundant lines also.
You're missing the point. The message is correctly formed, but the timestamp is wrong because the counter generating it has looped around and started counting from zero again. What happens when it gets to another system that looks at it and goes "Huh, that timestamp is earlier than the last message I got, best ignore it."
No it's a legally mandated approach. How likely is this to fail? If it's greater than 1x10^-9/flight hour, find another way to do it.
The most complex part of flight control systems isn't the flight control laws, they're simple, just a mathematical formula to apply, what's truly complex is the error and redundancy management. Similarly so for EICAS, FADECs and other avionics systems
This is my point, the supposedly simple MCAS design logic didn't adequately consider what happened in a fairly obvious failure situation - such as a bent AoA vane - in combination with the CRM issues of competing demands to 'fly the airplane' and troubleshoot a system pilots didn't know existed.
As a general case there is simply no way any one person can hold all the different inputs, ranges, data combinations and failure scenarios for any one avionics system in their head, doubly so once you start having to factor crew actions into the equation.
That's what i wrote that pilots trying to restart would operate the fuel switches behind throttle.
But this theory of spring-shut FSOV seems to negate that, assuming all controls are lost.
So if there is 1x engine failure & pilots can restart engine then by design, if we wan't to save humans, then it should be possible in 2x failure too.
As I understand non-787 FSOV design, you turn the fuel on by powering a solenoid that pulls open a spring-loaded valve. In the event of loss of electrical power to the FSOV, the spring pushes it shut. With the fuel switches still in the ON position, as soon as power came back the FSOV should have opened again.
There is a very large difference between components that go in a tractor or excavator and components that go in an airplane, even if they're basic hydraulic cylinders of exactly the same size and operating pressure.
Aircraft rated circuit breakers are Trip Free types, for example. Must be Trip Free, to prevent dumbass pilot from just holding the CB in the on position and overriding the CB.
I'm not sure what an automatic bus transfer switch has to be, other than I've never seen a solid state ABT before.
Computer for -
- Ground application,
- Air application,
- Space application.
All have their own ISO & dedicated concerns, standards, design, SOPs, etc.
But all need power & redundancies should be there at primary & secondary levels, that's it.
Anything aviation related needs to be tested to hell and back, and all this testing is done at the manufacturer's expense.
Very few manufacturers are willing to do such testing. Especially for electronics, which advance fast enough that computers 3 years old are obsolete.
For example, the main computers in the F-22 are technological cousins to the 386, and came out at the same time. 1980s level chips. The USAF bought enough chips to last a lifetime of the planes. Hopefully.
The other option is to maintain low production of chips that are increasingly obsolete.
===========================
Back to my main point.
A total electrical power failure is an extremely low-probability event. This is literally the first total electrical power failure I have heard of in a commercial aircraft. Ever.
Real time control signals. And they're still timestamped*, and a problem with that time-stamping following likely counter-wraparound after 51 days was serious enough to require an AD mandating regularly powering the aircraft on and off to restart the counter.
* Actually multiply timestamped, with a Sequence Number (1 byte) in the ARINC 664 protocol and a second Sequence Number (2 Bytes) and a full Timestamp (six bytes, first bit always zero), in the EDE data portion.
See this blog for an extended analysis, which concludes the relevant timestamp may be that in Boeing's Error Detecting Encoding (EDE), which is transmitted as data within the message, not as part of the ARINC 664 message structure :
You're missing the point. The message is correctly formed, but the timestamp is wrong because the counter generating it has looped around and started counting from zero again. What happens when it gets to another system that looks at it and goes "Huh, that timestamp is earlier than the last message I got, best ignore it."
This reminded me of Y2K bug.
You must be knowing that in Synchonous remote replication b/w 2 data ceneters also, such mechanism of sender's timestamp is not used. Each node uses local clock sync by NTP.
How do 2 devices in 2 different time zones, or across the world interact through internet? Do they consider eachother's local time? NO. They use things like NTP.
If NTP server fails or link with it fails, then it doesn't destroy communications b/w nodes/devices.
The aircraft has local Time Manager like NTP server.
Hence as per my low IQ the actual transmit timestamp could be issue if used wrongly in programming.
Every node has its own battery powered local clock, so after their max value, it is expected to reset.
If sender's clock reset 1st then receiver's & timestamp recieved is lower than receiver's then a well-programmed logic can check last 1 or 2 values & confirm that this resetting is expected.
Boeing might have used EDE due to UDP & not TCP in ARINC 664.
So it sounds funny that -
"stale data monitoring function lost" + assumed "switch failure" = delayed info on MFD.
In a such small network, a real-time system, the delay expected on MFD would be how much? few 10s of 100s of mili-seconds & will be corrected very soon.
But the AD assumes not just stale data problem but also CDN switch failure in a redundant network.
And such failure would cause display errors leading to pilot errors.
But we were discussing about DIRECT failure to both engines together.
I would divide this into 4 areas-
- H/w
- S/w
- communication
- clock & n/w nodes sync.
I'll mention some points for generic global audience & non-IT techies.
People with knowledge of OSI stack, N/w protocols, resource virtualization & partitioning, can understand these things more easily.
H/w -
- In general, a critical switch needs to be modular with at least 2 contoller modules & multiple port modules each with at laest 2 ports connected to both N/w A & B.
- Such switch also has temp sensors, smoke detectors.
- Cooling fan modular also redundant. If 1 fail, others spin faster, with alert.
- And if 1 entire switch fils then other N/w switch is supposed to route the data.
- So there is protection against -
- port/cable failure,
- module failure,
- controller failure
- cooling fan failure
- entire switch failure
+ power redundancies i said earlier.
S/w ( messages, data-structure)-
In switches, routers in datacenter for example -
- There are multiple modules needing multiple types of logs & look-up tables like MAC/CAM table, ARP table (Address Reolution Protocol) with IP address - MAC address mapping, then routing protocols like OSPF, EIGRP, etc have their routing tables & n/w topology table, etc, then link state table, etc.
- Some tables like topology are distributed across n/w whenever there is link state change.
- All these entries in tables have their own default age which can be tweaked if required.
- After age timer is zero the entries are deleted & when new PDU arrives the entries are again put in tables. But this doesn't affect working of device & display to admin team.
- The switch/router does malfunction due to numerous H/w & S/w issues & for certain issues there are reboots done 1st at smallest modular level, if didn't work then intermediate section level, still didn't work then entire switch/router reboot. But AFAIK, a S/w bug usually relates to OS, memory, not timestamps.
- If entire switch/router malfunctions, rarely, then link state changes, n/w topology changes, new master node might be needed by automatic election by exchanging some info. This can take few seconds, HOWEVER, some latest protocols either have an 'active-active' mirrored system of distributing work among 2 modules or 2 nodes, OR a deputy node is selected proactively to take over instantly to minimize re-direction delay.
- L3 Routers provide redundancy by protocols like VRRP (Virtual Router Redundancy Protocol), GLBP (Gateway Load Balancing Protocol), HSRP (Hot Standby Routing Protocol), VPC (Virtual Port Channel), etc.
- L2 Ethernet switch provide redundancy by PRP (Parallel Redundancy Protocol), Port Channel, VPC, Cisco has CEF, etc.
Communication -
- There are 2 types of communications - Data & Control Signals.
- Data received by FMC would be from sensors, components & about control surface positions.
- Data sent by FMC would be instructions & new values to operate all moving components & to displays, logs.
- There is choice to send Control Signals in dedictaed N/w separate from data channels, like CAN (Controller - Area Network) used by RDCs here in 787, this is called "Out of Band communication".
- If Data & Control Signals are sent in same channel then it is called "In Band Communication".
Clocking, Synchronization -
- All the functions & data structures are independent & synchronized from battery powered clock in a network or computing node.
- For all network nodes to sync together, every transmission protocol has 1st section called "preamble", etc, of its PDU (Protocol Data Unit) for sync, a pattern of 0/1 bits. Ethernet has 7 bytes preamble.
- After initial sync, there will periodic sync too.
- The log messages are oriented to GMT from which the display/analysis tools can calculate local time.
So whether the root cause is H/w malfunction or S/w bug, there is redundancy in network. Same goes with a critical computer.
So at this point itself i would reject CDN switch failure unless a bad switch design/product for real-time application.
Now let's look at Boeing 787 H/w & S/w features:
The 787's CCS (Common Core System) diagram, there seems to be at least 6 CDN switches.
Bcoz this is small N/w so L3 router with IP not used, just L2 Ethernet will suffice.
The avionics FMC H/w seems to be modular & redundant:
The 'End System' modules are connected via PCI bus in backplane & each ES LRU (Line replacable Unit) has -
- 1x ASIC (i hope multi-core)
- 2x transcievers
- 1x config memory
- 1x RAM
21 RDCs (Remote Data Concentrators) interface with components with other protocols, analog things, sensors, valves, pumps, etc.
They are connected to 2 networks via CDN switches.
I don't have exact pic of 787 CDN switch. something like following -
So we see that there are multiple ports, probably logically bundled in Ether-Channel port group giving redundancy, load balancing, high availability.
There are batteries + RAT for backup.
Now few points about this avionics S/w, communication -
- ARNIC 664 is Airbus version based on Ethernet, ATM (Async Transfer Mode), so it'll provide redundancy, speed, full-duplex, data integrity (CRC), etc.
- It seems to use Virtual Link ID instead of MAC address, hence a VL table instead of MAC/CAM table, can reject any erroneous data transmission.
- Reading further, IP address is also used, but not in routing as this is small n/w.
- CCS is an asynchronous system, decoupling this operation from the network interface.
- Data is transmitted on 2 channels/networks. At recieving end there is integity checking & redundancy management using '1st validation wins' policy.
- But it seem to use UDP primarily, not TCP. UDP is used where some data loss like in video, audio is acceptable, while TCP has 'sequences' & 'acknowledgement' for ordered delivery, not UDP. Hence the ES (End System) has to add 1 byte in data for Sequence # (0-255) at physical link level.
- But still again Boeing, at virtual link level, adds extra EDE protocol with 1 more sequence #, on top that the actual time stamp & 2 CRCs. May be extra sequence is required to differentiate virtual link frames, but exact time stamp IDK why, may be for logs. But more encapsulation, decapsulation, calculation means more complexity & delays.
- Timestamp is of transmit time & uses local clock.
- As all nodes use their own local clock, CCS needs to centralize all local time for age validation, done by the Time Management function, which maintains table of relative offsets with each ES in CDN. Time Agent of each ES is periodically questioned by the Time Managers.
- Offset table is broadcasted to each ES to perform age verification of PDUs from another ES.
Ultimately the consistency of broadcasted offset tables is being questioned in the analysis.
Possible reasons given -
- ES didn't get off settable. [This is not possible in redundant n/w, active-active or active-passive]
- Age in table > max config age, so discarded, or age is inconsistent. [This means corrupt data but with CRC X + CRC Y + FCS + 2 channels + redundancy manager, how is this possible?]
But still if this happens then System designers &/or programmers are at fault.
No it's a legally mandated approach. How likely is this to fail? If it's greater than 1x10^-9/flight hour, find another way to do it.
The most complex part of flight control systems isn't the flight control laws, they're simple, just a mathematical formula to apply, what's truly complex is the error and redundancy management. Similarly so for EICAS, FADECs and other avionics systems
I mean preemtively assuming that something won't work when needed & not doing anything for false situations like no fire, no runaway turbine, etc & glitch trips the ultimate fail-safe mechanical action & 100s of people loose their lives which could have been actually saved.
As I understand non-787 FSOV design, you turn the fuel on by powering a solenoid that pulls open a spring-loaded valve. In the event of loss of electrical power to the FSOV, the spring pushes it shut. With the fuel switches still in the ON position, as soon as power came back the FSOV should have opened again.
There is a very large difference between components that go in a tractor or excavator and components that go in an airplane, even if they're basic hydraulic cylinders of exactly the same size and operating pressure.
Aircraft rated circuit breakers are Trip Free types, for example. Must be Trip Free, to prevent dumbass pilot from just holding the CB in the on position and overriding the CB.
I'm not sure what an automatic bus transfer switch has to be, other than I've never seen a solid state ABT before.
Buddy, i didn't compare a tractor but highly modular, redundant datacenter equipments which run 24x7.
But airliners don't need 24 hrs half way across the world & the engines will need few hours rest too before next flight.
I'm not champ in electricals but i think capacitors & fast relays make it possible for trip-free switching within a second, like in our home/office invertors/UPS.
The main computers in the F-22 are technological cousins to the 386, and came out at the same time. 1980s level chips. The USAF bought enough chips to last a lifetime of the planes. Hopefully.
In documentaries, the F-22 mission computer was compared to Cray Supercomputer.
Chief test pilot Paul Metz said that the avionics bays are modular, can be easily upgraded whenever desired.
Just like we upgrade our desktop/laptop with better HDD, RAM, some peripherals, OS patch, same can be done to a jet also.
A total electrical power failure is an extremely low-probability event. This is literally the first total electrical power failure I have heard of in a commercial aircraft. Ever.
Neglecting temporary power loss to passenger cabin,
I fail to believe that complete electrical failure (to engines) can happen bcoz EEC has its PMA with 115 V AC backup & GCU (Generator Control Unit) is powered by small PMG (Permanent Magnet Generator) connected to main generator.
So the EEC & GCU are also independently powered.
All GCUs can't fault together, hence all generators can't shut down together.
In documentaries, the F-22 mission computer was compared to Cray Supercomputer.
Chief test pilot Paul Metz said that the avionics bays are modular, can be easily upgraded whenever desired.
Just like we upgrade our desktop/laptop with better HDD, RAM, some peripherals, OS patch, same can be done to a jet also.
Well, the avionics bays are "modular", but all they are is a backplane conceptually identical to an empty VME chassis. You are still limited to the number of address/data lines etc, as well as the electrical characteristics of the backplane - which serve as an inherent limitation on clocking, transfer speeds and so on.
By the way, it appears that the i960s were replaced by PowerPC CPUs in the early F-22 production run.
Cosmic rays can flip bits.... So you can read the data out of the message, confirm CRCs etc, write it into memory for onward use, and then a cosmic rays flips a bit.
Really. I've literally had to look into the probabilities of a cosmic ray flipping a particular bit at a particular point of flight.
I mean preemtively assuming that something won't work when needed & not doing anything for false situations like no fire, no runaway turbine, etc & glitch trips the ultimate fail-safe mechanical action & 100s of people loose their lives which could have been actually saved.
So, assume the likelihood of a dual engine failure due to FSOV failure is A, and in a percentage of cases where that happens, B, there'll be a loss of life. So the overall probability of loss of life is A * B (it'll actually be a lot more complex a calculation than that).
Now assume you create a marvellous self-resetting modified-FSOV. Now we have to start looking at its fault tree.
Let's assume it works in C percentage of cases. So your likelihood of modified-FSOV failure killing people is now A * B * C.
But it will also reinstate fuel-flow incorrectly in X percentage of cases*, and in Y percentage of those, it'll kill people by throwing fuel on a burning fire, speeding up a turbine runaway, whatever. So the likelihood of the modified-FSOV killing people by mistaken action is X * Y (Again, it'll be a much more complex calculation).
So the question you have to ask (not can, not should, but have to, because the airworthiness authorities are checking your homework), is is A * B greater than (A * B * C + X * Y)? And again, much more complex calculation.
If it is, then congratulations, your new modified-FSOV is a safer way of doing things. But if it isn't, then your fix has actually made the situation worse. cf MCAS.
It doesn't matter whether you think success is likely, you still have to do the calculations. Thinking about how something will work is simple, thinking about how it will fail is much more complex. And when you have multiple systems interacting with each other....
* Note that X is a single engine case, not the much rarer dual engine case
Currently there are multiple routes in the 16-18 hour non-stop range and QANTAS are due to launch London to Sydney non-stop in the next couple of years, which should be a bit over 20 hours.
I'm not champ in electricals but i think capacitors & fast relays make it possible for trip-free switching within a second, like in our home/office invertors/UPS.
In documentaries, the F-22 mission computer was compared to Cray Supercomputer.
Chief test pilot Paul Metz said that the avionics bays are modular, can be easily upgraded whenever desired. Just like we upgrade our desktop/laptop with better HDD, RAM, some peripherals, OS patch, same can be done to a jet also.
Neglecting temporary power loss to passenger cabin,
I fail to believe that complete electrical failure (to engines) can happen bcoz EEC has its PMA with 115 V AC backup & GCU (Generator Control Unit) is powered by small PMG (Permanent Magnet Generator) connected to main generator.
So the EEC & GCU are also independently powered.
All GCUs can't fault together, hence all generators can't shut down together.
This is genuinely on of the most baffling aviation accidents since MH370. I have a feeling that is is going to end up being either a human error/ maintenance mistake, which will make Air India look bad, or a one in a million design flaw that will end up making Boeing the villain.
Unlike MH370 the investigators have actual wreckage to examine along with the blackboxes, the one survivor from the 787 and lots of witnesses on the ground.
In a former life, we could determine an inservice event failure history within a few hours. Yes we didn’t have to deal with a totally wreaked aircraft but there again, we didn’t have the resources and urgency available for such a major incident.
You see modern avionics store so much information locally, the FDR & CVR form only part of the story. Furthermore this generation of FDR stores a large amount of data channels hence when combined other data sources,, the investigation must now have a broad outline of what happened, What’s far more challenging/time consuming is why it’s happened.
It’s really concerning that we haven’t seen an FAA/Boeing alert AD or SB related to specific systems…. It makes me think this is a deep systems architectural issue.
Cosmic rays can flip bits.... So you can read the data out of the message, confirm CRCs etc, write it into memory for onward use, and then a cosmic rays flips a bit.
Really. I've literally had to look into the probabilities of a cosmic ray flipping a particular bit at a particular point of flight.
So, assume the likelihood of a dual engine failure due to FSOV failure is A, and in a percentage of cases where that happens, B, there'll be a loss of life. So the overall probability of loss of life is A * B (it'll actually be a lot more complex a calculation than that).
Now assume you create a marvellous self-resetting modified-FSOV. Now we have to start looking at its fault tree.
Let's assume it works in C percentage of cases. So your likelihood of modified-FSOV failure killing people is now A * B * C.
But it will also reinstate fuel-flow incorrectly in X percentage of cases*, and in Y percentage of those, it'll kill people by throwing fuel on a burning fire, speeding up a turbine runaway, whatever. So the likelihood of the modified-FSOV killing people by mistaken action is X * Y (Again, it'll be a much more complex calculation).
So the question you have to ask (not can, not should, but have to, because the airworthiness authorities are checking your homework), is is A * B greater than (A * B * C + X * Y)? And again, much more complex calculation.
If it is, then congratulations, your new modified-FSOV is a safer way of doing things. But if it isn't, then your fix has actually made the situation worse. cf MCAS.
It doesn't matter whether you think success is likely, you still have to do the calculations. Thinking about how something will work is simple, thinking about how it will fail is much more complex. And when you have multiple systems interacting with each other....
* Note that X is a single engine case, not the much rarer dual engine case
Currently there are multiple routes in the 16-18 hour non-stop range and QANTAS are due to launch London to Sydney non-stop in the next couple of years, which should be a bit over 20 hours.
So are you saying that there are current cosmic ray impact risks that could be, if not eliminated, but at least greatly alleviated, by a few pounds of lead encasing of vital avionics boxes?
OBSERVATIONs in video-
- Each engine has 2x generators giving total 2x235 KV power, connected via gear box to spool.
- Generators are oil cooled.
- Generators have extra PMG (Permanent Magnet Generator) powering the GCU. PMG is not PMA. so the Generators power their own brain (GCU).
- EEC is dual channel redundant.
- As i said earlier, EEC gets powered from its PMA.
- If PMA fails the A/c's 115 AC bus kicks in.
- If 6 fuel pumps (2Left + 2 center + 2 right) pushing fuel fail, then engines have their own suction pump.
- If fuel filters are clogged then bypass will happen (warning displayed on MFD).
- Fuel tanks have water scavenge pumps, water being heavier sits down.
- Engines would stutter with smoke if fuel contaminated.
- Gear handle in cockpit tells gear to tilt forward, door open, then retract.
- 787-8/9/10 have different sequences of gear retraction.
- Flaps handle well separated from gear handle.
- All controls are made with different size, texture, shape so that if cockpit has smoke then pilots can still operate them well.
- The flaps positions have notches & detent to prevent accidental flaps decrease. Such pilot error is already being debunked in AI-171 case.
- Auto-gap function, keeps the slats deployed for lift, no manual control needed. Even if flaps retracted the slats might stay deployed for some time until sufficient speed. Also depends on AoA.
- Pre-gap function when below 225 knots. Operates same like auto-gap but operates when there is some kind of failure.
- Load relief function - auto retracts flaps when speed increases & flaps cause excess drag.
- RAT auto-deploys in following conditions -
- loss of all engines
- both engines are less than idle rpm
- loss of all hydraullic power
- loss of all electrical power
- loss of BPCU (Bus Power Control Unit), which detects lost power of C1 & c2 TRU (Transformer Rectifier Unit).
- On approach - loss of all 4 EM (Electric Motor Pumps), hydraullic pressure & loss of either left/right Flight Control ACE (Actuator Control electronics)
- Rotor burst on take-off causing loss of both PECS (Power Electronics Cooling Systems)
RAT can be manually deployed by button on overhead Hydraullic panel.
DERIVATIONS (not conclusion) from OBSERVATIONS -
- As RAT can auto-deploy when engines below idle RPM, an EEC glitch detecting high EGT for long could reduce thrust by reducing fuel flow. Although such glitch is very difficult to imagine.
- EEC is dual channel, has PMA. So if 4x generators lost, the PMA keeps EEC powered & connected to FMC.
- 4x GCUs have their PMG so 1 GU fail on each side is also tough to imagne. So all 4x generators can't be lost together.
- Due to water scavenge pumps, fuel contamination with water should stutter the engine with smoke, perhaps while taxi itself, but not stall the engines towards crash.
- Flaps can be auto-retracted by FMC by load relief' function. I wonder if a glitch can occur here or in auto-gap, pre-gap functions. But this doesn't seem to be case in AI-171 case.
Cosmic rays can flip bits.... So you can read the data out of the message, confirm CRCs etc, write it into memory for onward use, and then a cosmic rays flips a bit.
Really. I've literally had to look into the probabilities of a cosmic ray flipping a particular bit at a particular point of flight.
Then every phase is at risk - transmission source, transit carrier, destination.
And every electronic system, small/big, consumer goods or industrial, civil or military is at risk, especially space objects like satellites, ISS, etc.
(https://en.wikipedia.org/wiki/Cosmic_ray#Effect_on_electronics)
So, assume the likelihood of a dual engine failure due to FSOV failure is A, and in a percentage of cases where that happens, B, there'll be a loss of life. So the overall probability of loss of life is A * B (it'll actually be a lot more complex a calculation than that).
Now assume you create a marvellous self-resetting modified-FSOV. Now we have to start looking at its fault tree.
Let's assume it works in C percentage of cases. So your likelihood of modified-FSOV failure killing people is now A * B * C.
But it will also reinstate fuel-flow incorrectly in X percentage of cases*, and in Y percentage of those, it'll kill people by throwing fuel on a burning fire, speeding up a turbine runaway, whatever. So the likelihood of the modified-FSOV killing people by mistaken action is X * Y (Again, it'll be a much more complex calculation).
So the question you have to ask (not can, not should, but have to, because the airworthiness authorities are checking your homework), is is A * B greater than (A * B * C + X * Y)? And again, much more complex calculation.
If it is, then congratulations, your new modified-FSOV is a safer way of doing things. But if it isn't, then your fix has actually made the situation worse. cf MCAS.
It doesn't matter whether you think success is likely, you still have to do the calculations. Thinking about how something will work is simple, thinking about how it will fail is much more complex. And when you have multiple systems interacting with each other....
* Note that X is a single engine case, not the much rarer dual engine case
When we say that chances are 1 in 100 or even in 1 million/billion, that 1 chance could be the last one, middle one or 1st one also & it may kill us. People who wan't take risk in design phase itself, their choice & consequences.
All civil jets on outside look like a tube with wings & engines, but all maker companies globally have numerous differences on the inside, means big difference of opinions & implementations after complex calculations, simulations, R&D. They all accept the consequences over it.
So let's all keep our opinions & not go in circles.
Currently there are multiple routes in the 16-18 hour non-stop range and QANTAS are due to launch London to Sydney non-stop in the next couple of years, which should be a bit over 20 hours.
Didn't i write "for example".
All computers have certain common theory, but practical manifestations are different.
Every member/enthusiast, if not aero-professional, will give the closest example. I'm lucky that being IT guy at least i can talk about H/w & s/w in certain depth.
It os obvious that Aerospace/Aeronautical/Defence systems would be most fault tolerant, after which i think the datacenter equipments are the most redundant, fault tolerant systems, having their own ISO & other standards with specsmentioning limits of temp., humidity, terestrial altitude (pressure), etc.
This is genuinely on of the most baffling aviation accidents since MH370. I have a feeling that is is going to end up being either a human error/ maintenance mistake, which will make Air India look bad, or a one in a million design flaw that will end up making Boeing the villain.
There are whistle blowers everywhere.
Things which happened in US against Boeing.
In India also, passengers, retired pilots & other professionals have started to unofficially talk about mistakes, cover-ups by maintenance crews, managers, etc to save time & cost, gambling with people's life. Videos emerging on YouTube.
So are you saying that there are current cosmic ray impact risks that could be, if not eliminated, but at least greatly alleviated, by a few pounds of lead encasing of vital avionics boxes?
You're much better off with hardening, software protection and redundancy. You can use shielding, but you're actually better off with polyethylene than lead, and that's still not going to stop the really esoteric stuff, such as neutrinos that can pass through the entire planet without noticing it.
When we say that chances are 1 in 100 or even in 1 million/billion, that 1 chance could be the last one, middle one or 1st one also & it may kill us. People who wan't take risk in design phase itself, their choice & consequences.
It's not 'our choice', we are required to do this. The system will not be allowed to fly if we do not do this and show that its risk level is less than 1*10^-9 per flight hour. If the risk is higher than one in a billion, we have to find a better way to do it.
It's not 'our choice', we are required to do this. The system will not be allowed to fly if we do not do this and show that its risk level is less than 1*10^-9 per flight hour. If the risk is higher than one in a billion, we have to find a better way to do it.
There are some common rules/standards/directives globally + some national ones, w.r.t. function, manufacturing, operation, etc with levels of criticality & functions surviving.
So every maker will have to pass them.
But after that also there are numerous design differences on the inside.
And every maker claims their product is best unless really compared & shown with competitors. There are +/- points on both sides.
For example there are numerous videos of Boeing Vs Airbus Vs Embraer Vs Bombardier Vs Gulfstream, etc, depending on segment of jet, w.r.t. cockpit ergonomics, man-machine interface, task completion steps & time, components, maintenance, cost, etc.
And many operators change their fleet after initial experience.
These videos mentioned possibility of toilets & galleys leaking various liquids down into equipment & avionics bays & causing catastrophic short circuit.
These videos mentioned possibility of toilets & galleys leaking various liquids down into equipment & avionics bays & causing catastrophic short circuit.
Long before the Air India tragedy, the cause of which is still to be determined, people who had worked on the 787 had raised concerns about the production standards
Russian federal air transport regulator Rosaviatsia is urging aviation organisations to pay closer attention to the risk of aircraft fuel system contamination, after assessing a number of incidents over the past two years. Rosaviatsia states in a June bulletin that the presence of contaminants -...
www.flightglobal.com
TLDR: Russia's had a spate of contaminated fuel filter incidents, the contaminants in question include:
"various impurities, some with an unusually-high sulphur content, possibly from fuel which came into contact with low-quality rubber within the ground-refuelling system. Other impurities included particles similar to paint chips, and phosphorus compounds used in hydraulic fluids."
"a “significant amount” of cotton and cellulose fibres. Inspection of the filters showed some elements had gaps in their epoxy resin joints."
"organic deposits from heavy hydrocarbons which had passed through the filters."
I'm putting this here not because I think it's related to the Ahmedabad crash (which I think is vanishingly unlikely to have been down to fuel contamination), but as relevant to the earlier discussion on fuel contamination, because it points out a whole bunch of causes that aren't related to algal contamination/happening in a tropical country/happening in an Asian country.
Russian federal air transport regulator Rosaviatsia is urging aviation organisations to pay closer attention to the risk of aircraft fuel system contamination, after assessing a number of incidents over the past two years. Rosaviatsia states in a June bulletin that the presence of contaminants -...
www.flightglobal.com
TLDR: Russia's had a spate of contaminated fuel filter incidents, the contaminants in question include:
"various impurities, some with an unusually-high sulphur content, possibly from fuel which came into contact with low-quality rubber within the ground-refuelling system. Other impurities included particles similar to paint chips, and phosphorus compounds used in hydraulic fluids."
"a “significant amount” of cotton and cellulose fibres. Inspection of the filters showed some elements had gaps in their epoxy resin joints."
"organic deposits from heavy hydrocarbons which had passed through the filters."
I'm putting this here not because I think it's related to the Ahmedabad crash (which I think is vanishingly unlikely to have been down to fuel contamination), but as relevant to the earlier discussion on fuel contamination, because it points out a whole bunch of causes that aren't related to algal contamination/happening in a tropical country/happening in an Asian country.
Chemistry is such a tricky aspect of nature, it is difficult to proactively discover all chemical reactions.
The 2 examples we discussed were very educating -
- The excess biocide example, spanned across 5 flights, with errors in flight & on ground, yet the A/c survived.
- The salt water reacting with filter & releasing polymer particles jamming the FMU valve, within 1 flight itself, the flight surviving fortunately.
In a tropical country, during summer season, a possible contamination would have different reasons, most likey with poor maintenance.
But we don't know yet about historical maintenance records of AI-171 airframe, the H/w issues or the S/w alerts if any.
So on this angle we've to assume something similar to 2nd example of salt water causing full fuel contamination & rapid reaction within 1 flight, so much rapid that the problem didn't occur mid-flight but immediately after take-off.
What kind of chemical reaction can take place in fuelling chain -
- causing only 1 flight,
- impacting both engines same time,
- around mid-day noon,
- when local flights would depart in morning,
- probably taking fuel from same source?
Either it should be internal to airframe, or to the fuelling truck.
I checked some YT videos of fuel filter & pump in GenX-1B engine & found that there are multiple rings for sealing joints, just like in our kitchen pressure cooker.
I wonder if a reaction can take place here.
I checked some YT videos of fuel filter & pump in GenX-1B engine & found that there are multiple rings for sealing joints, just like in our kitchen pressure cooker.
I wonder if a reaction can take place here.
On July 3rd Air India pilots recreated flight 171 in a simulator and found that lowered gear and flaps at 0 would not have been enough to bring down the aircraft. I think it is now a safe bet to throw out the stall due to improper flaps settings theory.
On July 3rd Air India pilots recreated flight 171 in a simulator and found that lowered gear and flaps at 0 would not have been enough to bring down the aircraft. I think it is now a safe bet to throw out the stall due to improper flaps settings theory.
Pilot error on flaps was largely rejected from beginning itself.
Some Boeing tutorial video mentioned that FMC can auto-control flaps if needed, but retracting them during t/o or landing cannot be programming error.
The landing gear started retracting, tipped forward, but stopped, probably bcoz after electrical failure deploying RAT, the S/w would prioritize electricity to all minimum things needed for flight - FMC, EEC, hydraulic actuators, fuel supply.
EEC has its PMA, rest would need battery, RAT [& APU when there is time/altitude].
Although from the original FHD video of AI-171 flaps seem to be down, but thinking about this theory - For the "load relief" function to malfunction, the FMC needs to think that A/c has gained speed but pilot didn't retract flaps.
If 1 or more air speed sensors gets clogged then also the true air speed during t/o has not reached higher speed yet.
A clogged sensor obstructing air flow would be expected to report lower speed.
IDK if it can report higher speeds.
In such case i guess the majority of values reported by other sensors correctly would be considered.
So far we know that -
> There are 2 CDNs/networks.
> The 2 EECs are dual channel redundant with power from PMA & backup. So 4x links out from FMC.
> If 6x fuel pumps fail then engine can suction feed.
> 4x redundant generators.
> Just 1 engine is sufficient for safe emergency landing.
> Batteries & RAT would be enough for emergency controls & landing.
> Now, when we look at some key points from the CBT video on 787's electrical system showcasing so much redundancy, then it becomes very difficult to believe that an electrical HARD fault can cause a crash, even if someone throws a bucket of water in equipment bay short circuiting everything.
>> On H/w aspect, just at least 1 control-link from FMC to 1 of the EECs should survive with batteries+RAT & PMA on the ends.
However, manufacturing mistakes, maintenance mistakes & S/w glitches remain a concern.
> List of electricity sources for various purposes -
- 4x engine driven main generators giving 235 VAC.
- 2 APU generators giving 235 VAC with battery.
- 3 PMGs (Permanent Magnet Generators)
- 2 PMAs (Permanent magnet Alternators) for EEC
- Main batteries in forward avionics bay.
> Power sources remain isolated throughout the generation & distribution channels (probably to avoid short circuit).
> During power transfers a brief power interruption may occur as buses are energised from new power source.
> APU is started electrically by main battery turning any 1 APU Starter/generator to turn APU.
> Engines are started electrically by main battery turning engine starter/generator to turn spool, not by bleed air from APU.
> Main battery gives power for -
- A/c start
- APU start
- Refuelling ops
- Towing ops
- Electric braking (as backup)
- Captain's flight instruments (till RAT deployed)
> APU on ground gives power for -
- APU start
- Navigation lights (during batter-only towing ops)
> Electricity for flight control electronics -
- primary - 3 PMGs fully independent.
- secondary - 28 VDC.
- Additional dedicated batteries during temporary power interruptions.
> Electricity for EEC -
- primary - fully independent PMA.
- secondary - 115 VAC bus.
- During engine start the 115 VAC bus gives initial power, then switching to PMA after minimum engine RPM.
> Power distribution methods -
- Primary for higher loads - 115 VAC, 28 VDC in forward bay & 135 VAC in aft bay.
- Remote for lower loads - 17 RPDUs (Remote Power Distribution Units)
> The 4 engine generators power the 4 AC buses in aft bay.
> If any generator & its bus fails, it is powered by remaining buses.
> There are multiple power modes -
- for ground ops, depending upon power sources available.
- For flight, obviously 4x generators should be working.
- With 1 engine loss, 2 generators would suffice for nearest safe landing.
- In-air RAT-only mode - powers Captain's flight instruments, flight controls, navigation, communication.
- In-air battery-only mode - powers all same things as in RAT-only mode except center pitot heat.
> RAT deploys automatically under 1 of the conditions -
- both engines failure.
- all 3 hydraulic system pressure low.
- loss of all electrical power to Captain's & FO's flight instruments.
- loss of all 4 EMPs (Electric Motor Pumps) & FCS fault on approach.
- loss of all 4 AMPs & 1 engine failure on take-off or landing.
> 2 redundant BPCUs (Bus Power Control Units) provides function -
- Flight deck control/indication.
- Power transfer.
- Overall load management.
- some loads are automatically prioritised or inhibited at predefined conditions.
> CBIC (Circuit Breaker Indication & Control) shows status of Thermal & Electronic circuit breakers & control the electronic ones.
If 1 or more air speed sensors gets clogged then also the true air speed during t/o has not reached higher speed yet.
A clogged sensor obstructing air flow would be expected to report lower speed.
IDK if it can report higher speeds.
Air speed is calculated from the differential pressure between static ports (flush with skin, measures atmospheric pressure) and pitot ports (in airflow, measures sum of atmospheric + dynamic pressure).
Now think about putting your finger over the end of a garden hose, does the pressure go up or down? Whether blocked by insect, mud, ice, or physically crimped, it's not a simple answer.
Air speed is calculated from the differential pressure between static ports (flush with skin, measures atmospheric pressure) and pitot ports (in airflow, measures sum of atmospheric + dynamic pressure).
Now think about putting your finger over the end of a garden hose, does the pressure go up or down? Whether blocked by insect, mud, ice, or physically crimped, it's not a simple answer.
Ok, i thought the static port only measures altitude & pitot's tube only measures velocity.
Static pressure = force/area.
Dynamic pressure = 1/2 x D x V^2
Blocking or reducing garden hose end would increase pressure felt by finger, while blocking pitot's tube would decrease or zero the total pressure. Then the differential pressure would probably be -ve.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
www.ioactive.com
www.bbc.com
www.flightglobal.com
