1.0.0 Getting Started - lokokung/Starburst-Front-End-Control-System GitHub Wiki

Introduction to the Architecture

The architecture of the control system for the feanta computer is based on the physical hardware architecture in order to give both an intuitive feel for the system and allow for easy interchange of hardware when necessary. The main server to the system runs as a daemon after initiation and is flexible in the number of commands that it offers. To make this more clear, prior to starting the daemon, users have the option to link different sets of workers to the daemon which dictate what commands the daemon will be able to handle. The workers are concrete implementations of the IWorker class and represent a piece of hardware somehow linked to the feanta computer. In order to stick to object oriented programming standards, the different classes are separated into separate source files for concise and manageable code. For syntax purposes, the source file for different classes will be placed in parenthesis following the class.

ServerDaemon (feanta_server.py)

This class is the daemon class. In comparison to the physical system, it is the feanta computer itself. This class is initiated with a single parameter, a string ending with ".pid" to indicate where to put the pid file. The pid file is used to stop the daemon process either by manually reading the pid number in the file and killing the process from the command line or by executing the stop() method offered by the class. By default all processes handled by this server is logged with a time-stamp into the file defined by LOG_FILE in the source code. The class does, however, offer a set_log_file(log_file_destination) method to override the default location for the log.

Similar to how in terms of hardware, each new piece of hardware needs to be connected to the main computer for it to function, the link_worker(worker) method takes a IWorker instance and connects it to the server. The link_worker(worker) function will communicate with the worker and determine what commands the worker handles and map all incoming commands from the ACC to the worker which them processes the commands.

In order to see what workers are connected to an instance of ServerDaemon, the list_commands()' function returns a list of all commands that the ServerDaemon is capable of handling. Similarly, the list_workers()` command returns a string listing the workers currently connected to the instance.

Once workers have been linked and log file configurations setup, the ServerDaemon can be either started with the start() command or the run() command. The run() command does not start the server as a daemon, rather it starts it in the command prompt. This is useful for debugging and testing. The start() method does, however, start the server as a daemon. Once started, it will continue to run unless something causes the server to crash or the stop() command is issued. (Or if the process is manually killed from the prompt.)

IWorker (i_worker.py)

The IWorker class is the abstract class that all workers that connect with the ServerDaemon must extend. The two unimplemented methods are get_command_list() and execute(acc_command). The get_command_list() method must be implemented to return a list of commands that the worker is capable of handling. This method is used to let the ServerDaemon know what commands should be routed to this particular worker. The execute(acc_command) method is the command that receives an ACC command array once the command is executed from the ACC and routed to the worker from the ServerDaemon.

For standardization purposes, all concrete extensions of IWorker classes should have blocks within the source separated in the categories: Private worker-specific routines, command routines, function map, stateframe querying helper methods, public worker-specific routines, and finally IWorker abstract implementations. Look into the source of a concrete implementation of an IWorker in order to see an example.