The future of autonomy in the military could include unmanned cargo delivery; micro-autonomous air/ground systems to enhance platoon, squad, and soldier situational awareness; and manned and unmanned teaming in both air and ground maneuvers, according to a 2016 presentation by Robert Sadowski, chief roboticist for the U.S. Army Tank Automotive Research Development and Engineering Center (TARDEC), which researches and develops advanced technologies for ground systems. One day, robot medics may even carry wounded soldiers out of battle. The system behind these feats is ROS-M, the militarized version of the Robot Operating System (ROS), an open-source set of software libraries and tools for building robot applications. In this post, I will describe the work of SEI researchers to create an environment within ROS-M for developing unmanned systems that spurs innovation and reduces development time.

Foundations of Our Work

ROS is an open-source set of software libraries and tools for building robotics applications that has several specialized branches including ROS-M, which is tailored to the unique needs of military robots. ROS-M aims to add software and hardware simulation tools, cyber assurance checking, a code repository, and a training environment for warfighters to the upcoming ROS 2.0. As shown in the photo below, army robotics and autonomous systems are key themes in TARDEC's strategy and in the U.S. Army Operating Concept.

Photo: Courtesy U.S. Army

Specifically, the SEI worked with TARDEC to provide support for ROS-M Cybersecurity and Software Process working groups. Researchers involved in these working groups include Andrew Mellinger of the SEI's Emerging Technology Center; Dan Klinedinst with the SEI's CERT Division; and Neil Ernst from the SEI's Software Solution Division.

ROS-M Work

ROS-M promotes code sharing and reuse, especially for components whose distribution is restricted due to national security or export control concerns. Code sharing and reuse will reduce risks associated with testing, lower development costs, and foster cooperation between researchers and developers.

The first phase of ROS-M was strategic and focused on the direction of the work. The second phase of the work--planning--resulted in four working groups: business process, cybersecurity, software process, and software stack. Our team of SEI researchers was involved in all of the groups except for the business process group.

Initially, our ROS-M work focused on situational awareness. As we became involved in the program, however, we noticed that we could provide additional insights with respect to defense acquisition, which is a core focus of the SEI's research. For example, we initiated efforts on cybersecurity to highlight specific risk management activities, as well as CERT Secure Coding Standards. Other activities included helping the groups involved create appropriate governance and incentives.

• Cybersecurity. The major concern we had with respect to cybersecurity was that the bulk of requirements imposed upon DoD IT systems did not account for unmanned ground vehicles (UGVs) or mobile systems. The cybersecurity group needed additional guidance in these requirements/standards/frameworks on how to implement the prescribed controls on these types of systems.
  
  Moreover, many of the imposed requirements (beyond basic coding best practices) are specified, enforced, and verified by the organization responsible for the systems, and it was not clear who owns them. To address these challenges, we focused on helping unmanned systems that use ROS-M identify the organizations that were responsible for enforcing the requirements.
  
  
• Software process. Our biggest concerns relating to software process fell with sustaining adoptability and ability to ease transition to the DoD. We made several core assumptions when trying to address the main concerns that we saw. For example, we assumed many components would not be government/commercial off-the-shelf (G/COTS). They would be ROS-M integration ready, but not necessarily complete products. This assumption implied that there would be an integration effort and that the complete metadata would not be there, which affects hardware components, as there is no metadata relating to electrical or mechanical specifications. In addition, we were not sure how refined the API specifications would be. We assumed that there would be non-trivial effort into integrating these components.
  
  We also assumed that we were attempting to transition technology from nascent incubators all the way to the soldier's hands in theater. Based on this assumption, we focused on the approach of DoD acquisition professionals and system integrators (SIs). This focus led to an emphasis on the software development life cycle (SDLC) and the spectrum of capability and maturity the modules will represent. We recommended articulating that spectrum to help the innovation community both get closer to the DoD requirements, as well as help raise the baseline of capability across the ROS/ROS-M Communities.
  
  
• Software Stack. The Software Stack group focused on the baseline ROS components to implement first in the literal software stack. In this context, literal refers to the prioritized list of ROS components and modules that are implemented (e.g., ROS computer vision).

Challenges

During this work, we noted that defining who or what organization should bear responsibility for the strategic goals and vision for this effort will be necessary to its longevity.

We also faced the challenge of managing the tension between being accommodating to a variety of needs from different ROS-M participants versus being too restrictive. Being all-inclusive (overly cautious, accommodating, and indecisive) carries the risk of being ineffective, and being too stringent could result in a lack of participation. Navigating this balance is particularly challenging for this effort because the ROS community is very open and inclusive, whereas the military community has, by necessity, higher standards. A significant differentiator of the ROS-M community is the higher level of standards and requirements, and we recommend that the ROS-M community leverage these standards to the fullest potential while still maintaining enough openness to attract those in the ROS community. This challenge should not be underestimated. We have seen many standardization efforts lose their impact and integrity due to the need to be all-inclusive.

Looking Ahead: Government as the Integrator

In recent years, the DoD has moved away from using a lead system integrator (i.e., prime contractor) to build and integrate large systems and toward an approach known as government as the integrator (GATI). ROS-M provides the government a quick means to leverage developments by other robotics organizations and accelerate the time it takes for the DoD to field new technologies. Examples of other ROS-related successes are, CMU's DARPA Chimp robot was created using ROS; ROS-I, which functions on industrial robots; and Security Enhanced ROS, which is a security-enhanced instance of ROS. The DoD can enhance innovation by enabling ROS-M to incorporate these lessons from these planforms and various open architectures and ecosystems.

Another way to help the DoD become the integrator is to increase TARDEC's awareness of other efforts throughout the DoD to ensure that as they build out their capabilities, they have appropriate incentives, contract data requirements lists (CDRLs), and other deliverables. This includes other unmanned system standardization efforts (e.g. Joint Architecture for Unmanned Systems - JAUS) as well as best practices for open source and open architecture governance.

Related work

The SEI is also working to help TARDEC act as a large system integrator and oversee systems engineering tasks, such as component selections for various technologies. This effort involves creation of a type of recommendation engine for the registered components in the ROS-M ecosystem. For example, the engine would help answer the following question:

If the DoD needs a module that performs x function, how can it look out to determine its possibilities?

At the SEI's Emerging Technology Center, we are developing an engine that will ideally include specifications, such as how detailed a documentation package is for a specific module, as well as whether a module has been accredited on some other platform.

In developing a prototype of this engine, we are considering the following questions:

• What type of information package must be presented with the technology so that the acquisition professionals, systems engineering professionals, and system integrators can understand what they are getting?
• What sort of risks are these professionals and integrators assuming when evaluating this product? Are there cybersecurity risks? Are there performance risks. Are there capability risks?

Another line of research we are investigating is creating a theory for composable risk exposure surfaces. To adopt and deploy 3rd party components quickly and with confidence, we need to understand the hazards it poses to our system, evaluate our exposure surface with respect to this new component, and suggest design mitigations to reduce this risk. We believe that an approach that can automatically address these three aspects of component adoption can significantly reduce cost and improve robustness of software systems. We are using ROS and ROS-M as a case study to evaluate our research.

For this research effort we are collaborating with CERT researcher Will Casey, SEI visiting scientist Rick Kazman, and Christian Kastner at the Carnegie Mellon University School of Computer Science. Kastner served as our academic collaborator; his research focuses on controlling the complexity caused by variability in software systems. Kastner develops mechanisms, languages, and tools to implement variability in a disciplined way despite imperfect modularity, to understand feature interactions and interoperability issues, to detect errors, and to improve program comprehension in systems with a high amount of variability.

Ultimately, our aim is to help TARDEC understand the risks involved in acquiring systems and technologies and make an informed decision about whether to accept that risk by acting as the integrator.

We welcome your feedback on this work in the comments section below.

Additional Resources

This blog post is excerpted from a story about the ROS-M effort in the SEI's Year in Review.

Read the Signal article "Robotic Systems May Take a Bullet for Soldiers."

View the TARDEC presentation Shaping the Future: Army Robotics and Autonomous Systems.