#1984 was written as a warning not a instruction manual | Explore Tumblr posts and blogs

jacewilliams1 · 5 years ago

Text

Is software enough to keep pilots safe?

I am a pilot. I am not a software engineer or software writer. That said, I use software like everyone else in just about everything I use every day. As pilots, we are all to familiar with the problems on the Boeing 737 MAX. We are being told that faulty software is the cause. Yes, there were or could have been problems with the pilot training, but Boeing is re-writing the software and when complete, the problem will go away and the aircraft will be safe. Or will it?

Airbus is having an issue as we speak with the A350. In a mandatory airworthiness directive (AD) reissued in July 2019, EASA urged operators to turn their A350s off and on again to prevent “partial or total loss of some avionics systems or functions.”

This must be done at exactly 149 hours.

In 2015, the Boeing 787 suffered a similar yet different problem. A memory overflow bug was discovered that caused the generators to shut themselves down after 248 days of continual power-on operation.

These are just a couple of the latest incidents that are occurring on our newest generation of aircraft. Why are we having these computer-related problems?

I have been doing some research and believe me, it is hard—very hard—to sift through the BS on this subject.

You can test a wing until it breaks. How about software?

In the “old days,” testing was straightforward. As an example, many of us have seen the video of the wing bending on the original Boeing 747. Straightforward. You bend something until it breaks, do it again and again, and you then have a pretty good idea of when it will break. If it is well within the limits you set, you are good to go.

You cannot bend or break software. So, what do you do? You put it through testing that some people consider industry standard and others don’t. Here is what I found for a description on testing.

The definition of software testing, according to the ANSI/IEEE 1059 standard is, “A process of analyzing a software item to detect the differences between existing and required conditions (i.e., defects) and to evaluate the features of the software item.”

Makes sense to me. Let me give you an example. I have a cell phone. It is full of software. How many times must I turn it on and off before it will fail? Will it always fail the same way? Will my model of phone fail for me and you at the same time? We cannot answer these questions. With the bending wing, we can, and we have a very good idea that, at a point in the bending process, the wing will fail.

Software is not a wing. It is a code written for a unit it will help operate. Specifically, source code is made up of the numerous lines of instructions that software programmers write to create all software applications. Once the source code is written, it is compiled into a machine-readable program which is installed on a computer as an application.

So how is it tested so that we are as sure as possible that it will not fail, or we know exactly when it will fail and we can replace it before that time?

There is manual testing, automation testing, static testing and dynamic testing. Then there are approaches to testing like white box, black box and gray box. Finally, there testing levels. They are unit testing, integration testing, system testing, and acceptance testing. This is all very impressive, but it still doesn’t tell me how long that unit will run on the software and why exactly it will fail, like the wing will fail.

So why does software fail? Here is some of what I found on that subject.

Lack of user participation

Changing requirements

Unrealistic or unarticulated project goals

Inaccurate estimates of needed resources

Badly defined system requirements

Poor reporting of the project’s status

Lack of resources

Unmanaged risks

This is all very reassuring. I mentioned that I am a pilot and not a programmer. Given this, how do I know that the software testing that goes into an aircraft is more complete than that which goes into a cell phone? I have no way of knowing that. If a hydraulic pump on an aircraft engine fails, it is sent out and bench tested. A fault is found, and a directive is issued so that all other pumps can be inspected and fixed. All the operators who use those pumps are notified. It is a simple and time-tested procedure.

How do you know when some of that software fails?

Does a software failure on one aircraft necessarily mean that item will fail on all aircraft? With the hydraulic pump we know that things such as temperature, lubrication, vibration, and other factors can cause the failure. How so with software? We are in a highly regulated business. Software and the people who write it are not. They are, for the most part, self-regulated. Once you are a certified as a software engineer, you can write for anyone who will hire you.

Just look at how often the “check engine” light illuminates on a car or truck. That is a computer program. From what I can find out, there is not much more that goes into the software for an aircraft as there is that vehicle.

How often are we faced with software failures in aviation? I suggest that we do not have a clue. Unlike the pump, a software problem can go unreported. With a software failure, maintenance usually just does a reset and the problem goes away and then may or may not reappear. I for one do not believe that we keep a complete record of these small failures. I have experienced it firsthand and I saw the reaction of both my company and the manufacturer.

In one case I was flying an Airbus. On descent, I was about to level at 10,000 feet. I was hand flying the aircraft with the auto-throttles off. I moved the throttles forward and got no response. At that point, I was cleared to 9000 ft. I told the first officer to check for a problem quickly. Everything was in the right place. Everything.

Nothing I could do restored my control of engine power. I was cleared to 7000 feet and I knew that I would be staying there for some time. It was night and the weather was 400 overcast and I was nowhere near an airport I could glide to. At 7000 ft. I purposely let the speed decay to what is known on the Airbus as Alpha Floor. This is a computer program that Airbus installed so that the aircraft could not be stalled (not at all like Boeing’s MCAS). When Alpha Floor is reached, the aircraft is programed to go into TOGA thrust (take off and go-around). My hope was that if a computer glitch got me into this predicament, then the computer might just get me out of it. It did. The aircraft responded as it was supposed to, and everything was restored, and we landed without incident.

On landing I pulled the cockpit voice recorder and flight data recorder tapes and maintenance removed them. I did all that was required for such an incident and went to the hotel.

I was a commuter and when I returned home the next day, my wife was on the phone and told me it was for me. It was my company and Airbus in Toulouse, France. There was a great deal of concern over the incident—as there should have been. In the end, my company sent all the tapes to Airbus to investigate, they did not report it to the regulatory authorities and Airbus did a software change to all their aircraft using that system.

In 1984, I was flying between Dubai and Male, Maldives. I was flying a DC-8 and we had an Omega navigation system on board. It had just been installed and I had never used one before. At exactly the second that the sun broke the horizon that morning, the aircraft started to turn off track. The Omega was driving the autopilot at the time. If I had allowed it to continue, it would have kept turning. I found out later that there was shielding missing in the computer unit that caused this anomaly.

On the Boeing 747-200, some of the autopilots would suddenly and dramatically go into roll mode. I had this happen while flying to Paris one night. It happened to a Taiwanese flight flying from New York to Taipei. The aircraft rolled over onto its back at FL 390 and the crew did not regain control until around FL 170.

When all of these start going off, is it a real emergency or just a computer bug?

And one more. On my second to last flight before retirement, I was flying the polar route to Hong Kong. At about 50 miles past the North Pole, we began to get master caution warnings. “Smoke in the Lavatory,” “Cargo Compartment Smoke,” and the very worst one on an Airbus: “Electrical Smoke or Fire.” These warnings came every seven minutes and before we could react, the warning disappeared from the screen. This went on for the rest of the flight. I contacted my company via sat phone, and they got Airbus on the line. Airbus told me, yes, there is a problem with the warning computer, and they are aware of it. There is a fix coming out in two weeks. Software fix.

These are just the problems I have had. Multiply this by the number of “electric” aircraft we have in the air and the number of problems will be staggering.

Who can you trust, what can you trust?

Ask yourself this. Why do we need all this fly-by-wire and many other computer systems? Let’s face it, manual flight control systems for a pilot are much more intuitive and user-friendly. You can feel an aircraft when flying manual controls but there is no feel in fly by wire. We have all this computer equipment because it is lighter and saves money. Weight is money and airlines love it. Aircraft are designed by engineers and technicians and not by pilots. Yes, they do ask our opinion, but do they really incorporate it into the final design? Very little. The bottom line drives all of this and nothing more.

As pilots we should know what kind of testing is being done on software, who does it and what the expectations of it are. Again, it is up to the regulators to do their job, but I fear as I see what is happening with the MAX, they will allow economics to be the big winner.

I am about to leave flying for good. Many of you on the other hand are just starting. It behooves you to look deeply into this problem as it will probably affect you for the rest of your career.

The post Is software enough to keep pilots safe? appeared first on Air Facts Journal.

from Engineering Blog https://airfactsjournal.com/2020/03/is-software-enough-to-keep-pilots-safe/

0 notes

ciathyzareposts · 5 years ago

Text

Missed Classic 78: Crash Dive! (1984)

Written by Joe Pranevich

For the era that we study, Brian Moriarty is one of the giants. He brought us three of Infocom’s classics, starting with Wishbringer, and jumped over to LucasArts to create Loom, one of my favorite adventure games of all time. Before we move on to Trinity (1986) and start the story of Infocom-under-Activision, I’d like to reverse course and fill in the final blank from his early career. In the early 1980s, Moriarty worked as a writer and eventual technical editor for Analog Computing magazine, celebrating the Atari personal computers that he loved. In that role, he wrote his first game, a tepid Adventure in the Fifth Dimension (1983) that failed to foreshadow the fantastic designer he would become. The following year, he penned Crash Dive!, his final Atari game before joining Infocom. Does that game show his potential? That’s what I would like to find out.

Inspiration can strike from just about anywhere, but Crash Dive! has perhaps one of the more unusual origin stories that I have ever heard. It starts with a failure: in 1982, Analog’s Jon Bell and Tom Hudson wanted to make a submarine action game. Bell and his team even toured two submarines (the Nimitz and Dace) for inspiration and historical accuracy. Cover art was commissioned, the game was announced, and even the back-of-box copy was written… but it evaporated into thin air. Despite the time and expense, it was never released. That would be the end of the Crash Dive! story, if it wasn’t for its “inspirational” cover art and a very special issue of Analog Computing.

Eye of newt, and toe of frog. For a charm of powerful trouble, like a hell-broth boil and bubble.

In April 1984, Analog planned a special issue to highlight adventure gaming on the Atari. This was early days in our industry and their definition of an “adventure” doesn’t quite match up to our own, but they found joy in narrative games (including what we would call “RPGs”) as distinct from action games. To celebrate these adventures, the editorial staff commissioned reviews of many such games available for the Atari. According to Moriarty’s introductory note, so many reviews were planned and penned that they had to spill over into the next issue.

I do not want to get too sidetracked from our Crash Dive! story, but it’s worth a moment to consider just what Atari adventures were highlighted that April:

Ultima I had finally been ported to Atari, three years after it debuted for the Apple II. Reviewer Steve Panak called it “quite possibly one of the most addictive” role playing games ever made, although he disliked the space segment and found the ending disappointing. (Ultima was covered by our friend the CRPG Addict back in 2010.)

Skipping the direct sequel, Ultima III was reviewed by Cliff Chaput and he had a lot of nice things to say about the title screen and about the first fifteen minutes of gameplay. Although he describes the game as a “must-have”, he admits that his copy (and many of the copies shipped for Atari) doesn’t actually work due to a “glitch”. How he could so glowingly review a product that might not even be playable, I have no idea, but he liked the bits that he saw. (Ultima III was covered by the CRPG Addict only a few months after the previous game.)

Gruds… in… Spaaaaace! (Apple II version)

Gruds in Space is a graphical text adventure game by Sirius Software, but not one I had ever heard of. Patrick J. Kelley reviews it and I’ll let his words speak for themselves:

“This is the most detailed and animated graphics/text adventure that I’ve ever seen, and belies a lot of love in its creation. Blinking eyes, twinkling stars, flashing lights and leering monsters fill every frame with a real character, and the continuity of shape and color are truly amazing. This game sets a standard that many other so-called ‘graphic’ adventures fall far short of, both in concept and execution. In some cases, the animation is so well integrated that it becomes more than just an enhancement to the adventure, but a feature unto itself.”

Saigon: The Final Days was reviewed by Ray Berube and he seems to have hated its puzzle design and the overall execution of the game. He writes, “I can’t recommend Saigon. Invest a little more money and buy an Infocom adventure, or even one of the original Scott Adams titles. You’ll enjoy your investment rather than railing at your monitor.” Our own Will Moczarski seems to have enjoyed the game more than Ray did!

The Return of Heracles was reviewed by Michael Des Chenes and he enjoyed the game very much, although it hardly seems like either an adventure or an RPG. The CRPG Addict shares his enthusiasm for Stuart Smith titles and had a lot of fun with this so the review seems on point.

Planetfall was reviewed by Carl Firman and he waxes on so much about the extras and the setting that he doesn’t even remember to tell us how much he liked the game, although it appears that he liked it very much. I agree! I cannot believe that it’s been two years since my review. Time flies!

These six games hardly account for the state of adventure gaming in 1984, but it’s not a bad mix of styles and genres. Was there really only one Infocom release they could have looked at? Were there no Scott Adams games? Except for Gruds in Space, these are all titles that are somewhat well-known today, at least to people that read our site and sites like it. I’m half tempted to play the game just so we can complete the set!

Some time either during the development of this issue or just before, Moriarty stumbled onto the abandoned art that had been created for the unfinished 1982 Crash Dive! Maybe something clicked then, or maybe he already had submarines on the brain, but that bit of art inspired him to create his own submarine-based text adventure. To save money, he could even use the original title and artwork! Moriarty finished the game in time to be included as a type-in for Analog’s special adventure issue. He explained in his introductory note that most commercial adventures didn’t work on 16K Atari systems, and that we wrote this game to scratch that itch for those owners. (It required 32K to be typed in, but once loaded onto a disk it could be played on a 16K system.)

It was the captain, in the galley, with a butter knife?

Crash Dive! Is by far the largest feature in the issue, no doubt thanks to Moriarty’s role as technical editor. With four pages of documentation and eleven pages of tiny-print source code, I’m glad that we don’t have to type it all in anymore! The documentation includes a half-page image containing the “feelies” for the game, although we’re not supposed to peek at them yet.

The story is well-done over all: we are a maintenance worker stationed on the USS Sea Moss, an experimental submarine in the middle of the cold war. It’s tough to remember that in 1984, the Cold War wasn’t just a genre, it was a lived-in reality. The sub is armed with nuclear missiles and has an advanced cloaking system which renders it invisible to the enemy. All of our greatest foes want to get their hands on the technologies in this sub. While we are doing some routine repairs, the unthinkable happens: sabotage! Everyone else on the ship has been killed by poison gas but we survived thanks to being in an air-tight torpedo tube. Our mission will be to find and defeat whomever killed the crew and keep the submarine from being captured. The manual provides a clue that we will need to get it underwater as soon as possible and that the only solution may be to destroy this priceless technology to keep it out of enemy hands.

Playing the Game

This style of start screen was reused by several Analog Computing games, but I am unsure which is the first.

An interface so cluttered that it is easy to forget that there isn’t much text.

The game opens with us in the “escape tube” that we were repairing when all hell broke loose. The hatch is closed, so I open it. Big mistake! Poison gas fills the room and I’m dead already. We have to start over. Nothing says “fun” like an adventure where you can die in the first move! It doesn’t take me long to realize that the solution (in Adventure International fashion) is just to “hold breath”. That lets you leave the tube and explore.

This game has a punishing start. You can only hold your breath for five turns. That gives you barely enough time to do anything so I save and commit myself to fast exploration-dashes and restoring when I die. For simplicity, I’ll just summarize what I found. The submarine is longer than it is wide with a hallway leading north-south and rooms off to either side. It is arranged on two floors and the room that we start in after emerging from the hatch has stairs down.

We find on the current level:

To the north of our starting position is an access tunnel with a sign warning of radiation. Heading farther north kills you immediately.

West is a locked door with a “very secure” lock.

Further south is a long corridor. Off that corridor to the west is a radio room (with a pair of cable cutters) and to the east is the sonar room. We can activate the sonar to discover that there are enemy ships approaching.

At the end of the corridor is the “command station” with a periscope. Looking through the scope, we can see those same enemies. To the west is a ballast room; we can press a button to make the sub descend and then watch a gauge to see how deep we go. To the east is the navigation room containing a manual and a readout of our current position in X/Y coordinates. I discover in my frequent restarts that the numbers change each game.

Not tremendously easy to read without the original issue.

The submarine manual instructs us to look at the photo in Analog #18. That is easier said than done because while I do have the PDF, it’s not completely clear and I wish I would have been able to find (and afford) the original issue. Nonetheless, we learn that the X and Y coordinates are scrambled through some magic so that they will not relate in any way to real-world latitude and longitude. It also warns that the values are recalculated every several seconds except when the sub is at rest. The remainder of the page describes targeting the sub’s weapons (using the same “simplified” coordinate system) and arming the warhead by radio. We’ll need to find a “Delta-Q Coordinate Decoding Ring” to be able to aim the missiles at the enemy.

Keep in mind that is already twenty or more reloads! With no breathable air in sight, I explore downstairs:

Below the command room is the missile bay. An airlock to the south requires an ID card.

West of the missile bay is the fan room. A traitor who “looks dangerous” there, holding a gun. Doing anything to try to hurt him just gets me shot. How is he breathing?

East of the bay is an equipment room with a radiation suit. I do not have enough breath to pick it up and get it back to the room with the radiation.

The north end is the crew quarters where I find a “card” on the floor. I am excited that it might be the ID card that I need, except that it is a playing card, the ace of spades.

West is a shower and ventilation grate. I try to unscrew it with the screwdriver, but my screwdriver is the wrong size! I also pick up some shampoo.

East of the crew area is a galley with a dull knife. I try to take that to the shower grate, but there’s not enough time.

In the far north is a torpedo room with a wrench. More importantly, there’s a weapons locker to the east containing a gas mask. I can breathe again!

In little 5-turn increments, I explored most of the sub and only found a gas mask in the last possible room. What was the odds of that? With the mask on (just picking it up is sufficient; “wear”-ing it just tells you that you are already holding it), I can explore the rest of the game and start smashing the puzzles. Except, I’m a liar because I only have around 10-15 more turns before the enemy ships (that I saw on the scanner and periscope) catch up to us. I am trading one time limit for another, but at least I have wiggle room. What can we do in 10 turns?

My first puzzle is the grate in the shower room. I theorized before that I could use the dull knife, but I could not get there before I ran out of breath. This time when I use “unscrew grate”, the game knows that I intended to use the knife and it opens! I can crawl south into a ventilation duct and see an opening down into the fan room. Obviously, this has something to do with the traitor who has parked himself there, but I don’t see anything I can do yet. I end up restoring when the enemy captures the sub and I’ll have to come back to this puzzle later. As an aside, the “traitor” has to be a “him”, even though the game doesn’t say so. The US Navy did not allow women to serve on subs until 2011, as sad as that statement sounds today.

My next trick is to check out the radiation area. I grab the radiation suit from the equipment bay and head back upstairs. The radiation-filled room is used by the sonar. There is a “bolted-down” sonar system as well as a power cable here. I spend more time than I care to admit trying to find the right verb to unscrew the bolt, but I fail anyway because they are rusty and too tight. We haven’t found any oil, but the shampoo might be slippery enough. I try it and the bolts come loose! I don’t get to do anything else because I run out of time again.

Oh, duh. I am on a submarine! I restore and head to the ballast room. I set the ship to dive. A few turns later we have a “bang!” when we hit the bottom of wherever we are, but it doesn’t seem to be an issue.

Where was I? The sonar system! I do that all over again and notice that while the system is clearly labeled “radioactive”, I cannot pick it up because the power cable is stuck. I use the cable cutters from the radio room and solve that problem easily. Now what? I take my radioactive prize to the ducts by the shower and drop it down into the fan room below. When I run down to investigate, I discover that he died of radiation poisoning! I pick up his gun, but what I am supposed to do next?

Let’s take stock of what puzzles remain:

Two locked doors, one near the beginning of the game and an airlock to the south that requires an access card.

Some enemies are chasing us and could have depth charges. Can I blow them up with our super advanced missile systems?

The “escape tube” that I started in seems the best avenue for leaving the sub, but I don’t see how to do that yet.

Of these, the most promising is the locked door at the start. I didn’t find a key, but I discover that I can shoot the lock! That door leads to the captain’s quarters. He’s dead, but he didn’t die of the poison gas. Instead, he left a suicide note:

Suicide is painless? Maybe only in the Korean War.

There’s a nice little detail on this note, placing the submarine as SSCN-718. These are US Navy hull classification numbers and a good sign that Moriarty and the Analog team researched for the game. There is no SSCN classification in real life, but the designation would likely indicate that this is a coastal-waters submarine (the SSC) classification with nuclear weapons (the trailing N). I also like that the captain’s name is Captain R. D. Avatar. This game predates Ultima IV and Moriarty was probably thinking of the more generic “avatar” rather than the Ultima variety.

Searching his body, I uncover his ID card which opens up the airlock to the south. That leads us to a missile bay in two sections: the lower section contains a locked arming switch, while the upper bay contains a digital display. That display also has X and Y coordinates, although they are different than the ones in the navigation room. Pushing buttons nearby adjusts the coordinates. I do not have a way to get the coordinates of our enemy; the sonar system didn’t give those to me even prior to when I dropped it on a murderer’s head. Am I supposed to use the coordinates of our own ship? That sounds vaguely like suicide. Since those are the only coordinates that I have seen in the game so far, I set the missiles to those. It takes a long while since the numbers only increment by eight for each button press.

Now, I need to find the key to unlock the firing mechanism… but I cannot find it anywhere. I eventually take a hint which tells me that I need to look at the radiation suit again after wearing it. Some idiot left the firing key in the suit! I do my thing and the firing mechanism is activated. There’s one more button in missile control to push and… boom?

Fade to white.

There’s no text that explains what happened, at least none that I can see before the screen clears, but we don’t need to have it spelled out: we nuked ourselves. Worse, that is apparently the correct answer because we kept the sub and all of its technologies out of enemy hands. Yay? This is the “win” screen so I’ll just end the game right here. I suppose it’s a better “you die!” ending than Infidel.

Time Played: 1 hr 45 min

Final Rating

That was a fun little game, although we must emphasize “little”. Type-in games can never be tremendously large and Moriarty did a good job with narrative efficiency. Let’s see how that comes out in our PISSED rating system:

Puzzles and Solvability – The game’s central mechanic for at least the first half is to die frequently and try again. Needing to discover the gas mask within five turns, then realize that you need to dive (which itself is not difficult) in ten to fifteen more, takes up most of the game’s thought-space. After that, we have a few clever things like dropping the radioactive sonar thing on the traitor and nuking ourselves to keep the sub out of enemy hands. I needed to take one hint. I almost want to bump it up one point, but my first instinct is that this is only worth two points. My score: 2.

Interface and Inventory – The interface is boxy and takes up a lot of space, which is good because otherwise we’re realize just how little text is in this game. Other games used the “windowed” approach for an interface by 1984, but I see little value in having an always-visible inventory and other features. The parser itself wasn’t great but it worked well enough with two-word commands only and no intelligence for the noun selection. You had to “push green” instead of “push button”, for example, because the game isn’t smart enough to know if there is only one button in the room. My score: 2.

Story and Setting – This score is likely going to be the best of the game. The story and feelies are great! The captain’s suicide is relatively unexplained, as is the traitor’s motivations and identity, but the overall idea of a submarine so secret that it has to be kept out of enemy hands at all costs is a good one, especially in 1984. The space was also designed well and the small number of rooms added to a feeling of claustrophobia which benefited the setting. My score: 4.

Final map of the game with only 22 rooms.

Sound and Graphics – I almost want to give points here because of the screen design and the use of the “feelies” to augment the object descriptions, but I really cannot. We have never given points in this category just because a game has a nice manual and I won’t start now. My score: 0.

Environment and Atmosphere – While I did not enjoy the timers for their puzzle-factor, the constant racing to beat the clock made the game tense. The small size of the ship and even the “bang” as we strike the bottom of whatever shallow waters we are exploring help sell the claustrophobia of the situation. Even with the limited text, Moriarty writes well enough for some kudos. My score: 3.

Dialog and Acting – Alas, the game is limited when it comes to game text and occasionally it’s not even clear what you are doing. The game also cuts to white for the ending so quickly that you only realize in retrospect what just happened. My score: 1.

Adding up the scores: (2+2+4+0+3+1)/.6 = 20!

This isn’t a huge score, but higher than Fifth Dimension’s 13. That is understandable given the challenges of writing a type-in, but I suspect there was something else involved. Both of Moriarty’s games for Analog were as much “challenge exercises” for him as they were games. Moriarty first challenged himself to create a BASIC game that worked even on the smallest systems. He then forced himself to re-use a name and cover art from an abandoned project. Even Wishbringer was a challenge to craft a story into an existing universe and that turned out amazingly well. Maybe Moriarty was just the type of guy that thrived under adversity, but I cannot help but think that he could have made even better games if he had fewer strings attached. Is that what we will find with Trinity?

With the last of his pre-Infocom games out of the way, we’ll be looking at Trinity next, probably at the beginning of January. I am playing a stubborn Christmas game right now and have a deadline coming… See you soon!

source http://reposts.ciathyza.com/missed-classic-78-crash-dive-1984/

#retro games #dos games #retro #crpg #adventure #amiga #oldcomputers #8bit #16bit #blog #repost

0 notes