IBM and Olympic officials prepare for the herculean task of information management at the 1996 Summer Games
Salvatore Salamone
Programming rule number 1 is, Understand the end user's needs. But can you go too far? One programmer recently learned how to saddle up a horse, don a riding helmet, and fly off across a steeplechase course with the snap of a riding crop. While hanging on, he made notes about how to process scores so that they can be collated and displayed in three-tenths of a second. He's part of the programming team that is helping to create the massive technical infrastructure for the 1996 Summer Olympic Games in Atlanta.
This team is the ultimate example of technology convergence. Network administrators study grand prix racecourses to design the best systems to monitor bicycling events. UI (
user-interface) gurus attend triathlons to help figure out how on-air commentators can call up athlete biographies fast enough to make TV viewers think broadcasters know everything.
The system being implemented for the Olympics centers around a distributed database that gives officials the flexibility to change how pertinent data is assembled, displayed, and disseminated at each sporting venue. At the same time, the system provides enterprise-wide control over the data to ensure its integrity.
To accomplish this feat, the Atlanta Olympic Committee along with its technology partner, IBM, developed a distributed database system with one unusual twist. "We're putting together a Fortune 500 enterprise with a going-out-of-business strategy," quips
Bob Neal
, director of IS services for ACOG (Atlanta Committee for the Olympic Games).
Meeting the Challenge
Much of the technology used for what Olympic officials boast is the "largest peacetime event in his
tory" can be directly applied to commercial businesses. This is one reason IBM is donating much of the approximately $40 million technology cost of the project. Besides the promotional benefits of being a technical sponsor, Big Blue hopes to learn new tricks by tackling information management hurdles surrounding athletes who must jump more traditional hurdles. Lessons learned may help commercial banks with a large number of branch offices develop autonomous client/server loan-processing systems that tap into customer information residing on central mainframes.
However, Olympic officials face some challenges that few corporations ever encounter. Besides the temporal nature of the event, the Olympics is staggering in its magnitude. If sports in general are a statistician's dream, the Olympics is nirvana. Consider this: The Games encompass 10,000 athletes, 26 sports, 30 competition venues, and 17 days of competition. What kind of technical muscle lies behind this? There are 105 programmers (with 15 more to
come later), 7000 PS/2s and ThinkPad notebooks, 80 AS/400s, 250 LANs, three IBM System 390 mainframes, and approximately 160,000 E-mail accounts.
As if size isn't challenge enough, there's one more overriding pressure: Everything must work when the Games begin. The technical staff can't roll back the start-up date because of software bugs, hardware incompatibilities, or the desire to add one more feature to an application. Small delays in system operation can't be tolerated. TV broadcasters want to display an athlete's time and picture on the screen as he or she crosses the finish line, not 10 seconds later.
To lessen the risk of system failures, ACOG, for the most part, chose proven technology. And in areas where vastly different systems must interact, ACOG uses its own testing lab, where interoperability snags can be worked out before equipment is deployed.
Three Tiers
The Atlanta information system consists of three main components that are being developed separa
tely:
-- A results management system,
which collects raw data, performs necessary calculations, and makes the results available to the spectators, Olympic officials, and the press.
-- Info'96
, which provides athletes, their families, the press, and dignitaries with event and transportation scheduling, results, weather reports, Olympic news, and athlete biographies.
-- An operations management support system,
which handles accreditation for more than 150,000 people.
The first test of the results management system took place during a 120-mile grand prix bicycle race in May. At that time, the systems that processed and disseminated results worked without a hitch. The first large-scale test of the results system was scheduled for a rowing national championship held in June. After that, a number of small trials throughout the year will test the integration of the systems.
The key was settling on a common system architecture. O
fficials sought an architecture that was reliable, flexible, and fast enough to meet the needs of the Olympics. The search for such an architecture began in the fall of 1991, soon after Atlanta learned that it would be the host city. Neal, who has IT (information technology) experience but no previous Olympic experience, contacted the International Olympic Committee to see what was used in the past. "We got lots of war stories but not a lot of usable systems," he recalls. Neal benefited most from the 1992 Winter and Summer Games held in Albertville and Barcelona. From studying and working at them, he found patterns to guide the Atlanta efforts (see the figure
"Third Time's a Charm"
for illustrations of all three systems).
For example, the system used in Albertville had a strong mainframe component but was weak on the venue side. Essentially, the host was used to store, manipulate, and disseminate all the information, while the venues were little more than LAN-based front ends to the
data on the hosts. This system provided a common database for all the information of the Games. However, if the host or the lines connecting a venue to the host were unavailable, the people at the venues were on their own.
Additionally, this setup lacked the flexibility to make quick changes, because any modification required mainframe programming. Unfortunately, changes are a fact of life in the Olympics. The international federations for the various sports regularly change requirements or scoring systems on the fly. And during the 1992 Olympics, there was a more unpredictable change: Athletes from what was then the crumbling Soviet Union arrived at the Games as new countries were forming. This required new tables to be created in mainframe databases.
Client/Server Muscle
In contrast to the host-centered architecture used in Albertville, the Barcelona systems were strong at the venue level but weak on the host side. Thus, venues had autonomy, but the separate databases m
aintained at venues led to discrepancies in data. For example, an athlete's name might be spelled Smyth one day and Smith the next -- quite an identity crisis.
Neal and his group combined the best of both architectures. An IBM mainframe acts as a common database and repository to store all pertinent information about the athletes as well as the final event results. Additionally, the IBM host functions as an unbelievably large enterprise server that acts as the switch through which all results are distributed to the world. At the same time, the system gives venues autonomy and responsibility for virtually all the processing and preparation of results. The venues also distribute the final results to on-site people, such as event officials, spectators, and the media.
Additionally, the processed results data must be replicated from the venue database to the IBM host database for further dissemination. This replication is done using standard DB2 data transfer technology, where the venue data (collected
and stored using DB2/2, which is a version of DB2 for OS/2) is passed to the mainframe using a product from IBM called Distributed Database Connection Services.
There are about 70 venues and 10 associated facilities (e.g., the press center, the administrative offices, and the athletes' village). They range in size from the massive primary Olympic Stadium to small temporary setups spread throughout the area. Despite the size differences, all venues share some common features. For example, they all must deal with data acquisition, processing, and printing results for officials and the press.
The hardware in the venues consists of PS/2s, AS/400s, and Lexmark 4039 printers. The standard results management system venue configuration (
see the figure
) is a token-ring LAN with a results server running OS/2 LAN Server, OS/2 Warp, and DB2/2 server and client software. Attached to the token-ring network is an event management workstation, which runs OS/2 Warp and DB2/2 client software.
Additionally, each venue has workstations that act as subsystem controllers that drive scoreboard displays, feed the results to TV graphics systems, and pass the results to a press data system.
Because the system can't tolerate failures during an event, redundancy exists in the system, including dual token-ring networks. Additionally, each venue has LAN-attached Lexmark printers to produce the results for event officials and the press. Also attached to the LAN is a CIS (commentator information system) control station, which makes results available to TV commentators so they can better describe the action on the field.
One challenge in developing the results management system is that the results for each sport are so different -- points versus seconds, for example. "We have 26 sports and 37 different subprojects," says Jim Thompson, project manager for IBM results timed sports.
Selecting a common database architecture for all sports simplified matters. However, it still required knowledge of
all the sports to set up the appropriate database tables and structures. To help the developers, every sport submitted a set of requirements spelling out the types of information needed during an event and what constitutes official results.
For each sport, an ACOG competition manager (usually a member of that sport's international federation or governing body) helped the developers interpret the rules of competition. Some developers really got into their sports, including the programmer who took up horseback riding to get a better understanding of equestrian events. Besides having different results requirements, the results systems have to handle different types of raw data.
For the track, cycling, and swimming events, the incoming data is typically the time it takes each participant to finish a lap. Swiss Watch (Swatch) is responsible for the timing systems. It feeds this information over a serial link to the results management system in the venue. Pen-based laptops were developed for recording o
ther types of results (see the sidebar "Getting Into the Action").
Regardless of the form of the raw data, once it is passed to the results management system, it is handled in much the same way. The raw data is imported into a DB2/2 DBMS. Any calculations and manipulations required to turn the raw data into official results are then performed at the venue.
Performance counts in the venues. Many of the systems that use the results have very stringent time requirements. For example, the CIS and the TV graphics systems need the information virtually in real time. Specifically, the results management system must take the raw data, process it, put it into the appropriate format, and make it available to the CIS and the TV graphics display systems in three-tenths of a second. In the racing sports, printed results must be in the hands of the press 5 seconds after each lap. The system can have printed intermediate results, such as the lap times of the top 10 or 20 athletes, in the hands of people in 2 min
utes.
Distributing Information
The results must also be made available to people in other venues and to news agencies. To accomplish this takes a sophisticated infrastructure that includes use of public and private frame-relay and ISDN circuits, an ATM (asynchronous transfer mode) backbone (between three sites) that serves as a communications hub for the smaller venues, and lots of redundancy.
Processed results are replicated (using Distributed Database Connection Services) to a DB2 mainframe database. Once on the mainframe, several things happen to the results. They are replicated to two more mainframes. One of the two is a backup system (in the data center) that normally runs network applications. It can be called into action in a matter of minutes if there is a problem with the first system.
The data is also shipped off-site to a remote location in the event the data center is lost. If that happens, the estimated time for recovery is 1 hour. In all previous Games,
it was 24 hours. The significant improvement is because past Games relied on tapes that were dumped at the end of each day and transferred off-site. For Atlanta, any time there are changes on a volume, a system uses extended remote copy procedures, where the changes are automatically sent over a high-speed link to the disaster recovery site.
At the same time the printing is being performed, the results are also passed to an RS/6000 with serial communications cards that connect to news agencies. Each agency has a different serial-data format that must be taken into account. The RS/6000 was selected for its processing power and because it can accommodate 32 serial ports. Compared to other options, this offered a consolidation of equipment. The results are also distributed to the Info'96 system. The results pass down from the mainframe to AS/400s scattered throughout Atlanta, and then the scores can be displayed on any of the 2000 kiosks connected to the AS/400s.
Intelligent Information
With such diverse systems, there is a tendency to keep them separate. Neal wanted to avoid duplication of efforts by using information intelligently -- reducing redundancy. The idea is to save time by taking advantage of natural synergies.
For example, every athlete must be accredited before the games. Rather than requesting this information numerous times, this information is used by several of the systems. For one, this information is used to create lists of athletes for the venue databases. Each morning, the venues tap the host database and pull down a list of participants for each event in that venue. This saves time at the venue because the names do not have to be entered each day. Besides saving time, this ensures that all participants' names are spelled correctly (or at least consistently) from day to day -- something that was a problem previously when the venue databases were not synchronized with the host.
Information about each athlete is also used by Info'96 and the CIS, bo
th of which let people look up biographical details about each participant. Additionally, much of the information gathered in the accreditation process is used by the operations management support system to give athletes access to facilities. When an athlete registers in Atlanta, personal information is encoded onto
an ID card chip
. This card allows access to all the facilities as well as to the sports venues.
In more secure areas, such as the athletes' village, a biometric measurement of hand geometry is required before entry is permitted. (A hand-geometry measurement is taken when the athlete registers and is stored on the ID card.) Although access verification happens locally, a host component runs a security check to make sure the athlete has access rights to the facility. This jibes with Neal's desire for strong host and venue elements.
By tapping the strengths of host-based DBMSes and client/server development environments, IBM and ACOG hope the computer systems at the Ol
ympics perform at the same world-class level as the athletes.
WHERE TO FIND
IBM Corp.
Raleigh, NC
(800) 426-2968
Chalk Talk
THE CHALLENGE
-- Develop information systems
with the performance and flexibility
to handle the largest competitive sporting event ever staged.
-- Systems must work
as designed and without fail.
THE PROBLEMS
-- A hard deadline
with no room for rollout dates to slip.
-- Massive amounts of
scores, schedules, and other data must be
available almost instantaneously.
THE SOLUTIONS
-- A distributed database
system that uses client/server
technology for autonomy and flexibility.
-- A host enterprise server
that distributes data to news services
and to people not at the locations where e
vents take place.
THE BENEFITS
-- Autonomy of venues
ensures that they can operate even if the
host is unavailable.
-- A common host-based database
ensures data consistency and allows
for intelligent use of data by many systems.
LESSONS LEARNED
-- Rely on both
a strong host component and a strong client/server
component for distributed databases, such as those for large
companies with a number of branch offices.
illustration_link (25 Kbytes)
The
Albertville information system
relied on a central
mainframe with a common database to store all athlete data and scores. Officials at the venues couldn't easily change how scores were collated or reported.
The
Barcelona games
used the opposite approach of autonomous venues, each with a database for individual sports. Separate databases led to discrepancies in data.
The
Atlanta games
will use the best elements of the Albertville and Barcelona systems. The results management system in each venue receives raw performance data and processes it into final scores according to the criteria for each sport. Scores are then distributed on-site to officials, the press, and spectators, as well as replicated to the central data center, which maintains data integrity.
photo_link (40 Kbytes)
photo_link (11 Kbytes)
Salvatore Salamone is a BYTE news editor in the New York City bureau. You can reach him on the Internet or BIX at
ssalamone@bix.com
.
Olympic-Size Data Pool
