Where in the World is SCORE
Rabbit The SCORE Rabbit from DDC-I travels the world assisting many software development projects with safety critical needs. If you can correctly identify Where in the World is SCORE Rabbit, you can win a $50.00 gift certificate to Amazon.com. Each month a new contest begins. A portion of a photo showing SCORE Rabbit at his new location will be posted with larger pieces of the photo available each of the following 3 weeks. One clue will be given at the beginning of the month to help identify this location. The Vasa: A Disaster Story with Software Analogies Linda Rising I have spent some time leading postmortem meetings where projects (successful and otherwise) would examine possible causes for the fate of the project. We would look for things that should be repeated on other projects but usually the focus was—all the things that went wrong. Most of the time this list of gotchas contained nothing new—just those good things we’ve learned in the past but can’t seem to remember to apply in the current project. Those of us who work in the wonderful world of software are continually berating ourselves for not perfecting our engineering discipline (if it truly is an engineering discipline but that’s another discussion). Other engineering approaches seem to work better than ours or at least that’s what we think and certainly others have told us. I recently visited a fascinating museum in Stockholm, Sweden that tells the story of an engineering tragedy—the sinking of the Swedish warship, Vasa, on her maiden voyage on August 10, 1628. She capsized in a light squall and sank—she never made it out of the harbor. Of the 150 on board (only a partial crew—the ship was designed to carry 450), 30-50 died in the disaster, including wives and children of the crew who were allowed on board for the special occasion. All this happened in front of the crowd gathered to watch the sendoff. Imagine watching helplessly as the magnificent new ship went under! In 1956, the wreck of the Vasa was discovered by Mr. Anders Franzén. We not only have the ship but also records of the follow-on inquiry—a kind of postmortem document. The inquiry did not yield any conclusive result and no one was found guilty. It was an obvious failure but no one did anything wrong! Let’s start at the beginning to see if we can uncover anything that might help us. Along the way we’ll see the software parallels. January 16, 1625, the Swedish Navy signed a contract with two experienced Dutch ship builders, brothers Henrik and Arend Hybertsson. The contract outlined the construction of four ships: two small (keel length 108 feet) and two large (keel length 135 feet). There were some problems with shipyard finances in the first few years following the signing of this contract, which delayed construction of the Vasa. As a result, toward the end of construction, the work was rushed and hasty improvisations were included.
September 20, 1625, ten Swedish warships were lost in a storm. November 4, 1625, the king, Gustav II Adolf, with his army in Poland, wrote Admiral Klas Fleming in Stockholm asking for an earlier delivery of the two smaller ships in the contract to help him recover from the loss of the ten warships. In his letter he also specifies the keel length of the ships—120 feet—longer than the smaller ships in the contract but shorter than the larger ones! Ships in those days were made of wood and timber was cut to spec. Each tree felled was intended for a specific purpose. The timber had already been cut to meet the original specifications. The 120-foot ship could not have been built with the timber intended for the smaller ship or the larger. The builder protested.
February 22, 1626, the builder’s objection annoyed the king but he wanted his ship, so he wrote back to the Admiral that if the specifications could not be followed then the builder was to deliver the larger ship (135 foot) described in the original contract. March 21, 1626, this reply was finally replayed to the builder. In the mean time, construction had proceeded so, again, changes had to be made. The keel length of the Vasa is 135 feet but it is constructed of four pieces—more than the usual for the time. It appears that the builder had cut timber for the original specs, tried to meet the first request by extending the keel of one of the smaller ships and then when the second request appeared, had tried to extend the keel further. Could this have caused instability in the ship?
Late 1625, the builder, Henrik Hybertsson, became seriously ill Spring 1627, Henrik Hybertsson died. His assistant, Hein Jacobsson, took over his responsibilities. During the transition period, shipbuilding management suffered. A terminally ill manager tried to make decisions and his assistant tried to understand what he could do and what his sick boss wanted to be consulted about.
Modern building contracts contain detailed descriptions of the ship. In the 1600s there were no drawings and the descriptions in the contracts were very sketchy—especially for the armament. The following is the initial list of the armament planned for the Vasa. Note the specifications are given in terms of the weight of the projectile it fired, e.g. a 12-pounder fired a 12 pound cannonball. 24 12-pounders 36 24-pounders 8 48-pounders 10 small guns This was way too much for the single enclosed deck and the open deck planned for the Vasa. The word on the street was that the Danes had built a ship, the Sancta Sophia, similar in size to the Vasa but with two enclosed decks with ports for 50 guns. (In reality she only carried 40. On hearing this, the king decided that the Vasa must also have two gun decks. She was the first ship in Sweden to be built in this way—another innovation.
When the builder received the order to add another closed deck, the hull was already under construction. Hein Jacobsson testified that he built the Vasa one foot five inches wider than originally planned but since the bottom was already fixed this contribution to stability was negligible. In other words, the ship was not really adequate to hold the weight of the armament that two enclosed decks would carry, despite the best effort of the builder.
The Vasa was also the first Swedish warship with a real brick oven—another innovation and more weight. But wait, we’re not finished, there’s still more weight to come. In 1628, the king again changed the requirements, asking for even more armaments: 30 24-pounders (a reduction, since the lower deck could only have 30 gun ports) 30 12-pounders (increased from 24) 8 6-pounders (added) 4 48-pounders (whoa!) In a final round of changes, the previous list was replaced with 60 24-pounders, making the Vasa the first "all-big-gun" ship—yet another innovation! These changes came too late to alter the upper gun ports (they are smaller than those on the lower deck). The builder could only hope that the deck and its beams would stand up to the weight of 60 large guns. The requirement for 60 24-pounders was unrealistic since the two enclosed gun decks only had 56 gun ports. In a series of notes in the requirements document: the first specifies: 54 24-pounders, the second: 58 24-pounders, 12 12-pounders, and the third: 58 24-pounders, 8 12-pounders. The 12-pounders would have to have been placed on the upper, open deck. In the third case, 8 of the heavier 24-pounders would also have to have been placed on the upper deck. What a nightmare!
In the final analysis, the number of guns was determined by production—which was delayed! Sweden recovered most of the guns aboard the Vasa in 1663-64. The guns were of imprecise quality (signs of great haste). On the basis of the number and position of the gun carriages, she carried 48 24-pounders, 24 on each of the two enclosed decks.
Most ships during this period of naval history were pretty top-heavy. This was more the case for English ships than Dutch. Liberal ballast was the only thing keeping most of them afloat. To allow this, the hull had to be deep in the hold. Dutch ships were more of problem since they were designed with flat-bottomed hulls to accommodate the shallow waters along the Dutch coast. The Vasa was a hybrid—flat-bottomed (not much room for ballast) but heavily built and armed. Those close to the project were clearly concerned. Admiral Fleming and Captain Hansson ordered a stability test but neither of the builders was present or informed about the disturbing outcome. In the stability test, 30 men ran from one side of the ship to the other. According to testimony, "The first time, it heeled over one plank (an angle measurement), the second time two planks, and the third time three planks." At that point, the Admiral ordered the testing to stop. An observer noted, "If they had run across the ship one more time, she would have capsized." The Admiral said at the time that he wished, "that His Royal Majesty had been home." Why didn’t the admiral or the captain stop the Vasa from setting out on her expedition? Why did they allow families on board for the maiden voyage? The answer must have been related to the great urgency. She was already behind schedule and the king had ordered that "both the Vasa and [another ship] shall be ready by [July 25], and if not, those responsible would be subject to His Majesty’s disgrace."
Neither the admiral nor the captain said anything about the stability test in their testimony at the inquiry following the disaster. The outspoken boatswain Matsson was the only one to mention it. He added that the captain had told the admiral that the ship was unstable. Clearly, the high-ranking project managers knew about the problems and did nothing.
Adding ballast improves the stability of a ship but at a cost—the ship rides lower. If too much ballast is used, the gun ports will be too close to the waterline. The admiral had already expressed his concern to the boatswain that the gun ports were too close (3.5 feet he claimed, actual distance was a little over 4 feet) to the waterline and instructed the boatswain not to add more ballast. The boatswain testified that he went below with a lantern to ensure that as much ballast had been added as possible, despite the Admiral’s instructions. When the Vasa was constructed there were no scientific means to determine stability or center of gravity (cog) or the actual weight of ballast needed. Computer simulations based on measurements taken after the Vasa was recovered show that the cog was 6.16 m too high. Additional ballast sufficient to lower the cog might have saved the Vasa from capsizing in the harbor but the disaster would only have been postponed, given the weight on board. The actual weight of ballast on board was about 122 tons. Another 130 tons would have been needed to lower the cog the required amount. This would have lowered the gun ports to about 3.5 feet—possibly unacceptable for the admiral. Unfortunately, there was not room for the extra ballast in the hold. Finally, the captain sailed a brand new ship with open gun ports. The Vasa sank when water poured in through the open, lower gun ports. It might have been wiser to test the new ship on her maiden voyage with closed gun ports, but, again, this may have only delayed the disaster. Summary - The Vasa was initially specified as a small
ship but became a large ship. What are the lessons for software developers? Hearing all the problems in the building of the Vasa and empathizing with them—what does that do for us? Did you find yourself nodding and muttering to yourself while reading this? I heard lots of comments from people around me as we were listening to our museum guide tell this story. "Politics as usual." "The big boss always gets his way." "The same old story." Lots of comments, lots of people, lots of accents. It’s the same the world over. For me, the big revelation was seeing that we’re not alone, that other engineering disciplines really don’t have it all figured out, that the problems that cause disasters are a combination of technical and political and they can all cause a project to fail. It’s sort of a happy-sad revelation. I’m happy that software isn’t the only industry that struggles but sad that we are all plagued with seemingly insurmountable difficulties. Some might say that shipbuilding has improved in the last 300 years and that disaster stories like the Vasa are rare. To this I would have to reply, "You’re right, ship building has improved! Was the Titanic a ship? What about the Concorde?" I don’t want to end on a sour note because I believe that sharing stories is good and that recognizing commonalities and talking about problems is the first step to solving them. Henry Petroski [5] presents several engineering disasters in his book, To Engineer is Human. Don’t read this, as I did, on a plane flying through a lot of turbulence! Now that my version of story has been told, I hope we’ll all remember the Vasa and learn from the mistakes of the past. References 1. Borgenstam, C. and A. Sandström, Why
Vasa Capsized, AB Grafisk Press, Stockholm 1995. © 2001 The Software Practitioner, used with permission. Using Addresses in 80x86 Protected Mode Machine Code Torkil B. Rassmussen In DACS 80x86 Protected Mode the type SYSTEM.ADDRESS is a RECORD type with two fields: the offset field and the segment field. Since records in DACS-80x86 are passed by reference always, passing the address of an object typically incurs creation of temporaries to hold the record that is to contain the address requested. For Machine Code Insertions this poses a special problem, when using the System_Address method to address an operand to a machine code. For scalar variables using one register only, the resolve of scalar_object'address is the same for a local object and for a parameter, typically an EBP offset. For composite objects parameters are referenced indirectly via an address, or locals are referenced via an explicit (negative) EBP offset and implicitly SS. Using an LES instruction to retrieve a record address will generally NOT work for local composites, as this would yield the first 48 bits of the local (composite) object, and most likely result in a protection fault, because the segment value is illegal. This is however the proper way to address a composite parameter. General code to do this can therefore not be written. A way to secure load of the requested address in specific registers must therefore include an extra step that assures a uniform handling of the two cases. The first thing to do would be to declare a record type that mirrors the SYSTEM.ADDRESS type, but which does not use the former's unsigned fields, since these lead to unnecessary zero extensions, when selecting the fields:
type Address_Clone is
record
Offset : integer; -- signed 32 bit type
Segment : short_integer; -- signed 16 bit type
end record;
function mk_Clone is new Unchecked_Conversion( System.Address, Address_Clone );
The next thing to do, is to make a machine code routines that allows for the setting of offset and segment independently:
procedure set_ES_EDI
(offset : in integer;
segment : in short_integer) is
use machine_code;
begin
machine_instruction'( register_system_address, m_MOV, EDI, offset'address );
machine_instruction'( register_system_address, m_MOV, ES, segment'address );
end;
pragma inline(set_ES_EDI);
procedure set_DS_ESI_and_Move
(offset : in integer;
segment : in short_integer;
sz : in integer) is
use machine_code;
begin
machine_instruction'( register, m_PUSH, DS);
machine_instruction'( register_system_address, m_MOV, ECX, sz'address );
machine_instruction'( register_system_address, m_MOV, ESI, offset'address );
machine_instruction'( register_system_address, m_MOV, DS, segment'address );
machine_instruction'( none, m_REP);
machine_instruction'( none, m_MOVSB);
machine_instruction'( register, m_POP, DS);
end;
pragma inline(set_DS_ESI_and_Move);
And finally a frame routine that makes use of the above: procedure move (from : in system.address; to : in system.address; sz : in integer) is begin set_ES_EDI ( Mk_Clone(to).Offset, Mk_Clone(to).Segment ); set_DS_ESI_and_Move ( Mk_Clone(from).Offset, Mk_Clone(from).Segment, Sz); end; pragma inline(move); When calling move ( from'address, to'address, sz ); the compiler will allocate temporaries to hold the addresses, and place the actual addresses of from and to in those temporaries. When referencing the Offset and Segment fields inside set_ES_EDI and set_DS_ESI_and_Move a few further temporaries may be used, but the net result will be that the proper values are loaded into ES:EDI and DS:ESI as well as ECX and the repeated move can take place. Notice that ECX is likely to be moved to prior to switching DS, but if a subprogram local sz (or a constant) is used that does not matter.
|