Blackboard Architecture
(This discussion deliberately parallels FifoArchitecture: compare and contrast. Although it talks about the blackboard system as if it were built, it's all hypothetical at this point, so take it with a grain of salt.)
Description: The Blackboard Architecture is an alternate way of structuring the suite of flight computer software tasks. The blackboard is the focal point for all flight computer software interactions--- the suite of applications handles input/output to CAN and Wireless LAN in accordance with the flight computer state model.
The blackboard system consists of a handful of processes each focusing on a specific asynchronous task:
- can_rdr - Reads messages from the CAN device driver and posts them on the blackboard.
- can_wtr - Watches for CAN messages posted on the blackboard by other processes and writes them to the CAN device driver.
- sensor agents - A suite of sensor agents, roughly one per CAN node, although some CAN nodes e.g. the recovery node may have more than one sensor agent (power, recovery status) and some may have none (ATV). Each sensor agent watches the blackboard for CAN messages posted by can_rdr, does message processing, and posts "cooked" data to the blackboard.
- effector agent - Watches the sequencer blackboard for requested actions, and sends CAN messages to implement the requests.
- sequencer - Handles the flight computer state machine. Watches for posted information from the sensor and expert agents and posts action request for the effector agent. Implements the sequencer logic.
- expert agents - A suite of expert agents watch the blackboard for relevant information, interpret it according to their function, and write the resulting interpretation to the blackboard. Examples include:
- navigation agent - Interprets sensor data into position and velocity
- launch status agent - Interprets all data sources to produce an indication of launch, chuff, burnout, apogee, and parachute deployment.
- logger - Watches the blackboard for interesting information and logs it.
- fc2net - Watches the blackboard for telemetry messages, encapsulates them in UDP packets, and writes them to the blackboard for delivery by can_wrtr.
- net2fc - Watches the can_rdr for telemetry control messages, decapsulates them from UDP, and puts them on the blackboard for use by the other agents.
Agent management in the blackboard system is by cooperative multitasking. Facilities are provided for a thread to block until blackboard data is available, and to wake up blocked threads on message writes. Agents may be implemented as one or more threads, although typically only one is needed.
History: The blackboard architecture is a proposed replacement for the FIFO architecture, which replaced the earlier Can Muxer and Renegade architectures, which didn't get as far in implementation of the rocket application. The original flight controller was a hand-coded PIC assembly loop by AndrewGreenberg.
Pros: The main advantage to the blackboard architecture is its simplicity, flexibility, and extensibility. It provides a fairly intuitive fit to needed functionality. In addition, the architecture should provide for quite a bit of reuse of existing code, while allowing elimination of redundant, potentially buggy code.
Cons: The weakness to this model includes:
- Agents may be dependent on the blackboard data structures of multiple other agents. If not carefully managed, these dependency issues can become somewhat interesting.
- While the blackboard structure tends to make the control graph fairly explicit, this does not guarantee that the system will be deadlock, livelock, or race free.
- By supporting complex designs, the architecture may tend to encourage them.
-- BartMassey - 08 Oct 2003
Attachments: