I was reading up on the Primary Flight Computer (PFC) of the 777, just out of curiosity.
It's a triple redundant system, that is there's 3 separate PFC systems. That's not too surprising.
What did surprise me was that each of the 3 PFCs has 3 channels, and each channel is a CPU from a different manufacturer (AMD, Motorola, Intel). The reasoning is that any flaw in any particular cpu design would be outvoted by the other two.
They appear to use 3 different compilers for this reason (Ada), one for each processor. Seems like the I/O and endianness of the various chips would add complexity too.
I wonder if the added complexity makes it a net win or loss for safety? I guess a win, since that's what they do.
This reminds me of an article I read about the Space Shuttle's flight control system. Five computers on board, with 4 running redundantly and the fifth on backup.
> Q. How are actuators controlled?
> A. For the aerosurface actuators, each of the four computers sends out an independent command on an independent bus. With no failures, the commands should be identical. The voting is done at the actuator using a hydraulic voting mechanism, called a force-fight voter. In it, there are four hydraulic ports called secondary ports, each commanded by one of the four GPCs. The secondary ports go into the primary ports, which are heavy-duty actuators that connect to what's called a "summing bar," which is no more than a massive steel rod. If there are three good computers and one bad one, the three good commands physically out-muscle the fourth. This limits the control authority a little bit--we don't get the total force we'd like to get, but there's still enough power to control the vehicle. If you have a large enough pressure differential for a large enough time, the port is hydraulically bypassed, which relieves the pressure in that one port. The remaining three ports then regain their full authority.
Homer: Well, today's the day for Homer J. I know I'm
gonna win this time.
Lenny: Yeah? How come?
Homer: Union Rule 26: "Every employee must win Worker of
the Week at least once regardless of gross
incompetence, obesity or rank odor."
Mr. Burns: Compadres, it is imperative that we crush the
freedom fighters before the start of the rainy
season. And remember, a shiny new donkey for
whoever brings me the head of Colonel
Montoya... Hmm? What? Oh! ...and by that I
mean, of course, it's time for the Worker of
the Week Award. I can't believe we've
overlooked this week's winner for so very,
very long. We simply could not function
without his tireless efforts. So, a round of
applause for this inanimate [steel] rod.
This has been normal practice on airline computers for decades. The 757 used dual systems (the third being the pilot). Each channel:
1. used a different CPU architecture and brand
2. used different circuits
3. used different algorithms
4. used different languages
5. were developed by independent teams
6. with a third independent team to verify there were no inadvertent similarities
If the two channels disagreed, they were automatically electrically isolated, and the pilot was notified and was expected to take over.
>They appear to use 3 different compilers for this reason (Ada)
I understand why Ada is used for safety-critical applications, but I have to wonder: Does the fact that Ada is a relatively old and unfriendly language lead to more bugs than it prevents? My mind would probably go blank if I had to stare at Ada code for 8 hours a day.
What if we used Haskell for all non-realtime safety-critical functionality in aircraft? With a few extra rules to prevent stack overflows, I think I'd trust a million-line Haskell program over a million-line Ada program (although it would probably be more like ten-thousand-line Haskell program vs million-line Ada program).
Ada is proven in this area and generates fast, efficient code that is suitable for embedded systems. Ada's last revision is 2012. What do you find unfriendly?
I would most certainly not trust Haskell over Ada in embedded system work.
As an aside, I've been playing with learning Ada for a while (and all of the books I have from the last time poked at it are very out of date). Do you happen to know of any good references, online (Better!) or off?
Yeah, I would avoid trusting something hard-realtime to a language with lazy evaluation and garbage collection, even if it's quite trustworthy for other purposes.
(IIRC, these programs don't even use malloc, let alone garbage collection :)
MISRA discourages use of malloc (because you can deviate with clear documentation as to why) but it's not at all unheard of. That said, many embedded systems don't come with a usable implementation of malloc so the safe default is to write your own memory manager (safer but not always possible: use a well tested one) that uses static memory pools to allocate dynamic memory.
Any time you're using malloc() you run the risk of running out of memory, which is a very very bad thing for a safety-critical embedded system. Statically allocated, fixed-size things are good, as are algorithms that are designed not to require O(n) space to perform their processing.
There are many safety-critical systems that aren't hard realtime. Radio transponders, human interface systems, life support systems.
In fact, I'd say a great way to do it would be to implement all the hard realtime bits in some low-level, pain-in-the-ass language like Ada and then wrap all that unpleasant stuff in a high-level language that is very unfriendly to implementation bugs (like Haskell).
>> Radio transponders, human interface systems, life support systems.
Don't think you know what a hard real time system is. Both radio transponders and life support systems have to be hard real time. Motors and antennas don't magically communicate with your userland "apps," they're controlled by precisely timed code. The "human interface systems" (could you have brought to the conversation a more generic term?) to all of these are often, too, hard real time because that's the easiest way to prove something is safe and test the edge cases. For all intents and purposes, anything "soft real time" has a kernel and kernels are monolithic disasters waiting to happen for anyone who needs timing guarantees (hint: if your life depends on it, it needs timing guarantees).
On top of that is the unfriendliness of Haskell to the real world of hiring (and this is Boeing for godzilla's sake) and it's lack of proper testing in such an environment, although I'm sure there are those who use it in embedded.
>Motors and antennas don't magically communicate with your userland "apps," they're controlled by precisely timed code.
Motors and antennas are usually managed by hardware or dedicated uCs, not PFC software. Aircraft aren't running their telemetry off GnuRadio, and aircraft PFCs sure as hell aren't worrying about servo timing.
"Human interface systems" I thought would be self explanatory; pilots don't care if their plane UIs take 5us or 5ms to update. They can't react on those time scales anyway. Hell, you could probably code all the user-facing avionics stuff in Javascript and be fine.
> pilots don't care if their plan UIs take 5us or 5ms to update
Hard real-time doesn't mean "fast", it means having guaranteed upper bounds on response time. In order to get those guarantees, uninteruptable code paths need to be short and critical parts of the systems need to be simple, which often also leads to fast response. However, the difference between soft and hard realtime systems is the guarantees.
A soft real-time system that has a 5ms mean update time but has a 1e-6 chance of taking 10 seconds is much less useful than a hard real-time system that has a 15ms mean update time with a hard upper-bound of 50ms.
Which is why Rust is so interesting. It has deterministic upper bounds on performance. Not many new languages have this feature. Should eventually be useful for real-time systems and game developers.
But based on my meager experience in the language, I disagree that Ada is a massive pain in the ass to program in. It's probably less verbose and friendlier than Java, for example. Certainly easier than programming in C, and much less prone to fatal mistakes.
Do you have any links about the upper bounds of performance in Rust? I have a passive interest in embedded and Rust and that sounds pretty interesting.
You know, there are other languages than Haskell doing interesting things. Ada2012 for example, introduced design by contract with support for formal verification in conforming subprograms. This may be a near term more practical path than dependent types. Highly interesting.
I am a big Haskell fan but no, just, no. That would be a terrible idea because of how inherently unpredictable lazy evaluation is. Replace "Haskell" with OCaml or SML though, and I definitely agree.
Also as others have commented there are usually special requirements for embedded systems that may even occasionally require one to drop down to assembly (e.g. to get the code in the right place to execute if you're on bare metal).
This sounds like a gross misunderstanding of the kinds of guarantees made by Haskell's static systems.
The closest you're going to get it something like Atom [0] which is used to program a few different hard realtime systems. If you look at the Atom docs, however, you'll quickly find that programming in Atom is nothing like programming in Haskell---it's merely embedded there. The type system helps to ensure that your embedding does falter, but most of the errors still live in the sublanguage and I'm not sure how far Haskell's type system goes toward reducing those.
Avionics software is written in an environment where, _if_ such a problem as a programming language being "old and unfriendly" introduced bugs, that would have been noticed and mitigated.
What's so great about Haskell? It has no particular safety features compared to other languages, I think.
It won't help with with static analysis of any numeric types (though you can turn bad conversions into type errors, it can't tell if an explicit conversion is right or not) and the timing of anything is really hard to reason out.
The things that matter in critical embedded systems are typically not captured by type systems: memory boundedness, running time upper bounds, overflows,... For these things even (controlled) C is a better option than Haskell today.
> I wonder if the added complexity makes it a net win or loss for safety? I guess a win, since that's what they do.
The chance of one or more of the systems failing actually triples (OR), but the chance of all three failing (AND) decreases, which is what redundancy provides. Basic probability.
It means that there's an increased chance of bugs overall, yes, but a decreased chance of bugs that affect the overall flight, as it means that many more bugs will be caught and dealt with before they start affecting things majorly.
It doesn't save you from flaws in the design specs, though, or if everyone made the same faulty assumption.
As I've found myself: the best way to test an implementation of a data structure is to compare it against another implementation (preferably the simplest implementation possible - singly linked list, anyone?) and assert that they exhibit identical behavior.
Probably an overall win for safety, redundancy, and (maybe more importantly) security. That said, considering the number of different exploits that have been assembled for large attacks in the past (how many zero-days were in Stuxtnet?), I wouldn't completely rule out the possibility that the flight systems were hacked. This flight may not even have been the primary target, but rather a test of the attack vector, with the attacker finally directing the aircraft out over a big, deep body of water where it would eventually run out of fuel and eliminate most of the evidence.
More components obviously reduce the reliability, but if the likelihood of failure of each of those redundant systems are independent (and to some degree even if they are dependent), at a high-level I believe it's just P(failure of system 1)P(2)P(3), so the likelihood of failure could pretty easily be made infinitesimal. On the other hand, there are lots of plane flights. :-)
Anyone interested in this event or feeling inclined to speculate on the cause, mechanisms, and outcomes of the disappearance of Flight 370 should read a couple of the most recent threads on the topic over at airliners.net[1]. Their forums are the equivalent of HN for pilots and other aircraft professionals and are a fascinating read anytime an aircraft event is worth discussing.
If this was a movie plot it would be bashed for being unrealistic ...
"It doesn't make any sense somebody could hijack a plane that easily - you know, just deactivate the transponder and be gone - it's not that simple, of course - that would be ridiculous - and there is radar everywhere. Also the earth is covered with photo satellites - they would find the plane in no time - you know, a plane is a pretty big thing - haha - so anyway, bit naive, but the acting was alright - so if it wasn't about the transponder plot hole I'd give it a solid 8 ..."
This seems like a great place for me to add my wild and crazy crack pot 99.99% likely to be total nonsense theory to the cacophony of other similar theories... which would make a great plot device for a movie none the less. I'll give you the cliff notes version
When handing over from one ATC to another, MH370 adopted the identity of another plane in the area, and the other plane switched off it's transponders (let's call this other plane AB123). Leading to a scenario where the whole world is looking for a plane in the sea when it's actually airborne, but just happens to look like another plane on radar, and they landed it at some backwater airport (AB123's destination) that's under terrorist control (for example, how big a team would you need to take over Port Blair Airport on the Andaman islands? I'm guessing not very many, and no would be any wiser if you ran it as normal)
But why do this? Because whoever stole this plane needs to be able to fly MH370 into someones airspace unnoticed to do something bad, and flight AB123 is scheduled to fly into that airspace sometime soon, but if flight AB123 had been hijacked, or had gone missing, it would raise alarms. But to the outside world, flight ABC123 is fine, it's MH370 that everyone is worried about... but flight AB123 is MH370.
So where is AB123? I don't know. Maybe thats the plane the oil rig worker saw crash, or maybe they figured out some other way to hide it. Perhaps both planes flew to AB123's destination, but with one flying directly above the other so that it looks like one plane on radar (I don't know how Radar works but this would work for a movie) Also, AB123 might not be a passenger jet, it could be a cargo plane, or some other kind of plane that doesn't come with a bunch of passengers that people would miss.
Anyhoot, that's my crazy theory and even I don't believe it, but a small part of me hope's it's right because the people on Flight MH370 could still be alive.
At the very least, I think this is a good plot for a movie.
Complication: when the plane's "secondary radar" stopped (the transponders that report things like ID and altitude), both Malaysian and Vietnamese "primary radar" could still see it (the unassisted bounce back of the radar's radio waves). If they saw two biggish pips in the general vicinity they'd likely have said something by now, at least the Vietnamese, who've got to be getting annoyed by Malaysia's handling of this. E.g. per Wikipedia 'According to the Vietnamese deputy minister of transport, Pham Quy Tieu, "We informed Malaysia on the day we lost contact with the flight that we noticed the flight turned back west but Malaysia did not respond."'
Sorry, I wasn't clear enough, and thinking further, probably wrong on the main point:
You postulate two planes in the same area, that would look roughly the same on primary radar when their transponder was off (or maybe I misread you/assumed incorrectly about both looking big, see below). "Biggish" in that the 777 is a rather large aircraft with a presumably large radar cross section, "pip" as in a blob of light appearing on the radar's screen.
Going further, when they looked at the recordings of what their radar(s) saw, they'd see one "biggish pip" suddenly returning transponder information and another stop ... it's hard to imagine coordination to the split second, although it's possible.
Ah, I see one way in which I could be wrong: assuming the use of a small jet, it could be configured with a powerful enough transponder to simulate the 777's. So both pips would not necessarily be big, and if the location was carefully chosen maybe the small jet's wouldn't be seen by the radars. And that's more likely, after all, if they had a big jet to start with....
So what you're saying is I'm 100% correct and this is definitely what happened?
But back to being serious for a second. If mh370 really did keep on flying for five hours on the route that has been suggested, is there any other way it could go unnoticed? I'd like to think that it's impossible for something the size of a 777 to fly unhindered through the sky over several countries post 9/11. But then again, I had hoped someone couldn't make a plane vanish seemingly at the flick of a switch.
You seem to know your onions, is it possible to have two planes flying close enough together that they show up as one blip on radar? What's the pixel to kilometre ratio on those things?
Heh, I deduced a way it might be possible, assuming sufficient coordination.
I don't know specifics of radar, just the general principles. The major possibility here is that your suggested transfer of which transponder is saying "I'm MH123 at the same altitude" happened at a range where no radar would be giving a good enough return from the putative small jet assuming the role. Which upon review wasn't the scenario you were positing.
And if it was giving enough of a return to be seen, especially in retrospect as experts reviewed it, well, we'd have heard about it by now.
But if AB123 was big, we'd really have heard about it and it's near collision with MH370, or someone would be wondering why AB123 moved really quickly a noticeable distance at the same time MH370 went off the air. Or perhaps AB123's altitude was different, they were far enough the radars' couldn't tell that, and it's transponder was customized to lie about the altitude.... But people would still wonder, and would be questioning AB123's flight crew if they saw anything, etc. etc.
(I'm tired enough the above isn't entirely coherent, but it'll give you some things to chew on.)
Again, I would like to stress that I know all of this is unlikely, but there's is no reason why both planes would need to coordinate this down to the second. Mh370 goes offline, takes an hour to get into position with ab123. Then they make the switch.
Once mh370 goes missing, it stays missing. The trick is in making it look like ab123 is behaving normally. And while everyone is distracted by the search for mh370, I wonder how closely they would be looking at irregularities in other flights that aren't missing and aren't reporting any problems.
That being said, this seems like fodder for conspiracy theories and click throughs. Under normal circumstances, yeah, I bet it's hard to disable. However, if we assume the plane crashed, we know there was a massive malfunction -- seems more likely to me that it was a part of that.
I am not sure the WSJ cares much about click throughs. They are a subscription based-service. There are no ads on that page, at least not when I open up a browser with no adblocker.
I reach for occam's razor almost reflexively; I am inclined to think that the plane will be found around the area we lost contact.
However, the fact that India and the US is deploying so many assets on the other side makes me suspect they might have some credible leads. I am guessing India is possibly working more with the US than anyone else; given that India wouldn't want China to know what capabilities they have there.
It's getting to the point where whenever I see someone invoke Occam's Razor, I stop reading. People seem to think it means "The explanation is always simple", but what it actually means is "the hypothesis with the fewest assumptions should be selected."
On the disappearance of MH730 it seems a lot of people are happy to make the unfathomably large assumption that this was "probably" a catastrophic mechanical failure and that the plane has crashed into the sea, despite the conspicuous absence of any evidence for this scenario such as mayday calls, or a wreckage and now, in the face of overwhelming evidence that directly contradicts the theory that the plane has crashed (because it appears to have been under the control of a skilled pilot for five hours after it went missing, and skilled pilots are usually pretty good at landing planes) people are still positing the notion that the plane has crashed and that Occam's Razor somehow supports this point of view.
In short, "the most likely explanation" in this case, is the one that makes a boat load of wild assumptions.
Everyone seems to be jumping on the hijacker theory, but I have yet to see any evidence to contradict the theory of a fire aboard the plane. It explains the sudden course change, the failure (or deliberate shutdown) of some electrical circuits, and the altitude change (an effort to starve the fire of oxygen in the unpressurized regions of the aircraft).
It seems like aircraft fires occur more often than hijackings. Is there any reason at this point to prefer the hijacking theory, other than that it's a bit more sensational?
Responding to mpyne: you can envision scenarios where the fire took out their radios.
TrevorJ is a lot closer to the mark, although it wasn't the engine system phoning home, it was some sort of generic hourly "ping" with no other content (since the airline didn't sign up for the service that would have done more). Since these were pings from or to IMARSAT geosync satellites, very rough estimates of where the plane could be have been were made from them. I assume based on which satellites heard them (vs. ones over the horizon), perhaps comparing time-stamps and transit times to 22,000 miles in orbit, etc.
But of course the bottom line is that these pings went on for hours, which evidently would only stop when the engines stopped for whatever reason. That makes a plausible fire scenario more complicated.
That doesn't contradict the fire theory, though. It simply means that the fire didn't directly bring the plane down, but it could still have incapacitated some of the systems and possibly the crew.
I get the feeling no one has a clue yet. It is easy to come up with theories... e.g.
Malfunction in plane - transponder turns off - cabin loses pressure (and everyone on plane goes unconscious or similar) - because cockpit is locked crew does not manage to do anything in time - plane keeps on going - fuel runs out.
of course that is probably totally wrong.
One thing though - if it did fly low over land - I would expect at least someone would have used their cell phone - so I would rule out that option.
I haven't seen any explanation of the statement that the plane's location was thought to be within one of two "corridors" in completely different places -- a northern one extending to Kazakhstan and a southern one extending into the southern Indian Ocean. Is this indeterminacy expected? Is it the result of some sort of geometrical symmetry? I imagine someone here knows?
The "corridors" are actually geometrically symmetrical arcs as you suspect, somewhere around which it's believed the plane traveled until the pings stopped, presumably because the engines stopped running.
Thanks! According to sources [1, 2] there was a period of time during which it was pinging multiple satellites. Surely this symmetry doesn't persist in a dataset comprising pings at different times to different satellites (which themselves are moving)?
They're in geosynchronous orbit, so they rotate with the earth, are always over the same spot on earth at the equator.
Don't know which satellite series is used for this service, but the Inmarsat constellations aren't particularly large: http://en.wikipedia.org/wiki/Inmarsat#Satellites, so it could be they only got solid data---and it's not very specific---from one satellite.
I also wouldn't put much confidence in mass media reports saying "satellites", and the Wikipedia plural use is probably based on them.
The map I directed to you was apparantly an enhanced one from the NYT; here's one with many more details figured in: http://www.nytimes.com/2014/03/17/world/asia/malaysia-airlin... although I wouldn't treat those boundaries as gospel, there's likely more slop in the real estimates derived from the satellite.
>Until just a few years ago, the satellite communication system used by jetliners didn't include data on an aircraft's location in the pings, the electronic equivalent of handshakes used to establish initial contact.
I have a personal rule to date-time stamp all data collected from experiments. I'd add GPS if my experiments weren't all stationary. The extra bit of meta-data is a lifesaver if I do something dumb and have to reconstruct what I was doing when I collected the data, for instance correlating the data with my notes or other information that I gather.
This article alludes to one circuit killing both transponders, but I'd seen reported elsewhere that there was a 14 minute gap between when the transponders became innactive. Wouldn't that gap lend credibility to them not being disabled by a single circuit?
That patent seems like a thin hook to hang a conspiracy theory off of. It looks like a run-of-the-mill "optimize placement of stuff in a slightly different way than other people have done" patent, of which there are at least hundreds yearly.
um, "optimize placement of stuff in a slightly different way than other people have done" and save billions of dollars over the span of time, due to very high price of silicon wafers?
Most likely not; it's just another minor process variation, like the thousands of such patents that exist. Is there evidence that this patent is a particularly novel or important one?
And furthermore, what motive would someone have to knock off the inventors when they no longer even own the patent? If you look in the document, you can see that it has an single Assignee, Freescale Semiconductor. When a patent has been "assigned", the original inventors give up any proprietary rights in the invention to the Assignee, which is the normal process with corporate patents.
The article talks about needing to pull a circuit breaker to kill the transponder - I thought the transponder had a mode selection switch on the pedestal that could be set to standby; is there something else to it that I'm missing?
Moving around the plane opening hatches and tinkering with equipment requires there to be at least a few people. One to do the work, one inside the cockpit managing the flight and one looking after the passengers. All of them you would assume would have guns to keep the passengers from simply rushing them.
Getting multiple weapons past security surely means an inside job. And then what is the motivation for multiple people wanting to hijack this particular plane ?
Flight deck doors are secure also, and the first action on attempted hijack is divert to the nearest suitable. It looks increasingly likely that one or both pilots remained in control.
Cargo. The cargo list has still not been released. It is speculated that the cargo was heavy as the max amount of passengers was 50 less than the number of seats.
Here is my conspiracy theory: If you were the FSB, you would want to distract popular attention from events in the Ukraine. A lack of news coverage of the events in Crimea takes the heat off Western leaders to look tough.
Is there any legitimate reason for the pilot to disable the transponder? It seems like they should make it more difficult than just throwing a breaker in the cockpit.
> Is there any legitimate reason for the pilot to disable the transponder?
Yes, of course -- any piece of electronic equipment might (a) begin to misbehave and interfere with other equipment or produce misleading results, or (b) catch fire and emit smoke into the flight deck, or (c) both. It's common sense to have a way to disable any piece of equipment on short notice.
I played a small part in the design of NASA's Space Shuttle many years ago, and we definitely kept the possibility of equipment failure in mind at all times.
> It seems like they should make it more difficult than just throwing a breaker in the cockpit.
On board an aircraft, the pilot has the highest authority. You don't expect to have to protect the aircraft from him -- more the reverse. That is why, when a pilot goes crazy, the results are usually catastrophic.
The 777 is fully FBW apparently and many (all?) sensors communicate wirelessly. What are the chances that it was hacked by a passenger or remotely and taken over this way?
I don't have direct experience with the 777, but do with the 787 and other aircraft systems. I am not aware of any wireless sensors. There are a lot of sensors which communicate with the various computers over multiplexed wired data buses.
ARINC 429 is a legacy, but still heavily used, digital data bus.
ARINC 629 is used on the 777.
ARINC 664 is used on the 787 (and Airbus A380).
The military systems and some commercial systems also use MIL-STD-1553 and other digital busses.
Occams razor "states that among competing hypotheses, the hypothesis with the fewest assumptions should be selected".
What you've done is make a wild assumption, that would require a lot more assumptions to be true in order for your exploding plane theory to be true. Which is about as far away from Occam's Razor as you can get.
I wish people would stop saying "Occams Razor" and then inserting any old jibber they want, because they feel they've apparently qualified it by saying Occams Razor, even though they have no idea what Occam's Razor actually is. It's lazy and hollow reasoning.
No. The latest evidence shows that it flew on for hours afterwards and continued responding to satellite pings. If it exploded at the point where the transponder went offline, debris would have been found in that area by now.
Occam's razor is that nuclear power plants don't exist, they're just coal power plants (which already existed) with a story about nuclear power being possible. After all, do you have any idea how complicated controlled fission would have to be? It's easier if it doesn't exist.
The problem with this "theory" is that it doesn't explain all the evidence. Sure, a hijack would have to be way more complicated than a mid-air explosion, just like a nuclear power plant would have to be way more complicated.
But a complicated set of transponders turning off with sudden radio silence is exactly what happened. Plus, if it was a mid-air explosion - where are the pieces?
>Occam's razor is that nuclear power plants don't exist, they're just coal power plants (which already existed) with a story about nuclear power being possible. After all, do you have any idea how complicated controlled fission would have to be? It's easier if it doesn't exist
This is ridiculous. An elaborate conspiracy to fool people into believing in nuclear power isn't simple at all. Not to mention events like Chernobyl
It's a triple redundant system, that is there's 3 separate PFC systems. That's not too surprising.
What did surprise me was that each of the 3 PFCs has 3 channels, and each channel is a CPU from a different manufacturer (AMD, Motorola, Intel). The reasoning is that any flaw in any particular cpu design would be outvoted by the other two.
They appear to use 3 different compilers for this reason (Ada), one for each processor. Seems like the I/O and endianness of the various chips would add complexity too.
I wonder if the added complexity makes it a net win or loss for safety? I guess a win, since that's what they do.