▲ 21 points
back
19 comments
Unfortunately (particularly for those of us with 30" monitors) they don't have a full screen option like the amazing Mars Gigapan: http://gigapan.com/gigapans/113071
Edit: Found it - Awesome on a big monitor http://gigapan.com/gigapans/73573
I've worked at this plant, I've been in that control room during a refuel outage. I was there back in the 90's to install some feedwater pump vibration monitoring equipment when I worked for GE as an engineer. Later went on to design feedwater (level) control systems for other plants. Brings back some great memories.
Edit: I'm just hanging out listening to Giants/Dodgers... if anyone has any questions on the control panel systems, acronyms, etc fire away, I'll try and answer if I can. One memory was the all the acronyms I used to know. AMA
I really hope they plan to change the user and pass they have printed on two seperate labels on the computer on the right wall near the keyboard
Why would they? That computer isn't hooked up to a network, and there's a very small probability that Joe Random Hacker would be able to talk his way into a nuclear control room.
Also, it's a simulator control room.
They blurred out the 345KV error annunciator panel and the names of the contacts on the phones , so clearly they tried to censor some stuff. A password seems like a logical candidate that was simply forgotten.
That looks familiar ... In the '80s, I built equipment for Westinghouse's nuclear systems division and love the view of the synchroscopes.
The good old days of Westinghouse. I left there two years ago and all Westinghouse consists of now is the Nuclear division :)
A whole lot of subgroups within that though of course.
Rondout, IL sound familiar to you? =)
Growing up I really wished that I could work on things like that: I love switches, knobs, dials, klaxons, etc. but the best I have is vim and a command line. Obviously usability can be improved but I'll still lament the decline of big clunky switches and blinkenlights.
Very cool, my daughter was an operator on the Reed research reactor [1] and its control room is a lot simpler :-) Of course as an operations guy these days I see all those cool status panels and think it would be fun to pick some up for work. Then to find the gal who did the voice overs for Starcraft
"There is a packet anomaly in router one, there is a
packet anomaly in router one."
somebody needs to introduce a touch screen and some LCD displays to these people.
In nuclear power plants you just don't walk in and install new equipment. When upgrading control room to digital, you pretty much also need to upgrade the automation of the plant to be digital and qualifying it to be used in NPP is a real nightmare. In mainstream software markets you can always release bugfixes and add new features afterwards. In NPP your system must work the right way in every possible situation right from the start. I don't think, there are many software companies writing fail-safe programs of that size. And what's even more difficult, you have to prove it to be fail-safe to the regulators.
> I don't think, there are many software companies writing fail-safe programs of that size. And what's even more difficult, you have to prove it to be fail-safe to the regulators.
That's not possible. It is not possible to prove a nontrivial program to be fail-safe, any more than it is possible to prove a nontrivial axiomatic system to be internally consistent -- and for the same reason: Gödel's Incompleteness Theorems.
The Turing Halting Problem, and Gödel's Incompleteness Theorems, are deeply connected. The second cannot be resolved because the first cannot be resolved.
http://en.wikipedia.org/wiki/G%C3%B6dels_incompleteness_theo...
A quote: "The first incompleteness theorem states that no consistent system of axioms whose theorems can be listed by an "effective procedure" (e.g., a computer program, but it could be any sort of algorithm) is capable of proving all truths about the relations of the natural numbers (arithmetic). For any such system, there will always be statements about the natural numbers that are true, but that are unprovable within the system. The second incompleteness theorem, an extension of the first, shows that such a system cannot demonstrate its own consistency." (Emphasis added.)
http://en.wikipedia.org/wiki/Halting_problem
A quote: "Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist. A key part of the proof was a mathematical definition of a computer and program, what became known as a Turing machine; the halting problem is undecidable over Turing machines." (Emphasis added.)
The halting problem is undecidable over all possible Turing machines (i.e. programs, assuming Turing machines are an adequate model for the sort of programs of interest). It is entirely possible to choose some subset for which you know how to decide the halting problem, and program within the that subset.
It is a matter of cleverness (rather, successful algorithm design and theorem proving) how large you can make that subset. Such a subset could, for example, consist of programs written in a particular (non-Turing-complete) language, such that it is known how to construct a proof of (non-)halting because the structure of the program corresponds to the structure of a proof assembled from parts corresponding to the language's constructs.
This subset, this language, will necessarily exclude universal Turing Machines and other forms of interpreters — but I see no particular reason this is a problem for writing power plant control systems.
The structure of the above argument applies just as well to characteristics other than halting. For example, one can straightforwardly prove that any program does not access unallocated memory, provided that that program was written in a memory-safe language; the language is designed such that none of its constructs, nor any composition thereof, can be caused to do so. The analogous impossibility condition for this example is that you cannot express a C (or other non-memory-safe language) implementation in this language (without a virtual memory layer).
> The halting problem is undecidable over all possible Turing machines (i.e. programs, assuming Turing machines are an adequate model for the sort of programs of interest). It is entirely possible to choose some subset for which you know how to decide the halting problem, and program within the that subset.
No. Think about what you're saying. To be able to choose from among useful, nontrivial programs, those to whom the unsolved Turing halting problem doesn't apply, is to solve the Turing halting problem.
> It is a matter of cleverness (rather, successful algorithm design and theorem proving) how large you can make that subset.
This is a first-class logical error. Choosing the subset as you suggest, is equivalent to solving the Turing Halting problem, yet the problem is known to be insoluble. Surely you see this.
> This subset, this language, will necessarily exclude universal Turing Machines and other forms of interpreters — but I see no particular reason this is a problem for writing power plant control systems.
There is no other way to say this -- you are mistaken, in the most basic way. The Turing halting problem is not the common cold, that you can wait out, nor is it a question of language design, that you can finesse. It is fundamental, and the original claim -- approximately "prove to be failsafe" -- is not possible for any program more complex than "Hello World".
If you want a failsafe program to regulate your drilling operation or nuclear power plant, yes, you can have it, but all it can do is print "Hello World" over and over again.
If instead you want a useful program, one that can actually do useful work, you must accept that the Turing halting problem is (a) unsolved, and (b) insoluble.
> It is a matter of cleverness ...
It is not a matter of cleverness. It is a problem of understanding the limits of technology.
Choosing such a subset is not solving the halting problem. The halting problem says it is impossible to find a mechanical procedure that says whether an arbitrary program will halt. If a mathematician, by some intuition, is able to come up with a subset of programs for which some property can be proven, then this is not solving the general problem. Since this subset is not equal to the general set of programs, nor has it been found by some mechanical, formal means, it is not a violation of the theory of the halting problem. It can be a matter of a carefully crafted programming language, along with certain annotations (e.g., dependent types). Really, before making insistent statements like this, you should do some research (e.g. there's the whole field of program verification).
The grandparent obviously meant "prove" in an informal sense, as in getting something accepted by some bureaucratic certification. You're talking about formal, mechanized proof systems.
more complex software is more likely to be buggy