Random Ramblings on LabVIEW Design

Community Browser
Showing results for 
Search instead for 
Did you mean: 

Re: Software Design an Electronic Design Analogy

Active Participant

Hello Data Driven Darlings

I've seen a few presentations that describe coupling and cohesion incorrectly and thought it might be an idea to revisit some material I have used in training before. I think all the talk about asynchronous processes (actors) also allows us to discuss the metaphor as well. 

Please note that this applies to all ways of designing software, using a methodology does not fix your coupling and cohesion issues. I've heard the statement "I use OOP and this gives me good coupling and cohesion" several times, only to be presented with a class full of references to other classes (Global Reference Object).


In our book we used an factory analogy and it worked OK. In a training course that we provide we use an electronic design metaphor and I think this might be a better analogy going forward.


First of all let's take a look at a simple electronic schematic and review cohesion

Cohesion – A measure of how strongly the elements within a module are related. The stronger the better. 


Our design task is to break this circuit into printed circuit boards (pcbs).

As a designer we could just split the schema like this and create 6 pcbs.


This is coincidental cohesion and I've seen it's use in LabVIEW by careless use of the Create SubVI function. Signs that you are suffering from this are:-

Lack of re-usable functions : the pcbs can only be used for this type of job.

Difficulty in naming : giving each pcb a name and purpose is difficult.

Difficulty testing : the pcbs can only really be tested when fully assembled.


We can easily improve the design by breaking out the functions of each pcb (functional cohesion). Here's a reasonable effort.


As a bonus we can see that the amount of inputs and outputs has been reduced. So improving cohesion also improves coupling too.

Improvements functional cohesion gives are :-

You can take some of these pcbs and use them in other pieces of equipment.

Testing should be simplified, because of clarity of purpose and simplified interface.

Pcb naming and functionality is nice and clear.


This is equivalent of a standard functional LabVIEW program, with nicely defined subVIs.


The next improvement would be to add a bit of complexity to our requirements. As an example let's take the PSU, I would like to be able to adjust the voltage and current, read-back the voltage and current, get calibration details and set calibration details. This can be done at board level with potentiometers, screens and an instruction manual. Alternatively we could have a messaging system to set and get parameters. This frees up our design from specific constraints and as long as the messaging interface is consistent the design details remain hidden. From our cohesive PSU pcb we are now considering coupling and how we can decouple (hide) design details from the overall design. This is information hiding.


Frees the design from specific implementations : just buy a PSU with the correct protocol, pop it in and away you go.

Change is easy to accommodate (if the interface is designed thoughtfully)

Design is simplified : we don't need to understand PSUs, we just need to know the interface.


Coupling - A measure of the degree of independence between modules. When there is little interaction between two modules, the modules are described as loosely coupled. When there is a high degree of interaction the modules are described as tightly coupled.


This describes LCOD/action engines/by ref objects pretty well. We have always called it component design.


This Eaton PLC system illustrates what we call component design quite nicely I think*.


Each component in the system has a messaging system connecting everything together, each is a discrete component. The communications interface (SmartWireDT) allows additional features to be easily integrated.


So how do Actors fit into this analogy? I think we have to view an actor-based hardware system as a distributed system that can expand and contract to fit the problem at hand. One of the issues I have with it, is that I can't see that many real-world example that will need this extra effort.


Possible real world examples - Network of computers?? SCADA system where channels etc can be added automatically. Looking at large scale projects that use actor model languages we have messaging type applications (WhatsApp, Amazon and Facebook use Erlang mainly only where dynamic spawning is required i.e. dBs and connection management)


Hopefully cleverer peeps than me will fill in the blanks!

Off to Galway Ireland to speak at Dev Days next week (22nd June), should be fun! Say hello if you are joining us.

Le grá mór


* I've tried to improve the description of the component based system analogy (Thanks Mr Altenbach for the feedback)





 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png
Knight of NI

Nice post!


If you describe the extremes of coupling (loosely, tightly) followed by a sentence like: "This Eaton PLC system illustrates it quite nicely I think.". things become very ambiguous because we cannot tell which kind of coupling you are trying to illustrate with "it".

Active Participant

Can't say as I disagree Christian, I'll edit it in the next couple of days to clarify and expand the point.

Many thanks for your feedback, it's most appreciated.


 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png
Knight of NI

Ironically, I just finished a program that is running into issues because the circuit boards were not quite modularized properly.


One of the things I really like about being a Test Engineer is I get to see nearly all the aspects of engineering (a lot more than being an RF coop, a pure software engineer, or even a controls engineer).  And the more I see, the more I am convinced that good Software Engineering processes are no different (conceptually) than good general engineering processes (mechanical, electrical, etc).  I had a conversation last year with an RF engineer who bragged about how he could see all of his LabVIEW code in a single (very large) VI because he claimed he wanted to be able to see all of the details.  My mind went to his RF design diagrams where things were abstracted away (filter, amplifier, filter, pa, antenna instead of all the resistors, capacitors, inductors, transistors, etc).  So why treat code any differently?


So, Steve, I really like that you are showing software concepts as hardware concepts.  The parallels are not coincidental.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

The discussions from the Advanced User Track is not over. Join in the conversation: 2016 Advanced Users Track
Active Participant

Thanks Tim

Factory design and social design also have close parallels. I think there is a clear actor-oriented analogy (someone hopefully will say...how about such and such and it will all become clear)

 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png