THIS OPINION WAS INITIALLY ISSUED UNDER PROTECTIVE ORDER AND IS BEING RELEASED TO THE PUBLIC IN REDACTED FORM ON JULY 22, 1993 DENIED: July 9, 1993 GSBCA 12417-P INTEGRATED SYSTEMS GROUP, INC., Protester, v. DEPARTMENT OF THE ARMY, Respondent, and SYSCON CORPORATION, and INTERMEC CORPORATION, and FEDERAL COMPUTER CORPORATION, Intervenors. Shelton H. Skolnick, Judy D. Leishman, and Amy M. Hall of Skolnick & Leishman, P.C., Derwood, MD, counsel for Protester. COL Riggs L. Wilks, Jr., MAJ Charles R. Marvin, Jr., MAJ Karl M. Ellcessor, III, MAJ Roger D. Washington, and MAJ Rose J. Anderson, Office of the Chief Trial Attorney, Department of the Army, Arlington, VA, counsel for Respondent. Arthur M. Rayman of SYSCON Corporation, Washington, DC, counsel for Intervenor SYSCON Corporation. John W. Sobba of Intermec Corporation, Everett, WA, counsel for Intervenor Intermec Corporation. David S. Kovach of Federal Computer Corporation, Falls Church, VA, counsel for Intervenor Federal Computer Corporation. Before Board Judges BORWICK, HYATT, and GOODMAN. GOODMAN, Board Judge. Protester, Integrated Systems Group, Inc. (protester or ISG), has protested the terms of a Department of the Army (respondent or Army) solicitation no. DAHC94-93-R-0002 (the solicitation) for the purchase of Automatic Identification Technology (AIT), which includes Portable Data Collection Devices (PDCDs), commonly known as hand-held computers. Protester filed its protest on May 5, 1993, before the time established in the solicitation for receipt of proposals that same day. Three offerors - SYSCON Corporation, Intermec Corporation, and Federal Computer Corporation - have intervened in the instant protest. The ground of protest which remains to be resolved is whether the Army exceeded the Government's minimum needs and unduly restricted competition by including MS-DOS requirements for the PDCDs.1 Protester argues that the Government's minimum needs are specific functions and capabilities that can be fully satisfied by PDCDs operating systems other than MS-DOS 5.0 or compatible. According to protester, similar needs have been fully satisfied by the two prior contracts that acquired PDCDs with proprietary operating systems. Even if the Government's minimum needs are for an open system, rather than a proprietary system, protester believes there is no justification to exclude earlier versions of MS-DOS prior to MS-DOS 5.0 for the operating system of the PDCDs and MS-DOS 3.31 for the operating system for the intrinsically safe PDCDs. According to protester, earlier versions of MS-DOS provide open system compatibility and, when used in conjunction with third party software, provide the increased functions of memory management that were introduced in MS-DOS 5.0. Finally, protester argues that even if MS-DOS or compatible reflects respondent's minimum requirement for the operating system of the PDCDs, the specification which describes the operating system for the PDCDs is a "brand name or equal" specification which requires the solicitation to list the salient ____________________ 1 Several grounds of protest were withdrawn by protester during discovery, and respondent's motion for partial summary relief with respect to count 2 of the protest, specifically, the part of count 2 which challenges the Army's evaluation methodology as being "unclear," and any similar issue incorporated by reference from protester's agency protest, was granted by the Board's decision of June 9, 1993. characteristics so that an offeror can select an acceptable operating system.2 Respondent's position is that through the AIT procurement, the Government seeks to establish a technological baseline and create a more "open systems" architecture for hand-held computer equipment, thereby taking advantage of the benefits associated with such an environment. Respondent argues that the proprietary operating systems which were provided on PDCDs in two prior procurements cannot now meet the Government's AIT needs, and that a concerted and rational effort was made by the Government to arrive at the decision to include the MS-DOS 5.0 compatibility specification for the operating system as minimum requirement. Respondent further avers that there are many reasons for including the minimum requirement of the MS-DOS 5.0 compatibility specification for the operating system, rather than a previous version of MS-DOS , and that the lack of 386 or higher microprocessor in the PDCD does not limit the memory management functions as alleged by protester. With regard to the "brand name or equal" argument raised by protester, respondent argues that the MS-DOS 5.0 compatibility specification for the operating system is itself a salient characteristic of the hardware (or software) to be procured, or that it is self defining and no further explanation is required. For the following reasons, we deny the protest. Findings of Fact Previous Procurement of AIT 1. The AIT procurement pursuant to the instant solicitation is the third in a series conducted over the past ten years. The two previous procurements acquired AIT which included bar code scanners and related items over a period of five years each. These procurements, known as Non-Tactical (NT) I & II, or the Logistics Applications of Automated Marking and Reading Symbols (LOGMARS) I & II, acquired technology with different proprietary operating systems and programming languages in 1983 and 1988. The requirement to program applications in a vendor-unique ____________________ 2 The specification requires the operating system to be "MS-DOS 5.0, or later, or an operating system that is fully MS- DOS 5.0 or later version compatible, with the exception of the intrinsically safe PDCDs. The intrinsically safe PDCDs' operating system shall be at least MS-DOS 3.31, or later, or an operating system that is fully MS-DOS 3.31 or later version compatible." This will be referred to in this decision as the "MS-DOS 5.0 compatibility specification" or the requirement for "MS-DOS 5.0 compatibility." language, and then re-code from one vendor-unique language to a completely different user-unique language for use with the LOGMARS II equipment, caused significant problems in the Government user community with respect to personnel re-training, re-programming difficulties, equipment utilization delays, and other transition costs. For example, in 1988, the difficulties encountered by the Navy in re-coding applications were so significant that the agency was forced to delay using the NT II equipment by nine months. Transcript at 232-33, 262-64. Development of Requirements for the Instant Procurement 2. The LOGMARS Acquisition Working Group (LAWG) was formed to develop the requirements for the instant procurement. The LAWG was staffed with members representing the General Services Administration, the Defense Logistics Agency, the Defense Mapping Agency, the Army, Air Force, Navy, Marines, Coast Guard, and Army Information Systems Selection and Acquisition Agency (ISSAA). Transcript at 258-59. 3. A "data call" was sent out to the using community to obtain user input as to the types of functionality and characteristics required by the users' applications, environments, and growth projections. Responses reflected concern over the possibility of receiving proprietary hardware and software from yet another vendor of bar code systems, and a need for a standardized operating system which would allow greater portability of the applications code. Transcript at 161- 70; Protest File, Vol. 9, Exhibit 47. 4. As a result, the LAWG sought to avoid in this procurement the need to translate the existing inventory of application software into yet another proprietary language, and to avoid re-translation in future procurements. The LAWG recognized that re-translation would be repeated every five years, unless the incumbent contractor was selected in the subsequent contracts. Transcript at 199-200. 5. After studying responses from the data calls and analyzing government needs, program management personnel conducted extensive market surveys to determine the existence and scope of competition in the relevant portion of the PDCD marketplace. As a result of these surveys, they determined that there were several manufacturers who could compete, offering PDCDs with at least two operating systems, providing the standardization necessary to prevent the need for re-coding and re-training. Transcript at 112-13, 207, 249-50. The Disk-Based Operating System (DOS) Requirement of the Instant Procurement 6. Before release of the solicitation in the instant procurement, ISSAA released a draft request for proposals (RFP) in November 1992, requesting comments from industry. Transcript at 366, 395. The draft RFP contained a requirement for MS-DOS 5.0 or WINDOWS 3.1 for the PDCDs' operating system. Of the approximately 600 comments received in response to the draft RFP, only one questioned the MS-DOS requirement. Id. at 208. That question did not challenge the requirement for MS-DOS compatibility, but only wanted to know whether the operating system would be resident on the PDCDs or the PCs. Id. at 207. The Solicitation 7. The solicitation was issued by ISSAA on March 5, 1993, Protest File, Vol. 1, Exhibit 1 at A-1, accompanied by a letter from the contracting officer informing offerors that the RFP, and responses to clarifying questions from potential offerors, could be accessed electronically through a bulletin board service established by ISSAA for that purpose. The date for receipt of proposals was established originally as April 5, 1993. This date was subsequently extended to May 5, 1993, at the request of vendors. Id., Vol. 2, Exhibit 2, Amendment 0001 at 2. 8. The solicitation is for the acquisition of hardware, software, maintenance, training, technical engineering services, and documentation to establish and utilize automated identification systems throughout the Department of Defense and certain civilian agencies. The solicitation is for a firm, fixed-price, indefinite delivery, indefinite quantity contract structured to provide a basic year and nine option years. The guaranteed minimum amount is $4,000,000; the maximum amount is $249,370,000. Protest File, Vol. 1, Exhibit 1 at B-1, C-1. 9. The MS-DOS compatibility requirement in the draft RFP was incorporated into the solicitation. Protest File, Vol. 1, Exhibit 1 at C-22. After release of the solicitation, ISSAA amended the solicitation to clarify further that the operating system requirement was a "DOS" (disk-based operating system) requirement, not an MS-DOS requirement, to allow competition from other DOS-based operating systems compatible at the MS-DOS 5.0 level or higher. Id., Vol. 2, Exhibit 4, Amendment 0003 at C-22a. For intrinsically safe PDCDs, the MS-DOS requirement was relaxed to MS-DOS 3.31 or compatible, after a review of the market prompted by industry comments revealed the unavailability of any PDCDs utilizing an MS-DOS or compatible operating system at the 5.0 level or higher. Transcript at 204-06; Protest File, Vol. 2, Exhibit 5, Amendment 0004 at 3; Vol. 4, Exhibit 30 at 2. 10. Section M.3 of the solicitation requires that the Army award the contract to the offeror who provides the "best value" to the Government. Section M.3 of the solicitation provides in part: M.3 BASIS FOR AWARD ("BEST VALUE" EVALUATION) An award will be made to that responsible acceptable offeror based on all evaluation criteria described in this section and is deemed to be in the best interest of the government considering technical, management and logistics, and cost, whose prices are otherwise determined to be fair and reasonable. M.4.3 Evaluation Areas of Consideration. Consideration shall be given to the areas below. Evaluation shall be based upon the criteria stated in Section M as well as the requirements stated in Section C. All mandatory requirements set forth in the specification shall be met. Protest File, Vol. 1, Exhibit 1 at M-2 to M-3. 11. Mandatory requirements of the procurement were set forth in Section C of the solicitation, and designated as minimum requirements. The solicitation reads, in pertinent part: C.3.1.2. Mandatory Requirements. The Contractor shall satisfy all stated technical requirements of this Specification and the referenced Attachments and Exhibit. Requirements are a stated minimum, unless specified otherwise. Protest File, Vol. 1, Exhibit 1 at C-2 to C-3. 12. The solicitation informs potential offerors of the applications and objectives of the AIT program: C.1.2 AIT APPLICATIONS. Some anticipated applications of AIT are in the areas of personnel identification, health care, food service, inventory management, logistics, retail sales, access control, transportation, and personnel management. C.1.3 AIT OBJECTIVES. The objectives of the AIT program are to provide: a common, integrated structure for the automatic collection, storage, retrieval, processing, transmission, and receipt of data; standardization and interoperability among Government users of AIT equipment; and flexible systems and equipment that can grow in size and capability, adapting to the needs of the Government. Protest File, Vol. 1, Exhibit 1 at C-1. 13. The solicitation states the following requirements: C.3.1.1 General. The Contractor shall provide all necessary hardware, software, firmware, cables, connectors, accessories, maintenance, training, and documentation. Because of the diversity of applications, the Government requires the Contractor to provide the technical engineering services to configure, operate, and maintain the appropriate hardware and software to satisfy the specific application. AIT equipment shall be user-friendly, commercial-off-the-shelf (COTS) equipment capable of operating worldwide. The Government will require Contractor assistance in completing necessary applications when AIT equipment is installed in foreign countries. All Contractor-supplied operating systems software and firmware shall be installed prior to delivery. AIT equipment shall be capable of supporting operations in both the tactical and non-tactical environment. A tactical environment is defined as similar to a heavy industrial setting that may have a potentially explosive atmosphere. In this rigorous environment, AIT equipment may be subjected to rough handling, operational use, shock, and vibration caused by dropping or transportation over rough terrain. A non-tactical environment is defined as a normal office or light industrial setting, both indoors and outdoors. . . . . C.3.1.7 Current Production. All equipment shall be state-of-the-art technology and in current production at the time the Demonstration, C.17, is performed. a. "State-of-the-art" is defined as the most recently designed components that are in current production, marketed, available, maintained, and supported in accordance with the mandatory requirements specified elsewhere in this document. Prototype or development equipment is not acceptable. Out-of-date or discontinued equipment is not acceptable. . . . . C.3.2 FUNCTIONAL INTEGRATION. The Contractor shall provide equipment capable of integrating with other provided AIT equipment into operating configurations necessary to accomplish the automated collection, storage, retrieval, receipt, processing, and transmission of data. Protest File, Vol. 1, Exhibit 1 at C-2 to C-4. 14. With respect to the PDCDs being acquired, the solicitation imposes the following requirements: C.4.4.1 General Requirements. Portable data collection devices (PDCDs) are microprocessor-based, hand-held devices designed to gather source-entry data. The Government has a requirement for family of PDCDs that meets a variety of operational needs in widely varying environmental conditions. Typical environments include office settings that require PDCDs with no hardening, a tactical environment that requires industrially hardened, intrinsically safe PDCDs, and a warehouse environment where one-handed operations will require bar code scanners embedded in or integral to the PDCDs. . . . The requirements may be met by as few as one or several versions, or models, of PDCDs. . . . The PDCD shall support a wide range of AIT applications. PDCDs shall have memory options for large applications, shall be user-programmable, and shall provide the operator with assistance or prompts to perform required functions. The PDCD shall be reliable and user-friendly. The PDCD shall be able to transmit stored data to a PC or host computer for further processing. C.4.4.2 Functional Requirements. The PDCD family shall be sufficiently versatile in order to satisfy the following requirements: real-time and batch processing; flexibility in attaching a bar code non-contact scanner or wand; bar code scanner physical integration with the PDCD; interface with peripheral devices used to read/write to integrated circuit cards, and Personal Computer Memory Card International Association (PCMCIA) PC memory cards; interface with a peripheral device used to read magnetic stripe cards; data collection in a location that requires an intrinsically safe device; and data collection for workplaces requiring industrially hardened devices. PDCD memory shall be at least 256 Kbytes of RAM that can be expanded in increments at the user's option, and by the user, to 512 Kbytes and 1 Mbyte of RAM, if less than 1 Mbyte of RAM is provided in the basic configuration. In addition to RAM, a minimum of 64 Kbytes of non-volatile memory modules for storage of applications programs shall be included in the basic configuration and shall use EEPROM technology. C.4.4.3 Interfaces. The PDCDs shall interface with the following peripheral devices: bar code scanners or readers; integrated circuit card reader/writers; PCMCIA PC memory card reader/writers; and magnetic stripe readers. Although the Government requires a family of PDCDs, this requirement could potentially be met by one, or several, PDCD versions that can interface with the peripherals, and are also capable of meeting the following requirements: the PDCDs shall accept data from a bar code scanner or reader, integrated circuit card, PCMCIA PC memory card, magnetic stripe card, or manual data entry by keypad or keyboard; the PDCDs shall write data to integrated circuit cards, and PCMCIA PC memory cards; and, the PDCDs shall support various types of bar code scanners, such as wand bar code scanners, hand-held, non-contact, bar code scanners, and badge (or slot) bar code scanners. For portable operation, the ICC and PCMCIA PC card reader/writers, and the magnetic stripe reader interface, shall be integral or attached to the PDCD. When in use with the PDCD, the ICC and PCMCIA PC card reader/writers, and the magnetic stripe reader, shall be as mobile or portable as the PDCD and shall not encumber the operator. The Government recognizes that the PDCD may no longer be intrinsically safe when the ICC and PC card reader/writers, and the magnetic stripe reader, are attached. Protest File, Vol. 1, Exhibit 1 at C-6 to C-7; Vol. 2, Exhibit 4, Amendment 0003 at 3. 15. The solicitation included the following requirements related to software: C.5 SOFTWARE REQUIREMENTS. AIT software is comprised of applications software, diagnostic software, and system utilities. Software shall be capable of being installed on PC-based hosts with minimal degradation in equipment performance. Each provided program shall run under MS-DOS 5.0 or Microsoft WINDOWS 3.0, or later. The PDCD operating system shall be MS-DOS 5.0, or later, or an operating system that is fully MS-DOS 5.0 or later version compatible, with the exception of the intrinsically safe PDCDs. The intrinsically safe PDCDs' operating system shall be at least MS-DOS 3.31, or later, or an operating system that is fully MS-DOS 3.31 or later version compatible. An intrinsically safe PDCD with MS-DOS 5.0 or compatible, or later version, is desirable. Protest File, Vol. 1, Exhibit 1 at C-22; Vol. 2, Exhibit 4, Amendment 0003 at C-22a, Exhibit 5, Amendment 0004 at 3. 16. The solicitation also requires the awardee to provide bar code application generation software able to produce source code in ANSI "C" and executable code for the PDCD. In addition, the solicitation states that the "ability to produce source code in BASIC and/or Ada in addition to C would be desirable." Protest File, Vol. 1, Exhibit 1 at C-23; Vol. 2, Exhibit 4, Amendment 0003 at C-23. Compilers including all necessary libraries to allow for calls activating full functionality of the PDCDs are required for ANSI "C," BASIC , and Ada programming languages. Id., Vol. 1, Exhibit 1 at C-23. 17. An operating system is a computer program that coordinates the activities of a computer. The operating system is responsible for setting guidelines under which common computer tasks are executed. MS-DOS stands for Microsoft Disk Operating System, manufactured by Microsoft Corporation. Version 5.0 was released in 1991. Steven Simirin, The Waite Group's MS-DOS Bible (Sams Publishing, 4th Ed. 1991). MS-DOS 6.0 was released in 1993. 18. DR-DOS 6.0, a Novell product, is considered by the Government to be compatible, for the purpose of this solicitation, with MS-DOS 5.0. Transcript at 113, 119, 124, 220. 19. The minimum system requirement for MS-DOS 5.0 is an 8088 or higher microprocessor and 256K of RAM. Microsoft MS-DOS Operating System version 5.0 User's Guide and Reference (Microsoft Corp. 1991). The minimum system requirement for DR- DOS 6.0 is an 8088 microprocessor and a minimum of 512K of RAM. DR-DOS Version 6.0 (Novell 1992). 20. Compatibility with MS-DOS 5.0 is determined in two ways -- by running applications which MS-DOS 5.0 is able to run, and by testing similarity of command functions. Transcript at 118-19. 21. It is extremely difficult to find MS-DOS versions below MS-DOS 5.0 on the current commercial market. Transcript at 394. 22. As part of Section C, identified as a minimum requirement, the solicitation required a demonstration of the performance of the offerors' equipment: C.16 AIT DEMONSTRATION PLAN C.16.1 GENERAL. As part of the proposal evaluation process, those Offerors determined to be in the competitive range shall demonstrate the hardware and software identified in the Offeror's proposal. C.16.1.1 Demonstration Objective. The Government shall inspect and observe all COTS AIT equipment proposed by the Offeror to satisfy the requirements of this contract. Using the scenarios in this plan, the Offeror shall demonstrate interoperability of all AIT equipment; complete end-to-end connectivity; and, the minimum functional use of each piece of equipment. The demonstration shall occur in two parts: 1) the Offeror's presentation of the AIT equipment following the scenarios provided in this plan; and 2) the Government's independent observation and operation of the AIT equipment. All participating Offeror's will be given equal opportunity to demonstrate Offeror-proposed AIT equipment and configurations during individually scheduled demonstration periods. The Government reserves the right to schedule additional demonstration periods to review deficiencies noted in any one demonstration. If this right is exercised for any Offeror, it will be exercised for all Offerors with demonstration deficiencies. . . . . C.16.2.2 . . . . f. Portable Data Collection Devices 1. Demonstrate the PDCD's expandable memory feature. 2. Demonstrate the ability of the PDCDs to perform real-time and batch processing of data by interfacing PDCDs with the following equipment: (a) Host Computer. Demonstrate the PDCD's ability to send and retrieve information from a host computer. (b) Cards. Demonstrate the ability of the PDCD to read and write data to Integrated Circuit cards, PC Memory Cards, and Optical Memory Cards. Demonstrate the ability of the PDCD to read ANSI/ISO Standard magnetic tracks 1 and 2 of the magnetic stripe on the IC Card. The demonstration should include, but not be limited to the following: any unique features, memory capacity, read/write/rewrite functions, card and data tampering protection features, and the connection to an AT-compatible computer via an RS-232C interface. (c) Software. Demonstrate the use of operating system software and application programs downloaded from a computer. Show a PC screen display that mimics the PDCD display. Download the generated code to a PDCD and demonstrate correct operation on a PDCD. Run the application generator on a PC utilizing the system prompts. Troubleshoot and modify the generated code by changing three lines of code. Demonstrate source code output in BASIC , ANSI "C", and Ada languages. (d) Modem. Demonstrate the transfer of data to a host computer using an RF modem. (e) Port Concentrator. Demonstrate the connection of multiple PDCDs to a host computer using the port concentrators described in C.4.14. (f) Scanners. Demonstrate interface capability with a bar code non-contact scanner and wand. Protest File, Vol. 1, Exhibit 1 at C-58 to C-59. Clarification Questions from Potential Offerors Concerning the MS-DOS 5.0 Requirements 23. On March 26, 1993, the Army issued RFP amendment no. 0001, which included the answers to questions submitted by prospective offerors. Question 5 -- pertaining to the MS-DOS 5.0 requirement in RFP paragraph C.5.2 -- stated: This new requirement (not part of the DRFP) is exclusionary to this contractor. Our operating system is DR-DOS 3.41 and is MS-DOS-3.3 compatible. Our choice of DR-DOS was made four years ago in order to take advantage of DR-DOS's capability of component shut-down to alleviate unnecessary power consumption during portable operations. All support PC-based software from this contractor operates under MS-DOS 5.0 or Microsoft WINDOWS 3.0. The new mandatory requirement for PDCD MS-DOS 5.0 operating system is an overly restrictive requirement and is, at this eleventh hour, impossible to satisfy without violating paragraphs 3.1.6 and 3.1.7. Would the Government consider modifying the requirement to accept MS-DOS 5.0 or DR-DOS 3.41? The Army's response to question 5 was: 1) Your reference above should be to C.5, not C.5.2. 2) The government requires compatibility with MS-DOS 5.0. There is no requirement for the solution to be MS-DOS. The Government believes that is clear in the RFP. Protest File, Vol. 2, Exhibit 2. 24. RFP amendment no. 0001 also included question 19, which stated: Request that the Government rescind the requirement for "full MS-DOS 5.0, or later compatibility. [sic]" because it severely limits competition and does not appear to be in the Government's best interests. Not all commercially available PDCD's utilize MS-DOS, and most of those that do, cannot support full MS-DOS 5.0 because of BIOS and/or memory limitations. Recommend that this requirement be restated as MS-DOS 3.3 or later compatibility in order to enhance the competitive nature of the contract. The Army's response to question 19 was: The Government requires compatibility with MS-DOS 5.0. There is no requirement for the solution to be MS-DOS as stated in answer #5 in Q&As, Set 1, posted to the ISSAA Bulletin Board System (BBS), 15 March 1993. Protest File, Vol. 2, Exhibit 2. Protester's Involvement in the Procurement and Submittal of Agency Protest 25. To act as proposal manager, protester secured the consulting services of Mr. Karl Bendorf 26. During the period April 7-29, 1993, protester submitted several questions to the Government regarding the AIT procurement. These questions sought clarification regarding various technical issues, the evaluation criteria, and the methodology to be utilized for scoring proposals. Protest File, Vol. 4, Exhibits 21-27. 27. On April 26, 1993, protester requested a thirty-day extension of the time for receipt of proposals due to allegedly unclear evaluation criteria. Protest File, Vol. 4, Exhibit 25. 28. On April 29, 1993, protester requested clarification regarding the relaxation of the MS-DOS requirement for intrinsically safe PDCDs from MS-DOS 5.0 to 3.31 or compatible. Protester professed an inability to understand the reason for the relaxation, stating that "[w]e were forced to select products with higher prices than we would otherwise have chosen, in order to accommodate the higher requirement for MS-DOS 5.0 on all units." Protester again requested a thirty-day extension of the closing date for the RFP. Protest File, Vol. 4, Exhibit 26. 29. On May 2, 1993, ISG submitted an agency protest to the Army which included, in part, the following objections to the RFP specifications: The government is procuring data collection devices which have no intrinsic requirement for a particular operating system. The government stipulates a need for a particular version of MS-DOS, 5.0. We are aware of no aspect of bar code data collection which requires MS-DOS, however, assuming some, as yet unspecified, need for MS-DOS we are unable to identify those salient characteristics which are sought by the government. Since there are many different "DOS's", each endowed with different characteristics, capabilities and features, the government must list the salient characteristics desired. After resisting all attempts by the vendor community to loosen these requirements for MS-DOS 5.0, the government, at the last minute, has allowed the use of a version of MS-DOS (3.31) for those data collection devices designed to be used in hazardous environments. Again, no salient characteristics were stated, nor was any reason given for limiting the intrinsically safe PDCD to MS-DOS 3.31. We can think of no reason for limiting DOS versions below 3.20. Protest File, Vol. 4, Exhibit 28. 30. On May 4, 1993, the Army contracting officer issued her final decision on ISG's agency protest. The final decision stated, in part, that: The initial minimum requirement of the Government was to acquire full compatibility with MS-DOS 5.0 in all PDCDs. However, relative to intrinsically safe PDCDs, the compatibility requirement was lowered to MS -DOS 3.31 to enhance competition for this item, because of the lack of commercial availability of MS -DOS 5.0 compatibility. Protest File, Vol. 4, Exhibit 31. ISG's Protest 31. On May 5, 1993, protester filed this protest before the GSBCA, specifically incorporating all of the allegations made in its agency protest. One of the grounds for the protest was: The solicitation remains restrictive (requirement for DOS 5.0 or any version of DOS for that matter). . . . Protest File, Vol. 4, Exhibit 35. 32. 33. Three offerors intervened on the side of respondent: Federal Computer Corporation, SYSCON Corporation, and Intermec Corporation. 34. On May 23, 1993, protester amended its protest to withdraw the allegations relating to the printer speed requirement and the failure to extend the time for receipt of proposals. On June 9, 1993, in response to respondent's motion for partial summary relief, protester's allegations challenging the clarity of the evaluation criteria and methodology were dismissed by the Board. 35. A hearing on the merits was held on June 10-11, 1993. The remaining issues for resolution related to protester's allegations concerning the restrictiveness of the specification with regard to the DOS requirements: the generic requirement for DOS, the MS-DOS 5.0 compatibility specification, and the propriety of the relaxation of the MS-DOS version requirement for the intrinsically safe PDCDs. 36. Protester presented the testimony of its vice-president for marketing, Mr. Stephen L. Mills, and consultant, Mr. Karl Bendorf. The following witnesses testified in support of respondent's position: LTC Robert Coxe, the former program manager for AIT, MAJ Valerie Rasmussen, the AIT deputy program manager, Ms. Gloria McGee, the contracting officer, Ms. Christine Pallazza, the contracting specialist, Mr. Frank Murray, a member of the LAWG for this procurement, Mr. Steven Winter of Intermec Corporation, Mr. Robert Kidwell of SYSCON Corporation, and Mr. David Hoyle of Micro Palm Computers, Incorporated, as an expert in market trends in the hand-held computer industry. The Generic DOS Requirement 37. LTC Coxe, MAJ Rasmussen, and Mr. Murray testified concerning respondent's methodology with respect to determination of its minimum needs. They detailed respondent's experience under the previous AIT procurements, the formation of the LAWG, the responses to the data calls, and the market surveys they conducted in preparation for issuing the draft RFP. Transcript at 85-94, 161-70, 187-88, 214-18, 236-37, 255. 38. LTC Coxe testified as to estimates performed prior to the issuance of the solicitation by the service branches with respect to their software translation costs. As an example, due to previous use of vendor-unique systems, one of the users in the Air Force will incur costs of over $450,000 related to re-coding of software alone, and without a method to allow portability of this software across different manufacturers' devices, these costs would continue to recur. Transcript at 93-94, 164-68; Protest File, Vol. 9, Exhibit 47. 39. Mr. Murray testified as to the need to avoid re-coding costs from the Navy's perspective. Transcript at 236-37. MAJ Rasmussen testified that the open systems approach represented by the MS-DOS 5.0 or compatible operating system was a choice for the future, which would eliminate the recurring need for software re-coding. Id. at 199-200. 40. MAJ Rasmussen also testified that the open systems approach represented by the MS-DOS 5.0 or compatible operating system would eliminate the need for personnel re-training. Transcript at 199-200. Utilization of this approach would also allow the Government to take advantage of the skills of programmers, developers, and applications currently available under that standard. Id. at 227. 41. Respondent's market expert, Mr. Hoyle, testified that the market for PDCDs is three-tiered, based on functionality, and that the upper portion of the PDCD market (that portion relevant to this procurement) has already adopted the DOS standard for operating systems for the same reason: increased functionality and competition. He identified five separate producers of PDCDs with products using MS-DOS 5.0 or compatible operating systems. Transcript at 452. One of the more significant advantages of this category of PDCDs is the inherent flexibility such a device offers to run complex applications or to interface with a vast assortment of peripherals. At the bottom end of the PDCD market are those devices which can accomplish little more than simple bar code reading and de- coding. Above this level are those PDCDs which use a proprietary, vendor-unique operating system. Mr. Hoyle testified that these devices afford some level of flexibility, but are "nowhere near as capable as an MS-DOS -based system." Indeed, Mr. Hoyle testified that, in his expert opinion, such non-DOS based units are "most definitely" not state-of-the-art equipment. Transcript at 449. According to Mr. Hoyle, perhaps one of the most significant disadvantages associated with such a device is the restricted nature of a vendor-unique operating system: Once, for example, a customer had developed an application for a proprietary device, say, in a development environment, he can never take that software and run it on another device. And he can never take other software and run it on the hardware device. So he's very much locked into a hardware and a software platform. Transcript at 450. Mr. Hoyle testified that market trend for hand-held computers is moving away from non-DOS based devices and toward PDCDs operating with MS-DOS 5.0 or compatible operating systems. He stated that the proportion of manufacturers of DOS-based PDCDs in the hand-held computer market has increased dramatically over the past five years. In 1988, only twenty-five percent of manufacturers of PDCD devices produced units using a DOS-based system. By 1992, almost ninety percent of such manufacturers produced DOS-based PDCDs. Transcript at 446-47. Mr. Hoyle stated that he personally knew of at least five separate producers of PDCDs using an MS-DOS 5.0 or compatible operating system. Id. at 452. Protester's own proposal manager, Mr. Bendorf, acknowledged that he was aware of six or seven different producers of PDCDs using an MS-DOS 5.0 or compatible operating system. Id. at 289. 42. Mr. Hoyle's market analysis was confirmed by both Mr. Winter of Intermec Corp. and Mr. Kidwell of SYSCON Corp. Transcript at 44-45, 411-12. Mr. Kidwell testified that an MS- DOS 5.0 or compatible operating system provides a standardized architecture that supports the operation of the wide assortment of peripherals required by the AIT solicitation. Specifically, Mr. Kidwell testified that standardizing drivers for PCMCIA cards is a "key example" supporting the use of an MS-DOS 5.0 or compatible operating system. Id. at 427. 43. Evidence was also offered at the hearing concerning the current availability of PDCDs that do not run on a DOS-based operating system. Mr. Bendorf testified that at the current time (i.e., June 1993), to his knowledge there are at least 100 different PDCDs that do not run DOS. Id. at 290. According to responses he received from manufacturers, the great majority (more than ninety-eight percent) of the bar code PDCDs in the world are not DOS-based. Id. at 346-49. The DOS Version Requirement 44. The Government demonstrated that the purpose of the solicitation was to acquire a system that afforded compatibility for both existing program applications and those anticipated for future procurements. The evidence presented during the hearing demonstrates that the vast majority of Government PCs use MS-DOS 5.0 or a compatible operating system. Transcript at 231-33, 262- 67. Protester's vice president, Mr. Mills, acknowledged that, based upon his dealings with the Government, the typical procurement usually requires PCs using an MS-DOS 5.0 operating system. Id. at 394-95. Consequently, by virtue of this existing DOS operating system environment, Government programmers and users can readily develop applications from their PCs and download immediately to their PDCDs. Id. at 37, 98, 105, 132, 137. 45. The requirement for an operating system at the MS-DOS 5.0 compatibility level was discussed by LTC Coxe, MAJ Rasmussen, Mr. Murray, and both intervenor witnesses. These witnesses stated that the specific version requirement was determined by various technical requirements for the PDCDs to interface with various peripherals, such as Personal Computer Memory Card International Association (PCMCIA) and Integrated Circuit Card (ICC) devices. Transcript at 31-32, 99-101, 153-54, 176-77. 46. LTC Coxe testified that the PCMCIA card requirement could be met by a lower version of MS-DOS . Transcript at 122. However, such a solution, while possible, was not desirable. He testified that this solution was analogous to using a spare tire, as it might temporarily achieve a result, but you would not want to rely on the spare tire for your everyday needs. Id. at 149- 51. Mr. Kidwell testified that PCMCIA cards can be used when third party drivers are added to MS-DOS 3.3. Id. at 430-31. 47. LTC Coxe testified that the SmartDrive function of MS- DOS 5.0 in conjunction with the HIMEM.SYS device driver would allow the PCMCIA card to function as an extension of RAM, and this function does not exist in lower versions of MS-DOS . Transcript at 101-03. 48. LTC Coxe testified that the code compiler for MS-DOS 5.0 is standard and that it allows ease of training and use. Transcript at 146, 181. The Army is currently compiling codes on desktop PCs, mostly using MS-DOS 5.0 as an operating system. 49. Testimony was offered by respondent and one of the intervenors that an MS-DOS 5.0 operating system also provides the capability to utilize the maximum amount of the first 640K of random access memory (RAM) for storage of applications programs and data on the PDCDs themselves, by loading MS-DOS 5.0 and device drivers "higher level" memory. LTC Coxe stated that he is not aware of any operating system below MS-DOS 5.0 that in and of itself has "an EMM 386 driver, extended memory management driver, or to have a HIMEM.SYS driver or to have any of the drivers" for high memory allocation.3 Transcript at 29-30, 95- 96, 99-103, 106-07, 178-79, 267. 50. Respondent's witnesses testified further that the requirement of accessing upper level memory was essential to the ability of the PDCDs to use assorted peripherals such as the PCMCIA cards and the "smart" ICC Cards. Each of these ____________________ 3 These memory management drivers are actually software programs for memory management that come as a standard feature of MS-DOS 5.0, and whose functions can also be performed by third- party software utilities. peripherals requires its own device driver, which allows the PDCD to "talk" to the peripheral. Rather than have these drivers occupying memory addresses in the first 640K of the PDCD's memory, the MS-DOS 5.0 or compatible operating system loads these drivers onto the device's upper memory (i.e., above 640K). Transcript at 31-32, 99-101, 153-54, 176-77. This allows the "lower 640" to be used for data gathering and collection and for running application programs. Id. at 99. Mr. Murray testified that unless the PDCDs used an MS-DOS 5.0 or compatible operating system, the Government "would effectively be wasting or not have access to approximately 40 percent of the memory [it] just paid for." Id. at 267. 51. Mr. Bendorf and Mr. Mills testified extensively as to their knowledge of MS-DOS in general and MS-DOS 5.0 and earlier versions. Transcript at 293-316, 369-84. They discussed in detail the system files, the running of programs, and the command functions. Id. at 294, 297, 303, 307-08, 310, 325-26, 356-60, 370, 372, 380-81, 386-89, 402. In contrast to respondent's witnesses, Mr. Bendorf and Mr. Mills testified for protester that MS-DOS 5.0 allows high memory allocation only if a computer has a 386 or higher processor. Id. at 295-97, 313, 355-56. Of the six or so PDCDs that run MS-DOS 5.0, Mr. Bendorf testified that only one PDCD includes a 386 or higher chip. Id. at 298. 52. Mr. Bendorf also testified that high memory management can be achieved by adding third party software to versions of MS- DOS below 5.0. Transcript at 303-05. Three of those third party software products are Quarterdeck, 386 MAX, and RIBS. Id. at 370. The Army, through LTC Coxe, was fully aware of the large number of third party vendors. Id. at 147-48. 53. Mr. Mills claimed that protester could achieve the requisite functionality of MS-DOS 5.0 by modifying the MS-DOS 3.0 version with an assortment of third party software drivers and other programs. Transcript at 403. 54. Mr. Mills, protester's vice president of marketing, while appearing knowledgeable in the general area of memory management and the functional differences between MS-DOS 5.0 and earlier versions, qualified his testimony, stating that he was not familiar with the specific requirements of the AIT solicitation: I'll have to first say that I am not representing myself to be familiar with the specific bid and specific products and what device drivers may or may not be necessary for those specific products. Transcript at 403. 55. Mr. Kidwell of SYSCON testified that a PDCD with less than a 386 processor could still take advantage of applications compiled on a host computer with an MS-DOS 5.0 operating system when downloaded from the host to the PDCD. Transcript at 433- 34. 56. Respondent's witnesses testified that the term MS-DOS 5.0 is self defining. Mr. Winter further testified as to the level of specificity necessary for a solicitation to communicate minimum requirements with respect to a DOS operating system. He stated that the specific features of MS-DOS 5.0 are standard knowledge and that anyone who needs to know the specifics need merely review the manual which is available from Microsoft that comes with the purchase of MS-DOS 5.0. Transcript at 50, 59-60. LTC Coxe believed the features of MS-DOS 5.0 were so obvious that the LOGMARS team did not think about specifying them, as those knowledgeable in the industry would be aware of the specific characteristics. Id. at 122, 124. He stated that the term is so well used that it is emphasized at trade shows by software vendors to show that their software will run in an MS- DOS 5.0 environment. Id. at 111. Mr. Kidwell testified that by requiring that a device operate in an MS-DOS 5.0 or compatible environment, the computer community has absolutely no difficulty understanding what is required. Id. at 426. The Relaxation of the DOS Version for Intrinsically Safe PDCDs 57. Although respondent originally required an MS-DOS 5.0 or compatible operating system on all PDCDs, the agency's investigation in response to a question from a vendor discovered that no PDCDs were on the market that offered both intrinsically safe certification, allowing use in potentially explosive environments, and an MS-DOS 5.0 or compatible operating system. Transcript at 80, 204-06, 221. Such devices are to be used in highly volatile environments -- such as fuel points, grain silos, and other sites containing combustible materials. Id. at 51-52, 128. Due to the time required to complete the certification process, manufacturers had not yet marketed "5.0" versions of intrinsically safe PDCDs. Id. at 55, 416-17. Respondent states that it relaxed the requirement "reluctantly," in order to obtain the needed intrinsically safe devices, and not due to any reduction in the scope of the Government's technical needs. Id. at 221. Discussion The MS-DOS Requirement Protester argues that the RFP's MS-DOS requirements violate the delegation of procurement authority (DPA)4 that was issued by the General Services Administration (GSA) under authority of the Brooks Act. Protester also alleges that the inclusion of the MS-DOS requirements in the instant solicitation have eliminated numerous responsible sources from the AIT procurement, including manufacturers of PDCDs with proprietary operating systems, manufacturers of PDCDs with DOS-based operating systems that are not compatible with MS-DOS 5.0, manufacturers of intrinsically safe PDCDs with DOS-based operating systems that are not compatible with MS-DOS 3.31, and the plethora of third party vendors that sell special software to add "MS-DOS 5.0 functions" to earlier versions of MS-DOS and compatible operating systems. Protester's Post-Hearing Brief at 9-12. Respondent views protester as contending that virtually any PDCD, no matter how rudimentary and using virtually any operating system can, with the right "homemade" modifications, meet the performance objectives of the AIT procurement. Respondent characterizes protester's position as "backward-looking" philosophy, and states that "Protester hopes to pass on dated equipment with limited flexibility -- consistent with the fragmented standards of the hand-held computer market five years ago. AIT is a forward-looking acquisition, however, that seeks to capitalize on current market trends promoting a more open operating systems architecture, enhanced standardization, and, hence, greater competition and flexibility among producers in the PDCD marketplace." Respondent's Post-Hearing Brief at 44-45. Instead, respondent contends that protester's marketing strategy attempts to shackle the Government to the past, offering dated equipment that lacks the functionality and flexibility sought in this new generation of automatic identification technology equipment. This Board has repeatedly held that the fact that a particular vendor may not be able to compete in a procurement due to certain requirements contained in the solicitation does not necessarily make that requirement restrictive. Irvin ____________________ 4 The DPA in this procurement reads, in relevant part: With respect to competition, the basic procurement objective in satisfying FIP requirements is to obtain full and open competition by using competitive procedures which permit all responsible sources that can satisfy the needs of the agency to submit offers. This requires an acquisition strategy, suitable to the circumstances, in which the statement of the user's requirement is set forth in the least restrictive terms possible to satisfy the needs of the agency without compromising economy or efficiency . . . . Protest File, Vol. 4, Exhibit 33. Technologies Inc., GSBCA 11581-P, 92-1 BCA 24,674, 1991 BPD 348. We have acknowledged that "[e]very solicitation of necessity involves some restrictions." International Technology Corp., GSBCA 9967-P, 89-3 BCA 21,917, at 110,278, 1989 BPD 128, at 6. In order to prevail on this issue, protester must demonstrate that the requirements for MS-DOS in the solicitation overstate the Government's actual minimum needs. Irvin Technologies, Inc., 92-1 BCA 24,674, 1991 BPD 348; see also Julie Research Laboratories, GSBCA 9549-P, 88-3 BCA 21,076, 1988 BPD 168. Protester has failed to meet its burden of proof and has not demonstrated that the AIT specifications overstate respondent's actual minimum needs. The goal of this procurement was to establish a new generational baseline for hand-held computer equipment and future Government procurements involving automatic identification technology. The Government wants to free itself of the restrictive limitations associated with vendor-unique hardware and software of past procurements and move to the state- of-the-art open architecture offered by an MS-DOS 5.0 or compatible operating system. Findings 1-5, 12. Respondent has presented evidence detailing the underlying rationale for specifying MS-DOS requirements for the AIT solicitation. Respondent's and intervenors' witnesses discussed the reasons and benefits for movement to the open architecture afforded by an MS-DOS operating system. The AIT equipment obtained under the two previous procurements was limited by the then available technology and used two different vendor-unique operating systems. With the award of the second contract, the Government had two systems that used radically different proprietary languages and, hence, were not compatible with each other. As a consequence, the Government experienced great difficulty in re-programming software applications it had developed under the first contract for use in the second. Consequently, the Government was forced to train programmers in two very different programming languages in order to convert the applications from the first vendor-unique operating system to the second vendor-unique operating system. In 1988, the difficulties encountered by the Navy in re-coding applications were so significant that it was forced to delay using the NT II equipment by nine months. Finding 1. Respondent presented testimony that re-translating code is not only extremely time-consuming but very costly. Today, the Air Force estimates that it will cost just one of its users about $450,000 to convert its software applications from one vendor- unique system to another.5 By acquiring a system that uses an MS-DOS 5.0 or compatible operating system, the Government hopes to free itself from translating vast inventories of software for future procurements. The AIT program manager further determined that only by acquiring an open systems architecture such as that offered by an MS-DOS 5.0 or compatible operating system could the Government avoid the cycle of coding and then re-translating program codes. Finding 38. This decision to acquire an open system was the result of the Government's review of a series of data calls, market surveys, the findings of its acquisition working group, and responses to a published draft RFP for the vendor community to accurately determine its minimum requirements. Relying on these extensive resources, the Government promulgated the Section C statement of work contained in the present solicitation. Findings 2-5. Based upon its experiences with the earlier LOGMARS contracts, the Government is particularly concerned with compatibility of systems for future AIT-related procurements. Additionally, the Government wants to avoid the problems and costs related to training programming personnel on vendor-unique systems and, instead, enhance the ability of users themselves to program their own applications -- thereby maximizing user productivity. Finding 40. Therefore, the MS-DOS requirements . of the solicitation avoid the conversion problems experienced in past acquisitions and establish a new baseline that promotes technological flexibility and standardization in this procurement and future acquisitions. Findings 1, 3, 4, 37-40. Respondent's expert on trends in the PDCD market testified at length as to the three-tiered structure of the market and the advantages of the types of PDCD's sought in this procurement, as well as their availability. Finding 41. Protester's argument that a non-DOS based, proprietary operating system can function just as effectively as a DOS-based operating system ignores the advantages with respect to hardware and software flexibility, and the ability to integrate technologically new components as they are made available. In Irvin Technologies, Inc., this Board held: We cannot take issue with an agency's restrictions on competition in pursuit of legitimate agency requirements where those restrictions are rationally ____________________ 5 Protester characterized as speculative the testimony and documentation presented by respondent's witnesses as to the re- coding costs that the Government will incur in the future if an open system is not procured. Protester's Post-Hearing Brief at 10-11. While these costs were of necessity estimates, we do not find that they were speculative. premised and reasonable. . . . We give more credence to those persons charged with the responsibility for making such discretionary judgments than we give to the opinions of vendors which have not clearly demonstrated greater knowledge of the Government's internal operations and needs. 92-1 BCA at 123,111, 1991 BPD 348, at 6 (citing Data General Corp. v. United States, 915 F.2d 1544, 1551 (Fed. Cir. 1990); Computervision Corp., GSBCA 8744-P, 87-1 BCA 19,553, at 98,819, 1986 BPD 227, at 16). We find that respondent's decision to include the MS-DOS requirements in the solicitation was rationally premised and reasonable. We give more credence to the testimony of respondent's witnesses, who were charged with the responsibility of making the determination to include the MS-DOS requirements in this procurement, than we do to the testimony of protester's witnesses, who clearly have not demonstrated greater knowledge of the Government's internal operations and needs. Protester presented the testimony of two witnesses. Its vice president of marketing disclaimed any specific knowledge of "the specific bid and specific products and what device drivers may or may not be necessary for those specific products." Finding 54. as stated above, we give more credence to the testimony of respondent's witnesses. We therefore find that the MS-DOS requirements in the solicitation are rationally premised and reasonable, given the Government's desire to avoid the technological and competitive restrictions engendered by continuing to have to procure proprietary operating systems for PDCDs. The MS-DOS 5.0 Compatibility Specification for the Operating System Protester offers the same arguments that it made regarding the choice of MS-DOS requirement with regard to respondent's determination to specify the operating system of the PDCDs as "MS-DOS 5.0, or later, or an operating system that is fully MS- DOS 5.0 or later version compatible, with the exception of the intrinsically safe PDCDs." Protester believes that even if the generic requirement for MS-DOS does not restrict competition, the Government simply does not need the flexibility, or cannot take full advantage of, an operating system which uses MS-DOS 5.0 as a baseline. Protester contends that earlier versions of MS-DOS used in conjunction with third party software can adequately meet the minimum needs of the Government. Respondent argues that this hybrid approach results in the very problems regarding standardization among AIT hardware and software that the Government hopes to avoid. Also, this approach conflicts with protester's statement that it is extremely difficult to find MS- DOS versions below MS-DOS 5.0 on the current commercial market. Finding 21. The Government demonstrated that the purpose of the procurement was to acquire a system that afforded compatibility for both existing program applications and those associated with future procurements. The evidence presented during the hearing and confirmed by protester demonstrates that the vast majority of Government PCs use an MS-DOS 5.0 or compatible operating system. Finding 44. One of the major goals of the procurement is to have the PDCDs interface with personal computers so that information can be downloaded from the PC to the PDCD and uploaded from the PDCD to the PC. Id. The fact that the majority of Government PCs utilize MS-DOS 5.0 was a significant reason for the MS-DOS 5.0 compatibility specification for the PDCD operating system. Because the applications required in the procurement are also specified to be developed and run under MS-DOS 5.0, such compatibility is desirable with the operating system of the PDCD. Respondent introduced evidence to demonstrate that an MS- DOS 5.0 or compatible operating system enhances the use of the numerous peripherals also sought by the Government under this procurement, such as the PCMCIA cards and ICC Cards. Findings 45, 47. Additionally, the code compiler for MS-DOS 5.0 is standard and it allows ease of training and use. Finding 48. Thus, by virtue of this exisiting MS-DOS 5.0 operating system environment, Government programmers and users can readily develop applications from their PCs and download to their PDCD's. Finding 44. A great deal of testimony was offered concerning the advantage of using MS-DOS 5.0 for memory management. Respondent offered testimony supporting its decision for requiring an MS- DOS 5.0 or compatible operating system because of the ability of such a system to allow access to upper level memory to load device drivers in order to have more conventional memory free to run programs. These device drivers are standard features of MS- DOS 5.0. Findings 45, 49-50. Protester's witnesses testified that the advantages of memory management of MS-DOS 5.0 is lost if the PDCD does not contain at least a 386 microprocessor running in protective mode. Finding 51. Mr. Kidwell, of SYSCON Corporation, specifically refuted protester's argument that only PDCDs using a 80386-series chip can support an MS-DOS 5.0 or compatible operating system. Mr. Kidwell testified that it is not whether the PDCD uses an 80386-series chip but whether the chip supporting the PDCD has a 16-bit interface. Finding 55. This apparent confusion in the testimony concerning the type of microprocessor required for taking advantage of MS-DOS 5.0's capabilities with regard to memory management arises from the similarity of terminology and concepts used in an admittedly difficult subject area. A 286 microprocessor may access the High Memory Area (HMA), the first 64K above 1.024 megabyte (occupied by conventional memory - the first 640K, and upper memory, from 640K to 1.024 megabyte). A 286 processor accesses the HMA and loads MS-DOS 5.0 in this area by way of a device driver, HIMEM.SYS, thereby freeing those portions of conventional memory that would be normally occupied by MS-DOS 5.0. However, a 386 processor or higher is needed to access the upper memory blocks (UMB) (vacant portions of upper memory between 640K and 1.024 megabyte) by using the device driver EMM.386 which acts to map extended memory into these vacant blocks of upper memory. This same result may be achieved with a 286 processor using third party memory management software. Microsoft MS-DOS , Operating System Version 5.0 User's Guide and Reference 315 (Microsoft Corp. 1991). This is further complicated by the fact that the high memory area is often confused with the first 64K of extended memory, which it is not. The first 64K of RAM above 1.024M will either be HMA or extended memory, but it cannot be accessible as both. HMA is accessed in real mode, while the first 64K of extended memory is accessed in protective mode. John M. Goodman,6 Memory Management for All of Us 524 (SAMS Publishing 1992). The conclusion from the foregoing discussion is that MS DOS 5.0's memory manaement capabilites may not be fully utilized unless the PDCD uses a 386 microprocessor or greater and has extended memory. Even so, MS-DOS 5.0 can run with an 8088 processor and 256K of RAM, which is the minimum RAM required in the solicitation for the PDCDs, though it may not take advantage of it memory management capabilities due to the architecture of the system on which it is running. Finding 19. DR-DOS 6.0, which respondent has decided meets the MS-DOS 5.0 compatibility specification, requires an 8088 processor and 512K of RAM. Id. There are at least three versions of a commercially available operating system which would satisfy the MS-DOS 5.0 compatability specification for the operating system without using third party memory management software - MS-DOS 5.0, MS- DOS 6.0, and DR-DOS 6.0. Findings 17, 18. These products are licensed to vendors and readily available to producers of PDCDs. Respondent's expert in market trends identified at least five different producers of PDCDs using MS-DOS 5.0 or compatible operating systems. Finding 41. Protester has failed to meet its burden of proof, and has not demonstrated that the requirement for the operating system to be "MS-DOS 5.0, or later, or an operating system that is fully ____________________ 6 No relation to the author of this opinion. MS-DOS 5.0 or later version compatible" overstates the Government's actual minimum needs. Respondent has cited numerous reasons which justify the choice of MS-DOS 5.0 rather than an earlier version, even if all the advantages of memory management cannot be utilized as the result of the architecture of the PDCDs. Respondent has presented evidence detailing the underlying rationale for specifying the MS-DOS 5.0 operating system requirements for the AIT solicitation. Use of earlier versions of MS-DOS with third party software may enhance protester's competitive edge, but fails to satisfy respondent's minimum needs. We find that the determination to specify an MS-DOS 5.0 or later version (or fully compatible) operating system to be rationally premised and reasonable. This determination is not restrictive. Again, we give more credence to the testimony of respondent's witnesses who were charged with the responsibility of making the determination to include the MS-DOS 5.0 requirements for the operating system in this procurement than we do to the protester, whose witnesses clearly have not demonstrated greater knowledge of the Government's internal operations and needs. Relaxation of the Operating System for Intrinsically Safe PDCDs was Rationally Based. Respondent has detailed the rationale behind the MS-DOS 5.0 requirements for the AIT procurement. In April 1993, the Government relaxed the operating system requirement for a small portion of the PDCD population -- the intrinsically safe PDCDs. The Government took this action only after discovering that there were no MS-DOS 5.0 intrinsically safe devices available on the commercial market. Thus, to enhance competition, the Government relaxed the operating system requirement for this very limited number of PDCDs. Finding 57. We do not view this relaxation as an admission by respondent that it has overstated its minimum needs. Rather, having found that the MS-DOS 5.0 or compatible standard has been established as a minimum requirement for the procurement, for the reasons stated above, the relaxation of the requirement for the intrinsically safe PDCD's, because of the current state of the market, is rationally based. The specification does state that an intrinsically safe PDCD with an MS-DOS 5.0 operating system or compatible, or later version is desirable. Finding 15. Description of the Operating System Having determined that respondent's decision to designate MS-DOS requirements and an operating system of MS-DOS 5.0 or later version fully compatible was rationally based, we turn to the last issue in this protest. Protester alleges that respondent violated statutes, regulations and/or its DPA by not stating the salient characteristics for the brand name software, MS-DOS 5.0 and MS-DOS 3.31, for the PDCDs. In essence, protester argues that the specification is unclear and requires further elaboration. Protester bases its argument on Federal Acquisition Regulation (FAR) 10.001 and 10.004. 48 CFR 10.001, 10.004 (1992). Purchase description is defined in FAR 10.001 as follows: "Purchase description" means a description of the essential physical characteristics and functions required to meet the Government's minimum needs.7 FAR 10.004, relied upon by protester, reads in part: (a)(1) Plans, drawings, specifications, standards, or purchase descriptions for acquisitions shall state only the Government's actual minimum needs and describe the supplies and/or services in a manner designed to promote full and open competition. . . . . (b)(1) When authorized by 10.006(a), or when no applicable specification exists, agencies may use a purchase description subject to pertinent restrictions on repetitive use. An adequate purchase description should set forth the essential physical and functional characteristics of the materials or services required. As many of the following characteristics as are necessary to express the Government's minimum requirements should be used in preparing purchase descriptions: (i) Common nomenclature. (ii) Kind of material; i.e., type, grade, alternatives, etc. (iii) Electrical data, if any. (iv) Dimensions, size, or capacity. (v) Principles of operation. (vi) Restrictive environmental conditions. (vii) Intended use, including -- (A) Location within an assembly, and (B) Essential operating condition. ____________________ 7 Presumably, protester also relies upon the following portion of FAR 10.001, although it fails to cite it in its briefs: "Brand name description" means a purchase description that identifies a product by its brand name and model or part number or other appropriate nomenclature by which the product is offered for sale. (viii) Equipment with which the item is to be used. (ix) Other pertinent information that further describes the item, material, or service required (emphasis added). Thus, protester argues that by failing to include "salient characteristics" (i.e., "essential physical and functional characteristics") for the brand name products, MS-DOS 5.0 and MS-DOS 3.31, the Army violated the requirements of FAR 10.004 and the DPA in this procurement, and the Competition in Contracting Act. Protester contends that the MS-DOS 5.0 compatibility specification requires it to guess at the desired essential qualities of the brand name item, which makes it a defective specification. See Ciba Corning Diagnostics Corp., B- 223131, 86-2 CPD 185 (Aug. 13, 1986). As the Board stated in CMP Corp., GSBCA 8703-P, 87-1 BCA 19,499, 1986 BPD 214: It is axiomatic that bidders should not have to guess at the essential qualities, features or characteristics of the brand name item they have to equal. Id. at 98,561, 1986 BPD 214, at 7. Respondent poses alternative arguments on this issue. First, it argues that salient characteristics are required to be listed only for features that may be segregated from the central identity of the product to be procured. Since this procurement focuses on the purchase of hardware, i.e., PDCDs, the MS-DOS and MS-DOS 5.0 requirements may not be segregated, and therefore no salient characteristics need be listed. Respondent argues further that the specification of an MS-DOS 5.0 or compatible operating system should be considered a salient characteristic of the hardware to be procured, or alternatively, a salient characteristic of the software. Therefore, there is no need to describe a salient characteristic with additional "granularity." Respondent's alternative argument is that even if the MS- DOS 5.0 compatability specification is deemed to be a brand name specification and not a salient characteristic of the hardware or software, salient characteristics need not be listed because the specification itself, MS-DOS 5.0, coupled with a version level (5.0 or later) denotes a specific set of capabilities, level of functionality, and criterion of performance which should be known to a knowledgeable offeror. Respondent premises this latter argument on the principle that salient characteristics are by definition those not readily discernable from the identification of the product. Wordplex Corp., GSBCA 8159-P, 86-1 BCA 18,554, 1985 BPD 128. Thus, respondent contends that utilization of the phrase "MS-DOS 5.0 or fully compatible" tells competent offerors exactly what functionality is expected of the operating system. Thus, according to respondent, MS-DOS 5.0 or fully compatible is self- defining to a knowledgeable vendor, and no further elaboration is necessary. By stating MS-DOS 5.0, there is no need to list salient characteristics, because such a designation leaves no room for guessing. Thus, the purpose for listing the salient characteristics of the brand name or equal analysis is not present. We agree with respondent. Whether one considers the MS-DOS 5.0 compatibility specification a salient characteristic of the hardware or software, or a brand name or equal specification, no further elaboration is necessary. Protester has shown that it does not need to guess as to the functional characteristics of an MS-DOS 5.0, or later version, or fully compatible operating system. Respondent's witnesses testified that while the specification may not mean anything to a layman, a knowledgeable vendor would know the functional characteristics of an operating system which is MS-DOS 5.0 or later version, fully compatible, and that this information is freely available from Microsoft Corporation. Finding 56. LTC Coxe testified that there are two basic approaches to determining compatibility of an operating system - whether applications developed to run under the operating system will do so, and whether commands will execute. Finding 20. The solicitation itself contains a performance demonstration which requires the offeror to demonstrate the operating system by running programs. Finding 22. Protester's witnesses never disavowed knowledge of the functional characteristics of MS-DOS 5.0.8 They testified as to their detailed knowledge of the functional characteristics of MS-DOS 5.0 and its earlier versions, despite the fact that protester's vice-president of marketing admitted a lack of familiarity with the particulars of this procurement. Findings 51-54. Protester's correspondence before submission of its proposal shows that protester believed it was able to propose an MS-DOS 5.0 based system. Finding 28. Mr. Mills and Mr. Bendorf both confirm LTC Coxe's testimony that the focus in determining compatability of an operating system is the running of programs and execution of commands. Finding 51. In arguing that the advantages of MS-DOS 5.0 cannot be fully utilized by certain types of microprocessers, and that proprietary operating systems or earlier versions of MS-DOS 5.0 would suffice, protester's witnesses have demonstrated their understanding of the functions of not only MS-DOS 5.0 but also earlier versions. Protester has, therefore, demonstrated detailed knowledge to this Board of the very information which ____________________ 8 Being software, there was no discussion as to the physical characteristics (other than to mention that a disk operating system resides on a disk) which, together with functional characteristics, protester alleges comprise "salient characteristics." protester alleges it lacks - the functional characteristics required by the MS-DOS 5.0 compatibility specification. Given that the MS-DOS and MS-DOS 5.0 requirements of the solicitation are rationally based, protester was certainly aware of at least two commercially available products that would satisfy the specification - MS-DOS 5.0 and MS-DOS 6.0. To require respondent to amend the solicitation to include information detailing the functional characteristics of the operating system would not provide protester with any information additional to that which protester has demonstrated that it already possesses. Decision For the foregoing reasons, the protest is DENIED. The Board's order of May 7, 1993, suspending respondent's delegation of procurement authority hereby lapses. _______________________ ALLAN H. GOODMAN Board Judge We concur: ______________________ ______________________ ANTHONY S. BORWICK CATHERINE B. HYATT Board Judge Board Judge