Re:Airworthiness Directives; The Boeing Company Airplanes (2...
by ColinWright on Saturday February 05, 2022 @06:37AM
(#30220145)
Summary of the issue:
"The FAA received reports earlier this year of three incidents of display
electronic unit (DEU) software errors on Model 737 NG airplanes flying into
runway PABR in Barrow, Alaska. All six display units (DUs) blanked with a
selected instrument approach to a runway with a 270-degree true heading, and
all six DUs stayed blank until a different runway was selected. [...] The
investigation revealed that the problem occurs when this combination of
software is installed and a susceptible runway with a 270-degree true
heading is selected for instrument approach. Not all runways with a
270-degree true heading are susceptible; only seven runways worldwide, as
identified in this AD, have latitude and longitude values that cause the
blanking behavior."
(Note that this is all 6 displays on each plane, not 2 displays on each of three planes.)
The runways in question are:
* Runway 26, Pine Bluffs, Wyoming, USA (82V)
* Runway 28, Wayne County, Ohio, USA (KBJJ)
* Runway 28, Chippewa County, Michigan, USA (KCIU)
Re:Airworthiness Directives; The Boeing Company Airplanes (2...
by chrismorgan on Saturday February 05, 2022 @09:24AM
(#30221261)
The discontinuity in angle (that you loop back round from the highest value to the lowest value or vice versa) can lead to interesting issues when not treated carefully.
The reMarkable tablet’s file format contains an angle field for each point, which is the angle of movement, in radians clockwise from the positive x axis, range [0, 2π). For most tools (BallpointPen, CalligraphyPen, Marker, Pencil, MechanicalPencil), it’s the tangent from the last point, but for a few tools (Fineliner, Paintbrush, Highlighter), it’s the average of the last two line segments’ angles—not the tangent from two points ago to the current point, but the average of the last two segments’ tangents. The consequence of this is that if you’re drawing a line with one of these tools in the positive x axis direction, you’ll regularly end up with points with spurious angles, as the average of just above 0 and just below 2π is around π.
(There’s another field speed, calculated in pixels per sample, which also has this curious average-of-last-one-or-two-segments behaviour, so that I can synthesise both of these properties perfectly for all except the first point or two of every stroke, provided the stroke hasn’t been scaled or rotated. I also feel like grumbling about the fact that marker tilt is not recorded in the file, though it influences the width field in the CalligraphyPen and Pencil tools, which you might otherwise expect to be derived from some combination of pressure, tilt and speed.)
This is just a fun curiosity I observed when reverse-engineering it all (and I was really pleased that I predicted it as soon as I discovered the average-of-last-two behaviour, and that experimentation proved it to be so); I haven’t gone far enough to identify the effect of the angle property on rendering, but Fineliner and Highlighter certainly won’t use it (I suspect Paintbrush does).
My first two guesses on this Boeing issue are: some sort of mishandling of the point of angle discontinuity, or division by zero.
Re:Airworthiness Directives; The Boeing Company Airplanes (2...
by kloch on Saturday February 05, 2022 @10:16AM
(#30221849)
Software engineers seem to have a lot of problems with trigonometry and especially spherical coordinates/rotations. One recent example is MS FS2020 which despite being a clean-sheet redesign is still unable to render correctly or fly near the poles.
I used that guide to write quaternion functions for one of my projects. It is three times faster than the (also gimbal safe) trigonometric method I used previously. The quaterion functions can be found at the top of: https://github.com/kevinloch/bsrender/blob/main/src/process-.... The rotation quaternion is constructed at the bottom of https://github.com/kevinloch/bsrender/blob/main/src/init-sta.... The vector quaternion is constructed by simply copying the Euclidian x,y,z into i,j,k while setting r=0, and the output x,y,z is copied from i,j,k after rotation.
Beware my program uses a non-standard coordinate system where +y is to the left, being derived from equatorial coordinates used in astronomy where the x->y angle (Right Ascension) increases to the East. Removing the y-axis inversion/reversion steps in the quaternion functions should make them work with conventional coordinates.
The speed advantage of quaternions depends on the use case. If the points being rotated are natively Euclidian and you are performing the same rotation on a billion points then it's a clear winner as the expensive trig functions are only done once while the actual rotation steps are all + and *.
Re:Airworthiness Directives; The Boeing Company Airplanes (2...
by errcorrectcode on Saturday February 05, 2022 @12:30PM
(#30223428)
Quaternions are "non-intuitive" for people without a math background. If you're a professional software engineer, you should have a CS degree which includes a math background. I found 4x4 matrixes trivial in a computer graphics course because they were taught with proper examples in terms as they applied to camera and transformations. We re-implemented a subset of the OpenGL pipeline. If you don't understand the math, you can't hope to possibly understand how a 3D rendering pipeline works.
Cartesian <--> polar coordinate transformations applied to the real world must be done carefully because of the magnified error potential at boundary conditions. Again, heavy mathematics as a foundation are necessary to avoid major harm. Honestly, I don't think anyone except Professional Engineers should be allowed to work on critical flight control software. Boeing has been farming out software development to overseas contractors because they're cheaper ($9/hr), not because they're better.
Re:Airworthiness Directives; The Boeing Company Airplanes (2...
by smoyer on Saturday February 05, 2022 @10:47AM
(#30222184)
There are definitely cases where using polar coordinates or angles (with sin/cos/tan and their inverses) is the right tool for the job. The common problem with using trigonometry in software is that angles repeat every 2pi and tangents can overflow your math system (and in fact are undefined at 1/2pi and 3/2pi).
Many formulas can be reduced to operations on dy/dx but you still have to watch of a zero denominator (when used as a slope). You're right as this is certainly common in 2D games but to some degree, it was originally for performance reasons since you don't want to perform a bunch of trig operations when trying to obtain a reasonable refresh rate.
Re:Airworthiness Directives; The Boeing Company Airplanes (2...
by errcorrectcode on Saturday February 05, 2022 @12:25PM
(#30223363)
First, you have be able to spell "quaternions." :) I think you meant vectors, points, and 3x3 matrixes. 4x4 transformations have the advantages of specifying translations and scaling in 3-space where triples and 3x3 cannot.
Re:Airworthiness Directives; The Boeing Company Airplanes (2...
by smoyer on Saturday February 05, 2022 @09:36AM
(#30221410)
It's hard because ADs don't have a brief line of text that you can clip out (following HN guidelines) yet you don't want to have title that's multiple lines long. The title does indicate that it's not all planes ("Some") but fails on the bigger issue that it's a pretty limited set of airport runways.
From a software perspective (I spent a lot of time writing software for CAD systems and CNC equipment), the combination of certain latitude/longitude values and 270 degrees (which is Pi in Radians) sounds like a classic divide-by-zero problem.
We had a potentially less dangerous issue with a CAD system that could show the tool path of the generated CNC. The CAD system shared the path formulas with the CNC equipment and for a certain "design", the CAD system showed the tool immediately jumping to a location about two inches away. This had never been observed on the CNC equipment after years of operation. We loaded the same CNC into the milling machine without a tool or work piece and sure enough, the same instruction/coordinate combination caused the mill to jump those two inches at its maximum feed-rate. Needless to say, finding and fixing this bug became our top priority!
Re:Airworthiness Directives; The Boeing Company Airplanes (2...
by civilized on Saturday February 05, 2022 @10:24AM
(#30221949)
Your version is just obscure.
Obviously the problem has something to do with the 270 degree heading. Obviously the FAA is saying so. You're just making the headline confusing and uninteresting by omitting that.
Making an interesting point with imperfect precision is better than failing to say anything interesting at all.
I agree that "West" could have been improved by replacing with "some runways with a due West heading" but entirely dropping the interesting point, as the headline does now, is a cure worse than the disease.
Re:Airworthiness Directives; The Boeing Company Airplanes (2...
by __te__ on Saturday February 05, 2022 @09:43AM
(#30221494)
The PDF has a four sentence summary. The lazy critic did not quite reach the second sentence, which literally prohibits a selection of planes from landing on some airstrips due to a dangerous software bug (the details of the bug, which airstrips, and sort of why, is in the rest of the article — but it's pretty clear the lazy critic didn't make it past the post here).
If they'd read the whole PDF, they might have seen these bits:
"All six display units (DUs) blanked with a selected instrument approach to a runway with a 270-degree true heading, and all six DUs stayed blank until a different runway was selected."
And:
"An unsafe condition exists that requires the immediate adoption of this AD without providing an opportunity for public comments prior to adoption."
That's pretty serious, and indeed fits exactly with "some Boeing 737s can't land due West."
"The FAA received reports earlier this year of three incidents of display electronic unit (DEU) software errors on Model 737 NG airplanes flying into runway PABR in Barrow, Alaska. All six display units (DUs) blanked with a selected instrument approach to a runway with a 270-degree true heading, and all six DUs stayed blank until a different runway was selected. [...] The investigation revealed that the problem occurs when this combination of software is installed and a susceptible runway with a 270-degree true heading is selected for instrument approach. Not all runways with a 270-degree true heading are susceptible; only seven runways worldwide, as identified in this AD, have latitude and longitude values that cause the blanking behavior."
(Note that this is all 6 displays on each plane, not 2 displays on each of three planes.)
The runways in question are:
* Runway 26, Pine Bluffs, Wyoming, USA (82V)
* Runway 28, Wayne County, Ohio, USA (KBJJ)
* Runway 28, Chippewa County, Michigan, USA (KCIU)
* Runway 26, Cavern City, New Mexico, USA (KCNM)
* Runway 25, Barrow, Alaska, USA (PABR)
* Runway 28, La Mina, La Guajira, Colombia (SKLM)
* Runway 29, Cheddi Jagan, Georgetown, Guyana (SYCJ)
(The numbers are magnetic bearings, whereas the problem is apparently related to true bearing.)
The reMarkable tablet’s file format contains an angle field for each point, which is the angle of movement, in radians clockwise from the positive x axis, range [0, 2π). For most tools (BallpointPen, CalligraphyPen, Marker, Pencil, MechanicalPencil), it’s the tangent from the last point, but for a few tools (Fineliner, Paintbrush, Highlighter), it’s the average of the last two line segments’ angles—not the tangent from two points ago to the current point, but the average of the last two segments’ tangents. The consequence of this is that if you’re drawing a line with one of these tools in the positive x axis direction, you’ll regularly end up with points with spurious angles, as the average of just above 0 and just below 2π is around π.
(There’s another field speed, calculated in pixels per sample, which also has this curious average-of-last-one-or-two-segments behaviour, so that I can synthesise both of these properties perfectly for all except the first point or two of every stroke, provided the stroke hasn’t been scaled or rotated. I also feel like grumbling about the fact that marker tilt is not recorded in the file, though it influences the width field in the CalligraphyPen and Pencil tools, which you might otherwise expect to be derived from some combination of pressure, tilt and speed.)
This is just a fun curiosity I observed when reverse-engineering it all (and I was really pleased that I predicted it as soon as I discovered the average-of-last-two behaviour, and that experimentation proved it to be so); I haven’t gone far enough to identify the effect of the angle property on rendering, but Fineliner and Highlighter certainly won’t use it (I suspect Paintbrush does).
My first two guesses on this Boeing issue are: some sort of mishandling of the point of angle discontinuity, or division by zero.
In 3d I'm finding quternions to be sometimes better than vectors, but the learning curve has taken much longer.
Quaternions are popular because they are usually the fastest technique but are notoriously non-intuitive. This is the best guide I have found explaining them in a practical way: https://danceswithcode.net/engineeringnotes/quaternions/quat...
I used that guide to write quaternion functions for one of my projects. It is three times faster than the (also gimbal safe) trigonometric method I used previously. The quaterion functions can be found at the top of: https://github.com/kevinloch/bsrender/blob/main/src/process-.... The rotation quaternion is constructed at the bottom of https://github.com/kevinloch/bsrender/blob/main/src/init-sta.... The vector quaternion is constructed by simply copying the Euclidian x,y,z into i,j,k while setting r=0, and the output x,y,z is copied from i,j,k after rotation.
Beware my program uses a non-standard coordinate system where +y is to the left, being derived from equatorial coordinates used in astronomy where the x->y angle (Right Ascension) increases to the East. Removing the y-axis inversion/reversion steps in the quaternion functions should make them work with conventional coordinates.
The speed advantage of quaternions depends on the use case. If the points being rotated are natively Euclidian and you are performing the same rotation on a billion points then it's a clear winner as the expensive trig functions are only done once while the actual rotation steps are all + and *.
Cartesian <--> polar coordinate transformations applied to the real world must be done carefully because of the magnified error potential at boundary conditions. Again, heavy mathematics as a foundation are necessary to avoid major harm. Honestly, I don't think anyone except Professional Engineers should be allowed to work on critical flight control software. Boeing has been farming out software development to overseas contractors because they're cheaper ($9/hr), not because they're better.
Many formulas can be reduced to operations on dy/dx but you still have to watch of a zero denominator (when used as a slope). You're right as this is certainly common in 2D games but to some degree, it was originally for performance reasons since you don't want to perform a bunch of trig operations when trying to obtain a reasonable refresh rate.
https://news.ycombinator.com/item?id=21991087
From a software perspective (I spent a lot of time writing software for CAD systems and CNC equipment), the combination of certain latitude/longitude values and 270 degrees (which is Pi in Radians) sounds like a classic divide-by-zero problem.
We had a potentially less dangerous issue with a CAD system that could show the tool path of the generated CNC. The CAD system shared the path formulas with the CNC equipment and for a certain "design", the CAD system showed the tool immediately jumping to a location about two inches away. This had never been observed on the CNC equipment after years of operation. We loaded the same CNC into the milling machine without a tool or work piece and sure enough, the same instruction/coordinate combination caused the mill to jump those two inches at its maximum feed-rate. Needless to say, finding and fixing this bug became our top priority!
This seems like lazy, half-baked criticism.
How about "Some Boeing 737's cant land on some runways due to programming issue"
The current title is literally incorrect, they can all land due west just fine except for some particular runways
Obviously the problem has something to do with the 270 degree heading. Obviously the FAA is saying so. You're just making the headline confusing and uninteresting by omitting that.
Making an interesting point with imperfect precision is better than failing to say anything interesting at all.
I agree that "West" could have been improved by replacing with "some runways with a due West heading" but entirely dropping the interesting point, as the headline does now, is a cure worse than the disease.
If they'd read the whole PDF, they might have seen these bits:
"All six display units (DUs) blanked with a selected instrument approach to a runway with a 270-degree true heading, and all six DUs stayed blank until a different runway was selected."
And:
"An unsafe condition exists that requires the immediate adoption of this AD without providing an opportunity for public comments prior to adoption."
That's pretty serious, and indeed fits exactly with "some Boeing 737s can't land due West."