Confession - I've spent over twenty years as a software engineer; over a decade of that was developing avionics software for fighter radars.
Originally Posted by Jofm5
Encapsulation in this manner has added benefits in that should you change anything to do with the rudder you need only perform the extensive tests on the rudder classes to check the input and output parameters. If the test harness for the rudder class passes all parameters it should not have any impact on the overall software environment however it is not uncommon for full regression tests to be performed.
<nice explanation, but minor nit: try object oriented, not orientated. You'll be mentioning transportation next 
>
Except that we're not talking about civilian programming environments here, we're talking about
hard-real-time embedded systems programming, in a
multiprocessor environment...
If one process decides to become a cycle-intensive resource hog,
lower-priority tasks can suddenly find themselves
starved of resource. It all depends on how close to the edge you're running; e.g.
"income a pound, expenditure 99p = happiness; expenditure 101p = misery". Typically the contract specifies a healthy margin at the start, but these things can get eaten up over time.
For instance -
Tranche 1 Typhoon is running software written in
C and
assembler, delivered late 90s / early 00s, designed early 90s, running on processors that were
bleeding edge back then, but unbelievably slow now. To fit the algorithms into the space and time available meant some fairly intense
optimisation (and I mean that in the sense that the difference between unoptimised and "the best the that rather good optimising C compiler could manage" got us a 3% speedup).
We tried to generate
object oriented, reusable,
loosely coupled,
encapsulated code - but didn't always manage it.
Meanwhile, do a search on
"priority inversion" and "Mars Rover"...
Originally Posted by PTT
The point is all you need is to know how to get around the protection systems (a back door, which almost all software developers create) and you can do what you like
Wow, you must think that life's like 24, and it just takes a few keystrokes to break into a system and subvert it.
No, software developers don't "almost always" create
back doors. I've certainly never done it, but then I've specialised in embedded systems for most of my twenty years. Most "back doors" are just default passwords that incompetent managers forget to change, or passwords that morons write down or give out. The rest are mostly just unpublished APIs used for test purposes; e.g. command-line options that don't get into the user documentation (e.g. a Hi-fi firm I worked for used
shift-F12 to switch on debug mode in its software installation tool; it gave you more of an insight into what was going on, but was hardly "God mode"). Another example are
"cheats" for games software - if you want to test a particular feature in the game by running through it multiple times, you don't want to have to force the tester to take half-an-hour of play between each run of the test.
The delights of embedded systems with cycle periods of a few milliseconds (such as EW or radar systems which sample well into the kHz, over bandwidths well into the MHz) is that the million-to-one coincidence data set generally turns up in the first few minutes. You don't program in mysterious back doors based on funny codes, because nature has the nasty habit of generating just the wrong sequence of numbers. You don't allow mysterious program update mechanisms, because you don't want the bloke on the flight line to magically uninstall radar software v1.1, and it is assumed that if you want to carry out a software update, removing the LRI and connecting to it with a damn great 50-pin connector is not unreasonable. You don't have "unpublicised user accounts with admin privilege", because there aren't any user accounts. Up until the late 1990s, it was unlikely that there was even an
operating system.
So: no, I don't think that there's a magic "disable the system" back door built in to the software. If one were needed, it would have to be a contracted and specified requirement on the system - kind of hard to keep secret. One hint, and you get into all sorts of billion-dollar contractual obligations, let alone the diplomatic issues.
For instance - do you think that the US has a "back door" built into the UK strategic deterrent control software? Or not?