Message Bus Architecture - An Intro

[Mark_SAI]

Introduction

It all started when I was browsing across the forums and realised that I wanted an architecture that took all my favorite elements of LabVIEW (User events, Polymorphic VIs, Ease of Use, Flexibility being among them) and put them together all in one architecture...

Concepts

Let me introduce the idea of a Message Bus. You have subscribers to a message bus that can send or receive messages and perform actions as a result.

A subscriber spends most of its time waiting for a message on the bus, and once its received a message, it can choose to discard or process it, and perform any neccessary actions.

So what is a message? Its a user event that contains a Message ID and Message Data (as shown below)

Ok, thats good so far, but what about SubVIs?

I propose that SubVIs (By this, I mean major SubVIs, that contain a big portion of your programs functionality like the DAQ handler, or a Comms handler) have their own local message bus and are linked to the top level bus via a Link. This means that all Top Level messages like Stop commands/Control commands are forwarded to the local message bus. This allows you to Stop all the subscribers (and hence the SubVI) from the top level easily, as well as send configuration/start/data messages. Now you have something that conceptually looks like this:

Now I'm thinking- how I report things like error data back to the top level so it can decide whats next in terms of program execution?

...with this architecture its easy to send data back up to the Top Level VI too.

Execution

What do the VIs look like?

What would a typical subscriber look like?

I have written an example VI that shows typical usage of this architecture, including the 'Link and Filter' functionality where a local bus can choose to only listen to certain message IDs, therefore reducing the traffic internally.

If you have any questions, please comment on this and if it highlights a lack of detail in this article, I will append it in.

I have attached 2 versions of the architecture, both in LabVIEW 2009SP1. One uses Strings in the Message ID, and the other uses a Strict Type Def Enum as the Message ID. Both have their advantages and disadvantages (loose coupling vs. tight coupling), and if you are undecided with this, I'd look at the String version first.

[swatts]

Nice work, elegant, I'm wondering if you could encapsulate the queue reference by putting the whole lot in a wrapper VI.

[Mark_SAI]

I thought about it, it would likely involve some complications though as its not the same queue reference everywhere (I.e. Top level Bus and Local Bus) so I'd be looking at having a .vit component that I spawn an instance of for every unique bus and track which VIs are using which VIT reference which is certainly possible and I may well give this a go. (I would have to call it something totally different! Message Cloud perhaps...)

[swatts]

hmmmm,On second thoughts i like the idea of using the polymorphic selector as the VI command. I reckon that a support VI should hold the queue reference internally. Looking at the technique, rather than the architecture I'm thinking this could be the basis of a rethink on our component design (LV "Functional Global" based state machine)..... you got me thinking boyo. 

[nblume]

This is very nicely done, but 2 of the 3 times I have run the example VI, it has frozen LabVIEW.  The first time, it didn't happen until I tried to send a "Stop" message.  The other time it happened immediately after pressing the Run button.  Have you had any issues with this?  Any ideas what might be causing it?

[Mark_SAI]

Which version of LabVIEW are you using?

Do you have FDS or a lower version?

I'm interested in tracking down the cause of your crash. I am certain its not a fault with the underlying architecture as its heavily based on an architecture that has been used for large projects in the past.

[Mark_SAI]

The code as it stands needs updating (I will try and get round to updating the links in the article). All VIs should be changed to re-entrant (Pre-allocate) for the architecture to work bug-free during debugging/highlight execution.

[Joe India]

Nice work. I will get back with a detailed feedback.

[prajwal.prithviraj]

thx macaba,u have opened the box .we need to start thinking in ur way.