Programmable Modular Communications System (PMCS)

There were many USD (A&T) initiatives to encourage the implementation of open system designs to attain their full benefit. MIDS milestone-II DAB had directed the redesign to incorporate open system design features. The Link-16 FDL program was directed to employ the MIDS open system design. Discussions under the MIDS/SPEAKeasy cooperation work-ing group, and the tactical common data link (TCDL) open system architecture workwork-ing group, all set the stage for a new USD (A&T) initiative. The Quadrennial Review and a number of Congressional bodies had identified that there were more than 200 separate DoD radio programs. In February 1997, under the direction of OSD(C3I), a PMCS-IPT was established to identify a PMCS open system architecture, incorporating all functions required

to transmit, receive, and interface to host platforms, and develop a migration strategy from legacy systems to PMCS. The objectives were to:

† attain the cost-effective acquisition of the next generation of communications systems based on open system design standards;

† maximize the use of available commercial hardware and software to reduce both recurring and non-recurring costs;

† minimize proprietary solutions and maximize use of commercial standards to increase the number of potential equipment providers;

† minimize the number of discrete and unique hardware suites and maximize software reprogrammability and commonality in order to expand the production base.

The PMCS-IPT was headed by ODASD(C3) director of communications, and pulled in membership from BMDO, DARPA, DARO, DISA, USA, USN, USMC, USAF, the Joint Staff, NSA, and the FAA; all of the Service labs were involved. Status was periodically briefed to DASD (C3), DASD (C3IA), ASD (C3), and USD (A&T), and the working groups efforts amounted to an aggressive 4-month effort reviewing prior and ongoing Service/

Agency programs and accomplishments. The PMCS-IPT strove to identify common areas of agreement, differences in implementation approaches and their rationale, and recommend a high-level architecture along with the critical interfaces that must be specified and controlled. Security and programmable INFOSEC device maturity were significant areas of concern and attention. Service and Joint programs such as SPEAKeasy, MIDS, joint combat information terminal (JCIT), and the FAA’s planned next-generation communica-tions efforts were briefed and discussed in great detail.

2.6.1 The PMCS Architecture [9]

There are two diagrams that are most useful in understanding the PMCS. The first is the entity reference model (ERM, Figure 2.14) and the second is the software reference model (SwRM, Figure 2.15).

Referring to Figure 2.14, the PMCS ERM was very similar to SPEAKeasy’s functional allocation (Figure 2.12). The ERM contained eight functional entities where each was to carry out a specified set of communications capabilities or functions. Not every functional entity would be necessary for every user. The ERM represented the first level allocation of PMCS functions that were required to satisfy the broad range of capabilities and services that government users needed and expected from an advanced communications architecture. The critical system interconnect (CSI) functional entity was the split Black and Red interconnects required to achieve NSA endorsement. In some applications information would be protected (encrypted) at its origin and would thus not require additional transmission protection. In yet other cases, communications would always be ‘in the clear’ and there would not be a need for an INFOSEC functional entity. The ERM illustrated that it was intended to support multiple simultaneous communications channels. The ERM was not intended to specify particular packaging or implementation; it was meant to help achieve the PMCS attributes of scalabil-ity, extendibilscalabil-ity, and affordability. A functional entity could consist of one or more hardware or software modules. Entities that were satisfied in software could have coexisted on a single hardware module and would have been initialized with software for the various communica-tions funccommunica-tions required.

The SwRM (see Figure 2.15) identifies key attributes: software independence from the underlying hardware, the independence of all application software, and that common software services were shared among various software applications. This was achieved by standardizing the direct interfaces between the layers. The figure was not meant to imply that a common operating system (OS) was to be used throughout the system. Appropriate APIs and external environment (i.e. physical and electrical) interfaces (EEIs) isolated the applications and the OS and permitted distributed processing and different operating systems to be used on different entities. For an expanded view of the interfaces and their definitions refer to Figure 2.16.

Figure 2.15 PMCS software reference model Figure 2.14 PMCS entity reference model

The results of the PMCS effort was published on July 31, 1997, and are available on the World Wide Web [9].

2.6.2 The Migration of PMCS

In July 1997, the activities of the PMCS-IPT and the resulting Guidance Document were briefed to the USD (A&T). In a letter dated July 28, 1997, then Acting Director USD (A&T), Mr Anthony Valletta, stated the PMCS concept for future acquisition had been accepted. He directed that a working group from the PMCS-IPT be established to further refine the PMCS and identify acquisition management options for a joint service program. The Acquisition Management Working Group (AMWG) was chartered to complete its efforts within 30 days, and was led by the Director of Communications, Mr Richard Dyson. The Joint Requirements Oversight Council (JROC) had validated a Joint Tactical Radio Mission Need Statement (MNS) earlier in August.

Figure 2.16 PMCS critical interfaces – expanded view. Applications: These are the software programs specific to a functional entity; Local Control: This subfunction provides a common control interface for interacting with System Control, and manages intra-entity applications; Application Program Interface (API): This is a common set of calls that provides a level of abstraction between the application and the operating system or other services to ensure portability of the application code;

Message Passing: This critical subset of the API defines the calling conventions for intercommunication among entities; Operating System (OS): This manages the processes, files, and resources within the functional entity. These OS functions could be provided by COTS, or ‘‘home-grown’’. The OS does not have to be common across entities; External Environment Interface (EEI): This provides reliable delivery of messages between entities connected to the common.

In a decision memorandum dated September 11, 1997, then Acting USD (A&T), Mr R.

Noel Longuemare established the PMCS as a major defense acquisition program (MDAP) with the Army as the permanent component acquisition executive and lead service for the PMCS. The AF was directed to assign an initial program manager (PM) to lead a Joint Program Office (JPO). Service PMs were directed to serve in a rotating manner, and deputy-PMs were to be assigned for each of the Services. PMCS was placed under the oversight of a C3I-Systems Overarching IPT (OIPT). The JPO was given responsibility for budgeting and executing RDT&E funding, maintaining the PMCS open architecture, and for procuring common software and hardware modules. The JPO was directed to ensure that the maximum number of industrial firms participated in each phase of the evolutionary devel-opment of a PMCS family of radios. The JPO was established as the JTRS JPO after the title of the MNS and draft Operations Requirement Document (ORD).

In April 1998, PDUSD (A&T), Jacques S. Gansler, sent a letter to all the Service Acquisi-tion Executives stating that he was concerned with Service plans to proceed with near-term radio and terminal developments, thus continuing to field legacy systems. He directed that each Service Acquisition Executive take whatever steps necessary to minimize new programs and migrate existing development programs to the target single acquisition program, JTRS.

Later that year, in the end of August 1998, ASD (C3I), Mr Arthur L. Money, concerned that the Services were not aggressively following Mr Gansler’s direction, followed up with another memorandum to all the Service Acquisition Executives. He wanted to preclude efforts from independently developing and acquiring service unique radios and directed that all current Service ‘‘… efforts to initiate any contracting activity to develop and acquire any radio system to include software programmable radio technology are to be held in abeyance’’. No Broad Area Announcements and no Requests for Proposals were to be released without his direct approval. Any requests for ‘waivers’ were to be submitted through, and reviewed by, the JTRS JPO. Hence, the Services were then locked into supporting the JTRS initiative if they wanted any new communications capabilities, and the JTRS JPO was fully established.