Now, about that NASA Stuff ...
NASA determined in the mid 90's they would look into agent technology. There motivation was to automate some of the manual functions of the space missions performed at ground control centers and space systems. Even NASA, concerned with reducing the cost of its missions and operations, saw the possibilities that automating as many operations as possible would do just that. Their goal was to rely more on intelligent systems (which means less human interaction and intervention).At the time the agent concept had been around since the 40's but it was in the late 80's and 90's when the technology was really being implemented and showing promise (Artificial Life, SWARM and NetLOGO, etc.). So there was a risk in using a relative new technology with space missions which were in themselves already highly risky. In order to use this technology, they had to investigate ways to assure that the software would be correct. The Advanced Architectures and Automation, a branch of the Goddard Space Flight Center, had the responsibility of doing this job. An agent-based system you may be familiar with is RA (Remote Agent) developed at the Ames Research Center. The reason you may have heard of it is because it was first used on board Deep Space 1 in 1999. Deep Space 1 was a spacecraft that tested advanced, high risk technologies including the RA and was the first use of ion engines for an in flight spacecraft. Deep Space's mission was to flyby an asteroid and encounter a comet. RA was a reusable, artificial intelligent software system that allowed for goal-based spacecraft commanding. The RA allowed for levels of autonomy, enabling ground operators to interact with the spacecraft with immediate commands to the flight software using goals rather than the traditional detailed sequences of commands.
The AAA developed two agent-based systems: LOGOS (Lights-Out Ground Operations System and ACT (Agent Concept Testbed). LOGOS is amulti-agent system used for automating the satellite ground operations systems. LOGOS allows researchers to evaluate the performance and effectiveness of a community of agents operating in a ground system environment. LOGOS is comprised of a community of ten agents. Those agents interact with legacy software and databases as well as interact with other agents in the community. Here is a diagram of the LOGOS architecture.
An example of how LOGOS agents communicate and interacts with external systems is as follows:
- MIFA gets data from MOPSS that the spacecraft will be at a position where it will make contact at a certain time
- MIFA sends messages to other agents to inform them just in case there in some preprocessing that has to be done before the spacecraft is at the contact point
- GIFA gets the message then sends a message to GenSSA Data Server to begin to receive any transmissions from the ground control center
- Once the data server receives those transmissions it sends that data to GIFA which determines what part of the data should be sent to other agents, for example:
- GIFA sends engineering data to AIFA to archive and patterns are sent to VIFA for visualization
- Schedule information was sent to MIFA
- A report is sent to UIFA which sends the report to an analyst
- FIRE agent receives data on any anomalies
There is allot of parallelism going on during the asynchronous communications with the external systems and agents. What NASA found was that many race conditions occurred, for example;
- Agents would perform correctly on one computer but would miss messages or work incorrectly on another computer (we talked about how that occurs in previous blogs)
- Additional agents added to the community caused other agents to hang, crash or miss messages
- Inconsistent errors and buffer overflow occurred
Finding errors and race conditions in a parallel environment is very difficult using the traditional debugging techniques. Stringent eyeballing of code, testing, etc. may not be able to reveal all possible problems that results into race conditions. The standard approach to resolve some race conditions is to serialize some tasks and/or remove unneeded processing. But NASA needed also to remove any potential for race conditions and errors that they had not discovered. Failure is not an option! The software had to be correct! They decided to explore the use of formal methods in order to guarantee no errors and no race conditions. They decided to use CSP (Communication Sequential Processes) because it was able to model communication processes and utilize the local expertise. CSP was able to show the many omissions and race conditions that was not discovered yet.
The CSP specs for LOGOS was based on the inspection of the Java code and the design documents of the agents. Keep in mind that LOGOS was not (at that point) completely implemented, it was a proof-of-concept multi-agent system. But CSP only examined what was implemented or nearly implemented. First of all, the CSP specs defined LOGOS as:
LOGOS = AIFA || DBIFA || FIRE || LOG || MIFA || PAGER || SysMMA || UIFA || VIFA || Workplace
which means that all agents are running concurrently with Workplace communications software and each agent could communicate with any agent.
For further information on CSP, download the book on how to use it at this link:
Of course you recall that me and Cameron are on a wild goose chase down a yellow brick road of a particular set of AI-complete problems. Formal languages do get thrown in there and we'll share how weird it feels to use them when you're totally in the dark ...