This paper reports the results and findings of a historical analysis of open source intelligence (OSINT) information (namely Twitter data) surrounding the events of the September 11, 2012 attack on the US Diplomatic mission in Benghazi, Libya. In addition to this historical analysis, two prototype capabilities were combined for a table top exercise to explore the effectiveness of using OSINT combined with a context aware handheld situational awareness framework and application to better inform potential responders as the events unfolded. Our experience shows that the ability to model sentiment, trends, and monitor keywords in streaming social media, coupled with the ability to share that information to edge operators can increase their ability to effectively respond to contingency operations as they unfold.

Soldiers, first responders and other personnel operating at the tactical edge increasingly make use of mobile devices to help with tasks such as face recognition, language translation, decision-making and mission planning. Tactical-edge environments are characterized by limited resources, dynamic context, high stress and poor connectivity. This paper focuses on three architecture patterns that address these conditions. The Data Source Integration pattern uses server-side standardized definitions of live or cached geo-located data feeds that can be customized and filtered on a single, map-based user interface on a mobile device. The Group Context Awareness pattern uses context obtained from groups of handheld devices operating as part of a team to make sure that the right information is displayed to the right soldier at the right time. The Cloudlet-Based Cyber-Foraging pattern uses cloudlets as code-offload elements to optimize resources and increase computation power of mobile devices. Cloudlets are discoverable, localized, stateless servers running one or more virtual machines on which users can offload resource-intensive computations from their mobile devices. Prototype applications have been implemented for each of these patterns. Experiment results and participation in exercises have shown the effectiveness of the patterns in addressing the challenges of resource-constrained environments.

Structure makes data more useful, but also makes data entry more cumbersome. Studies have found that this is especially true on mobile devices, as mobile users often reject structured personal information management tools because the structure is too restrictive and makes entering data slower. To overcome these problems, we introduce a new data entry technique that lets users create customized structured data in an unstructured manner. We use a novel notepad-like editing interface with built-in data detectors that allow users to specify structured data implicitly and reuse the structures when desired. To minimize the amount of typing, it provides intelligent, context-sensitive autocomplete suggestions using personal and public databases that contain candidate information to be entered. We implemented these mechanisms in an example application called Listpad. Our evaluation shows that people using Listpad create customized structured data 16% faster than using a conventional mobile database tool. The speed further increases to 42% when the fields can be autocompleted.

The convergence of mobile computing and cloud computing is predicated on a reliable, high-bandwidth end-to-end network. This basic requirement is hard to guarantee in hostile environments such as military operations and disaster recovery. In this article, the authors examine how VM-based cloudlets that are located in close proximity to associated mobile devices can overcome this challenge. This article is part of a special issue on the edge of the cloud.

: Handheld mobile technology is reaching first responders, disaster relief workers, and soldiers in the field to aid in various tasks, such as speech and image recognition, natural language processing, decision making, and mission planning. However, these applications are computation intensive, so it is necessary to consider that (1) mobile devices offer less computational power than conventional desktop or server computers, (2) computation-intensive tasks consume large amounts of battery power, and (3) networks in hostile environments, such as those experienced by first responders and soldiers in the field, are often unreliable, and bandwidth is limited and inconsistent. While there has been considerable research in code offload to the cloud to enhance computation and battery life, most of this work assumes reliable connectivity between the mobile device and the cloud an invalid assumption in hostile environments. This technical note presents a reference architecture for mobile devices that exploits cloudlets?virtual-machine-based, code-offload elements?that are in single-hop proximity to the mobile devices that they serve. Two implementations of this reference architecture are presented, along with an analysis of architecture tradeoffs.

Interconnected systems of systems provide capabilities that aren't available in any single system. Fundamental service-oriented principles can help in engineering them, regardless of the implementation technologies used.

In today's rapidly changing environment it is no longer possible for isolated systems to provide all the capabilities that are necessary to fulfill a mission. Therefore, there is an increasing trend towards interconnected systems of systems that provide capabilities not available in a single system. However, existing software and system engineering practices do not scale well to SoS-engineering a system of systems (SoS) is still an open problem with significant challenges. Understanding these challenges and providing engineering solutions will require a two-pronged approach. First, a top-down approach that models an SoS at an abstract level is essential to understand key concerns that exist independent of the technologies used to implement the SoS. SoS research challenges about these concerns are well understood now. Second, a bottom-up approach that focuses on abstracting the concepts and lessons learned from specific examples of engineering systems of systems is needed. Currently, the most common approaches for engineering software-intensive systems of systems are service-oriented architecture (SOA), Grid Computing, and Cloud Computingall of which are distributed computing paradigms. In the future, newer technologies may replace or complement these existing engineering approaches. This paper focuses on the bottom-up approach by exploring several areas where lessons learned from SOA implementations can be abstracted and applied to systems of systems, regardless of the implementation technology.

Assurance is an essential part of building any software system because it provides confidence and reduces the risks associated with system implementation. Assurance of service-oriented systems is similar to assurance of any distributed system. However, service-oriented environments have additional challenges because of their unique characteristics-reduced control, observability, visibility, and trust; and increased coordination and collaboration. Therefore, assuring service-oriented systems requires a new mindset; modification of existing assurance methods, techniques, and tools; new methods; and most importantly, successful collaboration and coordination between the broad set of participants in a service-oriented environment. This paper introduces a framework for assurance in a web-servicesbased, service-oriented environment. The paper discusses the challenges and implications of the characteristics of serviceoriented systems on assurance activities, based on the framework. It then provides guidance to address some of these challenges using existing and new assurance techniques.

Traditional requirements engineering for single systems, while remaining a large challenge for engineers, has been extensively researched and many techniques have been proposed and used with varying degree of success. However, many modern systems of systems are being developed to support interaction across multiple controlling authorities and existing techniques are proving to be inadequate for meeting the challenges of requirements engineering for systems of systems. This paper discusses some of these challenges, examines several existing techniques, and discusses how these techniques could be applied to engineer requirements for systems of systems.

Over the past decade, the complexity of new and acquired systems of systems has increased dramatically. Until now, research has mainly focused on the properties of systems of systems. Recently, paradigms such as service oriented architecture (SOA) and Grid computing are being adopted to implement systems of systems. Additionally, techniques such as SoS Navigator are being developed to identify complexrelationships among organizations participating insuch systems of systems. However, there is no unifiedbody of knowledge that captures the engineeringpractices necessary for creating and managing systemsof systems. Further research is required to build this body of knowledge, but two main challenges must be addressed.

Standards have been instrumental in achieving the significant level of systems interoperability we rely on in almost every domain. Many organizations are betting on the ability of standards to provide unprecedented end-to-end systems interoperability with partner organizations. Our experience suggests that the expectation of what can be achieved with standards is too high. For example, many large health care providers assume that moving to a new version of a major health care standard (HL7 3.0 and the associated reference information models) will guarantee "seamless" interoperability across all health care systems inside the enterprise. However, this new standard does not take into account clinical workflows and operational contexts that differ across point-of care systems and have a large effect on how accurately clinicians interpret data. This paper offers a caution, not that standards are not useful but that organizations need to be aware of limitations of standards they are adopting to achieve systems interoperability. After discussing these limitations, we present some strategies to minimize their effect.

Service-Oriented Architecture (SOA) is having a major impact on the development of software systems because of its potential for increased business agility, adaptability of applications, interoperability between systems, and reuse of legacy assets. However, organizations often make decisions on SOA adoption without carefully analyzing the implications of their decisions. This article outlines a set of common misconceptions about SOA and suggests ways in which software development lifecycle activities can be adapted to account for the characteristics of SOA-based systems. Copyright © 2008 John Wiley & Sons, Ltd.

(Abstract) In order to satisfy net-centric warfare goals, there is increasing reliance on systems of interconnected systems. This paper describes a method for analyzing the survivability of missions in such an environment by considering the stresses that occur between systems. The method was applied to the time sensitive targeting mission thread.

You don't have to look far to become aware of the effect that service-oriented architecture (SOA) is having on software systems. Vendors are aggressively marketing hardware, software, tools, and services that support SOA implementation within organizations as diverse as the Department of Defense, banks, federal agencies, manufacturing companies, and health care providers. Even more significantly, customers are embracing SOA as a way to successfully achieve business agility and interoperability among systems. However, our experience from working with current and potential adopters of SOA is that they often have a variety of misconceptions that lead them to oversimplify the effort required to implement SOA. Chief among these misconceptions is the belief that simply by adopting an SOA strategy for the enterprise, an organization has established a well-crafted architecture that will help the organization achieve its many IT goals. In reality, SOA is not an architecture, but an architectural pattern from which an infinite number of architectures can be derived - both good and bad. In this experience report, we discuss at a high level this and several other misconceptions about SOA derived from our experiences

An effective way of leveraging the value of legacy systems is to expose their functionality, or subsets of it, as services. In the business world, this has become a very popular approach because it allows underlying systems to remain largely unchanged, while exposing functionality to a larger number of clients through well-defined service interfaces. The U.S. Department Of Defense (DoD) is also adopting this approach by defining service-oriented architectures (SOAs) that include a set of infrastructure common services on which organizations can build additional domain services or applications. When legacy systems or components are to be used as the foundation for domain services, there must be an analysis of how to convert the functionality in existing systems into services. This analysis should consider the specific interactions that will be required by the SOA and any changes that need to be made to the legacy components. We have recently helped an organization evaluate the potential for converting components of an existing system into services that would run in a new and tightly constrained DoD SOA environment. This paper describes the process that was used and outlines several issues that need to be addressed in making similar migrations.

: Systems of systems introduce complications for information technology (IT) governance because their individual system components exhibit considerable autonomy. This technical note examines the ways in which six key characteristics of good IT governance are affected by the autonomy of individual systems in a system of systems. The characteristics discussed are as follows: (1) collaboration and authority, (2) motivation and accountability, (3) multiple models, (4) expectation of evolution, (5) highly fluid processes, and (6) minimal centrality. This report examines each characteristic in detail and, where possible, provides guidance for the practitioner.

Most autonomic systems consist of a number of components and systems. These systems require a high degree of interoperability between the constituent components and systems. We describe current research on the topic of interoperability that has relevance for autonomic systems and list a set of critical properties of interoperability that need to be considered in designing autonomic systems.