Posts by user "syseng68k" [Posts: 30 Total up-votes: 46 Pages: 2]

I guess it depends on the model, as there are three position versions where the center position is valid, but that uses a different cam profile. For the one here, just confirmed, the toggle always finds one side or the other. The cam profile is circular, and it doesn't seem possible to balance in the middle. The cam section is separate to the threaded section. Might be a press fit initially, but is also staked either side. Have seen one of these where the cam section was loose, but still not possible to override the cam. A simple, but very effective bit of design work, IMHO.

Dunno, the discussion around the switch as a failure point looks spurious to me. With that used to support the idea that a possible engine shutdown was due to the master fuel valve closing.

I don\x92t really buy that, since we don\x92t know at this stage whether the engines did in fact fully shutdown, or were commanded to spool down to idle, or other lower thrust setting, both of which would produce the same result. Thoughts ?.

Thanks. The next question being: With both engines at idle, will there still be enough hydraulic and electrical power generated ?. Might depend also on aircraft mode, ground / air, takeoff / landing etc.

I guess the underlying point i'm digging at is that not only the fuel shutoff valve and control has authority over the engine. Many a/c subsystems will be connected together via an aircraft data bus, (or local area network, in compute terminology). and will need access to the FADEC for many reasons. Just as home wifi allows multiple users to access a shared resource, most modern complex systems are networked to supervise and share data.

hans brinker:

Thanks for that. Should be obvious, I guess.

Lead Balloon:

A bit of background on real time computing might help here. Apologies if some of this is tldr, obvious, or a simplification.. The FADEC must monitor the local environment, calculate and control, various aspects of engine operation. eg: baro pressure, temperature, fuel, speed control, overtemp, as well as respond to external commands (speed, start / stop etc) and provide operating status reports in real time, to other parts of the a/c. It really is a complex, semi autonomous system in it\x92s own right. In the old analog days, there might have been several individual hardware subsystems / black boxes, to do that, but since the advent of low cost reliable computing, more and more of that functionality has been delegated to software processes. Hardware function is abstracted into software space, a single black box replacing many. All those tasks that used separate hardware in the past, now run as individual software processes, at microsecond rate, sequentially. A sleight of hand making it appear as though there are separate computers, one for each item. Some critical tasks require microsecond response times, while others can wait seconds or longer. The way that is managed is by assigning a priority to each task, which ensures that all tasks have access to the processor as needed. Hence, the title, Real Time Systems. The task set shares processor, memory and other hardware, but there is great effort and process expended to encapsulate / isolate individual tasks, even though some of them will need to communicate with each other. Done right, that kind of system design can improve reliability due to far less hardware, and lowers cost and weight. However, it does concentrate far more design complexity into a much smaller abstract space, and needs a rigorous development process for safety critical applications.

Getting back to the point, if the TMCA function is resident on the FADEC, then it\x92s likely that it is just one software task of many running on a single set of FADEC hardware. Pretty opaque and no idea how we can begin to analyse that here. Iirc, tdracer said elsewhere that the various TMCA input qualifiers are handled by the airframe (?) , with a single yes / no input to the FADEC, but need to verify that. Really important to define what does what and where.

If there is complete power loss, some or majority of the data streams would be lost, as their sources would power down.

Aerospace101:

I think tdracer said upthread, that there are two rad alt sensors, and one wow, giving three. Need to verify, `but if two out of three are in agreement, that might be enough redundancy.

Musician: CVR Data

I think you will find that the cvr data is digitised before reachng the recorder, so that could be starlink as well. Can see that happening in the future, but the main obstacle to that is the cost of bandwidth and data storage. Significant to include all a/c in the sky at any given time, though the data could be compressed into packets, sent in batches.

IgnorantAndroid: Dumbfounded

Definately not true for the people i've worked with, me included, where most of us can design the hardware, and write and debug the code to run on it. Might be true of very large projects, where the software at top level is little more than an application, with the hardware an abstraction.

Musician: Illegal

Wasn't aware of that, thinking only about technical aspects. The possiblity of a data leak to a third party is always there, once a system is networked in some way.