Case Study - JEDMICS

Background

The Joint Engineering Data Management Information and Control System (JEDMICS), formerly known as EDMICS before the "joint" services status was added, is designed to provide a modern means of storing and retrieving engineering drawings and data in electronic repositories through the use of various optical, digital and magnetic mass storage devices, digitizing scanners, graphics hard copy devices, graphics display workstations and communications devices. JEDMICS addresses the needs of the primary and secondary engineering repositories for the United States Armed Services and the Defense Logistics Agency, including activities such as Navy Shipyards, Naval Aviation Depots and Army and Air Force maintenance depots.

A key element of JEDMICS is the conversion of repositories for engineering data, which include both drawings and documents, into digital format and storing the data on optical disk to support changes in depot maintenance processes. These repositories will store 190 million engineering drawings and 500,000 technical publications. Such an extensive amount of data in JEDMICS repositories represents an enormous investment in labor and in the establishment of workflow processes to utilize that data. It, therefore, is critically important that the JEDMICS investment be kept technologically fresh. This puts tremendous emphasis on platform and software interchange and interoperability.

Definition of Existing Environment in Existing Terms

JEDMICS can be viewed as several subsystems: Input, Data Integrity, Index, Optical Storage, Graphics Display Workstation and Output. The functional view of the JEDMICS architecture is shown in the following figure:

Figure 1 - Functional View of Existing JEDMICS Environment

The Input Subsystem is the primary entry point for scanning drawings, aperture cards, and documents into JEDMICS. The major hardware components include (1) large-format scanners; (2) dual-sided page scanners; (3) high-speed aperture card scanners.

The Data Integrity Subsystem provides for the processing of scanned images that temporarily reside on magnetic storage while awaiting quality assurance on Data Integrity Control workstations.

The Index Subsystem provides for the inquiry and access of image-related index information upon being scanned into the JEDMICS system.

The Optical Storage Subsystem provides for the storage of image data on both multiple disk autochangers, "jukeboxes", and standalone single-disk devices. The stand-alone units provide backup for the jukebox and, in addition, are a means for exchanging data between sites.

The Remote Output (Workstation) Subsystem provides the capability to access image and index data that resides in the Data Integrity Control and Optical Storage Subsystems. The Multifunction Graphics Display Workstation provides the ability to view an image and direct output to a hardcopy output device. The multifunction capability of this workstation allows the site to access different systems from the same hardware platform. The Engineering Graphics Display Workstation provides a true raster editing capability.

The Output Subsystem provides for a variety of output devices and media types for JEDMICS engineering data. Output capabilities include aperture card production, high-resolution hardcopy plotting, large-format printing, and high-speed printing.

The topology of the existing JEDMICS is shown in the following figure:

Figure 2 - Existing Hardware Topology

Restatement of Existing Environment in TOGAF Terms

The existing JEDMICS environment follows a distributed computing architectural model. A client JEDMICS application on a workstation communicates with server applications on the Index Server and Optical Data Management Server to retrieve engineering data and display it at the workstation. The Input Subsystem works as a client communicating with the Data Integrity Subsystem server to enter engineering data into JEDMICS. The data, once subjected to quality control checks, is then transferred from the Data Integrity (Pending) Server to the Index and Optical Data Management Servers to be entered into JEDMICS permanent storage.

The Output Subsystem also acts as a client to the Index and Optical Data Management Servers to output JEDMICS data. Requests for output are initiated by the Workstation client and communicated to the Output Subsystem. The Output client application requests the data from the Index and Optical Data Management Servers and outputs it to aperture cards, tapes, printers, plotters, CD-ROMs or any other output device available to JEDMICS.

The general diagram for the JEDMICS distributed computing model is shown in the following figure:

Figure 3 - JEDMICS Distributed Computing Architecture

The existing environment can be restated in TOGAF terms using the following table that maps the existing JEDMICS components into the standard application platform services:

Figure 4 - Mapping of Services to Existing Architecture

The standard application platform services provided in JEDMICS perform the following specific functions:

Views, Constraints and External Environments

Operations View

In the Operations view, the key operational aspect of the system is the storage of engineering data and the retrieval by users of that data. JEDMICS is designed to be the authoritative repository for all DOD engineering data. The majority of the engineering data to be stored is in the form of drawings. Drawings consist of sheets and frames of data and can have accompanying documents associated with them. Drawings and drawing sheets can be revised and the coherent basis for each set of revisions among the drawings and drawing sheets must be made. Additionally, sets of drawings or individual sheets may be associated with each other to create sets that can be used for procurement, manufacturing, and maintenance of objects described by the drawings.

Because the JEDMICS is to serve as the authoritative repository of engineering data, strict quality controls are placed on all data entering the system. This quality control function is exercised by staging input to interim magnetic storage first, and then migrating the data to optical disk for permanent storage once it has been checked. Data placed in permanent storage may be accessed by local and remote users and viewed or printed as needed. Each piece of data in the system must be able to be accessed by drawing number, manufacturer, description, and weapon system.

Figure 5 - Operations View

Management View

The management view of the system is that the user has a role in the system according to the function that they are performing. This view partitions the users of the system into the following categories:

Figure 6 - Management View

Security View

The security view has two types of security mechanisms. Each user has a unique user ID and password that allows him or her access to certain categories of data. In addition, each hardware device capable of inputting or outputting data has restrictions on the category of data that it can operate on. Data can be input, viewed, printed, and output only if both the user and the input/output device have the prerequisite access authority to the required categories.

Figure 7 - Security View

Constraints

JEDMICS provides the means for the acquisition, storage, management, and distribution of engineering technical data as well as the wide variety of other published material related to the operation and maintenance of ships, airplanes, and weapons systems in the Services. With JEDMICS, this information is received, stored, accessed, and transferred digitally on optical disk.

The optical disk technology in JEDMICS is the cornerstone of the weapons system acquisition process improvements anticipated through CALS. The repositories of drawings maintained in JEDMICS are the source for the efficient distribution and sharing of the large volume of complex engineering drawings and technical data.

JEDMICS has replaced the current manual and semi-automated aperture card-based repository functions with a fully automated optical disk-based system that will enhance access, timeliness, and product quality for the primary Government users of engineering drawings.

The current JEDMICS was constructed using an open-systems approach to software development, the integration of commercial-off-the-shelf (COTS) hardware/software, training, maintenance, site surveys, and system design plans. The JEDMICS contract included a technology refreshment clause that allowed for the incorporation of new technology as it became available. The system was initially deployed with VAX computers as the Index Server, Sun Sparc 1+ computer workstations for Editing Workstations, and Zenith 286 computers for the User Workstations. Because Open System principles were adhered to during the JEDMICS design, the system has evolved to SGI Challenge POSIX index servers, Sun Sparc 5 Editing Workstations, and Pentium User Workstations. The latest software version fielded for the 36 systems in use supports both of these configurations (original VAX and current SGI), plus intermediate technical refresh configurations. Only minor software differences exist, and only because of the operating system differences between the VAX (non-POSIX compliant VMS operating system) and the SGI (POSIX compliant IRIX operating system). A uniform software baseline is supported across all installations.

The major constraint is that the target architecture should be compatible with the existing hardware suite already fielded to users. COTS software already purchased and fielded with the earlier version of the JEDMICS software should also be retained in the target architecture. Specifically, the ORACLE RDBMS represents a significant investment and must be retained. COTS drawing viewers and editors as well as special purpose hardware devices are not subject to redesign. The workstations and server computers have been refreshed periodically with new technology, but the current assets represent too large an investment to replace. Similarly, all of the data entered into existing JEDMICS sites must be transformed, with no loss of information, to a new target architecture.

The other constraints associated with the existing base of hardware and software are:

A final business process constraint is that the old and new software systems must coexist during the transition period of all 36 sites.

Goals

Besides the constraints that the existing COTS hardware and software impose, certain business goals and objectives also affect the target architecture. As part of the most recent change in system specifications, the JEDMICS customer has specified that the software be redesigned using object oriented programming models and the DOD-STD-2167A life-cycle methodology. (The DOD-STD-2167A life-cycle is a formal "waterfall" software development model designed to produce maintainable, complete, and correct software systems). The motivation for using object oriented programming models was the desire to increase the maintainability of the software in the future and to provide sufficient isolation layers to allow the system to evolve as a repository. Because of the aging base of fielded weapon systems, engineering data contained in JEDMICS repositories will still be providing long term support to users well into the next century.

External Environments

The network used at each JEDMICS site is part of the local environment and, as such, the existing JEDMICS coexists with other networked systems and equipment. The new target architecture will also be required to fit into existing external environments without disruption of the site's other missions. JEDMICS, within certain limits, also must be portable to user provided workstations and other equipment such as printers and plotters. The data created using the existing JEDMICS software must be transferable to the new JEDMICS target architecture without any data loss and with a minimum of disruption.

Target Architecture

The target architecture for the new JEDMICS software followed a number of goals:

  1. Make maximum use of existing equipment.
  2. Follow Open System precepts for portability, interoperability and vendor independence.
  3. Use Object Oriented Data Base techniques to isolate specific technology choices.
  4. Use COTS software to lower conversion costs.

Based on the analysis of the user functional requirements, the new JEDMICS subsystems were partitioned along object oriented boundaries. The subsystems in the target architecture are:

  1. Session Management subsystem - Handles all user-level interaction in a consistent manner.
  2. Distributed Object Management subsystem - Manages all of the engineering data contained in JEDMICS regardless of specific location.
  3. Drawing Management subsystem - Maintains all of the special relationships associated with drawings, drawing sheets, drawing revision and accompanying documents.
  4. Input and Output subsystem - Handles all input and output of data to JEDMICS in a uniform and consistent manner.

The target JEDMICS environment still follows a distributed computing architectural model. A client JEDMICS Session Management application on a workstation communicates with the Distributed Object Management server application to enter and retrieve engineering data on the Index Server and Optical Data Management Server. This engineering data is displayed at the workstation. The Session Management application can also communicate with the Drawing Management application to request or set the various drawing management relationships. The Input and Output application works as a client communicating with the Distributed Object Management server application to enter engineering data into JEDMICS. The Distributed Object Management server application makes use of a relational data base management system (Oracle - existing) and a network data object manager (SQL*NET - new) to store data in JEDMICS.

The Input and Output Subsystem also acts as a client to the Distributed Object Management server application to output JEDMICS data. Requests for output are initiated by the Session Management application client and communicated to the Input and Output Subsystem. The Input and Output client application requests the data from the Distributed Object Management server application and outputs it to aperture cards, tapes, printers, plotters, CD-ROMs or any other output device available to JEDMICS.

The general diagram for the new JEDMICS distributed computing model is shown in the following diagram:

Figure 8- The New Distributed Computing Arichitecture

The functional components of the new JEDMICS system architecture are shown in the following diagram:

Figure 9- The New JEDMICS Functional Architecture

Using object oriented methodology, the functional architecture becomes simpler and more direct. The target architecture will use these standards for each of the Application Platform Services:

Service Standard Description
Data Interchange MIL-STD-1840B, MIL-STD-28002 CALS data interchange
Data Management ISO/IEC 9075 SQL data definition
Graphics & Imaging MIL-STD-28002 CALS raster image format
Network   TCP/IP, TFTP
Object X/Open G302 Object definition and registration
Operating System IEEE Std 1003.1-1990 POSIX
Software Engineering ISO/IEC 9899 Programming languages - C
Transaction Processing    
User Interface X/Open C150, C160, C320 X Windows and Motif API

Migration

The migration phase will require moving the 36 sites from their old system to their new target architecture. One of the elements that will simplify the transition is the decision to maintain all of the drawing images saved on optical media in their current raster format. While images remain the same, the index structure in the Oracle data base will be radically changed. This will necessitate the transfer and conversion of all currently entered drawing index data into the new object oriented data base structure. A separate conversion effort will address these activities. The implementation of the conversion will require that both the old and new software architectures will be briefly run in the same user environment.

New software COTS products will be installed at the sites during migration, and translation software will be in operation to allow interoperability between sites running the old and new architectures.


Copyright © PRC, Inc., The Open Group, 1998