Skip to content

Powered by

Other Space Activities

JMS [JSpOC (Joint Space Operations Center) Mission System]

Jan 15, 2016

Initiatives and Programs

JMS [JSpOC (Joint Space Operations Center) Mission System]

JMS (JSpOC Mission System) is the U.S. DoD program of record tasked with replacing the legacy SPADOC (Space Defense Operations Center) and ASW (Astrodynamics Support Workstation) capabilities by the end of FY2015 as well as providing additional SSA (Space Situational Awareness) and C2 (Command and Control) capabilities post-FY2015. To meet the legacy replacement goal, the JMS program is maturing a government SOA (Service Oriented Architecture) infrastructure that supports the integration of mission applications while acquiring mature industry and government mission applications. Future capabilities required by the JSpOC after 2015 will require development of new applications and procedures as well as the exploitation of new SSA data sources. 1)

To support the post FY2015 efforts, the JMS program is partnering with the AFRL (Air Force Research Laboratory) to build a JMS application development environment. The purpose of this environment is to:

1) Empower the research & development community, through access to relevant tools and data, to accelerate technology development

2) Allow the JMS program to communicate user capability priorities and requirements to the developer community

3) Provide the JMS program with access to state-of-the-art research, development, and computing capabilities

4) Support market research efforts by identifying outstanding performers that are available to shepherd into the formal transition process.

The application development environment will consist of both unclassified and classified environments that can be accessed over common networks (including the Internet) to provide software developers, scientists, and engineers everything they need (e.g., building block JMS services, modeling and simulation tools, relevant test scenarios, documentation, data sources, user priorities/requirements, and SOA integration tools) to develop and test mission applications. The developed applications will be exercised in these relevant environments with representative data sets to help bridge the gap between development and integration into the operational JMS enterprise.


The space surveillance part of JMS has a long history within AFSPC (Air Force Space Command) ; space surveillance processing requirements have been continuously refined and honed over the past 40 years. Capabilities for space surveillance and space defense have been developed since the mid-1960s. Systems such as the Delta and 427M computers supported space surveillance analysis from the early 1970s. The linear descent of JMS requirements starts with the SPADOC (Space Defense Operations Center) System Operational Requirements Document (SORD) in 1989 and results in a highly refined, well-understood set of SSA requirements. The legacy of C2 requirements is scarcely less rich, being based on the AOC (Air and Space Operations Center) C2 construct. 2)

JFCC SPACE (Joint Functional Component Commander for Space) needs a modern capability to command and control her assigned and attached space forces. Air Force Space Command has produced the JSpOC Mission System as the solution to the need. JMS has a long requirements pedigree – the need has been clear and consistent for over 30 years. As JFCC SPACE's responsibilities grow and transform the JSpOC into the CSpOC (Combined Space Operations Center), the need for a modern, fully automated data processing solution becomes more and more obvious. JMS is starting to field a solution that already improves JSpOC crew members' operations today and lays the foundation for more improvements in the near term and for broader, further-reaching space C2 and SSA capabilities in the future. JMS will be a key contributor to mastering the increasingly congested, contested, and competitive space domain.

The JMS acquisition program is being developed by the AFSPC SMC (Space & Missile Systems Center) JMS SPO (System Program Office) to deliver an integrated, net-centric SSA (Space Situational Awareness) and C2 (Command and Control) capability to provide the following primary functions:

• Replace the legacy SPADOC (Space Defense Operations Center) and ASW (Astrodynamics Support Workstation)

• Rapidly detect, track, and characterize objects of interest. High Accuracy Catalog

• Produce UDOP (User-Defined Operational Picture) and SOB (Space Order of Battle)

• Perform space threat analysis such as predict and report orbital conjunctions

• Conduct C2 of space forces in a dynamic environment.

The JMS program will provide a collaborative environment that will enhance and modernize the SSA capabilities; create decision-relevant views of the space environment; rapidly detect, track and characterize objects of interest; identify / exploit traditional and non-traditional sources; perform space threat analysis; and enable efficient distribution of data across the SSN (Space Surveillance Network). Furthermore it provides a viable migration path from the legacy SPADOC system, which has 75% of its components beyond the end of life or end of service, and the majority of its software is no longer vendor supported. JMS will also develop improved information capabilities for integration across SSA sensors through data exposure and accomplished via the Net Centric Sensors and Data Sources effort in SSA Systems and Operations.



JSpOC (Joint Space Operations Center)

The JMS (JSpOC Mission System) is a modern SOA (Service-Oriented Architecture) infrastructure with increased process automation and improved tools to enhance SSA (Space Situational Awareness). The JMS program has already delivered Increment 1 in April 2013 as initial capability to operations. The programs current focus, Increment 2, will be completed by 2016 and replace the legacy SPADOC (Space Defense Operations Center) and ASW (Astrodynamics Support Workstation) capabilities. Post 2016, JMS Increment 3 will continue to provide additional SSA and C2 capabilities that will require development of new applications and procedures as well as the exploitation of new data sources with more agility. 3)

The JSpOC includes the personnel from all four military services and three Allied nations (United Kingdom, Australia, and Canada), facilities and equipment necessary to provide CDR JFCC SPACE the ability to plan and execute command and control of worldwide space forces. It is composed of five core divisions: SD (Strategy Division), CPD (Combat Plans Division), COD (Combat Operations Division), ISRD (Intelligence, Surveillance and Reconnaissance Division), and USV (Unified Space Vault).

In 2012, the JMS Program Office entered into a partnership with AFRL/RD (Directed Energy) and AFRL/RV (Space Vehicles) to create ARCADE (Advanced Research, Collaboration, and Application Development Environment). The objective of ARCADE is:

1) To serve as a centralized testbed for all R&D (Research and Development) activities related to JMS applications, including algorithm development, data source exposure, service orchestration, and software services, and provide developers reciprocal access to relevant tools and data to accelerate technology development.

2) To allow the JMS program to communicate user capability priorities and requirements to developers.

3) To provide the JMS program with access to state-of-the-art research, development, and computing capabilities.

4) To support JMS Program Office-led market research efforts by identifying outstanding performers that are available to shepherd into the formal transition process.

AFRL/RV and AFRL/RD have created development environments that together allow developers to develop applications and work with data sources. The ARCADE Portal gives developers a sandbox environment to test and benchmark new algorithms and services and is currently available over Internet using a CAC or Kerberos using Yubikey. The ARCADE SOA is hosted on restricted networks that allow new applications to be integrated with the JMS SOA and other data sources to help mature the capability to TRL 6.

The JMS program is being executed by the Space and Missile Systems Center Space Superiority Systems Directorate (SMC/SY) for the Program Executive Officer for Space (PEO Space). The JMS program is leveraging investments in existing government prototype efforts and existing industry applications to rapidly deliver needed capabilities. It will deliver capabilities to get off legacy SPADOC and ASW through two increments which leverage these mature capabilities by the end of FY14. Once this is accomplished, the JMS system will have the necessary capabilities and framework upon which additional SOA-compliant capabilities can be easily added in the Post-Increment 2 time period. The JMS program office will act as the system architect and as the integrator and maintainer of the JMS system baseline.

Increment 1 (2011-2013): Increment 1 leverages capabilities that have already been developed. It builds on the AFRL JMS prototype known as CP0 (Capability Package 0). CP0 was developed, tested, and deployed in close cooperation with the JSpOC user community. It provides automated links to existing data sources and includes a UDOP (User Defined Operational Picture) to integrate and display the information. CP0 also provides the baseline JMS SOA. The CP0 prototype has been incrementally improved through SPs (Service Packs). SPs aggregate applications of capability developed, integrated, tested, and deployed in approximately 3-month cycles with odd numbered SP's delivering new capability and even numbered SP's largely containing only IA updates. CP0 plus SP 1 through 5 complete Increment 1, which will satisfy two of the five JMS CDD (Capability Description Document) KPP (Key Performance Parameters), namely UDOP and Net-centricity.

Increment 2 (2013-2016): Increment 2 will build upon the Increment 1 baseline, satisfy the remaining three JMS CDD KPPs (Space Catalog, Orbital Conjunction, and Ops Availability) and allow decommissioning of the legacy SPADOC hardware by the end of FY 2015. Increment 2 integration, test, and sustainment will be managed by the SPAWAR (Space and Naval Warfare Systems Command) San Diego as part of the JMS program office. The content of Increment 2, number and type of contracts used to acquire Increment 2 services for integration by SPAWAR, and timing of Increment 2 SP releases will be determined based on Increment 1 capability, program lessons learned, and maturity of industry and government applications.

Increment 3 (2016+): At the completion of Increment 2, JMS will have delivered a flexible, extensible SOA framework with foundational services (such as catalog and conjunction services) upon which additional SSA capabilities can be added. During this phase, the JMS program office will rely on the JSpOC user and the Requirements & Planning Council (R&PC) co-chairs (CDR JFCC SPACE and PEO Space) to establish and continually refine capability priorities. The JMS program will communicate these priorities to the application development community with regular updates to focus application developments on the most important user needs. SPAWAR will continue as part of the JMS program office in the role of software integration and sustainment of the JMS baseline.

The buildup of the ARCADE began during Increment 2. Existing projects such as Ibex (a joint DARPA/AFSPC effort leveraging expertise at AFRL and MIT LL), the GEO Odyssey program, DARPA Orbit Outlook, space weather services can take advantage of this initial buildup to help develop, test, and collaborate in a virtual-computing environment, from physically different parts of the country. The JMS program will work with AFRL on this initial infrastructure to turn the initial ARCADE services into a worldwide asset for SSA tool development by the time JMS enters the Increment 3 time period.



Key Elements of ARCADE (Advanced Research, Collaboration, and Application Development Environment)

AFRL and the JMS program partnered to develop the ARCADE. The end state of this environment will give various user groups (e.g., software developers, SSA experimenters, and JSpOC users) the documentation, building block JMS services, modeling and simulation tools, relevant test scenarios, data sources, JMS user requirements/priorities, SOA integration tools required to support JMS development, and establish a structured Governance Process. The environment will also provide these user groups with a framework that enables and encourages multi-organizational collaboration. This environment is envisioned as a means for the JMS program to become a more agile acquisition system that accelerates the delivery of prototypes into SPs (Service Packs). 4) 5)

Although this environment is not a so-called cloud computing paradigm it is being implemented in a manner that shares characteristics of well-known computing clouds, such as Amazon's Elastic Compute Cloud or Google's Compute Engine. These characteristics include:

Infrastructure as a Service: JMS ARCADE will provide computational storage and networking resources available on demand

Platform as a Service: JMS ARCADE will provide the JMS SOA and SDK; AFRL will investigate methods to optimally integrate SOA technologies with Cloud technology

Software as a Service: JMS ARCADE will provide all the development tools needed to build a JMS-compatible service as well as modeling and simulation tools for SSA experiments

Data as a Service: JMS ARCADE will provide both simulated and real data sources to application developers and SSA experimenters formatted according to data standards as defined by the JMS common data model.

The JMS development environment will provide some or all of these services as applicable to each type of user. User profiles will catalog each user attribute according to the type of service required.


MHPCC Portal-based Application Development Environment Foundation

AFRL is making upgrades and expansions to existing network environments as the foundation of the JMS application development environment. For the unclassified environment, which is critical to the application developer user segment, JMS will leverage the existing DOD HPCMP (High Performance Computing Modernization Program ) Portal capability developed at the MHPCC (Maui High Performance Computing Center) and JMS technologies developed within the AFRL/RV BEAST (Battlespace Evaluation and Assessment SSA Testbed). The HPC (High Performance Computing) portal capability is easily accessible through the Internet, leverages existing hardware, account management, and user support services. It currently uses PKI-CAC and Yubikey authentication, which allows DOD and DOD contractors to access HPCMP systems via the Internet and modern web browser with no additional user-side software requirements.

The ARCADE Portal was designed to provide the ability for users to develop, integrate, and evaluate services prior to SOA integration. As shown in Figure 1, the ARCADE Portal chiefly provides:

• JMS software development kits and resources

• A suite of software development tools including terminal, integrated development environments, editors, compilers, debuggers, and configuration management applications

• File transfer capabilities

• A Workflow tool for service generation and testing of services.

The Workflow tool is one of the most important aspects of the ARCADE Portal. It enables two capabilities : 1) generation of service wrappers, and 2) testing of services in system-of-systems scenarios. One of the challenges for scientist and engineers when working with JMS is lack of SOA knowledge. Almost all technology developers can provide stand-alone applications that take input as command line arguments or from files and provide output to files or standard out. The ARCADE Portal Workflow tool provides a basic mechanism for developers to create JMS-compatible service wrappers around applications like these, provided the applications use standard data inputs and outputs. This is expected to be a significant enabler for scientists and engineers to create JMS SOA-ready services without having to understand SOA technology or Java programming.

Once a service is generated, it can be tested in a closed-loop scenario with other data processing components to gauge how well the new service impacts the overall system. The current workflow tool is limited to the cataloging process, as shown in Figure 1, with components for:

- Input- generates the "truth" data for simulations

- Scheduler- tells the sensors when and where to look for simulations

- Observation Generator- this generates sensor observations

- Correlator- this compares the sensor observations against the known catalog

- UCT Resolution- associates UCTs (Uncorrelated Tracks) and build new catalog entries

- Catalog Update- updates the catalog given correlated observations.

Efforts are underway to add Indications and Warnings and Command and Control components to the workflow. The user can assign a given service to each of these components. The services can be hosted within the ARCADE Portal computing environment or externally hosted. Once execution begins, the services are called in sequence at defined time steps until the scenario time is completed. Intermediate and output files are available for on-line viewing or for download. Efforts are underway to provide pre-configured scenarios in which a developer can test their services and compare results against performance benchmarks. The JMS program can then use these performance benchmarks when deciding whether to acquire a given service.

With benchmarking in mind, the Workflow tool was designed to work primarily with simulations; however, real data observation generation services have been demonstrated. The dynamic nature of the scenarios becomes moot with real data since the system cannot direct future data collection based upon present processing. For simulation scenarios, care has been taken to implement truth generation with six degree of freedom special perturbations trajectory modeling, relevant satellite material models, and state of the art sensor simulation (currently limited to optical sensors).

To recap the role of the ARCADE Portal, consider a person who has an idea on how to improve SSA, whether it is building a new sensor or a smarter method to manage data collection or data exploitation, the ARCADE Portal provides the software development tools for that person to develop an application from that idea. The Workflow tool then allows the person to wrap that application as a JMS-compatible service. Then the impact that service has on relevant scenarios can be quantified using the Workflow tool as well. The person only needs a web-browser and the intellectual ability to build his application.

Figure 1: The ARCADE Portal Workflow Tool Scenario Set-Up (image credit: AFRL, Scitor Corporation)
Figure 1: The ARCADE Portal Workflow Tool Scenario Set-Up (image credit: AFRL, Scitor Corporation)


JMS SOA-based Development Environment

Due to the restricted nature of JMS data sources, the services of which are an integral part of the JMS infrastructure, only on restricted enclaves of ARCADE will host the JMS SOA for software application developers to interact with. The decision to only host the JMS SOA in a restricted computing environment may be reversed in the future, but there are policy issues that must be sorted through prior to release of the JMS SOA at an open level. Although access to the computing networks severely limits the communities who may access the restricted portions of ARCADE, still there is a broad community of government, industry, and academia who can access these restricted ARCADE enclaves, and participate in software development, collaboration, and research, with the JMS SOA.

To be specific, the JMS SOA supplied on the ARCADE is a near-copy of the JMS SOA that is currently operational. The JMS SOA available through the ARCADE provides access to user groups that range from large industry to rapid prototyping shops in academia, government, and small business (as shown in Figure 2) and will protect the intellectual property rights of these users through roles defined within the SOA's underlying security system. The controls will also give JMS personnel the accesses necessary to review prototypes while in the development and integration phases. This review may support JMS market research efforts and allows the JSpOC operators to get early exposure to development applications as well as give government experts the opportunity to provide feedback to the developer on usability, the viability of the processing algorithms, scalability to relevant or operationally-sized data feeds, and more.

Figure 2: Features of the JMS ARCADE on a Network (image credit: AFRL, Scitor Corporation)
Figure 2: Features of the JMS ARCADE on a Network (image credit: AFRL, Scitor Corporation)


Transition to Operations

The mission application path to transition will incorporate a phased progression from development to operations. Though the ARCADE emphasis is placed on maturation of applications to TRL 6 (Figure 6). Technical Readiness Levels 6-9 are all defined relative to an operational environment, in this case the currently operational version of JMS. After maturation in ARCADE if an application is deemed a viable candidate for JMS inclusion and after appropriate security checks and contracting requirements are completed the candidate application will be transitioned to the JEDI ( JMS Enterprise Development and Integration) environment, which is the official integration environment hosted by SPAWAR. Capability integration occurs in accordance with a formalized gating process within the JEDI, after which, if the candidate application graduates, and the application progresses to the MIE (Mission Integration Enclave). The MIE is a testing environment, co-located with the JSpOC, where the 46th Test Squadron performs official Development Testing and Operational Testing. Once the candidate application goes through the MIE it is assessed at TRL 8. An assessment of TRL 9 is only possible if an application is employed in operations, JSpOC operations.

The aforementioned process of transition is complex, which is a motivator for the creation of the ARCADE testbed, in order to supply developers with the necessary knowledge, software development kits, exposure to test data sources, and environment such that candidate applications are at a sufficient level of technical maturity to facilitate transition through the subsequent steps, JEDI and MIE integration and testing. Whereas the barrier to entry for the JEDI and MIE are quite high, the barriers to entry into ARCADE are very low. ARCADE accounts, at the appropriate classification level are currently being approved for any US Government, US Government Contractor, or DoD CRADA (Cooperative Research & Development Agreement) members who apply.

ARCADE or ARCADE-like services may be extended in the future to foreign partners and academia. Software development kits, test data, and a copy of the JMS environment are all included with ARCADE accounts at the appropriate classification levels. A downside to this migration approach is that there are multiple development environments to develop, deploy, and maintain. However, the transition is believed to be the most agile means to acquire and deploy mission applications as well as the best strategy to mobilize the broadest possible community of developers and experimenters. Accessibility is a fundamental strength of this approach.

Figure 3: ARCADE-JMS technical maturation process (image credit: AFRL, Scitor Corporation)
Figure 3: ARCADE-JMS technical maturation process (image credit: AFRL, Scitor Corporation)


ARCADE Governance Process

Governance refers to the mechanism, processes, roles and responsibilities by which the ARCADE Program and Key Stakeholders maintain control over the process of software application maturation. The Governance of ARCADE is still in a draft format, planned to be completed by Fall 2015. The ARCADE Governance Process is currently directed by the ARCADE Governance Board, chaired by the senior-level officials from key Government stakeholders: AFRL and SMC/SY. The senior-level ARCADE Governance Board meets biannually; assumes responsible for the overall Governance process; assesses the ARCADE Program's value, plans, and goals; and assists with Application transition by formulating recommendations to the JMS Requirements and Planning Council.

In addition to directing the ARCADE Governance process at the Board level, the key Government stakeholders—AFRL, SMC/SY, and JSpOC—perform work at the execution level. As ARCADE host, AFRL supplies assistance and may, upon request, furnish evaluations of Application development in four main areas: Information Assurance, System Engineering, Military Utility, and Information Veracity. The JMS Program Office (SMC/SY) is the transition agent and additionally performs independent evaluation on the subjects of Information Assurance, System Engineering, Military Utility, and Information Veracity. It is planned that in FY 2016 the overall Governance and evaluation portion of ARCADE will transition to SMC/SY. It is planned that evaluations will be tiered.

For example, a System Engineering assessment will be Tiered with the lowest Tier being unassessed and the highest being fully compatible, proven by test running on live test-data feeds with the JMS SOA and if applicable JMS UDOP. Military Assessment will be handled with a similar Tiered grading scheme, with highest weight placed on the JSpOC's evaluation of a technology; the JSpOC, the operational stakeholder is uniquely qualified to assess Military Utility of a technology. Thus far the most challenging assessment to define and staff is the need for Info Veracity. The proposed Tiered approach is that the highest-Tier assessment will be documented by successful comparison of an application results with benchmarks accepted by a Community of Interest. For orbit determination algorithms there are benchmarking tools, with varied levels of acceptance in the Astrodynamics Community of Interest, and importantly the MHPC (Maui High Performance Computing Center) Portal ARCADE currently hosts some and has capability to host more simulation tools for these benchmarking purposes.

Unfortunately similar benchmarks are not available for all algorithm technologies. For example, the Community of Interest for Space Environmental Effects does not currently possess such benchmarks. Proposed middle-Tier Information Veracity assessment is evaluation with quantifiable measures by an independent evaluator and proposed lower-Tier assessment is qualitative evaluation by an independent evaluator. Both of these assessments are essentially peer-review processes with varying degrees of rigor. Although the ARCADE Program recognizes the need to assess the truthfulness of information offered to JSpOC operators, the ARCADE Program does not currently have the resources nor expertise to perform peer-review for all conceivable algorithm technologies. It is important to note that Information Veracity is for ARCADE purposes only, and the language Information Veracity assessment is used purposefully instead of Verification because official Validation and Verification is performed by the Test Authority, the 46th Test Squadron. In all evaluations the base-level assessment will be reserved for unassessed technologies.

AFRL as the ARCADE Host, the JMS Program Office in its cardinal role as transition agent, and the JSpOC as recipients of ARCADE-matured software applications represent three primary Government stakeholders for ARCADE. The fourth, last but not least important role in the ARCADE paradigm is that of Application Developer. Application developers may be from Small Business, Industry, Government Labs to include Federally Funded Research and Development Centers, and Academia. The ARCADE Governance Process describes the roles of Application Developers in ARCADE for the purposes of defining what support an Application Developer may expect and a model for how application installation, maturation, and transition may proceed.

Figure 4: High-level diagram of ARCADE Governance (image credit: AFRL, Scitor Corporation)
Figure 4: High-level diagram of ARCADE Governance (image credit: AFRL, Scitor Corporation)

Figure 5 shows the high-level steps: Obtain Software Development Kits, Install in ARCADE, Application Evaluation, and Transition to the Program Office (SPO). Details of the high-level steps toward transition are still being finalized. The details will likely be captured in an ARCADE User's Manual, consistent with the high-level descriptions included as part of the Governance Process. The ARCADE User's Manual is also in draft format currently. Some of the steps are already well fleshed out, for example the Software Development Kits and Installation Processes, both of which are relatively straightforward to define, have been defined as a series of steps with defined expected outcomes. Other parts of the Governance Process, App Evaluation and Transition to SPO, are currently inadequately defined but will be fleshed-out completely by Fall 2015.

Figure 5: Scitor Corporation locations throughout the U.S. with headquarters in Reston VA (image credit: Scitor Corporation)
Figure 5: Scitor Corporation locations throughout the U.S. with headquarters in Reston VA (image credit: Scitor Corporation)

ARCADE is an example of a modern technology enabler for the Government to achieve this needed infusion of new and relevant technologies outside the traditional Air Force acquisition process. Borrowing from concepts such as crowd sourcing for solutions and application development for smart phones and tablets ARCADE provides the Government an exciting tool for attracting, vetting, and maturing critical functionality needed to manage the technology needs of JMS.

A significant feature of ARCADE, which benefits the Government, is the ability for ARCADE to act as a tool for market research. As the R&PC (Requirements & Planning Council) releases priorities to the community, all developers in the US are equally exposed to the statement of needs and properties and can choose to respond through development. As developers register and start interacting, ARCADE provides the logging of metrics of the number of responses and relative maturity level of entrants in direct response to the R&PC priorities. This feedback can be utilized to gauge industries ability in technological ability and/or in number of companies technologically adept in the particular needed function. No response, low response, or high responses all provide extremely useful information about the mindset of industry and where their capabilities are. The Government can then use this information to springboard other acquisition activities to take advantage of industries response.

The most significant benefit the ARCADE provides to the Government is that of risk management. Specifically ARCADE deflects integration risk away from the Government onto the developer in the process of maturing new technologies relevant to SSA and Space control. In a traditional acquisition process consisting of studies or technology demonstrations, these need to be funded to get a technology mature enough for a "normal" source selection to take place. In some circumstances sole source development can be an option, however in both cases the Government ends up with a contract and timeline in hopes of achieving a particular capability in a planned timeline. Contrast this with ARCADE development utilizing the ARCADE, where announced priorities find a balance with technology push (bottoms up) from industry. The timeline for this is open, versus a directed procurement, allowing a greater market and opportunity for creative solutions. In this process it is the developer working to submit a matured product, proven in a relevant test environment, who bears the bulk of the risk instead of the Government. This shifting of the risk allows the Government to more rapidly move from new technology to fully integrated functionality, in a reduced time and risk (Ref. 4).

Figure 6: Illustration of the ARCADE element within the JMS (image credit: AFRL, Scitor Corporation)
Figure 6: Illustration of the ARCADE element within the JMS (image credit: AFRL, Scitor Corporation)


Achieving Responsive Capability Delivery to JMS

Industry and government entities have clearly identified the need for a common, relevant development environment to support mission application development for the JMS user. Through access to relevant tools and data, JMS will empower the development community to accelerate technology development, define a new business case, lower costs, and identify development areas that support user-identified priorities/requirements. The JMS application development environment will encourage participation by niche application developers and small businesses by removing the need for developers to invest in duplicative, stand-alone infrastructure and facilitating access to test data sources. By providing JMS integration process requirements early in the development process and enabling successful integration into the SOA framework as soon as possible, the environment will flatten the application developers' learning curve.

From the perspective of the end users and SSA experimenters, the JMS ARCADE will allow JSpOC operators to get early exposure to development applications via UDOP-compliant plug-ins that may address needs identified in exercises such as Global Lightning/Terminal Fury. The JMS program office is working closely with SMC/SYE on ops engineering efforts that involve changes to tactics and procedures. ARCADE tools will enable lower tier exercise vignettes to motive quick changes in both technology and CONOPS to happen simultaneously. This would enable early operator feedback to code developers for prototype capability improvements.

Once an application progresses through the utility testing enabled by the development environment, it can finalize its path to SOA integration by entering the SPAWAR JMS integration gating processes and eventually Operational Test & Evaluation. If used properly, the environment will empower users to develop high-impact, high-TRL applications in a timely manner as well as help bridge the gap between development and integration into the operational JMS enterprise by exercising the developed applications in a relevant environment with representative data sets (Ref. 3).



1) Rick Luce, Captain Paula Reele, ChrisSabol, Paul Zetocha, Juan Echeverry, Richard Kim, Barbara Golf, "Joint Space Operations Center Mission System Application Development Environment," Proceedings of AMOS (Advanced Maui Optical and Space Surveillance Technology Conference),Maui ,Hawaii, USA, Sept. 11-14, 2012, URL:

2) Michael Morton, Timothy Roberts, "Joint Space Operations Center (JSpOC) Mission System (JMS)," Proceedings of AMOS (Advanced Maui Optical and Space Surveillance Technology Conference),Maui ,Hawaii, USA, Sept13-16, 2011, URL:

3) Jeremy Murray-Krezan, Chris Sabol , Lt Anthony M. Runco, Paul Zetocha, Juan Echeverry, Richard Kim, "The Joint Space Operations Center (JSpOC) Mission System (JMS) and the Advanced Research, Collaboration, and Application Development Environment (ARCADE)," Proceedings of the 15th AMOS (Advanced Maui Optical and Space Surveillance Technology Conference), Maui, Hawaii, USA, Sept. 9-12, 2014, URL:

4) Kipp Johnson, Richard Kim, Juan Echeverry, "The Joint Space Operations Center (JSpOC) Mission System (JMS) and the Advanced Research, Collaboration, and Application Development Environment (ARCADE)," Proceedings of the 16th AMOS (Advanced Maui Optical and Space Surveillance Technology Conference), Maui, Hawaii, USA, Sept. 15-18, 2015, URL:

5) "JMS Advanced Research, Collaboration, and Application Development Environment," DoD HPC, URL:

The information compiled and edited in this article was provided by Herbert J. Kramer from his documentation of: "Observation of the Earth and Its Environment: Survey of Missions and Sensors" (Springer Verlag) as well as many other sources after the publication of the 4th edition in 2002. - Comments and corrections to this article are always welcome for further updates (

Terms and ConditionsCookie NoticeContactAbout

© 2023