|Acquisition Program: || Objective: ||Provide a scalable framework for ingesting, analyzing and distributing streaming audio and video data to support various DoD needs.
|| Description: ||A scalable framework that allows disparate formats, analysis algorithms, ingestion systems, and presentation systems to be integrated in a loosely coupled fashion to exploit large amounts of streaming audio and video data.
Many current DoD Command and Control and ISR systems are of a typical stovepipe design that does not allow for horizontal integration of functionalities and data. The DoD is moving away from this approach and going a more modular and pluggable design. In the past, many streaming media workflows were designed with the intent of addressing a specific need and without requirements to be interoperable or modifiable on the fly. This framework will change that.
In order to provide warfighters with the correct and relevant information in a timely fashion, this framework will expose interfaces for the analysis algorithms, ingestion systems and distribution methods. It will also provide for the mediation of formats. Together this will allow a user to run any analysis algorithms on a stream from any source and present it to any consumer. Such workflows will be made available for consumption by other analysts. Workflows that are already established, formalized and vetted as business processes will also benefit from this. The system will provide a functionality to convert business processes to executable workflows. This will eliminate some of the manual conversion and integration in these processes, while keeping the processes as they were formalized.
This topic presents several challenges. Many of them fall under the category of interoperability issues and include such items as: mediating between formats without information loss and exposing interfaces to analysis algorithms, ingestion systems, and distribution systems to make them pluggable. In addition such a framework will need to be scalable. New algorithms, formats, and data sources should be easily added. Scalability will also extend to the ability to support highly complex workflows and large numbers of streaming data sources. It is also expected to conform to established standards used by the DoD and industry.
The OSD is interested in innovative R&D that involves technical risk. Proposed work should have technical and scientific merit. Creative solutions are encouraged.
|| ||PHASE I: Complete a systems architecture design and engineering plan. Identify the gaps and pitfalls in designing a system with the currently available technology. Establish approaches to meet these gaps and avoid these pitfalls.
|| ||PHASE II: Complete a prototype system that demonstrates the ability to work with several formats, analysis algorithms, ingestion systems, and presentations systems in a basic ISR workflow. The system should also demonstrate the ability to be scaled so that other functionalities may be added with limited time and development cost.
|| ||PHASE III: Complete a deployable system that is capable of functioning in an operational environment. Test the system in the operational setting and provide performance metrics for said system. Metrics should indicate the ability to function in an operational environment. Functional requirements necessary to transition to one of the military Services should also be evaluated.
|| References: ||1. J. A. Ballas and J. Nevitt. “Using Web Services to Foster Global Collaboration in Sound Design.” Proceedings of the 14th International Conference on Auditory Display, Paris, France (2008).
2. H. Detmold, A. Dick, K. Falkner, D. Munro, A. van den Hangel, and R. Morrison. “MiddleWare for Distributed Video Surveillance.” IEEE Distributed Systems Online. Feb. 2008.
3. H. Detmold, A. Dick, K. Falkner, D. Munro, A. van den Hangel, and R. Morrison. “Scalable surveillance software architecture.” Proceedings of the IEEE International Conference on Advanced Video and Signal-based Surveillance (poster) (2006).
4. N. Dube, H. Bhatt, R. Ramakrishna, K.S. Dasgupta. “Service Oriented Architecture for Satellite Image Processing. “ Proceedings of the 13th International Conference on Advanced Computing and Communications (ADCOM) (2005).|
|Keywords: ||streaming video, streaming audio, analysis algorithms, scalable framework, ISR workflow, business process|
Questions and Answers:
Q: What is the nature of the video? I.E. what kinds of algorithms will be applied to the content?
A: The video could possibly be anything that is or will be used by the DoD in the future. The algorithms could possibly be anything currently used in the DoD and anything that the DoD might use in the future. The focus of this topic is not one type of algorithm or workflow, but a modular framework.
Q: Is it acceptable to respond to a subset of the topic?
A: No, all aspects of the topic should be responded to.
Q: Given the emphasis on workflow, is there a standard workflow language in effect within the DoD?
If not, can OSD suggest an approach that will not require conducting a survey of the forms of workflow in use throughout DoD. Such a survey seems beyond the scope of an SBIR.
A: The emphasis is on the framework and its modularity/flexibility to produce many varied workflows. There is no standard workflow language in effect or targeted for this SBIR.
The topic states, " Such workflows will be made available for consumption by other analysts. Workflows that are already established, formalized and vetted as business processes will also benefit from this." This statement only indicates that a framework should have some way to store workflows so they may be used again. Many terms have been used for this including, but not limited to, recipe, template, workflow, and orchestration. The mechanism used for doing this is an engineering design decision to be made by the proposer/performer.
Q: Developing a framework allowing "disparate ... ingestion systems, and presentation systems to be integrated..." could require a survey of all such systems. This would seem out of scope for an SBIR. Does a list of such systems exist?
A: A survey of all such systems is not necessary. A general knowledge of such systems is necessary in order to design a sufficiently flexible and extensible framework.
A survey of all such systems would not be very useful and miss the mark on several regards. For instance, new systems will be acquired, designed, and used by the DoD and survey would miss these systems. In addition it is no possible to anticipate the use of legacy systems or systems outside the DoD's control.
Q: The submissions for SBIRs requires choosing one of OSD/AF, OSD/Army, OSD/DARPA or OSD/Navy. Which of these choices applies to this SBIR?
A: For this topic please select OSD/Navy.