Julia W. Loftis, Associate Chief for Information Systems Technology
- Thursday, 01 March 2007
NTB: Why was the software developed?
Loftis: Originally, what we were looking at, what we perceived as a technology organization, was future needs. And in any application where you may be searching for something, it’s logical that you would have multiple platforms do this rather than just one. We were thinking of applications for rovers on the surface of Mars for mapping or site-surveying — anything where you would have to do local, in situ measurements. We were looking for software that could control a fleet of platforms to do this, instead of a single platform.
Goddard has been very interested in the concept of “sensor webs,” multiple sensors that act as a coherent system. In particular, when you can’t do remote sensing, for example, if an area is cloud covered, that’s when you send sensors in to measure in situ, right where they are. For under cloud-covered areas or sub-surface measurements, that’s when you are really going to need to send in fleets of platforms, which is essentially a sensor web. So we are looking at this concept of dynamic, moveable, optimizable sensor webs.
As for me, my job as Code 580 Assistant Chief for Technology is to do strategic planning, which identified the need for such a system, create partnerships, with the OASIS boats led by oceanographer at WFF Dr. John Moisan, find funding and sell the project (IRAD, then AIST), formulate a project with project lead Jeff Hosler and Troy Ames who provided the underlying technology, and monitor its progress while continuing to look for new opportunities for application and funding.
NTB: Describe the ASF architecture and how the process works.
Loftis: I want to emphasize that ASF is different from many approaches that are “peer-to-peer.” A peer-to-peer approach would be a single platform, would make its own decisions based on its environment, and would be autonomous. Each platform would be autonomous and communicate to each other. ASF is a supervisory system. It’s very good if some of your platforms aren’t “smart” and it is very efficient; it can see the forest for the trees.
In XML, ASF is first configured to know what platforms are there, their characteristics like its inputs and outputs, what controls are used. What happens is, a user then sets up a goal or objective within ASF, and says what area he or she wants to monitor, what is being looked for. ASF takes that goal and parses it and divides the work among the platforms that are available. Then ASF will go about sending directions to each platform as to what measurements to take and what waypoints to go to, and it will continue to monitor the fleet as the data is collected and it will fuse the data and present it to the consol operator. It will accomplish the goal, and display all the data.
A central consol controls the platforms. It could be stationary buoy, it could be a remote-sensing satellite, and they all work together. From the remote sense data, we might find out where the algal bloom is; we might collect data from the stationary buoys and we could instruct the boats to go to them. It would be a mixed fleet of all types of platforms. Additionally, ASF would immediately know if a platform failed. It’s a controlled means, directing each platform and controlling what it does, to adapt if one gets stuck or breaks. It will have the others fill in and take that work. ASF is monitoring the progress that each platform takes, and it would assign another platform to take over that area.