• TADS-1750A Development System Now Offers Full Support for Windows NT, 2000, and XP Host Environments
• DDC-I Offers TADS-1750A Customers Simple, Cost-Effective Windows Migration Package
• The War Room: A Place of Their Own
• Tech Talk: Verifying PROM'ed Systems by Checksums

DDC-I's Trusted TADS-1750A Development System Now Offers Full Support for Windows NT, 2000, and XP Host Environments

Phoenix, AZ and Lyngby, Denmark — February 18, 2003 — DDC-I today announces the addition of support for Windows® based development platforms for the TADS Ada Development System targeting the 1750A (TADS-1750A) product family. In addition to Windows NT, 2000, and XP hosting capabilities, TADS-1750A will continue to support the original Sun™ SPARC®, and DEC VAX/VMS host development environments.

"Updating TADS-1750A to support the latest versions of Windows is a direct response to the needs of our customers, who continue to migrate safety-critical software development for a variety of projects to these increasingly popular platforms," explains Richard Frost, DDC-I Senior Software Engineer and TADS Windows Rehost Project Manager.

TADS-1750A offers a mature solution, combining a highly optimizing compiler with selective linking and modular run-time systems to generate the most compact code available. With classical optimizations and performance benefits specific to the Mil-STD-1750A processor architecture, Ada 83 specific compiler optimizations include data packing, constraint and overflow check elimination and static aggregate initialization.

"TADS remains a valuable development environment for real-time embedded system developers in aerospace, avionics, defense, and many other safety-critical applications where failure is simply not an option. We are dedicated to providing our clients with quality tools as well as customizing solutions as needed for their individual requirements," Frost concludes.

[ Back to Top ]

DDC-I Offers TADS-1750A Customers Simple, Cost-Effective Windows Migration Package

Phoenix, AZ and Lyngby, Denmark -- February 21, 2003 -- DDC-I today announced the availability of a new Windows™ (NT/2000/XP) migration package for existing TADS-1750A users. Designed to streamline the transition from VAX or UNIX-hosted development systems, this limited-time package is fully customizable, offering current customers an affordable migration path to the most popular PC-based network and enterprise computing platform.

"The TADS for Windows program is affordable and flexible, and allows organizations to dictate exactly what tools and support they need, instead of handing them a rigid list of options," explains Bud Blum, DDC-I Product Champion for the TADS product line.

With DDC-I’s guidance, customers define package parameters to create a least-cost migration path which includes all necessary license transfers and keys to replace current TADS licenses. Software support from the current license agreement also carries over, to keep recurring costs level, while the customer has complete freedom to select the number of seats they want to rehost and whether to upgrade their software versions during the migration.

According to Blum, the package combines two days of on-site consulting at no additional charge to assist with rescripting, memory and segment set up, tool adaption, related ethernet work and board support upgrades. A final project report with detailed recommendations is also included.

"Our goal is to help our customers get the best from their safety-critical software development tools, and when it comes to managing a platform migration, minimal disruption for the programmers and the development environment they depend on is top priority," concludes Blum.

[ Back to Top ]

The War Room: A Place of Their Own

My husband and I spent this past Christmas holiday in London, re-visiting some sights and seeing new ones. On this trip we had a chance to see The Cabinet War Rooms, http://www.iwm.org.uk/cabinet/, where Winston Churchill and his staff spent their days during the Second World War. British planners were concerned that the public might think their leaders were deserting them, so they found a site near the traditional home of government, they chose the basement of the Office of Works' building, which faced St. James's Park and Horseguards Road on one side and Great George Street on the other. Known throughout the war as 'George Street,' this building offered the strongest structure of any in the area and was conveniently situated between Parliament and the Prime Minister's office-residence at Number 10 Downing Street. When the rooms became fully operational on August 27, 1939, one week before the German invasion of Poland and Britain's declaration of war, most thought it would be a temporary arrangement. This 'temporary' measure was to serve as the central shelter for government and the military strategists for the next six years, especially during the time referred to as the Blitz, the word applied by the British press to the heavy and frequent bombing raids carried out over Great Britain, particularly over London and other major cities, in 1940 and 1941.

It was fascinating to see how Churchill and his staff lived in the warren-like underground rooms. Everything has been left as it was the day after VJ day, August 16, 1945, every book, map, chart, pin, and notice in the same position now that they occupied then.

Churchill created a nerve center where all war-related information was made available to the war planners and political leaders. The loose threads of information, which had little meaning themselves, could be woven into a coherent picture that all could share. This system was far superior to the one used by the United States at the time. Because of inter-service rivalries and lack of coordination, American war planners and diplomats in 1940-41 had no system for effectively bringing together people and information. One of the shocking lessons of Pearl Harbor was that the many pieces of information that could have identified the when, where, and how of Japan's surprise attack were known by the State Department and individual military personnel, but were never integrated. According to the late Gordon Prange, a leading authority on the Pacific War, "Pearl Harbor was less a failure of intelligence than a failure to use the excellent data available." [Meyer+97]

The lesson is clear. When strategic decisions of vital importance to a country or an organization are being made without all the information that could be had, the penalty can be severe. This is also true at the project level. Two important tenets of agile processes are: (http://agilemanifesto.org/)

• Business people and developers must work together daily throughout the project.

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

To encourage this close communication, projects can schedule frequent meetings and teams can have a "place of their own" or a "war room." To illustrate the importance of this "team space," I’ll tell a story about the penalty one project paid for taking away a successful team "place of their own."

A medium-sized company was ramping up (remember the good ol’ days?). They had customers clamoring for a future release and they were hiring like crazy. They hired so many people that they had to use every inch of available space. Yes, of course, the developers were in 8X8 cubicles (see www.dilbert.com) but these disappeared fast. In leaner times, some teams had converted some adjoining empty cubicles into small meeting rooms. The walls of these small gathering places were covered with whiteboards and poster boards where the team posted architectural drawings, code snippets, schedules, bug reports, you name it. Nice, but it had to go. The new people had to sit somewhere. Soon after a strange side effect appeared. The defect rates began to slowly creep up on those teams that had lost their little local meeting rooms. No one really understood why. It wasn’t until months later in a pattern writing class that the answer was revealed. The pattern, written by two members of one of the teams described above, was called A Place of Their Own. Here’s the pattern.

A Place of Our Own

Alias: War Room

Context: A team of people are working together on a project and need to communicate.

Problem: The team needs a place to gather in small groups, spread out documents, and have a white board available for sketches.

Hallway discussions can be interrupted.

Hallway discussions can disturb others.

A single cubicle is too small.

Team members often don't know ahead of time when they need to get together.

The space might be needed for several days.

Solution: Locate a convenient small space near the team and have it available when the need arises. A conference room can be reserved or an empty cubicle can be converted to a meeting space.

If a conference room is used, try to book the same room at the same time daily. Be sure to free it up if it will not be used.

Resulting Context: The team will have a place of its own and be able to meet on short notice to carry out important discussions.

If every team follows this pattern and solves the problem by reserving a conference room, all the conference rooms will be booked up but probably standing empty much of the time!

If it's too easy to meet, time may be wasted in meetings. Why do most meetings end? Because someone else needs the room!

A couple of years ago, several cubicles were set up as small conference rooms, with a few chairs, a table and a white board. One of them was near our group and was a great place for small meetings. This space was always available for discussion as issues popped up. Our patch review teams were usually made up of four people. We could easily fit in our little room to do a patch review, discuss feature estimates, or just brainstorm ideas. If you've ever tried having a discussion with three people in your cubicle, you know that it just doesn't work. This room was great. Without the phone, you could work uninterrupted. Our group used this cubicle but it was available for others. Sometimes you would see coaches using the room. When anyone needed a place for 3 or 4 people—quick—this was it.

Sometimes it's hard to get a conference room when you need it, especially at the last minute. It seems inefficient to use a huge room for a three-person meeting. It's hard to say but having this small conference area most likely freed up larger conference rooms and allowed small meetings to be scheduled at short notice. Little spaces like this, scattered across the company, definitely serve a purpose and provide a valuable resource for people.

When the company started hiring, the building filled up and these rooms were converted back to office space. Since the rooms are no longer available, I've noticed that more and more reviews are sent out as desk reviews. This is disturbing. I wonder about the quality of the desk review vs. the meeting review. In addition, the learning that went on when our team would come together and discuss the patches is now diminished. For new designers, this is one of the few ways to learn new commands and pickup expertise from our more experienced designers. Novices can also learn how to be a better reviewer.

The following are from project postmortems:

A critical element in the project success was the War Room with four computers where the team designed and implemented together. This was done from the beginning.

We had a small conference room reserved as our War Room. We had a meeting every morning when things got hot.

We had a conference room reserved every day from 1-3. At the daily Scrum meeting we decided how to use the room. If we needed the time, the room was available. If we didn't need it, we freed the space.

One of our teams had a War Room. They reserved a conference room for a month and the entire team worked there together. Since they were all learning, this helped the team make progress. They did a lot of pair programming, so peer review was built in.

In Alexander's pattern Flexible Office Space [Alexander+77] he writes:

...make it possible for people to work in twos and threes...

In his pattern Small Meeting Rooms [Alexander+77] Alexander states:

...meetings work best when the meeting rooms are fairly near the participants' offices. Then discussions which begin in the meeting rooms are able to continue in the office or the lab.

[Alexander+77] Alexander, C.A. et al, A Pattern Language, Oxford University Press, 1977.

As you can see, the reason for the increase in defects was this. As last-minute fixes were made, the team would quickly gather in a small, local meeting room for a code review. Since the room was in a handy location (just like Churchill’s war rooms) and it had all the relevant documents and drawings, it was a perfect place. It held many more people than a single cubicle and since the team members sat relatively close together (another important organizational pattern), it was easy to call a meeting. Alternatives available included: using a conference room (almost impossible, since these are usually booked well in advance and are few in number or are not conveniently located – some are in other buildings), squeeze the necessary folks into a single cubicle (good for the Guinness Book but not for a code review), or head to the cafeteria (noisy, full of distractions, no whiteboards, no handy documents). So, the team either did a half-hearted job in a single cubicle or did no code review at all. Now we see the link between A Place of Their Own and defect density!

There’s a subtle effect on morale and team-building as well. When the daily Scrum meetings or other team meetings are always held in the same place—full of team artifacts and handy to individual team cubicles, a sense of camaraderie evolves and the team begins to feel they are part of the same effort, working together to achieve something they all feel is important. This has considerable impact on productivity. Happy people are productive people.

Takeuchi and Nonaka describe a team room used by Fuji-Xerox in building the FX-3500 medium-size copier. Team members were brought together in one large room. As described by one member of that team:

When all the team members are located in one large room, someone's information becomes yours, without even trying. You then start thinking in terms of what's best or second best for the group at large and not only about where you stand. If everyone understands the other person's position, then each of us is more willing to give in, or at least to try to talk to each other. Initiatives emerge as a result. [Meyer+97]

A team room serves not only as a meeting place but also as a physical repository for the various questions and answers that a team must deal with over the course of a project. A list of "I Don’t Knows" can be prominently posted and as the answers emerge, they too should be placed on the team room walls.

When the team war room has been created, anyone visiting that room can see the current state of the project in any of its phases. Here’s a comment from one team that used this successfully:

Actually, meetings are almost nonexistent now. In fact, we just huddle at the end of the week. [We] stand around…charts and, basically, report in on what we’re doing. If we’ve got to change some dates or change some priorities, at that time we decide what we’re going to do, and we understand why we’re going to do it. It takes about a half hour. [Fritz99]

I know, I know. Some of you are thinking, "Linda, you come up with great ideas but what about my company? We can’t afford to have this extra space for each team." Yes, it’s true. These are tough times. We can’t afford the luxuries. We have to watch our pennies. Well, that means we’ve got to be creative! Find some small space that can "belong" to the team. Even an outside wall of a cubicle can hold important postings. Let this be the area where the team has daily Scrum meetings. Maybe the wall at the end of the team aisle could be the "gathering place." Team leads and managers, support your teams in this effort with small things: a whiteboard, a slight bending of the rules about taping things to walls, and stop by to see what the teams have done and share in their success. A manager who only appears when things are going bad, carries that stigma of Bad News Charlie. We all need encouragement and thanks. Maybe the small "place of their own" can be the beginning of that.

Let me know if the "war room" concept helped your team and how you solved any local roadblocks along the way to creating a "place of your own." Good luck!

[Fritz99] Fritz, R., The Path of Least Resistance for Managers, Berrett-Koehler Publishers, San Francisco, 1999.

[Meyer+ 97] Meyer, M.H. and A. Lehnerd, The Power of Product Platforms, The Free Press, 1997.

About the Author
http://www.lindarising.org
risingl@acm.org

Linda Rising has a Ph.D. from Arizona State University in the area of object-based design metrics. Her background includes university teaching as well as work in industry in telecommunications, avionics, and strategic weapons systems. She is the author of numerous articles and has published three books: Design Patterns in Communications, The Pattern Almanac 2000, and A Patterns Handbook. She is currently writing a book with Mary Lynn Manns: Introducing Patterns (or any Innovation) into Organizations, to appear in 2003. 

[ Back to Top ]

Verifying PROM'ed Systems by Checksums

By Thorkil Bjørn Rasmussen
DDC-I A/S 
Senior Software Engineer
DACS Product Champion

General:
The following outlines how use of checksums may be used to establish system consistency, and how DDC-I software can help in this respect.

The discussion applies to 32 bit variants of DACS-80x86, that is for i386, i486 and Pentium.

Checksums - Why and How
In order to verify the correctness and validity of systems, it may be necessary to apply some forms of checks. This is true regardless of the medium that holds the binary code and constants, whether it is a disc, RAM, PROM or some other form of memory.

If e.g. the PROM is damaged there is a good chance that the program will not start up due to damaged system tables - you will know that something is wrong. However, there may be isolated bit errors at odd locations which still would allow the system to start-up, but then fail down the road.

Adding checksums allows you to include a positive verification. There is also the aspect of version control - does the system really consist of that particular build? Well, if you record the checksum information, there will be no doubt.

To this end the DACS-80x86 target linker includes a capability to generate individual checksums for each segment. DACS never relies on initialized memory, so only constant- and code-segments need consideration.

It is worth noting, that the target linker can be instructed to include a complete binary file as raw data with a segment name (the RAW directive), so that application dependent constant data may be not only added at link time, but also subjected to checksum control, similar to the constant- and code-segments The RAW directive creates a segment with a specified name, and with the contents from a specified host file on the host system.

The technique used by the target linker for handling checksums, is to create an additional (special) segment called LCI (load control information), which is placed last in the LDT (local descriptor table). The LCI contains checksums and other information for the segments. Since this special LCI segment is initialized by the linker, it is also itself being subjected to the checksum'ing. It can be thought of as a checksum on all the other checksums. The entries in the LCI segment refer to segments in either the GDT or the LDT tables, and some of these LCI entries denote a checksum value, which should match the value you would get, if you added all the DWORDs of the segment.

Checksums at Run-Time
If the target linker has been instructed to create the LCI segment, the application can verify the checksums at run-time. In order to do this the application needs a way to address the memory in question. The system tables GDT, IDT and LDT are readily readable, but others such as the TSS and LCI are not. However from LDT and GDT the base addresses of all other segments as well as their sizes can be obtained. In flat mode systems this is sufficient to read any segment's DWORDs, but in protected mode the user must provide an "all" segment that covers the memory from physical zero to top of physical memory to allow the checksum'ing. When run under debugger control, the debugger has created such a segment, which can be searched for and reused, but otherwise a target linker directive must be added to the build configuration file that adds such a segment to either the GDT or the LDT (a target linker DAT directive can be used, with the OVERLAP keyword). Please note that the debug monitors do not accept to load programs for debugging that have such (overlapping) all segments, and that such a DAT directive should only be used, when target linking for PROM.

Once such an all segment in protected mode has been established, or always in flat mode, the LCI segment entries may be scanned for checksum information and each checksum entry verified against the actual PROM'ed data. For most segments this does not pose any problems, but the system segments typically change, when code is executing. Again there are several models: the system tables may be residing in PROM, in which case they can not change, or they may be loaded from a floppy disk or solid state 'disks', in which case they are alterable. A GDT or LDT entry typically changes, when the segment it corresponds to is accessed. The target linker can be instructed to set this 'accessed' bit at link time to reduce the GDT/LDT changes (option PREACCESS), but this can not be extended to the TSS segment entry, so this will invariably be one bit off (though it can be accounted for). The contents of the TSS segment itself is also bound to change, because registers are recorded in the segment during start up - this may also be compensated to some extent. Finally, having breakpoints set in the code (when debugging) also changes the checksums for those code segments, where breakpoints have been set.

DDC-I Package Available
DDC-I has developed a package that allows for checksum'ing of segments in a program that is loaded using the DDCILOAD method (loading from floppy or solid state disk, as is common on PC bare systems). A simple interface allows the caller to verify that all segments are consistent, and that those that are not, are those expected to deviate. Please contact DDC-I for more information about this package.

Other applications typically start up by copying themselves from PROM to RAM, and setting up new GDT, LDT, IDT or TSS tables. In such a case checksum code should attempt to use the original versions of the tables, since these are exactly what the LCI describes. Accessing the original tables require just getting to the original GDT, and DDC-I can help provide a method to do this, once the used load method is known.

Verification of the physical destination RAM should be tested by power-up self tests, so this is not an issue when looking at the checksums, but of course the purpose could be to verify exactly the code and constant segments that are actually executed or read, so a 'hybrid' that checks the system segments from their original locations in PROM and the other segments from their RAM copies could be desirable. Again DDC-I can help setting up such a scheme.

Conclusion:
Including system checksum information increases the system reliability and aids in keeping track of versions; this all saves valuable time as problems are detected early. Please contact DDC-I if you are interested.

[ Back to Top ]