BlinkenBone - architecture overview

Components of BlinkenBone

It was much fun to split the BlinkenBone system into cleanly separated modules, which communicate over meaningful interfaces.
But after that I had to fiddle long with this  "Architectural overview" diagram:

(click image to enlarge)

Perhaps this is overengineered, but I wanted to create the final architecture for any future blinkenlight project.

Well, I hope you can recognize the main components:

• Real physical console panels are connected to I/O boards ("BlinkenBoard").
• many parallel BlinkenBoard are connected to one BeagleBone over a parallel bus ("BlinkenBus")
• The low level interface to all these board is a Linux file device named "/dev/blinkenbus".
• On top of the file interface, the "Blinkenlight API server" provides a high level interface to the panels.
  He abstracts the digital I/O signals into high level objects like "panel" and "control".
• The Blinkenlight API communication model is split into client application programs, and servers providing panel control (a "two-tier" architecture).
• A console panel can also be simulated. The simulation program must also act as server. It can run on any computer and is not bound to the BeagleBone. PAnelsimulations are written in Java Swing, so they are platform independent.
• Test programs, machine simulations (SimH), or some other show programs are all clients to the Blinkenlight API server. They can run on any computer.
  They set lamps and react on switch settings like the real machine behind the console.

Why a client/server model?

The split of application logic into "clients" and "servers" gives an immense degree of freedom for a BlinkenBone installation:

• Flexible interconnection between clients and servers:  For example, a maschine simulation program can easily access different console panels or simulation just by connecting it to a different server. (one client - alternating servers - alternating panels)
• One panel installation can be driven by alternating client program. For example, you could operate a given console panel either with SimH or a Web interface or a "kiosk mode" show program (alternating clients - one BeagleBone - one panel)
• One BlinkenBus can control many I/O boards, so one BeagleBone can control more than one console panel. Then many simulation programs each can access their own panel over the same BeagleBone. (many clients - one BeagleBone - many panels)
• One machine simulation program could even access many BeagleBones in parallel (one client - multiple BeagleBones - many more panels). So the system is expandable beyound imagination.
• If the BeagleBone/BlinkenBus/BlinkenBoard system is replaced by some other hardware in the future, existing client programs need not to be touched.
  (same client programs - changing panel hardware server)
• BeagleBone can act as headless remote controller for console panels, and can be controlled over WLAN.
• Development of client machine simulation applications for consoles can be done under Ubuntu or Windows. So cross compiling/cross debugging is mostly elimanted, software development can be done without physical access to the BeagleBone server.
• All clients can always run on the BeagleBone itself, by communicating to the Blinkenlight API server at "localhost".

MVC

If you're a fan of the "Model-View-Controller" pattern, you can reorder the BlinkenBone architecture as follows:

• the "Model" (business logic and data objects) are provided by the Blinkenlight API server. He has data structures about panels and their controls and allows to manipulate them.
• the "Controller" (user input logic) sits in the Blinkenlight API client (a machine simulation). The simulation program changes the state of the panel according to the user input (switch flipping) and the machine state.
• the "View" is just the physical console panel (or its graphical simulation). This is the front end the user interacts with.

Layers

An actual BlinkenBone application can be written as stack of components. For example, the video on the Intro page shows SimH controlling a PDP-11/40 console panel. This is the component setup:

Impressive, isn't it?