Moderators: jsumali2, richierich, ua900, PanAm_DC10, hOMSaR
LX015 wrote:In all seriousness, I wonder if IAG is now having 2nd thoughts about the LOI for 200 MAXs...
PW100 wrote:planecane wrote:PW100 wrote:Is 3 seconds sufficient to recognize a runaway trim in a stand-alone failure scenario (leaving aside that usually other issues be present at the same time)?
If we look at MCAS, it has a 9 second cycle. Should pilots be expected to disable MCAS after only 3 seconds, or should they allow at least a full MCAS cyce, and take action at the next cycle (after 3 seconds)?
Leaving aside the question whether the intermittent behaviour of MCAS would be recognizable as runaway trim (prior to the accidents).
The expectation is/was that the pilots were expected to recognize a runaway stabilizer (caused by MCAS or otherwise) within 3 seconds and begin the NNC. That's why, to me, it has always been completely irrelevant that MCAS was intermittent. The big failure that was missed is that the same thing that would cause MCAS cause a runaway stabilizer ALSO caused other issues simultaneously. This factor is the reason that I believe the lack of documentation of MCAS and specific training played a huge factor. The training could have been part of the iPad course. Simple instructions that if there was uncommanded nose down trim that the runaway stabilizer NNC should be performed first, regardless of other issues would have gone a long way. The information should have been provided that other alerts (single side stick shaker, unreliable airspeed, etc.) would likely occur simultaneously but that responding to the runaway stabilizer should take priority. This should have been part of the training and the QRH.
I understand what you're saying with the intermittent behaviour.
But then it would make not much sense to schedule MCAS cycle for 9 seconds, if Boeing at the same time expected the crew to shut it down after 3 seconds . . .
OldAeroGuy wrote:I don't think you understand the situation. The problem is that the pilots may do the right action and not see the plane respond quickly enough because the computer is overloaded. They will them think they have not taken the correct action and try something else.XRAYretired wrote:Just imagine for a moment spending a few seconds finding the QRH which then tells you to repond within 3 seconds. No it doesnt, nor does the EID because it is ludicrous.
Ray
No need to find the QRH as the response to a Stab Trim Runaway is a memory item, as stated many times on this thread..
RickNRoll wrote:I don't think you understand the situation. The problem is that the pilots may do the right action and not see the plane respond quickly enough because the computer is overloaded. They will them think they have not taken the correct action and try something else.[/quote]No need to find the QRH as the response to a Stab Trim Runaway is a memory item, as stated many times on this thread..
PixelFlight wrote:I don't think that the FAA "chose to leak", there are now expected to promptly communicate to the others administrations any important finding on the subject and consequently would loss credibility if there are not the first to announce the finding to the public.
planecane wrote:Interested wrote:
Great - get the NG back in production and everybody can feel safe again
Will you feel that way if it is determined that the same potential cause of runaway stabilizer (a microprocessor failure) exists on the NG as well?
PixelFlight wrote:DO-178 define "structural coverage criteria". This document resume well enough the subject on page 12 https://pdfs.semanticscholar.org/ba18/3 ... 3c6f1d.pdf
"
structural coverage criteria have to be achieved depend on the software level:
• Level C: 100% statement coverage is required, which means that every statement in the
program has been exercised.
• Level B: 100% decision coverage is required. That means that every decision has taken all
possible outcomes at least one (ex: then/else for an if construct) and that every entry and exit
point in the program has been invoked at least one.
• 100% MCD/DC (Modified Condition/Decision Coverage) is required for level A software,
which means that:
o Every entry and exit point in the program has been invoked at least once
o Every decision has taken all possible outcomes
o Each condition in a decision has been shown to independently affect that decision’s
outcome (this is shown by varying just that condition while holding fixed all other
possible conditions).
"
Revelation wrote:PixelFlight wrote:DO-178 define "structural coverage criteria". This document resume well enough the subject on page 12 https://pdfs.semanticscholar.org/ba18/3 ... 3c6f1d.pdf
"
structural coverage criteria have to be achieved depend on the software level:
• Level C: 100% statement coverage is required, which means that every statement in the
program has been exercised.
• Level B: 100% decision coverage is required. That means that every decision has taken all
possible outcomes at least one (ex: then/else for an if construct) and that every entry and exit
point in the program has been invoked at least one.
• 100% MCD/DC (Modified Condition/Decision Coverage) is required for level A software,
which means that:
o Every entry and exit point in the program has been invoked at least once
o Every decision has taken all possible outcomes
o Each condition in a decision has been shown to independently affect that decision’s
outcome (this is shown by varying just that condition while holding fixed all other
possible conditions).
"
"Every line executed" != "All logic verified correct for all range of inputs" and/or "all real-time requirements met".
737-8 MAX: "For all speeds higher than 220 Kts and trim set at a value of 2.5 units, the difficulity level of turning the manual trim wheel was level A (trim wheel not movable)." hivue wrote:PixelFlight wrote:I don't think that the FAA "chose to leak", there are now expected to promptly communicate to the others administrations any important finding on the subject and consequently would loss credibility if there are not the first to announce the finding to the public.
So why did they leak it instead of making just such a public announcement? CNBC is implying that there appears to be stuff currently going on between Boeing and the FAA that we do not know about and that is not business as usual and the old way of doing things. See the link in my last post in the immediately previous part of this thread.
737-8 MAX: "For all speeds higher than 220 Kts and trim set at a value of 2.5 units, the difficulity level of turning the manual trim wheel was level A (trim wheel not movable)." kalvado wrote:OldAeroGuy wrote:kalvado wrote:
But what exactly are the symptoms to be determined within 3 seconds? Sts is another source of trim movement without direct pilot command, and it happens often. So how to ensure response to actual runaway without many false alarms?
As Mentor Pilot says in his video, STS is making control forces easier. Runaway Stab is making it more difficult to control the airplane. If you're having to hold an increasing amount of uncommanded column force, it's a Runaway Stab.
Watch the video:
https://video.search.yahoo.com/yhs/sear ... tion=click
That is a great symptom, but is it actually detectable within 3 seconds and differentiated from turbulence offset or gradient of force in maneuver?
I can imagine 3 seconds response to engine warning sound on takeoff, but I suspect force feeling is largely a closed loop which can be consciously understood only when things are very wrong. I know where I want my car to go, and I don't really notice small glitches like a piece of stone under the wheel. It takes curb or a good pothole to start noticing
PixelFlight wrote:BoeingVista wrote:I disagree with that assessment its quite possible that Boeing has just run out of processing power for the amount of tasks the computer is required to perform.Freefall wrote:I think they will need change both (software and hardware) upgrades probably needed because now MCAS software needs to deal with more situations/scenarios and for that more processing power and memory will be needed.RickNRoll wrote:The problem is that the processor is an old one that does not appear to have enough power to run more complex time critical calculations.StTim wrote:I suspect that what happened was processor overload rather than BSOD type failure.
The "out of processing power" is very hard to believe in the context of a DO-178 compliant software development, especially for the transition from MCAS v1 to MCAS v2. From what have been released so far, the differences between the MCAS v1 and MCAS v2 is just a couple of relatively simple conditions. Even on a 30 years old processors those condition will not add more than a fraction of millisecond of processing time. It's not possible to properly certify for flight operation a computer + software combo with a such insanely small processing margin time.
aerolimani wrote:The way I read this section is that it is defining the power and capability that a trim system must have. To my reading, it's determining how much capability the system needs to have so that the pilot can achieve a fast enough response from the system. In other words, the 3 seconds is defining what the system needs to be capable of, not what the pilot's response time needs to be. This section also defines how the forces should not behave erratically as the system moves through its trim degrees.
I will post here the opening explanation for the section you are quoting. Not anywhere in this whole section, and certainly not in the explanation, is there mention of the actions of an automatic trim system, or its expected characteristics as regards pilot response time. I think it's important to quote the section's opening explanation, as it gives context to everything else contained in the section.33. Out-of-Trim Characteristics - § 25.255.
a. Explanation. Certain early, trimmable stabilizer equipped jet transports experienced “jet upsets” that resulted in high speed dives. When the airplane was mistrimmed in the nose-down direction and allowed to accelerate to a high airspeed, it was found that there was insufficient elevator power to recover. Also, the stabilizer could not be trimmed in the nose-up direction, because the stabilizer motor stalled due to excessive airloads imposed on the horizontal stabilizer. As a result, a special condition was developed and applied to most part 25 airplanes with trimmablestabilizers. With certain substantive changes, it was adopted as § 25.255, effective with amendment 25-2. While these earlier problems seem to be generally associated with airplanes having trimmable stabilizers, it is clear from the preamble discussions to amendment 25-42 that § 25.255 applies “regardless of the type of trim system used in the airplane.” Section 25.255 is structured to give protection against the following unsatisfactory characteristics during mistrimmed flight in the higher speed regimes:
(1) Changes in maneuvering stability leading to overcontrolling in pitch.
(2) Inability to achieve at least l.5g for recovery from upset due to excessive control forces.
(3) Inability of the flightcrew to apply the control forces necessary to achieve recovery.
(4) Inability of the pitch-trim system to provide necessary control force relief when high control force inputs are present.
RickNRoll wrote:OldAeroGuy wrote:XRAYretired wrote:Just imagine for a moment spending a few seconds finding the QRH which then tells you to repond within 3 seconds. No it doesnt, nor does the EID because it is ludicrous.
Ray
No need to find the QRH as the response to a Stab Trim Runaway is a memory item, as stated many times on this thread..
I don't think you understand the situation. The problem is that the pilots may do the right action and not see the plane respond quickly enough because the computer is overloaded. They will them think they have not taken the correct action and try something else.
SteinarN wrote:so... this is separate from the the MCAS software issue?From Aviation Week
It seems in fact like the latest problem is related to FCC overload. The article says the THS is slow to react to manual trim inputs from the thumb switches when simulating a trim runaway. Thereby forcing the aircraft into a steep dive before the THS finally starts reacting to the thumb switches. It is not clear if this problem can be fixed by a software update or if it requires time consuming hardware changes.....
PixelFlight wrote:In fact the FAA did communicate:
OldAeroGuy wrote:aerolimani wrote:The way I read this section is that it is defining the power and capability that a trim system must have. To my reading, it's determining how much capability the system needs to have so that the pilot can achieve a fast enough response from the system. In other words, the 3 seconds is defining what the system needs to be capable of, not what the pilot's response time needs to be. This section also defines how the forces should not behave erratically as the system moves through its trim degrees.
I will post here the opening explanation for the section you are quoting. Not anywhere in this whole section, and certainly not in the explanation, is there mention of the actions of an automatic trim system, or its expected characteristics as regards pilot response time. I think it's important to quote the section's opening explanation, as it gives context to everything else contained in the section.33. Out-of-Trim Characteristics - § 25.255.
a. Explanation. Certain early, trimmable stabilizer equipped jet transports experienced “jet upsets” that resulted in high speed dives. When the airplane was mistrimmed in the nose-down direction and allowed to accelerate to a high airspeed, it was found that there was insufficient elevator power to recover. Also, the stabilizer could not be trimmed in the nose-up direction, because the stabilizer motor stalled due to excessive airloads imposed on the horizontal stabilizer. As a result, a special condition was developed and applied to most part 25 airplanes with trimmablestabilizers. With certain substantive changes, it was adopted as § 25.255, effective with amendment 25-2. While these earlier problems seem to be generally associated with airplanes having trimmable stabilizers, it is clear from the preamble discussions to amendment 25-42 that § 25.255 applies “regardless of the type of trim system used in the airplane.” Section 25.255 is structured to give protection against the following unsatisfactory characteristics during mistrimmed flight in the higher speed regimes:
(1) Changes in maneuvering stability leading to overcontrolling in pitch.
(2) Inability to achieve at least l.5g for recovery from upset due to excessive control forces.
(3) Inability of the flightcrew to apply the control forces necessary to achieve recovery.
(4) Inability of the pitch-trim system to provide necessary control force relief when high control force inputs are present.
The FAA's language above is talking about the pilot's ability to recover from a runaway of the trim system, in either the nose up or the nose down direction. I'm not sure of the sense of your quoted sentence below
"The way I read this section is that it is defining the power and capability that a trim system must have."
The FAR 25.255 requires that the pilot be able to overcome the impact of a runaway stabilizer and the state it will leave the airplane in after a 3 second runaway. For instance, if the airplane is at Vmo/Mmo at the moment that the stabilizer runaway begins and the pilot takes no action for 3 sec and then begins to control the airplane via the elevators, the airplane must be able to recover from the overspeed and not exhibit any unusual flight control behaviors.
To make sure the airplane can meet this requirement, trim speed might need to be set at a low rate to make sure the airplane isn't badly out of trim after 3 sec. Is that what you mean?
By the way, here's the exact FAR language:
Sec. 25.255
[Out-of-trim characteristics.]
[(a) From an initial condition with the airplane trimmed at cruise speeds up to VMO/MMO, the airplane must have satisfactory maneuvering stability and controllability with the degree of out-of-trim in both the airplane nose-up and nose-down directions, which results from the greater of--
(1) A three-second movement of the longitudinal trim system at its normal rate for the particular flight condition with no aerodynamic load (or an equivalent degree of trim for airplanes that do not have a power-operated trim system), except as limited by stops in the trim system, including those required by Sec. 25.655(b) for adjustable stabilizers; or
(2) The maximum mistrim that can be sustained by the autopilot while maintaining level flight in the high speed cruising condition.
The 3 sec is in (a)(1)
7BOEING7 wrote:kalvado wrote:OldAeroGuy wrote:
As Mentor Pilot says in his video, STS is making control forces easier. Runaway Stab is making it more difficult to control the airplane. If you're having to hold an increasing amount of uncommanded column force, it's a Runaway Stab.
Watch the video:
https://video.search.yahoo.com/yhs/sear ... tion=click
That is a great symptom, but is it actually detectable within 3 seconds and differentiated from turbulence offset or gradient of force in maneuver?
I can imagine 3 seconds response to engine warning sound on takeoff, but I suspect force feeling is largely a closed loop which can be consciously understood only when things are very wrong. I know where I want my car to go, and I don't really notice small glitches like a piece of stone under the wheel. It takes curb or a good pothole to start noticing
When you're hand flying the 737 (if the airplane is in "trim") you'll notice immediately just like a pothole. With the autopilot is flying, if somebody is paying attention, might be a couple of seconds --if you're asleep at the wheel when the autopilot disconnect warning goes off you'll figure it out.
When fixing an aircraft you don't want to design in the next crash
“An average line pilot wouldn’t know what the hell they’re doing,” said one of the people, who said the uncommanded movement was not an erroneous activation of the MCAS function, which has been at the center of the twin crash investigations. The FAA’s view ultimately won the day. Boeing in a statement said it “agrees with the FAA’s decision and request, and is working on the required software.”
But the fix is expected to add months to the jet’s return to service, clouding an already complicated outlook for the 737 Max.
StTim wrote:The other thing, in terms of timeliness, is that if these chips are associated with real-time constraints is they won’t be running anything approaching a ‘normal’ OS. They’ll be no pre-emotive multitasking or anything like that (again, doesn’t help for worst case execution times). It’ll be single task, or you’ll have something like a cyclic scheduler where each application has a fixed share of processor time. If it is a cyclic scheduler, there may be options to increase the ‘share’ given to MCAS - there may be unused capacity, or they may be able to reduce the share given to other apps on the processor.
PixelFlight wrote:EDIT: In fact the FAA did communicate: https://www.faa.gov/news/updates/?newsId=93206
"On the most recent issue, the FAA’s process is designed to discover and highlight potential risks. The FAA recently found a potential risk that Boeing must mitigate. "
DenverTed wrote:I am guessing that is why some one in the FAA leaked this. They didn't like the way Boeing was able to get away with this without anyone knowing what they have been doing behind everyone's back.So this isn't MCAS, it is something in the MAX software, which is different from the NG software. And the manual trim wheel recovery is free and clear for the NG and the MAX, or where does the FAA stand on that right now? I guess the NG is flying, so they must not be too concerned with the safety of the manual trim wheel.
"This airplane is designed by clowns, who in turn are supervised by monkeys" BoeingVista wrote:Boeing and FAA initially disagreed on severity of "catastrophic" 737 software glitch.
https://theaircurrent.com/aviation-safe ... re-glitch/
So Boeing still don't really get the meaning of "safety is our first priority", it means not releasing a software fix with another deadly flaw, or minimising deadly flaws in the MAX by redesignating the risk as lower than its actual effect on the flyability of the aircraft via paperwork. The FAA rated the "glitch" as catastrophic where as Boeing rated it two rungs lower as "major"; FAA stuck to their guns for once and Boeing fell into line.When fixing an aircraft you don't want to design in the next crash“An average line pilot wouldn’t know what the hell they’re doing,” said one of the people, who said the uncommanded movement was not an erroneous activation of the MCAS function, which has been at the center of the twin crash investigations. The FAA’s view ultimately won the day. Boeing in a statement said it “agrees with the FAA’s decision and request, and is working on the required software.”
But the fix is expected to add months to the jet’s return to service, clouding an already complicated outlook for the 737 Max.
SteinarN wrote:From Aviation Week
It seems in fact like the latest problem is related to FCC overload. The article says the THS is slow to react to manual trim inputs from the thumb switches when simulating a trim runaway. Thereby forcing the aircraft into a steep dive before the THS finally starts reacting to the thumb switches.
xmp125a wrote:SteinarN wrote:From Aviation Week
It seems in fact like the latest problem is related to FCC overload. The article says the THS is slow to react to manual trim inputs from the thumb switches when simulating a trim runaway. Thereby forcing the aircraft into a steep dive before the THS finally starts reacting to the thumb switches.
Let's remember the cockpit recording from the ET crash. "Manual trim is not working". We debated ad nauseam whether they meant manual manual trim (wheel) or manual electric trim (switch).
This could be huge, if the problem was in the original MAX firmware, and was discovered only now. And is basically impossible to prove or disprove that the actual processor behaved this way when ET had problems trimming -, as in all real-time embedded systems. Sole fact that it exists is a disaster for Boeing (remember Toyota lawsuit?).
zhetenyi1973 wrote:This is simply not true. It looks like you never heard of OSE which is an Real-Time OS and even Linux is capable to run RT applications. Of course you have to patch the kernel for it.
In an RT OS you can define hard priority between processes meaning a higher priority process is scheduled immediately if it wants to run. Of course you can starve out lower priority
processes if you are not careful. You can even have higher priority processes than interrupts, meaning the kernel will note the interrupt, but the handler code will be run later.
Most probably something similar happened here, so the solution is simply to increase the priority of the process which handles that particular data. Or the message dispatcher has to
prioritize these kind of data/messages over other data/messages in case there is only a simple loop in the code.
BoeingVista wrote:Also, from the article I posted above it sounds like the FAA went looking for this failure mode and were not really surprised when the aircraft didnt react as it was supposed to
par13del wrote:RickNRoll wrote:I don't think you understand the situation. The problem is that the pilots may do the right action and not see the plane respond quickly enough because the computer is overloaded. They will them think they have not taken the correct action and try something else.No need to find the QRH as the response to a Stab Trim Runaway is a memory item, as stated many times on this thread..
xmp125a wrote:
Let's remember the cockpit recording from the ET crash. "Manual trim is not working".
xmp125a wrote:
IF the problem was in the original software, not introduced with MAX 2.0. Either way this is potentially worse than MCAS issue:
1) IF the original firmware had the same problem, it throws a very different light on ET crash, where it would mean that it is the yet unknown problem, which may prevented ET crew from saving the plane, even when following the checklist, and obviously there are scenarios that overload the safety-critical CPU (perhaps there are more, and FAA found only one of them)
2) IF the problem was introduced with MCAS 2.0 then it looks disastrous for Boeing since they unknowingly introduced NEW failure mode.
PixelFlight wrote:The "out of processing power" is very hard to believe in the context of a DO-178 compliant software development, especially for the transition from MCAS v1 to MCAS v2. From what have been released so far, the differences between the MCAS v1 and MCAS v2 is just a couple of relatively simple conditions. Even on a 30 years old processors those condition will not add more than a fraction of millisecond of processing time. It's not possible to properly certify for flight operation a computer + software combo with a such insanely small processing margin time.
xmp125a wrote:BoeingVista wrote:Also, from the article I posted above it sounds like the FAA went looking for this failure mode and were not really surprised when the aircraft didnt react as it was supposed to
With bot Lion and ET investigation still ongoing and this being unprecedented situation for a long time, perhaps they got a hint from NTSB? "Guys, can you check this next time when you are in MAX sim?". These unexplained traces and voice recordings are certainly being one of the main mysteries the investigation team needs to solve, so I would not be surprised.
AFAIK FAA is on much better terms with NTSB than NHTSA is... (who is fighting NTSB recommendations)
Amiga500 wrote:xmp125a wrote:Amiga500 wrote:2. Boeing cannot realistically change the computing hardware within 24 months. They would have to re-certify the whole architecture (S/W and H/W). That would be an absolute nightmare scenario.
Let's take a step back.Remember when everyone were shaking their heads how on Earth MCAS V1.0 found its way to production?
A bit of conspiracy teory, but plausible one: what if "proper" MCAS design was tested during MAX development but found to be too demanding for the flight computer? And then MCAS 1.0 with its fatal flaws was born, and seemingly stupid design decisions, like use 1 sensor only, alternate sensor between the flights?
Is that really out of the question?
Ah, nah, can't really believe that.
Trying to do that would leave a paper trail - which would have ended up in folks being prosecuted before now.
xmp125a wrote:Why do you assume Boeing's code is DO-178 compliant?
BoeingVista wrote:Neither answer is good at this point, either way FAA now has to crawl over every aspect of the MAX control logic challenging every one of Boeings assumptions all the way back to the NG.
JerseyFlyer wrote:This seems to be a test of what happens when a microprocessor is broken, i.e. a test of adequate redundancy, which neither Boeing nor FAA tested for previously. Puts both in a bad light.
Interested wrote:Isn't it just the ultimate compromise of a plane that's proved to be a disaster?
Revelation wrote:JerseyFlyer wrote:This seems to be a test of what happens when a microprocessor is broken, i.e. a test of adequate redundancy, which neither Boeing nor FAA tested for previously. Puts both in a bad light.
I've read at least four different accounts so far (CNN, Bloomberg, AvWeek, AirCurrent) and all say the issue is the trim system is not responsive enough, and none say it's an issue with a broken microprocessor, or a lack of redundancy.
XRAYretired wrote:xmp125a wrote:par13del wrote:I don't think you understand the situation. The problem is that the pilots may do the right action and not see the plane respond quickly enough because the computer is overloaded. They will them think they have not taken the correct action and try something else.
So to speculate, the ET pilots understood it was MCAS, initiated the appropriate NNC but when the response was not immediate they moved on?
IF the problem was in the original software, not introduced with MAX 2.0. Either way this is potentially worse than MCAS issue:
1) IF the original firmware had the same problem, it throws a very different light on ET crash, where it would mean that it is the yet unknown problem, which may prevented ET crew from saving the plane, even when following the checklist, and obviously there are scenarios that overload the safety-critical CPU (perhaps there are more, and FAA found only one of them)
2) IF the problem was introduced with MCAS 2.0 then it looks disastrous for Boeing since they unknowingly introduced NEW failure mode.
Interested wrote:The CNN report claims there is an issue with the microprocessor that leads to the nose pointing down if the chip fails and this cannot be recovered quickly enough by pilots
It almost seems to suggest that if the pilots could correct the problem quick enough it wouldn't be such a big thing?
xmp125a wrote:par13del wrote:RickNRoll wrote:I don't think you understand the situation. The problem is that the pilots may do the right action and not see the plane respond quickly enough because the computer is overloaded. They will them think they have not taken the correct action and try something else.No need to find the QRH as the response to a Stab Trim Runaway is a memory item, as stated many times on this thread..
So to speculate, the ET pilots understood it was MCAS, initiated the appropriate NNC but when the response was not immediate they moved on?
zhetenyi1973 wrote:StTim wrote:The other thing, in terms of timeliness, is that if these chips are associated with real-time constraints is they won’t be running anything approaching a ‘normal’ OS. They’ll be no pre-emotive multitasking or anything like that (again, doesn’t help for worst case execution times). It’ll be single task, or you’ll have something like a cyclic scheduler where each application has a fixed share of processor time. If it is a cyclic scheduler, there may be options to increase the ‘share’ given to MCAS - there may be unused capacity, or they may be able to reduce the share given to other apps on the processor.
This is simply not true. It looks like you never heard of OSE which is an Real-Time OS and even Linux is capable to run RT applications. Of course you have to patch the kernel for it.
In an RT OS you can define hard priority between processes meaning a higher priority process is scheduled immediately if it wants to run. Of course you can starve out lower priority
processes if you are not careful. You can even have higher priority processes than interrupts, meaning the kernel will note the interrupt, but the handler code will be run later.
Most probably something similar happened here, so the solution is simply to increase the priority of the process which handles that particular data. Or the message dispatcher has to
prioritize these kind of data/messages over other data/messages in case there is only a simple loop in the code.
